Browser Use(ブラウザユース)とは?読み方・LLMでブラウザを自動操作するOSSライブラリの仕組み・使い方・Playwrightとの違いを完全解説

Browser Use(ブラウザユース)とは?読み方・LLMでブラウザを自動操作するOSSライブラリの仕組み・使い方・Playwrightとの違いを完全解説

Browser Useとは

Browser Use(ブラウザユース)とは、LLM(大規模言語モデル)に実ブラウザを操作させるためのオープンソースPythonライブラリで、2024年末に公開されてから急成長し、2026年5月時点でGitHubのスター数は約79,000に達している。Playwrightをラップして、ChromiumベースのブラウザをLLMが自然言語の指示だけで操作できるようにすることが目的のフレームワークだ。

イメージとしては「Webブラウザに操作マニュアルを渡す代わりに、新人にお願いするのと同じ感覚で指示できるツール」と捉えると分かりやすい。たとえば「Amazonでワイヤレスイヤホンを検索して、レビュー4.5以上で5,000円以下の商品をCSVで出力して」と一文渡すだけで、Browser UseはLLMにDOM情報・スクリーンショットを渡し、要素のクリックやフォーム入力を自動で実行する。ここが重要なポイントです — CSSセレクタやXPathを書かずに済む点が従来のRPAやスクレイピングツールとの決定的な違いだ。

Browser Useの読み方

ブラウザユース

ブラウザ ユース

browser-use(PyPIパッケージ名と同じ表記)

Browser Useの仕組み

Browser Useの実行フローは「LLMに対してブラウザの状態を要約して見せる→次の操作をLLMに決めさせる→Playwrightで実行」のループになる。ハイレベルに分解すると次の通り。

Browser Useの実行ループ

①ユーザーから自然言語タスクを受け取る
②現ページのDOM/スクリーンショットを抽出
③LLMに送って次のアクションを決定
④Playwrightで操作→ループ

DOM抽出と「アクセシブルなビュー」

Browser Useは現在のページから「LLMが理解しやすい形に整形したDOM要素一覧」を生成する。これは生のHTMLそのままではなく、操作可能な要素にIDを振り直し、テキスト・ロール・属性を付加した抽象表現だ。トークンを節約しつつ、LLMが要素を一意に指せるよう配慮されている。

アクションスペース

LLMが選べるアクションは「クリック」「入力」「スクロール」「ドロップダウン選択」「タブ切替」「ファイルダウンロード」など、Web操作に必要な最低限のセットに絞られている。LLM側はそのDSLでアクションを返し、Browser UseがPlaywright経由で実行する。覚えておきたいのは、アクションスペースを絞ることでLLMの誤操作を減らしている点だ。

Browser Useの使い方・実例

基本的な使い方(Quick Start)

import asyncio
from browser_use import Agent
from langchain_anthropic import ChatAnthropic

async def main():
    agent = Agent(
        task="GitHubでvLLMリポジトリを開いて、最新リリースのバージョンを取得して",
        llm=ChatAnthropic(model="claude-opus-4-6"),
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

たった数行で、ChromiumブラウザをClaudeに操作させられる。LLMはOpenAI・Anthropic・Google Gemini等のメジャーモデルが選べ、設定はLangChainのChatModelインターフェース経由で渡せる。

よくある実装パターン

パターンA: 競合価格調査エージェント

agent = Agent(
    task=(
        "Amazon、楽天、Yodobashi.comでiPhone 16 Pro 256GBの最安値を調べて、"
        "店舗名・価格・URLをJSONで返して"
    ),
    llm=ChatAnthropic(model="claude-opus-4-6"),
)
result = await agent.run()

向いているケース: 競合価格調査・在庫モニタリング・レビュー収集。サイト構造が変わってもLLMが視覚的に判断できるため、堅牢に動く。

避けるべきケース: 高頻度のスクレイピング(規約違反やレート制限の問題)。

パターンB: フォーム自動入力アシスタント

agent = Agent(
    task=(
        "経費精算サイトを開いて、CSVから読んだ5件の経費データを順に入力・保存して、"
        "保存後のIDを取得して"
    ),
    llm=ChatAnthropic(model="claude-opus-4-6"),
    initial_actions=[{"open_url": "https://example.com/expenses"}],
)
result = await agent.run()

向いているケース: 社内SaaSへのバッチ入力、経費精算、人事申請の代行。

避けるべきケース: パスワードや多要素認証を要する高セキュリティ画面(操作ログから機密が漏れるリスク)。

アンチパターン: ログイン情報をプロンプトに直接記述

# ⛔ 絶対NG
agent = Agent(
    task="Amazon にログインしてください。メール: user@example.com、パスワード: P@ssw0rd",
    llm=ChatAnthropic(model="claude-opus-4-6"),
)

Browser UseはLLMにプロンプト全文を送るため、認証情報をタスク文に含めるのは情報漏洩リスクが大きい。実装する場合はsecretsパラメータや環境変数を使い、Playwrightのコンテキストに直接注入する設計を選ぶこと。

Browser Useのメリット・デメリット

メリット

  • CSSセレクタやXPathを書かずに自然言語で動かせる
  • Playwrightベースなのでページ変更に強い(視覚的に判断できる)
  • OSSで商用利用可(MITライセンス)
  • LLMプロバイダを選べる(OpenAI・Anthropic・Google・Ollamaなど)
  • マルチタブ操作・ファイルダウンロード・JS実行など機能が豊富

デメリット

  • 1ステップごとにLLM呼び出しが発生し、API料金とレイテンシが嵩む
  • LLMの判断ミスで誤操作が起きるリスクがあり、安全装置の設計が必須
  • 厳格なrobots.txt・利用規約のあるサイトには使えない場合がある
  • 長時間運用時のセッション管理・Cookie管理を別途実装する必要がある

Browser UseとPlaywright・Computer Useの違い

「ブラウザを自動化したい」場面でBrowser UseはPlaywright・Selenium、AnthropicのComputer Useと比較されることが多い。下記の比較表で違いを整理する。

観点 Browser Use Playwright Computer Use(Claude)
操作の指定 自然言語タスク セレクタ・スクリプト 自然言語+画面座標
操作対象 ブラウザ専用 ブラウザ専用 デスクトップ全体
LLM依存 あり(プロバイダ選択可) なし あり(Claude固定)
堅牢性(UI変更耐性) 高い 低い(セレクタが固定) 高い
運用コスト LLM API課金 CPU/メモリのみ Claude API課金(やや高め)
主な用途 調査・スクレイピング・代行 E2Eテスト 汎用デスクトップ自動化

つまり「ブラウザだけを賢く動かしたい」ならBrowser Use、「テストの再現性が最優先」ならPlaywright、「ブラウザに留まらない作業」ならComputer Useが向いている。

よくある誤解

誤解1: 「Browser Useは無料で動かせる」

なぜそう誤解されるのか: ライブラリ自体がOSSで無料配布されているため、運用コストもゼロという連想が働く。GitHub README冒頭の「Make websites accessible for AI agents」というコピーも気軽な印象を与えている。

正しい理解: Browser Use自体は無料だが、内部で使うLLM(OpenAI・Anthropic等)の利用料がステップごとに発生する。1タスクあたり数十〜数百回のLLM呼び出しが起きるため、本格運用時はコスト試算が不可欠。OllamaなどローカルLLMを使えば実質無料化も可能だが精度は落ちる。

誤解2: 「どんなサイトでも完璧に動く」

なぜそう誤解されるのか: GitHub READMEのデモが派手で、AmazonやLinkedInなど主要サイトでの動作映像が拡散しているため。「LLMが視覚的に判断する=何でも動く」という思い込みもある。

正しい理解: Cloudflareの厳格なBot対策、CAPTCHA、暗黙のJS判定などでブロックされるサイトは多い。また機密性の高いサイトはBot行為自体が利用規約違反となるケースがあるため、利用前に対象サイトのToSを必ず確認する必要がある。

誤解3: 「Browser UseはRPAの完全置き換えになる」

なぜそう誤解されるのか: 「自然言語で動かせる=UiPath・Power Automateを置き換えられる」という単純な見方が広まっている。RPA市場の話題性も相まってBrowser Use万能論が出回っている。

正しい理解: Browser Useはブラウザ専用で、デスクトップアプリやAS/400などのターミナルには非対応。安定動作・監査ログ・ガバナンスといった企業RPAに必須の機能はまだ限定的で、業務基幹に組み込むには補完設計が必要。

実務での活用シーン

実務では「定型作業の自動化」と「探索的な調査」の二軸で導入が進んでいる。覚えておきたいのは、用途設計を間違えるとLLMコストが青天井になる点だ。

競合調査・市場リサーチ

「主要EC3サイトで〇〇の価格を調べて」のような調査タスクを、人手なしで毎週実行する事例が増えている。スプレッドシートに自動転記するエージェントとして稼働させやすい。

SaaS入力代行

経費精算・労務管理・SFA入力など、手入力が多いSaaS業務を代行する用途。社員のデスクトップに常駐させ、CSVやSlackの依頼から自動的に入力するパターンが定着しつつある。

営業リードリサーチ

LinkedInやBaseconnectなどから候補企業の情報を収集し、CRMに登録するワークフローに使われている。Sales関連サイトのToSと地域法令を厳密に確認する必要がある。

よくある質問(FAQ)

Q1. Browser Useはどのブラウザに対応していますか?

PlaywrightベースのためChromium・Firefox・WebKitに対応します。実運用ではChromiumが最も安定しており、ヘッドレス/ヘッドレスでない両方のモードが選べます。

Q2. ローカルLLM(Ollama)でも動きますか?

はい。LangChainのChatOllamaを通して接続できます。小さいモデルだと指示の解釈精度が落ちるため、7B以上のInstructモデルを推奨します。

Q3. CAPTCHAは突破できますか?

原則としてCAPTCHAは突破しない設計です。サイトのアンチBotポリシーを尊重し、必要に応じて2Captchaなど合法な代行サービスやMFA設計を組み合わせる必要があります。

Q4. プロダクション運用で気をつけることは?

レート制限・利用規約・PII取り扱いの3点が最重要です。ログにユーザーデータを残さない設計や、エージェントの暴走を止めるmax-stepsの設定など、安全装置の組み込みが推奨されます。

まとめ

  • Browser UseはLLMでブラウザを自然言語操作するOSSライブラリ(GitHub 79K+ stars)
  • Playwrightベースで、DOM抽出+LLM判定+アクション実行のループを自動化
  • CSSセレクタ不要でUI変更に強いが、ステップごとにLLM料金が発生する
  • Playwrightはテスト用、Computer Useはデスクトップ全般、Browser Useはブラウザ自動化に特化
  • 競合調査・SaaS入力・営業リサーチで実用例が急増
  • 本番運用ではレート制限・規約・セキュリティ設計が成功の鍵

参考文献・出典

📚 参考文献・出典