「作りたいものがない」は、才能の問題じゃない。

「思いつかない」の正体は4種類ある

「好きなものを作っていいよ」と言われて手が止まるのは、あなたの発想力が弱いからではない。探索空間が広すぎると人間は探索できない。これは創作全般で知られた性質で、白紙のキャンバスより「お題」があるほうが筆は進む。

ただし「思いつかない」とひとことで言っても、詰まっている場所は人によって違う。対処が変わるので、まず自分がどれかを見分けてほしい。

A〜D のどれであっても、解き方は根性ではなく構造だ。制約を先に置く。技術・ジャンル・対象ユーザー・ひねり — 何かを固定した瞬間、「その条件で成立するものは何か?」という答えられる問いに変わる。

制約を先に置く「触媒発想」— 5ステップの手順

種火ではこの「先に置く制約」を触媒と呼んでいる。たとえば「WebGPU × 学習 × 子供 × オフライン限定」のように4軸を固定すると、発想はゼロからではなく掛け算から始まる。

重要なのは、触媒の選択にセンスは要らないこと。乱択でいい。むしろ自分では選ばない組み合わせのほうが、見たことのない案につながる。

4軸の中身

種火が使っている触媒プールは、技術20 × ジャンル15 × 対象12 × ひねり15 = 54,000通り。実物はこんな粒度だ。

「ひねり」の軸があるのがポイント。技術×ジャンル×対象だけだと既存サービスの言い換えになりやすいが、そこに「音だけ」「1画面」のような制約が1つ入るだけで、既存の何かとは違う形に押し出される。

手順

1. 4軸を乱択で固定する。 自分で選ばない。選んだ時点で過去の延長になる
2. 問いを置き換える。 「何を作りたいか」ではなく「この4条件を全部満たすWebサービスは何か」。前者は答えられないが、後者は答えられる
3. 20秒で判定して捨てる。 長く吟味しない。「見たい/見たくない」だけ。引っかからなければ次の触媒を引く
4. 残った案だけ深掘りする。 対象ユーザー・最小機能・収益の形・技術構成をここで初めて具体化する
5. 着手前に死角を潰す。 堀があるか、その領域の典型的な失敗は何か(→ 08)

ステップ1〜2は自分の手でもできるが、AIに丸ごと任せたほうが速い。触媒の乱択から案の組み立てまで自動化されているので、「作りたいものがない」状態からでもボタンひとつでWebサービス案が出てくる。出てきた案に「いや、こうじゃない」と感じたら — その違和感がもう、あなたの発想の始まりだ。

出した案を捨てる基準 — 3つの質問

触媒を何回か引くと、今度は逆の問題が来る。案は出るが、どれを作るか決められない。ここで時間を溶かす人は多い。

判定は3問で足りる。全部通る案はそう多くないので、迷ったら順に当てていけばいい。

3問すべて Yes なら着手していい。 2問なら保留(💡 派生展開で切り口を変えると通ることがある)。1問以下なら捨てる。

捨てるのが惜しければ、案を残す場所を作っておくといい。アーカイブに置いておけば、前提が変わったときに拾い直せる。捨てるのと消すのは違う。

よくある詰まり方と、その抜け方

「案は出るが、全部ありきたりに見える」

たいてい対象ユーザーが広すぎる。「タスク管理ツール」はありきたりだが、「訪問介護のヘルパーが移動中に片手で打てる記録ツール」はありきたりではない。案を捨てる前に、対象を10分の1に狭めてからもう一度見てほしい。ありきたりさの正体は、アイデアそのものではなく解像度の低さであることが多い。

「毎回、似たような案ばかりになる」

制約を自分で選んでいるのが原因。人は無意識に自分の得意分野と直近の関心に寄せるので、選択そのものが幅を殺す。相性の悪い組み合わせをあえて残すのが効く。「WebRTC × 家計簿 × 高齢者 × 音だけ」のような、噛み合わなさそうな触媒ほど未踏の形になる。

「作り始めると必ず飽きる」

案の選び方が「面白そう」基準になっている可能性が高い。面白さは着手時にピークを迎えて減衰するが、自分の不便は減衰しない。飽きが慢性化しているなら、次の1本は 種2(毎週やっている手作業) から選ぶといい。地味だが完走率が違う。

「もう誰かが作っている気がして手が止まる」

ほぼ確実に誰かは作っている。それでも成立するかは「その既存サービスを、自分の対象ユーザーが実際に使っているか」で決まる。存在していても届いていない・重すぎる・高すぎるなら、そこは空いている。

気になるなら、着手前に 🛡 模倣耐性判定 で「時間で深くなる要素があるか」を見ておくと判断が速い。

「思いついた」を「作る」に変える

案がひとつでも出たら、流れは決まっている。①派生で選択肢を増やす(💡 AI派生展開で1案→3案) → ②着手前チェック(🛡 模倣耐性と⚰ 失敗パターン) → ③仕様書化(📋 MVP仕様書を Claude Code / Cursor に貼る)。

実装フェーズの歩き方は、姉妹ガイド Claude Codeで何を作る? に詳しくまとめてある。仕様書に何を書くべきかもそちらで扱っている。