仕様駆動開発 — Specsを中心とした開発フロー

Mon, 02 Feb 2026 10:00:00 +0900

はじめに

2025年、**仕様駆動開発（Spec-Driven Development）**が話題になり、関連ツールを試してみました。しかし、従来のSDDには「ドキュメント過剰」の課題を感じ、直近の開発で試行錯誤する中での、私なりのアプローチを整理します。

2025年、AIコーディングエージェントの登場により**仕様駆動開発（Spec-Driven Development）**が再注目されています¹。

SDDの理想では、Specレビュー → 実装 → テスト/検証 → フィードバックのサイクルが日単位で回転し、AIにより爆速化されるはずでした²。

flowchart LR
 A[📝 Spec作成] --> B[🔍 Specレビュー]
 B --> C[💻 AI実装]
 C --> D[✅ テスト/検証]
 D --> E{フィードバック}
 E -->|修正| A
 E -->|OK| F[🎉 リリース]

しかし、実際にSDDを試してみると、いくつかの課題が見えてきました。

課題	説明
Specの巨大化	小さな機能追加でも数千行のSpecが生成され、レビューが重くなる²
正確性検証の難しさ	LLMが確率的な出力をする以上、Specのみで実装漏れやミスを防ぐのは難しい
組織的な調整	エンジニア単独では完結せず、PM・QAなど複数ステークホルダーの関与が必要
小規模開発への不適合	単純なバグ修正に詳細仕様を書くのはオーバーヘッド

開発の歴史は、「重すぎる文書化」と「軽すぎる文書化」の間で振り子のように揺れ動いてきました。³

flowchart LR
 subgraph 歴史の振り子
 A[📚 ウォーターフォール
重すぎる文書化] -->|反動| B[🏃 アジャイル
軽すぎる文書化]
 B -->|反動| C[📝 SDD
再び仕様重視?]
 C -->|課題| D[🎯 バランスを探る]
 end

アジャイル開発は「重すぎる文書化」の反動として生まれましたが、別の課題も生まれました。