product-playbook 1.0.0

package/i18n/ja/references/04b-solutions.md

@@ -0,0 +1,269 @@
+# ステージ3：Develop — ソリューション設計と優先順位付け
+
+## 3.2 並行プロトタイピング原則
+
+複数の並行アプローチを同時に開発 — 単一のソリューションを設計して急いで実行しない：
+
+```
+| HMW質問 | ソリューションA（保守的/漸進的） | ソリューションB（バランス型） | ソリューションC（大胆/破壊的） |
+|---|---|---|---|
+| [HMW1] | | | |
+```
+
+3つのソリューション品質ゲート：
+- ソリューションAは現在のアプローチより明確に優れているか？
+- ソリューションCはコアJTBDを本当に解決するか？
+- 3つのソリューションは本当に異なるか、同じアイデアのバリエーションではないか？
+
+## 3.3 Shreyas DoshiのPre-mortem
+
+**対象：中/高完成度 / オーディエンスがエンジニア/内部企画の場合**
+
+ソリューションにコミットする前に、すでに失敗したと仮定：
+
+```
+仮定：ソリューションXを選択し、[期間]後に失敗を宣言した。なぜ失敗したのか？
+
+| 失敗理由 | 可能性（高/中/低） | 予防可能性（高/中/低） | 予防措置 |
+|----------------|--------------------------|-------------------------------|-------------------|
+| | | | |
+```
+
+**セキュリティ失敗シナリオ**（少なくとも1つは必ず検討、特にユーザーデータを扱うプロダクト）：
+
+```
+| セキュリティリスク | 可能性 | 予防可能性 | 予防措置 |
+|---------------|-----------|----------------|-------------------|
+| ユーザーデータ漏洩（データベース侵入、不正APIアクセス） | | | |
+| 大量アカウント乗っ取り（ブルートフォース、クレデンシャルスタッフィング） | | | |
+| API悪用（レート制限なし、大量スクレイピング） | | | |
+| XSS / CSRF攻撃によるユーザー被害 | | | |
+| 機密データの意図しない露出（バージョン管理にシークレット、ログにパスワード） | | | |
+```
+
+> プロダクトがユーザー認証や機密データを含まない場合は、「該当なし」と記載し理由を説明。
+
+## 3.4 Gibson BiddleのGEM優先順位モデル（Netflix）
+
+```
+| 機能 | G（Growth） | E（Engagement） | M（Monetization） | 総合優先度 |
+|---------|-----------|----------------|------------------|-----------------|
+| | | | | |
+```
+
+**Impact / Effortマトリクス：**
+
+```
+| 機能 / ソリューション | インパクト（高/中/低） | 必要工数（高/中/低） | 象限 |
+|---|---|---|---|
+| | | | Quick Win / 戦略的 / 穴埋め / 回避 |
+```
+
+## 3.5 RICE定量的優先順位付け
+
+**対象：高完成度 / オーディエンスがデータサイエンティスト/経営層の場合**
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+
+| 機能 | Reach（影響ユーザー数/月） | Impact（0.25/0.5/1/2/3） | Confidence（%） | Effort（人月） | RICE Score |
+|---------|--------------------------|------------------------|----------------|----------------------|------------|
+| | | | | | |
+```
+
+**Impactスケール定義：**
+| スコア | レベル | 基準 |
+|-------|-------|----------|
+| 3 | 巨大 | ユーザー体験を根本的に変える；コアJTBDを直接解決 |
+| 2 | 高 | ユーザー体験を大幅に改善；North Star Metricに明確なポジティブインパクト |
+| 1 | 中 | 顕著な改善；一部のユーザーまたはシナリオに有用 |
+| 0.5 | 低 | 小さな改善；あれば良い程度 |
+| 0.25 | 最小 | ほとんど違いがない；メンテナンスレベルの作業 |
+
+**Confidence判断の参考：**
+- 100%：定量データに裏付け（A/Bテスト、ユーザーデータ）
+- 80%：定性データに裏付け（ユーザーインタビュー、競合検証）
+- 50%：合理的な仮説だが未検証
+- 20%：純粋な直感または推測
+
+> 「機能に優先順位を付けるのではなく、問題に優先順位を付けてください。機能はソリューションであり、問題の優先順位を確認した後にのみ意味があります。」 — Shreyas Doshi
+
+## 3.6 ユーザーストーリー表
+
+**対象：オーディエンスがエンジニアの場合**
+
+```
+| # | ユーザーストーリー | 受入基準 | 優先度 |
+|---|---|---|---|
+| US1 | [ペルソナ]として、[アクション]をしたい、そうすれば[価値] | | |
+```
+
+---
+
+## 📄 PRD出力フォーマット（オーディエンスがエンジニアの場合に使用）
+
+ユーザーが「PRDを作成して」「エンジニア向けのドキュメントを作って」と言った場合、関連する先行ステップをすべて統合し、以下の完全なフォーマットで作成：
+
+```
+# [プロダクト名] プロダクト要件ドキュメント
+
+**バージョン**: v[X.X]　**日付**: [日付]　**作成者**: [PM名]
+**ステータス**: 下書き / レビュー中 / 承認済み
+
+---
+
+## 1. 背景と目標
+
+**問題ステートメント**：[HMW質問から変換 — 誰のためにどんな問題を解決するか一段落で説明]
+**ターゲットペルソナ**：[どのペルソナ]
+**コアJTBD**：[ターゲット顧客] + [ジョブコンテキスト]で + [ジョブ]をしたい
+**成功メトリクス**：[North Star Metric + Hero Metric]
+
+---
+
+## 2. ソリューション概要（PR-FAQから）
+
+**プロダクトワンライナー**：[PR-FAQ見出し]
+**Aha Moment**：ユーザーが[アクション]を完了した時、コア価値を体験する
+**プロダクトポジショニング**：[April Dunfordポジショニングサマリー（完了している場合）]
+
+---
+
+## 3. 機能スコープ
+
+### MVP必須機能
+| 機能 | 説明 | 優先度 | 備考 |
+|---------|------------|----------|-------|
+| | | P0 | |
+
+### V2追加
+| 機能 | 説明 | 優先度 | 備考 |
+|---------|------------|----------|-------|
+| | | P1 | |
+
+### 明示的にやらないこと（Not Doing List）
+| やらないこと | 理由 |
+|-----------|--------|
+| | |
+
+---
+
+## 4. ユーザーストーリー
+
+| # | ...として | ...したい | そうすれば... | 受入基準 | 優先度 |
+|---|---------|-------------|------------|---------------------|----------|
+| US-001 | [ペルソナ] | [アクション] | [価値] | - [ ] 条件1 | P0 |
+
+---
+
+## 5. 機能仕様
+
+> 各P0機能について以下を文書化：
+
+### [機能名]
+- **説明**：[この機能が何をするか]
+- **トリガー条件**：[いつトリガーされるか]
+- **正常パス**：[ステップ1 → 2 → 3]
+- **エッジケース**：[エラーシナリオ、境界条件]
+- **受入基準**：
+  - [ ] [具体的なテスト可能な条件]
+  - [ ] [具体的なテスト可能な条件]
+
+---
+
+## 6. 技術的考慮事項
+
+**既知の技術的制約**：[エンジニアが知るべき制約]
+**依存関係**：[サードパーティサービス、API、他機能からの前提条件]
+**パフォーマンス要件**：[ロード時間、同時接続数等（該当する場合）]
+**セキュリティ要件**：[データ保護、権限等（該当する場合）]
+
+---
+
+## 7. リスクと仮定（Pre-mortemから）
+
+| リスク | 可能性 | インパクト | 予防措置 |
+|------|-----------|--------|-------------------|
+| | 高/中/低 | 高/中/低 | |
+
+**コア仮定**：[検証が必要な仮定 — 誤りが証明された場合、方向性の見直しが必要]
+
+---
+
+## 8. マイルストーンとタイムライン
+
+| マイルストーン | 目標日 | 含まれるもの |
+|-----------|------------|----------|
+| Alpha | | [テスト可能な最小バージョン] |
+| Beta | | [限定ユーザーテスト] |
+| Launch | | [正式リリース] |
+
+---
+
+## 9. 未解決の質問
+
+| 質問 | 担当者 | 予定解決日 |
+|----------|-------|------------------------|
+| | | |
+```
+
+---
+
+## 🗂️ 開発アーティファクト（オンデマンドトリガー）
+
+### フローチャート（Mermaid構文）
+
+ユーザーが「フローチャートを作って」と言った場合、User Storiesと機能仕様に基づいてMermaidフローチャートを生成：
+
+```mermaid
+flowchart TD
+    A[ユーザーがアクセス] --> B{ログイン済み？}
+    B -- はい --> C[メイン画面を表示]
+    B -- いいえ --> D[ログインへリダイレクト]
+    C --> E[コアアクションを完了]
+    E --> F[Aha Momentに到達]
+```
+
+含めるもの：メインユーザーフロー / 重要な分岐 / エラーシナリオ
+
+### DBスキーマ（Mermaid ERD構文）
+
+ユーザーが「DBスキーマを作って」と言った場合、MVP機能スコープに基づいてMermaid erDiagramを生成：
+
+```mermaid
+erDiagram
+    USER {
+        int id PK
+        string name
+        string email
+        datetime created_at
+    }
+    PRODUCT {
+        int id PK
+        string name
+        int owner_id FK
+    }
+    USER ||--o{ PRODUCT : "所有"
+```
+
+含めるもの：メインエンティティ / リレーションシップ / キーフィールド（FK、インデックス推奨）
+
+### UIワイヤーフレーム（HTMLワイヤーフレーム）
+
+ユーザーが「UIワイヤーフレームを作って」と言った場合、HTML + インラインCSSで低忠実度ワイヤーフレームを出力。含めるもの：
+- コアページ（User Storiesに基づいてページ数を決定）
+- グレースケール配色、ブランドカラーなし
+- 各要素の機能的な目的を注釈
+- Aha Momentが発生する箇所を注釈
+
+---
+
+## 📎 このステージのファイル統合ヒント
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| 既存PRD / 要件ドキュメント | 3.7 MVP | 既存機能リストをMVP境界決定の参考として抽出 |
+| 技術アーキテクチャドキュメント | 3.5 RICE（Effort） | 実際の技術的複雑さでEffortスコアを評価 |
+| デザインモックアップ / ワイヤーフレーム | 3.2 並行プロトタイピング + UIワイヤーフレーム | ソリューションのビジュアル参考として使用；既存 vs 新規デザインのニーズを特定 |
+| エンジニアリング見積りドキュメント | 3.5 RICE + 3.7 MVP | 仮定のEffortを実際の見積りに置き換え；MVPスコープを調整 |
+| 過去バージョンのポストモーテム | 3.3 Pre-mortem | 過去の失敗教訓でリスクリストを補完 |

package/i18n/ja/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# ステージ3：Develop — MVPスコープ定義
+
+## 3.7 MVPスコープ定義
+
+MVP判断基準：**コア仮説を検証できるか？ターゲットユーザーがプライマリJTBDを完全に体験できるか？**
+
+```
+| カテゴリ | MVP必須 | V2で追加 | 将来検討 |
+|---|---|---|---|
+| コア機能 | | | |
+| ユーザー体験 | | | |
+| 技術要件 | | | |
+```
+
+**やらないことリスト（Not Doing List）（同等に重要）：**
+
+```
+| やらないこと | 理由 |
+|-----------|--------|
+| | |
+```

package/i18n/ja/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# フェーズ4：Deliver — North Star + Aha Moment
+
+## 4.1 Marty CaganのEmpowered Teams原則
+
+**対象：高完成度 / 納品先オーディエンスがリーダーシップまたはクロスファンクショナルチームの場合**
+
+> 4.1 Empowered Teamsは、納品先オーディエンスがリーダーシップまたはクロスファンクショナルチームの場合のみ表示；それ以外はスキップ。
+
+```
+| 次元 | Feature Team（回避すべき） | Empowered Team（目標） |
+|-----------|---------------------|----------------------|
+| 割り当て | 機能リスト（Output） | 解決すべき問題（Outcome） |
+| 成功の定義 | 機能を期限通りにデリバリー | ユーザーとビジネスのメトリクスを達成 |
+| PMの役割 | 要件収集者とプロジェクトマネージャー | 問題探索者とソリューション検証者 |
+| エンジニアの役割 | 仕様を実装 | 問題探索とソリューション設計に参画 |
+```
+
+> "真のプロダクトディスカバリーは、エンジニアとデザイナーと**一緒に**行うものであり、PMが一人で完成品を渡すのではない。" — Marty Cagan
+
+**Lennyの3つのPM責務：**
+- **Shape**：ユーザーインサイト、データ、市場インテリジェンスを統合し、何を作るか決定
+- **Ship**：高品質のプロダクトが予定通りリリースされ、サプライズがないことを保証
+- **Synchronize**：すべてのステークホルダーがビジョン、戦略、目標、ロードマップで連携
+
+## 4.2 成功メトリクスフレームワーク（North Star + 3層シグナル）
+
+North Star Metricは以下を満たす必要があります：
+- ユーザーが受け取る実際の価値を反映（バニティメトリクスではない）
+- 継続的に成長可能（自然な上限がない）
+- チーム全体を1つの目標で連携させる
+
+```
+| 企業 | North Star Metric | なぜこのメトリクスか |
+|---------|-------------------|-----------------|
+| Airbnb | 宿泊数 | ホストとゲスト双方に提供された価値を表す |
+| Spotify | 月間リスニング時間 | ユーザーが本当に音楽を使い楽しんでいることを表す |
+| Facebook | DAU / MAU比率 | 習慣的な再訪問を表す |
+| Slack | 週間メッセージ送信数 | チームが本当にコラボレーションしていることを表す |
+| Salesforce | アクティブ顧客ACV（年間契約額） | 顧客が継続的にビジネス価値を得ていることを表す（B2B） |
+```
+
+**あなたのNorth Star Metric：**
+```
+North Star Metric：[ユーザーとプロダクトのために創出されるコア価値を表す単一の数値]
+定義：[正確な計算方法]
+なぜこのメトリクスか：[実際のユーザー価値を表す理由を説明。ビジネス成果だけではなく]
+```
+
+### 📝 North Star品質チェックリスト
+- ✅ ユーザーが受け取る価値を反映しているか？（売上やDAUではなく）
+- ✅ 継続的に成長可能か？（自然な上限がない）
+- ✅ チーム全員がこのメトリクスを見て何をすべきか分かるか？
+- ✅ ゲーミング可能か？（可能なら、ガードレールメトリクスが必要）
+- ✅ B2Bプロダクト：個々のユーザーだけでなく、組織レベルの価値を反映しているか？
+- ❌ よくある問題：売上をNorth Starにする（売上は結果であり、ドライバーではない）、メトリクスが複合的すぎてアクションに結びつかない
+
+**3層シグナルシステム（順番に達成する必要あり）：**
+
+```
+| レイヤー | メトリクスタイプ | 定義 | B2Cターゲット | B2Bターゲット |
+|---|---|---|---|---|
+| レイヤー1（前提条件） | コアアクション成功率 | ユーザーはプロダクトのコアアクションを完了したか？ | 30-40%以上 | 60-80%以上（ユーザーのモチベーションが高い） |
+| レイヤー2（価値の代理指標） | D14 / D28リテンション率 | ユーザーは戻ってくるか？ | コンシューマープロダクト 15-20%以上 | ロゴリテンション 90%以上；Net Revenue Retention 100%以上 |
+| レイヤー3（熱狂シグナル） | Sean Ellis Score | 「このプロダクトが使えなくなったら、どのくらいがっかりしますか？」 | 40%以上が「とてもがっかり」と回答 | 40%以上が「とてもがっかり」と回答 |
+| ガードレールメトリクス | 過剰最適化の防止 | 他の重要な次元が損なわれないことを保証 | コンテキスト依存 | コンテキスト依存 |
+```
+
+注意：レイヤー1はレイヤー2の前提条件です。コアアクション成功率が非常に低い場合、リテンションデータは無意味です。ユーザーがプロダクトの価値を体験する機会がなかったからです。
+
+## 4.4 Aha Momentデザイン
+
+```
+Aha Moment定義：
+ユーザーが[特定の行動]を完了した時、このプロダクトのコア価値を体験したことになる。
+目標：プロダクトに入ってから[X分 / Xステップ]以内にこの瞬間に到達させる。
+
+Aha Moment到達率：[目標%]
+現在の障壁：[Aha Momentにより早く到達することを妨げているものは？]
+改善プラン：[障壁をどう取り除くか？]
+```
+
+**例：**
+| プロダクト | Aha Moment | 時間目標 |
+|---------|-----------|-------------|
+| Slack | チームが2,000通目のメッセージを送信 | 最初の2週間 |
+| Dropbox | 最初のファイルが2台目のデバイスに同期 | 初回使用から10分以内 |
+| Zoom | 初回のワンクリック参加でスムーズな映像 | 初回使用時 |
+
+### 📝 Aha Moment品質チェックリスト
+- ✅ 具体的で追跡可能な行動か？（「プロダクトが便利だと感じる」ではない）
+- ✅ JTBDの機能的ジョブに直接結びついているか？
+- ✅ 時間目標は妥当か？（B2Cは初回使用内、B2Bはトライアル期間内が目安）
+- ✅ オンボーディングを設計してより早く到達させることができるか？

package/i18n/ja/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# ステージ4：Deliver — PMF + GTM + ビジネスモデル
+
+## 4.3 Todd Jackson（First Round Capital）の4段階PMFフレームワーク
+
+```
+| レベル | 名称 | 特徴 | あなたのタスク | 典型的な企業ステージ |
+|-------|------|----------------|-----------|----------------------|
+| レベル1 | 初期PMF | ソリューションに対して支払い意思のある顧客が3-5社見つかった | これらの初期ユーザーに深く対応し、再現可能なパターンを見つける | プレシード / シード |
+| レベル2 | 発展中のPMF | 口コミが始まるが、成長はまだ不安定 | スケーラブルな獲得チャネルを見つけ、リテンションを改善 | シード / シリーズA |
+| レベル3 | 強力なPMF | 「魚が船に飛び込んでくる」— 紹介が主要な成長ドライバーに | スケーラブルな需要チャネルを構築、効率メトリクスを改善 | シリーズA / B |
+| レベル4 | 極限のPMF | メトリクスが堅牢、企業は100人超、TAM拡大を検討 | 新市場への参入または新プロダクトのリリース | シリーズC以降 |
+```
+
+**Four P's（レベル1-2でPMFを見つけるための重要質問）：**
+1. Problem：解決している問題は本当に十分に緊急で重要か？
+2. Promise：プロダクトはユーザーにどんな約束をしているか？ユーザーはそれを信じるか？
+3. Product：プロダクトは本当にその約束を果たしているか？
+4. Pitch：ターゲットユーザーにどうやってプロダクトを発見させ、信じさせるか？
+
+## 4.7 GTM戦略（Go-to-Market）
+
+**対象：フルモード / 高完成度 / オーディエンスが経営層/セールス/マーケティングの場合**
+
+プロダクトが完成したら、どうやってターゲットユーザーに知ってもらい、使い始めてもらうか？
+
+### 獲得チャネルの選択
+
+```
+| チャネルタイプ | 最適な用途 | 典型的な手法 | 主要メトリクス |
+|-------------|----------|----------------|-------------|
+| Product-Led Growth（PLG） | ユーザーがセルフサーブで価値を体験できるプロダクト | 無料トライアル、Freemium、バイラル招待 | サインアップ転換率、アクティベーション率、招待率 |
+| コンテンツ＆コミュニティ | ターゲットユーザーが共通の情報ニーズやコミュニティを持つ | ブログ、SEO、コミュニティ構築、KOL | トラフィック、コンテンツ転換率、コミュニティエンゲージメント |
+| 有料獲得 | 高速検証またはROIが明確な場合 | SEM、ソーシャル広告、リターゲティング | CAC、ROAS、LTV/CAC |
+| Sales-Led | B2B高ACV、デモと交渉が必要 | SDR、AE、デモ、エンタープライズ契約 | パイプライン、成約率、ACV |
+| パートナーシップ | ターゲットユーザーが特定のプラットフォームやエコシステムに集中 | API統合、レベニューシェア、共同マーケティング | パートナーチャネル転換率、パートナー数 |
+```
+
+### 最初の100ユーザー獲得プラン
+
+```
+ターゲットユーザーのプロフィール：[ペルソナから]
+彼らがいる場所：[オンライン/オフラインで集まる場所]
+引きつけるフック：[PR-FAQのAha Momentから]
+試してもらう方法：[障壁を下げる方法]
+初期目標：[Y日以内にXユーザーにプロダクトを試してもらう]
+```
+
+### ローンチ戦略
+
+| 戦略 | 説明 | 最適な用途 |
+|----------|------------|----------|
+| クローズドベータ | 10-50人を手動で招待、深いフィードバックを収集 | PMFレベル1、プロダクトがまだ洗練中 |
+| オープンベータ | 公開だがBetaラベル付き、期待値を管理 | PMFレベル1-2、より多くのデータが必要 |
+| ソフトローンチ | 特定の市場やチャネルで控えめにリリース | フル露出なしで実環境テストが必要 |
+| フルローンチ | 全チャネル正式リリース | PMFレベル2-3、プロダクトが安定 |
+
+## 4.8 ビジネスモデル＆プライシング
+
+**対象：フルモード / 高完成度 / オーディエンスが経営層/セールスの場合**
+
+### 収益モデルの選択
+
+```
+| モデル | 仕組み | 最適な用途 | 主要メトリクス |
+|-------|-------------|----------|-------------|
+| Freemium | 無料基本プラン + 有料プレミアム | 大規模ユーザーベースのプロダクト、無料プランで価値を実証 | 無料→有料転換率（目標2-5%） |
+| サブスクリプション | 月額/年額課金 | 継続的な価値を提供するツールやサービス | MRR/ARR、チャーン率 |
+| 従量課金 | 使った分だけ支払い | API、クラウドサービス、トランザクションプラットフォーム | ユーザーあたり平均支出、利用成長率 |
+| 買い切り | 一括購入 | ツールソフトウェア、コース | 平均注文額、リピート率 |
+| トランザクションフィー | 取引ごとに手数料 | プラットフォーム、マーケットプレイス | GMV、テイク率 |
+| シートベース | ユーザーごとに課金 | B2Bコラボレーションツール | アカウントあたり平均シート数、拡張率 |
+```
+
+### 価値ベースのプライシングアラインメント
+
+```
+コアプライシング質問：
+1. プロダクトはユーザーにどれだけ節約させる、またはどれだけ稼がせるか？（価値アンカー）
+2. ユーザーは現在、代替品にいくら支払っているか？（競合参照）
+3. 価格はユーザーが受け取る価値に見合っているか？（公正性の認識）
+
+プライシング戦略：
+  - モデル選択：[Freemium / サブスクリプション / 従量課金 / ...]
+  - 価格帯：[価値アンカーと競合参照に基づく]
+  - 無料プランに含まれるもの：[Aha Momentに到達するのに十分だが、高度なニーズには不十分]
+  - 有料トリガーポイント：[どんな利用行動や量がアップグレードをトリガーするか？]
+
+⚠️ よくあるプライシングの間違い：
+  - 価格が低すぎ（「たいした価値がない」というシグナル）
+  - 無料プランが寛大すぎ（アップグレード動機がない）
+  - 価格と価値のミスアラインメント（機能ベースプライシング vs 価値ベースプライシング）
+  - B2Bで年間契約割引なし（キャッシュフロー安定性を逃す）
+```
+
+---
+
+## 📎 このステージのファイル統合ヒント
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| 財務データ / 収益レポート | 4.8 ビジネスモデル | 仮定を実際の収益構造に置き換え、プライシングの妥当性を評価 |
+| マーケティングチャネルデータ | 4.7 GTM | 実際のCAC、転換率などでチャネル選択を評価 |

package/i18n/ja/references/05c-validation-spec.md

@@ -0,0 +1,117 @@
+# ステージ4：Deliver — 仮説検証 + プロダクトスペックサマリー
+
+## 4.5 仮説検証プラン
+
+**対象：中/高完成度 / オーディエンスがデータサイエンティスト/自分自身の場合**
+
+```
+| コア仮説 | 検証方法 | 検証タイミング | 成功基準 | 仮説が誤りの場合... |
+|----------------|-------------------|-------------------|-----------------|----------------------------------|
+| | Alphaユーザーインタビュー / データ | | | |
+```
+
+原則：定性的検証（ユーザーインタビュー、日記調査）+ 定量的検証（データ）は同等の重み；自身の確証バイアスに警戒を。
+
+## 4.6 プロダクトスペックサマリー
+
+プロダクトスペックサマリーは、すべてのモードの最終成果物です（クイックモードは1ページの方向性サマリーを作成 — 構造は異なるが同じ精神）。
+プロダクトスペックサマリーは3セクションで構成され、異なる読み深さに対応：
+
+### セクション1：意思決定サマリー（30秒で読める）
+
+```
+**プロダクトワンライナー**：[PR-FAQ見出し]
+**誰のため**：[ターゲットペルソナを一文で]
+**コア価値**：[JTBD機能的ジョブ + 感情的ジョブを一文で]
+**North Star Metric**：[メトリクス名 + 定義]
+**現在のPMFレベル**：[レベル1-4 + 一文の説明]
+```
+
+### セクション2：実行境界（2分で読める）
+
+```
+**コアJTBD Statement**：[ターゲット顧客] + [ジョブコンテキスト]で + [ジョブ]をしたい
+**Aha Moment**：ユーザーが[アクション]を完了した時、コア価値を体験。目標：[X]以内に到達。
+**MVP必須機能**：[最も重要な3-5の機能/能力]
+**やらないこと（このバージョンで意図的に除外）**：[明示的な除外 + 理由]
+**主要仮説**：[検証が必要な2-3のコア仮説]
+**Pre-mortemトップリスク**：[失敗の最も可能性の高い2-3の原因]
+**Hero Metric**：[最も重要な1-2の成功メトリクス + 目標値]
+```
+
+### セクション3：ディープリファレンス（必要時に参照）
+
+```
+**JTBD分解**：
+  - 機能的ジョブ：
+  - 感情的ジョブ：
+  - 社会的ジョブ：
+**April Dunfordポジショニング**：
+  - 実際の競合代替品：
+  - ユニーク属性：
+  - ターゲットユーザーへのコア価値：
+  - ターゲット市場特性：
+  - 市場カテゴリー：
+**コアHMW質問**：[Defineステージから]
+**ソリューション説明**：[PR-FAQサマリーから]
+**ビジネスモデル**：[収益モデル + プライシング戦略（完了している場合）]
+**GTM戦略**：[初期獲得チャネル + ローンチ戦略（完了している場合）]
+```
+
+3セクション完了後、Claudeは**ユーザーに聞かれるのを待たず、以下の3セクションを積極的に追加する必要があります**：
+
+---
+
+### ⚠️ リスクレジスター
+
+企画プロセス全体で特定されたすべてのリスクを統合（出典：Pre-mortem + 機会評価 + 仮説検証）：
+
+```
+| リスクタイプ | リスクの説明 | 深刻度（高/中/低） | 緩和策はあるか？ |
+|-----------|-----------------|------------------------|---------------------|
+| 市場リスク | | | |
+| ユーザー仮定リスク | | | |
+| 技術リスク | | | |
+| 競合リスク | | | |
+| 実行リスク | | | |
+```
+
+---
+
+### 🔍 ギャップと盲点
+
+Claudeは会話フロー全体に基づいて、以下のタイプのギャップを積極的に特定：
+
+```
+| タイプ | 説明 | 推奨次ステップ |
+|------|------------|----------------------|
+| 未実行ステップ | [どのフレームワークがスキップされ、どんな盲点が生じる可能性があるか] | |
+| データ不足 | [どの意思決定が実際のユーザーデータではなく仮定に基づいているか] | |
+| 論理の飛躍 | [推論のどこに中間的なエビデンスが欠けているか] | |
+| 未検証の仮説 | [まだ検証方法のないすべてのコア仮説をリスト] | |
+| 不明確な定義 | [実行前により正確な定義が必要な概念] | |
+```
+
+---
+
+### 💡 追加推奨事項
+
+Claudeはプロダクトの特性、ステージ、既知のリスクに基づいて3-5の具体的でアクション可能な推奨事項を提供：
+
+```
+1. [最優先]：[具体的なアクション] — 理由：[なぜこれが最も重要か]
+2. [次の優先]：[具体的なアクション] — 理由：
+3. [三番目の優先]：[具体的なアクション] — 理由：
+...
+```
+
+推奨事項のカバー範囲：ユーザー検証方法、MVP境界の調整、競争戦略、メトリクス設計、チーム配置、次のマイルストーンの優先事項。
+
+---
+
+## 📎 このステージのファイル統合ヒント
+
+| アップロード内容 | 統合先 | 統合アクション |
+|-----------------|----------------|-------------------|
+| ユーザー行動データ（CSV / Excel） | 4.2 North Star + 4.3 PMF | 実際のリテンションとエンゲージメントデータでPMFレベルを評価；North Starベースラインを校正 |
+| Sean Ellis調査結果 | 4.3 PMF + 4.2 3層シグナル | Scoreを直接計算し、レイヤー3に記入 |