AIアプリケーション向けにE2B互換またはE2B代替のサンドボックスを評価する際は、APIサーフェスの重複、SDKインターフェースの互換性、コードインタプリタセッションの動作、ファイルと状態のライフサイクル、パッケージインストールポリシー、ネットワークエグレス制御、セッション期間と同時実行制限、価格モデルを確認してから移行を決断してください。これらのチェックはいずれも半日のテストで完了しますが、1つでも省略すると、本番環境で移行後に想定外の問題が発生する最も一般的な原因となります。
サンドボックス移行の質問が重要な理由
サンドボックスプロバイダーは表面的には似ています。いずれも隔離された実行環境、何らかのPythonサポート、RESTまたはSDKインターフェースを提供しています。しかし、実際のエージェントワークロード（ツール呼び出し間で永続的なファイルシステムを必要とするコーディングエージェント、実行時にpandasをインストールするデータ分析ワークフロー、特定のAPIへのアウトバウンドHTTPSが必要なブラウザエージェントなど）を実行しようとすると、細部はすぐに異なります。
有用な移行チェックリストは機能比較表ではありません。実際のアプリケーション要件に基づいて、プロバイダー切り替えが容易か、それとも完全な再アーキテクチャが必要かを判断するための一連の質問です。
このガイドでは、各カテゴリについて尋ねる価値のある質問、プロバイダーのドキュメントで確認すべき点、そしてNovita Agent Sandboxが移行先として評価するチーム向けに各側面をどのように対応しているかを解説します。
APIとSDKの互換性
質問すべきこと:
- 対象プロバイダーはあなたの言語（Python、TypeScript、Go）向けの公式SDKを提供していますか？
- SDKは、サンドボックス作成、コード実行、ファイル操作、プロセス管理など、依存している同じ高水準プリミティブを公開していますか？
- REST APIサーフェスは安定しておりバージョン管理されていますか、それとも急速に変化していますか？
- SDKはどの認証フローを使用しますか（APIキーヘッダー、OAuth、サービスアカウント）？ 既存のシークレット管理と一致しますか？
確認すべき点: サンドボックスのライフサイクルメソッド、ファイルシステムメソッド、プロセスメソッドを明示的にカバーするSDKドキュメント。汎用的なREST APIのみでメンテナンスされたSDKがないプロバイダーでは、より多くのグルーコードが必要になります。
実際に違いが現れる箇所: E2BのPython SDKは、サンドボックス作成、sandbox.run_code()によるコード実行、ファイルシステム操作をラップしています。アプリケーションが特定のメソッド名を呼び出したり、SDKからのストリーミング出力動作に依存している場合は、想定通りに動作するかどうかを対象プロバイダーで事前にテストしてください。
コードインタプリタの互換性
質問すべきこと:
- サンドボックスは対話型Python実行（REPL形式、スクリプト実行だけでなく）をサポートしていますか？
- 標準出力、標準エラー、実行結果はどのように分離されていますか？
- サンドボックスはPythonコードからチャート、図、バイナリ出力（PNG、SVG、HTML）を生成できますか？
- デフォルトのPythonバージョンは何ですか？設定可能ですか？
- コードインタプリタは任意のシェルコマンドを実行できますか、それともPythonのみに制限されていますか？
確認すべき点: 多くのAIアプリケーションフレームワークは、stdout、stderr、表示データ（Jupyter形式のリッチ出力）、実行エラーを分離したストリーミングまたは構造化された実行結果を前提としています。エージェントがその構造を解析している場合、フラットなテキスト応答のみを返すプロバイダーでは解析レイヤーを書き直す必要があります。
実行結果のストリーミング: 一部のプロバイダーはコード実行中に部分的な出力をストリーミングします。他のプロバイダーは実行完了後に単一の応答オブジェクトを返します。短いコードスニペットではほとんど問題になりませんが、長時間のデータ処理ステップでは、部分的な出力のストリーミングがユーザーエクスペリエンスにとって重要になることがよくあります。
セッションのライフサイクルとタイムアウト動作
質問すべきこと:
- デフォルトおよび最大セッションタイムアウトは？
- プロバイダーはセッションの一時停止と再開（中断間の状態保持）をサポートしていますか？
- セッションがタイムアウトした場合、実行中の処理はどうなりますか？
- アプリケーションの観点から、セッション作成は同期ですか、非同期ですか？
- セッションを明示的に終了する方法は？自動クリーンアップはどのように行われますか？
確認すべき点: コーディングエージェントや複数ステップのデータ分析ワークフローでは、単一のLLMターンを超えるセッションが必要になることがよくあります。デフォルトのタイムアウトが60秒で、一時停止/再開ができないプロバイダーでは、エージェントが各ターン終了前にすべての状態をシリアライズする必要があり、アーキテクチャ上の大きな制約となります。
特に一時停止/再開について: 一時停止/再開は、スナップショットを使って新しいセッションを作成することとは異なります。一時停止/再開は、メモリ内のプロセス状態、開いているファイルハンドル、ロードされたライブラリを保持します。スナップショットと復元はファイルシステムイメージを復元しますが、通常は実行中のプロセスを保持しません。プロバイダーがどのメカニズムを提供しているか、そしてエージェントが実際にどちらを必要としているかを把握してください。
セッション作成のレイテンシ: エージェントがツール呼び出しごとに新しいサンドボックスを作成する場合、起動レイテンシが急速に累積します。プロバイダーのドキュメントで、コールドスタートとウォームプールの動作、およびセッションの事前ウォームアップが可能かどうかを確認してください。
ファイルと状態の永続性
質問すべきこと:
- サンドボックスはセッション内のコード実行ステップ間で永続的なファイルシステムを持っていますか？
- あるセッションで作成されたファイルは後続のセッションでアクセスできますか、それともファイルシステムはセッションごとに一時的ですか？
- ファイルのアップロード/ダウンロードAPIはありますか、それともファイルはインラインで渡す必要がありますか？
- ファイルシステムサイズの制限（セッションごとのディスククォータ）は？
- エージェントが大規模な成果物（モデル、データセット）を生成する場合、ファイルのエクスポートはどのように機能しますか？
確認すべき点: ほとんどのサンドボックスはセッションごとの一時的なファイルシステムを提供します。ワークフローでセッション間の永続性が必要な場合（例：複数のユーザーインタラクションにわたって成果物を構築するコーディングエージェント）、プロバイダーが名前付きボリューム、永続ワークスペース、またはドキュメント化されたエクスポート＆リストアパターンをサポートしているか確認してください。
コードインタプリタモードでのファイルI/O: データ分析エージェントの場合、サンドボックス内でCSVやPNGを書き込み、それをアプリケーションにダウンロードできることはコアな基本機能です。アップロード→コード実行（読み取り＆変換）→結果のダウンロードというラウンドトリップがエンドツーエンドで機能することをテストしてください。
パッケージインストールポリシー
質問すべきこと:
- サンドボックス内のコードは、制限なく実行時に
pip installを実行できますか？ - プロバイダーはカスタムベースイメージやプリインストールされたパッケージ環境を許可していますか？
- パッケージを許可リストまたは拒否リストに追加する仕組みはありますか？
- パッケージインストールはセッション内のツール呼び出し間で持続しますか、それとも実行ごとにリセットされますか？
- パッケージインストールが失敗した場合（システム依存関係の欠如、バージョン競合）はどうなりますか？
確認すべき点: 実行時のパッケージインストールは、サンドボックスの最も一般的な分岐点の1つです。一部のプロバイダーはパッケージを永続的なセッションレイヤーにインストールするため、ステップ1でpip install pandasを実行するとステップ2でも利用可能です。他のプロバイダーは各コードブロックでベースイメージにリセットします。エージェントがインストールの永続性を前提としている場合、これは決定的な前提の崩れとなります。
サプライチェーンに関する注意: 実行時に任意のpip installを許可することは、サプライチェーンに影響を及ぼします。本番環境のワークロードでは、プロバイダーがパブリックインターネットからのオープンなpip installではなく、インターネット制限付きインストール（プライベートPyPIミラーやキュレーションされた許可リストから）を許可しているかどうかを確認してください。
ネットワークポリシーとエグレス
質問すべきこと:
- アウトバウンドインターネットアクセスはデフォルトで有効ですか、それともサンドボックスはネットワーク分離されていますか？
- サンドボックス内のコードは外部APIにHTTPリクエストを送信できますか？
- エグレス先の設定可能な許可リストまたは拒否リストはありますか？
- サンドボックス内のDNS解決はどうなりますか？
- 2つのサンドボックスは直接通信できますか、それともアプリケーションレイヤーを介してのみですか？
確認すべき点: 公開データセットを取得するデータ分析エージェントの場合、オープンエグレスは便利です。セキュリティに敏感な環境内で動作するコーディングエージェントの場合、制御またはブロックされたエグレスが適切なデフォルトです。自分のワークロードにどちらが必要かを把握してください。
ブラウザエージェントとコード実行エージェント: ブラウザエージェントは通常、完全なインターネットアクセス（ユーザーが指定したURLへのナビゲーション）を必要とします。コード実行エージェントは多くの場合、特定のAPIへのアクセスのみを必要とします。これらは異なるエグレスプロファイルであり、異なるサンドボックス設定が必要になる場合があります。
サンドボックス内のシークレット処理
質問すべきこと:
- シークレット（APIキー、認証情報）をサンドボックス作成時にどのように注入しますか？
- 注入されたシークレットは環境変数、マウントされたファイル、またはその両方としてアクセス可能ですか？
- シークレットは実行ログやシリアライズされた状態に表示されますか？
- プロバイダーはログ出力からシークレットを自動的にスクラブしますか？
確認すべき点: 最も一般的なミスは、環境変数を介してシークレットを注入し、サンドボックスが起動時にすべての環境変数をログに記録して、シークレットを可観測性スタックに漏洩させることです。プロバイダーにスクラビング動作があるかどうかを確認し、ない場合はアプリケーションレベルでのスクラビングを構築してください。
一般的な環境変数との違い: すべての環境変数がシークレットであるとは限りません。両方を区別せずに扱う（型付きシークレットなし、編集なし）プロバイダーでは、より防御的なコーディングが必要になります。
同時実行とスケーリングの制限
質問すべきこと:
- アカウントあたりのデフォルトおよび最大同時サンドボックス制限は？
- 同時実行の強制はハード（制限を超えるとリクエスト失敗）ですか、ソフト（リクエストがキューイングされる）ですか？
- リージョンやデータセンターごとの同時実行上限はありますか？
- サンドボックスごとのユーザー分離モデルがありますか、それともすべてのサンドボックスがアカウントレベルの制限を共有しますか？
- 0から100の同時サンドボックスにスパイクした場合のバースト動作は？
確認すべき点: 評価ワークロード、RL環境、マルチテナントコーディングプラットフォームでは、すべて高い同時実行性が必要です。無料枠が5または10の同時サンドボックスに制限されているプロバイダーは、プロトタイピングには適していますが、50〜100の並列試行を伴う本番RL実行には適していません。
アカウントと組織の制限: 一部のプロバイダーはAPIキーごとに制限を適用し、組織ごとに複数のキーを許可します。他のプロバイダーはキー数に関係なく組織レベルで制限を適用します。高同時実行ワークロードの場合、この違いは本番アカウントの構成方法に影響します。
可観測性とロギング
質問すべきこと:
- プロバイダーはどの実行ログを公開しますか：stdout、stderr、システムイベント、ネットワークトラフィック？
- ログはリアルタイムでストリーミングされますか、それとも実行完了後にのみ利用可能ですか？
- ログの保持期間は？
- 構造化ログAPI（JSON、検索可能なフィールド）はありますか、それともプレーンテキストのみですか？
- 独自の可観測性スタック（OpenTelemetry、Datadog、Splunk）を接続できますか？
確認すべき点: 本番環境でのエージェント障害のデバッグには、実行されたコード、出力された内容、作成されたファイル、行われたネットワーク呼び出しを知る必要があります。stdout/stderrのみを公開し、それ以外は何も公開しないプロバイダーでは、根本原因分析が遅くなります。
監査証跡要件: ユースケースが規制データまたはコンプライアンス要件を含む場合、プロバイダーがタイムスタンプ付きのすべての実行イベントの監査ログを生成できるかどうかを確認してください。プレーンテキストのstdoutは監査証跡にはなりません。
移行パスと労力
移行にコミットする前に、実際の作業範囲を次の次元で評価してください。
SDKレイヤー: 対象プロバイダーが同様のメソッド名を持つ公式SDKを持っている場合、アプリケーションレベルの変更は初期化、認証、および少数のメソッドシグネチャに限定される可能性があります。対象がREST APIのみを提供する場合は、アダプターレイヤーを作成する必要があります。
セッションと状態モデル: 現在のプロバイダーに一時停止/再開があり、対象にない場合は、エージェントがマルチターン状態を処理する方法を再設計する必要があります。これはめったに小さな変更では済みません。
パッケージ環境: 現在のプロバイダーがプリインストールされたパッケージを含むカスタムベースイメージを使用している場合、新しいプロバイダーでその環境を再構築するには時間とテストが必要です。
テスト: サンドボックスの移行には、本番トラフィックを切り替える前に、実際のエージェントワークロードを対象プロバイダーでエンドツーエンドで実行する統合テストスイートを含める必要があります。サンドボックスをモックする単体テストでは不十分です。動作の違いは実際の実行環境に正確に現れるからです。
大まかな労力の目安: 対象プロバイダーが同じプリミティブ（作成、コード実行、ファイル一覧、ファイルダウンロード、終了）をラップするSDKを持ち、セッションモデルがターンごとにステートレスである場合、移行は多くの場合1〜2日の労力です。一時停止/再開、カスタムベースイメージ、特定のストリーミング出力動作に依存している場合は、設計、実装、テストに1週間以上を見積もってください。
価格モデルの違い
サンドボックスの価格モデルは大きく異なり、適切なモデルはワークロードの形状によって異なります。
一般的な価格設定の次元:
| 次元 | 影響するもの |
|---|---|
| 秒単位の課金 | セッションが短く、アイドル時間が短いワークロード |
| 分単位の課金 | 小さな課金単位がそれほど重要でないワークロード |
| サブスクリプションフロア | 使用状況に関係なく固定の月額コスト |
| vCPU + メモリ課金 | カスタマイズ可能なリソース割り当て；設定した分だけ支払う |
| 実行ごとの定額課金 | 均一なタスクサイズに対する予測可能なコスト |
質問すべきこと:
- 課金は使用量ベース（アクティブなサンドボックス時間の秒/分単位）ですか、それともサブスクリプションベース（月額最低料金）ですか？
- vCPUとメモリは独立して課金されますか、それとも固定の階層に結び付けられていますか？
- 課金可能な秒としてカウントされるものは何ですか？セッション作成時間、アクティブなコード実行時間、またはセッションの壁掛け時間全体ですか？
- 無料枠はありますか？そのワークロードタイプに対する制限は？
- コールドスタートセッションと事前ウォームされたセッションの間にコストの違いはありますか？
実際に価格設定が分岐する方法: セッション作成から終了まで（コードがアクティブに実行されているかどうかに関係なく）課金するプロバイダーは、エージェントターン間のアイドル時間が長いワークロードではより高価になります。アクティブな実行中のみ課金するプロバイダーは、そのようなワークロードには安価ですが、必要なリソース階層に存在しない場合があります。
高同時実行のRLや評価ワークロードの場合、秒単位のレートよりも1000実行あたりのコストが重要になることがよくあります。プロバイダーを選択する前に、現実的な月間実行数で計算を実行してください。
Novita Agent Sandboxの適合性
Novita Agent Sandboxは、このチェックリストが主に書かれている移行先の1つです。コーディングエージェント、ブラウザエージェント、データ分析、評価、RLワークロードを対象としています。このチェックリストを進めているチーム向けに、Novitaが適合する点とギャップが存在する可能性がある点を以下に示します。
SDKとAPI: Novitaは、サンドボックス作成、コード実行、ファイルシステム操作、プロセス管理のためのPython SDKとREST APIを提供しています。E2Bスタイルのワークフローから移行するチームは、使い慣れたプリミティブを見つけるでしょう。特定のメソッド名については、対象のSDKバージョンに合わせてNovita Sandbox documentationを確認してください。
セッションライフサイクル: Novitaは最大24時間のセッション、一時停止/再開、アイドルセッションの自動一時停止/自動再開をサポートしています。LLM呼び出し間でセッション内状態を保持する必要があるマルチターンコーディングエージェントにとって、これは60分制限のプロバイダーとは運用上の大きな違いです。
同時実行: Novitaの基本ティアは、サブスクリプション料金なしで50の同時サンドボックスをサポートしています。より高い同時実行が必要な評価やRLワークロードについては、エンタープライズティアについてNovitaにお問い合わせください。
価格モデル: Novitaは、実際のvCPUとメモリに対して秒単位で課金し、サブスクリプションの最低料金はありません。変動またはバースト的な使用パターンのワークロードの場合、フロアのない使用量ベースの課金は、サブスクリプションベースの代替案よりも安価であることがよくあります。コスト予測を行う前に、Novita AI pricing pageで現在の料金を確認してください。
BYOCデプロイメント: Novitaは、お客様自身のAWSまたはGCP VPC内でのサンドボックス実行をサポートしています。厳格なネットワーク分離要件を持つチームにとって、これはマルチテナントパブリッククラウドモデルを回避します。
注意深く確認すべき点: E2B API/SDK互換性、ドロップイン置換の保証、特定の機能パリティは、継続的な開発の対象です。お客様の特定のワークロードパターンをNovitaの現在のSDKに対してテストせずに、完全な互換性を想定しないでください。互換性に関する主張を公開する前に、製品レビューをお勧めします。
Novitaが適合しない可能性がある場合: E2B固有のSDK抽象化に深く投資しているチーム、GPUサンドボックスサポートが必要なチーム、またはAWS/GCP以外のオンプレミスデプロイメントが必要なチームは、移行前に適合性を慎重に評価する必要があります。
FAQ
Novita Agent SandboxはE2Bのドロップイン代替品ですか？
想定していません。SDKメソッド名、セッションライフサイクル動作、ストリーミング出力構造、パッケージインストールの永続性はすべて、特定のワークロードに対してテストしてから、任意のプロバイダーをドロップイン代替品として扱ってください。このガイドのチェックリストを使用して、各側面を明示的に検証してください。
E2Bから別のサンドボックスプロバイダーに移行するための最小限の労力は？
対象プロバイダーが同様のプリミティブ（作成、コード実行、ファイル操作、終了）を持つ公式SDKを持ち、セッションモデルがターンごとにステートレスである場合、移行は多くの場合1〜2日の労力で、SDKの初期化、認証、および少数のメソッドシグネチャをカバーします。一時停止/再開、カスタムベースイメージ、特定のストリーミング出力動作に依存している場合は、1週間以上を見積もってください。
Novita Agent Sandboxは一時停止と再開をサポートしていますか？
はい。Novitaはアイドルセッションの一時停止/再開と自動一時停止/自動再開をサポートしており、セッション長は最大24時間です。これは、LLM呼び出し間でセッション内状態を保持する必要があるマルチターンコーディングエージェントに関連します。現在の動作については、お使いのSDKバージョンに合わせてNovita Sandbox documentationを確認してください。
対象のサンドボックスプロバイダーが自分のアプリケーションと互換性があるかどうかをテストするにはどうすればよいですか？
本番トラフィックを切り替える前に、ステージング環境で実際のエージェントワークロードを対象プロバイダーでエンドツーエンドで実行してください。アプリケーションが呼び出す特定のSDKメソッド、パーサーが期待するストリーミング出力構造、ツール呼び出し間のパッケージインストールの永続性、ファイルのラウンドトリップ（アップロード、変換、ダウンロード）をテストしてください。サンドボックスをモックする単体テストでは不十分です。互換性の違いは実際の実行でのみ現れます。
Novitaはプライベートクラウドアカウント内でのサンドボックス実行をサポートしていますか？
はい。Novitaは、お客様自身のAWSまたはGCP VPC内でのBYOC（Bring Your Own Cloud）デプロイメントをサポートしています。厳格なネットワーク分離、データ保存に関する要件、またはコンプライアンス要件があるチームにとって、これはマルチテナントパブリッククラウドモデルを回避します。現在のBYOCの可用性と構成オプションについては、Novitaにお問い合わせください。
