AIエージェントの停止条件｜安全に任せる5つの設計
目次
はじめに
AIエージェントに業務を任せるとき、「どこまで自動で進めるか」はよく議論されます。一方で、同じくらい重要なのが「どの条件で止めるか」です。処理が完了したときだけでなく、情報が足りないとき、同じ操作を繰り返すとき、権限を越えそうなときにも、エージェントは安全に停止して人へ引き継げなければなりません。
停止条件がないエージェントは、失敗しても走り続ける仕組みになりやすいものです。APIを何度も呼ぶ、誤った前提で下書きを更新し続ける、承認が必要な操作まで進めようとする、といった事故につながります。停止は自動化の失敗ではなく、設計された制御です。
本記事では、業務で使うAIエージェントの停止条件を、次の5つに分けて整理します。
- 完了条件を満たしたら止める
- 回数と時間の上限で止める
- 異常や前提崩れを検知したら止める
- 権限・影響範囲を越える前に止める
- 人が判断すべき場面で止めて引き継ぐ
1. 完了条件を満たしたら止める
最初に決めるべきなのは、処理を続ける条件ではなく完了の定義です。たとえば「問い合わせに回答する」という業務なら、回答文を生成した時点を完了にしてはいけません。対象顧客を特定できていること、根拠となる社内情報を参照していること、必須項目が埋まっていること、送信前のレビュー状態になっていることまでを完了条件にします。
完了条件は、できればチェッ ク項目として表現します。
- 対象レコードのIDが確定している
- 必須フィールドの欠落がない
- 参照した情報の取得日時が記録されている
- 送信や更新の前に承認ステータスを確認している
- 実行結果を後から追跡できる
この条件をすべて満たしたら、エージェントは「成功」として終了します。条件を満たしていないのに文章だけ返す場合は、「未完了」または「要確認」として止めます。成功と停止を同じ意味にしないことがポイントです。
要件や完了条件をAIが読める形に整えるなら、Kakusillのように仕様・判断基準・変更履歴をまとめて管理できる仕組みも役立ちます。
2. 回数と時間の上限で止める
エージェントの処理には、最大反復回数、最大実行時間、外部APIの呼び出し回数などの上限を設定します。これは、正常系の処理を速く終わらせるためだけの設定ではありません。想定外のループや、同じ失敗の再試行を有限にするための安全弁です。
たとえば、次のように上限を分けます。
- 1タスクの最大ステップ数
- 同じツールを連続して呼べる回数
- 同じエラーに対する再試行回数
- 1回の実行に許される時間
- 1日または1案件あたりのコスト上限
上限に達したときは、無理に完了扱いにせず、停止理由と最後に成功したステップを保存します。「上限超過」という状態があれば、担当者は続きを再開するか、前提を修正するかを判断できます。再開時に最初から実行し直す設計にすると、二重更新や重複通知を招くため、チェックポイントも合わせて残します。
3. 異常や前提崩れを検知したら止める
AIエージェントは、入力が曖昧なままでも次の行動を提案できます。しかし、提案できることと、実行してよいことは別です。取得したデータの形式が変わった、対象件数が想定より大きい、参照先が空になった、前の処理結果と現在の状態が一致しない、といった変化は停止のサインになります。
異常判定には、次のような観点があります。
- 必須データが空、または型が想定と異なる
- 対象件数が設定した範囲を超えている
- 同じIDに対する更新が直前に行われている
- 外部サービスの応答が不完全、または検証できない
- モデルの出力が許可された形式から外れている
- 重要な事実を一次情報で確認できない
ここで重要なのは、取得できなかった情報を「該当なし」と解釈しないことです。取得失敗と該当なしは別の状態として保存し、未確認なら未確認のまま止めます。エージェントの判断に使った根拠、入力、出力、ツール結果を記録しておけば、後から原因を追えます。
4. 権限・影響範囲を越える前に止める
読み取りや下書き作成と、外部送信・削除・課金を同じ自動実行として扱うと危険です。操作を影響度で分け、エージェントの権限を越える境界に到達したら、実行前に停止します。
たとえば、次の操作は明確な境界を置きやすい領域です。
- 顧客や社外へのメール送信
- CRMや会計システムの正式更新
- レコードの削除、アーカイブ、権限変更
- 購入、支払い、広告予算の変更
- 契約や公開コンテンツの確定
停止画面や引き継ぎデータには、「何をしようとしたか」「対象は何か」「なぜ人の承認が必要か」を含めます。単に「承認してください」と表示するだけでは、レビューする人が判断できません。操作の差分、影響範囲、根拠、想定される取り消し方法まで渡すと、承認の質が上がります。
5. 人が判断すべき場面で止めて引き継ぐ
人への引き継ぎは、エージェントが失敗したときだけに限定しません。機微性が高い、影響が大きい、不可逆である、または関係者の合意が必要な操作は、正常に処理できる場合でも人の確認を挟みます。
引き継ぎ条件は「人が見て判断する」ではなく、観測できるルールにします。
- 金額や対象件数が閾値を超えた
- 個人情報や機密情報を外部へ出す可能性がある
- 顧客への回答が例外的な判断を含む
- 複数の情報源が矛盾している
- 再試行上限に達した
- 停止・取消・返金など不可逆性の高い操作を行う
このとき、エージェントは判断を人へ丸投げするのではなく、選択肢と推奨案を整理します。ただし、推奨案を 承認済みの事実として扱ってはいけません。人が判断した結果、差し戻しになった場合も、その理由を次回の設計改善へ反映できるようにします。
停止条件を要件に落とすチェックリスト
実装前に、次の項目を仕様書へ入れておくと、停止条件が運用で抜けにくくなります。
- 正常終了の条件は何か
- 最大ステップ数・時間・再試行回数はいくつか
- どの異常を検知し、どの状態へ遷移するか
- 読み取り、下書き、更新、送信をどう分けるか
- 承認者は誰で、何を見て判断するか
- 停止時にどの入力・根拠・出力を保存するか
- 再開する場合のチェックポイントはどこか
- 停止後に重複実行を防ぐ識別子は何か
「止める」ことまで実装したら、テストでは正常系だけでなく、空データ、タイムアウト、権限不足、重複実行、矛盾した情報を投入します。停止理由が再現でき、担当者が次の行動を選べることが合格条件です。
まとめ
AIエージェントの価値は、処理を最後まで自動で進めることだけではありません。安全に止まり、理由を残し、適切な人へ引き継げることも、業務へ組み込むための重要な能力です。
設計の順番は、完了条件、上限、異常、権限境界、引き継ぎ条件の順に整理すると進めやすくなります。これらを実装後に追加するのではなく、要件定義の段階で仕様・状態遷移・受け入れ条件として決めておくことが、PoC止まりや運用事故を防ぎます。
AIエージェントを実業務へ導入するなら、まず対象業務と停止条件を一緒に棚卸ししましょう。業務フロー、権限、例外、判断履歴を整理したうえで、任せる範囲を段階的に広げることが、継続して使える自動化への近道です。
