2026年10月6日更新：Spec Kitの現行版（1.1.0）の進め方に合わせて手順と図を差し替え、TDDとの違い、仕様の記入例、SDDが向かない場面を追加しました。出典を一次情報で確認できなかった他社の効果の数値は削除しています。
仕様駆動開発（SDD: Spec-Driven Development）は、AIにコードを書かせる前に「何を作るか」を仕様として書き、その仕様を基準に実装と検証を進める開発手法です。AIコーディングツールが普及した2025年以降に広まり、GitHubのSpec Kitのような専用のツールも出ています。
この記事は、「SDDという言葉を見かけたが、何をすることなのか」を知りたい方と、AIを使った受託開発で手戻りを減らしたい開発担当・発注担当の方に向けて書いています。
先に、要点をまとめます（2026年10月6日確認）。
- SDDは、目的・範囲・制約・受け入れ基準を実装の前に書き、AIの実装をその仕様に照らして確かめる進め方です。コードと仕様が食い違ったら、仕様を基準に直します
- TDD（テスト駆動開発）が「テストを先に書く」のに対し、SDDは「その前段の、何を満たせば完成かを先に書く」ことに重心があります。受け入れ基準をテストに落とせる形で書くと、両者はつながります
- 効くのは、AIに任せる範囲が広く、発注側と「何を作るか」を握る必要がある開発です。1行の修正や、作りながら方向を探す試作には向きません
仕様駆動開発（SDD）とは？
コードを書く前に、目的・範囲・制約・受け入れ基準を仕様として書き、その仕様を「正」として実装と検証を進める開発手法です。AIにコードを書かせる場面で、AIの当て推量を減らすために使われています。
SDDでいう仕様には、次の4つを書きます。
| 書くこと | 中身 | 例（申請の差し戻し機能） |
|---|
| 目的 | 誰の、どの困りごとを解決するか | 差し戻された申請者が、理由を見て再申請できるようにする |
| 範囲 | 作るものと、今回は作らないもの | 差し戻しと再申請は作る。差し戻し理由の定型文化は作らない |
| 制約 | 守るべき技術・運用のルール | 差し戻しは承認者の権限を持つ人だけが行える |
| 受け入れ基準 | 何ができたら完成とみなすか | 差し戻した申請が、申請者の一覧に「差し戻し」と理由付きで表示される |
「仕様を正にする」とは、実装と仕様が食い違ったときに、仕様のほうを基準にするという意味です。AIが仕様と違うものを作ったらコードを仕様に合わせて直し、作りながら仕様のほうが間違っていたと分かったら、仕様を先に書き換えてから実装をやり直します。仕様を書いて終わりにせず、コードと一緒に更新し続けることが前提になります。
TDDやウォーターフォールとは何が違う？
TDDはテストを先に書く手法、ウォーターフォールは工程を順に進める進め方で、SDDは「完成の条件を、AIが読める形で先に書く」ことに重心がある手法です。三つは排他ではなく、組み合わせて使えます。
| 手法 | 最初に書くもの | 書く粒度 | AIとの関係 |
|---|
| ウォーターフォール | 要件定義書・設計書 | システム全体を工程ごと | 前提にしていない |
| TDD（テスト駆動開発） | 失敗するテスト | 関数・画面の振る舞い単位 | テストを合否の判定に使える |
| SDD（仕様駆動開発） | 目的・範囲・制約・受け入れ基準 | 機能単位で、必要十分に | 仕様をAIへの指示と判定の基準にする |
ウォーターフォールの設計書との違いは、機能ごとに短く書き、実装の途中でも更新する点です。重い文書を最初に全部そろえる進め方ではありません。TDDとの関係では、SDDの受け入れ基準を「テストで判定できる文」で書いておくと、そのままテストの元になります。後半の記入例で具体的に示します。
なぜAIを使う開発でSDDが注目されたのか？
プロンプトで指示して出てきたコードをそのまま採用する進め方は、試作には速い一方で、規模が大きくなると意図とのずれや作り直しが増えたためです。
「Vibe Coding（バイブコーディング）」という言葉は、2025年2月にAndrej Karpathy氏が使い始め、Collins English Dictionaryの2025年のWord of the Yearにも選ばれました（Wikipedia: Vibe coding）。プロンプトを投げ、出てきたコードを細かく読まずに動かしていくスタイルです。
この進め方で受託の規模の開発をすると、次のことが起きます。
- AIが、指示の書かれていない部分を推測で埋める。推測が外れると、作り直しになる
- 同じ指示を別の日に出すと、別の構造のコードが出てくる。機能が増えるほど全体の一貫性が崩れる
- 何をもって完成とするかが決まっていないため、レビューで「これで合っているか」を毎回人が判断する
SDDは、推測で埋められていた部分を、実装の前に人が決めて書いておく手法です。受託開発では、この「人が決める部分」の多くを発注側と一緒に決めることになるため、仕様がそのまま合意の記録にもなります。
Spec Kitでは、どう進める？
プロジェクトに1回だけ原則（constitution）を決め、機能ごとに specify → plan → tasks → implement → converge の順に進めます。implementとconvergeは、仕様と実装のずれがなくなるまで繰り返します。
Spec Kitは、GitHubが公開しているオープンソースのツールキットです（MITライセンス、10月6日時点の最新版は1.1.0）。Python 3.11以上とuvを入れ、specify コマンドでプロジェクトを初期化すると、AIコーディングツールのチャットから /speckit-specify のような手順を呼び出せるようになります。対応するツールは50以上あり、Claude Code、Cursor、GitHub Copilot、Codex CLI、Kiro CLIなどが含まれます（対応ツールの一覧）。
# Spec Kit の導入（Claude Code で使う場合）
uv tool install specify-cli
specify init my-project --integration claude
| 手順 | すること |
|---|
| constitution | コード品質・テスト・保守性など、プロジェクトで譲れない原則を決める（1回だけ） |
| specify | 何を・なぜ作るかを、技術の話を入れずに利用者の目線で書く |
| plan | どう作るか（使う技術、データの持ち方、制約）を足す |
| tasks | 計画を、レビューできる小さな作業に分ける |
| implement | タスクを1つずつ実装する |
| converge | 仕様と実装のずれを確かめる。「Converged」と出るまでimplementと繰り返す |
必要に応じて、仕様のあいまいな点を質問させる手順や、チェックリスト、成果物どうしの整合を調べる手順も追加できます。READMEは、各手順の結果を確認してから次に進むよう案内しています。AIにまとめて任せる道具というより、人が確認する区切りを作る道具として使っています。
仕様はどう書く？（Next.js受託での記入例）
受け入れ基準を「誰が、何をしたら、何が見えるか」の形で書きます。この形なら、AIへの指示にも、テストの元にも、発注側との確認にもそのまま使えます。
以下は、Next.jsで作る社内の申請システムに「差し戻し」機能を足す場面を題材にした記入例です。実装済みの顧客事例ではありません。自社の業務に置き換えて、項目の粒度を確かめてください。
# 機能: 申請の差し戻し
## 目的
承認者が不備のある申請を差し戻し、申請者が理由を見て直して再申請できるようにする。
## 範囲
- 作る: 差し戻し操作、理由の入力（必須・500字以内）、申請者の一覧での表示、再申請
- 作らない: 差し戻し理由の定型文、メール以外の通知
## 制約
- 差し戻しは、その申請の承認者だけが行える（権限の判定はData Access Layerで行う）
- 差し戻し後の申請は、申請者が直すまで承認の一覧に出さない
## 受け入れ基準
1. 承認者が理由を入力して差し戻すと、申請の状態が「差し戻し」になる
2. 申請者の一覧で、その申請に「差し戻し」と理由が表示される
3. 承認者以外のユーザーが差し戻しのServer Actionを直接呼ぶと、エラーになり状態は変わらない
4. 理由が空、または501字以上のときは差し戻せず、入力欄にエラーが表示される
受け入れ基準の3番は、画面からは操作できない経路の確認です。画面にボタンを出さないだけでは、Server Actionを直接呼ばれたときに防げません。仕様に書いておくことで、AIの実装と、そのテストの両方に含まれます。権限の判定をどこに置くかは権限の判定をData Access Layerに置く設計で詳しく書いています。
4つの受け入れ基準は、それぞれテストの1件に対応します。1・2・4は画面を操作するテスト（Playwrightなど）、3はServer Actionを直接呼ぶテストで確かめます。どこまで自動テストにするかは中小企業のNext.jsフルスクラッチで、テストをどこまで書くかにまとめています。
Next.jsのフルスクラッチ受託に、どう落とすか？
プロジェクト固有の「正しい書き方」を原則に書く、受け入れ基準をテストで判定できる形にする、仕様を発注側との合意の記録にも使う、の3点です。
1つ目は、プロジェクト固有の正しい書き方を、constitutionや仕様に書いておくことです。Next.jsは版ごとの変化が大きく、AIの学習データには古い書き方が混ざります。「認可はData Access Layerで判定する」「キャッシュは use cache で境界を明示する」といったルールを先に書いておくと、AIが古い書き方で実装したときに、レビューで仕様違反として指摘できます。Next.js側でも、版に合ったドキュメントをAIに読ませる AGENTS.md の仕組みが用意されています（Next.js 16.2 の AGENTS.md とブラウザログ転送で、AI駆動開発の受託はどう速くなるか）。
2つ目は、受け入れ基準をテストで判定できる形で書くことです。「使いやすいこと」のような基準は、AIの実装が満たしたかを判定できません。上の記入例のように、操作と結果で書きます。
3つ目は、仕様を発注側との合意の記録にも使うことです。受託では、仕様の「範囲」と「作らないもの」が、そのまま見積もりの前提になります。AIへの指示のために書いた文書を、発注担当の方にも読める言葉で書いておけば、確認の資料を別に作らずに済みます。
私たちは、AIを使う開発で「計画を先に書いてから実装する」進め方を基本にしています。ツールの使い分けはCursor と Claude Code をどう使い分けているか｜中小企業向け Next.js 受託の現場に、現場の変化はClaude Code × Next.js 16 で受託開発はどう変わったか｜2026年の現場からに書いています。
SDDが向かない場面は？
1行の修正、作りながら方向を探す試作、仕様を更新し続ける人がいない開発には向きません。仕様を書く手間が、得られる確認のしやすさを上回るためです。
- 小さな修正：文言の変更や明らかな不具合の修正に、目的から受け入れ基準まで書く必要はありません。Spec Kitも、機能開発とは別に、不具合修正用の短い手順を用意しています
- 方向を探す試作：何を作るべきか自体を確かめる段階では、仕様が毎日変わります。試作で方向が決まってから、本番に向けて仕様を書きます
- 仕様の更新を担う人がいない：コードだけが変わり、仕様が古いまま残ると、AIは古い仕様に合わせてコードを戻そうとします。仕様の更新を、誰の作業に含めるかを先に決めておきます
まとめ
- 仕様駆動開発（SDD）は、目的・範囲・制約・受け入れ基準を実装の前に書き、その仕様を基準にAIの実装を確かめる手法です
- TDDとは排他ではありません。受け入れ基準をテストで判定できる文で書くと、そのままテストの元になります
- Spec Kit（1.1.0）では、constitutionを1回決め、specify → plan → tasks → implement → converge の順に進めます
- 向くのは、AIに任せる範囲が広く、発注側と作るものを握る必要がある開発です。小さな修正や方向を探す試作には向きません
AIを使ったNext.jsの開発で、仕様をどこまで書くか、誰が更新するかを一緒に決めたい場合は、お問い合わせからご相談ください。ゼットリンカーでは、エンジニアが直接ヒアリングし、仕様の「範囲」と「作らないもの」をそろえてから見積もりと実装に入ります。
関連する記事です。
※本記事は、2026年10月6日時点の github/spec-kit のREADMEと対応ツールの一覧に基づいています。Spec Kitの手順名や対応ツールは更新されることがあります。
技術仕様・対象バージョンは本文と参照先をご確認ください。
最終更新：2026年10月6日
Next.js