validate-market

プロジェクト／市場を検証する

検証監査を実施します。成果物は、次の問いに答える1つのドキュメントです。その事業は成り立つのか、ほかに誰が参入しているのか、どこに勝機があるのか、次に取るべき具体的な行動は何か。創業者の貴重な数カ月を守るための監査なので、あらゆる場面で励ましより正直さを優先します。

厳守事項：実装はしません。 コード、スキャフォールディング、名前の変更、サイトの変更は行いません。出力はドキュメントのみです（およびその敵対的レビュー）。ユーザーがドキュメントの保存場所を指定した場合はそこに保存します。指定がない場合は、リポジトリ内なら docs/research/<slug>-market-viability-audit.md、リポジトリ外なら ./<slug>-market-viability-audit.md を既定の保存先とします。

姿勢（必須）

• 関心は需要ではありません。 スター、ウェイトリスト、称賛、「興味深いですね」は何の証拠にもなりません。行動こそが証拠です。お金を払う、壊れたときに困る、促されずに再び使う、誰かがそれを中心にワークフローを組み立てる、といった行動です。
• 現状維持が最大の競合です。 安価な代替策（コピー＆ペースト、スプレッドシート、設定ファイルの慣例）は、競合表に載るどのスタートアップよりも手ごわい相手です。必ず最初に挙げ、ユーザーが現時点で支払っているコストを見積もります。
• すべてについて立場を明確にします。 「考え方はいろいろあります」や「うまくいくかもしれません」とは書きません。手元にある証拠に基づいて、何がうまくいき、何がうまくいかないのかを述べ、どのような証拠があれば判断を変えるのかを示します。
• 些細な不便か、深刻な痛みか。 少数の人にとって切実な痛みなのか、多数の人にとって軽微な痛みなのかを明言し、実際にリーチできるのはどの層なのかを示します。
• 反証となる証拠から始めます。 判定の次に置く最初のセクションは、正直な需要の現状です。たとえ見栄えが悪くても（特に見栄えが悪い場合はなおさら）、隠さず示します。

フェーズ 0：意見を述べる前に事実を確認する

判断をひとつでも書く前に、検証可能な数値を集めます。これを省略してはいけません。これこそが監査を単なる印象論から区別するものです。

• リポジトリ：経過年数、スター数、フォーク数、コントリビューター数（gh repo view <repo> --json stargazerCount,forkCount,createdAt,isPrivate）。
• 稼働中のプロダクト：実際のエンドポイントにアクセスします（ランディングページ、公開ディレクトリ、統計 API に curl を実行）。「デプロイ済み」と「利用されている」を区別します。
• ユーザーが提示できる分析データ、収益、ウェイトリスト、インストール数を確認します。明らかでなければ質問します。
• 基準となる問いを適用します。明日それがなくなったら、プロジェクト外の誰かが困るでしょうか。 答えを書き留めます。「いいえ」なら、その事実がドキュメント全体を左右します。すべての提案は、その状況を改善することを前提にしなければなりません。

フェーズ 1：問題と足がかり

• 創業者自身の言葉で問題を述べます。引用してください。創業者の表現には、売り込み文句よりも足がかりがよく表れていることが多いからです。
• 最も狭い足がかりを特定します。今週、誰かが導入できる1つのフローです。動詞から始める1文で示します（「X を A から B に10秒で移す」）。価値を説明するのにプラットフォーム全体が必要なら、それはロードマップではなく危険信号だと明記します。
• 見つけられる人物としてターゲットユーザーを定義します。 役割、よく集まる場所、すでにお金を払っているものを示します。「開発者」や「大企業」は対象を絞る条件であって、人物像ではありません。

フェーズ 2：市場環境の調査

WebSearch では、一般化されたカテゴリ用語を使い、製品名や秘匿情報は決して使わないでください。少なくとも次の 4 つの検索を行い、上位の検索結果を読みます。

1. カテゴリの標準とプラットフォームの現状（「<カテゴリ> protocol landscape <年>」）。
2. カテゴリの資金調達とスタートアップ（「<カテゴリ> startups <年> funding」）。
3. 同じ切り口の課題を解決する、直接的な隣接製品（「<一般的に説明した切り口> tool」）。
4. 最近、大手企業が取り込んだもの（「<大手プラットフォーム> <カテゴリ> features <年>」）。

次の 3 点を明確にまとめます。

• その領域を誰が押さえているか、そして本当にオープンなのか。
• 機能か、それとも会社か？ 上位のプラットフォーム（IDE、OS、大手のチャットツール、研究機関）が 1 回のリリースで取り込めるものか？ 取り込みまでの期間を正直に示します。
• タイミングに関する主張はすでに勝負がついているか？ 市場に説明する必要がなくなっているなら、これは良い面と悪い面の両方があります。説明コストはかかりませんが、わかりやすい切り口はすでに押さえられています。

WebSearch が利用できない場合は、その旨をドキュメントに明記し、分布内の知識に基づいて進め、それが分かるようにラベルを付けます。

フェーズ 3：前提

提案全体の基盤となる前提を 3～5 個書きます。それぞれに検証済み（根拠を示す）または仮定（創業者がどう検証するかを示す）と明記します。その後、自分が最も強くこだわっている前提に反論してみます。崩せない場合は、どのような外部の出来事があれば崩れるかを示します。

フェーズ 4：第三者による先入観のない評価

あなたの推論を見ていない相手から、セカンドオピニオンを得ます。

• codex が PATH 上にある場合：製品、段階と需要の証拠、創業者が示した課題、市場環境の概要、前提をまとめた構造化コンテキストブロックを一時ファイルに組み立て、それに対して codex exec を読み取り専用で実行し、次の点を尋ねます：（1）最も有力な見解を最大限に擁護する、（2）実際に何を作るべきかを明らかにする詳細を 1 つ引用する、（3）誤っている前提を 1 つ挙げ、それを証明する証拠を示す、（4）チャネル、指標、打ち切り基準を含む 48 時間の計画を立てる。
• それ以外の場合：同じプロンプトで、新しいサブエージェント（Agent ツール）を起動します。重要なのは、新しいコンテキストです。自分の結論を貼り付けてはいけません。

ドキュメントでは、第三者評価の最も鋭い指摘を引用し、それを採用（前提を修正）するのか、反論（その理由を示す）するのかを明確に述べます。自分自身に黙って同意することこそ、このフェーズが防ごうとしている失敗です。

フェーズ 5：ドキュメントを書く

構成（名称は適宜調整し、順序は維持します。結論を最初に、判断の前に根拠を示します）：

1. 見出し＋冒頭で結論。 1 段落で、事業として成り立つか、制約となる要因は何か、次に何をすべきかを述べます。曖昧な表現は避けます。
2. 問題提起。
3. 需要の根拠（率直な評価）。 外部の根拠を先に、内部の根拠を後に示し、明確に分けます。「誰かが困るのか？」への答えも含めます。
4. 現状。 回避策と、それにかかるコストを示します。小さな不便か、深刻な問題かを判断します。
5. ターゲットユーザーと最も狭い切り口。
6. 市場とタイミング。 重要な数値を 2～4 個、出典とともに示します。
7. 競争環境。 表には、事業者、概要、重複する領域、実際の脅威を含めます（ステータス quo を 1 行目に置き、脅威の各セルには「理由」を 1 行で記載）。その後、構造的な考察を 1～3 点示し、機能と企業のどちらが重要かという問いも含めます。
8. 強み。 実在し、検証可能なものだけを挙げます。「創業者と問題の適合性」は該当します。「優れた技術」は、流通やコスト構造を変える場合に限り該当します。
9. 弱みとリスク。 創業者が読みたくないもの（名称／商標、プラットフォームによる吸収、単独創業者、未定義の価格設定）も含めます。それぞれについて、対処策とそのコストを述べます。
10. 前提条件（フェーズ 3 の内容に、初見の読者向けの修正を適用したもの）。
11. 複数モデルの視点（フェーズ 4 の内容。各立場は維持します）。
12. 検討したアプローチ。 2～3 案を示します。必ず 最小限の検証スプリント（数週間、ほぼ費用ゼロ、アウトリーチ優先）を含め、通常は横方向のポジショニング変更も含めます。それぞれの労力、リスク、利点、欠点、再利用できる既存資産を示します。
13. 推奨案。 1 つ選びます。率直な答えが「選ぶのではなく、順序を決める」なら、日付を含む順序を示します。
14. ビジネスモデルの概要。 検証後まで明示的に保留します。何もないところから料金プランを作るのではなく、最も近い実績ある類例（例：Tailscale のプレイブック）を示します。
15. 未解決の問い。 それぞれ、答えをどこから得るかを示します。
16. 成功基準：事前に定める 3 段階（下記の厳密性チェックリストを参照）。
17. 課題。 今週実行する、具体的で現実の行動を 1 つ示します。「開発する」ではなく、相手の名前と人数を含むアウトリーチまたは観察の行動にします。

事前に定める基準の厳密性チェックリスト

これらは、敵対的レビューで確実に指摘される抜け穴です。レビュー前に解消してください。

• 撤退を含め、すべての分岐に結果を定めます。 「撤退（または再定義）」では判断になりません。継続、中間、撤退のそれぞれについて、次の行動と期限を明記します。
• 段階の優先順位を明示します。 結果が混在することもあります。どの段階を優先するかを記載します（例：「撤退条件を最初に評価する」）。
• 分母を固定します。 「最大 100 件に声をかける」と「返信が 5 件未満」は基準が曖昧です。最低限の実施条件を追加します（「80 件以上に連絡しなければ撤退の判断は有効とせず、努力不足と判断して 1 週間延長する」など）。
• 用語を定義します。 「真剣な返信」「実のある会話」「アクティブユーザー」は、それぞれ、トリガーとして使う箇所で定義を 1 行ずつ記載します。
• 日程計算を成立させます。 推奨案が外部の期限（バッチ応募やローンチ期間など）を目標にする場合、スプリントの終了日と文書作成期間を合わせて、その期限に間に合うようにします。文書内で計算を示します。
• 測定手段を用意します。 基準の評価に計測機能が必要な場合、その計測機能の確認を第 1 週のタスクとして明記し、自己申告による代替手段も用意します。
• 第 1 週の予定を組めるようにします。 コールドアウトリーチには返信までの時間がかかります。第 1 週の目標は「完了」ではなく「予定済み」とします。創業者の稼働時間がフルタイムか、夜間・週末のみかを明記し、パートタイムの場合の案も示します。
• アウトリーチでは創業者の DM スキルではなく、市場を測ります。 2 つ以上のチャネルと、コンバージョン率ではなく絶対数の基準を求めます。

フェーズ 6：敵対的レビューの反復

1. 新しいサブエージェント（Agent ツール）を起動し、この会話ではなくドキュメントだけを読ませます。5 つの観点からレビューさせます。完全性（約束した質問にすべて回答しているか）、一貫性（セクション間に矛盾がないか、スケジュールが実際のカレンダーに照らして成立するか）、明確さ（創業者が何も尋ねずに行動できるか）、範囲（監査のみで、余計な内容がないか）、実現可能性（指定された期間内に、この創業者が実行できるか）です。番号付きの指摘リストと 1～10 のスコアを求めます。外部の市場に関する主張はファクトチェックせず、内部ロジックだけを確認するよう伝えます。
2. ドキュメント内の実際の問題をすべて修正します。レビュー担当者の指摘が誤っている場合は、指摘を黙って削除せず、ドキュメント自体の中で反論します。
3. もう一度レビューを依頼します。再レビューは 2 回までとするか、新たな指摘が表面的なものになった時点で終了します。残った意見の相違は、「Reviewer concerns」の項目の下にドキュメント内で記録します。
4. ユーザーに、実施したラウンド数、見つかった問題と修正した問題、最終スコアを報告します。

最後に

最終メッセージの末尾に、2 文での判定、ドキュメントの場所、3 段階の判断基準、1 週目の課題を記載します。創業者のプロフィールが適合する場合（実際の課題、専門分野の知識、主体性）、その旨を明確に述べ、該当する次のステップ（アクセラレーターへの応募、デザインパートナーへのアプローチ）を示します。ただし、その根拠がドキュメントに記載されている場合に限ります。市場でまだ検証されていない取り組みを称賛してはいけません。