Claude CodeやCursorがそのまま実装できるPRDの書き方

2026年にPRDが変わった理由

20年間、PRDは合意のための文書でした。読み手は人間で、会議で質問し、悪い要件には反論し、小さな隙間は判断で埋めるエンジニアでした。人間が曖昧さを解決してくれるので、PRDは曖昧でも構いませんでした。

コーディングエージェントは、統計的に最もありそうな解釈を選び、確認せずに素早くそれを実装することで曖昧さを解決します。これが問題のすべてです。かつて10分の会話で済んだ曖昧さが、今は誤った実装、レビュー、リバート、二度目の実行というコストになります。エージェントで日常的にリリースしているチームは2025年に同じことに気づきました。成果物の品質は、モデルの選択よりも、書かれた仕様の品質に密接に連動するのです。

二つのオープンソースプロジェクトがこの転換を可視化しました。2025年9月に公開されたGitHubのSpec Kitは、エージェントの作業をゲート付きの順序に構造化します。プロジェクト原則のコンスティテューション、仕様、技術計画、タスクリスト、そしてその後にようやく実装です。2026年10月時点でリポジトリは約143,000スターを表示しています。Eyal ToledanoによるTask Masterはより狭い範囲を扱います。task-master parse-prd your-prd.txtでPRDを依存関係順のタスクリストに変換し、Cursor、Windsurf、Claude Codeがそれを順に処理します。リポジトリは2026年10月時点で約28,000スターです。どちらのツールも、PRDはチームへのメモではなくエージェントへのインターフェースだと想定しています。

転換を一文で言えば、PRDは人が合意する文書であることをやめ、エージェントが実行する入力になったのです。

エージェントがPRDに求めるもの

エージェントが必要とするのは四つで、ほとんどのPRDはそのどれも整った形で与えていません。

番号付きで原子的な要件。 要件ごとに一文、安定したID（R1、R2、R3）を付けます。「ユーザーはメールでパスワードをリセットできる」は要件です。「ユーザーはスムーズなアカウント復旧体験を得られる」は要件ではありません。IDが重要なのは、エージェント、計画、タスク、テストのすべてがそれを参照するからです。

エージェントがテストできる受け入れ基準。 要件ごとに、合格した確認がどう見えるかを、エージェントが実行できる言葉で書きます。HTTPレスポンス、データベースの状態、描画された要素、CLIの終了コードなどです。確認を言葉にできなければ、その要件は未完成です。

明示的な非目標。 エージェントは作りすぎます。放っておくと「パスワードリセットを追加」は、リセットフロー、レート制限、監査ログ、それらを設定する設定ページになります。非目標のセクション（「今回のイテレーションではレート制限なし。管理UIなし。SMSなし。」）はPRDに追加できる最も安価な一行で、他のどの行よりも無駄な作業を減らします。

制約と既存システムの形。 どのフレームワーク、どのデータベース、認証はどこにあるか、触ってはいけないファイル、従うべき規約。Spec Kitはこれをコンスティテューションと呼びます。Cursorではルールファイルに、Claude CodeではCLAUDE.mdに、CodexではAGENTS.mdにあります。PRDはそれらを繰り返すのではなく参照すべきです。

ビフォーアフター：同じ要件の書き直し

下の表は私たち自身のPRDから取ったものです。左列はかつての書き方、右列はエージェントが行動できる書き方です。

右列は要件ごとには長く、全体では短くなります。各行を取り巻いていた曖昧な段落が消えるからです。

テンプレート、セクションごとに

これが私たちの使う骨組みです。すべてのエージェントがMarkdownを読め、Gitで差分がきれいに出るのでMarkdownにしています。コードブロック内ではセクション名を見出しではなく太字にして、構造が見えるようにしています。

**機能：** メールによるパスワードリセット
**責任者：** （名前）   **状態：** 下書き | 凍結   **ベースライン：** v1（2026-10-28）

**課題**
パスワードを忘れたユーザーはサポートにメールする。サポートは2026年9月に
そうしたメールを41件処理した。セルフサービスの経路がない。

**目標**
サインアウト状態のユーザーが、誰にも連絡せず2分以内に自分でパスワードを
リセットできる。

**要件**
R1. サインアウト状態のユーザーはメールアドレスを入力してリセットを要求できる。
    合格条件：既知のメールでPOST /auth/resetが200を返し、30分で期限切れの
    password_reset行を1件作成する。
R2. 未知のメールでも同じ200レスポンスを返し、何も作成しない。
    合格条件：未知のメールでPOST /auth/resetが200を返し、行数は変わらない。
R3. リセットメールには、新しいパスワードと確認の欄があるフォームを開く
    リンクが1つ含まれる。
    合格条件：取得したテストメール内のリンクが/auth/reset/:tokenに解決し、
    両方の欄を表示する。
R4. 有効なトークンと一致するパスワードを送信すると、ハッシュを更新し、
    トークンを削除し、ユーザーをサインインさせる。
    合格条件：統合テストreset_happy_pathが完了し、ユーザーが/homeに到達する。
R5. 期限切れまたは使用済みのトークンは「このリンクは期限切れです」と
    新しいリンクを要求するボタンを表示する。

**非目標**
今回のイテレーションではレート制限なし。SMSなし。管理UIなし。
サインインフォームの変更なし。

**制約**
CLAUDE.mdに従う。既存のメーラー（lib/mail）を使う。依存関係を追加しない。
トークンはランダム32バイトの16進エンコード。

**未決事項**
Q1. リセット時に他のセッションもサインアウトさせるか？決定責任者：（名前）、
    期限2026-10-30。決定まで実装しない。

**エージェントの範囲外**
メール本文の文言：プレースホルダーで十分。

選択についていくつか補足します。

• 状態とベースライン。 バージョンと日付付きの「凍結」は、エージェントがこのテキストだけを基に実装し、それより新しいものは参照しないという意味です。最初の実行前に凍結し、要件が変わればバージョンを上げるので、後の監査でリリースされたものと合意されたものを比較できます。
• 合格条件の行。 別のテスト計画ではなく、要件の隣に書きます。エージェントはこれをテスト仕様として読み、多くはテストを先に書きます。
• 決定責任者付きの未決事項。 責任者のいない未決事項は、エージェントが埋める隙間です。「決定まで実装しない」がそれを防ぐ指示です。

午後ひとつで書き上げる手順

1. 課題を実際の数字を1つ含む三文で書く。 数字がなければ取りに行く。「サポートは9月にリセットのメールを41件処理した」は「ユーザーは復旧に苦労している」に勝ります。
2. 要件を一文ずつ列挙し、番号を振る。 5〜15件を目安に。20件を超えるなら機能が二つあるので、PRDを分割します。
3. 各要件の下に合格条件の行を書く。 書けないなら、要件が原子的でないか、完了の姿をまだ知らないかのどちらかです。どちらもエージェントより先に見つける価値があります。
4. 誰かが要件を読む前に非目標を書く。 熱心なエンジニアがここに付け加えそうで、私たちが望まないものは何か、と自問して書き出します。
5. 制約ファイルを指し示す。 書き写さない。CLAUDE.md、AGENTS.md、Cursorのルールを規約の唯一の情報源に保ちます。
6. 凍結する。 状態を記し、バージョンを決め、エージェントが読める場所に置きます。リポジトリ内のファイルか、MCPサーバー経由でエージェントが取得できるページです。
7. エージェントをR1だけで実行する。 残りを実行させる前にその出力をレビューします。最初の要件で、エージェントがそもそもPRDを読めているかが分かります。

PRDの置き場所と、エージェントの読み方

Google Doc上のPRDはClaude Codeには見えません。機能する選択肢は次のとおりです。

• リポジトリ内のファイル。 docs/prd/password-reset.mdをCLAUDE.mdやAGENTS.mdから参照します。最も単純で、バージョン管理され、すべてのエージェントが読めます。Spec KitもTask Masterもこれを前提にしています。
• MCP経由でエージェントが取得するページ。 チームがリポジトリではなくワークスペースツールでPRDを書いているなら、MCPサーバーによってエージェントはページを直接読めます。Atrixはページ、課題、サイクルを85ツールとOAuth 2.1を備えたMCPサーバーで公開しており、Official MCP RegistryとGlamaに掲載されています。実際の効果は、コーディングエージェントが凍結済みのPRDページを読み、計画された課題を作成し、完了時に更新できることで、ツール間でテキストをコピーする必要がなくなります。はっきり述べておく限界として、エージェントはワークスペースのオブジェクトを読み書きするだけで、あなたのコードやテストを実行はしません。
• 両方。 私たちは正本のPRDをページとして保ち、実行開始時にエージェントが凍結版をリポジトリにコピーするので、コミットには何を基に実装したかが正確に記録されます。

CursorとCodexについては、Cursor連携とCodex連携にセットアップが書かれています。OAuth接続を一度行えば、エージェントはPRD、バックログ、現在のサイクルをツールとして見るようになります。

省くべきもの

人間には必要でエージェントには不要なものすべてです。

• ペルソナとユーザーリサーチ。リンクしたページに置きます。エージェントに必要なのは要件であってペルソナではありません。
• 競合分析。同様です。
• モックアップ。要件が視覚的なものでない限り不要です。視覚的なら、エージェントが見られるスクリーンショット1枚のほうが、それを説明する三段落より優れています。
• スケジュール。エージェントはスプリントを計画しません。それはサイクルの役目です。

従来のPRDはなくなりません。エージェントが読む文書ではなくなるだけです。ステークホルダー向けの長い形式が必要なら、AI PRDテンプレートの記事がその版を扱っており、サイトのPRDテンプレートは複製できるホスト版です。

よくある質問

AIコーディングエージェント向けのPRDは、仕様駆動開発の仕様と同じものですか？

ほぼ同じです。Spec Kitが示す仕様駆動開発は、仕様（何を、なぜ）と計画（どう、どの技術スタックで）とタスク（順序付けられた作業）を分けます。ここで述べたPRDは仕様の層です。計画とタスクはそこから、エージェントまたはTask Masterのようなツールによって生成されます。

Claude CodeやCursor向けのPRDはどのくらいの長さにすべきですか？

触るコードと一緒にエージェントのコンテキストに収まる短さです。実際には400〜1,200語、番号付き要件5〜15件です。それより長ければ機能を分割します。

ユーザーストーリーはまだ必要ですか？

「ユーザーとして、私は〜したい」の形式では不要です。エージェントに必要なのは要件と受け入れ基準で、ストーリーの包装は検証可能な内容を増やさずに語数を増やします。チームが計画にストーリーを使うなら残して構いませんが、番号付き要件を先に置いてください。

CLAUDE.mdやAGENTS.mdに書くものと、PRDに書くものの違いは？

規約はルールファイルに書きます。技術スタック、フォルダー構成、テストコマンド、スタイル、触らないファイルです。PRDは機能ごとで、ルールファイルを参照します。規約をPRDごとに繰り返すと、互いにずれていきます。

エージェントにPRDを書かせるべきですか？

ブリーフから下書きは作れますし、その下書きはまだ決めていないことのチェックリストとして役立つことが多いです。AtrixのエージェントはDevelop実行でこれを行います。ブリーフを入れると要件、アーキテクチャ、計画された課題が出てきて、Builderでは月100回実行できます。しかし凍結、非目標、未決事項の決定はあなたの仕事です。何を作ってほしくないかをエージェントは知りません。

エージェントがPRDどおりに実装したかはどう確認しますか？

合格条件の行を使い、凍結したベースラインと結果を要件ごとに照合します。Atrixの要件監査は凍結したページに対してこの比較を行い、要件のカバレッジとドリフトを確認しますが、コード自体は確認しません。コードについては、合格条件が示すテストを実行し、認証と決済の経路は手動でレビューしてください。

次のステップ

PRDテンプレートをコピーし、R1を合格条件付きで書き、R2を書く前にその一件だけでエージェントを実行してみてください。PRDがリポジトリの外にあるなら、MCPサーバーがClaude Code、Cursor、Codexがそれを読む手段です。

出典

GitHub Spec Kitリポジトリ、スター数は2026年10月27日時点；Spec-driven development with AI: get started with a new open source toolkit、GitHub Blog、2025年9月；Task Masterリポジトリ、スター数は2026年10月27日時点。