playwright mcpをAI駆動開発フローに組み込んでE2Eテストをさせよう

導入

こんにちは。グループ研究開発本部 次世代システム研究室のH.Oです。

前回の記事では、私の所属しているプロジェクトである天秤AIに、開発用AIエージェントを導入し、運用を開始した事例について紹介しました。この取り組みをきっかけにしてプロジェクトでは、AI駆動開発への転換が大きく進むことになりました。AIによる自動化は、コーディングとレビューに始まり、今ではジャストアイデアの状態から仕様を生成、タスク分解、githubでのissueの作成まで行えるようになりました。このAI駆動開発のワークフローの技術的な詳細は後日、別の記事で紹介したいと思いますが、今回はその取り組みを進めていく中で、比較的一筋縄では行かなかったE2Eの自動化の試みについてご紹介したいと思います。

結論ファースト

• localのE2Eテストは、Cursor + Playwright MCPの使い心地が良い。
• 社内限定のステージング環境で自動E2Eテストを回すために、EC2上の n8n ワークフローに Playwright MCP Server を追加し、n8n から直接呼び出す仕組みにした。

アジェンダ

1. 前提
2. playwright mcpとは
3.  検証
   1. Cursor + Playwright MCP
   2. Devin + Playwright MCP
   3. n8n + Playwright MCP
4. 結論
5. 最後に

 

1. 前提

私たちのチームでは「AI 駆動開発ワークフロー」という仕組みを構築しています。
これは AWS 上に用意したステージング環境の中で動いており、1台の EC2 インスタンス上に以下のコンポーネントを Docker Compose で立てています。

• n8n: ワークフロー自動化ツール

• 複数の MCP Server: 各種エージェント機能を提供するモジュール群

2. playwright mcpとは

Playwright MCPは、E2E（End-to-End）テストを自動化するための仕組みを、AIエージェントやワークフローオーケストレーターから簡単に呼び出せるようにしたサーバーコンポーネントです。通常のPlaywrightはNode.jsやPythonのコードで、直接ブラウザ操作を記述しますが、MCPサーバーとして動かすことで「外部サービスからのリクエストを受け、テストを実行し、結果を返す」というAPI的な利用が可能になります。

具体的には以下のような特徴があります。

• ブラウザ操作の自動化
  ChromiumやFirefox、WebKitといったブラウザをヘッドレスモードで起動し、ユーザー操作をシミュレートできます。ログイン、画面遷移、フォーム入力、スクリーンショット取得などが可能です。

• MCPプロトコル準拠
  Model Context Protocolに対応しており、n8nやAIエージェントなど、MCPクライアントからSSE（Server-Sent Events）経由でコマンドを受け取れます。これにより「テストを実行して結果を返す」という処理を一つのノードやアクションとして組み込めます。

• ワークフローとの統合
  CI/CDや社内のステージング環境に組み込むことで、デプロイ後に自動でUIテストを走らせたり、異常があればSlack通知するといったフローを簡単に実現できます。

要するに、Playwright MCPは「ブラウザ操作をMCPの標準的なインターフェースで公開したサーバー」であり、AI駆動の開発ワークフローや自動テスト基盤において、柔軟かつプラグイン的に利用できるのが特徴です。

3. 検証

さて、実際にこれらを組み込んでいく方法を考えました。一点目としてどこに組み込むか、二点目として何をテストさせるか、という方針を決めました。結論として、自動的なE2Eテストはローカルとステージングに組み込み、主にリグレッションが発生していないかチェックする目的で実行するもの、と設定しました。

一点目、プロジェクトにはローカル、ステージング、本番環境の３種があります。ここのどこに自動E2Eテストを組み込むべきでしょうか。まず、ローカルでは、自分で実装・修正したコードの動作確認を行う目的で使用することが考えられます。また、ステージングではUATをビジネスサイドに依頼する前にあらかじめ実装した機能が明確に動くのかどうか、またリグレッションが発生していないかどうか等を検査する需要が存在します。一方で本番環境については、以下の二つのリスクを考慮して、自動化したE2Eは組み込まない、という判断をしました。

・自動E2Eテストを実行する際にDBのレコードを作成・更新・削除する可能性があるため、意図しない処理が実行されて、本番のDBに不要な、あるいは致命的な変更を加えるリスクがあること。
・テスト用のアカウントのログイン情報をワークフローに与える必要があるため、流出のリスクがあること。

二点目、テストさせるタスクについてです。アプリケーションの複雑化に伴ってしばしば遭遇した問題として、リグレッションの問題を痛感していました。その中には新規登録やログインなど、ユーザーの流入に直結する絶対に障害が起きてはいけないような機能も含まれています。AIが実装したコードがapproveされ、ステージング環境にマージすることも増えていく中で、このリグレッションの問題を減らす、ことに自動E2Eテストは役に立つのではないか、という仮説を立てました。この目的で運用することで、毎回同じテストを人間が律儀に繰り返す必要はなくなります。promptを適切に管理し、STGに新しい機能がマージされるたびに同じテストを自動的に実行させ、リグレッションが発生していないことを確かめることで、動作確認の質を高めつつ、それによって人間の工数が大幅に取られてしまうことがない、という状況を実現できると考えました。

では技術面の検証を行なっていきます。タスクの例として、「サービスのログインの動作確認」をさせてみます。

事前に、自動E2Eテストをするためだけのアカウントを作成します。

与えるプロンプトは以下とします。

playwright mcpを使用し、[ステージング環境のURL]にアクセスし、以下のログインのフローをテストしてください。
emailを[email]、passwordを[password]でログインしてください。

 

   ・Playwright MCP + Cursor

私は普段Cursorを愛用しているのですが、こちらにPlaywright MCPをまず導入してみて、様子を見ようということで試してみました。結論、setupがとても簡単で、使い勝手は良好でした。

Cursor Settingsのウィンドウ左側にあるMCPの項目を選択します。（画像は既に追加済の状態です）

この画面でNew MCP Serverをクリックし、表示されるmcp.jsonに以下を設定します。

"playwright": {
  "command": "npx",
  "args": [
    "@playwright/mcp@latest"
  ]
}

Cursorのchat欄にプロンプトを入力し送信します。ブラウザが立ち上がりテストを実行してくれました。
画面遷移も軽快で問題なく動作確認ができました。また、エラーになった際も確認事項をリストアップし、修正方針を提案してくれます。スクリーンショットも撮影し、保存してくれます。

エラーが発生した場合の出力例

エラーメッセージ
システムから以下のエラーメッセージが表示されました：
> "パスワードに誤りがあるか、このメールアドレスは登録されていません。再入力してください。正しく入力してもログインできない場合はアカウントロックされている可能性があります。その場合こちらから解除をお願いします。"
考えられる原因
パスワードが間違っている - 提供されたパスワードが正しくない可能性
メールアドレスが登録されていない - このメールアドレスがシステムに登録されていない可能性
アカウントがロックされている - セキュリティ上の理由でアカウントがロックされている可能性
追加確認事項
アカウントの状態確認が必要
正しい認証情報の再確認が必要
アカウントロックの解除が必要な可能性
スクリーンショットは .playwright-mcp/login_failed_screenshot.png に保存されました。

 

　・Playwright MCP + Devin

プロジェクトではDevinのTeamsプランの契約をしていて、開発とレビューのタスクをDevinにアサインすることがよくあります。ここで、Devinに実装だけでなく、実装したものをE2Eまで完了してもらうことはできないか？と考えました。E2Eテストをするにあたって重視したことが、ログだけではなく実際のブラウザ遷移を確認できることです。先ほどのCursorと組み合わせる場合もlocal machineでbrowserを立ち上げることができます。Devinの強みは、独自の仮想環境を持っていて、Devinに内部的にブラウザを立ち上げ、その操作を依頼することができ、挙動や実行ログを確認できることです。

Devinは過去MCPと連携させることはできませんでしたが、8月にMCP Marketplaceという機能をリリースしています。この選択肢の中にPlaywright MCPがあったためこちらを組み込むことにしました。

 

こちらのMCP Marketplaceにアクセスすると、Playwright MCPの選択肢があるため、こちらを選択することで簡単に導入ができます。認証情報も特に設定する必要はありません。

Devinの入力欄から、ログインのテスト用のE2Eを入れてみて、実行できるか試しました。しかし、ステージング環境には、社内のネットワークからのみアクセスできるアクセス制御をかけているため、Devinに普通にステージング環境のURLを見にいくように伝えても、アクセス制御に引っかかってしまいます。

こういう場合は、Devinと社内環境との間にVPN接続を設定するという方法と、Enterprise版のみで提供されているself host可能なDevinを用い、アプリケーションと同じインフラの中にSelf Hostするのが選択肢としてあります。Devin自体はTeamsプランのため、publicなものです。VPNを接続したとしても、あくまでTeamsプランのDevinはPublicのため、入力する情報には気を使う必要がありますと考えました。また、Enterprise版は高額であり、導入が現実的ではないという判断になりました。

一方で、Devinによる実装とE2Eテストを一気通貫で行うには、どのようにすれば良いか、Devinのローカル環境の中でアプリケーションを立ち上げ、実装をした後に、動作確認もするよう指示を出し、ローカルで行うような動作確認をしてもらえれば良いのではないか、と考えました。しかし、DevinのMarketplace上で提供されているPlaywright MCPは独自のdocker containerの中に建てられており、ここから、projectのcontainerにアクセスできない、という問題が発生し、疎通ができませんでした。

課題

・プロンプトに含まれるデータを安全に利用できるかというところでセキュリティの懸念を払拭することができませんでした。セルフホストが可能なEnterprise版のDevinは非常に高額であり、導入が難しいです。

・処理時間が非常に長く、playwright mcpではツールで代用してブラウザテストをするように試みようとするなど、挙動が安定せず、結果としてACUを大量に消費してしまう事象も発生しました。

　・Playwright MCP + n8n

上記のDevinでの検討を踏まえた上で、結論としてPlaywright MCP serverを、既存のn8n製のworkflowをデプロイしているステージング環境にセルフホストし、ワークフローから自前でホストしているPlaywright MCP serverを叩く、という方法を選択しました。こうすることで、Playwright MCPによるやりとりはアクセスが保護されているEC2の中で完結し、安全に利用することができます。

作成したワークフローのうち、Playwright MCPに関するところを切り出したのがこのワークフローです。

n8nで作成したワークフローの詳細については詳細には触れませんが、Slackのチャンネルで入力した内容とコマンドがワークフローの中で処理され、各自のタスクが処理されるという流れになっています。その一部としてE2Eを依頼するケースを追加しています。この場合、When Executed by Another Workflowを入力としてAI Agentにプロンプトが送信されます。ここにOpenAIのmodelとMCP Clientのnodeを繋ぎます。MCP clientをclickするとEndpoint等を設定できる箇所があります。ここに、セルフホストしたPlaywright MCP serverのエンドポイントを入力することで接続できます。

 

AI Agentには、n8n上で起動できるformのnodeを繋げ、検証用の入り口を作りました。ここからプロンプトを入力しました。ログインに成功し、次の手続きに進むようにアウトプットが出力されています。処理時間も数秒程度で非常に早いものでした。

これを既存のワークフローに紐づけることで、SlackのチャンネルからE2Eテストの依頼を文章としてとばし、テストの成否をSlackに返すことができるようにしようと考えています。

課題

・この方法ではブラウザを立ち上げての挙動推移を見守ることができません。同様のアウトプットを期待する場合は、内部的にscreenshotやvideoをonにして実行させる対応が必要になります。

最後に注意点ですが、E2EをAIで自動化する場合、必ずテスト専用のアカウントを作成するようにし、他のアカウントでテストを実行しないようにしてください。

結論

• ローカルでのE2EテストはCursor + Playwright MCPが導入も楽で、非常に軽快に動きます。
• 社内の環境からのみアクセスできるステージング環境でのE2Eテストは、すでにn8n製ワークフローをセルフホストしているステージング環境のEC2に、Playwright MCP serverをセルフホストし、ワークフローから、Playwright MCP serverを叩かせることで安全に利用できます。

採用に力を入れています。鋭意募集中

GMOインターネットグループ グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。