このPRDプロンプトは、プロダクトマネージャー、起業家、個人開発者のためのものです。頭の中にあるのは「地域の小さな店の記帳と照合を助けるミニプログラム」といった、たった一文のプロダクトアイデアだけ。下のプロンプトをアイデアと一緒にAIに貼り付ければ、背景、ターゲットユーザー、機能一覧、受け入れ基準、対象外まで揃った製品要求仕様書（PRD）が一度で出力されます。開発チームはそれを受け取ってすぐに着手でき、「この機能は結局どう作ればいいのか」と何度も聞き返す必要がなくなります。
そのままコピーできるPRDプロンプト
あなたは経験8年のプロダクトマネージャーです。以下のプロダクトアイデアについてPRD（製品要求仕様書）を作成してください。開発チームはこの文書をもとに直接スケジュールを組み、開発を進めます。
プロダクトアイデア：[プロダクトを一文で説明してください。例：地域の小さな店の記帳と照合を助けるミニプログラム]
以下の構成で出力し、どの節も省略しないでください。
1. 背景と課題：誰のどんな問題を解決するのか、今はどうやってしのいでいるのか。
2. ターゲットユーザー：2〜3種類のユーザーを挙げ、それぞれの状況と悩みを一文で説明する。
3. プロダクト目標：今回何を届けるのかを一文で書き、測定可能な成功基準を2〜3件挙げる。
4. 機能一覧：「必須 / あるべき / なくてもよい」の3段階に分け、機能ごとに説明を一文と受け入れ基準を1件書く。
5. コアフロー：ユーザーが主要タスクを完了するまでの手順を5ステップ以内で書く。
6. 対象外：今回やらないことを3件明記し、開発中のスコープ拡大を防ぐ。
7. 確認事項：私から補足が必要な情報を3件以内で挙げる。答えをでっち上げないこと。
要件：すべての機能に受け入れ基準を付けること。不確かな点は明記し、数字をでっち上げないこと。変える場所は2つ、効果は大きく違う
使うには[プロダクトアイデア]を差し替えるだけですが、アイデアが具体的であるほど仕様書は使えるものになります。「記帳ミニプログラム」よりも「地域の小さな店の記帳と照合を助け、会計士向けに書き出しもできるミニプログラム」のほうがずっと良いです。さらにフィットさせるには、プロダクトアイデアの下に変数を2つ追加します。[対象プラットフォーム：ミニプログラム / Web / アプリ]と[初回リリース時期：例：4週間後]です。AIはプラットフォームに合わせて機能を削り、時期に合わせて優先順位を付けます。
出力が漠然としすぎているときは、こう追及してください。「機能一覧を5件以内に絞り、作らない場合に何を失うかを1件ずつ書いてください。」受け入れ基準が曖昧なときは、こう聞きます。「『快適な体験』を測定可能な数字に変えてください。たとえば起動は2秒以内、といった形で。」アイデアがまだバラバラの思いつきの集まりなら、まず要件整理プロンプトで思いつきを一覧に整理してからPRD作成に戻ってください。順番を逆にしてはいけません。
使う前に知っておきたい3つの境界
このプロンプトが向いているのは初版のPRDです。機能が10件以内、ユーザーの役割が3種類以内のシンプルなプロダクトが対象です。複数端末の同期、複数ロールの権限管理、決済コンプライアンスなどが絡む複雑なシステムでは、AIの出力は下書きとして扱い、構成と境界は人間が再確認してください。AIは数字をでっち上げることもあります。市場規模、ユーザー数、転換率など、出典のない数字は開発者に渡す前に確認するか削除してください。また、実際の営業機密、未公開のプロダクト詳細、ユーザーの個人情報を会話に貼り付けないこと。先に機密情報を取り除いてください。開発者に渡す前に3項目を確認します。すべての機能に受け入れ基準があるか、対象外が3件書かれているか、でっち上げの数字がないか、です。
