「PoC（実証実験）は終わった。で、本番に進めていいのか」——AIプロジェクトでもっとも決めにくいのが、この場面です。結論から言うと、PoCから本番へ進めてよいかは、結果を見てから考えるのではなく、PoCを始める前に「Goとする最低ライン」を決めておくことで判断できます。 判断の観点は、事業成果・精度・運用・リスク・採算の5つです。
この記事では、Go/No-Go判断の5つの観点、結論の4つの形、判定シートの作り方、具体例を解説します。PoCが本番に進まない構造そのものについてはAI導入がPoC止まりになる本当の理由で扱っています。ここでは、PoCの結果を、どう決めるかに絞ります。
なぜPoCの結果は「判断」が難しいのか？
PoCの判断が難しいのは、結果が「動いた／動かない」の二択ではなく、「ある条件では動いた」という中間の形で返ってくるからです。
典型的には、次のような結果になります。
- 精度は「まあまあ」。使えそうだが、間違いも出る
- 一部の業務では効果があるが、例外が多い業務では効かない
- 機能は動いたが、本番の運用を誰が担うかが決まっていない
こうした中間の結果を、基準なしに見ると、判断は声の大きい人の印象に引っ張られます。「もう少し様子を見よう」と先送りされ、結局PoC止まりになるのも、この状況です。
だからこそ、結果が出る前に、何を満たせば進めるのかを決めておくことが要ります。
Go/No-Goを決める5つの観点とは？
Go/No-Goは、事業成果・精度・運用・リスク・採算の5つの観点で、それぞれ最低ラインを決めて判断します。
Go/No-Go を決める5観点。技術だけ（精度）で決めると、運用・リスク・採算の見落としが本番で表に出る
1. 事業成果：対象業務の何が、どれだけ改善したか
最初に見るのは、技術の指標ではなく業務の指標です。たとえば「問い合わせ対応にかかる時間」「資料作成の件数」のように、PoCの前に測れていた数字を使います。ここが測れていないPoCは、判断の土台がありません。費用対効果の測り方はAI導入の費用対効果（ROI）はどう考える？で扱っています。
2. 精度：本番と同じ条件で、基準を満たしたか
PoCは、理想的なデータで行われがちです。本番で実際に来る入力（言い回しの揺れ、例外、古い資料）を評価データに入れて測ったかを確認します。「なんとなく良さそう」を、数字に変える方法は生成AIの評価（Evals）はどうやる？にまとめています。
3. 運用：誰が回し、誰が直せるか
AIは作って終わりではありません。間違えたときに誰が気づき、誰が直し、どこから人に引き継ぐのかが決まっていなければ、本番では回りません。引き継ぎの設計はAIエージェントから人へどう引き継ぐ？、本番運用のループは生成AI・AIエージェントの本番運用で扱っています。
4. リスク：情報の扱い・権限・誤りの影響
扱うデータの機密度、AIに持たせる権限、間違えたときの影響の大きさを確認します。PoCでは疑似データで動かしていたものが、本番では実データに触れます。判断の観点は企業の生成AI活用、セキュリティはどう担保する？を参照してください。
5. 採算：効果額に対して、本番の費用が見合うか
PoCの費用と、本番の費用は別物です。本番では、運用の人件費、利用料、保守、改善の費用が継続的にかかります。費用の見方は生成AI導入の費用はどう考える？で整理しています。
結論は「Go／止める」の二択ではない——4つの形
判定の結論は、Go・条件付きGo・見直し・止める、の4つで考えると、先送りを防げます。
| 結論 | 意味 | 次の一手 |
|---|---|---|
| Go | 5観点すべてが最低ラインを満たした | 本番の計画と体制へ進む |
| 条件付きGo | 一部が未達だが、条件を付ければ進められる | 条件（対象の絞り込み、人の確認を残すなど）を決めて進む |
| 見直し | 設計を変えれば届く見込みがある | 設計を変えて、期間を区切って再検証する |
| 止める | 基準に届く見込みがない | 学びを記録して終了。次のテーマへ |
特に大事なのは、「止める」も成果だという考え方です。見込みのない取り組みを早く止められれば、費用と人の時間を、成果の出るテーマに回せます。止めることを失敗扱いにすると、見込みの薄いPoCが「様子見」のまま続いてしまいます。
判定シートは、どう作る？
判定シートは、PoCの開始前に、5観点それぞれに「測る指標」「最低ライン」「測る人」を書いて、関係者で合意しておきます。
| 観点 | 測る指標（例） | Goの最低ライン（例） | 測る人 |
|---|---|---|---|
| 事業成果 | 対象業務の1件あたりの処理時間 | 現状から一定割合以上の短縮 | 業務の持ち主 |
| 精度 | 評価データでの正答率 | 合意した水準以上 | 技術担当 |
| 運用 | 誤りの発見から修正までの手順 | 担当者と手順が決まっている | 運用担当 |
| リスク | 扱うデータと権限の整理 | 社内ルールに適合 | セキュリティ担当 |
| 採算 | 効果額に対する本番の年間費用 | 合意した費用対効果以上 | 事業責任者 |
「最低ライン」の欄は、自社の業務と、失敗したときの影響の大きさで決まります。一般的な正解の数字は存在しません。大切なのは、結果を見る前に決めて、記録しておくことです。基準を事前に決める進め方は、生成AIの要件定義はどう進める？と、PoCの前の準備であるAI活用アセスメントも参考になります。
具体例：経理の問い合わせ対応AIのPoCを判定する
バックオフィスの経理部門で、社内からの経費精算・請求書の問い合わせにAIが答えるPoCを例にします（数値は説明用の仮の値で、実在の導入結果ではありません）。
PoCの前に決めた判定シート（仮）
- 事業成果：担当者の問い合わせ対応時間を、月80時間から半分以下にする
- 精度：過去の問い合わせから選んだ評価データ100件で、正答率90%以上
- 運用：AIが答えられない質問は、担当者に引き継ぐ手順が整っている
- リスク：個人の給与情報には、AIがアクセスできない
- 採算：削減できる人件費に対して、本番の年間費用が下回る
PoCの結果（仮）
- 事業成果：試験運用で、対応時間が月80時間から約45時間に減った → 達成
- 精度：評価データ100件で正答率は86% → 未達（基準は90%）。誤りの多くは「規程が改定された直後の質問」だった
- 運用：引き継ぎ手順は整っていた → 達成
- リスク：給与情報へのアクセスは遮断済み → 達成
- 採算：試算上は下回る → 達成
判定：条件付きGo
精度だけが未達ですが、誤りの原因が「古い資料が混ざっていること」と分かっています。そこで、次の条件を付けて本番へ進めます。
- 規程の改定時に、AIが参照する資料を更新する担当と手順を決める
- 規程に関わる質問は、当面は担当者の確認を挟む
- 本番開始後の1か月は、評価データを増やして精度を再測定する
もし誤りの原因が「そもそも文書が整理されていない」のように、数週間では解けないものだったなら、判定は見直し（資料整備を先に行ってから再検証）になっていたはずです。精度の改善の考え方はRAGの精度が上がらないのはなぜ？が参考になります。
このように、事前に基準があれば、「86%は足りないのか」という議論が、「何を直せば90%になるのか」という議論に変わります。
Go/No-Goでつまずきやすい点
- 基準を、結果を見てから決める：都合のよい解釈になり、判断がぶれる
- 精度だけで決める：運用・リスク・採算の見落としが、本番で表に出る
- 判断者が曖昧：誰も決めず、「継続検討」のまま止まる
- 止める判断を許さない：見込みの薄い取り組みが、様子見で延命される
- 本番後の評価を決めていない：Go の後に精度が落ちても気づけない
FDEは、Go/No-Goにどう関わるか
PoCの判断が難しい根本の理由は、作る人と、業務を担う人が離れていて、基準を一緒に作れていないことにあります。
弊社（株式会社 DeploAI）の FDE（Forward Deployed Engineer）は、顧客の現場に入り込み、対象業務を理解したうえで、判断基準の設計、評価の実施、本番化に必要な条件の整理までを伴走します。スタンダードプランには、評価のしくみ（evals）の構築が含まれており、PoC後も、本番の精度を測り続けられる状態を目指します。FDEの役割そのものはFDE（Forward Deployed Engineer）とはをご覧ください。
まとめ
- PoCから本番へ進めてよいかは、結果を見る前に決めた最低ラインで判断する
- 観点は 事業成果・精度・運用・リスク・採算 の5つ。精度だけで決めない
- 結論は Go／条件付きGo／見直し／止める の4つ。止めることも成果
- 判定シートに、観点ごとの指標・最低ライン・測る人を書き、開始前に合意する
- 基準があれば、議論は「足りるか」から「何を直せば届くか」に変わる
DeploAI の FDE の進め方はサービス内容を、費用の考え方は料金をご覧ください。「PoCの結果をどう判断すればよいか」という段階のご相談も歓迎です。お気軽にお問い合わせください。
