事業アイデア・需要探索の方法論

事業ネタ・プロダクト機会の探索で「自分の関心や既存プロダクトの型に偏らないように」と走査面（キーワードの網羅スイープ、カテゴリの無作為走査など）を無偏化すると、探索の質はむしろ下がる。

なぜ

• 無偏な走査面は誰でも回せる面であり、そこに可視化されている需要（検索サジェストに立つ語・公開ランキング上位）は「過去に大量に観測された需要」。参入障壁が低ければ供給は既に埋まっているのが経済的な既定
• 機会の実体は非対称性（自分だけが持つ文脈・資産・実行力とのマッチ）にあり、偏りの除去はその非対称性ごと捨てる操作。「自分の候補リストは偏っている」は排除理由ではなく、勝てる場所の地図である可能性を先に検討する
• 機会は「領域」の粒度ではなく「構造の断層」（公式供給の縦割り分断・規格の版ずれ・履歴の不在・改正追従の欠如）の粒度で現れる。断層は深掘りしないと見えないため、広く浅い無偏走査は却下記録を量産しやすい

実測の根拠（一般化元）

• 意図修飾語のフラットスイープ1周・34領域がほぼ全て「既存供給が現役」で却下。生き残った候補は全て無偏スイープ以外の経路（既知領域の隣接展開・供給停滞シグナルの逆引き）から出た
• 補正装置（供給側の逆引き・制度の先回り・却下前の勝ち筋設計）を積み増しても、土台の走査面が「可視化済みの需要の大きい順」を向いている限りパッチが増え続けた

適用

• 探索の起点は「自分の資産が他者より安く検証・構築できる面」に置く: 再利用可能なパイプライン・スキーマ、深く知っている規制・業界、既存候補の隣接タスク群
• まだ可視化されていない需要（施行日が確定した制度変更など、発生タイミングが既知のもの）は無偏走査の外にあり、先回りできる数少ない面
• 無偏スイープを使うなら「機会の発見」ではなく「市場の地図作り」（何がどの理由で埋まっているかの却下理由マップ）として1周だけ回し、成果物は経済構造の実測として再利用する

パッケージレジストリ・拡張ストア・アプリストアなどで「利用実績が多い × 長期間更新されていない」を参入余地のシグナルとして数値逆引きする市場調査手法では、停滞シグナル単独で「放置された需要」と読むと誤検出する。停滞には「放置」と「完成」の2種類があり、区別は未解決の痛みの在庫で行う。

判断基準

• 参入余地と読んでよい停滞: 利用が多く、未解決 issue や不満レビュー（痛みの在庫）が積み上がっているのに更新が止まっているもの。需要側の要求が変化し続けているのに供給が追従していない状態。
• 参入余地でない停滞: 機能表面積が小さい純関数ユーティリティ（色空間変換のような数十行の写像など）が何年も更新されないケース。仕様が安定して「完成」しているだけで痛みの在庫がほぼゼロであり、利用者に置き換える理由が無い。
• 判定は「人気 × 停滞」の2軸に「痛みの在庫（未解決 issue 数・不満レビュー数）」と「機能表面積（対象の仕様・環境が動き続ける領域か）」を加えて行う。

落とし穴

• GitHub API が返す open issue 件数は open PR を含むため、痛みの在庫を系統的に過大評価する。停滞リポジトリほど未マージ PR が積もるので、issue 単体を数え直してから判断する。
• 利用数（ダウンロード数など）は CI 等の機械的トラフィックで水増しされるため、絶対値でなく相対比較と推移で読む。

検証方法

候補に挙げた停滞プレイヤーについて、直近1年でも issue 起票・不満レビューが継続しているか（需要側の要求変化が現在も起きているか）を確認する。起票が続いていれば放置、止まっていれば完成に近い。

検索需要の調査で「ある修飾語（計算・テンプレート・比較など）と共起する名詞＝需要が実在する領域」を機械的に回収したいとき、検索エンジンのサジェスト補完APIを双方向に使うと、手作業の検索窓操作より速く網羅できる。サジェストは前方一致補完なので、素朴に引くと修飾語の「後続語」しか取れず、実際の検索で多い「名詞＋修飾語」（前置名詞）が抜ける。この非対称を2つの手で埋める。

手順（2026-08-03 に Google の complete/search エンドポイントで再現確認）

• 後続語: 「修飾語＋空白＋かな1文字」を あ〜わ でスイープする（英語圏はアルファベット）。1文字シードごとに補完候補10件前後が返り、後続語の分布が取れる
• 前置名詞: クエリ先頭に空白を置き、カーソル位置パラメータを 0 に指定して引く（Google なら client=chrome と cp=0 の組）。補完が「空白の前」を埋める挙動になり、「ふるさと納税 計算」のような前置名詞つき人気クエリが関連度スコアつきで返る
• エンコード: 日本語クエリは URL エンコード必須（生 UTF-8 は 400）。入出力エンコード指定（ie/oe に utf-8）を付けないと応答が Shift_JIS で化ける
• 規律: 非公開エンドポイントなので1走査あたり十数リクエスト・sleep 付きの低頻度に留める。挙動はいつでも変わりうる前提で、使う前に1クエリで再現確認してから本走査に入る

なぜサジェストで領域回収か

• 自作の領域リストから調査対象を選ぶと、リストの生成レンズ（自分の関心・既存プロダクトの型）の偏りがそのまま調査の偏りになる。需要側の言語（実際に打たれている補完候補）から領域を立ち上げると母集団が自分から切り離される
• サジェストは探索面であって物差しではない。ここで立った領域の需要実在は、検索ボリュームの実測で別途確認する

落とし穴

• 後続語スイープだけで「共起を網羅した」と誤認しやすい。前置名詞側に主要需要が乗っている領域（名詞＋タスク型のクエリ）はまるごと欠落する
• 補完候補は パーソナライズ・地域の影響を受けるため、絶対的な網羅ではなくシードの取り方を変えた複数回の走査で補う

AI に網羅的な列挙（候補探索・監査・リスク洗い出しなど）をさせるとき、分類軸（型・カテゴリ）を列挙より前に持ち込むと出力がその分類に収束する。見落としやすいのは、プロンプト文言ではなく走査対象リストの側に原因があるケース。しかも原因は2層あり、構造を直しても出自が残る。

第1層: リストの構造

対象リストを分類ごとのセクションに分けると、対象を選んだ時点で分類も決まる:

• ある対象を走査して出た候補が全件同じ分類になる（他分類の可能性は否定されたのではなく、問われていない）
• 別の対象で候補0件になったとき、真の空白なのかその分類だけ飽和していたのかを区別できない

対処: 走査対象リストは分類と直交する軸で並べ、分類は列挙後に写像する（生成 → 分類の2段分離）。各対象に全分類の問いを当てることを手順に固定する（手順に書かない問いは実行されない）。

第2層: リストの出自（見落としがち）

セクションを割らなくても、リストを作ったときの問いが分類に偏っていれば同じ結果になる。表面上は網羅的に見えるので気づかない。

自己診断のやり方: リスト各行に共通する属性を数える。実例では19行中18行が同じ属性を持っており、その属性はまさに潰そうとしていた分類の探し方そのものだった。「このリストはどんな問いで作ったか」を明示的に問う。

最も強い対処: 走査面を自作リストから外部シグナルへ移す

自分で書いたリストを広げても、恩意で作った別のリストになるだけ。母集団の選定を自分の関心から切り離すには、利用者側が実際に使っている言語や、第三者が持つグラフを走査面にする:

• 利用者の言語（検索語・問い合わせ文・エラー文言など）を起点にし、そこから対象を事後的に回収する
• 自作リストは走査面から降ろし、カバレッジ記録（触れたものの記録）として使う。「見るべきものの全体ではない」と本文に明記する

ただし外部シグナルへの入口語は自分で選ぶので、入口語の語彙が同じレンズなら回収される対象も同じ側に落ちる。入口語の網羅性も同じ基準で点検する（実例: 事務・書式系の語ばかりで、地理・価格・消費者向けの語群が欠けていた）。

実績ラベルもアンカーになる

候補リストや分類表に「実証済み」「相性◎」のような既存成功例のラベルを載せると、有望さの証拠として読まれる。実態は「その分類の実行経験がある」だけ。実績ラベルは最後の同点決勝にのみ使うと明記する。

検証

• 記録フォーマットに分類別の内訳を持たせ、「当てて0件」と「当てていない」を記号で書き分ける（例: 0 と —）。これがないと空白の証明と未実施が区別できない
• 件数を記録するならどの段階の数かを定義する（列挙段階か、スクリーニング通過後か）。未定義だと同じ記号が回によって別の意味になる
• 1対象の走査で単一分類しか出なかったら、それ自体を記録する
• 過去の走査記録は書き換えず、未実施の問いを「要再走査」として後から追記する

手順を入れ替えたときの落とし穴

走査面を入れ替えるような改訂では、上位の規範文書（思想・判断基準の正本）の追従漏れが最も危険。手順側に「迷ったら正本に戻れ」と書いてある限り、正本の古い記述は廃止した設計を復活させる経路になる。改訂後は正本・索引・メタデータ（説明文・見出し）まで旧設計の残存参照を機械的に検索する。

適用範囲

網羅性が価値の中心にある列挙タスク全般（候補探索・セキュリティ監査・リスク洗い出し・レビュー観点の網羅）。逆に、既に分類が確定している対象を処理するタスクでは分類別の構造でよい。