仕様駆動開発（スペック駆動開発）について調べてみた

Last updated at 2026-01-30Posted at 2026-01-29

仕様駆動開発（スペック駆動開発）とは

仕様駆動開発（Spec Driven Development: SDD）とは、
ソフトウェア開発の初期段階でまず詳細な「仕様（Spec）」を明確かつ構造的に記述し、その仕様を単一の拠り所 SSOT（シングルソース・オブ・トゥルース）として設計・実装・テスト・ドキュメント化まで一貫して進める開発手法です。

この手法では、「コードを書く前に仕様を書く」ことを重視し、仕様書をプロジェクト全体の中心に据えて開発を進めます。

特に最近は生成AIをソフトウェア開発に積極的に活用する動きの中で、この「仕様ファースト」のアプローチが再注目されています。

従来の開発手法との違い・位置付け

ウォーターフォール開発との比較

ウォーターフォール型は要件定義から設計・実装・テストを順番に行う手法で、初期に詳細な仕様書を作成する点はSDDと似ています。
しかしウォーターフォールでは一度作った仕様を固定しがちで、変更に弱いという欠点があります。

SDDではむしろ「仕様を常に進化させ続ける」ことを前提としており、開発中に得られたフィードバックを仕様に反映しながら柔軟に進める点で従来の大規模な「変更できない仕様書」とは異なります。

アジャイル開発との比較

アジャイル開発は、動くソフトウェアを短いサイクルで作り上げ、反復的に改善していく手法です。アジャイルは「包括的な文書より動くソフトウェアを重視」すると謳われますが、SDDもこの価値観と対立するものではありません。

SDDの仕様書は、従来の詳細設計書というより、次のイテレーションで実装すべき機能要件や受け入れ基準の「ストーリー」に近い粒度で作成・更新されることが多く、アジャイル的な反復の中で逐次アップデートされます。

つまり、アジャイルの速いフィードバックループの中に「常に最新化される仕様」という要素を組み込んだものと位置付けることができます。

テスト駆動開発との比較

テスト駆動開発は、実装前にテストコードを先に書き、テストが失敗する状態から実装を開始してテストを通るようコードを書く手法です。TDDでは「テストケース」がプロジェクトの設計記述の一部となりますが、扱う粒度は関数やモジュールなど技術実装よりです。

一方、SDDではテストより上位の「仕様書」そのものを先に作成します。
例えば、システム全体の機能要件リストやAPIの仕様書など、テストケースより広い範囲の要件をカバーします。TDDが開発者視点で「コードが設計どおり正しく動くか」に重点を置くのに対し、SDDはより上流の「何を実現すべきか」を明確にする点に重点があります。

メリット

1. 認識合わせが速くなる

SDDは「仕様」が単一の拠り所になるため、議論の中心が常に 仕様に書いてあるか / 受け入れ基準を満たすか に寄ります。
結果として、口頭のニュアンスや暗黙知に依存した「思ってたのと違う」が減り、レビューや合意形成がしやすくなります。

2. 手戻り削減・品質の前倒し

実装に入る前に、仕様（要件・制約・受け入れ基準）をレビューするため、設計ミスや要件漏れを早期に発見できます。
後工程での修正は高コストになりがちなので、品質保証の前倒し が効きやすいのがメリットです。

3. 仕様→設計→タスク→実装の「段階化」で進行管理がしやすい

特にAI支援のSDDでは、「いきなり実装」ではなく、仕様→設計→タスク分解→実装 という段階を踏むワークフローがよく採用されます。ThoughtWorksはSDDを、構造化された仕様から始めて小さなピース（解決策・タスク）へ段階的に分解していくワークフローとして説明しています。

4. AIとの相性が良い

AIにコードを書かせるとき、曖昧な会話ログだけだと再現性が落ちがちです。
一方で仕様が明文化されていると、AIに渡すべき前提とゴールが揃うので、出力のブレを抑えやすいです。GitHubのSpec Kitも、いわゆるvibe codingではなく仕様から始める構造化プロセスでAIコーディングを支援する、といった位置付けで紹介されています。

デメリット

1. 初期コストがかかる

SDDは「仕様を書いてから作る」ので、最初に時間と集中力を使います。
特に、ドメイン理解が浅い状態で仕様を固めにいくと、後で仕様の作り直しが発生しやすいです。

2. 仕様メンテが止まると一気に破綻する

仕様がSSOTである以上、仕様が更新されないと 「仕様は古い / コードが正」 になり、誰も仕様を信用しなくなります。
SDDは「書いて終わり」ではなく、継続運用が前提です。

3. ウォーターフォール化しやすい

「完璧な仕様を書いてから着手」をやり始めると、意思決定が遅くなり、アジャイルの良さ（速い検証ループ）を失います。
ポイントは 今のイテレーションで必要な粒度まで に仕様を抑えること。

4. AI前提だと「書いてないことは出てこない」問題が顕在化する

AIは暗黙知を補完してくれません。
仕様に書き漏れると、そのまま漏れた成果物が出てくる（あるいはAIが勝手に補完して事故る）ので、仕様を書く側の責任が増えます。

導入事例

KDDI：エンタープライズ開発でのSDD実践

KDDIの技術記事では、AIと対話しながら即興でコードを書かせる（いわゆるvibe coding）運用だと、前提や意図がチャット履歴に埋もれて追跡できず、再現性や説明責任の面でつらい――といった課題が出たため、「仕様が先導し、AIが実装する」 形に寄せてSDDを導入した、という文脈が紹介されています。

2026年現在のトレンドと話題性

1. 「AI支援コーディングの作法」としてSDDが言及されるようになってきた

ThoughtWorksのTechnology Radarでも、Spec-driven development がAI支援コーディングの新しいワークフローとして取り上げられています。

2. 大手・コミュニティからツールや実践知が増えている

GitHubがSpec Kitを公開して「仕様から始めるAI開発」を後押ししていたり、KiroのようにSpecワークフロー自体をIDE側で用意する動きも出てきています。
日本語圏でも、cc-sddなどを使った実践記事がQiita/Zennで増えていて、試行錯誤の知見が溜まりつつある印象です。

3. ただし「銀の弾丸」ではなく、運用設計が本体

SDDは「仕様を書けば勝ち」ではなく、仕様の粒度・更新フロー・レビュー観点が揃って初めて効果が出ます。
逆に、仕様が重くなりすぎたり、更新されなくなったりすると、従来の「重厚な設計書が形骸化する問題」をそのまま再演しがちです。

cc-sdd で「仕様駆動開発」を体験する

ここからは、実際に cc-sdd のフローに沿って TODOアプリを「仕様→設計→タスク→実装」 の順で作ります。

cc-sdd は、仕様（requirements）→設計（design）→タスク（tasks）→実装（impl） の流れをコマンドで強制し、さらにプロジェクト方針を steering（憲法） として先に固める、KiroスタイルのSDD（仕様駆動開発）をCLI上で再現するツールです。

cc-sdd

この記事では、cc-sdd が提供する /kiro:* コマンドを使って、TODOアプリを「仕様から」作ります。

この記事で扱うコマンド群は、cc-sdd の Kiro Inspired な開発手順（/kiro:spec-init / /kiro:spec-requirements / /kiro:spec-design / /kiro:spec-tasks / /kiro:spec-impl）に沿ったものです。

全体像：どういう流れで、何が生成されるのか

Flow（作業の流れ）

最終的に生成されるドキュメント一覧

.kiro/steering/*.md
- プロジェクトの前提・方針・技術スタック・構造（AIに渡す“憲法”）
.kiro/specs/test-todo-app/requirements.md
- 要件定義（Acceptance Criteria つき）
.kiro/specs/test-todo-app/design.md ＋ research.md
- 技術設計（なぜその設計/技術にしたか、も含む）
.kiro/specs/test-todo-app/tasks.md
- 実装タスク分解（taskId 付き。ここから spec-impl で実装）
.kiro/specs/test-todo-app/spec.json
- 生成フェーズや承認状態などの メタ情報

この「steering → requirements → design → tasks → impl」という段階的な進め方は、cc-sdd を使った解説記事でも同様の流れで紹介されています。
「AI駆動PM」と「SDD（仕様駆動開発）」で要件定義書・設計書の精度を劇的に向上させる方法

Step 0：プロジェクト作成

mkdir test-todo-app
cd test-todo-app
npm create vite@latest . -- --template react-ts
npm i
npm run dev

以下のコマンドを実行すると.kiroディレクトリが生成されセットアップが完了します。

npx cc-sdd@latest --claude --lang ja

Step 1：/kiro:steering（前提・方針をAIに渡す）

/kiro:steering は、プロジェクト全体の方針（技術・構造・制約）を“AIが参照するSSOT”として先に作る工程です。
この「まずコンテキスト（憲法）を確立してから開発を進める」流れ自体が、cc-sdd の説明として共有されています。

下記のファイルが生成されます。

.kiro/steering/product.md
.kiro/steering/tech.md
.kiro/steering/structure.md

この段階でやることはシンプルで、

生成された steering を読む
明らかにズレてる前提があれば直す（例：不要な機能が入ってる/技術選定が違う）

だけでOKです。

Step 2：/kiro:spec-requirements（要件定義）

/kiro:spec-requirements test-todo-app

→ .kiro/specs/test-todo-app/requirements.md が生成されます。

ここで重要なのは、requirements は「長文の要件」ではなく、Acceptance Criteria（受け入れ基準）の集合になっていることです。

Step 3：/kiro:spec-design（技術設計）

/kiro:spec-design test-todo-app -y

→ design.md / research.md が生成されます。

Step 4：/kiro:spec-tasks（実装タスク分解）

/kiro:spec-tasks test-todo-app -y

→ tasks.md が生成されます。

この tasks.md の “taskId（例：1.1 / 2.1 …）” が、次の 実装の入口 になります。

Step 5：/kiro:spec-impl（タスク単位で実装していく）

次は tasks.md の順に こう進めます：

/kiro:spec-impl test-todo-app 2.1
/kiro:spec-impl test-todo-app 3.1
/kiro:spec-impl test-todo-app 3.2
...

適宜、コンテキストを切ってタスクをどんどん実行させていきましょう。

「コンテキストを切る」とは

結論：次のタスクに行く前に、会話履歴（＝AIの短期記憶）を捨てるだけです。

いちばん簡単なのは：

/clear

を実行することです。

なぜ切るのか？

spec-impl はタスクごとに「このタスクのゴール」に集中させたいのに、前の会話が残っていると

直前の実装方針に引っ張られて、別タスクの条件を取りこぼす
“さっき言ったこと”を前提にして、仕様書の内容より会話ログを優先してしまう

みたいな事故が起きやすいです。

何を基準に「切ったらOK」？

そのタスクの最後に npm run build と npm run lint が通っている
tasks.md に 完了チェックが入り、要約が追記されている
その状態で一回 /clear

この3点セットで十分です。

まとめ

仕様駆動開発（SDD）は、昔ながらの「仕様書を最初に作る」発想に見えつつも、最近は AIと協働するための開発プロセスとして再解釈され、注目度が上がっていると感じました。

個人的には、いきなり全体をSDDにするよりも、

まずは API仕様（OpenAPI） や 受け入れ基準（Given-When-Then） のように、範囲を絞って“仕様をSSOTにする”練習をする
次に、仕様→設計→タスク分解の型をチームに馴染ませる
みたいに段階導入するのが現実的だと思っています。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up