🎭

2026元日、Playwright MCPに触れて気づいた、LLM時代のブラウザ自動化の新しいパラダイム

に公開
AI
アクセシビリティ
Playwright
E2E
Model Context Protocol
tech

はじめに

年末年始でPlaywright MCPを触り直しています。きっかけは、MCPがLinux Foundation傘下のAgentic AI Foundationに移管されたというニュースでした。GitHub Starsは23,000を超え、2024年11月のMCP発表からわずか1年。最初は「また新しいツールか」程度に思っていたのですが、触っているうちに、これまで経験してきたブラウザ自動化とは何か違うと感じ始めました。

その違和感を年末年始で整理してみた結果、自分なりに言語化できたのが「Webページの表現方法」の変化という視点です。

PlaywrightとPlaywright MCPは別物である

最初に混乱したポイントを共有します。

PlaywrightとPlaywright MCPは、関連はあるものの根本的に異なるものです。自分は「PlaywrightのMCP対応版」くらいに思っていたのですが、それは誤解でした。

Playwright Playwright MCP
本質 ブラウザ自動化フレームワーク MCPサーバー実装
利用者 人間（開発者） LLM/AIエージェント
入力 コード（TypeScript/Python等） 自然言語 → 構造化コマンド
ページの表現 DOM/セレクタ ARIA Snapshot（アクセシビリティツリーのYAML表現）

Playwrightは開発者がコードを書いてブラウザを操作するためのフレームワークです。一方、Playwright MCPは、LLMがブラウザを操作するための「翻訳レイヤー」です。Playwrightの能力を借りていますが、目的も設計思想も異なります。

この区別がつかないまま触ると、何が新しいのかがわからなくなります。

ブラウザ自動化における「表現」の変遷

自分のブラウザ自動化歴を振り返ると、Selenium → Puppeteer → Playwright と渡り歩いてきました。今になって気づくのは、「Webページをどう表現するか」という問いへの答えが変わり続けてきた、ということです。

第1世代：DOM + セレクタ（Selenium時代）

最初に触ったのはSeleniumでした。WebDriverプロトコルでブラウザを制御し、ページはDOMツリー + CSSセレクタ/XPathで表現していました。

# 当時よく書いていたコード
element = driver.find_element(By.CSS_SELECTOR, "#login-button")
element.click()

HTMLの構造を理解していれば要素を特定できる。直感的ではありました。ただ、現実には...

  • クラス名が変わるとテストが壊れる
  • 「このボタンはこのセレクタで取れる」という暗黙知が必要
  • HTTPベースの通信が遅い（リクエスト/レスポンスの往復）

テストが不安定で、「ローカルでは動くのにCIで落ちる」に何度も遭遇しました。ブラウザ自動化は信用できない、という印象がこの頃に形成されました。

第2世代：CDP + 直接制御（Puppeteer/Playwright時代）

2017年にPuppeteer、2020年にPlaywrightが登場して、状況が変わりました。Chrome DevTools Protocol（CDP）を使うことで、WebSocketによる双方向通信が可能になり、パフォーマンスと安定性が大幅に向上しました。

// Playwrightの自動待機
await page.click('button'); // visible, enabled, 遮蔽なしを自動確認

待機処理を自分で書かなくてよくなったのは、実務上かなり大きな改善でした。

ページの表現方法自体はDOMベースのままでしたが、Playwrightはロールベースのセレクタを導入しました。

await page.getByRole('button', { name: 'Submit' }).click();

「この要素のHTMLはこう」ではなく「この要素の意味はこう」という発想。この転換が、後のPlaywright MCPに直接つながっていたのだと今は思います。

第3世代：アクセシビリティツリー（Playwright MCP）

そして2025年、Playwright MCPが本格的に普及しました。ここでページの表現方法が決定的に変わります。

スクリーンショットでも、DOMでもなく、アクセシビリティツリーです。Playwright MCPでは、これを「ARIA Snapshot」と呼ばれるYAML形式で表現します。

# Playwright MCPがLLMに渡すページ表現（ARIA Snapshot）
- banner:
  - heading "ログイン" [level=1]
  - textbox "メールアドレス"
  - textbox "パスワード" [type=password]
  - button "ログイン"
  - link "パスワードを忘れた方"

これはPlaywrightのlocator.ariaSnapshot()が出力するYAML形式の構造化データです。スクリーンリーダーが「見る」ページの姿を、LLMが解釈しやすい形式で表現したものと言えます。

最初見たときはピンと来ませんでした。なぜこれが革新的なのか。

なぜアクセシビリティツリーなのか

理解するのに時間がかかりましたが、今は納得しています。

スクリーンショットベースの限界

2024年頃、多くのAIブラウザ自動化ツールはスクリーンショットベースでした。ページを画像として取得し、Vision Model（GPT-4V等）で解析して要素を特定する方式です。

自分も試したことがありますが、この方式にはいくつかの問題がありました。

  1. 曖昧性: 「このボタンっぽいものをクリック」という推測が入る
  2. コスト: Vision Modelは高価で遅い
  3. 非決定性: 同じ画面でも毎回異なる解釈をする可能性がある

「動くときは動くけど、なぜ動くのかわからない」という感覚がありました。

アクセシビリティツリーの優位性

アクセシビリティツリー（Accessibility Tree）は、ブラウザが支援技術（スクリーンリーダー等）のために生成する構造化データです。W3CのAOM（Accessibility Object Model）仕様でアクセス方法が標準化されつつあり、PlaywrightはこれをariaSnapshot()メソッドでYAML形式に出力します。

これをLLMに渡すと：

  1. 決定論的: 同じページなら同じ構造が返る
  2. 軽量: テキストデータなのでトークン効率が良い（70-80%削減という報告も）
  3. 意味的: role、name、stateが明示されているので解釈の余地がない
// Playwright MCPの内部処理（概念的なイメージ）
const snapshot = await page.locator('body').ariaSnapshot();
// → LLMはこのYAML形式のスナップショットを読んで操作を決定

つまり、「LLMにとってのWebページの最適表現」を見つけた、ということなのだと理解しています。

2つのアプローチの比較

MCPという標準化の意味

Playwright MCPを語る上で、MCP（Model Context Protocol）自体についても触れておきます。

N×M問題の解決

2024年11月、AnthropicがMCPを発表した背景には「N×M問題」がありました。N個のAIアプリケーションとM個のツール/データソースを接続しようとすると、N×M個のカスタムコネクタが必要になる。

これは実感としてわかります。去年、いくつかのAIツールを業務に組み込もうとしたとき、それぞれ独自のAPI設計で、同じようなコードを何度も書く羽目になりました。

MCPは、Language Server Protocol（LSP）の発想を借りて、この問題を解決しようとしています。LSPがエディタと言語サーバーの間を標準化したように、MCPはLLMと外部ツールの間を標準化します。

2025年の急速な普及

MCPの普及速度には驚きました。

Anthropic、OpenAI、Google、Microsoftが同じ標準を支持するのは珍しいことです。

Playwright MCPの具体的な仕組み

もう少し具体的に、Playwright MCPがどう動くのかを見ていきます。

提供されるツール群

Playwright MCPは、以下のようなツールをLLMに公開します。

browser_navigate   - URLへの遷移
browser_click      - 要素のクリック
browser_type       - テキスト入力
browser_snapshot   - ページのARIA Snapshot取得
browser_screenshot - スクリーンショット取得（記録用）
browser_evaluate   - JavaScript実行
...

触っていて気づいたのは、browser_snapshotがデフォルトの「ページを見る」手段で、browser_screenshotはあくまで補助的な位置づけだということです。公式ドキュメントにも「browser_snapshot is preferred over screenshots for performing actions」と明記されています。

refパラメータによる要素指定

LLMがページを操作する際、ARIA Snapshotに含まれるref（参照ID）を使います。

elementは人間が読むための説明、refは機械的な識別子です。この二重構造は、デバッグ時に「LLMが何を意図していたか」がわかりやすくて助かっています。

従来のPlaywrightとの使い分け

実務的な観点で、今のところこう使い分けています。まだ試行錯誤中ですが。

Playwright MCPが向いているケース

  • 探索的テスト: 「このサイトを一通り触って問題を見つけて」
  • 新機能の検証: フローが確定していない段階での動作確認
  • バグ再現: 「この手順で再現して」という自然言語指示
  • プロトタイピング: テストコードを書く前の挙動確認

従来のPlaywrightが向いているケース

  • 回帰テスト: 確定したフローを繰り返し実行
  • CI/CDパイプライン: 高速・低コストな自動実行
  • 大規模テストスイート: 数百〜数千のテストケース
  • 厳密なアサーション: 「この要素のテキストが正確にこれ」

両者は排他的ではなく、補完的だと感じています。Playwright MCPで探索し、安定したフローはPlaywrightのテストコードに落とし込む。このワークフローが今のところしっくり来ています。

触ってみて感じていること

ここからは、まだ整理しきれていない所感です。

ブラウザの「見え方」が変わった

Playwright MCPを使っていると、ブラウザを見る視点が変わります。以前は「このボタンのセレクタは何だろう」と考えていましたが、今は「このページのアクセシビリティ構造はどうなっているか」を意識するようになりました。

結果として、アクセシビリティへの関心が高まりました。適切なrole、aria-label、見出し構造...これらがLLMにとっての「ページの見え方」を決めるからです。AIのためにアクセシビリティを改善すると、人間（支援技術を使うユーザー）のためにもなる、という構図は興味深いです。

「コードを書かない」の意味

Playwright MCPは「コードを書かずにブラウザ操作」と紹介されることがありますが、これは半分正しく半分誤解を招きます。

確かに、テストスクリプトを一から書く必要はありません。しかし、出力されるコードのレビュー、セレクタ戦略の理解、Playwrightの動作原理の把握...これらは依然として必要です。むしろ、Playwrightを理解していないと、MCPの出力が妥当かどうか判断できません。

「コードを書かない」ではなく「コードを書く前の探索が高速化する」が実態に近いと思います。

使っていて気になる点

自分が使った範囲では、いくつか気になる点もあります。

  • 出力の一貫性: 同じ指示でも若干異なる操作になることがある
  • 複雑なシナリオ: 複数タブ、認証フロー、動的UIなどでの挙動が不安定な場面もある
  • トークンコスト: 大きなページではスナップショットが肥大化する

もちろん、自分の使い方や理解が不十分な部分もあるかもしれません。コミュニティでは改善が進んでいて、Fast Playwright MCPのようなトークン最適化版も登場しています。

2026年以降を見据えて

最後に、少し先のことを考えてみます。これは予想というより、自分が気にしていることです。

WebDriver BiDiとの関係

W3Cでは、WebDriver BiDi（Bidirectional）の標準化が進んでいます。WebDriverの相互運用性とCDPの双方向性を兼ね備えた次世代プロトコルです。

Playwright MCPは現在CDPを内部で使っていますが、WebDriver BiDiが普及すれば、よりクロスブラウザな実装が可能になります。ブラウザ自動化の基盤レイヤーが標準化され、その上にMCPレイヤーが乗る...という構造が見えてきます。

この辺りのプロトコル層の関係性は、もう少し勉強が必要だと感じています。

AIエージェントの普及

MCPがLinux Foundationに移管されたことで、AIエージェントの相互運用性が本格的に議論されるフェーズに入りました。Playwright MCPは、その中でも成熟度の高いMCPサーバー実装の一つです。

Webブラウザは依然として最も普遍的なUIです。AIエージェントが実世界のタスクをこなすとき、ブラウザ操作は避けて通れません。Playwright MCPが提示した「ARIA Snapshotによるページ表現」は、その基盤になる可能性があると考えています。

ただ、本当にそうなるかはわかりません。2026年が終わる頃、また振り返ってみたいです。

おわりに

Playwright MCPに触れて気づいたのは、これが単なる「便利なツール」ではないということです。

「Webページをどう表現するか」という問いへの新しい答えのひとつなのかなと思います。DOM + セレクタから、アクセシビリティツリー（ARIA Snapshot）へ。人間向けの表現から、LLM向けの表現へ。

Selenium → Puppeteer/Playwrightの変化と同じくらい、もしかするとそれ以上に大きな転換点かもしれません。

まだ理解しきれていない部分も多いですし、ツール自体も進化の途上にあります。でも、方向性としてはこちらに向かっていくのだろうという感触は持てるようになりました。

引き続き追いかけていきます。

参考リンク

Discussion