仕様駆動開発（SDD）とは
仕様駆動開発（SDD: Spec-Driven Development）は、AI のコーディングエージェントに「思いつきのプロンプト」で書かせるのではなく、自然言語で書いた仕様を起点にしてコードを生成させる開発手法です。GitHub が 2025 年 9 月 2 日に公開した OSS ツールキット Spec Kitをきっかけに、AI 開発の現場で広く語られるようになりました。
自然言語で書いた仕様を「唯一の正（Single Source of Truth）」に据え、AI のコーディングエージェントにその仕様から実装（コード）を生成させる開発手法です。仕様はコードを補助する資料ではなく、コードを生み出す元になります。
AI（ChatGPT、Claude、Geminiなど）がコードを大量に書けるようになると、ボトルネックは「実装する速さ」から「何を作るかを曖昧さなく決められるか」に移ります。仕様駆動開発は、その仕様を構造化して先に固め、AI に実装させる進め方です。GitHub Spec Kit の Constitution → Specify → Plan → Tasks → Implement の流れが代表例で、本記事ではその仕組みと、具体的な作り方、仕様の保守、課題、海外の実践例までを整理します。
01.結論：仕様駆動開発（SDD）とは何か
従来の開発では、仕様書はあくまで実装の参考資料で、最終的な正しさはコードが持っていました。仕様駆動開発はこの関係を逆にします。GitHub Spec Kit の解説ドキュメントは「仕様がコードに仕えるのではなく、コードが仕様に仕える」と表現し、仕様を実装の生成元として扱います（github/spec-kit: spec-driven.md）。
背景には、AI コーディングエージェントの普及があります。実装そのものは AI が短時間で大量に書けるようになりました。一方で、AI は仕様の曖昧さをそのまま実装に持ち込みます。曖昧な指示からは曖昧なコードが、矛盾した要件からは矛盾した挙動が生成されるため、品質を担保する起点は「人間が仕様をどれだけ正確に定義できるか」へ移ります。仕様駆動開発は、この前提に合わせて工程を組み直したものです。
02.SDDに至る流れ：vibe codingから仕様駆動へ
仕様駆動開発は、いきなり登場したわけではありません。AI でコードを書く方法が「思いつきで書かせる」段階から「仕様を固めてから書かせる」段階へ進んだ、という流れの中にあります。
起点は vibe coding（バイブコーディング）です。2025 年 2 月、Andrej Karpathy 氏が「コードの存在を忘れて勢いに身を任せる新しいコーディング」として この言葉を提唱しました。AI コーディングエージェントが普及して実装を量産できるようになる一方、思いつきで書かせると仕様の曖昧さがそのままバグになる課題が表面化します。その対策として、リポジトリに AGENTS.md や CLAUDE.md を置いて規約や前提を固める運用が広がりました。
時期は各社・各氏の公開情報に基づく。出典は本文中のリンクを参照。
この流れを製品やツールに落としたのが、2025 年 7 月に AWS が公開した仕様駆動の IDE「Kiro」（InfoQ: Beyond Vibe Coding）と、同年 9 月の GitHub Spec Kit です。2026 年には、vibe coding を広めた Karpathy 氏自身が「vibe coding は過去で、これからは agentic engineering（エージェントを統率する開発）が既定になる」と述べ（The New Stack）、Thoughtworks は仕様駆動開発を Technology Radar の「Assess（評価・試用段階）」に位置づけました（Thoughtworks Technology Radar）。
03.基本：仕様を「唯一の正」にしてAIに実装させる
仕様駆動開発の中心にあるのは、「仕様を Single Source of Truth（唯一の正）にする」という考え方です。Single Source of Truth とは、ある情報について正本となる場所を一つに定め、ほかはそこから派生させるという設計原則を指します。仕様駆動開発では、仕様がその正本になります。
GitHub のブログは、コーディングエージェントを「検索エンジンのように扱う」のではなく、「言われたことを文字どおりに受け取るペアプログラマーのように扱う」と表現しています（The GitHub Blog, 2025-09-02）。文字どおりに受け取る相手だからこそ、仕様・計画・タスクという中間の成果物を先に整え、実装はそこから生成させる、というのが基本の発想です。
- Single Source of Truth（唯一の正）：ある情報の正本となる場所を一つに定め、ほかはそこから派生させる設計原則。仕様駆動開発では仕様がこれにあたります。
- コーディングエージェント：自然言語の指示を受けて、コードの生成・編集・テスト実行までを自律的に進める AI。Claude Code・GitHub Copilot・Codex・Gemini CLI など。
04.GitHub Spec Kit のワークフロー
仕様駆動開発を具体的な手順に落とした代表例が、GitHub の OSS ツールキット github/spec-kitです。MIT ライセンスで公開され、Specify CLI と一連のテンプレートから構成されます。GitHub Copilot・Claude Code・Gemini CLI をはじめ、30 以上の AI コーディングエージェントに対応しています（同リポジトリ README）。
守るべき原則（言語・設計方針・テスト方針など）を先に固める。成果物：constitution.md。
何を作るかを自然言語で書く。実装方法ではなく満たすべき要件を書く。成果物：仕様。
技術選定・構成・設計を仕様から具体化する。どう作るかを決める。成果物：技術計画。
計画を、検証できる小さなタスクに分解する。成果物：タスク一覧。
AIがタスクごとに実装する。仕様・計画・原則を常に参照する。成果物：コード。
Constitution は最初に一度固め、以降の Specify → Plan → Tasks → Implement のすべての工程で参照される。仕様や計画を更新すると、その変更が後続の工程に反映される。
Constitution：守るべき原則を先に決める
最初の工程が Constitution（憲法）です。Microsoft の開発者向け解説によると、Constitution はプロジェクトの「動かしてはならない原則」を定める文書で、memory/constitution.md に置かれます。使う言語、設計の方針、テストの方針、品質の基準などをここに集約し、以降のすべての工程がこの原則を参照します（Microsoft for Developers）。
Constitution を先に固めるのは、AI が工程を重ねるうちに少しずつ方針から外れていくのを防ぐためです。原則が一か所にまとまっていれば、複数の開発者が同じ AI に作業させても、出力の方向が揃いやすくなります。
Specify → Plan → Tasks → Implement
Constitution のあとは、4 つの工程を順に回します。GitHub Spec Kit では、各工程が次のコマンドに対応します。
/speckit.specify：何を作るかを仕様として書く/speckit.plan：技術構成・設計を決める/speckit.tasks：検証できる小さなタスクに分解する/speckit.implement：AIがタスクごとに実装する
各工程の成果物（仕様・計画・タスク）はレビュー可能なテキストとして残るため、実装に進む前に「要件は正しいか」「設計は妥当か」を人間が確認でき、問題があれば前の工程に戻って直せます。AI が走り出してから軌道修正するより、上流で直すほうが手戻りが小さくなります。
具体例：自動返信メールを1機能として作る
手順だけでは像が掴みにくいので、「問い合わせフォームに自動返信メールを追加する」という小さな機能を例にします。まず Specify で、実装方法ではなく満たすべき要件を書きます。受け入れ基準は、後述の EARS 記法に沿って「どういうときに何が起きるか」を一文ずつ書きます。
# specs/001-contact-autoreply/spec.md
## 概要
問い合わせフォームの送信時に、送信者へ自動返信メールを送る。
## 受け入れ基準（EARS記法）
- 問い合わせが送信されたとき、システムは
送信者のアドレス宛に自動返信メールを送らなければならない。
- アドレスが不正なとき、システムは
自動返信を送らず、エラーを記録しなければならない。
## 対象外
- 添付ファイルの自動返信は対象外とする。次に Plan で技術構成（どのメール送信基盤を使うか等）を決め、Tasks でその計画を、検証できる小さな単位に分解します。タスクは 1 つずつ完了を確認できる粒度にします。
# specs/001-contact-autoreply/tasks.md
1. 送信完了フックに自動返信処理を追加する
2. メールアドレスの形式を検証する
3. 自動返信メールの本文テンプレートを用意する
4. 不正アドレス時のエラー記録を実装する
5. 受け入れ基準を満たすか確認する自動テストを追加する最後に Implement で、AI エージェントがタスク 1 から順に実装します。各タスクが受け入れ基準を満たすかをテストで確認し、満たさなければ仕様・計画・原則を参照しながら直します。人間がやるのは「仕様とタスクが正しいかのレビュー」で、コードを 1 行ずつ書く作業はエージェントが担う、という分担になります。
05.仕様はひとつをメンテし続けるのか
「巨大な仕様を一つ作って、それをずっと保守し続けるのか」と疑問に思うかもしれませんが、実際は違います。GitHub Spec Kit は機能ごとに独立した仕様フォルダを作ります。たとえば specs/001-contact-autoreply/、specs/003-chat-system/ のように、機能（feature）単位で番号付きのフォルダが切られ、その中に spec.md が置かれます。一つの巨大な仕様ではなく、機能の数だけ小さな仕様が並ぶ構造です。
共通して長く使うのは、全機能が参照する Constitution（原則）の方です。各機能の仕様は、コードと一緒に育てる「生きたドキュメント」として扱います。GitHub Spec Kit の解説でも、仕様は「一度書いて忘れる埃をかぶった資料ではなく、コードと共に進化する生きたドキュメント」とされ、要件が変わるたびに仕様を更新し、計画やタスクを作り直す運用が想定されています（github/spec-kit）。
仕様はバージョン管理されるので、最初の意図から実装までの変更履歴が追えます。完成したら捨てるのでも、永久に凍結するのでもなく、コードをリファクタリングするのと同じ感覚で仕様を更新し続けるのが理想です。仕様を更新できる状態を保てるかどうかが、仕様駆動開発が機能するかの分かれ目になります。
06.vibe coding・従来手法との違い
思いつきのプロンプトで AI にコードを書かせ、出来上がりをそのまま受け取る進め方を指します。素早く試作できる一方、要件や設計が言語化されないため、規模が大きくなると破綻しやすくなります。
仕様駆動開発は、vibe coding と対になる概念としてよく語られます。vibe coding が「先にコードを出す」のに対し、仕様駆動開発は「先に仕様を固める」点が違います。また、要件を先に書く点は従来のウォーターフォール開発やテスト駆動開発（TDD: Test-Driven Development）とも似ていますが、位置づけは異なります。
| 手法 | 起点とAIとの関係 | 向いている場面 |
|---|---|---|
| vibe coding | 思いつきのプロンプトから、AIが書いたものをそのまま受け取る | 試作・使い捨ての検証 |
| 仕様駆動開発（SDD） | 構造化した仕様から、AIが実装を生成し、人間は仕様を検証する | 継続的に保守する開発・チーム開発 |
| テスト駆動開発（TDD） | 失敗するテストから、満たすべき振る舞いを規定する | 振る舞いを細かく固めたい実装 |
| ウォーターフォール | 凍結した仕様書から、後戻りしない前提で進める | 要件変更が起きにくい開発 |
仕様駆動開発とテスト駆動開発は排他ではありません。Specify や Tasks の段階で受け入れ基準（満たすべき条件）をテストとして書いておけば、AI が実装した結果をそのテストで検証できます。仕様が「何を満たすか」を、テストが「満たせたかの判定」を担う関係です。
07.何が良くなるか：上流で仕様の曖昧さを潰す
仕様駆動開発の効きどころは、実装ではなく仕様の段階で曖昧さや矛盾を潰せることです。AI は曖昧な指示をそのまま実装に変換してしまうため、仕様が固まっていないまま走らせると、後工程で気づいて直すコストが大きくなります。仕様を先に構造化しておけば、人間のレビューでも AI のレビューでも、矛盾や抜けを早い段階で検出できます。
仕様の曖昧さを減らす道具として知られるのが EARS 記法です。
要件文を一定の構文に沿って書くための記法です。「前提条件・きっかけ・システム名・システムの応答」を決まった語順で書くことで、曖昧さや複雑さといった要件の典型的な問題を減らします。Rolls-Royce の Alistair Mavin 氏らが 2009 年に提案しました。
EARS は、Airbus・Bosch・NASA・Rolls-Royce など多くの組織で使われている軽量な記法で、専用ツールを必要とせず、英語の自然な語順に近いのが特徴です（EARS 公式サイト）。先ほどの具体例で受け入れ基準を「〜のとき、システムは〜しなければならない」と書いたのも、この記法に沿ったものです。仕様の品質をどう担保するかは、品質保証（QA）の観点からも重要になります。
08.課題と批判：「Markdownのウォーターフォール」
仕様駆動開発には批判もあります。よく聞かれるのが「結局はウォーターフォールを Markdown でやり直しているだけではないか」という指摘です。実装前に大量の仕様を書く点が、後戻りを許さないウォーターフォールに似て見えるためです。
Thoughtworks は、「仕様を書いてから実装する」ことと「仕様を凍結してから実装する」ことは別物だと整理しています。前者は短い反復で仕様を更新していくのに対し、後者は工程の関門で仕様を固定してしまう点が違うと述べています（Thoughtworks Technology Radar）。仕様駆動開発が「Markdown のウォーターフォール」になるかどうかは、仕様を更新し続けられるかにかかっています。
実務上の課題として、Thoughtworks のチームは、ツールが冗長な Markdown を出力して読む負担が増えること、生成された仕様ファイルが長くてレビューしづらいこと、不要な防御的チェックが混じることなどを報告しています（同上）。仕様を「唯一の正」にする以上、その仕様が大きくなりすぎてレビューできなくなると、本来の利点が失われます。仕様を適切な粒度に保つこと自体が、新しい設計課題になります。
仕様駆動開発は、継続的に保守する開発や複数人での開発で効きやすい手法です。一方、使い捨ての試作や、要件が固まる前の探索段階では、仕様を先に固める負担のほうが大きくなることがあります。まずは一つの機能で Specify → Plan → Tasks → Implement を回し、仕様のレビューが手戻り削減につながるかを確かめてから、対象を広げるのが現実的です。
09.海外での実践：取り入れ方と採用の広がり
海外では、仕様駆動開発をどこまで徹底するかで段階に分けて捉える見方が広がっています。ソフトウェアコンサルティング企業の Thoughtworks で AI 支援開発を統括する Birgitta Böckeler 氏は、主要ツール（Kiro・Spec Kit・Tessl）を実際に試したうえで、仕様駆動開発を取り組みの深さで 3 つの段階に整理しています（Martin Fowler / Thoughtworks）。
- spec-first（仕様を先に書く）：まず仕様を書いてから実装に入る。仕様はそのタスクのあいだ使う。
- spec-anchored（仕様を残す）：実装後も仕様を残し、その後の保守や改修にも使い続ける。
- spec-as-source（仕様を源泉にする）：人は仕様だけを編集し、コードには直接触れない。コードは仕様から再生成される。
Böckeler 氏は、この 3 つは対立する考え方ではなく、前の段階の弱点を補うように踏み込みを深めたものだと説明しています。多くのチームは spec-first から始め、仕様を残して保守にも使う spec-anchored へ進み、spec-as-source までたどり着くのはごく一部だ、というのが同氏の見立てです。ツールを選ぶより先に、どの段階を目指すかを決めることが、実践の出発点になります。
採用も広がっています。GitHub Spec Kit は公開から 1 週間で GitHub のスター数が 16,000 を超え、「断片的な vibe coding への対抗策」として注目を集めています（Visual Studio Magazine, 2026-05）。一方で、前章で見たように仕様が肥大化する課題も指摘されており、どの段階で運用するかはチームの規模や対象によります。
なぜ Anthropic は開発が異常に速いのか｜100並列のエージェント運用と PRD を持たない組織
重い仕様書（PRD）を持たずに合意を取る組織の例。仕様駆動開発とは対照的な進め方として参考になります。
10.よくある質問（FAQ）
仕様駆動開発（SDD）とは一言で何ですか？
自然言語で書いた仕様を「唯一の正（Single Source of Truth）」に据え、AI のコーディングエージェントにその仕様から実装を生成させる開発手法です。仕様はコードを補助する資料ではなく、コードを生み出す元になります。GitHub が 2025 年 9 月に公開した Spec Kit が代表的なツールキットです。
仕様はひとつをずっとメンテし続けるのですか？
いいえ。GitHub Spec Kit は機能ごとに独立した仕様フォルダ（例: specs/001-...、specs/003-...）を作るため、機能の数だけ小さな仕様が並びます。共通して長く使うのは、全機能が参照する Constitution（原則）の方です。各機能の仕様はコードと一緒に育てる「生きたドキュメント」として、要件が変わるたびに更新し、計画やタスクを作り直します。バージョン管理されるので、意図から実装までの履歴も追えます。
GitHub Spec Kit はどんなツールですか？
GitHub が 2025 年 9 月 2 日に公開した MIT ライセンスの OSS ツールキットです。Specify CLI とテンプレートで、Constitution → Specify → Plan → Tasks → Implement の流れを支援します。GitHub Copilot・Claude Code・Gemini CLI など 30 以上の AI コーディングエージェントに対応しています。
vibe coding と何が違いますか？
vibe coding は思いつきのプロンプトで AI にコードを書かせ、出来上がりをそのまま受け取る進め方です。仕様駆動開発は、先に仕様を構造化して固め、そこから AI に実装を生成させる点が違います。試作には vibe coding が、継続的に保守する開発やチーム開発には仕様駆動開発が向きます。
仕様駆動開発はウォーターフォールの焼き直しではないですか？
Thoughtworks は Technology Radar で、「仕様を書いてから実装する」ことと「仕様を凍結してから実装する」ことは別物だと整理しています。前者は短い反復で仕様を更新するのに対し、後者は工程の関門で仕様を固定します。仕様を更新し続けられれば、ウォーターフォールとは異なる進め方になります。なお同社は仕様駆動開発を「Assess（評価・試用段階）」に位置づけています。
11.まとめ
仕様駆動開発（SDD）は、自然言語で書いた仕様を「唯一の正」に据え、AI のコーディングエージェントにその仕様から実装を生成させる開発手法です。vibe coding が広まったあと、仕様の曖昧さがバグになる課題への対応として現れました。GitHub Spec Kit の Constitution → Specify → Plan → Tasks → Implement が代表的な流れで、機能ごとの仕様をコードと一緒に育てながら、上流で曖昧さを潰すことを狙います。「Markdown のウォーターフォール」になる懸念や、仕様が肥大化する課題はありますが、仕様を更新し続けられる運用なら、AI が実装を量産する時代に品質を保つための有力な進め方です。AWS Kiro や GitHub Spec Kit の広がりが示すように、仕様を実装の入力に据える動きは海外でも本格化しています。
チームでAI駆動開発を内製化するための設計を一緒に整理しませんか
仕様の構造化、Constitution の整備、レビュー工程の設計まで、Cryptul が現場で使える型に落とし込みます。
