前の章で、個人開発は「決める→準備→作る→出す→育てる」の5フェーズで進むこと、そして鉄則は「1機能に絞ってMVPを公開する」ことだと確認しました。この第2章は、その最初のフェーズ「決める」を扱います。何を・誰のために作るかを小さく決め、それを仕様（spec）という形にするところまでを、一緒に進めましょう。
「作りたいもの」を、AIに渡せる形まで固める
なぜ最初に「決める」のか
早くコードを書き始めたい気持ちはよくわかります。でも、個人開発でいちばん多い失敗は「作りながら何を作っているのか分からなくなる」こと。ゴールが曖昧なまま手を動かすと、途中で「やっぱりこの機能も」と方向がぶれ、いつまでも完成しません。
だからコーディングは後回しでいいのです。まず「何を・誰のために・どこまで作るか」をはっきりさせる。地図もゴールも決めずに歩き出せば迷子になるのは当然で、逆に行き先さえ決まっていれば、AIという相棒が最短ルートまで案内してくれます。
機能が次々増えて複雑化。AIへの指示も毎回ぶれる。完成が遠のき、やる気が尽きて放置。
ゴールが1つに定まる。AIに的確に指示でき、出力もぶれない。最短で「動くもの」に到達。
💡 「決める」は考え込む時間ではありません。 完璧な企画書はいりません。この章でやるのは、A4の紙1枚（あるいはメモ1画面）に収まる程度の小さな決断です。悩んで止まるより、仮でもいいから決めて前に進むほうが、ずっと早くゴールに着きます。
アイデアの見つけ方 ― AIで壁打ち
「作りたいものが特にない」――大丈夫です。アイデアはゼロからひねり出すものではなく、身近な不便から拾うものです。そしてその発掘作業こそ、AIがいちばん得意とするところ。一人でうんうん唸る必要はありません。AIを壁打ち相手にすれば、アイデアはどんどん湧いてきます。
毎日ちょっと面倒に感じていること。手作業の繰り返し、記録の手間、探しものの時間。あなたが困っていることは、他の誰かも困っています。
「こんなアプリがあれば使うのに」と思ったもの。最初のユーザーは自分。自分が本気で欲しいものは、作る動機が続きます。
漠然とした興味をAIに投げ、質問を返してもらう。対話するうちに輪郭が見えてくる。思いつきを口に出す相手として最適です。
壁打ちのコツは、具体的なお題を投げること。「何かいいアプリない？」では良い答えは返りません。次のように、視点を絞って聞いてみましょう。
- 「家計管理の面倒を解決するアプリ案を10個、一言ずつ出して」
- 「その中で、一番小さく作れるのはどれ？ 理由も添えて」
- 「この案、本当に使う人はいる？ 想定ユーザーと使う場面を教えて」
- 「似たサービスは既にある？ あるなら、個人が狙える差はどこ？」
- 「この案を1機能だけに削るなら、残すべき機能はどれ？」
10個出させて1個選ぶ、という進め方が効きます。AIは大量の候補を一瞬で並べてくれるので、あなたの仕事は「選ぶ」ことに集中できます。ピンとくるものがあれば、それをさらに深掘りしていきましょう。
1機能に絞る ― 個人開発の鉄則
アイデアが見えてきたら、次に大事なのが「盛りすぎない」こと。前の章の鉄則を覚えていますか。1機能に絞ってMVPを公開する――これは個人開発でいちばん破られやすく、いちばん守るべきルールです。
「せっかく作るなら、あの機能もこの機能も」と欲張った瞬間、完成は遠のきます。機能が2つになれば作業は2倍ではなく、組み合わせのぶん3倍・4倍に膨らむからです。一人の時間と気力には限りがあります。最初は、たった1つの「これができれば価値がある」に絞りきる。
本の登録・感想メモ・星評価・読書時間グラフ・友達と共有・おすすめ本のAI提案・バーコード読み取り…。全部入りを目指して、いつまでも完成しない。
「読んだ本を1行の感想と一緒に記録する」だけ。一覧で振り返れれば十分。まず公開し、使われたら次を足す。
✅ 削る基準は「これが無いと成り立たないか」。 迷った機能はまず「後で」の箱に入れましょう。捨てるのではなく、公開後に本当に必要なら足す。最初の1機能が動いて誰かに使われたとき、次に何を足すべきかはユーザーの反応が教えてくれます。
アイデアを1行に言語化する
絞った1機能を、次は1行の言葉にします。ここがこの章の核心です。頭の中のふわっとしたイメージを、「誰の・どんな不便を・どう解決するか」という形にはめ込むと、アイデアが一気に具体化します。
「本をよく読む人のための、読んだ本をすぐ忘れてしまう不便を、1行の感想と一緒にサッと記録して一覧で振り返れるようにするアプリ。」
この1行が書ければ、あなたの個人開発は半分成功したようなものです。以降のすべて――技術選び、AIへの指示、公開時の紹介文まで、この1行がぶれない軸になります。うまく書けないときは、これもAIに手伝ってもらいましょう。「この機能を、誰の・どんな不便を・どう解決するかの1行にして」と頼めば、いくつも案を出してくれます。
仕様に落とす ― AI開発の土台
1行が固まったら、最後に仕様（spec）にします。仕様とは「何を作るかの設計メモ」。難しく考えず、画面・データ・操作の3点を最小限で書き出すだけで十分です。
なぜ仕様が大事か。AIコーディングでは、仕様がそのまま土台になるからです。「こんなアプリ作って」と丸投げするより、画面とデータと操作を書いた仕様を渡すほうが、AIは何倍も正確なコードを返します。この考え方を突き詰めたのが仕様駆動開発（Spec-Driven Development）で、個人開発でも同じ原則が効きます。
どんな画面が必要か。
例：記録一覧・記録の追加。2〜3画面で足りることがほとんど。
何を保存するか。
例：本のタイトル・感想・記録日。項目を箇条書きにするだけ。
ユーザーが何をできるか。
例：記録を追加する・一覧で見る。できることを動詞で並べる。
この3つを書き出したものが、あなたの最初の仕様です。たとえば読書記録アプリなら、次のようなメモになります。
データ: 本のタイトル（文字）／感想（1行の文字）／記録日（日付）
操作: 記録を追加する・一覧で新しい順に見る・記録を削除する
💡 仕様は完璧でなくていい。 最初から全部書ききる必要はありません。作りながら「あ、これも要るな」と気づいたら追記すればいい。大事なのは「まず土台となる1枚を持つ」こと。真っ白から作るより、たたき台があるほうがAIも人も何倍も速く進めます。
入門ルート／実践ルートの進め方
ここまでの「決める」作業は、どちらのルートでも同じです。違うのは仕様をどこまで形式的に書くかと、それを誰に渡すかだけ。自分のルートに合わせて進めましょう。
仕様はメモ帳やノートに手書きでOK。整った文書は不要です。「画面・データ・操作」を箇条書きにしたら、そのままAIチャットに貼り付けて壁打ち。「この仕様、抜けや矛盾はある？」と聞けば、AIが穴を埋めてくれます。
この章のゴール: 1行の言語化と、3点メモが書けていればOK。
仕様をMarkdownファイル（例: spec.md）にまとめ、Claude CodeやCursorに渡します。AIエディタは仕様書を読んで実装の土台にするので、ここが丁寧なほど後が速い。書き方は仕様駆動開発が参考になります。
この章のゴール: AIエディタに渡せる spec.md が1枚できていればOK。
どちらのルートでも、この章を終えた時点で「1行の言語化」と「画面・データ・操作の最小仕様」が手元にある――それがゴールです。ここまで来れば、あとは作る土台を整えるだけ。次のフェーズに進む準備が整いました。
まとめと次の章
- コーディングは後回し。まず「何を・誰のために作るか」を決めると迷子にならない。
- アイデアは身近な不便・自分の欲しいものから。AIで壁打ちして10個出し、1個選ぶ。
- 個人開発の鉄則は「1機能に絞る」。迷った機能は「後で」の箱へ。
- アイデアを「誰の・どんな不便を・どう解決するか」の1行に言語化する。
- 仕様は画面・データ・操作の最小3点。AIコーディングでは仕様が土台になる。
- 入門はノートとAIチャット、実践はMarkdownの spec.md で進める。
「決める」フェーズはここまで。アイデアが1行になり、最小仕様が手元にあれば、もう作り始める一歩手前です。次は、それを実際にどんな技術・ツールで作るかを決めるフェーズ。前の第1章「全体像とルート選び」に戻って地図を見直してもよいですし、そのまま第3章「技術とツールを準備する」へ進みましょう。あなたの1行を、形にする土台づくりが始まります。