AIを使ったPRD（プロダクト要求仕様書）の書き方：無料テンプレート付き
AIでPRD（プロダクト要求仕様書）を書く実践的な方法を解説します。モデルに何を渡し、何を自分で決めるべきか、そしてすべての要件を検証可能にするためのポイントをまとめました。
目次
PRD（プロダクト要求仕様書）の失敗パターンは、たいてい次の2つのどちらかです。誰も書かず、スコープがSlackのスレッドと3人の頭の中にしか存在しないケース。あるいは、誰かが長大なドキュメントを書いたものの、誰も読まず、誰も検証できないケースです。AIを使えば、1つ目の失敗は簡単に解消できます。モデルはPRDらしい体裁のドキュメントを数秒で書き上げてくれるからです。一方で、2つ目の失敗はずっと起こりやすくなります。流暢で自信に満ちたドキュメントは、合意されたドキュメントと同じではないからです。
このガイドでは、落とし穴にはまらずにAIの便利な部分だけを活用する方法を紹介します。PRDの目的、モデルに渡すべきもの、自分の手元に残すべきもの、そして誰かが実際にテストできる要件に仕上げる方法を順に解説します。ツールを使わずに構成だけ知りたい方は、コピーまたはMarkdownでダウンロードできる無料のPRDテンプレートもご利用ください。
PRDは本来何のためにあるのか
PRDには2種類の読み手がいます。その両方を意識して書く価値があります。
1人目は、実際にそれを作る人です。どんな課題を解決するのか、誰のためのものか、最初のリリースに何を含め、あえて何を含めないのかを知る必要があります。毎日午後になるたびに質問しに来なければならないようなら、そのドキュメントは役割を果たしていません。
2人目は、完成後にそれを検証する人です。あなた自身かもしれませんし、共同創業者、レビュアー、あるいはローンチ前の監査担当者かもしれません。その人は、ドキュメントを1行ずつ確認して「はい、これは完了しています」「いいえ、完了していません」と判断できなければなりません。それが可能になるのは、稼働中のプロダクトについて真か偽かを判定できる文として要件が書かれている場合だけです。
多くのPRDテンプレートは1人目の読み手に向けて作られています。2人目の読み手に応えるものはごくわずかです。だからこそ、多くのプロダクトが「合意したもの」ではなく「作ったもの」をリリースしてしまうのです。
押さえるべきセクション
最初のリリース向けの実用的なPRDは、おおよそ10個の短いセクションで構成されます。
- 概要。 名称、オーナー、ステータス、1行のサマリー。それが何で、誰のためのものかを2行で説明できないなら、ほかの部分を書く前にもう少し考えましょう。
- 課題。 ユーザーが実際に直面している課題、現状はどう対処しているか、そしてなぜそれがわかるのか。「クリニックのマネージャー6人へのインタビュー」は根拠になります。「みんな嫌がっている」は根拠になりません。
- ターゲットユーザー。 主要なユーザー1人、その人が新しい手段を探し始めるきっかけ、そして対象外となるユーザー。
- ジョブ（Jobs to be done）。 ユーザー自身の言葉で3〜5個。「こういうときに、これをしたい。そうすれば、この成果が得られるから」という形で書きます。
- MVPスコープ。 最初のリリースで何ができるかを、実際に動いているところを確認できる粒度で書きます。
- 要件。 番号付きで検証可能な文。受け入れ基準と優先度を添えます。
- 成功指標。 何を、どこで測定し、目標値はいくつか。まだ目標値がない場合は空欄にしておきます。
- 非ゴール。 このリリースであえてやらないこと。
- 未解決の課題。 それぞれに担当者と期日を設定します。
- 承認。 誰が、いつ合意したか。以降の変更をどう提案するか。
6番目のセクションがすべてを左右します。そこで、次の見出しで詳しく取り上げます。
検証可能な要件を書く
要件とは、完成したプロダクトについて真か偽かを判定できる1つの文です。「認証」はトピックにすぎません。「ユーザーはメールでパスワードを再設定できる」が要件です。
各要件には次の4つを持たせます。
- キー：REQ-001 のような識別子です。キーは恒久的なものです。タスクやコミット、監査から参照されるため、番号を振り直したり再利用したりしてはいけません。
- 受け入れ基準：稼働中のシステムでどのように確認するかを記述します。「再設定をリクエストし、1分以内にメールを受け取り、新しいパスワードを設定し、そのパスワードでサインインする」といった具合です。これが書けないなら、その要件はまだ完成していません。
- 優先度：小規模なチームならMoSCoW法で十分です。Must（必須）、Should（推奨）、Could（可能なら）、Won't（今回は対象外）の4段階です。5段階評価だと「3か4か」という議論が起きがちですが、本当に重要な判断は「最初のリリースをそれなしで出せるかどうか」だけです。
- 種類：機能要件（振る舞い）、非機能要件（速度、稼働率、アクセシビリティ）、または制約（法規制、プラットフォーム、予算）のいずれか。
リストを誠実に保つためのルールは2つです。1行につき1つのコミットメント。1つの文に2つ含まれているなら分割します。そして、受け入れ基準のない要件は、黙って受け入れるのではなく「未完成」とマークします。
AIが役立つところ、役立たないところ
うまくいく役割分担は次のとおりです。
モデルに渡すのはコンテキストであり、意思決定ではありません。 実際にわかっていることを貼り付けましょう。自分の言葉で書いた課題、顧客との会話のメモ、前提となる制約、すでに除外したこと。1行のプロンプトから下書きさせると、モデルはあらゆる隙間をもっともらしい内容で埋めてしまいます。ここでは「もっともらしさ」こそが敵です。合意済みの内容のように読めてしまうからです。
構成と最初の下書きは任せましょう。 雑多なメモを上記の10セクションに整理したり、抜けている非ゴールに気づいたり、「システムは高速であるべき」を測定可能な表現に書き直したりするのは、モデルの得意分野です。退屈な部分を素早くこなしてくれます。
スコープの判断は人が行います。 最初のリリースに何を含め、何を外し、「完了」とは何を意味するのか。これらはビジネス上の意思決定です。モデルは、妥当そうだから、あるいは一般的だからという理由で、平気で要件を作り出します。それこそが誰も合意していないスコープであり、数週間後に誰も頼んでいない作業として表面化しがちです。
数値を作らせてはいけません。 目標値、価格、日付がわからないなら空欄にしておきましょう。PRDに書かれた架空の成功指標は、コミットメントとして扱われてしまいます。
抽出結果は、元の文章と照らし合わせて確認します。 文章形式のドキュメントをモデルで要件表に変換する場合は、各要件の出典となった文を引用させましょう。そうすれば、ドキュメント全体を読み返さなくても40行を確認でき、出典のない行はすべて創作だと判断できます。
今日から実践できるワークフロー
汎用のAIアシスタントを使って手作業で進める場合は、次の手順がおすすめです。
- PRDテンプレートをエディタにコピーします。
- 課題とターゲットユーザーのセクションは自分で書きます。短いうえに、モデルが最も苦手とする部分です。誰と話したかを知っているのはあなただけだからです。
- メモを貼り付け、メモに書かれている内容だけを使って、ジョブ、MVPスコープ、非ゴールの下書きを依頼します。
- キー、要件文、受け入れ基準、優先度、種類の列を持つ表として要件を提案させ、それぞれの出典となる文を引用させます。
- 出典のないものは削除します。欠けている受け入れ基準を補います。優先度は自分で決めます。
- 承認を得て、そのバージョンを凍結します。以降の変更は、黙って編集するのではなく、提案して記録します。
Atrix AIで進める場合
Atrix AIは、同じワークフローをワークスペースの中で、ガードレール付きで実行します。
Develop モードでは、エージェントがプロジェクトにすでにある情報を読み込みます。サマリー、ピッチ、ターゲット顧客（プロジェクトに昇格させたアイデアのメモを含む）、そしてプロジェクト内のドキュメントです。そのうえで、課題、ターゲットユーザー、ジョブ、MVPスコープ、成功指標、非ゴールを含むPRDを、プロジェクト内のドキュメントとして作成します。もう一度依頼すると、新しいコピーを作るのではなく、以前のテキストをバージョンとして残したうえで同じドキュメントを更新します。
さらにAtrixは、PRDから要件を抽出し、受け入れ基準、MoSCoWの優先度、種類を備えたキー付きの行として登録できます。各行には出典となった文が引用されます。引用がドキュメント内に見つからない行は破棄されます。それ以外はすべて「提案」として登録され、人が承認するまでは有効になりません。受け入れ基準のない要件は（Won't を除き）フラグが立てられ、すべての要件に受け入れ基準がそろい、承認待ちのものがなくなるまで、要件を凍結することはできません。
承認済みの要件はバックログのイシューに分解でき、各イシューには対応する要件キーが記載されます。これにより、プロジェクト管理が合意内容と結びついた状態を保てます。コーディングエージェントに開発を引き継ぐ際は、ハンドオーバーバンドルにドキュメントと要件キーが含まれ、コミットでキーを参照するよう求めます。
これが最後のステップを可能にします。承認済みの要件をベースラインとして凍結すると、要件監査で要件ごとに、作業が存在するか、進行中か、完了しているかを確認でき、承認後に変更または削除された要件もわかります。レポートはモデルの意見ではなく、あなたの記録から算出されます。コードを読むわけではありません。合意した各要件に対して記録された作業が完了しているかどうかを示すものです。
要件の抽出とイシューへの分解は、それぞれ1回のAI実行を使います。そのため、無料プランの月5回の実行で、最初のPRDには十分対応できます。
PRDを完成とする前のチェックリスト
- チーム外の人が、あなたに質問せずに最初のリリースを作れるか？
- すべてのMust要件に受け入れ基準があるか？
- すべての要件が、真か偽かを判定できる1つの文になっているか？
- 非ゴールが書き出されているか？
- すべての未解決の課題に担当者と期日があるか？
- 誰かが承認し、そのバージョンが保存されているか？
6つすべてに「はい」と答えられるなら、そのPRDは2種類の読み手の両方に応えられています。無料テンプレートから始めるか、エージェントに下書きを任せて、あなたは意思決定に時間を使いましょう。