はじめに
プロダクトエンジニアのテックリードをしている橋本です。
今回はリファクタリングを行った際のテストについてです。
リファクタリング PR のテストで、修正対象のコードパターンが多く、該当するテストデータを探すのも面倒、実施パターンも多いので手動でやりたくありませんでした。そこで Claude Code と Chrome DevTools MCP を使った自動 QA を試してみました。
今回の QA 対象
管理画面で社内利用している機能の改修を予定しており、その前段階としてリファクタリングを実施しました。具体的には、プリミティブな値を直接使用していた箇所を、変更容易性を高めるための適切なオブジェクトに置き換える変更です。
Unit Test は存在していますが、画面から一貫した E2E テストがあるわけではありません。今回の変更は影響範囲が広く、ビジネスロジックの振る舞いが変わっていないことを確認するため、手動での動作確認が必要でした。
テスト対象のパターンは以下の 7 種類でした:
| パターン | 対象 | アクション数 |
|---|---|---|
| A | プランX: 審査フェーズ1 | 2 |
| B | プランX: 審査フェーズ2 | 2 |
| C | プランY: 審査フェーズ1 | 2 |
| D | プランY: 審査フェーズ2 | 2 |
| E | 再編集承認 | 2 |
| F | 公開後: 審査フェーズ1 | 3 |
| G | 公開後: 審査フェーズ2 | 2 |
合計 16 テストケースです。各パターンに該当するデータをローカル DB から探し、画面操作で動作確認し、スクリーンショットを取得してレポートにまとめる必要がありました。
やったこと
使用したツール
- Claude Code: Anthropic の CLI ツール
- Chrome DevTools MCP: ブラウザ操作を可能にする MCP サーバー
- カスタムコマンド: 指示書を実行するスラッシュコマンド
実行の流れ
- 指示書に QA の手順を記述
- カスタムコマンドで実行開始
- Claude が PR コメントからテストパターンを確認
- ローカル DB から各パターンに該当するデータを自動検索
- QA 操作手順書を生成
- Chrome DevTools MCP 経由でブラウザ操作を実行
- 各パターンのスクリーンショットを自動取得
- レポートを生成
楽だった部分
データ探しの自動化
なお、ローカル開発環境で使用しているデータは、本番データに対して機密情報をマスク・書き換えたものを dump し、ローカルで import して利用しています。テストデータをゼロから作成することも可能ですが、関連テーブルが多く、フロー全体でのデータ変化もかなり複雑なため、全パターンを一から作成するのは現実的ではありませんでした。
7 パターン × 複数データの検索を Claude が自動でやってくれました。手動だと Rails console で条件に合うデータを探す作業が必要で、かなりの時間がかかります。
# こういうクエリを何度も書く必要がありました
# あくまでイメージです。実際の model や attribute とは一致していません。
Review.joins(:request)
.where(review_type: :phase1, status: :ongoing)
.where(requests: { ... })
これを全部 Claude がやってくれました。ちなみに、Claude はクエリを書く際にカラム名を間違えることがありましたが、自動でエラーを検出し、修正して再実行しました。こうした軽微なミスの自己修正ができるのも利点です。
画面操作の自動化
ダイアログの同意ボタン以外は全て自動で操作されました。
（ダイアログは本来 MCP ツールの handle_dialog で操作できるはずですが、今回はなぜか上手く動作しませんでした...）
- ページ遷移
- フォーム入力
- ボタンクリック
- スクリーンショット取得
16 テストケースの操作を自分でやる必要がありませんでした。
レポート生成
指示することで、操作結果のスクリーンショット付きレポートを生成させました。状態変化のテーブルも作成させました。これは markdown のレポートを出力させた上で pdf にツールで変換して issue に紐づけておきました。
テストデータが存在しないケースへの対応
パターン G に該当するデータがローカル環境に存在しませんでした。Claude はこれを検出し、パターン F のデータを使って審査申請を実行することでパターン G の状態を作成する手順を考えていました。こうした「データがないなら作る」という判断と手順の組み立ても自動で行ってくれます。
楽できなかった部分
途中で何度も止まる
完全自動とはいかず、途中で何度も介入が必要でした。Claude Code のコンテキスト制限に達して会話が途切れることもあり、その都度「続きをやって」と指示して継続させる必要がありました。
事前データ調査と実際の差異
データを事前に調査して「このデータでテストできる」と判断しても、実際に操作すると別の審査が未完了でエラーになるなど、想定外の問題が発生しました。データベースのレコード状態だけでは判断できない前提条件があり、実際に操作してみないと分からないケースがありました。
テストデータの消費問題
操作を実行すると、そのデータは次のステータスに遷移してしまいます。同じパターンで別のテストをしたい場合、使えるデータがなくなります。
対策としてデータベースを復元してから続きを実行する必要がありました。これは Claude に指示すれば実行してくれますが、データ復元の必要性を判断するのは人間の役割でした。
ダイアログ操作の問題
Chrome DevTools MCP でブラウザのダイアログ（confirm 等）の OK ボタンが上手く押せませんでした。handle_dialog ツールを使用しても、タイミングの問題でダイアログが表示される前にコマンドが実行されてしまうことがありました。この部分だけは手動で対応しました。
コンテキストオーバーフロー
長時間の QA 実行中に Claude Code のコンテキスト制限に達し、会話が途切れることがありました。圧縮された会話から続行しようとしても正しく動作しないことがあったため、セッションをリセットして新しいセッションで「続きをやって」と指示して継続させました。ただし、前のセッションの状態を完全には引き継げないため、どこまで完了しているかの確認が必要でした。
なお、これはサブエージェントなどを活用してコンテキストを分割すれば対処可能な問題です。今回はあくまでゼロから会話ベースで進めたため発生した課題であり、事前に仕組みを整備しておけば回避できます。
結果
| 項目 | 結果 |
|---|---|
| テストケース数 | 16 |
| 成功 | 16 |
| エラー | 0 |
| スクリーンショット数 | 26 枚 |
全パターンの動作確認が完了し、リファクタリングが正常に機能していることを確認できました。
所感
良かった点
- データ探しのコスト削減: パターンが多い場合、該当データを探す作業だけでもかなりの時間がかかります。これを自動化できたのは大きいです
- 操作の自動化: 単純作業の繰り返しを自分でやらなくて済みました
- レポートの自動生成: スクリーンショット付きのレポートが自動で作成されました
- 軽微なエラーの自己修正: クエリのカラム名間違いなど、軽微なミスは自動で修正して再実行してくれました
- 不足データへの対応提案: テストに必要なデータが存在しない場合、作成手順を提案してくれました
課題
- 完全自動化は難しい: 途中で止まる前提で、介入できる状態で実行する必要があります
- データの状態管理: テスト実行でデータが変わるため、復元の仕組みが必要です
- ブラウザ操作の限界: ダイアログ操作など、一部対応できない操作があります
- コンテキスト制限: 長時間のタスクでは会話が途切れることがあり、継続指示が必要
総評
「完全自動で楽々」とはいきませんでしたが、手動で全部やるよりは確実に楽でした。特にパターンが多く、データ探しが面倒なケースでは効果が大きいです。
今回のケースでは、7 パターン × 2 以上のアクション = 16 テストケースという規模感でしたが、これを手動でやると各パターンに該当するデータを探す作業だけで相当な時間がかかります。Claude にやらせることで、その時間を他の作業に使えました。
ただし、完全に放置できるわけではなく、途中で止まったら再開させる、データを復元する、ダイアログを手動で操作するなど、ある程度の監視と介入は必要です。「半自動」くらいの感覚で使うのが現実的だと思います。
おまけ: Claude との会話の様子
実際の会話では約 400 回のやり取りがありました。印象的だったやり取りを 3 つ紹介します。
エラーの自己修正
Claude: カラム名の問題がありました。クエリを修正します。
Claude: `state_cd` が正しいカラム名です。クエリを修正します。
クエリのカラム名を間違えてもエラーを検出し、自動で修正して再実行してくれました。
データがない場合の提案
User: パターン G で事前操作をした結果、審査中にすることはできますか？
Claude: はい、可能です。パターン F のデータで審査申請アクションを実行すれば、
パターン G の状態を作成できます。
該当データがない場合でも、既存データから目的の状態を作る手順を提案してくれました。
ビジネスルールエラーの発見
Claude: 審査通過のテストでエラーが発生しました：
「本人確認審査が通過していません。審査画面から確認してください」
これは想定されたビジネスルールエラーです。審査を通過させるには、
本人確認審査が完了している必要があります。
単純な操作だけでなく、エラーの解釈やビジネスルールの理解も行いながらテストを進めてくれました。
まとめ
Chrome DevTools MCP を使った自動 QA は、特に以下のようなケースで効果的です:
- テストパターンが多い
- 該当データを探すのが面倒
- 画面操作が単純だが繰り返しが多い
- スクリーンショット付きのレポートが必要
一方で、完全自動化は難しく、人間の介入が必要な場面もあります。「半自動ツール」として割り切って使うのが現実的です。
余談
今回は Chrome DevTools MCP を使った会話ベースのアプローチでしたが、Playwright の Agent モードを使ってコードとして実行させるアプローチもアリかもしれません。テスト手順をコードで定義しておけば、再実行性や保守性が向上しそうです。