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との違い

名前は同じですが、使い方も用途も異なります。
置き換えるものではなく、組み合わせて使います。

比較軸通常のPlaywrightPlaywright 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テンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

ソフトウェアテスト代行サービスのご紹介

当社では10万円から始められるソフトウェアテスト代行サービスを提供しています。

テスト専門部隊による品質保証で、開発チームは本来の開発業務に集中できます。
品質向上と納期遵守の両立をサポートし、顧客からの信頼獲得に貢献します。

お問い合わせ

サービスに関するお問い合わせ、ご不明な点がございましたら、以下のお問い合わせフォームをご利用ください。お客様からのご質問に対し、担当者が責任を持ってお答えいたします。

よかったらシェアしてね!
目次
閉じる