Playwright MCPでE2Eテストを自動化する方法|導入手順と使いどころ

「AIに画面を操作させてテストできないか」
その仕組みを提供するのが Playwright MCP です。
Microsoftが公開しているオープンソースで、無償で使えます。
設定ファイルを1つ書けば、AIがブラウザを操作できるようになります。
ただし、回帰テストの主軸には向きません。
毎回同じ結果になるとは限らないためです。
この記事では、導入手順と実際の使いどころを解説します。
向かない用途と、テストコードに落とし込む流れまで整理しました。
Playwright MCPとは
Playwright MCP は、AIにブラウザ操作の機能を渡すためのサーバーです。
MCPは Model Context Protocol の略で、AIと外部ツールをつなぐ共通の規格です。
これを使うと、AIが自分でページを開き、クリックし、入力できます。
人が操作手順を1つずつコードで書く必要がありません。
画像ではなく構造で画面を理解する
特徴は、画面の見た目ではなくアクセシビリティツリーを使う点です。
これはブラウザが内部で持っている、画面構造のデータです。
| 方式 | 仕組み | 特徴 |
|---|---|---|
| 画像認識型 | スクリーンショットをAIが見る | 画像を扱えるモデルが必要。読み取りが曖昧になりやすい |
| Playwright MCP | 画面構造のデータを読む | 要素を確実に特定でき、処理も軽い |
ボタンやリンクが「何であるか」を、AIが文字情報として受け取れます。
そのため、座標のずれや描画の違いに影響されません。
通常のPlaywrightとの違い
名前は同じですが、使い方も用途も異なります。
置き換えるものではなく、組み合わせて使います。
| 比較軸 | 通常のPlaywright | Playwright MCP |
|---|---|---|
| 指示の方法 | コードを書く | 自然言語で伝える |
| 実行結果 | 毎回同じ | 毎回同じとは限らない |
| 速度 | 速い | 遅い(AIの応答を待つ) |
| 費用 | 無償 | 無償(ただしAIの利用料がかかる) |
| 向く用途 | 回帰テストの自動実行 | 探索的な確認、下書き作成 |
実務では「MCPで下書きを作り、Playwrightのコードとして固定する」流れが現実的です。
両者の長所を使い分けられます。
導入手順
準備するものは Node.js と、MCPに対応したAIツールだけです。
Claude Desktop、VS Code、Cursor などが対応しています。
STEP1|設定ファイルに追記する
利用するAIツールのMCP設定に、次の内容を追加します。
これだけで、次回の起動時から使えるようになります。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}
設定ファイルの場所は、AIツールごとに異なります。
多くのツールでは、設定画面からMCPサーバーを追加できます。
STEP2|起動して接続を確認する
AIツールを再起動し、ブラウザ操作の機能が増えているか確認します。
初回はブラウザのダウンロードが走るため、少し時間がかかります。
「指定したページを開いて、見出しを教えて」と指示してみます。
ブラウザが立ち上がれば、接続は成功しています。
STEP3|実行方法を調整する
用途に応じて、起動時のオプションを加えます。
よく使うものを挙げます。
| オプション | 効果 | 使う場面 |
|---|---|---|
| –headless | 画面を表示せずに実行する | CI環境、動作を見なくてよい場合 |
| –browser | 使うブラウザを指定する | Chrome以外での確認 |
| –device | 端末の画面サイズを模倣する | スマートフォン表示の確認 |
| –isolated | 状態を保存せず毎回まっさらにする | ログイン状態を持ち越したくない場合 |
最初は画面を表示したまま使うことをすすめます。
AIが何をしているか、目で確認できるためです。
テスト業務での使いどころ3つ
効果が出るのは、決まった手順を繰り返す場面ではありません。
むしろ「手順が決まっていない仕事」に向きます。
使いどころ1|探索的テストの補助
目的を伝えて、AIに画面を触らせます。
人が思いつかない操作順序を試すことがあります。
探索的テストの進め方そのものは、探索的テストの進め方|規律ある4ステップ実践ガイドで解説しています。
使いどころ2|テストコードの下書き生成
実際に操作させたうえで、その手順をコードとして出力させます。
画面を見ながら書かせるため、要素の指定が実物と合います。
これが最も実用的な使い方です。
ゼロからコードを書く時間を大幅に減らせます。
使いどころ3|画面仕様の把握
仕様書がない画面の項目を洗い出させます。
入力欄の種類や必須項目を、一覧にしてもらえます。
資料が不足している状況での進め方は、資料なしのテスト代行は可能|依頼前の準備と進め方にまとめています。
実際の指示の書き方
指示は具体的にします。
曖昧だと、AIが勝手に判断して別の操作をします。
| 目的 | 指示の例 |
|---|---|
| 画面項目の洗い出し | 「このページの入力欄をすべて挙げて、必須かどうかを表にして」 |
| 異常系の確認 | 「メールアドレス欄に全角文字を入れて送信し、エラー文言を報告して」 |
| コード生成 | 「今の操作をPlaywrightのテストコードにして。要素はロールと名前で指定して」 |
| 表示崩れの確認 | 「スマートフォンの幅で開いて、見切れている要素があれば教えて」 |
コード生成では、要素の指定方法まで指定します。
指定しないと、壊れやすいセレクタが使われることがあります。
向かない用途と注意点
できることが多い分、誤解も生まれやすい仕組みです。
次の点は、導入前に理解しておきます。
- 回帰テストの主軸にはできない:同じ指示でも操作が変わることがあり、結果が安定しない
- 実行が遅い:1操作ごとにAIの応答を待つため、大量のケースには向かない
- 利用料がかかる:MCP自体は無償だが、AIの利用量に応じた費用が発生する
- 本番環境では使わない:AIが想定外の操作をする可能性がある
- 認証情報の扱いに注意:画面の内容がAIに送られる前提で運用する
とくに4番目は徹底してください。
検証環境で、消えても困らないデータを使います。
テストコードに落とし込む流れ
実務での現実的な使い方は、下書きを作らせて固定することです。
次の順で進めます。
- MCPでAIに操作させ、対象の画面を通しで動かす
- その手順をPlaywrightのコードとして出力させる
- 期待値(何をもって合格とするか)を人が書き直す
- 版管理に入れ、CIから毎回実行する
3番目が最も重要です。
AIが書いた期待値は、現在の画面をなぞっているだけの場合があります。
確認すべき観点はAI生成テストコードのレビュー観点|そのまま使えないコードの見分け方にまとめました。
よくある質問
プログラミングの知識は必要ですか
操作させるだけなら不要です。
ただし生成したコードを運用する段階では、読める必要があります。
Autify や MagicPod の代わりになりますか
用途が違います。
継続的な回帰テストの運用には、有償ツールのほうが適しています。
比較はAIテスト自動化ツール比較|Autify・MagicPod・mabl・Playwright MCPの選び方で整理しています。
CI環境で動かせますか
技術的には可能ですが、結果が安定しないため推奨しません。
CIでは、生成したPlaywrightのコードを実行します。
まとめ|下書きを作らせ、コードで固定する
Playwright MCP は、AIにブラウザを操作させる無償の仕組みです。
導入は設定ファイル1つで済みます。
- 画面構造のデータを読むため、要素を確実に特定できる
- 向くのは探索的テスト、下書き生成、画面仕様の把握
- 結果が安定しないため、回帰テストの主軸にはしない
- 本番環境では使わず、検証環境に限定する
- 生成後は期待値を人が書き直し、コードとして固定する
まずは検証環境で、1画面の項目洗い出しから試してください。
設定を書いてから動くまで、10分ほどで確認できます。
次に読むならこの記事
テストの手戻りを減らしたい方へ
テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。



