皆さん、こんにちは。プラットフォーム技術部の林と申します。
しばらくご無沙汰しておりましたが、また記事を書いてみようと思います。
以前、Playwrightについての記事を書きましたが、その後さらに触っていく中で、Playwright MCPとPlaywright CLIにも挑戦してみました。今回はその延長として、実際に触ってみた感想を共有したいと思います。
Playwrightについて詳しく知りたい方や、これから学び始める方は、こちらの記事もぜひご覧ください。
https://developers.play.jp/entry/2022/12/09/160940
Playwright MCPとは？
Playwright MCPは、ブラウザ上の情報をAIエージェントが直接参照できるようにするための仕組みです。
従来のAIを用いた開発フローでは、人間がブラウザを開いてテスト結果を確認し、その情報をプロンプトに含ませる必要がありました。
しかし、Playwright MCPを活用すれば、エージェントはページ上の構造情報（DOM、アクセシビリティツリーなど）をコンテキストとして直接読み取ることが可能になります。
Playwright MCPが提供する主な操作一覧
| ツール名 | 機能 |
|---|---|
playwright_navigate |
指定したURLに移動する |
playwright_screenshot |
画面のスクリーンショットを撮る |
playwright_click |
指定した要素をクリックする |
playwright_fill |
入力フォームに値を入力する |
playwright_inspect_dom |
ページの構造を詳細に解析する |
これにより、自然言語の指示からPlaywrightの操作を即座に実行させることができます。 詳細についてはPlaywright MCP 公式リポジトリで！
Playwright CLIとは？
Playwright CLI の動作イメージ
playwright-cli は、AIがコマンド経由でブラウザ操作を実行する仕組みです。
MCPのように毎回DOM全体をAIに渡して解析させるのではなく、
CLIを通して明示的に操作を実行する点が特徴です。
仕組みの流れ
- コマンド実行時にページの snapshot を取得
- 各要素に対応する ref（参照ID） が生成される
- その情報が
.playwright-cliフォルダ内に YAML形式で保存 される - YAML中のref（参照ID）を参照して、操作対象の要素を特定する
それでは、実際に操作しましょうか！
実例1：Googleを開く
% playwright-cli open https://google.co.jp
出力例：
### Ran Playwright code
await page.goto('https://google.co.jp');
### Page
- Page URL: https://www.google.com/
- Page Title: Google
### Snapshot
- [Snapshot](.playwright-cli/page-2026-○○-○○T○○-○○-○○-○○○Z.yml)
本操作によりGoogleのページが起動し、各要素の ref 情報を保持したスナップショットファイルが .playwright-cli フォルダ内に生成されます。
これによりGmailリンクの ref が e10 であることが特定できたので、次は実際にそのスナップショット内を確認し、Gmailリンクの ref が正しく e10 と定義されているかチェックしましょう！
実例2：Gmailリンク
% playwright-cli click e10
出力例：
### Ran Playwright code
await page.getByRole('link', { name: 'Gmail' }).click();
### Page
- Page URL: https://accounts.google.com/v3/signin/identifier?continue=https%3A%2F%2Fmail.google.com...
- Page Title: Gmail
### Snapshot
- [Snapshot](.playwright-cli/page-2026-○○-○○T○○-○○-○○-○○○Z.yml)
### Events
- 1 new console entry in ".playwright-cli/page-2026-○○-○○T○○-○○-○○-○○○Z.yml#L1"
これで、無事にGmailのログインページへ遷移できました！
本手法の特徴は、スナップショットから取得した各要素に固有の参照ID（ref）を付与し、その構造情報をYAML形式で保存・管理する点にあります。
そのため、処理の流れが明確であり、どの要素に対して操作を行っているのかを人間側でも正確に把握・追跡できるのが大きなメリットです。
環境構築
AIエージェントには様々な種類があり、皆さんもそれぞれ好みのツールを使っているかと思います。
(意図せずファイルを削除してしまうようなものではない前提で)
今回は、私が普段利用している VS Code と GitHub Copilot を例に、Macでの環境構築手順を説明します。
1. ブラウザ実行環境の準備
まずは、MCP経由でブラウザを動かすために必要なPlaywright本体をインストールしておきます。ターミナルで以下を実行します。
# プロジェクトフォルダの作成 mkdir hogehoge && cd hogehoge # 初期化とPlaywrightのインストール npm init -y # Playwright本体とMCPサーバー用パッケージのインストール npm i playwright @playwright/mcp # Playwright CLI のインストール npm install -g @playwright/cli@latest
Playwright は複数ブラウザに対応しています。
Chromium 以外を利用する場合は、それぞれインストールが必要です。
# Firefox のインストール npx playwright install firefox # WebKit（Safari相当）のインストール npx playwright install webkit
2. VS Codeの設定
次に、VS CodeのChat（Copilot）でMCPを使えるように設定します。
- VS Codeでコマンドパレット（
Cmd + Shift + P）を開き、Chat: Chat Settingsを入力します。
Chat設定 - 設定画面で Chat > Agent: Enabled にチェックを入れ、有効化します。
Chat有効化 - 再度コマンドパレットから
MCP: Open User Configurationを開き、以下のサーバー情報をmcp.jsonに追加します。
{ "servers": { "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp"], "type": "stdio" } } }
mcp.json で --browser を指定しない場合、現状は Chrome のみが利用されます。
もし他のブラウザを利用したいなら、mcp.json への設定追加とインストールが必要です。
設定後は、chat 上で指定したブラウザを用いたテストが実行可能となります。
{ "servers": { "playwright-chrome": { "command": "npx", "args": ["@playwright/mcp", "--browser", "chromium"], "type": "stdio" }, "playwright-firefox": { "command": "npx", "args": ["@playwright/mcp", "--browser", "firefox"], "type": "stdio" }, "playwright-webkit": { "command": "npx", "args": ["@playwright/mcp", "--browser", "webkit"], "type": "stdio" }, "playwright-edge": { "command": "npx", "args": ["@playwright/mcp", "--browser", "msedge"], "type": "stdio" } } }
現状、Playwright MCPにて指定可能なブラウザは chrome、firefox、webkit、msedge の4種類です。
詳しく内容はPlaywright MCP 公式リポジトリからご覧ください。
- 設定後、MCPパネルからサーバーを起動（Startを押下して、Runningにする）すれば準備完了です。
Start 
Running
実行
今回試してみた方法は、主に2つあります。 1つは自然言語の指示、もう1つは Playwright CLI を使用する方法です。
今回用意したの例は、以下のようなExcel（test_cases.xlsx）を用意します。
| 前提条件 | 検証手順 | 期待結果 | 結果 |
|---|---|---|---|
| Googleへ遷移しておく | Gmailを選択する | Gmailページへ遷移する |
これをGitHub Copilotに読み込ませ、チャット欄から
このExcelの指示通りにPlaywright MCPを使って実行し、成否を結果列に記入して保存して
と指示します。
Playwright MCP のみ
まずは CLI を使わず、Playwright MCP を使うように指示してみます。
Excelシートに書かれた日本語の指示を、AIに直接実行させて結果を更新させる
- Excelの解釈: AIが前提条件と検証手順を読み取り、実行順序を組み立てます。
リクエスト内容 - 自律操作:
playwright_navigateでページを開き、DOMを解析して最適な要素を自動で見つけ、分析やクリックを行います。 - 結果の反映: 期待結果を満たしているかブラウザ上で確認し、Excelの結果セルに自動的に記入します。
テスト結果 
シート内容
Playwright CLI
Playwright CLI の使用を明記してみます。
Excelシートに書かれた日本語の指示を Playwright CLI 経由で AI が実行し、その結果を自動的にシートへ反映する
今回の例では「✔️ PASS」のような結果表示が少し気になりますが、
これはリクエスト時のプロンプトで、あらかじめ「PASS」「NG」などの結果形式を明記しておくべきポイントでした。
実際にはAIが自動的にその形式で出力するわけではないため、
結果の書式を指定しておけば、より分かりやすい出力になったと思います。
メリット
- ノーコードでの操作実現:
「Gmailを選択する」といった自然言語の指示だけで、AIが対象のボタンを自動特定します。これまでのように、複雑なXPathやCSSセレクターを手動で調査・記述する手間から解放されます。 - メンテナンスコストの劇的な削減:
サイトのデザインや構造に軽微な変更があっても、AIが人間のように文脈を判断して操作を継続してくれます。従来のように、要素の変更を検知するたびに頻繁にコードを修正し続ける泥臭い作業は、もう不要です。
デメリット
- AIの「学習データ」による混乱 :
Playwright CLIを用いたアプローチは比較的新しいため、AI（LLM）側の振る舞いに不安定な要素が残っています。
実際操作した時に「Playwright CLIでテストして」と指示しても、AIが最新のCLIスキルではなく、学習データに豊富にある従来のテストコード（Playwright Test）の生成・実行を優先してしまうことがあります。 - 意図しない挙動 :
テストスクリプトを書き始めてしまい、リアルタイムなブラウジングが中断されるケースが多々あります。
この指示の微調整（プロンプトエンジニアリング）にかかる時間を考えると、結局、人間が手動でコマンドを叩いた方が早いという本末転倒な状況に陥りやすいのが現状です。
まとめ
Playwright MCPとPlaywright CLIを触ってみて、ブラウザ操作の自動化がコードからAIへの指示へと変わる大きな可能性を感じました。
特に印象的だったのは、Excelなどの既存ドキュメントと組み合わせる運用です。これが実現すれば、専門知識がなくてもテスト自動化を運用できる未来がすぐそこまで来ていると実感しました。
一方で、UI変更が激しく壊れやすい箇所の自動化をあえて限定するなど、メンテナンスコストを考慮した使い分けこそが、現時点における現実的な最適解ではないでしょうか。
皆さんもぜひ、Playwright MCPとPlaywright CLIを試してみてください！
