AI PoC Guide
4フェーズ・3ゲートと移行条件の設計
AI PoCの進め方は、一般に「目的を決める→検証する→評価する」という流れで説明されます。この流れ自体に誤りはありません。ただし、実際のPoCで判断が止まるのは流れの途中ではなく、段階と段階の境目です。
本記事では、AI導入を4つのフェーズに分け、その境目に3つの判断ポイント(ゲート)を置く進め方を解説します。中心となる原則は一つで、次に進む条件をPoC開始前に確定しておくことです。
最終更新:2026年9月21日
01
Overview
フェーズ
目的
主な成果物
次の判断(ゲート)
0 構想
目的
価値と判断方法を設計する
主な成果物
構想書、3つのKPI、現在値の測定計画、リスク区分
次の判断(ゲート)
開始ゲート:PoCを始めるか
1 PoC
目的
技術とデータの主な不確かさを減らす
主な成果物
評価結果、総費用の前提、未検証の事項、限定実運用の仮説
次の判断(ゲート)
PoC結果ゲート:限定実運用へ進むか
2 限定実運用
目的
実際の業務の一部で、効果と運用を確かめる
主な成果物
3つのKPIの実測、運用評価、統制のテスト
次の判断(ゲート)
本番ゲート:本番化するか
3 本番・拡大
目的
効果を保ちながら対象を広げる
主な成果物
監視、変更管理、総費用の実績、再評価
次の判断(ゲート)
定期的な再評価
各ゲートで問われるのは「良い結果が出たか」ではなく、「次の追加投資を判断できる材料がそろったか」です。
本記事では平易さを優先し、「開始ゲート」「PoC結果ゲート」「本番ゲート」と表記します。AnchorXの標準体系では、それぞれG1(企画)・G3(PoC結果)・G5(本番判定)にあたります。配布資料との対応関係はこのとおりです。
「限定実運用」は、PoCと本番の間に置く段階です。PoCで技術的な実現性を確かめた後、一部の業務・一部の利用者で実際に使用し、効果が出るか、現場で運用が回るかを確認します。PoCの段階では、業務への効果は「使ってみて良さそうだった」という手応えにとどまることがほとんどです。その手応えを数値で確かめることが、限定実運用の役割です。
02
Phase 0
PoCの進め方で最も差がつくのは、PoCを始める前の段階です。
活動
成果物
目的、目指す業務の姿、AIを使わない選択肢を整理する
構想書(1〜2枚)
サービスの受け手を特定し、3つのKPI(事業・サービス・経営)を決める
価値の整理、KPI定義書
主観的な指標を含め、現在値の測定を始める
測定計画、開始記録
リスク区分と、最低限の禁止事項・許容条件を決める
初期のリスク評価
判定する人・判定日・判定4区分それぞれの条件を決める
意思決定計画
PoCのゴールを「AIの精度を検証する」と設定すると、PoCが終わった時点で次の行動が決まりません。ゴールはPoC終了時に下す判断の形で記述します。
×
「問い合わせ対応AIの回答精度を検証する」
○
「問い合わせ対応AIを、一部のチャネルで限定実運用に進めるかを判断する」
後者の形であれば、判断に必要な材料(精度、重大な誤りの頻度、費用の見込み、運用の体制)が自然に洗い出されます。
顧客満足度や利用者アンケートのような指標は、導入後に「導入前の値」を取り直すことができません。比較に使う指標は、構想の段階で測定を開始します。 この時期を逃すと、限定実運用で効果を確かめる手段が失われます。
測定項目の一覧と、KPIを3つの層で置く考え方はPoCの評価項目をどう決めるかにまとめています。
03
Gate 1
構想が終わった時点で、次の6項目を確認してPoCを開始するかを判断します。
通過条件
満たしていない場合
目的と、目指す業務の姿が文書になっている
構想をやり直す
サービスの受け手(利用者・お客様、社内業務なら次の工程)が特定されている
効果が生まれる道筋を整理する
3つのKPI、現在値、測り方が決まっている
測定の設計を終える
リスク区分と、最低限の禁止・許容条件が決まっている
リスクを確認する
判定する人、判定日、判定4区分それぞれの条件が決まっている
開始前に決める
PoCをやる必要性と、PoCで減らす不確かさが明確である
PoCを省くことも含めて再検討する
最後の項目は見落とされやすい項目です。PoCは実施すること自体が目的ではなく、不確かさを減らすための手段であるため、減らしたい不確かさが存在しない案件にPoCは不要です。
04
Phase 1
活動
成果物
最も重要な技術とデータの仮説に絞って検証する
技術検証の結果、制約の一覧
評価データと評価方法を設計し、業務部門の確認を取る
評価データ、評価の仕様、確認記録
重大度別の誤り、代表的なケースと例外、費用・速度を評価する
評価レポート
本番や改善まで含めた総費用の幅と前提を整理する
総費用の試算、前提の一覧
手応えを、限定実運用で確かめる仮説に変える
限定実運用の検証仮説書
確かめきれなかったことを整理する
未検証の事項リスト
PoCで頻繁に生じるのは、検証範囲の拡大です。多数の項目を同時に確かめようとすると期間が延び、結果の解釈も難しくなります。PoCで確かめる対象は、次の判断に最も影響する仮説に限定します。
また、総費用は単一の金額ではなく、「基本・上振れ・下振れ」の幅と、それぞれが成り立つ前提で示します。総費用に含める範囲は、初期開発のほか、データ整備、外部との連携、権限・セキュリティ、利用料、監視、人による確認、教育、精度の改善、モデルの変更、将来の移行・廃止までです。
05
Gate 3
PoCが終わった時点で、5つの観点で判断材料がそろったかを確認します。
観点
通過条件
業務効果
限定実運用で確かめる3つのKPI、現在値、判定の基準値、測る期間・対象が決まっている
品質・精度
評価データの妥当性、重大度別の誤り、代表的なケースと例外、制約が確認されている
経済性
総費用の幅、拡大したときの費用の増え方、見積もりの前提、未確定の項目の期限と担当者が明記されている
リスク
限定実運用に必要な統制、人による確認、データの扱い、停止の条件が設計されている。許容を判断するのが誰かが決まっている
運用可能性
対象業務、人とAIの役割分担、利用者、教育、運用の責任者が決まっている
共通
独立した立場の人が材料を確認し、判定日が守られている
ここで適用する原則は一つです。材料の不足は、Goの理由にはなりません。 「止める理由がないから進める」という判断が続くと、追加投資が既定路線になります。
ただし、材料が不足しているからといって保留にするわけでもありません。行き先は不足の中身によって分かれます。遅れている材料が特定できていて期限を切れるなら条件付きGo、設計そのものを変えないと判断できないなら保留・再設計、何が足りないかを項目名で書けないならNo-Goです。
保留・再設計は例外扱いです。 再判定日と、その日までに揃わなかった場合の既定判定(原則No-Go)まで記録しなければ成立しません。ここを書かずに保留にすると、期限が無期限に更新され、判断までの時間だけが延びます。判定4区分の使い分けと保留・再設計の成立要件はPoCの評価項目をどう決めるかで解説しています。
06
Phase 2
限定実運用では、対象の業務・利用者・期間を絞って実際に使用し、次の項目を確認します。
3つのKPIが、事前に決めた基準値を満たすか
人とAIの役割分担で、業務が実際に回るか
誤りを人が見つけて直せるか、問題が起きたときに停止できるか
利用者が使い続けるか(利用率、AIの出力の採用率、手戻り)
比較の方法も事前に決定します。導入前の値と比べるのか、同じ期間に導入していないグループと比べるのかで、結果の解釈が変わるためです。
07
Gate 5
観点
通過条件
業務効果
3つのKPIが基準値を満たし、改善が生まれた道筋を説明できる
品質・精度
品質・速度・安定性が許容範囲で、重要なケースの不確かさが分かっている
経済性
総費用と効果の見込みが許容範囲で、拡大したときの費用を説明できる
リスク
監視、人による確認、事故対応、緊急停止と再開の手順が機能する
運用可能性
利用者・運用者が実際に使え、責任分担と変更管理が回る
共通
満たさない場合は、事前に決めた条件に従って 条件付きGo/保留・再設計/No-Go のいずれかを選ぶ
08
Phase 3
本番化は終点ではありません。AIは、入力の傾向や業務ルール、モデルそのものが変化することで、稼働後に品質が変わることがあります。本番後も、効果の継続的な測定、モデルやデータの変更管理、評価データの更新、総費用の実績の追跡を続けます。
本番化した後に、利用を部署や全社へ広げ、業務に組み込まれた状態にするまでの進め方は、組織の4フェーズ(導入・活用・浸透・定着)として生成AIの社内浸透・定着ガイドで整理しています。
09
Tailoring
すべての案件で4つのフェーズを踏む必要はありません。案件の性質に応じて調整します。
案件の状態
適した進め方
技術的な不確かさが大きい/独自開発が多い
PoCと限定実運用を分け、PoCでは最重要の仮説に絞る
技術は分かっているが、業務での効果や定着が不確か
短い技術確認の後、限定実運用に重点を置く
市販製品で、リスクが低く小規模
PoCを省き、限定導入と比較測定を行う
判断の影響が大きい、顧客への影響が大きい
構想の段階でリスク区分と許容条件を決め、独立した確認を入れる
10
Why Decide First
ここまで「先に決める」ことを繰り返し述べてきました。理由は判断の構造にあります。
PoCが技術確認だけで終わり、次に進む条件が決まっていない場合、手元に残るのは「技術的に動いた」「担当者の反応が良い」という材料です。この状態では、案件を止めるには説明が求められる一方、続けることは現状維持として扱われます。結果として、追加投資が既定路線になりやすくなります。
すでに費用をかけた案件を止める判断は、誰にとっても難しい判断です。これを担当者の意志の強さに委ねるのではなく、判定日と条件を先に決め、No-Goや再設計を「正常な学びの結果」として扱う仕組みにしておくことが有効です。
ここまでは、複数の案件で共通して観察される事象にもとづく設計上の提言であり、統計的に実証された因果関係ではありません。
note
報告会で判断が出ないまま数か月が経過する構造については、noteの記事で解説しています。
なぜAIのPoCは、成功しても本番に進まないのか
IBM Institute for Business Valueが世界のCEO 2,000人(33カ国・24業種)を対象に行った2025年の調査では、過去数年のAI施策のうち期待したROIを達成したものは25%、全社規模に拡大したものは16%と報告されています。
過去数年のAI施策のうち(IBM Institute for Business Value、2025年)
期待したROIを達成した
25%
全社規模に拡大した
16%
この数字には注意点が2つあります。第一に、AI施策全般を対象とした調査であり、生成AIやPoCに限ったものではありません。第二に、ROIが未達になった原因までは示していません。判断条件を決めていなかったためなのか、技術が届かなかったためなのか、別の理由なのかは、この調査からは判別できません。
したがって、この調査から言えるのは、多くの施策が期待どおりには進んでいないという事実までです。
ただし、その事実を前提に置くのであれば、「どこで、何を基準に止めるか」を事前に設計しておく価値は高くなります。停止すること自体が珍しくないのであれば、停止の仕方を設計しておくほうが合理的です。
出典:IBM Institute for Business Value『2025 CEO Study』(2025年6月26日、n=2,000 CEO)
11
Readiness
目的と、目指す業務の姿が文書になっているか
サービスの受け手が特定されているか
3つのKPI(事業・サービス・経営)と、現在値の測定計画があるか
後から取れない指標の測定を始めたか
リスク区分と、最低限の許容・禁止条件があるか
PoCで減らしたい不確かさが明確か
判定する人、判定日、判定4区分それぞれの条件があるか
これらは、PoCの企画書にそのまま記載する項目でもあります。企画書の構成例はPoC計画書・企画書に何を書くかで紹介しています。
12
Summary
AI導入を構想・PoC・限定実運用・本番の4フェーズに分け、境目に3つのゲート(G1・G3・G5)を置きます
各ゲートで問われるのは「良い結果が出たか」ではなく「次の投資を判断できる材料がそろったか」です
各ゲートは 業務効果/品質・精度/経済性/リスク/運用可能性 の5観点で確認します
PoCのゴールは「検証すること」ではなく「終了時に下す判断」の形で記述します
材料の不足はGoの理由になりません。 ただし行き先は保留とは限りません。遅れなら条件付きGo、設計変更が必要なら保留・再設計、項目名で書けないならNo-Goです
保留・再設計は例外扱いです。 再判定日と、揃わなかった場合の既定判定(原則No-Go)まで書かなければ成立しません
案件の性質によっては、PoCを分ける・短くする・省く判断も合理的です
PoCそのものの基本はAI PoCとは何か、評価の具体的な設計はPoCの評価項目をどう決めるかで解説しています。個別の疑問への短い回答はAI PoCのよくある質問にまとめています。
Download
本記事の元資料です。4フェーズ・3ゲートの判定基準、段階ごとの活動と成果物、進行中の案件にも使える実践チェックリスト、業務類型別のサービスKPI一覧までを収録しています。
資料をダウンロード
Free Consultation
目的・評価項目・判定基準が決めきれていないPoCを、60分の無料相談で整理します。AIセカンドオピニオンのページ(so.anchorx.co.jp)が別タブで開きます。
無料相談のページへ