はじめに
初めまして！
皆さん、テストの必要性をご存知ですか？
私は配属先で仕事をするまでテストの必要性や重要性を全くわかっていませんでした。
さらにいうと、テストにもいろんな種類があることも初めて知りました。
これはまずいと色々調べていくうちに、今回の題材であるPlaywright MCPと出会いました。
「テストの勉強もできてMCPも触れるならラッキー」くらいの感覚で触ってみたら思いのほか面白かったので、自分自身の整理の意味も込めて、今回初めて記事を書いてみようと思います。
Playwrightとは
Playwrightは、Microsoftが開発したオープンソースのWeb UI自動化テストフレームワークです。Webアプリケーションのエンドツーエンド (E2E) テストを効率的かつ信頼性高く行うために設計されています。
Playwright MCPとは
Playwright MCPは、2025年3月にMicrosoftから発表された、AI（大規模言語モデル、LLM）がブラウザを直接かつ自動で操作できるようにするためのサーバー技術です。ブラウザ自動化ツール「Playwright」の拡張機能として提供されています。
「MCP」とは「モデルコンテキストプロトコル（Model Context Protocol）」の略です。従来のスクリーンショットによる画像解析とは異なり、ページの構造情報であるアクセシビリティツリーを利用してUIを制御するため、高速かつ安定した動作が可能です。
アクセシビリティツリーを利用することで、ボタンの色やレイアウトが変わっても、要素の役割（ロール）やラベルが同じであれば動作し続けます。従来のCSSセレクタベースのテストでは、デザイナーがクラス名を変更するだけでテストが壊れてしまうことがありましたが、この方式ならそうした問題を回避できます。また、画像解析よりも軽量で処理速度が早く、視覚的な類似性ではなく要素の意味的な構造に基づいて動作するため、より正確な操作が可能になります。
これにより、AIが自然言語の指示を理解し、人間がコードを書く代わりにE2Eテストの実行や定型的なブラウザ操作などを自律的に行えるようになります。
従来のブラウザ自動化との違い
従来のブラウザ自動化ツールでは、開発者がテストシナリオを詳細にコーディングする必要がありました。しかしPlaywright MCPを使用することで、「このページのフォームに適当な値を入力して送信ボタンを押してください」といった自然言語の指示だけで、AIが自動的にページ構造を理解し、適切な要素を見つけて操作を実行できます。
実際に触ってみよう
セットアップ
今回はGitHub CopilotのエージェントモードからPlaywright MCPを使おうと思います。
セットアップは以下のサイトを参考にしてください。
https://qiita.com/unamu1229/items/718767ad7d4ff1ef386b
注意事項：
settings.jsonに追加すると警告が出る場合があります（私の環境では、macでは出てwindowsでは出ませんでした）。その場合は指示に従って対応してください。セットアップが完了すると、mcp.jsonというファイルが作成されます。
Webサイトのテストをしてもらおう
セットアップが完了したので、実際にテストをしてもらおうと思います。
テストはKDDIアジャイル開発センターのサイト（https://kddi-agile.com/）で行います。
まず、AIエージェントに下記のような指示を出します。
https://kddi-agile.com/
上記のページのテストをしてください。
すると、ブラウザが立ち上がり画像のようにテストが開始されました。
テスト実行時は、まずPlaywrightがブラウザを起動し、AIが指定されたURLにアクセスします。その後、ページの構造を解析して、テスト可能な要素を特定し、リンクのクリックやフォーム入力、ページ遷移などを自動実行します。最終的にエラーや不具合がないかチェックして結果を出力します。
最終的なテスト結果は次のようになりました！
この記事には載せていませんが、自身で作成したサイトに意図的に不具合を残した状態でテストしたところ、その点をしっかり指摘してくれました。
まだ実際の現場で求められるレベルがわかっていないのでなんとも言えませんが、動作を見る限りは必要最低限のテストはできているのではないかと感じました。
少なくとも、これだけのテストコードを手動で書くコストを考えると効率的なのは間違いないと思います。
懸念点と対応案
私がPlaywright MCPを試してみて感じた懸念点は大きく2点です。
1. 実施されているテストの透明性
いくつかのサイトで試してみましたが、テストが実行されているのは良いものの、どのような処理が行われているのかが全くわかりません。これでは、テスト結果の妥当性を判断することが困難です。
2. 再現性の低さ
LLMの特性上、同じ指示を投げたとしても毎回答えが変わってしまう場合があります。そのため、同じテストを再実施したくてもできない可能性があります。継続的インテグレーション（CI）での利用といった今後の活用を考えると、この点は大きな課題となります。
対応策
上記の対応策を調べたところ、プロンプトにテスト実行と同時に実施されているテストをコードとして出力するという指示を追記する方法があるようです。
具体的なプロンプト例：
https://kddi-agile.com/
上記のページのテストをしてください。
テスト実行と同時に、実行したテストケースをPlaywrightのテストコードとして出力してください。
このように指示することで、テストの透明性を向上させ、後から同じテストを再実行することが可能になります。
まとめ
本記事ではPlaywright MCPを使ってWebサイトの自動テストを行ってみました。
今回は簡単な指示しかしていませんが、もっと詳細にプロンプトを書くことで、より目的に合った内容に近づけられると思います。
また、今回はGitHub CopilotからPlaywright MCPを動かしましたが、Claude CodeやGemini CLIなどと組み合わせた方が色々とできることが増えそうだなと直感的に感じました。それぞれのAIエージェントには異なる特徴があるため、用途に応じて使い分けることで、より効果的なテスト自動化が実現できそうです。
ブラックボックスな部分も多いと思いますが、使い方次第で強力な道具になる気がしているので、引き続き勉強して活用できたらいいなと思います。