バイブコーディングがうまくいかないとき、原因の大半はツールではなく指示にあります。

同じツール・同じ課題でも、指示の出し方で結果はまるで変わります。この記事では、現役エンジニアとして実務で使っているAIが誤解しない伝え方を7つに絞って書きます。

コツ1：1指示1目的に区切る

最も効きます。

悪い例

ログイン機能を作って、あとデザインも整えて、テストも書いておいて

良い例

ログイン機能を作って。まずは入力欄と送信ボタンだけでいい

まとめて頼むと、AIは優先順位を自分で決めます。その判断があなたの意図とずれると、全部が微妙にずれます。小さく区切って、確認しながら積むのが最短です。

コツ2：「どこを」を先に言う

AIは、対象が曖昧だとプロジェクト全体を探しにいきます。時間もかかり、費用も増えます。

悪い例

レイアウトが崩れてる。直して

良い例

ヘッダーのナビゲーションが、スマホ幅で改行されて2段になっている。そこだけ直して

ファイル名が分かるなら、それも添えてください。場所が特定できた瞬間、精度が跳ね上がります。

コツ3：「どうなってほしいか」を書く（「どう直すか」ではなく）

実装方法まで指定すると、AIの得意分野を潰してしまいます。

惜しい例

flex-wrap: nowrap を付けて

良い例

スマホ幅でもナビゲーションを1行に収めたい。入りきらないならハンバーガーメニューにしてほしい

What（どうなってほしいか）はあなたの仕事、How（どう実現するか）はAIの仕事。この分担を崩さないでください。技術に詳しくない人ほど、この形が有利に働きます。

コツ4：エラーは全文そのまま貼る

要約しないでください。

悪い例

なんかエラーが出た

良い例

こういうエラーが出た（以下、ターミナルの出力を全文貼る）

エラーメッセージには、行番号・ファイル名・原因の手がかりが詰まっています。要約すると、その手がかりを自分で捨てていることになります。

これは初心者が最も損をしているポイントです。分からないものほど、そのまま渡す。

コツ5：前提と制約を先に伝える

AIはあなたの環境を知りません。

  • 使っている言語・フレームワーク
  • 動かす環境（ブラウザなのか、手元のPCなのか）
  • やってほしくないこと（「既存のファイルは消さないで」など）

特に3つ目が重要です。禁止事項を先に言っておくと、事故が激減します。

コツ6：出てきたものを「動かしてから」次を頼む

AIの出力を読んだだけで次に進むと、間違いが積み上がります。

  1. 出てきたものを動かす
  2. 期待どおりか自分の目で確認する
  3. 違っていたら、どう違ったかを伝える

3つ目の伝え方も大事です。「動かない」ではなく「ボタンを押しても何も起きない。エラーは出ていない」。観測した事実を伝えてください。

コツ7：うまくいったら、その指示を残す

効いた指示は資産です。メモに残しておくと、次から同じ品質を再現できます。

チームで使うなら、プロジェクトのルール（使う技術、命名規則、やってはいけないこと）を文書としてAIに読ませられる形で置いておくと、毎回説明する必要がなくなります。

悪い指示・良い指示 早見表

状況 悪い 良い
依頼の粒度 全部まとめて 1指示1目的
対象 「サイトが変」 「ヘッダーのこの部分が」
内容 実装方法を指定 望む結果を説明
エラー 要約する 全文そのまま
制約 言わない 禁止事項を先に
確認 読んで終わり 動かして確認

それでも詰まったときは

同じ指示を繰り返さないでください。言い方を変えても直らないときは、たいてい前提がずれています。

  • いったん会話を新しく始める
  • 「今の状態を説明して」と、AIに現状把握を言わせる
  • 作業をもっと小さく割る

それでも1〜2週間動けないなら、独学の限界かもしれません。判断基準は独学ロードマップに書きました。

まとめ

  • 1指示1目的。まとめて頼まない。
  • どこをを先に言う。どうなってほしいかを書く（実装方法ではなく）。
  • エラーは全文そのまま。要約は手がかりを捨てる行為。
  • 禁止事項を先に伝えると事故が減る。
  • 出力は動かして確認してから次へ。

次に読む