未経験からアプリ開発｜バイブコーディングで最初の1本を作る方法

未経験からアプリを作る。それが実現する時代になった。

でも、実際に始めようとすると色々な質問が出てくる。何から作ればいい？どのプロンプトで指示する？エラーが出たらどうする？

僕は週に50人以上のバイブコーディング初心者と接する立場だ。その中で見えてきたのは、最初のアプリ選びと最初のプロンプトで、成功するかどうかが大きく変わるということだ。

この記事では、実際に受講者が作ったものを事例に挙げながら、最初の1本を確実に完成させるまでの道のりを具体的に解説する。完璧を目指さなくていい。動くものを作ることが全てだ。

最初に作るアプリは何がいいか

初心者がよく「何を作ったらいいですか？」と聞く。その時の僕の答えはいつも同じだ。

自分が毎日使いたいと思えるもの。ただしシンプルなもの。

複雑さと実用性のバランスが大事だ。以下の4つのアプリを比較してみよう。

僕が最初のアプリとして推すのはToDoリストだ。理由は3つある。

1つ目、自分が毎日使う可能性が高い。だから完成後もアプリを触り続け、改善のアイデアが湧く。2つ目、機能が明確で、AIに説明しやすい。要件がシンプルだから、プロンプトもシンプルになる。3つ目、ユーザーインターフェースの基本（入力、表示、削除）が全て含まれているので、学習効果が高い。

AIへの最初のプロンプト

では、実際にToDoアプリを作る場面を想像してほしい。

AIに「ToDoアプリを作って」と言うだけでは、返ってくるコードがめちゃくちゃになる可能性がある。重要なのは、要件を余すことなく、でも短く、明確に伝えることだ。

僕が受講生に勧める最初のプロンプトはこれだ。

「HTMLとJavaScriptで動作するToDoアプリを作ってください。以下の機能が必要です。1つ目、テキストボックスに任意のタスクを入力して『追加』ボタンで登録する。2つ目、登録されたタスク一覧を画面に表示する。3つ目、各タスクの横に『完了』ボタンと『削除』ボタンを付ける。完了ボタンを押すと、そのタスクに取り消し線を引く。削除ボタンを押すと、タスクが一覧から消える。見た目は白基調で、シンプルに。」

このプロンプトが良い理由は、機能が明確で、実装の指針が見えているからだ。曖昧な言葉や長たらしい説明がない。AIにとって解釈の余地がないプロンプトは、精度の高いコードを返してくる。

ポイントは、口語で構わないってことだ。「テキストボックスに任意のタスクを入力して」なんて、少し日本語がおかしい。でも、AIはこれで理解する。むしろ、「何が必要なのか」を明確に書く方が、「自然な日本語で説明する」より大事だ。

逆に、やってはいけないプロンプトを1つ例に挙げておく。それは「素晴らしいToDoアプリを作ってください」という頼み方だ。「素晴らしい」って何だ。AIは困る。その結果、あなたの想像と全く違うアプリが返ってくる。だから、「素晴らしい」とか「使いやすい」みたいな抽象的な言葉は避ける。「白基調」「シンプル」みたいに、具体的に書く。

実装の流れを実演する

次は、実際のアプリ開発を進める流れを見てみよう。ここではCursorというAIコーディングツールを使う想定だ。

エラー対処のコツ

バイブコーディング初心者が最も困るのは、エラーが出た時だ。

従来のプログラミングなら、自分でエラーメッセージを読み解いて、原因を特定して、コードを修正する。その過程に数時間かかることも珍しくない。

バイブコーディングは違う。エラーメッセージをコピーして、AIに投げるだけだ。

「このJavaScriptエラーが出ました。『Uncaught TypeError: Cannot read property ‘addEventListener’ of null』修正してください。」

この一文で十分だ。AIはエラーの原因を特定して、修正案を提示する。ほとんどの場合、その修正案を実装すれば、エラーは消える。

実際のところ、バイブコーディングでのエラーは大きく2つに分かれる。1つ目は構文エラー。括弧の閉じ忘れとか、セミコロンの漏れとか。AIに「このエラーを直して」と投げれば、5秒で返ってくる。2つ目は論理エラー。アプリは動くんだけど、仕様と違う動きをする場合だ。この場合は「このボタンをクリックしても何も起きない」みたいに、現象を説明するといい。

僕がよく見かける失敗パターンがある。エラーが出ると、初心者は自分でコードをいじろうとする。中途半端な修正を加えて、ますますカオスになる。その結果、AIに投げるときは「このコード全体がおかしくなった」という状態になってる。だから、エラーが出たら、すぐにAIに相談することだ。いじるな。投げろ。それがバイブコーディングの流儀だ。

受講生の実例

ここまで理論で説明してきたが、実際にどのくらいの完成度に達するのか、具体例を紹介しよう。

先月、営業職の30代女性が僕のバイブコーディング講座に参加した。プログラミング経験は全くない。それでも、初日の3時間で自分用のToDoアプリを完成させた。

彼女が最初に作ったアプリは、タスク追加、削除、完了の3機能だけ。背景は白で、フォントもデフォルト。言ってしまえば、デザインはダサい。だが、動く。毎日のタスク管理に使えている。

その後、彼女は自分でプロンプトを編集して、優先度のタグ機能を追加した。期日の表示を追加した。色を変えた。その過程で、彼女はプログラミングの基礎を体で理解した。コードの構造とか、関数とか、変数とか。教科書で学ぶのとは違う。自分が作ったアプリで試行錯誤しながら学ぶから、実践的な知識が身につく。

2週間後、彼女は同じ方法でメモ帳アプリも作った。今度は最初のToDoアプリより、ずっと短い時間で完成した。理由は簡単。プロセスが分かったから。1ヶ月後には、顧客情報管理ツールを業務で使える形にまで仕上げた。営業の仕事効率が20%上がったと、彼女は言っていた。これが実力だ。

もう1人、20代の新卒エンジニアの例を紹介しよう。彼はプログラミング経験があった。むしろ、その経験があるせいで、最初は苦労していた。なぜなら、バイブコーディングのやり方が、従来のプログラミングと真逆だからだ。コードを細かく読む必要もない。完璧性を追い求める必要もない。その思考を切り替えるまでに、1週間かかった。だが、切り替わった後は、彼の成長が目覚ましかった。従来のやり方より、5倍のスピードで機能を実装できるようになった。

完璧を目指すな、まず動かせ

バイブコーディングの最大の利点は、スピードだ。従来のプログラミングなら数週間かかる開発が、数時間で終わる。

その代わり、最初からミリ単位で完璧を目指そうとする人は失敗する。なぜなら、バイブコーディングは反復的なプロセスだからだ。

まず動く最小限のアプリを作る。次に、「こういう機能があったらいいな」と思ったら、そこをAIに改善させる。その繰り返しだ。この考え方がなければ、完璧なコードを求めるあまり、プロンプトが複雑になる。複雑なプロンプトはAIの精度を下げる。結果として、返ってくるコードがめちゃくちゃになることすらある。

実は、このプロセスは、優れたプロダクト開発の手法「MVP（Minimum Viable Product）」と同じ考え方だ。最小限の機能で市場に出す。ユーザーの反応を見て改善する。バイブコーディングは、このMVP思想をプログラミングに持ち込んだものなんだ。

「動く」が全てだ。デザインがダサくてもいい。パフォーマンスが悪くてもいい。とにかく、ユーザーがやりたいことができる状態に持っていく。その先の改善は、その後のプロンプトで十分だ。

次のステップへ

ToDoアプリが完成したら、次は何をするか。

そこから先は、自由だ。メモ帳アプリを作ってもいい。カウンターアプリを作ってもいい。あるいは、自分の業務で使える簡単なツールを作るのもいい。

重要なのは、一度「動くアプリを作る」という経験を手に入れたことだ。その経験があれば、次のアプリは1時間で完成する。その次は30分だ。

6ヶ月後、あなたは10個以上のアプリを作ってるはずだ。そしてその時点で、あなたは立派なアプリ開発者だ。