AI PRDテンプレート：各セクションと、セクションごとのプロンプト、そして記入例

テンプレートが果たすべき役割

プロダクト要求仕様書には2種類の読者がいます。作る側は、同僚か外注先かコーディングエージェントかを問わず、何を作り、どこで止まるかを知る必要があります。確認する側は、出荷されたものが合意した内容と一致しているかを確かめる必要があります。すべての要件が検証可能な1つの文で書かれ、すべての非目標が明記されていれば、テンプレートはその両方に応えられます。

セクションは、それぞれが異なる種類の問いに答えるように選んであります。

全体を2ページ以内に収めてください。読まれないPRDは、存在しないPRDと同じです。

MarkdownのPRDテンプレート

このブロックをページ、リポジトリ内のファイル、またはエディタにコピーしてください。角括弧の中はすべて置き換え、セクションを書き終えたら案内の行は削除します。

PRD: [機能またはプロダクト名]

責任者: [名前]
ステータス: [下書き / レビュー中 / 合意済み]
最終更新: [YYYY-MM-DD]
概要: [一文で：何か、誰のためか、何を置き換えるか]

**1. 課題**
現在、[誰]は[何かを成し遂げる]必要があるとき、[どんな回避策]をとっている。
それには[実際に観察した時間・費用・リスク]がかかっている。
根拠: [インタビュー、サポートチケット、商談、自分たちの利用経験。件数も書く]

**2. 目標**
G1. [指標]を[現在値]から[目標値]へ、[期日]までに。
G2. [指標]を[現在値]から[目標値]へ、[期日]までに。
測定方法: [ダッシュボード、クエリ、レポート]

**3. ユーザーストーリー**
US-1. [役割]として、[状況]のとき、[行動]したい。なぜなら[結果]を得たいから。
US-2. [役割]として、[状況]のとき、[行動]したい。なぜなら[結果]を得たいから。
US-3. [役割]として、[状況]のとき、[行動]したい。なぜなら[結果]を得たいから。

**4. 受け入れ基準**
各ストーリーについて、レビュアーが合否を判定できるチェックを1つ以上。
AC-1a. [状態]のとき、[操作]すると、[観察できる結果]になる。
AC-1b. [状態]のとき、[操作]すると、[観察できる結果]になる。
AC-2a. [状態]のとき、[操作]すると、[観察できる結果]になる。
優先度: 各ストーリーに [Must / Should / Could]。

**5. 非目標**
このリリースでは[こと]をやらない。理由は[理由]。
このリリースでは[こと]をやらない。理由は[理由]。

**6. リスクと未解決の問い**
R1. [リスク]。発生確率 [低/中/高]。発生したら: [対応]。
R2. [リスク]。発生確率 [低/中/高]。発生したら: [対応]。
未解決: [着手前に答えが必要な問いと、誰が答えるか]

重みのほとんどを支えているのは2つの決まりごとです。各ストーリーと各基準には安定したキー（US-1、AC-1a）があり、コミットメッセージやイシュー、監査から参照できること。そして各基準が「〜のとき・〜すると・〜になる」の形式で書かれ、コードになる前にテストとして成立していることです。

セクションごとのプロンプト

「PRDを書いて」という1回のプロンプトからは、根拠をでっち上げ、目標が一般論に終始する、自信だけはある文書が返ってきます。実際に手元にある事実を添えてセクションごとに頼めば、モデルが作り話をする余地は減ります。以下は私たちが使っているプロンプトです。角括弧の部分は送信前に埋めてください。

1. 課題。 「顧客との会話[N]件とサポートチケット[N]件のメモです：[貼り付け]。課題セクションを120字以内で、『現在、[誰]は[タスク]が必要なとき[回避策]をとっている。それには[コスト]がかかっている』の形式で書いてください。コストはメモに出てくるものだけを使うこと。最後に、出典の件数を数えた根拠の行を付けてください。」
2. 目標。 「課題は次のとおりです：[貼り付け]。現在の数値は：[指標、値]。『G#. [指標]を[現在値]から[目標値]へ、[期日]までに』の形式で目標を3つ提案してください。現在値を推測で埋めないこと。渡していない値が必要ならTBDと書いてください。」
3. ユーザーストーリー。 「課題と目標：[貼り付け]。『[役割]として、[状況]のとき、[行動]したい。なぜなら[結果]を得たいから』の形式でユーザーストーリーを最大5つ書いてください。1ストーリーにつき役割は1つ。G1にどれだけ直接貢献するかの順に並べてください。」
4. 受け入れ基準。 「以下の各ストーリーについて、『[状態]のとき、[操作]すると、[観察できる結果]になる』の形式で受け入れ基準を2〜3個書いてください。いずれもコードを見られない人が確認できるものにすること。検証可能な基準が書けないストーリーがあれば指摘してください。」ここで弱いストーリーが正体を現します。モデルがテストを書けないなら、あなたにも書けません。
5. 非目標。 「これらのストーリーを前提に、普通のエンジニアなら含まれていると思い込みそうで、実際には含まれないことを6つ挙げてください。それぞれ『このリリースでは[こと]をやらない。理由は[理由]』の形式で。」そのあと、チームが本当に手を出しそうなものだけに絞ります。
6. リスク。 「この機能がリリース後に失敗する最も可能性の高い経路を、技術面・事業面を問わず4つ挙げてください。それぞれについて発生確率と、私たちがとる対応を書くこと。推測で書いた箇所には印を付けてください。」

1セクション頼み、読み、直し、直した版を次のプロンプトに貼る。この「直した版の連鎖」こそが本当の安全装置です。モデルは、あなたがすでに承認した内容しか目にしません。

記入例：2人のコンサルティング会社の予約リンク

小さくて現実的な形の機能について、テンプレートを埋めた例です。数値は例示用です。

PRD: 公開予約リンク

責任者: Dana
ステータス: 合意済み
最終更新: 2026-10-28
概要: 見込み客が共有カレンダーから30分の枠を選べる公開ページ。
現在やっているメールの往復を置き換える。

**1. 課題**
現在、通話を希望する見込み客はメールで連絡してきて、時間を決めるまでに
平均4通のやり取りが発生している。前四半期の22件の通話で創業者の時間が
約3時間使われ、2人の見込み客は時間が決まる前に連絡が途絶えた。
根拠: 過去90日の送信メール検索。22スレッドを集計。

**2. 目標**
G1. 予約1件あたりのメッセージ数を4から1へ、12月15日までに。
G2. 月間の予約通話数を7から10へ、1月31日までに。
測定方法: 共有受信箱で「日程調整」タグの付いたスレッド数。
ワークスペースの予約テーブル。

**3. ユーザーストーリー**
US-1. 見込み客として、リンクを開いたとき、自分のタイムゾーンで枠を
見たい。なぜなら間違えて午前3時に予約したくないから。
US-2. 創業者として、枠が予約されたとき、見込み客の情報付きで
カレンダーに入ってほしい。なぜなら記憶頼みで準備したくないから。
US-3. 創業者として、休暇中は、枠を一切出したくない。なぜなら不在の
週に誰にも予約されたくないから。

**4. 受け入れ基準**
AC-1a. UTC+9の訪問者がページを開くと、時刻はUTC+9で表示され、
タイムゾーン名が見える。
AC-1b. すでに予約済みの枠がある状態でページを開くと、その枠は
表示されない。
AC-2a. 予約が完了した状態でカレンダーを開くと、見込み客の名前・
メール・メモ付きの予定が60秒以内に存在する。
AC-3a. 承認済みの休暇申請がある日について、ページを開くと、
その日の枠は一切表示されない。
優先度: US-1 Must、US-2 Must、US-3 Should。

**5. 非目標**
予約時の決済はやらない。初回通話は無料だから。
グループイベントはやらない。頼まれたことが一度もないから。
ブランドのカスタマイズはやらない。私たち2人がブランドそのものだから。

**6. リスクと未解決の問い**
R1. カレンダー同期の遅延による二重予約。発生確率 中。発生したら:
日程変更リンク付きの確認メールを送り、毎日確認する。
R2. スパム予約。発生確率 低。発生したら: 枠を押さえる前にメール
確認を必須にする。
未解決: 15分の枠も用意するか？ Danaが金曜までに決める。

この例に含まれていないものに注目してください。「心地よい体験」もアーキテクチャもスクリーンショットもありません。AC-3aはレビュアーが2分で実行できるテストです。非目標は、外注先が最も聞いてきそうな3点です。

どこに保管し、次に何をするか

チャット画面の中のPRDは、タブを閉じた瞬間に失われます。「下書き」から「合意済み」の間に何が変わったかを見られるバージョン履歴のある置き場所と、ストーリーを作業に変える手段が必要です。

Atrixでは、PRDテンプレートは上のMarkdownと同じセクションを持つホスト型のページで、さらに各行にキー、検証可能な1文、受け入れ条件、MoSCoW優先度を持つ要件テーブルが付いています。エージェントのDevelop実行は逆方向にも働きます。短いブリーフを渡すと「要件を下書きする」ステップが課題、対象ユーザー、スコープ、番号付き要件、非目標をページに書き出し、続くステップがアーキテクチャと計画済みイシューを提案して、バックログに受け入れられます。制約も知っておいてください。1回の実行でプランの月間実行回数（Builderは100回、Studioは500回）を1つ消費し、無料プランはなく、エージェントはブリーフをもとに書くので、薄いブリーフからは薄いPRDしか出てきません。AIエージェントのページに各実行が生成するものの一覧があります。

PRDを人ではなくコーディングエージェントに読ませたい場合は、姉妹記事のClaude CodeやCursorが実装できるPRDの書き方で追加の制約を扱っています。

テンプレートが防ぐよう設計されたよくある間違い

• 現在値のない目標。 「コンバージョンを増やす」は願望です。「3月までに2.1%から3%へ」が目標です。現在値が分からなければTBDと書き、着手前に調べてください。
• 機能を言い換えただけのストーリー。 「ユーザーとして、ダッシュボードが欲しい」には状況も結果もありません。何を成し遂げようとしているのかを問いましょう。
• コードを見ないと確認できない基準。 「APIが200を返す」は実装の詳細です。「予約が完了した状態でカレンダーを開くと、予定が存在する」がユーザーの見るものです。
• 空の非目標。 このセクションが空なら、スコープは決まっていません。作る人が決めることになります。
• 技術リスクしか挙げないリスク欄。 「誰も使わない」が最も多い失敗で、リストに入れるべきものです。

FAQ

AI PRDテンプレートとは何ですか？

あなたが提供した事実からAIアシスタントが各セクションを下書きでき、レビュアーがその結果を確認できるように書かれたプロダクト要求仕様書のテンプレートです。上のテンプレートには課題、目標、ユーザーストーリー、受け入れ基準、非目標、リスクの6セクションがあり、それぞれにプロンプトが付いています。

AIプロダクト向けのPRDは普通のPRDと違いますか？

セクションは同じです。変わるのは受け入れ基準です。AI機能には、モデルが間違う・遅い・利用できない場合の基準と、「正しく動く」ではなく明示された精度のしきい値が必要です。初回リリースで対応しない振る舞いは非目標に加えてください。

PRDはどのくらいの長さにすべきですか？

機能なら2ページ以内、新しいプロダクトなら3〜4ページです。あるセクションがそれ以上に伸びるなら、たいていは設計書かバックログがPRDの中に紛れ込んでいます。外に出してリンクしてください。

ChatGPTやClaudeにPRD全体を書かせてもいいですか？

可能ですし、読み心地のよい結果が返ってきます。それこそが問題です。1回のプロンプトで書いたPRDは、根拠も現在値も持っていないので、でっち上げます。自分の数字を添えてセクションごとに頼み、次へ進む前に1つずつ直すことで、文書は正直なままでいられます。

GitHub Spec Kitとの違いは何ですか？

Spec Kitは、エージェントのチャット内のコマンドで仕様を計画、タスク、コードへと変換していくコーディングエージェント向けのツールキットです。このテンプレートは仕様そのもので、そのプロセスが始まる前に人が合意するために書かれています。両者は組み合わせて使えます。PRDを書き、それをspecifyステップに渡してください。

PRDが合意されたあと、受け入れ基準はどこへ行きますか？

それぞれがイシューの完了定義になります。Atrixでは、PRDページの要件テーブルが後の要件監査で照合される対象です。監査は凍結したベースラインと計画内容を比較するもので、ソースコードを見るものではありません。用語集のPRDの項目で用語を説明しています。

次のステップ

上のMarkdownをコピーするか、ホスト型のPRDテンプレートを開いてチームで埋めてください。ブリーフから始めたい場合は、7日間のトライアル中にAtrixのエージェントが最初の版をページに下書きします。

出典

ChatPRDの料金とGitHub Spec Kit。いずれも2026年10月に確認。