AIエージェントサンドボックスとは？

AIエージェントサンドボックスは、AIエージェントが実際の作業を行う実行レイヤーです。コードの記述と実行、パッケージのインストール、ファイルの読み取りと変更、API呼び出しの実行、ブラウザセッションやデスクトップGUIとの対話などです。サンドボックスは、独自のファイルシステム、CPUとメモリの割り当て、ネットワークインターフェース、プロセス名前空間を持つ境界環境を提供し、外部のすべてから隔離されています。

主要な設計目標は封じ込めです。LLMがシェルコマンドを生成し、エージェントがそれを実行するとき、そのコマンドはサンドボックス内で実行されます。パッケージをインストールしたり、サブプロセスを実行したり、資格情報を読み取ろうとしたりすると、それらの操作はサンドボックスにスコープされます。コードがプロセスをクラッシュさせたり、ディスクを満たしたりしても、損害はローカルに留まります。

サンドボックスは、クラウドプロバイダーの課金およびリソースアカウンティングの単位としても機能します。E2B、Daytona、Novita Agent Sandbox などのSDKを呼び出すと、サンドボックスインスタンスを作成し、その内部で操作を実行し、それを閉じます。プロバイダーは消費したコンピューティング量に基づいて課金します。

エージェントサンドボックスは通常のコンテナとどう違うのか？

通常のコンテナはファイルシステム名前空間とリソース制限を提供しますが、同じホスト上のすべてのコンテナは同じOSカーネルを共有します。コンテナ内のプロセスがカーネルの脆弱性や誤って構成されたsyscallフィルターを悪用した場合、ホストや他のコンテナに影響を与える可能性があります。

エージェントサンドボックスは通常、マイクロVM境界を使用することでさらに一歩進んでいます。マイクロVMは、ワークロードを独自のゲストカーネルを持つ軽量仮想マシンでラップし、ハードウェア仮想化（KVM）によって支えられています。ゲストはホストカーネルから設計上分離されているため、ゲスト内のカーネルエクスプロイトが自動的にホストに影響を与えることはありません。

実用的なトレードオフはパフォーマンスのオーバーヘッドです。マイクロVMは、最小限のカーネルであっても起動する必要があるため、コンテナよりも起動が遅くなります。Firecracker のような高速なマイクロVMプラットフォームは、そのオーバーヘッドをほとんどの場合500ミリ秒未満に削減し、Daytona のようなスナップショットベースのシステムはそれを100ミリ秒未満に押し上げています。しかし、それでもコンテナを起動するよりもオーバーヘッドが大きいです。

LLMによって生成されたコードや信頼できないコードを含むほとんどのAIエージェントワークロードでは、より強力な境界には価値があります。完全に信頼できる内部コードでユーザー生成の入力がない場合は、強化されたコンテナで十分かもしれません。

AIエージェントの文脈における分離とは？

エージェントサンドボックスにおける分離は、いくつかの次元にわたって機能します。サンドボックス分離が実際のワークロード下でどのように耐えるか、マイクロVM境界が役立つ場所とそうでない場所についての技術的な詳細は、Firecracker評価ガイドを参照してください。

ファイルシステム分離 — エージェントはホストから分離された独自のファイルシステムを持ちます。サンドボックス内に書き込まれたファイルはホストに表示されず、ホストファイルは明示的にマウントされない限り内部からアクセスできません。これにより、エージェントがサンドボックス外にある資格情報、構成ファイル、その他のシークレットを読み取るのを防ぎます。

プロセス分離 — サンドボックス内のプロセスは、外部のプロセスを表示したりシグナルを送信したりできません。エージェントはサンドボックス内でサブプロセス、バックグラウンドジョブ、またはサーバーを開始できますが、ホストプロセスツリーと通信することはできません。

ネットワーク分離 — デフォルトでは、エージェントサンドボックスは、アウトバウンドネットワーク呼び出しがブロックされるか、許可リストに登録されるか、レート制限されるように構成できます。任意のインターネットアドレスにデータを漏洩してはならないエージェントは、既知のエンドポイントリストに制限できます。詳細については、以下のエグレスフィルタリングのセクションを参照してください。

リソース分離 — CPUとメモリの割り当ては上限が設定されています。無限ループに入ったり、大きな出力を生成したりするエージェントは、同じホスト上の他のサンドボックスを枯渇させません。これは、リソース制限がVMまたはコンテナレベルで強制されるためです。

これらの次元は、ブラスト半径を定義します。つまり、エージェントが誤動作したり、クラッシュしたり、予期しないコードを実行したりした場合の最悪のシナリオは何かということです。

エグレスフィルタリングとは何か、なぜ重要なのか？

エグレスフィルタリングは、エージェントがサンドボックス内からアウトバウンドネットワーク接続を行うことを許可されるかどうかを制御します。

寛容な構成では、エージェントはインターネット上の任意のホストに対してHTTP/HTTPS呼び出しを行うことができます。これは、パッケージを取得したり、外部APIを呼び出したり、ウェブを閲覧したりするコーディングエージェントにとって便利です。また、侵害されたエージェント、またはプロンプトインジェクション攻撃によって操作されたエージェントが、攻撃者が制御するサーバーにデータを漏洩したり、到達すべきでないインフラストラクチャと対話したりする可能性があることも意味します。

制限的な構成では、エグレスは明示的な許可リストにロックされます。エージェントはモデルAPI、特定のデータベース、パッケージレジストリのみを呼び出すことができます。それ以外はすべてドロップされます。これは設定が難しく、エージェントの依存関係が変更されると許可リストのメンテナンスが必要ですが、攻撃対象領域を大幅に縮小できます。

ほとんどの本番エージェントデプロイメントはこれらの極端な中間に存在します。エグレスは完全に無制限ではありませんが、初日からゼロトラストリストにロックされているわけでもありません。一般的なパターンには、既知の悪意のある宛先をブロックする、すべてのアウトバウンド呼び出しを監査用にログする、エージェントの動作が予測可能になるにつれてリストを徐々に厳しくする、などがあります。エグレス制御と各分離境界からまだ逃げ出せるものの完全な内訳については、安全なコード実行ガイドを参照してください。

一部のサンドボックスプロバイダーは、SDKを介してプログラムでエグレス制御を提供します。他のプロバイダーは、サンドボックスをデフォルトで完全にアウトバウンドオープンとして扱います。エージェントが外部ホストに到達できないと想定する前に、プロバイダーがどのモデルを使用しているかを把握してください。

エージェントサンドボックスでシークレットと資格情報はどのようにスコープされるのか？ {#secrets-and-credentials}

サンドボックスに渡されるシークレットは、その特定のエージェント実行に必要なものだけにスコープされるべきであり、長時間有効な資格情報をディスクに書き込むのではなく、環境変数または短命トークンとして渡されるべきです。サンドボックス境界はブラスト半径を制限しますが、環境内でアクセス可能な資格情報をエージェントが読み取って転送するのを自動的に防ぐわけではありません。

基本原則は最小特権です。ルートクラウドキーや広範な権限を持つサービスアカウントではなく、機能する最も狭い資格情報を渡します。一般的なパターン：

起動時の環境変数 — 起動時にサンドボックス環境にシークレットを注入します。エージェントのコードから利用可能ですが、デフォルトではファイルシステムのスナップショットに永続化されず、ログに表示されません。静的APIキーよりも短命トークンを優先します。

DNSレベルのブロッキング — 一部のデプロイメント構成では、サンドボックス内から解決できるDNS名を制限できます。これにより、エージェントがネットワークアクセスを持っていても、個々のIPではなくDNSレイヤーで解決をブロックすることで、資格情報漏洩エンドポイントに連絡するのを防ぎます。

短いTTLを持つスコープされたサービスアカウント — クラウドAPIを呼び出すエージェントの場合、短い有効期間を持つロール引き受けチェーンを使用します。資格情報が漏洩した場合、攻撃者のウィンドウはトークンの有効期間によって制限されます。

ホスト資格情報ファイルなし — ホスト資格情報ファイル（~/.aws/credentials など）をサンドボックスファイルシステムにマウントしないでください。代わりに、セッションごとに新しい短命資格情報を生成します。

サンドボックスはプロセスレベルの境界を提供します。何をその内部に渡すかはユーザーの責任です。

AIエージェントサンドボックスで監査ログはどのように機能するのか？ {#audit-logs}

エージェントサンドボックスの監査ログは、通常、プラットフォームレベルのイベント（サンドボックスの作成、開始、停止、タイムアウト）とアプリケーションレベルのイベント（実行されたコマンド、変更されたファイル、外部API呼び出し）の2つのレベルをカバーします。ほとんどの管理プロバイダーはプラットフォームイベントを自動的に出力します。アプリケーションレベルのログは、ユーザーが計装する責任があります。

意味のある監査範囲を確保するためにキャプチャすべきもの：

サンドボックスライフサイクルイベント — 作成タイムスタンプ、セッション期間、終了理由（通常のクローズ、タイムアウト、またはクラッシュ）。ほとんどの管理プラットフォームはこれらを自動的にログし、APIまたはダッシュボードを介して公開します。

アウトバウンドネットワーク呼び出し — エージェントが連絡したホストとタイムスタンプ。ここでエグレスログと監査ログが重なります。プラットフォームがエグレスログをサポートしている場合は、有効にして出力をログアグリゲーターにルーティングします。

コード実行の入力/出力 — エージェントが実行したコマンドと受け取った結果。これはアプリケーションレベルであり、サンドボックスインフラストラクチャ層ではなく、エージェントフレームワークでキャプチャする必要があります。

ファイルシステムの変更 — 書き込まれた、削除された、または変更されたファイル。コーディングエージェントやデータ処理パイプラインに関連します。一部のサンドボックスプラットフォームは、セッション終了時にファイルシステム差分APIを公開します。他のプラットフォームでは、エージェントコードでの計装が必要です。

コンプライアンスユースケース（SOC 2、HIPAA、規制産業）の場合、通常、改ざん防止ストア内のプラットフォームレベルのログと、エージェントフレームワークからのアプリケーションレベルのログを組み合わせる必要があります。プロバイダーが実際に何を出力するのか、何が明示的な有効化を必要とするのかを、カバレッジを想定する前に確認してください。

エージェントサンドボックスにおけるスナップショットとは？

スナップショットは、実行中のサンドボックスの正確な状態（ファイルシステム、メモリ、実行中のプロセス、ネットワーク状態）をキャプチャし、後でその状態にサンドボックスを復元できるように保存します。

これはいくつかのシナリオで役立ちます：

コールドスタートコストの削減 — 毎回新しいVMを起動してパッケージをインストールする代わりに、一度起動してすべてをインストールし、スナップショットを取得してから、新しいセッションごとにそのスナップショットから再開します。Daytona の90ミリ秒未満のコールドスタートは、この技術によって可能になっています。

長時間実行エージェントのチェックポイント — 数時間かかるタスクに取り組んでいるコーディングエージェントは、途中で一時停止し、正確な状態が保存されます。エージェントをレビュー、変更、または再起動する必要がある場合、最初からやり直すのではなく、チェックポイントから再開できます。

再現可能な評価 — RLトレーニングやモデル評価パイプラインの場合、既知の良好な開始状態をスナップショットし、各評価エピソードの前にその状態にリセットできます。これにより、再プロビジョニングして状態が一致することを期待するよりも、多くの実行にわたって真に同一の開始条件が得られます。

すべてのサンドボックスプロバイダーがAPIレベルでスナップショット制御を公開しているわけではありません。E2Bのテンプレートシステムは「プリインストール環境」のユースケースを処理しますが、任意のセッション途中のチェックポイント復元機能は提供しません。Daytona のスナップショットAPIはより柔軟です。

エージェントサンドボックスを支える技術は？

最も一般的な基盤技術は以下の通りです：

Firecracker — AWSによって開発されたマイクロVMランタイムで、LambdaとFargateで内部的に使用されています。Firecrackerは500ミリ秒未満で最小限のゲストカーネルを起動し、攻撃対象領域を減らすために最小限のデバイスモデルを公開し、KVMハードウェア仮想化によって支えられています。E2BとNovita Agent Sandbox はどちらもFirecrackerを使用しています。

gVisor — Googleが開発したカーネルサンドボックスで、完全なゲストカーネルを実行するのではなく、システムコールに介入します。マイクロVMよりも軽量ですが、完全なカーネル分離は提供しません。分離スペクトルにおいて、プロセスレベルとVMレベルの間に位置します。

syscallフィルタリング付きDockerコンテナ — seccomp、AppArmor、最小限のケイパビリティで強化されたコンテナ。これは最も一般的な出発点ですが、信頼できないコードにとっては最も弱い分離境界です。

V8 / Deno — V8ランタイムのパーミッションモデルを使用したJavaScript固有の分離。JavaScriptのみのワークロードのサンドボックス化に適していますが、任意のシェルコマンドや非JSコードを実行する必要があるエージェントには使用できません。

基盤技術の選択により、サンドボックスの起動パフォーマンス、分離の強度、運用の複雑さが決まります。マルチテナントコンテキストで信頼できないコードやLLM生成コードを実行するエージェントワークロードの場合、Firecrackerクラスの分離が現在の実用的な標準です。

AIエージェントはサンドボックスから脱出できるのか？

実際には、サンドボックスからの脱出はまれですが不可能ではなく、リスクプロファイルは技術に依存します：

コンテナエスケープ は文書化されています。誤って構成されたコンテナ（特権モード、Dockerソケットのマウント、書き込み可能なホストディレクトリ）には既知のエスケープベクターがあります。特権なし、読み取り専用ルートファイルシステム、最小限のケイパビリティを持つ強化されたコンテナはこのリスクを大幅に削減しますが、排除はしません。

マイクロVMエスケープ には、ハイパーバイザーの脆弱性またはデバイスモデルの欠陥が必要です。これらはまれです。なぜなら、攻撃対象領域が設計上小さいからです。Firecrackerの最小限のデバイスモデルは、ハイパーバイザーの露出を減らすために特別に設計されています。AWSは、本番環境でのFirecrackerレベルのエスケープを開示していません。

サンドボックスアクションへのプロンプトインジェクション は別の種類の「脱出」です。カーネルエクスプロイトではなく、攻撃者がユーザー提供のコンテンツに命令を埋め込み、エージェントに本来すべきでないアクションを取らせるものです。これはアプリケーションレベルの懸念事項であり、サンドボックスレベルのものではありません。サンドボックスはプロンプトインジェクションからの被害を封じ込めるのに役立ちます（注入されたコードはホストではなくサンドボックス内で実行されます）が、インジェクション自体を防ぐわけではありません。

実際的な結論：適切に構成された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の呼び出しなど、副作用を持つアクションを取り始めたときです。

コードインタープリタとエージェントランタイムの違いは何か？ {#code-interpreter-vs-agent-runtime}

コードインタープリタは、単一のコードスニペットを分離して実行し、出力を返します。デフォルトではステートレスです。各実行はクリーンな状態で開始され、結果が返され、何も永続化されません。セルが呼び出し間で状態を共有しないサンドボックス化されたJupyterカーネルのようなものです。これは、実行間で状態を必要としないデータ分析、数式評価、または単発のコード実行に適したツールです。

エージェントランタイムは、マルチステップワークフロー向けに設計された永続的でステートフルな実行環境です。エージェントは、ファイルの書き込み、パッケージのインストール、バックグラウンドプロセスの実行、ネットワーク呼び出し、多くのLLMターンにわたるワークスペース状態の蓄積を、ステップ間でコンテキストを失うことなく実行できます。ファイルを編集し、テストを実行し、エラー出力を読み、反復するコーディングエージェントは、コードインタープリタではなく、エージェントランタイムで動作しています。

この区別はツール設計において重要です：

	コードインタープリタ	エージェントランタイム
呼び出し間の状態	なし（実行ごとに新規）	セッション内で永続的
ファイルシステムアクセス	通常、呼び出しごとに分離	永続的ワークスペース
マルチステップワークフロー	設計対象外	コアユースケース
一般的なセッション長	秒	数分から数時間
例	Jupyterカーネル、単一コードセル	E2B, Daytona, Novita Agent Sandbox

実際には、境界線は曖昧です。E2Bとほとんどの管理サンドボックスプラットフォームは、コードインタープリタのように動作できます（1つのスニペットを実行し、出力を返す）が、その下には完全なエージェントランタイムインフラストラクチャ（永続的ファイルシステム、プロセス管理、ネットワークアクセス）を提供します。OpenAIのCode Interpreterのようなプラットフォームは、ステートレスのユースケース向けに特別に設計されており、エージェントランタイムが提供する柔軟性に対して意図的なトレードオフを行っています。

状態要件のない単一タスクのための迅速で分離された実行環境が必要な場合は、コードインタープリタを選択してください。ワークロードに反復的なファイル編集、インストールされたパッケージ依存関係、長時間実行プロセス、または中断したところから再開する必要があるワークフローが含まれる場合は、エージェントランタイムを選択してください。

AI生成コードを安全に実行するには？ {#run-ai-generated-code-safely}

本番環境でAI生成コードを安全に実行するには、すべてのレイヤーで適切な制御が必要です。サンドボックスは実行境界を処理しますが、ユーザーが行う必要のあるアプリケーションレベルの決定もあります。

信頼できないコードには、コンテナではなくマイクロVMレベルの分離を使用してください。 Firecrackerベースのサンドボックス（E2B、Novita Agent Sandbox）は、LLM生成コードを独自のカーネルを持つVM内に配置します。コンテナエスケープは文書化されており、既知のベクターがあります。マイクロVMレベルのエスケープにはハイパーバイザーの脆弱性が必要であり、設計上まれです。コードが人間によってレビューされていない場合、コールドスタートコストはより強力な境界に見合う価値があります。

エグレスをエージェントが実際に必要とするものに制限してください。 データ分析コードを実行するエージェントは、おそらく任意のインターネットホストに到達する必要はありません。エグレスをモデルAPI、特定のパッケージレジストリ、およびタスクが明示的に必要とする外部サービスにロックします。BYOCデプロイメントでは、これはVPCセキュリティグループレベルで実施できます。管理デプロイメントでは、利用可能な場合はプロバイダーのエグレス制御を使用するか、無制限のエグレスを既知のリスクとして受け入れログに記録します。

スコープされた短命の資格情報のみを渡してください。 サンドボックスに本番データベース、ルートクラウドキー、または広範なサービスアカウントへのアクセスを与えないでください。現在のタスクに必要なものだけを、短いTTLを持つ資格情報を使用して渡します。生成されたコードが資格情報を読み取って漏洩した場合、損害は制限されます。

タイムアウトとリソース制限を適用してください。 実行に明示的な時間とメモリの制限を設定します。LLMによって生成された無限ループや予期せず大きな出力は、セッションを無期限に消費したりディスクを満たしたりするのではなく、グレースフルに終了する必要があります。

最初からエグレスとコマンド履歴をログに記録してください。 エージェントが何をしたかの記録がなければ、予期しない動作を調査できません。開発中であっても、早期にエグレスログを有効にしてください。実行されたコマンド、ファイル書き込み、外部呼び出しのアプリケーションレベルのログはユーザーの責任です。サンドボックスインフラストラクチャはこれを自動的に行いません。

リスクを完全に排除する構成はありません。目標は、既知の制限された残留リスクです。エージェントは、強力な分離境界内で、必要な最小限の資格情報とネットワークアクセスで、ユーザーが作成していないコードを実行し、予期しない動作を検出して診断するための十分なログがある状態です。

よくある質問

AIエージェントサンドボックスは開発環境と同じですか？

いいえ。開発環境は人間の開発者のためのワークスペースです。セッションをまたいで永続化され、長期にわたって使用され、カスタマイズおよび再利用されるように設計されています。AIエージェントサンドボックスはランタイム実行境界です。タスクの期間にわたって存在し、エフェメラルで再現可能になるように設計されており、その主な役割は封じ込めであり、開発者の快適さではありません。一部のサンドボックスはセッション内のLLMターンにわたって状態を永続化できます（そのため、よりワークスペースのように感じられます）が、設計目標はホストからの分離であり、フル機能のIDEではありません。これらの用語はベンダーのマーケティングで重なることがあります。プラットフォームを評価する場合は、ラベルではなく、分離境界が実際に何であるかを確認してください。

エージェント実行サンドボックスとは何ですか？

エージェント実行サンドボックスはAIエージェントサンドボックスと同じものです。「実行」という表現は、ランタイムの側面を強調しています。LLMがアクション（コードの実行、ツールの呼び出し、ファイルの書き込み）を実行することを決定した場合、それらのアクションはサンドボックス内で実行されます。サンドボックスは、エージェントが行うことと、システムの残りの部分が表示または影響を受ける可能性があるものとの間の境界を強制する実行レイヤーです。「エージェントサンドボックス」、「コード実行サンドボックス」、「エージェント実行環境」という用語は、業界で同じ意味で使用されます。

Firecracker は AI エージェントワークロードにおいて 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とDaytonaを比較したAIエージェントサンドボックス評価ガイドを参照してください。

AIエージェントサンドボックスとは？