solo-validate

/validate

スタートアップのアイデアをエンドツーエンドで検証します。KB を検索し、Manifest との整合性、S.E.E.D. のニッチチェック、悪魔の代弁者による反転、STREAM の 6 層分析を実施し、技術スタックを選定して PRD を生成します。

理念： 検証では、楽観的にならず、誠実であるべきです。悪いアイデアは、構築に 3 か月を費やすより、5 分で見切るほうが賢明です。目標は励ますことではなく、真実を見極めることです。

MCP ツール（利用可能な場合）

MCP ツールが利用可能な場合は、CLI よりも優先して使用します。

• kb_search(query, n_results) — 関連ドキュメントをナレッジベースから検索します
• project_info() — アクティブなプロジェクトとその技術スタックを一覧表示します
• web_search(query) — 廃業したスタートアップや競合の失敗事例を検索します

MCP ツールが利用できない場合は、Grep/Glob/WebSearch にフォールバックします。

手順

1. $ARGUMENTS からアイデアを解析します。空の場合は、検証したいアイデアをユーザーに尋ねます。

2. 関連する知識を検索します： MCP の kb_search ツールが利用可能な場合は、直接使用します。

   • kb_search(query="<idea keywords>", n_results=5) それ以外の場合は、ローカルで検索します。
   • プロジェクトとナレッジベース全体の .md ファイルを対象に、アイデアのキーワードを Grep で検索します 見つかった関連ドキュメント（既存のアイデア、フレームワーク、機会）を要約します。

3. 詳細調査（任意）： このアイデアの research.md が存在するか確認します（docs/ または現在の作業ディレクトリを確認してください）。

   • 存在する場合：内容を読み、調査結果を STREAM 分析と PRD の記入に反映します（競合、課題、市場規模）。
   • 存在しない場合：先に詳細調査を行うか、ユーザーに確認します。行う場合は、/research <idea> を実行してから戻るよう伝えます。行わない場合は、そのまま続行します。

4. Manifest 整合性チェック（厳格に実施）：

   このスキルに同梱されている references/manifest-checklist.md を参照し、9 つの原則と 6 つの危険信号からなる完全なチェックリストを確認します。各項目に照らしてアイデアを評価してください。これは形式的な確認ではありません。Manifest に違反している場合は、ソフトな中止フラグとなります。

   各原則について、準拠しているか、違反しているかを評価します。違反している場合は、該当する原則を具体的に示します。

   主な原則（詳細はチェックリストを参照）：

   1. プライバシー優先／オフライン優先
   2. 1 つの課題 → 1 つの機能 → リリース
   3. AI は機能ではなく基盤
   4. 完璧さより速度を重視（数日で MVP）
   5. アンチフラジャイルなアーキテクチャ
   6. 無理なく収益を上げる
   7. 搾取に反対する
   8. サブスクリプション疲れ
   9. ロボットではなく、クリエイター

   スコア： 違反 0 件 = 完璧、1～2 件 = 要注意、3 件以上 = 強い KILL シグナル。

   誠実に評価してください。 アイデアが原則に反するなら、そう明言します。無理に整合性を取り繕わないでください。

5. S.E.E.D. ニッチチェック（詳細分析の前に簡潔に実施）：

   次の 4 つの観点からアイデアを採点します。

   • S — 検索性： 検索順位を上げられるか？上位 10 件にフォーラムや Reddit があるか、新しい巨大サイトが少ないか、動画による占有がないか？
   • E — 根拠： 実際の引用や URL で裏付けられた、本当の課題があるか？それとも仮説にすぎないか？
   • E — 容易さ： 既存の技術スタックで 1～2 日以内に MVP を作れるか？重い依存関係がないか？
   • D — 需要： ロングテールキーワードが存在するか？明確な収益化の道筋があるか？

   中止フラグ（いずれかに該当したら、直ちに停止します）：

   • 上位 10 件の SERP が大手メディアや百科事典に独占されている
   • 新しい競合コンテンツ（公開から 60 日未満）が、すでに十分に網羅している
   • 実際のユーザーの課題を示す根拠がない（創業者の仮説のみ）
   • 最適な技術スタックを使っても、MVP に 1 週間を超える時間が必要

   中止フラグが 1 つでも該当する場合は、その理由を説明して KILL を推奨します。STREAM には進まないでください。

6. 悪魔の代弁者（反転）：

   「問いをひっくり返してみましょう。確実に失敗させるには、どうすればよいでしょうか？」— STREAM レイヤー 3（反転）

   この手順は必須です。肯定的な採点を行う前に、積極的にアイデアを潰そうとしてください。目的は、構築しない理由を見つけることです。 6a. 逆転思考 — 失敗する5つの方法： このアイデアが失敗する具体的な方法を5つ挙げてください。一般的なリスク（「競争」など）ではなく、根拠のある具体的なシナリオを示してください。

   • 具体的にどの競合がこの事業を打ち負かす可能性がありますか？（名称、資金調達額、戦略）
   • どのようなユーザー行動がこの事業を成り立たなくしますか？（解約データ、支払意思）
   • どのような規制・法的事象がこの事業を終わらせますか？（具体的な法律、判例）
   • どのような技術的制約がこれを阻みますか？（レイテンシ、コスト、精度）
   • どのような市場の動向によって、この「機会」が幻になりますか？

   6b. 廃業したスタートアップの検索： 類似の試みをして失敗した、または方向転換したスタートアップを検索してください。

   • WebSearch："<idea category>" startup failed OR pivoted OR shut down
   • WebSearch："<competitor>" pivot OR layoffs OR shutdown
   • 見つかった場合：何が原因で失敗しましたか？同じリスクがここにも当てはまりますか？

   6c. ユニットエコノミクスのストレステスト（research.md がある場合）： 悲観的な前提でユニットエコノミクスを再計算してください。

   指標	楽観的	現実的	悲観的
   月次解約率	10%	30-40%（業界データ）	50%+（初年度）
   平均継続期間	10か月	2.5-3か月	1.5か月
   LTV	（価格 × 10）	（価格 × 2.5）	（価格 × 1.5）
   CAC	<$20	$30-50	$50-80
   LTV:CAC	>3:1	~1:1	<1:1（採算割れ）

   悲観的な LTV:CAC が 1 未満の場合は、重大なリスクとして明示してください。

   6d. 「空白市場」テスト： 分析で「空白」の市場セグメントや価格帯のギャップが見つかった場合、次の点を確認してください。

   • なぜ空白なのでしょうか？ 機会でしょうか、それとも失敗の跡でしょうか？
   • このポジショニングをまさに試みて失敗した企業を検索してください
   • この価格帯では需要が存在しないために、そのセグメントが空白なのでしょうか？

   6e. マニフェストとの矛盾を率直に示す： ステップ4の調査結果を再確認してください。見つかったマニフェスト違反ごとに、矛盾を明確に述べてください：「これは X を必要とし、その理由は Z であるため、原則 Y に違反します。」 矛盾を正当化して見過ごしてはいけません。進めるかどうかを決めるのはユーザーであり、このスキルではありません。

7. STREAM 分析： アイデアを6つのレイヤーすべてに照らして検討してください。

   各レイヤーの質問を含む6レイヤーのフレームワーク全体については、このスキルに付属する references/stream-layers.md を参照してください。

   各レイヤーについて、肯定的評価と否定的評価の両方を示してください。フレームワークの実際の質問を使用してください。

   • レイヤー1（範囲）： 地図≠領土、単純さ、境界 — どの前提が未検証ですか？
   • レイヤー2（時間）： エントロピー、リンディ効果 — これは5年後にも存在していますか？
   • レイヤー3（道筋）： 逆転思考（悪魔の代弁者の調査結果を使用）、二次的影響 — その影響がもたらす影響は何ですか？
   • レイヤー4（利害）： 非対称性、反脆弱性 — 悲観的な数値で見た実際のリスクとリターンはどうですか？
   • レイヤー5（対象者）： 評判、ネットワーク — 信頼を積み上げていますか、それとも損なっていますか？
   • レイヤー6（メタ）： 有限性、バランス — 限られた時間を費やす価値がありますか？ミッションに合致していますか？

   採点ルール：

   • 各レイヤーを1〜10で採点します
   • 悪魔の代弁者の分析で重大な問題が見つかった場合、該当するレイヤーのスコアを必ず下げてください
   • マニフェストとの整合性に違反がある場合、レイヤー6（メタ）のスコアを必ず下げてください
   • 最終スコア = 加重平均（メタと利害は1.5倍の重み）

8. 足がかりとなるセグメント（最初のターゲット市場）：

   調査ペルソナ（利用可能な場合）またはアイデアの説明をもとに、足がかりとなるセグメントを定義してください。

   • 具体的に誰ですか？ — 「誰でも」ではなく、狭いセグメントを定めます（例：「月収3〜8千ドルのフリーランスデザイナー」であり、「フリーランサー」ではありません）
   • なぜ最初にこの層を狙うのですか？ — 接点を持ちやすく、課題が深刻で、支払意欲があり、具体的なチャネルを通じてリーチできます
   • リーチするチャネルは？ — 具体的なチャネルを1つ（subreddit、コミュニティ、ニュースレター）
   • 次に隣接するセグメントは？ — 足がかりとなる市場を獲得した後、どこへ拡大しますか？

   これは PRD の ICP セクションと /launch の GTM 戦略に反映されます。

9. 価格モデル（理由を添えた2〜3案）：

   競合の価格設定（research.md より）とマニフェストの原則に基づいてください。サブスクリプション疲れは現実のものです。可能な場合は、一回限りの購入、または誠実で透明性のある価格設定を優先してください。

   モデル	価格	理由	マニフェストとの整合性
   買い切り	$X	運用コストがない → 継続課金もない	最適（ロックインなし）
   フリーミアム	無料 / $X/mo	サーバーコストをまかなうため、サブスクリプションが妥当	正直であれば問題なし
   従量課金	Y あたり $X	使った分だけ支払う	良好（透明性がある）

   マニフェスト（templates/principles/manifest.md）に基づくルール：

   • 運用コストがかからないなら、無料にするべきです
   • 可能であれば、サブスクリプションより買い切りを優先します
   • ロックインとは逆のものを作ります。ユーザーが所有するツール、ユーザーが管理するデータを実現します
   • アップグレードを強制するためのダークパターンや人為的な制限は設けません

   推奨するモデルを選び、その理由を説明してください。PRD に含めてください。

10. スタックの選定： 調査データから自動検出したうえで、確認するか質問します。

自動検出ルール（research.md の product_type フィールドまたはアイデアのキーワードに基づく）：

• product_type: ios → ios-swift
• product_type: android → kotlin-android
• product_type: web + AI/ML に関する言及 → nextjs-supabase（または nextjs-ai-agents）
• product_type: web + ランディングページ／静的サイト → astro-static
• product_type: web + コンテンツサイト + 一部ページで SSR が必要（CDN データ、トランスクリプト、動的コンテンツ） → astro-hybrid
• product_type: web（デフォルト） → nextjs-supabase
• product_type: api → python-api
• product_type: cli + Python のキーワード → python-ml
• product_type: cli + JS/TS のキーワード → nextjs-supabase（モノレポ）
• エッジ／サーバーレスのキーワード → cloudflare-workers

確信度が高い状態で自動検出できた場合は、選択したスタックを示して続行します。 曖昧な場合（例：Web とモバイルのどちらも考えられる場合）は、AskUserQuestion を使って上位 2～3 個の選択肢を提示し、質問します。 MCP project_info が利用可能な場合は、参考としてユーザーの既存のスタックを表示します。

11. PRD を生成： 現在のプロジェクトディレクトリに docs/prd.md として PRD ドキュメントを作成します。アイデアからケバブケースのプロジェクト名を導き出します。

PRD は Definition of Done を満たす必要があります：

• 問題の説明が 30 語以上（誰が、いつ、なぜ今困っているのか）
• ICP + JTBD — 対象セグメント + 2～3 個の Jobs-to-be-Done
• 3～5 個の機能。それぞれに測定可能な受け入れ基準を設定
• 3～5 個の KPI。単位（日次／週次）と目標値を設定
• 各 KPI の Kill／Iterate／Scale のしきい値
• 3～5 個のリスクと軽減策
• Honest Assessment セクション（Devil's Advocate のステップから）
• ユニットエコノミクス：楽観的と悲観的の両方（両方の列）
• 失敗したスタートアップの先例（誰がこれを試み、失敗したか？）
• マニフェストとの衝突（原則違反の明示的な一覧）
• ビーチヘッドセグメント — まず誰を対象にするか、その理由、リーチ方法
• 価格モデル — 推奨案とマニフェストとの整合性チェック
• 主要なパッケージを含む技術スタック
• アーキテクチャ原則（SOLID、DRY、KISS、スキーマ優先）
• エビデンス優先 — 数値／主張には出典 URL を付けます（利用可能な場合は research.md から）

12. 出力サマリー：
    • アイデア名と一行での説明
    • S.E.E.D. スコア（S/E/E/D をそれぞれ低／中／高で評価）
    • マニフェストとの整合性（9 原則のうち X 個を満たすか、違反項目を一覧表示）
    • 2 つのスコア：
      • 楽観的スコア（0～10）：最良のケースを想定
      • 現実的スコア（0～10）：悲観的なユニットエコノミクス、実際の解約率、資金調達済みの競合他社を考慮
    • Devil's Advocate による最大の発見（作るべきでない最も強い理由を 1 つ）
    • 主なリスクと主な強み
    • 生成された PRD のパス
    • 「もし私が間違っているとしたら…」 — 判断を変えることになる、単一の前提を明示
    • 推奨する次のアクション（以下から 1 つ）：
      • /research <idea> — エビデンスが弱い場合、まずデータを集めます
      • /scaffold <name> <stack> — 現実的スコアが 7 以上の場合、構築します
      • フェイクドアテスト — 現実的スコアが 5～7 の場合、コーディングの前に $20 をかけてランディングページの仮版を用意します
      • KILL — 現実的スコアが 5 未満、またはキルフラグが発動した場合
      • PIVOT — アイデアに価値はあるものの、現在のアプローチではうまくいかない場合（具体的な方向転換案を提案）

重要事項

• Devil's Advocate のステップ（ステップ 6）を省略しないでください。必須です。
• references/manifest-checklist.md と references/stream-layers.md（このスキルに同梱されています）を必ず読んでください。実際のチェックリストが記載されています。
• 速度よりも品質と誠実さを重視してください。ステップ 4、6、7 には時間をかけてください。
• KILL の推奨は妥当で価値のある結果です。何カ月もの無駄な努力を防げます。

使用するタイミング

• 重大な開発に着手する前
• /research または /swarm の後に、評価して PRD を作成するとき
• 複数のアイデアから選ぶとき（各アイデアを実行し、現実的なスコアを比較してください）
• 友人からスタートアップについて意見を求められたとき（優しくではなく、率直に伝えてください）

よくある問題

S.E.E.D. のキルフラグが発動する

原因： アイデアが基本的なニッチ市場の実現可能性を満たしていません（SERP が独占されている、根拠がない、MVP が複雑すぎる）。 対処法： これは意図された動作です。キルフラグは時間を節約します。アイデアの方向転換を検討するか、より深い根拠を得るために /research を実行してください。

research.md が見つからない

原因： /research のステップを省略しています。 対処法： このスキルでは、最初に調査するかどうかを尋ねます。より強力な PRD を作成するには、/validate の前に /research <idea> を実行してください。

スタックの自動検出が間違っている

原因： プロダクトの種類が曖昧です（ウェブ向けともモバイル向けとも解釈できます）。 対処法： 曖昧な場合、スキルは AskUserQuestion を使って尋ねます。アイデアの説明でプロダクトの種類を明示してください。

スコアが高すぎるように見える

原因： 確証バイアスにより、賛成する根拠を見つけた時点で調査をやめています。 対処法： Devil's Advocate のステップが必須になりました。省略した場合、スコアは無効です。全面的な反転を行って再実行してください。

マニフェストとの矛盾を正当化してしまう

原因： アイデアには魅力があるものの、原則に反しています。 対処法： 矛盾を明示してください。「これは X に反しています。理由は Y です」と伝えるほうが、何も言わないより有益です。続行するかどうかを決めるのはユーザーであり、スキルではありません。