目次を表示する

browser-use完全解説

第4章 競合比較 ── Playwright・Stagehand・Skyvern との使い分け

第4章 競合比較 ── Playwright・Stagehand・Skyvern との使い分け

ブラウザ自動化の地形図

2026年時点のブラウザ自動化ツールは「AIの関与度」で明確に層が分かれている。

graph TB
    subgraph "AI関与なし"
        PW["Playwright / Selenium<br/>決定論的・高速・セレクター依存"]
    end

    subgraph "AI補助"
        SH["Stagehand<br/>Playwright + 選択的AI<br/>（act / extract / observe）"]
    end

    subgraph "AI主導"
        BU["browser-use<br/>完全自律エージェント<br/>LLMが全ステップを判断"]
        SK["Skyvern<br/>CV + LLM ハイブリッド<br/>単一APIエンドポイント"]
    end

    subgraph "OS操作レベル"
        CU["Computer Use<br/>（Claude / OpenAI Operator）<br/>ブラウザに限らないOS全体の操作"]
    end

    PW -. "AI適応性が必要になると" .-> SH
    SH -. "完全自律が必要になると" .-> BU

Playwright との比較

Playwrightはbrowser-useの「下位レイヤー」として機能しており、対立関係ではなく補完関係にある。しかしプロジェクト選定では比較対象になる。

観点Playwrightbrowser-use
実行速度高速（ミリ秒単位）低速（62秒/タスク平均）
信頼性安定動作時は99%以上70〜83%（タスク複雑度に依存）
ページ変更への耐性弱い（セレクター変更で壊れる）強い（AIが再判断）
セットアップコスト高い（セレクターの特定・維持）低い（自然言語タスクのみ）
実行コスト極めて安いLLM API費用がかかる
適したタスク繰り返し・決定論的・高ボリューム複雑・動的・探索的

判断基準：

Playwright を選ぶとき
  ✅ 毎日1000回以上実行する繰り返しタスク
  ✅ ページ構造が安定しており変更が少ない
  ✅ CIパイプラインでのUIテスト
  ✅ LLMコストを最小化したい

browser-use を選ぶとき
  ✅ ページ構造が頻繁に変わる（ECサイト・動的コンテンツ）
  ✅ 「このフォームを埋めて送信する」のようなアドホックタスク
  ✅ 事前にどこをクリックすべきかわからない探索的なタスク
  ✅ セレクター保守にかかる人件費 > LLMコスト の場合

Stagehand との比較

Stagehand（Browserbaseが開発）は「PlaywrightのAI拡張」として設計されており、browser-useとは設計思想が根本的に異なる。

Stagehandの設計思想：外科的AIアシスト

Stagehandは「Playwrightコードが主体で、難しい部分だけAIを呼ぶ」という思想だ。

// Stagehandのコード例
import { Stagehand } from "@browserbasehq/stagehand";

const stagehand = new Stagehand();
await stagehand.init();

// 普通のPlaywright的な遷移
await stagehand.page.goto("https://example.com");

// AIが必要な部分だけ自然言語指示
await stagehand.page.act("'ログイン' ボタンをクリックして");

// 構造化データの抽出（Zodスキーマで型安全）
const product = await stagehand.page.extract({
  instruction: "商品の名前・価格・在庫状況を取得して",
  schema: z.object({
    name: z.string(),
    price: z.number(),
    inStock: z.boolean(),
  })
});

自動キャッシュ（Stagehand v3の差別化機能）：AIが成功したアクションのセレクターパスを記録し、次回実行時はAIを呼ばずに再生する。ページレイアウト変更時のみAIが再介入。繰り返すほどPlaywright並みの速度・コストに近づく。

browser-use の設計思想：LLMが完全制御

browser-useは「LLMが全ステップを判断し、人間は目標だけ伝える」という思想だ。コードではなく自然言語がファーストクラスの市民だ。

# browser-useのコード例
agent = Agent(
    task="""
    example.comにログインして、
    注文履歴の最新5件を取得して、
    各注文の金額・日付・ステータスをJSON形式で返して
    """,
    llm=llm,
)
# あとはAIが全部やる
result = await agent.run()

どちらを選ぶか

flowchart TD
    Q1{"TypeScriptが使えるか？"}
    Q2{"既存のPlaywrightコードがあるか？"}
    Q3{"繰り返し実行で\nコスト最適化が重要か？"}
    Q4{"全ステップを予測できないか？"}

    SH_WIN["Stagehand が有利<br/>TypeScript・既存資産活用・コスト最適化"]
    BU_WIN["browser-use が有利<br/>Python・完全自律・探索的タスク"]

    Q1 -- No（Python） --> BU_WIN
    Q1 -- Yes --> Q2
    Q2 -- Yes --> SH_WIN
    Q2 -- No --> Q3
    Q3 -- Yes --> SH_WIN
    Q3 -- No --> Q4
    Q4 -- Yes --> BU_WIN
    Q4 -- No --> SH_WIN

Skyvern との比較

Skyvernはbrowser-useと同じ「AI自律エージェント」カテゴリだが、アーキテクチャが異なる。

観点browser-useSkyvern
アーキテクチャPlaywright + LLMComputer Vision + LLM
APIスタイルPythonライブラリ単一RESTエンドポイント
WebVoyager精度83.3%（BU 2.0）85.8%
言語Python主体REST API（言語非依存）
OSSYes（コア部分）Yes
クラウドYesYes

Skyvernの差別化点は「アプリケーションコードが不要」なことだ。URLとタスクを渡すだけで自律実行する。一方でカスタマイズ性はbrowser-useの方が高い。

ハイブリッドパターン：実務の答え

実務の現場で最も語られているのは「単一ツールへの全振り」ではなく「ハイブリッドパターン」だ。

「本番システムの多くはPlaywrightを80%の予測可能なステップに使い、Stagehand/browser-useを残りの20%のAI判断が必要なステップに使う」（NxCode 比較記事より）

# ハイブリッドパターンの例

from playwright.async_api import async_playwright
from browser_use import Agent

async def scrape_product_data(product_url: str):
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page()

        # ① 予測可能な部分はPlaywrightで高速・安定実行
        await page.goto(product_url)
        await page.wait_for_load_state("networkidle")

        # ② シンプルな構造化データ抽出もPlaywrightで
        title = await page.locator("h1.product-title").text_content()
        price = await page.locator("[data-price]").get_attribute("data-price")

        # ③ 複雑・動的な部分のみbrowser-useのエージェントに委譲
        # （例：レビューの要約、比較商品の発見、在庫確認フォームの操作）
        agent = Agent(
            task=f"このページの主要なユーザーレビューを3つ日本語で要約して: {product_url}",
            llm=llm,
            browser=existing_browser,  # 既存のブラウザセッションを共有
        )
        review_summary = await agent.run()

        await browser.close()
        return {
            "title": title,
            "price": price,
            "review_summary": review_summary
        }

このパターンの利点は明確だ。コスト・速度・信頼性はPlaywrightが担保し、セレクターが壊れやすい部分・探索的な判断が必要な部分のみAIが担う。

Computer Use との位置づけ

AnthropicのComputer Useとbrowser-useはしばしば混同される。整理しておく。

観点browser-useComputer Use（Claude）
操作対象WebブラウザのみOS全体（ブラウザ・デスクトップアプリ等）
実装形態PythonライブラリLLM API機能（tool_use）
アーキテクチャPlaywright + LLMスクリーンショット + 直接マウス/キーボード制御
使いどころWebタスクの自動化デスクトップアプリを含む広範なタスク

browser-useはClaude Computer Useと組み合わせて使うことも可能だ（Claude Computer Useをバックエンドとして使い、browser-useがPlaywrightの制御層を担当する）。