Playwright Test AgentsとKiro IDEによる実業務システムのE2Eテスト自動化

結論

• Playwright Test AgentsとKiro IDE、Amazon Q Developer Proを組み合わせることで、メール受信以外のスタッフツールの機能テストを自動化出来た
• Amazon Q Developer ProとKiro IDEの組み合わせにより、月額$19のサブスクリプションでAI駆動によるテスト自動化を低コストで構築出来た

はじめに

こんにちは。次世代システム研究室のT.Tです。

現在開発運用に携わっているWebサービスをPHP 8.5にバージョンアップする予定です。これまでは、バージョンアップ時のリグレッションテストを手動で実施していましたが、今回のバージョンアップに合わせてリグレッションテストの自動化を試してみました。その手始めとして、社内向けのスタッフツールのE2Eテストの自動化に取り組みました。

テスト自動化のツールとして、Playwright Test AgentsとAWSが提供するKiro IDEを組み合わせてテスト自動化に取り組みました。Kiro IDEのAI基盤としては、Amazon Q Developer ProとClaude Opus 4.6を利用しました。本記事では、これらのツールを利用したテスト自動化についてご紹介します。

1.E2Eテスト自動化に取り組んだ背景

スタッフツールの概要

スタッフツールは、Webサービスの運用担当者が利用する社内向けWebアプリケーションです。会員検索や会員情報の更新、利用状況のレポートをCSVファイルでダウンロードする機能等があり、ユーザーに提供しているWebサービスよりもテストパターンが多いのが特徴です。構成要素としては、フォームによる入力やプルダウンメニューによる選択、リスト表示、ページング、CSVアップロード、CSVダウンロード等があります。

手動テストの課題

手動でのリグレッションテストには以下のような課題がありました。

• 機能数が多いためテスト工数が多い
• スタッフツールの機能を正確に把握している開発者が少なく、開発者が入れ替わるタイミングでのテスト漏れのリスクがある

これらの課題を解決するために、Playwright Test AgentsとKiro IDE、Amazon Q Developer Proを活用したE2Eテスト自動化の仕組みを構築しました。

2.Playwright Test AgentsとKiro IDEによるテスト自動化

Playwright Test Agentsは、Playwright 1.56で導入されたAI駆動のE2Eテスト自動化ツールです。Planner・Generator・Healerの3エージェントが協調してテスト計画の立案からコード生成・自己修復までを自律的に担います。アーキテクチャの詳細やClaude Codeを使ったセットアップ手順については、こちらの記事で詳しく解説しています。本記事ではKiro IDEを使った実業務システムへの適用方法に焦点を当てます。

システム構成とプロジェクト設計

テストプロジェクトは specs/（Markdown形式のテスト計画）と tests/（TypeScriptのテストコード）の2層構造で管理しています。Kiro IDEの設定は .kiro/ ディレクトリにまとめ、Steering（エージェント指示書）とHooks（自動化トリガー）を定義しています。

tests/
├── playwright.config.ts          # BASE_URL切り替え
├── tests/
│   ├── auth.setup.ts             # 認証管理
│   ├── fixtures.ts               # MCP実行時の自動ログインフォールバック
│   ├── seed.spec.ts              # エージェント起点となるシードテスト
│   ├── member/                   # 会員機能用テストデータ
│   .. 
│   ├── ...                       # テストデータ
│   └── ...                       # テストデータ
└── specs/                        # テスト計画（Markdown）

.kiro/
├── settings/mcp.json             # Playwright MCPサーバー設定
├── steering/                     # #pw-planner / #pw-generator / #pw-healer
└── hooks/                        # 自動連鎖フック

Playwrightの設定では、BASE_URL 環境変数で実行環境を切り替えられるようにしており、テスト環境での実行は以下のコマンドで行います。

# テスト環境での実行
cd tests
BASE_URL=https://test-staff.example.com npx playwright test --headed

# テストレポートの表示
npx playwright show-report

Kiro IDEでのテスト開発ワークフロー

Kiro IDEでは、.kiro/settings/mcp.json にPlaywright MCPサーバーを登録することで、Kiro ChatからAIがブラウザを直接操作出来るようになります。テスト開発の実際の流れは以下の5ステップで、人間が関与するのはステップ2（テスト計画のレビュー）のみです。

Kiro IDEでは #pw-planner と入力するだけでSteeringが呼び出され、同等の処理をKiro Chatの中で完結出来ます。

Steeringによる操作の簡略化

Kiro IDEでは、.kiro/steering/ ディレクトリにエージェント指示書（Steering）をMarkdownファイルとして配置しておくことで、Kiro Chatで # から始まるSteering名を入力するだけで対応するエージェントを呼び出せます。毎回長いプロンプトを書く必要がなく、チームメンバー間でエージェントの挙動を統一出来ます。スタッフツール向けに定義した3つのSteeringは以下の通りです。

Hooks（自動連鎖）によるシームレスなワークフロー

KiroのHooks機能を使うと、各ステップの完了をトリガーに次のアクションを自動で提示出来ます。例えば pw-chain-planner フックはPlannerがテスト計画を保存した直後に、Generator向けのプロンプトを自動出力します。コピー&ペーストするだけで次のステップへ進めるため、作業の流れが途切れません。また pw-validate-plan フックは、specs/ に新しいMarkdownファイルが作成された時点でテスト計画のフォーマットを自動チェックし、Generatorが正しく処理出来る形式になっているかを即座に検証します。

テスト自動化の結果と精度検証

Playwright Test Agentsにより生成したテストケースは226件で、全件がテストをPASSしました。正常に機能している状態でテストケースを生成したため問題ない挙動ですが、テスト失敗時にエラーを検出出来るかを確認するため、member-search.spec.ts のテストコードのユーザーIDやURLの期待値を意図的に改ざんして、エラーを検出出来るかを検証しました。

4件全てで意図した通りにFAILが発生し、エラーメッセージには「Expected vs Received」が明確に表示されました。Playwright Test Agentsが生成したテストコードで、アプリケーションで発生する実際のエラーを正確に検出出来そうです。

# 検証時の実行結果（抜粋）
Error: expect(received).toContain(expected) // indexOf
  Expected substring: "member_id=12345678"
  Received string:    "https://test-staff.example/member/member-search?member_id=1234567&..."

Error: expect(locator).toHaveValue(expected) failed
  Locator:  locator('input[name="member_id"]')
  Expected: "11111111"
  Received: "11111112"

Playwright Test Agentsで自動化が出来ない箇所

Playwright Test Agentsによって機能テストをほぼ全て自動化出来ましたが、単体ではスタッフツールから送信したメールを受信する部分のテストが自動化出来ていません。GmailのようなメールサービスのAPIと連携すればメールの受信テストも実現出来るようなので、引き続きメールの受信テストの自動化にも取り組む予定です。

テスト失敗時の検出と修正

Playwright Test Agentsの導入後はテスト失敗時の原因特定も効率化されています。Playwright は失敗したアサーションごとに「Expected」と「Received」を明示するため、Healerエージェントが修正すべき箇所を即座に特定出来ます。意図的にエラーが出るように改ざんしたテストでは、全件で正確なエラーレポートが出力され、エラー内容から修正箇所を特定するまでに要する時間が手動デバッグと比べて大幅に短縮されました。

3.Amazon Q Developer ProとKiro IDEによるコスト効率

Amazon Q Developer Proとは

Amazon Q Developerは、AWSが提供するAIコーディングアシスタントです。ProプランはIDE統合のコード補完・チャット機能等が利用出来て、価格は1ユーザー当たり$19/月です。Kiro IDEはAmazon Q Developer Proのサブスクリプションで利用出来るため、追加費用なしでPlaywright MCPとの連携環境を構築出来ます。

コスト構造の整理

Playwright Test Agentsによるテスト自動化環境の主なコスト構成は以下の通りです。

今回のテストケースの生成ではAmazon Q Developer Proの利用上限に達することなく、全機能のテストケースを生成することが出来ました。開発チーム内で、Amazon Q Developer Proを実装時にも利用していますが、実装時にも上限に達することなく利用出来ているので、コストパフォーマンスは良いと思います。

Amazon Q Developerの今後について

2026年5月にAWSよりAmazon Q Developerについて、「Amazon Q Developer IDE プラグインおよびサブスクリプションサポートは2027年4月30日に終了します」のタイトルのメールで通知が来ました。内容としては、Amazon Q Developer のサポート終了に関するお知らせに記載されているものでした。Amazon Q DeveloperはKiroに移行し、2027年4月30日で使えなくなるようです。新規アカウントの作成は2026年5月15日以降に出来なくなり、モデルは2026年5月29日以降にOpus 4.6が利用不可になり、Opus 4.5以下の既存モデルは引き続き利用出来るようです。

4.まとめ

本記事では、Playwright Test AgentsとKiro IDE、Amazon Q Developer Proを組み合わせたスタッフツールのE2Eテスト自動化の取り組みをご紹介しました。226件のテストケースを自動化し、全件PASSすることが出来、エラー検出精度の検証でも、意図的に改ざんした箇所を全て検出出来ました。今後は機能追加や仕様変更に合わせて新たなテスト計画・テストケースを生成したり、Healerにより自動で復旧する仕組みを整えていく予定です。また、ユーザーに提供しているWebサービス側のE2Eテストの自動化も進めていく予定です。

Amazon Q Developer Proと組み合わせることで、1ユーザー当たり月額$19で利用出来るので、コスト面でのメリットもあると思います。AWSよりAmazon Q Developerの提供終了・Kiroへの移行の通知がありましたが、本記事でご紹介したKiro IDEを使ったワークフローはそのまま継続して利用出来るので、Kiroへの移行と並行して、AIを活用したテスト自動化やテスト品質の維持・向上に取り組んでいきたいと思います。

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。