意思決定ガイド

AIエージェントのPoCをいつ終える?本番移行・中止の判定基準

AIエージェントのPoCを続けるか、本番へ移すか、中止するか。業務価値、安全、運用負担、データ、連携、費用の合格線と、終了時に残す証拠を整理します。

AIエージェントのPoCは、「もう少しデータを増やせば」と延長し続けるものではありません。開始前に終了日と合格線を置き、業務価値、安全、運用負担、データ、連携、費用を同じ表で判定します。結果は本番移行だけでなく、範囲縮小と中止の三つに分けます。

たとえば、問い合わせメールの返信案を作るPoCで、文面は自然でも、担当者が元メール、価格表、顧客台帳を毎回10分かけて確認しているとします。AIの回答だけを採点すれば成功に見えますが、現場の確認待ちは減っていません。本番へ進める前に見るのは、AIが答えたかではなく、人を含む仕事全体が成立したかです。

AIエージェントのPoCは、いつ終えるべきか?

開始前に決めた終了日と評価件数に達した時点で、延長せず三つの出口から必ず選びます。

終了日は、対象業務の一巡に合わせます。日次業務なら通常日と繁忙日、月次業務なら少なくとも締め処理、季節要因が強い業務なら代表的な例外を含めます。ただし、全部の例外が出るまで待つのではなく、過去データで補います。

PoC終了時の出口は次の三つです。

表は横にスクロールできます →
出口選ぶ条件次に行うこと
本番移行合格線を満たし、監視・停止・復旧を運用できる権限を限定して段階導入
範囲縮小・再検証原因が特定でき、範囲を変えれば検証する価値がある対象、権限、データを変えて期限付き再試験
中止業務価値がない、安全に止められない、費用が見合わない接続とデータを閉じ、結果を記録

デジタル庁の生成AI調達・利活用ガイドラインは、PoC段階か本番開発段階かというフェーズに応じ、対策が不足にも過剰にもならないようリスクとのバランスを取る考え方を示しています。PoCの安全策を、そのまま本番の十分条件にはしません。

本番移行の判定は、どの軸で行うのか?

業務価値、安全、運用、データ、連携、費用の六軸すべてに合格線と証拠を用意します。

精度は六軸の一部です。AIが候補を正しく出しても、人が毎回ゼロから調べ直す、連携失敗時に二重登録する、監視担当がいないなら、本番には移せません。

表は横にスクロールできます →
判定軸PoCで確かめること本番へ進めない条件
業務価値処理時間、待ち時間、未処理、手戻り人を含む全体で改善がない
安全禁止操作、誤送信、権限外参照、停止重大な誤りを実行前に止められない
運用確認、修正、問合せ、監視、引継ぎ特定の担当者しか例外を処理できない
データ必須項目、更新頻度、欠損、利用権限本番データで根拠を特定できない
連携API、タイムアウト、再送、読戻し二重処理と結果不明を解消できない
費用AI利用料、連携、監視、人の確認継続費を含めると採算が合わない

NISTのAI RMF Coreは、本番に近い条件で性能や保証基準を測ること、稼働後の監視、異議申立てや上書き、廃止、事故対応、復旧、変更管理を計画することを示しています。PoCの成功は、監視なしで放してよいという意味ではありません。

合格線は、どのように数値へ落とすのか?

現在値、目標、重大な失敗の上限、測定方法、判定者を業務ごとに一行で明確に決めます。

共通の「正解率90%」は置けません。同じ誤りでも、社内文書の分類と、顧客へ送る見積金額では影響が違います。平均値だけでなく、起こしてはいけない失敗を別に数えます。

問い合わせ仕分けなら、次のような評価表を自社用に作ります。数値は例であり、公的基準ではありません。

表は横にスクロールできます →
指標現在値PoCの合格線重大な失敗証拠
担当部署の候補一致過去データで測る自社で設定緊急連絡を通常扱い判定一覧
人の確認時間現状を計測自社で設定根拠確認ができない作業ログ
未処理の滞留現状を計測自社で設定期限超過を通知しないキュー履歴
外部送信なし承認後のみ未承認で送信送信・承認ログ
復旧手順を作る自社で設定二重送信、元に戻せない障害試験結果

測定対象を成功例だけにしません。短いメール、添付だけのメール、複数部署にまたがる相談、怒りを含む文面、担当者不在を混ぜます。件数は、各種類の傾向が見えるよう業務責任者と決めます。

精度が目標に届かないときは、何を見直すのか?

モデル変更の前に、業務範囲、入力、正解定義、参照データ、人へ戻す境界を順に一つずつ見直します。

「AIが間違えた」でまとめず、原因を分けます。

  • 入力メールに判断材料がない
  • 社内でも担当部署の正解が人によって違う
  • 古いFAQや価格表を参照している
  • 得意先や商品マスタに重複がある
  • 一つのPoCに分類、返信、送信、台帳更新を詰め込んでいる
  • 人へ戻す条件がなく、曖昧な案件も必ず答えさせている

入力に情報がなければ、モデルを替えても確実にはなりません。まず「判断材料不足」として人へ返す選択肢を作ります。正解が社内で割れるなら、AI評価より前に業務ルールを決めます。

AISIのAIセーフティに関する評価観点ガイド第1.20版は、AIエージェントの自律的な挙動、外部環境との相互作用、観測と制御を評価観点に加えています。文章の正しさだけでなく、外部システムへ何をしようとしたか、途中で止められるかを試します。

PoCから本番へ移すとき、何が新しく必要になるのか?

権限分離、監視、障害対応、ログ保存、変更管理、教育、問合せ窓口を本番運用として追加します。

PoCでは、担当者が横で画面を見続け、少量のデータを手で直せます。本番では夜間や繁忙時も動き、モデル、プロンプト、API、マスタが変わります。見守っていた人の作業を、運用として名前と時間へ置き換えます。

AIエージェントへ渡す権限の決め方で整理した閲覧、下書き、承認後実行、自動実行の段階を使い、本番開始時はPoCより権限を広げません。まず下書きまたは承認後実行で稼働し、監視結果を見て広げます。

経済産業省のAI事業者ガイドライン第1.2版は、経営層が方針を定め、運用状況をモニタリングし、環境やリスクの変化に応じて見直すAIガバナンスを示しています。本番移行の承認は現場担当者だけに背負わせません。

どんな条件なら、PoCを中止するべきか?

価値が確認できず、重大リスクを止められず、必要データや運用責任者を確保できないなら中止します。

次の状態なら、一度閉じます。

  • 対象業務の目的を数値または観察で説明できない
  • 人の確認を含めると現行より仕事が増える
  • 社外送信や基幹更新の重大な誤りを止められない
  • 利用できるデータが不足し、追加取得の根拠も権限もない
  • 例外対応が一人へ集中し、引継ぎできない
  • 本番の継続費と監視費を負担できない
  • 同じ条件の延長で、新しく確かめる仮説がない

中止は失敗を隠すことではありません。AIを外し、入力フォームを整える、FAQを更新する、承認経路を短くするだけで目的に届くなら、作らない判断のほうが早いことがあります。

範囲を縮めて再検証してよいのは、どんな場合か?

原因を特定でき、対象、権限、データのどれを変えるかと新しい終了日を説明できる場合です。

返信送信まで任せたPoCが不安定なら、問い合わせ分類と返信下書きへ戻します。全商品を対象にしてマスタ不整合が多いなら、コードが整っている商品群だけに絞ります。

延長理由は「もう少し試したい」ではなく、「旧品番が原因だったため現行商品だけで再評価する」のように書きます。評価表、対象データ、担当者、終了日を更新し、前回と同じ判定を繰り返さないようにします。

終了時には、どんな証拠を残せばよいか?

対象、評価データ、結果、失敗例、費用、判断、残課題、接続停止を一つの終了記録へ残します。

最低限、次を保存します。

  1. PoCの目的と対象業務
  2. 使用したデータの期間、種類、除外
  3. モデル、プロンプト、連携、マスタの版
  4. 六つの判定軸と測定結果
  5. 重大な失敗と人が修正した例
  6. PoC中にかかった利用料と社内作業
  7. 本番、縮小、中止を決めた人と理由
  8. アカウント、APIキー、テストデータを閉じた記録

中止時も接続を残しません。テスト用アカウント、外部サービス連携、共有したデータ、ログの保管期限を確認し、不要な権限を削除します。

社内では、PoC開始前に何を決めておくべきか?

業務責任者、終了日、合格線、禁止操作、評価データ、費用上限、三つの出口を先に決めます。

現場担当者、業務責任者、情報管理の担当、費用を承認する人を決めます。一人が兼ねても、誰の立場で何を判断するかを書き分けます。

PoCの発注書や計画書には、「本番開発は別判断」と明記します。PoCを契約したことが、そのまま本番開発の承認にならないようにします。

開発会社へは、どの情報と成果物を求めるのか?

現行業務、失敗例、禁止操作、合格線を渡し、評価結果、ログ、費用試算、終了手順を求めます。

普段うまく処理できる例だけでなく、確認待ちのメール、担当者不在、マスタ欠落、連携先停止を渡します。機密情報を使う場合は、利用目的、保存、学習利用、削除、再委託の条件を先に確認します。

成果物にはデモ画面だけでなく、評価データ一覧、失敗分類、修正履歴、監視と停止の試験結果、本番の運用体制と費用、中止時の削除記録を含めます。

一次情報は、どの資料を確認したか?

AIエージェント評価、ガバナンス、PoCと本番の区別、継続監視を扱う四つの一次資料を確認しました。

関連記事と相談先は、どこから確認できるか?

権限設計、要件整理、受入テストを往復し、PoC計画または終了判定の資料を持って相談できます。

Heygoodは、PoCを本番開発の前売りにしません。現行業務と失敗時の影響を見て、六つの合格線を一緒に置きます。本番へ進む理由が足りなければ、範囲を縮めるか、PoCを閉じる判断まで含めて相談できます。

この記事の情報源

2026年7月29日時点で、AISI第1.20版、AI事業者ガイドライン第1.2版、デジタル庁の生成AI調達・利活用ガイドライン、NIST AI RMFを確認

  1. AISI「AIセーフティに関する評価観点ガイド(第1.20版)」
  2. 経済産業省「AI事業者ガイドライン(第1.2版)」
  3. デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」
  4. NIST「AI Risk Management Framework Core」

よくある質問

PoCの精度が高ければ、本番へ移してよいですか。

精度だけでは決めません。誤りの影響、確認時間、停止と復旧、データと権限、監視費用まで本番条件で確かめます。

PoCは何か月行えば十分ですか。

一律の月数はありません。対象業務の繁忙期や例外を含む期間を決め、開始前に終了日と合否を置きます。延長には新しい検証目的が必要です。

目標に届かなければ、必ず中止ですか。

原因が範囲の広さやデータ不足なら、権限を下書きまでに戻し、対象を絞って再検証できます。根拠なく同じ条件で延長はしません。

中止したPoCの成果は残りますか。

残ります。使えない条件、必要データ、例外、評価結果、費用を記録すれば、同じ検証の繰り返しを防ぎ、別の改善案に使えます。

Next reading

すべての記事を見る →
意思決定ガイドAIエージェントにどこまで権限を渡してよいか?承認・停止・監査ログの決め方記事を読む意思決定ガイド問い合わせメールの仕分けと返信下書きはどこまで自動化できるか?記事を読む意思決定ガイドFAX受注はAI-OCRだけで自動化できるか?マスタ照合・例外・基幹連携まで記事を読む