仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】

「AIにコードを書かせたら、思っていたものと違う実装が返ってきた」。原因の1つは、何を作るかの合意が曖昧なまま実装を始めることです。これを防ぐ進め方が仕様駆動開発（Spec-Driven Development／SDD）です。本記事では、SDDの意味と従来手法（ウォーターフォール・アジャイル・TDD）やAI駆動開発との違い、spec-firstからspec-as-sourceまでの3つの段階、「やめたほうがいい」と言われる理由を整理し、GitHub Spec Kit 1.2系で実際に仕様を生成した結果と、EARS記法の仕様テンプレートまでを2026年10月時点の公式情報でまとめます。ツール同士の違いは仕様駆動開発ツール比較（Spec Kit・Kiro・cc-sdd・OpenSpec）で扱っています。

まとめ：仕様駆動開発の要点と2026年10月時点で最初に試す1本

• 仕様駆動開発（SDD）は、コードより先に「何を・なぜ作るか」を仕様として書き、その仕様からAIや人が計画・タスク・実装を導く開発手法。英語はSpec-Driven Development。
• TDDが「動作の正しさ」を先に固めるのに対し、SDDは「要件」を先に固める。両者は併用できる。
• 到達度は3段階。仕様を先に書くだけのspec-first、機能の保守まで仕様を残すspec-anchored、人は仕様だけを編集するspec-as-source。Böckeler氏の2025年の検証では、KiroとSpec Kitは主にspec-firstと評価されています。
• 主要ツールは2026年10月時点でGitHub Spec Kitが1.2系、OpenSpecが1.14系、cc-sddが3.1系。AWSのKiroはIDEとして仕様の3ファイルを生成する。
• 向くのは画面やAPIをまたぐ新機能と、後から他人が読む変更。小さなバグ修正に被せると仕様が膨らみ、レビューの手間が実装を上回る。

結論として、次に着手する中規模の機能1本だけをSpec Kitなど無料のツールでSDDの流れに乗せ、生成された仕様の「前提（Assumptions）」を人が読んで直す時間と、手戻りの減り方を測ってから、チームへ広げるかを決めるのが確実です。

仕様駆動開発（SDD）の定義と「先に仕様、後にコード」が意味すること

Spec-Driven Developmentの意味と略語SDDが指す別の言葉

仕様駆動開発とは、コードを書く前に「何を・なぜ作るのか」を仕様として明文化し、その仕様を起点に設計・実装・テストを進める開発手法です。英語ではSpec-Driven Development、略してSDDと呼ばれ、「仕様書駆動開発」「スペック駆動開発」もほぼ同じ意味で使われます。

GitHubはSpec Kitのspec-driven.mdで、SDDを「どう作るかの前に、何を・なぜ作るかを定義する」進め方とし、要件を仕様・技術計画・タスクへ変換してから実装を導く流れとして整理しています。

なお「SDD」という略語は、ソフトウェア設計書を指すIEEE 1016のSoftware Design Descriptions（IEEE 1016-2009）でも使われます。設計書の書式を探しているなら、本記事のSDDとは別物です。

仕様を単一の真実のソースとして扱い開発中も更新し続ける運用の条件

仕様を長期に保守するSDDの運用では、開発の進行に合わせて仕様書を更新し続け、プロジェクトの「単一の真実のソース（Single Source of Truth）」として扱います。疑問が生じたらコードではなく仕様に立ち返るため、認識合わせと軌道修正がしやすくなります。

ここでいう仕様は、発注時の要件定義書と内容が重なることもあります。違いは使い方で、SDDの仕様は機能単位で小さく切り、リポジトリの中にMarkdownで置き、コードと同じプルリクエストで更新しながら実装と検証の基準に使います。文書ごとの区別は仕様書とは？設計書・要件定義書との違いで整理しています。

仕様に書く3つの層：要件・技術計画・タスクに分けて記述する内容

主要ツールの成果物を並べると、SDDの仕様は3層に分かれます。1層目は誰が何のために使うかと受け入れ基準を書く「要件」、2層目はアーキテクチャやデータ構造を決める「技術計画（設計）」、3層目は実装単位に割った「タスク」です。AWSのKiroはこれをrequirements.md・design.md・tasks.mdの3ファイルとして生成し、バグ修正ではbugfix.mdに現在の挙動・期待する挙動・変えてはいけない挙動を書きます（Kiro Docs：Specs）。Spec Kitでは同じ3層がspec.md・plan.md・tasks.mdになります。

spec-first・spec-anchored・spec-as-sourceで見る仕様駆動開発の3つの段階

「SDDを導入した」と言っても、仕様をどこまで長く使うかでチームの運用は大きく変わります。ThoughtworksのBirgitta Böckeler氏はmartinfowler.comの記事（2025年10月15日）で、SDDを名乗るツールを試したうえで実装の段階を次の3つに分けています。

同記事は、見つかったSDDの定義とツールはすべてspec-firstで、spec-anchoredやspec-as-sourceまで目指すものは一部だと書いています。Spec Kitについても、同氏が2025年9月に試した版では仕様が変更要求単位で作られるため、spec-firstだと評価しています。表のTessl Frameworkは当時のベータ版で、Tesslの現在の製品構成はTesslとは？AIエージェントのスキル管理基盤の使い方・料金で扱っています。

実務では、まずspec-firstで回し、価値が出た機能だけ仕様を残してspec-anchoredに移すのが現実的です。spec-as-sourceは、自然言語の仕様からコードを毎回生成し直す前提なので、生成結果が実行のたびに揺れるLLMでは検証の負担が大きくなります。同記事は、かつてUMLなどのモデルからコードを生成したモデル駆動開発（MDD）が普及しなかった経緯を引き、同じ道をたどらないかという問いを投げています。

ウォーターフォール・アジャイル・TDD・AI駆動開発と仕様駆動開発の違い

SDDは既存の開発手法を置き換えるものではなく、「何を起点に置くか」が異なるアプローチです。

TDDと仕様駆動開発の比較：テストと仕様という起点の違い

TDDが「入力Xなら結果Yになる」という動作を先に固めるのに対し、SDDは「そもそも何を満たすべきか」という要件と設計を先に固めます。SDDで受け入れ基準を決め、その基準をTDDのテストに落とす組み合わせが自然で、cc-sddの/kiro-implもタスクごとにRED→GREENのTDDで実装を進めます（gotalab/cc-sdd README）。テスト先行の回し方はTDD（テスト駆動開発）のRed・Green・Refactorの回し方、Given-When-Thenで振る舞いを書く方法はBDD（振る舞い駆動開発）の仕組みとTDDとの違いで扱っています。

AI駆動開発・バイブコーディングとの比較：仕様の位置づけ

AI駆動開発は、AIを開発工程に組み込むこと全般を指す広い言葉です。本記事で扱うAI支援型のSDDは、AIに渡す判断基準を「仕様」に置く進め方です。対極にあるのが、指示と結果の手応えだけで進めるバイブコーディング（vibe coding）で、正本は会話とその場のコードになります。AWSが工程全体をAI前提で組み直したAI-DLC（AI駆動開発ライフサイクル）は、SDDより広い開発プロセス全体の枠組みで、要件を先に固める発想は共通です。

使い分けは単純です。捨てる前提の試作はバイブコーディングで速く作り、残すと決めた機能はSDDに切り替えて仕様を書き起こします。

アジャイルとの併用：スプリント単位の仕様分割

アジャイルとの併用では、ストーリーポイントの大きい機能だけスプリント前に仕様を切ると、反復の速さを落とさずに済みます。設計判断を長文で残す文化があるチームなら、デザインドック（Design Doc）の書き方と役割を分け、設計の「なぜ」はデザインドック、機能単位の受け入れ基準はSDDの仕様に置くと重複を避けられます。

生成AIのコーディング支援で仕様駆動開発が再注目された背景

「仕様を先に書く」考え方自体は新しいものではありません。2025年以降に再注目されたのは、AIコーディングエージェントが実装の大半を書けるようになったからです。AIに「ログイン機能を作って」とだけ伝えると、パスワードのハッシュ化やロックアウトが抜けることがあります。「メールアドレスとパスワードで認証し、失敗時は401を返し、パスワードはハッシュ化して保存する」と仕様で渡せば、AIはその条件に沿って実装し、レビューする人もその条件で合否を判断できます。

ツールもこの流れで揃いました。GitHubは2025年9月2日に公式ブログでSpec Kitを発表し、同じ2025年にAWSは仕様駆動のAI IDEとしてKiroを公開しました。GitHubのブログは人の役割を「舵取りだけでなく検証すること。各段階で振り返り、磨き込む」と書いており、SDDはレビューを前提にした進め方です。エージェントの仕組みそのものはコーディングエージェントの仕組みと主要ツールで解説しています。

仕様駆動開発の進め方：仕様定義から実装・照合までの5工程と確認点

ツールによって呼び方は異なりますが、流れは共通しています。

1. 仕様定義（要件）：誰が・何のために使うのか、機能・非機能要件と受け入れ基準を書く。
2. 設計・計画：アーキテクチャ・技術選定・データ構造を決める。
3. タスク分解：実装単位に分け、完了条件と依存関係を整理する。
4. 実装：仕様を参照しながらコーディングする。AIには仕様を指示として渡す。
5. 照合・更新：仕様と実装を突き合わせ、変更があれば仕様も更新する。

要件定義・タスク分解・実装の終わりに置く人間のチェックポイント3か所

最低限押さえるのは、要件を書き終えた時点（作るものが合っているか）、タスクに割った時点（漏れと順序が正しいか）、実装後（どの受け入れ基準を満たしたか）の3か所です。Kiroはタスクの依存関係を解析し、互いに依存しないタスクを並行して実行するため、タスク分解の質がそのまま実装時間に効きます（Kiro Docs：Specs）。逆に各段階の承認を省いて一気に3ファイルを作るQuick Specもあり、公式は「よく理解している機能」と「レビューより速さを優先する試作」を、特に適した用途として挙げています。

Spec Kitで仕様駆動開発を試す手順と実際に生成された仕様

Spec Kitの導入条件とuvによるプロジェクト初期化

GitHub Spec Kitは、2026年10月時点で1.2系（v1.2.2、2026年10月19日公開）が最新です。数日おきに版が上がるので、導入時はSpec Kitのリリース一覧で確認してください。前提はPython 3.11以上、パッケージマネージャーのuv、対応するAIコーディングエージェントで、Linux・macOS・Windowsで動きます（GitHub spec-kit README）。

# PyPIのspecify-cliを入れる
uv tool install specify-cli
# 版を固定するなら上の行の代わりに次を実行する（v1.2.2の例）
# uv tool install specify-cli --from git+https://github.com/github/[email protected]

# Claude Code 向けにプロジェクトを作る
specify init my-project --integration claude
cd my-project

2026年10月22日にv1.2.2をmacOSで実行すると、specify init demo --integration claudeは30ファイルを作り、その内訳は.claude/skills/のスキル10本（speckit-constitution・specify・plan・tasks・implement・convergeと、補助のclarify・analyze・checklist・taskstoissues）と、.specify/のテンプレート・スクリプトでした。注意点は、--integrationを付けずに非対話で実行するとGitHub Copilot向け（.github/skills/）になることです。CLIのヘルプにも「非対話ではCopilotを既定にする」と書かれています。

Spec Kitの基本工程：constitutionからconvergeまでの6スキル

プロジェクトのディレクトリでエージェントを起動し、チャット欄で/speckit-*のスキルを1つずつ呼びます。ターミナルのコマンドではありません。原則（constitution）はプロジェクトに1回、機能ごとにspecify→plan→tasks→implement→convergeを回します。

/speckit-constitution テストを必ず書く。外部ライブラリの追加は事前に相談する。
/speckit-specify 社内の備品貸出を記録するWebアプリ。社員は備品を借りて返す。返却期限を過ぎた貸出は管理者が一覧で確認できる。
/speckit-plan Next.js と PostgreSQL を使う。認証は社内のSSOに合わせる。
/speckit-tasks
/speckit-implement
/speckit-converge

READMEは、/speckit-convergeが「Converged」を返すまでimplementとconvergeを繰り返す手順です。convergeのスキル定義には「APPEND-ONLY, NEVER REWRITE」とあり、コードを見て未実装の作業をtasks.mdへ追記するだけで、アプリのコードは変更しません。コマンドごとの出力ファイルはSpec Kit（GitHub）の使い方・インストール・コマンド解説で詳しく扱っています。

3文の依頼から生成された仕様：要件17件と自動で置かれた前提8項目

constitutionは未設定のまま、上の/speckit-specifyの1行（備品貸出アプリの3文）を、Claude Code 2.1.302（モデルはSonnet）で1回実行しました。生成されたspec.mdは137行で、中身は次のとおりです。

読みどころは最後の2行です。依頼に無かった「備品の登録・管理」がストーリーに加わり、「返却期限に上限を設けない」「期限超過の自動通知は対象外」といった業務上の判断が、質問されないまま前提として書かれました。speckit-specifyのスキル定義は確認の目印（NEEDS CLARIFICATION）を最大3個に制限し、それ以外は妥当な既定値で埋めるよう指示しています。今回は0個でした。

つまりSDDで人が最初にレビューすべき箇所は、機能要件の一覧よりもAssumptionsの節です。ここを読まずに/speckit-planへ進むと、AIが置いた前提がそのまま実装の根拠になります。前提に異論があれば、/speckit-clarifyで質問を出させて仕様に戻します。生成結果はモデルと実行のたびに変わるため、上の数は1回分の記録です。

EARS記法で書く仕様書テンプレートとrequirements.md・tasks.mdの例

受け入れ基準をWHEN／SHALLの1文で書くEARS記法の具体例

受け入れ基準の書き方はツールで異なります。Spec Kitは上の実測のとおりGiven-When-Then形式の受け入れシナリオを書き、それとは別に番号付き機能要件（FR）と測定可能な成功基準（SC）を記載します。Kiroはrequirements.mdにEARS（Easy Approach to Requirements Syntax）記法を採用し、各要件を「WHEN［条件・イベント］ THE SYSTEM SHALL［期待する振る舞い］」の形で書きます（Kiro Docs：Feature Specs）。条件と振る舞いが1対1になるため、テストケースへそのまま落とせます。ログイン機能の例をこの形で書くと次のとおりです。

# 機能：パスワードログイン

## ユーザーストーリー
登録済みのユーザーとして、メールアドレスとパスワードでログインしたい。

## 受け入れ基準（EARS）
1. WHEN 正しいメールアドレスとパスワードが送信された
   THE SYSTEM SHALL セッションを発行してダッシュボードへ遷移させる
2. WHEN パスワードが一致しない
   THE SYSTEM SHALL HTTP 401 を返し、メールアドレスとパスワードのどちらが誤りかは表示しない
3. WHEN 同じアカウントで5回連続して認証に失敗した
   THE SYSTEM SHALL そのアカウントのログインを15分間拒否する
4. THE SYSTEM SHALL パスワードを平文で保存せず、ハッシュ化して保存する

## 対象外
- ソーシャルログイン
- パスワード再設定（別の仕様で扱う）

「対象外」を書くと、AIが頼んでいない機能まで作り込むのを防げます。上の実測でAIが自分から足した「備品の登録・管理」のような追加は、この節で止めます。EARSの5つの基本型はEARS記法の読み方と5つの基本型の書き方で日本語の例文つきで解説しています。

タスクと受け入れ基準の対応づけ：要件番号の記載例

タスク側では、各タスクがどの受け入れ基準を満たすためのものかを番号で結びます。要件番号の無いタスクは、仕様にない作業が紛れ込んでいるサインとしてレビューで止めます。

## タスク
- [ ] 1. users テーブルに password_hash 列と failed_count 列、locked_until 列を追加する（要件 3, 4）
- [ ] 2. 連続失敗とロックのテストを先に書く（要件 3）
- [ ] 3. POST /login を実装し、失敗時は 401 を返す（要件 1, 2）
- [ ] 4. 5回連続失敗で locked_until を15分後に設定し、ロック中の認証を拒否する。期限後は再試行を許可する（要件 3）
- [ ] 5. 認証成功時にセッションを発行し、ダッシュボードへ遷移させる（要件 1）
- [ ] 6. パスワードをハッシュ化して保存し、平文が保存されないことをテストする（要件 4）
- [ ] 7. 認証失敗時の応答がメールアドレスの登録有無を明かさないことをテストする（要件 2）

Kiroには要件から入るRequirements-Firstと、設計から入るDesign-Firstの2つの進め方があり、既存システムの制約が強い改修では後者が合います。KiroとCursor・GitHub Copilotの役割の違いはKiroとCursor・GitHub Copilotの違い、Kiro自体の料金と使い方はKiroとは？仕様駆動AI IDEの特徴・料金・使い方を参照してください。

Steering・constitutionによるプロジェクト共通前提の管理

機能ごとの仕様とは別に、どの機能にも共通する前提（製品の目的・技術スタック・ディレクトリ構成・守るべき原則）を1か所に置く仕組みが各ツールにあります。ここが空だと、機能の仕様を書くたびに同じ前提をAIが推測で埋めます。上の実測でも、Spec Kitのエージェントは「constitutionがプレースホルダのままなので制約として参照していない」と報告しました。

KiroのSteeringのドキュメントは、product.mdに製品の目的と対象ユーザー、tech.mdにフレームワークと技術的制約、structure.mdにファイル構成と命名規則を書くとし、ホームディレクトリの~/.kiro/steering/に置くとすべてのワークスペースに効き、ワークスペース側の指示と矛盾したらワークスペース側を優先すると定めています。KiroはAGENTS.mdも読みます。既存のリポジトリにSDDを入れるときは、機能の仕様より先にこの前提ファイルを作ってください。

OpenSpec・cc-sddで既存リポジトリに仕様駆動開発を足すコマンド

OpenSpecの仕様管理：既存コードへの変更提案と差分

OpenSpecは、既存のコードに対する「変更提案」単位で仕様を管理する軽量なツールで、2026年10月時点の最新は1.14系（v1.14.3、2026年10月17日公開）です。Node.js 20.19.0以上が必要です（Fission-AI/OpenSpec README）。

# OpenSpec を入れてリポジトリを初期化する
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

# 以降はエージェントのチャットで実行する
/opsx:explore
/opsx:propose add-dark-mode
/opsx:apply
/opsx:archive

何を作るか決まっていない段階では/opsx:explore、決まっていれば/opsx:proposeから始めます。CursorやGitHub Copilotでは/opsx-proposeのように記法が変わり、openspec initが使うツールに合わせた書き方を表示します。詳しくはOpenSpecとは？使い方・インストール・/opsxコマンドにまとめています。

cc-sddの導入：Claude Code・Codexで使うKiro流の工程

cc-sddは、Kiroと同じ仕様書の流れをClaude CodeやCodexなどへ持ち込むコミュニティ製のツールで、最新は3.1系（v3.1.0、2026年9月23日公開）です。8つのエージェントに同じ17本のスキルを入れ、Claude CodeとCodexが安定版、Cursor・GitHub Copilotなどはベータ扱いです（gotalab/cc-sdd README）。日本語の仕様書を出力できます。

# Claude Code 向けに日本語で導入する（Codex なら --codex-skills）
npx cc-sdd@latest --claude-skills --lang ja

# エージェントのチャットで新機能を仕様から実装まで進める
/kiro-discovery 写真アルバムのアップロード・タグ付け・共有
/kiro-spec-init photo-albums
/kiro-spec-requirements photo-albums
/kiro-spec-design photo-albums
/kiro-spec-tasks photo-albums
/kiro-impl photo-albums

cc-sddのREADMEは、仕様を「エージェントへの命令書ではなく、システムの部品同士の契約」と位置づけ、正本はあくまでコードだと明言しています。仕様を正本にするSpec Kitの説明とは立場が違います。ただし、コードを正本とすることだけでは、仕様を保守し続けるspec-anchoredかどうかは判断できません。MCPサーバーとして承認フローを足す方式はspec-workflow-mcpの導入と使い方、仕様とコードのずれをAIに検知させる発展形は整合性駆動開発（CoDD）で扱っています。

仕様駆動開発のメリット・デメリットと採用する案件・見送る案件

手戻り削減・認識統一・保守性という3つのメリット

最初に確認したい利点は、業務上の前提を実装前に人が直せることです。例えば今回のSpec Kitの生成仕様では、貸出期限に上限を設けないという前提を計画前にレビューできます。2つ目は、仕様という共通言語でチームの認識がそろい、新メンバーが機能の意図を仕様から読めることです。3つ目は、仕様・設計・タスクが記録として残り、引き継ぎに使えることです。AIと組み合わせる場合は、仕様がそのままAIへの指示書になり、同じ機能を別のエージェントに頼んでも結果がぶれにくくなります。

着手の遅れ・更新の手間・レビュー量という3つのデメリット

デメリットは、仕様を書くぶん着手が遅れること、仕様を最新に保つ手間がかかること、そしてAIが生成する仕様の量が多くレビューが追いつかないことです。今回のSpec Kitの実測でも、3文の依頼から137行の仕様が生成されました。生成する速さだけでなく、人が確認する時間も導入コストに含めてください。

仕様駆動開発を採用すべき条件と見送るべき場面の判断表

見落とされがちなのは最後の条件です。レビューされない仕様はAIが書いたもっともらしい文書にすぎず、手戻りはむしろ増えます。AIエージェントに実装を任せる前提で要件の言語化から進めたい場合は、一創の生成AI開発・AI受託開発で、仕様の作成から実装・レビュー体制づくりまでご相談いただけます。

「仕様駆動開発はやめたほうがいい」と言われる理由と見送りの線引き

SDDへの批判は、手法そのものより「AIが仕様を書くと重くなりすぎる」点に集中しています。根拠として引かれる一次情報は次の2つです。

• Böckeler氏の検証記事では、Kiroに小さなバグの修正を頼むと、要件文書が4本のユーザーストーリーと計16個の受け入れ基準に膨らみ、「ナットを割るのに大槌を使う」ようだったと書かれています。Spec Kitでは、既存クラスの説明として調べたメモをエージェントが新しい仕様と取り違え、クラスを重複して生成しました。
• ThoughtworksのTechnology Radar（2025年11月）はSDDを「Assess（評価段階）」に置き、ツールによってはレビューしにくい長い仕様を生成すること、AI向けの詳細なルールを手で作り込むやり方は結局スケールしないという教訓を学び直しているのかもしれないと書いています。同じ号（Volume 33）の総論も、SDDに「重い事前仕様とビッグバンリリース」という従来の悪い型へ戻るリスクがあると指摘しています（Technology Radar Vol.33 PDF）。なお、この項目は最新版のRadarには載っていません。

批判はもっともですが、多くは適用する変更を絞れば避けられます。判断の線は次のとおりです。

• 見送る：AIに仕様を作らせても、そのレビューに実装より長い時間がかかる変更（バグ修正・設定変更・1画面の文言修正）。
• 見送る：仕様の前提（Assumptions）を判断できる人がチームにいない。AIの推測がそのまま要件になる。
• 続ける：仕様レビューで防げた手戻りの見込み工数が、仕様の作成・レビュー・更新にかかる工数を上回る機能。防げた手戻りと仕様にかけた時間を機能ごとに記録すると、続けるかどうかの根拠になる。

仕様が読まれなくなる失敗を防ぐ運用ルール：解像度・曖昧語・更新責任

性能要件の具体化：数値目標・測定条件・判定基準

最優先は、仕様の解像度を上げるのは人間の仕事だと決めておくことです。「いい感じに作って」では、上の実測のように業務判断までAIが埋めます。曖昧な表現も避けます。「十分高速に」ではなく、例えば「合意した負荷試験環境で対象APIに毎秒1000リクエストを10分間送り、応答時間の95パーセンタイルを500ミリ秒以下、エラー率を0.1％未満とする」のように、数値と測定条件を併記します。

仕様の継続保守：プルリクエストでの更新と人によるレビュー

仕様を残すなら、変更時はプルリクエストに仕様の更新を含め、更新の責任者を決めます。これがspec-firstからspec-anchoredへ進む条件です。AIの生成物は必ず人がレビューします。Spec KitのREADMEも、各スキルの結果を確認してから次へ進む手順を前提にしています。

よくある質問

仕様駆動開発は英語で何と言いますか？

Spec-Driven Development（略してSDD）です。英語圏ではハイフンなしの「spec driven development」とも書かれます。日本語では「仕様駆動開発」のほか「仕様書駆動開発」「スペック駆動開発」とも訳され、いずれもコードより先に仕様を定義し、その仕様を起点に設計・実装・テストを進めるアプローチを指します。

仕様駆動開発とテスト駆動開発（TDD）の違いは何ですか？

TDDはテストコードを先に書いて実装の動作を固定する手法で、SDDは作るべき要件と設計を先に明文化する手法です。層が違うため対立せず、SDDで受け入れ基準を定義し、その基準をTDDのテストに落として実装する併用が自然です。cc-sddの実装工程もタスクごとにTDDで進めます。

仕様駆動開発のデメリット（欠点）は何ですか？

仕様を書くぶん着手が遅れること、仕様を最新に保つ手間がかかること、AIが生成する仕様が長くレビューが追いつかないことです。小さな修正に適用すると仕様が膨らむため、画面やAPIをまたぐ新機能や後から他人が読む変更に絞るのが現実的です。

仕様駆動開発はやめたほうがいいですか？

すべての変更に使うのはやめたほうがよい、が答えです。数行で済むバグ修正や設定変更に一式の仕様生成を適用すると、仕様レビューの負担が実装を上回る場合があります。一方、複数の画面やAPIにまたがる新機能では、仕様の前提を実装前に人が直せる利点が残ります。適用する機能を選んで続けてください。

AI駆動開発と仕様駆動開発の違いは何ですか？

AI駆動開発はAIを開発工程に組み込むこと全般を指します。仕様駆動開発は仕様を起点とする手法であり、AIと組み合わせる場合にはAI駆動開発の進め方の1つになります。その場合の特徴は、AIに渡す正本を会話やその場の指示ではなく仕様書に置き、仕様から計画・タスク・実装を導く点です。

関連記事

• 仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpecの違いと選び方【2026年10月】
• Spec Kit（GitHub）とは？仕様駆動開発の使い方・インストール・コマンドを徹底解説
• Kiroとは？AWS製の仕様駆動AI IDEの特徴・料金・使い方を解説【2026年版】
• OpenSpecとは？使い方・インストール・/opsxコマンドをv1.14で解説
• EARS記法とは？読み方と5つの基本型の書き方を日本語例文で解説【Kiro対応】