AI PoCのよくある質問

技術検証が成功しても本番に進まず、検証だけが積み重なる状態を指します。本サイトでは「PoC止まり」と表記しています。原因として複数の案件で共通して観察されるのは、PoCの結果を見て何をもって次に進むと判断するのかが、事前に決まっていないことです。

PoCは技術的な実現可能性を中心に確認する段階、限定実運用は一部の業務・利用者で実際に使用して効果と運用を確認する段階です。最小限の機能で使ってもらい価値を確かめるMVPは、確認している対象としては限定実運用にあたります。

期間そのものより、「何を確かめ終わったら終了か」が決まっているかが重要です。期間だけを決めると、期間内に結論が出なかった場合に延長されます。延長する場合は、延長する理由と新しい終了条件を先に決めます。理由なく延長すると、次も延長されます。

規模と回数は別の問題です。小さく始めること自体は正しいのですが、判断条件がなければ、小さなPoCが何度も繰り返されるだけになります。規模より先に、終わり方を決めます。

対象業務が単純で、失敗したときの影響が限定的であれば、検証を省いて小さく本番導入する選択肢はあります。その場合も、判断の時点とNo-Goの条件は先に決めます。PoCという形式が必要なのではなく、判断の設計が必要です。

PoCの回数を増やすのではなく、1件を本番まで通すことに集中したほうが早く到達します。PoCは回数を重ねても成果になりません。成果は本番で業務が変わったときに出ます。判断条件を設けて不要なPoCを減らすことが、結果的に最短経路になります。

小さくて確実な効果のほうが、大きくて不確実な効果より投資判断に耐えます。絞った理由と、全体に広げた場合の見込みを併記します。「今回は条件Aの○件が対象。全体に広げる場合は条件Bへの対応が必要で、そこは今回の検証範囲外」と書けば、決裁者は段階的な投資として判断できます。

そうではありません。効果が損益に届きにくいと分かったうえで、別の理由で起案します。品質の安定、リスクの低減、担当者の属人性の解消は、金額にならなくても投資理由になります。問題になるのは、金額にならない効果を金額として出すことです。

「誰にとっての成果か」で3つに分けて見ます。業務にとっての成果（事業KPI：処理時間、AIの出力の採用率）、利用者・お客様にとっての成果（サービスKPI：初回解決率、待ち時間）、会社にとっての成果（経営KPI：総対応コスト、売上・利益）です。自社の作業量だけを見ると、受け手の体験が悪化していても気づけません。

一律の基準はありません。業務によって、誤りが起きたときのコストが異なるためです。誤りを人が発見できる業務と、そのまま外部に出る業務では、必要な水準がまったく違います。精度の目標値は、誤りが起きたときに何が起こるかから逆算して決めます。

何件のうち0件なのかが書かれていなければ判断に使えません。件数の少ない評価で0件が出ることと、必要な水準を満たすことは別です。許容値と評価件数は一組で決めます。

社内での概算や、業務改善の効果を現場で共有する目的であれば有効です。ただし、役員会に出す効果額として提出すると通りません。その金額は支出として減っていないためです。用途を分けて使います。

報告できます。金額欄に入れないだけです。定性的な効果は別枠で書き、判断材料のひとつとして扱います。金額欄に推計値を混ぜると、確認できる部分まで疑われます。

社内の投資基準に依存します。ただしAI案件では、「ROIが何パーセントか」より「その数字がどの前提の上に立っているか」が問われることが多くあります。前提が明示されていないROIは、数値の大小にかかわらず判断材料になりません。

前提が合いません。従来のシステムはリリース時点でほぼ完成しており、以降は保守費だけです。AIはMVPとしてリリースし、使いながら精度と自動化率を上げていくため、リリース後も投資が継続します。

いつ何が確認できるかを、時点で示します。「3か月後に処理可能率、6か月後に定着、12か月後に損益影響を確認する」と書きます。途中の時点で損益影響を求められないよう、先に合意しておくことが重要です。

効果額に対して投資額が大きすぎる可能性があります。対象業務を絞って投資額を下げるか、検証目的の小規模な起案に切り替えます。効果を大きく見せる方向で調整すると、後で必ず問題になります。

読めないことを前提に、基本・上振れ・下振れの3通りで出します。それぞれが成り立つ前提も併記します。上限を超えたときにどうするか（利用を絞るか、追加予算を申請するか）まで書いておくと、判断に耐えます。

全社一律のツール配布は、特定の業務に組み込むAIとは分けて考えます。一律のまま効果額を出そうとすると、ほぼ必ず「削減時間 × 単価」になり、役員会で通りません。効果を出すのであれば、全社の利用状況から成果が出ている業務を特定し、その業務単位で測り直すほうが確実です。

効果の定義は推進部門、金額への変換は経理・財務、判断は役員です。この3者の役割を分けておくと、報告会で計算式を巡る議論になりません。推進部門が金額まで作って提出すると、その数字の妥当性を巡る議論から始まります。

企画の段階です。効果額が固まってからではなく、対象業務を選ぶ段階で一度話しておくと後戻りが減ります。要員計画のある業務かどうかは、財務側のほうが把握していることが多くあります。

他社の数字は、対象業務・算定方法・期間が分からないと比較できません。特に、削減時間を単価で金額化した数字と、支出の変化を追った数字では桁が違って見えます。比較する前に算定方法を確認します。

許容を判断する人を決めないまま、対策の設計から議論を始めているためです。対策はいくらでも積み増せるため、どこまで備えれば足りるかを決める人がいなければ、議論は閉じません。計画書の段階で、リスク区分とその理由に加えて、許容を判断するのが誰かを先に決めます。撤退する場合に何が必要かも、あわせて見積もっておきます。

人の承認を挟む操作と、自動で実行してよい操作の切り分けを確かめます。取り消しにくい操作を自動の側に置いたまま検証すると、本番で初めて問題が表面化します。停止できるか、前の状態に戻せるかも、設計上の可否ではなく実際に試して確かめます。重要な案件では、不正な指示を含む文書を読ませて、権限を超えた操作が起きないかも試験します。

社内のルールで認められた範囲であれば扱えます。入力・保存・学習への利用・削除の可否を、PoCの環境について個別に確かめます。PoCの環境と本番の環境では条件が異なることが多く、PoCで問題がなかったことは、本番で扱えることを意味しません。

PoCの開始前に運用部署の合意を取り、取れない場合は案件のタイミングを見直します。決まらないまま進めると、稼働直前に押し付け合いになります。設計した部署と運用する部署が異なる場合は、引き渡しの設計を最初に行います。合意が取れないこと自体が、この案件が今やるべきものではないという情報です。

PoCの支援体制と本番の運用体制が別物だからです。PoCはベンダーと情報システム部門で回せても、本番は業務部門が回すことになります。精度監視、例外処理、データ更新、問い合わせ対応は、まだ誰の職務記述書にも書かれていません。工数と担い手を決めていない場合、使われなくなるのは自然な結果です。

次のPoCを始める前に、「この検証の結果がこうなら、この案件はNo-Goとする」という条件を文書にし、決裁者と合意します。条件がないまま続けると、検証は無限に続きます。すでに走っているPoCについては、次の報告会を「判断の会」と定義し直し、その場で4区分のいずれかを出すと決めるところから始まります。

結果の良し悪しではなく、判断材料の不足を指摘されている可能性が高い状態です。業務効果／品質・精度／経済性／リスク／運用可能性の5観点が埋まっているかを確認します。特に、経済性のうち運用費の部分と、運用可能性が抜けていることが多くあります。

実装したベンダー以外の目を一つ入れると、判断が安定します。技術的な妥当性だけでなく、投資判断に必要な材料が揃っているかを確認する役割です。契約が続くことが収益になる立場からは、撤退を含む提案は構造上出にくくなります。姿勢の問題ではなく、事業構造の問題です。

他社の成功は、自社の判断材料にはなりません。確認すべきは、その事例の対象業務の性質、データの状態、運用体制が自社と比較可能かどうかです。比較できないのであれば、参考情報として扱います。事例をそのまま自社の期待値にすると外れます。

2択にすると、多くの案件がどちらにも決まりません。実際に起きるのはその中間だからです。判定は Go／条件付きGo／保留・再設計／No-Go の4区分で置きます。保留・再設計は例外扱いで、材料の遅れは条件付きGo、何が足りないかを項目名で書けない場合はNo-Goです。