DotMD
Mac版をダウンロード

MarkdownのPRDテンプレート：コピーして埋めるだけ。

プロダクト要求仕様書（PRD）は、コードの隣の.mdファイルで持つのがいちばん続けやすい方法です。このテンプレートは短く、番号付きの要件と確認できる受け入れ基準を備え、AIエージェントが実装に使えるように書かれています。

Mac版をダウンロード

macOS 14以降。閲覧は無料で、編集とレビューは1回のお支払いです。

要点

よいPRDは、課題、目標、対象外のことを示し、そのあとに確認できる受け入れ基準付きの番号付き要件を並べます。prd.mdまたはdocs/prd/feature-name.mdとして保存し、下のテンプレートをコピーして、各セクションを平易な文で埋めてください。

# PRD: <Feature name>

## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria

·

テンプレート

新しいファイルにコピーし、山括弧の中をすべて置き換えます。セクションを削除するのは、本当に当てはまらないと確信できるときだけにして、空のままにせず「none」と書きます。そうすれば、読み手は検討済みだと分かります。

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

このように書く理由

AIエージェント向けのPRDも、人向けと役割は同じですが、推測の余地がより少なくなります。人なら廊下で「どういう意味ですか」と聞いてくれますが、エージェントは空白を自分の最善の推測で埋めて、そのまま進みます。

  • 非目標は、スコープの膨張を防ぐいちばん安上がりな備えです。エージェントは、止めない限り「親切な」おまけを足します。
  • 番号付きの要件（R1、R2）があると、計画、テスト、レビューコメントのすべてが同じものを指せます。
  • タスクリストのチェックボックスにした受け入れ基準は、チェックしていけるToDoリストになります。構文はMarkdownのタスクリストをご覧ください。
  • エッジケースは、生成されたコードが最初に失敗する場所です：空のデータ、不正な入力、接続の切断。
  • ロールバックは、リリースする前に、変更をどう元に戻すかを考えさせてくれます。

埋め方

  1. 解決策を書かずに課題を書く

    機能の名前を出さずに課題を説明できないなら、その機能は推測です。誰が影響を受け、今は何が起きているのかを書きます。

  2. 目標はすべて測れるものにする

    「チェックアウトを速く」は願望です。「チェックアウトの中央値を30秒未満に」は目標です。

  3. 要件は振る舞いとして書く

    「ファイルが10MBを超えたら、システムはエラーを表示する」はテストできます。「適切なエラー処理」はテストできません。

  4. 要件ごとに基準を対にする

    Given、when、thenの形を使います。確認方法が書けないなら、その要件はあいまいです。

  5. 未解決の質問で終える

    それぞれに担当者の名前を書きます。エージェントはそれらを自分で決めるのではなく、質問するべきです。

フローや状態には図が役立ちます。ファイル内のMermaidブロックは変更しやすいです。Mermaidフローチャートの書き方をご覧ください。

PRDをAIエージェントに渡す

貼り付けるのではなく、エージェントにファイルを指し示します：「docs/prd/export.mdを読んで、計画を提案して。まだコードは書かないで」。まず計画を頼み、番号付きの要件と照らして確認してから、作らせます。PRD、計画、タスクリストは、たいてい3つの別のファイルです。PRDは何をなぜ、計画はどうやって、タスクはその手順を書きます。

プロジェクト全体のルール（コマンド、スタイル、フォルダ）はPRDに入れず、CLAUDE.mdまたはAGENTS.mdに置きます。そうすればPRDには、この機能に固有のことだけが残ります。

よくある間違い

  • 課題を装った解決策。「ドロップダウンが必要」は課題ではありません。
  • 非目標がない。近くのものがすべて対象になってしまいます。
  • 失敗しようのない要件。どんなテストでも失敗しえないなら、何も言っていないのと同じです。
  • 誰も読み返さないPRD。状況と未解決の質問は、進めながら更新します。
  • 小さな変更に10ページ。1日で終わる機能なら、半ページで足ります。

プロダクトマネージャーは、DotMDでPRDを整形されたドキュメントとして読み、レビューできます。正確な箇所へのコメントもつけられます。閲覧は無料です。編集とレビューについては料金をご覧ください。

MarkdownのPRDテンプレートに関するよくある質問

PRDテンプレートには何を入れますか？

課題、目標、非目標、ユーザーのシナリオ、番号付きの要件、受け入れ基準、エッジケース、データとインターフェース、成功指標、リリースとロールバック、未解決の質問です。

なぜPRDをMarkdownで書くのですか？

Markdownのファイルはコードの隣にあり、Gitで読みやすい履歴が残り、AIエージェントが読みやすく、ほかのファイルと同じようにレビューや変更ができます。

ファイル名はどうすればよいですか？

プロダクトが1つならprd.md、複数あるならdocs/prd/feature-name.mdです。1ファイルにつき1機能にします。

PRDと仕様書はどう違いますか？

PRDは、ユーザーの視点で何をなぜ作るかを書きます。仕様書や計画は、どう作るかを書きます。それぞれを単独でレビューできるよう、分けておきます。

その他の質問

ほかの記事

AI仕様書レビューのチェックリスト CLAUDE.mdとAGENTS.mdの違い Markdownのタスクリスト Mermaidフローチャート

ガイド

スペック駆動開発 コメント Markdownチートシート