E2BはAI生成コードをどこで実行するのか、サンドボックスSDKの設計と導入判断
Open-source, secure environment with real-world tools for enterprise-grade agents.
ひと目でわかる
- これは何？
- E2BはAIが生成したコードをクラウド上の分離サンドボックスで走らせるためのSDKとインフラを提供する。PythonとJavaScriptのSDK、Code Interpreter、Desktopの3層を、READMEとリポジトリ構成から読み解き、採用すべきチームと見送るべきチームを分ける。
- 誰に向いている？
- 自前のコンテナ分離基盤を運用せずにエージェントへ実行環境を渡したいチームは、E2Bのマネージド経路から試す価値がある。逆に、Azure上でのセルフホストを前提にしている場合や、データが自社ネットワーク外に出ることを許容できない場合は、この構成はそのままでは要件を満たさない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
E2Bが埋めるのは「LLMに手足を与えた後の実行場所」という空白
LLMにコードを書かせるところまでは、どのモデルでもできるようになった。問題はその次で、生成されたコードをどこで走らせるかが決まらない。手元のプロセスでexecすればホストを壊される。Dockerを都度立てるなら起動と後片付けの管理コードを自分で書くことになる。E2Bはこの部分を切り出し、クラウド上の分離されたサンドボックスをSDK経由で開始・操作する形にした。対象読者は、コーディングエージェントやデータ分析エージェントを製品に組み込もうとしている開発者である。READMEの冒頭は「run AI-generated code in secure isolated sandboxes in the cloud」と述べており、実行環境そのものを売り物にしている点がはっきりしている。
SDKは3層に分かれ、用途ごとに別パッケージを入れる
E2BのSDKは単一ではなく、目的別に分離されている。基本となるのはe2bパッケージで、Sandbox.create()でサンドボックスを起こし、sandbox.commands.run()でシェルコマンドを実行する。次にCode Interpreterで、runCode()/run_code()によるコード実行が欲しい場合に@e2b/code-interpreterまたはe2b-code-interpreterを追加する。3層目がDesktopで、@e2b/desktopまたはe2b-desktopを入れるとマウス、キーボード、スクリーンショット、アプリ起動、デスクトップストリーミングのAPIが使える。READMEの例ではdesktop.launch('google-chrome')の後にdesktop.screenshot()を呼んでいる。基本SDKだけではコード実行もGUI操作もできず、必要な層を明示的に足す設計だと読める。
実行の流れはAPIキー、サンドボックス作成、コマンド実行の3段
導入の最短経路はREADMEに番号付きで示されている。まずnpm i e2bまたはpip install e2bでSDKを入れる。次にE2BのダッシュボードでAPIキーを取得し、環境変数E2B_API_KEYにe2b_***の形式で設定する。このキーはSDKがサンドボックスの起動時に参照するもので、コードに直書きする前提にはなっていない。そのうえでPythonならwith Sandbox.create() as sandbox:のブロック内でsandbox.commands.run('echo "Hello from E2B!"')を呼び、result.stdoutを受け取る。JavaScriptならawait Sandbox.create()の戻り値に対して同じ呼び出しをする。コンテキストマネージャで囲む形は、ブロックを抜けた時点でサンドボックスを破棄する意図を示している。
セルフホストはTerraform前提で、対応クラウドが限定される
マネージドのE2Bを使わず自前で立てる場合、READMEはe2b-dev/infraリポジトリのself-host.mdを参照するよう案内している。インフラはTerraformでデプロイする構成だと明記されており、対応クラウドはAWSとGoogle Cloudの2つにチェックが付き、Azureと汎用Linuxマシンは未対応の欄になっている。ここは導入判断で最も効く制約である。社内標準がAzureであれば、この手順はそのままでは使えない。Terraformのstate管理、クラウドの認証情報、サンドボックスを動かす計算資源の設計は利用側の責任範囲になり、マネージド利用時に比べて運用対象が明確に増える。
コード実行とGUI操作を同じ基盤に載せている点は、裏返すと依存の大きさでもある
Code InterpreterとDesktopが同じSandbox抽象の上に乗っているのは、エージェントに「計算させる」と「画面を操作させる」の両方を一つの実行基盤で扱えるという意味を持つ。ただしこれは、基本SDKのバージョン更新が上位2層に波及しうる構造でもある。リポジトリのリリースを見ると、e2b@2.49.0と@e2b/python-sdk@2.49.0が同日に公開されており、SDK群がまとめて動いていることがうかがえる。どの層をいくつ使うかをあらかじめ決めておかないと、依存パッケージの数だけ追従コストが増える。逆にコマンド実行だけで足りるなら、e2b一つに留めるのが最も保守しやすい。
向かないケース：ネットワーク境界の外にコードを出せない処理
E2Bの既定の使い方は、サンドボックスがクラウド上に立つことを前提にしている。社内の機密データを扱うコードを、外部ネットワーク上の環境で実行する構成は、多くの組織の規程に抵触する。セルフホストを選べば配置先は自陣のクラウドアカウント内になるが、対応プロバイダがAWSとGCPに限られるため、オンプレミスや閉域網で完結させたい要件には応えられない。もう一つの見送り条件は実行時間の短さで、単発の数行のコードを一度だけ評価するだけなら、サンドボックスの起動とAPIキー管理の分だけ構成が重くなる。その場合はプロセス分離とタイムアウトだけで足りる。
比較対象としてのコンテナ自前運用と、Jupyterカーネル直結との違い
現実的な対抗策は2つある。一つはDockerやKubernetes上にコンテナを都度立てる自前運用で、違いは抽象度にある。E2Bはサンドボックスの起動、コマンド実行、ファイル操作、GUI操作までをSDKのメソッドに畳んでおり、利用側はコンテナイメージやネットワークポリシーを書かない。代わりに、サンドボックス内部の構成を細かく制御する自由は失われる。もう一つはJupyterカーネルを直接立ててコードを流す方法で、こちらは計算結果とリッチな出力の扱いに強いが、シェルコマンドの実行やデスクトップ操作は範囲外になる。E2BのCode Interpreter層はこの両者の中間に位置し、コード実行とコマンド実行を同じサンドボックスで扱えるようにしている。
ライセンスと更新コストの見積もり
リポジトリのライセンスはApache-2.0で、商用利用や改変、再配布を含む条件はこの表記に従う。ここから先は法的助言ではなく、確認事項として読んでほしい。セルフホストを選ぶ場合、Apache-2.0が適用されるのはリポジトリ内のコードであり、デプロイ先クラウドの利用料、Terraformで作成されるリソース、サンドボックスが外部から取得するパッケージのライセンスは別に検討が必要になる。更新頻度は高く、提示されたリリース情報では同日に複数バージョンが公開されている例がある。SDKのメジャー番号が上がるタイミングでは、commands.run()やrunCode()の戻り値の扱いを自社コード側で確認する作業が発生する。
編集部の結論
自前のコンテナ分離基盤を運用せずにエージェントへ実行環境を渡したいチームは、E2Bのマネージド経路から試す価値がある。逆に、Azure上でのセルフホストを前提にしている場合や、データが自社ネットワーク外に出ることを許容できない場合は、この構成はそのままでは要件を満たさない。最初に確認すべきは、SDKが要求するE2B_API_KEYの扱いと、セルフホスト手順が想定するTerraformのプロバイダ対応範囲の2点である。
コミュニティノート