spec駆動開発 (Spec-Driven Development)
コードではなく仕様（spec）を第一級の成果物として扱い、コードはそこからのビルド出力とみなす開発手法。.cファイルをコンパイルしてバイナリを得るのと同じ関係を、Markdownの仕様書とソースコードの間に置く、という比喩でよく説明される。
vibe codingに代表されるLLMを使った開発の失敗モード——エージェントが一見もっともらしいコードを出すが、意図から徐々にずれていき、存在しないAPIを呼び、プロジェクトが大きくなるほど破綻する——への対処として、2025年に立ち上がった。「コードを生成するのは安くなったが、正しさは依然として高い」というのが共通の問題意識にあたる。
従来のドキュメント駆動との違い
仕様書を先に書くこと自体は新しくないが、spec駆動開発では仕様が「書いて終わりのドキュメント」ではなくリポジトリ内に置かれ、エージェントが毎回参照する実行時のコンテキストである点が異なる。仕様はGitで管理され、コードと一緒にレビュー・更新される。人間側にとってはレビュー対象がコードから仕様に前倒しされる、という効果もある。
典型的なワークフロー
ツールによって細部は違うが、おおむね次の段階を踏む。
- 何を作るかを自然言語で記述する（要件・ユーザーストーリー）
- 技術的な設計に落とす
- 依存関係を考慮した順序付きタスクに分解する
- エージェントにタスクを実装させる
- 実装が仕様と一致しているか検証し、仕様を確定させる
段階を厳密なゲートとして強制するか、緩く行き来できるようにするかが、ツールごとの思想の分かれ目になっている。
主な実装
- GitHub Spec Kit —
constitution（プロジェクトの不可侵な原則）を最初に定め、specify → plan → tasks → implementと逐次的に進む。ガードレールが強い。 - OpenSpec — フェーズゲートを強制せず、現状の振る舞いに対する差分（spec delta）として変更を書く。既存コードベース（ブラウンフィールド）優先。
- Kiro — AWSがこの語を早期に打ち出したagentic IDE。2025年7月14日にパブリックプレビュー公開、2026年5月GA。仕様を「super-prompt」と位置づけ、spec → design → tasksという構成を採る。
2026年時点では主要なAIコーディングツールがそれぞれ独自のspec駆動の流儀を持っている状況で、上記のほかBMAD、Tessl、Google Antigravityなども挙げられる。
SKILL.mdとの関係
SKILL.mdやAGENTS.mdが「エージェントにどう作業させるか（手順・規約）」を渡すのに対し、spec駆動開発の仕様は「何を作るか（プロダクトの意図）」を渡す。レイヤーが違うため併用される。
出典
- spec-kit/spec-driven.md - GitHub
- Diving Into Spec-Driven Development With GitHub Spec Kit - Microsoft for Developers
- Spec-driven development, Back to the Future?!
- Kiro: Your agentic IDE for spec-driven development - AWS re:Invent 2025