はじめに
「Vibe Coding」と「Spec Driven Development（SDD）」——AI時代の開発手法として、これらの言葉を耳にする機会が増えました。
SNSやブログでは、これらがしばしば異なるアプローチとして語られ、「どれを選ぶべきか」という議論になりがちです。
- 「Vibe Codingは自由だが品質が不安」
- 「SDDは堅牢だが柔軟性に欠ける」
- 「結局どれを使えばいいのか？」
しかし、本当にこれらは「どれか一つを選ぶ」ものでしょうか？
本記事では、SDDを単なる「仕様を先に書く開発手法」として捉えるのではなく、SDDが前提としている開発思想そのものに立ち返ります。そして、フェーズ × 固定度 × AI裁量 × Spec濃度という統合的な視点から、AI時代の開発プロセス全体を整理してみます。
3分でわかるこの記事のポイント
結論：Vibe CodingもSDDも「二者択一」ではなく「同じ開発プロセスの異なるフェーズ」
開発フェーズとSpec濃度の関係
| フェーズ | やること | Spec濃度 | AI裁量 |
|---|---|---|---|
| 0: アイデア探索 | 発散・実験 | L0（なし） | 最大 |
| 1: 試作・理解深化 | 仮説検証 | L1（低） | 大 |
| 2: 確信形成 | 部分固定 | L2（中） | 中 |
| 3: 実装拡張 | 本格開発 | L3（高） | 低 |
| 4: 運用・保守 | 維持管理 | L3（維持） | 最小 |
重要な考え方
早すぎる固定 → 探索の余地を奪う → 最適解を逃す
遅すぎる固定 → 一貫性を失う → 収拾がつかなくなる
∴ 確信が持てたものから段階的に固定する
各手法の位置づけ
- Vibe Coding → フェーズ0〜1の技法（探索最大化）
- SDD → フェーズ2〜4の枠組み（確信を固定・活用）
これらは排他的ではなく、開発の時間軸上で連続している。
なぜこの議論が必要なのか
AI開発ツールの急速な進化により、開発のあり方そのものが変わりつつあります。
従来の開発
要件定義 → 設計 → 実装 → テスト → 運用
↑
仕様書が最初から必要
AI時代の開発
アイデア → 即座にプロトタイプ → 動かして確認 → 改善 → ...
↑
AIが数分で実装
この変化により、「仕様書をいつ・どのように書くべきか」 という根本的な問いが生まれました。
一方では「AIに任せて自由に作らせればいい」という声があり、他方では「仕様がなければ品質は保てない」という声があります。
どちらも一理あるのですが、それぞれが当てはまる場面が異なるのではないでしょうか。
SDDが前提としている開発思想
初期の仕様は「仮説」に過ぎない
ソフトウェア開発において、初期段階の仕様はあくまで仮説です。
実際に作って動かしてみなければ分からないことが多く、探索が十分でない段階から仕様に強い拘束力を与えると、次のような問題が起こります。
では仕様は不要なのか？
いいえ。仕様なしで進めると、別の問題が発生します。
SDDの解答：段階的固定
SDDは、この矛盾を「段階的固定」というアプローチで解決します。
実装 → 試行錯誤 → 確信形成 → 仕様作成
↑ ↑
ここでは固定しない ここで固定する
つまり、
- 探索と検証を通じて成熟した知見だけを
- **「その時点での真実」**として明文化し
- AIによる実装生成や判断の拠り所として活用する
これにより、仕様を固定し過ぎずに、開発スピードと一貫性を両立させることができます。
「Spec濃度」という概念
ここで重要なのは、**仕様書の量や形式ではなく「濃度」**という考え方です。
Spec濃度とは
| 濃度 | 意味 | 例 |
|---|---|---|
| L0 | Specを持たない | メモ、雑談、アイデアスケッチ |
| L1 | 低濃度Spec | 仮説、前提、失敗例の記録（変わる前提） |
| L2 | 中濃度Spec | 不変条件、判断基準、制約の明文化 |
| L3 | 高濃度Spec | 契約レベル、意図・理由・例外を含む |
Spec濃度とは、
- どこまで判断を先送りせずに固定しているか
- どこまで責任を持って「変えない」と言えるか
を表す指標です。
濃度と解像度の関係
解像度に応じてSpec濃度を調整する ——これがSDDの基本原則です。
フェーズ × 固定度 × AI裁量 × Spec濃度 統合表
開発プロセス全体を、5つのフェーズで整理してみましょう。
アイデア萌芽から運用保守まで、5つのフェーズを経て開発は進化する
統合表
| フェーズ | Spec濃度 | 作る側の解像度 | 固定度 | AI裁量 | Specの扱い |
|---|---|---|---|---|---|
| 0: アイデア萌芽・問題探索 | L0 | 低い（問題定義自体が揺れている） | ほぼゼロ | 最大 | Specは持たない |
| 1: 試作・理解深化 | L1 | 中（何がダメかが分かり始める） | 低い | 大 | 低濃度Spec（変わる前提） |
| 2: 確信形成・部分固定 | L2 | 中〜高（なぜそうか説明できる） | 中 | 中 | 中濃度Spec（不変条件） |
| 3: 実装拡張・チーム化 | L3 | 高い（説明・引き継ぎが可能） | 高 | 低 | 高濃度Spec（契約レベル） |
| 4: 運用・保守 | L3維持 | 非常に高い | 最大 | 最小 | 維持・更新（変更は例外） |
フェーズの可視化
各フェーズの詳細解説
フェーズ0：アイデア萌芽・問題探索（Spec濃度 L0）
状態
- 作る側の解像度：低い（問題定義自体が揺れている）
- 固定度：ほぼゼロ（固定してよいものが存在しない）
- AI裁量：最大（発散・連想・大胆な提案を全面的に受け入れる）
Specの扱い
- Specは持たない（メモがあっても成果物ではない）
主な手法
- Vibe Coding
- ラフプロトタイピング
- スパイク実装
人間の役割
- 判断しない
- 違和感・面白さ・方向性だけを見る
具体例：タスク管理アプリを作ろうとしている場合
人間: 「タスク管理アプリ作りたい」
AI: 「こんな感じでどうですか？」
→ シンプルなTodoリスト
→ カンバンボード
→ ガントチャート形式
→ 音声入力対応
→ AIアシスタント付き
人間: 「お、カンバン面白そう」（方向性だけ判断）
この段階では「正しい仕様」を考えることに意味がありません。何が面白いか、何に違和感があるかだけを感じ取ります。
フェーズ1：試作・理解深化（Spec濃度 L1）
状態
- 作る側の解像度：中（何がダメかが分かり始める）
- 固定度：低い（前提はすべて暫定）
- AI裁量：大（制約付き発散）
Specの扱い
- 低濃度Spec（仮説・前提・失敗例を記録）
- 変わる前提で書く
主な手法
- 実装主導の探索
- PoC（Proof of Concept）
- プロトタイピング
人間の役割
- 仮説を壊す
- 前提の更新
- 違和感の言語化
具体例：カンバンアプリの試作
# 現時点での前提（L1 Spec）
## 仮説
- ドラッグ&ドロップでカード移動できると便利そう
- カラムは3つ（Todo, Doing, Done）で十分？
## 試してみて分かったこと
- ❌ カラム3つでは足りない → ユーザーが追加できる必要あり
- ❌ ドラッグ&ドロップはモバイルで使いにくい
- ✅ カードの色分けは直感的に分かりやすい
## 次に試すこと
- カラム追加機能
- モバイル向けの別UI（タップで移動）
この段階のSpecは**「変わることを前提とした記録」**です。拘束力はなく、学びを蓄積するためのものです。
フェーズ2：確信形成・部分固定（Spec濃度 L2）
状態
- 作る側の解像度：中〜高（なぜそうか説明できる）
- 固定度：中（固定範囲と可変範囲が明確）
- AI裁量：中（Spec内は自由、Spec外は提案のみ）
Specの扱い
- 中濃度Spec（不変条件・判断基準・制約を明文化）
主な手法
- Spec Driven Development（入口）
- 部分Spec化
- 設計レビュー
人間の役割
- 何を固定するかの判断
- 固定に責任を持つ
具体例：確信が持てた部分を固定
# カンバンアプリ Spec v0.1（L2）
## 固定事項（これは変えない）
### データモデル
- カードは必ず1つのカラムに属する
- カラムの順序は保持される
- カードIDはUUID v4
### 不変条件
- カードを削除してもカラムは残る
- カラムを削除するとその中のカードも削除される
## 可変事項（まだ探索中）
- UIの詳細デザイン
- 通知機能の有無
- 複数ボード対応
ここで初めて**「これはもう変えない」**と言える要素が生まれます。これがSDDの実質的な開始点です。
フェーズ3：実装拡張・チーム化（Spec濃度 L3）
状態
- 作る側の解像度：高い（説明・引き継ぎが可能）
- 固定度：高（仕様は契約として扱う）
- AI裁量：低（Spec逸脱は警告・提案止まり）
Specの扱い
- 高濃度Spec（契約レベル、意図・理由・例外を含む）
主な手法
- 本格SDD
- チーム開発
- CI・レビュー前提
人間の役割
- 変更承認
- 例外判断
- 品質と責任の担保
具体例：契約レベルのSpec
# カンバンアプリ Spec v1.0（L3）
## カード移動 API
### エンドポイント
POST /api/cards/{cardId}/move
### リクエスト
```json
{
"targetColumnId": "uuid",
"position": 0 // 0-indexed
}
振る舞い
- cardIdが存在しない場合 → 404 Not Found
- targetColumnIdが存在しない場合 → 400 Bad Request
- positionが範囲外の場合 → 末尾に配置（エラーにしない）
理由
- positionエラーにしない理由：並行編集時のUXを優先
- 末尾配置を選んだ理由：先頭配置よりも自然な挙動
例外
- カードがアーカイブ済みの場合は移動不可（400）
このレベルでは、**意図・理由・例外まで含めて**明文化されます。AIはこのSpecに従って実装を補助し、人間は変更判断と責任を担います。
---
### フェーズ4：運用・保守（Spec濃度 L3を維持）
**状態**
- 作る側の解像度：非常に高い（前提を深く理解）
- 固定度：最大（変更は原則例外）
- AI裁量：最小（補助・影響分析のみ）
**Specの扱い**
- 高濃度Specの維持・更新
- 変更理由と影響範囲を記録
**主な手法**
- 運用改善
- 影響分析
- 変更管理
**人間の役割**
- 最終判断
- 責任所在の明確化
#### 具体例：変更管理
```markdown
# Spec変更履歴
## 2024-03-15: カード移動APIの変更
### 変更内容
- position範囲外の挙動を「末尾配置」から「400エラー」に変更
### 変更理由
- 並行編集時の予期しない挙動がサポート問い合わせの30%を占めていた
- 明示的なエラーの方がデバッグしやすいというフィードバック
### 影響範囲
- フロントエンド: CardMoveDialog.tsx
- テスト: card-move.spec.ts
- ドキュメント: API.md
### 承認
- レビュー: @engineer-a, @engineer-b
- 承認: @tech-lead
Vibe CodingとSDDは補完関係にある
ここまでの整理を踏まえると、各開発手法の位置づけが明確になります。
| 手法 | 役割 | 適用フェーズ |
|---|---|---|
| Vibe Coding | 探索を最大化するための技法 | フェーズ0〜1 |
| SDD | 成熟した知見を固定し、共通基盤にする枠組み | フェーズ2〜4 |
これらは相互に排他的ではなく、同じ開発プロセスの異なる側面を扱っています。
おわりに
SDDを「最初から仕様を書く開発手法」と捉えると、探索の余地を奪うものに見えるかもしれません。
しかし実際には、SDDは
- 探索を前提にし
- 確信が持てたものだけを段階的に固定し
- AIの力を一貫性とスピードに変換する
ための思想と枠組みです。
Vibe CodingとSDDは相互に排他的なものではなく、同じ開発プロセスの異なる側面です。
探索 → 試作 → 確信 → 拡張 → 運用
↑ ↑ ↑ ↑ ↑
Vibe Vibe SDD開始 SDD本格 SDD維持
この関係を正しく理解し、今自分がどのフェーズにいるかを意識することが、AI時代の健全なソフトウェア開発につながると考えています。
参考：統合表（完全版）
| フェーズ | Spec濃度 | 作る側の解像度 | 固定度 | AI裁量 | Specの扱い | 主な手法 | 人間の役割 |
|---|---|---|---|---|---|---|---|
| 0: アイデア萌芽 | L0 | 低い | ほぼゼロ | 最大 | 持たない | Vibe Coding, ラフプロト | 違和感・方向性を見る |
| 1: 試作・理解深化 | L1 | 中 | 低い | 大 | 低濃度（変わる前提） | PoC, プロトタイピング | 仮説を壊す・更新する |
| 2: 確信形成 | L2 | 中〜高 | 中 | 中 | 中濃度（不変条件） | SDD入口, 部分Spec化 | 何を固定するか判断 |
| 3: 実装拡張 | L3 | 高い | 高 | 低 | 高濃度（契約） | 本格SDD, チーム開発 | 変更承認・品質担保 |
| 4: 運用・保守 | L3維持 | 非常に高い | 最大 | 最小 | 維持・更新 | 運用改善, 変更管理 | 最終判断・責任所在 |