入門シリーズで、あなたはもう「AIに頼んで、動くアプリを1本作って公開する」を一周したはずだ。だが、その先にもう一段の壁がある。機能が10を超えたあたりから、1つ足すたびに別の場所が壊れる。いざ人に配ってみると、自分のパソコンでは動くのに相手の環境だけ起動しない。AIが書いたコードが、エラーひとつ出さずに“それっぽく間違っている”。「小さく作る」を覚えただけでは越えられないこの壁を、私は実際に動くアプリを7本公開する中で、ぶつかっては越えてきた。その進め方を、ここに全部書く。
この記事は「入門の続き」だ
まず立ち位置をはっきりさせておく。「バイブコーディングとは何か」「最初のAIの選び方」「メモ帳アプリの作り方」。その基礎は、もう 入門シリーズ（全7回）で一周した前提だ。だからここでは繰り返さない。この記事が扱うのは、その基礎を「人に毎日使ってもらえる物」まで持っていく段階で、初めて見えてくる進め方のほうだ。
私はプログラミングを体系的に習ったわけではない。それでもバイブコーディングだけで、実際に動くアプリを7本作って公開してきた。複数AIを1画面に束ねるデスクトップ司令塔、高精度OCRアプリ、文字起こしアプリ、背景除去ツール、X(旧Twitter)向けのメディア生成パイプライン、ブラウザで遊べる2D RPG、そして都市開発シミュレーションゲームまで。メモ帳1個のときには出てこなかった問題が、この規模では次々に出た。以下の5つは、その7本でしか学べなかった「最後まで完成させ、人に渡せる物にする」ための効かせどころだ。各原則の最後に、実際にそれを使った制作記事を置いた。口で言うだけなら誰でもできる。だから、動いているアプリそのものを一緒に見てほしい。
（もしまだ1本も完成させていないなら、先に 入門1 から一周してくるのが近道だ。この記事は、その手応えがある人に一番効く。）
7本を通して見えた、「完成しない」共通パターン
規模の違う7本を作っても、つまずきの正体は驚くほど同じ4つに集約された。入門でも場面ごとに触れてきたが、ここで一度ひとまとめにしておく。これが、次の5原則の“裏返し”になっている。
- 「何を1つと数えるか」を決めずに割っている。入門で「小さく作る」は覚えた。だが規模が出ると、機能の“割り方”そのものを設計しないと、小さく頼んでいるつもりで塊が育つ。
- 画面や機能は決めたが、「データの流れ」を決めていない。見た目だけ先に固めて作り始めると、後から処理の順序がねじれて崩れる。
- 「自分の環境で動いた」で確認を止めている。配った先・固めた後では別の壊れ方をする。手元の成功は、人に渡せる証明にはならない。
- エラーが出ない間違いを見逃している。AIは平気で、それっぽいけれど誤った物を自信満々で出す。エラーで止まってくれる間違いより、これがずっと厄介だ。
裏を返せば、この4つを反対にするだけで、未経験でも“完成率”はまるで変わる。順に見ていこう。
実例7本でたどり着いた、5つの進め方
先に言っておく。あなたが次に作る物は、7本のような大きさでなくていい。この5つの効かせどころを意識して回せるかどうかが決め手だ。入門で覚えた基本動作の“一段上”として読んでほしい。
1. 「1つずつ」の先へ：“何を1つと数えるか”を設計する
入門で「機能は1つずつ作って動かす」は身についたはずだ。実アプリでは、その手前にもう一手ある。そもそも機能を「どの単位に割るか」を、最初に設計する。複数AIを1画面に束ねる司令塔アプリを作ったとき、機能を1画面に詰め込もうとした瞬間に破綻した。そこで「会話」「生成」「ワークスペース」とタブで役割を分け、1タブ＝1つの関心事に絞り直したら、一気に作りやすくなった。「1つずつ」は手順、「何を1つと数えるか」は設計だ。小さな物では勝手に決まるこの線引きが、規模が出ると効いてくる。
👉 実際にこう作った: Claude Mission Control の作り方
2. 「相談する」の先へ：“データの流れ”を先に固定する
入門で、いきなり「作って」と言わずAIに相談する頼み方は学んだ。実アプリでは、相談で固めるべき中身が一段深くなる。画面や機能だけでなく、「データがどこから来て、どう変わって、どこへ出るか」という流れを、コードの前に言葉で確定させる。文字起こしアプリでは「録音 → 文字起こし → Word出力」という流れを最初に固定したから、途中で道に迷わずに済んだ。流れさえ決まっていれば、それぞれの段はAIに任せても全体は崩れない。設計図を持って歩くか、地図なしで歩くかの違いだ。
👉 実際にこう作った: Whisper文字起こしアプリの作り方
3. 「役割で分ける」を、配布に耐える“線引き”まで決め切る
入門で「係を分ける（責務の分離）」の入口には触れた。人に配る規模では、ここを曖昧にしたまま育てると、後でほぼ確実に詰まる。「画面を出す係」「処理をする係」「データを保存する係」を、どのファイルに何を置くかまで最初に決め切る。司令塔アプリでは「画面は表示だけ・中身の処理は1か所に集める」と線引きを固定したら、どこを直せばいいか毎回迷わなくなった。分けること自体より、“置き場所のルールを先に決め切る”ことが、後から壊れない土台になる。
👉 実際にこう作った: 背景除去アプリの作り方
4. 動作確認を、「配った先」まで届かせる
入門で「ちゃんと動くか自動でチェックする仕組み（テスト）も一緒に書く」ことには触れた。人に渡す段になると、確かめる場所が自分のパソコンの外まで広がる。OCRアプリを配布用に固めたときは、手元では完璧に動くのに、配布版だけ起動に失敗するという罠にはまった。毎回きちんと動作確認を回していたから、どの工程で壊れたのかをすぐ特定できた。「自分の環境で動く」と「配った先で動く」はまったくの別物だ。自動チェックを最初から仕込み、さらに“配る形そのもの”でも一度動かして確かめる。これが、ある程度の規模になると生命線になる。
👉 実際にこう作った: 高精度OCRデスクトップアプリの作り方
5. エラーが出ない“それっぽい間違い”を、レビューで捕まえる
入門で、エラーが出たらその文をそのままAIに貼って直す、という基本は身についたはずだ。本当に厄介なのは、エラーすら出さずにAIが自信満々で間違えるときだ（いわゆるハルシネーション）。文字起こしアプリでは、AIが無音部分にありもしない言葉を勝手に補う癖があり、出力の説明を読み込んで気づき、対策を入れて初めて使い物になった。コードは書けなくていい。だがAIが何をしたかの「説明」は必ず読む。「ここはなぜこうしたの？」「もっと読みやすく直して」と問い返し、AIを部下ではなくレビューし合う相棒として扱う。エラーを直す力の、その一歩先にあるスキルだ。
👉 実際にこう作った: Xメディア生成パイプラインの作り方
次の一歩：どこへ進むか
ここまでの5つは、入門で覚えた基本動作を「途中で壊れない・人に渡せる」レベルまで引き上げるための効かせどころだ。新しい道具は要らない。要るのは、この“意識の置きどころ”だけだ。あなたの今の位置に合わせて、次はこう進めばいい。
- まだ1本も完成させていないなら → まず 入門1〜7 で「作って公開する一周」を体験する。話はそれからだ。
- すでに1本作れたなら → この5原則を意識しながら、2本目を“一回り大きく”作ってみる。大きめの見本が欲しければ、AIと都市開発シミュを組み上げる実践連載（全6回）がある。壁にぶつかった原則の制作記事を、その都度のぞきに来てほしい。
- 何を作るか迷うなら → 開発実例ギャラリーで、AIで実際に作れる物の幅を眺める。次のアイデアは、たいていそこで見つかる。
正直なまとめ
正直に言う。AIは万能ではないし、最初のうちは思ったより時間がかかる。エラーにも、エラーすら出ない間違いにも、何度もぶつかる。それでも、ここで挙げた5つ（何を1つと数えるかを設計する／データの流れを先に固定する／配布に耐える線引きを決め切る／確認を配った先まで届かせる／エラーの出ない間違いを捕まえる）を意識するだけで、AIは「丸投げで終わる相棒」から「完成まで連れて行ってくれる相棒」に変わる。私が未経験から実際に7本を作って公開できたのだから、特別な才能は要らない。要るのは、入門で覚えた基本と、この一段上の進め方。あとは、あなたが次の1本に手をつけるかどうかだけだ。
バイブコーディングを始める道具 PR
🖥 作ったものを公開する場所（サーバ/ドメイン）
🤖 コードを書かせるAIツール（公式）
📚 進め方を深める技術書（Amazon）
👉 次は、実際に作った物を見てください: AIで作った実例の一覧（開発実例ギャラリー） ・ ほかのアプリの作り方 ・ まだ入門が済んでいない方は 入門1から
