株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
この記事でわかること
- Playwright Test Agentsの3つのAIエージェント（Planner・Generator・Healer）の活用方法
- Playwright MCPを使ったAIコーディングエージェントとのE2Eテスト連携
- Docker検証環境の構築とテストデータ管理のベストプラクティス
はじめに：AIが変えるE2Eテストの常識
E2Eテストは、UIの操作からバックエンドのAPI呼び出し、データベースの状態変化まで、ユーザーの操作に沿って、複数の機能をまたぐ一連の動作を検証するテスト手法です。しかし従来は「テストコードの作成コストが高い」「UIの変更のたびにテストが壊れる」「メンテナンスに時間がかかる」という3つの課題がありました。
AIエージェントは、これらの作業の一部を支援できます。Playwright v1.56で導入されたTest Agentsは、テスト計画の作成、コード生成、失敗したテストの修復を支援する3つのエージェントです。生成物と修復結果は、対象の仕様に照らして確認する必要があります。（出典：Playwright：v1.56リリースノート、Playwright：Test Agents）
Playwright Test Agents：3つのAIエージェントによるテスト自動化
Planner（プランナー）：テスト計画の自動生成
PlannerエージェントはWebアプリケーションを自律的に探索し、テストすべき機能・シナリオを洗い出して、Markdown形式のテスト計画書を自動生成します。
使い方：まずプロジェクト内で次のコマンドを実行し、利用するAIツール向けのエージェント定義を生成します。このコマンドだけでPlannerが探索を始めるわけではありません。
npx playwright init-agents --loop=claude定義を生成した後、対応するAIツールからPlannerを呼び出し、対象機能の依頼と、初期状態やフィクスチャを設定するseed testを指定します。Plannerが生成するテスト計画書には、各テストケースの目的、前提条件、操作手順、期待結果が構造化されて記載されます。人間はこの計画書をレビューし、不要なケースの削除や追加すべきケースの指示を行います。
Generator（ジェネレーター）：テストコードの自動生成
Generatorエージェントは、Plannerが作成したテスト計画書に基づいて、実行可能なPlaywrightテストコードを生成します。
（導入したGeneratorエージェントをエディタ上で呼び出します）Generatorは対象アプリケーションでロケーターやアサーションを確かめながらコードを生成します。getByRole、getByText等のロケーターは対象要素に合わせて選び、生成結果を確認します。Page Object Modelはテストを整理する設計方法の一つで、自動的に必ず適用されるものではありません。必要に応じて生成後のコードをその構造に整理します。（出典：Playwright：Generator、Playwright：Locators、Playwright：Page object models）
Healer（ヒーラー）：壊れたテストの自動修復
テストが失敗した場合、Healerエージェントが失敗した操作を再実行し、現在のUIを調べて修正を試みます。再実行はテストの成功または停止条件に達するまで行われ、修復の成功が保証されるわけではありません。
（導入したHealerエージェントをエディタ上で呼び出します）これにより「UIを変更したらテストが壊れる→手動修正→またUIを変更→また壊れる」という作業の一部を支援できます。ただし、アプリケーションの機能自体が壊れていると判断した場合は、テストをスキップする結果になることもあります。スキップを成功と扱わず、修正差分・期待結果・未解決の不具合を人が確認します。（出典：Playwright：Healer）
Playwright MCP：AIコーディングエージェントとの連携
MCPとは何か
MCP（Model Context Protocol）は、AIエージェントが外部ツールと連携するための標準プロトコルです。Playwright MCPサーバーを起動し、Claude CodeやCursorなどの対応するAIコーディングエージェントに設定することで、ブラウザ操作を呼び出せます。テストコードの実行と組み合わせる場合は、利用するエージェントの実行環境も設定します。（出典：Microsoft：Playwright MCP）
AIコーディングエージェント + Playwright MCPの活用パターン
パターン1：実装後の即時動作確認
AIエージェントがコードを実装した後、Playwright MCPを使ってブラウザ上で動作確認を行い、問題があれば即座に修正するループを構築できます。1セッション内で「実装→ブラウザ確認→修正→再確認」を完結させることが可能です。
パターン2：テスト仕様書からのE2Eテストコード自動生成
テスト仕様書（Markdown）をAIエージェントに渡し、Playwright MCPでアプリケーションを実際に操作させながらテストコードを生成させるパターンです。AIがアプリケーションの実際の挙動を観察しながらテストを書くため、画面上の要素と生成コードを照合できます。ただし、誤った挙動を正解として固定しないよう、期待結果は仕様と照らして確認します。
パターン3：打鍵テストの自動化
AIエージェントに、実行時間・操作回数・再試行回数の上限と停止条件を設けてDocker検証環境のアプリケーションを操作させ、発見した不具合を報告し、テストシナリオをCSVで出力させるパターンです。探索的テストの補助として、想定した操作以外のエッジケースも探します。
Docker検証環境の構築
なぜDockerが必要か
AIエージェントにテストを実行させる場合、本番環境やステージング環境を使うとリスクがあります。Docker上に検証環境を構築する際は、ブラウザだけでなく、接続先のアプリケーション・API・データベース・認証情報をテスト専用に分け、本番へのネットワーク接続を制限します。メール送信や決済などの外部処理もテスト用の接続先やモックに切り替えます。Docker内のブラウザから本番に接続できる設定では、本番への影響を防げません。（出典：Playwright：Docker環境、Microsoft：Playwright MCPのSecurity）
Docker Compose構成の設計
| サービス | 役割 | ポート |
|---|---|---|
| app（フロントエンド） | テスト対象のWebアプリケーション | 3000 |
| api（バックエンド） | APIサーバー | 8000 |
| db（データベース） | テスト用データベース | 3306/5432 |
| playwright（テストランナー） | Playwrightテスト実行環境 | - |
テストデータ管理の注意点
E2Eテストの信頼性を左右するのがテストデータの管理です。以下の点に注意します。
- 標準入力（stdin）の供給：テスト対象が標準入力を期待する場合、所定のテストデータを自動検出して供給する仕組みを用意する
- バイナリファイルの取り扱い：テストデータにバイナリファイルが含まれる場合、UTF-8テキストとして読み書きするとエンコーディングが破損する。Buffer（バイナリ）で読み書きするよう設計する
- テスト間のデータ隔離：各テストケースの実行前にデータベースをリセットし、テスト間の依存を排除する
テスト判定ロジックの設計
ライブラリプロジェクトの判定
ビルド成果物の形式はプロジェクトごとに異なるため、成否判定の条件は対象に合わせて設計する必要があります。実行ファイルの有無だけで成否を判定すると、ライブラリプロジェクトは常に失敗扱いになります。
ベースライン欠落時の判定
比較対象のベースライン出力が取得できなかった場合、「ベースライン取得不可」を独立したステータスとして扱います。「基準がなければ一致とみなす」という判定は危険であり、ベースライン取得の失敗原因を可視化する設計にします。
CI/CDパイプラインへの組み込み
推奨フロー
- PRが作成される
- GitHub ActionsがDocker Compose環境を起動
- Playwright Test Agentsがテスト計画を生成（Planner）
- 既存のテストスイートを実行
- 失敗したテストがあればHealerが自動修復を試行
- 新機能に対するテストケースをGeneratorが追加提案
- テスト結果をPRコメントに自動投稿
Visual Regression Testing
UIの見た目の変化を検出するVisual Regression Testingも、Playwright MCPと組み合わせることで自動化できます。メインブランチとフィーチャーブランチのスクリーンショットを比較し、意図しないUI変更をPRレビュー時に検出します。
よくある落とし穴と対策
1. 生成されたテストコードを無検証で使う
AIが生成したテストコードは「たたき台」です。特にセレクターの安定性やテストデータの妥当性は人間が確認する必要があります。
2. テスト環境と本番環境の差異を見落とす
Docker環境と本番環境の差異（DNS設定、ファイルパス、環境変数）がテスト結果に影響することがあります。テスト環境を本番に近づける努力と、環境差異を明示的に管理する仕組みの両方が必要です。
3. E2Eテストの実行時間が長すぎる
テストスイートが大きくなると実行時間が長くなり、CIがボトルネックになります。テストの並列実行、変更に影響するテストだけを実行するselective testing、テスト結果のキャッシュを活用して実行時間を管理しましょう。
まとめ：AIエージェントでE2Eテストの「コスト対効果」を改善する
従来のE2Eテストは「作るのは大変だが、あれば安心」という位置づけでした。AIエージェントは、テスト計画・コード生成・失敗したテストの修復を支援します。E2Eテストの「作るコスト」をどの程度減らせるかは、生成物の確認・修正や実行環境の維持にかかる工数も含めて評価します。
Playwright Test Agents（Planner→Generator→Healer）と、Playwright MCP経由のAIコーディングエージェント連携を組み合わせ、E2Eテストのカバレッジと開発速度の両立を目指します。テストの追加・修復だけでなく、重要な業務シナリオが検証されているかも継続して確認します。
AIテスト自動化の導入はrenueにご相談ください
renueは、Playwright MCPを活用したE2Eテスト自動化について、Docker検証環境と人によるレビューを組み合わせる設計を提案しています。Docker検証環境の構築、AIエージェントによる探索的テスト、Visual Regression Testingの導入まで、テスト戦略の設計から実装までを一貫して支援します。
