# Business Ideation

> ビジネス・サービスのアイデアを「発散 → 深掘り → 評価」の 3 フェーズで練り上げる汎用スキル（業界・会社に依存しない。特定事業ドメイン前提の類似スキルとは異なり、任意のテーマで使える）。 検討過程は notes ファイルを正本として育て、セッション中断・再開に対応する。 「事業アイデアを壁打ちしたい」「新しいサービスを考えたい」「このビジネス案を練りたい」 「アイデアをストレステストして」「事業案の弱点を潰したい」「副業のアイデアを深掘りしたい」 などと言ったら起動する。

- Skill: `mjcreativelab/business-ideation` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add mjcreativelab/business-ideation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mjcreativelab/business-ideation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mjcreativelab (https://skillmd.com/u/mjcreativelab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mjcreativelab/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/evidence-rules.md) と [references/note-templates.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](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](references/note-templates.md) に従う
- フェーズ境界では notes に `## Phase N <フェーズ名> 確定（YYYY-MM-DD）` セクションと manifest が存在することを確認してから次フェーズの references を Read する（**このファイル存在チェックが物理ゲート**。揃っていなければ書いてから進む）
- 中断するときは「## ユーザー判断待ち」セクションに未決事項を残す。再開はそこから

## Phase 0: 前提確認

最初のユーザー対話の前に [references/evidence-rules.md](references/evidence-rules.md) と [references/note-templates.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](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](references/phase-deepen.md) を Read して Phase 2 に進む。**確定セクションと manifest が notes に存在しない状態で phase-deepen.md を Read しない。**

## Phase 2: 深掘り

手順の詳細は [references/phase-deepen.md](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](references/phase-evaluate.md) を Read して Phase 3 に進む。**確定セクションと manifest が notes に存在しない状態で phase-evaluate.md を Read しない。**

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

手順の詳細は [references/phase-evaluate.md](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}` は使わない。サポートファイルは本ファイルからの相対パスで参照する（クロスツール配布のため）