製品要件ドキュメントを自動的に実行可能なテストに変換する方法
Zeshi Du
PRDはプロダクトが何をすべきかを説明します。テストスイートは実際にそれを実行していることを検証します。この2つのドキュメントの間には、歴史的に人間だけが行える翻訳ステップがあります。要件を読み、それぞれの確認方法を決定することです。この翻訳が自動的にどのように行われるか、そして良い結果を得るために何を提供すべきかを説明します。
この翻訳ステップが通常崩壊する理由
従来のワークフローでは、誰か（QAエンジニア、またはその役割を担う開発者）がPRDを読み、テスト可能な要件に分解し、それぞれのテストケースを書きます。時間と担当者が割り当てられている場合はうまく機能します。AIネイティブなチームの多くが今まさに感じている理由で崩壊します。PRDはAIコーディングエージェントが手動のQAプロセスが対応するよう設計されたペースを超えて開発を進める中で、誰もそこからテストカバレッジを再導出する時間がないほど早く書かれ、または更新されるからです。
その結果は見慣れたパターンです。PRDが何が起きるべきかを述べ、コードがわずかに異なることをし、誰も要件を実際のチェックに翻訳していないためギャップを捕捉するものがありません。
ここで言う「自動的に」の具体的な意味
PRD駆動型エージェントは、要件定義書を直接読み込み、元のPRDの形式（正式な仕様書、Notionの草稿、いくつかのユーザーストーリーなど）に関わらず、一貫した構造を持つ正規化された内部バージョンを構築します。その正規化されたPRDから、ドキュメントを流し読みした担当者が気づいた事項ではなく、実際の要件に対応したテストケースを生成します。
実践的なプロセス
1. 既存のPRDをアップロードするか、パスを指定します。PRDがある場合は、現在の形式のまま主要なインテントソースとして使用できます。事前に再フォーマットする必要はありません。正規化ステップが、既存の構造をテストエージェントが一貫して扱える形式に変換します。
2. エージェントに正規化された要件定義書を構築させます。このステップでは、PRDと実際のコードベースの分析（プロジェクト構造、コンポーネント階層、APIルート、実装パターン）を組み合わせます。その結果として、製品概要・目標・要件などのコンポーネントが個々のテストケースにマッピングできるほど明確に分解された、構造化された内部PRDが生成されます。
3. 実行後ではなく、実行前にテスト計画をレビューします。これはスキップしない価値のあるステップです。生成された計画には、どの要件がどのテストケースにマッピングされたかが示されます。テストを実行した後に結果レポートを見て首をかしげるのではなく、この段階で要件の読み間違いを発見し、無駄なテスト実行を防ぐ機会が得られます。
4. レビュー済みの計画からテストケース生成とコード生成を行わせます。計画が正しい状態になったら、エージェントは各要件に対してハッピーパス・エッジケース・エラー状態をカバーするテストケースを設計し、テストコードに直接触れることなく実行可能なスクリプト（プロジェクトに応じてPlaywright・Cypress・APIテストスクリプト）を生成します。
5. 隔離された環境で実行し、合否だけでなく元のPRDに照らして結果を読み取ります。テストがパスしても、マッピングされた要件が正しく満たされているとは限りません。特に初期段階では、テストケースとPRDセクションのマッピングを定期的にスポットチェックし、変換ステップがインテントを正確に捉えていると確信できるようにすることが重要です。
より良い結果を得るためにPRDに実際に記載すべき内容
生成されるテストの質は、PRDの品質と具体性に比例します。「ユーザーがチェックアウトできる」という要件では、エージェントが作業できる情報が乏しいのに対し、「ユーザーが保存済みカード・新しいカード・PayPalでチェックアウトでき、支払いに失敗した場合はエラーが表示される」という記述は、最初のバージョンではエージェントが推測に頼るしかない内容を、3つの支払い方法と1つの失敗状態という明確なテストケースに直接マッピングできます。
正式なPRDがまったくない場合でも、それはブロッカーにはなりません。エージェントはコードベースから直接製品のインテントをリバースエンジニアリングできます。ただし、インフォーマルなものであっても書かれたPRDは、純粋なコード推論よりも一貫して精度の高いテストカバレッジを生み出します。コードは何が実装されたかを示しても、何が意図されていたかを必ずしも示すわけではないからです。
PRDの今後の書き方に何が変わるか
PRDがテスト生成に直接フィードされることを理解すると、要件を書く際にテスト可能な具体性を意識する価値が生まれます。機能を高レベルでのみ説明し、詳細は実装中に埋められると想定するのではなく、異なる状態やエッジケースを明示的に記述します。これは余計な作業ではありません。有能なQAエンジニアがいずれ求めてくるのと同じ具体性を、レビュー会議で後から引き出すのではなく、最初から記録しておくだけです。
身につける価値のある習慣：コードを更新する前にPRDを更新する
特にAIコーディングエージェントを使って素早く開発している場合、実装を先に変更してPRDを後で更新する（もしくは更新しない）という誘惑に駆られがちです。しかしその順序は、PRD駆動型テストの前提を静かに崩壊させます。PRDを更新するまで、生成されたテストは古い要件を検証し続けるからです。順序を逆にして、コーディングエージェントに実装を依頼する前にPRDを（たとえ1文でも）更新することで、テスト生成が現在のインテントに基づき続け、後追いにならずに済みます。また二次的なメリットもあります。すでに陳腐化した要件から作業するエージェントよりも、更新された要件から作業するコーディングエージェントの方が、より正確な実装を生み出す傾向があります。
具体性の違いを示す短い例
同じ要件の2つのバージョンを比較してみましょう。「ユーザーはパスワードをリセットできる」という記述は、リセットフローの存在以外、テストジェネレーターにほとんど何も伝えません。一方、「ユーザーがメールでリセットリンクをリクエストし、リンクは30分後に期限切れとなり、期限切れのリンクにはジェネリックなエラーではなく特定のエラーが表示される」という記述は、1つの曖昧な項目ではなく、リクエスト自体・有効期限の境界・特定のエラー状態という3つの明確でテスト可能な動作をジェネレーターに提供します。2番目のバージョンを書くのに要する追加時間はわずか15秒程度ですが、機能が存在するかどうかを確認するテストスイートと、エッジケースで実際に意図した通りに動作するかを確認するテストスイートの差を生みます。そして実際のバグのほとんどは、まさにエッジケースで発生します。
まとめ
PRDから実行可能なテストを自動生成することで、AIがパイプラインの他のすべてを加速させた後もボトルネックになりがちな手動の変換ステップが不要になります。要件は依然として明確である必要がありますが、変わるのはその要件を実行中のテストに変換する作業を誰が行うかです。TestSpriteのPRD駆動型テスト生成は、正式・非公式を問わず既存の要件定義書から直接その変換を処理します。