仕様駆動開発とは？
仕様駆動開発（Spec-Driven Development）は、先に作った仕様を中心にして、実装、テスト、文書の更新を進める開発方法です。英語の頭文字からSDDとも略されます。
AIへその場の会話だけでコードを書かせるのではなく、「何を作るか」「何をしてはいけないか」「どの状態になれば完成か」を仕様として残し、AIと人間が同じ内容を参照します。仕様を、実装前に作って終わる書類ではなく、開発中も更新する共通の判断基準として扱います。
どんな流れで進める？
- 目的と解決したい問題を整理する
- 必要な機能、制約、入出力、完成条件を仕様へ書く
- 人間が仕様を確認し、曖昧な部分を直す
- AIや開発者が仕様をもとに実装する
- テスト結果と実装を確認し、必要なら仕様も更新する
仕様は長い文書である必要はありません。小さな機能なら、目的、変更範囲、守る条件、完了条件をMarkdownへ数項目書くだけでも役立ちます。
バイブコーディングとの違い
バイブコーディングは、「こんなものがほしい」という感覚をAIへ伝え、動くものを見ながら速く進める方法です。仕様駆動開発は、実装前に判断基準を言葉にし、その仕様から外れていないか確認しながら進めます。
- バイブコーディング：試作、自分用ツール、アイデアを確かめる段階に向く
- 仕様駆動開発：長く使う機能、複数人の開発、失敗の影響が大きい仕事に向く
どちらか一方だけを選ぶ必要はありません。最初はバイブコーディングで形を探り、方向性が決まったら仕様へ整理してSDDへ移る方法もあります。
AI時代に重要な理由
AIは、曖昧な依頼からでも、それらしく動くコードをすばやく作れます。しかし、依頼した人が考えていた条件と、AIが補って考えた条件がずれていると、「動くけれど欲しかったものではない」結果になります。
仕様があれば、Claudeで要件と設計を整理し、Codexで実装し、別のAIでレビューする、といった分業でも判断基準を共有できます。会話やモデルが変わっても、仕様がプロジェクトに残ることが強みです。
注意点
仕様と実際のコードがずれたままになる「仕様の陳腐化」には注意が必要です。実装を変更したら仕様も更新し、テストやレビューで両者が一致しているか確認します。
また、SDDは「最初から完璧な仕様を書く方法」ではありません。小さく書き、実装から得た知識を戻し、仕様とコードを一緒に育てる方法として使うと続けやすくなります。