Claude Codeで、何を作る?

何が速くなって、何が速くなっていないか

Claude Code や Cursor を使えば、CRUD付きのWebサービスは本当に一晩で動く。数年前なら1〜2ヶ月かかっていた個人開発の実装フェーズは、いまボトルネックではなくなった。

ただし、速くなったのは全工程ではない。個人開発を工程で割ると、こうなっている。

つまり、真ん中だけが極端に速くなって、前後が取り残されている。実装が1ヶ月かかっていた頃は「作りたいものが無い」と感じる暇がなかったが、今夜から作れる状態になった途端、多くの個人開発者が同じ場所で止まる。作りたいものが決まっていない。あるいは決めたはずの案が「これ、作る意味あるのか?」と揺らぐ。

いまいちばん練習すべきスキルはコーディングではなく発案と、その案を絞り切ることだ。そして両方とも、根性やセンスではなく型で出せる。

「Webサービス」に絞ると勝ち筋が見える

何を作るかの前に、どこで作るかを固定しよう。おすすめは迷わず Webサービス(SaaS / Webアプリ / PWA / API / ブラウザ拡張)だ。理由は3つ。

• AIコーディングが最も効く領域 — 生成されたコードがほぼそのまま本番で動く。ストア審査もビルド地獄もない
• 試行回数を最大化できる — URLひとつで公開・共有・撤退ができる。個人開発は当てるゲームではなく試行回数のゲーム
• 運用が一人分のサイズに収まる — レンタルサーバー1台と月数百円で回る構成が現実的に組める

ネイティブアプリやハードウェアが悪いわけではない。ただ、実装以外の摩擦が個人開発には重い。ストア審査は数日〜数週間かかり、リジェクトされれば作り直しが要る。ハードは在庫と物流が乗る。どちらも「一晩で作って翌朝に公開する」というAI時代の速度が活きない。

最初の1本は摩擦の少ない土俵で回して、「公開して反応を見る」という一周を体で覚えるのが先だ。土俵を移すのはその後でいい。

最初の1本の選び方と、避けるべき4つの初手

型で案が出たら、次は「どれを最初に作るか」だ。AIで実装が速くなったとはいえ、速くならなかった部分に地雷がある。次の4つに当てはまる案は、初手としては避けたほうがいい。

逆に、最初の1本に向いている条件

• ログイン不要でも成立する — 触ってもらうまでの摩擦がゼロになる
• 1画面で完結する — 画面遷移が増えるほど未完成のまま放置される確率が上がる
• 自分が今週使う — 完成した瞬間に自分が最初のユーザーになる
• データが消えても致命傷にならない — バックアップや整合性の設計に時間を取られない

この4条件を満たす案は、週末で公開まで到達できる。まず1本、公開して反応を見る一周を終わらせることのほうが、大きい案を1本抱えるより遥かに学びが多い。

作る前に潰しておく、2つの死角

案が出たら、すぐコードを書きたくなる。その前に2つだけ確認すると、数週間の無駄打ちを防げる。

死角1: それ、すぐ真似されない?

実装が安い時代は、模倣も同じだけ安い。あなたが一晩で作れるものは、他人も一晩で作れる。だから問うべきは「作れるか」ではなく「時間が経つほど深くなる要素があるか」だ。

堀になりうるのは、たとえばこういうもの:

• データの蓄積 — 使われるほど価値が増す(後発は同じデータを持てない)
• ワークフローへの食い込み — 業務に組み込まれると乗り換えコストが跳ね上がる
• コミュニティ — 人が集まっている場所自体が価値になる
• 参入の面倒さ — 泥臭い初期投入や関係構築が要る領域は、そもそも誰も来ない

逆に「UIがきれい」「機能が多い」は堀にならない。どちらも一晩で並ばれる。🛡 AI模倣耐性判定 が5軸で辛口に診断してくれるので、着手前に一度通しておくといい。

なお、実際に16件を診断してみると5軸80スコアのうち4以上が1つも出なかった。堀は選ぶものではなく後から積むものだという話は Webサービスの差別化と参入障壁 に実データつきで書いた。

死角2: その領域の「典型的な失敗の型」を知っているか?

どのジャンルにも、先人が同じ理由でつまずいたパターンがある。マッチング型なら供給側が先に離脱する、ツール型なら本家に同機能が入る、コミュニティ型なら初期の空席期間を越えられない — といった具合に、失敗は驚くほど型どおりだ。

着手前に ⚰ AI失敗事例リサーチ で業界×ジャンルの失敗パターンを引いておくと、回避設計が最初から織り込める。作ってから気づくと、作り直しになる。

仕様書にしてから貼る — 何を書くか

なぜ口頭のプロンプトだと崩れるのか

「タスク管理ツールを作って」とだけ書くと、AIは決まっていない部分を推測で埋める。タスクに期限はあるのか、担当者は付くのか、完了したタスクは消えるのか — どれも決めていないので、その場の自然な解釈で実装される。

問題は、推測が毎回変わることだ。会話を重ねて修正を頼むたびに、前回とは違う前提で書かれる。結果、機能は増えているのに全体の筋が通らないコードが積み上がる。これは能力の問題ではなく、決定が渡されていないことの必然的な帰結だ。

仕様書の価値は「丁寧さ」ではない。推測の余地を先に潰しておくことにある。とくに WON'T(今回は作らない) を明記できるかどうかが効く。書かないと、機能は際限なく膨らむ。

仕様書に入れる項目

渡し方

仕様書ができたら、全文を最初に渡してから、実装ステップ単位で進めるのがいい。「1のステップだけやって」と区切り、動作を確認してから次に行く。まとめて全部を頼むと、途中で仕様から逸れても気づけない。

仕様書づくり自体もAIに任せられる。アイデアの概要を入れると、上の項目を埋めたそのまま貼れるMarkdown仕様書が出てくる(実装ステップとチェックボックス付き)。

仕様書の中身、とくに「作らないもの」の決め方は専用ガイドで詳しく扱っている → MVP仕様書の書き方

動いたあと、公開して終わりにしないために

実装が速くなったことの副作用として、「作ったけど誰にも使われていないもの」が手元に溜まりやすくなった。一晩で作れるということは、一晩で忘れられるということでもある。

最低限やっておくと違うのは、次の3つくらいだ。

• 自分が使う導線に置く — ブックマークバーなり、毎日開くページのリンクなり。自分が使わないものは誰も使わない
• 最初の10人に直接見せる — 不特定多数への告知より、顔の見える10人に見せたほうが情報量が多い
• 畳む条件を先に決めておく — 「3ヶ月使われなかったら止める」と決めておくと、惰性の維持コストに引きずられない

そして、うまくいかなかった案は捨てずに残しておくといい。ボツにした理由が「実装が重い」「APIが無い」だったなら、その前提はまた変わる。⚱ AI供養箱 はそのための場所だ。