【図解】バイブコーディングの限界と、その先にある3つの手法 ― SDD・VSDD・CoDD
この記事を読んでほしい人：
Cursor や Claude Code を使って開発している人、「なんか AI が意図通りに動かなくなってきた」と感じている人、チームで AI 駆動開発を導入しようとしている人。
TL;DR
バイブコーディング → 小規模では最強。スケールすると崩壊する。
SDD → 「何を作るか」を AI に渡す。崩壊を防ぐ土台。
VSDD → 「意図通りに作られているか」を継続的に検証する。
CoDD → 整合性をシステム全体で構造的に保証する。
これは「AI 駆動 vs スペック駆動」の話ではない。レイヤーの話だ。
バイブコーディングは本当に破綻するのか
最初に正直に言う。
自分もバイブコーディングから始めた。Claude Code を開いて「こんなアプリ作って」と投げたら、数分で動くものができた。あの体験は本物だった。革命だと思った。
でも、しばらく経ってから気づいた。
「作ることはできる。でも、意図を維持することができない。」
これが AI 駆動開発（AIDD）の、誰も最初に教えてくれない限界だ。
バイブコーディングが崩壊するまでのリアルな流れ
これは AI の性能不足ではない。曖昧な指示で、文脈のないシステムを作り続けているからだ。
AIDD の3つの構造的問題
これら3つは全て、同じ根本原因から来ている。
「何を作るか」が明文化されていない
Spec-Driven Development（SDD）― AI のための設計
SDD は新しいアイデアではない。しかし AI 時代に入って、その意味が根本的に変わった。
従来の仕様書は「人間同士の共有のため」だった。AI 時代の Spec は違う。
AI に「曖昧さを渡さない」ためのもの
Vibe Coding vs SDD のフロー比較
SDD が求める「最小の4つ」
よく「結局ウォーターフォールでは？」という批判が出る。違う。
SDD が求めるのは巨大なドキュメントではない。AI が推測しなくて済む情報の最小セットだ。
github/spec-kit が 9.5万スター以上を獲得していること自体が、この方向性への開発者コミュニティの答えだ。
Verified Spec-Driven Development（VSDD）― 仕様があるだけでは不十分
SDD を導入しても、まだ問題は残る。
- AI が仕様を「微妙に解釈をズラして」実装する
- エッジケースを無視する
- 一部だけ正しく、全体では破綻する
- 後から追加した仕様が既存実装と矛盾する
「仕様があっても、実装がその仕様通りになっているかは別の話だ」
VSDD の検証ループ
TDD vs VSDD ― 似ているが視点が違う
TDD が「実装の正確性」を守るなら、VSDD は「意図の正確性」を守る
ハルシネーションが起きたとき、バグになるまで気づかないのが Vibe Coding だ。仕様との乖離を継続的に検出できるのが VSDD だ。
Coherence-Driven Development（CoDD）― 整合性を設計の中心に置く
CoDD が提唱するのは：
「システム全体の一貫性（Coherence）」を、設計の第一原則にする
SDD が「何を作るか」を明確にするなら、CoDD は「上流の意思決定が、下流の実装に一貫して伝播する構造」を作る。
CoDD のウェーブ設計
核心は constrained_by という依存関係の明示だ。上流が変われば下流も更新される。整合性が構造として保証される。
3つの手法の全体像
これらは競合しない。土台から積み上がるレイヤー構造だ。
| 手法 | 何を解決するか | キーワード | いつ必要になるか |
|---|---|---|---|
| Vibe Coding | アイデアの高速検証 | スピード | プロジェクト開始時 |
| SDD | AI への曖昧な指示 | 仕様の明文化 | MVP を超えた瞬間 |
| VSDD | AI 出力と意図のズレ | 検証ループ | チーム開発・本番運用 |
| CoDD | システム全体の整合性崩壊 | コヒーレンス | 長期・大規模プロジェクト |
「AI 駆動 vs スペック駆動」は間違った対立軸だ
よく「SDD は AI のスピードを殺す」と言われる。本当にそうか。
上：Vibe Coding のコスト推移 下：SDD のコスト推移（概念図）
バイブコーディングで10回修正を繰り返すコストと、最初に30分かけて仕様を書くコストを比べたとき、どちらが速いか。
答えは明らかだ。
AI はコードを書く速度では人間を超えた。しかし「意図を定義する」ことは、まだ人間の仕事だ。
AI 時代に人間が担う役割の変化
SDD・VSDD・CoDD が示しているのは、この方向性への具体的な答えだ。
あなたはどう思うか
今の自分の解釈をまとめると：
- Vibe Coding は「入口」として正しい。 否定しない。でもゴールではない。
- SDD はスケールのための土台。 4つの最小セットを定義するだけでいい。
- VSDD は「意図の正確性」を守る仕組み。 TDD と組み合わせると強力。
- CoDD は AI エージェント時代のための設計思想。 長期・大規模になるほど効く。
ただ、これはあくまで自分の現時点の解釈だ。
みなさんに聞いてみたいことがある：
- バイブコーディングから SDD に移行した人は、どのタイミングで「限界」を感じたか？ セッション数？プロジェクト規模？
- VSDD の「検証ループ」を実際に運用している人はいるか？ どう実装しているか？
- 「SDD はウォーターフォール回帰だ」という批判に対して、あなたはどう答えるか？
コメント・反論・事例、全部歓迎します。