PRD（Product Requirements Document／製品要求仕様書）は、何を作るか、そしてなぜかを定める文書です。課題、スコープ、要求、その裏の決定をまとめ、チームと関係者が同じ絵を持てるようにします。弱点はその後にあります——2〜3スプリントで PRD は現実とずれ、陳腐化（ドリフト）する。ここでは構成とテンプレート、そしてドリフトを防ぐ方法を解説します。
このテンプレートはそのまま使えます。最も価値があり、最も早く古くなるのが4番——決定です。PRD は ロードマップ とその下の決定の、見える先端にすぎません。
PRD は承認された日には正しい。その後、会議が前提を変え、エッジケースが決定を覆す——なのに文書は止まったまま。12ページの文書を手で追従させる人はいません。数週間後、AI エージェントはもう成立しない仕様の上に作り始めます。
要求と決定が、7ページ目の一行ではなく参照できるカードに。理由と担当者を持ち、ID で辿れます。
後の決定が前を覆すと、依存カード——つまり該当する PRD 部分——が自動で stale に。文書が3週間も黙って嘘をつきません。
Claude Code や Cursor が MCP 経由で PRD を読みます——最新か、明示的に stale か。状態の分からない静的文書ではありません。
PRD は承認日には正しい。問題は、その後の6週間、誰も追従させないことだ。要求をカードにすれば、PRD 自身が「古くなった」と知らせる。それが Draftlize。
PRD は「何を・なぜ」を定める上位の文書、仕様書は「どう作るか」に踏み込みます。PRD の決定が変われば仕様も変わるべきで、その連動が肝心です。
多くは PM が、エンジニアやデザインと協働して書きます。大事なのは、中の決定が後から辿れて、理由が残ることです。
課題・スコープ・要求・決定が伝われば十分です。長さより、覆されたときに気づける仕組みが重要です。
要求と決定を、固定した段落ではなくリンクしたカードにします。決定が変わると Draftlize が依存箇所を自動で stale 表示します。詳しくは 意思決定ログ。
PRD をリンクしたカードで書けば、各要求が参照可能に。決定が変われば該当箇所を自動で stale——PRD ドリフトはもう終わりです。
$5 無料で始める