AIはPRDからE2Eテストを生成できるか？
Zeshi Du
できる。ただし、正直な回答には「機能するために何が必要か」も含まれる。PRDからE2Eテストを生成することは、2つの難問を連鎖させることだ。ドキュメントの意味を理解すること、そしてその意味を実際のプロダクトに対して実行可能なテストへと変換すること。前半しか解決しないAIツールは、見栄えの良い成果物を生み出すが、何も検証しない。
そこで全体像を示す。このケイパビリティに何が必要か、ナイーブなアプローチがどこで破綻するか、そしてTestSpriteがどのようにチェーン全体をエンドツーエンドで実装しているか。
「PRDから」が意味しなければならないこと
PRDは意図を記述する。ユーザーはこれができる、システムはこれを強制すべきだ、このフローはこの結果で終わる、と。E2Eテストは動作を検証する。ブラウザがステップを実行し、結果を確認する。その間には3つの変換が存在し、それぞれがチェーンの破綻点となり得る。
ドキュメントは構造化された意図にならなければならない。人間向けに書かれた文章から、機能、フロー、ルールを正確に抽出する。意図は実行可能なステップにならなければならない。想像上のプロダクトに対する擬似コードではなく、実際のプロダクトに対するリアルなナビゲーションとして。そしてステップは、プロダクトが進化しても有効であり続けなければならない。PRDの約束は、UIのいかなる単一ビルドよりも長く生き続けるからだ。
PRD-to-E2Eを謳うツールは、最初の変換だけでなく、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をアップロードするか、エージェントをプロジェクトに向け、フィーチャーマップをレビューして調整し、実行する。発見された問題は作業が行われる場所に届く。MCPサーバーを通じてCursorまたはClaude Codeに届き、コーディングエージェントが同じセッションでギャップを修正する。あるいはGitHub ActionsによってPRコメントとして届く。フィーチャーマップはプロダクトのテスト可能な定義として持続するため、後続の実行は同じ根拠に対して新しい作業を検証し、Webポータルの実行履歴はPRDが持ち得なかったものになる。ドキュメントのどれだけが現在も真実であるかの、ライブな記録として。
シナリオ：PRD、そのプロダクト、その間のギャップ
4人チームが、Claude Codeでハウスクリーニングサービスのマーケットプレイスを構築している。PRDには予約の約束が定義されている。顧客はサービスを選び、時間帯を選択し、クリーナーが仕事を承認し、顧客は時間枠の24時間前まで無料でキャンセルできる。
PRDをアップロードすると、フィーチャーマップが予約、マッチング、キャンセル、支払いをフローとして構造化して返ってくる。さらに、ドキュメントの古さによる産物として、計画段階でカットされた紹介プログラムが含まれている。レビューパスでマップから削除する。30秒の作業だ。そして実行する。
エージェントはデプロイ済みのプロダクトで実際のユーザーのように予約し、マッチングし、キャンセルする。マップのほとんどはグリーンで検証される。キャンセルルールが特定の形で失敗する。23時間後のキャンセルは正しく遅延料金が課されるが、再スケジュールされた予約をキャンセルすると、24時間のウィンドウが新しい時間ではなく元の時間を基準に計算される。そのため、火曜日の予約を金曜日に変更して水曜日にキャンセルした顧客は、3日後の仕事に対して遅延料金を請求される。PRDのルールは明確だったが、実装のクロックは誤ったフィールドに固定されていた。
発見された問題は、違反している約束を参照してClaude Codeのターミナルに届き、修正によってウィンドウが再固定され、再実行でクローズされる。一方、紹介プログラムはファントムテストを一切生成しなかった。マップであり、ドキュメントではなく、それが根拠となっていたからだ。
まとめ
AIはPRDからE2Eテストを生成できるか？ できる。実装がタスクの本質を尊重している場合に限り。つまり、ドキュメントから構造化された意図へ、実行された現実へ、維持されたカバレッジへというチェーンを。ナイーブなバージョンは、ドキュメントを信頼しすぎ、プロダクトに触れる機会が少なすぎることで破綻する。
TestSpriteのチェーンはすべてのリンクで根拠を持つ。レビュー可能な根拠としての編集可能なフィーチャーマップ、実際のアプリケーションの探索から導出されたテスト、エビデンスに基づくバックエンドのアサーション、動作に固定されたメンテナンス。これにより、PRDの約束はこれまでなかったものになる。継続的に実行可能なものとして。
今すぐTestSpriteでPRDを実行可能なE2Eテストに変換しよう。無料プラン、クレジットカード不要。