プロンプトがあり、アイデアがある。ここから先でつまずく理由と、それを完全に回避する方法を紹介します。

最初のビルドセッションを終えたとします。画面には何かが表示されました。素晴らしい出来だったかもしれません。惜しいけれど、あと一歩という感じだったかもしれません。あるいは、なぜ期待通りに動かないのかわからず、ループにはまってしまったかもしれません。

それは完全に普通のことです。「バイブコーディング（Vibe coding）」は新しい働き方であり、他の新しいスキルと同様、最初の数回のセッションで、ほぼ誰もがつまずくパターンがいくつかあります。朗報なのは、毎回同じ5つのパターンだということです。一度知ってしまえば、次に何が起きるか予測できるようになります。

この記事は、その近道となるガイドです。

この記事の目的はシンプルです：

最初のビルドセッションを早期終了させてしまう5つの間違いを特定する
それぞれの理由を説明する（AIに問題があるわけではありません）
時間を無駄にする前に、それぞれを正確に修正する方法を示す

間違い1 — あいまいなループ

どのような状態か

何かを生成したけれど、しっくりこない。そこで「もっと良くして」や「デザインを改善して」と入力する。AIは何か違うものを生成するが、まだしっくりこない。また「もっと良くして」と入力する。また変わる。30分後、4つのバージョンを試したが、どれも自分のイメージ通りではない。

これが「あいまいなループ」です。最初のセッションで最も多い間違いです。

なぜ起きるのか

AIはあなたに対して出し惜しみをしているわけではありません。あなたにとって「より良く」が何を意味するのかを本当に理解していないのです。あなたの好み、ターゲットとする読者、あるいは具体的に何が不満なのかという参照情報がありません。だから推測するしかなく、不明瞭な指示に対して出した推測が正解であることはほとんどありません。

修正法：評価するのをやめ、指示を出す

「評価」はAIに何かが間違っていると伝えるだけですが、「指示」は代わりにどうすればいいかを伝えます。

あいまいな指示 → 「もっと良くして。」具体的な指示 → 「見出しのフォントが細すぎて読みにくい。もっと太くして、ページの上部で目立つような大きさに変更して。」

調整のためのプロンプトを入力する前に、自分に問いかけてください。「具体的に何が間違っていて、具体的に何を代わりにすればいいのか？」。まずその質問に答えてから、入力してください。

もし何が間違っているのか言葉にできない場合は、EnterのVisual Editor（ビジュアルエディタ）を使用してください。気になっている要素をクリックして直接調整し、理想の形になったら、今変更した内容を次のプロンプトとして記述します。クリックと記述の組み合わせは、プロンプトだけで推測し続けるよりもはるかに高速です。

間違い2 — 全書き換えの罠

どのような状態か

何かがうまく機能しないので、AIに最初からやり直すよう頼みます。新しいバージョンには別の問題があり、また最初からやり直すよう頼みます。1時間後、5つの全く異なるバージョンを目にすることになりますが、同時に、これまでのバージョンでうまく機能していた部分もすべて失っています。

なぜ起きるのか

最初からやり直すことは、決断力があるように思えます。進歩しているように感じます。しかし、どちらでもありません。

すべての完全な書き換えは、間違っていた部分だけでなく、うまくいっていたすべてのものまでも捨て去ります。気に入っていたレイアウト、理想に近かった見出し、ほぼ完成していた構造。すべてがゼロに戻り、また新しい一連の問題を解決しなければならなくなります。

修正法：核攻撃ではなく外科手術を

書き換えを依頼する前に、自問してください。「すべてが壊れているのか、それとも特定の1つの要素が壊れているのか？」

ほとんどの場合、壊れているのは特定の1つの要素です。それを見つけ、特定し、その部分だけを修正してください。

あいまいな指示 → 「やり直して、気に入らない。」具体的な指示 → 「ナビゲーションバーが上部で場所を取りすぎているので、高さを減らしてリンクを小さくして。それ以外はそのままにして。」

2番目のプロンプトは問題を解決しますが、最初のものは新しい問題を生み出します。何かがおかしいとき、すべてを壊したいという衝動に抵抗してください。特定の箇所を修正し、うまくいっている箇所は維持しましょう。

間違い3 — 機能の肥大化

どのような状態か

製品の核となる部分は機能しています（完璧ではありませんが）。そこで何かを追加します。プロフィールページ。オンボーディングフロー。共有機能。そうすると、完全に完成していない基盤の上に構築することになります。新しい機能によって別の場所でバグが発生します。本来ならまだ構築すべきではなかった機能のデバッグに時間を取られることになります。

なぜ起きるのか

何かがうまくいくと、拡張したくなるのが本能です。核となる部分は解決したように感じるので、足りない部分に注意が向きます。しかし、次に進もうと決めた瞬間には、核はまだそれほど強固ではないのです。

修正法：次の機能を構築する前に、一つのことを完成させる

機能を追加する前に、自問してください。「核となる機能は十分にうまく機能しており、これを追加することでさらに良くなるのか。それとも、核を完成させるのを避けるためにこれを追加しようとしているのか？」

最初のビルドセッションでは、答えはほとんど常に後者です。

コア部分にとって「完了」とはどのような状態か定義してください。実際の1人にとって真に役立つ、この製品の最小限のバージョンとは？感銘を与える必要はありません。役立つかどうかです。まずはそれを構築してください。端から端まで正しく機能することを確認します。それから、その後に次の機能を追加してください。

最高のビルドは、最も多くの機能を持っているものではありません。存在するすべての機能が実際に動作するものです。

間違い4 — 完璧主義者の停滞

どのような状態か

機能するものがあるのに、ボタンの色が正確ではないからといって20分費やします。次に、見出しの間隔がわずかにずれている。さらに20分。フォントの太さ。パディング（余白）。2時間が過ぎます。製品は始めた時よりわずかに良くなっただけですが、まだ誰にも見せていません。

なぜ起きるのか

完璧を求めることは、リリースするよりも安全だと感じられます。まだ作業中であれば、それは間違っているとは言えません。他の誰かがそれを見た瞬間、理解されない可能性がある。それは、わずかに色味の違うボタンよりも向き合うのが難しいものです。

修正法：誰かに見せられるレベルを目指す

誰か他の人があなたの製品を30秒間使ってくれることで得られるフィードバックは、2時間の独りよがりな調整よりも価値があります。最初の10秒間の彼らの混乱（どこをクリックするか、どこで止まるか、何を見落とすか）こそが、次に何を修正すべきかを教えてくれます。何時間も同じ画面を見つめた後では、自分の目ではそれに気づくことができません。

セッションにルールを設けてください。実際の1人に見せられるレベルになったら、調整をやめて見せること。完璧になった時ではありません。「見せられるレベル」こそがマイルストーンです。

不完全なものをリリースしましょう。そこから学び、そして改善するのです。

間違い5 — 孤立した作業（ソロ・サイロ）

どのような状態か

ひとりで構築し、ひとりで調整し、ひとりで反復する。あなたは何のためにすべてがあるのか、なぜそのボタンがあるのか、各セクションが何をするのかを理解しています。製品はあなたにとっては完璧に筋が通っています。しかし、ようやく誰かに見せた時、彼らは最初の10秒で混乱します。

それを3時間前に知ることもできたはずです。

なぜ起きるのか

特に初めての時は、構築は個人的なことのように感じられます。未完成のものを見せることは脆弱性をさらけ出すことになります。「理解されなかったらどうしよう？」「デザインがひどいと思われたらどうしよう？」

それらは現実の恐怖です。しかし、それこそが、あなたが知る必要があることそのものです。

修正法：早く公開し、リンクを共有し、何が起きるか観察する

Enterは、あなたのプロジェクトを即座にライブURLへデプロイします。そのリンクは、あなたが得られる最速のフィードバックメカニズムです。1人に送ってください。承認を得るためではなく、観察するためです。彼らがどのように操作するかを見てください。どこで立ち止まるかに気づいてください。何をクリックして、何をクリックしなかったか。何を見落としているか。