FlowTune Media

OpenBrowser-AI — トロント大の学生4人が作ったOSSブラウザエージェントが、browser-useをトークン2.6倍効率で上回った話

OpenBrowser-AIBrowser UseAIエージェントオープンソースMCPCLI

OpenBrowser-AI

Product Hunt を眺めていて、ひさしぶりに「これは手を動かしたくなる」という新規ツールに遭遇した。

OpenBrowser-AI。2026年4月7日にProduct Huntでローンチされた、オープンソースのブラウザ自動化エージェントフレームワークだ。驚くのは開発体制で、トロント大学の4人の学生がキャップストーンプロジェクトとして4か月で作った。それでいてbrowser-useやSkyvern、vercel-labs/agent-browser、BrowserOSといった既存のフレームワークと肩を並べる完成度になっている。

数字で言えば、Claude Sonnet 4.6をLLMバックエンドに使った6タスクのベンチマークで、4つの競合フレームワーク全てが100%精度を叩き出した一方、OpenBrowser-AIはトークン消費を平均2.6倍効率化し、6タスク中5タスクでトークン効率のトップに立った。推論コストが2.6倍節約できるのは、個人・企業どちらの視点から見ても無視できない数字だ。

何がそんなに違うのか

既存のブラウザ自動化フレームワークは、ほとんどがPlaywrightをラップする構造を取っている。browser-useもvercel-labs/agent-browserもそうだ。これは安定性と互換性の面ではメリットがあるが、LLMが操作一つにつき1回のツール呼び出しを発行することになり、トークン消費が膨らむ。

OpenBrowser-AIはここから離れた。**raw CDP（Chrome DevTools Protocol）**に直接接続し、中間層を剥がした。そして決定的な違いがこれだ。

LLMはPythonコードを書き、それが永続的な名前空間で実行される。

何が起きるかというと、例えば「Amazonにログインして、ほしいものリストの商品をCSVに書き出せ」という指示に対して、LLMは次のようなPythonブロックを一発で生成する。

browser.goto("https://www.amazon.co.jp/gp/registry/wishlist/")
items = browser.query_all(".g-item-sortable")
data = [(item.text("h3"), item.text(".a-price")) for item in items]
import csv
with open("wishlist.csv", "w") as f:
    csv.writer(f).writerows(data)

これが永続名前空間（browser、csv、data などの変数）で実行される。次のLLMコールでは data にそのままアクセスできる。10ステップの操作を3回のLLMコールで終わらせられる設計だ。

「ページ状態を450文字に圧縮する」というチューニング

もう一つ興味深いのが、ページ状態をLLMに渡すときの圧縮だ。

ブラウザの現在の状態（開いているタブ、フォーム要素、URL、title、重要な可視要素の位置）を、OpenBrowser-AIは平均450文字程度のテキストにまとめてLLMに渡す。browser-useがだいたい2000〜5000トークン相当のHTMLを渡すのと比べて、実に1/10以下。

これが可能なのは、CDP直叩きで「今のDOMで本当に重要な要素は何か」を精密に選別できるからだ。Playwrightラッパーだと、この選別ロジック自体がLLMに任されることが多く、結果としてLLMに大量のDOMを渡してしまう。OpenBrowser-AIは前処理側で絞る設計を取った。

地味だが、これがトークン効率2.6倍の核心だ。

対応LLMとインストール

対応LLMは15プロバイダ。

  • OpenAI / Anthropic / Google / AWS Bedrock / Azure / Groq / Together AI / Ollama 他

CLIツールとMCPサーバーの両方を同梱している。

pip install openbrowser-ai
openbrowser-ai run "gmail にログインして、未読メールを全部markdownで要約して"

MCPサーバーモードにすれば、Claude DesktopやClaude Code、CursorなどMCP対応クライアントからそのまま呼び出せる。

{
  "mcpServers": {
    "openbrowser": {
      "command": "openbrowser-ai",
      "args": ["mcp"]
    }
  }
}

MCP経由で動かすときの体験は正直かなり気持ちがいい。Claude Codeに「この記事のランキングをブラウザで取得して表にまとめて」と頼むと、内部でOpenBrowser-AIが立ち上がってChromeを操作し、結果のテーブルだけが返ってくる。エージェントの手がブラウザまで伸びる体験は、触ってみるまで分からない種類のものだ。

クラウド版と「保存済み認証プロファイル」

GitHubのOSSと並行して、チームはクラウド版プラットフォームも公開している。こちらは次の機能がある。

  • 保存済み認証プロファイル：Gmail、Slack、Notionなどにログインした状態をセッションとして保存し、以後のスクリプトから再利用できる
  • スケジュール実行：Cronのようにブラウザワークフローを定時実行
  • 並列セッション：複数ブラウザを同時に動かしてタスクを分散

認証情報を一度通せば、以降はLLMが「今からSlackの#generalに投稿して」と言うだけで動く。個人の自動化用途なら十分すぎる機能だ。

研究成果としての一面

個人的に興味深かったのは、4人の学生がツールを作るだけでなく論文まで出している点だ。HuggingFaceとResearchGateに2本の研究論文が公開されている。

  • Qwen3-8B へのSFT + GRPO強化学習：ブラウザ用フォーム入力タスクに特化してファインチューニングした小型モデルの実験
  • Diffusion言語モデルとの比較：自己回帰LLMとDiffusion LMでブラウザ操作能力を比較

フレームワークを作って「はい便利です」で終わらず、その上で実験できる研究プラットフォームとして設計されているわけだ。この姿勢は好感が持てる。AIエージェント研究と実装を分断しない流れは、2026年のアカデミア発OSSにありがちな健全なパターンになりつつある。

競合フレームワークとの比較

ブラウザエージェントOSSは2026年時点で混戦状態だ。主なものをざっくり整理しておく。

  • browser-use — 最も有名。Playwrightベース。プラグイン・統合が豊富だが、トークン効率は平均的
  • Skyvern — 視覚モデル（LLaVA系）+ GUIベースでタスクを捌く。複雑なECサイトに強い
  • BrowserOS — ChatGPT Atlas/Perplexity Cometの代替を目指すOSSブラウザ本体
  • vercel-labs/agent-browser — Vercelが公式メンテするCLI。Next.js等の自社プラットフォーム連携が特徴
  • OpenBrowser-AI — 今回の主役。CDP直叩き + Python名前空間でトークン効率を最大化

用途で使い分けるなら、browser-useは本番運用の安定性、Skyvernは視覚認識重視のタスク、OpenBrowser-AIはAPIコストを下げたい大規模自動化、という住み分けになりそうだ。

微妙に感じる点

正直なところ、OpenBrowser-AIには学生プロジェクトゆえの未成熟さも残る。

第一に、エラーハンドリングがまだ浅い。CDPで直接動かしているので、ページロード中のタイミング問題やJavaScriptのレースコンディションに遭遇しやすい。browser-useがPlaywrightで吸収しているような細かい挙動のブレを、自前で拾う必要がある。

第二に、コミュニティの厚みが足りない。GitHubスターはまだ4桁前半で、Issueへの返答速度も学業の合間にやっているため安定しない。本番運用するならフォークして自分で手を入れる覚悟が必要だ。

第三に、永続名前空間というパラダイムに慣れが必要。browser-useのようなツール呼び出しベースに慣れた開発者にとって、LLMが書くPythonコードをデバッグする感覚は最初少し混乱する。printデバッグで中間変数を覗く運用に切り替える必要がある。

ただ、これらはいずれも「プロジェクトの成熟度」の問題であって、設計思想そのものの欠陥ではない。3〜6か月で解決される種類のものだと思う。

何が実現できるか

OpenBrowser-AIの本当の面白さは、トークン効率の良さが「GPUコスト」ではなく「LLM呼び出しコスト」を直撃するところにある。毎日100回ブラウザエージェントを走らせる運用を想定すると、月のAPI請求が数千ドル規模で変わる。個人開発者レベルでも体感できる差額だ。

具体的に考えられる応用は次のようなものだ。

  • 定期的なデータ収集：競合価格監視、SNSトレンド収集、求人情報スクレイプを安価に自動化
  • パーソナルRPA：Gmail/Slack/Notionにまたがる日次業務を自然言語で指示するだけで完結させる
  • LLM + Webのハイブリッドテスト：自社WebアプリのE2Eテストを「このページで注文が完了するはず」という自然言語で書ける
  • 研究用データセット生成：論文用に特定サイトから大量のデータを集めるときに、手作業スクリプトを書く代わりにLLMに指示

特に「API化されていない公開情報を集めたい」というニーズに対しては、今までPlaywrightで手書きしていた部分をまるごと自然言語に置き換えられる可能性がある。4人の学生が4か月で作ったツールがこれほどの射程を持ち始めているのは、正直それ自体が驚きだ。

少なくとも、筆者の個人用データ収集スクリプトの次の書き換え先としては、OpenBrowser-AIを真っ先に試したいと思っている。

参考: OpenBrowser-AI on GitHub / OpenBrowser-AI on Product Hunt

関連記事