PRD、スペック、RFC：3つの文書、3つの読者、そして最初に書くべきもの

3つの文書を並べて比べる

いちばん大事なのは最初の行と最後の行です。各文書は1つの問いに答え、それぞれに典型的な失敗の仕方があります。

PRDは何のためにあるか

プロダクト要件定義書は、誰かがエディタを開く前に、プロダクトに関わる全員が課題と境界について合意するために存在します。用語集のPRDの項に全体の構成がありますが、本当に価値のある部分は次の通りです。

• 課題を1段落で。誰が抱えていて、それをどう知ったか。
• ゴールと非ゴール。 有用なのは非ゴールの方です。「v1ではオフライン編集を対応しない」の一文が、1か月分の議論を防ぎます。
• 番号付きの要件。 変わらない識別子（REQ-007）、優先度、テスターに渡せる受け入れ基準を添えます。
• 未解決の質問。 まだ開いているものだけを、日付付きで。

PRDはクライアントが承認する文書であり、後に要件監査が実装を照合する対象です。それが機能するには、変わらない識別子と、承認時点で凍結したコピーが要ります。毎週その場で書き換えられるPRDは監査できません。何が合意されたのか、誰にも言えないからです。

PRDでないもの：画面の一覧、データベースのスキーマ、技術設計。「これをJSONB列に保存する」と書いた瞬間、それは帽子を取り違えたスペックになっています。

ゼロから書くなら、PRDテンプレートにこの順番でセクションが用意されています。以前の記事AIでPRDを書く方法では埋め方を順に説明しています。

スペックは何のためにあるか

スペック（機能仕様、技術仕様、設計書。名前は曖昧に混ざります）は、要件を、作って検証できるだけ正確な振る舞いに翻訳します。PRDが「顧客は自分のデータをエクスポートできる」と言うとき、スペックは、どの形式か、ファイル名は何か、25MBを超える添付はどうなるか、エクスポートはバックグラウンドで走るか、その間に人は何を見るかを述べます。

良いスペックはPRDとは別の形をしています。

1. 1スペックに1要件または1機能。 プロダクト全体を扱うスペックは、詳細が多すぎるPRDです。
2. 散文ではなく、状態と遷移。 「状態Yでユーザーが Xをすると Zが起きる」の表は、段落よりも多くのバグを捕まえます。
3. エッジケースを明示的に列挙。 空、上限、同時実行、オフライン、権限拒否。
4. インターフェース。 APIの形、イベント名、フィールドとその型。
5. このバージョンの対象外。 誰かが誤って作らないように。

スペックは、機能がリリースされる瞬間まで頻繁に変わって構いません。作る人のための作業文書なので、承認よりも版の履歴が重要です。5人のチームでは、スペックはプロジェクト配下のPRDの隣にあるページで、エンジニアが作業しながら編集し、PMは書き換えるのではなくコメントする、という形が多いです。

プロダクトスペックと技術スペックの違いは、主に誰がエッジケースを書くかです。プロダクトスペックは各状態で人が見るものを、技術スペックはシステムがそこに至る方法を列挙します。小さなチームはたいてい2セクションの1文書にまとめますし、それで問題ありません。

RFCは何のためにあるか

RFCは、取り消すのが高くつく変更を提案し、影響を受ける人に「後ではなく今」異論を出すよう求めます。これらのツールで小さな会社を運営してきた中の例：プロジェクト単位の権限からワークスペース全体の権限への移行、請求プロバイダの乗り換え、モノレポの採用、マーケティングサイトから1言語を外すこと。

形式は単純で、インターネット最初期のRFCが文字通り「コメントを求めるメモ」だった1960年代から変わっていません。

• 背景：今何が事実で、なぜそれが問題か。
• 提案：具体的な変更内容。
• 検討した代替案と、それぞれを退けた理由。このセクションがRFCと告知を分けます。
• 影響：楽になることだけでなく、難しくなること。
• 受付期間：コメントの締切日と、決定者。

RFCは、それに基づいて行動する人よりも多くの人に読まれます。3つの中で唯一、コードが出荷されたときではなく、コメントが止まったときに完成する文書です。決定後は「承認」か「却下」と記して、そのまま触らないこと。後の変更は、最初のRFCを参照する別のRFCにします。これをディシジョンレコードやADRと呼ぶチームもありますが、仕組みは同じです。

典型的な失敗は、決定の後に、記録を残すために書かれるRFCです。人は気づきますし、次のRFCにはコメントしなくなります。

いま必要なのはどの文書か

次の問いに順番に答えてください。

1. まだ存在しないプロダクトや機能があり、それが何かについて複数人の合意が要るか。 PRDを書きます。既存プロダクト内の機能なら、別文書を始めるのではなく、プロダクトのPRDに新しい番号付き要件として追加します。
2. エッジケースが2〜3個を超える要件、または他の誰かがそれに合わせて作るインターフェースがあるか。 その要件のスペックを書き、要件からリンクします。
3. 複数のチームに関わる、1週間以上かかる、または取り消しにくい変更があるか。 RFCを書き、締切日を付けます。
4. どれにも当てはまらないか。 受け入れ基準付きのイシューを書き、文書は省きます。2日のタスクにPRDは要りません。

クライアント向けプロダクトを作る6人のチームなら、PRDが1本、プロジェクトの期間を通じてスペックが3〜10本、RFCが年に1〜2本というのが典型です。スペックよりRFCが多いなら、作るより議論している時間の方が長いということです。

2026年の変化：エージェントが最初に読む

2年前、スペックの最初の読者は開発者でした。今は、コーディングエージェント、ワークスペース内の計画エージェント、MCP経由で接続されたアシスタントであることが多い。これが「良い文書」の条件を、実務的にいくつか変えます。

構造が散文に勝つ。 番号付き要件と受け入れ基準のあるPRDを渡されたエージェントは、それに対してイシューを計画し、カバレッジを報告できます。4ページの物語を渡されると、要約して境界を失います。見出し、識別子、表は、もはや好みの問題ではなく、インターフェースです。

非ゴールは文字通りに読まれる。 人は「v1ではオフライン非対応」を流し読みして覚えています。作業を計画するエージェントは、渡された文書に書いてある場合にだけそれを守ります。非ゴールはチャットのスレッドではなく、PRDに書いてください。

ベースラインの重要性が増す。 あるエージェントが要件を書き、別のエージェントがそこからイシューを計画すると、ドリフトが起きやすくなります。1回のパスで要件が弱められ、誰も気づかない。承認時にPRDを凍結し、後の版をそれと比較するのが、これを捕まえる方法です。Atrixでは、エージェントのDevelop実行がブリーフから要件文書を書き、要件をベースラインとして凍結でき、要件監査がそのベースラインに対するカバレッジとドリフトを示します。コードをスキャンするのではなく、レコードを比較します。

スペックがテスト計画になる。 スペックが状態と期待される振る舞いの表なら、コーディングエージェントは各行をテストに変えられます。段落で書かれた意図なら、できません。

RFCは人間のまま。 RFCの決定は、組織がどのトレードオフを受け入れるかの判断です。エージェントは代替案のセクションをうまく下書きし、コメントを要約できます。決める側に回るべきではありません。

3つを1か所にまとめる

文書がどこにあるかは、以前より重要です。エージェントは届く場所にあるものしか読めないからです。PRDがGoogleドキュメント、スペックがWiki、RFCがプルリクエストの説明にあると、権限が3つ、検索窓が3つ、相互のリンクはゼロです。

私たちでうまくいっているのは、プロダクトごとのページツリーです。PRDが最上位ページ、各スペックはその要件からリンクされた子ページ、RFCはワークスペース直下のフォルダにタイトルにステータスを付けて置きます。ロードマップの項目は要件にリンクし直すので、項目が遅れたとき、それが担う要件まで1クリックです。プロダクトロードマップのテンプレートはこのリンクを前提に作られています。

Atrixはこれを実現する一つの手段で、プロジェクト配下にネストするページ、リアルタイム共同編集、版の履歴、Markdownエクスポートがあり、MCPサーバーを通じて外部のアシスタントも同じページを読めます。NotionやConfluenceもネストと履歴に対応しています。重要なのは、3つの文書すべてに同じツールから同じ権限でアクセスできることです。

FAQ

PRDとスペックの違いは何ですか？

PRDは、受け入れ基準付きの番号付き要件というレベルで「何を、なぜ作るか」を示します。スペックは、その要件の1つが各状態でどう振る舞うかを、作って検証できる精度で示します。PRDは承認されて凍結され、スペックは機能のリリースまで変わり続けます。

RFCと設計書（design doc）は同じものですか？

少し違います。設計書は何かをどう作るかを説明し、RFCは変更をすべきかを問い、決定の前に異論を募ります。多くの設計書にはRFC風の「検討した代替案」セクションがあり、両者の名前を区別しないチームもありますが、RFCを定義づけるのはコメント期間と最後の決定です。

スタートアップにPRDは必要ですか？

最初のバージョンを作る2人のチームなら、1ページの課題記述とイシューの一覧で足ります。クライアント、投資家、新しいメンバーが「何が合意されたのか」を知る必要が生じた最初の瞬間から、番号付き要件のあるPRDは元が取れます。きっかけは会社の規模ではなく、複数人の合意が必要になることです。

スペックはPMとエンジニアのどちらが書きますか？

通常は作業に最も近いエンジニアかデザイナーが書き、PMがレビューします。PRDはPMの文書、スペックは作る人の文書です。PMのいないチームでは、創業者がPRDを書き、機能を作る人がスペックを書きます。

PRDに技術的な詳細を含めるべきですか？

いいえ。アーキテクチャ、スキーマ、APIの形はスペックか技術設計に書きます。実装を指定するPRDは、作る人が決めるべき判断を固定してしまい、エンジニアが別のアプローチを選んだ瞬間に古くなります。

AIエージェントはこれらの文書を書けますか？

3つとも下書きできますし、明確なブリーフと既存ページをコンテキストとして渡せば、PRDとスペックはよく書けます。人間が担うべきなのは、PRDの課題記述、RFCの決定、そして要件をベースラインに変える承認です。

次のステップ

プロダクトを始めるなら、まずPRDを書いてください。PRDテンプレートは、上記のセクションを順に並べたMarkdownページです。要件ができたら、プロダクトロードマップのテンプレートが各ロードマップ項目を担当する要件にリンクします。これが後の監査が頼るリンクです。エージェントのいるワークスペースでこれらの文書がどう機能するかは、ドキュメントとホワイトボードとAIエージェントのページをご覧ください。