shirokuronoir

AIエージェントの暴走を止める4つの境界

AIエージェントの暴走を止める4つの境界

AIエージェントへ複数のツールを渡すと、1回の操作だけを見て許可する方式では足りません。顧客を調べてから送金する、金額が大きければ人が承認する、一定回数を超えたら止める。安全性は、操作同士のつながりまで見て初めて判断できます。

AWSは2026年8月6日、Amazon Bedrock AgentCoreに時系列ポリシーとGatewayのレート制限を追加しました。この記事では機能紹介で終わらせず、個人開発や小規模チームでも使える4つの運用境界へ置き換えます。

先に結論

本番のAIエージェントには、次の4つをエージェント本体の外側で強制します。

1. 危険な操作の前に必要な確認を通したか

2. 前のツールが返した値を改変していないか

3. 高額・削除・公開操作を人が承認したか

4. 回数、同時接続、トークン、累計金額が上限内か

プロンプトに「慎重に操作して」と書くだけでは、拒否を保証できません。AWS公式ブログでは、時系列ポリシーをAgentCore Gatewayで評価し、エージェントのコードや推論から独立させています。レート制限も同じGatewayで適用し、下流のツールやモデルへ届く前に止めます。

今回はAWS環境へ実装したとは断定しません。公開された公式仕様を照合し、導入前のテスト項目まで具体化しました。

1. 操作の順序を固定する

最初の境界は「何をしたか」ではなく「何をした後か」です。例えば返金エージェントなら、注文確認、返金可否の判定、返金実行の順序を守らせます。返金ツール単体に権限があっても、直前に注文を確認していなければ拒否します。

AWSの時系列ポリシーは、セッション内の行動履歴をtrajectoryとして扱います。Gatewayが現在の要求と過去の操作を照合するため、エージェント自身が履歴ストアやポリシーを変更できない設計です。

小規模な実装でも、次の状態をサーバー側へ持たせます。

  • セッションIDと利用者ID
  • 実行したツール名と時刻
  • 成功、失敗、拒否の結果
  • 次に許可できる操作
  • 確認結果の有効期限

「確認済み」は永続的な権限にしません。価格や在庫など変化する情報は、確認から5分など有効期限を決め、期限切れなら再確認させます。

2. 前の結果を次の入力へ引き継ぐ

AIエージェントは、前のツール出力を要約するときに値を取り違える可能性があります。顧客番号、送金先、ファイルパス、公開先URLは、自然言語の記憶に任せず機械的に照合します。

AWS公式ブログでは、先行ツールの出力と現在の引数が一致することをポリシーで要求する例が示されています。この考え方なら、顧客検索で返ったIDと異なるIDを送金ツールへ渡した場合に拒否できます。

実装時は、重要な値を次のように扱います。

1. 先行ツールの結果からIDを構造化データとして保存する

2. 次のツール要求に含まれるIDと完全一致で比較する

3. 不一致なら自動修正せず、拒否理由を記録する

4. 再試行時は先行ツールからやり直す

ファイル操作なら、検索結果の絶対パスをそのままエージェントへ返すのではなく、許可領域内のリソースIDへ変換する方が安全です。ローカルツールをつなぐ場合の情報最小化は、クラウドAIとPCをつなぐ6つの安全策でも整理しています。

3. 人の承認を行動履歴に残す

承認ボタンを表示しただけでは不十分です。誰が、何を、いつ承認したかを、実行要求と結び付けます。

次の操作は人の承認対象にします。

  • 外部への送金、購入、返金
  • 公開記事や本番設定の変更
  • ファイル、ユーザー、データベースの削除
  • 秘密情報を含む可能性があるデータ送信
  • 累計金額や件数が通常範囲を超える処理

承認イベントには、利用者、対象、金額または変更内容、期限、要求IDを含めます。承認後に金額や対象が変わった場合は、同じ承認を使い回さず再承認させます。

認証と承認は別物です。利用者がログイン済みでも、危険な操作を毎回許可する理由にはなりません。短期認証と権限分離はAIエージェント認証、APIキーを減らす設計を参照してください。

4. 回数と費用に上限を置く

正しい順序で動くエージェントでも、ループすれば費用と負荷が増えます。AWSのAgentCore Gatewayのレート制限では、OAuthのclaimまたはIAM identityを基準に、利用者単位で要求数、同時接続、トークン流量を制御できます。

上限は1種類ではなく、時間軸を分けます。

| 境界 | 例 | 防ぐこと |

|—|—:|—|

| 1分 | 20要求 | 短時間の暴走 |

| 同時 | 2接続 | 重複実行と下流の枯渇 |

| 1セッション | 30,000トークン | 長いループ |

| 1日 | 1,000円相当 | 気付きにくい累積費用 |

| 高リスク操作 | 3回 | 連続した購入や削除 |

数値は固定の推奨値ではありません。通常時の実測を取り、警告値と拒否値を分けます。拒否した要求を無限再試行しないよう、エージェントへ終了理由も返します。

速度、失敗、トークン量の計測方法はAIエージェントが遅い時に見る5項目につながります。

30分で作る拒否テスト

導入前に、正常系より先に次の拒否を確認します。

1. 確認ツールを飛ばして実行ツールを呼ぶ

2. 前のツールが返したIDを1文字変える

3. 承認後に金額または公開先を変える

4. 同じ要求IDを連続送信する

5. 1分上限と1日上限を意図的に超える

6. 拒否後にエージェントが自動再試行し続けないか見る

合格条件は、危険な要求が実行されず、拒否理由、利用者、セッション、要求IDがログから追えることです。本文やトークンなどの秘密値を監査ログへ残さない点も確認します。

今日から行う3つの作業

1. 現在のAI自動化から、金銭・削除・公開に関わる操作を1つ選ぶ

2. その操作の前提手順、引き継ぐ値、承認者、上限を1枚に書く

3. 順序違反、値の改変、上限超過を再現し、すべて拒否されるか試す

最初から全ツールへ適用する必要はありません。最も事故の影響が大きい1操作で拒否テストを通し、同じ型を横展開します。

まとめ

AIエージェントの安全性は、1回の権限確認だけでは作れません。操作順序、値の一貫性、人の承認、利用上限を行動履歴と結び付け、エージェントの外側で強制する必要があります。

AgentCore固有の機能を使わない場合でも、この4境界はAPI Gateway、ワークフローエンジン、監査ストアで再現できます。まず危険な1操作を選び、「正しく動いた」ではなく「間違った動きを拒否できた」で本番可否を判断してください。

関連記事

著者情報

しろのあ。AIとCodexを使ったWordPress、note、アプリ制作、ゲームサーバー運用の自動化を実践し、確認できた手順と判断材料を記録しています。

出典

1. Securing AI agents with temporal policies in Amazon Bedrock AgentCore / AWS Machine Learning Blog

2. Configure rate limits for AI traffic on AgentCore gateway / AWS Machine Learning Blog

3. Control agent behaviors and cost beyond a single action / AWS Machine Learning Blog