目次を表示する

browser-use完全解説

プロローグ ── ブラウザがAIの「手」になる日

プロローグ ── ブラウザがAIの「手」になる日

シリーズ構成 Ch.1 プロローグ(本章) / Ch.2 アーキテクチャ:エージェントループの解剖 / Ch.3 機能詳細:クラウドとOSS / Ch.4 競合比較:Playwright・Stagehand・Skyvern / Ch.5 ユースケース / Ch.6 ベストプラクティス / Ch.7 アンチパターン / Ch.8 セキュリティ / Ch.9 エピローグ


自動化の壁

Webスクレイピングの世界に長く関わってきた人なら、この繰り返しに覚えがあるはずだ。

スクレイパーを書く。しばらくは動く。ある朝、サイトのリニューアルでセレクターが変わり、スクレイパーが壊れる。修正する。また壊れる。修正する。これが延々と続く。

Playwrightが登場してブラウザ自動化は格段に洗練された。それでも「コードが依存しているセレクターが変わると壊れる」という根本的な脆さは変わらなかった。WebサイトはHTMLを管理者の都合で変える。自動化スクリプトはそれを知らずに死ぬ。

browser-useはこの問いに根本から違うアプローチで応える。

「AIにブラウザを見せ、何をすべきかを言葉で伝えたら、あとはAIが判断する」

セレクターをハードコードしない。ボタンのXPathを書かない。ページ構造の変化に壊れない。AIが人間と同じように「画面を見て、何をクリックするか判断する」ことで自動化の本質を変えようとしている。


何者か:一行の定義

browser-useは「AIエージェントがWebブラウザを操作するためのPythonライブラリ」だ。

Playwrightの上に構築されており、LLMとブラウザを接続するアダプター層として機能する。開発者はタスクを自然言語で書き、どのLLMを使うかを設定するだけで、エージェントがブラウザを自律的に操作する。

from browser_use import Agent, Browser, ChatBrowserUse
import asyncio

async def main():
    browser = Browser()
    agent = Agent(
        task="GitHubの browser-use リポジトリのスター数を調べて返して",
        llm=ChatBrowserUse(),
        browser=browser,
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

このコードで「GitHubを開く → 検索する → リポジトリページに移動する → スター数を読む → 返す」という一連の操作をAIが自律実行する。


市場での存在感

2026年3月時点で、browser-useのGitHubスター数は 81,200+。2024年末のリリースから約1年で、最も急成長したオープンソースAIプロジェクトの一つになった。

timeline
    title browser-use の成長と進化
    2024年末 : 初回リリース(browser-use v0.x)
             : Playwright + LLM の最初のオープンソース統合
    2025年前半 : 急成長・GitHubスター急増
               : WebVoyagerベンチマーク74.7%達成
               : Fortune500企業での採用開始
    2025年後半 : BU 2.0リリース
               : 精度+12%(74.7% → 83.3%)
               : クラウドサービス(Browser Use Cloud)リリース
    2026年2月 : 完全新設計の実験的エージェントAPIリリース
              : SDK v3.0 - client.run() API
    2026年3月 : GitHubスター 81,200+
              : litellm依存を除去(サプライチェーン攻撃対応)

Fortune 500企業への採用が進んでいる一方で、OSS版は「プロトタイプ・小規模自動化向け」、クラウド版は「本番・大規模向け」という二層構造が明確になってきている。


なぜ今か:三つの文脈

browser-useが2024〜2025年に急成長した背景には三つの文脈がある。

① LLMのマルチモーダル化:GPT-4V・Claude 3・Gemini 1.5のような「画像を理解できるモデル」が一般化した。これにより「スクリーンショットを見て何をクリックするか判断する」という本質的な人間的操作がLLMに可能になった。

② Playwrightの成熟:CypressやSeleniumに比べて、Playwrightはモダンで高速、かつ自動化APIが整備されている。browser-useはPlaywrightをバックエンドとして採用することで、信頼性の高い基盤の上にAI層を追加することができた。

③ AIエージェントへの需要爆発:Level 3〜4の自律エージェントをプロダクトに組み込もうとする企業が急増した(本シリーズの前稿「AIプロダクト統合のレベル」参照)。ブラウザ操作は「人間が毎日やっている作業のかなりの部分」を占めており、そこを自動化できれば価値は大きい。


このシリーズが扱うこと

本シリーズはbrowser-useを多角的に解説する。

  • どういう仕組みで動くのか・エージェントループとページの認識(Ch.2)
  • OSS版とクラウド版の機能・違い・使い分け(Ch.3)
  • Playwright・Stagehand・Skyvernとの比較と使い分け方(Ch.4)
  • 何に使われているか・どんな価値を生み出しているか(Ch.5)
  • 何が「効く」プラクティスとして語られているか(Ch.6)
  • 何が「失敗」として繰り返されているか(Ch.7)
  • セキュリティリスク:プロンプトインジェクションと防御設計(Ch.8)
  • 今後の展開とこの技術が示す方向性(Ch.9)

本シリーズは 2026年3月31日時点の情報を元に執筆しています。