OSSのリポジトリが並んでいると、どれを使えばいいのか判断が難しくなります。名前が似ていて、機能も重なって見える。しかし調べていくと、メンテナンスが止まっているもの、思想がまったく違うものが混ざっていることが分かります。
この検証では、ブラウザ自動化ツールを提供する組織の公開リポジトリを網羅調査し、採用すべきもの・避けるべきものを切り分けました。
この検証の概要
検証時期 | 2026年5月28日〜（検証中） |
|---|---|
やりたかったこと | Computer Useよりトークン効率と運用コストを下げられる代替を見つけ、無料枠クラウドにホストする価値があるか評価する |
調査対象 | 公開44リポのうち上位約13件を整理／うち9リポを技術深掘り |
方法 | リサーチエージェント3並列で各リポの技術レポートを作成 |
状況 | 調査完了・ローカル実機検証はこれから |
結論：同じ組織のリポでも採用可否は大きく分かれる
調査で判明した重要な事実を並べます。
リポジトリ | 判明した事実 | 判断 |
|---|---|---|
ワークフロー系 | v0.2.11（2024-11）止まりで事実上メンテ停滞中。かつAGPL-3.0 | 採用優先度を下げる |
Web UI系 | v3.0.0でブラウザ拡張へ大きく方向転換。従来構成は実質レガシー | 方向性を確認して判断 |
動画系 | コミット16件でPoC段階 | プロダクション投入は非推奨 |
エージェントSDK | MIT・Playwright不要で256MB RAM動作可 | 無料枠クラウドとの相性が良い |
Cloud SDK | エッジ環境に直接デプロイ可能な唯一の選択肢（ブラウザ不要のため） | 有力 |
VPS常駐型 | 特定OS専用・Docker非対応 | コンテナ構想とは思想が違う |
「同じ組織が出しているから、どれも同じ品質・同じ方針」ではありません。ライセンス、更新頻度、前提とする実行環境がそれぞれ違います。
ライセンスは最初に確認する
この調査で最も実務的な発見です。
ワークフロー系のリポはAGPL v3.0のため、商用利用時のライセンス確認が必須です。
AGPLは、ネットワーク経由でサービス提供する場合にもソース公開義務が生じ得るライセンスです。「OSSだから自由に使える」という前提で組み込むと、後から問題になります。
対照的に、エージェントSDKはMITライセンスです。同じ組織のリポでもライセンスが異なる——この確認を最初に行う価値があります。
トークン効率という選定軸
この検証の出発点は、Computer Useとの比較でした。
ハーネス系のツールは、Computer Use比でトークン消費が約1/8と報告されています。
Computer Useはスクリーンショットを画像トークンとして送るため、ステップ数が増えるほどコストが積み上がります。CDP直結でDOM情報を扱う方式なら、この消費を大きく下げられます。
「AIにブラウザを操作させる」という同じ目的でも、情報の渡し方でコストが1桁変わります。
ホスト先の選定：無料枠を軸に
ホスト候補の選定にも判断基準があります。
候補 | 判断 |
|---|---|
エッジ実行系（Workers / Containers） | 優先——無料枠とエッジ実行の親和性を確認したい |
各種クラウドの常時無料枠 | 候補 |
一部のPaaS | 除外——無料枠の空きがない／制約がきつい |
ここで「ブラウザバイナリを同梱できるか」が分岐点になります。
エッジ環境ではブラウザ本体を動かせないため、ブラウザ不要の構成（Cloud SDK経由）でないと成立しません。これが「エッジに直接デプロイ可能な唯一の選択肢」という評価につながっています。
MCPサーバーとして起動できる
実装上の要点です。
メインのリポは uvx --from 'browser-use[cli]' browser-use --mcp でstdio MCPサーバーとして即起動できます。
AIエージェントから呼び出す前提の仕組みが、既に用意されているということです。
ただし課題も残っています。stdio MCPをHTTP/SSEにラップするレイヤーの安定性が未確認です。ローカルで動くことと、リモートから呼べることは別の問題になります。
ローカル検証を先行させる判断
進め方についての判断も記録されています。
クラウドにホストする前に、各リポをローカルで触り、実機の手触り・トークン消費・ホスト難易度を確認してから判断する。
調査だけで構成を決めると、動かしてみて初めて分かる制約に後から気づきます。ホスト先を決める前に、そもそも動くものを選別しておくという順番です。
検証は4波に分けて進める計画になっています。
- 第1波（マスト） — メインライブラリ / ハーネス / SDK
- 第2波 — ワークフロー系 / エージェントSDK
- 第3波 — 動画系
- 第4波 — VPS常駐型 / デスクトップ / Web UI
優先順位をつけて、必須のものから確認します。44リポを全部触ろうとすると終わりません。
調査の進め方
この検証自体の作業方法も参考になります。
リサーチエージェント3並列で9リポの技術深掘りを実施し、各サブディレクトリにレポートを配置しました。
各レポートには、概要・アーキテクチャ・機能・インストール方法・LLM呼び出し経路・コンテナ適性・コスト・直近更新日・強弱・検証お題という項目が揃っています。
調査項目を先に決めてから並列化すると、比較可能な形で結果が揃います。項目がばらばらだと、集まっても比べられません。
この調査で得られる判断材料
OSSを選定するときに確認すべき項目として、この検証は良い例になっています。
- 直近の更新日——メンテナンスが続いているか
- ライセンス——商用利用に制約はないか
- コミット数・バージョン——PoC段階か、実用段階か
- 前提とする実行環境——コンテナで動くか、特定OS専用か
- リソース要件——無料枠に収まるか
- 方向転換の有無——メジャーバージョンで別物になっていないか
READMEを読むだけでは、このうち半分も分かりません。更新履歴とライセンスファイルを見る必要があります。
よくある質問
同じ組織のリポなら、どれを選んでも同じですか？
違います。メンテナンスが止まっているもの、PoC段階のもの、特定OS専用のもの、ライセンスが異なるものが混在しています。
Computer Useと比べてコストは下がりますか？
ハーネス系はComputer Use比でトークン消費が約1/8と報告されています。スクリーンショットではなくDOM情報を扱う方式のためです。
無料枠のクラウドで動きますか？
構成によります。エッジ環境ではブラウザバイナリを動かせないため、ブラウザ不要の構成でないと成立しません。逆に、256MB RAMで動作しPlaywright不要のものは相性が良好です。
OSS選定で確認すべきことは？
直近の更新日・ライセンス・コミット数・前提とする実行環境の4点は最低限確認してください。READMEだけでは判断できません。
まとめ
- 同じ組織のリポでもメンテ状況・ライセンス・前提環境がそれぞれ違う
- AGPL-3.0のリポは商用利用時にライセンス確認が必須。MITのものと混在している
- ハーネス系はComputer Use比でトークン消費が約1/8。情報の渡し方でコストが1桁変わる
- エッジ環境ではブラウザバイナリを動かせない。ブラウザ不要の構成が必要になる
- ホスト先を決める前に、動くものを選別する
- OSS選定では更新日・ライセンス・コミット数・実行環境を最低限確認する
- 並列調査は項目を先に決めてから実施すると比較可能な形で揃う
OSSの選定は、機能比較より前に「まだ生きているか」「使ってよいか」の確認が必要です。ここを飛ばすと、動かしてから戻ることになります。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の技術選定とAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。