AIに企画を出させるコストは、ほとんどゼロになった。Claude Codeに「この市場で個人開発が狙えるニッチを探して」と投げれば、30分程度で20案以上出てくる。
問題はそこではなかった。出てきた案を殺す速度のほうが追いつかない。
1年かけて68案を検証して、68案とも自分で殺した。その過程で判定を自動化する仕組みを作ることになったので、それを全部書く。実装はClaude Codeのスキルとナレッジファイルだけ。特別なものは使っていない。
企画の中身の話はしない。書くのは判定の仕組みのほうだ。
なぜ判定のほうが重くなるのか
最初は素朴にやっていた。発散させて、出てきた案を1つずつ調べる。
1案あたりの調査は、競合を探して、レビュー数を見て、無料の代替がないか確認して、で10〜30分。20案なら丸一日かかる。それでも「案を出す部分が速くなったのだから、全体としても速くなったはずだ」と思っていた。
3ラウンド目で気づいた。同じ死に方をする案が毎回出てくる。
たとえば「〇〇費シミュレーター」系。保険、車、不動産、ローン。これは毎回発散に出てくるし、毎回同じ理由で死ぬ。大手が集客のために計算機を無料開放しているので、支払意思がゼロなのだ。1ラウンド目で30分かけて調べて殺したのに、2ラウンド目でまた出てきて、また30分かけて調べていた。
LLMは前のラウンドで何を殺したか覚えていない。会話履歴に残っていても、新しいセッションでは消える。結果として、自分は同じ調査を何度も繰り返していた。
「AIに探させても同じような案ばかり出てくる」という感覚の正体はこれだった。案が同じなのではない。殺した記録が残っていないから、同じに見えていた。
殺した理由を1行ずつ残す
そこで、落とした案を1行ずつファイルに追記することにした。death-ledger.md という名前にした。
フォーマットは4列だけ。
| 題材/機構キー | 死因を一文 | 最強のincumbent | 判定日 |
1列目を「題材キー / 機構キー」にしたのが要点だ。案の名前ではなく、照合できるキーにする。次のラウンドで出てきた案と機械的に突き合わせるために使うので、固有名詞でなく構造で書く。
運用ルールは2つだけ決めた。
- 案を落とすたびに、その場で1行追記する（後でまとめてやろうとすると必ず溜まって破綻する）
- 同じ型で2回死んだら「構造的死因パターン」に昇格させる
2つ目が効いた。個別の死因を並べているだけだと、台帳が肥大して照合コストが上がる。だが2回以上繰り返した型を上位概念に畳むと、台帳が成長するほど照合が速くなる。
いま台帳は219行あって、そのうち上位パターンは17個。ここでは3つだけ例を挙げる。
撒き餌無料構造の試算系
大手が集客のために計算機を無料開放している領域。保険・車・不動産・ローンの試算はここに入る。見積りや査定で儲ける本体があるので、計算機そのものは永久に無料でいい。この構造がある限り支払意思は発生しない。判定は「隣接に、見積り/査定で儲ける大手がいるか」を見るだけで済む。
制度追従の当事者計算機
失業保険、養育費、高額療養費のような制度計算。2つの理由で死ぬ。ひとつは公式の無料Webが一回性で足りること。もうひとつは後発の参入者が全員レビュー一桁で、それが市場の天井を示していること。実際に調べたら、15年運営されている計算アプリのレビューが5件だった。市場が薄いというより、一度計算したら二度と開かないジョブなので母数が積み上がらない。
スワーム乱立
同じジョブの新規アプリが直近1年で3本以上あって、全員レビュー一桁のケース。「市場が動いている」証拠に見えるが、読み方が逆だった。参入障壁がゼロで、かつ天井が極小である複合証拠になる。AI開発が普及した後、発掘で見つかる程度の空白は既に同時多発で参入されている。最古参の1〜2月組も半年後に0〜3件のままなので、「まだ新しいから」では説明がつかない。
台帳の効果は分かりやすい。1案あたり数十分かかっていた判定が数秒になる。照合して一致したら、該当行を引用して落とすだけだ。
判定をスキルに固定する（会話に置かない）
台帳を作っただけでは足りなかった。照合するのを忘れるからだ。
セッションが変わると、私（人間の側）もClaude Codeも「まず台帳と照合する」という手順を忘れる。会話で「台帳を見てね」と毎回言うのは、言い忘れた瞬間に破綻する。
そこでClaude Codeのスキルとして、探索のフェーズ自体を固定した。スキルは ~/.claude/skills/ に SKILL.md を置くだけで、APIへのアップロードもいらない。参照するファイルは同じフォルダに置いて相対パスで書ける（Agent Skills の仕様、公式のサンプル集）。
フェーズ1 発散（複数の源泉から候補を出す）
フェーズ1.5 死因台帳との照合 ＋ 占有チェック ← ここが要
フェーズ2 需要シグナルと既存の弱さの調査
フェーズ3 「既存がなぜ弱いか」の判定
フェーズ4 評価
フェーズ5 スモールテスト設計
フェーズ1.5を、発散の直後・重い調査の前に置いたのが一番効いた。
最初は照合をフェーズ3あたりに置いていた。すると調査コストを払ってから殺すことになる。順番を入れ替えて、発散した瞬間に台帳と突き合わせるようにしたら、調査に入る案が半分以下に減った。
スキルのファイルにはこう書いてある。
生成は安い、ゲートが律速。 重い需要調査にコストを払う前に、明らかに死ぬレーンをここで落とす。
もう一つ、判断基準を会話でなくファイルに置くルールを徹底した。これは成瀬允宣氏の「サーヴァントエンジニアリング」——自分のレビュー判断を「分ける→渡す→囲う」でAIに再現させる手法——から取った考え方で、Persona / Policy / Knowledge をファイル化して渡す部分をそのまま流用している。
- 自分固有の制約（何を作らないか、どのプラットフォームを使うか）→
uxe-ap-constraints.md - 評価のハードゲート（鮮度の要求、思いつき禁止など）→
idea-guardrails.md - 死んだレーン →
death-ledger.md
これらを _shared/ に置いて、複数のスキルから参照している。1箇所直せば全部のスキルに効く。会話に置いた基準は毎回劣化するが、ファイルに置いた基準は劣化しない。
「良い点も挙げて」と言わない
判定の質を上げたもう一つの要素は、指示の出し方だった。
素朴に「この案を評価して」と投げると、LLMは良い点と悪い点をバランスよく並べる。これは判定に使えない。どの案も「一長一短ですね」で終わってしまう。
そこで、明示的に殺しに行かせるようにした。
この案が死ぬ理由を探せ。
良い点は挙げなくていい。
1〜2クエリで殺せるものは殺せ。
これで結果が変わった。発散フェーズを生き延びた案が、敵対検証でほぼ全滅する。ある回は候補8本を検証して8本とも落ちた。別の回は10本中10本。
ここで分かったのは、発掘フェーズで「既存が不在」と判定されたものが、敵対検証で頻繁に崩れることだった。理由はいくつかある。
- 検索語のアーティファクト: 「〇〇 互換」で0件だったが、「〇〇 変換」「〇〇 調色」で調べたら既存が多数あった
- ストアの片側しか見ていない: iOSだけ見て「買い切りが存在しない＝空白」と判定したが、Google Playに同種の買い切りが実在した
- 無料Web/PWAを数えていない: アプリストアには無いが、無料のWebツールが機能を完全に充足していた
発掘段階で見つかる「空白」は、多くの場合こちらの測定器の欠陥だった。敵対検証は、その欠陥を暴くために要る。
続けない条件を先に書く
仕組みが整うと、次の問題が出てくる。止め時が分からない。
判定が速くなったので、ラウンドを何回でも回せてしまう。そして毎回「今回は生存ゼロだったが、次は当たるかもしれない」と思う。
そこでルールを先にファイルに書いた。
生存ゼロのラウンドが2回連続したら、同じ制約セットでの再実行は期待値がマイナスだと実証されたものとする。3回目を回す前に必ず停止し、「制約を1つ変える」選択肢を提示する。
制約の変更候補も先に列挙しておいた。
- 配信チャネルを持つ
- 買い手を変える（消費者 → 技術者／事業者）
- プラットフォームを変える
- 自分の資産とのシナジー起点に限定する
このルールで実際に探索を止めた。そのあと「買い手を変える」を選んで消費者向けから事業者向けに移したが、そちらも4方向やって全滅した。負けを負けとして記録できたのは、先にルールを書いてあったからだ。
停止条件を後から決めると、必ず「もう少し掘れば」に負ける。先に書いておけば、条件に触れた時点で機械的に止まる。
それでも68回死んだ
ここまでが仕組みの話で、結果は68連敗だった。
行き詰まったので、診断そのものをClaude Codeにやらせた。返ってきたのは「判定ゲートのほうが壊れている」だった。案が悪いのではなく打席の構造が悪い、企画スキルは凍結でなく廃棄しろ、前ターンで自分が推した改善案も撤回する、と。ここまで作ってきた仕組みを捨てろという結論だった。
その提案には別プロジェクトへの全面移行も含まれていた。そちらは別のセッションで進めていたので、範囲を狭めて指示し直した。そこは触るな、収益化のことだけ考えろ、と。
1分半後、前の診断が撤回された。
収益 = 作る力 × 届ける力。届ける力がゼロなら、作る力が何であれ積はゼロ。
これで死因を並べ直すと、全部が同じ形に還元できた。
- 「無料の強者が棚を占有している」→ 棚に並ぶには発見される必要がある
- 「ASO一本しか経路がない」→ 検索需要に寄生する以外の道がない
- 「バイラル依存なので棄却」→ 唯一の代替経路を持っていない
ゲートは壊れていなかった。68回とも正しく「これは死ぬ」と言い続けていた。緩めても意味がない。緩めた分だけ、静かに沈む本数が増える。
同じモデルが、1分半のあいだに正反対の診断を出した。違いは範囲の指定だけだ。逃げ道になる選択肢をひとつ閉じたら、答えのほうが変わった。
68回分の記録がなければ、どちらの診断が正しいかも判断できなかった。仕組みを作った意味はそこにあった。
結局どこが効いたか
案を出すコストが下がると、ボトルネックは判定のほうに移る。1ラウンド30分で20案出るなら、遅いのは殺す速度のほうだ。
いちばん効いたのは、照合を発散の直後に置いたことだった。調査コストを払ってから殺すのは順序が逆で、入れ替えただけで調査に入る案が半分以下になった。
次が、同じ型で2回死んだら上位概念に畳むルール。台帳は放っておくと肥大して、照合そのものが重くなる。畳むと逆に、育つほど速くなる。
残りは細かい。殺した理由はファイルに残す（会話履歴は次のセッションで消える）。敵対検証では「良い点を挙げるな」と明示する。停止条件は先に書く。最後のは仕組みというより自分への縛りだが、無いと確実に延命する。
市場調査に限った話ではない。AIに候補を大量に出させて絞り込むタスクなら、殺した記録をどこに置くかという問題は同じ形で出てくる。