mjcreativelab business-ideation — ビジネス・サービスのアイデアを練る
アイデアの 発散（Phase 1）→ 深掘り（Phase 2）→ 評価・ストレステスト（Phase 3） を 1 スキルで支援する。 ゴールは「アイデアを出すこと」ではなく、検証プラン表と撤退基準（Kill line）が書かれた、次の行動が明確なアイデアに仕上げること。検証プラン表・Kill line・申し送り表（handoff manifest）が notes に揃って初めて完了とする。
引数の解析
$ARGUMENTS を先頭から解析する：
--quick/--fullがあれば実行モードとして抽出する（後述）。両方あれば--fullを優先- 残りのテキストは「テーマまたはアイデアの種」として扱う（例:
/business-ideation --full 一人暮らし高齢者向けサービス） - モード指定がない場合、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 モード）」と明記して残す。
横断ルール（全フェーズ最優先）
- 二層エビデンスラベル: 数値と主張にはラベルを必ず付ける（ラベルなしの数値・断定は書かない）。定義と書式は references/evidence-rules.md を Phase 0 で Read して適用する。想定インタビューや AI が生成した「顧客の声」を実証データ扱いしない
- 数値のベース明示: 金額は「売上 / 粗利 / 営業利益」のどれか、「月次 / 年次」のどれかを毎回併記する
- 最低 3 案比較: ユーザーが 1 案持ち込みでも、対抗案 2 つを生成して比較表を出してから深掘り対象を決める（最初の思いつきに固定される first-idea trap の回避）。全案を本気で作る — 本命を引き立てるための当て馬を作らない
- 壁打ちでは問いを立てる、評価は評価フェーズで: Phase 1〜2 では案の良し悪しを結論づけない・却下で終わらせない（早すぎる否定の防止。1-1 の絞り込みスコアリングや 1-3 の足切りスクリーニングは候補を選ぶための装置であり、ここで禁じる「評価」には当たらない）。Phase 3 では逆に、根拠なく褒めない（甘い自己採点の防止）
- 例外必発火: 次を検出したらモードや進行中の手順にかかわらず必ず停止してユーザーに確認する — (a) 法規制ディールブレイカーの疑い、(b) 比較対象が 3 案を下回る、(c) 既に notes に確定した数値・前提と大きく矛盾する新情報
- ユーザーへの質問文は平易に: アルファベット略語は初出時に日本語を併記する（例: 「顧客獲得コスト（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 する。
- 意思決定アンカーの確認: この検討は何を決めるためのものかを最初に確認する
- 新しいアイデアをゼロから出したい（→ Phase 1 発散から）
- 持ち込みアイデアを練りたい（→ 対抗案 2 つを生成して Phase 1 の比較から）
- 既存案の Go / No-Go・ピボットを判断したい（→ この経路でも最低 3 案比較〔横断ルール 3〕は省略しない: 対抗案 2 つを生成して比較表を提示し、「## Phase 1 発散 確定」を notes に書いてから、Phase 2 の不足を埋めて Phase 3 へ）
- 前提の固定: 以下を確認して notes に記録する。不明・未定はそのまま「未定」と記録する（勝手に補完しない）
- 対象ドメイン・テーマ（あれば）
- 使える自社・自分のアセット（スキル、顧客基盤、データ、販路、資金など）
- 目標規模（例: 副業で月 10 万円の粗利 / 3 年で営業利益 1 億円。未定なら未定と記録）
- ガードレール = やらないことの制約（例: 在庫を持たない、既存事業と競合しない、特定業界は扱わない）。ここで挙がった項目が Phase 3 冒頭の all-or-nothing ゲートになる
- モード確認: 引数で未指定なら Quick / Full を確認する
- 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 が出て初めてこのスキルの成果物になる：
summary.md（notes と同じディレクトリ。書式は note-templates.md）- 検証プラン表（XYZ 仮説・成功閾値・反証されたら何が崩れるか、を含む）
- Kill line（数値・期限つきの撤退基準）と Decision Framework（検証成功なら → / 失敗なら →）
- handoff manifest（未確定の前提・推計のままの数値・規制論点・未解決論点。空欄禁止 — 該当なしも明記）
完了時に各フェーズの内容から次の一手 2〜3 個を、直前の分析の最重要発見に基づいて動的に提案する（固定文言にしない）。
注意事項
- 検討途中で会話が長くなり本 SKILL.md がコンテキストから消えた可能性がある場合は、次のフェーズに進む前に再 Read する
- 調査（市場規模の実データ収集・競合の網羅調査など）はこのスキルの範囲外。必要になったら「追加調査すべき項目リスト」を notes に書いてユーザーに渡す（WebSearch での軽い裏取りは可）
- サービス名・商標はすべて仮称扱い。正式な商標・ドメイン調査は別途必要である旨を summary に 1 行残す
${CLAUDE_SKILL_DIR}は使わない。サポートファイルは本ファイルからの相対パスで参照する（クロスツール配布のため）