仕様駆動開発への期待と誤解
ある意味ブレーキと理解すれば良いPlanモードと異なり、仕様駆動開発への理解を難しくする論点として、「仕様（Spec）とは何なのか」「作成された仕様書をどのように扱うか」「仕様駆動開発はウォーターフォールへの先祖返りなのか」の3つの論点が挙げられます。1つずつ整理していきましょう。
代表的な疑問①: 仕様（Spec）とは何なのか
2025年7月にAWSが公開したAIエージェント搭載のIDEであるKiroは仕様駆動開発の火付け役です。 公開された記事『Kiro and the future of AI spec-driven software development』には、仕様書について、「A specification is a kind of (version controlled, human-readable) super prompt.」[1]と記されています。
[1] 筆者訳：仕様書とは、バージョン管理され、人間が読める、一種のスーパープロンプトです。
OSSのSpec-kitは、仕様駆動開発のプロセスを「外付け」で支援するために用意されたプロンプトとスクリプトをひとまとめにしたキットです。公開元であるGitHubが書いたブログ『Spec-driven development with AI: Get started with a new open source toolkit』では、仕様書について、 「That’s why we’re rethinking specifications — not as static documents, but as living, executable artifacts that evolve with the project.」[2]と記されています。
[2] 筆者訳：仕様書を静的な文書ではなく、プロジェクトと共に進化する生きた実行可能な成果物として捉え直しています。
この2つを見ると、どちらも既存の仕様書とは異なる概念であることが分かります。仕様が実装の先に来ること自体は当たり前ですが、仕様書はあくまでCoding Agentが実装前に必要とするプロンプトであり、生きたドキュメントであるという点については、Vibe Coding以後に生まれた概念として新たに受け止める必要があります。
代表的な疑問②: 作成された仕様書をどのように扱うか
仕様駆動開発への期待と誤解を整理すべく、3つのパターンを紹介します。これはThoughtworks社のBirgitta Böckelerが執筆した記事『Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl』で紹介されているものです。
| アプローチ | 特徴 | 仕様の位置づけ |
| Spec-first | 仕様を優先して作成 | 実装の前提条件 |
| Spec-anchored | 仕様を起点に、実装しながら更新 | 進行中の基準点 |
| Spec-as-source | 仕様そのものがコード生成の入力 | 実行可能な定義 |
Spec-firstは仕様ファーストという名の通り、要件・設計・タスクをすべて揃えてから実装に入るスタイルです。綿密に練られた仕様を元にしたワークフローを採用し、開発者の意図との差が小さくなるのがメリットです。仕様ファイルの保守戦略については明言されていないか、実装後は削除されるものが多いです。
Spec-anchoredでは、仕様を書き出して実装をするまではSpec-firstと同様のプロセスを経ます。その後の仕様ファイルの扱いが異なり、仕様ファイルがタスク完了後も保持され、該当機能の進化と保守のために引き続き使用されます。
Spec-as-sourceは、Spec-anchoredの仕様の取り扱いを推し進めた考え方で、ソースコードは仕様書に完全に従属するといったものです。宣言的UIやインフラのコード化（IaC）に近い発想で、仕様と実装の乖離が原理的に起きない前提に立ちます。
前述の通りKiroやSpec-KitはSpec-first相当の戦略を採っています。ところが仕様駆動開発という字面の印象から、仕様を継続的にメンテナンスする(Spec-anchored)という考え方や、仕様こそが正でソースコードは動的に作り直せる(Spec-as-source)という考え方など、思い浮かべる前提が異なることがある点に気を付けましょう。
ウォーターフォールへの先祖返りなのか
仕様駆動開発の中には、仕様書を信頼できる唯一の情報源(Single Source Of Truth、SSOT) として扱う流派があることを知ると、開発の中心がソースコードからドキュメントへ先祖返りしているようにも感じられます。このことから仕様駆動開発とはウォーターフォール開発の復権ではないかと疑問に思ったり、反発したりする開発者も居るでしょう。
ウォーターフォール開発特有の、各フェーズの厳格な順序性や前工程への戻りの難しさは仕様駆動開発とは無関係です。仕様駆動開発の仕様書はKiroが「スーパープロンプト」と定義したように、あくまでAIエージェントを動かすための制御手段であり、コンテキスト注入の一環です。生きたドキュメントとしてAIエージェントに最新の仕様を渡せることが、その柔軟性を支えています。
