startup-design

スタートアップの設計

スタートアップのアイデアを、漠然とした構想から検証済みの設計へと導く、構造化された複数フェーズのスキルです。分野ごとに整理された一連の Markdown ドキュメントを作成し、セッションが中断されても作業を継続できるよう、進捗を追跡する機能も備えています。

仕組み

このプロセスは、順番に実行する番号付きの8つのフェーズに加え、事前確認（フェーズ0.5）と顧客発見のゲート（フェーズ3.7）で構成されています。各フェーズで出力ファイルを作成し、進捗トラッカーを更新します。セッションが中断された場合は、最後に完了したチェックポイントから再開します。

PRE-FLIGHT → INTAKE → BRAINSTORM → RESEARCH → [Research Gate] → CUSTOMER DISCOVERY → [Interview Gate] → STRATEGY → BRAND → PRODUCT → FINANCIAL → VALIDATION

モード

フルモード（デフォルト）： 事前確認と顧客発見を含む、すべてのフェーズを順番に実行します。ゼロからスタートアップを徹底的に設計する場合に最適です。

ファストトラックモード： ユーザーが「手早く検証したい」「迅速に評価したい」などと述べた場合、または時間や予算が明らかに限られている場合は、短縮版を実行します。

1. フェーズ0.5（事前確認）— 必ず実行し、所要時間は5分です
2. フェーズ1（インテーク）— 質問は1ラウンドに短縮し、これまでに顧客と話した内容があれば記録します
3. フェーズ2（ブレインストーミング）— 5～8案ではなく、3案を作成します
4. フェーズ3（調査）— 第1波と第2波のみを実施します（顧客の声や流通に関する詳細な調査は省略）
5. フェーズ3.5（調査ゲート）— 続行するかどうかを判断するチェックポイントです
6. フェーズ3.7（顧客発見）— 創業者がこれまでに5回以上顧客と話している場合は、その内容を記録します。そうでない場合は、先に少なくとも3件のインタビューを実施します
7. フェーズ4（戦略）— リーンキャンバスのみを作成します
8. フェーズ5（ブランド）とフェーズ6（プロダクト）は省略します
9. フェーズ7（財務）— 収益モデルのみを対象とし、ステージA（仮定ベース）で実施します。詳細な予測は行いません
10. フェーズ8（検証）— スコアカードと、上位3つの実験のみを作成します

ファストトラックでは作成するファイルが少なくなりますが、根拠に基づいて続行するかどうかを判断できる明確なシグナルを創業者に示します。アイデアが検証を通過した場合、今後のセッションでフルモードに拡張できるよう、ファストトラックモードを使用したことを PROGRESS.md に記録してください。

言語

デフォルトの出力言語は英語です。ユーザーが別の言語で記述した場合、または言語を明示的に指定した場合は、すべての出力にその言語を使用してください。

---

参考資料： 最初に references/output-guidelines.md を一度読んでください。標準的なファイルのヘッダー／フッター（タイトル、日付、フェーズ、確信度、フラグ）、フェーズ間の相互参照形式、良い出力と悪い出力の品質例、プロセス途中で方向転換する場合の対応方法が定められています。

フェーズ0：再開確認

何よりも先に、作業ディレクトリ（またはプロジェクトのサブディレクトリ）に PROGRESS.md ファイルがあるか確認します。存在する場合は内容を読み、最後に完了していないフェーズから再開します。ユーザーには次のように伝えます。「前回のセッションの進捗が見つかりました。[phases]を完了しています。[next phase]から再開します。」

進捗ファイルがない場合は、フェーズ1から開始します。

---

Phase 0.5: 事前チェック

プロセス全体に時間をかける前に、簡単な健全性チェックを実施します。的を絞った検索を2～3件、最大5分で行います。目的は、すぐに失格となるような兆候を見つけ、創業者があらかじめ把握できるようにすることです。

次の3つを確認します。

1. 支配的なソリューションの確認 — この問題に対する、十分な資金を得て広く普及しているソリューションがすでに存在しますか？次のように検索します："{problem domain} software"、"{problem} tool site:producthunt.com"、"{problem} app reviews"。顧客が1万人以上いる明確な市場リーダーが存在する場合は、すぐに伝えます。これは中止する理由にはなりませんが、創業者は着手前に競争の実情を知っておく必要があります。

2. 先例となる失敗の確認 — まったく同じアイデアを試し、公に失敗した企業はありますか？次のように検索します："{startup idea} startup failed"、"{problem} startup shutdown"、"why {product category} failed"。過去の失敗は失格の理由ではなく、学びの機会です。しかし、知られていない過去の失敗は地雷になり得ます。

3. 規制・法的な即時中止要因の確認 — このアイデアが成立し得ない明白な法的理由はありますか？（例：特定の金融規制、対象地域のデータプライバシー法、ライセンス要件など。）簡単に検索するだけで、壁に向かって進むことを防げます。

**出力：**見つかった内容を、創業者に向けた短いメッセージ（箇条書き最大3～5項目）にまとめます。次の形式を使います。

## Pre-Flight Check

✅ No dominant incumbent found — space appears open.
⚠️  [CompanyX] tried a similar approach in 2021 and shut down in 2023.
    Key reason: [one sentence]. Worth understanding before proceeding.
✅ No obvious regulatory blockers identified for [target market].

→ Ready to proceed to intake. The above is context, not a verdict.

簡潔にまとめてください。これは注意喚起であり、完全な分析ではありません。この時点では、プロジェクトディレクトリもPROGRESS.mdもまだ存在しません。まず会話の中で調査結果を提示し、プロジェクトディレクトリを作成した後、Phase 1の出力ステップで{project-name}/00-intake/preflight.mdに保存します。

---

Phase 1: インテークインタビュー

以降のすべての質は、ここでどれだけ背景情報を引き出せるかに左右されます。急がないでください。丁寧に聞き取ることで、後から何時間も見当違いの方向に進むことを防げます。

参考：references/intake-questions.mdを読み、質問項目一式（アイデア、創業者、市場、ビジネス、制約）、盲点を明らかにする厳しい質問、インタビューの手法を確認します。

5つの質問領域すべてと厳しい質問を網羅します。これらはプロセス全体の雰囲気を定めるとともに、これは無条件に応援する場ではなく、率直な評価の場であることを示します。会話の流れに沿って一度に3～5問ずつ尋ね、曖昧な回答は掘り下げます。2～3回やり取りしたら、理解した内容を要約して、ユーザーに確認または修正してもらいます。

出力

聞き取った情報をすべて明確に整理し、{project-name}/00-intake/brief.mdにまとめて保存します。プロジェクト名はスタートアップのアイデアから作成します（ケバブケース。例：pet-health-tracker）。

プロジェクトのルートにPROGRESS.mdを作成し、プロジェクト名、開始日、言語、Pre-Flight（0.5）とCustomer Discovery（3.7）を含む全フェーズのチェックリスト、セッションの状態を記録するNotesセクションを記載します。Pre-FlightとPhase 1には完了の印を付けます。また、ディレクトリが作成されたこの時点で、Phase 0.5のPre-Flightの調査結果を00-intake/preflight.mdにも保存します。

---

Phase 2: ブレインストーミング

調査に踏み込む前に、アイデアの可能性を探ります。こうすることで、アイデアの最初のバージョンに早まって収束するのを防げます。

プロセス

1. 発散 — 中核となるアイデアのバリエーションを5～8個作成します。発想の枠を広げます。

   • ターゲット市場がまったく異なっていたらどうなりますか？
   • ビジネスモデルを逆転させたらどうなりますか？
   • 問題をもっと小さく、または大きくした形で解決したらどうなりますか？
   • 代わりに解決できる、隣接する問題はありますか？
   • 「10倍のバージョン」と「可能な限りシンプルなバージョン」は、それぞれどのようなものですか？

2. 分析 — 各バリエーションについて、次の点を記します。

   • 魅力的な点
   • リスクや難しい点
   • 競争環境がどう変わるか

3. 収束 — バリエーションをユーザーに提示します。どの要素に共感するかを一緒に見極めます。目的は、バリエーションを1つ選ぶことではなく、検討を通じて得た知見で元のアイデアを豊かにすることです。

4. 洗練 — ユーザーの反応を踏まえ、洗練されたアイデアを明確にまとめます。アイデアが大きく進化した場合は、ブリーフを更新します。

出力

{project-name}/00-intake/brainstorm.md に保存します。PROGRESS.md を更新します。

---

フェーズ 2.5：リサーチの深度評価

インテーク（該当する場合はブレインストーミングも）の後、市場の複雑さを評価し、リサーチの深度に関する推奨をユーザーに提示します。

参考： 複雑さのスコアリングマトリクス、ティアの定義、ウェーブの構成、ユーザーへの説明テンプレートについては、references/research-scaling.md を読んでください。

プロセス

1. インテークの内容をもとに、3つの要因をスコアリングします：市場の広さ（1～3）、既知の競合他社（1～3）、対象地域の範囲（1～3）
2. スコアを合計（範囲：3～9）し、ティアに割り当てます：Light（3～4）、Standard（5～7）、Deep（8～9）
3. リサーチ深度の表をユーザーに提示します（正確なテンプレートは research-scaling.md を参照）
4. ユーザーの回答を待ちます：light、deep、または推奨を承認する ok
5. 選択されたティアを PROGRESS.md に記録します

選択されたティアによって、フェーズ 3 の各ウェーブに参加するエージェント数と、各エージェントの検索ラウンド数が決まります。ティアごとの正確なウェーブ構成については、research-scaling.md を参照してください。

---

フェーズ 3：市場調査

このフェーズは、最も多くのリソースを必要とします。前のウェーブの調査結果をもとに進める、ウェブ調査の4つの連続したウェーブを実施します。

環境の検出

Agent ツールが利用可能か（Claude Code）、利用できないか（Claude.ai、その他の環境）を確認します。

• Agent ツールが利用可能： 以下の説明に従い、各ウェーブ内でサブエージェントを並行して起動します。これにより、時間を短縮できます（1ウェーブあたり約3～5分）。
• Agent ツールが利用不可（Claude.ai、ウェブ）： 調査を自分で順次実施します。各ウェーブでは、参照ファイルに記載された同じエージェントテンプレートに従い、メインの会話内で検索を1つずつ実行します。同じトピックを調査し、同じ調査原則を適用してください。出力品質は同等で、時間がかかるだけです。順次実行モードだからといって、ウェーブを省略したり、検索の深さを減らしたりしてはいけません。

ウェブ検索の利用可否

フェーズ 3 では WebSearch が必要です。Claude Code ではこのツールを常に利用できます。ユーザーが事前に許可していない場合、検索のたびにシステムから許可を求められます。ユーザーが許可しない場合、または WebSearch がまったく利用できない環境では、知識ベースの調査モードに切り替えます。トレーニングデータを使用し、すべての調査結果に [Knowledge-Based — not live data, verify independently] と明記し、信頼度評価を1段階下げ、重要な主張を創業者が手動で確認するよう推奨します。今後のセッションで調査がウェブ検索に基づいていないことがわかるよう、モードを PROGRESS.md に記録してください。

参考資料 — 各ウェーブで該当するファイルを読んでください。

• references/research-principles.md — 全体に適用するルール（情報源の品質、相互参照、定量化、検索失敗への対処）。最初に読んでください。
• references/research-wave-1-market.md — ウェーブ 1 のエージェントテンプレート（市場規模、トレンド、規制）
• references/research-wave-2-competitors.md — ウェーブ 2 のエージェントテンプレート（直接競合、間接競合、GTM 分析）
• references/research-wave-3-customers.md — ウェーブ 3 のエージェントテンプレート（顧客の声、需要、オーディエンス）
• references/research-wave-4-distribution.md — ウェーブ 4 のエージェントテンプレート（チャネル、地域への参入）
• references/research-synthesis.md — 生の調査結果を最終成果物にまとめる方法

原則のファイルと、現在実行しているウェーブのファイルだけを読んでください。すべてのウェーブのファイルを一度に読み込まないでください。

調査原則

• 各エージェントは、最低5～8件のウェブ検索を行い、検索を重ねるごとに詳しく調査します。
• 重要な調査結果はすべて、互いに独立した2～3件の情報源と照合します。
• 情報源の品質を評価します（Tier 1：アナリストレポート、Tier 2：テック系報道、Tier 3：ブログ／ソーシャルメディア）。
• すべてを定量化します。「市場は成長しています」ではなく「42億ドル、CAGR 12.3％」のように記述します。
• すべてのデータに日付を記し、18か月より古い情報にはフラグを立てます。
• 情報源間の矛盾は、一方を選ぶのではなく、そのまま記録します。

リサーチのウェーブ

エージェント向けブリーフ、検索戦略、出力先の詳細はウェーブのリファレンスファイルに記載されています。各ウェーブを開始する際は、該当するファイルを読んでください。

• ウェーブ 1：市場概況（エージェント 3 名）— A1 市場規模と経済性、A2 業界トレンドとタイミング、A3 規制とコンプライアンス（規制対象でない場合は A3 を省略）
• ウェーブ 2：競合分析（エージェント 3 名）— B1 直接競合の詳細分析、B2 間接競合と代替手段、B3 競合の市場投入戦略
• ウェーブ 3：顧客と需要（エージェント 3 名）— C1 顧客の声と課題点、C2 需要シグナルと市場検証、C3 ターゲット層のプロファイリング
• ウェーブ 4：流通とパートナーシップ（エージェント 2 名）— D1 流通チャネル、D2 地域と市場参入

次のウェーブを開始する前に、各ウェーブを完了させてください。重要な調査結果は次のウェーブに引き継いでください（ウェーブ 1 の調査結果をウェーブ 2 のエージェントに、競合リストと市場投入戦略の調査結果をウェーブ 3 に引き継ぐなど）。各ウェーブ内のエージェントは並行して実行するか、Agent ツールを使わずに順次リサーチブロックとして実行します。

生データ → 統合分析

すべてのエージェントは、生の調査結果を {project-name}/01-discovery/raw/ に保存します。すべてのウェーブが完了したら、4 つの完成度の高い成果物に統合します。

統合は書式設定ではなく、推論です。生の調査結果を判断へと変える段階です。何かを書き始める前に、各要素がどのように結び付くかを慎重に考えてください。どの情報源が食い違っており、どちらを信頼すべきか、証拠が実際に裏付けていることと創業者が期待していることの違い、そしてそれらがこのスタートアップにとって何を意味するのかを検討します。これはプロセス全体で最も大きな効果をもたらす思考作業であり、以降のすべてのフェーズの質に影響します。そのため、モデルが長時間の思考に対応しているなら、この段階で活用してください。質の低い統合では、入力を言い換えただけの整然とした文書ができます。質の高い統合では、同じ証拠から優れたアナリストが導き出す、表面的には見えにくい結論にたどり着きます。

統合では、次のことを行ってください。

• 研究領域をまたいで情報を結び付ける（競合の空白領域 → 顧客の課題 → ポジショニングの機会）
• 矛盾点を明らかにし、どのデータを信頼するか説明する
• 主要な主張ごとに確信度（高／中／低）を評価する
• 事実を列挙するだけでなく、明確な戦略的示唆を導き出す

出力ファイル

• {project-name}/01-discovery/market-analysis.md — 市場規模（TAM/SAM/SOM）、成長、成熟度、規制の概要、タイミングの評価
• {project-name}/01-discovery/competitor-landscape.md — 競合プロフィール、構造化された比較マトリックス（列：名称、製品、価格、ターゲット、資金調達、実績、主な強み、主な弱み）、ポジショニングマップ、プラットフォームリスク、脆弱性分析
• {project-name}/01-discovery/target-audience.md — ペルソナ、課題の優先順位、顧客が達成したいこと、使用する言葉、購買行動、チャネル
• {project-name}/01-discovery/industry-trends.md — 技術トレンド、投資シグナル、行動の変化、規制の動向、戦略的示唆
• {project-name}/01-discovery/confidence-dashboard.md — すべての調査にわたるデータ品質の概要。主要な主張ごとに、主張、情報源の階層（1/2/3）、裏付けとなる情報源の数、確信度（高／中／低）、データの経過期間を記載します。これにより、創業者は確かな根拠がある領域と、根拠が乏しい領域を把握できます。

PROGRESS.md を更新してください。

---

フェーズ 3.5a：調査の検証

統合が完了し、すべての成果物ファイルを書き終えたら、矛盾を見つけるために検証を行います。

参照： 検証プロトコル、共通チェック、スキル固有のチェックの全容については、references/verification-agent.md を読んでください。

プロセス

1. エージェント V1：検証 を起動します。01-discovery/ 内のすべての成果物ファイルを読み、ラベルのない主張、内部矛盾、確信度評価の一貫性、データギャップの不足、フラグの不足、データの古さ、同一ソースによる誤った裏付けがないかを確認します
2. V1 は、スタートアップの設計に特化したチェックも実施します。フェーズ間の一貫性（戦略に市場データが反映されているか、製品が顧客の課題に対応しているか、財務計画がビジネスモデルと整合しているか、検証で特定したリスクを扱っているか）を確認します
3. V1 は {project-name}/01-discovery/verification-report.md を作成します
4. 重大な問題が見つかった場合： 一時停止し、問題点をユーザーに提示します。先に修正するか、そのまま進めるかを尋ねます
5. 警告／情報のみの場合： 1 行で要約を示し、Research Gate に進みます

Claude.ai を使用している場合、または Agent ツールを利用できない場合は、同じプロトコルに従って、メインの会話内で自分で検証チェックを実施します。

---

フェーズ 3.5：Research Gate（進行可否のチェックポイント）

戦略から検証までに時間を投じる前に、調査結果に基づく率直な評価を創業者に示し、一時停止します。これは形式的な手続きではなく、判断のためのポイントです。

結論を書く前に、十分に考えて判断してください。最も強いシグナルと危険信号を比較し、どっちつかずの「場合によります」に平均化しないでください。致命的な欠点 1 つが有望なシグナル 5 つを上回ることもあれば、際立ったシグナル 1 つがいくつかの弱点を抱えたまま進む根拠になることもあります。創業者は、あなたの証拠の読み取りに基づいて、実際の時間と資金を投じようとしています。データが本当に何を裏付けているのか、慎重に考えてください。

簡潔な要約を示します。「調査で分かったことは次のとおりです。」市場規模、競争の激しさ、顧客需要の兆候、タイミングを取り上げます。その後、明確な推奨を示します。

• グリーンライト — データは続行を支持しています。最も強いシグナルを示します。
• イエローライト — シグナルが混在しています。懸念点と、成功に必要な条件を具体的に示します。
• レッドライト — データはこのアプローチに否定的です。調査で隣接する機会が明らかになった場合は、方向転換の案を提示します。

創業者に「これを踏まえて、戦略の策定に進む、アイデアの方向転換をする、またはここで終了する、のどれを希望しますか？」と尋ねます。決定を尊重しつつ、十分な情報に基づく判断であることを確認してください。ゲートの評価は {project-name}/01-discovery/research-gate.md に保存します。

---

フェーズ 3.7：顧客発見（インタビュー）

調査で分かるのは、市場を外側から見た姿です。顧客インタビューで分かるのは、内側から見た課題の実感です。これはプロセス全体で最も有力な検証手段であり、実際にカレンダー上の時間を確保する必要がある唯一の手段です（通常 1～2 週間）。

参考： インタビューのプロトコル、質問の構成、メモのテンプレート、統合ガイドについては、references/customer-interview.md をお読みください。

このフェーズを実施するタイミング

Research Gate でアイデアがグリーンライトまたはイエローライトとなった後に、このフェーズを実施します。レッドライトとなり、創業者が中止を選んだ場合は、このフェーズを省略します。

インタビューはセッションの流れを中断するため、創業者に明確な選択肢を提示します。

• 今すぐインタビューを実施する（推奨） — ここで一時停止し、数日かけてインタビューを実施してから、このチェックポイントから再開します（PROGRESS.md に状態が保存されます）。
• 延期して続行する — 調査データのみを基に戦略の策定へ進みます。その影響を明確に伝えてください。財務予測はステージ A（仮定ベース）のままとなり、最終評価ダッシュボードには「顧客インタビュー：実施数 0・延期」と表示され、インタビューはフェーズ 8 の検証プレイブックで最優先の実験になります。顧客と接触せずに立てた戦略は、検証済みの方針ではなく仮説です。この点を率直に伝えたうえで、しつこく促すことなく創業者の決定を尊重してください。

例外 — ファストトラックモード： インテークで創業者が過去に 5 件以上の顧客との会話を報告した場合は、インタビューテンプレートを使ってそれらの会話を記録し、先に進みます。すべての主張に [Founder-reported] のフラグを付けます。会話が 5 件未満の場合は、新たにインタビューを実施するよう勧めてください。最低件数はフルモードで 5 件、ファストトラックでは 3 件です。

プロセス

1. インタビュー対象者を特定する — 01-discovery/target-audience.md の主要ペルソナをもとに、対象者の具体的なプロフィールを定義します。最低5人にインタビューします。
2. インタビューを実施する — references/customer-interview.md のプロトコルに従います。各インタビューは25～30分を目安にし、課題に焦点を当て、製品の売り込みはしません。
3. 各インタビューを記録する — 参照ファイルのテンプレートを使って、{project-name}/00-intake/interviews/interview-{N}.md に保存します。
4. 統合する — すべてのインタビューが終わったら、次の内容を含む {project-name}/00-intake/interview-synthesis.md を作成します：課題の確認率、行動のシグナル（費用を払った人／代替策を構築した人）、重要なフレーズ、前提の監査。

インタビューゲート：続行か再評価か

統合後、創業者に簡潔な調査結果を提示し、次のゲートを適用します。

次の場合はフェーズ4に進みます：

• 5人中4人以上が、中心的な課題を明確に、促されずに確認する
• 少なくとも2人に行動のシグナルが見られる（何かに費用を払った、代替策を構築した、積極的に探した）
• 課題についての表現がインタビューを通じて一貫している

次の場合は一時停止して再評価します：

• 課題を確認した人が5人中3人以下（インタビューを増やした場合は、それに比例して判断します）
• 全員が「興味深い」と言うものの、行動のシグナルがない
• 彼らが説明する課題が、提案しているソリューションと一致しない

統合結果とゲートの判定を創業者に提示します。再評価が必要な場合、インタビューで解決する価値のある隣接課題が示されていれば、具体的なピボット案を提案します。アイデアのピボット、ターゲットの絞り込み、または中止は、創業者に判断してもらいます。

インタビューゲートの結果を PROGRESS.md に記録します。

---

フェーズ4：戦略

調査結果をもとに、戦略の基盤を定義します。各ドキュメントではフェーズ3の具体的な調査結果を参照してください。調査と切り離された戦略は、単なる推測にすぎません。

参照資料： Lean Canvas、April Dunford のポジショニング、Value Proposition Canvas、RICE／MoSCoW の標準的な定義については、references/frameworks.md を読んでください。各ファイルに必要な構成については、references/output-specs.md のフェーズ4のセクションを読んでください。

02-strategy/ に次のファイルを作成します：

• lean-canvas.md — 9つのブロックすべてを含む完全な Lean Canvas
• value-proposition.md — バリュープロポジションキャンバス（顧客の仕事、ペイン、ゲイン）、一文で表したバリュープロポジション、根拠
• business-model.md — 収益モデル、ユニットエコノミクス、拡張性、依存関係とパートナーシップ
• positioning.md — April Dunford の5つの構成要素
• go-to-market.md — ローンチ戦略、最初の100人の顧客を獲得する計画、優先順位を付けた成長チャネル、マイルストーン

PROGRESS.md を更新します。

---

フェーズ5：ブランド

チェックポイント： 開始前に、ポジショニング、ターゲット市場、ビジネスモデルを含む戦略の概要を創業者に簡潔に提示します。「これはあなたのビジョンを反映していますか？この戦略をもとにブランドを構築する前に、調整したい点はありますか？」と尋ねます。

戦略をブランドアイデンティティに落とし込みます。ブランドは後付けではなく、ポジショニングから自然に広がるものにします。

参照資料： 各ファイルに必要な構成については、references/output-specs.md のフェーズ5のセクションを読んでください。

03-brand/ に次のファイルを作成します：

• mission-vision-values.md — ミッション、ビジョン、実践的な価値観を3～5つ作成します。ユーザーが選択または組み合わせられるよう、2～3案を用意します
• tone-of-voice.md — パーソナリティの特性、「私たちはこうです／こうではありません」の例を含むボイスの原則、文章のサンプル、語彙ガイド
• brand-personality.md — ブランドアーキタイプ、感情的な属性、ビジュアルの方向性、競合と比べたときにブランドがどのように感じられるべきか

PROGRESS.md を更新します。

---

フェーズ 6：プロダクト

構築を開始したり、開発チームに説明したりできる程度に、プロダクトを定義します。機能を決める際は、01-discovery/competitor-landscape.md の競合機能分析と、01-discovery/target-audience.md の顧客の課題の優先順位を参考にしてください。何もないところから設計しないでください。

参考資料： 優先順位付けには、references/frameworks.md の RICE または MoSCoW を使用します。各ファイルに必要な構成については、references/output-specs.md のフェーズ 6 のセクションを確認してください。

04-product/ に以下を作成します：

• mvp-definition.md — 中核となる仮説、必須機能、あると望ましい機能、明確な対象範囲外項目、成功基準
• feature-prioritization.md — RICE/MoSCoW リスト、依存関係、T シャツサイズによる工数見積もり、構築順序
• user-journey.md — エンドツーエンドのジャーニーマップ、タッチポイントと感情、離脱リスク、「アハ体験」

PROGRESS.md を更新します。

---

フェーズ 7：財務

チェックポイント： 予測を行う前に、価格設定、目標顧客数、チーム規模、スケジュールについて、創業者に主要な前提を確認します。これらは数値に直接影響します。ここで誤ると、予測は現実離れしたものになります。

戦略を数値に基づいて立てます。前提については誠実に扱い、すべて推定値として明記し、その根拠を説明してください。01-discovery/market-analysis.md からユニットエコノミクスのベンチマーク（CAC、LTV、解約率、ACV）を、01-discovery/competitor-landscape.md から競合の価格設定を参照し、実データに基づいて予測を行います。

参考資料： ビジネスモデルの種類（SaaS、マーケットプレイス、E コマースなど）ごとの標準的な指標について、references/industry-benchmarks.md を確認してください。創業者の予測をこれらのベンチマークと比較し、通常の範囲から外れているもの（悲観的すぎるものと楽観的すぎるものの両方）に注意を促します。

2 段階の財務モデル

この段階での財務予測は、顧客インタビュー（フェーズ 3.7）で需要を裏付けるシグナルが得られたかどうかによって、次の 2 つの状態のいずれかになります。

ステージ A — 仮定ベース（デフォルト、収益化前の検証段階）： 実際のトラクションデータがない場合に使用します。すべての数値に [Assumption — unvalidated] と明記します。目的は、信頼できる予測を作成することではなく、財務構造を把握し、どの前提が最も大きな影響を与えるかを特定することです。

ステージ B — エビデンスベース（インタビューで強い行動シグナルが確認された場合）： インタビューで支払意思、既存の回避策への支出、または先行販売への関心が確認された場合に使用します。実際のシグナルに基づいて予測します。「インタビュー対象者 5 人中 3 人が、部分的な解決策に現在月額約 200 ドルを支払っていると回答した」は、ベンチマークよりも有用なデータです。これらの数値には [Estimate — grounded in interview data] と明記します。

すべての財務ファイルの冒頭に、ステージを示す 1 行の宣言を記載します。

**Financial Model Stage:** A — Assumption-Based | All projections are hypotheses to be tested, not forecasts.

または

**Financial Model Stage:** B — Evidence-Based | Key assumptions anchored to {N} customer interviews.

収益モデル

05-financial/revenue-model.md に記載します：

• 価格設定戦略とその根拠
• 収益予測（月 1～12、1～3 年目）。すべての前提を明示します
• 感度分析：主要な前提が ±30% 変化した場合の影響
• ステージ A の場合： モデルの信頼性を高める前に、検証実験が必要な前提を明確に示します

コスト構造

05-financial/cost-structure.md に記載します：

• 固定費（インフラ、ツール、給与）
• 変動費（ユーザーあたり、取引あたり）
• 一時費用（開発、法務、ローンチ）
• 損益分岐点分析

予測

05-financial/projections.md に記載します：

• 3 つのシナリオ：保守的、ベース、楽観的
• 各シナリオの主要な前提
• キャッシュフローのタイムライン
• 必要な資金とランウェイの計算
• 前提の感度分析表： 誤っていた場合に予測が最も大きく変わる上位 5 つの前提を列挙します。それぞれについて、現在の前提、50% 悪化した場合の影響、検証方法を記載します。

PROGRESS.md を更新します。

---

フェーズ 8：検証

このフェーズでは、アイデアがうまくいくかを検証するために、創業者が次に何をすべきかを具体的に示します。

参考資料： 各ファイルに必要な構成については、references/output-specs.md のフェーズ 8 のセクションをお読みください。

06-validation/ に以下を作成します：

• validation-playbook.md — 最も低コストなものから順に実験を並べ、それぞれについて検証する前提、方法、指標、合格・不合格の基準を記載します。フェーズ 3.7 でインタビューを先送りにした場合は、実験 #1 にします
• risk-analysis.md — 市場、プロダクト、ビジネス、チーム、財務の各リスクについて、発生可能性 × 影響度のマトリックスを作成し、軽減策と早期警戒シグナルを記載します
• assumptions-tracker.md — すべての重要な前提について、確信度、検証方法、ステータスを表に記載します
• experiment-design.md — 上位 3 つの実験について、詳細な設計と、そのまま使えるテンプレートを記載します
• kill-criteria.md — 実験に関連付けた、具体的で測定可能な撤退・方向転換の条件を 5～7 個記載します
• scorecard.md — 7 つの評価軸をそれぞれ 1～10 点で評価し、曖昧さのない結論の段落を記載します

正直でいてください。アイデアに弱点があるなら、はっきり伝えてください。目的は創業者の自尊心を満たすことではなく、適切な意思決定を支援することです。

PROGRESS.md を更新し、すべてのフェーズを完了済みにしてください。

---

最終成果物

すべてのフェーズが完了したら、まず会話内に最終評価ダッシュボードを表示します（references/output-guidelines.md の「Final Assessment Dashboard」セクションを参照）。これにより、創業者はファイルを読み込む前に、主要な調査結果をひと目で確認できます。

次に、最終ファイルを 2 つ作成します。

プロジェクトのルートにある README.md — エグゼクティブサマリー：

• スタートアップの概要を 1 段落で記載します
• 調査から得られた主な知見を記載します
• 戦略的なポジショニングの要約を記載します
• 主なリスクを 3 つ挙げ、軽減策を記載します
• 確信度ダッシュボードの要約（判明していることと推測にとどまること）を記載します
• 生成したすべてのドキュメントへのリンクを記載します

action-plan-30-days.md — 最初の 1 か月の具体的な週次計画：

• 第 1 週： 顧客発見（連絡する相手、質問する内容、会話の回数）
• 第 2 週： 検証実験（最初に実施する実験と具体的な手順）
• 第 3 週： MVP のスコープ設定（検証結果に基づき、何を作り、何を見せかけ、何を見送るか）
• 第 4 週： 継続・中止の判断と次のフェーズの計画
• 各週には、実行可能で具体的なタスクを 3～5 個含めます。「顧客調査をする」ではなく、「このテンプレートを使って、[ペルソナ] にコールド LinkedIn メッセージを 20 通送る」のように記載します

アンチパターンの確認： 最終化する前に、成果物全体を確認し、よくある創業者のアンチパターンがあれば特定します。「問題を探しているだけのソリューション」「風呂敷を広げすぎる」（一度に機能や市場を増やしすぎること）、「時期尚早なスケーリング」、「見栄えのする指標への固執」、「ステルス状態が長すぎること」、「ユニットエコノミクスの無視」がないか確認してください。該当するものがあれば、README に簡潔な 検出されたアンチパターン セクションを追加します。

---

徹底的な誠実さのプロトコル

参考資料： 完全なプロトコルについては、各セッションの開始時に references/honesty-protocol.md をお読みください。主なルールを以下にまとめます。

このスキルは、創業者の気分を良くするのではなく、適切な意思決定を支援します。誠実さは譲れません。

1. 真実を伝える。 市場が小さすぎる場合や、アイデアに致命的な欠陥がある場合は、率直に伝えてください。創業者の前提が調査データと矛盾する場合は、それを指摘してください。
2. 主張にラベルを付ける。 [Data]、[Estimate]、[Assumption]、[Opinion] のタグを使用してください。推定値を事実として提示しないでください。
3. 各フェーズで懸念を明示する。 各フェーズの出力の末尾に、重大な懸念／注意すべき懸念のセクションを設けてください。
4. 明確な結論を示す。 スコアカードでは、8～10 点は続行、6～7 点は条件付き、4～5 点は懸念あり、1～3 点は中止・方向転換を推奨してください。
5. 根拠に基づく。 データがない場合は、そう伝えてください。捏造しないでください。
6. 実行可能な内容にする。 すべてのドキュメントで、創業者が次にすべきことを示してください。
7. すべてを記録する。 各フェーズの後に PROGRESS.md を更新してください。

---

参照ファイル

references/ ディレクトリには、参考ドキュメントが含まれています。現在のフェーズに必要なものだけを読んでください。

ファイル	読むタイミング	約行数	目的
output-guidelines.md	各セッションの開始時（1回）	約126	ファイルのヘッダー／フッター、相互参照、品質の例、方針転換への対応
honesty-protocol.md	各セッションの開始時（1回）	約69	誠実さに関するルール、データラベル、アンチパターン
research-principles.md	フェーズ3の開始前（1回）	約54	情報源の品質、相互参照、データの不足
research-wave-1-market.md	Wave 1 のエージェントを起動するとき	約206	市場規模、トレンド、規制に関するエージェントのテンプレート
research-wave-2-competitors.md	Wave 2 のエージェントを起動するとき	約220	直接・間接競合、GTM 分析に関するエージェントのテンプレート
research-wave-3-customers.md	Wave 3 のエージェントを起動するとき	約233	顧客の声、需要、オーディエンスに関するエージェントのテンプレート
research-wave-4-distribution.md	Wave 4 のエージェントを起動するとき	約132	チャネル、地理的な参入に関するエージェントのテンプレート
research-synthesis.md	すべての Wave の完了後、最終ファイルの作成前	約110	生の調査結果を成果物に統合する方法
research-scaling.md	インテーク後、フェーズ3の前	約122	複雑度のスコアリング、ティアの定義、Wave の構成
verification-agent.md	統合後、フェーズ3.5の前	約117	検証プロトコル、共通チェックとスキル固有のチェック
intake-questions.md	フェーズ1（インテーク）中	約60	質問一式、難しい質問、インタビューのテクニック
output-specs.md	フェーズ4、5、6、8の実施中	約180	戦略、ブランド、プロダクト、検証に関するファイル別の仕様
customer-interview.md	フェーズ3.7（顧客発見）の前	約189	インタビュープロトコル、質問の構成、統合ガイド
frameworks.md	フェーズ4（戦略）、フェーズ6（プロダクト）、フェーズ8（検証）の実施中	約107	Lean Canvas、Dunford、VPC、RICE／MoSCoW の定義
industry-benchmarks.md	フェーズ7（財務）の実施中	約66	ビジネスモデルの種類ごとの標準指標