AIエージェント本番化は「止め方」から設計する――停止・引き継ぎ・再実行の実務

月曜の朝、AIエージェントが週末分の依頼を処理し、画面には「120件完了、7件失敗」と表示されている。ところが、どのメールを送信し、どの顧客情報を書き換え、どこからやり直せばよいのかが分からない――たとえば、そんな場面では、モデルの正答率より先に運用設計の欠落が表面化します。

本番化で最初に問うべきなのは、「どこまで自動化できるか」ではありません。「どの条件で止め、誰に何を渡し、重複なくどこから再開できるか」です。本稿の立場は明確です。AIエージェントは、能力の広さではなく、失敗から業務を戻せる最小単位を先に設計すべきです。

利用拡大は、失敗の影響範囲も広げる

パナソニック コネクトは、自社向け「ConnectAI」を国内全社員約11,800人に展開し、2025年度の削減効果を78.8万時間、総労働時間の3.4％と公表しています。これは同社による算定値であり、独立検証済みの効果ではありません。同社は2026年度から、SFAやERPなどの構造化データと連携する業務データ連携型AIエージェントの活用拡大も掲げています。[1]

デジタル庁も、2025年5月に全職員向けの生成AI利用環境「源内」を内製し、国会答弁検索や法制度調査支援などを提供したうえで、運用継続と政府等への拡大方針を示しています。[2] これらは、生成AIの利用が文章作成から、社内データを参照し業務判断を支える段階へ進んでいることを示す事例です。ただし、事例の存在は、任意の業務で自律実行が妥当だという根拠にはなりません。

正答率だけでは本番運用を判定できない

デジタル庁の生成AI調達・利活用ガイドラインは、動作状況、不具合の原因と対応、更新内容、意図する利用範囲の情報提供に加え、管理機能の検証、運用監視、事故対応の体制・手順、予行演習まで確認項目に含めています。[3] また、総務省・経済産業省は2026年3月31日付で「AI事業者ガイドライン」を第1.2版へ更新しました。[4]

米国国立標準技術研究所（NIST）のAIリスクマネジメントフレームワークも、想定用途と異なる結果を出すAIを停止・無効化する責任、利用者による上書き、事故対応、復旧、変更管理を運用後の管理項目として挙げています。[5] 共通するのは、精度評価を通過した時点を完成と見なしていない点です。

精度は「普段どれだけ合うか」を測ります。しかし本番で損失を左右するのは、誤りが起きた後に何件へ波及するか、取り消せるか、担当者が事実を再構成できるかです。したがって、評価単位も回答一件ではなく、入力から外部システムの更新までを含む業務トランザクションへ広げる必要があります。

先に固定する三つの設計

1. 停止条件を「モデルの自信度」から切り離す

モデルが返す確信度だけに停止判断を任せると、業務上の重要度を取り違えます。読み取り、下書き、社内更新、外部送信、金銭・契約という順に、失敗時の回復費用は変わります。そこで各操作に、件数上限、金額上限、許可する対象、連続失敗回数、処理時間、入力欠損の条件を設定します。条件に触れたら、モデルに再考させるのではなく、処理を止めます。

OpenAIのエージェント構築ガイドも、試行回数が上限を超えた場合と、取り消しにくい高リスク操作を、人へ引き継ぐ主な条件として挙げています。[6] これは特定製品の成功保証ではなく、ベンダーが示す設計指針です。実務では、自社の損失上限と承認責任に置き換えて決めます。

2. 人への引き継ぎを「エラー通知」で終わらせない

担当者へ「失敗しました」とだけ通知しても、調査が最初から始まります。引き継ぎ時には、依頼ID、完了済みの工程、未実行の工程、参照した根拠、外部システムへ加えた変更、停止理由、推奨する次の操作を一組で渡します。画面上の会話履歴だけでなく、業務記録として検索できる形に残すことが重要です。

たとえば、見積書の下書き作成から承認依頼までを扱う場面では、「見積書を作成できなかった」では足りません。価格表の参照までは成功し、顧客別割引の承認者を特定できず停止した、と分かれば、人は未完了部分だけを判断できます。引き継ぎの品質は、復旧時間だけでなく、責任分界の明確さにも影響します。

3. 再実行は工程単位にし、副作用を台帳化する

最初から全工程を再実行する方式は実装が軽い一方、メールの二重送信やレコードの重複更新を招きます。人が毎回取り消す方式は例外に強いものの、件数が増えるほど運用負荷が上がります。推奨は、工程ごとに一意な処理IDと完了状態を持ち、外部への変更を「副作用台帳」に記録したうえで、未完了工程だけを再開する方式です。

ただし、この方式には初期設計と保存領域の費用がかかります。すべての試作へ実装するのではなく、外部送信や更新があり、同種処理を反復する業務から適用します。読み取り専用の短期検証なら、出力保存と手動確認で十分な場合もあります。

FDEでは「業務の戻し方」から段階を刻む

Forward Deployed Engineering（FDE）では、企画、試作、概念実証（PoC）、実装、定着を別々の引き継ぎ案件にしません。利用部門と開発側が同じ失敗記録を見ながら、次の順序で自動化範囲を広げます。

第一に、業務担当者と完了条件を一文で定義し、外部への副作用を列挙します。第二に、実データを読み取っても更新しないシャドー運用で、停止理由と引き継ぎ情報を集めます。第三に、通信切断、入力欠損、APIの時間切れ、承認者不在を意図的に発生させ、再実行と手動復旧を試します。第四に、対象件数と利用者を限定して更新を許可します。最後に、失敗一件当たりの調査時間、重複処理数、手動引き継ぎ後の完了率を見て範囲を広げます。

承認箇所を増やせば安全になるとは限りません。承認が頻発すると、担当者は内容を読まずに通すようになり、処理も滞留します。停止条件は「迷ったら全部」ではなく、損失が大きい操作、元に戻せない操作、根拠が欠けた操作へ絞るべきです。

処理件数が少なく、担当者が短時間で全件確認でき、しかも業務システム側に一意な処理IDを残せないという場合には、自律実行を前提とした多段エージェントには向きません。その場合は、AIを下書きと判断材料の提示に限定し、確定操作を人に残す方が合理的です。

実務への示唆

提言1：停止条件を先に承認してください。 モデル、プロンプト、画面を決める前に、件数・金額・対象・連続失敗・時間切れの上限を業務責任者が決めます。

提言2：PoCの合格条件に復旧試験を入れてください。 正常系の成功率だけでなく、途中停止、担当者への引き継ぎ、未完了工程からの再開を実演できることを条件にします。

提言3：自動化率ではなく回復可能性を追ってください。 少なくとも、重複処理、復旧に要した時間、手動で再調査した件数を記録します。自動化範囲は、この三つが許容範囲に収まってから広げます。

AIエージェントの本番化は、失敗をゼロにする計画ではありません。失敗が起きても、影響を限定し、経緯を説明し、業務を正しい地点から再開できる状態をつくる計画です。止め方が決まって初めて、自動化の速度を上げられます。

参考資料

1. パナソニック コネクト「AI活用で総労働時間の3.4％削減」（2026年7月29日）
2. デジタル庁「ガバメントAI『源内』」（確認日：2026年9月21日）
3. デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（2025年9月18日掲載版）
4. 経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日）
5. NIST「AI Risk Management Framework Core」（AI RMF 1.0、確認日：2026年9月21日）
6. OpenAI「A practical guide to building agents」（日付不明、確認日：2026年9月21日）

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-21。