仕様駆動開発とは何か ── Vibe Codingの次のステージ

2026/04/26

仕様駆動開発とは何か ── Vibe Codingの次のステージ

この章では、仕様駆動開発（SDD）の定義と、関連する開発手法との関係を整理する。

仕様駆動開発の定義

**仕様駆動開発（Specification-Driven Development、SDD）**とは、仕様（Specification）をソフトウェア開発の中心に置き、コードより仕様を「真実の源泉（Source of Truth）」とみなす開発アプローチだ。

従来の開発では「コードが唯一の真実」だった。ドキュメントは実装の後追いで書かれ、しばしば実態とズレていく。

SDDはこれを逆転させる。

従来の開発:
  実装 → テスト → ドキュメント
  （コードが真実）

仕様駆動開発:
  仕様 → テスト → 実装
  （仕様が真実）

この逆転は、AIがコードを書く時代において特別な意味を持つ。AIは仕様さえ明確であれば、実装・テスト・ドキュメントをすべて生成できる。逆に、仕様が曖昧なら、AIは独自の解釈で「それっぽいコード」を作り始める。

Vibe Codingとの違い

「雰囲気で伝えてAIに作ってもらう」Vibe Codingと、SDDはどう違うのか。

観点	Vibe Coding	仕様駆動開発
指示の形式	自然言語（曖昧でよい）	構造化された仕様（明確であること）
仕様の扱い	都度チャットで伝える	SPEC.mdなどのファイルに永続化
テスト	後付け（または省略）	仕様から先行して生成
チーム共有	難しい	仕様ファイルで共有可能
適した規模	個人プロトタイプ	チーム開発・長期保守
コードの一貫性	担保しにくい	仕様が制約として機能

Vibe Codingが悪いわけではない。プロトタイプ、個人プロジェクト、アイデアの初期検証には今も有効だ。

問題は「Vibe CodingをそのままチームのメインSTYLEにする」ことだ。

伝統的なSDDとの違い

「仕様駆動開発」という言葉自体は新しくない。ウォーターフォール開発の文脈では「要件定義書・設計書を先に書く」というプロセスを指すこともある。

AI時代のSDDはこれとも異なる。

観点	伝統的なSDD	AI時代のSDD
仕様の形式	数十〜数百ページの文書	1〜2ページのMarkdown
仕様の検証	人間がレビュー	AIが実装し、テストで自動検証
サイクル	ウォーターフォール的（数週間〜数ヶ月）	インクリメンタル（数時間〜数日）
目的	「何を作るか」の合意	「AIに正確に何を作らせるか」の制約
変更コスト	高い（手戻りが大きい）	低い（仕様を修正してAI再実行）

AI時代のSDDは、ウォーターフォールへの回帰ではない。 仕様は軽量で、変更可能で、テストと直結している。

BDDとの関係

**BDD（振る舞い駆動開発、Behavior-Driven Development）**は、SDDの一部を構成する実践手法だ。

BDDでは、振る舞いをGherkin形式で記述する：

Feature: ユーザー認証

Scenario: 正常なログイン
  Given ユーザー "[email protected]" が登録されている
  When メールアドレスとパスワードを入力してログインする
  Then ダッシュボードへリダイレクトされる
  And セッショントークンが発行される

この記述はそのままテストコードに変換される。SDDとBDDの関係はこうだ：

SPEC.md（機能全体の仕様）
  ├── Outcomes: ゴール
  ├── Scope: 範囲
  ├── Constraints: 制約
  └── Scenarios（BDD）: ユースケース別の振る舞い
        ├── Gherkin形式のシナリオ
        └── → そのままCucumberテストになる

BDDは「ユースケースレベルの仕様」、SDDはそれを包む「機能レベルの仕様設計」と理解するとよい。

OpenAPI・Contract-Firstとの関係

APIを持つシステムでは、OpenAPI（Swagger）やAsyncAPIによる仕様記述もSDDの一形態だ。

# openapi.yaml（API仕様の例）
openapi: 3.1.0
paths:
  /api/users:
    post:
      summary: ユーザー登録
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [email, password]
              properties:
                email:
                  type: string
                  format: email
                password:
                  type: string
                  minLength: 8
      responses:
        '201':
          description: 登録成功

この仕様ファイルから：

フロントエンドのSDK（TypeScript型定義込み）
バックエンドのスタブサーバー
APIテストスイート

を自動生成できる。これがContract-First開発だ。SDDとOpenAPIを組み合わせると、フロントエンドとバックエンドが仕様（コントラクト）を軸に並行開発できる。

SDDの核心：「仕様が実行可能である」ということ

伝統的な仕様書は「読むもの」だった。AI時代の仕様は「実行されるもの」だ。

SPEC.md
  ↓（AIが読む）
  ↓（テストを生成）
  ↓（実装を生成）
テスト実行 → PASS/FAIL

仕様が通れば実装は正しい。仕様が失敗すれば実装を修正する。仕様そのものが検証ゲートになる。

これが「仕様が真実の源泉」の実体的な意味だ。

次の章では、なぜ2026年のこのタイミングでSDDが注目されているのか、その背景を探る。