先に要点
AIエージェントにツールを渡すと、調査、修正案作成、テスト、通知、デプロイ前確認まで自動で進められるようになります。
うまく使えば、人間が細かく指示しなくても、目的に向かって作業を進めてくれます。
ただし、自動で進むものは、自動で止まる設計も必要です。
エラーが出たのに別の方法を試し続ける。対象件数が想定より多いのに更新を続ける。検証環境のつもりが本番環境に接続している。
こうした場面で止まれないAIエージェントは、便利というより危険です。
この記事では、AIエージェントの停止条件をどう決めるかを、実務で使えるチェックリストとして整理します。
権限の分け方は AIエージェントの権限設計とは？読み取り・書き込み・承認を分ける実務チェック、本番操作全体の考え方は AIエージェントに本番操作を任せる前に決めること｜権限・承認・ログ設計のチェックリスト もあわせて読むとつながりやすいです。
停止条件とは何か
停止条件とは、AIエージェントが作業を続けず、人間、別のフロー、または安全な終了状態へ戻るための条件です。英語では stop condition、stop rule、abort condition、escalation condition のように表現されることがあります。
ポイントは、停止条件を AIが困ったら止まる という曖昧な話にしないことです。
実務では、数値、状態、検証結果、権限、対象範囲のような具体的な条件に落とします。
| 曖昧な止め方 | 実務向けの止め方 |
|---|---|
| 危なそうなら止める | 本番DB更新、外部送信、権限変更、削除は承認なしで実行しない |
| 失敗したら止める | 同じ操作が2回失敗したら停止し、担当者へ通知する |
| 件数が多ければ止める | 対象件数が事前見積もりの120%を超えたら停止する |
| おかしければ確認する | 検証環境の想定なのに本番接続情報を検出したら停止する |
停止条件は、AIエージェントの失敗を責めるためではなく、失敗が大きくなる前に区切るための設計です。
なぜ停止条件が必要なのか
AIエージェントは、通常のチャットAIよりも行動範囲が広くなります。
ツールを呼び出し、結果を見て、次の操作を選び、必要なら再試行します。
この性質は強みですが、運用ではリスクにもなります。
再試行
失敗した方法を少し変えて何度も試す
権限
権限エラーを別の経路で回避しようとする
ツール
目的達成のために不要なツールまで呼ぶ
環境
本番と検証環境を取り違える
影響範囲
対象件数や影響範囲を見誤る
前提
途中の前提が崩れても作業を続ける
人間なら途中で これは一回止めよう と判断する場面でも、AIエージェントは目的に向かって進み続けることがあります。
そのため、止める条件をプロンプトだけでなく、アプリ側の制御、ツール側の権限、ガードレール、承認フローに組み込む必要があります。
代表的な停止条件
実務でよく使う停止条件を整理します。
| 停止条件 | 止める理由 | 例 |
|---|---|---|
| 再試行回数 | 同じ失敗を繰り返すと影響が広がる | 同じAPI呼び出しが2回失敗したら停止 |
| 最大ターン数 | 無限に考え続ける、ツールを呼び続けるのを防ぐ | 10ターンを超えたら人間へエスカレーション |
| 対象件数 | 想定より大きい更新や送信を防ぐ | 更新対象が50件を超えたら停止 |
| 環境違い | 検証環境のつもりで本番を触る事故を防ぐ | production接続を検出したら承認待ちにする |
| 権限エラー | 回避策探しや権限逸脱を防ぐ | 403やpermission deniedが出たら停止 |
| 差分不一致 | 事前説明と実際の変更がズレたまま進むのを防ぐ | 承認済み差分と実行差分が違えば停止 |
| テスト失敗 | 壊れた状態で次へ進むのを防ぐ | テスト失敗後の自動デプロイは禁止 |
| 外部送信 | 誤送信や機密情報流出を防ぐ | 社外メール送信前に必ず停止して承認 |
OpenAI Agents SDK の Runner には max_turns のような実行上限があり、上限を超えると MaxTurnsExceeded が発生する仕組みがあります。これは、AIエージェントがいつまでもツール呼び出しや推論を続けないための基本的な安全装置です。例外で終わらせずに、error_handlers で上限に達したときの決まった出力を返すこともできます（2026年10月時点の公式ドキュメントで確認）。
再試行しすぎを止める
AIエージェントは、失敗すると別の方法を試せます。
これは調査や実装では助かることがありますが、本番操作では危険になることがあります。
たとえば、APIが失敗したときに自動で再試行する設計はよくあります。
しかし、同じ顧客へのメール送信、決済API、DB更新、クラウド設定変更で再試行しすぎると、二重送信、重複請求、状態不整合が起きます。
再試行については、次を決めます。
- 何回まで再試行してよいか
- 同じ入力で再試行してよいか
- 失敗理由が変わったら止めるか
- タイムアウトと権限エラーを同じ扱いにしない
- 再試行の間隔をどうするか
- 再試行後に人間へ通知するか
特に権限エラーは、再試行で解決しないことが多いです。権限がないなら別の方法を探す ではなく、権限エラーを停止条件にして、人間へ戻す方が安全です。
対象件数で止める
本番操作でよくある事故は、対象件数の見誤りです。
1件だけ更新するつもりが、条件のミスで1000件に当たる。特定顧客だけに送るつもりが、全ユーザーに送る。こういう事故はAIに限らず起きます。
AIエージェントに更新や送信を任せるなら、対象件数を停止条件に入れます。
例としては次です。
- 事前見積もり件数と実行直前件数が違えば停止
- 対象件数がしきい値を超えたら停止
WHERE条件なしの更新や削除は停止- 対象リストに社外ドメインが含まれたら停止
- 顧客IDが複数に増えたら停止
AIエージェントに 安全にやって と頼むより、対象件数を機械的に確認する方が堅いです。
環境違いで止める
検証環境と本番環境の取り違えは、AIエージェントでも人間でも起きます。
そのため、環境違いは強い停止条件にします。
たとえば、次のようなチェックです。
- 実行対象URLが
prodや本番ドメインを含む - DB接続先が本番ホストである
- クラウドアカウントIDが本番用である
- APIキーのスコープが本番用である
- デプロイ先ブランチが本番反映対象である
- 本番の監視アラートが出ている
検証環境では自動実行、本番環境では承認必須、という分け方はかなり実用的です。
環境名をプロンプトに書くだけではなく、ツール実行前にコードで確認するのが安全です。
ガードレール違反で止める
ガードレールは、AIの入力、出力、ツール操作を安全な範囲に収めるための制御です。
停止条件とガードレールはかなり近い関係にあります。
OpenAI Agents SDK の Guardrails では、入力と最終出力に加えて、関数ツールの呼び出しの前後もチェックでき、条件に合わない場合は tripwire を発火させて例外を出し、実行を止める仕組みが説明されています。
実務では、次のようなガードレール違反を停止条件にします。
- 個人情報を外部送信しようとしている
- 認証情報を出力しようとしている
- 承認なしで本番操作へ進もうとしている
- 禁止されたコマンドを実行しようとしている
- 許可されていないファイルを読み書きしようとしている
- 出力形式が契約やAPI仕様と違う
- 参照元が不明な情報を確定情報として扱っている
止めた後に何をするか
停止条件で止めるだけでは、運用としては半分です。
止めた後にどう扱うかまで決めておかないと、現場では 止まったけど誰も見ない という状態になります。
- 1
停止条件に触れる
再試行回数、対象件数、環境違い、権限エラー、差分不一致、ガードレール違反など。
- 2
実行を止める
その先の操作には進まない。
- 3
渡し先を決める
人間へ確認、安全な下書きへ戻す、別フローへ切り替える、完全に終了する、のどれか。
- 4
ログに残す
なぜ止まったか、何をしようとしていたか、誰が再開または拒否したか。
止めた後のパターンは主に4つです。
人間へ確認
危険操作、判断材料不足、環境違い、対象件数超過などは担当者へ渡します。
安全な下書きへ戻す
本番実行は止めつつ、作業案や確認項目だけを出力させます。
別フローへ切り替える
障害対応、セキュリティ確認、承認フローなど専用の流れへ移します。
完全に終了する
権限逸脱、危険コマンド、認証情報露出のような場面では再開させません。
停止後にAIへ 続けて と言えば再開できる設計にしてしまうと、停止条件の意味が薄くなります。再開できる条件、再開できない条件も分けておきます。
ログに残すべきこと
停止条件が発火したら、監査ログに残します。
あとから見たときに、なぜ止まったのか、何をしようとしていたのか、誰が再開または拒否したのかを追える必要があります。
最低限、次を残します。
いつ・なぜ
- 停止した日時
- 停止条件の種類
- 実行しようとしていた操作
どこに・何を
- 対象環境
- 対象リソース
- 入力パラメータ
直前の経過
- 直前のツール呼び出し
- エラー内容
- 再試行回数
判断と結果
- AIの提案理由
- 人間へ渡したか
- 承認、拒否、終了の結果
OpenAI Agents SDK の Tracing では、LLM生成、ツール呼び出し、handoff、guardrail などのイベントを記録する考え方が用意されています。どのSDKを使う場合でも、停止条件と実行ログをつなげておくと、事故調査や改善がかなり楽になります。
よくある失敗例
失敗例1：止める条件がプロンプトにしかない
危険な操作はしないで と書くだけでは弱いです。本当に止めたい操作は、権限、ツール実行前チェック、ガードレール、承認フローで止めます。
失敗例2：全部の操作で止めすぎる
検索、要約、ログ読み取りのたびに止めると、AIエージェントの良さが消えます。低リスクな読み取りは自動、高リスクな副作用は停止、という分け方が現実的です。
失敗例3：停止後の担当者が決まっていない
止まった通知だけ出ても、誰が見るか決まっていないと放置されます。停止条件ごとに、開発者、運用担当、セキュリティ担当、承認者のどこへ渡すかを決めます。
失敗例4：停止ログが薄い
ガードレール違反 とだけ残っていても、原因が分かりません。どの条件に触れたのか、どの入力やツール呼び出しが問題だったのかまで残します。
実務チェックリスト
AIエージェントの停止条件を設計するときは、次を確認します。
上限
- 最大ターン数や最大ツール呼び出し回数を決めた
- 同じ失敗の再試行回数を決めた
- 権限エラーは回避せず停止する
本番と対象範囲
- 本番環境を検出したら承認待ちにする
- 対象件数が想定を超えたら止める
- 削除、外部送信、課金、権限変更は自動実行しない
変更の確認
- テスト失敗後に本番反映へ進まない
- 差分が承認時と違えば止める
止めた後
- 停止後に誰へ渡すか決めた
- 停止理由、入力、ツール呼び出し、再試行回数をログに残す
- 再開できる条件と、再開禁止の条件を分けた
このチェックがない状態で本番操作や外部送信を任せるのは、かなり危険です。
AIエージェント停止条件のよくある質問
Q. 停止条件はどこに実装しますか？
A. コード側で実装するのが原則です。プロンプトだけで 停止しろ と書いても、AI が判断ミスする可能性があるため、コードレベルで 条件 → 強制停止 させます。
Q. 停止後の再開はどう設計しますか？
A. 人間承認後に再開可能なもの と 絶対に再開禁止のもの を分けます。本番環境誤検知 などは確認後再開、権限エラー は原因解消まで停止、などです。
Q. ループ防止はどう実装しますか？
A. 最大ステップ数(例: 50)、同じツールの連続呼び出し制限、コスト上限(例: $5/タスク)、時間上限(例: 30分)、を設定します。どれかに達したら強制停止です。
Q. 停止条件のテストはどうしますか？
A. 想定外の入力で停止する ことを CI/CD で自動検証します。意図的に問題ある入力を与えて、停止 + ログ記録 + アラート が動作するかをテストします。
Q. 停止しすぎる(過剰停止)になりませんか？
A. なります。過剰停止 だと業務に支障が出るため、しきい値の調整、段階的停止(警告 → 承認 → 停止)、例外条件の追加 で運用しながら調整します。
Q. 緊急停止スイッチは必要ですか？
A. 必要です。システム管理者が即座に全エージェントを停止できる kill switch を設けます。プロンプトインジェクション、コスト爆発、外部 API 障害、などの非常時用です。
Q. 停止条件のログから何を学べますか？
A. どの条件で何回停止したか、どの ユーザー入力で停止したか、再開後に再停止していないか、を月次で集計し、しきい値見直し や エージェント改善 に活かします。
まとめ
AIエージェントの停止条件とは、自動実行を安全に区切るためのルールです。
重要なのは、AIが賢く判断して止まることを期待するのではなく、再試行回数、対象件数、環境、権限、差分、ガードレール違反などを具体的な条件として設計することです。
AIエージェントは、止まれるからこそ任せられます。
自動化の範囲を広げるほど、どこで止めるか、止めた後に誰へ渡すか、何をログに残すかを先に決めておく必要があります。
関連して、ツールを渡しすぎるリスクは AIエージェントにツールを渡しすぎると何が起きる？選択ミス・コスト・権限リスクを整理、承認点の置き方は 人間承認をどこで入れるべき？AIエージェントの承認設計を整理 で整理しています。
停止条件は、AIエージェント運用の地味な部品ですが、本番運用ではかなり効く安全装置です。
参考
- OpenAI Agents SDK: Running agents
- OpenAI Agents SDK: Runner reference
- OpenAI Agents SDK: Guardrails
- OpenAI Agents SDK: Tracing