everything-claude-code/docs/ja-JP/commands/plan-prd.md

description, argument-hint

description	argument-hint
リーンで問題起点のPRDを生成し、実装計画のために/planに引き渡します。	[製品/機能のアイデア]（空欄 = 質問から開始）

PRDコマンド

プロダクト要件ドキュメントを作成します — SDLCの要件フェーズのアーティファクトです。成功のために何が真でなければならないか、なぜかを記録し、どのようにの前で止まります。実装の分解は/planに委任されます。

入力: $ARGUMENTS

このコマンドのスコープ

このコマンドがすること	このコマンドがしないこと
問題とユーザーをフレーミング	アーキテクチャの設計
成功基準とスコープの記録	ファイルの選択やパターンの記述
未解決の質問とリスクの一覧	実装タスクの列挙
.claude/prds/{name}.prd.mdの書き込み	実装計画の作成 — それは/plan

実装の詳細を書いていることに気づいたら、止めて削除してください。それは/planに属します。

アンチフラフルール: 情報が不足している場合はTBD — {方法}による検証が必要と書く。もっともらしく聞こえる要件を作り出さないこと。

ワークフロー

4つのフェーズ。各フェーズは単一のゲート — 質問し、ユーザーを待ち、次に進む。ネストしたループも並行リサーチの儀式もなし。

フェーズ 1 — FRAME

$ARGUMENTSが空の場合、質問:

何をビルドしたいですか？1〜2文で。

提供された場合、1文で再述し質問:

理解しました: {再述}。正しいですか、調整すべきですか？

次にフレーミング質問を一度に提示:

1. 誰がこの問題を抱えていますか？（具体的な役割またはセグメント）
2. 何が観察可能な痛みですか？（想定されるニーズではなく行動を記述）
3. なぜ既存のもので解決できないのですか？
4. なぜ今？ — 何が変わってこれを行う価値があるのですか？

ユーザーを待つ。回答（または明示的な"skip"）なしに先に進まない。

フェーズ 2 — GROUND

エビデンスを求める。これは最も短いフェーズであり、最も重要:

この問題が実在し解決する価値があるというエビデンスは何ですか？（ユーザーの引用、サポートチケット、メトリクス、観察された行動、失敗したワークアラウンド — 具体的なもの何でも）

ユーザーにエビデンスがない場合、PRDのEvidenceセクションを仮説 — {ユーザーリサーチ | アナリティクス | プロトタイプ}による検証が必要と記録。これによりPRDの誠実さが保たれる。

フェーズ 3 — DECIDE

スコープと仮説を一度に:

1. 仮説 — 完成させてください: 私たちは*{能力}が{ユーザー}の{問題を解決}すると信じています。{測定可能な成果}*が得られたら正しいとわかります。
2. MVP — 仮説をテストするために必要な最小限は？
3. スコープ外 — ユーザーが求めても明示的にビルドしないものは？
4. 未解決の質問 — アプローチを変える可能性のある不確実性は？

回答を待つ。

フェーズ 4 — GENERATE & HAND OFF

必要に応じてディレクトリを作成し、PRDを書き、報告。

mkdir -p .claude/prds

出力パス: .claude/prds/{kebab-case-name}.prd.md

PRDテンプレート

# {製品 / 機能名}

## Problem
{2〜3文: 誰が何の問題を抱えていて、未解決のコストは何か？}

## Evidence
- {ユーザーの引用、データポイント、または観察}
- {または: "仮説 — {方法}による検証が必要"}

## Users
- **Primary**: {役割、コンテキスト、ニーズのトリガー}
- **Not for**: {明示的に除外する対象}

## Hypothesis
私たちは**{能力}**が**{ユーザー}**の**{問題を解決}**すると信じています。
**{測定可能な成果}**が得られたら正しいとわかります。

## Success Metrics
| Metric | Target | How measured |
|---|---|---|
| {primary} | {number} | {method} |

## Scope
**MVP** — {仮説をテストするための最小限}

**Out of scope**
- {項目} — {延期する理由}

## Delivery Milestones
<!-- ビジネス成果であり、エンジニアリングタスクではない。/planが各マイルストーンを計画に変換。 -->
<!-- Status: pending | in-progress | complete -->

| # | Milestone | Outcome | Status | Plan |
|---|---|---|---|---|
| 1 | {name} | {ユーザーに見える変更} | pending | — |
| 2 | {name} | {ユーザーに見える変更} | pending | — |

## Open Questions
- [ ] {スコープやアプローチを変える可能性のある質問}

## Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|

---
*Status: DRAFT — 要件のみ。実装計画は/planで保留中。*

ユーザーへの報告

PRD created: .claude/prds/{name}.prd.md

Problem:    {一行}
Hypothesis: {一行}
MVP:        {一行}

Validation status:
  Problem  {validated | assumption}
  Users    {concrete | generic — refine}
  Metrics  {defined | TBD}

Open questions: {count}

Next step: /plan .claude/prds/{name}.prd.md
  → /plan が次の保留中のマイルストーンを選択し、実装計画を作成します。

統合

• /plan <prd-path> — PRDを消費し、次の保留中のマイルストーンの実装計画を作成。
• tdd-workflowスキル — テストファーストで計画を実装。
• /pr — PRDと計画を参照するPRを作成。

成功基準

• PROBLEM_CLEAR: 問題が具体的でエビデンスがある（または仮説としてフラグ付き）。
• USER_CONCRETE: プライマリユーザーが具体的な役割であり、"ユーザー"ではない。
• HYPOTHESIS_TESTABLE: 測定可能な成果が含まれている。
• SCOPE_BOUNDED: 明示的なMVPと明示的なスコープ外。
• NO_IMPLEMENTATION_DETAIL: ファイルパス、ライブラリ、タスクの分解が含まれていない — もし含まれていたら/planステップに移動。