フェーズ 2: PRD - 製品要求仕様書の生成

PRD フェーズは Agent App Factory パイプラインの第2フェーズで、input/idea.md を完全な MVP（実用最小製品）指向の製品要求仕様書に変換する役割を担います。このフェーズでは、ターゲットユーザー、コア機能、MVP の範囲、非目標を明確にし、後続の UI デザインと技術アーキテクチャに明確な指針を提供します。

学習後の到達目標

input/idea.md を標準テンプレートに従った artifacts/prd/prd.md ドキュメントに変換できる
PRD Agent の責任範囲（要件を定義のみ行い、技術実装には関与しない）を理解できる
MoSCoW 機能優先度フレームワークを習得し、MVP がコア価値に集中できるようにできる
高品質なユーザーストーリーと検証可能な受け入れ基準を作成できる
PRD に含めるべき内容と、後続のフェーズに含めるべき内容を区別できる

現在の課題

明確な製品アイデア（Bootstrap フェーズで完了）を持っているかもしれませんが、要求仕様書に変換する際に次のような困難に直面しているかもしれません：

"どの機能を含めるべきかわからず、漏れやオーバーデザインを心配している"
"機能は多いが、MVP に必須なものがどれかわからない"
"ユーザーストーリーが明確に書かれておらず、開発チームが理解できない"
"誤って技術実装の詳細を要件に混ぜてしまい、スコープの肥大化につながっている"

このような不明確な PRD は、後続の UI デザインとコード開発の指針が欠如し、最終的に生成されるアプリが期待から逸脱したり、不必要な複雑さが含まれたりする原因になります。

いつ使うべきか

Bootstrap フェーズが完了し、以下の条件を満たす場合：

idea.md の構造化が完了している（Bootstrap フェーズの出力）
UI デザインや技術アーキテクチャをまだ開始していない（これらは後続のフェーズ）
MVP の範囲を明確にしたい（機能のオーバーデザインを避けるため）
開発とデザインに明確な指針を提供する必要がある（ユーザーストーリー、受け入れ基準）

🎒 開始前の準備

前提条件

PRD フェーズを開始する前に、以下を確認してください：

✅ プロジェクトの初期化が完了している
✅ 7 フェーズパイプラインの概要を理解している
✅ Bootstrap フェーズが完了し、input/idea.md が生成されている
✅ AI アシスタント（Claude Code 推奨）がインストール・設定されている

コアコンセプト

PRD フェーズとは？

PRD（Product Requirements Document、製品要求仕様書）フェーズのコア責任は**「何を作るか」を定義することであり、「どう作るか」ではありません**。

技術文書ではない

PRD Agent はアーキテクトや UI デザイナーではありません。以下の決定は行いません：

❌ 使用する技術スタック（React vs Vue、Express vs Koa）
❌ データベースの設計方法（テーブル構造、インデックス）
❌ UI レイアウトとインタラクションの詳細（ボタンの位置、カラースキーム）

そのタスクは以下のとおりです：

✅ ターゲットユーザーとその課題を定義する
✅ コア機能と優先度をリストアップする
✅ MVP の範囲と非目標を明確にする
✅ テスト可能なユーザーストーリーと受け入れ基準を提供する

なぜ PRD が必要か？

想像してください。あなたが施工チームに「家を建てたい」と言ったとします。

❌ 図面なし：施工チームは推測するしかなく、あなたが住みたくない家が完成するかもしれません
✅ 詳細な図面あり：部屋数、機能レイアウト、材料要件が明確で、施工チームは図面通りに施工します

PRD フェーズは、「家を建てたい」という考えを「3LDK、主寝室が南向き、オープンキッチン」という詳細な図面に変換するプロセスです。

MoSCoW 機能優先度フレームワーク

PRD フェーズでは MoSCoW フレームワークを使用して機能を分類し、MVP がコア価値に集中できるようにします：

分類	定義	判断基準	例
Must Have	MVP に絶対に欠かせない機能	それがないと製品のコア価値を提供できない	家計簿アプリ：支出記録の追加、支出リストの表示
Should Have	重要だがブロッキングではない機能	ユーザーが明確に欠如を感じるが、一時的に回避策がある	家計簿アプリ：レポートのエクスポート、カテゴリ別統計
Could Have	あれば良い機能	コア体験に影響せず、ユーザーは欠如に特に気づかない	家計簿アプリ：予算アラート、マルチ通貨対応
Won't Have	明確に除外する機能	コア価値と無関係か技術的複雑度が高い	家計簿アプリ：ソーシャルシェア、投資アドバイス

MVP のコア

Must Have 機能は 5-7 個以内に制御し、MVP がコア価値に集中し、スコープの肥大化を防ぐようにしてください。

実践手順

ステップ 1：Bootstrap フェーズの完了を確認

PRD フェーズを開始する前に、input/idea.md が存在し、内容が標準に従っていることを確認します。

bash

# idea.md が存在するか確認
cat input/idea.md

期待される内容：概要説明、問題、ターゲットユーザー、コア価値、仮説、非目標などのセクションを含む構造化されたドキュメント。

idea.md が標準に従っていない場合

Bootstrap フェーズに戻って再生成するか、手動で情報を編集・補足してください。

ステップ 2：パイプラインを PRD フェーズまで起動

Factory プロジェクトディレクトリで以下を実行します：

bash

# パイプラインが既に起動している場合、PRD フェーズまで進む
factory run prd

# または最初からパイプラインを起動
factory run

CLI は現在の状態と利用可能なフェーズを表示し、PRD Agent のアシスタント指令を生成します。

ステップ 3：AI アシスタントが PRD Agent 定義を読み込む

AI アシスタント（Claude Code など）は自動的に agents/prd.agent.md を読み込み、その責任と制約を理解します。

PRD Agent の責任

PRD Agent は以下のことのみ実行できます：

input/idea.md の読み取り
artifacts/prd/prd.md の書き込み
skills/prd/skill.md の思考フレームワークと意思決定原則の使用

以下のことは実行できません：

技術実装の詳細や UI デザインの議論
他のファイルの読み取り（upstream 産物を含む）
他のディレクトリへの書き込み

ステップ 4：skills/prd/skill.md を読み込む

PRD Agent は skills/prd/skill.md を読み込み、以下の指針を取得します：

思考フレームワーク：

ターゲットユーザー：誰が使用するか？背景、役割、課題は何か？
コア問題：製品が解決する根本的な問題は何か？
コア価値：なぜこのソリューションに価値があるか？競合との違いは何か？
成功指標：成功をどう測るか？

MoSCoW 機能優先度：

Must Have（必須）：MVP に絶対に欠かせない機能
Should Have（推奨）：重要だがブロッキングではない機能
Could Have（オプション）：あれば良い機能
Won't Have（除外）：明確に除外する機能

ユーザーストーリー作成ガイド：

[ロール/ユーザータイプ]として
[機能/操作]したい
[ビジネス価値/目標]のため

PRD ドキュメント構造要件（8 つのセクション）：

概要
ターゲットユーザーペルソナ
コア価値提案
機能要件（MoSCoW 分類）
ユーザーフロー
非目標（Won't Have）
成功指標
仮説とリスク

ステップ 5：PRD ドキュメントを生成

AI アシスタントは input/idea.md の内容に基づき、スキルの思考フレームワークと意思決定原則を使用して、完全な PRD ドキュメントを生成します。

PRD Agent が行うこと：

input/idea.md を読み込み、主要な要素（ターゲットユーザー、問題、コア価値など）を抽出する
MoSCoW フレームワークに従って機能を分類する
Must Have 機能のユーザーストーリーと受け入れ基準を作成する
非目標をリストアップし、スコープの肥大化を防ぐ
量化可能な成功指標を提示する
整理されたドキュメントを artifacts/prd/prd.md に書き込む

重要な制約

PRD Agent は技術実装の詳細や UI デザインの議論を禁止されています。これらの内容が検出された場合、PRD Agent は書き込みを拒否します。

ステップ 6：prd.md の内容を確認

PRD Agent が完了すると、artifacts/prd/prd.md が生成されます。以下の点を注意深く確認してください：

チェックポイント ✅：

ターゲットユーザーが具体的か？
- ✅ 具体的なペルソナがある（年齢/職業/技術能力/使用シーン/課題）
- ❌ 曖昧：「全員」や「家計簿が必要な人」
コア問題が明確か？
- ✅ ユーザーが現実シーンで直面する課題が記述されている
- ❌ 抽象的：「ユーザー体験が良くない」
コア価値が量化可能か？
- ✅ 具体的なメリットがある（80% の時間節約、50% の効率向上）
- ❌ 抽象的：「効率向上」「より良い体験」
Must Have 機能が集中しているか？
- ✅ 5-7 個以内のコア機能
- ❌ 機能が多すぎる、または二次機能が含まれている
各 Must Have 機能にユーザーストーリーがあるか？
- ✅ 標準フォーマットを使用（...として...したい...のため）
- ❌ ユーザーストーリーが欠如している、またはフォーマットが正しくない
受け入れ基準が検証可能か？
- ✅ 具体的な検証可能な基準がある（金額を入力できる、リストに表示される）
- ❌ 曖昧（「ユーザーフレンドリー」「体験がスムーズ」）
Should HaveとWon't Haveが明確にリストされているか？
- ✅ Should Have が「将来のイテレーション」とマークされ、理由が説明されている
- ✅ Won't Have に除外理由が説明されている
- ❌ 欠如している、または少なすぎる
成功指標が量化可能か？
- ✅ 具体的な数値がある（ユーザーリテンション > 30%、タスク完了時間 < 30 秒）
- ❌ 曖昧（「ユーザーが気に入る」「体験が良い」）
仮説が検証可能か？
- ✅ ユーザー調査で検証可能
- ❌ 主観的判断（「ユーザーは気に入るだろう」）
技術実装の詳細や UI デザインが含まれているか？
- ✅ 技術詳細と UI 記述がない
- ❌ 技術スタック選択、データベース設計、UI レイアウトなどが含まれている

ステップ 7：続行、再試行、一時停止を選択

確認後、CLI はオプションを表示します：

bash

操作を選択してください：
[1] 続行（UI フェーズへ進む）
[2] 再試行（prd.md を再生成）
[3] 一時停止（後で続行）

コードエディターで先に確認することを推奨

AI アシスタントで確認する前に、コードエディターで artifacts/prd/prd.md を開き、一字一句確認してください。UI フェーズに進むと、修正コストが高くなります。

注意点

注意点 1：Must Have 機能が多すぎる

悪い例：

Must Have:
1. 支出記録の追加
2. 支出リストの表示
3. レポートのエクスポート
4. カテゴリ別統計
5. 予算アラート
6. マルチ通貨対応
7. ソーシャルシェア
8. 投資アドバイス

結果：MVP の範囲が大きすぎ、開発期間が長く、リスクが高い。

推奨：5-7 個のコア機能に制限する：

Must Have:
1. 支出記録の追加
2. 支出リストの表示
3. 支出カテゴリの選択

Should Have（将来のイテレーション）:
4. レポートのエクスポート
5. カテゴリ別統計

Won't Have（明確に除外）:
6. ソーシャルシェア（コア価値と無関係）
7. 投資アドバイス（専門資格が必要、技術的複雑度が高い）

注意点 2：ユーザーストーリーの欠如またはフォーマットが正しくない

悪い例：

機能：支出記録の追加
説明：ユーザーは支出記録を追加できる

結果：開発チームが誰のために、何を解決するかが不明確。

推奨：標準フォーマットを使用：

機能：支出記録の追加
ユーザーストーリー：予算意識の高いユーザーとして
すべての支出を記録したい
消費の行き先を把握し、予算を管理するため

受け入れ基準：
- 支出金額と説明を入力できる
- 支出カテゴリを選択できる
- 記録が即座に支出リストに表示される
- 現在の日時が表示される

注意点 3：受け入れ基準が検証不可能

悪い例：

受け入れ基準：
- ユーザーインターフェースがフレンドリー
- 操作がスムーズ
- 体验が良い

結果：テストできず、開発チームが「フレンドリー」「スムーズ」「良い」の定義が不明確。

推奨：具体的な検証可能な基準を記述：

受け入れ基準：
- 支出金額と説明を入力できる
- 10 個のプリセットカテゴリから選択できる
- 記録が 1 秒以内に支出リストに表示される
- 現在の日時が自動的に記録される

注意点 4：ターゲットユーザーの記述が抽象的すぎる

悪い例：

ターゲットユーザー：家計簿が必要なすべての人

結果：後続の UI デザインと技術アーキテクチャの方向性が不明確。

推奨：ペルソナを明確にする：

主要ユーザーグループ：
- 役割：18-30 歳の新社会人
- 年齢：18-30 歳
- 技術能力：中級、スマートフォンアプリに慣れている
- 使用シーン：日常的な消費後にすぐ記録、月末に統計を確認
- 課題：月末に予算超過に気づくが、どこにお金を使ったか不明確、予算管理ができない

注意点 5：非目標の欠如または少なすぎる

悪い例：

非目標：なし

結果：後続の PRD と Code フェーズでオーバーデザインが発生し、技術的複雑度が増加する。

推奨：少なくとも 3 項目をリストアップ：

非目標 (Out of Scope)：
- ソーシャルシェア機能（MVP は個人記録に集中）
- 財務アドバイスと投資分析（専門資格が必要、コア価値を超える）
- サードパーティ金融システムとの統合（技術的複雑度が高い、MVP には不要）
- 複雑なデータ分析とレポート（Should Have、将来のイテレーション）

注意点 6：技術実装の詳細が含まれている

悪い例：

機能：支出記録の追加
技術実装：React Hook Form でフォームを管理、API エンドポイント POST /api/expenses

結果：PRD Agent はこれらの内容を拒否します（要件定義のみ行い、技術実装には関与しません）。

推奨：「何をするか」のみ記述し、「どうするか」は記述しない：

機能：支出記録の追加
ユーザーストーリー：予算意識の高いユーザーとして
すべての支出を記録したい
消費の行き先を把握し、予算を管理するため

受け入れ基準：
- 支出金額と説明を入力できる
- 支出カテゴリを選択できる
- 記録が即座に支出リストに表示される
- 現在の日時が表示される

注意点 7：成功指標が量化不可能

悪い例：

成功指標：
- ユーザーは私たちのアプリを気に入る
- 体验がスムーズ
- ユーザーリテンションが高い

結果：製品が成功したかを測定できない。

推奨：量化可能な指標を記述：

成功指標：
製品目標：
- 最初の月で 100 人のアクティブユーザーを獲得
- ユーザーは週に少なくとも 3 回使用
- コア機能（支出記録の追加）使用率 > 80%

主要指標 (KPIs)：
- ユーザーリテンション：7 日リテンション > 30%、30 日リテンション > 15%
- コア機能使用率：支出記録の追加使用率 > 80%
- タスク完了時間：支出の追加 < 30 秒

検証方法：
- バックエンドログでユーザー行動を記録
- A/B テストでユーザーリテンションを検証
- ユーザーフィードバックアンケートで満足度を収集

注意点 8：仮説が検証不可能

悪い例：

仮説：ユーザーは私たちのデザインを気に入るだろう

結果：ユーザー調査で検証できず、MVP が失敗する可能性がある。

推奨：検証可能な仮説を記述：

仮説：
市場仮説：
- 若者（18-30 歳）には「お金がどこに行ったかわからない」という課題がある
- 既存の家計簿アプリは複雑すぎ、若者はよりシンプルなソリューションを必要としている

ユーザー行動仮説：
- ユーザーは予算管理に役立つなら、毎回の消費後に 2 分を費やして支出を記録する意思がある
- ユーザーは複雑なチャートや分析よりもミニマルな UI を好む

技術的実現可能性仮説：
- モバイルアプリで高速な 3 ステップ記録フローを実現できる
- オフラインストレージで基本的なニーズを満たせる

まとめ

PRD フェーズのコアは**「要件を定義することであり、実装ではない」**：

入力：構造化された input/idea.md（Bootstrap フェーズの出力）
プロセス：AI アシスタントが skills/prd/skill.md の思考フレームワークと MoSCoW 優先度フレームワークを使用
出力：完全な artifacts/prd/prd.md ドキュメント
検証：ユーザーが明確か、価値が量化可能か、機能が集中しているか、技術詳細が含まれていないかを確認

重要な原則

❌ しないこと：技術実装の議論、UI レイアウトの設計、データベース構造の決定
✅ することのみ：ターゲットユーザーの定義、コア機能のリストアップ、MVP 範囲の明確化、テスト可能なユーザーストーリーの提供

次のレッスンの予告

次のレッスンでは フェーズ 3：UI - インターフェースとプロトタイプの設計 を学びます。
以下を学びます：
PRD に基づいて UI 構造を設計する方法
ui-ux-pro-max スキルを使用してデザインシステムを生成する方法
プレビュー可能な HTML プロトタイプを生成する方法
UI フェーズの出力ファイルと終了条件

付録：ソースコード参照

展開してソースコードの場所を表示

更新日時：2026-01-29

機能	ファイルパス	行番号
PRD Agent 定義	`agents/prd.agent.md`	1-33
PRD Skill	`skills/prd/skill.md`	1-325
パイプライン定義（PRD フェーズ）	`pipeline.yaml`	20-33
オーケストレーター定義	`agents/orchestrator.checkpoint.md`	1-100+

重要な制約：

技術実装詳細の禁止：prd.agent.md:23
UI デザイン記述の禁止：prd.agent.md:23
ターゲットユーザーの必須：pipeline.yaml:29
MVP 範囲の定義必須：pipeline.yaml:30
非目標のリスト必須：pipeline.yaml:31
出力ファイルは artifacts/prd/prd.md に保存必須：prd.agent.md:13

終了条件（pipeline.yaml:28-32）：

PRD にターゲットユーザーが含まれている
PRD が MVP 範囲を定義している
PRD が非目標（Out of Scope）をリストアップしている
PRD に技術実装詳細が含まれていない

Skill 内容フレームワーク：

思考フレームワーク：ターゲットユーザー、コア問題、コア価値、成功指標
MoSCoW 機能優先度フレームワーク：Must Have、Should Have、Could Have、Won't Have
ユーザーストーリー作成ガイド：標準フォーマットと例
PRD ドキュメント構造要件：8 つの必須セクション
意思決定原則：ユーザー中心、MVP 重視、非目標の明確化、検証可能性
品質チェックリスト：ユーザーと問題、機能範囲、ユーザーストーリー、ドキュメント完全性、禁止項目チェック
しないこと (NEVER)：7 つの明確に禁止された行為

PRD ドキュメント必須セクション：

概要（製品概要、背景と目標）
ターゲットユーザーペルソナ（主要ユーザーグループ、二次ユーザーグループ）
コア価値提案（解決する問題、私たちのソリューション、差別化優位性）
機能要件（Must Have、Should Have、Could Have）
ユーザーフロー（主フローの記述）
非目標（Won't Have）
成功指標（製品目標、主要指標、検証方法）
仮説とリスク（市場仮説、ユーザー行動仮説、技術的実現可能性仮説、リスク表）

フェーズ 2: PRD - 製品要求仕様書の生成 ​

学習後の到達目標 ​

現在の課題 ​

いつ使うべきか ​

🎒 開始前の準備 ​

コアコンセプト ​

PRD フェーズとは？ ​

なぜ PRD が必要か？ ​

MoSCoW 機能優先度フレームワーク ​

実践手順 ​

ステップ 1：Bootstrap フェーズの完了を確認 ​

ステップ 2：パイプラインを PRD フェーズまで起動 ​

ステップ 3：AI アシスタントが PRD Agent 定義を読み込む ​

ステップ 4：skills/prd/skill.md を読み込む ​

ステップ 5：PRD ドキュメントを生成 ​

ステップ 6：prd.md の内容を確認 ​

ステップ 7：続行、再試行、一時停止を選択 ​

注意点 ​

注意点 1：Must Have 機能が多すぎる ​

注意点 2：ユーザーストーリーの欠如またはフォーマットが正しくない ​

注意点 3：受け入れ基準が検証不可能 ​

注意点 4：ターゲットユーザーの記述が抽象的すぎる ​

注意点 5：非目標の欠如または少なすぎる ​

注意点 6：技術実装の詳細が含まれている ​

注意点 7：成功指標が量化不可能 ​

注意点 8：仮説が検証不可能 ​

まとめ ​

次のレッスンの予告 ​

付録：ソースコード参照 ​

フェーズ 2: PRD - 製品要求仕様書の生成

学習後の到達目標

現在の課題

いつ使うべきか

🎒 開始前の準備

コアコンセプト

PRD フェーズとは？

なぜ PRD が必要か？

MoSCoW 機能優先度フレームワーク

実践手順

ステップ 1：Bootstrap フェーズの完了を確認

ステップ 2：パイプラインを PRD フェーズまで起動

ステップ 3：AI アシスタントが PRD Agent 定義を読み込む

ステップ 4：skills/prd/skill.md を読み込む

ステップ 5：PRD ドキュメントを生成

ステップ 6：prd.md の内容を確認

ステップ 7：続行、再試行、一時停止を選択

注意点

注意点 1：Must Have 機能が多すぎる

注意点 2：ユーザーストーリーの欠如またはフォーマットが正しくない

注意点 3：受け入れ基準が検証不可能

注意点 4：ターゲットユーザーの記述が抽象的すぎる

注意点 5：非目標の欠如または少なすぎる

注意点 6：技術実装の詳細が含まれている

注意点 7：成功指標が量化不可能

注意点 8：仮説が検証不可能

まとめ

次のレッスンの予告

付録：ソースコード参照