バイブコーディングの落とし穴と、仕様駆動開発が注目される理由
3ヶ月で壁にぶつかる
バイブコーディングでプロジェクトを始めると、最初の1〜2ヶ月は驚くほど速い。Augment Codeの調査によると、定義済みタスクの完了速度は平均55%向上する。チャットで指示を出すだけで、画面が形になっていく。
問題は、その先だ。
多くのプロジェクトが3ヶ月目あたりで壁にぶつかる。コードベースがAIのコンテキストウィンドウに収まらなくなる。ファイルAを直したらファイルBが壊れる。でも、なぜ壊れたのかを説明できる人間がいない。仕様書もない。あるのはSlackに散らばったプロンプトの残骸だけだ。
GitClearが2億1,100万行のコードを分析した結果がこれを裏づけて いる。AI導入後、リファクタリングは60%減少し、コピペは48%増加した。「動くからヨシ」の繰り返しが、静かに負債を積み上げていたわけだ。
セキュリティは「動く」の裏側にある
もう一つ、見過ごせない問題がある。セキュリティだ。
AI生成コードの脆弱性混入率は最大62%に達するという調査がある。「動く」と「安全」はまったく別の話なのだが、バイブコーディングのフローでは両者が区別されない。プロンプトを投げて、動いたらOK。セキュリティレビューが入る余地がない。
特に厄介なのが「パッケージ・ハルシネーション」だ。AIが存在しないライブラリをimportする。悪意ある第三者がその名前でパッケージを公開する。知らないうちにサプライチェーン攻撃が成立する。2026年に入ってから、このパターンの報告が急増している。
Appleが拒否し始めた
2026年3月、興味深いニュースが飛び込んできた。Appleがバイブコーディング製アプリのApp Store審査を厳格化しているという報道だ。
ReplitやVibecodeなどのツールで生成されたアプリが、審査後にAIで根本的に作り変えられてしまう。Appleのポリシーは「審査後のアプリの本質的な変更」を禁止しているが、バイブコーディングはまさにそれを可能にしてしまう。
プラットフォーム側がリスクとして認識し始めたのは、技術コミュニティだけの問題ではなくなった証拠だろう。
「野良アプリ」という時限爆弾
企業の情シス担当者にとって、もっと身近な問題もある。
非エンジニアの社員がバイブコーディングで業務ツールを「自作」し始めると、情シスの管理外で保守不能なアプリが増殖する。いわゆるシャドーITの新しい形だ。
作った本人は異動する。引き継ぎドキュメントはない。でもそのツールに依存した業務フローだけが残る。ある日突然動かなくなって、誰も直せない。このシナリオは、すでに多くの企業で現実になりつつある。
じゃあ、どうすればいいのか
ここで出てくるのが仕様駆動開発（SDD: Specification Driven Development）だ。
SDDのアイデアはシンプルで、コードを書く前に仕様を書く。変更したくなったら、コードではなく仕様を直す。コードは仕様から生成される「副産物」という位置づけになる。
バイブコーディングが「プロンプト → コード → 動作確認」のサイクルなのに対し、SDDは「仕様 → コード生成 → 仕様との整合性検証」のサ イクルだ。
この違いが何を生むか。レビューの基準ができる。仕様というベースラインがあるから、「AIが出したコードが正しいかどうか」を判定できる。バイブコーディングには、この基準がない。
2026年のツール状況
SDDが単なる理想論ではなく現実的な選択肢になった背景には、ツールの成熟がある。
AWS KiroはVS Code拡張として、要件・設計・タスクの3段階のドキュメントを自動生成する。バイブコーディングとSDD、両方のモードを切り替えられる設計が面白い。
GitHub Spec KitはオープンソースのCLIで、Copilot・Claude Code・Gemini CLIと連携する。既存のワークフローに組み込みやすい。
Karpathy本人も方向転換したのが象徴的だ。2026年2月、バイブコーディングの提唱者自身が「エージェンティック・エンジニアリング」という新しい概念を提案した。複数のAIエージェントを計画者・実装者・検証者として統制する開発スタイルで、「ノリ」から「仕組み」への進化と言っていい。
バイブコーディングは「捨てるべき」なのか
ここまでリスクを並べたが、バイブコーディングを全否定するつもりはない。
プロトタイピングには最強だ。アイデアを30分で形にして、ユーザーに見せてフィードバックをもらう。この用途では、仕様を書いている暇はないし、書く必要もない。
問題は、プロトタイプがそのまま本番に化けるときだ。「動いてるし、このままいこう」が、3ヶ月後の技術的負債の山を作る。
実務で機能するアプローチは、ハイブリッドだ。
- 探索フェーズ — バイブコーディングでアイデアを素早く検証する
- 移行トリガー — 以下のサインが出たらSDDに切り替える
- 修正が別の場所を壊し始めた（コンテキストドリフト）
- チームメンバーが増えた
- 本番環境にデプロイする判断をした
- 本番フェーズ — 仕様をバージョン管理し、コード生成と検証のサイクルを回す
SIer・受託開発への影響
この流れは、SIerや受託開発にも大きな影響を与える。
クライアントが「バイブコーディングで作ったんですけど、セキュリティ大丈夫ですかね？」と相談してくるケースが増 えている。コードは動くが、仕様がない。テストもない。誰が何を意図してこう書いたのか、AIのチャットログを遡らないとわからない。
こうした案件を引き受けるにせよ断るにせよ、仕様を起点に開発を組み立てる力が、これまで以上に問われる時代になった。
「人月を売る」時代から「仕様策定力を売る」時代へ。この転換の速度は、思ったより速い。
まずやること
バイブコーディングを使っているなら、今日からできることが一つある。
プロンプトを投げる前に、3行だけ仕様を書く。
- この機能は何をするのか（What）
- なぜ必要なのか（Why）
- 正常系と異常系は何か（How）
たった3行。これだけで、AIの出力品質は明らかに変わる。そして、その3行は後からレビューの基準にもなる。
完璧な仕様書は要らない。「ノリ」に3行の構造を足すだけで、開発の持続可能性はまったく違うものになる。
---
*AI開発のパートナーをお探しなら、仕様駆動の アプローチで上流から伴走するAtsumellにご相談ください。*
