バイブコーディングの「3ヶ月の壁」を越える方法
あの高揚感が、3ヶ月で消える
「AIに話しかけるだけで、アプリが動く」。バイブコーディングを初めて体験したとき、多くの開発者がこの感覚に驚いたはずだ。
Andrej Karpathyが2025年2月にこの言葉を生み出してから、1年以上が経った。Collins English Dictionaryの「Word of the Year」にも選ばれ、MIT Technology Reviewの「2026年10大ブレークスルー技術」にも名を連ねた。もはやバズワードではなく、開発の選択肢として定着している。
ところが、バイブコーディングで作ったプロダクトには共通の症状がある。最初の3ヶ月は快適に進むのに、そこから急に手が止まる。
機能を追加しようとするとバグが連鎖する。直したはずの箇所が別の場所を壊す。チームメンバーが触ろうとすると「どこを変えていいのかわからない」と言う。GitClearの調査では、AI支援開発でコードの複製が48% 増加し、リファクタリングは60%減少したという数字が出ている。
この現象を、開発者たちは「3ヶ月の壁」と呼び始めている。
なぜ3ヶ月で壊れるのか
暗黙の仕様が積み上がる
バイブコーディングでは、AIとの対話が仕様書の代わりになる。「ログイン機能を作って」「バリデーションも追加して」。この指示の積み重ねでプロダクトは形になっていく。
問題は、これらの指示がどこにも残らないこと。
チャットログは残っているかもしれない。でも、50回のやりとりの末に辿り着いた設計判断の理由を、3ヶ月後に復元できる人はいない。結果として、コード自体が唯一の「仕様書」になる。そしてAI生成コードは人間が書いたコードよりも意図が読み取りにくい。
「動くからOK」の蓄積
バイブコーディングの快適さは「動くものがすぐ手に入る」ことにある。だが「動く」と「正しい」は別物だ。
AIが生成したコードには、表面的には動作するが設計としては問題があるパターンが混入しやすい。Veracode/Cloud Security Allianceの調査によると、AI生成コードの40〜60%にセキュリティ上の欠陥が含まれている。
初期はこれらが顕在化しない。プロダクトが小さいうちは、多少の設計の歪みは気にならない。しかし機能が増え、コードベースが膨らむにつれて、歪みが複利で効いてくる。
チームが合流できない
個人開発なら、3ヶ月の壁を超えても何とかなることがある。自分のバイブを自分が知っているからだ。
ところがチーム開発になると話は変わる。新しいメンバーが合流したとき、プロジェクトの「なぜそうなっているのか」を伝える手段がない。コードを読んでもAIとの対話の文脈はわからない。口頭で説明しても限界がある。属人化の極致だ。
仕様駆動開発（SDD）は「銀の弾丸」ではない
ここで「じゃあSDDにしよう」と短絡するのは危険だ。
仕様駆動開発は、コードを書く前に仕様を書き、その仕様に基づいてAIがコードを生成するアプローチ。仕様が「唯一の真実源泉（Single Source of Truth）」になるので、3ヶ月の壁の原因である「暗黙の仕様」「属人化」を構造的に防げる。
ただし、コストがかかる。
仕様を書くには時間が必要だ。しかも「AIが理解できるレベル」の仕様を 書くのは、従来の仕様書を書くのとは違うスキルが要る。探索的な開発フェーズ——何を作るかまだ決まっていない段階——では、仕様を書くこと自体が足かせになる。
大事なのは「どちらかを選ぶ」ではなく「いつ切り替えるか」を決めること。
実践的な使い分けガイド
フェーズ1: バイブコーディングで探索する（〜2週間）
最初の2週間はバイブコーディングで良い。むしろバイブコーディングの方が向いている。
この段階でやること：
- ユーザーに見せるプロトタイプを最速で作る
- 「こういうのが欲しかった」「いや、違う」のフィードバックを集める
- 技術的な実現可能性を検証する
このフェーズで仕様を書くのは時間の無駄だ。何を作るか自体が変わるのだから。
フェーズ2: 「これを作る」と決まったら仕様化する
プロトタイプを通じて方向性が固まったタイミングが切り替え時だ。具体的には：
- ユーザーの反応が「これでいい」から「もっとこうしたい」に変わったとき
- 2人目の開発者がプロジェクトに参加するとき
- 「来月リリースしたい」というスケジュールが設定されたとき
ここで立ち止まって、バイブコーディングで得た知見を仕様に落とし込む。プロトタイプのコードを捨てる必要はない。だが、仕様に書かれていない機能は本番に入れないというルールを設ける。
フェーズ3: SDDで本番品質に仕上げる
仕様が固まったら、SDDのサイクルに入る。
- 仕様を定義する（要件 → 設計 → タスク分解）
- AIが仕様に基づいてコード・テストを生成
- 仕様との整合性を検証
- 変更があれば仕様を更新してから再生成
このサイクルを回すことで、「なぜこのコードが存在するのか」が常に追跡可能になる。3ヶ月後でも、1年後でも。
Apple App Storeの事例が教えてくれること
2026年3月、AppleがApp Storeでバイブコーディング製アプリの審査を厳格化したことが話題になった。ReplitやVibecodeなどのツールで生成されたアプリに対し、修正なしではアップデートをリリースできない制限がかけられている。
この動きは示唆に富む。プラットフォーム側が「AIで作りました、中身はよくわかりません」では品質保証にならないと判断したということだ。
エンタープライズ開発でも同じことが起きている。KDDIをはじめとする大企業がSDDを採用し始めたのは、監査証跡——「なぜこのコードが生成されたのか」を仕様まで遡って説明できること——が必要だからだ。
バイブコーディングでプロトタイプを作り、SDDで本番に仕上げる。この使い分けが、今後の標準になっていくだろう。
「仕様を書く力」が開発者の新しい武器になる
Karpathy自身が2026年2月に「エージェンティック・エンジニアリング」という次の概念を提唱したのは象徴的だ。バイブコーディングの提唱者本人が、ノリだけでは限界があることを認めたわけだ。
では、エンジニアに求められるスキルはどう変わるのか。
コーディング能力の重要性は相対的に下がる。代わりに上がるのは：
- 仕様を書く力 — AIに正確に意図を伝え、検証可能な仕様を定義する能力
- 設計判断力 — AIが提示する複数の選択肢から、最適なアーキテクチャを選ぶ力
- 検証する力 — AIの出力が仕様を満たしているか、セキュリティ上の問題がないかを見抜く力
SIer・受託開発の文脈でいえば、「エンジニアの人数 × 月数」で売る時代 は終わりつつある。仕様策定力そのものが、提供価値の中核になる。
まず明日からできること
- 今のプロジェクトで「暗黙の仕様」を1つ文書化する — 「なぜこの認証フローにしたのか」「なぜこのDBスキーマにしたのか」。たった1つでいい
- プロトタイプと本番の境界線を決める — 「この機能はプロトだから仕様はない」「この機能は本番だから仕様が必要」を明示する
- SDDツールを1つ試してみる — GitHub Spec Kit、Kiro、cc-sddなど。チュートリアルを30分やるだけで感覚がつかめる
バイブコーディングを否定する必要はない。探索フェーズでは今でも最強のアプローチだ。でも、それだけで走り続けると3ヶ月後に壁にぶつかる。
壁にぶつかる前に、仕様を味方につけておこう。
---
*AI開発のパートナーをお探しなら、仕様駆動のアプローチで上流から伴走するAtsumellにご相談ください。*
