Chatworkの利用料金やプランに関係する開発・運用を担当するチームでPHPエンジニアをしているヤシロです。
この記事では、Claude CodeとChrome DevTools MCPを組み合わせて、E2Eテスト作成の自動化をやってみた取り組みについてご紹介します。
取り組みの中で、うまくいかないところもあり、完全な自動化まではできなかったものの、自動化に近づく仮説も出てきたので、あわせてご紹介します。
この記事は、kubell Advent Calendar 2025(シリーズ 2)の10日目の記事です。
E2Eテスト実装の課題
私のチームでは、機能実装が完了するとTestRailにテスト手順と期待値を記載し、それをもとにSelenium(PHP)でE2Eテストを実装しています。ただし、E2Eテストを書くほどでもない機能については省略することもあります。なお、現状ではCI/CDには組み込んでおらず、ローカル環境でのみ実行しています。
チームでのE2Eテスト実装の流れは以下のとおりです。
実装完了 → TestRailにテスト手順・期待値を記載 → Seleniumの実装 → Seleniumの実行結果をTestRailに添付 → レビュー依頼
E2Eテストの実装・運用には課題を感じていました。
まず、TestRailに書いた手順をSeleniumのコードに落とし込む作業が単調で手間がかかります。セレクタを調べてコードに書くという作業の繰り返しになるため、正直なところ面倒です。
また、UIが変わるたびにセレクタの修正が必要になり、メンテナンスコストも高くつきます。テストが壊れても直す時間がなく、そのまま放置されてしまうことも少なくありません。
以前、Claude単体でテストコード生成を試みたことがあります。しかし、Claudeはブラウザの画面を実際に見ながらテストを書くことができないため、DOM構造を正確に把握できず、セレクタの精度が低くなってしまいました。結局手直しが多く発生し、期待したほどの効率化にはつながりませんでした。
Chrome DevTools MCPで精度が上がるのではないか
そんな中、Chrome DevTools MCPの存在を知りました。これを使えばClaudeがブラウザの画面を見ながらテストを書けるようになります。TestRailにはすでにテスト手順が書いてあるので、それをそのままAIに渡してSeleniumのコードを生成してもらえれば、以前の課題を解決できるのではないかと考えました。
TestRailとClaude Codeを連携させる
TestRailとClaudeを連携する公式MCPは存在しないため、TestRailからテストケースを手動でコピペする必要があります。しかし、これでは手間がかかるので、APIでテストケースを取得してそのままClaude Codeに渡せる仕組みを作ることにしました。
まず、TestRail APIを使ってテストケースを取得するPHPスクリプトをClaude Codeで生成しました。このスクリプトにケースIDを渡すと、テストケースのタイトル、各ステップの内容、期待値を取得できます。
以下はTestRail APIを利用してテストケースを取得するPHPスクリプト(生成はClaudeで行いました)
<?php // 省略 try { $client = new Cw\Tests\Helper\TestRailAPIClient(); $case = $client->getCase($case_id); echo "===== TestRail ケースID: {$case_id} =====\n"; echo "タイトル: " . ($case['title'] ?? 'N/A') . "\n\n"; if (!empty($case['custom_steps_separated'])) { echo "テストステップ:\n"; foreach ($case['custom_steps_separated'] as $index => $step) { $stepNum = $index + 1; echo "\n{$stepNum}. " . ($step['content'] ?? '') . "\n"; if (!empty($step['expected'])) { echo " 期待値: " . $step['expected'] . "\n"; } } } else { echo "テストステップが見つかりません\n"; } echo "\n===== 完了 =====\n"; } catch (Exception $e) { echo "エラー: " . $e->getMessage() . "\n"; exit(1); }
次に、CLAUDE.mdに設定を追記しました。
ユーザーがTestRailのケースIDまたはURLを提供すると、Claude Codeが自動的にTestRailからケース情報を取得し、その情報をもとにSeleniumテストコードを生成する流れを記述しています。特定のケースIDを指定してスクリプトを実行すると、テストケースのタイトルとともに、各ステップの手順と期待値が順番に出力されます。
実践①:画面を操作しながらテストケースを自動生成する
まず試したのは、TestRailに記載するテスト手順と期待値そのものをClaude Codeで生成することです。画面を見ながら生成することで、実際の動作に即したテストケースを作成できると考えました。
Chrome DevTools MCPでブラウザを操作しながら、手順と期待値を記録するようプロンプトで指示しました。入力値やボタンを指示しながら進めると、Claudeがテストケースを出力してくれました。画面遷移に沿って各ステップの手順と期待値が整理された形で生成され、期待値には表示されるべき具体的な文言や入力値の反映状況なども含まれており、実用的な内容になっていました。
以下は、Chatworkのプラン変更機能に関して実際に生成されたテストケースの抜粋です。
前提条件: フリープランのアカウント(user@example.com)でログイン済みであること
| Step | 手順 | 期待値 |
|---|---|---|
| 1 | 料金表画面にアクセスする | 料金表画面が表示され、フリープランに「現在利用中」と表示されている |
| 2 | ビジネスプランの「アップグレード」ボタンをクリックする | プラン変更画面に遷移し、契約アカウント、利用プラン、ライセンス数、ご利用料金、お支払い方法が表示される |
| 3 | 「年間契約」ラジオボタンを選択し、「次へ進む」ボタンをクリックする | 決済情報入力画面に遷移し、Stripeのセキュアな支払い入力フレームが表示される |
| … | … | … |
| 5 | 「この内容で申し込む」ボタンをクリックする | プラン変更完了画面に遷移し、「利用プランの変更が完了しました。」のメッセージと案内メール送信の案内が表示される |
実践②:Seleniumコードを自動生成する
次に、TestRailのケースIDを渡すだけでSeleniumコードを生成する流れを試しました。「TestRailのケースID 9938のSeleniumテストを作成して」とプロンプトで指示すると、Claude CodeがTestRail APIでケース情報を自動取得し、Chrome DevTools MCPで画面を確認しながらSeleniumコードを生成してくれます。
生成されたSeleniumコードはかなりの行数になるため、ここでは省略しますが、テストケースの各ステップに対応したコードが出力されました。
ただし、生成されたコードにはいくつか特徴がありました。プロダクト自体のHTML要素の使い方が通常のユースケースと異なる部分については、要素の取得に失敗していたり、一部確認してほしいassertが抜けていたりすることがありました。
また、Chatworkではクレジットカード情報の入力フォームとしてStripe PaymentElementを使用しているのですが、iframeのような動的に生成される要素の取得は苦手な傾向があるように思いました。
良かった点と課題
上記の取り組みを行うことで、テストケース作成やSelenium実装の負担を多少は下げることができました。
TestRailのケースIDを渡すだけでSeleniumコードが生成されるようになり、セレクタを調べる手間が大幅に削減されました。Claude単体で試したときと比べて、Chrome DevTools MCPを使うことでテストコードの精度が向上したように思います。
一方で課題もあります。複雑なフローでは一発で完璧なコードにならないこともあり、生成されたコードのレビューと手動での修正は引き続き必須です。
負担は軽減されたものの、一部のケースではそのまま使えるコードが出力されるわけではなく、まだまだ人の手による調整が必要な段階です。
生成されたコードのデバッグに関しては、ブラウザを操作しながらできるので、修正の精度も上がったように感じました。
まとめ
Chrome DevTools MCPを使うことで、テストケース作成やSelenium実装の負担を軽減できるようになりました。
CLAUDE.mdにTestRail連携の設定を書いておけば、ケースIDを渡すだけで自動生成が可能です。ただし、完璧なコードが生成されるわけではなく、手動での修正作業は依然として必要です。
それでも、E2Eテストの「たたき台」を作るには十分実用的で、ゼロから書くよりは大幅に楽になりました。
今後はテスト失敗時の自動修正なども試していきたいと考えています。
E2Eテストを書くのは正直面倒ですよね。同じ悩みを持っている方は、ぜひ試してみてください。