このAIエージェントサンドボックスFAQは、開発者がエージェント生成コードを実行する前に尋ねる実用的なセキュリティの質問に答えます。分離の仕組み、エージェントが持つネットワークアクセス、ファイルとセッション状態の保存場所、シークレット、監査ログ、コンプライアンス、コストの取り扱い方法について説明します。サンドボックスが初めての方は、AIエージェントサンドボックスとは？ から始めて、分離モデル、外部通信、スナップショットについての基礎を学んでください。プロバイダーを選ぶ際は、2026年におけるベストAIエージェントサンドボックス または E2B vs. Daytona 評価ガイド をご覧ください。
AIエージェントをサンドボックス化する理由
なぜチームはAIエージェント専用のサンドボックスを使用するのですか？
AIエージェントは、実行されるコードが人間によって書かれ、実行前にレビューされないという点で、従来のソフトウェアとは根本的に異なります。LLMが指示を生成し、ツールを選択し、パッケージをインストールし、APIコールを動的に行います。多くの場合、アプリケーション開発者が事前に列挙していなかった方法で行われます。サンドボックスは、すべての可能なアクションを事前に承認する必要なく、それらのアクションの結果を封じ込めるランタイム強制レイヤーを提供します。サンドボックスがなければ、誤動作または操作されたエージェントがホストシステム、隣接するワークロード、または外部インフラストラクチャに影響を与える可能性があります。サンドボックスがあれば、最悪の爆発半径は分離された環境に限定され、セッション後に破棄できます。
AIエージェントのコード実行とは何ですか？
AIエージェントのコード実行は、LLMの決定が実際にコンピューターが実行する命令になるランタイムフェーズです。エージェントはタスクを受け取り、推論し、コードやツールコールを生成し、実行レイヤーがそれらのアクションを実行して結果をエージェントに返します。サンドボックスはこの実行フェーズの標準的なインフラストラクチャレイヤーです。エージェントが必要とする計算、ファイルシステム、ネットワーク環境を提供し、その環境を他のすべてから分離したままにします。「モデルが推論 → 実行レイヤーが実行 → 結果がモデルにフィードバック」というサイクルが、エージェントがタスクを完了するまで繰り返されます。
サンドボックス化は、単にエージェントをコンテナで実行することとどう違うのですか？
コンテナはファイルシステムとネットワーク名前空間の分離を追加しますが、同じホスト上のすべてのコンテナはOSカーネルを共有します。信頼できない入力からLLMが生成したコードを実行するAIエージェントの場合、共有された脆弱性を介したカーネルレベルの脱出が隣接するワークロードに影響を与える可能性があります。専用のAIエージェントサンドボックスは通常、マイクロVM境界を追加します。エージェントのコードは、独自のゲストカーネルを持つ軽量仮想マシン内で実行されるため、ゲストでのカーネルレベルの悪用がホストに影響を与えることはありません。実際的なトレードオフは、わずかな追加のコールドスタートオーバーヘッド（Firecrackerベースのプラットフォームでは通常500ms未満）です。完全な比較については、サンドボックス分離モデル セクションを参照してください。
サンドボックス分離モデル
AIエージェントサンドボックスにおける「分離」とはどういう意味ですか？
分離とは、エージェントのコード、ファイル、プロセス、ネットワークアクセスが、ホストシステムや他のテナントに影響を与えることができない境界のある環境に制限されることを意味します。実際には、分離はスペクトルです。プロセスレベルの分離はOSプリミティブ（名前空間、cgroups、seccomp）を使用してシステムコールとリソースアクセスを制限します。コンテナ分離はファイルシステムとネットワーク名前空間の境界を追加します。マイクロVM分離は、ワークロードを独自のゲストカーネルを持つ軽量仮想マシンでラップします。スタックを上がるごとに境界の強度が増しますが、起動オーバーヘッドと運用の複雑さが若干増加します。すべての分離次元の包括的な概要については、AIエージェントサンドボックスとは？ を参照してください。詳細な評価フレームワークについては、AIエージェントサンドボックス向けFirecracker をご覧ください。
Dockerはエージェント生成コードの実行に十分ですか？
コンテナは再現可能なイメージと優れたリソース制御を提供しますが、同じホスト上のすべてのコンテナはホストカーネルを共有します。カーネルの脆弱性や、seccompフィルターをすり抜けるシステムコールが他のワークロードに影響を与える可能性があります。低リスクで短命なタスクで、信頼された、またはほぼ信頼されたコードを実行する場合、適切に強化されていれば、コンテナは多くの場合十分です。特権モードなし、最小限のケイパビリティ、Dockerソケットのマウントなし、可能な限り読み取り専用のルートファイルシステム。パッケージをインストールしたり、サブプロセスを生成したり、任意のシェルコマンドを呼び出したりする可能性のある、信頼できないAI生成コードの場合は、より強力な境界を評価する価値があります。答えは実際の脅威モデルに依存します。各分離レベルでの検証チェックリストについては、AI生成コードサンドボックス：プロダクションアプリの要件 を参照してください。
コンテナとマイクロVMの分離の違いは何ですか？
主な違いはカーネル境界です。コンテナはホストカーネルを共有します。マイクロVMはそれぞれ、ハードウェア仮想化（KVM）をバックエンドとした軽量仮想マシン内でゲストカーネルを実行します。Firecrackerのような技術を使用したマイクロVMベースのサンドボックスは、従来のVMの完全なオーバーヘッドなしでVMスタイルの境界を提供します。起動レイテンシは高速になるように設計されており、デバイスモデルは攻撃面を減らすために最小限であり、ゲストは設計上、ホストカーネルから分離されています。実際的な意味は、ゲストでのカーネル悪用が自動的にホストや他のゲストに影響を与えないのに対し、共有カーネルコンテナモデルでは影響を与える可能性があるということです。マイクロVM境界が役立つ場面と、問題全体を解決しない場面については、AIエージェントサンドボックス向けFirecracker を参照してください。
サンドボックスはエージェントごと、ユーザーごと、またはタスクごとに存在しますか？
それはプラットフォームとアプリケーションの設計方法に依存します。マルチテナントアプリケーションの最も安全なパターンは、エージェントの実行ごと、またはタスクごとに1つの分離されたサンドボックス環境を使用することです。つまり、各ユーザーのセッションには独自のプロセスツリー、ファイルシステム、ネットワーク名前空間、および資格情報スコープがあります。サンドボックスをユーザー間や無関係なタスク間で共有することは、プロダクションエージェントアプリケーションにおける状態漏洩の最も一般的な原因です。プラットフォームを評価する際は、並行セッションがAPIルーティングレベルだけでなく、ファイルシステム、プロセス、およびネットワークレベルで分離されていることを確認してください。セッションごとの分離チェックリストについては、AI生成コードサンドボックス：プロダクションアプリの要件 を参照してください。
サンドボックスの外部通信とネットワークポリシー
AIエージェントはサンドボックスから外部ネットワーク呼び出しを行えますか？
それはサンドボックスの外部通信ポリシーに依存します。デフォルトでは、多くのサンドボックスは外部接続を許可しており、これはウェブ調査、APIコール、パッケージインストールに便利です。信頼できないコードを実行するプロダクションワークロードでは、デフォルトで開かれた外部通信はリスクです。侵害された、または誤動作しているエージェントがデータを外部に送信したり、内部メタデータサービスにアクセスしたり、任意のURLから予期しないコードをプルしたりする可能性があります。より強力なプロダクション姿勢は、デフォルト拒否の外部通信と、許可された宛先の明示的な許可リストです。どのポリシーを選択しても、明示的でログに記録されるべきです。ネットワーク制御の評価方法については、AIエージェントサンドボックス向けFirecracker を参照してください。
サンドボックス内でDNSはどのように制御されますか？
DNSは外部通信ポリシーの一般的なギャップです。HTTP宛先の許可リストは、DNS解決を自動的に制限しません。任意のドメイン名を解決できるエージェントは、ネットワークトポロジを推測し、内部名をプローブし、HTTPがブロックされていてもDNSをサイドチャネルとして使用する可能性があります。一貫性のある外部通信ポリシーのためには、DNS解決を一貫して処理する必要があります。許可リストを尊重する内部リゾルバを指すか、解決を承認されたドメインに制限します。サンドボックスプロバイダーに、DNSがより広範な外部通信ポリシーとどのように関連して範囲設定されているかを確認してください。
ネットワーク制限されたセッション中、パッケージフェッチはどのように制御されますか？
パッケージインストールはネットワーク操作です。外部通信が許可リストに制限されている場合、許可リストにはエージェントが正当に必要とするパッケージレジストリが含まれている必要があります。または、サンドボックスが信頼されたネットワーク内にプルスルーキャッシュを提供する必要があります。プルスルーキャッシュには、検査ポイントとして機能するという追加の利点があります。フェッチされるパッケージを確認し、予期しない依存関係をキャッチし、冗長な外部通信を削減できます。再現性が柔軟性よりも重要なワークロードでは、一部のチームは事前に焼き付けられたサンドボックステンプレートを使用し、ランタイムパッケージフェッチを完全に排除します。ランタイムインストールの管理については、パッケージインストール セクションを参照してください。
ファイルアクセスとホストファイルシステム
サンドボックス化されたエージェントにはどのようなファイルアクセスがありますか？
サンドボックス化されたエージェントは、そのワークスペースに明示的にマウントされたファイルにのみアクセスできる必要があります。コーディングエージェントの場合、それはチェックアウトされたリポジトリと生成されたアーティファクト用の作業ディレクトリかもしれません。データ分析エージェントの場合、それはアップロードされたCSVファイルと出力フォルダかもしれません。エージェントは、ホストファイルシステム、他のテナントのワークスペース、アプリケーションサーバーのシークレット、またはマウントされたパス外のシステムディレクトリに到達できないようにする必要があります。良い慣行は、ソースマテリアルを読み取り専用でマウントし、生成されたアーティファクト用に別の読み書き可能な出力ディレクトリを提供することです。ツールごとにファイルシステムマウントをスコープする方法については、MCPサーバーサンドボックス：ファイルシステム、シークレット、ネットワーク制御による分離されたMCPサーバー を参照してください。
ホストファイルシステムはサンドボックス内部からアクセス可能ですか？
アクセス可能であってはなりません。正しく構成されたサンドボックス（コンテナまたはマイクロVM）は、エージェントのビューを独自のゲストファイルシステムに制限します。サンドボックス内部からホストファイルシステムにアクセスすることは、設定ミスであり、期待される動作ではありません。この境界を破る一般的な間違いには、広範なディレクトリ（開発者のホームディレクトリや/など）のマウント、コンテナでの特権モードの使用、Dockerソケットのサンドボックスへのマウントが含まれます。プラットフォームを評価するか、独自に構築する場合は、何がマウントされているか、ルートファイルシステムの権限は何か、シンボリックリンクの脱出やアーカイブ抽出のトリックが意図されたワークスペース外のパスに到達できるかどうかを確認してください。
セッション終了後、ファイルはどうなりますか？
エフェメラルセッションの場合、作業ディレクトリと生成されたすべてのファイルはセッション終了時に破棄されます。これは、コード補完、評価実行、および継続性よりも再現性が重要なタスクにとって正しいデフォルトです。永続的なワークスペース（長時間実行されるコーディングエージェント、反復的な開発セッション）の場合、ファイルはセッション内の実行呼び出し間で存続し、プラットフォームがワークスペースの永続化またはスナップショットをサポートしている場合は、セッション終了後も保持される可能性があります。重要な質問は、保持されたワークスペースを誰が所有するか、いつクリーンアップされるか、あるユーザーのワークスペースが別のユーザーに漏洩する可能性があるかです。永続化モデルのチェックリストについては、AI生成コードサンドボックス：プロダクションアプリの要件 を参照してください。
セッション状態と永続化
サンドボックスセッションはステートフルですか、それともエフェメラルですか？
両方のパターンが存在し、異なるワークロードに役立ちます。エフェメラルセッションは、タスクごとにクリーンなベースラインから開始します。パッケージ、ファイル、履歴は蓄積されません。これらは推論が容易で、評価実行や単発のコード実行に最適です。ステートフルセッションは、ファイル、インストールされたパッケージ、シェル履歴、環境状態を複数の実行呼び出し間で保存します。これは、マルチステップのコーディングエージェント、インタラクティブなデータ分析、長時間実行されるワークフローに必要です。ほとんどのプロダクションプラットフォームは両方をサポートしています。トレードオフは、ステートフルセッションには明示的なクリーンアップポリシーとより慎重なテナント分離が必要なことです。
管理されたサンドボックスでは、状態はどのくらい持続しますか？
セッション期間はプラットフォームとプランによって異なります。一部のプロバイダーはデフォルトのセッションタイムアウト（一般的に60分から24時間）を設定しており、その後セッションは終了し、スナップショットや外部ストレージに永続化されない限り状態は失われます。長時間実行されるエージェントワークフロー（LLM呼び出しの間が数分から数時間一時停止する可能性があるセッション）では、アイドル時間の課金を避けながら状態を保存するために、セッションの一時停止と再開または自動一時停止をサポートするプラットフォームが必要です。最大セッション長と、タイムアウトが発生した場合の進行中の状態がどうなるかを確認してください。Novita Agent Sandboxは最大24時間のセッションをサポートし、アイドル時間管理のための一時停止/自動再開機能を文書化しています。機能比較については、Novita Sandbox: E2B Proのコスト効率の高い代替案、シームレスな互換性 を参照してください。
セッションは一時停止および再開できますか？
一部のプラットフォームは一時停止と再開をサポートしており、セッションがディスクに一時停止され、同じ状態から後で再開できます。これは、ステップ間でLLM応答を待つエージェント、高価なワークロードのレート制限、および時間をかけて複数のユーザーインタラクションにまたがるセッションに役立ちます。確認すべき重要な点は、一時停止されたセッションがどのくらいの期間停止状態を維持できるか、一時停止中に保持されたネットワーク接続はどうなるか、セッション開始時に注入された資格情報が再開後も有効か、それとも更新が必要かです。
サンドボックス状態はスナップショット化して再利用できますか？
テンプレートとスナップショットは関連していますが、異なります。テンプレートは事前に構築されたベースライン環境（ランタイム、ツール、承認されたパッケージ）であり、新しいセッションはそこから開始します。スナップショットは実行中のセッションの現在の状態をキャプチャし、将来のセッションの開始点として使用します。テンプレートはセッションごとの起動オーバーヘッドを削減し、すべてのエージェントが一貫した管理されたベースラインから開始することを保証します。スナップショットは、部分的な作業を保存したり、反復的なジョブをウォームスタートしたりするのに役立ちます。両方ともガバナンスが必要です。誰が作成できるか、誰が読み取れるか、どのテナントに属するか、バージョン管理はどうなっているか。
パッケージインストールとランタイム依存関係
エージェントはランタイムにパッケージをインストールできますか？
ほとんどのサンドボックス環境は、デフォルトでランタイムパッケージインストール（pip install、npm install、apt-getなど）を許可しています。なぜなら、多くのエージェントワークロードでそれらが必要だからです。問題はインストールが許可されているかどうかではなく、各インストールが管理されているかどうかです。管理されていないパッケージインストールは、サンドボックス内で最もリスクの高い操作の1つです。ランタイムに外部コードを実行環境にプルし、任意のコマンドを実行する可能性のあるインストール後スクリプトを含むことができ、サプライチェーンリスクをもたらす可能性があります。
ランタイムパッケージインストールを管理するポリシーは何ですか？
プロダクションパッケージポリシーには通常、レジストリ許可リスト（承認されたパッケージレジストリまたはミラーからのみフェッチ）、プルスルーキャッシュ（実行前に入力を検査）、インストールログ（すべてのインストールのパッケージ名、バージョン、ソース、結果を記録）、およびオプションのオフラインモード（依存関係をテンプレートに事前焼き付けし、再現性が重要な評価パイプラインではランタイムインストールを禁止）の組み合わせが含まれます。適切なポリシーはワークロードに依存します。コードのデバッグを支援するコーディングエージェントは柔軟なパッケージアクセスが必要かもしれません。自動評価パイプラインはおそらくフリーズされた環境から実行する必要があります。実際の実装例については、サンドボックス化されたPythonと制御されたパッケージアクセスでAIデータアナリストを構築する を参照してください。
シークレットと資格情報の取り扱い
サンドボックス内でシークレットと資格情報はどのように処理されますか？
シークレットは狭く注入されるべきです。特定のタスクが必要とする資格情報のみを、そのセッションの期間中のみ注入します。一般的なアンチパターンは、すべてのAPIキーを含む広範な環境ファイルをすべてのセッションにマウントすることです。これにより、侵害されたセッションがそのファイル内のすべての資格情報にアクセスできるようになります。タスクにスコープされた短命なトークンを優先し、ハードコーディングよりも注入メカニズム（環境変数またはマウントされたファイル）を優先します。最も機密性の高い資格情報については、明示的に承認されたプロセスにのみ値を提供するランタイムシークレットAPIが、すべてのプロセスが利用できるフラットな環境変数よりも強力な分離を提供します。
モデルはサンドボックスに注入された環境変数を参照できますか？
はい、環境変数がモデルのコードが実行されるプロセスに注入されている場合、参照できます。環境変数はデフォルトで同じセッション内のすべてのプロセスから見えます。モデルはコンテキストウィンドウから直接読み取ることはできませんが、サンドボックス内で実行される生成コードは、os.environ、process.env、または同等の方法でそれらを読み取ることができます。これが、スコープを狭くすることが重要な理由です。タスクが必要とする資格情報のみを注入し、短命なトークンを優先して、漏洩した資格情報の有用な時間枠を制限します。編集はアプリケーションの責任です。エラーメッセージやprint文にシークレットが表示される可能性がある場合は、デフォルトで完全なstdoutをログに記録しないでください。
セッション終了後、シークレットはどうなりますか？
環境変数とマウントされたシークレットファイルは、セッションティアダウンの一部としてクリーンアップされる必要があります。プラットフォームがセッション間で状態を保存する場合（スナップショット、永続ボリューム）、ファイルシステムに書き込まれた資格情報や資格情報プロバイダーによってキャッシュされたものもクリーンアップまたはローテーションされることを確認してください。再開可能なスナップショット内の古い資格情報はリスクです。セッションティアダウン後、スナップショットは元のセッション期間中のみ有効だったトークンを保持すべきではありません。
監査ログと可観測性
サンドボックスではどのようなイベントがログに記録されますか？
有用なサンドボックス監査記録には、セッション作成とティアダウン（セッションID、テナント、テンプレートバージョン、リソース割り当て、期間）、実行イベント（実行されたコードまたはコマンドカテゴリ、開始/終了時間、終了ステータス）、パッケージインストール（名前、バージョン、ソース、結果）、外部ネットワークコンタクト（ドメイン、IP、ポート）、特定のパスからのファイル読み取りまたは書き込み、およびクリーンアップ結果が含まれます。目標は、監査ログを2番目のシークレットストアにすることなく、エージェントの動作を事後的に再構築可能にすることです。生の顧客ファイル、完全なコマンド出力、完全なプロンプトは、通常、監査ログに含めるべきではありません。保持とアクセス制御が特にそのデータ向けに設計されている場合を除きます。
誰が監査ログにアクセスできますか？
監査ログのアクセス制御は、オペレーターと、関連する場合はテナントにスコープされるべきです。マルチテナントプラットフォームでは、あるテナントの監査記録は他のテナントから見えてはなりません。コンプライアンスに敏感なデプロイメントでは、監査証跡は改ざん防止可能で、必要な期間保持され、承認されたレビュー担当者（セキュリティチーム、コンプライアンス責任者）がオンデマンドでアクセスできる必要があります。サンドボックスプロバイダーに、デフォルトで提供されるログ保持期間、ログを独自のSIEMまたはストレージにエクスポートできるかどうか、およびログデータを保護するアクセス制御について尋ねてください。
コンプライアンスとセキュリティレビュー
プロダクションでサンドボックスを使用する前に、どのようなコンプライアンスレビューが必要ですか？
特定の要件は業界と管轄区域によって異なりますが、あらゆるプロダクションエージェントシステムの標準的な質問には以下が含まれます。サンドボックスに入るデータは何か（そのデータはGDPR、HIPAA、SOC 2、またはその他のフレームワークの対象か）、サンドボックスはどこでホストされ、データ所在地要件を満たしているか、分離モデルは何か、監査可能か、資格情報はどのように管理およびローテーションされるか、監査証跡はどのようなものか。ほとんどのセキュリティレビューでは、生成コードがプロダクションデータベース、内部管理画面、または意図された範囲外の顧客データに到達する可能性があるかどうかも尋ねられます。これらはベンダー認定だけでなく、アーキテクチャ上の制御です。
AIエージェントサンドボックスを評価する際に、セキュリティチームはどのような質問をすべきですか？
セキュリティレビューのための実用的な評価チェックリスト：
- 分離: 境界は何か（プロセス、コンテナ、マイクロVM）？各エージェントセッションはファイルシステム、プロセス、ネットワークレベルで分離されているか？
- 外部通信: デフォルトの外部通信ポリシーは？外部宛先を許可リストに登録できるか？DNSはどのように制御されているか？
- シークレット: 資格情報はどのように注入されるか？タスクにスコープされているか？セッションティアダウン時にクリーンアップされるか？
- 監査: どのイベントがログに記録されるか？誰がログにアクセスできるか？保持期間は？
- データ所在地: サンドボックスはどこでホストされているか？デプロイメントを特定のクラウドリージョンまたはアカウントにスコープできるか？
- コンプライアンス体制: プロバイダーは関連する認定（SOC 2、ISO 27001）を保持しているか？共有責任モデルは？
- ネットワーク到達範囲: サンドボックスは内部メタデータサービス、プライベートAPI、他のテナントのリソースに到達できるか？横方向の移動はどのように防止されるか？
これらは、単一のベンダーが自動的に満たす要件としてではなく、評価するための質問としてフレーム化してください。ベンダー文書内のセキュリティとコンプライアンスの主張は、現在の製品文書に対して検証する必要があり、額面通りに受け取るべきではありません。規制上または契約上の要件があるチームは、プロダクションデプロイメントの前ではなく、後にセキュリティチームにレビューを完了させるのではなく、事前に完了させてください。
BYOC（クラウド持ち込み）またはVPCデプロイメントはいつ関連しますか？
データ所在地要件、ネットワークセキュリティポリシー、またはデータが特定のクラウドアカウントから離れることを禁止する規制上の制約が、チームが共有管理サービスよりもBYOCまたはVPCデプロイメントを選択する主な理由です。独自のAWSまたはGCP VPC内でサンドボックスを実行することは、実行環境がネットワーク境界内にあり、クラウドアカウントのアクセス制御が適用され、サンドボックスからの外部通信を既存のネットワークポリシーで管理できることを意味します。トレードオフは運用上の責任です。インフラストラクチャ管理、パッチ適用、スケーリングを自分で行う必要があります。Novita Agent Sandboxは、これらの要件を持つチーム向けの機能として、AWSまたはGCPアカウントへのBYOCデプロイメントを文書化しています。現在の可用性と構成オプションは、Novita Agent Sandboxドキュメント で確認してください。
サンドボックスの価格設定とコスト要因
サンドボックスのコストを決定するものは何ですか？
サンドボックスコストは通常、コンピュート時間（vCPUとメモリ、秒または分単位で課金）、セッションオーバーヘッド（一部のプラットフォームではセッションごとの起動料金）、含まれる無料枠を超える永続ストレージ、および外部データ転送（エグレス）の組み合わせです。それぞれの相対的な重みはワークロードに依存します。短いセッションのコードインタプリタは主にコンピュートです。大きなファイルをダウンロードするブラウザ自動化エージェントは、かなりのエグレスを生成する可能性があります。永続的なコーディングワークスペースはストレージを蓄積します。アイドル時間の処理は主要な差別化要因です。自動一時停止を備えたプラットフォームは、サンドボックスがLLM応答を待っている間の課金を停止するため、インタラクティブなワークフローのコストを大幅に削減できます。各価格軸の詳細な内訳については、AIエージェントサンドボックスの価格モデル：セッション、コンピュート、ストレージ、エグレス を参照してください。
セッション時間、コンピュート、エグレスはコストにどのように相互作用しますか？
ほとんどのワークロードでは、コンピュート時間が支配的です。1 vCPUでの10分間のコーディングセッションは、通常のレートでの1 GBのエグレスよりもコストがかかります。しかし、特定のワークロードでは相互作用が重要です。大規模なトレーニングデータセットをダウンロードするデータエージェントは、コンピュートコストをはるかに超えるエグレス料金を生成します。LLMターン間でセッションを開いたままにするブラウザエージェントは、自動一時停止が有効になっていない場合、アイドルコンピュートを蓄積します。実際的なアプローチは、プラットフォームにコミットする前に、実際のワークロードプロファイルに対して各次元を見積もることです。Novita Agent Sandboxは、実際のvCPUとメモリ使用量に基づいて秒単位で課金し、セッションごとの起動料金はありません。2026年半ば現在、1 vCPUは$0.0000098/sで価格設定されています（出典：Novita AIの価格ページ、公開文書で確認済み。予算計画の前に必ず最新のレートを確認してください）。
セルフホスティング vs. 管理型AIエージェントサンドボックス
チームは管理型サンドボックスではなく、いつセルフホスティングを選択すべきですか？
セルフホスティング（多くの場合Firecrackerまたは同等のマイクロVMレイヤー上で独自のサンドボックスインフラストラクチャを実行すること）は、以下の場合に適しています。データ所在地またはネットワークポリシー要件によりサードパーティ管理サービスの使用が禁止されている場合、ワークロード量が多く、管理サービスのコストが独自のインフラストラクチャを運用するコストを上回る場合、またはチームに既存のプラットフォームエンジニアリング能力があり、分離モデル、イメージガバナンス、ネットワークポリシーを完全に制御したい場合。セルフホスティングは見かけよりも困難です。カーネル、ルートファイルシステム、イメージ、スナップショット、レートリミッター、メトリクス、クリーンアップ、マルチテナント分離の管理は、実際の作業です。運用範囲の詳細については、AIエージェントサンドボックス向けFirecracker を参照してください。
管理型サンドボックスはいつ適していますか？
コーディングエージェント、データ分析ツール、ブラウザ自動化ワークフロー、または評価パイプラインを構築するほとんどのチームにとって、管理型サンドボックスはプロダクションへのより迅速な道です。プラットフォームがインフラストラクチャプロビジョニング、セキュリティ強化、イメージ更新、スケーリング、ライフサイクル管理を処理します。チームはサンドボックス内部ではなく、エージェントアーキテクチャに集中できます。コスト比較は単なるクラウドコンピュートレートだけではありません。分離レイヤーを構築および維持するためのエンジニアリング時間、それを文書化するためのコンプライアンス作業、および予期しないことが発生した場合のインシデント対応を考慮に入れてください。専任のプラットフォームエンジニアリング能力のないチームにとって、管理サービスは通常、より迅速にプロダクションに到達し、より低い総所有コストを維持します。管理型 vs. セルフホスティングの総コストを比較するフレームワークについては、AIエージェントサンドボックスの価格モデル を参照してください。
管理型サンドボックスプロバイダーを評価する際に、チームはどのような質問をすべきですか？
表面的な価格設定を超えた実用的な評価質問：
- セッションごとの分離モデルは何か（マイクロVM、コンテナ、プロセス）？
- デフォルトおよび構成可能な外部通信ポリシーは？
- どのようなパッケージインストールガバナンスオプションがあるか？
- シークレットはどのように注入およびクリーンアップされるか？
- どのような監査ログデータが利用可能で、どのようにアクセスするか？
- 必要なティアでのセッション長と同時実行制限は？
- プロバイダーはBYOCまたはVPCデプロイメントをサポートしているか？
- 一時停止/再開の動作はどうで、課金にどのように影響するか？
- スケール時（ウォームプール、スナップショット、コールドブート）の起動レイテンシはどうか？
信頼できないコードの安全な実行
プロダクションでAI生成コードを安全に実行するにはどうすればよいですか？
基本は、LLM生成コードをホスト上で実行しないことです。すべての実行を、ファイルシステム、プロセス、ネットワークの分離を提供するサンドボックス経由でルーティングします。それ以外に、意味のある違いを生む5つのベストプラクティスがあります。（1）外部通信ポリシーを明示的に設定する。デフォルト拒否と許可リストがデフォルト公開よりも安全です。（2）シークレットのスコープを狭くする。現在のタスクが必要とする資格情報のみを注入します。（3）パッケージインストールを管理する。承認されたレジストリからのインストールを許可するか、再現可能なワークロードには事前に焼き付けられたイメージを使用します。（4）アプリケーションレベルのログではなく、カーネルまたはハイパーバイザーレベルでログを記録します。（5）リソース制限（CPU、メモリ、ディスク、ウォールクロックタイムアウト）を設定し、暴走エージェントが隣接するセッションに影響を与えないようにします。完全な評価チェックリストについては、AIサンドボックスはコード実行に対してどの程度安全か？ を参照してください。
オープンソースのAIエージェントサンドボックスはありますか？
はい。DaytonaはAGPLライセンスの下でオープンソースであり、セルフホスティングデプロイメントをサポートしています。E2BのコアSDKはオープンソースですが、管理されたランタイムインフラストラクチャはそうではありません。ゼロから独自のサンドボックスを構築したい場合、最も一般的なアプローチは、Firecracker（AWS開発、Apache 2.0ライセンス）をマイクロVMランタイムとして使用し、独自のイメージ管理、オーケストレーション、ライフサイクル制御を組み合わせることです。セルフホスティングは、管理サービスが抽象化する運用範囲を引き受けることを意味します。カーネル管理、ルートファイルシステムガバナンス、レート制限、スナップショットストレージ、クリーンアップポリシー、マルチテナント分離などです。その範囲が実際にどのようなものかについては、AIエージェントサンドボックス向けFirecracker を参照してください。
管理型AIサンドボックスプラットフォームとは何ですか？
管理型AIサンドボックスプラットフォームは、サンドボックスインフラストラクチャをAPIとして提供するクラウドサービスです。SDKを呼び出すと、サンドボックスがプロビジョニングされ、準備完了状態で返され、プラットフォームが基盤となるコンピュート、ネットワーキング、イメージ管理、ライフサイクルを処理します。Novita Agent Sandbox、E2B、Daytonaの管理モードが例です。代替手段はセルフホスティングであり、サンドボックスインフラストラクチャを自分でプロビジョニングおよび運用します。管理型プラットフォームに関する重要な質問は、使用する分離モデル、構成可能な外部通信ポリシー、BYOCまたはVPCデプロイメントが利用可能かどうか、予想されるワークロードに対する秒単位の価格設定はどうかです。構造化された比較については、2026年におけるベストAIエージェントサンドボックス を参照してください。
エンタープライズ向けAIエージェントサンドボックスとは何ですか？
エンタープライズAIエージェントサンドボックスの要件は通常、開発者向け管理サービスがデフォルトで提供するものを超えます。一般的な要件には以下が含まれます。BYOCまたはVPCデプロイメント（サンドボックスは共有サードパーティテナントではなく、自社のクラウドアカウント内で実行される）、SOC 2またはISO 27001認証、構成可能な外部通信ポリシーとSIEMへの監査ログエクスポート、短命トークンによるセッションレベルの資格情報スコーピング、エージェントワークロードの実行場所を制限するデータ所在地制御。Novita Agent Sandbox は、独自のAWSまたはGCP VPCへのBYOCデプロイメントをサポートしており、最も一般的なエンタープライズデータ所在地とネットワーク分離要件に対応します。アーキテクチャ上の決定を行う前に、製品ドキュメント で現在のコンプライアンス認証と利用可能な構成オプションを確認してください。
