仕様駆動開発（SDD）とは？主要ツール比較｜Kiro・GitHub Spec Kit・Tessl【2026年版】

仕様駆動開発（SDD／Spec-Driven Development）とは、コードを書く前に「仕様（spec）」を先に記述し、その仕様を人間とAIが共有する唯一の正（source of truth）として開発を進める手法だ。行き当たりばったりにコードを生成する「バイブコーディング」を、構造化された仕様で制御することが狙いである。

AIコーディングが当たり前になった一方で、「動くには動くが仕様が誰の頭にも残っていない」「規模が大きくなると破綻する」という悩みが増えてきた。SDDは、この悩みに「まず仕様を書き、その仕様からAIに実装させる」という順序を持ち込む考え方だ。

本記事では、仕様駆動開発とは何かという定義から、仕様の"寿命"で分かれる3つの成熟度レベル、そして主要ツールのGitHub Spec Kit・AWS Kiro・Tesslの工程・生成物・料金・成熟度までを、公開一次情報にもとづいて中立に比較する。

本記事は特定のSDDツール・製品を勝たせず中立に整理し、特定ツールや当社サービスへの送客は一切しない。当社（YDAIコンサルティング株式会社 AI編集部）は複数事業でAI開発の実務に携わる立場だが、各ツールには強みと制約（弱点）を同粒度で併記する。料金・バージョン・提供状況は変動が速いため、本記事の数値・日付は2026年7月18日時点の各社公開一次情報にもとづく。

仕様駆動開発（SDD）は、コードより先に「仕様（spec）」を書き、それを人間とAIの唯一の正として実装を進める手法だ。2026年時点の主要ツールは、OSSでエージェント中立のGitHub Spec Kit、要件→設計→タスクを統合IDEでこなすAWS Kiro（2026年5月7日にGA・出典: kiro.dev・参照2026-07-18）、spec-as-sourceを狙うが本体はベータのTesslの3系統だ。仕様の"寿命"の考え方（spec-first／spec-anchored／spec-as-source）で成熟度レベルが分かれる。いずれも発展途上で料金・提供状況・仕様が流動的なため、小さく試して自社の規模とチーム環境で見極めるのが安全だ。

仕様駆動開発（SDD）とは

SDDは「AIに何を作らせるか」を曖昧なプロンプトではなく、レビュー可能な仕様として固定してから実装に進む点に本質がある。まず定義を押さえ、従来開発との違い、注目される背景の順に見ていく。

仕様駆動開発（SDD）の定義

仕様駆動開発（SDD）とは、コードより先に仕様（spec）を書き、その仕様を「documentation first」の発想で開発の中心に据える手法だ。仕様は人間どうしの合意事項であると同時に、AIエージェントが実装を生成するための指示書にもなる。従来の「まず動くコードを書く」から「まず合意された仕様を書く」へと重心が移るのが最大の特徴である。

マーティン・ファウラーのサイトでSDDを解説するBirgitta Böckelerは、仕様を主たる作業対象に置き、AIとの協働の基点にする開発スタイルとしてSDDを整理している（出典: Martin Fowler）。要点を一言でいえば、SDDの核心はプロンプトの積み重ねではなく、人間がレビューできる仕様を介してAIに実装させることにある。

バイブコーディング・従来開発との違い（用語早見表）

SDDの位置づけは、従来開発とバイブコーディングと並べると見通しがよい。鍵は「仕様が最終的に何として残り、何をレビューするか」だ。

開発スタイル	仕様の扱い	AIの役割	主なレビュー対象	向く場面
従来開発	仕様書は別管理・実装と乖離しがち	補完など補助	人が書いたコード	中〜大規模
バイブコーディング	仕様は残さず生成コードを直接手直し	コード生成の主体	生成されたコード	小規模・試作
仕様駆動開発（SDD）	仕様が唯一の正・修正の起点	仕様から実装を生成	仕様（spec）そのもの	チーム開発・継続保守

バイブコーディングは素早い試作に向くが、仕様が残らないため後から「なぜこう作ったのか」を追えない。SDDは仕様をレビュー・修正の対象に置くことで、変更を仕様の書き換えから始められる。この違いが、規模が大きくなるほど効いてくる。

なぜ2026年に注目されるのか（背景）

背景には、AIコーディングの普及でLLMの非決定性（同じ指示でも出力がぶれる性質）や、大規模開発での破綻が現場で顕在化したことがある。個別のプロンプトを積み上げる進め方では全体の整合を人間が把握しきれず、「仕様で制御する」という発想が求められた。

ツール側の動きも速い。GitHubがOSSのSpec Kitを公開し、AWSがSDD特化IDEのKiroを2026年5月7日にGA（一般提供開始）とし（出典: kiro.dev・参照2026-07-18）、Claude CodeやCursor、Google Antigravityなども仕様を軸にしたフローを相次いで取り込んだ。結果としてSDDは、2026年のコーディング主要トレンドの一つに位置づけられている。

SDDの3つの成熟度レベル（spec-first / spec-anchored / spec-as-source）

SDDは一枚岩ではなく、仕様をどこまで「生かし続けるか」で3つのレベルに分けて理解すると整理しやすい。仕様の"寿命"が伸びるほど踏み込んだSDDになるが、その分だけ運用の負荷やリスクも増える（出典: Martin Fowler）。

spec-first：仕様を先に書き、実装後は破棄する

最も軽量なレベルで、初期の足場として仕様を書き、機能を実装したあとは仕様を保守しない。手早く始められるのが長所だが、実装が進むほど仕様と現実のコードが乖離しやすいのが弱点だ。後述するKiroの基本フローは、この spec-first に近い使い方になりやすい。

spec-anchored：仕様を保守フェーズまで維持する

仕様を継続的に更新し、変更はまず仕様の修正から始める中間レベルだ。GitHub Spec Kitが志向する形で、constitution（原則）と反復サイクルで仕様を生かし続ける。ただしBöckelerは、実運用ではブランチ単位で spec-first 寄りに戻りやすいと中立に観察している（出典: Martin Fowler）。

spec-as-source：仕様が一次成果物・生成コードは編集しない

最も踏み込んだレベルで、仕様が主たる成果物となり、生成されたコードは「DO NOT EDIT（編集禁止）」として扱う。仕様とコードの対応関係を持たせ、コードから仕様への逆生成も探索する。Tesslが明示的に狙う地点だが、かつてのモデル駆動開発（MDD）が抱えた「抽象仕様と実装のギャップ」という歴史的な失敗を繰り返すリスクも指摘されている（出典: Martin Fowler）。理想は高いが、現時点では実験的な段階にある。

主要SDDツール比較（Kiro・GitHub Spec Kit・Tessl）

ここでは公開一次情報を横断集計した独自比較表で全体像を示し、続けて各ツールを個別に整理する。中立に一覧化し、勝者は作らない。

独自比較表：Kiro・GitHub Spec Kit・Tessl（＋補助BMAD）

ツール	提供元	提供形態・ライセンス	ワークフロー工程	主な生成物	対応エージェント	SDD成熟度	料金（2026-07-18時点）
GitHub Spec Kit	GitHub	OSS・MIT	Constitution→Specify→Plan→Tasks→Implement（＋clarify/analyze等）	constitution・spec・plan・tasks の各markdown	30以上（Claude Code/Copilot/Gemini/Cursor等）に中立対応	spec-anchored志向	無料（OSS）
AWS Kiro	AWS	商用IDE（GA済み）	要件→設計→タスクの3段（vibe/specモード併用）	requirements・design・tasks の各markdown	Kiro IDE内蔵のエージェント	spec-first基本	Free 50クレジット／Pro 月20ドル〜（クレジット制）
Tessl	Tessl	フレームワーク本体はベータ（招待制）	仕様↔コードの双方向同期を志向	仕様（一次成果物）・生成コードはDO NOT EDIT	自社プラットフォーム	spec-as-source志向	ベータ（一般提供前）
BMAD-METHOD（補助）	OSSコミュニティ	OSS	アジャイル的エージェント手法（PRD→設計→ストーリー）	PRD・設計文書・ストーリー	各種エージェント	spec-first〜anchored	無料（OSS）

各セルの根拠は記事末の出典に集約している。

GitHub Spec Kit：OSS・エージェント中立のCLIツール

GitHub Spec KitはMITライセンスのOSSで、specify CLIで導入する。Constitution（原則）を起点に、Specify（仕様化）→Plan（設計）→Tasks（分解）→Implement（実装）へ進み、clarify・analyze・checklist などの補助コマンドも備える。Claude Code・GitHub Copilot・Gemini・Cursorなど30以上のエージェントに中立対応する点が強みだ（出典: github/spec-kit・参照2026-07-18）。

更新は非常に活発で、2026年7月時点で v0.13 系までリリースが進んでいる。一方の弱点は、生成されるmarkdownが多くレビュー負荷が高いこと、そして運用が spec-first 寄りに流れやすいことだ。

AWS Kiro：要件→設計→タスクの3段IDE

KiroはAWS発の仕様駆動特化IDEで、2026年5月7日にGAとなった。仕様は要件（requirements）→設計（design）→タスク（tasks）の3段で構成し、素早く作るvibeモードと仕様を固めるspecモードを併用できる。AWSはKiroをAmazon Q Developerの後継と位置づけており、Amazon Q DeveloperのIDEプラグインと有料サブスクリプションは2027年4月30日にサポート終了が予定されている（出典: AWS公式・参照2026-07-18）。

料金はクレジット制で、2026年7月18日時点では次の体系だ（出典: kiro.dev/pricing・参照2026-07-18）。超過分は1クレジットあたり0.04ドルで追加できる。

プラン	月額	クレジット/月
Free	0ドル	50
Pro	20ドル	1,000
Pro+	40ドル	2,000
Pro Max	100ドル	5,000
Power	200ドル	10,000

弱点は、小規模なタスクでは3段の工程が冗長になりやすいこと、クレジットを消費すること、そしてIDEへの依存が生じることだ。

Tessl：spec-as-source志向、ただし2026年時点はベータ

Tesslは spec-as-source を明示的に狙うフレームワークとレジストリで、生成コードはDO NOT EDIT、仕様とコードの対応を持たせる思想を掲げる（出典: Martin Fowler・参照2026-07-18）。ただし2026年7月時点でフレームワーク本体はGA未達で、招待・ベータの状態が続いている。

同社はその後、agent skills（エージェント向けスキル）のレジストリとパッケージ管理へ軸足を移し、スキルのライフサイクルを管理するプラットフォームを標榜している（出典: tessl.io）。SDDの理想形として注目に値する一方、フレームワーク本体がまだ一般提供前である事実は、導入検討時に必ず踏まえておきたい。

SDDツールの選び方の目安（中立）

どれか一つを「勝たせる」のではなく、各社の設計思想と提供状況に応じて選ぶのが現実的だ。既存のClaude Code・Copilot・CursorなどにSDDを載せ、まずOSSで始めたいならGitHub Spec Kitが素直だ。要件→設計→タスクを統合IDEで一気通貫させたいならAWS Kiroが噛み合う。

仕様を長期の一次成果物にする実験に踏み込みたいならTesslが方向性として近いが、本体はベータ前提で選ぶ必要がある。アジャイル的なエージェント手法をOSSで試すなら、補助としてBMAD-METHODも候補になる。コーディングツール全体の中でSDDをどう位置づけるかはコーディングツール比較の全体像も、実装エージェントの運用作法はClaude Code活用のベストプラクティスもあわせて参照すると判断しやすい。

導入前に知っておくべき制約・批判的視点

SDDは銀の弾丸ではない。ツールの優劣ではなく、SDDという進め方そのものに内在する論点として、少なくとも次の4点は中立に押さえておきたい。

第一に、生成されるmarkdownのレビュー負荷だ。仕様・設計・タスクが自動生成される分、人間がそれを読んで合意する工数は残る。第二に、LLMの非決定性で、同じ仕様でも生成結果はぶれる。第三に、モデル駆動開発（MDD）が過去に抱えた「抽象仕様と実装の乖離」という歴史的な失敗を、spec-as-source が再来させるリスクだ（出典: Martin Fowler）。

第四に、ツール自体が発展途上で、料金・提供状況・仕様が流動的な点である。Kiroはクレジット制、Tesslはベータ、Spec Kitは高頻度更新と、いずれも短期間で条件が変わりうる。エージェント同士の役割分担を設計する視点はマルチエージェント設計パターン、主要コーディングエージェントの比較はClaude CodeとCodexの比較も参考になる。導入は小さく試し、自社の規模とチーム環境で見極めるのが安全だ。

まとめ

仕様駆動開発（SDD）とは、コードより先に仕様を書き、その仕様を人間とAIが共有する唯一の正として実装を進める手法だ。仕様の"寿命"で spec-first・spec-anchored・spec-as-source の3レベルに分かれ、2026年時点の主要ツールはOSS中立のGitHub Spec Kit、統合IDEのAWS Kiro（2026年5月7日GA）、spec-as-source志向だが本体はベータのTesslの3系統である。いずれも強みと制約を併せ持ち、料金・提供状況・仕様は流動的だ。どのツールが自社に合うかは規模とチーム環境しだいで変わるため、まずは小さく試し、仕様をレビューできる体制を作ることから始めたい（本記事は2026年7月18日時点の各社公開一次情報にもとづく）。

---

コーディングツール全体の中でのSDDの位置づけはコーディングツール比較の全体像、実装エージェントの運用はClaude Code活用のベストプラクティス、主要エージェントの比較はClaude CodeとCodexの比較、複数エージェントの分担設計はマルチエージェント設計パターンもあわせてどうぞ。