最適なAIサンドボックスソリューションとは、ワークロードの隔離要件、運用許容度、コストモデルに合致するものであり、汎用的なリストで1位になるものではありません。マルチテナントアプリでの短いコード実行には、軽量なマネージドmicroVMサービスが適していることが多いです。RL（強化学習）や評価パイプラインで1時間に数百ものサンドボックスを起動する場合、同時実行数やセッションごとの料金が機能の豊富さよりもはるかに重要になります。厳格なコンプライアンス要件やVPC制約のあるチームにとっては、セルフホストまたはBYOC（自社クラウド環境）へのデプロイによってトレードオフが完全に変わります。このガイドでは、主要なカテゴリのAIサンドボックスソリューションと、意思決定の基準となるユースケースおよび評価軸をマッピングします。
どのような種類のAIサンドボックスソリューションが存在するのか？
マネージドクラウドサンドボックス
マネージドクラウドサンドボックスは、プロバイダーがVMプロビジョニング、ライフサイクル管理、ネットワーキング、スケーリングといったすべてのインフラを管理するAPIファーストのサービスです。SDKを呼び出してサンドボックスを作成し、その中でコードやコマンドを実行すると、プラットフォームが後片付けを行います。
実用的な利点は、統合が迅速であることです。管理するクラスタも、チューニングするスケーリングポリシーも、維持するVMイメージもありません。セッションごと、または消費したコンピュートユニットごとに支払います。
制約としては、プロバイダーの共有インフラ上で動作するため、ネットワークエグレス、パッケージインストール、リソース制限、セッション期間に関するプロバイダーのポリシーに従う必要があります。VPC要件や厳格なデータ主権制約があるチームは、限界に直面する可能性があります。
一般的に適している用途：コーディングエージェント、ブラウザ自動化、データ分析パイプライン、LLM評価ハーネス。
このカテゴリの例としては、E2B、Daytona（マネージドモード）、Novita Agent Sandboxなどがあります。
セルフホストのオープンソースオプション
セルフホストサンドボックスは、サンドボックスインフラを自社のクラウドアカウント、オンプレミス、またはVPC内で実行できるようにします。一般的なアプローチとしては、Dockerベースのコンテナ分離、FirecrackerマイクロVMランタイム、またはgVisorベースのシステムがあります。
トレードオフは運用負荷です。プロビジョニング、パッチ適用、スケーリング、監視可能性、障害処理を引き受けることになります。プラットフォームエンジニアリングのキャパシティがあり、真のコンプライアンス要件（エアギャップ環境、規制対象データの取り扱い、またはサードパーティのコード実行を禁止する組織ポリシー）があるチームにとって、セルフホストが唯一の実行可能な道であることがよくあります。
セルフホストは、スケール時のコスト管理をより厳密に行えるという利点もあります。インフラがプロビジョニングされれば、サンドボックスあたりの限界費用はクラウドコンピュートのみです。高い同時実行性では、その利点が運用オーバーヘッドを相殺できます。
一般的に適している用途：厳格なデータ主権やコンプライアンス要件を持つエンタープライズ、運用への投資が報われる大規模チーム。
組み込みインタプリタサンドボックス
組み込みインタプリタサンドボックスは、制御された環境内で特定の言語ランタイム（最も一般的にはPythonまたはJavaScript）への実行を制限します。これらは、汎用的なエージェントワークロードではなく、狭く予測可能なコード実行のために設計されています。
例としては、Pyodide（WebAssembly経由のPython）、Denoの権限ゲートランタイム、およびさまざまなREPL-as-a-service統合があります。これらは統合が迅速で、呼び出し元のプロセスに近い場所で実行されるため、場合によっては完全にブラウザ内で動作するため、インフラのオーバーヘッドが最小限です。
制限は範囲です。組み込みインタプリタサンドボックスは通常、任意のパッケージをインストールしたり、シェルコマンドを実行したり、バックグラウンドプロセスを開始したり、永続的なファイルシステムを管理したり、ステートフルなマルチステップワークフローを処理したりできません。「LLMにPythonを書かせて安全に実行させる」というシンプルなユースケースには機能しますが、本格的なコーディングエージェントやコンピュータ使用ワークフローに似たものには、すぐに限界に達します。
一般的に適している用途：コード説明機能、LLM支援計算機、シンプルなブラウザ内REPLデモ。
フルエージェントランタイムサンドボックス
フルエージェントランタイムサンドボックスは、隔離されたコード実行を超えた機能を提供します。ファイルシステム、バックグラウンドプロセスサポート、パッケージインストール機能、ネットワークアクセス、ブラウザ環境、場合によってはデスクトップGUIを備えたステートフルなワークスペースを、すべて隔離されたVM境界内で提供します。
これらは、エージェントがアクションを実行し、結果を観察し、多くのターンにわたって継続する必要があるマルチステップワークフロー向けに設計されています。ファイルを編集し、テストを実行し、変更をコミットするコーディングエージェント、Webインターフェースを段階的に操作するブラウザエージェント、または並行して何百ものエピソードを実行するRL評価ハーネスなどは、すべてフルエージェントランタイム機能の恩恵を受けます。
表面積が大きいということは、評価すべき項目も多いことを意味します。分離モデル、セッションのステートフル性、ネットワークエグレスポリシー、パッケージインストール動作、一時停止/再開サポート、同時実行制限などがすべて重要です。これらはまた、料金モデルの複雑さが最も高いサンドボックスでもあります。
一般的に適している用途：コーディングエージェント、コンピュータ使用エージェント、ブラウザ自動化、RLおよび評価パイプライン、長時間実行されるマルチステップエージェントワークフロー。
AIサンドボックスソリューションの評価方法
AIサンドボックスソリューションを比較する際に、実際に本番環境の動作とコストに影響を与える評価軸を以下に示します。
| 評価軸 | 確認すべき点 |
|---|---|
| 分離モデル | VM境界（マイクロVM、フルVM） vs コンテナ vs プロセス分離。マルチテナントのセキュリティと被害範囲に影響します。 |
| セッションのステートフル性 | ファイルシステムはツールコールやLLMターン間で永続化されますか？サンドボックスは中断したところから再開しますか、それとも各コールで新しく始まりますか？ |
| 起動レイテンシ | API呼び出しからサンドボックスが準備完了になるまでの時間。インタラクティブなワークフローに影響します。バッチ評価ではあまり重要ではありません。 |
| エグレス/ネットワーク制御 | デフォルトでアウトバウンドネットワークは許可されていますか？特定のドメインへのエグレスを制限できますか？プロバイダーはエグレスに課金しますか？ |
| パッケージインストールポリシー | エージェントは実行時に任意のパッケージをインストールできますか？毎回のセッションでインストール時間を支払わないためのテンプレート/スナップショットシステムはありますか？ |
| 言語とランタイムのサポート | Python、Node.js、シェル、ブラウザ — どのランタイムがファーストクラスですか？追加のセットアップが必要なものはありますか？ |
| セッション期間と同時実行数 | 各料金ティアでの最大セッション長。同時実行数の制限と引き上げの可否。 |
| リソース構成の柔軟性 | vCPUとメモリをサンドボックスごとに個別に設定できますか？最小/最大割り当ては？ |
| 一時停止/再開とスナップショット | 実行中のセッションを状態を失わずに一時停止および再開できますか？起動コストを削減するためにテンプレートやスナップショットは利用可能ですか？ |
| SDKとAPIの品質 | 使用言語の公式SDK、安定したAPIバージョニング、認証モデル、ドキュメントの品質。 |
| 監視可能性 | プラットフォーム内またはエクスポートによるログ、イベント、セッションメトリクス、使用状況の可視性。 |
| 料金モデル | 秒単位のコンピュート、セッション料金、サブスクリプション階層、ストレージコスト、エグレス料金。単一の指標で総コストを把握することはできません — ワークロードプロファイルに合わせた組み合わせ全体を評価してください。 |
| デプロイモデル | 完全マネージドクラウド、BYOC（自社のAWS/GCPアカウント）、またはセルフホスト。 |
| セキュリティとコンプライアンス | SOC 2、データ主権、監査ログの利用可能性、VPCサポート。 |
あなたのユースケースに合ったAIサンドボックスはどれか？
さまざまなAIワークロードによって、これらの評価軸の重要度は異なります。これを最終的なランキングではなく、評価の出発点として使用してください。
| ユースケース | 最も重要な評価軸 | カテゴリ適合 |
|---|---|---|
| 短いコード実行（LLM生成のPython、JS） | 起動レイテンシ、セッションごとのコスト、言語サポート | マネージドクラウドまたは組み込みインタプリタ |
| データ分析エージェント | セッションのステートフル性、パッケージインストール、メモリ設定、ランタイムサポート | マネージドクラウドまたはフルエージェントランタイム |
| コーディングエージェント（ファイル編集、テスト実行、コミット） | ファイルシステムの永続性、シェルアクセス、パッケージインストール、セッション期間 | フルエージェントランタイム |
| ブラウザ自動化 / コンピュータ使用 | ブラウザ環境、視覚的出力、ステートフル性、セッション期間 | フルエージェントランタイム |
| RL / 評価パイプライン | 同時実行制限、セッションごとのコスト、起動レイテンシ、テンプレートサポート | マネージドクラウドまたはフルエージェントランタイム |
| セキュリティ重視のエンタープライズ | 分離モデル、BYOC/VPCサポート、監査ログ、コンプライアンス認証 | セルフホストまたはBYOC対応マネージドクラウド |
重要な洞察：マルチステップの状態、ファイル永続性、パッケージインストールを必要とするユースケースは、フルエージェントランタイムサンドボックスへと向かいます。短いセッションで高い同時実行性を必要とするユースケースは、セッションあたりのオーバーヘッドが低く、テンプレート/スナップショットのサポートが優れたソリューションへと向かいます。セキュリティ主導の要件は、どの機能セットが最適かにかかわらず、BYOCまたはセルフホストへと向かいます。
Novita Agent Sandboxの位置づけ
Novita Agent Sandboxは、フルエージェントランタイムカテゴリのマネージドクラウドサンドボックスです。AIエージェントスタートアップ、コーディングエージェントチーム、ブラウザエージェント開発者、評価/RLインフラストラクチャ向けに位置づけられています。
現在の製品ドキュメントに基づくと、Novita Agent Sandboxは以下をサポートしています：
- Pythonとシェルアクセスによるコード実行
- マルチステップエージェントワークフロー全体でのファイルシステム永続性
- ブラウザ自動化サポート
- サンドボックスごとに設定可能なvCPUとメモリ（カスタムリソース設定にアクセスするためにサブスクリプションは不要）
- 最大24時間のセッション長
- アイドル時間の課金を減らすための一時停止/再開と自動一時停止
- 繰り返しのパッケージインストール時間を回避するスナップショットテンプレート
- 自社のAWSまたはGCPアカウントへのBYOCデプロイ（VPCやコンプライアンス要件があるチーム向け）
- E2B互換のSDKインターフェース。これにより、すでにE2Bを使用しているチームの移行摩擦が軽減されます
料金について：Novitaは、実際のvCPUとメモリ使用量に基づいて秒単位で課金し、月額サブスクリプションは必要ありません。現在の料金はnovita.ai/sandboxに記載されています — 最新のレートについてはそのページを確認してください。この市場のサンドボックス料金は頻繁に変更されます。
Novitaが適しているケース： コーディングエージェント、データ分析エージェント、またはブラウザ自動化を構築しており、月額サブスクリプションの最低料金なしでマネージドクラウドソリューションを希望するチーム。すでにE2B SDKを使用しており、互換性のある代替案を評価したいチーム。VPCやコンプライアンスの理由でBYOCが必要だが、それ以外ではマネージドインフラを好むチーム。
他のオプションが適している可能性があるケース： E2Bの特定のSDKエコシステムやエンタープライズサポート階層に深くコミットしているチーム。BYOCでは不十分なオンプレミスまたはエアギャップデプロイメントの要件があるチーム。GPUサンドボックス要件があるワークロード（サポートを想定する前に、現在のNovita GPUサンドボックスの可用性を確認してください）。オープンソースまたはセルフホストのポリシーにより、管理プロバイダーを一切除外するチーム。
マネージド vs セルフホストAIサンドボックス：それぞれを選ぶべき時
マネージドサンドボックスサービスはインフラ作業を排除しますが、トレードオフがあります。共有インフラ上で動作し、プロバイダーのポリシー決定に従い、クラスタを所有するのではなくコンピュートユニットごとに支払うことになります。
セルフホストサンドボックス（またはクラウドアカウントを提供するBYOCモデル）は、運用責任をチームに移します。その計算は以下に依存します：
コンプライアンスとデータ要件。 規制要件によりコードやデータをサードパーティに送信することが禁止されている場合、セルフホストまたはBYOCのみが選択肢となります。マネージドプロバイダーのBYOCオプションは、この課題を解決できることがあります。プロバイダーのソフトウェアはVPC内で実行されますが、インフラはユーザーが所有します。
スケールとコスト。 非常に高いサンドボックスボリュームでは、インフラを所有することでサンドボックスあたりの限界費用が削減されます。そこに到達するための運用オーバーヘッド（プロビジョニング、自動スケーリング、パッチ適用、監視可能性）は現実のものです。月間数百万セッション未満のほとんどのチームにとって、エンジニアリング時間を考慮すると、マネージド料金は一般的に競争力があります。
機能要件。 カスタム分離ポリシー、プライベートパッケージレジストリ、特定の監査ログ形式など、一部の機能はセルフホストインフラで実装する方が簡単です。マネージドプロバイダーは迅速に動きますが、すべての調整ノブを公開しているとは限りません。
チーム規模とプラットフォームエンジニアリング能力。 Firecrackerベースのサンドボックスランタイムをセルフホストすることは簡単ではありません。その運用負荷は、専任のプラットフォームエンジニアリングチームを持つ場合に適しています。2人でコーディングエージェントスタートアップを運営しているチームにとって、その時間投資が正当化されることはほとんどありません。
実用的な道筋：コンプライアンスが主な理由であれば、BYOC対応のマネージドプロバイダーから始めてください。これにより、プロバイダーの共有インフラにデータを置かずに、マネージドインターフェースを利用できます。BYOCが特定のコンプライアンス要件を満たさない場合にのみ、完全なセルフホストに移行してください。
サンドボックスを決定する前の評価チェックリスト
サインアップしたり、本番ワークロードを移行したりする前に、これらを確認してください：
分離
- VM/コンテナの境界は何か？マイクロVM、コンテナ、それともプロセスレベル？
- 分離はテナントごと、セッションごと、それともチームごと？
セッションライフサイクル
- ファイルシステムの状態はセッション内のツールコール間で永続化されるか？
- サンドボックスはセッション期限切れをどのように処理するか — 正常終了か強制終了か？
- 一時停止/再開はサポートされているか？再開レイテンシは？
パッケージとランタイム
- エージェントは実行時に任意のパッケージをインストールできるか？
- プリインストール環境用のテンプレートやスナップショットは利用可能か？
- テンプレートビルドはどのように課金されるか？
ネットワーク
- デフォルトでアウトバウンドネットワークは許可されているか？
- エグレスを特定のドメインやIPに制限できるか？
- エグレスは別途課金されるか？
同時実行数と制限
- プランレベルでの同時実行制限は？
- 引き上げは可能か？そのコストは？
- 最大セッション期間は？
料金
- コンピュート時間とは別にセッション料金があるか？
- カスタムリソース設定にアクセスするための月額サブスクリプションの最低料金はあるか？
- ストレージはどのように課金されるか？
- 現在のレートはいつ最後に更新されたか？
デプロイ
- BYOCまたはセルフホストデプロイは利用可能か？
- BYOCはどのクラウドプロバイダーをサポートしているか？
コンプライアンス
- どのような認証が取得されているか（SOC 2、ISO 27001）？
- 監査ログは利用可能か？どのような形式か？
- データ処理契約は利用可能か？
FAQ
AIサンドボックスソリューションとは何ですか？
AIサンドボックスは、AIエージェントがホストシステムに影響を与えることなく、コードの実行、ファイルの管理、パッケージのインストール、ブラウザやその他のインターフェースとの対話を行える、隔離された実行環境です。サンドボックスは、信頼できない生成コードからホストを保護し、評価のための再現可能な環境を提供し、マルチテナントのエージェントワークロードが互いに干渉せずに並行して実行できるようにします。
マネージドサンドボックスとセルフホストサンドボックスの違いは何ですか？
マネージドサンドボックスサービスは、プロビジョニング、スケーリング、パッチ適用、監視可能性といったインフラを処理し、消費したコンピュートまたはセッションに対して課金します。APIを呼び出してサンドボックスを作成すると、プロバイダーが残りすべてを処理します。セルフホストサンドボックスは、ユーザーが制御するインフラ（クラウドアカウント、VPC、またはオンプレミス環境）で実行されます。より多くの制御と、スケール時には潜在的に低い限界費用が得られますが、すべての運用責任を負うことになります。
microVMベースのサンドボックスが必要ですか、それともコンテナで十分ですか？
脅威モデルによります。コンテナ分離（Dockerなどを使用）は、コードが信頼されている内部ツールや行儀の良いエージェントに適しています。MicroVM分離（FirecrackerやQEMUを使用）は、より強力な境界を提供します — サンドボックスごとに個別のゲストカーネル — これにより、マルチテナント環境で信頼できないコードやLLM生成コードを実行する際の被害範囲が減少します。本番環境のコーディングエージェント、ブラウザ自動化、またはエージェントのコードが完全に予測可能でないワークロードでは、microVMレベルの分離はわずかに高いオーバーヘッドに見合う価値があります。
異なるサンドボックスプロバイダー間での料金はどのように評価すべきですか？
見かけのレートだけでなく、特定のワークロード形状に対するコストプロファイル全体を比較してください。主要な変数：秒単位のコンピュートレート、セッション最低料金、カスタムリソース設定のロック解除に必要な月額サブスクリプション要件、ストレージ料金、エグレス料金、アイドル時間の処理。自動一時停止機能を持つプロバイダーは、実行ステップ間にLLM待ち時間があるワークロードのコストを大幅に削減できます。現在の料金ページを直接確認してください — この市場のレートは変動し、マーケティングサマリーは遅れることがよくあります。
AIサンドボックスにおけるBYOCとはどういう意味ですか？
BYOC（Bring Your Own Cloud）とは、サンドボックスサービスがプロバイダーの共有インフラではなく、ユーザー自身のクラウドアカウント（例えば、AWS VPCやGCPプロジェクト）で実行されることを意味します。プロバイダーのソフトウェアがプロビジョニングと管理を処理しますが、コンピュートはユーザーのアカウントで実行され、データはVPC内に留まり、基盤となるインフラの課金可視性を保持します。これは、データ主権要件、VPCセキュリティポリシー、またはサードパーティの共有インフラを排除するコンプライアンス制約があるチームにとって重要です。
