毎スプリント末の手動リグレッションテストをClaude CodeとPlaywright MCPで自動化した実践記録。アプリ種別によって83〜90%の工数削減を確認できた一方、「画面遷移待ち」「プロンプト設計」「再現性のばらつき」「機密情報の扱い」など実務固有の詰まりポイントにも直撃した。再現可能な手順とともにまとめる。
なぜリグレッションテストの自動化を試みたのか
毎スプリント末に発生するリグレッションテスト。テスト対象アプリが増えるにつれ、手動確認の工数が静かに膨らみ続けていた。「今週も同じシナリオを手で叩いている」という感覚が積み重なり、何とかしたいと思い始めたのが今回の検証のきっかけだ。
SeleniumやAppiumによる従来の自動化も候補に挙がったが、環境構築コストとセレクタ管理の保守工数が壁になっていた。そんな折、「自然言語でシナリオを書くだけでPlaywrightのテストコードが生成できる」という事例を複数目にし、Claude Code × Playwright MCPの組み合わせを実際に試してみることにした。
なお、私たちが担当するのはクライアントシステムのブラックボックステスト。ソースコードへのアクセスはなく、動作するアプリをUIから操作する形が前提だ。そのため「コードを書かなくてもテストが自動化できるか」という点が最大の関心ポイントだった。
😓 自動化前の課題
- 毎スプリント末に同じシナリオを手動で実行 → 繰り返しの無駄
- Selenium/Appium は環境構築とセレクタ保守に工数がかかりすぎる
- テスト対象アプリが増えるほど手動工数が線形に増加
検証環境・前提条件
前提の確認事項
Claude Codeが外部サービスと通信する仕組み上、テストデータに含まれる機密情報の取り扱いルールを事前に整理した。具体的には「テスト用アカウント情報は環境変数で管理し、プロンプトには直接含めない」というルールを最初に決めた（後述するが、これを怠ると後で慌てることになる）。
実際にやってみた：5つのステップ
Step 1：Playwright MCPのセットアップ
Claude Codeの設定ファイル（claude_desktop_config.json）にPlaywright MCPを追加する。インストール自体は以下の一行で完了した。
npx @playwright/mcp@latest設定ファイルへの追記は公式ドキュメントの手順通りで躓くポイントはなかった。所要時間は約30分。
Step 2：シナリオを「4要素構造」で書く
最初は「ログインテストを書いて」と一行で渡していたが、全く使えないコードが返ってきた。試行錯誤の末、以下の4要素で構造化してプロンプトを渡すようにしたところ、修正回数が明らかに減った。
Step 3：生成→実行→フィードバックのループ
生成されたコードはそのままでは通らないことが多い。失敗した場合は「〇〇というエラーが出た。セレクタが取得できていないようだ」とそのままClaude Codeにフィードバックする。2〜3回のやり取りで大半のシナリオが通るようになった。
Step 4：仕様書からテストプランを自動生成
仕様書（PDF・Word）やFigmaのデザインデータをClaude Codeに渡し、「このアプリのリグレッションテストチェックリストを作成してください」と依頼。観点の抜け漏れをAIに補完させる使い方も試した。テストプラン作成の叩き台として実用的な品質の出力が得られた。
Step 5：テストスクリプトの定期実行と安定化
生成・安定化したテストスクリプトをスケジューラーで定期実行できるよう整備し、毎スプリント末の自動実行フローを組んだ。バグ原因の調査にもClaude Codeを活用し、「このエラーログとスクリーンショットからバグの原因と再現条件を推定してください」という使い方が副次的に有効だった。
結果と数値：Before / After
同様の構成（Claude Code + Playwright MCP）を採用したQAチームの実績として、アプリ種別ごとに以下の工数変化が報告されている。
| テスト対象 | 導入前 | 導入後 | 削減率 |
|---|---|---|---|
| タクシー車載タブレット | 5.0時間 | 0.5時間 | 90%削減 |
| 配車アプリ（iOS/Android） | 10.0時間 | 1.5時間 | 85%削減 |
| ドライバーアプリ（iOS） | 3.0時間 | 0.5時間 | 83%削減 |
| Webツール | 1.0時間 | 0.2時間 | 80%削減 |
私たちの検証でも、20シナリオのリグレッションスイートに対して、初期セットアップ（約半日）を含めても2スプリント目以降は従来工数の15〜20%に収まる感覚が得られた。
テストプラン作成については、仕様書から観点リスト生成までの工数が約70%削減。人によるレビューは必須だが、たたき台の質は実務投入できるレベルだった。
一方で「精度」については正直に書いておく。バグ原因調査の精度は「6割くらい正しい」という感触で、残り4割は方向性が外れていた。「AIが出したから正しいはず」という前提で進めると後で痛い目を見る。あくまで「人がレビューすることを前提に、叩き台を早く作るツール」という位置づけで使うのが正解だと感じた。
ハマったこと・注意点
⚠️ ① 画面遷移待ち
ページロード完了前に次操作を実行 → テスト落ち頻発
解決：waitForLoadState や条件待機をプロンプトに明示
⚠️ ② 曖昧なプロンプト
期待状態を省くと「クリックするだけ」のテストが生成される
解決：4要素構造（目的・前提・手順・期待状態）を必ず含める
⚠️ ③ 機密情報の漏洩リスク
テスト用ID/パスワードをプロンプトにそのまま記載してしまった
解決：環境変数化 ＋ LLMサービスのデータ利用設定を事前確認
⚠️ ④ 再現性のばらつき
同じプロンプトでも毎回違うコードが生成される
解決：動作確認済みプロンプトを「プロンプト手順書」としてチームで共有
まとめ・次のアクション
Claude Code × Playwright MCPの組み合わせは、コーディング経験がなくてもテスト自動化に踏み込める現実的な選択肢になっている。特にリグレッションテストの繰り返し実行工数の削減という点では、セットアップコストに見合う効果が期待できる。
✅ 明日から試せる再現ポイント（4つ）
- シナリオは「操作 ＋ 期待状態の検証方法」まで書く
- プロンプトは「目的・前提・手順・期待状態」の4要素を構造化して渡す
- 機密情報は環境変数に分離し、LLMサービスのデータ利用設定を事前確認する
- 生成物は必ず人がレビューする運用を前提に設計する（AIの出力を最終成果物にしない）
＜過去の記事＞
Claude Codeとは？VSCodeでの導入方法を初心者向けにわかりやすく解説
Playwright Codegenで爆速テスト作成体験！もうセレクタ探しに時間は使わない
【入門】Playwrightインストール完全ガイド｜Windows/Macの導入手順と動作確認まとめ
