ln-201-opportunity-discoverer

パス: ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とした相対パスです。

機会発見者

タイプ: L3 ワーカー
カテゴリ: 2XX プランニング

既存のプロダクトの次の成長方向を見つけるための、トラフィック優先のアプローチです。

コアとなる考え方

アンチパターン: アイデア → アンケート → プロダクト → 「トラフィックはどこ？」 正しい方法: トラフィック → ニッチ → MVP → 既存の需要に合わせてローンチ

開発者の90％が陥る失敗

大半が失敗する理由は次のとおりです。

1. 類似事例のないアイデアを考案する
2. 5人に「お金を払いますか？」と尋ねる（ホットドッグでも「はい」と答えるでしょう）
3. まとまった金額をかけてプロダクトを作る
4. 「それではトラフィックを確保しましょう」とローンチする
5. トラフィックが存在しないこと、これまで一度も存在しなかったことに気づく

コールドトラフィックから購入されないもののために、マーケターがファネルを構築することはありません。

トラフィック優先の原則

#	原則	アンチパターン
1	プロダクトより先にトラフィックが存在する	作ってからトラフィックを探す
2	アンケートは不要 — 実際の検索需要を測定する	「買いますか？」と尋ねる
3	既存の需要 — 人々が検索しているものに合わせてローンチする	新しいカテゴリを作る
4	1つのチャネル、1つのアイデア — 手を広げない	5つのチャネルを一度にテストする
5	早期に打ち切る — 早く失敗し、時間を無駄にしない	すべてのアイデアを同じように評価する

参考となる方法論

Marc Andreessen（pmarca）:

「実践的なレベルで市場を検証しましょう。市場が存在することを示すために、実際に有料顧客を獲得しましょう。」

Sam Altman（YC）:

「そのプロダクトを切実に必要としているのは誰でしょうか？ 小さな市場の大部分を狙うのが最善の答えです。」 「ローンチするか、販売を試みてアイデアをテストしましょう。コードを書く前に、意向表明書を獲得しましょう。」

---

目的と範囲

• Epic の作成前に成長方向を発見する
• エビデンス優先の KILL ファネルでアイデアを絞り込む
• 出力：推奨アイデア1つとトラフィックチャネル1つ
• 位置付け：ln-210（Epic Coordinator）の前

実行時の契約

必ず読み込むこと: references/planning_worker_runtime_contract.md、references/coordinator_summary_contract.md

実行時ファミリー：planning-worker-runtime

識別子：

• ディスカバリー作業項目の識別子

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_INPUT_PROCESSING
3. PHASE_2_KILL_FUNNEL
4. PHASE_3_RANK_SURVIVORS
5. PHASE_4_WRITE_DISCOVERY_REPORT
6. PHASE_5_WRITE_SUMMARY
7. PHASE_6_SELF_CHECK

サマリー契約：

• summary_kind=opportunity-discovery-worker
• スタンドアロンモードでは、アーティファクトを永続化せずにサマリーを返す場合があります
• 管理モードでは、同じ JSON を summaryArtifactPath に書き込みます
• 管理モードのデフォルトのアーティファクトパスパターン：.hex-skills/runtime-artifacts/runs/{parent_run_id}/opportunity-discovery-worker/ln-201--{identifier}.json

使用するタイミング

このスキルを使用する場合：

• プロダクトがあり、次の成長方向を探している
• 3～10個の潜在的なアイデアやニッチがある
• 意思決定する前に機会を検証したい
• 注力するチャネルを1つ選ぶ必要がある

使用しない場合：

• プロダクトに関する背景情報がない（グリーンフィールドのスタートアップ）
• 方向性の検証がすでに完了している（ln-210 に進む）
• 既存の Story の優先順位を決める（ln-230 を使用）

---

入力パラメーター

パラメーター	必須	説明	デフォルト
ideas	いいえ	カンマ区切りのリスト	-
context	いいえ	アイデア生成用のプロダクト説明	-
strict	いいえ	厳格な KILL 閾値	true

入力モード：

• ideas="idea1, idea2, idea3" — リストを評価する
• context="SaaS for X" — プロダクトをもとにアイデアを生成する
• 両方 — 生成したアイデアにユーザーのアイデアを追加する

---

KILL ファネルのパイプライン

アイデアは、以前のように調査中心の4つの独立した段階を経ることはありません。まず、各アイデアについて、エビデンスをまとめて確認します。

Idea → [Evidence bundle: traffic + demand + competition + revenue]
          ↓
      [Hard kill matrix]
          ↓
     [Interest gate]
          ↓
      [MVP gate]
          ↓
       SURVIVOR

エビデンスバンドル（1回のリサーチ）

質問： より詳しい評価を正当化するだけの外部エビデンスはありますか？

リサーチバンドル：

WebSearch: "[idea] how people find solutions"
WebSearch: "[idea] search volume {current_year}"
WebSearch: "[idea] competitors {current_year}"
WebSearch: "[idea] pricing SaaS"

1回のリサーチで、次の4つのシグナルを抽出します：

• トラフィックチャネル： 人々はこのソリューションをどこで積極的に探していますか？
• 需要： 検索ボリューム、トレンドの方向性、またはコミュニティにおける強い課題シグナル
• 競争： 競合他社の数と市場の種類
• 収益： 妥当な価格帯と支払い意欲の傾向

トラフィックチャネルの例：

チャネル	シグナル	最適な対象
検索／SEO	「[課題] 解決策」をGoogleで検索する人がいる	情報商材、ツール
YouTube	チュートリアルの検索がある	教育、ハウツー
マーケットプレイス	カテゴリーが存在する（ProductHunt、AppStore）	アプリ、プラグイン
コミュニティ	活発なサブレディット、フォーラムがある	ニッチ製品
有料広告	競合他社が広告を出している	需要が実証済み
アウトバウンド	明確なICPがあり、アプローチ可能	高額なB2B

需要のしきい値：

ボリューム	判定
>10K/月	強い需要
1K-10K/月	成立可能なニッチ
<1K/月	非常に強いニッチシグナルで補えない限り、需要が弱い

競争のしきい値：

競合他社	指数	市場	判定
0	1	ブルーオーシャン	需要が実在すればチャンスあり
1-2	2	新興	最適な参入ポイント
3-5	3	成長中	差別化が必要
6-10	4	成熟	難しいが可能
>10	5	レッドオーシャン	多くの場合、打ち切る価値あり

収益のしきい値：

ARPU	市場タイプ	実現可能性
>$100/ユーザー/月	エンタープライズ	高利益率
$50-100	プロフェッショナル	良好
$20-50	プロシューマー	成立可能
$5-20	コンシューマー	ボリュームが必要
<$5	広告収入型	通常、割に合わない

即時却下マトリクス

次のハードストップ条件のいずれかに該当する場合は、直ちに却下します：

• 特定可能なトラフィックチャネルがない
• 需要が成立可能なしきい値を明らかに下回り、それを補うニッチシグナルもない
• 競争指数 = 5で、明確な勝ち筋がない
• 小規模チームのビジネスで、予想収益が$20/ユーザーを下回る

却下理由を記録し、そのアイデアの分析を終了します。

個人的な関心

質問： これを作ることを楽しめそうですか？

方法： AskUserQuestion — 1～5で評価

Rate your interest in building [idea]:
1 = Meh, would do for money only
2 = Low interest
3 = Neutral
4 = Interested
5 = Excited, would build for free

重要な理由：

• 関心が低いと、3か月で燃え尽きます
• 関心が高いと、苦しい時期もモチベーションを維持できます
• これに2年以上を費やすことになります

質問するタイミング： 外部エビデンスバンドルを通過したアイデアに限ります。

却下条件： スコアが1～2の場合 — PMFに到達する前にやめてしまいます。

出力： スコア（1～5）

---

MVPの実現可能性

質問： 4週間でローンチできますか？

評価：

要素	質問	危険信号
技術	既存のスキルで対応できますか、それとも習得が必要ですか？	新しい技術スタック
依存関係	外部APIやパートナーが必要ですか？	他者待ち
コンテンツ	大量のコンテンツ制作が必要ですか？	執筆に数か月
規制	法的要件やコンプライアンス要件がありますか？	ライセンス、承認
チーム	1人でできますか、それとも採用が必要ですか？	1人では始められない

所要期間の目安：

週数	複雑さ	判定
1-2	1人で対応、既存のスキルを活用	最適
2-4	学習が少し必要	良好
4-8	新しい技術が一部必要	許容範囲
>8	大規模なインフラが必要	却下

評価するタイミング： 外部エビデンスと関心度のゲートを通過したアイデアに限ります。

却下条件： MVPまでに8週間を超える場合 — 検証には遅すぎます。

出力： 所要週数の見積もりと障害要因

---

ワークフロー

フェーズ1：入力処理（2分）

1. 入力を解析する：

   • ideas の場合：カンマ区切りのリストを分割する
   • context の場合：WebSearchで5～7個のアイデアを生成する
   • 両方の場合：組み合わせる

2. 件数を検証する：

   • 最小：3個のアイデア
   • 最大：10個のアイデア

3. 出力ディレクトリを作成する：

   mkdir -p docs/reference/research/
   

出力： アイデアキュー（3～10個）と PHASE_1_INPUT_PROCESSING のチェックポイント

---

Phase 2: KILL ファネル（アイデアごと）

各アイデアをまとめてエビデンスを調査する一連の工程に通し、生き残ったアイデアにのみ個人向けのフィルターを適用します：

FOR each idea:
    Build evidence bundle:
        traffic + demand + competition + revenue

    Apply hard kill matrix
        IF failed → KILL, log reason, NEXT idea

    Ask Interest
        IF score 1-2 → KILL, log reason, NEXT idea

    Assess MVP-ability
        IF >8 weeks → KILL, log reason, NEXT idea

    → SURVIVOR: add to survivors list

トークン効率：

• 一度に処理するアイデアは1つ
• アイデアごとに、個別の調査フェーズを4回行う代わりに、調査をまとめて1回実施
• 早期にKILL＝興味の確認プロンプトも、MVPの評価も不要
• アイデアごとにコンテキストをクリア

---

Phase 3: 生き残ったアイデアをランク付け（2分）

生き残ったアイデアがある場合：

1. 総合スコアを計算：

   Score = Demand_score + (6 - Competition_index) + Revenue_score + Interest + MVP_score
   

2. スコアの降順で並べ替え

3. 最上位の推奨案を選択

生き残ったアイデアがない場合：

• 報告：「すべてのアイデアを却下しました。方向性を見直してください。」
• 学習のためにKILLログを表示

---

Phase 4: 出力（2分）

生成： docs/reference/research/[YYYY-MM-DD]-discovery.md

構造化されたランタイム概要も出力します：

• schema_version
• summary_kind=opportunity-discovery-worker
• run_id
• identifier
• producer_skill=ln-201
• produced_at
• input_mode、ideas_analyzed、generated_ideas、survivors_count、killed_count、top_recommendation、report_path、warningsを含むペイロード

構成：

# Opportunity Discovery: [Date]

## Summary
- Ideas analyzed: X
- Survivors: Y
- Killed: Z

## TOP RECOMMENDATION

**Idea:** [Name]
**Channel:** [Primary channel]
**Why:** [2-3 sentence rationale]

### Key metrics:
- Demand: [volume]/month
- Competition: [Index] [Ocean type]
- Revenue: $[X]/user
- MVP: [X] weeks

## Survivors Table

| Idea | Channel | Demand | Competition | Revenue | Interest | MVP | Score |
|------|---------|--------|-------------|---------|----------|-----|-------|
| ... | ... | ... | ... | ... | ... | ... | ... |

## KILL Log

| Idea | Killed at | Reason |
|------|-----------|--------|
| ... | ... | ... |

## Next Steps
1. Create Epic with ln-210 for top recommendation
2. Focus on [channel] as primary acquisition
3. Target MVP in [X] weeks

---

時間の目安

アイデア数	推定時間
3	15-20分
5	25-35分
10	50-70分

注： KILLファネルは全項目のスコアリングより高速です。不適切なアイデアを早い段階で却下できます。

---

統合

ワークフロー内の位置：

Product exists
     ↓
ln-201 (Opportunity Discovery) ← THIS SKILL
     ↓
ln-210 (Epic Coordinator)
     ↓
ln-220 (Story Coordinator)

依存関係：

• WebSearch（Interest以外のすべてのフィルター）
• AskUserQuestion（Interestフィルター）
• Write、Bash（出力）

---

重要なルール

1. まずトラフィック — トラフィックチャネルがなければ分析しない
2. エビデンスをまとめて一度だけ調査 — 1回の調査でトラフィック、需要、競合、収益に答えられる場合は、調査を多く必要とするフェーズを個別に実行しない
3. すぐにKILL — 却下対象のアイデアをスコアリングしない
4. 推奨案は1つ — 決断できなくなるのを避ける
5. アンケートはしない — 実際の検索データのみを使用
6. 興味は重要 — 外部的に実現可能なアイデアにのみ質問する
7. MVPのスピード — リリースが遅いと、学習も遅くなる

---

使用例

アイデアを指定する場合：

ln-201-opportunity-discoverer ideas="AI writing tool, code review bot, translation API"

コンテキストを指定する場合：

ln-201-opportunity-discoverer context="B2B developer tools SaaS"

出力例：

# Opportunity Discovery: 2026-01-29

## TOP RECOMMENDATION

**Idea:** Code review bot
**Channel:** SEO (developers search "code review tool")
**Why:** Growing demand (15K/mo), emerging market (3 competitors),
$50/user pricing proven, can MVP in 3 weeks with existing skills.

## KILL Log

| Idea | Killed at | Reason |
|------|-----------|--------|
| AI writing | Competition | Red Ocean (25+ competitors) |
| Translation API | Revenue | Commoditized, <$10/user |

---

完了の定義

• プロダクトのコンテキストと市場シグナルをもとにアイデアをブレインストーミングする
• 却下を決定する前に、各アイデアのエビデンスをまとめて収集する
• InterestとMVPの確認前に、厳格なKILL判定マトリクスを適用する
• 生き残ったアイデアをスコアリングしてランク付けする
• docs/reference/research/[YYYY-MM-DD]-discovery.md にディスカバリードキュメントを生成する
• チャネルと根拠を添えて、最上位の推奨案を特定する
• 却下したすべてのアイデアと理由をKILLログに記録する
• 構造化された opportunity-discovery-worker の概要を返す
• summaryArtifactPath が指定されている場合、概要のアーティファクトを出力する

参照ファイル

ファイル	目的
filter_criteria.md	すべてのフィルターのKILL基準
channel_analysis.md	トラフィックチャネルの特定
discovery_template.md	出力Markdownテンプレート

• 必ず読むこと： references/research_tool_fallback.md を読み込む

---

バージョン： 2.0.0 最終更新日： 2026-01-29