より良いコードとより良いテストを生み出すPRDの書き方
Yunhao Jiao
プロダクト要件定義書（PRD）は、興味深い形で復活を遂げています。長年にわたり、PRDは主にウォーターフォール開発と結びついていました。アジャイルが置き換えるべきとされた、重厚な事前ドキュメントの象徴です。そこにAIコーディングツールが登場し、突然PRDが再び不可欠な存在となりました。
その理由はこうです。AIコーディングエージェントは、与えられたコンテキストの質にしか依存できません。曖昧なプロンプトからは曖昧なコードしか生まれません。具体的な要件定義書からは、具体的で検証可能なコードが生まれます。そして、TestSpriteのようなエージェンティックテストプラットフォームを使用するチームにとって、PRDはテスト生成の文字通りの情報源となります。
このガイドでは、AIネイティブな開発においてPRDを効果的にする要素を解説します。AIが生成するコードの品質と自動テストのカバレッジを、同時に向上させるPRDのあり方を紹介します。
AIコーディングツール時代にPRDがより重要になる理由
従来の開発では、開発者が要件を読み、メンタルモデルを構築し、コーディング中に無数の細かな判断を行います。彼らの経験と判断力が、要件の隙間を埋めます。
AIコーディングエージェントは、隙間を別の方法で埋めます。統計的な蓋然性です。要件が曖昧な場合、AIはトレーニングパターンに基づいて最も可能性の高い解釈を選びます。これがあなたの意図と一致することもありますが、多くの場合そうではありません。しかも、本番環境で何かが失敗するまで気づきにくい形で。
AIが生成するコードの品質は、入力の明確さに正比例します。これは推測ではありません。詳細なPRDを用いたAIコーディングセッションは、曖昧なプロンプトを使ったセッションと比べて、より正確な実装と少ない意図のズレをもたらすと、多くのチームが一貫して報告しています。
特にTestSpriteにおいて、PRDはテスト生成の信頼できる唯一の情報源です。詳細なPRDは、正しい動作を検証するテストケースを生み出します。曖昧なPRDは、AIがあなたの意図を推測した内容をカバーするテストケースを生み出します。実際のバグを検出できるのは、前者だけです。
AIネイティブな効果的PRDの構成
1. 機能サマリー（2〜3文）
何を構築するのか、そしてなぜ構築するのかを、明確かつ簡潔に説明します。これは、以降のすべての意思決定の基盤となるコンテキストです。
弱い例：チェックアウトフローを構築する。
強い例：ログイン済みユーザーがカートを確認し、配送先・請求先情報を入力し、割引コードを適用して、Stripeで購入を完了できる複数ステップのチェックアウトフローを構築する。このフローはモバイルで動作し、決済失敗時も適切に処理できなければならない。
2. 受け入れ基準を伴うユーザーストーリー
各ユーザーストーリーには、明示的な受け入れ基準が必要です。「完了」の定義となる、具体的かつテスト可能な条件を記述します。
各受け入れ基準はテストケースになります。曖昧な受け入れ基準からは曖昧なテストが生まれます。具体的な基準からは、具体的で意味のあるテストが生まれます。
3. エッジケースとエラー状態
ほとんどのPRD、そしてAIが生成するコードが失敗するのはここです。特定の動作を引き起こすケースを明示的に列挙します。
- 空の入力が与えられた場合はどうなるか？
- 境界値の入力（最大長、最小値）が与えられた場合はどうなるか？
- 必要なサービスが利用不可の場合はどうなるか？
- 同時操作が発生した場合はどうなるか（2人のユーザーが最後の1点を同時に購入しようとした場合など）？
- 不正アクセスが試みられた場合はどうなるか？
チェックアウトフローの例：
- ユーザーがチェックアウト途中でブラウザを閉じた場合：カートは保持され、セッションは再開できる
- 決済が失敗した場合：ユーザーに具体的なエラーが表示され、カートはクリアされず、ユーザーはリトライできる
- チェックアウト中に商品が在庫切れになった場合：決済処理前にユーザーへ通知される
- 決済送信中にネットワークが切断された場合：二重請求は発生せず、ユーザーに適切なエラーが表示される
4. 不変条件（絶対に守るべきルール）
不変条件とは、実装の詳細にかかわらず常に真でなければならないルールです。これらを明示的に記述します。
- 未認証ユーザーが他のユーザーの注文履歴を閲覧できてはならない
- 決済処理は冪等でなければならない（リトライ時に二重請求が発生しないこと）
- カートの合計金額は常に、商品価格の合計から割引を差し引いた金額と等しくなければならない
- 在庫切れ商品は絶対に購入できないようにしなければならない
不変条件は、テスト生成においてPRDの中で最も重要なコンテンツです。TestSpriteは不変条件の違反を重大な障害として扱い、それぞれを検証するための専用テストを生成します。
5. スコープ外
構築しない機能を明示してください。これにより、AIコーディングエージェントが意図しない機能を実装することを防ぎ、まだ存在しないフローをテスト生成が対象とすることを防ぎます。
今回のリリースのスコープ外：ゲストチェックアウト、分割払い、国際配送、サブスクリプション購入。
6. 依存関係と統合ポイント
この機能が連携する外部システムと、その統合契約を列挙してください：
- 決済処理用Stripe API（カード情報収集にStripe.jsを使用）
- 注文確認メール用SendGrid
- 在庫確認用内部インベントリサービス
- セッション検証用Auth0
これにより、AIコーディングエージェントに必要な統合コンテキストが提供され、TestSpriteが各統合ポイントのAPIコントラクトテストを生成するための情報が得られます。
AIネイティブチームのためのPRDテンプレート
得られる成果
Cursorセッションの前にこの構造で作成されたPRDは、3つのメリットをもたらします：
- より質の高いAI生成コード。コーディングエージェントは、もっともらしいパターンで空白を埋めるのではなく、実装すべき具体的な要件を持つことができます。
- 要件ベースのテストカバレッジ。TestSpriteは受け入れ基準、エッジケース、不変条件から直接テストを生成します。すべての受け入れ基準がテストになり、すべての不変条件が検証されます。
- 共有コンテキスト。何か問題が発生したとき、PRDが本来あるべき動作の信頼できる情報源となります。意図した動作が明示的に文書化されていれば、デバッグと修正が迅速になります。
必要な投資は、各コーディングセッション前の20〜30分の構造化された思考時間です。その見返りは、AIコーディングエージェントからの質的に向上したアウトプットと、追加のテスト作成時間を必要としない意味のあるテストカバレッジです。
TestSpriteでPRDを自動テストに変換する →