GitHubが提唱する“Spec-Driven Development”は、曖昧なプロンプトに頼るVibe Codingを卒業し、AIを仕様書で導く新しい開発哲学だ。
序章：ノリで書く開発、どこまで通用したか
生成AIの登場以降、コードを書くスピードは劇的に上がった。
「これを作って」と言えばAIが即座に雛形を出し、開発者は修正を重ねながら完成に近づける。
この“Vibe Coding”──つまり、明確な仕様なしに雰囲気でAIに書かせる開発は、最初のブームを支えた。
だが現場では、次第にその副作用が露呈してきた。
仕様がないまま進むため、
- 途中で挙動がズレる
- 修正指示が累積して破綻する
- チーム共有が困難になる
という典型的な“後戻り地獄”に陥る。
そして今、GitHubはこの混乱に対する回答として“Spec-Driven Development”を打ち出した。
第1章：Spec-Drivenとは何か
GitHubが公開した「Spec Kit」は、仕様（spec）をAIにとっての行動指針にするという発想から生まれたオープンソースツールだ。
開発プロセスは以下の4ステップに整理されている。
- Specify（仕様定義）
目的・要件・制約を明示し、AIに理解させる。 - Plan（設計）
仕様に基づき、実装アーキテクチャをAIとともに策定。 - Tasks（分解）
実装タスクを整理し、AIが扱える粒度まで落とし込む。 - Implement（実装）
AIが仕様に沿ってコードを生成・改修し、開発者がレビューする。
この循環は、もはや“AIに命令する”というより、“AIと仕様書を共有して共に進める”というスタイルに近い。
第2章：仕様がAIの「契約書」になる
Vibe Coding時代は、プロンプトが命令であり、結果は出たとこ勝負だった。
Spec-Drivenでは、仕様がプロンプトよりも上位に立つ。
AIにとっての「契約書」が仕様書になることで、
- 生成結果の一貫性
- バグや解釈ミスの削減
- チーム間での“共通言語”
が生まれる。
GitHub自身が「仕様をAIに与えることは、曖昧さを減らす最良の方法」と述べているのは象徴的だ。
AIは曖昧さを嫌う。仕様はその“光源”であり、AIの行動範囲を定義する羅針盤になる。
第3章：直感から理性への転換
Vibe Codingは、ある意味で“芸術的な創作”に近かった。
プロンプトとAIの間にある偶発的なひらめきを楽しむ文化があった。
だが、プロダクト開発の現場ではそれが持続しない。
Spec-Drivenはその真逆──論理・再現性・共有可能性の回復だ。
AIを「助手」ではなく「設計者の部下」として扱う。
人間は仕様策定という上流工程に集中し、AIは実装と検証を担う。
開発という営みの重心が、再び「設計」に戻ってきたとも言える。
第4章：反発と課題
とはいえ、Spec-Drivenが万能というわけではない。
仕様を書く手間は増えるし、自由な試行錯誤はやや抑制される。
また、仕様が不完全なままAIに与えられた場合、誤った方向に完璧に実装されてしまうリスクもある。
つまり、AIが仕様を守る時代は、人間が仕様に縛られる時代でもある。
ここをどうデザインするかが、次の課題になる。
結語：AIと“仕様書で語る”時代へ
GitHubが提唱するSpec-Driven Developmentは、
Vibe Codingの混沌を経たAI時代の第2段階──“理性と構造の復権”を象徴している。
仕様はもう「ドキュメント」ではない。
AIにとっての指令書であり、プロジェクト全体の意思そのもの。
人間が仕様を整え、AIがそれを忠実に具現化する。
そんな未来が、静かに始まろうとしている。
