open-computer-use を読む: E2B Desktop Sandbox とオープンソース LLM で組む computer use エージェント

open-computer-use が埋めるのはどの隙間か

computer use 系のエージェントを自前で組もうとすると、最初に詰まるのはモデル選定ではなく実行環境の確保である。GUI を操作させるには画面付きのマシンが要り、そのマシン上でマウスとキーボードを動かし、シェルも叩ける必要がある。ローカルのデスクトップをそのまま使うと、エージェントの誤操作が自分の作業環境に直撃する。open-computer-use はこの実行環境を E2B の Desktop Sandbox に外注し、エージェント側はクライアントから映像を受け取って操作命令を送るだけの構造にしている。README の Features には secure Desktop Sandbox とあり、隔離されたクラウド上の Linux を前提にしていることが読み取れる。対象読者は、GUI 操作を伴うタスクを LLM にやらせたいが、実行基盤の構築とモデル接続の両方を同時に作りたくない開発者である。Ubuntu を使うと明記しつつ、任意の OS で動くよう設計されているとも書かれている。

grounding と vision と action を分ける三層のモデル構成

このプロジェクトの設計上の中心は、モデルを一つに絞らず役割ごとに分けている点にある。README の LLM support 節では config.py に grounding_model、vision_model、action_model の三つを指定する例が示されている。例では grounding に OSAtlasProvider、vision に GroqProvider("llama3.2")、action に GroqProvider("llama3.3") を割り当てている。grounding は画面上の要素がどこにあるかを座標として特定する役割、vision は画面の内容を読む役割、action は次に何をするかを決める役割と読める。providers.py にインポートされるプロバイダ一覧を見ると、Llama 3.2 は vision only、Llama 3.3 は action only と注記され、Gemini 2.0 Flash や GPT-4o、Claude は vision と action の両方を担えるとされている。つまり vision と action を別モデルに分けることも、一つのマルチモーダルモデルに兼ねさせることもできる。grounding だけは OS-Atlas や ShowUI といった専用モデルが HuggingFace Spaces 経由で用意されている。この分離は、汎用 VLM の座標特定が不安定だという前提に立った設計だと推測できる。

クライアントとサンドボックスの間で何が流れるか

データの流れは README の記述からおおむね追える。E2B 上に Desktop Sandbox が立ち、そのデスクトップの表示がクライアント側にライブストリームされる。エージェントはその映像を入力として grounding と vision のモデルに渡し、action モデルが決めた操作をキーボード、マウス、シェルコマンドとしてサンドボックスに返す。README には Operates the computer via the keyboard, mouse, and shell commands とあり、GUI 操作とシェル操作が同列に扱われている。シェルが使えるということは、ブラウザ操作だけでなくファイル操作やコマンド実行もタスクに含められるということである。また User can pause and prompt the agent at any time と書かれており、完全自動ではなく人間が途中で介入できる前提になっている。設計の詳細は別記事 How I taught an AI to use a computer に委ねられており、リポジトリ内の architecture.png 以上の情報は README にはない。ストリーミングの遅延や解像度の扱いについては、この資料からは確認できない。

起動までの手順と .env に並ぶキー

前提は Python 3.10 以降、git、E2B の API キー、そして利用する LLM プロバイダの API キーである。macOS を想定した例として brew install poetry ffmpeg が示されている。ffmpeg が入るのは映像ストリームを扱うためだろう。リポジトリを clone して cd open-computer-use したあと、.env を作成し、E2B_API_KEY を設定する。加えて config.py で選んだプロバイダに対応するキーを書く。列挙されているのは FIREWORKS_API_KEY、OPENROUTER_API_KEY、LLAMA_API_KEY、GROQ_API_KEY、GEMINI_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEY、MOONSHOT_API_KEY で、Hugging Face Spaces はキー不要と注記されている。ただし HF_TOKEN については、Gradio のレート制限を回避するために必須と書かれている点に注意したい。起動は poetry install のあと poetry run start である。プロンプトを最初から与えるなら poetry run start --prompt "use the web browser to get the current weather in sf" のように渡す。表示ストリームは Python プログラムの起動から数秒で見えるようになると README は説明している。

grounding モデルがボトルネックになりやすい理由

三層に分けた設計は柔軟だが、弱点も同じ場所にある。action モデルをどれだけ賢くしても、grounding がクリック対象の座標を外せばタスクは失敗する。README が grounding 専用のモデルを別枠で用意し、OS-Atlas と ShowUI を HuggingFace Spaces 経由で呼ぶ構成にしているのは、この工程を汎用 VLM に任せると精度が出にくいという判断の表れだと読める。ここで実務上の制約が生じる。grounding を HuggingFace Spaces に依存させる場合、HF_TOKEN が必須と明記されており、外部サービスのレート制限と可用性がエージェント全体の信頼性に直結する。自前のモデルに差し替えることも可能だが、その場合の座標精度は各自で確かめるほかない。README には grounding の精度に関する数値も、失敗時のリトライ機構の説明もない。GUI 操作の成功率を測定したい用途では、この情報不足が導入判断を難しくする。

プロバイダ差し替えの自由度とメンテナンス負担

モデルを入れ替える作業は config.py の数行を書き換えるだけで済むと README は示している。providers.py にプロバイダを追加し、config.py で指定する流れである。新しいモデルやプロバイダを足した場合は providers.py を更新して PR を送るよう README が呼びかけている。ここから読み取れるのは、このプロジェクトが特定ベンダーへの固定を避け、コミュニティ側の追加に依存しているという姿勢である。ただしその自由度はメンテナンス負担と表裏になる。プロバイダ側の API 仕様が変われば providers.py の修正が必要になり、その修正は上流のリポジトリが取り込むまで利用者側には届かない。リリースは取得できておらず、バージョン番号による安定版の追跡ができるかは資料からは判断できない。master ブランチを直接使う前提で運用するなら、poetry install のたびに依存関係が動きうることを許容する必要がある。ライセンスは Apache-2.0 で、改変と再配布の条件は比較的緩い部類に入る。ただし E2B および各 LLM プロバイダの利用規約は別途適用される。

代替としての Anthropic Computer Use との違い

比較対象として素直なのは Anthropic の Computer Use である。あちらは Claude という単一のモデルが画面を見て操作を決める構成を前提にしており、モデル選定の自由度は低い代わりに、vision と action の受け渡しを自前で設計する必要がない。open-computer-use は逆の立場を取る。grounding、vision、action を別々のプロバイダに割り当てられるようにし、Llama、Gemini、GPT-4o、Claude、Mistral、DeepSeek、Moonshot といった複数系統を providers.py 経由で並べている。実行環境も Anthropic の場合は利用者側で用意する必要があるが、こちらは E2B の Desktop Sandbox を前提に組み込んでいる。どちらが優れているという話ではなく、モデルの組み合わせを自分で決めたいか、単一モデルの挙動に乗るかという設計思想の差である。コスト最適化のために vision だけ安価なモデルに寄せる、といった調整ができるのは前者の利点だと言える。

どんなチームが採用し、どんなチームが避けるべきか

向いているのは、E2B のアカウントをすでに持ち、computer use の挙動をモデルごとに比較したい開発者である。config.py の grounding_model を差し替えて同じプロンプトを流せば、座標特定の精度差がタスク成否として現れる。逆に避けるべきなのは、API キーを一つに絞って運用したいチームである。E2B に加えて最低一つの LLM プロバイダ、grounding を HuggingFace Spaces に頼るなら HF_TOKEN と、管理すべき資格情報が複数になる。GUI 操作の再現性を厳密に測定したい用途も向かない。README には成功率やリトライの方針がなく、pause と prompt による人間の介入が前提に置かれている。着手前に確かめるべきは、config.py の三つのモデル指定を自分のプロバイダで埋めたときに、poetry run start --prompt の単発タスクが完走するかどうかである。ここで grounding が外れるなら、OS-Atlas と ShowUI のどちらが自分の画面構成に合うかを先に切り分ける必要がある。

編集部の結論

導入を検討すべきなのは、E2B の Desktop Sandbox をすでに契約していて、grounding・vision・action の各役割を別プロバイダに割り当てながら computer use の挙動を比較したいチームである。逆に、単一の API キーで完結させたい場合や、GUI 操作の再現性を厳密に検証したい用途には向かない。着手前に config.py の grounding_model を OSAtlasProvider から任意の vision 対応モデルへ差し替えたときに座標精度がどう変わるかを、poetry run start --prompt の単発タスクで確認しておくべきだ。

公式情報源

1. e2b-dev/open-computer-use on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README