AIエージェントを本番で回し始めると、精度そのものより、想定外にどう戻すかが重要になります。例外が起きた時に全部再試行する設計だと、誤更新や重複実行が増え、逆に全部止める設計だと現場負荷が上がります。
AIエージェントの例外は、①一時的な外部失敗、②入力不備・矛盾データ、③業務ルール違反、④権限・境界違反の4種類に分け、それぞれ「回数上限付きで再試行」「人へ移管」「その件だけ隔離」「そのワークフローを停止」を既定の戻し方にします。再試行してよいのは、待てば成功する可能性があり、同じ処理を二度実行しても副作用が重ならない場合だけです。人へ移管する例外には、処理ID・例外の種類・AIの判断理由・試行回数をまとめて渡し、再開は「原因が解消し、二重実行にならないこと」を確認してから行います。
要点
- AIエージェントの例外は、一時的な外部失敗、入力不備・矛盾データ、業務ルール違反、権限・境界違反の4種類に分け、戻し方を1つずつ決めます。
- 再試行してよいのは待てば直る外部失敗だけで、書き込みを伴う処理は処理IDで実行済みかを確かめてから再実行します。
- 人へ移管するときは処理ID・例外の種類・AIの判断根拠・試行履歴を渡し、再開は原因解消と二重実行の防止を確認してから行います。
例外は4種類に分け、戻し方を1つずつ決める
例外を「エラー」とひとまとめにすると、待っても直らない入力不備を何度も再試行したり、一時的な通信失敗で処理全体を止めたりします。まず、起きた原因が「時間が解決するか」「人の情報や判断が要るか」「その件だけの問題か」「仕組みの境界を越えたか」で4種類に分け、それぞれに既定の戻し方を1つ決めます。
| 例外の種類 | 典型例 | 既定の戻し方 | 再試行 | 次に動く人 |
|---|---|---|---|---|
| 一時的な外部失敗 | APIのタイムアウト、利用上限超過の一時エラー、接続先の一時障害 | 回数上限付きで再試行し、上限を超えたら人へ移管 | 可（重複防止が前提） | 上限超過時に運用担当 |
| 入力不備・矛盾データ | 顧客IDや承認者が空欄、同じ顧客に相反する状態がある | 人へ移管し、入力の補完や確認を依頼 | 不可（待っても直らない） | 入力元の担当者 |
| 業務ルール違反 | 値引き率が規程の範囲外、送付先が取引停止リストにある | その件だけ隔離し、判断者の確認待ちにする | 不可 | 業務ルールの責任者 |
| 権限・境界違反 | 許可されていない項目や外部への書き込み、承認なしの送信、認証切れ | そのワークフローを停止し、管理者へ通知 | 不可 | システム管理者 |
表の「既定」は、迷ったときに自動で選ばれる戻し方という意味です。たとえば認証切れは通信エラーに見えても、再試行で直らず、別の資格情報で動かすと統制を外れるため、権限の例外として扱います。どの種類にも当てはまらない例外は、再試行ではなく人への移管に倒すと安全です。
種類別の判断例：再試行・移管・隔離・停止
分類を決めても、現場で迷うのは境目のケースです。種類ごとに「どの状況なら、どう判断し、何を確認したら次へ進むか」を表にしておくと、担当者が替わっても判断がぶれにくくなります。
一時的な外部失敗：回数上限と重複防止を先に決める
| 状況 | 判断 | 確認すること |
|---|---|---|
| 読み取りAPIがタイムアウトした | 間隔を空けて再試行する | 上限回数に達したら人へ移管する |
| 書き込みAPIが応答を返さなかった | すぐに再試行しない | 書き込み先で処理済みかを処理IDで照合し、未処理の場合だけ再試行する |
| 同じ接続先で失敗が連続している | 個別の再試行をやめ、そのワークフローを止める | 接続先の障害か、自社側の設定変更かを切り分ける |
書き込みを伴う処理は、応答がなくても相手側では成功していることがあります。各処理に一意の処理IDを持たせ、「このIDは処理済みか」を確かめてから再実行すると、二重登録や二重送信を防げます。
入力不備・矛盾データ：AIに補わせず、入力元へ戻す
| 状況 | 判断 | 確認すること |
|---|---|---|
| 必須の顧客IDが空欄 | 入力元の担当者へ補完を依頼する | 補完後に、同じ処理IDで1回だけ再投入する |
| CRMと請求データで顧客の状態が食い違う | どちらが正しいかを人が判断する | 正本とするデータを決め、もう一方を修正してから再投入する |
| AIが推測で値を埋められそうに見える | 推測で埋めない | 推測値は「候補」として人に見せ、確定は人が行う |
業務ルール違反：その件だけ隔離し、本流は止めない
| 状況 | 判断 | 確認すること |
|---|---|---|
| 見積の値引き率が規程の上限を超えた | その見積だけ保留にし、承認者の確認待ちにする | 承認された場合は承認記録を付けて再投入、却下ならその件を終了する |
| メールの宛先が配信停止リストにある | その送信だけ止める | リストの更新漏れか、宛先データの誤りかを確認する |
| 同じ種類の違反が短時間に続く | 個別の隔離ではなく、ルールか入力側の不具合を疑って停止を検討する | 違反件数と発生元を確認する |
権限・境界違反：1件でもワークフローを止める
| 状況 | 判断 | 確認すること |
|---|---|---|
| 許可されていない項目への書き込みが要求された | そのワークフローを停止する | 指示文やツール設定の変更で範囲が広がっていないか |
| 承認がないまま外部送信しようとした | 停止し、送信済みの有無を確認する | 送信済みなら訂正や連絡が必要か |
| 認証が切れた、または別の資格情報に切り替わった | 停止し、管理者が資格情報を確認する | 誰の権限で動いていたかを監査ログで確認する |
OWASPは、影響の大きい操作の前に人の承認を挟むことや、操作してよいかの判断をAI自身に任せず接続先のシステム側で認可することを対策に挙げています。権限・境界違反を「再試行で通す」設計にしないことが重要です。同じ異常が複数のワークフローに広がっている場合や、誤送信・誤更新がすでに起きている場合は、個別の停止ではなくAI自動化の緊急停止手順に切り替えます。
人へ移管するときに渡す情報
人へ移管しても、受け取った担当者が最初から調べ直す状態では、例外処理は速くなりません。移管の通知や確認画面には、少なくとも次の項目をそろえます。
| 項目 | 内容 | ないと起きること |
|---|---|---|
| 処理ID | 対象の処理と、元のデータを特定できる一意のID | どの件か分からず、再投入で二重処理が起きる |
| 例外の種類 | 4種類のどれか、エラーの内容 | 担当者が原因の切り分けからやり直す |
| AIの判断と根拠 | AIが何を判断し、どのデータを見たか | AIの判断を採用してよいか判断できない |
| 試行の履歴 | 再試行した回数、途中まで実行したステップ | 実行済みの操作をもう一度行ってしまう |
| 求める対応と期限 | 補完・承認・却下のどれを求めるか、いつまでか | 保留が放置され、業務が止まったままになる |
移管の結果（補完した値、承認・却下、担当者）は監査ログに残します。同じ種類の移管が繰り返される場合は、入力フォームの必須項目やルールの見直しにつなげます。人がどの操作の前で確認するかという全体設計はHuman in the loopで整理しています。
隔離・停止した処理を戻すときの条件
例外処理は、止めることより戻すときに事故が起きやすくなります。隔離した件や停止したワークフローを再開する前に、次の3点を確かめます。
- 原因が解消している：入力が補完された、承認が得られた、権限設定が直った、など例外の種類に応じた解消を確認する。
- 二重実行にならない：処理IDで実行済みのステップを確認し、未実行の部分だけを再投入する。
- 記録が残っている：誰が、どの理由で再開を決めたかを記録する。
隔離した件は1件ずつ再投入し、停止したワークフローは少量の処理から再開して、同じ例外が再発しないかを確認します。再開の手順や担当は運用Runbookに書いておくと、担当者が替わっても同じ判断ができます。
よくある質問
AIエージェントの例外は何種類に分けて設計すればよいですか？
一時的な外部失敗、入力不備・矛盾データ、業務ルール違反、権限・境界違反の4種類に分けると、戻し方を1つずつ決めやすくなります。それぞれ、回数上限付きの再試行、人への移管、その件だけの隔離、ワークフローの停止を既定にします。
再試行してよい例外と、人へ回すべき例外はどう見分けますか？
時間をおけば成功する可能性があるかで見分けます。タイムアウトや接続先の一時障害は再試行の対象ですが、入力の空欄や承認の不足は待っても直らないため人へ回します。書き込みを伴う処理は、処理済みかを確認してから再試行します。
認証切れは再試行してよいですか？
再試行では直らず、別の資格情報で動かすと誰の権限で処理したかが追えなくなるため、権限の例外として停止し、管理者が確認します。
隔離と停止はどう使い分けますか？
問題がその1件に限られるなら隔離し、他の処理は続けます。権限や境界を越える操作が起きた、同じ違反が続いているなど、仕組み側の不具合が疑われる場合はワークフローごと停止します。誤送信や誤更新がすでに広がっている場合は、緊急停止の手順に切り替えます。
例外処理の結果はどこに残しますか？
例外の種類、AIの判断、試行回数、人の対応、再開の判断を監査ログに残します。同じ例外が繰り返される場合は、入力フォームやルールの見直し、Runbookの更新につなげます。
