Business ideation

business-ideation — ビジネス・サービスのアイデアを練る

アイデアの 発散（Phase 1）→ 深掘り（Phase 2）→ 評価・ストレステスト（Phase 3） を 1 スキルで支援する。 ゴールは「アイデアを出すこと」ではなく、検証プラン表と撤退基準（Kill line）が書かれた、次の行動が明確なアイデアに仕上げること。検証プラン表・Kill line・申し送り表（handoff manifest）が notes に揃って初めて完了とする。

引数の解析

$ARGUMENTS を先頭から解析する：

1. --quick / --full があれば実行モードとして抽出する（後述）。両方あれば --full を優先
2. 残りのテキストは「テーマまたはアイデアの種」として扱う（例: /business-ideation --full 一人暮らし高齢者向けサービス）
3. モード指定がない場合、Phase 0 でモードを確認する

再開の検出: 引数のテーマに対応する notes（docs/business-ideas/<スラグ>/notes.md）が既に存在する場合は新規開始せず、notes 末尾の「## ユーザー判断待ち」セクションと最後の「確定」見出しを読み、そこから再開する。再開時も Phase 0 と同様に references/evidence-rules.md と references/note-templates.md を Read し、現在地のフェーズに対応する references（phase-deepen.md / phase-evaluate.md）を物理ゲート確認のうえ Read してから続行する。

実行モード

モード	発散	深掘り	評価
Quick（軽い壁打ち）	案出しは 3 視点発散のみ（1-2〜1-4 の記述・スクリーニング・選択ゲートは全モード共通）	必須セット（問題ファースト変換・課題実在性 3 点・収益モデル宣言・Why Now）	ガードレールゲート + Red-team（3 件上限）+ 検証プラン表 + Kill line
Full（本気の検討）	掛け合わせ総当たり含む全手順	全手順	全手順

Quick でも出口の完了条件（検証プラン表・Kill line・manifest）は同じ。省略されるのは途中の装置であって出口ではない。未実施の手順の成果物は捏造せず、確定セクション・summary の該当項目に「未実施（Quick モード）」と明記して残す。

横断ルール（全フェーズ最優先）

1. 二層エビデンスラベル: 数値と主張にはラベルを必ず付ける（ラベルなしの数値・断定は書かない）。定義と書式は references/evidence-rules.md を Phase 0 で Read して適用する。想定インタビューや AI が生成した「顧客の声」を実証データ扱いしない
2. 数値のベース明示: 金額は「売上 / 粗利 / 営業利益」のどれか、「月次 / 年次」のどれかを毎回併記する
3. 最低 3 案比較: ユーザーが 1 案持ち込みでも、対抗案 2 つを生成して比較表を出してから深掘り対象を決める（最初の思いつきに固定される first-idea trap の回避）。全案を本気で作る — 本命を引き立てるための当て馬を作らない
4. 壁打ちでは問いを立てる、評価は評価フェーズで: Phase 1〜2 では案の良し悪しを結論づけない・却下で終わらせない（早すぎる否定の防止。1-1 の絞り込みスコアリングや 1-3 の足切りスクリーニングは候補を選ぶための装置であり、ここで禁じる「評価」には当たらない）。Phase 3 では逆に、根拠なく褒めない（甘い自己採点の防止）
5. 例外必発火: 次を検出したらモードや進行中の手順にかかわらず必ず停止してユーザーに確認する — (a) 法規制ディールブレイカーの疑い、(b) 比較対象が 3 案を下回る、(c) 既に notes に確定した数値・前提と大きく矛盾する新情報
6. ユーザーへの質問文は平易に: アルファベット略語は初出時に日本語を併記する（例: 「顧客獲得コスト（CAC）」）。成果物本文（notes / summary）は専門用語のままでよい

ドキュメント正本方式（notes の運用）

• 検討の正本は docs/business-ideas/<テーマスラグ>/notes.md（Phase 0 で場所を変更可）。会話はワーキングメモリ、notes が記録
• 確定した決定は、その場で notes に追記する。フェーズ末尾でまとめて書かない（セッションが落ちても確定分は残る）
• 見出し規約・申し送り表（handoff manifest）・summary の書式は references/note-templates.md に従う
• フェーズ境界では notes に ## Phase N <フェーズ名> 確定（YYYY-MM-DD） セクションと manifest が存在することを確認してから次フェーズの references を Read する（このファイル存在チェックが物理ゲート。揃っていなければ書いてから進む）
• 中断するときは「## ユーザー判断待ち」セクションに未決事項を残す。再開はそこから

Phase 0: 前提確認

最初のユーザー対話の前に references/evidence-rules.md と references/note-templates.md を Read する。

1. 意思決定アンカーの確認: この検討は何を決めるためのものかを最初に確認する
   • 新しいアイデアをゼロから出したい（→ Phase 1 発散から）
   • 持ち込みアイデアを練りたい（→ 対抗案 2 つを生成して Phase 1 の比較から）
   • 既存案の Go / No-Go・ピボットを判断したい（→ この経路でも最低 3 案比較〔横断ルール 3〕は省略しない: 対抗案 2 つを生成して比較表を提示し、「## Phase 1 発散 確定」を notes に書いてから、Phase 2 の不足を埋めて Phase 3 へ）
2. 前提の固定: 以下を確認して notes に記録する。不明・未定はそのまま「未定」と記録する（勝手に補完しない）
   • 対象ドメイン・テーマ（あれば）
   • 使える自社・自分のアセット（スキル、顧客基盤、データ、販路、資金など）
   • 目標規模（例: 副業で月 10 万円の粗利 / 3 年で営業利益 1 億円。未定なら未定と記録）
   • ガードレール = やらないことの制約（例: 在庫を持たない、既存事業と競合しない、特定業界は扱わない）。ここで挙がった項目が Phase 3 冒頭の all-or-nothing ゲートになる
3. モード確認: 引数で未指定なら Quick / Full を確認する
4. notes 初期化: docs/business-ideas/<テーマスラグ>/notes.md が無ければ assets/idea-notes-template.md を雛形にして作成し、上記 1〜3 を「## Phase 0 前提 確定（YYYY-MM-DD）」として記録する

前提（目標規模・ガードレール等）が途中で変わった場合は、静かに反映せず「前提が変わったので Phase N からやり直すか、差分だけ直すか」を明示的に確認する。

Phase 1: 発散

1-1: 案出し

持ち込みアイデアがある場合: そのアイデアの狙い（誰のどんな困りごとか）を確認したうえで、同じ困りごと・同じアセットから発想した対抗案を 2 つ以上生成し、3 案以上の比較表に載せる。

ゼロから出す場合（Quick / Full 共通）— 3 視点発散: 次の 3 視点から各 3〜5 案を出す。視点ごとに発想の軸を変えることで、似た案への収束を防ぐ：

視点	発想の軸
事業家	収益構造・市場の伸び・アセットの転用（何が儲かるか）
顧客代弁者	深い困りごと・我慢している不便・感情的な負（何が痛いか）
オペレーター	実現しやすさ・既存オペレーションの流用・コスト構造（何が回るか）

Full モードのみ — 掛け合わせ総当たり: 「面白さ」だけで選ぶと恣意性が入る。テーマの隣接領域を 5〜8 個挙げ、各領域の代表的なペインを抽出し、領域 × ペインの掛け合わせ候補を 15〜20 件列挙して 4 軸（各 ★1〜3）で採点する：

軸	内容
ペインの深さ	お金を払ってでも解決したいレベルか
自分・自社の必然性	Phase 0 のアセットなしには成立しない構造か
市場規模ポテンシャル	目標規模に対して十分な母数が桁感で見込めるか
掛け算の創発性	アセット × アイデアで足し算でなく掛け算の価値が出るか

合計 9 点以上をコア候補、6〜8 点をストレッチ候補とし、多様性（領域・収益モデル）を意識して 3〜5 案をドラフトする。スコアが低いのに直感で残す案は、残す理由を明示して残してよい。

1-2: 案の記述フォーマット

各案は次を必ず埋める（「鍵となる仮定」は必須欄 — 発散と深掘り・評価を接続する結合組織）：

### 案 <ID>: <仮称>
- 一言説明: <誰のどんな困りごとを何で解決するか>
- 使うペイン: <困りごと>（主張ラベル付き）
- 使うアセット: <Phase 0 のアセットとの対応>
- 収益モデル仮説: <誰から何の対価をもらうか>
- 鍵となる仮定: <この案が成立するために真でなければならないこと 2〜3 件>

1-3: 出口スクリーニング（深掘り投資前の足切り確認）

深掘りに進む候補案それぞれについて、深掘り後に詰む要因を先に軽くスクリーニングする：

• 経済性の桁感: 対象市場の母数 × 客単価の桁が目標規模と整合するか。初期投資が必要な案は累積赤字の桁感も 1 行で
• 法規制ディールブレイカー: 案のドメインから関係しうる規制領域を挙げ（例: 中古品売買 → 古物営業法、決済預かり → 資金決済法、健康関連 → 薬機法）、✅ 問題なさそう / ⚠️ 確認が必要 / ❌ 根幹に抵触の疑い で仮判定する。⚠️ 以下は確認先（専門家・省庁・業界団体）を notes に記録する。このスキルは「法務確認済み」を自称しない — ここでの判定はあくまで机上の仮判定
• ❌ の疑いが出た案は横断ルール 5 に従い停止してユーザーに確認する

1-4: ユーザー選択ゲート

比較表（案 × 一言説明 × 鍵となる仮定 × スクリーニング結果）を提示し、AskUserQuestion で深掘りに進める案を 1〜3 案選んでもらう（選択理由も一言もらう）。落ちた案は notes に「見送り理由」付きで残す。

AskUserQuestion が使えない環境では、同じ選択肢を通常の質問文で提示する（以降の選択ゲートも同様）。

Phase 1 → 2 ゲート

notes に「## Phase 1 発散 確定」セクション（選定案・見送り案・理由・manifest）を書き出してから、references/phase-deepen.md を Read して Phase 2 に進む。確定セクションと manifest が notes に存在しない状態で phase-deepen.md を Read しない。

Phase 2: 深掘り

手順の詳細は references/phase-deepen.md（Phase 1 → 2 ゲート通過後に Read）。選定した案ごとに、問題の実在性 → 顧客の絞り込み → 提供価値 → 事業構造（構造類型・フライホイール・KSF〔Key Success Factor: 成功のために絶対に勝つべきポイント〕）→ タイミング → 収益モデル → 仮定の洗い出し、の順で解像度を上げる。

Quick モードの必須セット: 問題ファースト変換（2-1）/ 課題実在性 3 点（2-3）/ 収益モデル宣言（2-8 の 3 分類と WTP アンカーまで）/ Why Now（2-7）。残りはユーザーが求めた場合のみ。

Phase 2 → 3 ゲート

notes に「## Phase 2 深掘り 確定」セクションと manifest を書き出してから、references/phase-evaluate.md を Read して Phase 3 に進む。確定セクションと manifest が notes に存在しない状態で phase-evaluate.md を Read しない。

Phase 3: 評価・ストレステスト

手順の詳細は references/phase-evaluate.md（Phase 2 → 3 ゲート通過後に Read）。ガードレールゲート（all-or-nothing）→ Red-team → Pre-mortem → 模倣シミュレーション → 整合チェック → 3 値判定サマリ → 検証プラン表 + Kill line → 差し戻しルーティング、の順で案を攻撃し、生き残った部分を検証可能な形にする。

Quick モードの必須セット: ガードレールゲート / Red-team（3 件上限）/ 検証プラン表 + Kill line（評価の過程で ❌・弱・Kill 基準抵触が出た場合はモードによらず差し戻しルーティングも必須）。

完了の定義

以下がすべて notes / summary に存在して完了とする。「発散と深掘りが本体、評価はおまけ」ではない — 検証プラン表と Kill line が出て初めてこのスキルの成果物になる：

1. summary.md（notes と同じディレクトリ。書式は note-templates.md）
2. 検証プラン表（XYZ 仮説・成功閾値・反証されたら何が崩れるか、を含む）
3. Kill line（数値・期限つきの撤退基準）と Decision Framework（検証成功なら → / 失敗なら →）
4. handoff manifest（未確定の前提・推計のままの数値・規制論点・未解決論点。空欄禁止 — 該当なしも明記）

完了時に各フェーズの内容から次の一手 2〜3 個を、直前の分析の最重要発見に基づいて動的に提案する（固定文言にしない）。

注意事項

• 検討途中で会話が長くなり本 SKILL.md がコンテキストから消えた可能性がある場合は、次のフェーズに進む前に再 Read する
• 調査（市場規模の実データ収集・競合の網羅調査など）はこのスキルの範囲外。必要になったら「追加調査すべき項目リスト」を notes に書いてユーザーに渡す（WebSearch での軽い裏取りは可）
• サービス名・商標はすべて仮称扱い。正式な商標・ドメイン調査は別途必要である旨を summary に 1 行残す
• ${CLAUDE_SKILL_DIR} は使わない。サポートファイルは本ファイルからの相対パスで参照する（クロスツール配布のため）