Playwright v1.56で追加されたPlaywright Test Agentsが気になって実際に試してみました！
この機能の個人的に気になっているところは、AIがテスト計画を考えるところからコード生成、さらにはUI変更によって動かなくなったテストを自動で直すところまでやってくれるらしいです。
というわけで、実際に使ってみたので記事にまとめました。
この記事では、3つのAIエージェント（Planner、Generator、Healer）の機能と使い方を紹介していきます。
各エージェントについて
それぞれどんなエージェントがあるのか簡単に紹介します。Playwright Test Agentsは、それぞれ違う役割を持つ3つのエージェントで構成されています。
Planner（プランナー）
アプリケーションを探索しながらテスト計画を立案するエージェントです。
- 役割：アプリケーションを分析してテスト計画書を作成
- 必要なもの：テストしたい内容の説明と、基本的なシードテスト
- 出力：
specs/ディレクトリにMarkdown形式のテスト計画
Generator（ジェネレーター）
Plannerが作成したテスト計画を、実行可能なPlaywrightテストコードに変換するエージェントです。
- 役割：テスト計画からPlaywrightのテストコードを生成
- 特徴：実際にサイトを操作しながら、セレクターやアサーションの妥当性を確認して作成してくれます
- 出力：
tests/ディレクトリに実行可能なテストファイルが作成されます
Healer（ヒーラー）
失敗したテストを分析して自動的に直してくれるエージェントです。
- 役割：失敗したテストを自動で修正
- 特徴：
- エラーが出たステップを詳しく調査
- UI変更を見つけて適切な要素やフローを見つけてくれる
- 修正方法を提案する、または機能に問題がないか確認する
実際にセットアップしてみる
事前準備
私が試した環境はこんな感じです：
- claude code
- Node.js
- Playwright
今回はデモとして、「Takeshi Kishi」さんが提供するテスト用デモサイトを利用させて頂きます。
git clone https://github.com/takeyaqa/hotel-example-site
cd hotel-example-siteセットアップ手順
使っているエディタに合わせてコマンドを実行します。
私の場合は、claude codeで試してみました。
npx playwright init-agents --loop=claude「y」で進みます。
Need to install the following packages:
playwright@1.56.0
Ok to proceed? (y) 以下の構成でファイルが作成されます。※追加分のみ抜粋
repo
├── .claude/agents
│ ├── playwright-test-generator.md
│ ├── playwright-test-healer.md
│ └── playwright-test-planner.md
├── .mcp.json
└── seed.spec.ts次にclaude codeを起動します。
claudeMPCサーバーの使用について聞かれます。
1はこのプロジェクトに追加されるMCPサーバーも自動的に使用するか。2は今回のMCPサーバーのみ使用するか、3は使用しないといった感じでしょうか。
今回はデモなので「1」で進みます。
➜ playwright-claude-demo git:(master) ✗ claude
╭──────────────────────────────────────────────────────────────────────────────╮
│ │
│ New MCP server found in .mcp.json: playwright-test │
│ │
│ MCP servers may execute code or access system resources. All tool calls │
│ require approval. Learn more in the MCP documentation │
│ (https://docs.claude.com/s/claude-code-mcp). │
│ │
│ ❯ 1. Use this and all future MCP servers in this project │
│ 2. Use this MCP server │
│ 3. Continue without using this MCP server │
│ │
╰──────────────────────────────────────────────────────────────────────────────╯
Enter to confirm · Esc to reject実際に動かしてみる
ステップ1: Plannerにテスト計画を作成してもらう
まず、アプリケーションの基本的な動作を示すシードテストを準備します。
これによってPlannerがアプリの構造を理解しやすくなります。
特定の機能に絞ってテスト計画の作成を指示してみます。
@planner
宿泊予約のテスト計画を作成してください。 Plannerを動かすとディレクトリ構成を解析してテスト計画を作ってくれます。
ドキドキしながら待つこと数分……。
テスト計画（hotel-reservation-test-plan.md）が作成されました！
実際に作成されたテスト計画の内容： ※全文は多いので抜粋
## 1. アプリケーション概要
### 1.1 対象システム
### 1.2 主な機能
### 1.3 利用可能な宿泊プラン
## 2. テストシナリオ
### シナリオ 1: 正常系 - 基本的な予約フロー（連絡希望しない）
### シナリオ 8: バリデーション - 氏名未入力エラー
### シナリオ 26: 境界値テスト - 日付ピッカーの最小値（翌日）
### シナリオ 28: UI/UX - 連絡方法変更時の動的項目表示（希望しない→メール）
### シナリオ 37: 多言語対応 - 英語版ページの基本動作
### シナリオ 40: 複雑な料金計算 - 土日を含む3泊4日の予約
### シナリオ 41: 異常系 - 無効なプランIDでのアクセス
### シナリオ 44: プラン別制約 - カップル限定プラン（人数固定）
### シナリオ 47: セッションストレージ - 予約データの保存
### シナリオ 48: Cookie - トランザクションIDの保存
### シナリオ 49: アクセシビリティ - フォームラベルとフィールドの関連付け
## 3. テスト実行環境
### 3.1 推奨ブラウザ
### 3.2 サーバー起動方法
### 3.3 テストデータ
## 4. テスト優先度の定義
## 5. テスト実行時の注意事項
## 6. 既知の制約事項
## 7. テスト完了基準
## 8. 不具合報告時の記載事項
## 9. テスト計画の更新履歴
## 10. 参考情報
### 10.1 ファイル構成
### 10.2 関連ドキュメント驚いたのがシナリオのパターン。正常系、異常系だけでなくバリデーションや境界値などの観点が盛り込まれていることに驚きです。
他にもテスト環境や不具合の起票方法などもまとまっています。
ステップ2: Generatorでテストコードを生成してもらう
次に、Generatorを使ってみます。このエージェントが、さきほど作成されたのテスト計画をPlaywrightのテストコードに書き起こしてくれます。
@generator
hotel-reservation-test-plan.mdからPlaywrightテストを生成してください。テストコード作成完了までワクワクしながら待ちます。
claude codeは今何を実行しているか経過が流れるログのように見れるのがいいですね。
ここで感動したのが、Generatorがテストコード作成までやってくれるのかと思いきや、
「テストコードの実行→実行結果の確認→テストコードの修正」を繰り返しながらテストコードを書いてくれるところにそこまでやってくれるのかと驚きました。
実際に生成されたテストコード:
repo
├── tests
│ ├── reserve-validation.spec.ts
│ ├── reserve-basic.spec.ts
│ └── pages
│ └── ReservePage.ts
└── playwright.config.tsファイルを確認してみます。
repo
├── tests
│ ├── reserve-validation.spec.ts
│ ├── reserve-basic.spec.ts
│ └── pages
│ └── ReservePage.ts
└── playwright.config.tsビルドしてテストを実行してみます。
# プロジェクトのビルド（初回のみ）
npm run build
# 全テスト実行
npx playwright test実行レポートを見たらどうやらfirefoxとwebkitのみ失敗しているようです。
ステップ3: Healerに壊れたテストを直してもらった
最後にHealerを試してみました。
@healer
"firefox"と"webkit"のブラウザのテストが失敗しました。修正してください。先程同様テストを実行しながら修復してくれていました。
しばらく待機してテストコードの修正が完了したようです。ドキドキしながら再度テストを実行してみたら無事全てのテストが通りました！
使ってみて感じたメリット
1. 開発が速くなった
テストコードを書く時間がかなり減りました。その分、「何をテストすべきか」という本質的な部分に時間を使えるようになった気がします。
2. メンテナンスが本当に楽
UI変更でテストが壊れても、Healerが自動的に直してくれるので助かりました。「テストコード修正と戦っていたら日が暮れていた…」なんてことがだいぶ減りそうです。
3. テストの漏れに気づける
Plannerが幅広くテスト計画を作ってくれるので、「あ、このケーステストしてなかった！」という発見がありました。自分ではつい面倒と思って割愛してしまう境界値やすべてのバリデーションのパターンも提案してくれました。
4. チームで共有しやすい
テスト計画がMarkdown形式で書かれるのが良いですね。エンジニア以外のメンバーにも「こういうテストしてます」って見せやすいです。
会社ではConfluenceを使っているのでドキュメントにも書き起こしやすいです。
5. 使い方を選べる
プロジェクトに合わせて、エージェントの使い方を変えられます。全部使うこともできるし、特定のテストだけとか必要なものだけ使うこともできる柔軟さが良かったです。
こんな時に使えそう
実際に試してみて、こういう場面で使えるなと思ったケースを紹介します。
ケース1: 新機能のテストを作る時
新機能をリリースする時、こんな感じで試してみました：
- 新機能について「こういう動きします」と説明を書く
- Plannerに投げてテスト計画を作ってもらう
- Generatorで実際に動くテストコードを取得
従来だと数時間かかっていたテスト作成が、かなり短縮されました。これは助かります。
ケース2: リファクタリング後のテスト直し
UIをリファクタリングした後はなんかは特にテストが失敗しやすいと思いますが、このコマンド一発で、Healerが失敗したテストを見つけて、自動で直してくれるかもと思いました。
npx playwright test --headed直せないものについては、「これ、もしかして機能壊れてる？」と報告してくれるらしいので、バグっぽいものも早期に拾えそうです。
ケース3: 古いアプリにテストを追加する時
テストがほとんどない古いアプリケーションでも試したりもできそう。
- Plannerに「この辺テストしてほしい」とお願いしてテスト計画を作成
- Generatorでまとめてテストコードを作成
- 少しずつテストを動かして改善
上記のサイクルを繰り返すことで、手動でレガシーコードに立ち向かうよりは、かなり効率的にテストできるようになるんじゃないかなと思います。
使ってみて分かったコツ
実際に試してみて、こうした方が良さそうだなと思ったポイントを共有します。
1. シードテストはちゃんと作る
Plannerが正確にアプリを理解できるように、基本的な動きを示すシードテストはしっかり作っておいた方が良いです。ここを雑にすると、生成されるテスト計画も微妙になります。
AIエージェント任せではなく、きちんと自分の目でチェックして本来の目的に沿った内容になっているか確認して、必要に応じてアップデートしましょう。
2. テスト計画は一旦レビューする
Generatorでコードを作る前に、Plannerが作ったテスト計画をチームで見てみることをお勧めします。Markdownなので読みやすいですし、「ここはテストしなくていいかな」とか調整できます。
3. 小さく始めてみる
既存のテストに対していきなり全部使うのではなく、まず一部の機能で試してみるのが良いと思います。私もそうしました。手応えを感じてから、少しずつ範囲を広げていくのが安全ですし、結果的にコストも削減できます。
4. 定期的にアップデートする
Playwrightが更新されている可能性があるので、定期的にnpx playwright init-agentsを実行して、最新の機能を取り込んでおきましょう。
5. 最後は人間が判断する
エージェントは便利ですが、「何をテストすべきか」「どこまでテストするか」の最終判断は人間がすべきだと思います。AIは相棒として使うのが良いバランスな気がします。
あ、サイレントヒルfのネタじゃないです。笑
使ってみて気づいた注意点
実際に試してみて、「ここは気をつけた方がいいな」と思った点もまとめます：
- まだ新しい機能: 比較的新しい機能なので、たまに思った通りに動かないこともありました。本番で使う前に、ちゃんと検証した方が良さそうです
- リソースは結構使う: エージェントを動かすと、普通のテストよりもCPUとメモリを使います。マシンスペックと特にコストは気にした方が良いかもしれません
- セキュリティには注意: 本番環境の認証情報とかは、エージェントに渡さないように気をつけてください。これめっちゃ大事です！！！
まとめ
Playwright Test Agentsは、テスト自動化の新しい可能性を見せてくれています。Planner、Generator、Healerの3つのエージェントが協力することで、テストを作るところから保守するところまで、全体的に楽になります。
正直、最初は「AIにテスト書かせて本当にちゃんと作ってくれるの？」と思っていたのですが、実際に使ってみるとその精度の高さと便利さに驚きました。AIがテストの相棒になってくれることで、開発者は「何をテストすべきか」「どこまでテストするか」といった本質的なことにより集中できるようになります。繰り返しの作業はエージェントに任せて、もっと価値のある開発に時間を使えるようになります。
個人的にはまずは小さめのプロジェクトから試してみることをお勧めします。テスト自動化の新しい世界を、ぜひ体験してみてください！！