til/…/browser-mcp-2026
browser-mcp-2026.mdupdated 2026-08-012,044 chars

ブラウザ自動化 MCP 2026 — Playwright・chrome-devtools・agent-browser 比較

AIエージェントが​ブラウザを​操作する​ための​MCP​（Model Context Protocol＝AIと​ツールを​つなぐ​標準プロトコル）​サーバーには、​Playwright・chrome-devtools・agent-browserの​3系統が​ある。​トークン消費量、​認証済みセッションの​再利用可否、​成熟度が​大きく​異なり、​どれを​選ぶかで​タスクの​コスト構造が​劇的に​変わる。

画面状態を​LLMに​伝える​4つの​方​法

AIエージェントに​画面の​状態を​伝える​方​法は​主に​4通りある。​スクリーンショット​（vision＝画像を​読み取る​手法）は​1枚あたり5,000〜8,000トークンを​要し、​表現力は​最も​高いが​最も​高価である。​フルHTMLを​渡す方​法は​数万トークンに​の​ぼり、​現実的でない​ケースが​多い。​アクセシビリティツリー​（＝画面の​意味構造を​テキストで​表した​木構造）は​200〜12,000トークンで、​現在の​主流と​なっている。​さらに、​アクセシビリティツリーに​加えて​要素を​コンパクトな​参照IDだけに​絞る​方​法は​200〜400トークンで​済み、​agent-browserが​採用する​最も​軽量な​手法である。

Playwright MCP​（Microsoft公式）

Playwright​（プレイライト）​MCPは​アクセシビリティスナップショットを​標準採用しており、​ツール定義スキーマの​初期化だけで​約13,700トークンを​要する。​スナップショット1回あたり3,800〜12,000トークン、​テスト全体では​約114,000トークンを​消費したと​いう​実測が​報告されている。​E2Eテスト​（＝画面操作を​最初から​最後まで​通しで​検証する​テスト）、​CI/CD​（＝コード変更を​自動で​ビルド・検証・配布する​仕組み）、​SaaSの​疎通確認と​いった​用途に​最も​適しており、​成熟度・​安定性は​高い。​一方で、​すでに​ログイン済みの​Chromeセッションを​再利用しに​くいと​いう​弱点が​ある。

chrome-devtools-mcp​（Google公式）​— 認証済みサイトに​最強

chrome-devtools-mcpは​CDP​（Chrome DevTools Protocol＝Chromeブラウザを​外部から​制御する​内部​プロトコル）を​使って​既存の​Chromeプロセスに​アタッチ​（接続）する。​この​方​式に​より、​行政ポータル・銀行・社内ツールなどの​セッションを、​再ログインなしで​そのまま​利用できる。​ツールスキーマの​初期化には​約17,000トークンかかるが、​タスク全体で​見ると​Playwright比78%の​コスト削減が​報告されている。​Anthropic公式の​Claudeプラグインと​しても​配布されているが、​対応は​Chromiumのみで​Firefoxには​対応しない。

agent-browser-mcp​（Vercel Labs）​— 長期自律ループに​最適

agent-browser-mcpは​操作可能な​要素だけを​安定した​参照ID付きで​返す設計であり、​1ページ​あたり200〜400トークンと、​Playwrightの​約30分の​1に​抑えられる。​同じ​コンテキスト予算​（＝一度に​扱える​情報量の​上限）で​Playwright MCPの​5.7倍の​アクションを​実行できる​ため、​数百ステップに​及ぶ自律ループ​（例：Ralph Wiggum Loop）に​向いている。​ただし2026年初めに​リリースされた​ばかりで​本番運用の​実績は​まだ​少なく、​MCPラッパー自体も​コミュニティ製である​点には​注意が​必要である。

使い分けの​結論

認証が​必要な​業務には​chrome-devtools-mcpを​既定と​して​使い、​数百ステップに​およぶ​長期自律ループには​agent-browser-mcpへ​切り​替え、​テストパイプラインには​Playwright MCPを​使う​——と​いうのが​現時点の​ベストプラクティスである。

出典・参考

関連ノート

148 notestil