AIにブラウザを操作させる方法は、大きく2つに分かれます。画面をキャプチャして見るか、DOMを解析するかです。
この違いは精度に直結します。Web操作のベンチマークでは、DOM解析ベースのBrowser Useが89%、画面キャプチャベースのComputer Useが56%という差が出ています。
この検証の概要
検証時期 | 2026年4月20日〜（検証中） |
|---|---|
対象 | Browser Use CLI（Playwright + DOM解析ベースのブラウザ自動化フレームワーク） |
やりたかったこと | Google Trendsの急上昇キーワード調査を、Computer Useから低コスト・高精度な方式へ置き換える |
精度 | WebVoyagerベンチマーク 89%（Computer Use 56%比で+33pt） |
コマンドレイテンシ | 約50ms（Daemonアーキテクチャによる） |
コスト | セルフホストなら$0（クラウド版は$0.05/step） |
判定 | 条件付きで導入可（実動作確認後に更新予定） |
本記事は調査・設計段階の記録です。実際のPoC実施は後日のため、動作結果の数値は掲載していません。
結論：Web操作に限るなら、専用ツールのほうが強い
Computer Useはデスクトップ全体を操作できる汎用性があります。しかし対象がブラウザだけなら、汎用性は必ずしも利点になりません。
項目 | Browser Use CLI | Computer Use | pytrends |
|---|---|---|---|
制御範囲 | ブラウザのみ | デスクトップ全体 | Python API（ブラウザ不要） |
仕組み | DOM解析（Playwright） | 画面キャプチャ（Vision LLM） | 非公式内部API |
モデル依存 | 任意のLLMを選択可 | 特定モデル専用 | モデル不要 |
精度（WebVoyager） | 89% | 56% | N/A |
コスト | 無料（セルフホスト） | トークン従量課金 | 無料 |
JSレンダリング対応 | ◎ 完全対応 | ◎ 完全対応 | × 非対応 |
既存Chromeプロファイル | ◎ そのまま使用可 | △ 毎回入力 | × |
安定性リスク | ◯ 公式OSS | ◯ 公式 | △ 非公式・突然壊れる可能性 |
DOM解析ベースのため、JavaScriptレンダリング後の要素も確実に取得できます。画面を見て判断する方式では、レンダリング結果の見た目に依存します。
Daemonアーキテクチャ：毎回起動しない
速度面での特徴です。
ブラウザプロセスをコマンド間で維持するため、コマンドレイテンシは約50msにとどまります。
ブラウザ自動化で意外とコストになるのが起動時間です。1コマンドごとに立ち上げ直していると、連続操作で積み上がります。プロセスを保持する設計は、複数ステップの操作を前提にした作りです。
3種類のブラウザモード
- ヘッドレスChromium（デフォルト）
- 実際のChrome — 既存のログイン済みプロファイルをそのまま使用
- クラウドブラウザ（リモート）
2つ目が実務では重要です。ログイン済みサービスへのアクセスが、認証を都度やり直すことなく行えます。アンチボット検出が強いページでも、実際のプロファイルを使うほうが通りやすくなります。
# 実際の Chrome プロファイルを指定して起動
browser-use --profile /path/to/Chrome/Default open "https://trends.google.com/trending?geo=JP"Claude Codeから自然言語で呼ぶ
MCPサーバーとして登録できるため、自然言語1文でブラウザ操作が完結します。
# インストール
curl -fsSL https://browser-use.com/cli/install.sh | bash
browser-use doctor
# Claude Code に MCP 登録
claude mcp add browser-use -- uvx --from 'browser-use[cli]' browser-use --mcp登録後は、次のような指示で実行できます。
Google Trendsの急上昇ワード上位20件（日本・今日）を取得して一覧化してCLIから直接操作する場合は次のようになります。
# 1. ページを開く
browser-use open "https://trends.google.com/trending?geo=JP"
# 2. JS レンダリング完了を確認
browser-use state
# 3. テキスト一括取得
browser-use get text
# または JavaScript で直接抽出（より確実）
browser-use eval "
Array.from(document.querySelectorAll('[data-entity-id]'))
.map(el => el.innerText.trim())
.slice(0, 20)
.join('\n')
"操作コマンドは click、type、input、scroll、hover、upload、select、eval（JavaScript）、get html/text が用意されています。
なぜスクレイピングでは取れないのか
この検証の対象を例にすると分かりやすくなります。
Google Trendsの急上昇キーワードページはクライアントサイドJSでデータが描画されるため、requests や curl では取得できません。HTMLを取得しても、データがまだ入っていない状態のものが返ります。
JSレンダリングが必要なページでは、ブラウザを動かすしかありません。これがスクレイピングライブラリではなくブラウザ自動化が必要になる理由です。
実装上のTips
browser-use stateでJSレンダリング完了を確認してからget textする — タイミング次第で空になる- 短時間の連続リクエストはブロックされやすい — リクエスト間に数秒のウェイトを設ける
- アンチボット検出が強いサービスは
--profileで実際のChromeプロファイルを使用する --sessionオプションで名前付きセッションを使うとマルチタスクがしやすい
エラー | 原因 | 対処 |
|---|---|---|
| JSレンダリング完了前にコマンドを実行 |
|
アクセスがブロックされる | アンチボット検出 |
|
懸念点
- ブラウザ以外のデスクトップアプリは操作不可 — 汎用性はComputer Useのほうが高い
- Python 3.11+ の環境構築が必要
- 2025年にlitellm経由のサプライチェーン攻撃が発生した経緯がある（現在は依存から除去済みだが、任意LLM連携でlitellmを使う場合は慎重に）
- OSSのため乗り換えコストは低いが、提供元がクラウド版を強化した場合、セルフホスト版のサポートが薄れる可能性
よくある質問
Computer Useと何が違いますか？
DOM解析か画面キャプチャかの違いです。Browser Useはブラウザに特化してDOMを解析するため、WebVoyagerベンチマークで89%（Computer Use 56%）という精度差が出ています。ただしブラウザ以外のアプリは操作できません。
スクレイピングライブラリでは代替できませんか？
JSレンダリングが必要なページでは代替できません。クライアントサイドでデータが描画されるページは、requests や curl ではデータが入る前のHTMLしか取れません。
費用はかかりますか？
セルフホストなら$0です。クラウド版は$0.05/stepの従量課金になります。Computer Useのトークン従量課金と比べるとコスト面で優位です。
取得結果が空になります
JSレンダリングの完了前にコマンドを実行している可能性があります。browser-use state でレンダリング完了を確認してから get text を実行してください。
まとめ
- Web操作に限れば、DOM解析ベースのほうが画面キャプチャベースより精度が高い（WebVoyager 89% vs 56%）
- Daemonアーキテクチャによりコマンドレイテンシは約50ms。連続操作を前提にした設計
- 既存のChromeプロファイルをそのまま使えるため、ログイン済みサービスやアンチボット対策のあるページに強い
- MCP登録でClaude Codeから自然言語1文で実行できる
- JSでデータを描画するページはスクレイピングライブラリでは取得できない。ブラウザ自動化が必要になる
- ブラウザ以外のアプリは操作不可。汎用性と精度はトレードオフ
自動化ツールの選定では、対象範囲を絞れるかどうかが精度を左右します。何でもできるツールより、目的に特化したツールのほうが結果的に確実です。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のリサーチ業務の自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。