AIコーディングアシスタントが爆発的に普及した2025年、ソフトウェア開発の世界で新たなパラダイムが急速に立ち上がりつつある。Spec-Driven Development（SDD：仕様駆動開発）──仕様書をソースコードに先立つ「正」として扱い、実装をAIによる生成物と位置づける開発手法である。2025年8月にはAmazon Kiroが仕様駆動型IDEとして一般提供を開始し、同年9月にはGitHubがオープンソースのSpec Kitを公開。ThoughtWorksはTechnology Radar Vol.33（2025年11月）で同手法を「Assess」に分類した。本記事では、SDDの原理と実践パターン、TDD/BDDとの関係、そして導入企業の実践知見を整理する。

SDDとは何か ── 「仕様が正、コードは生成物」

Spec-Driven Developmentとは、構造化された仕様（Specification）を開発の起点かつ唯一の信頼源（Single Source of Truth）とし、AI コーディングエージェントがその仕様から実装コードを生成するワークフローを指す。従来の開発ではソースコードそのものが最終的な真実であったが、SDDではこの関係を逆転させる。

2026年1月に公開されたarXiv論文「Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants」（Deepak Babu Piskala著）は、SDDの成熟度を3段階に分類している。

  • Spec-First（仕様先行）：仕様を先に書き、それに基づいてコードを書く。API開発におけるOpenAPI仕様の先行定義がこの典型である。
  • Spec-Anchored（仕様固定）：仕様が開発を方向づけるが、実装上の判断は開発者に委ねられる。GitHub Spec Kitが採用するアプローチに近い。
  • Spec-as-Source（仕様＝ソースコード）：仕様そのものがメンテナンス対象のアーティファクトとなり、コードは完全に使い捨ての生成物として扱われる。Tessl Frameworkが志向する急進的なビジョンである。

この3段階は排他的な選択ではなく、プロジェクトの性質やチームの成熟度に応じて使い分けるべきものとされる。論文はAPI開発・エンタープライズシステム・組み込みソフトウェアの各ドメインでのケーススタディを通じ、SDDの適用判断フレームワークを提示している。

主要ツールの比較 ── Spec Kit・Kiro・Tessl

2025年後半、SDDを実践するためのツールが相次いで登場した。それぞれ思想と粒度が異なり、開発チームは自らのコンテキストに合ったものを選ぶ必要がある。

GitHub Spec Kit

2025年9月2日にGitHub Blogで正式発表されたオープンソースツールキット。4つのフェーズ──Specify（仕様記述）→ Plan（技術計画）→ Tasks（タスク分解）→ Implement（実装）──を順に進めるCLIベースのワークフローを提供する。Copilot、Claude Code、Gemini CLIなど主要なAIコーディング環境をサポートし、エージェント非依存（agent-agnostic）を特徴とする。仕様・計画・タスクはすべてMarkdownファイルとしてリポジトリに格納されるため、既存のGitワークフローと自然に統合できる。

Amazon Kiro

2025年7月にプレビュー版として登場し、同年11月17日に一般提供（GA）を開始したAIネイティブIDE。自然言語で要件を記述すると、ユーザーストーリー（受け入れ基準付き）→ 技術設計書（ダイアグラム・スキーマ含む）→ 実装タスクリストの3段階を自動生成する。料金はクレジット制（無料枠50クレジット〜Power tier月額200ドル）で、Claude Sonnet 4.0を含む複数モデルを選択可能。仕様からの自動生成に最も踏み込んだ商用プロダクトである。

Tessl Framework & Registry

2025年時点でプライベートベータ段階にあった仕様駆動プラットフォーム。最大の特徴はSpec Registryで、10,000以上のプレビルド仕様を公開し、AIエージェントがオープンソースライブラリを正しく使用できるようコンテキストを提供する。「コードではなく仕様をメンテナンスする」という最も急進的な立場を取り、仕様の更新が自動的にコード再生成をトリガーするビジョンを掲げる。

TDD・BDDとの関係 ── 対立ではなく階層構造

SDDはTDD（テスト駆動開発）やBDD（振る舞い駆動開発）を否定するものではない。むしろ、3つの手法は抽象度の異なるレイヤーとして階層的に共存する。

  • SDDは「何を・なぜ作るか」を定義する。プロダクトの意図と契約を自然言語＋構造化フォーマットで記述し、AIエージェントにとっての最上位の指示となる。
  • BDDは「システムがどう振る舞うべきか」を定義する。Gherkin等で記述されたシナリオがエンドツーエンドの品質ゲートとなる。
  • TDDは「個々のユニットが正しく動くか」を保証する。コードレベルの設計品質を高めるループとして機能し続ける。

SDDのもとでは、AI がTDDのテストコードやBDDのシナリオ自体も仕様から生成する可能性がある。実際にKiroはユーザーストーリーの受け入れ基準からテストを自動生成する機能を備えている。これは「テストを書く行為」がエンジニアの手から離れることを意味するが、テストの意図を定義する行為──すなわち仕様記述──は依然として人間の責務である。

導入企業の実践パターンと組織的変化

SDDの導入は技術的なワークフロー変更にとどまらず、チーム構造と役割定義にも影響を及ぼす。

EPAMが実施したブラウンフィールド（既存コードベース）へのSpec Kit適用検証では、構造化された作業の約80%がAIによって自動処理された一方、残りの20%にはトレードオフの判断・ドメインコンテキストの理解・プロジェクト固有の意思決定という人間の関与が不可欠であった。この「80/20」は、SDDにおけるシニアエンジニアの役割を端的に示している。

McKinseyが2025年後半に約300社の上場企業を対象に実施した調査では、70%の企業がAIツールの進化に対して役割定義を変更していないことが明らかになった。組織構造の変革が技術導入に追いついていない現実がある。先進的な企業では、従来の8〜10人チーム・2週間スプリント・四半期計画というモデルから、3〜5人の「ワンピザ・ポッド」が継続的に計画し、エンジニアがAIエージェントをオーケストレーションするモデルへの移行が始まっている。

ThoughtWorksは2025年12月のブログ記事で、SDDには「重厚な事前仕様策定とビッグバンリリースという伝統的なアンチパターンへの回帰リスク」があると警鐘を鳴らしている。仕様の粒度設計──大きすぎればウォーターフォール回帰、小さすぎれば管理コスト増大──が実践上の最大の論点である。

SDDの課題と今後の展望

SDDは万能薬ではない。ThoughtWorks Technology Radar Vol.33（2025年11月）は同手法を「Assess（評価段階）」に分類し、現行のワークフローが「elaborate and opinionated（入念だが独断的）」であると指摘した。手作りの詳細なルールでAIを制御するアプローチは、究極的にはスケールしない可能性があるという懸念も示されている。

技術的な課題も残る。仕様と実装の乖離を検知する仕組み（ドリフト検出）、仕様のバージョニングとマイグレーション、そして大規模コードベースにおける仕様間の依存関係管理は、いずれも未成熟な領域である。

とはいえ、AIコーディングアシスタントの能力が向上するほど「何を作るか」の精度が「どう書くか」の精度より重要になるという構造的トレンドは不可逆である。SDDは、Vibe Coding（雰囲気でAIにコードを書かせるスタイル）の対極に位置する規律あるアプローチとして、特にエンタープライズ領域での採用が進むと考えられる。

2026年以降、仕様記述そのものをAIが支援する「メタSDD」──要件の曖昧さを検出し、仕様の完全性を検証するエージェント──の登場も予想される。仕様の品質がソフトウェアの品質を決定する時代において、エンジニアに求められるスキルセットは「コードを書く力」から「意図を構造化する力」へと確実にシフトしていく。

FAQ

SDDはウォーターフォール開発への回帰ではないのか？

SDDの仕様は反復的に更新される「生きたドキュメント」であり、一度書いたら変更しないウォーターフォールの要件定義書とは本質的に異なる。ただし、仕様の粒度設計を誤ると重厚な事前設計に陥るリスクがあるため、ThoughtWorksも注意を促している。

SDDを導入するとエンジニアの仕事はなくなるのか？

EPAMの検証では構造化作業の約80%がAIで自動化されたが、トレードオフ判断やドメインコンテキストの理解など残り20%は人間が不可欠であった。SDDはエンジニアの役割を「コードを書く人」から「仕様を設計しAIをオーケストレーションする人」へと変化させるものである。

TDDやBDDを実践しているチームでもSDDは導入できるか？

SDDはTDD・BDDの上位レイヤーとして機能する。SDDが「何を・なぜ」を定義し、BDDが振る舞いを検証し、TDDがユニットレベルの正確性を担保する。既存のテスト文化を活かしながら段階的に導入可能である。

GitHub Spec KitとAmazon Kiro、どちらを選ぶべきか？

Spec KitはCLIベースのオープンソースで既存のAIエージェントと組み合わせて使える軽量なアプローチ。Kiroは仕様から実装まで一気通貫のIDE体験を提供する。チームの既存ツールチェーンとの親和性、およびベンダーロックインの許容度で判断するのが妥当である。

参考文献