AIエージェントがツールを呼び出す瞬間——ファイルを読み込み、シェルコマンドを実行し、外部APIを叩く——LLMが生成した命令は制御された境界の外に出る。プロンプトインジェクションによって悪意ある指示が混入した場合、サンドボックスがなければその命令はホストシステム上で直接実行される。本記事はAIエージェントガバナンスのピラーコンテンツに連動します。
ツール実行にサンドボックスが必須な理由は何か
AIエージェントのツール実行をホストに直接さらすシステムは、LLMの判断ミスやインジェクション攻撃でカーネルレベルの被害を受ける可能性があります。サンドボックスはその被爆面を封じ込める設計です。
エージェントが実行するツールは大きく3種類に分類できます。コード実行系（Pythonインタープリタ、シェル、Node.js）、ファイルシステム系（読み書き、ディレクトリ走査）、ネットワーク系（HTTP呼び出し、データベース接続）です。それぞれが異なるホストリソースに触れるため、一律の隔離設計は成立しません。
特に警戒すべきはコード実行系です。フロンティアモデルのコンテナ脱出成功率は2023年末の10%未満から2025年には約50%に上昇したと報告されており（Zylos Research 2026）、2023年の能力前提で設計されたサンドボックスはすでに過小評価されているリスクがあります。また、runc ≤1.1.11の「Leaky Vessels」（CVE-2024-21626）のように、コンテナランタイム自体のCVEがサンドボックス全体を無効化するケースも報告されています。
標準的なDockerコンテナはホストのLinuxカーネルを共有するため、カーネル脆弱性によるコンテナ脱出を防げません。エージェントがLLM生成コードを実行する構成では、標準Dockerを「信頼済みコードのみ」と位置付け、不信頼コードには別の隔離層を重ねる設計が必要です。
分離技術の比較——Docker・gVisor・Firecracker・WASMの使い分け
カーネル共有の有無が隔離強度の分水嶺です。2026年時点でエージェント用途の標準はgVisorとFirecrackerの使い分けに収束しつつあります。
主要な隔離技術の特性を以下にまとめます。
| 技術 | 起動時間 | メモリ消費 | ホストカーネル露出 | 適用場面 |
|---|---|---|---|---|
| Docker（runc） | 約10ms | 約10MB | あり（共有） | 信頼済みコードのみ |
| gVisor（Sentry） | 約100ms | 約20MB | なし | 計算処理中心、Kubernetes |
| Firecracker | 約125ms | 約5MB | なし | 不信頼コード・最大隔離 |
| Kata Containers | 約200ms | 約30MB | なし | K8sネイティブ |
| WASM/WASI | 1ms未満 | 1MB未満 | なし | 限定計算、ブラウザ実行 |
gVisorはユーザー空間カーネル（Sentry）がシステムコールを傍受・フィルタリングする設計で、ホストカーネルへの直接アクセスを遮断します。I/O集約的なワークロードでは10〜30%のオーバーヘッドがありますが、計算処理中心のエージェントタスクには許容範囲です。Kubernetes SIG Appsが2025年11月にkubernetes-sigs/agent-sandboxを標準化し、GKEは2026年3月にネイティブ統合済みです。
FirecrackerはAWSが開発したmicroVMで、ハイパーバイザーレベルの隔離を125ms起動で実現します。LLM生成コードの実行環境として最も強固ですが、ステートフルな操作には向きません。WASM/WASIは計算処理に限定した超軽量オプションで、ネットワーク・ファイルシステムへのアクセスをWASI APIで明示的に許可する設計です。
リスクレベル別の選定と最小権限設計
ツールのリスクをLLM生成コード実行・計算処理・信頼済みツールの3段階に分類し、各段階で隔離強度を変えることでパフォーマンスと安全性を両立します。
エンタープライズのエージェント基盤では、全ツールを同じ隔離レベルで処理するのはパフォーマンス上のボトルネックになります。リスクティア設計が実用的な解です。
Tier 1（高リスク）: LLM生成コードの実行、ユーザーから受け取ったシェルコマンドの実行。FirecrackerまたはKata Containersをデフォルトに設定し、ホストカーネルを完全分離する。実行後はVMを即時破棄するエフェメラル設計を徹底する。
Tier 2（中リスク）: データ変換・計算処理・社内システム向けMCPツール呼び出し。gVisorをベースとし、Kubernetes上でSandboxClass APIを使って動的に適用する。リソース上限（CPU・メモリ・ディスク）をツール定義ごとに設定する。
Tier 3（低リスク）: 社内承認済みのREAD-ONLYツール、ホワイトリスト済みの外部API呼び出し。標準コンテナで可だが、ネットワークポリシーとIAMスコープによる制御は必須。
MCPツール定義に署名マニフェストを要求する設計も有効です。ツールの実行前にエージェントオーケストレーターが署名を検証し、未承認ツールの呼び出しをブロックします。権限管理設計の最小権限原則と組み合わせることで、ツールごとに短命な認証情報を発行するパターンも実装できます。
ネットワーク分離・エフェメラル設計と可観測性
デフォルト全エグレス遮断＋ホワイトリスト方式でネットワークを制御し、タスク完了後に実行コンテキストを破棄するエフェメラル設計がサンドボックスの基本形です。
ネットワーク隔離の原則は「デフォルト全エグレス遮断、ホワイトリスト方式での許可」です。エージェントのツール実行コンテナに対してKubernetesのNetworkPolicyを設定し、アウトバウンド通信は承認済みエンドポイント（特定APIドメイン・社内DBのCIDR）のみ許可します。インバウンドも同様に、エージェントオーケストレーターからの接続以外は遮断します。
エフェメラル実行コンテキストは、タスク1件ごとに実行環境を生成し、完了後即座に破棄するパターンです。Firecrackerならスナップショットからの復元が100ms以下で可能なため、ステートレスな実行環境を低レイテンシで提供できます。長期間稼働する実行環境は認証情報の漏洩・メモリ汚染・ドリフトのリスクを蓄積するため、ショートリビング設計が推奨されます。
可観測性レイヤーでは、全ツール呼び出しをトレースとして記録します。AIエージェントの監査ログ管理と組み合わせ、「どのエージェントが・どのツールを・どのパラメータで・どの結果で呼び出したか」をスパン単位で記録することで、異常なパラメータ流出を事後に検知できます。リアルタイム異常検知も設定し、短時間に大量のファイルアクセスや想定外のネットワーク宛先へのアクセスを自動フラグします。
エンタープライズ規模でサンドボックス基盤を設計・運用するには、Kubernetesのワークロード管理・gVisor/Firecracker統合・NetworkPolicy設計・監査ログパイプラインを横断的に実装する必要があります。KuuのRDEサービスでは、エージェントセキュリティ基盤の設計から本番導入まで一貫してサポートしています。
参考
- AI Agent Sandboxing and Security Isolation: MicroVMs, gVisor, WASM | Zylos Research
- How to Sandbox LLMs & AI Shell Tools | Docker, gVisor, Firecracker | CodeAnt AI
- Building Effective Agents | Anthropic Engineering
まとめ
AIエージェントのツール実行環境は、「どのツールが何にアクセスできるか」をコードで強制する設計です。エージェントの判断が誤った場合でも、サンドボックスが爆発半径を封じ込めます。
実装の優先順位は3段階です。
- Tier分類とツール棚卸し: 既存ツールをリスクティア（LLM生成コード実行／計算処理／信頼済み）に分類し、ToolCallごとに必要な隔離レベルを決定する
- 隔離技術の選定と導入: Tier 1にFirecracker／Kata、Tier 2にgVisor、Tier 3に標準コンテナ＋NetworkPolicyを段階的に導入する
- エフェメラル設計と可観測性: タスク完了後の実行コンテキスト破棄を徹底し、全ツール呼び出しをトレースに記録してフィードバックループを確立する
エージェントガバナンスの観点では、ツール実行の隔離はプロンプトインジェクション対策・権限管理・監査ログと三位一体で機能します。ゼロからの設計支援が必要な場合は、Kuuの企業向けRDEサービスにご相談ください。