AIはPRDからE2Eテストを生成できるか？
Zeshi Du
できます。ただし、正直な回答には、機能するために何が必要かという条件も含まれます。PRDからE2Eテストを生成することは、2つの難問を連鎖させることです。ドキュメントの意味を理解すること、そしてその意味を実際のプロダクトに対して実際に動作するテストへと変換すること。前半だけを解決するAIツールは、何も検証しない見栄えの良い成果物を生み出すだけです。
全体像をお伝えします。この機能が必要とするもの、単純なアプローチが破綻する箇所、そしてTestSpriteがそのチェーンをエンドツーエンドで実装する方法です。
「PRDから」が意味するべきこと
PRDは意図を記述します。ユーザーはこれができる、システムはこれを強制すべき、このフローはこの結果で終わる。E2Eテストは挙動を検証します。ブラウザがステップを実行し、結果を確認する。両者の間には3つの変換が存在し、それぞれがチェーンの破綻しうる箇所です。
ドキュメントは構造化された意図へと変換されなければなりません。人間向けに書かれた文章から、機能・フロー・ルールを正確に抽出します。その意図は実行可能なステップへと変換されなければなりません。想像上のプロダクトへの疑似コードではなく、実際のプロダクトへの実際のナビゲーションです。そして、ステップはプロダクトの進化に伴って有効であり続けなければなりません。PRDの約束はUIのいかなる単一ビルドよりも長く生き続けるからです。
PRDからE2Eを主張するツールは、最初の1つだけでなく、3つすべてに対して評価されるべきです。
単純なアプローチが破綻する箇所
PRDをモデルに渡してテストスクリプトを生成させるという直接的なアプローチは、予測可能な箇所で失敗します。
実装を幻覚します。PRDにはユーザーがログインすると書かれているため、生成されたスクリプトはモデルが作り出したページ構造上の、存在しないかもしれない #login-button をクリックします。ドキュメントのギャップや陳腐化を引き継ぎます。PRDは著者が把握しているがモデルは知らない形で不完全・時代遅れなため、異なる形でリリースされた、またはリリースされていない機能のテストが生成されます。そして静的な成果物を生み出します。推測した実装に固定されたスクリプトは、書かれた瞬間から劣化し始めます。
3つの失敗すべてに共通するパターンは同じです。ドキュメント単体では不十分です。PRDはプロダクトを記述するものであり、テストはプロダクト自体に対して実行されなければならないからです。
TestSpriteがチェーンを実装する方法
TestSpriteのアプローチは、各変換を検証可能なものに根拠を置きます。
PRDは編集可能なフィーチャーマップになります。エージェントはドキュメントを機能とフローの構造化された全体像へとパースし、生の文章ではなくそのマップがテスト生成の根拠となります。「編集可能」が重要な性質です。何かが実行される前に、マップを確認し、誤読された要件を修正し、スコープ外のものを削除し、ドキュメントが省いたものを追加できます。ドキュメントのギャップは、暗黙的に引き継がれるのではなく、人間の目視によって解消されます。PRDがないチームでも始められます。エージェントがコードベースとプロダクトから意図をリバースエンジニアリングし、マップはそれが正しく理解できているかを確認する場所となります。
そして意図は現実と出会います。探索エージェントがデプロイ済みアプリケーションを開き、実際のユーザーとして、フィーチャーマップが記述するフローをナビゲートします。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
実行可能なステップはこの探索から生まれます。実際の要素、実際のナビゲーション、マルチステップのジャーニーを流れる実際のデータ、そのため何も想像上の実装に固定されません。PRDの約束がバックエンドに関わる場合、Backend Testing 2.0は実際のエンドポイントを呼び出し、アサーションを生成する前に実際のレスポンスを観察します。テストが実行可能なのは、実行することから導出されたからです。
そして3つ目の変換、有効であり続けること、は挙動に根拠を置くことで処理されます。UIが変化した場合、Auto-Heal Rerunが適応して検証可能な形で再実行し、挙動が壊れた場合、PRDの言語で検出結果が浮上します。どの約束されたフローで、何が起きるべきで、何が起きたか。
ワークフローにおける実際の姿
実践的なループは短いものです。PRDをアップロードするか、エージェントをプロジェクトに向け、フィーチャーマップを確認・調整し、実行します。検出結果は作業が行われる場所に届きます。CursorまたはClaude CodeのMCPサーバー経由では、コーディングエージェントが同じセッションでギャップを修正します。GitHub Actions経由ではPRコメントとして届きます。フィーチャーマップはプロダクトのテスト可能な定義として永続するため、後続の実行は同じ根拠に対して新しい作業を検証し、Webポータルの実行履歴はPRDがかつて持っていなかったものになります。ドキュメントのどれだけが現在真実かのライブな記録です。
シナリオ: PRD、そのプロダクト、そしてその間のギャップ
4人のチームが、Claude Codeでホームクリーニングサービスのマーケットプレイスを構築しています。PRDは予約の約束を定義しています。顧客はサービスを選び、時間枠を選び、清掃員は仕事を受け付け、顧客は時間枠の24時間前までキャンセルを無料で行えます。
PRDをアップロードします。フィーチャーマップは、予約・マッチング・キャンセル・支払いをフローとして構造化した形で返ってきます。加えて、ドキュメントの古さによる産物が1つあります。企画段階でカットされた紹介プログラムです。確認パスでマップからそれを削除します。30秒で完了し、実行します。
エージェントは、デプロイ済みプロダクト上で実際のユーザーとして予約・マッチング・キャンセルを行います。マップのほとんどは緑で検証されます。キャンセルルールは特定の方法で失敗します。23時間前のキャンセルは正しく延滞料を請求しますが、再スケジュールされた予約をキャンセルすると、24時間の窓を新しい時間ではなく元の時間に対して測定します。そのため、火曜の予約を金曜に変更して水曜にキャンセルした顧客は、3日後の仕事に対して延滞料を請求されます。PRDのルールは明確でしたが、実装のクロックは誤ったフィールドに固定されていました。
検出結果は、違反する約束を参照してClaude Codeのターミナルに届き、修正によって窓が再固定され、再実行でクローズされます。紹介プログラムは、一方で幻のテストを生成しませんでした。マップが根拠であり、ドキュメントではなかったからです。
まとめ
AIはPRDからE2Eテストを生成できるか？できます。実装がそのタスクの本質を尊重している場合に限り。それはドキュメントから構造化された意図、実行された現実、維持されたカバレッジへのチェーンです。単純なバージョンは、ドキュメントを過度に信頼し、プロダクトに触れるのが少なすぎることで破綻します。
TestSpriteのチェーンはすべての環で根拠を持っています。レビュー可能な根拠としての編集可能なフィーチャーマップ、実際のアプリケーションの探索から導出されたテスト、証拠に基づくバックエンドのアサーション、そして挙動に固定されたメンテナンス。これによりPRDの約束はこれまで実現しなかったものになります。継続的に実行可能なものです。
今日、TestSpriteでPRDを実際に動作するE2Eテストに変換しましょう。無料プラン、クレジットカード不要。