スペック駆動開発

スペック駆動開発とは

スペック駆動開発（Spec-Driven Development / SDD）は、AIエージェントにコードを生成させる前に、目的・制約・受け入れ条件を明文化した構造化仕様書を作成する開発手法だ。「バイブコーディング」がプロンプトの雰囲気でコードを生成するのに対し、SDD ではエージェントへの指示の前に人間が仕様を確定させ、その仕様を実装の唯一の正解（Single Source of Truth）として扱う。

仕様書は Markdown などの人間が読みやすい形式で書かれる。バグ修正やリファクタリングの際も、まず仕様書を更新してからエージェントに差分を実装させることで、コードが仕様から乖離しにくい構造を維持する。2025年末にエンジニアコミュニティで注目を集め、2026年には DeepLearning.AI がコースを開設、Microsoft・GitHub・AWS が専用ツールをリリースした。

なぜ注目されているのか

AIコーディングツールが普及する中で、「もっともらしいが間違ったコード」が大量生成される問題が顕在化した。エージェントはプロンプトの文脈から実装を推測するため、プロジェクトが大規模になるほど仕様とコードの乖離（ドリフト）が進む。SDD はこのドリフトへの構造的な対処として位置づけられており、早期採用者の報告ではエージェントによる一発実装の成功率が従来比 3〜10 倍になるとされている。

一方で、仕様書の作成・維持コストが増加するという課題もある。仕様を書く段階で要件が固まっていなければ SDD の効果は薄く、仕様変更のたびにエージェントへの再指示が必要になる。アジャイルな開発では仕様ファーストの原則と相性が悪い場面もあり、ユースケースを絞った導入が推奨されている。

関連する技術

バイブコーディングとは目的が対照的だが技術的な土台は共通しており、Claude Code や GitHub Copilot などの AI コーディングアシスタントがどちらにも使われる。またメタハーネスによる複数エージェントの制御と組み合わせることで、単一の仕様書から複数エージェントが並列実装する設計パターンも登場している。

ドラゴンボールで例えると

AIエージェントを悟空、開発者を亀仙人に例えると、スペック駆動開発は「修行メニューを紙に書いて渡してから修行を始める」スタイルにあたる。

• 仕様書（Spec） ＝ 亀仙人が渡す修行メニュー表。「牛乳を100軒配達・甲羅を背負って10km走る」という受け入れ条件つきの指示書
• バイブコーディング（従来の丸投げ） ＝ 「なんか強くなりそうなことをしてこい」と感覚だけで丸投げ。悟空は自己流で動くが、方向がずれやすい
• スペック駆動開発 ＝ メニューを事前に明文化し、「このチェックリストが全部終わったら合格」という基準を渡してから修行させる
• 仕様ドリフト ＝ メニューを口頭で伝えたら悟空が途中で忘れて別の修行をしている状態。仕様書があればズレを即検知できる
• 仕様変更コスト ＝ 修行メニューを毎週変えると悟空も混乱する——アジャイルな頻繁な変更とは相性が悪い場面も

「感覚で強くなれ」より「このメニューをこなせ」のほうが再現性が高い。AIが「なんとなく動く」時代になるほど、仕様を先に固める原則が重要になる。