E2B code-interpreter を採用する前に確認しておきたいこと

このリポジトリが引き受けている範囲は SDK 本体ではない

README の冒頭には注記があり、@e2b/code-interpreter と e2b-code-interpreter の SDK ソースは E2B モノレポの packages/code-interpreter-js と packages/code-interpreter-python に移ったと書かれている。つまり、このリポジトリを clone して SDK を直したいと考えている人は、最初から見当違いの場所にいる。ここに残っているのはサンドボックステンプレートと chart data extractor である。Issue や Pull Request の送り先も本家モノレポ側と明記されている。採用検討の段階では、依存するパッケージ名と、そのパッケージが実際にどこで開発されているかを切り離して把握しておく必要がある。npm の @e2b/code-interpreter と PyPI の e2b-code-interpreter は今も配布されているが、その中身の開発拠点は別リポジトリだ。

runCode は何を実行しているのか

README が示す最小例は短い。Python では Sandbox.create() を with 文で開き、sandbox.run_code("x = 1") の後に sandbox.run_code("x+=1; x") を呼び、execution.text を print すると 2 が出ると書かれている。ここから読み取れるのは、変数 x が 2 回の呼び出しをまたいで保持されるという点だ。単発のプロセス起動ではなく、Jupyter カーネルのような状態を持つセッションがサンドボックス内で動いている。トピックに jupyter と jupyter-notebook が並んでいることとも整合する。JavaScript 側も同じ形で、Sandbox.create() の後に sbx.runCode('x = 1')、続けて sbx.runCode('x+=1; x') を await し、execution.text を console.log する。戻り値が text という単一のフィールド名で示されているため、少なくともテキスト出力を取り出す経路が用意されていることは確かめられる。画像やリッチ出力の扱いについては、この README の範囲では記述が見当たらない。

サンドボックスはローカルではなくクラウドで起動する

E2B の説明では、AI が生成したコードをクラウド上の分離されたサンドボックスで実行する、とある。手順 2 で E2B へのサインアップとダッシュボードからの API キー取得を求められ、E2B_API_KEY=e2b_*** を環境変数に設定するよう指示される。ここが設計上の分岐点だ。API キーはクラウド側リソースの鍵であり、実行は自分のマシンや自分の VPC 内で完結するわけではない。コードとその実行結果が外部のサービスを通る。社内規定や顧客データの扱いを理由に、生成コードを外部に送れない案件では、この一点だけで採用可否が決まる。逆に、実行環境の分離、リソース制限、後片付けを自前で実装しなくてよいというのが、この構成を選ぶ理由になる。README には分離の実装方式やリソース上限の数値までは書かれていない。

導入はパッケージ名とAPIキーの2点で決まる

JavaScript / TypeScript では npm i @e2b/code-interpreter、Python では pip install e2b-code-interpreter を使う。注意すべきは、Python 側のパッケージ名が e2b-code-interpreter であり、import 文は from e2b_code_interpreter import Sandbox とアンダースコア区切りになることだ。pip の名前と import の名前が異なるので、検索でたどり着いたサンプルが別パッケージ (e2b) を指している場合がある。README のバッジも PyPI の e2b と npm の e2b を参照しており、code-interpreter パッケージとは別の系列が存在する。環境変数は E2B_API_KEY で、値は e2b_ で始まる形式が例示されている。API キーをコードに直書きせず環境変数から読ませる前提のサンプルになっている点は、そのまま従っておくのが無難だ。

テンプレートを差し替えないと足りないパッケージがある

README には Customizing the sandbox template の節があり、追加パッケージや別ランタイムが必要なら独自の Code Interpreter サンドボックステンプレートをビルドできると書かれている。手順は template/README.md にあり、作成、ビルド、利用の流れと、本番用の code-interpreter-v1 テンプレートのビルド方法が扱われている。ここは運用コストが発生する部分だ。デフォルトのテンプレートに含まれるライブラリだけで足りるうちはよいが、社内の独自パッケージや特定バージョンの数値計算ライブラリを入れたいとなれば、テンプレートを保守してビルドし直す必要が出る。アプリケーション側のコード変更なしに実行環境の中身が変わるため、テンプレートのバージョン管理与否かが再現性に直結する。README はこの点の詳細を template/README.md に委ねており、本体側にはビルド手順の具体は書かれていない。

ローカル実行やコンテナ自前運用との違い

比較対象として素直なのは、アプリケーションと同じプロセス内で exec するか、自分で Docker コンテナを立ててコードを流し込む方法だ。後者はネットワーク境界を自分で決められ、API キーも外部サービスも不要になる。代わりに、実行ごとのコンテナ起動、タイムアウト、暴走プロセスの kill、ファイル系の後始末、複数ユーザー間の状態分離をすべて自分で書くことになる。E2B はこのうちセッションの生成と破棄、状態を保持した run_code の連続呼び出しを SDK の数行に畳んでいる。差が出るのはレイテンシと可搬性だ。クラウド側でサンドボックスを起こす以上、ネットワーク往復が必ず入る。ローカルの exec と比べて速くなることはない。オフライン環境やエアギャップ環境では動かない。分離の強度を自分で監査したいチームにとっても、実装が見えない点は不利に働く。

ライセンスとメンテナンスの見取り図

ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。直近のリリースは 2026 年 8 月の @e2b/code-interpreter@2.7.1 と @e2b/code-interpreter-python@2.9.1 で、JS 側と Python 側のバージョン番号が揃っていない。SDK のソースが別リポジトリにある以上、このリポジトリの更新頻度は SDK のそれではない。依存を追うときは本家モノレポのリリースノートを見る必要がある。Apache-2.0 は特許許諾を含む寛容なライセンスだが、クラウド側の実行サービス自体の利用条件はライセンスとは別の契約になる。SDK が Apache-2.0 だからといって、API キーを使った実行が無条件に自由になるわけではない。ここは法務判断の領域なので、契約条件は各自で確認する必要がある。

編集部の結論

自前でコンテナ分離を組まずに、LLM の出力をそのまま実行させたいチームに向く。逆に、外部ネットワークへコードを送れない環境や、サンドボックスの起動レイテンシを許容できない対話型アプリには向かない。導入前に確認すべきは 3 点で、SDK のソースが packages/code-interpreter-python と packages/code-interpreter-js に移っていること、E2B_API_KEY がクラウド側の鍵であること、そしてカスタムテンプレートを作る場合は template/README.md の手順に従う必要があること。このリポジトリ自体が保持するのはサンドボックステンプレートと chart data extractor であり、SDK の不具合は本家モノレポ側で扱う。

公式情報源

1. e2b-dev/code-interpreter on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases