社内の業務システムやBtoB SaaSでE2Eテスト（画面操作を実際に再現して確認するテスト）を自動化したい、あるいは問い合わせ対応やデータ入力を代行するエージェントを作りたい。そういった場面で「AIにブラウザを操作させる」選択肢が急速に実用段階に入っています。既存のSeleniumやPlaywrightのテストコード資産がある現場ほど、どの仕組みを足すべきか迷いやすいところです。
この種のツールはもともと、画面をスクリーンショットで撮り、画像認識モデルにボタンの座標を推測させる方式が主流でした。誤クリックが多く、業務システムの複雑な画面では実用に耐えないことも珍しくありませんでした。現在主流の方式は、画面をアクセシビリティツリー（画面の要素を構造化データとして表現したもの。スクリーンリーダー向けにブラウザが標準で持っている情報です）として読み取り、要素ID（例えば「@e3」のような参照名）を指定してクリックする仕組みに置き換わっています。見た目ではなく構造を読むため、画面のレイアウトが多少変わっても壊れにくいのが特徴です。
選択肢として代表的なのが、Microsoftが開発する「Playwright MCP」、Pythonライブラリの「Browser Use」、Vercel Labsが公開するRust製CLIの「agent-browser」の3つです。MCP（Model Context Protocol、AIエージェントが外部ツールを呼び出すための標準規格）という言葉が出てきますが、要は「AIコーディングアシスタントにブラウザ操作という道具を持たせる共通の渡し方」と理解すれば十分です。
判断軸1: 誰が操作の起点になるか
まず整理すべきは「人間が指示するたびにAIがブラウザを動かすのか」「AIが最初から最後まで自律的にタスクをこなすのか」という違いです。
Playwright MCPとagent-browserは、Claude CodeやCursor、VS Codeのようなコーディングエージェントに「ブラウザを操作する道具」を追加する形です。開発者が「localhost:3000を開いてテストメールでサインアップし、どのステップで失敗するか教えて」のように指示を出し、エージェントがその都度ブラウザ操作のツールを呼び出します。
一方Browser Useは、Pythonスクリプトの中でエージェントループ（タスクを分解し、実行し、結果を確認するまでを自動で繰り返す仕組み）を丸ごと動かします。人間は最初にタスク内容を自然言語で渡すだけで、あとはエージェントが自律的にブラウザを操作し続けます。定型バッチ処理や、夜間に走らせる自動巡回タスクに向いた形です。
判断軸2: 既存のテスト資産との接続のしやすさ
既にPlaywrightやSeleniumでE2Eテストを書いている現場なら、Playwright MCPが最も摩擦が少ない選択です。Playwright自体をMCPツールとして公開しているだけなので、既存のテストコードやCI構成を大きく変える必要がありません。
導入はコマンド一つで済みます。Claude Codeの場合は以下です。
claude mcp add playwright npx @playwright/mcp@latestVS Codeならcode --add-mcp、Codexならcodex mcp add playwrightと、各クライアントに応じたコマンドが用意されています。CursorやWindsurf、Claude Desktopなど標準のMCPクライアントであれば、JSON形式の設定ブロックをそのまま貼り付ける方式です。
Browser Useはゼロから書く独立したPythonプログラムなので、既存のテストスイートへの統合よりも、新規のエージェント機能として作る方が相性がよいツールです。
判断軸3: コンテキストコスト（LLMに渡す情報量とそれに伴うAPIコスト）
業務システムの画面は項目数が多く、アクセシビリティツリーも巨大になりがちです。MCP経由でツールのスキーマや画面全体のツリーを毎回LLMのコンテキストに読み込ませると、トークン消費がかさみます。
ここで候補に挙がるのがagent-browserです。Rust製の軽量CLIで、短いシェルコマンドを介してブラウザを操作します。MCPのようにツール定義やアクセシビリティツリー全体をコンテキストに積み上げる必要がなく、トークン効率を重視する現場向けの設計です。
Microsoft自身もPlaywright MCPのドキュメントで「長時間のステートフルなループ（探索的テストや自己修復型テストなど）はMCPが有利だが、単発のタスクをこなすだけならPlaywright CLIとスキルの組み合わせの方がトークン効率で勝ることがある」と明記しています。常時接続するMCPサーバーと、都度呼び出すCLIのどちらが適するかは、タスクの性質次第です。
判断軸4: モデルの選択自由度
Playwright MCPとagent-browserは「道具」の提供に徹しており、どのLLMを使うかはホスト側のコーディングエージェント（Claude Code、Cursorなど）の設定に依存します。
Browser UseはChatOpenAIのようにLLMクライアントを自分のコードで指定する設計です。OpenAI系以外のモデルに切り替えたい、複数モデルを使い分けたいという要件があるなら、こちらの自由度の高さが効いてきます。
選択肢の比較
| 項目 | Playwright MCP | Browser Use | agent-browser |
|---|---|---|---|
| 提供形態 | MCPサーバー | Pythonライブラリ | Rust製CLI |
| 操作の起点 | コーディングエージェントが都度呼び出す | エージェントが自律実行 | コーディングエージェントが短いコマンドで呼び出す |
| 既存テスト資産との親和性 | 高い（Playwrightをそのまま利用） | 低い（新規実装が前提） | 中程度 |
| コンテキストコスト | やや高い（ツリー全体を読み込む） | タスク次第 | 低い（最小限のコマンド） |
ケース別の推奨
既存のPlaywright/SeleniumベースのE2Eテストがあり、Claude CodeやCursorで画面の動作確認や自己修復型テストを作りたいなら、Playwright MCPを選ぶのが筋です。導入コストが最も低く、--headlessでCI上の無人実行にも対応できます。--isolated --storage-state=path/to/storage.jsonを使えば、ログイン済み状態を保存してセッションを使い回すことも可能です。
社内の問い合わせ対応や定型データ収集のように「人間が都度指示を出さずに一つのタスクを最初から最後まで自律的にこなしてほしい」という要件なら、Browser Useが候補になります。uv add browser-useでインストールし、タスクを自然言語で渡すだけで動かせる手軽さがあります。
大量のエージェントを並行稼働させる、あるいはトークン単価が高いモデルを使っていてコストを切り詰めたいという制約があるなら、agent-browserの軽量さが効いてきます。短いシェルコマンドでブラウザを操作する設計のため、MCPのツールスキーマ分のオーバーヘッドを避けられます。
あえて見送るべき条件
画面のテストケースが少数で、手動テストや既存のPlaywrightスクリプトで十分回っているなら、わざわざAIエージェントを挟む必要はありません。構造化データを読む方式とはいえ、LLMの呼び出しにはレイテンシとコストが発生します。決まった手順をなぞるだけのテストはスクリプトのままの方が速く安定します。
また、金融系や医療系の業務システムで操作ログの完全な再現性や監査証跡が厳密に求められる場合、LLMの判断を介在させる設計自体を慎重に検討すべきです。エージェントは同じ指示でも毎回まったく同じ操作列を取るとは限らないため、既存のPlaywright/Seleniumスクリプトによる決定的なテストと役割を分けて考える必要があります。
導入前に確認すること
まず手元の環境で、ホストにしているコーディングエージェント（Claude Code、Cursor、VS Codeなど）がMCPに対応しているか確認してください。対応していればPlaywright MCPの導入コストは最小です。
- 既存のE2Eテスト資産があるか→あればPlaywright MCPを優先
- 自律実行型のエージェントが必要か→Browser Useを検討
- トークンコストやレイテンシの制約が厳しいか→agent-browserを検討
- 操作ログの完全な再現性が必須か→AIエージェントの導入自体を見送る
どのツールも公式READMEにクイックスタートのコマンドが用意されているため、まずは開発環境でPlaywright MCPをnpx @playwright/mcp@latest経由で動かし、アクセシビリティスナップショットがどのような情報を返すか実際に確認してみるのが、判断の精度を上げる近道です。