競合調査で「空白」を見誤るパターン
一言まとめ
個人開発の企画で「競合がいない」と結論する前に潰すべき 4 つの見落とし。後発の個人開発プロダクト、カテゴリ名での検索漏れ、宣伝割合と能力割合の混同、プラットフォーム規約による中核機能の禁止。2026 年 6 月に自分で作った競合マップが、上位 4 案すべてで上振れしていた反省から。
目次 5 sections
一言で
調査時点: 2026-06。十数個の企画案について「既存製品の弱点 = 個人開発で刺せる隙」を並べた競合マップを作り、★ を付けて並べたところ、別の視点での批評(critique)で上位 4 案すべての「空白」が誤りだった。どれも検索を一段で止めていた。以下はその 4 つの誤り方を、再発防止の手順に書き直したもの。
前提として、競合がいること自体は問題にならない(差別化するか、より良いものを作れば勝てる)。問題は「いない」と誤認した状態で設計に入ることで、差別化の根拠が消える。
4 つの見落とし
| # | 見落とし | 起きたこと | 対策 |
|---|---|---|---|
| 1 | 後発の個人開発プロダクトを掘り切らない | 大手(評価額 $1B 級)だけを競合として見て「空白」と書いたが、同じコンセプトの小さな個人開発アプリが 3 本既にあった | 大手の名前で検索を終えず、「<コンセプト> app」「<既存大手> alternative」「<コンセプト> indie」で個人開発層まで降りる |
| 2 | カテゴリ名で検索しない | 自分の案を「○○と△△を接続するフロー」と自分の言葉で定義し、その言葉で検索したため、同じ機能が「アイデア検証ツール」というカテゴリ名で 1 年前から存在していたのを見落とした | 自分の案が属しうるカテゴリ名を 3 つ挙げ、カテゴリ名でも検索する。Product Hunt のトピック名、App Store のサブカテゴリ名が手がかりになる |
| 3 | 宣伝割合を能力割合と誤読する | 論文で「163 本中、ある機能を明示するのは 8%」とあったのを「92% はその機能を持たない」と読んだ。実際はその機能は OS 標準で全アプリにあり、宣伝に書く価値が無いだけだった | 「明示している割合」と「できる割合」を分ける。OS やプラットフォームの標準機能は table stakes なので、差別化軸には数えない |
| 4 | プラットフォーム規約が中核機能を禁止している | 唯一の差別化点が YouTube の埋め込みの上に UI を重ねる機能だったが、YouTube の API 利用規約がそれを禁じていた | 中核機能が外部プラットフォームの上に乗るなら、設計前に利用規約の該当条項を読む。「技術的に実装可能」と「規約上可能」は別 |
手順にすると
- 自分の案を一文で書き、その一文に含まれる名詞ごとに検索する。
- 大手 → 中堅 → 個人開発の順に、少なくとも 3 層まで競合を探す。個人開発層は Product Hunt、Indie Hackers、Show HN、App Store のレビュー数 100 未満の帯に多い。
- 案が属しうるカテゴリ名を 3 つ挙げ、カテゴリ名で検索し直す。
- 「空白」と書きたくなったら、その空白を埋める専用プロダクトの名前を名指しで検索する(「<コンセプト> only app」「dedicated <コンセプト>」)。見つからなければ、なぜ誰も作っていないかの仮説(需要が無い・規約で無理・標準機能で足りる)を 1 行書く。
- 中核機能が外部プラットフォームに依存するなら、規約の該当条項を引用してから設計に進む。
4 の「なぜ誰も作っていないか」の仮説が「標準機能で足りる」「規約で無理」になった時点で、その案は空白ではなく穴である。
関連
更新履歴
- 2026-06-29: 初版(ローカル調査ノートの訂正・教訓節)
- 2026-10-17: Wiki へ移植、概念ページとして再構成