AIにいきなりコードを書かせるのは、設計図なしで大工を現場に送り込むようなものだ。動くものはできるかもしれない。でも後からやり直すコストが、最初に計画する手間をはるかに上回る。
「とりあえず作って」の代償
バイブコーディングを始めたばかりの人がやりがちなのが、思いついたことをそのままAIに投げることだ。
「ToDoアプリを作って」「ログイン機能をつけて」「かっこいいダッシュボードにして」。
AIはすぐにコードを出してくれる。それが問題だ。
目的地を告げずにタクシーを走らせるようなもので、「なんとなく東の方向に」と言えば走り出す。でも5分後に「やっぱり西だった」となったとき、すでに高速に乗っている。引き返すコストは、最初から正しい方向に向かうより何倍も高くつく。
AIコーディングでも同じことが起きる。途中で「やっぱりデータベース設計を変えたい」「認証方式が違った」となると、すでに生成されたコードとの格闘が始まる。
データが示す「計画なし」のリスク
これは感覚の話ではない。
METR（Machine Learning エバリュエーションと測定研究所）が2025年に行った研究は、経験豊富なオープンソース開発者16名を対象に、AIを使った場合と使わない場合の作業時間を計測した。結果は意外だった。AI使用時のほうが19%遅かった。
しかも、開発者たち自身は「24%速くなると期待していた」と答えていた。実際には遅くなっていたにもかかわらず、終了後のアンケートでも「約20%速くなった」と思い込んでいた。
なぜAIを使うと遅くなるのか。研究から見えてくる原因のひとつは、AIが生成したコードのレビューと修正に多くの時間が取られることだ。コードは動く。でもテストカバレッジが不足していたり、コードスタイルが統一されていなかったり、プロジェクト全体の設計と噛み合っていなかったりする。
計画なしで生成を繰り返すと、こういうコードが積み重なる。
この研究はエンジニアが対象だが、非エンジニアのバイブコーダーにとっても示唆は同じだ。「何を作るか」を明確にせずAIに投げると、出てきたものを評価する基準すら持てない。
Plan Modeとは何か
Cursorにも、Claude Codeにも、「Plan Mode（計画モード）」と呼ばれる機能がある。これは、AIがコードを書く前に計画だけを作るモードだ。
通常のモードでは、指示を出すとAIはすぐにファイルを作り始める。Plan Modeでは、AIはファイルを読み、構造を調べ、質問をし、計画書を作る——でも何も変更しない。
建築で言えば、大工が現場に来る前に設計士が図面を引くフェーズだ。
CursorのPlan Mode
Cursorでは、Shift + Tabでモードが切り替わる。Plan Modeを選ぶと、AIは以下のことをやってくれる：
- コードベース全体を読んで構造を把握する
- 実装上の懸念点や確認事項を質問してくる
- 変更が必要なファイルと手順をMarkdownで整理する
- 「Build」ボタンを押すまで何も変更しない
計画を保存するオプションを選ぶと .cursor/plans/ フォルダにMarkdownファイルとして保存され、Gitで管理してチームと共有することもできる。
Claude CodeのPlan Mode
Claude Codeでは、/planコマンドを入力するか、Shift + Tabを2回押してPlan Modeに入る。VSCodeの場合はプロンプトボックス下部のモード表示をクリックして切り替えられる。
Plan Mode中、Claude Codeはファイルの読み取り・検索・分析はできるが、ファイルの作成・編集・削除はできない。読むだけのフェーズを明示的に分けることで、「考えながら書く」ではなく「考えてから書く」を強制する。
プロンプトの設計が結果を決める
Plan Modeを使っても、最初のプロンプトが曖昧なままでは効果が半減する。
AIへの指示は「どんなものを作るか」だけでなく、「何を使って」「どんな制約の中で」「どんな手順で」を含む必要がある。
❌ 悪い例：情報が少なすぎる
ToDoアプリを作って。ユーザーがタスクを追加・削除できるようにして。
この指示でAIが作るのは、何でもありの実装だ。どのフレームワーク、どのデータベース、どの認証方式を使うか、すべてAIが勝手に決める。後から「それじゃない」となっても、すでにコードが積み上がっている。
✅ 良い例：文脈と制約を先に渡す
Next.js（App Router）とSupabaseを使い、以下の仕様でToDoアプリのPlanを作成して。
まず必要なファイル構造と、DB設計（テーブル名・カラム・型）を提示してほしい。
コードはまだ書かなくていい。
仕様：
- ユーザーはメールアドレスとパスワードで登録・ログインできる
- ログイン後、自分のToDoだけが見える（他人のは見えない）
- タスクにはタイトル・期限・完了フラグがある
- Supabase Row Level Securityを有効にする
この指示なら、AIは計画を立てる前に「どのテーブル設計にするか」「RLSのポリシーをどう書くか」「認証フローをどう組むか」を考える。それを先に見せてもらえるので、実装前に方向を修正できる。
Plan Modeを使いこなすコツ
1. コードよりも先に「設計」を要求する
「〇〇を実装して」という指示の前に、「まず設計だけ教えて。コードはまだ書かなくていい」と付け加えるだけで、AIの出力が変わる。
Plan Modeに入っていなくても使えるテクニックだ。AIは指示通りに動く。計画を先に出させるよう指示すれば、計画を出す。
2. AIの質問に正直に答える
Plan Modeで優秀なAIは、曖昧なところを質問してくる。「認証はどの方式ですか？」「データは後から編集できる必要がありますか？」
これを「面倒」と感じて「なんでもいいです」と答えてしまうと、AIが最悪のタイミングで最悪の選択をする。質問に答えるのは数十秒だ。後から書き直す時間のほうがずっと長い。
3. 計画を一度レビューしてから実行する
Plan Modeが出した計画を、鵜呑みにしないこと。「このファイルを作ります」「このAPIを叩きます」という計画が出たとき、知識がなくてもできる確認がある。
「変更するファイルが多すぎないか」「何かが抜けていないか（たとえば認証の話があるのにセッション管理への言及がないなど）」。大工の図面に窓の書き忘れがないかを確認するのに、専門知識は要らない。
「計画が長くて読む気がしない」と感じたときこそ注意が必要だ。そういう計画は大抵、AIが複数の問題を一度に解こうとしている。「まず最初のステップだけ教えて」と絞り込もう。
実践：段階的に進める
Plan Modeの最大のメリットは「一度に全部やらない」ことを自然にできる点だ。
たとえば「認証付きToDoアプリ」を作る場合、以下のようにフェーズを分けて計画を立てると、各段階で方向修正がしやすい。
フェーズ1: DB設計とSupabase設定のPlanだけ出して
→ レビュー → OKなら実行
フェーズ2: 認証フローのPlanを出して（DB設計を前提に）
→ レビュー → OKなら実行
フェーズ3: ToDo CRUDのPlanを出して（認証実装を前提に）
→ レビュー → OKなら実行
各フェーズを独立して計画・実行することで、「途中で根本から変える」という最も高コストな状況を避けられる。
なぜ計画が「面倒」に感じるのか
正直に言う。計画を立てるのは面倒だ。AIにすぐコードを出させたほうが「進んでいる感」がある。
でもその「進んでいる感」が罠だ。
動かないコードを前に、どこが間違っているかわからずAIに「修正して」を繰り返す時間は、計画を立てる時間の何倍にもなる。計画を立てることは「遠回り」ではない。むしろそれが最短ルートだ。
METR研究が示した「AIを使うと19%遅くなる」という結果も、計画なしに使い始めるとこうなると考えれば腑に落ちる。計画があればこの数字は変わるはずだ。
まず一回やってみる
次にAIに何か作ってもらうとき、最初のプロンプトに「まず計画だけ教えて。コードはまだ書かなくていい」と付け加えてみてほしい。
Cursor使いなら Shift + Tab でPlan Modeに切り替えてから投げる。Claude Code使いなら /plan と入力してから始める。
計画が出てきたら、5分だけ読む。おかしいところがあれば指摘する。問題なければ実行する。
それだけでいい。「完璧な計画」を目指す必要はない。「全部AIに任せる前に一度確認する」習慣をつけることが、バイブコーディングの次のステップだ。
