AIエージェントのPoC｜本番へ渡す5条件

会議のデモでは、AIエージェントがきれいに動いた。

議事録を読み、CRMの更新案を作り、メールの下書きまで返した。ところが、本番移行の確認会では答えに詰まった。同名会社を選んだらどうするのか。CRMの更新だけ成功し、メール作成が失敗したらどこから再開するのか。同じ依頼が二回来たら、二重更新しないのか。

これらは生成AI全般の品質問題ではない。道具を使い、状態を変え、複数段階の仕事を進めるAIエージェント固有の問題である。

AIエージェントのPoCで確かめるべきなのは、最終回答の見栄えだけではない。道具の選択、対象の特定、途中状態、再実行、権限、監査まで含め、繰り返し同じ業務へ投入できるかを見る。

ここでは、PoCを本番へ渡すための5条件を、SIerと発注者が合意できる成果物へ落とす。

AIエージェントのPoCは「動いた」だけでは終われない

通常のチャット機能なら、入力と回答を比べれば評価の入口を作れる。AIエージェントは、その間に検索、抽出、API呼び出し、承認待ち、更新、通知が入る。

最終結果が正しくても、途中で許可されていない顧客情報を読んでいれば合格ではない。逆に、情報不足を検知して人へ戻したなら、処理未完了でも正しい動作である。

エージェント開発ライフサイクルの公式ガイドは、発見、実験、構築、展開、安定運用を別の段階として扱う。実験で得たプロンプトや接続コードを、そのまま本番実装と見なさない設計だ。

PoC開始時には、デモ用シナリオではなく、本番で判断に迷う場面を先に集める。

• 候補が一件に決まらない
• 必須情報が欠けている
• 読み取りは成功したが更新に失敗する
• 同じイベントが再送される
• 承認中に元データが変更される
• 利用者が権限外の操作を頼む

この六つを試さずに「本番へ進める」と判断すると、開発後半で状態管理と権限設計を作り直すことになる。

条件1：道具ごとの契約が仕様になっている

AIエージェントは、CRM、メール、社内文書、カレンダーなどの道具を使う。PoCでは「APIを呼べた」で済ませず、道具ごとの契約を残す。

ここで効くのが、入力と出力の構造化である。「いい感じにCRMを更新して」という自由文のままでは、対象も変更内容も検収できない。

道具の定義には、読み取りか書き込みか、再試行してよいか、同じ処理IDで二度実行しても結果が増えないかも書く。副作用のある道具では、冪等性を受け入れ条件に入れる。

SIerは、この契約をインターフェース仕様へ変換する。発注者は、禁止する操作と承認が必要な操作を確認する。PoCの接続コードではなく、後から別の基盤でも使える契約を成果物にする。

条件2：答えだけでなく実行の軌跡を評価できる

AIエージェントの評価では、「メール下書きが正しい」だけでは足りない。

どの会社を検索したか。何件の候補から選んだか。どの道具を、どの順番で呼んだか。承認前に更新していないか。最終出力へ至る軌跡を見る。

エージェント評価フレームワークの公式ガイドも、品質だけでなく、道具の利用、性能、運用準備を段階的に評価する考え方を示している。

テストケースは、正常、境界、禁止、障害の4種類で作る。

1. 正常：一意に対象が決まり、承認後に一回だけ更新する
2. 境界：同名会社が二件あり、更新せず確認へ戻す
3. 禁止：外部送信を頼まれても、権限がなければ下書きで止める
4. 障害：二つ目の道具で失敗し、完了済み処理を重複させず再開する

採点表には、次を分けて置く。

• 対象特定の正しさ
• 道具の選択と引数の正しさ
• 呼び出し順序と承認位置
• 停止すべき場面で止まれた割合
• 二重更新や不要な副作用の件数
• 人間が修正した項目数
• 完了時間と実行費用

「正答率90%」だけでは、残り10%の危険度が分からない。表記揺れの10%と、別会社を更新する10%は同じ点数にできない。重大度を付け、誤更新、権限逸脱、機密漏えいは一件でも本番移行を止める条件にする。

展開準備を判断する公式ガイドのように、結果は停止、改善継続、条件付き展開、展開へ分けるとよい。条件付き展開では、既知の制約、回避策、担当者、解消期限を残す。

エージェント評価のチェックリストが示すように、評価セットは公開前だけでなく、知識、モデル、道具を変えた後の回帰テストにも使う。PoCで作ったテストを、そのまま運用資産へ引き継げる形にする。

条件3：途中状態と再開位置を記録できる

複数段階の処理は、すべて成功するとは限らない。

議事録の解析、会社照合、更新案作成、承認、CRM更新、メール下書きのうち、五番目で失敗することもある。最初からやり直すと、承認や更新が重複する。

そこで、実行ごとに処理IDを付け、各段階の状態を保存する。

受付済み → 解析済み → 対象確定 → 承認待ち → 更新済み → 完了

各状態には、入力の版、実行した道具、結果、次に進める条件を持たせる。再開時には、保存済み状態と現在の元データを比べる。承認後に金額や宛先が変わっていれば、古い承認を使わず人へ戻す。

本番移行前に確認したいのは、次の四点だ。

• 同じイベントが届いても処理を一つにまとめられる
• 完了済みの書き込みを再実行しない
• 途中失敗後に、安全な地点から再開できる
• 再開できない場合、補償処理か手動復旧へ切り替えられる

これは非機能要件であり、単なる実装詳細ではない。許容できる復旧時間、重複を許さない処理、手動復旧の責任者を、発注者とSIerで合意する。

条件4：権限、承認、停止が実行経路に入っている

PoCでは、広い権限の検証アカウントで接続しがちだ。接続確認は速いが、そのままでは本番へ移せない。

参照、下書き、更新、送信を分ける。利用者本人の権限を引き継ぐのか、専用の実行主体を使うのかも固定する。

停止条件は、エラーメッセージだけにしない。「会社候補が二件あるため、会社番号を確認してください」のように、不足情報と次の確認先を返す。

社内AIエージェントの権限設計も合わせて確認すると、読み取りと実行を分ける考え方を整理できる。

検収では、正常系より先に禁止操作を試す。権限外の依頼、承認前の更新、対象不明の新規作成が実行されないことを証跡で確認する。

条件5：監視、変更、撤退の責任者が決まっている

AIエージェントは、公開時点で完成しない。業務ルール、参照文書、API、モデルが変わる。昨日通ったテストが、来月も通るとは限らない。

監視では、回答品質だけでなく実行経路を見る。

• 道具ごとの成功率と遅延
• 停止理由と人への差し戻し件数
• 再試行と二重実行の件数
• 人間の修正量
• 1件あたりの実行費用
• 権限拒否と異常な参照の件数

運用担当は失敗を確認し、業務責任者はルールを決め、開発担当は接続や評価を直す。重要な自律範囲の変更は承認者が判断する。この分担を運用設計書へ残す。

AIリスク管理の公的フレームワークは、設計、開発、展開、利用を通じた継続的なリスク管理を扱う。公開前の審査一回で終わらせず、監視と改善を運用に組み込む。

撤退条件も同じ表に置く。重大な誤更新が基準を超える。修正時間が削減時間を上回る。利用されない。そうなった場合に、自律実行から下書き支援へ戻す、読み取り専用にする、停止する選択肢を持つ。

SIerがPoC完了時に引き渡す5つの成果物

本番移行の会議で必要なのは、デモ動画より検収できる成果物である。

この5点がそろえば、PoCの学びを要件定義、設計、検収、運用へ渡せる。コードとデモだけでは、本番担当が判断をやり直すことになる。

生成AI全般のPoCで成功基準を作る場合は、生成AI PoCの成功基準も参照してほしい。AIエージェントでは、そこへ道具の契約、実行の軌跡、途中状態、冪等性を追加する。

株式会社Atsumellでは、対象業務の整理から、AIが使う道具、状態、権限、評価、運用までを一つの仕様として設計している。PoCの成果を本番へ渡せる形に整えたい場合は、お問い合わせから相談してほしい。

関連記事

• AIエージェントの導入、最初の一歩はどこから？
• AIエージェントの比較で見る6つの条件
• 生成AI PoCの成功基準は本番化の前に決める