AIにコーディングさせる方法が急速に分かれています。
一方には、会話しながら即興で作っていくバイブコーディングがあります。もう一方が、この記事のテーマであるSpec Driven Development（SDD）です。
一言で言えば、SDDはコードを依頼する前に、まず仕様（spec）を文書として確定します。
その文書を唯一の真実の情報源とし、AIに計画・実装・検証を進めさせます。
この記事では、SDDの仕組み、代表的なツールであるspec-kitとKiro、バイブコーディングとの使い分けまで整理します。ツール情報は2026年8月時点のものです。
まずは要点から見ていきましょう。
- SDDは「何を作るか」をspec文書で先に確定し、コードをその成果物として扱う方法論です。
- 流れはspec（要件）→ plan（技術設計）→ tasks（作業分解）→ 実装の4段階です。
- GitHubのspec-kitとAWSのKiroが、この流れをツールとして実装した代表例です。
- 一般的な使い分けは、プロトタイプにはバイブコーディング、長期保守するプロダクトコードにはSDDです。
なぜ仕様が再び注目されたのか
開発前に文書を書くという考え方自体は新しくありません。ウォーターフォール時代の要件定義書がまさにそれでしたが、重すぎるとしてアジャイルに押し出されました。
しかしAIエージェントの登場で状況が変わりました。人間の開発者は曖昧な要件を受けても、質問しながら文脈を補います。
一方AIは、曖昧なプロンプトを受けると空白をもっともらしい推測で埋めます。要件と違うのに見た目は正常という、最も厄介な不具合が生まれます。
そこで「AIに仕事をさせるなら、まず曖昧さを取り除く必要がある」という要求が生まれ、答えとして仕様が再び注目されました。今回は人が読む文書ではなく、AIが実行基準にする文書だという点が異なります。
4段階のパイプライン：specからtasksまで
ツールによって名称は少し異なりますが、骨格は同じです。
| 段階 | 成果物 | 確定する内容 |
|---|---|---|
| Specify | spec.md | 何を、なぜ作るのか（要件・シナリオ） |
| Plan | plan.md | どう作るのか（技術スタック・アーキテクチャ） |
| Tasks | tasks.md | どの順番で作るのか（作業単位への分解） |
| Implement | コード | 各taskを順番に実装 |
重要なルールは2つあります。
1つ目は、各段階の成果物を人がレビュー・承認してから次へ進むことです。曖昧さがコードに届く前に、文書段階で除去されます。
2つ目は、実装中に要件が変わったらコードではなくspecを修正し、その下流の段階をやり直すことです。specは常に最新の真実でなければなりません。
見方を変えると、コードはもはや原本ではなく、specをコンパイルした成果物です。本当のソースは文書なのです。
2つのツール：spec-kitとKiro
GitHubのspec-kitは、特定のエージェントに依存しないオープンソースのツールキットです。
Claude Code、Copilot、Gemini CLIなどの上に、/specify、/plan、/tasksのスラッシュコマンドを追加し、前述のパイプラインを強制します。
プロジェクトの不変の原則を記載するconstitution文書を置ける点も特徴です。
AWSのKiroは、SDDを中心に設計されたエージェント型IDEです。requirements.md、design.md、tasks.mdの3種類の文書を作成します。
強みは要件の記法です。EARS（Easy Approach to Requirements Syntax）記法で要件を構造化します。
「システムは〜の状況で〜しなければならない」という形の文に整理する方法です。
すでにClaude Codeのような汎用エージェントを使っているなら、spec-kitを追加する方が導入コストは低くなります。IDE統合の体験を求めるならKiroが適しています。
バイブコーディングとの使い分け
SDDが常に正しいわけではありません。3種類の文書を作成してレビューするコストが実際にかかるため、週末のプロトタイプや一度限りのスクリプトに適用すると、かえって大げさになります。
判断基準はコードの寿命です。今週捨ててもよいコードなら、バイブコーディングで素早く回します。
数か月以上保守・拡張するコードなら、SDDで先に曖昧さを取り除く方が総コストを抑えられます。
運用時に注意すべき点が1つあります。specとコードがずれたまま放置されるdriftです。
「要件変更は必ずspecから」というルールが崩れた瞬間、specは誰にも信頼されない文書になります。そうなるとSDD全体が形式的な手続きに成り下がります。
まとめ
結局のところ、SDDは「AI時代の本当のプログラミング言語は自然言語の仕様である」という主張です。1行のプロンプトで済ませていた意図の伝達を、レビュー可能な文書へと引き上げます。
次の機能開発でプロンプトを書く前に、まずspec文書を1つ書いてみてください。この方法論が自分の作業に合うか、1日で判断できます。