AIエージェントサンドボックスは、AIエージェントがコードを実行したり、ツールを呼び出したり、ファイルシステムやブラウザとやり取りしたりするための隔離された実行環境です。この環境内で発生することはホストシステム、隣接するワークロード、機密インフラに影響を与えません。サンドボックスは境界を作り出します。内部で発生したことは内部に留まり、外部で発生したことは明示的に許可しない限り内部から到達できません。Novita Agent Sandbox はこのパターンの実装の1つです（FirecrackerマイクロVMによる隔離、AWSまたはGCP VPCへのBYOCデプロイ、純粋な従量課金制）。しかし、ここで説明する概念はどのサンドボックスプラットフォームにも当てはまります。この記事では、その境界がどのように機能するのか、トレードオフは何か、実際にいつ必要になるのかという最も一般的な質問に答えます。隔離、シークレット、エグレス、コンプライアンス要件に関する詳細なQ&Aについては、AIエージェントサンドボックスFAQ を参照してください。
AIエージェントサンドボックスとは？
AIエージェントサンドボックスは、AIエージェントが実際の作業を行う実行レイヤーです。コードの記述と実行、パッケージのインストール、ファイルの読み取りと変更、API呼び出し、ブラウザセッションやデスクトップGUIとのやり取りなどです。サンドボックスは、独自のファイルシステム、CPUとメモリ割り当て、ネットワークインターフェース、プロセス名前空間を持つ境界のある環境を提供し、外部から隔離されています。
重要な設計目標は 封じ込め です。LLMがシェルコマンドを生成し、エージェントがそれを実行すると、そのコマンドはサンドボックス内で実行されます。パッケージをインストールしたり、サブプロセスを実行したり、認証情報を読み取ろうとしたりしても、それらの操作はサンドボックス内に限定されます。コードがプロセスをクラッシュさせたり、ディスクを満杯にしたりしても、被害はローカルに留まります。
サンドボックスは、クラウドプロバイダーにとっての課金およびリソースアカウンティングの単位としても機能します。E2B、Daytona、Novita Agent Sandbox のようなSDKを呼び出すと、サンドボックスインスタンスを作成し、その中で操作を実行し、それを閉じます。プロバイダーは消費したコンピュートに基づいて課金します。
エージェントサンドボックスは通常のコンテナとどう違うのか？
通常のコンテナはファイルシステム名前空間とリソース制限を提供しますが、同じホスト上のすべてのコンテナは同じOSカーネルを共有します。コンテナ内のプロセスがカーネルの脆弱性を悪用したり、設定ミスのあるシステムコールフィルターを突破したりすると、ホストや他のコンテナに影響を与える可能性があります。
エージェントサンドボックスは通常、マイクロVM境界を使用してさらに一歩先を行きます。マイクロVMはワークロードを軽量な仮想マシンでラップし、独自のゲストカーネルを持ち、ハードウェア仮想化（KVM）によってバックアップされています。ゲストは設計上ホストカーネルから隔離されているため、ゲストでのカーネル脆弱性の悪用が自動的にホストに影響を与えることはありません。
実際のトレードオフはパフォーマンスオーバーヘッドです。マイクロVMはカーネル（最小限であっても）を起動する必要があるため、コンテナよりも起動が遅くなります。Firecrackerのような高速なマイクロVMプラットフォームは、このオーバーヘッドをほとんどの場合500ミリ秒未満に削減しており、Daytonaのようなスナップショットベースのシステムは100ミリ秒未満に抑えています。それでも、コンテナを起動するよりもオーバーヘッドは大きいです。
LLMが生成したコードや信頼できないコードを扱うほとんどのAIエージェントワークロードでは、より強力な境界は価値があります。ユーザー入力のない完全に信頼された内部コードを実行している場合は、強化されたコンテナで十分かもしれません。
AIエージェントにおける隔離とは？
エージェントサンドボックスにおける隔離は、複数の次元にわたって機能します。サンドボックス隔離 が実際のワークロードでどのように機能するか、マイクロVM境界が役立つ箇所と役立たない箇所を含む技術的な詳細については、Firecracker評価ガイドを参照してください。
ファイルシステムの隔離 — エージェントはホストとは別の独自のファイルシステムを持ちます。サンドボックス内に書き込まれたファイルはホストに現れず、ホストファイルは明示的にマウントされない限り内部からアクセスできません。これにより、エージェントがサンドボックス外部にある認証情報、設定ファイル、その他のシークレットを読み取るのを防ぎます。
プロセスの隔離 — サンドボックス内のプロセスは、外部のプロセスを参照したりシグナルを送ったりすることはできません。エージェントはサンドボックス内でサブプロセス、バックグラウンドジョブ、サーバーを開始できますが、ホストのプロセスツリーと通信することはできません。
ネットワークの隔離 — デフォルトでは、エージェントサンドボックスは、アウトバウンドネットワーク呼び出しをブロック、許可リスト、またはレート制限するように設定できます。任意のインターネットアドレスにデータを流出させるべきではないエージェントは、既知のエンドポイントリストに制限できます。詳細については、以下のエグレスフィルタリングのセクションを参照してください。
リソースの隔離 — CPUとメモリの割り当てが制限されています。無限ループに入ったり、大量の出力を生成したりするエージェントは、同じホスト上の他のサンドボックスを枯渇させません。リソース制限がVMまたはコンテナレベルで強制されるためです。
これらの次元は一緒になって 爆発半径 を定義します。エージェントが誤動作したり、クラッシュしたり、予期しないコードを実行したりした場合に最悪何が起こるかです。
エグレスフィルタリングとは何か、なぜ重要なのか？
エグレスフィルタリングは、サンドボックス内のエージェントが外部に対して許可されるアウトバウンドネットワーク接続を制御します。
寛容な設定 では、エージェントはインターネット上の任意のホストにHTTP/HTTPS呼び出しを行うことができます。これは、パッケージを取得したり、外部APIを呼び出したり、ウェブを閲覧したりするコーディングエージェントにとって便利です。しかし、これは、侵害されたエージェントやプロンプトインジェクション攻撃によって操作されたエージェントが、攻撃者が管理するサーバーにデータを流出させたり、到達すべきでないインフラとやり取りしたりする可能性があることも意味します。
制限的な設定 では、エグレスは明示的な許可リストにロックされます。エージェントはモデルAPI、特定のデータベース、パッケージレジストリのみを呼び出すことができます。それ以外はすべてドロップされます。これは設定が難しく、エージェントの依存関係が変更されるにつれて許可リストを維持する必要がありますが、攻撃対象領域ははるかに小さくなります。
ほとんどのプロダクションエージェントデプロイメントは、これらの極端な中間に存在します。エグレスは完全に無制限ではありませんが、初日からゼロトラストリストにロックされているわけでもありません。一般的なパターンには、既知の悪意のある宛先をブロックする、すべてのアウトバウンド呼び出しを監査用にログする、エージェントの動作が予測可能になるにつれてリストを徐々に厳しくするなどがあります。エグレス制御 と各隔離境界から何がまだ脱出できるかの完全な内訳については、安全なコード実行ガイドを参照してください。
一部のサンドボックスプロバイダーは、SDKを介してプログラムによるエグレス制御を提供します。他のプロバイダーはサンドボックスをデフォルトで完全にアウトバウンド開放として扱います。エージェントが外部ホストに到達できないと想定する前に、プロバイダーがどのモデルを使用しているかを把握してください。
エージェントサンドボックスにおけるスナップショットとは？
スナップショットは、実行中のサンドボックスの正確な状態（ファイルシステム、メモリ、実行中のプロセス、ネットワーク状態）をキャプチャし、後でサンドボックスをその状態に復元できるように保存します。
これはいくつかのシナリオで役立ちます。
コールドスタートコストの削減 — 毎回新しいVMを起動してパッケージをインストールする代わりに、1回起動してすべてをインストールし、スナップショットを取得し、新しいセッションごとにそのスナップショットから再開します。Daytonaの90ミリ秒未満のコールドスタートは、この手法によって可能になっています。
長時間実行エージェントのチェックポイント — 複数時間のタスクに取り組んでいるコーディングエージェントは、途中で一時停止でき、その正確な状態が保存されます。エージェントをレビュー、変更、再起動する必要がある場合、最初からやり直すのではなく、チェックポイントから再開できます。
再現可能な評価 — RLトレーニングやモデル評価パイプラインでは、既知の良好な開始状態のスナップショットを取得し、各評価エピソードの前にそれにリセットできます。これにより、再プロビジョニングして状態が一致することを期待するよりも、多くの実行にわたって真に同一の開始条件が得られます。
すべてのサンドボックスプロバイダーがスナップショット制御をAPIレベルで公開しているわけではありません。E2Bのテンプレートシステムは「プリインストール環境」のユースケースを処理しますが、任意のセッション途中のチェックポイント復元は提供しません。DaytonaのスナップショットAPIはより柔軟です。
エージェントサンドボックスを支える技術は？
最も一般的な基盤技術は次のとおりです。
Firecracker — AWSが開発したマイクロVMランタイムで、LambdaとFargateで内部的に使用されています。Firecrackerは500ミリ秒未満で最小限のゲストカーネルを起動し、攻撃対象領域を減らすために最小限のデバイスモデルを公開し、KVMハードウェア仮想化によってバックアップされています。E2BとNovita Agent Sandbox はどちらもFirecrackerを使用しています。
gVisor — Googleが開発したカーネルサンドボックスで、完全なゲストカーネルを実行するのではなく、システムコールに割り込みます。マイクロVMよりも軽量ですが、完全なカーネル隔離は提供しません。プロセスレベルとVMレベルの間の隔離スペクトルに位置します。
システムコールフィルタリングを備えたDockerコンテナ — seccomp、AppArmor、最小限のケーパビリティで強化されたコンテナ。最も一般的な出発点ですが、信頼できないコードに対する最も弱い隔離境界です。
V8 / Deno — V8ランタイムのパーミッションモデルを使用したJavaScript固有の隔離。JavaScriptのみのワークロードのサンドボックス化には適していますが、任意のシェルコマンドや非JSコードを実行する必要があるエージェントには使用できません。
基盤技術の選択は、サンドボックスの起動パフォーマンス、隔離の強度、運用の複雑さを決定します。マルチテナントコンテキストで信頼できないコードやLLMが生成したコードを実行するエージェントワークロードには、Firecrackerクラスの隔離が現在の実用的な標準です。
AIエージェントはサンドボックスから脱出できるのか？
実際には、サンドボックスからの脱出はまれですが不可能ではありません。リスクプロファイルはテクノロジーに依存します。
コンテナからの脱出 は文書化されています。設定ミスのあるコンテナ（特権モード、Dockerソケットのマウント、書き込み可能なホストディレクトリ）には既知の脱出ベクトルがあります。権限のない、読み取り専用ルートファイルシステム、最小限のケーパビリティを持つ強化されたコンテナは、このリスクを大幅に低減しますが、排除するわけではありません。
マイクロVMからの脱出 には、ハイパーバイザーの脆弱性またはデバイスモデルの欠陥が必要です。これらはまれです。なぜなら、攻撃対象領域は設計上小さいからです。Firecrackerの最小限のデバイスモデルは、ハイパーバイザーの露出を減らすために特別に設計されています。AWSは、本番環境でFirecrackerレベルの脱出を開示していません。
サンドボックスアクションへのプロンプトインジェクション は、別の種類の「脱出」です。カーネルの悪用ではなく、攻撃者がユーザー提供コンテンツに命令を埋め込み、エージェントに本来取るべきでないアクションを取らせるものです。これはアプリケーションレベルの concern であり、サンドボックスレベルの concern ではありません。サンドボックスはプロンプトインジェクションによる被害の封じ込めに役立ちます（注入されたコードはホストではなくサンドボックス内で実行されます）が、インジェクション自体を防ぐわけではありません。
実際的な結論：適切に設定されたFirecrackerベースのサンドボックスは、理論上は脱出不可能ではありませんが、攻撃のハードルは十分に高いため、ほとんどのエンタープライズエージェントデプロイメントでは、残存リスクは管理可能です。より一般的な障害モードは、設定ミス（過度に寛容なエグレス、サンドボックスに渡された不適切にスコープ設定された認証情報）であり、カーネルレベルの悪用ではありません。
AIエージェントサンドボックスはGPUワークロードをサポートするのか？
2026年半ば時点で、ほとんどのAIエージェントサンドボックスはGPUサポートを含んでいません。E2B、Daytona、Vercel SandboxはすべてCPUのみです。
マネージドサンドボックススペースでは、Modalが主な例外です。コンテナ内でオンデマンドGPUアクセスを提供し、エージェントのコードと同じ環境でのモデル推論、ファインチューニング、RLワークロードに適しています。
ほとんどのエージェントワークフローでは、エージェント自体はローカルでモデルを実行するのではなく、外部のLLM推論API（Novitaの推論エンドポイントなど）を呼び出します。そのアーキテクチャでは、サンドボックス内にGPUは必要ありません。サンドボックスはコード、ファイル操作、ツール呼び出しを処理し、重い推論は別のGPUサービスで実行されます。これは、コーディングエージェント、データ分析エージェント、およびほとんどのブラウザ自動化ワークフローで使用されるパターンです。
サンドボックス内にGPUが必要な場合（例えば、オフライン使用のためのローカルモデル推論、RLトレーニングステップ、マルチステップ評価パイプライン）、その点をプロバイダー選択に考慮する必要があります。Modalは現在、このパターンで最も一般的に使用されるオプションです。
専用のサンドボックスが実際に必要なのはいつか？
すべてのAIアプリケーションに専用のサンドボックスが必要なわけではありません。サンドボックスが真の価値をもたらすシナリオは次のとおりです。
LLMが生成したコードを実行している場合 — エージェントが人間によって作成されていないコードを記述して実行し、予期しないことを行う可能性があります。これがコアユースケースです。実行はサンドボックス内で行われるため、ホスト、認証情報、他のワークロードに影響を与えることはありません。
エンドユーザーにサービスを提供している場合 — 複数のユーザーのエージェント実行が同じ基盤インフラを共有します。あるユーザーのエージェントが、意図的または偶発的に別のユーザーに影響を与えないように、ユーザー間の隔離が必要です。
長時間実行されるステートフルなワークフローが必要な場合 — ファイルを編集し、テストを実行し、変更をコミットするコーディングエージェントは、多くのLLMターンにわたって永続するワークスペースを必要とします。呼び出しごとに新しいサブプロセスでは状態が維持されません。サンドボックスなら維持できます。
コンプライアンスまたは監査要件がある場合 — すべてのエージェントアクションをログに記録し、ネットワークアクセスを制限し、エージェントワークロードが本番データベースや認証情報にアクセスできないことを証明する必要があります。サンドボックスはこれらの制御を実施するレイヤーを提供します。
ブラウザまたはコンピュータ使用の自動化を行っている場合 — ブラウザ自動化サンドボックス 環境はホストから完全に隔離されているため、エージェントはローカルのブラウザセッションやシステム状態に影響を与えることなく、クリック、タイプ、スクリーンショットを実行できます。
単純な「このテキストを要約する」パイプラインでコード実行がない場合は、おそらく専用の実行サンドボックスは必要ありません。LLMへのAPI呼び出しで十分です。サンドボックスが必要になるのは、エージェントが副作用をもたらすアクション（ファイルの書き込み、コードの実行、代理での外部APIの呼び出し）を開始し始めた瞬間です。
よくある質問
AIエージェントサンドボックスは開発環境と同じですか？
いいえ。開発環境は人間の開発者向けのワークスペースであり、セッション間で永続し、長期間存続し、カスタマイズおよび再利用されるように設計されています。AIエージェントサンドボックスはランタイム実行境界です。タスクの期間存在し、エフェメラルで再現可能になるように設計されており、その主な役割は封じ込めであり、開発者の快適さではありません。一部のサンドボックスはセッション内のLLMターン間で状態を永続化できます（ワークスペースのように感じさせることができます）が、設計目標はホストからの隔離であり、フル機能のIDEではありません。これらの用語はベンダーのマーケティングで重複することがあります。プラットフォームを評価する場合は、ラベルではなく実際の隔離境界が何であるかに注目してください。
エージェント実行サンドボックスとは何ですか？
エージェント実行サンドボックスはAIエージェントサンドボックスと同じものです。「実行」というフレーミングは単にランタイムの側面を強調しています。LLMがアクション（コードの実行、ツールの呼び出し、ファイルの書き込み）を決定すると、それらのアクションはサンドボックス内で実行されます。サンドボックスは、エージェントの動作と、システムの残りの部分が見たり影響を受けたりできるものとの間の境界を強制する実行レイヤーです。「エージェントサンドボックス」、「コード実行サンドボックス」、「エージェント実行環境」という用語は、業界で同じ意味で使用されています。
AIエージェントワークロードにおいて、FirecrackerとgVisorはどのように比較されますか？
どちらも標準的なコンテナを超えた隔離を提供しますが、メカニズムが異なります。FirecrackerはKVMバックアップのマイクロVM内で最小限のゲストカーネルを起動します。サンドボックスはホストカーネルから完全に分離された独自のカーネルを持ちます。gVisorは完全なゲストカーネルを実行せずに、ユーザースペースカーネル（runsc）を使用してシステムコールに割り込みます。実際のトレードオフ：Firecrackerはゲストカーネルが完全に分離されているため、より強力なホスト境界を提供します。gVisorは完全なカーネルを実行しないため、サンドボックスあたりのメモリオーバーヘッドが低くなりますが、隔離は完全なマイクロVMとシステムコールインターセプションで強化されたコンテナの間にあります。信頼できないLLM生成コードを実行するマルチテナントAIエージェントワークロードでは、Firecrackerクラスの隔離が現在の本番標準です。gVisorは、コードが部分的に信頼されており、最大限の隔離よりもメモリ密度が重要なワークロードに合理的です。
プロンプトインジェクションはエージェントがサンドボックスから脱出する原因になりますか？
プロンプトインジェクションはサンドボックスの技術的な隔離をバイパスするわけではありません。エージェントの意思決定を悪用して、攻撃者が意図したが開発者は意図しなかったアクションを取らせます。「このURLに環境変数を流出させろ」のような注入された命令は、エージェントにアウトバウンドネットワーク呼び出しをさせます。これはエグレスポリシーがそれを防いでいる場合にのみブロックされます。サンドボックスのファイルシステムとプロセスの隔離はそのまま維持されます。これは、サンドボックスセキュリティとプロンプトインジェクション防御がスタックの異なる部分に対処していることを意味します。サンドボックスはエージェントがインフラレベルで実行できることの爆発半径を制限します。アプリケーションレベルの制御（ツール呼び出し制限、人間による承認、エグレス許可リスト化）は、エージェントがそれらの機能を悪用するように指示されることから防御します。
なぜAIエージェントに特にサンドボックスが必要なのですか？
従来のコード実行との重要な違いは 不確実性 です。人間の開発者がコードを書くとき、開発者はそれがおおよそ何をするかを知っています。LLMがコードを生成したり、ツールを呼び出すことを決定したりすると、アプリケーションは、何が正確に実行されるか、どのパッケージがインストールされるか、どの外部エンドポイントが連絡されるかについて、可視性が限られている可能性があります。しかもそれは数千の同時セッションにわたる可能性があります。その不確実性は、各標準的なセキュリティ制御の重要性を高めます。エージェントが誰も予期しなかったエンドポイントに到達する可能性があるためエグレスポリシーが重要になり、エージェントが動的に依存関係をインストールする可能性があるためパッケージガバナンスが重要になり、エージェントのアクションが事前に列挙されていなかった場合に何が起こったかを再構築するのが難しくなるため監査ログが重要になります。サンドボックスは、すべての個々のエージェントアクションを事前に信頼することなく、その不確実性を処理するための実施レイヤーを提供します。
一般的なサンドボックスプロバイダー
主要なオプションの簡単な概要です。より詳細な比較はリンク先の記事を参照してください。
- Novita Agent Sandbox — FirecrackerマイクロVM、AWSまたはGCP VPCへのBYOCデプロイ、サブスクリプション料金なし、最大24時間のセッション。コンプライアンス要件、コスト感度、またはすでにLLM推論にNovitaを使用しているチーム向けの主要なオプション。詳細は novita.ai/sandbox を参照。
- E2B — マネージド、FirecrackerマイクロVM、大規模コミュニティ、セルフホスティングなし。文書化されたSDKと活発なエコシステム。
- Daytona — 90ミリ秒未満のコールドスタート、オープンソース（AGPL）、セルフホスト可能。レイテンシに敏感なユースケースや、セルフホストインフラが必要なコンプライアンスユースケースに適しています。
- Modal — サンドボックス内でGPUが必要な場合の主要なオプション。コンテナベースの隔離。
- Vercel Sandbox — 高速なコールドスタート、Vercelプラットフォーム上のJS/TSに最適。
仕様と決定フレームワークを含む完全な比較については、2026年の最強AIエージェントサンドボックス を参照してください。E2BとDaytonaの詳細な評価（コールドスタート、BYOC、スナップショット、価格設定）については、E2B vs Daytona AIエージェントサンドボックス評価ガイド を参照してください。
