第5章 運用・コスト・安全性

学習目標

• 最大ターン数、予算上限、進展のないループの検出で、暴走と無限ループを防ぎます。
• タイムアウトと再試行をエラーの種類と冪等性に合わせて設計し、再試行の急増を防ぎます。
• 取り消し可能性と影響範囲で人の承認ポイントを選び、承認を実行内容に結び付けます。
• フック・コールバック・ガードレールを実行経路に配置し、各仕組みの適用範囲を把握します。
• サンドボックスと最小権限で被害範囲を限定し、事故対応の順序を定めます。

はじめに

ある金曜の夜、リサーチエージェントが同じ検索を数百回繰り返しました。検索結果の形式が変わって読めなくなり、読めないため再検索していました。ターン制限は無効で、コスト警報は月曜の朝になって受信箱で見つかりました。別の会社では正反対のことが起きました。全行動に人の承認を設けると、1日数百件の承認依頼が届き、承認者は数秒でボタンを押すようになりました。最後には、危険な依頼が一つ、誰にも読まれず通りました。

二つの事故に共通するのは、安全をモデルの判断や人の注意力に依存していたことです。この章は、安全をシステムへ組み込む方法を扱います。停止条件・予算・タイムアウト・再試行・過負荷制御で暴走を防ぎ、危険な箇所だけに承認を設け、フック・コールバック・ガードレール・サンドボックスで実行経路に強制力を組み込み、事故対応の順序を整理します。

重要な概念

停止条件はシステムに組み込む

「完了したら停止する」という指示は推奨にすぎません。停止はループを動かすコードが強制すべきです。OpenAI Agents SDKのランナーは、最終出力で終了し、handoffやツール呼び出しがあれば再び回るループです。max_turnsでターン数を制限し、超えるとMaxTurnsExceeded例外が発生します。max_turns=Noneを渡すと制限が無効になるため、運用では共通の実行ラッパーで上限を強制してください。error_handlersに"max_turns"ハンドラーを設けると、例外の代わりに「依頼の範囲を絞って再試行してください」など、制御された最終出力を返せます。

result = await Runner.run(agent, "今週の精算差異を確認して", max_turns=15)

ターン制限だけでは不十分です。一ターンで高価なツールを複数回呼べるうえ、サブエージェントが個別にターンを使い、同じ検索を繰り返す場合もあります。

停止時には理由、部分結果、次の選択肢を残し、ユーザーと運用者が次の判断をできるようにします。

予算上限の層

コスト上限は複数の層に重ねて設けます。一層を突破しても次の層が止めるためです。

プロバイダー側の上限も活用してください。Claude APIでは組織・ワークスペース単位で支出上限を設定でき、ワークスペースごとの支出・レート上限を低くして、一か所の過剰利用が他を止めないようにできます（デフォルトワークスペースを除く）。独自設定の支出上限に達すると通常は400エラー（Claude Codeワークスペースではretry-after付き429の場合あり）、使用ティアの月間支出上限に達するとretry-afterなしの429が返ります。後者はアクセス再開までSDKの自動再試行も含めてすべて失敗するため、エラー内容で区別し、再試行ではなく運用者への通知に回してください。

OWASP Top 10 for LLM Applications 2025は、このリスクを無制限の消費（Unbounded Consumption、LLM10）と分類し、過剰な呼び出しでコストを急増させるウォレット枯渇攻撃（denial of wallet）を例に挙げています。対策は、入力サイズの検証、ユーザー別のレート制限と割り当て、タイムアウトと処理量の制御、使用量監視、一部の機能を維持しながら縮退するグレースフルデグラデーションです。

複数ワーカーの同時実行では、事後精算だけで上限を守るのは困難です。起動前に予想コストを予約し、終了後に精算すれば、同時出発したワーカーの合計が上限を超える事態を減らせます。

進展のないループを検出する

呼び出し回数が少なくても、同じ失敗を繰り返していれば価値は生まれていません。進展を測る兆候は次のとおりです。

1. 同じツールを同じ引数で連続N回呼んだ。
2. 同じエラーメッセージが連続して返った。
3. 直近Mターンで新たな根拠、ファイル、状態変化がない。
4. 失敗後も同じツールと引数の組み合わせで再試行する。

兆候を検出したら実行を止め、反復した呼び出しとエラー、そこまでの成果物をまとめて人に渡します。検出はツールラッパーやループコードで行うため、モデルが指示に従うかどうかにかかわらず動作します。

タイムアウトと締め切り

タイムアウトは、クライアントがリクエストの完了を待つ最大時間です。Amazon Builders' Libraryの記事は、勘で設定せず、許容する誤タイムアウト（もうすぐ終わるリクエストを待ち切れず諦める場合）の割合（例：0.1%）を先に定め、そのパーセンタイル（例：p99.9）の下位サービスのレイテンシを基準にするよう勧めています。リモート呼び出しには接続タイムアウトとリクエストタイムアウトを両方設けます。

エージェントにはタスク全体の締め切りも必要です。各段階のタイムアウトが正常でも、再試行と段階が積み重なると際限なく長引くため、残り時間を各段階に配分し、不足するなら新しい段階を始めません。MCP仕様も全リクエストのタイムアウトを推奨し、進捗通知でタイマーをリセットできる場合でも、最大タイムアウトは常に強制するよう求めています。モデル呼び出しでは、Claude API文書が10分を超え得る長いリクエストにストリーミングやバッチAPIを勧めています。

再試行

再試行は一時的な失敗から回復させますが、Amazonの表現では「利己的」です。成功確率を上げるためにサーバー容量を追加で使うからです。過負荷時の再試行は過負荷を強めます。原則は次のとおりです。

SDKのデフォルト再試行も計算に含めてください。Claudeの公式SDKは、接続エラー、レート制限、5xxなどの一時的失敗をデフォルトで2回、指数バックオフで再試行し、retry-afterに従います。その上でツールラッパーが3回、エージェントも3回再試行すると、一度の失敗が数十回の呼び出しになります。担当階層は一つに決めてください。実行の有無が不明な失敗（第2章）は、再試行より処理結果の照会を優先します。

同時実行と過負荷の制御

一つのタスクの暴走が、他ユーザーの正常業務まで妨げてはいけません。そのための仕組みは四つです。

• 同時実行制限：組織・ユーザー・ツールごとに、同時実行と外部呼び出しの数を制限します。
• 待ち行列と流入制限：待ち行列が長くなったら、新しいタスクの受け付けを遅らせるか優先度を下げます。待機にも期限を設けます。
• サーキットブレーカー（circuit breaker）：下位サービスの失敗率が閾値を超えたら、一定時間呼び出し自体を止め、失敗する呼び出しによる浪費を防ぎ、回復の時間を与えます。電気のブレーカーが過電流で回路を切るのと同じです。通常はクローズ（通過）、遮断中はオープン、一定時間後に試験呼び出しを送るハーフオープンを経て、成功すれば再びクローズに戻ります。
• グレースフルデグラデーション：処理できない場合は「受け付け済みで、処理後に通知する」など、一部機能だけを維持します。

内部上限は固定時間枠ごとのリセットより、継続的に補充されるトークンバケット方式（Claude APIもレート制限に採用）のほうが瞬間的な急増に対処しやすくなります。

人による承認ポイント

全行動に承認を設けると、承認者はやがて読まずに押します。承認疲れです。OpenAIのガイドは、読み取り・書き込み、取り消し可能性、必要なアカウント権限、金銭的影響でツールを低・中・高リスクに分類し、高リスク関数の実行前にガードレール検査や人への引き継ぎを自動で結び付けるよう勧めています。人が介入する二つの契機は、失敗閾値の超過（何度試しても意図を理解できないこと）と、高リスク行動（注文取消、高額返金、決済）です。高リスク行動は信頼が蓄積するまで人が監督するよう求めています。

判断の二軸は、取り消し可能性と影響範囲です。

承認画面には、実行する内容（対象、金額、受信者、件数）、根拠、トレースへのリンクを表示します。依頼数を減らしてこそ、一件ずつ真剣に読まれます。

承認を実行内容に結び付ける

承認と実行の間には隙間があります。承認者が見た金額と実際の引数が違う、承認後に対象が変わる、同じ承認で2回実行する、といった可能性です。承認を実行内容に結び付けると、この隙間を閉じられます。

1. 承認依頼に全実行引数を含め、キー順を固定した正規化シリアライズのハッシュや、プレビューID（第2章）を承認記録へ保存する。
2. 実行直前に、実際の引数が承認内容と同じかサーバーで照合する。異なれば実行せず、再承認を得る。
3. 承認に有効期限を設け、一度の使用で消費されるようにする。
4. 承認者の権限も実行時に再確認する。承認自体が新しい業務権限を与えるわけではない。

OpenAI Agents SDKでは、ツールにneeds_approvalを設定すると実行が停止し、承認待ち項目が結果のinterruptionsに入ります。これをRunStateに変換して承認または拒否し、同じ状態から続行します。シリアライズ状態には保留中のツール引数も入るため、文書の推奨どおり、サーバー管理の保存先に置き、信頼できるスナップショットだけを復元してください。ローカルのShellToolとApplyPatchToolは承認が任意で、needs_approvalのデフォルト値はFalseという点も覚えておいてください。

実行経路に置く遮断装置

禁止事項は、プロンプトではなく実行経路に置きます。ツールの実行直前にコードで検査し、遮断できる必要があります。

ADKプラグインの短絡（short-circuit）ルールは、順序の問題を生みます。Pythonでは登録順に実行され、最初に値を返したプラグインで止まるため、結果を即座に返すプラグインが先にあると、後ろの検査は動きません。必須の検査の位置を登録順で確認してください。

ガードレールの適用範囲

OpenAI Agents SDKのガードレールが、どこまで適用されるかを正確に把握する必要があります。

• 入力ガードレールはチェーンの最初のエージェントだけで、出力ガードレールは最終出力を出すエージェントだけで実行されます。
• 入力ガードレールは、デフォルトではエージェントと同時に実行されます（run_in_parallel=True）。作動前に、すでにトークンを使い、ツールを実行している場合があります。副作用のあるツールを使うなら、run_in_parallel=Falseでガードレール終了後にエージェントを開始します。文書も、コスト削減とツール副作用の防止にこの方式を勧めています。
• ツールガードレールは関数ツール（FunctionTool）を包みます。handoff呼び出し自体には適用されず、ホスト型ツールやShellTool・ApplyPatchToolなどの組み込み実行ツールはこのパイプラインを通りません。Agent.as_tool()は、現在ツールガードレールのオプションを直接公開していません。

サンドボックスと最小権限

信頼できない入力を扱う、またはコードを実行するエージェントは、モデルの判断ではなく環境で安全を確保します。サンドボックスは、プログラムがアクセスできるファイル、プロセス、ネットワークをOSレベルで制限した隔離環境です。

Claude Codeのサンドボックスがよい例です。デフォルトでは無効で、有効にするとシェルコマンドとその子プロセスにOSが強制する境界（macOSはSeatbelt、LinuxとWSL2はbubblewrap）が適用されます。Windowsネイティブではサンドボックスなしで実行されるため、WSL2内で使う必要があります。公式ドキュメントに記載された境界は次のとおりです。

• 書き込みは作業・一時ディレクトリなどに制限されますが、読み取りはデフォルトで~/.sshなどの認証情報ファイルを含むファイルシステムの大部分で許可されています。遮断にはdenyReadを設定します。
• ネットワークは許可ドメイン一覧（初期は空）を検査するプロキシを通ります。文書は、github.comなどの広いドメインを許可すると、データ流出経路になり得ると警告しています。
• 組み込みのファイル・Webツールはサンドボックス外で動き、権限ルールに従います。コマンドフックとローカルMCPサーバーはユーザーの全権限で動くため、内部動作まで制限するには別の隔離が必要です。
• コマンドがサンドボックスで失敗すると外での再試行を要求できますが、allowUnsandboxedCommands: falseでこの出口を閉じられます。サンドボックスを起動できないときに実行自体を止めるには、failIfUnavailableを有効にします。

文書は、権限ルールとサンドボックスを相互補完する層として説明します。プロンプトインジェクションでモデルの判断を迂回されても、サンドボックスの制限は残るからです。確認をすべて省略するbypassPermissionsモードは、被害が広がらないコンテナやVMなどの隔離環境だけで使うよう警告しています。

OWASPは、エージェントが有害な行動をするリスクを過剰なエージェンシー（Excessive Agency、LLM06）にまとめ、根本を過剰な機能・権限・自律性と捉えています。対策は、拡張機能と範囲の最小化、処理範囲が限定されていない拡張機能の回避、最小権限、ユーザーの権限コンテキスト内での実行、影響の大きい行動の人による承認、LLMではなく下位システムが許可を判断する完全仲介（complete mediation）です。

プロンプトインジェクションと権限の分離

プロンプトインジェクションは、入力がモデルの行動を意図と異なるものに変える脆弱性です（OWASP LLM01）。ユーザーが直接入れる直接インジェクションと、Webページやファイルなど外部ソースの内容に隠れた間接インジェクションがあります。ツールを持つエージェントには、間接インジェクションが特に危険です。読むだけのつもりだった文書が行動を指示するからです。

OWASPが挙げる対策は、モデル行動の制約、期待する出力形式の定義と検証、入出力フィルタリング、権限制御と最小権限、高リスク行動の人による承認、外部内容の分離と明示、攻撃シミュレーションを含む敵対的試験です。設計の要点は、インジェクションを完全には検出できないと仮定することです。そのため、信頼できない内容を読む段階と取り消せない行動の段階の間に権限境界を設けます。外部内容を読んだ後の外部送信ツールに人の確認を要求する、読み取り専用のサブエージェントが要約だけを渡す、といった方法です。

事故対応

エージェントが誤った一括処理を行ったら、次の順序を守ります。

1. 遮断：書き込みツールまたはエージェント自体を即座に停止します（キルスイッチ）。デプロイせず変更できる設定値（機能フラグ）でツール別・テナント別・全体の単位で止められるようにし、停止時にトレースとログを失わないようにします。
2. 範囲の確定：トレースと監査ログから、影響を受けた対象と時点を特定し、証拠を保存します。
3. 復旧：確定した範囲だけを元に戻すか補償します。プログラムの版を戻すことと、すでに外部で生じた効果の復旧は別です。
4. 再発防止後の再開：原因を直し、事例を回帰評価に追加して合格を確認してから、権限を段階的に再開します。

この順序は、普段から監査ログ、トレーシング、キルスイッチ、元に戻せる書き込みの設計があるからこそ実行できます。組織ではNIST AIリスク管理フレームワーク（AI RMF）が出発点になります。任意に利用できるこの枠組みは、ガバナンス（Govern）、文脈の把握（Map）、測定（Measure）、管理（Manage）の四機能でAIリスクを扱い、生成AIプロファイル（NIST AI 600-1）も別途あります。法的な報告・記録義務は業種と管轄で異なるため、別に確認する必要があります。

さらに深く

部分成功と補償処理

複数の外部システムを順に変えるタスクは、途中で失敗すると一部だけ変わった状態が残ります。DBトランザクションのように一括で取り消せないため、段階ごとに補償処理（生じた効果を相殺する逆の操作）を事前定義します。分散システムでサガ（saga）パターンと呼ぶ方式です。予約を作ったなら予約取消、クレジットを付与したなら回収が補償です。

補償には限界があります。補償自体が失敗する場合もあり、通知送信や送金など事実上回収できない行動もあります。そこで、取り消しやすい段階を先に、取り消せない段階を最後に配置します。外部通知は内部の全変更の確定後に送ります。各段階の確定地点と部分成功の状態を記録すれば、事故時の範囲確定と復旧が速くなります。

実行中のタスクを壊さないデプロイ

長時間実行エージェントは、デプロイの性質を変えます。数時間のタスクが動いている間にツール引数の形式やプロンプトを変えると、新しいコードで進行中のタスクが壊れ得ます。Anthropicのリサーチシステムは、実行中のエージェントを妨げないよう、旧版と新版を同時に起動し、少しずつトラフィックを移すレインボーデプロイ（rainbow deployment）を使うと記しています。

設計原則は三つです。第一に、モデル・プロンプト・ツール定義・ポリシーを一つの実行構成バージョンにまとめ、各タスクの開始時の版を記録します。第二に、進行中のタスクはその版で完了させ、新規タスクだけを新版に送ります。第三に、ツール引数の形式を変えるときは、当面は旧形式と新形式の両方を受け付けます。変更前は、実際の副作用を起こさず新版を並行実行して行動差を見るシャドー実行で、リスクを減らせます。

自律性を段階的に広げる

取り消せないツールは、一度に開放しません。模擬実行で行動を観察し、実行は全件人の承認付きで始め、人による修正率と事故件数が基準以下を保つ低リスク領域から自動化を広げます。拡大条件と差し戻し条件を数値で定めてください。OpenAIのガイドのとおり、高リスク行動の人による監督は、信頼が蓄積するまで維持するものです。

実務の場面

おでかけチケット：発売日の再試行急増

公演予約プラットフォーム「おでかけチケット」の相談エージェントは、予約照会、座席変更、取消の受け付けを支援します。人気公演の発売日に、外部予約システムのレイテンシが通常のp99の0.8秒から12秒へ増大しました。モデルSDKがデフォルトの再試行を行い、ツールラッパーがさらに3回試し、エージェントも失敗を見て同じツールを再度呼びました。1時間の予約システム呼び出しは通常の9倍、問い合わせ1件あたりのコストは5倍になり、待ち行列が増えて通常の問い合わせまで遅れました。

チームは三つの案を却下しました。タイムアウトを60秒へ延ばすと接続を長く保持し、同時処理能力がさらに下がります。ワーカーを増やすと、すでに遅い予約システムに負荷を加えます。max_turnsを下げても、コストは減る一方、再試行の乗算構造が残ります。

修正は次のとおりです。再試行はツールラッパーの一か所だけで、指数バックオフとジッターを使い、最大2回としました。エージェントには「予約システムが遅延中です。再呼び出しせず、受け付けの案内をしてください」という回復指示を返します。予約システムの呼び出しはテナントごとに同時実行上限を設け、30秒間の失敗率が50%を超えるとサーキットブレーカーが開き、2分間遮断し、その後の試験呼び出しが成功すれば閉じます。遮断中は座席変更と取消を受け付けだけにし、処理後に通知します。一相談には全体の締め切り90秒と、トークン・ツール呼び出し上限を設けました。座席変更には予約番号と変更依頼番号から作った冪等キーを付け、再試行でも受け付けは一度だけにしました。

次の発売日も同じ遅延がありましたが、予約システムへの呼び出しは通常の1.4倍にとどまり、通常の問い合わせの応答時間はほぼ変わりませんでした。

せせらぎ精算：承認を減らして承認を生かす

精算代行会社「せせらぎ精算」は、加盟店の精算ミスを見つけ訂正するエージェントを試験運用しました。全訂正に承認を設けると、依頼は1日400件を超え、平均確認時間は4秒まで下がりました。

チームはツールをリスク別に分けました。照会と報告書作成は自動、10万ウォン以下で次回精算で相殺される訂正は日次上限内で自動、10万ウォンを超える訂正と加盟店への外部通知は承認必須としました。承認は指示ではなく訂正ツール前の実行段階で強制し、画面には金額・根拠・トレースリンクを表示しました。記録には訂正内容のハッシュを保存し、実行直前に引数が異なれば実行せず再承認を求めます。承認は24時間後に失効します。依頼は1日30件程度に減り、1件あたり1分以上かけて内容を精読する確認体制が定着しました。

実行ごとに最大ターン数とコスト上限を設け、同じ引数で5回を超えて照会したら停止・通知させました。1か月後、元データの形式変更で同じ照会が繰り返されましたが、反復検出が3分で停止させました。運用者はキルスイッチで訂正ツールだけを無効にし、照会は維持してパーサーを修正し、この事例を回帰セットへ追加してから訂正ツールを再開しました。採用しなかった案は「承認者を増やす」でした。依頼が400件あれば、承認者を増やしても一件に使う注意は増えないからです。

間違えやすいポイント

1. 「全行動に承認を設ければ最も安全だ」 制御が多ければ安全に見えますが、承認疲れで確認が形式化すると危険な依頼も通ります。取り消し可能性と影響範囲で選びます。
2. 「システムプロンプトに禁止を書いたから遮断される」 モデルは通常指示に従うため信じたくなりますが、指示は推奨です。取り消せない行動は実行経路で遮断します。
3. 「入力ガードレールがあるから副作用のあるツールも安全だ」 入口の検問は安心感を与えますが、デフォルトの同時実行では、作動前にツールを実行している場合があります。
4. 「再試行は多いほど成功率が上がる」 もう一度なら成功しそうでも、過負荷時は負荷を強め、各階層で試すと乗算で増えます。一階層、バックオフとジッター、上限を設けます。
5. 「ターン制限があるからコスト暴走はない」 ループが終わると安心しますが、一ターンの高価な呼び出し、サブエージェントの増殖、反復検索はターン数だけでは捉えられません。
6. 「サンドボックスを有効にしたから秘密は漏れない」 隔離は心強くても、読み取りが開放されていたり広いドメインを許可したりすると流出経路が残ります。外で動くツールもあります。
7. 「監査ログがあれば承認は不要だ」 記録があれば制御できているように見えますが、ログは事後追跡用であり、削除済みデータを復活させません。
8. 「承認されたからそのまま実行すればよい」 人が確認すれば十分に見えますが、承認と実行の間で引数が変わり得ます。実行内容に結び付け、期限と一回限りの使用を設けます。

ひと目でわかるまとめ

公式ドキュメントで確認する

• OpenAI Agents SDK: Running agents — エージェントループ、max_turns、エラーハンドラー
• OpenAI Agents SDK: Guardrails — 入力・出力・ツールガードレールの範囲と実行方式
• OpenAI Agents SDK: Human-in-the-loop — needs_approval、中断と再開
• Claude Code: Hooks reference — PreToolUseの遮断と終了コード
• Claude Code: Configure permissions — ルール評価順序、フックとの優先順位、bypassの警告
• Claude Code: Sandboxing — サンドボックス境界、ネットワーク許可一覧、限界
• Google ADK: Plugins — 全体ポリシー、コールバックとの優先順位、短絡ルール
• OWASP: LLM06 Excessive Agency — 過剰な機能・権限・自律性と対策

セルフチェック

5-1. 最大ターン数だけでは防げないコスト暴走を二つ挙げ、それぞれを防ぐ仕組みを書いてください。

5-2. モデルSDK、ツールラッパー、エージェントが別々に再試行する際の問題と、推奨する設計を説明してください。

5-3. ツール呼び出しがタイムアウトした際、すぐ失敗と記録して再送してはいけない場合と、代わりにすべきことを説明してください。

5-4. 全行動に人の承認を設けると逆に危険になる理由を説明し、対象を選ぶ二軸を挙げてください。

5-5. Claude CodeのPreToolUseフックによる遮断（終了コード2）と権限ルール（allow、deny）の関係を説明してください。

5-6. Claude Codeのサンドボックスが包まないものを二つ挙げ、それを何で制御するか書いてください。

5-7. 一人のユーザーが1日に使えるエージェントのコスト上限を決め、80%と100%に達したときのシステムの動作を設計してください。

実習課題