オープンソースのAIエージェントサンドボックスを評価するチームは、まず実際の分離境界、ワークスペースの永続性モデル、エグレスとパッケージの制御、シークレットの取り扱い、監査可能性、そして安全に運用するために必要な運用負荷を確認すべきです。適切な選択とは、普遍的な勝者を見つけることではなく、脅威モデル、エージェントのワークロード、コンプライアンス要件、およびエンジニアリング能力にサンドボックスモデルをマッチングさせることにあります。
AIエージェントサンドボックスとは何か？
AIエージェントサンドボックスとは、エージェントがコードを実行し、ファイルを検査し、ブラウザを自動化し、ツールを呼び出し、タスクを完了する際に、ホストマシンや本番ネットワークへの広範なアクセス権を与えられずに済む実行環境です。それは、モデルの推論と現実世界への副作用との間の境界です。
この境界が重要となるのは、現代のエージェントが単にテキストを書く以上のことを行うからです。コーディングエージェントはリポジトリをクローンし、依存関係をインストールし、テストを実行し、プレビューポートを開き、プルリクエストを作成するかもしれません。ブラウザエージェントやデータエージェントはスクリプトを実行し、状態を保持し、ファイルをダウンロードし、スクリーンショットをキャプチャするかもしれません。これらのアクションにはランタイムが必要であり、ランタイムには制御が必要です。
評価のためには、4つのレイヤーを分けて考えてください。
| レイヤー | 決定事項 | 重要性 |
|---|---|---|
| エージェントフレームワーク | モデルがどのように計画し、ツールを呼び出し、結果に反応するか | 優れたフレームワークが自動的に安全なランタイムを作り出すわけではない |
| サンドボックスランタイム | コマンド、ファイル、ブラウザセッション、プロセスが実行される場所 | これが主要な分離とライフサイクルの境界となる |
| ポリシープレーン | サンドボックスが読み取り、取得、インストール、公開、保持できるもの | サンドボックスがリスクモデルに合致するかを決定する |
| レビュープレーン | 実行後に利用可能なログ、差分、アーティファクト、承認 | 人間が何が起こったかを検証できるかを決定する |
セルフホストおよびオープンソースの選択肢は、これらのレイヤーに対するより多くの制御をチームに提供します。同時に、より多くの責任を運用するチームに移すことにもなります。
セルフホスティングはいつ意味があるのか？
セルフホスティングは、チームがデプロイ場所、ネットワークパス、ベースイメージ、保持ルール、ログシステム、または内部セキュリティレビューを直接制御する必要がある場合に合理的です。
実際の要件が単に「エージェントにコードを安全に実行させる」ことである場合、セルフホスティングはあまり魅力的ではありません。その場合、マネージドサンドボックスの方が運用が容易かもしれません。なぜなら、プロバイダーがプロビジョニング、スケーリング、ランタイム更新、アップタイム、および開発者体験の一部を処理するからです。
以下の少なくとも1つが当てはまる場合にセルフホスティングを使用してください。
- ポリシーにより、特定のクラウドアカウント、VPC、リージョン、またはプライベートネットワーク内での実行が要求される。
- エージェントにカスタムベースイメージ、内部パッケージミラー、プライベートソースシステム、または内部ブラウザターゲットが必要である。
- セキュリティチームが分離スタック、エグレスパス、保持モデル、およびログを検査したいと考えている。
- ランタイムコンポーネントのパッチ適用、不正使用シグナルの監視、シークレットのローテーション、障害のデバッグを行うためのエンジニアリング能力がある。
運用作業をスタッフでまかなえない場合は、デフォルトでセルフホスティングを避けてください。サンドボックスは、単一のコンテナやVMがコマンドを実行できるため、デモ中はシンプルに見えます。しかし、本番環境は異なります。同時実行制限、リソースクォータ、イメージクリーンアップ、パッケージキャッシュ戦略、ネットワークポリシー、シークレットのスコープ設定、テレメトリ、インシデント対応、および明確なアップグレードパスが必要です。
評価すべきオープンソースのサンドボックスオプション
オープンソースの状況は急速に変化しているため、これを永続的な機能マトリックスではなく、時点での方向性として捉えてください。2026年6月24日時点で、これらのプロジェクトとツールは、セルフホストまたはオープンソースのエージェントサンドボックスパスを比較する際に検査するのに有用な例です。
| オプション | 最初に検査すべき点 | セルフホスティングの問い |
|---|---|---|
| E2B | オープンソースのサンドボックス/ランタイムコンポーネント、SDK、テンプレート、およびFirecrackerベースのサンドボックス位置付け | どの部分がオープンソースで、現在どのデプロイモードがサポートされ、チームにどのような運用作業が残るのか？ |
| Daytona | 開発およびAIエージェントのユースケースのためのワークスペースおよびサンドボックスインフラストラクチャ、オープンソースリポジトリとセルフホストドキュメントパス | そのワークスペースモデル、APIサーフェス、およびデプロイアーキテクチャは、エージェントのワークロードとセキュリティポリシーに合致するか？ |
| OpenHands | エージェントアクションを実行するためのサンドボックス環境を使用する、文書化されたランタイムアーキテクチャを持つエージェントプラットフォーム | 完全なエージェントプラットフォームを採用しているのか、それともランタイムパターンのみを借用しているのか？ |
| SWE-ReX | ソフトウェアエンジニアリングエージェントの研究および評価ワークフローで使用されるオープンソースのランタイムインターフェース | その抽象化は本番のニーズに適合するか、それとも主に制御された評価ハーネスに有用なのか？ |
| Modal Sandbox | オープンソースのセルフホストランタイムではなく、マネージドサンドボックスAPI | APIの人間工学、プロセス実行、ファイルシステム、タイムアウト動作の比較ポイントとして有用。セルフホストの選択肢としては適さない。 |
表だけで選択しないでください。各プロジェクトについて、現在のドキュメントを読み、最新のリリースノートを確認し、自分のワークロードで小さな概念実証を実行してください。評価では、何が実行でき、何が分離され、何が永続化され、何がネットワークに到達でき、何がシークレットを見ることができ、タスク後にどのような証拠が残るのかという問いに答える必要があります。
分離境界：コンテナ、マイクロVM、フルVM
最初の質問は「安全か？」ではありません。有用な質問は「分離境界は何か？」です。
コンテナは高速で親しみやすく、Dockerイメージを中心に構築しやすいため魅力的です。信頼された内部ジョブ、CIのようなタスク、短命な分析、および脅威モデルが中程度である開発ワークフローに適しています。しかし、コンテナはホストカーネルを共有するため、信頼されていないコードやマルチテナントワークロードを扱うチームは、カーネルへの露出、seccomp/AppArmorプロファイル、ユーザー名前空間、マウントされたボリューム、特権モード、およびエスケープ対応を評価する必要があります。
Firecrackerスタイルの分離のようなマイクロVMは、従来のVMよりも起動と密度をコンテナワークフローに近づけつつ、より強力なVM境界を追加します。各セッションに個別のカーネルとより厳格なリソース境界を提供できるため、エージェントサンドボックスの議論で一般的です。しかし、これによりネットワークポリシー、シークレット制御、パッチ適用、またはホストの強化の必要性がなくなるわけではなく、ランタイムの分離レイヤーが明確になるだけです。
フルVMは、より厳格なエンタープライズ環境、デスクトップ自動化、またはより広範なOSサーフェスを必要とするワークロードに適合する可能性があります。トレードオフは、より重い起動、イメージ管理、および容量計画です。
セルフホスティングの前にこれらの質問をしてください。
| 確認項目 | 検証内容 |
|---|---|
| カーネル境界 | サンドボックスは他のワークロードとカーネルを共有するか、それとも各セッションが個別のカーネルを取得するか？ |
| テナント境界 | 2つの顧客セッションがホストレベルのリソース、ボリューム、キャッシュ、ブラウザプロファイル、またはネットワーク名前空間を共有することはあるか？ |
| 権限モデル | サンドボックスは特権コンテナ、ルートユーザー、マウントされたDockerソケット、またはホストパスを実行するか？ |
| エスケープ体制 | カーネル、ランタイム、コンテナ、およびハイパーバイザーの脆弱性はどのようにパッチ適用され、展開されるか？ |
| リソース制御 | CPU、メモリ、ディスク、プロセス数、オープンファイル数、およびランタイム期間はセッションごとに強制されるか？ |
| サイドチャネル | リスクモデルは、共有CPU、キャッシュ、ディスク、または騒がしい隣人動作の軽減を必要とするか？ |
プロジェクトが「分離されている」と説明している場合、メカニズムを理解するまで読み続けてください。
状態、ファイル、およびワークスペースのライフサイクル
サンドボックスが短命であっても、エージェントの作業はステートフルです。エージェントはファイルを作成し、パッケージをインストールし、ブラウザプロファイルを保持し、バックグラウンドプロセスを実行し、または人間がアーティファクトをレビューする間に一時停止するかもしれません。サンドボックスには明確なワークスペースモデルが必要です。
ライフサイクルから始めてください。
- ベースイメージまたはテンプレートからサンドボックスを作成する。
- 許可されたワークスペースをマウントまたはクローンする。
- ポリシーに基づいてセットアップコマンドを実行する。
- エージェントにコマンド、ブラウザアクション、およびファイル操作を実行させる。
- 出力を抽出する：差分、ログ、スクリーンショット、レポート、またはダウンロードされたファイル。
- サンドボックスを停止、一時停止、スナップショット、アーカイブ、または破棄する。
重要な点は、永続性は意図的であるべきだということです。永続的なワークスペースは、長時間実行されるエージェント、多段階のコーディングタスク、および人間参加型のレビューに役立ちます。同時に、クリーンアップが弱い場合、期限切れの資格情報、キャッシュされた依存関係、ブラウザCookie、生成されたデータ、および部分的な作業がセッション間で漏洩する可能性がある場所でもあります。
セルフホスティングの前に、以下を定義してください。
- 各エージェントタスクが新しいファイルシステムを取得するかどうか。
- パッケージキャッシュが共有、スコープ設定、または再構築されるかどうか。
- ブラウザプロファイルが実行間で永続化されるかどうか。
- ユーザーアップロードがコピー、マウント、またはストリーミングされるかどうか。
- スナップショットにシークレット、トークン、Cookie、または内部ログが含まれるかどうか。
- ログとアーティファクトがどのくらいの期間保持されるか。
- 誰が一時停止されたセッションを再開できるか。
優れたサンドボックスは、デフォルトのライフサイクルを退屈なものにします。タスク開始前に何が存在し、タスク中に何が変更され、クリーンアップ後に何が残るかを説明できるべきです。
ネットワーク、パッケージ、およびエグレスポリシー
ネットワークアクセスは、多くのサンドボックス設計があいまいになる領域です。エージェントはしばしばインターネットを必要としますが、「インターネットアクセス」は単一の許可ではありません。
コーディングエージェントは、パッケージレジストリ、公開ドキュメント、Gitリモート、およびプレビューURLを必要とするかもしれません。ブラウザエージェントは、テストアプリケーション、ステージングAPI、およびスクリーンショットストレージを必要とするかもしれません。データエージェントは、オブジェクトストレージ、データベースレプリカ、または制限されたSaaS APIを必要とするかもしれません。これらは異なる許可であり、異なるリスクを伴います。
カテゴリを使用してください。
| エグレスタイプ | 一般的な必要性 | ポリシー上の質問 |
|---|---|---|
| パッケージレジストリ | npm、pip、apt、cargo、モデル/ツールの依存関係 |
レジストリは許可リスト化され、キャッシュされ、スキャンされ、ログ記録されているか？ |
| 公開Web | ドキュメント参照、ブラウザタスク、公開データ収集 | 任意のブラウジングは許可され、プロキシされ、レート制限され、監査可能か？ |
| Gitアクセス | リポジトリのクローン、ブランチのプッシュ、サブモジュールの取得 | トークンは可能な限り読み取り専用で、タスクにスコープ設定されているか？ |
| 内部API | ステージングサービス、テストアプリ、プライベートパッケージミラー | アクセスは環境、サービス、ルート、および資格情報によって制限されているか？ |
| プレビューイングレス | ローカルWebアプリまたは生成されたレポートの人間によるレビュー | どのポートが、誰に、どのくらいの期間、どのような認証で公開されているか？ |
| Webhook | エージェントコールバック、CIイベント、外部ツール統合 | サンドボックスは任意のホストに発信コールバックを送信できるか？ |
パッケージポリシーは特に注意が必要です。多くのエージェントタスクは依存関係のインストールなしでは失敗しますが、パッケージインストールには、インストール後のスクリプト、ネイティブバイナリ、レジストリの侵害、タイポスクワッティングのリスク、および長いキャッシュライフタイムが伴います。ロックファイルベースのインストール、承認されたレジストリ、短命なトークン、およびインストールログを優先してください。
セルフホストシステムの場合、DNSログ、プロキシ設定、証明書トラストストア、およびネットワークインシデント対応を誰が担当するかも決定してください。
シークレット、ログ、および監査証跡
エージェントサンドボックスは、モデルが簡単に出力、コピー、または流出させることができる生の資格情報の置き場所になるべきではありません。
最も安全なパターンは、タスクにスコープ設定されたアクセスです。ジョブに必要な最小限の資格情報をサンドボックスに与え、ジョブが終了したら削除します。コーディングタスクには読み取り専用のリポジトリトークンとプルリクエストトークンが必要かもしれません。ブラウザタスクには本番ユーザーではなくテストアカウントが必要かもしれません。データタスクには恒久的なクラウド資格情報ではなく、一時的な署名付きURLが必要かもしれません。
エージェントが気軽に読めるファイルにシークレットを置かないでください。環境変数は便利ですが、多くのデバッグコマンドは環境状態を出力します。プラットフォームがブローカーアクションをサポートしている場合は、それを使用してください。生の資格情報をモデルループに公開せずに、サンドボックスが狭い操作を実行できるようにします。
ログは、レビューおよびインシデント対応に十分な強度である必要があります。
- 要求され、承認され、拒否され、実行されたコマンド。
- 作業ディレクトリ、終了コード、stdout、stderr、タイムアウト、およびリソース使用量。
- タスクによって生成されたファイルアーティファクト。
- ポリシーがサポートする粒度でのネットワーク宛先。
- パッケージ名、バージョン、レジストリ、およびインストール出力。
- シークレット編集の決定と編集の失敗。
- 危険なアクションに対する人間の承認。
目標は、レビュアーをログで溺れさせることではありません。目標は、エージェントが驚くべき出力を生成したり、依存関係が変更されたり、トークンの露出が疑われたりしたときに、何が起こったかを再構築できるようにすることです。
リセット、スナップショット、およびマルチテナントリスク
リセット動作は、デモの最後のクリーンアップスクリプトではなく、本番機能です。
ephemeral なサンドボックスは、作成、実行、アーティファクトの抽出、破棄という単純なため、推論が容易です。短いコード実行、単発のブラウザアクション、および評価ジョブに適しています。永続的なサンドボックスは、より長いワークフローに役立ちますが、所有権、有効期限、およびレビュー制御が必要です。
スナップショットとテンプレートは、これらのモデルの間に位置します。準備された環境を保持することで起動を高速化できますが、スナップショット内にあるものも保持します。それらに以下が含まれているかどうかを確認してください。
- インストールされたパッケージとキャッシュ。
- シェル履歴またはプロセス状態。
- ブラウザCookie、ローカルストレージ、およびダウンロード。
- 一時ファイルと生成された出力。
- 資格情報または設定ファイル。
- 以前のタスクからのログ。
マルチテナントシステムの場合、スケジューラがワークロードをどのように配置するか、キャッシュが共有されるかどうか、ディスクがどのようにワイプされるか、およびホストレベルのリソースがどのように監視されるかを尋ねてください。また、障害時に何が起こるかを尋ねてください。クラッシュ、タイムアウト、またはコントローラーを失ったサンドボックスでも、クリーンアップとアーティファクトの処理が必要です。
開発者アクセスとデバッグパス
セルフホストのサンドボックスには、実用的なデバッグストーリーが必要です。エージェントが失敗した場合、開発者は問題がモデル、ツールコール、ランタイム、イメージ、パッケージミラー、ネットワークパス、またはターゲットアプリケーションのいずれにあるかを知る必要があります。
有用なデバッグパスには以下が含まれます。
- 同じベースイメージからコマンドを再生する方法。
- コマンド実行とツールコールの構造化ログ。
- ダウンロード可能なアーティファクトとスクリーンショット。
- 明示的なタイムアウトおよびリソース制限エラー。
- ポリシーが許可する場合に、開発者がライブセッションにアタッチするための制御された方法。
- バージョン管理されたテンプレートまたはイメージ。これにより、障害を環境バージョンに関連付けることができます。
- ユーザーに表示される出力と内部ランタイムログの明確な分離。
緊急アクセスには注意してください。ライブサンドボックスへの広範なシェルアクセスは、サンドボックスが強制するように構築されたのと同じ分離仮定に違反する可能性があります。誰がアタッチできるか、何を見ることができるか、シークレットが編集されるかどうか、およびアクセスがどのようにログ記録されるかを定義してください。
Novita Agent Sandbox の位置付け
Novita Agent Sandbox は、コード実行、ブラウザ自動化、コンピュータユーススタイルのワークフロー、データ分析、評価、および長時間実行されるエージェントワークフローのためのマネージドエージェントランタイムです。Novita Agent Sandbox ドキュメント では、ライフサイクル、コマンド、ファイル、ブラウザセッション、および関連するワークフロープリミティブのためのSDKおよびCLIパスを備えたステートフルなサンドボックス環境について説明されています。
これにより、Novita は、チームが初日から完全なセルフホスト運用負荷を引き受けることなく、エージェント実行インフラストラクチャを評価したい場合に適合します。
境界を明確に保ってください。
- デプロイ制御、ソースレベルのカスタマイズ、または内部インフラストラクチャの所有権が優先される場合は、オープンソースまたはセルフホストのランタイムを使用してください。
- 迅速な導入、プロバイダー管理のランタイム運用、およびAPIファーストのワークフローが、すべてのレイヤーを所有することよりも重要な場合は、マネージドサンドボックスを使用してください。
- どちらの場合でも、分離、エグレス、パッケージインストール、シークレット、ログ、永続性、およびレビューゲートを、自社のポリシーに照らして評価してください。
プロバイダー名をセキュリティの保証として扱わないでください。それは、それでもアーキテクチャレビューを必要とするランタイムの選択肢として扱ってください。
セルフホスティングチェックリスト
オープンソースのAIエージェントサンドボックスを本番環境に移行する前に、このチェックリストを使用してください。
| 領域 | 本番前の最低限の質問 |
|---|---|
| 分離 | 境界はコンテナ、マイクロVM、フルVM、またはそれ以外か、そしてそれはワークロードにとって十分か？ |
| ワークスペース | 各タスクは既知のファイルシステム状態から開始し、リセット可能か？ |
| 永続性 | 一時停止、再開、スナップショット、および保持は偶発的ではなく明示的か？ |
| ネットワーク | パッケージの取得、ブラウジング、APIコール、Git、Webhook、およびプレビューイングレスは個別に制御されているか？ |
| パッケージ | ロックファイル、レジストリ、インストール後スクリプト、ネイティブバイナリ、およびキャッシュは管理されているか？ |
| シークレット | 資格情報はタスクにスコープ設定され、編集され、ローテーションされ、無関係なコマンドから利用できないか？ |
| ログ | レビュアーはコマンド、出力、ファイル変更、ネットワークパス、および承認を再構築できるか？ |
| マルチテナンシー | ホスト共有、キャッシュ共有、ディスククリーンアップ、クォータ、および騒がしい隣人動作は理解されているか？ |
| デバッグ | エンジニアはセキュリティモデルをバイパスせずに障害を再現できるか？ |
| 運用 | 誰がイメージ、ランタイム、カーネル、依存関係、およびサンドボックスコントローラーにパッチを適用するか？ |
| 不正使用制御 | タイムアウト、リソース制限、レート制限、および強制終了パスは強制されているか？ |
| 終了パス | サンドボックスがクラッシュまたはタイムアウトした場合でも、アーティファクトをエクスポートしてレビューできるか？ |
いくつかの回答が不明確な場合は、プロジェクトをプロトタイプレーンに留めておいてください。その境界を説明できないサンドボックスは、大規模な信頼できないエージェント作業を実行する準備ができていません。
FAQ
最適なオープンソースAIエージェントサンドボックスは何ですか？
すべてのチームにとって単一の最適なオープンソースAIエージェントサンドボックスはありません。適切な選択は、分離要件、デプロイモデル、エージェントワークロード、エグレスポリシー、永続性ニーズ、および運用能力によって異なります。各候補ランタイム内で独自のタスクを実行して、選択肢を比較してください。
AIエージェントサンドボックスにはDockerで十分ですか？
Dockerは、信頼された内部自動化、ローカル開発、およびCIのようなジョブには十分ですが、信頼されていないコードや厳格なマルチテナントワークロードには不十分な場合があります。コンテナのみに依存する前に、カーネル共有、特権、マウントされたボリューム、ネットワークアクセス、シークレット、およびエスケープ対応を確認してください。
エージェントワークロードにおいて、マイクロVMはコンテナよりも安全ですか？
マイクロVMは、各サンドボックスが個別のカーネルで実行できるため、より強力な分離境界を提供できます。ただし、これによりエグレス、パッケージ、シークレット、ログ記録、パッチ適用、またはマルチテナント運用が自動的に解決されるわけではありません。マイクロVMをアーキテクチャの一部として扱い、セキュリティモデル全体として扱わないでください。
エージェントサンドボックスをセルフホストする前に、何をテストすべきですか？
ファイルをクローンまたはマウントし、依存関係をインストールし、コマンドを実行し、シークレットを処理し、承認されたネットワークターゲットに到達し、アーティファクトを生成し、タイムアウトし、リセットする実際のワークロードをテストしてください。また、パッケージインストールの失敗、ブラウザクラッシュ、ネットワーク拒否、リソース制限、およびコントローラーエラー後のサンドボックスクリーンアップなどの障害パスもテストしてください。
セルフホスティングではなく、マネージドサンドボックスを使用すべきなのはいつですか？
チームがランタイムのパッチ適用、スケーリング、容量計画、およびインフラストラクチャ運用を所有せずに、エージェント実行APIとレビューアーティファクトを必要とする場合は、マネージドサンドボックスを使用してください。デプロイ制御またはソースレベルのカスタマイズがその作業を正当化するほど重要である場合は、セルフホストを使用してください。
