株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
この記事でわかること
- Playwright Test Agentsの3つのAIエージェント（Planner・Generator・Healer）の活用方法
- Playwright MCPを使ったAIコーディングエージェントとのE2Eテスト連携
- Docker検証環境の構築とテストデータ管理のベストプラクティス
はじめに：AIが変えるE2Eテストの常識
E2Eテストは、UIの操作からバックエンドのAPI呼び出し、データベースの状態変化まで、システム全体の動作を検証する最も網羅的なテスト手法です。しかし従来は「テストコードの作成コストが高い」「UIの変更のたびにテストが壊れる」「メンテナンスに時間がかかる」という3つの課題がありました。
2026年、AIエージェントの登場によりこれらの課題が根本的に解消されつつあります。Playwright v1.56で導入されたTest Agentsは、テスト計画の作成からコード生成、壊れたテストの自動修復までをAIが担います。
Playwright Test Agents：3つのAIエージェントによるテスト自動化
Planner（プランナー）：テスト計画の自動生成
PlannerエージェントはWebアプリケーションを自律的に探索し、テストすべき機能・シナリオを洗い出して、Markdown形式のテスト計画書を自動生成します。
使い方：
npx playwright test --agents plan --url https://your-app.comPlannerが生成するテスト計画書には、各テストケースの目的、前提条件、操作手順、期待結果が構造化されて記載されます。人間はこの計画書をレビューし、不要なケースの削除や追加すべきケースの指示を行います。
Generator（ジェネレーター）：テストコードの自動生成
Generatorエージェントは、Plannerが作成したテスト計画書に基づいて、実行可能なPlaywrightテストコードを生成します。
npx playwright test --agents generate生成されるコードはPlaywrightのベストプラクティスに従い、ロケーター戦略（getByRole、getByText等）やPage Object Modelパターンが適用されます。
Healer（ヒーラー）：壊れたテストの自動修復
UIの変更によりテストが失敗した場合、HealerエージェントがDOM構造の変化を分析し、テストコードを自動修復します。
npx playwright test --agents healこれにより「UIを変更したらテストが壊れる→手動修正→またUIを変更→また壊れる」というメンテナンスの悪循環を断ち切れます。
Playwright MCP：AIコーディングエージェントとの連携
MCPとは何か
MCP（Model Context Protocol）は、AIエージェントが外部ツールと連携するための標準プロトコルです。Playwright MCPサーバーを起動することで、Claude CodeやCursorなどのAIコーディングエージェントから直接ブラウザ操作やテスト実行を呼び出せます。
AIコーディングエージェント + Playwright MCPの活用パターン
パターン1：実装後の即時動作確認
AIエージェントがコードを実装した後、Playwright MCPを使ってブラウザ上で動作確認を行い、問題があれば即座に修正するループを構築できます。1セッション内で「実装→ブラウザ確認→修正→再確認」を完結させることが可能です。
パターン2：テスト仕様書からのE2Eテストコード自動生成
テスト仕様書（Markdown）をAIエージェントに渡し、Playwright MCPでアプリケーションを実際に操作させながらテストコードを生成させるパターンです。AIがアプリケーションの実際の挙動を観察しながらテストを書くため、生成されるコードの精度が高くなります。
パターン3：打鍵テストの自動化
AIエージェントにDocker環境でアプリケーションを無限に操作させ、発見した不具合を報告し、テストシナリオをCSVで出力させるパターンです。探索的テストをAIに任せることで、人間が思いつかないエッジケースを発見できます。
Docker検証環境の構築
なぜDockerが必要か
AIエージェントにテストを実行させる場合、本番環境やステージング環境を使うとリスクがあります。Docker上に隔離された検証環境を構築し、AIエージェントが安全にテストを実行できる環境を用意します。
Docker Compose構成の設計
| サービス | 役割 | ポート |
|---|---|---|
| app（フロントエンド） | テスト対象のWebアプリケーション | 3000 |
| api（バックエンド） | APIサーバー | 8000 |
| db（データベース） | テスト用データベース | 3306/5432 |
| playwright（テストランナー） | Playwrightテスト実行環境 | - |
テストデータ管理の注意点
E2Eテストの信頼性を左右するのがテストデータの管理です。以下の点に注意します。
- 標準入力（stdin）の供給：テスト対象が標準入力を期待する場合、テストデータディレクトリからtest.datを自動検出して供給する仕組みを用意する
- バイナリファイルの取り扱い：テストデータにバイナリファイルが含まれる場合、UTF-8テキストとして読み書きするとエンコーディングが破損する。Buffer（バイナリ）で読み書きするよう設計する
- テスト間のデータ隔離：各テストケースの実行前にデータベースをリセットし、テスト間の依存を排除する
テスト判定ロジックの設計
ライブラリプロジェクトの判定
テスト対象がライブラリ（.aファイルや.soファイル）を生成するプロジェクトの場合、実行ファイルが存在しなくてもビルド成功として判定する分岐が必要です。実行ファイルの有無だけで成否を判定すると、ライブラリプロジェクトは常に失敗扱いになります。
ベースライン欠落時の判定
比較対象のベースライン出力が取得できなかった場合、「baseline_unavailable」を独立したステータスとして扱います。「基準がなければ一致とみなす」という判定は危険であり、ベースライン取得の失敗原因を可視化する設計にします。
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）の3段階自動化と、Playwright MCP経由のAIコーディングエージェント連携を組み合わせれば、E2Eテストのカバレッジを維持しながら開発速度を落とさない開発フローを構築できます。
AIテスト自動化の導入はRenueにご相談ください
Renueでは、複数のプロジェクトでPlaywright MCPを活用したE2Eテスト自動化を実運用しています。Docker検証環境の構築、AIエージェントによる探索的テスト、Visual Regression Testingの導入まで、テスト戦略の設計から実装までを一貫して支援します。