ツールを導入し、使い分けも分かった。次に効いてくるのは「AIにどう頼むか」です。同じClaude Codeでも、指示の出し方ひとつで成果物の質は何倍も変わります。この章では、AIとの二大スタイル――気軽に会話しながら作るバイブコーディングと、先に仕様を決めて正確に作らせる仕様駆動開発を軸に、「上手に頼む」技術を身につけます。ここが、AIコーディングの一番の勘どころです。

この章で身につくこと

合言葉は「小さく探索は vibe、大きく正確は spec」

2つのスタイルがわかる
バイブコーディングと仕様駆動開発の長所と落とし穴をつかめる。
場面で選べる
作るものの規模と目的で、どちらで頼むかを判断できる。
良い指示が書ける
具体化・文脈・出力例など、伝わるプロンプトの型が身につく。

指示の質が、成果を決める

AIコーディングで最初につまずくのは、たいてい「ツールの操作」ではなく「頼み方」です。AIは、あなたの頭の中を読めません。曖昧な一言を渡せば、AIは足りない部分を勝手に推測して埋め、それらしく動くけれど意図とずれたコードを返してきます。逆に、何を・なぜ・どう作ってほしいかを的確に伝えられれば、驚くほど正確に仕上げてくれる。「指示の質」がそのまま「成果の質」になる――これがこの章を貫く一番のメッセージです。そしてその頼み方には、大きく2つのスタイルがあります。

バイブコーディング ― 会話しながら作る

バイブコーディング(vibe coding)とは、細かい設計を前もって固めず、AIと会話しながら試行錯誤で作っていくスタイルです。「こんな感じのものが欲しい」とラフに伝え、出てきたものを見て「もう少しこう」「ここを直して」と対話を重ね、雰囲気(vibe)に任せて形にしていきます。手軽で探索的、アイデアを一気に形にできるのが最大の魅力です。

🎨 イメージ: 設計図を引かずに、粘土をこねながら形を探る感覚。「作りながら考える」ので、頭の中がまだ固まっていないアイデアでも、とりあえず手を動かして確かめられます。

向く場面と、気をつけたい落とし穴を並べてみましょう。

✅ 向く場面
  • 小さいもの:単発スクリプト、簡単なツール、1画面のアプリ。
  • 試作・プロトタイプ:形を見て判断したいとき。捨てる前提の実験。
  • 学習・素振り:新しい技術を触って感触をつかむとき。
⚠ 落とし穴
  • 全体設計がぶれる:会話ごとに方針が揺れ、一貫性が失われやすい。
  • 規模が増えると破綻:ファイルが増えるほどAIも人も全体を把握しきれなくなる。
  • 中身がブラックボックス化:動くけれど、なぜ動くか説明できないコードが積み上がる。

💡 ひとことで: バイブコーディングは「速く試す」には最強ですが、「大きく育てる・長く保守する」には向きません。小さく・使い捨て・探索――この3語を目安にすると、失敗しにくくなります。

仕様駆動開発 ― 先に決めて正確に作る

仕様駆動開発(spec-driven development)は、バイブコーディングと対照的なスタイルです。コードを書き始める前に、「何を・どう作るか」を仕様として文書にまとめ、その仕様をAIに渡して正確に実装させます。行き当たりばったりで会話するのではなく、合意した設計図に沿ってAIを走らせるやり方です。

やり方はシンプルです。まずAIと相談しながら仕様書を作り、それを(多くの場合ファイルとして)プロジェクトに置き、その仕様を参照させながら実装を進めます。

STEP 1
仕様を書く

目的・機能・入出力・制約を文章にする。AIに草案を作らせてから直すと速い。

STEP 2
合意する

実装前に仕様を自分で読み、抜けや矛盾を潰す。ここが品質の分かれ目。

STEP 3
仕様どおり作らせる

「この仕様に従って実装して」と指示。ずれたら仕様に立ち返って直す。

✅ 向く場面
  • 少し大きいもの:複数機能・複数ファイルにまたがる開発。
  • 品質重視:あとで壊れると困る、長く保守するもの。
  • チームや他人が読む:仕様が共有の拠りどころになる。
🧭 コツ
  • 最初から完璧を狙わず、仕様も小さく始めて育てる。
  • 仕様はあなたが必ず読む。AI任せの仕様は穴だらけになりがち。
  • 実装がずれたら会話で場当たり修正せず、仕様を直してからやり直す

📐 なぜ効くのか: AIは「今のこの会話」しか見ていません。仕様書といういつでも立ち返れる基準を先に置くことで、会話が長引いても方針がぶれず、実装の抜け漏れや手戻りが減ります。要は「AIに設計図を渡してから作らせる」だけのことですが、効果は絶大です。

使い分け ― 小さく探索か、大きく正確か

どちらが優れているという話ではありません。作るものの「規模」と「目的」で選ぶのが正解です。2つのスタイルを軸で対比してみましょう。

🎨 バイブコーディング
小さく・探索
規模小さい
目的試作・探索・学習
進め方会話で試行錯誤
速さとても速い
弱点大きくなると破綻
📐 仕様駆動開発
大きく・正確
規模中〜大きい
目的品質・保守・本番
進め方仕様→実装
速さ立ち上がりは遅い
弱点小物には重い

✅ 実際は「行き来」する。 二者択一で固定する必要はありません。まずバイブコーディングで素早く試作し、いける手応えがつかめたら仕様に起こして本実装へ移る――この流れが実務では最も強力です。小さな探索はvibe、育てる段階はspec。1つのプロジェクトの中でスタイルを切り替えていきましょう。

良い指示の5つのコツ

どちらのスタイルでも、AIに渡す指示(プロンプト)が良ければ成果は上がります。今日から使える基本のコツを5つ、カードで押さえましょう。深掘りはプロンプトエンジニアリング実践ガイドへ。

① 具体化する

「いい感じにして」ではなく、何をどうしてほしいかを具体的に。数値・条件・対象を明示するほど精度が上がる。

② 文脈を渡す

使っている言語・フレームワーク・関連ファイル・制約を伝える。背景を知るほどAIは的確になる。

③ 1タスクずつ

あれもこれも一度に頼まない。小さく区切って1つずつ頼めば、確認も修正も楽になる。

④ 期待する出力を示す

欲しい形(関数名・戻り値・出力例・フォーマット)を先に見せる。ゴールを共有すればずれにくい。

⑤ 直して反復する

一発で完璧を狙わない。出力を見て「ここをこう」と具体的に修正を重ねるほうが速い。

言葉だけでは掴みにくいので、同じ依頼を「悪い指示」と「良い指示」で並べてみます。

❌ 悪い指示

「ログイン機能を作って。」

言語も、保存先も、成功・失敗時の挙動も不明。AIは全部推測で埋め、あなたの想定と食い違ったコードを返す。手戻りの原因。

✅ 良い指示

「Laravelのプロジェクトに、メールとパスワードでのログイン機能を追加して。既存のusersテーブルを使う。認証成功で/dashboardへ、失敗ならエラーメッセージを表示。パスワードは既存のハッシュ方式に合わせて。まずroutesControllerだけ提案して、実装は私の確認後に。」

目的・文脈・成功条件・出力範囲・進め方まで明示。5つのコツが全部入っている。

🧩 一歩進んで: AIに「何を伝えるか」だけでなく、プロジェクト全体でどんな情報をどう届けるかを設計する考え方をコンテキストエンジニアリング、AIが働く環境(ツール・権限・指示ファイル)ごと整える考え方をハーネスエンジニアリングと呼びます。上達したくなったら覗いてみてください。

AIがルールを無視するとき

Claude Codeには、プロジェクトごとの指示をCLAUDE.mdのようなファイルにまとめ、AIに常に守らせる仕組みがあります。ところが実際に使うと、「書いたはずのルールをAIが無視する」場面に出くわします。原因はいくつかあります。

📄 指示が長すぎ・多すぎ

ルールが膨大だと重要なものが埋もれる。数を絞り、優先度を明確に

🌀 曖昧・矛盾している

解釈の幅があると守られない。具体的で検証可能な書き方にする。

🗂 会話が長くなった

やり取りが長引くと最初の指示が薄れる。要所で思い出させるのが有効。

💡 対策の要点: ルールは「短く・具体的に・優先度をつけて」書くこと。そして大事なルールは、必要な場面でもう一度会話の中で念押しする。原因の詳しい切り分けと具体的な直し方は、AIがCLAUDE.mdのルールを無視する理由と対策で解説しています。

この章のまとめ
  • 指示の質が成果の質。AIは足りない部分を推測で埋めるので、的確に頼めるほど正確に返る。
  • バイブコーディング=会話しながら試行錯誤。小さく・使い捨て・探索に強い。大きくすると破綻。
  • 仕様駆動開発=先に仕様を決めて正確に実装。中〜大きい・品質重視に強い。
  • 使い分けは「小さく探索は vibe、大きく正確は spec」。実際は行き来する。
  • 良い指示のコツは具体化・文脈・1タスクずつ・出力例・反復の5つ。
  • AIがルールを無視するのは指示が長い・曖昧・会話が長いから。短く具体的に、念押しを。

頼み方が分かれば、AIコーディングは一気に安定します。それでも実際に手を動かせば、必ずエラーや行き詰まりに出くわします。次の第5章「詰まりを抜ける」で、よくあるエラーの原因と抜け出し方を体系的に押さえましょう。