AI PoC終了基準｜本番移行・検収・運用引継ぎの設計

AI PoCは、動くデモを作った時点では終わりません。終了時に必要なのは「精度が高そう」という感想ではなく、継続・中止・本番移行のどれを選ぶかを、同じ証拠から関係者が判断できる状態です。本稿では、タイ・ASEANでAI導入を進める製造業を想定し、AI PoCの終了基準、検収条件、成果物、本番移行、運用引継ぎを一つの意思決定パッケージとして設計します。個別製品のデモ評価ではなく、PoC疲れを防ぎ、投資判断を閉じるための実務ガイドです。

AI PoCの終了基準は「Go・条件付きGo・Hold・Stop」を決めるゲート

結論から言えば、AI PoCの終了基準は単一の精度目標ではありません。業務価値、品質、重大リスク、セキュリティ・プライバシー、運用可能性、経済性の六つを別々に評価し、決裁者が次の四つから一つを選べる状態にすることです。

重要なのは、重大な安全事故、個人データ漏えい、禁止操作といった失敗を、平均精度や便益の高さで相殺しないことです。総合点が80点でも重大リスクゲートが不合格ならGoにはしません。逆に、全項目を100点にするまでPoCを延長する必要もありません。本番で管理できる残余リスクと、移行後に改善する項目を分ければ、止めるべきものを止め、進めるべきものを進められます。

NISTのAI Risk Management Frameworkは任意利用の枠組みで、AIリスクをGovern、Map、Measure、Manageの機能で扱います。生成AI向けのNIST AI 600-1も、組織の目的・リスク許容度・資源に合わせてリスク管理を具体化する考え方です。したがって、本稿の数値はNISTやISOの必須値ではありません。自社の用途と影響度に合わせて合意するためのTOMAS TECH推奨例です。

PoC疲れは「技術が未完成」より「終了条件がない」ことで起きる

PoC疲れとは、試作を何度も続けても本番移行も中止も決められず、現場が同じ説明・データ準備・レビューを繰り返す状態です。典型的には次の順序で発生します。

1. 「AIで何か効率化したい」という広い目的で開始する。
2. ベンダーが見栄えのよいデモを作り、関係者の期待が上がる。
3. 成功指標、対象外、テストデータ、重大失敗が未定義のまま評価へ入る。
4. 部門ごとに「精度」「便利さ」「安全性」の意味が異なり、判定が割れる。
5. 不足を埋めるため小さな追加開発を続けるが、決裁資料と運用責任はできない。
6. 予算年度や担当者が変わり、別名のPoCが再開する。

この問題はモデルを高性能化するだけでは解消しません。PoC開始前に「何が分かれば意思決定できるか」を定義し、終了時に提出する証拠を契約・計画・会議体へ組み込む必要があります。発注先そのものの比較が必要ならAI開発会社の選び方を先に整理し、本稿では選定後の出口設計に集中してください。

PoCは小さな本番ではなく、仮説を買う期間

PoCの目的は、安価に完成品を入手することではありません。「この業務課題にAIが寄与する」「必要なデータが取得できる」「許容可能なリスクで運用できる」「本番化の便益が総費用を上回る」という不確実な仮説を、意思決定に足る証拠へ変えることです。

そのため、PoCコードがそのまま本番コードにならないこと自体は失敗ではありません。一方、評価データ、構成、制約、未解決事項、移行見積りが残らなければ、たとえデモが成功しても組織には再利用可能な資産が残りません。「作ったもの」ではなく「不確実性をどれだけ減らしたか」を検収する視点が必要です。

AI PoC開始前に固定する5つの境界

終了基準は最終週に作るものではありません。キックオフ前に、最低でも次の五つを合意します。

1. 意思決定文

一文で「PoC終了時に誰が何を決めるか」を書きます。例えば「品質保証部長、工場IT責任者、事業責任者は、2026年11月30日までに、保全報告書作成支援を一工場で本番化するか判断する」です。「AIの可能性を確認する」では決定になりません。

2. 対象業務と対象外

利用者、拠点、言語、入力データ、出力、連携先、判断権限を明示します。「保全報告書の下書き作成」は対象でも、「設備を自動停止する」「人事評価に使う」「承認なく外部送信する」は対象外、というように書きます。対象外は機能不足ではなく、リスク境界です。

3. 基準線

現状の所要時間、件数、エラー、再作業、待ち時間、損失を測ります。AI導入後だけを測ると、改善率を計算できません。平均だけでなく中央値、90パーセンタイル、部門・言語・製品群などのセグメントも残します。繁忙期と閑散期が違うなら測定期間も記録します。

4. テストデータと禁止データ

正常例、難例、欠損、長文、多言語、古い様式、悪意ある入力を含め、どの母集団を代表するかを書きます。個人データ、機密図面、顧客秘密を使う場合は、利用目的、アクセス、保存、削除、越境処理を確認します。技術評価が通っても法務・契約上の適法性を自動的に証明するわけではありません。

5. 変更凍結点

モデル、プロンプト、検索索引、コード、API、データ版、パラメータを評価前に固定し、識別子を付けます。テスト中に設定を変えたなら、影響範囲を再試験します。「最後に少し直した」状態で旧スコアを流用すると、検収対象と証拠が一致しません。

AI PoC終了基準を六つのゲートで設計する

Gate 1　業務価値

業務価値ゲートでは、機能が動くかではなく、利用者の仕事が改善するかを見ます。推奨する指標は、処理時間、処理能力、一次完了率、再作業率、待ち時間、回避損失、利用率のうち二〜四つです。指標ごとに現状値、目標値、測定方法、対象期間、データ所有者を決めます。

例えば「報告書作成時間を削減」だけでは不十分です。「承認済みの保全報告書400件について、情報収集開始からレビュー提出までの中央値を30分から18分以下へ下げ、再作業率を10%以下に保つ」と書けば、再計算できます。短縮した時間が別の確認作業へ移っただけなら、工程全体で測定します。

Gate 2　品質と有効性

品質は用途ごとに定義します。分類ならprecision、recall、F1、誤検知・見逃しのコストを区別します。文章生成なら、事実整合、出典一致、必須項目充足、禁止表現、読みやすさを別々に採点します。検索拡張なら検索結果の適合性と最終回答の正しさを分けます。

単一の「正答率95%」では、何を正答としたか分かりません。評価手順書には、採点ルーブリック、正解データの作成者、評価者間の不一致処理、再試験条件を含めます。OpenAIのEvalsのような評価基盤は基準・データ・graderを構造化できますが、ツールを使うだけで業務上正しい基準になるわけではありません。業務責任者が失敗の意味を定義する必要があります。

Gate 3　重大リスクと安全性

重大リスクゲートは平均点とは別のpass/failです。例として、設備操作、危険手順、法令判断、価格承認、個人データ、機密情報に関する禁止動作を列挙します。各シナリオについて、期待される拒否、エスカレーション、確認、ログ記録を検証します。

「重大事故が一度も起きなかった」だけでは、母数が少なければ保証にはなりません。対象シナリオをリスク分析から作り、故意に境界を試すnegative testを含めます。AIエージェントの具体的な試験ケース設計はAIエージェント受入試験で詳しく扱っているため、本稿ではPoC終了判定への組み込み方に限定します。

Gate 4　セキュリティ、プライバシー、法務

確認項目には、ID、最小権限、秘密情報、暗号化、ログ、脆弱性対応、サプライヤー、データ保持、削除、利用規約、知的財産、個人データ、越境処理を含めます。タイのETDAによる生成AIガバナンス指針も、便益・限界・リスク・組織的統制を合わせて考える構成です。

ここでの検収成果物は「PDPA対応済み」という一行ではありません。どのデータを、誰が、何の目的で、どこへ送り、どれだけ保存し、どう削除できるかを示すデータフロー、責任分担、例外一覧です。個別案件の適法性は、契約主体、データ主体、処理場所、業界規制に応じて専門家が確認します。

Gate 5　運用可能性

PoC環境で一度動くことと、担当者が休暇中でも本番を維持できることは別です。監視、アラート、一次対応、エスカレーション、バックアップ、復旧、ロールバック、モデル・プロンプト変更、費用上限、問い合わせ、利用者教育を評価します。

推奨例として、限定本番のサービス目標を可用性99.5%、p95応答8秒以内、重大アラート一次確認15分以内と置くことはできます。ただしこれは一般規格の値ではなく、業務が許容できる停止時間と費用から決める例です。夜間に使わない社内支援と、24時間の生産工程では同じ値にしません。

Gate 6　経済性と拡張性

PoC費用だけでなく、本番移行費、月次運用費、モデル/API費、監視、再評価、データ整備、教育、ライセンス、保守、退出費を含めます。便益も「時間削減×人件費」だけでなく、実際に転用できる時間、回避損失、売上寄与、品質改善を重複なく計算します。

拡張性は、件数を10倍にした負荷だけではありません。拠点、言語、部門、データ区分、利用者権限が増えたときに、品質と統制を維持できるかを確認します。一工場の成功を十工場へ単純乗算せず、ローカル様式、ネットワーク、データ所有者、サポート時間を差分として見積もります。

平均点で重大失敗を隠さないAI PoCスコアカード

実務では「必須ゲート」と「加点項目」を分けます。以下は推奨例であり、各社の必須値ではありません。

加重平均は、重大リスク以外の優先順位付けに使えます。例えば業務価値30、品質25、運用20、経済性15、拡張性10の100点とし、75点以上を候補にしてもよいでしょう。ただし、必須ゲートを一つでも落とした場合は総合点に関係なくGoにしないルールを先に固定します。

AI PoC検収条件を再計算可能にする

分母、期間、セグメントを固定する

「90%成功」は、90/100なのか900/1,000なのかで不確実性が違います。除外したケース、タイムアウト、手動救済を分母から消すとスコアが良く見えます。検収レポートには、総件数、除外件数と理由、成功、部分成功、失敗、未判定を必ず並べます。

また、全体90%でもタイ語の手書き入力だけ60%なら、本番対象によっては不合格です。拠点、言語、文書種、製品、難易度、権限など、業務上重要なセグメントに最低値を置きます。

サンプル数は「十分そう」ではなく式を残す

比率を推定する単純な計画例では、n = z² × p × (1-p) / e²を使えます。95%相当としてz=1.96、想定成功率p=0.90、許容誤差e=0.05なら、n=1.96²×0.9×0.1÷0.05²=138.30なので139件へ切り上げます。さらにセグメント不足や無効データに対して20%を単純加算する管理用バッファなら、139×1.2=166.8で167件です。ただし「20%が無効になっても有効139件を確保する」という意味なら、必要件数は139÷0.8=173.75を切り上げた174件です。両者を混同せず、予備の定義を計画書に明記します。

これは単純無作為抽出を仮定した計画値です。母集団が小さい、クラスが偏る、同一設備から相関したデータが出る、重大事故が極めて稀、複数セグメントの最低値を保証したい場合は別設計が必要です。式、仮定、乱数seed、抽出日、データ版を残し、都合のよい事例だけを選ばないようにします。

LLM評価だけに検収を任せない

モデルによる自動採点は大量の回帰試験に有効ですが、採点モデルにも誤りと変動があります。人手で確認したgold setとの一致、評価者間一致、採点モデルの版、プロンプト、温度、再現条件を残します。高影響の失敗は人が確認し、自動採点の平均だけで承認しません。

変更後のスコア流用を禁止する

モデル、プロンプト、検索データ、ツール、API、ガードレールの変更は、品質とリスクを変えます。変更ごとに影響分析し、最低限の回帰セットを再実行します。本番移行時には「PoCで合格した構成」と「本番へ出す構成」の差分表を作り、未試験差分を明示します。

AI PoCの検収成果物は12点で揃える

検収は報告会ではなく、後から追跡できる成果物の受渡しです。最低限、次の12点を推奨します。

成果物の所有権と編集可能な形式も契約に書きます。PDFだけでは閾値や費用を再計算できません。評価データ、計算表、構成定義、runbookは、機密性を守りつつ顧客が継続利用できる形式で引き渡すようにします。第三者モデルやOSSの権利は、顧客成果物と分けて一覧化します。

契約・RFPに入れるAI PoC検収条項

契約文では「AI精度が高いこと」のような曖昧語を避け、次を明記します。

• 検収対象のバージョン、環境、モデル、データcut-off。
• 顧客とベンダーのデータ準備、正解付与、レビュー責任。
• 指標、閾値、分母、セグメント最低値、重大失敗の定義。
• テストデータの凍結、漏えい防止、再利用条件。
• 不合格時の是正回数、再試験範囲、追加費用、最終期限。
• 条件付き検収の条件、責任者、期限、未達時の扱い。
• 成果物、ソース、設定、ログ、文書、知的財産の引渡し範囲。
• Stop時のデータ返却・削除、アクセス撤去、費用精算。
• 本番移行が別契約の場合の見積り前提と有効期限。

特に「顧客都合でデータが遅れた」「モデル提供者が版を変更した」「外部API仕様が変わった」場合の扱いを決めます。責任の押し付けではなく、再計画・影響評価・変更承認の手順を先に作るためです。契約前の要件整理に外部支援が必要な場合は生成AIコンサルティングの選び方も参照できますが、PoC契約の検収責任は最終的に自社側にも残ります。

AI PoCから本番移行するときのギャップ分析

PoC環境と本番環境の差を、機能、データ、セキュリティ、可用性、性能、運用、契約、費用の八領域で比較します。典型的な差分は次の通りです。

差分ごとに「本番前に閉じる」「限定本番中に閉じる」「リスク受容する」を選びます。すべてを本番前に完成させると移行が遅れ、何も閉じずに出すと障害が現場へ移ります。影響度と可逆性で順番を付けます。

一斉展開ではなく段階的な昇格にする

推奨は、shadow、internal pilot、limited production、expanded productionの段階です。shadowでは出力を業務へ反映せず比較し、internal pilotでは訓練済み利用者が確認し、limited productionでは対象拠点・件数・権限を制限します。各段階に昇格条件とrollback条件を持たせます。

例えば「重大失敗1件」「週次コストが上限の120%」「重要セグメント品質が二週連続で下限未満」のいずれかで拡張停止、といったトリガーを置きます。数値は業務別に決めますが、問題が起きた後に停止条件を議論しないことが重要です。

運用引継ぎは本番移行の受入試験

引継ぎ完了は、文書を共有フォルダに置くことではありません。運用担当がベンダーや開発者の口頭支援なしで、監視確認、一次切り分け、停止、rollback、復旧、エスカレーションを実演できることです。

RACIを運用イベント単位で決める

「IT部が担当」では粗すぎます。モデル品質低下、誤回答、個人データ疑い、API障害、費用急増、権限変更、モデル更新、利用者苦情、重大インシデントごとに、Responsible、Accountable、Consulted、Informedを置きます。タイ拠点と日本本社、現地ベンダー、クラウド事業者の営業時間と連絡言語も記載します。

runbookは正常系より異常系を重視する

runbookには、アラートの意味、確認画面、ログ取得、暫定回避、停止手順、復旧条件、証拠保全、連絡先を含めます。スクリーンショットだけでなく、環境名、権限、コマンド、期待結果、失敗時の次手を版管理します。秘密情報そのものは書かず、vault参照と取得権限を記載します。

rollbackを実演する

以前のモデル・プロンプト・索引・アプリへ戻す手順を実際に試します。戻せない外部モデル更新があるなら、モデル固定、代替モデル、機能停止、手動業務への切替を設計します。rollback後にデータ不整合が残るか、処理途中のキューが再実行されるかも確認します。

継続評価を運用へ移す

Google Cloudの生成AI運用ガイダンスは、本番出力を取得し、継続評価で性能を追う考え方を示しています。PoC評価セットを捨てず、代表ケース、重大リスク、回帰ケースを定期実行します。実利用から新しい失敗を収集する際は、個人データや機密を評価基盤へ再投入してよいか確認します。

30・60・90日でAI PoCを閉じる実行計画

期間は案件に合わせて変えますが、意思決定の流れは固定できます。

0〜30日　仮説と証拠の設計

• 意思決定者、業務所有者、データ所有者、運用責任者を任命する。
• 現状基準線、対象外、重大失敗、経済性の式を合意する。
• テストデータ、権利、個人データ、セキュリティ境界を確認する。
• 検収成果物、変更管理、Stop時の削除まで契約へ入れる。

31〜60日　構築と中間ゲート

• 凍結可能な版で最小構成を作る。
• 正常、難例、negative、セグメント別の試験を実行する。
• 中間時点で「改善可能な不足」と「前提を壊す不足」を分ける。
• 本番ギャップ、月次費用、運用人員を早期に見積もる。

61〜90日　独立再試験と引継ぎ

• 開発に使っていないholdoutで再試験する。
• 重大リスク、セキュリティ、rollback、障害訓練を実施する。
• 経済性を保守・標準・楽観の三シナリオで再計算する。
• 運用担当がrunbookを実演し、決裁会議で一つの判定を記録する。

期間延長は「もう少し良くなりそう」では承認しません。何の不確実性を、どの追加証拠で、いつまでに減らすかを書きます。同じ評価を繰り返すだけの延長ならStopか再設計を選びます。

製造業のAI PoCを数値で判定する例

以下は事実値ではなく、再計算方法を示す仮定例です。タイ工場で保全報告書の下書きをAIが支援するとします。月4,000件、1件12分短縮、利用率70%、対象業務の人件費600バーツ/時、品質調整係数0.85と仮定します。

時間便益 = (12分 ÷ 60) × 4,000件 × 0.70 × 600バーツ × 0.85 = 285,600バーツ/月

さらに、記載漏れによる再作業・停止の回避期待額を90,000バーツ/月、本番運用費を150,000バーツ/月と仮定すると、

月次純便益 = 285,600 + 90,000 - 150,000 = 225,600バーツ/月

本番移行の一時投資を1,800,000バーツとすれば、単純回収期間は、

1,800,000 ÷ 225,600 = 7.98か月 ≒ 8.0か月

ここで利用率が50%、品質係数が0.70なら時間便益は(12/60)×4,000×0.50×600×0.70=168,000バーツ/月に下がります。同じ90,000バーツの回避額と150,000バーツの運用費なら純便益は108,000バーツ、回収は約16.7か月です。Go/Stopは、楽観値ではなく経営が承認した保守シナリオと回収上限で判断します。

また、12分短縮が本当に人員余力や処理能力へ転換されるかを確認します。短縮時間が細切れで他業務へ使えない、利用者が出力確認に追加時間を使う、繁忙期しか価値が出ない場合、品質係数や実現率を下げます。式を共有すれば、財務、現場、ベンダーが異なる前提を議論できます。

終了判定会議で残す一枚

決裁者向けには、詳細報告書とは別に一枚のdecision recordを作ります。

会議では新しい指標を持ち込まず、事前合意した基準と証拠で判断します。条件付きGoの条件が曖昧なら実質的にHoldです。「運用しながら考える」は、所有者・期限・停止条件がある場合だけ条件付きGoと呼べます。

AI PoCでよくある失敗と修正方法

デモの満足度を検収にする

役員デモが成功しても、代表データ、例外、負荷、権限、運用は証明されません。デモは理解促進、検収は再現可能な証拠、と役割を分けます。

精度の平均だけで決める

重大な見逃しや少数言語の失敗が平均に埋もれます。重大リスクをpass/failにし、重要セグメントへ最低値を置きます。

PoC予算と本番総費用を混同する

無償枠、手作業、開発者常駐で安く見えます。本番の従量費、監視、教育、再評価、サポート、退出を加えます。

条件付きGoが永久に残る

条件の責任者、期限、証拠、未達時の扱いがありません。チケット化し、次回判定日と自動エスカレーションを設定します。

Stopを失敗として隠す

前提が成立しないと早期に分かったStopは、将来の損失を回避した成果です。評価データ、非成立理由、再開条件、削除証明を残します。

引継ぎを公開後へ先送りする

開発者しか止められないシステムが本番になります。運用実演をGoの必須条件に置きます。

AI PoC終了基準に関するFAQ

AI PoCの終了基準はいつ決めますか？

原則として発注・キックオフ前です。少なくとも意思決定文、対象外、指標、重大失敗、テストデータ、成果物を合意します。途中で新事実が出た場合は変更記録を残し、評価に使う前に承認します。

AI PoCの成功率は何%なら本番移行できますか？

万能な割合はありません。用途、失敗コスト、人の確認、セグメントで変わります。90%という平均より、重大失敗0、重要セグメント最低85%、人手確認後の残余リスクなど、業務に対応した複数条件で判断します。数値例は推奨値であり標準要件ではありません。

AI PoCの検収条件に費用対効果を含めるべきですか？

含めるべきです。ただしPoC開発費だけでなく、本番移行、一時・月次運用、監視、再評価、教育、退出を含めます。便益側も実現率と品質調整を入れ、保守・標準・楽観の感度を示します。

PoCが不合格でも追加開発を続けるべきですか？

不足が修正可能で、追加検証により特定の不確実性が減る場合だけです。追加範囲、費用、期限、再判定基準を固定します。前提データが存在しない、重大リスクを制御できない、保守ケースで経済性がない場合はStopを選びます。

条件付きGoとHoldの違いは何ですか？

条件付きGoは、限定本番を安全に始められ、残課題の所有者・期限・停止条件が明確な状態です。Holdは、本番判断に必要な証拠や前提が欠け、まだ利用を開始できない状態です。

AI PoCから本番移行する際に最も抜けやすいものは何ですか？

運用所有者、監視、rollback、費用上限、モデル変更時の再評価、データ削除です。PoC担当者の暗黙知をrunbookと演習へ移さなければ、本番化後に属人化します。

AI PoCの成果物は誰のものですか？

契約によります。顧客固有の評価データ、設定、コード、計算表、文書と、ベンダー既存資産、第三者モデル、OSSを分け、利用・修正・再委託・終了後保持の権利を明記してください。

StopしたPoCのデータはどう処理しますか？

保存義務がある証拠と削除すべき業務データを分けます。環境、バックアップ、ログ、ベンダー保管、評価サービスを対象に、アクセス撤去、返却、削除、削除確認、契約終了を記録します。

まとめ　AI PoCの出口は「精度」ではなく意思決定と引継ぎ

AI PoCを終えるとは、デモを完成させることではありません。業務価値、品質、重大リスク、セキュリティ・プライバシー、運用、経済性の六ゲートを、再計算可能な証拠で閉じることです。Goなら段階的な本番移行と運用引継ぎへ進み、Holdなら不足証拠を限定し、Stopならアクセス・データ・契約まで安全に閉じます。

PoC疲れを防ぐ最も効果的な方法は、開始時に出口を契約することです。意思決定者、対象外、重大失敗、テスト母集団、検収成果物、変更凍結、条件付きGo、Stop時の削除を先に決めます。そして運用担当が停止・復旧・rollbackを実演して初めて、本番移行の準備ができたと判断します。

TOMAS TECHでは、タイ・ASEAN拠点のAI PoCについて、終了基準、検収成果物、経済性モデル、本番ギャップ、運用引継ぎをRFP段階から整理できます。製品や委託先が未決定でも、「続ける・止める・本番へ進む」を同じ証拠で判断できる形にしたい段階からお問い合わせいただけます。

参照した一次・公式情報

• NIST AI Risk Management Framework
• NIST AI 600-1 Generative Artificial Intelligence Profile
• ISO AI management systems overview
• ETDA Generative AI Governance Guideline for Organizations
• ETDA guideline PDF
• Google Cloud: Deploy and operate generative AI applications
• OpenAI Evals guide
• Thailand National AI Strategy and Action Plan 2022–2027