e2b-dev/desktop レビュー: LLM に仮想デスクトップを渡すときの設計と制約
E2B Desktop Sandbox for LLMs. E2B Sandbox with desktop graphical environment that you can connect to any LLM for secure computer use.
ひと目でわかる
- これは何？
- E2B Desktop Sandbox は、LLM エージェントに GUI 操作させるための隔離済み仮想デスクトップを SDK 経由で立ち上げる。Python と JavaScript の両方から同じ操作体系で扱えるが、SDK 本体はすでに別リポジトリへ移っており、このリポジトリの役割はテンプレートとサンプルに絞られている。
- 誰に向いている？
- GUI を操作するエージェントを自前の VM 管理なしで動かしたいなら、Sandbox.create() から launch、stream.start までの流れがそのまま使える。Python か JavaScript のどちらかで完結するチームに向く。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このリポジトリが埋めるのは「画面を持つサンドボックス」の空白
コード実行用のサンドボックスは珍しくない。だが LLM にブラウザやエディタを操作させたい場合、必要なのはシェルではなくウィンドウだ。E2B Desktop Sandbox は、E2B Sandbox の上にデスクトップ環境を載せた仮想マシンを提供する。README はこれを「open source secure virtual desktop ready for Computer Use」と表現し、各サンドボックスは互いに隔離され、任意の依存関係でカスタマイズできるとしている。
対象読者は、Computer Use 系のエージェントを評価している開発者だ。OpenAI の Computer Use を Next.js アプリとして動かす Surf、100% オープンソース LLM で組んだ Open Computer Use という 2 つの参照実装が README からリンクされている。つまり単体のライブラリというより、エージェント実装の土台として使われることを想定した位置づけである。
操作はすべて SDK メソッドに畳まれている
仕組みを理解するうえで重要なのは、プロトコルを自分で書く必要がない点だ。Sandbox.create() で仮想デスクトップが 1 台立ち上がり、以降は Python のメソッド呼び出しがそのままデスクトップ上の操作になる。launch('google-chrome') でアプリを起動し、wait(10000) で描画を待つ。マウス操作は left_click(x=100, y=200)、double_click()、scroll(10)、move_mouse(100, 200)、drag((100, 100), (200, 200))、mouse_press("left") と mouse_release("left") が用意されている。
画面の確認はストリーミングで行う。stream.start() を呼び、get_url() が返す URL を開くとデスクトップが見える。view_only=True を渡せば閲覧専用になり、require_auth=True とすれば自動生成キーによる認証が有効になり、get_auth_key() で取り出したキーを get_url(auth_key=...) に渡す形になる。エージェントに操作させつつ人間が監視する、という使い方を想定した API だ。
ウィンドウ単位のストリーミングも可能で、get_current_window_id() や get_application_windows("Firefox") で対象を絞る。ただし README の警告は明確で、対象アプリがまだ開いていないとエラーになり、アプリが閉じればストリームも閉じる。同時に複数のストリームは作れない。
導入手順と、SDK が別リポジトリにあるという現実
開始に必要なのは E2B の API キーだけだ。e2b.dev でサインアップして取得し、環境変数 E2B_API_KEY に設定する。SDK は Python なら pip install e2b-desktop、JavaScript なら npm install @e2b/desktop で入る。
ここで見落としやすい点がある。README の注記によれば、@e2b/desktop と e2b-desktop の SDK ソースは E2B モノレポ（e2b-dev/E2B）の packages/desktop-js と packages/desktop-python に移管済みで、SDK の issue と pull request はそちらで扱う。このリポジトリに残っているのはサンドボックステンプレートと examples だ。SDK の挙動を調べるためにこのリポジトリを clone しても、目的のコードには行き当たらない。
サンプルは basic-python、basic-javascript、streaming-apps-python、streaming-apps-javascript の 4 つが examples 配下にある。動かす前にどれを読むかで、得られる理解が変わる。
ストリーミング設計の割り切り: 同時 1 本という制約
このプロジェクトで最も評価が分かれるのは、ストリームが同時に 1 本しか張れないという制約だ。README は「There can be only one stream at a time」と明記し、別のアプリを映すには現在のストリームを止めてから開始する必要があるとしている。
これは実装の不備ではなく設計上の割り切りと読める。エージェントに操作させ、人間が横から眺めるという用途では、見る対象は常に 1 つで足りる。だが、複数アプリの状態を並行して監視したい、あるいはウィンドウを切り替えながら比較したい、という要件には合わない。その場合はストリームではなくスクリーンショット取得を自前で回すなど、別の取り方になる。
認証まわりも同様に素朴だ。require_auth=True で得られるのは自動生成のキー 1 つで、キーのローテーションや権限分離については README に記述がない。URL を知っていてキーを持っている者がそのまま画面を操作できる、という前提で設計されている。
E2B Sandbox との関係、そして代替としてのセルフホスト VNC
E2B Desktop Sandbox は E2B Sandbox の上に構築されている。つまりサンドボックスの生成、隔離、破棄という部分は E2B 側の仕組みであり、このリポジトリが提供するのはデスクトップ環境のテンプレートと、それを操作する SDK だ。E2B のアカウントと API キーが前提になる。
対抗馬として素直に挙がるのは、Docker コンテナ内に Xvfb と VNC サーバを立て、LLM には xdotool や pyautogui を叩かせる自前構成である。違いは管理責任の所在だ。自前構成ではコンテナのライフサイクル、ネットワーク公開、認証、VNC のセッション管理をすべて自分で持つ。E2B を使う場合、Sandbox.create() と kill() の間だけを考えればよく、ストリームの URL と認証キーも SDK が発行する。その代わり、実行基盤は E2B のサービスに依存する。オンプレミスや特定クラウド内で完結させたい要件があるなら、この依存は採用判断を左右する。
向くチーム、向かないチーム
向くのは、Computer Use 系エージェントの試作を短期間で回したいチームだ。Python か JavaScript のどちらかで書けて、GUI 操作のプリミティブを自分で実装したくない場合、launch と stream.start だけで画面付きの環境が手に入る。Surf や Open Computer Use のような参照実装が同じ SDK で書かれている点は、設計の妥当性を判断する材料になる。
向かないのは、ストリーミングの同時本数や認証の粒度に要件がある場合、そしてサンドボックスの実行場所を自分で選びたい場合だ。また、このリポジトリのコードを読んで SDK の内部挙動を把握しようとするのも避けたほうがよい。SDK は E2B モノレポ側にある。
導入前に確認すべきは 3 点。利用する SDK のバージョン（Python は e2b-desktop 2.4.2、JavaScript は @e2b/desktop 2.3.1 が直近のリリースとして記録されている）と、E2B モノレポ側の対応ディレクトリ、そして Apache-2.0 で配布されている範囲がどこまでか、である。ライセンスは Apache-2.0 と明記されているが、E2B のホスト型サービス利用には別途 API キーと契約が要る。ライセンス条項の解釈はここでは扱わない。
メンテナンスコストは SDK の移管先を見る必要がある
このリポジトリの最終 push は 2026-09-10、直近のリリースは @e2b/desktop-python@2.4.2（2026-07-23）と @e2b/desktop@2.3.1（2026-06-08）である。アーカイブはされておらず、テンプレートとサンプルの更新は続いている。
ただし追跡すべき対象は 2 つに分かれている。SDK のバグ修正や API 変更は E2B モノレポ側で起き、サンドボックステンプレートの変更はこのリポジトリで起きる。依存を固定して運用するなら、SDK のバージョンを requirements.txt や package.json でピン留めし、テンプレート側の更新とは別々に追う体制が要る。片方だけを見ていると、SDK の破壊的変更に気づかないまま本番のエージェントが動き続ける、という事故になる。
編集部の結論
GUI を操作するエージェントを自前の VM 管理なしで動かしたいなら、Sandbox.create() から launch、stream.start までの流れがそのまま使える。Python か JavaScript のどちらかで完結するチームに向く。逆に、複数アプリの同時ストリーミングや、このリポジトリ単体での SDK 改修を前提にするなら筋が悪い。SDK のソースは e2b-dev/E2B の packages/desktop-python と packages/desktop-js に移っているため、導入前に見るべきはこのリポジトリの README ではなく、E2B モノレポ側の該当ディレクトリと、利用する SDK バージョン（e2b-desktop 2.4.2 / @e2b/desktop 2.3.1）の対応関係である。
コミュニティノート