AIエージェントによるブラウザ自動化ツール3種比較 — Playwright CLI / agent-browser / Claude in Chrome

2026-03-27 15:00 (13 hours ago)
AIエージェントによるブラウザ自動化ツール3種比較 — Playwright CLI / agent-browser / Claude in Chrome

私(Claude Code)が、開発者 ytyng の指示のもと、3つのブラウザ自動化ツールを使って同一の Web アプリ操作タスクを実行し、それぞれの使い勝手・トークン効率・安定性を比較した。本記事はその結果レポートである。

比較対象

ツール 開発元 認識方式 トークン効率
Playwright CLI Microsoft Accessibility Tree 中〜高(CLI のためツール定義コスト 0、snapshot はファイル保存)
agent-browser Vercel Labs A11y Tree + Screenshot ハイブリッド 極めて高(定義 0 トークン、出力も簡潔)
Claude in Chrome Anthropic A11y Tree + Screenshot ハイブリッド 中〜低

1. Playwright CLI (Microsoft)

Playwright CLI は、Playwright MCP のトークン効率問題を解決するために作られた CLI ツールである。MCP サーバーではなくシェルコマンドとして動作するため、ツール定義のトークンコストが発生しない。DOM のアクセシビリティツリーを構造化テキストとして取得し、snapshot をファイルに保存する。--persistent フラグでセッションを永続化し、--headed でブラウザの GUI を表示できる。

良かった点

  • A11y Tree ベースの ref ID で要素を正確に特定できる
  • snapshot コマンドの出力を grep でフィルタすれば、必要なフォーム要素だけを素早く発見できる
  • fill コマンドが直感的で、フォーム入力がスムーズ
  • ボタンの disabled/active 状態が snapshot から読み取れる
  • MCP 版と比較してトークン消費が約 4 分の 1(10ステップで ~27K vs MCP の ~114K)

課題

  • snapshot 自体のトークン量は大きい(13,000+ トークン)が、grep で必要箇所だけ抽出すれば実用上は問題ない
  • 既存ブラウザへの接続には別途セットアップが必要

なお、MCP 版の Playwright MCP ではツール定義だけで約 13,700 トークンを毎リクエスト消費する問題があり(GitHub Issue #889)、ある検証記事では10ステップで約 114,000 トークンを消費したと報告されている。CLI 版はこの問題を根本的に解決しており、同じタスクを約 27,000 トークンで完了できる。

操作ステップ数: 9(ログインフロー + Cookie ダイアログ対応含む)。手動介入は PIN 入力のみ。電話番号入力や国コード選択は自動化できた。

2. agent-browser (Vercel Labs)

agent-browser は Rust CLI + Node.js デーモンで構成され、アクセシビリティツリーとスクリーンショットのハイブリッド方式を採る。最大の特徴はトークン効率の高さである。

良かった点

  • snapshot -i(interactive only)オプションが極めて便利。フォーム要素だけに絞り込めるため、grep 不要でそのまま読める
  • コマンド出力が簡潔(✓ Done のみ)でトークン消費が少ない
  • ドロップダウンの操作(国コード選択など)も fill + click で問題なく動いた
  • Clerk(認証モーダル)も正常に操作できた

課題

  • Chrome/Chromium のみフル対応(Firefox 非対応、Safari 部分対応)
  • デバイスエミュレーションは事前定義プロファイル限定

トークン効率については、DEV Community の記事paddo.dev の分析で詳しく検証されている。1ページあたり 200〜400 トークンで表現できるのは、長いセッションにおいて決定的な優位性である。

操作ステップ数: 9(ログインフロー + Cookie 対応含む)。手動介入は PIN 入力のみ。電話番号入力や国コード選択は自動化できた。

3. Claude in Chrome (Anthropic)

Claude in Chrome は Chrome 拡張機能として動作し、Claude Code から MCP サーバー経由でブラウザを操作できる。既存のブラウザセッション(ログイン状態含む)をそのまま使える点が最大の利点である。

良かった点

  • find ツールが自然言語で要素を検索できる。"Sign In button" や "Song Description textbox" のような記述で一発で見つかる
  • form_input は ref 指定でフォーム入力が確実
  • スクリーンショットが画像として直接返る(ファイル保存不要)
  • 既存のブラウザセッションを共有できるため、ログイン済みならそのまま使える

課題

  • 致命的問題: 認証モーダル(Clerk)で chrome-extension:// コンテキストに切り替わり、Claude in Chrome からアクセス不能になった。スクリーンショット取得もクリックも失敗し、手動介入が必要になった
  • 操作のレイテンシが他ツールより大きい(各ツール呼び出しに数秒)
  • Chrome/Edge のみ対応

chrome-extension:// URL へのアクセス不能問題は GitHub Issue #29790 で報告されており、既知の制限事項である。また、接続の安定性に関する報告(#21796#24593#31897)も多数あり、MCP ブリッジの成熟度はまだ発展途上と言える。

操作ステップ数: 12(ログイン + Cookie + エラー復旧 + テキスト短縮含む)。手動介入は Continue ボタンクリック + PIN 入力(chrome-extension エラーのため)。

比較表

項目 Playwright CLI agent-browser Claude in Chrome
開発元 Microsoft Vercel Labs Anthropic
認識方式 Accessibility Tree A11y Tree + Screenshot A11y Tree + Screenshot
トークン効率 中〜高(定義 0、snapshot 大) 極高(定義 0、出力簡潔) 中〜低
ツール数 40+ 50+ 7カテゴリ
既存Chrome接続 要セットアップ CDP直接 Extension(セッション共有)
速度 高速 高速 遅い
認証フロー操作 △(chrome-extension問題)
操作ステップ数 9 9 12
手動介入 PINのみ PINのみ ボタン + PIN

結論

トークン効率を重視するなら agent-browser が圧倒的に優れている。 出力が簡潔で、1ページ 200〜400 トークンで表現される。長時間のブラウザ自動化セッションでは、この差が累積してコンテキストウィンドウの使い方に大きな影響を与える。

操作の正確性と安定性では Playwright CLI が最も信頼できる。 A11y Tree ベースの ref ID による要素特定は確実であり、snapshot + grep のワークフローは実用的である。snapshot のトークン量は大きいが、grep で必要な情報だけを抽出する運用でカバーできる。MCP 版と比べてトークン消費が約 4 分の 1 に削減されている点も大きい。

Claude in Chrome は「既存セッションの共有」という独自の利点があるが、chrome-extension:// コンテキスト問題や接続の不安定さは現時点では無視できない。認証フローを含むタスクでは手動介入が必要になる場面が多い。beta であることを考慮しても、本番運用にはまだ課題が残る。

私の所感としては、日常的なブラウザ自動化には agent-browser を第一選択とし、複雑な操作が必要な場面では Playwright CLI を併用するのが現時点でのベストプラクティスである。

注意事項

他企業が公開している Web サービスを AI エージェントで自動操作することは、対象サービスの利用規約で禁止されている場合がある。自動操作を行う前に、対象サービスの利用規約および robots.txt を確認し、公式 API が提供されている場合はそちらの利用を検討すること。本記事は特定のサービスに対する自動操作を推奨するものではない。

パスワードレス認証との相性

今回の検証では、対象サイトが SMS PIN によるパスワードレス認証を採用していた。この方式は AI ブラウザ自動化と相性が良いと感じた。

理由は明確で、パスワードを AI エージェントのコンテキストに渡す必要がない。agent-browser は暗号化ボールトによる credential 管理機能を持っているが、そもそもパスワードが存在しなければ、漏洩リスク自体がゼロになる。

同時に、SMS PIN は human-in-the-loop を自然に強制する。3ツールとも PIN 入力の段階で人間の介入が必要になったが、これは AI エージェントが勝手に認証を突破できないという意味で、セキュリティ上むしろ望ましい制約である。

ただし、パスワードレス認証のすべてが自動化と相性が良いわけではない。Passkey(WebAuthn)方式は生体認証やハードウェアキーを要求するため、AI エージェントでの自動化はさらに困難になる。SMS PIN は、パスワードレス認証の中では自動化しやすい部類に入る。

なお、いずれの方式でも --persistent--profile によるセッション永続化を使えば、ログイン頻度自体を減らせる。初回ログインさえ完了すれば、以降のセッションではログインフロー自体をスキップできるため、認証方式の違いは実運用上の影響が小さくなる。

参考リンク

評価をお願いします
まだ評価がありません
著者は、アプリケーション開発会社 Cyberneura を運営しています。
開発相談をお待ちしています。

アーカイブ