はじめに——「サンドボックスで実行すれば安全」という前提そのものを疑う
これまでのAIセキュリティ記事では、Claude Code・Cowork・OpenClaw系のエージェントにコード実行やファイル操作を許すとき、「サンドボックス（隔離環境）の中で実行すれば安全」を前提に議論を組み立ててきました。ツール呼び出しの乗っ取り、設定ファイル経由の攻撃、逆シリアライゼーション——いずれも「隔離された環境に閉じ込めておけば、最悪でもその中で完結する」という暗黙の安心感が土台にありました。
しかし2026年、その土台そのものが攻撃対象になっています。エージェントがコード実行を持つのが標準になった今、攻撃者が狙うのは隔離環境の内側で悪さをすることではなく、隔離環境そのものを破って「母艦」（ホスト・他のコンテナ・社内ネットワーク）に到達することです。サンドボックスは万能の壁ではなく、強度の異なる複数のグレードがある「設計物」であり、選び方と組み方を誤れば簡単に踏み越えられます。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年、セグメンテーション設計とトラフィックの封じ込めに携わってきました。本記事の核心は、そのネットワーク分離・DMZ設計の発想が、そのままエージェントのサンドボックス設計に転用できるという点にあります。「境界を1枚引いたら安全」ではなく、「境界は破られる前提で、破られた後の被害をどう封じ込めるか」——このNOC/インフラ的な多層防御の視点で、サンドボックス脱出への守り方を実装の目線から整理します。
想定読者は、AIエージェントに自動でコードを書かせ・実行させている開発チーム、SaaSにコード実行機能を組み込んでいる事業者、そして社内でエージェント基盤を運用する情シス・CISOの方々です。
前提——「サンドボックス脱出」とは何を破る攻撃か
「サンドボックスから脱出する」と一口に言っても、破られる境界は一つではありません。エージェントが与えられた実行環境から、どの層をどう越えて母艦に近づくか——防御策が層ごとに異なるため、まずここを分けて理解することが出発点です。
脱出1：コンテナからホストへの脱出（Escape to Host）
最も古典的かつ深刻な脱出です。エージェントが実行するコードが、コンテナランタイム（Docker/runc）やカーネルの脆弱性、あるいは過剰な権限設定（特権コンテナ、危険なケイパビリティ付与、ホストのDockerソケットのマウント）を突いて、コンテナの外＝ホストOS上でコマンドを実行できる状態に至る手口です。ホストを取られれば、同じホスト上で動く他の顧客のコンテナ・シークレット・ネットワークすべてが射程に入ります。MITREの標準分類では、この「Escape to Host」はATT&CKのT1611として定義され、2026年2月のMITRE ATLAS更新でエージェント特有の実行・永続化テクニックとして明示的に取り込まれました。
脱出2：共有ボリューム・マウント経由の汚染
コンテナのカーネルを破らなくても、ホストや他コンテナと共有しているファイルシステムが抜け道になります。作業ディレクトリ、キャッシュ、共有ボリュームにエージェントが書き込めるとき、そこへ悪意ある実行ファイル・設定ファイル・シンボリックリンクを仕込み、ホスト側や別プロセスがそれを読む・実行するタイミングで境界を越えます。「隔離されたコンテナの中」に見えても、書き込み先が外と繋がっていれば、それは隔離の穴です。
脱出3：ネットワーク経由の横移動（Lateral Movement）
カーネルもファイルシステムも破らず、ネットワークの出口（エグレス）から抜ける経路です。サンドボックス内から社内メタデータサーバー（クラウドのインスタンスメタデータエンドポイント）、内部API、データベース、他のマイクロサービスへ到達できてしまえば、コンテナを破らなくても母艦の資産に手が届きます。クラウドのメタデータエンドポイントから一時認証情報を抜き取る手口は典型例で、これは「コンテナは無傷なのに、実質的に脱出が成立している」状態です。
3つの脱出を整理すると次のようになります。
| 脱出経路 | 破る境界 | 主な原因 | 逆に効く防御の軸 |
|---|---|---|---|
| ホストへの脱出 | カーネル／ランタイム | 特権付与・危険なマウント・ランタイム脆弱性 | 強い隔離（gVisor/microVM）・最小権限 |
| 共有ボリューム汚染 | ファイルシステム境界 | 書き込み可能な共有マウント・シンボリックリンク | 読み取り専用・使い捨て環境・マウント最小化 |
| ネットワーク横移動 | ネットワーク境界 | 無制限のエグレス・メタデータ到達 | エグレス制御・ネットワーク分離 |
標準フレームワークでの位置づけ
これらは「特殊な懸念」ではなく、業界標準のフレームワークが正面から扱う中核リスクです。社内説明や監査対応の根拠として押さえておくと効きます。
- MITRE ATT&CK / ATLAS： コンテナからの脱出は T1611（Escape to Host） に対応します。2026年2月のMITRE ATLAS更新では、エージェントがコード実行を通じてサンドボックスを破り母艦に到達する一連の攻撃が、エージェント特有のテクニックとして拡充されました。推論・実行環境への到達自体は ML Model Access のタクティクスに位置づけられます。
- OWASP LLM Top 10（2025年版）： エージェントに過剰な権限・実行能力を与えることに起因する被害は LLM06:2025 Excessive Agency（過剰なエージェンシー）、実行結果の出力を適切に扱わないことによる被害は LLM05:2025 Improper Output Handling が対応します。サンドボックス脱出は、これらが「実行環境の設計不備」と結びついたときに現実化します。
なぜ「Dockerで隔離した」だけでは足りないのか
多くのチームが「エージェントのコードはDockerコンテナで動かしているから隔離されている」と考えています。しかし2026年の共通認識は明確です——LLMが生成したコードやユーザー由来のコードは「敵対的コード」として扱うべきであり、共有カーネル型のコンテナ（Docker/runc）はその隔離には力不足だということです。
理由はシンプルで、通常のコンテナはホストOSのカーネルを共有しているからです。コンテナはあくまでプロセスの名前空間とリソースを分離する仕組みであり、仮想マシンのような強いハードウェア境界を持ちません。カーネルに脆弱性が一つあれば、あるいは権限設定を一つ誤れば、その共有カーネルを踏み台にホストへ抜けられます。これは「壁を1枚立てた」状態であって、「別棟に隔離した」状態ではありません。
ネットワークで例えるなら、VLANでセグメントを分けただけで「物理的に別ネットワークだ」と安心するのに似ています。設定ミスや実装の穴一つでセグメントは越えられる——だからこそインフラの世界では、重要度に応じて分離の強度を変え（VLAN／物理分離／エアギャップ）、境界を多重化してきました。サンドボックスもまったく同じで、守る対象の危険度に応じて隔離強度を選ぶという発想が要になります。
第1の防御層：隔離強度を選ぶ——コンテナ強化から使い捨てmicroVMまで
サンドボックス脱出対策の土台は、そもそも破られにくい隔離を選ぶことです。隔離技術には強度と運用コストのトレードオフがあり、エージェントに実行させるコードの信頼度に応じて選び分けます。
隔離強度の段階
| 隔離方式 | 境界の強さ | 特徴 | 向く用途 |
|---|---|---|---|
| 素のコンテナ（Docker/runc） | 弱（共有カーネル） | 軽量・高速だがカーネルを共有 | 信頼できる自社コードのみ |
| コンテナ強化（rootless・seccomp・ケイパビリティ削減） | 中 | 共有カーネルのまま攻撃面を削る | 低リスクの補助実行 |
| gVisor | 強 | ユーザー空間でシステムコールを代理（Sentry）、VMほどの重さなし | I/Oの軽い汎用エージェント実行 |
| microVM（Firecracker/Kata） | 最強（ハードウェア境界） | 専用カーネルで隔離、起動〜125ms級 | 敵対的コードの本番実行 |
gVisorは、コンテナ内のプロセスが叩くシステムコールをホストカーネルに直接通さず、ユーザー空間の「Sentry」というプロセスが代理して受け止める方式です。ホストカーネルへの攻撃面を大きく削れる一方、フルVMほどの重さはありません。FirecrackerやKata ContainersのようなmicroVMは、各サンドボックスに軽量な専用カーネルを与える方式で、ハードウェアの境界がカーネルベースの攻撃をまるごと無効化します。Firecrackerは起動が125ミリ秒級・オーバーヘッドも小さく、「使い捨て前提で毎回作り直す」運用と相性が良いのが特徴です。
コンテナを使うなら「強化」は必須
コスト上どうしても素のコンテナを使う場面でも、次の強化は最低ラインです。すべて「万一の脱出を難しくする」ための攻撃面削減です。
- 非root実行（rootless / USER指定）： コンテナ内でroot権限を持たせない。特権昇格の起点を潰す。
- ケイパビリティの削減（cap-drop ALL）： 必要な権限だけを個別に付与し、危険なケイパビリティ（
CAP_SYS_ADMIN等）は与えない。 - seccomp / AppArmor プロファイル： 発行できるシステムコールを絞り、カーネル攻撃面を縮める。
- 特権コンテナ・危険なマウントの禁止：
--privileged、ホストのDockerソケット（/var/run/docker.sock）のマウント、ホストルートのマウントは厳禁。これらは脱出を「設定一つで招き入れる」典型です。 - 読み取り専用ルートFS： ファイルシステムを原則読み取り専用にし、書き込みは限定した一時領域のみに許す。
第2の防御層：エグレス制御——「出口」を締めて横移動を止める
カーネルを破られなくても、ネットワークの出口が開いていれば母艦に届きます。ここはNOC/TAC的な発想がそのまま効く領域です。ネットワーク設計の鉄則「デフォルト拒否・必要な通信だけ許可（default-deny）」を、サンドボックスのエグレスにも適用します。
エグレスをデフォルト拒否にする
サンドボックスからの外向き通信は、原則すべて遮断し、業務上必要な宛先だけを明示的に許可（アローリスト）します。「とりあえず全部通し、危険なものだけ塞ぐ」ブロックリスト方式は、抜け道を数え切れず必ず漏れます。ネットワークの世界でファイアウォールを常にdefault-denyで設計するのと同じ理由です。
特に塞ぐべき宛先
- クラウドのメタデータエンドポイント： インスタンスメタデータサービス（例：
169.254.169.254）への到達は、一時認証情報の窃取に直結します。サンドボックスからは必ず遮断します。 - 内部ネットワーク・社内API・DB： サンドボックスを社内セグメントから隔離し、内部サービスへ直接到達させない。必要な連携は認証付きの限定エンドポイント経由に絞る。
- 任意の外部ホスト： データ持ち出し（エクスフィル）や外部C2への通信を防ぐため、外向きは許可した宛先だけに限定する。
これはネットワークのマイクロセグメンテーションそのものです。「サンドボックスは孤島であるべき」という前提を、ネットワーク層で物理的に担保します。
第3の防御層：実行前ポリシー検査——「何を実行しようとしているか」を止める
隔離とエグレス制御が「破られた後の被害を抑える」防御だとすれば、実行前ポリシー検査は「危険な実行を始めさせない」入口の防御です。エージェントがコマンドやコードを実行する直前に、ポリシーエンジンで是非を判定します。
- 危険操作のブロック： ネットワーク設定の変更、権限昇格、マウント操作、パッケージの野良インストール、既知の脱出に使われるコマンド列などを、実行前に検出して拒否する。
- 許可リスト方式のツール実行： エージェントが呼べるコマンド・ツールを列挙して限定し、それ以外は既定で拒否する（Excessive Agencyの直接的な緩和策）。
- Human-in-the-Loopの分岐： 破壊的・不可逆な操作（本番への書き込み、外部送信、削除）は自動実行させず、人間の承認を挟む。
- 入力の汚染チェック： 実行対象のコードや引数に、外部から注入されたプロンプト・エスケープ列が混ざっていないかを検査する。
ポイントは、この検査をエージェント自身に判断させないことです。実行するエージェントとは分離した、独立したポリシー層に置きます。判定者と実行者を分けるのは、評価レイヤー汚染を防ぐ基本設計であり、ここでも「分離」が効きます。
第4の防御層：使い捨て環境（Ephemeral Sandbox）——脱出しても「持ち帰れない」設計
最後の層は、サンドボックスを1タスクごとに作って捨てる使い捨て設計です。脱出や汚染が起きても、環境が短命であれば攻撃者は足場を維持できません。永続化（persistence）を根本から封じる、最も効果的な運用です。
- タスク単位で生成・破棄： エージェントのセッションやタスクごとに新しいサンドボックスを立ち上げ、終了時に完全破棄する。前のタスクの汚染を次に持ち越さない。
- 状態を持たせない： サンドボックス内に認証情報・永続データ・鍵を置かない。必要な資格情報は短命トークンで都度払い出し、環境と一緒に消えるようにする。
- スナップショットからの復元： Firecrackerのスナップショット復元のように、クリーンな初期状態を高速に復元できる仕組みを使えば、使い捨てのコストを抑えつつ毎回まっさらから始められる。
- 書き込みは一時領域に閉じる： エージェントの書き込みを使い捨ての一時ボリュームに限定し、ホストや共有ストレージへ痕跡を残さない。
使い捨て環境は、共有ボリューム汚染（脱出2）と永続化の両方に同時に効きます。「壊されてもいい前提の環境を、壊れたら捨てる」——インフラでいうイミュータブル（不変）インフラの発想を、エージェント実行に持ち込む形です。
多層防御チェックリスト
| 層 | 対策 | 主に効く脱出 |
|---|---|---|
| 隔離 | 敵対的コードはmicroVM（Firecracker/Kata）かgVisorで実行 | ホストへの脱出 |
| 隔離 | コンテナ強化（非root・cap-drop・seccomp・特権/危険マウント禁止） | ホストへの脱出 |
| ネットワーク | エグレスはdefault-deny＋アローリスト | ネットワーク横移動 |
| ネットワーク | メタデータエンドポイント・内部網からの分離 | ネットワーク横移動 |
| 実行前 | ポリシーエンジンで危険操作をブロック（独立層） | ホストへの脱出・全般 |
| 実行前 | ツール許可リスト＋破壊的操作のHuman-in-the-Loop | 全般 |
| ファイル | 読み取り専用FS・共有マウント最小化 | 共有ボリューム汚染 |
| 運用 | タスク単位の使い捨て環境・状態レス・短命トークン | 共有ボリューム汚染・永続化 |
| 運用 | 実行ログ・脱出兆候の監査（改ざん不能ログ） | 全般（事後対応） |
よくある質問（Q&A）
Q1. Dockerコンテナで実行していれば、サンドボックス脱出は防げますか？
不十分です。素のDockerコンテナはホストOSのカーネルを共有しており、カーネルの脆弱性や権限設定のミス一つでホストへ抜けられます。LLMが生成したコードやユーザー由来のコードは敵対的コードとして扱い、本番ではgVisorやFirecracker/Kataのような、より強い隔離の上で実行するのが2026年の推奨です。
Q2. gVisorとFirecracker（microVM）、どちらを選ぶべきですか？
扱うコードの危険度と性能要件で決めます。gVisorはユーザー空間でシステムコールを代理して攻撃面を削る方式で、フルVMより軽くI/Oの軽い汎用実行に向きます。Firecracker/Kataはハードウェア境界を持つmicroVMで、隔離は最強です。真に信頼できない敵対的コードを本番で実行するならmicroVMが基本、性能や密度を優先しつつ相応の隔離が欲しいならgVisor、という切り分けが目安です。
Q3. エグレス（外向き通信）はどこまで絞るべきですか？
原則すべて拒否（default-deny）し、業務上必要な宛先だけを明示的に許可してください。特にクラウドのメタデータエンドポイント（例：169.254.169.254）と社内の内部ネットワークからは必ず分離します。ここが開いていると、コンテナを破らなくても認証情報の窃取や横移動が成立してしまいます。
Q4. 実行前ポリシー検査は、エージェント自身にやらせてはいけないのですか？
実行するエージェントとは分離した独立層で行うべきです。エージェント自身に是非を判断させると、プロンプトインジェクションでその判断ごと乗っ取られ得ます。判定者と実行者を分ける——これはガードレールやLLM-as-a-Judgeを守るときと同じ設計原則で、サンドボックスの実行前検査でも同様に効きます。
Q5. すべてをmicroVMや使い捨てにすると重くないですか？
一律に最強の隔離を敷く必要はありません。守る対象の危険度に応じて隔離強度を選ぶのが要点です。信頼できる自社コードは軽い環境、外部由来・LLM生成の敵対的コードはmicroVM＋使い捨て、というように段階を分けます。Firecrackerは起動が125ミリ秒級・スナップショット復元も高速で、使い捨て運用のコストは以前より大きく下がっています。
まとめ——「隔離は破られる」を前提に、母艦までの距離を稼ぐ
AIエージェントにコード実行を許すのが標準になった2026年、「サンドボックスで実行すれば安全」という前提は、そのまま鵜呑みにできなくなりました。要点は3つです。
1. サンドボックスは強度の異なる設計物。 素のコンテナは共有カーネルの「壁1枚」に過ぎません。敵対的コードにはgVisorやmicroVMのより強い隔離を、守る対象の危険度に応じて選び分けます。
2. 破られる前提で、被害を封じ込める。 隔離を破られても、エグレスをdefault-denyで締め、メタデータ・内部網から分離しておけば、母艦への横移動は止まります。ネットワークのマイクロセグメンテーションの発想がそのまま武器になります。
3. 実行前に止め、壊れたら捨てる。 独立したポリシー層で危険な実行を入口で拒否し、使い捨て環境で永続化を封じる。「隔離・エグレス・実行前検査・使い捨て」の4層を重ねて初めて、多層防御が成立します。
「隔離してあるから安全」ではなく、「隔離は破られる前提で、破られた先の母艦までの距離をいかに稼ぐか」——これが、コード実行を持つエージェントを運用するための基本姿勢です。
参考リンク
- MITRE ATLAS（AIシステム向け敵対的脅威ランドスケープ）
- MITRE ATT&CK「T1611 Escape to Host」
- OWASP Top 10 for LLM Applications（2025年版）
- gVisor（アプリケーションカーネルによるコンテナ隔離）
- Firecracker microVM
免責事項： 本記事は2026年7月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の隔離実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談ください。フレームワークやツールは更新されるため、最新情報は各公式ソースでご確認ください。
コメント