近頃もてはやされる仕様駆動開発とやら。お前に俺たちの開発が救えるか。
見よ、仕様駆動開発の名を騙るものを
ここ一年ほどで、「仕様駆動開発をやるべきだ」という声をよく聞くようになりました。けれど、聞くたびに少し引っかかるものがありました。たぶん理由は単純で、「仕様駆動開発」と言いながら、その「仕様」が人によって全然違うからです。要件を指している人もいれば、設計を指している人もいる。ひどいときには、願望とTODOと擬似コードまで全部まとめて「仕様」と呼ばれている。
仕様、便利すぎる。便利すぎる言葉は、たいてい危ないです。名をひとつ与えれば、何かを分かった気になれる。しかし実際には、その中でまだ整理されていない意図も、対立した前提も、言葉になっていない判断も生き残っている。
GitHubはSpec Kitを通じて、仕様を中心に /specify、/plan、/tasks と段階化し、AIエージェントに実装させるプロセスを提示しています。そこでは仕様は、静的な文書ではなく、プロジェクトとともに更新されるliving documentであり、AIと人間がともに参照するSSoTだと説明されています。
一方で Thoughtworks は、spec-driven developmentを「構造化された要求仕様をプロンプトとして用いてAIコーディングエージェントでコード生成を進める開発パラダイム」と説明しつつ、その定義はまだ業界内で揺れていると整理しています。実際、業界には「仕様こそが保守対象であり、コードは二次成果物にすぎない」という立場もあれば、「最終的なSSoTは実行可能コードだ」という立場もあります。 Technology Radar も、定義はまだ流動的だと述べています。
さらに、Spec-Driven Development: From Code to Contract in the Age of AI Coding AssistantsやUnderstanding Spec-Driven-Development: Kiro, spec-kit, and Tesslでは、この曖昧さをより明示的に扱っています。 そこでは、仕様駆動開発を「仕様をSSoTとし、コードを生成または検証される二次成果物として扱う発想」としたうえで、実際にはspec-first、spec-anchored、spec-as-sourceという厳密さの異なるレベルがあると整理しています。つまり、仕様駆動開発は単一の教義ではなく、スペクトラムです。だから、「spec -> plan -> tasksと進めば自動的にSDDになる」とも言えませんし、「仕様を正確に書ければ人間はもうコードと向き合わなくてよい」とも言えません。まずこの言葉の揺れを自覚しないと、議論はすぐに宗教戦争になります。
ぼくが仕様駆動開発に対して「よくわからんなぁ」と感じるのは、概念より先に道具が広まっているからです。もちろん、それ自体に問題があるわけではありません。ただ、その結果として、「とりあえずSDDのツールを入れればよい」「spec-onlyでいけるらしい」「人間はレビューだけしていればよい」といった、魅力的だけれど雑な言説が出回りやすくなります。
このエントリではひとまず、仕様を「AIに実装を委譲する前に、人間が外化しておくべき意図・制約・成功条件・境界条件の構造化されたもの」として扱います。Word一冊である必要はないし、Markdown一枚である必要もない。大事なのは、AIが危険な補完をしないために必要なだけ具体的であり、人間が検証できる形になっていることです。
その仕様、まことに人の言う仕様か
仕様駆動開発の議論をややこしくしている理由は、「仕様」という言葉が多くのものを兼ねていることです。要件定義書を思い浮かべる人もいれば、PRDを思い浮かべる人もいる。設計方針、受入基準、テスト観点、作業分解、アーキテクチャ原則まで含める人もいます。
GitHubのSpec Kitは、まさにその曖昧さを工程分割で吸収しようとしています。高レベルの要求と成功条件を仕様として起こし、それを技術的な実装計画に落とし、最後にタスクへ分解する。ここで重要なのは、「仕様」が一枚の神聖な文書ではなく、意図を徐々に具体化していく一連の構造化成果物として扱われていることです。GitHubは各段階にチェックポイントを置き、方向づけだけでなく検証も人間の役割だと明言しています。
ここでいう「仕様」は、完成済みの名詞というより、AIに危険な補完をさせないためのコンテキスト設計です。仕様とは、情報の置き場ではなく、AIが判断するときの足場だと言った方が近いでしょう。Thoughtworksの整理もこれに近く、spec-driven developmentは単に要件を書く作法ではなく、構造化された機能仕様を複数の段階を経て解決策やタスクへ落としていくワークフローだとされています。ただし同時に、それはかなりopinionatedであり、ツールやタスクの種類によって姿が変わるとも注意されています。
Addy Osmaniの “How to write a good spec for AI agents” は、この点をさらに実務的にしています。
仕様駆動開発の「仕様」を一言で言うなら、AIに実装を委譲するために人間が先に外化しておくべき意図・制約・成功条件・境界条件の束です。媒体はWordやMarkdownやチケット群などでよい。重要なのは、AIが勝手に危険な補完をしないだけの具体性と、人間が検証可能な構造を持っていることです。ここを外すと、「仕様」という看板の下に、長文メモと擬似コードとレビュー観点の残骸が押し込まれていきます。人はそれを整理したつもりになる。でも実際には、散らばったものを一枚の皮で包んだだけ、ということも珍しくありません。
仕様だけにすがって、生きられるか
仕様駆動開発の議論が盛り上がると、高い確率で「十分に厳密な仕様を書ければ、人間はコードを細かく読まなくてもよいのではないか」という誘惑が現れます。気持ちはわかるよ気持ちは。人は疲れると、よくできた言葉にすがりたくなるものです。これだけ丁寧に書いたのだから、あとは正しく実装されるはずだ。そう思いたくなる。けれど、その願いはしばしば、人間の理解責任を別の場所へ追いやっているだけです。
問題は、自然言語仕様には表現限界があることです。だから実装判断そのものは消えません。そして、その不足を文書の厚みで埋めようとすると、今度はレビュー負荷がコード側から文書側へ移るだけです。 コードより先に仕様を整え、AIにそれを忠実に実装させられるなら、変更の中心は仕様に移り、レビューも仕様レビュー中心へ寄せられる。見た目はたいへん美しい。プロジェクトマネージャーも喜びそう。けれど、その美しさに安心しすぎるのは危険です。
Addy Osmaniが理解負債（Comprehension Debt）と呼んでいるのは、まさにその見えにくい危険です。理解負債とは、システムに存在するコード量と、それを人間が本当に理解している量のギャップです。AIがコードを大量に生成できるようになると、このギャップは従来より速く広がります。しかも厄介なのは、コードベースが一見きれいで、テストも通っているため、問題が静かに潜伏することです。Addyは、「テストが通ったこと」と「自分たちがそれを理解していること」は別物だと強く警告しています。
ここでspec-onlyの限界が出ます。自然言語仕様がどれほど精密でも、実装には境界条件、例外処理、データ構造の選択、性能トレードオフ、既存コードベースとの接続、UIのふるまい、運用上の抜け道といった暗黙の設計判断が入り込みます。つまり、仕様は実装を駆動できても、実装判断そのものをゼロにはできません。
だからAddyが言うように、巨大な仕様を丸ごと投げるのではなく、スマートな仕様にする必要があるわけです。仕様は必要ですが、自然言語仕様だけで実装上の暗黙的な判断を封じ込めることには限界がある。もし本当に封じ込めようとすれば、仕様はどんどんコードに似ていきます。すると、コードを目を皿にして確認していた工数が、今度は文書を目を皿にして確認する工数へ移動するだけになります。これは効率化というより、レビュー対象の横滑りです。
marmelabの批判は、まさにこの痛点を突いています。そこでは、SDDは実装前に重い設計を積み上げる形でMarkdownを大量に生み、レビュー負荷を減らすどころか、むしろ二重化すると批判されています。 そして、仕様が厚くなるほど安心できるとは限らない。むしろ「読んだ気になれる」ことの方が危ないのです。読んだ気になった仕様は、読まれなかった仕様より静かに人を誤らせます。
ただし、ここから「では仕様は要らない」と飛ぶのも短絡です。GitHubとAddyのどちらも、AIエージェントへの明確で過不足ない構造化された仕様が必要だと述べています。理由は単純で、AIは指示の行間を読まないからです。曖昧な指示から暗黙の要件を正しく推測できない。だから仕様は必要です。けれど、それは万能の代理人ではありません。AIが勝手に危険な補完をしないために必要なだけ具体的であるべきものです。大事なのは長さではなく、境界条件と検証可能性です。
曇りなき眼で考える、仕様駆動開発のあり方
ここまで整理すると、あるべき仕様駆動開発の姿はかなり絞れます。仕様は必要です。だが、仕様だけでは足りない。仕様はAIに道を示せます。でも、その道が正しいかどうかを引き受けるのは、やはり人間です。仕様はAIに仕事をさせる入口であり、品質保証や理解の代用品ではない。この3つを同時に言える形でなければ、筋の通ったSDDにはならない気がします。
この点で、SDD 論文が示す “Golden Rule” は重要そうに思います。
The Golden Rule: Use the minimum level of specification rigor that removes ambiguity for your context. Spec-first for AI-assisted initial development; spec-anchored for long-lived production systems; spec-as-source only when generation tooling is mature and trusted.
仕様の厳密さは信仰心で決めるものではなく、その文脈で曖昧さをどこまで除去しないと危ないかで決めるべきだ、ということです。AI補助の初期開発ならspec-firstで十分な場合もある。長く運用する本番システムならspec-anchoredが必要になる。spec-as-sourceは、生成ツールが十分に成熟し、信頼できる場合に限られる。全部をspec-as-sourceに寄せる必要はありませんし、自然言語仕様を無限に厚くすればよいわけでもありません。
GitHubの流儀を踏まえると、この話はさらに具体的になります。つまり、仕様は凍結文書ではなく、実装と検証を通じて更新され続けるliving documentです。何かおかしければ仕様に戻り、複雑になったら整理し、タスクが大きければ細分化する。ここでの本体は、実装後にWordを赤入れすることではなく、「何をどの粒度で誰が更新し、その変更を何で検証するのか」を決めることです。
そして、この運用を成立させる条件が、人間の理解責任を消さないことです。要求やedge caseは、最初から全部そこにあるわけではありません。実装し、つないで壊し、レビューして初めて見えてくるものがあります。Addyの理解負債論が言っているのは、まさにそこです。AIで実装速度が上がっても、システム全体の理解、つまり「なぜこの形なのか」「どの部分が根幹なのか」「どこを変えると何が波及するのか」という感覚は、自動では共有されません。だから人間がコードを読む能力は、なくならないどころか、むしろ希少資源になります。AI時代のエンジニアリングで残る仕事は、全文字を手打ちすることでなく、仕様と実装の差分を見抜いて変更影響を判断し、理解負債が積み上がらないようにすることです。
この意味で、あるべき仕様駆動開発とは、「AIに全部任せる方法」ではありません。AIに委譲しやすいように仕様を外化しつつ、その仕様を更新可能な運用対象として扱い、人間が理解・検証・修正のループを持ち続ける方法です。仕様は入口です。出口ではありません。人間の理解は保険ではなく、本体の一部です。
まとめ
黙れ小僧！仕様駆動開発に俺たちの仕様を救えるか！
要件定義で固めたはずの仕様を基本設計で言い換え、詳細設計で分解し、実装で解釈してテストで真意を問い直す。その長い工程のあいだで、誰も嘘をついておらぬのに、少しずつ意味がズレていく！
しかも我らは、設計の判断基準も、変更時に何を見ているのかという手順も、頭では分かっているつもりで、いざ外化しようとすると驚くほど言葉にできぬではないか！
Wordにもなりきれず、Markdownで完結できず、チケットにもExcelにも散っていく、哀れで愛しい我らの仕様だ！
お前にこの仕様を救えるか！
仕様は人間社会の産物です。承認経路や政治、既存資産の重み、現場の苦心まで抱えています。仕様駆動開発が突然それを浄化してくれるわけではありません。marmelabが警戒したように、やり方を誤ればSDDは重い文書駆動に戻り、読むだけで一日が終わる未来を招きます。Addyが警告したように、AIが大量にコードを書いても、人間が理解しなければ理解負債は静かに膨らみます。
それでも、仕様駆動開発が開発を救う可能性はあるんだと思います。その形は、仕様書を一冊きれいにすることではありません。AIに渡す意図を明示し、勝手な補完を減らし、実装と検証を通じて仕様を更新し、人間の理解責任を散らさずに保つことです。GitHub的な整理を踏まえると、いま起きているのは、「意図や制約を先に構造化して管理する」状態への重心移動だと言えます。ただし、その意図を保守するのは結局のところ人間です。仕様駆動開発が救うのは仕様そのものというより、仕様をめぐる意思決定の秩序です。
仕様駆動開発は、たぶん俺たちの開発を簡単には救いません。しかし、仕様を凍結文書でなく運用対象として扱うことで、ズレを早く見つけて理解負債を小さくし、開発を少しまともにできます。そのために必要なのは、spec-onlyの夢でなく、どの仕様を誰がいつどう更新するのかを設計することです。
要するに、仕様駆動開発の本質は「仕様を増やすこと」ではありません。仕様を運用することです。
やり方？ 知らんわ。教えてくれよ頼むから。
