AIにE2Eテストの実装を任せるなら、大事なのは「ドキュメント」の質！

最近、開発現場では「AI駆動開発」が当たり前になりつつありますよね。私が参加している新オフィスプロジェクトでも、積極的にAIを取り入れています。ただ、よく耳にするのが「E2E（End-to-End）テストをAIに完璧に書かせるのは難しい」という声です。

画面遷移が複雑だったり、実際のデータベースや外部サービスと連携したりする E2E テストは、確かにハードルが高いイメージがあります。しかし、今回実際にやってみた結果、ある結論に達しました。

「AIに丸投げは無理。でも、仕様の『文脈』を整えてあげれば、AIは驚くほど強力な武器になる」

今回は、Cursor と Playwright を使い、どのように AI に E2E テストを実装させたのか、その過程で見えた「重要なポイント」をシェアします！

1. 前提条件と技術スタック

今回の検証環境は以下の通りです。

• AIツール: Cursor（メインのコード生成には Claude 4.6 Opus、微調整に Autoモード を使用）
• テストフレームワーク: Playwright

  Playwrightとは？

  Microsoftが開発しているオープンソースのブラウザ自動化ライブラリです。Chromium、Firefox、WebKitといった主要なブラウザを一つのAPIで操作でき、モダンなWebアプリのテストを高速かつ安定して行えるのが特徴です。最近のE2Eテスト界隈では、非常に人気のあるツールですね！

• テスト対象: 新オフィスの「会議室予約システム」。ユーザーが実際に画面を操作して、予約が正しく完了するかという「正常系」のUI動作を検証します。

2. 実践：AIにE2Eテストを実装させるための3つの重要ポイント

実際のファイルの中身を見なくても、AIがなぜ動くコードを書けたのか。その理由は「ソースコード以外の情報」の与え方にありました。

ポイント1：AIに「ビジネスの文脈」を理解させる

AIはコードを読み取れますが、コードから「業務のルール」を読み取るのは苦手です。例えば、以下の情報はコードだけでは伝わりません。

• 業務フロー: 「空室の状態から、ボタンを押して予約し、ステータスが使用中になる」という一連の流れ。
• テストの目的: 「単にボタンが押せるか（UI）」を確認したいのか、「実際にGoogleカレンダーまで予約が入るか（結合）」を確認したいのか。
• 実行条件: 「テスト前には必ず会議室を空室にしておく」といった前提条件。

これらをAIに共有するために、既存の仕様書を活用しました。業務フローやテストの目的が明文化されていたことで、AIは「何をどこまでテストすべきか」という前提を外さずに実装できました。

ポイント2：「これがあれば動く」具体的情報の提供

AIが迷わず実装を完了させるためには、以下のような具体的な「材料」が整理されている必要があります。ドキュメントに以下の要素が含まれていたのが大きな勝因でした。

ドキュメントに書いていなかった部分（今回はデータの投入方法は記述してませんでした）は、AIがソースコードを読み取って推測して補う形になりました。ここが明記されていれば、さらに精度が上がったはずです。

ポイント3：勝手な「モック化」を防ぐ制約設定

AIは放っておくと、「テストを通しやすくするため」に実APIやデータベースを本物そっくりの偽物（モック）に置き換えて実装してしまうことがあります。しかし、今回のE2Eテストの目的は「本番環境に近い状態で動くこと」でした。

そこで、AIに対して以下の制約を明確に（ドキュメントやプロンプト経由で）提示しました。

• モック禁止の徹底: 「画面操作を起点に実APIを呼び出し、FirestoreやGoogleカレンダーの実サービスを通して検証すること」を指示。
• 環境変数の活用: 開発環境のアプリURLや、テスト専用の会議室IDを環境変数から読み込むように誘導。

このように「やってはいけないこと（逃げ道）」を塞ぐことで、AIは現実のインフラ構成に即した、信頼性の高いテストコードを生成してくれました。

AIとのやり取り：実際に投げたプロンプトの例

では、具体的にどうやってCursorに指示を出したのか？私が実際に投げたプロンプトがこちらです。ポイントは「いきなり書かせないこと」でした。

それでは「ドキュメント名（複数でも良い）」をベースとして、 E2Eテストコードを実装してほしいです。
もし、実装する上で必要な情報（実装前の確認事項）があればそれを先に提示してください。

このプロンプトを投げると、AIは「テスト対象のベースURLは？」「テスト用のアカウント情報はどこにありますか？」のような、実装に必要な「足りないピース」をリストアップしてくれます。その返答を返した瞬間に、迷いのない正確なコードが生成されました。

💡 やるべきこと
AIが生成したコードは、「最後の一押し」の微調整が必須です！セレクタの微調整や、タイムアウト時間の調整など、人間が最終確認を行うことで、より堅牢なテストになります。

3. 実際にやってみてわかったこと

良かった点：驚異的なスピードと知識の補完

一番の驚きは、「Playwrightの詳しい書き方を知らなくても、テストが完成してしまう」ことです。テストエンジニアが手書きするよりも圧倒的に速く、かつ既存のCI/CD設定などを参照させることで、プロジェクトの作法に則ったコードが手に入りました。

苦労した点：AIの限界と「準備」の重要性

一方で、複雑な状態遷移（時間経過が絡むものなど）については、AIの理解が甘くなる場面もありました。また、今回は既存のインフラやCI/CD環境が整っていたためAIがそれを参照できましたが、ゼロからの状態だったら、もっと詳細な環境構築のプロンプトを書く必要があったと感じています。

4. まとめ

AIでE2Eテストの実装を自動化する鍵は、コードの書き方を教えることではなく、「ドキュメントを通じて、テストの背景とルールを正しく伝えること」にあります。

• 「テストケース（手順・ID）」が整理されているか
• 「実環境を使う」という方針が明確か
• 「業務フローの文脈」が示されているか

これらが揃っていれば、AIはプロジェクトにぴったりのE2Eテストを実装してくれるはずです！これからAIでE2Eテストの実装に挑戦する方は、まず「AIに読ませるためのドキュメント」の整理から始めたら良いと思います！