いよいよフェーズ3「作る」です。第2章で決めた仕様と、第3章で選んだ技術・ツールを手に、実際に動くものを組み上げていきます。ここでつまずく人の多くは、実は「コードが書けない」からではありません。一気に完成を目指してしまうから挫折するのです。この章では、AIを相棒に「小さく作って動かす」を高速で回す作り方を、入門・実践の両ルートで案内します。
目指すのは「一気に完成」ではなく「小さく前進」
実装の基本姿勢 ― 小さく回す
実装で最も大切な姿勢は、たった1つです。「小さく作って動かし、直す」を高速で繰り返すこと。頭の中にある完成形を一発で作ろうとせず、まず一番小さな「動く塊」を作り、それを少しずつ育てていきます。
なぜこれが効くのか。プログラムは動かして初めて、何が間違っているかがわかるからです。100行書いてから一度に動かすと、どこが原因かわからず途方に暮れます。10行書いて動かせば、間違いはその10行の中にしかありません。AIに書かせる場合もまったく同じで、小さく頼んで、すぐ確認する方が、結果的にずっと速く・確実に進みます。
「全機能を一気に作って」とAIに丸投げ。大量のコードが出てくるが、動かすとエラーだらけ。どこが原因かわからず、直す気力も失う。
「まず一覧を表示する画面だけ」と1機能ずつ依頼。動いたら次、を積み重ねる。常に「動く状態」を保ったまま前進できる。
⚠️ AIのコードも間違える ― だから必ず自分で動かす。 AIが書いたコードは、それらしく見えても動かすとエラーだったり、意図と違う動きをすることがよくあります。「AIが書いたから正しいはず」は禁物。出てきたコードは必ず自分の手で動かして、目で確認する。これが個人開発で最初に身につけるべき鉄則です。動かさずに次へ進むと、間違いが積み重なって手に負えなくなります。
「作って動かして直す」ループの手順
この「小さく回す」を、具体的な4ステップにしたものが下の図です。1機能ぶんを、このループでぐるぐる回していきます。1周は数分〜数十分。速く回すほど上達します。
「次はこの1機能だけ」とAIに具体的に依頼。範囲を絞るほど精度が上がる。
出てきたら即実行。ブラウザやターミナルで自分の目で結果を確かめる。
エラーや違和感があれば「ここをこう直して」と会話で修正。動くまで繰り返す。
動いたら区切りとして保存（コミット）。良い状態を残し、次の機能へ。
💡 STEP 4「保存」を軽視しない。 機能が1つ動くたびに保存（Gitのコミット）しておくと、次の変更で壊れても直前の動く状態に戻せます。「昨日は動いていたのに」の悲劇を防ぐ命綱です。保存の具体的なやり方は次の第5章で詳しく扱います。
入門ルートと実践ルートの実装スタイル
「小さく回す」は共通の姿勢ですが、具体的な回し方はルートによって変わります。第1章で選んだ自分のルートに合わせて、進め方を確認しましょう。もちろん、途中で混ぜても乗り換えてもかまいません。
バイブコーディングで、AIと会話しながらアプリを組み立てます。「一覧画面を作って」→「ボタンの色を青に」→「押したら保存されるように」と、日本語で頼んで、画面を見て、また頼む。この繰り返しが、そのまま「小さく回すループ」になります。
コツ: 一度に1つだけ頼む。うまくいかなければ「さっきの変更を戻して」と言えばよい。
Claude Codeなどに仕様書ごと渡して、まとまった実装を任せます。作業量に応じて工数（effort）を調整し、勝手にファイルを書き換えすぎないよう権限モードを使い分けて安全に自動化するのがポイントです。
コツ: 大きく任せても、確認は小さく。詰まったらエラー集で対処法を探す。
どちらのルートでも、忘れてはいけないのは「出てきたものを自分で動かして確かめる」という基本姿勢です。会話で作ろうが自動で作らせようが、確認するのは人間の仕事。この一手間を省かないことが、完成にたどり着くかどうかの分かれ道になります。
AI機能を組み込むなら
作っているものが「AIを使うアプリ」――たとえば文章を要約する、質問に答える、画像を判定する――なら、アプリの中からAIを呼び出す仕組みが必要です。ここは少しだけ専門的になりますが、選択肢は大きく3つに整理できます。自分のアプリに必要なものだけ選べば十分です。
🧭 迷ったら①だけでいい。 最初のMVPでは、1つのAI APIを呼ぶだけで十分なことがほとんどです。②③は「複数モデルを比べたい」「自前データで答えさせたい」という必要が出てから足せばOK。ここでも「小さく作る」が正解です。
詰まったときの動き方
実装中は、必ずどこかで詰まります。エラーが出る、思った動きにならない――これは失敗ではなく作っている証拠です。大事なのは、詰まったときにパニックにならず、順番に切り分けること。AIがいる今、詰まりは以前よりずっと早く抜けられます。
赤い文字を丸ごとコピーして「このエラーが出た。原因と直し方は？」と聞く。エラー文が最大のヒント。自己流で書き換えず、まず貼る。
「どこまでは動いていたか」を思い出す。直前に変えた1か所が原因のことが大半。範囲を狭めれば原因は必ず見つかる。
こじれたら、保存しておいた直前の動く状態に戻してやり直す。深追いより、いったん戻る方が速いことも多い。
🔧 実践ルートの人へ。 Claude Codeなどでよく出るエラーと対処はエラー集にまとまっています。同じエラーで悩むのは時間の無駄。詰まったらまず調べる、それでも駄目ならAIに聞くを習慣にしましょう。
この章のまとめ
フェーズ3「作る」の核心は、テクニックよりも「小さく作って動かして直す」を高速で回す姿勢にあります。一気に完成を目指さず、動く塊を少しずつ育てていきましょう。
動くものができたら、次はそれを安全に世へ出す番です。前の第3章「技術とツールを選ぶ」に戻って準備を見直すこともできますが、実装が回り始めたら、テストとセキュリティを固めて公開する第5章「テストして世に出す」へ進みましょう。