バイブコーディングがうまくいかないとき、原因の大半はツールではなく指示にあります。
同じツール・同じ課題でも、指示の出し方で結果はまるで変わります。この記事では、現役エンジニアとして実務で使っているAIが誤解しない伝え方を7つに絞って書きます。
この記事の前提
- 対象：AIツールを使ってコードを書き始めたばかりの方、指示の出し方に自信がない方
- 前提知識：特定のツール（Claude Code、Cursorなど）の操作方法は前提にしていません。チャット形式でAIに指示を出し、コードやアプリの一部を作ってもらう場面全般に共通する「伝え方」を扱います
用語のかんたん解説
| 用語 | 意味 |
|---|---|
| プロンプト | AIに送る指示文のこと。この記事でいう「指示」と同じ意味です |
| MCP | AIツールが外部のサービス（GitHubなど）と連携するための仕組みの総称 |
| ハンバーガーメニュー | 画面が狭いときに、メニュー項目を三本線のアイコンにまとめて隠す表示方法 |
コツ1：1指示1目的に区切る
最も効きます。
悪い例
ログイン機能を作って、あとデザインも整えて、テストも書いておいて
良い例
ログイン機能を作って。まずは入力欄と送信ボタンを実装してください。
まとめて頼むと、AIは優先順位を自分で決めます。その判断があなたの意図とずれると、全部が微妙にずれます。小さく区切って、確認しながら積むのが最短です。
コツ2：「どこを」を先に言う
AIは、対象が曖昧だとプロジェクト全体を探しにいきます。時間もかかり、費用も増えます。
悪い例
レイアウトが崩れてる。直して
良い例
ヘッダーのナビゲーションが、スマホ幅で改行されて2段になっている。直してください。
ファイル名が分かるなら、それも添えてください。場所が特定できた瞬間、精度が跳ね上がります。
コツ3：「どうなってほしいか」を書く（「どう直すか」ではなく）
実装方法まで指定すると、AIの得意分野を潰してしまいます。
惜しい例
flex-wrap: nowrapを付けて
良い例
スマホ幅でもナビゲーションを1行に収めたい。入りきらないならハンバーガーメニューにしてほしい
What（どうなってほしいか）はあなたの仕事、How（どう実現するか）はAIの仕事。この分担を崩さないでください。技術に詳しくない人ほど、この形が有利に働きます。
コツ4：エラーは全文そのまま貼る
要約しないでください。
悪い例
なんかエラーが出た
良い例
こういうエラーが出た（以下、ターミナルの出力を全文貼る）
エラーメッセージには、行番号・ファイル名・原因の手がかりが詰まっています。要約すると、その手がかりを自分で捨てていることになります。
これは初心者が最も損をしているポイントです。分からないものほど、そのまま渡す。
コツ5：前提と制約を先に伝える
AIはあなたの環境を知りません。
- 使っている言語・フレームワーク
- 動かす環境（ブラウザなのか、手元のPCなのか）
- やってほしくないこと（「既存のファイルは消さないで」など）
特に3つ目が重要です。禁止事項を先に言っておくと、事故が激減します。
Githubでプロジェクト管理しておいて、mcpか何かで指示出してるAIにと連携しておけばよっぽど事故起きませんけどね。
コツ6：出てきたものを「動かしてから」次を頼む
AIの出力を読んだだけで次に進むと、間違いが積み上がります。
- 出てきたものを動かす
- 期待どおりか自分の目で確認する
- 違っていたら、どう違ったかを伝える
3つ目の伝え方も大事です。「動かない」ではなく「ボタンを押しても何も起きない。エラーは出ていない」。自分の目で見た事実を伝えてください。
コツ7：うまくいったら、その指示を残す
効いた指示は資産です。メモに残しておくと、次から同じ品質を再現できます。
チームで使うなら、プロジェクトのルール（使う技術、命名規則、やってはいけないこと）を文書としてAIに読ませられる形で置いておくと、毎回説明する必要がなくなります。
悪い指示・良い指示 早見表
| 状況 | 悪い | 良い |
|---|---|---|
| 依頼の粒度 | 全部まとめて | 1指示1目的 |
| 対象 | 「サイトが変」 | 「ヘッダーのこの部分が」 |
| 内容 | 実装方法を指定 | 望む結果を説明 |
| エラー | 要約する | 全文そのまま |
| 制約 | 言わない | 禁止事項を先に |
| 確認 | 読んで終わり | 動かして確認 |
指示でつまずいたときの原因パターン
うまく伝えたつもりでも、結果がずれることがあります。よくあるパターンと、確認する順番をまとめます。
| 起きること | 考えられる原因 | 確認する順番 |
|---|---|---|
| 頼んでいない箇所まで変更される | 対象範囲（「どこを」）を指定していない | まずファイル名・画面の場所を指定し直す（コツ2） |
| 同じ指示を繰り返しても直らない | AIが持っている前提と、あなたの前提がずれている | 「今の状態をどう理解しているか」をAIに説明させる |
| 修正のたびに別の場所が壊れる | 一度に複数の目的を頼んでいる | 依頼を1つの目的まで小さく割り直す（コツ1） |
| エラーは消えたが動作がおかしい | エラーメッセージだけを見て、実際の挙動を確認していない | コツ6に戻り、動かして自分の目で確認する |
初心者がやりがちで、あとで困る指示
- 「さっきの続きで」とだけ伝える：会話が長くなるほど、AIも前提を見失います。区切りが悪いと感じたら、状況を一度言葉でまとめ直してから頼んでください
- 動作確認をせずに次の指示を重ねる：コツ6のとおり、確認前に次を頼むと、原因の切り分けができなくなります
- 「いい感じにして」で終わらせる：曖昧な言葉はAIにとっても解釈の余地が大きすぎます。良い例のように、状態や条件を具体的に書いてください
- 禁止事項を後出しする：「それは消さないでほしかった」は事後に伝えても手遅れです。コツ5のとおり、最初に伝えてください
それでも詰まったときは
同じ指示を繰り返さないでください。言い方を変えても直らないときは、たいてい前提がずれています。
- いったん会話を新しく始める
- 「今の状態を説明して」と、AIに現状把握を言わせる
- 作業をもっと小さく割る
それでも1〜2週間動けないなら、独学の限界かもしれません。判断基準は独学ロードマップに書きました。
まとめ
- 1指示1目的。まとめて頼まない。
- どこをを先に言う。どうなってほしいかを書く（実装方法ではなく）。
- エラーは全文そのまま。要約は手がかりを捨てる行為。
- 禁止事項を先に伝えると事故が減る。
- 出力は動かして確認してから次へ。
よくある質問（指示の書き方）
Q. 指示は日本語と英語、どちらがいいですか？ A. 使っているAIツールが日本語に対応していれば、日本語で問題ありません。曖昧な言い回しを避け、コツ2・コツ3のように対象と望む結果を具体的に書くことのほうが、言語の選択より結果に影響します。
Q. 指示が長くなりすぎるのですが、まとめたほうがいいですか？ A. 長さそのものより、1回の指示に目的が複数含まれていないかを確認してください。コツ1のとおり、目的が1つに絞れていれば、多少長くても問題になりにくいです。
Q. 何度言っても同じ間違いを繰り返す場合は？ A. 「それでも詰まったときは」で触れたとおり、同じ言い方を繰り返しても直りません。会話を仕切り直し、AIに現状の理解を説明させてから、作業をさらに小さく割ってください。
Q. 指示を打つのが遅くて、コツを実践する余裕がありません A. 音声入力で指示を出す方法もあります。AI音声入力Typelessの実測レビューで、打鍵の手間を減らす選択肢を紹介しています。
Q. ツールによって、指示の伝え方は変えるべきですか？ A. 基本的な7つのコツはツールに依存しません。ただしツールごとに得意・不得意があるため、選び方自体に迷う場合はAIコーディングツール比較を参照してください。
次に読む
- 指示を打つのが遅いと感じるなら → AI音声入力Typelessを実測レビュー
- よくある失敗と回避法 → 初心者がやりがちな失敗7つ
- 何が作れるのか → バイブコーディングで作れるもの10例
- 3ヶ月の学習設計 → 独学ロードマップ