AIでプロダクト要件定義書（PRD）を書く方法（無料テンプレート付き）

プロダクト要件定義書（PRD）は、何を作るのか、誰のためのものか、何ができなければならないか、そしてそれがうまく動いていることをどう確認するかを、平易な言葉で短くまとめた文書です。AIを使うと、この文書をずっと速く書けます。ラフなメモを渡せば、構造化されたセクション、ユーザーストーリー、エッジケースにまとめてくれます。あなたの役割は、AIには決められない判断、つまり目的、スコープ、そして何を含めないかを示し、AIが追加した内容をチェックすることです。

このガイドでは、PRDに何を書くべきか、どのAIアシスタントでも使える下書きの手順、各セクションのプロンプト、そしてコピーして使える穴埋め式テンプレートを紹介します。

PRDの役割（とその範囲）

PRDは次の4つの質問に答えます。

1. なぜこれを作るのか？どんな問題を、誰のために解決するのか？
2. 最初のバージョンで何ができなければならないのか？
3. 今回は何をやらないのか？
4. どうすればうまくいったと判断できるのか？

PRDは技術設計書ではありません。どのデータベースやフレームワークを使うかは書きません。それが必要なら、別の技術仕様書に書きます。また、マーケティングの企画書や事業計画書でもありません。PRDをプロダクトの振る舞いに絞ることで、読むすべての人にとって役立つ文書になります。デザイナー、開発者、内容に同意する関係者、あるいはPRDをコードに変えるAIアプリビルダーにとって、使いやすくなるのです。

誰に必要か

• 一人で起業している人。スコープが膨らむ前に食い止めたい場合に役立ちます。
• 小規模なチーム。「何に合意したか」をひとつの場所にまとめておきたい場合に役立ちます。
• フリーランスや制作会社に依頼する人。明確なPRDがあれば、見積もりも正確になります。開発者に依頼する、またはAIで作るも参考にしてください。
• AIで作る人。PRDのユーザーストーリーやデータ一覧は、整理されていない要望リストより良いプロンプトになります。

AIが得意なこと、苦手なこと

もっとも多い失敗は、上の表の下から2番目の行が逆になったときに起きます。AIは、あなたのユーザーについてもっともらしい推測で、自信を持ってすき間を埋めてしまいます。AIが書いたユーザー、市場規模、行動に関する内容は、事実ではなく確認すべき問いとして扱ってください。

ステップ1：知っていることを書き出す

プロンプトを送る前に、ラフなメモを書いておきましょう。箇条書きで構いません。次の内容を含めてください。

• 問題を、ユーザーの視点から1〜2文で。
• 誰がその問題を抱えているのか。「中小企業」ではなく、「顧問先が10〜40社のフリーランス経理担当者」のように具体的に。
• 今はそれをどうやって解決しているか（スプレッドシート、メール、使いにくいツールなど）。
• 最初のバージョンが成功したと言える、たったひとつの結果。
• すでに「やらない」と決めていること。
• 厳しい制約：期限、予算、スマートフォンで動く必要があるか、すでに使っているツールと連携する必要があるか。

その問題を抱えている人と話したことがなければ、まずそれをしてください。アプリのアイデアを検証する方法に、実践的なやり方があります。推測の上に作ったPRDは、見た目の整ったただの推測にすぎません。

ステップ2：AIに最初の下書きを頼む

メモを貼り付け、決まった構成で下書きを頼みましょう。うまくいくプロンプトの例です。

以下は、あるプロダクトについてのメモです。これを次のセクションだけを使って、プロダクト要件定義書にまとめてください：概要、課題、ユーザー、目標と成功指標、スコープ（対象に含む／含まない）、受け入れ基準付きのユーザーストーリー、データ、権限、エッジケース、未解決の質問。2ページ以内に収めてください。ユーザーや市場についての事実を勝手に作らないでください。メモに書かれていない部分は、「未解決の質問」に質問として書いてください。

最後の指示が重要です。不明な点を埋めずに「未解決の質問」に回すよう指示すると、ずっと正直な下書きになります。

ステップ3：各セクションを絞り込む

下書きをセクションごとに見直しましょう。次のフォローアッププロンプトが役立ちます。

課題とユーザー

課題の説明を、ユーザーの視点から1〜2文で書き直してください。解決策の言葉は使わないでください。

課題の説明に自社のプロダクトが出てくるなら、それは課題ではなく解決策を書いています。

目標と成功指標

少人数のユーザーで最初の1か月に測定できる、最初のバージョンの成功指標を3つ提案してください。それぞれ、どう測定するかも書いてください。

ひとつかふたつ選びましょう。「20人の経理担当者が1か月間、毎週使う」は測定できます。「生産性を向上させる」は測定できません。

スコープ

このPRDに書かれた内容のうち、中核の流れを壊さずに後のバージョンへ回せるものをすべて挙げてください。

AIツールは機能を追加しがちです。このプロンプトは、その逆をさせます。容赦なく絞りましょう。多くの最初のバージョンのPRDは大きすぎます。MVPとはでは、小さな最初のバージョンのほうがなぜ多くのことを教えてくれるのかを説明しています。

ユーザーストーリーと受け入れ基準

各要件を、ユーザーストーリー（「〔ユーザー〕として、〔行動〕をしたい。それによって〔結果〕を得たい」）の形で書き、Given／When／Then の形式で2〜4個の受け入れ基準を付けてください。

受け入れ基準は、後でテストするためのチェックリストです。「予約済みの枠があるとき、別の顧客がカレンダーを見ても、その枠は表示されない」はテストできます。「予約機能がうまく動く」はテストできません。

エッジケースと権限

各ユーザーストーリーについて、データが空の場合、無効な入力があった場合、ネットワークが遅い・失敗した場合、アクセス権のないユーザーがアクセスした場合に何が起こるかを挙げてください。

ここは、AIが力を発揮する場面です。人が見落としがちな空の状態や権限の抜けを、素早く見つけられます。

ステップ4：懐疑的な目でレビューする

全体をもう一度読み直して、次の点を確認してください。

• ユーザーに関するすべての主張は、AIではなく、あなた自身や調査から来ているか。
• **スコープの「対象外」**が、少なくとも「対象」と同じくらいの長さがあるか。
• 各ユーザーストーリーに、あなたに聞かなくてもテストできる受け入れ基準があるか。
• データのセクションに、アプリが保存するすべての種類のレコードと、それを見られる人が挙がっているか。
• 未解決の質問に、担当者と期限が決まっているか。
• 本当の制約ではない技術的な内容が紛れ込んでいないか（「オフラインで動く必要がある」は要件ですが、「Redisを使う」は要件ではありません）。

その後、そのプロダクトを使う、または作る人ひとりに見せて、わかりにくい点を聞いてください。その人の質問こそが、抜けている部分です。

穴埋め式PRDテンプレート

以下をドキュメントにコピーし、角括弧の部分を置き換えてください。本当に当てはまらないセクションは削除してかまいません。

プロダクト名： 〔名前〕 担当者： 〔判断に責任を持つ人〕 ステータス： 〔下書き／レビュー中／合意済み〕 — 最終更新日： 〔日付〕

1. 概要

〔2〜3文で、これが何か、誰のためか、主な成果は何かを書く。〕

2. 課題

〔ユーザーの視点から見た課題。今どうしているか、そしてそれがなぜ困るのか。〕

3. ユーザー

4. 目標と成功指標

• 目標： 〔最初のバージョンで達成すべき結果〕
• 指標： 〔測定方法と目標値〕
• 対象外： 〔人が想定しがちだが、このバージョンでは目指さないこと〕

5. スコープ

最初のバージョンに含む：

• 〔機能〕
• 〔機能〕

最初のバージョンに含まない：

• 〔機能。後回しにできる理由〕
• 〔機能。後回しにできる理由〕

6. ユーザーストーリー

ストーリー1： 〔ユーザー〕として、〔行動〕をしたい。それによって〔結果〕を得たい。

• Given〔前提の状況〕、When〔行動〕、Then〔結果〕。
• Given〔前提の状況〕、When〔行動〕、Then〔結果〕。

ストーリー2： 〔ユーザー〕として、〔行動〕をしたい。それによって〔結果〕を得たい。

• Given〔前提の状況〕、When〔行動〕、Then〔結果〕。

7. データ

8. 権限

〔誰がログインできるか、どんな役割があるか、それぞれの役割が何を見られて何を変更できるか。〕

9. エッジケース

• 〔空の状態：データがまだないとき何が表示されるか〕
• 〔無効な入力：間違ったメールアドレスや未入力の項目があったとき何が起こるか〕
• 〔アクセス：見てはいけないページを開こうとしたとき何が起こるか〕

10. 連携と制約

〔決済、メール、既存のツール、期限、予算、対応すべき端末。〕

11. 未解決の質問

PRDからプロンプトへ

良いPRDは、ほぼそのままAIアプリビルダーのプロンプトに変換できます。

• 概要、ユーザー、データの表は、最初のプロンプトになります。
• 各ユーザーストーリーは、フォローアップのプロンプトひとつになります。
• 各受け入れ基準は、プレビューで確認するべき項目になります。
• 「最初のバージョンに含まない」一覧は、今はまだ頼まないと決めた機能です。

PRD全体を貼り付けて何もかも頼むより、ストーリーを1つずつ作り、先へ進む前に受け入れ基準を確認するほうがずっと確実です。プロンプトの書き方について詳しくは、AIアプリビルダー向けのプロンプトの書き方をご覧ください。

よくある間違い

• 解決策を課題として書いてしまう。 「ユーザーはダッシュボードが必要だ」は解決策です。「オーナーは、一件ずつ開かないと、どの請求書が期限切れかわからない」は課題です。
• 「対象外」のセクションがない。 これがないと、話し合うたびにスコープが蒸し返されます。
• AIにユーザーを作らせてしまう。 AIが作ったペルソナは本物らしく見えますが、実在しません。
• 数えられない指標。 数える方法がないなら、それは指標ではありません。
• 更新しない。 作っているものと合わなくなったPRDは、ないよりも悪いものです。「最終更新日」を入れておき、判断が変わったら書き換えてください。

MythexでPRDを使う

Mythexで作るなら、PRDをそのままチャットに貼り付けられます。PRDには**Plan（計画）**モードから始めるのがおすすめです。エージェントはPRDを読み、アプローチと手順のチェックリストを提案します。それをプランタブで確認し、**Build（作成）**を押したときにはじめてファイルの変更を始めます。また、対象ユーザー、ブランド、ルールなど、常に適用すべき内容はプロジェクトのナレッジとして保存できるので、毎回のチャットで繰り返す必要がありません。Build、Plan、Askの各モードについては、チャットのドキュメントをご覧ください。また、完成したPRDを書く前に、最初のバージョンがどんな形になるかを見るには、テンプレートが手軽です。

よくある質問