はじめに——「防ぐ」でも「直す」でもない、”暴走している最中に止める”という空白
これまでのAIセキュリティ記事では、プロンプトインジェクションやツールポイズニング、モデル抽出といった「侵入・攻撃を事前に防ぐ」ための多層防御を中心に扱ってきました。また、目標ハイジャックの記事では「異常を検知する」ことを、レジリエンス／チェックポイントの記事では「事業を継続し状態を復旧する」ことを扱いました。しかし2026年、これらのあいだにぽっかりと空いた層が問題になっています。それは、防御をすり抜けた／内部で暴走したエージェントを、被害が広がりきる前に”止める・囲い込む・巻き戻す”という、インシデント最中（さなか）の制御レイヤーです。
2026年、自律実行を前提としたエージェントが本番業務に投入され始めました。承認を挟まず、ツールを呼び、ファイルを書き換え、APIを叩き、外部へメールを送る——この自律性こそが価値であると同時に、暴走したときの被害の伝播速度を桁違いに上げています。人間の運用者が「おかしい」と気づいてダッシュボードを開くころには、エージェントはすでに数百回のアクションを実行し終えているかもしれません。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年、障害の封じ込めに携わってきました。大規模ネットワークが不安定化したとき、私たちがまずやるのは「原因究明」ではありません。まず問題区間を切り離し（アイソレーション）、影響範囲を止血する——原因を突き止めるのはその後です。この「事故対応の順序」が、そのままAIエージェントの暴走対策に転用できる、というのが本記事の核心です。
本稿は攻撃対策（＝敵をどう防ぐか）ではなく、“制御不能への備え”（＝味方であるはずのエージェントが制御を外れたとき、どう止めるか）という新しい軸に特化します。既に公開済みの「インシデントレスポンス＆フォレンジック（事後）」記事の手前、つまり火が出てから鎮火するまでの数分〜数十分を設計します。想定読者は、自律エージェントを本番投入している（あるいは投入を検討している）情シス・SRE・CISO、そしてエージェント基盤を設計するアーキテクトの方々です。
前提——「暴走」には4つの起こり方がある
「エージェントが暴走する」と一口に言っても、止め方を設計するには原因を分けて捉える必要があります。止血の当て方が変わるからです。
① 乗っ取り（外部起因）
プロンプトインジェクションやツールポイズニングで、エージェントの目標そのものが攻撃者に書き換えられるケースです。エージェントは「正常に」動作しているつもりで、攻撃者の意図を実行します。検知記事が扱う「目標ハイジャック」がこれにあたります。
② 自己暴走（内部起因）
攻撃者はいません。プランニングのループが破綻し、同じ操作を無限に繰り返す、誤った前提のまま大量のリソースを消費する、目標を過剰に最適化して想定外の副作用を出す——いわゆる報酬ハッキングや無限ループです。悪意がないぶん、既存のセキュリティ検知には引っかかりにくいのが厄介です。
③ 権限の踏み外し（設計起因）
与えた権限が広すぎたために、本来触るべきでない本番データベースや決済APIに、正規の権限で到達してしまうケースです。Confused Deputy（混乱した代理人）問題もここに含まれます。エージェント自体は正しく動いていても、被害が生じます。
④ 連鎖（マルチエージェント起因）
1体のエージェントの誤りが、それを信頼する別のエージェントの入力になり、増幅しながら伝播するケースです。1つのサブエージェントの幻覚が、オーケストレーターを経由してシステム全体の判断を汚染します。ネットワークでいうブロードキャストストームに近い構図です。
4つを整理すると、必要な”止め方”が見えてきます。
| 暴走の型 | 起点 | 気づきにくさ | 特に効く封じ込め |
|---|---|---|---|
| ① 乗っ取り | 外部攻撃 | 中（検知層が拾う） | 権限サーキットブレーカー・即時停止 |
| ② 自己暴走 | 内部のロジック破綻 | 高（悪意がない） | レート／支出遮断・ループ検知 |
| ③ 権限踏み外し | 過剰な権限設計 | 高（正規の権限） | ブラストラジウス分離・最小権限 |
| ④ 連鎖 | エージェント間伝播 | 非常に高い | 区画化・伝播遮断・段階的自律 |
標準フレームワークでの位置づけ
この「止める・囲い込む」というテーマは、業界標準フレームワークにも根拠があります。社内説明や監査対応の裏づけとして押さえておくと効きます。
- OWASP LLM Top 10（2025年版）： エージェントの過剰な行動権限は LLM06:2025 Excessive Agency（過剰な代理権） が正面から扱います。権限・機能・自律性を絞り、人間の承認ゲートを挟むことを推奨しています。無限ループやリソース枯渇は LLM10:2025 Unbounded Consumption（無制限な消費） に対応します。
- MITRE ATLAS： エージェントがツール経由で意図しない操作を実行する経路は、AIシステムへの敵対的脅威ランドスケープとして整理されています。封じ込めは、検知（Detect）と対応（Respond）の連結点に位置づけられます。
- NIST AI RMF： 「MANAGE」機能のなかで、AIリスクのインシデント対応と復旧の手続きを事前に用意しておくことを求めています。キルスイッチはその具体化です。
つまり本記事のテーマは「特殊な心配」ではなく、2025年以降のAIガバナンス標準が求める「止められる設計（controllability）」の実装論です。
設計原則——「止める」は事故が起きてから考えても遅い
ネットワークの現場で骨身に染みているのは、止血装置は平時に仕込んでおかなければ、有事には使えないという事実です。障害の最中に「どこを切れば止まるか」を探し始めた時点で、もう手遅れです。AIエージェントの封じ込めも同じで、以下の4原則をアーキテクチャに最初から埋め込むことが前提になります。
- 止める権限は、エージェントの外側に置く。 エージェント自身に「自分を止める」判断を委ねてはいけません。停止スイッチは、エージェントが操作できない独立したコントロールプレーンに置きます（電力系統のブレーカーが、負荷側から操作できないのと同じ）。
- フェイルセーフ（安全側に倒れる）を既定にする。 制御を失ったとき、エージェントは「動き続ける」のではなく「止まる」方向に倒れるべきです。ハートビートが途切れたら自動停止、承認応答がなければ実行しない、が既定値です。
- 被害の上限を、事前に数値で決めておく。 「1時間あたりの支出上限」「外部送信の回数上限」「書き込み可能な範囲」を、実行前にハードリミットとして設定します。上限は”アラート”ではなく”遮断”に結線します。
- 段階的に止める。全か無かにしない。 いきなり全停止は事業影響が大きすぎます。「速度を落とす→権限を剥がす→隔離する→全停止する」という階段を用意し、状況に応じた最小限の介入で止めます。
以降、これらを4つの封じ込めレイヤーとして実装に落とします。入口から順に、権限・消費・被害範囲・自律度の4面で”止める・囲い込む”を重ねます。
第1の封じ込め層：権限サーキットブレーカー——「止める」を独立させる
最初の層は、エージェントの行動権限そのものを、外から瞬時に落とせるブレーカーです。電力系統のサーキットブレーカーが、異常電流を検知して回路を物理的に開くように、エージェントの権限を”開放”して無力化します。
キルスイッチとサーキットブレーカーは別物
この2つはしばしば混同されますが、役割が違います。
- キルスイッチ（Kill Switch）： 人間が手動で引く全停止レバー。「今すぐ全部止めろ」を、迷わず・確実に・一発で実行できることが命です。UIの奥に隠さず、権限を持つ全員が押せる場所に置きます。
- サーキットブレーカー（Circuit Breaker）： 条件を満たしたら自動で開く遮断器。エラー率・異常アクション・レート超過といった閾値を超えたら、人間を待たずに該当機能を落とします。マイクロサービスのサーキットブレーカーパターンのエージェント版です。
両方が要ります。自動ブレーカーは人間の反応速度（分〜十分）より速く止められ、手動キルスイッチは「自動では判断できないが、明らかにおかしい」状況を人間が止められます。
実装の要点
- 権限を実行時に取り消せる構造にする： 権限を起動時に固定するのではなく、1アクションごとに外部のポリシーエンジンへ照会する（call-time authorization）。ブレーカーが開いていれば、その瞬間から全アクションが拒否されます。トークンやセッションの失効を待つ必要がありません。
- 停止は”取り消し”であって”お願い”ではない： エージェントに「止まって」と指示するのではなく、ツール実行のゲート側で拒否します。乗っ取られたエージェントは自分から止まらないため、止血は必ず外側のレイヤーで行います。
- ブレーカーの粒度を分ける： 「全エージェント」「特定エージェント」「特定ツール（例：メール送信だけ）」「特定リソース（例：本番DBへの書き込みだけ）」を個別に開けるようにします。1つの機能だけが暴走しているとき、全停止せずにその機能だけ落とせます。
- フェイルクローズ設計： ポリシーエンジンへの照会が失敗（タイムアウト・障害）したら、”許可”ではなく”拒否”に倒します。制御が確認できないなら動かさない、が安全側です。
| 比較軸 | キルスイッチ | サーキットブレーカー |
|---|---|---|
| 作動主体 | 人間（手動） | システム（自動） |
| 速度 | 人間の判断速度 | ミリ秒〜秒 |
| 粒度 | 全停止が基本 | 機能・リソース単位 |
| 得意な状況 | 自動判定できない異常 | 閾値で捉えられる異常 |
| 誤作動リスク | 低い（人が判断） | あり（過検知）→段階設計で緩和 |
第2の封じ込め層：支出／レート遮断——「消費」に物理的な天井をつける
自己暴走（②）の被害は、多くの場合リソース消費として現れます。無限ループで同じAPIを叩き続ける、大量のトークンを焼き続ける、外部にメールを送り続ける——「Denial of Wallet（財布への攻撃）」とも呼ばれる、コスト面での自傷です。ここにはアラートではなく遮断を置きます。
「通知」で止まると思ってはいけない
コスト超過を”通知”しても、通知を人間が見て対応するまでのあいだ、エージェントは走り続けます。ネットワークでトラフィックが跳ねたとき、アラートメールを待たずにポリサー（policer）が物理的にレートを削るのと同じで、閾値は自動遮断に直結させなければ意味がありません。
遮断すべき”消費”の種類
- 金銭： LLM API・外部API・クラウドリソースの累積課金。エージェント単位・タスク単位でハードな支出上限を設定し、超過で即停止。
- アクション回数： ツール呼び出し・外部書き込み・メール送信などの回数。単位時間あたりと累積の両方に上限を置く。
- ループ： 同一・類似アクションの反復。近接重複したツール呼び出しが一定回数を超えたら、ループとみなして停止（プランニング破綻の典型シグナル）。
- 時間： 1タスクの実行時間。想定を超えて走り続けるタスクは、デッドマンズスイッチで打ち切る。
実装の要点
- 「不可逆な操作」ほど上限を厳しく： 読み取りは緩く、書き込み・送信・決済・削除といった取り消せない操作ほど、低い上限と追加承認を課します。被害の重さでレートを差別化します。
- 予算はエージェントの外で管理する： 残予算のカウンタをエージェントに持たせると、暴走時に自己申告が信用できません。外部のメータリング層で計上・遮断します。
- デッドマンズスイッチ： エージェントが定期的にハートビートを送り、途切れたら（＝制御喪失の疑い）自動的にリソースアクセスを閉じます。フェイルセーフの具体化です。
第3の封じ込め層：ブラストラジウス分離——「被害範囲」を設計で囲い込む
止めきれずにアクションが実行されてしまっても、その1発が届く範囲（ブラストラジウス＝爆風半径）が小さければ、被害は局所で収まります。これは事故が起きる前の”区画化”の設計であり、封じ込めの中でもっとも効果が持続する層です。原発の格納容器や、船の水密隔壁と同じ発想です。
ネットワーク・セグメンテーションのAI版
ネットワーク設計では、1つのセグメントが侵害されても全体に波及しないよう、VLANやマイクロセグメンテーションで区画を切ります。エージェントも同じで、1体の暴走が到達できる範囲を、権限・データ・ネットワークの3面で事前に区切ります。
- 最小権限（least privilege）： エージェントには、そのタスクに必要な最小限のスコープだけを与えます。「念のため広めに」は、暴走時の爆風半径をそのまま広げます。
- 環境の分離： 本番と検証、機密データと一般データを、エージェントから見て別の実行環境・別の認証境界に置きます。1つの環境の暴走が、別の環境に届かないようにします。
- エグレス制御： エージェントが到達できる外部の宛先を許可リストで絞ります。暴走しても、データを未知の外部へ持ち出せない・未知のAPIを叩けない状態にします。
- 使い捨て実行環境： エージェントのアクションを、タスクごとに破棄されるサンドボックス／エフェメラルな環境で実行し、状態を持ち越さない。汚染を1タスクに閉じ込めます。
不可逆性を減らす設計
封じ込めの最後の砦は、「取り消せる」ようにしておくことです。暴走を止めても、実行済みのアクションが不可逆なら被害は残ります。
- ステージングと確定の分離： エージェントの出力（メール・変更・注文）を、いきなり確定せず下書き／保留キューに置き、確定は別ゲート（自動遅延 or 人間承認）を通す。暴走時は保留分を破棄すれば被害ゼロ。
- ソフトデリート・可逆操作の優先： 削除は物理削除でなく論理削除、上書きでなくバージョン追記にして、巻き戻せる状態を保つ。
- チェックポイントとロールバック： 状態復旧はレジリエンス記事の領域ですが、封じ込めの観点では「止めた地点から、汚染前の状態へ巻き戻せる」導線を用意しておくことが重要です。止めるだけでなく、巻き戻すまでが封じ込めです。
第4の封じ込め層：段階的自律——「そもそも一気に走らせない」
ここまでは「走り出したものを止める」層でした。最後の層は発想を変え、自律度そのものを、信頼が積み上がるにつれて段階的に開放するという予防的封じ込めです。全開の自律をいきなり与えなければ、暴走の初速そのものを抑えられます。
Human-in-the-loop から Human-on-the-loop へ、段階的に
- レベル0：提案のみ： エージェントは案を出すだけ。実行は人間。導入初期や高リスク業務の既定。
- レベル1：承認付き実行（Human-in-the-loop）： 各アクションを人間が承認してから実行。不可逆な操作は常にこのレベル以上に固定。
- レベル2：監督付き自律（Human-on-the-loop）： エージェントは自律実行するが、人間が並走監視し、いつでも介入・停止できる。
- レベル3：完全自律： 定義された安全な範囲内では人間の介在なしに実行。ただしサーキットブレーカーと支出遮断は常時作動。
重要なのは、自律度を”操作の不可逆性 × 実績の信頼度”で決めることです。読み取りや下書き生成はレベル3でよくても、決済・削除・外部送信はレベル1に固定する、といった操作別の自律ポリシーを設けます。新しいエージェントやモデル更新直後は一段下げ、安定稼働の実績に応じて上げる——ネットワーク機器を本番投入する前にカナリアで様子を見るのと同じ運用です。
| 自律レベル | 人間の関与 | 向く操作 | 常時併設する封じ込め |
|---|---|---|---|
| L0 提案のみ | 実行は人間 | 導入初期・最高リスク | — |
| L1 承認付き | 都度承認 | 決済・削除・外部送信 | ブレーカー＋監査 |
| L2 監督付き | 並走監視・随時介入 | 反復的な業務処理 | ブレーカー＋レート遮断＋キルスイッチ |
| L3 完全自律 | 事後レビュー | 低リスク・可逆な処理 | ブレーカー＋レート遮断＋ブラストラジウス分離 |
止める→囲う→巻き戻すのインシデント連携
4つの封じ込め層は、単体ではなく1本のインシデントフローとしてつながって初めて機能します。ネットワーク障害対応の「隔離→止血→復旧→原因究明」を、エージェント運用に写します。
- 検知（Detect）： 目標ハイジャック検知・異常アクション・レート超過・ループ検知が、暴走の疑いをスコアリングして発報。
- 止める（Stop）： サーキットブレーカーが該当機能を自動遮断。明確な暴走や人間の判断が必要なケースはキルスイッチで全停止。
- 囲う（Contain）： 権限を剥がし、エグレスを閉じ、実行環境を隔離。ブラストラジウス分離で汚染を局所化。
- 巻き戻す（Roll back）： 保留キューの破棄、論理削除の復元、チェックポイントへのロールバックで、汚染前の状態へ戻す。
- 引き継ぐ（Hand off）： ここから先はIR＆フォレンジック（事後）の領域。何が起きたかを改ざん不能なログで再現し、原因究明・再発防止へ。
本記事が埋めるのは、この「止める→囲う→巻き戻す」の3ステップです。検知（拾う）とフォレンジック（調べる）のあいだにある”最中の制御”を、平時に設計しておくことが、自律エージェント時代の運用の土台になります。
多層封じ込めチェックリスト
| 層 | 対策 | 主に効く暴走の型 |
|---|---|---|
| 権限 | 手動キルスイッチ（全停止・全員が押せる） | ①乗っ取り・全般 |
| 権限 | 自動サーキットブレーカー（機能・リソース単位） | ①②・閾値で捉えられる異常 |
| 権限 | call-time認可・フェイルクローズ | ①③ |
| 消費 | 支出／アクション回数のハード遮断 | ②自己暴走 |
| 消費 | ループ検知・デッドマンズスイッチ | ② |
| 範囲 | 最小権限・環境分離・エグレス制御 | ③権限踏み外し・④連鎖 |
| 範囲 | 保留キュー・論理削除・ロールバック導線 | 全般（不可逆性の低減） |
| 自律 | 操作別の段階的自律（不可逆操作はL1固定） | 全般（初速の抑制） |
| 連携 | 止める→囲う→巻き戻す→IRへ引き継ぐ導線 | 全般（事後対応） |
よくある質問（Q&A）
Q1. キルスイッチとサーキットブレーカー、どちらか一方でよいのでは？
両方必要です。サーキットブレーカーは閾値で捉えられる異常を人間より速く自動遮断しますが、閾値で表現できない「明らかにおかしい」状況は取りこぼします。キルスイッチはそこを人間の判断で止めますが、人間の反応速度には限界があります。速い自動遮断と、賢い手動停止は役割が違い、補完関係にあります。
Q2. エージェントに「異常を感じたら自分で止まって」と指示すればよいのでは？
それだけでは危険です。乗っ取られた（①）エージェントや、ロジックが破綻した（②）エージェントは、自分が異常だと認識できません。自己申告に依存した停止は、いちばん止めたい状況でいちばん効きません。止血装置は必ず、エージェントが操作できない外側のレイヤーに置いてください。エージェント内の自己停止は”補助”であって”主”ではありません。
Q3. サーキットブレーカーの誤作動で、正常な業務まで止まりませんか？
だからこそ段階的な封じ込めが重要です。いきなり全停止せず、「速度を落とす→特定機能だけ落とす→権限を剥がす→全停止」という階段を設計し、状況に応じた最小限の介入で止めます。また、ブレーカーの粒度を機能・リソース単位に分けておけば、暴走している1機能だけを落として、他は動かし続けられます。過検知の影響は”全停止”ではなく”部分緩和”に留められます。
Q4. これは既存の「検知」記事や「レジリエンス」記事と何が違うのですか？
時間軸上の担当が違います。検知は「暴走に気づく（拾う）」、本記事の封じ込めは「気づいた暴走を止めて囲って巻き戻す（最中の制御）」、レジリエンスは「事業を継続し状態を復旧する」、IR＆フォレンジックは「事後に原因を究明する（調べる）」です。本記事は検知とフォレンジックのあいだにある、これまで手薄だった”止血”の層を埋めます。
Q5. 小規模なエージェント導入でも、ここまで必要ですか？
規模より操作の不可逆性で判断してください。1体でも、決済・削除・外部送信といった取り消せない操作を自律実行させるなら、最低限の支出遮断・キルスイッチ・不可逆操作の承認ゲートは必須です。逆に、読み取りと下書き生成しかしないエージェントなら、まずはブラストラジウス分離（最小権限・エグレス制御）から始めれば十分なことが多いです。全部を一度に入れる必要はなく、不可逆な操作から順に囲うのが現実的です。
まとめ——「止められること」を、価値と同じ重さで設計する
自律エージェントの議論は、長らく「何ができるか（能力）」と「どう防ぐか（事前防御）」に集中してきました。しかし2026年、エージェントが自律実行を前提に業務投入されるようになった今、「制御を外れたとき、どう止めるか」が同じ重さで問われています。要点は3つです。
1. 止血装置は外側に、平時に仕込む。 エージェント自身に停止を委ねてはいけません。キルスイッチとサーキットブレーカーを、エージェントが操作できない独立レイヤーに、有事の前に用意します。
2. 全か無かにせず、段階的に止める。 速度を落とす・機能を落とす・権限を剥がす・全停止する——状況に応じた最小限の介入で止められる階段を設計します。これはNOCのインシデント対応そのものの発想です。
3. 止めるだけでなく、囲って巻き戻すまでが封じ込め。 ブラストラジウス分離で被害を局所化し、保留キューやロールバック導線で不可逆性を減らす。「止める→囲う→巻き戻す」の3点セットで初めて、被害範囲は最小化されます。
「自律させない」という選択肢が現実的でなくなった以上、「いつでも止められる・被害を囲える・巻き戻せる」を前提に、権限・消費・範囲・自律度の4層で封じ込める——これが、暴走・乗っ取りの瞬間に事業を守るための基本姿勢です。エージェントに与えるべきは、大きな自律性と、それを上回る”止められる保証”の両方です。
参考リンク
- OWASP「LLM06:2025 Excessive Agency」
- OWASP「LLM10:2025 Unbounded Consumption」
- OWASP Top 10 for LLM Applications（2025年版）
- MITRE ATLAS（AIシステム向け敵対的脅威ランドスケープ）
- NIST AI Risk Management Framework（AI RMF）
免責事項： 本記事は2026年8月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の封じ込め実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。
コメント