仕様駆動開発（SDD）とは｜3つの文書で進める手順と向き不向き

仕様駆動開発（SDD）とは｜コードより先に仕様を固める開発プロセス

仕様駆動開発は、自然言語で書いた仕様を開発の中心に置き、そこからコード・テスト・ドキュメントの実装や更新を進める手法です。生成をAIに任せるか人が書くかは、この定義の外側にあります。GitHubが公開しているツールキットspec-kitのドキュメントでは、この思想を「仕様がコードに仕える（serve）のではなく、コードが仕様に仕える」という形で表現しています。実装が主、仕様が従という関係を逆転させたわけです。

マイクロソフトの開発者向けブログSpec-Driven Development: A Spec-First Approach to AI-Native Engineeringでも、構造化された仕様を人とAIの共通の正とし、先に合意してからAIに実行を加速させるという位置づけで説明されています。

「仕様がSSoT」とはどういう状態か

SSoT（Single Source of Truth＝唯一の正）とは、ある仕様について判断が割れたときに、必ずそこを見れば答えが決まる場所がひとつに定まっている状態を指します。

SDDでは、その場所をコードではなく仕様書に置きます。実装が仕様と食い違っていたら、直すのは原則としてコードのほうです。仕様を変えたい場合は、先に仕様書を更新してから実装をやり直します。

この「直す順番が決まっている」ことが、SDDの実質です。文書の枚数ではありません。

バイブコーディングとの違い

バイブコーディング（プロンプト中心で、動くまでAIと対話を繰り返す進め方）は、意図が頭の中とチャット履歴にしか残りません。動くものは早く出ますが、数か月後に別の人が仕様を再構成しにくい状態になりやすい、という課題があります。

SDDは、その意図を事前に外へ出します。対話のログではなく、レビューできる文書として残すところが違いになります。

どちらが優れているという話ではありません。使い捨てる前提の検証コードならバイブコーディングのほうが速く、長く保守する機能ならSDDのほうが後工程が軽くなります。

ミニFAQ：SDDを使うとプロンプトは不要になりますか

いいえ。仕様書は「何を作るか」を固定しますが、AIに渡す文脈の設計は別の技術として残ります。文脈の渡し方はコンテキストエンジニアリングとは｜プロンプトとの違いと実務で整理しています。

TDD・ウォーターフォール・アジャイルとの違い

結論から言えば、SDDはウォーターフォールの「先に決める」とアジャイルの「あとで直せる」を、仕様からの再生成でつないだ折衷案と捉えると位置づけを理解しやすくなります。手法としての定義はまだ固まりきっていないため、以下は業界標準の分類ではなく整理のための比較です。

TDDとの違いは「何を先に書くか」

TDDが先に書くのは、振る舞いを検証するテストコードです。SDDが先に書くのは、何を作るかを定義した仕様です。

抽象度が違うので、排他ではありません。仕様で受け入れ基準を決め、その基準をテストに落としてからRed-Green-Refactorを回す、という組み合わせは自然に成立します。TDDそのものの進め方はTDD（テスト駆動開発）とは｜進め方・向く場面と現場で続けるコツで扱っています。

ウォーターフォールとの違いは「仕様を直す前提があるか」

「先に仕様を書く」と聞くと、ウォーターフォールへの先祖返りに見えます。実際、工程の順番だけを見ればよく似ています。

違いは仕様を直したあとに起きることです。ウォーターフォールでは、設計書を直してもコードは人が追従させます。SDDでは、仕様を直したら実装計画を作り直し、AIに生成し直させることが前提に組み込まれています。つまり設計書の更新が「作業の起点」になるか「作業の記録」で終わるかの差です。

アジャイルとは併用できる

スプリント内のタスクをSDDの単位に合わせる、という使い方は無理なく成立します。スクラムのプロダクトバックログアイテムと、仕様の1単位を対応させるイメージです。各フレームワークの前提はアジャイル開発とは｜仕組み・スクラム・ウォーターフォールとの違いにまとめています。

仕様駆動開発の進め方｜3つの文書と4ステップ

主要なSDDツールは呼び名こそ違うものの、人が合意する成果物は3つに集約されます。AWSが公開しているKiroのSpecsドキュメントでは、要件を書くrequirements.md、技術アーキテクチャを書くdesign.md、実装計画をタスクに分けたtasks.mdという3ファイルが生成されます。spec-kitでも、仕様・計画・タスクという同じ3段構えです。

ステップ1：要件（何を作るか・何を作らないか）

ユーザーストーリーと受け入れ基準を書きます。ここで技術の話は書きません。

実務で効くのは、作らないものを明記することです。スコープ外を1行も書いていない要件は、AIに渡した瞬間に余計な機能を生やします。「今回は管理画面を作らない」「多言語対応はしない」と書いておくだけで、生成物のブレがかなり減ります。

ステップ2：設計（どう作るか）

アーキテクチャ、データモデル、外部インターフェース、エラー時の扱いを書きます。粒度の目安は、別のエンジニアが読んで実装方針で迷わない程度です。クラス単位まで書く必要はありません。

設計文書の項目立てで迷う場合は、従来の設計書の作法がそのまま使えます。基本設計書の書き方｜項目一覧・粒度の判断基準と詳細設計書との違いが参考になります。ドメインの切り方で悩むならドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころの戦略設計の考え方と相性がよいでしょう。

ステップ3：タスク分解

設計を、順番に実行できる単位へ割ります。並行して進められるタスクには印をつけておくと、複数のエージェントに割り振るときに扱いやすくなります。

ここで出たタスクの粒度は、そのまま見積もりの単位にも使えます。見積もり根拠の作り方は工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターンを参照してください。

ステップ4：実装と検証

タスクを順に実装させ、受け入れ基準に照らして検証します。ここで仕様との差分が出たら、コードを直すのか仕様を直すのかを毎回決めます。この判断を記録に残さないと、あとで「どちらが正しかったのか」が分からなくなります。

EARS記法で要件の曖昧さを減らす

要件の文がぶれると、生成物もぶれます。対策として知られているのがEARS（Easy Approach to Requirements Syntax）です。

EARSはロールス・ロイスのAlistair Mavin氏らが航空エンジン制御システムの要求分析の中で考案し、2009年の要求工学の国際会議で発表されました。公式の解説ページでは、常時・状態・イベント・オプション・望ましくない挙動などのパターンに沿って、節の順序とキーワードを固定する書き方が示されています。

「ユーザーがログインボタンを押したとき、システムは認証処理を実行しなければならない」のように、トリガーと主語と動作を定型に押し込む形です。自然言語のまま、解釈の揺れだけを削れるところが利点になります。

ツールは手段。プロセスを先に決める

SDDを支援するツールは複数ありますが、どれを選んでも先ほどの3文書と4ステップは変わりません。spec-kitはMITライセンスで公開されており、2026年10月時点のリポジトリ表示では14万件台のスターが付いています（スター数は日々変動するため、最新値は公式リポジトリで確認してください）。Kiroは専用IDEとして同じ流れを提供します。汎用のコーディングエージェントでも、文書の置き場所と更新ルールさえ決めれば同じ進め方は再現できます。

ツール単体の機能比較はAIコーディングエージェント比較｜Cursor・Claude Code・Clineの選び方とClaude Codeとは｜使い方・料金プラン・案件動向を解説に譲ります。先に決めるべきなのは、仕様をどこに置き、誰が承認し、どの頻度で更新するかというルールのほうです。

ミニFAQ：3つの文書は毎回すべて作る必要がありますか

いいえ。変更が1ファイルで終わるバグ修正まで3文書を作ると、形骸化しやすくなります。小〜中規模のWeb開発での一例としては、実装が3ファイル以上にまたがる、または関係者が2人以上いる変更から要件と設計を書き、それ未満はタスクの箇条書きに留める切り方があります。チームの規模や保守期間によって線引きは変わるため、運用しながら調整してください。

SDDが向く案件・向かない案件

判断に使える軸は5つあります。該当が多いほどSDDの効果が出やすくなります。

向かない場面を無理に当てはめないことも実務では重要です。探索フェーズで3文書を作り込むと、捨てる前提の文書にレビュー工数を払うことになります。方向性が定まった時点で仕様に起こす、という順番でかまいません。

フリーランスエンジニアがSDD案件で確認すべきこと

ここからは、SDDを採用している現場へ業務委託で入る場合の論点です。社員として導入を進める立場とは、確認すべきポイントが変わります。

契約形態と「仕様書」の扱いを先に確認する

準委任と請負では、作った仕様書の位置づけが変わります。請負で「仕様書も納品物に含む」と読める書き方になっていると、実装が完了していても仕様書の体裁で検収が止まることがあります。

契約前に確認しておきたいのは次の3点です。

1. 要件・設計の文書が契約上の成果物に含まれるか

2. 含まれる場合、どの粒度・どの形式をもって完成とみなすか

3. 仕様変更が生じたときの追加作業の扱い（稼働時間の増加として精算するのか、範囲内とみなすのか）

条項の読み方そのものは業務委託契約書の確認ポイント｜フリーランスエンジニアが締結前に見る条項とチェックリストに整理しています。個別の契約で判断に迷う場合は、専門家への確認も検討してください。

稼働の内訳が変わることを見積もりに織り込む

SDDでは、実装に充てていた時間の一部が仕様の作成とレビューに移ります。総量が減るかどうかはチーム次第ですが、内訳は確実に変わります。

稼働を時間で精算する準委任なら大きな問題にはなりません。一方、機能単位で金額を決める契約の場合、仕様作成の工数を見込まずに金額を出すと持ち出しになります。導入初期の数機能については、仕様の確定にかかる時間を見積もりへ明示的に積むことを勧めます。

客先が未導入なら「全面導入」を提案しない

プロセスの刷新は、外部から入った人間が最初に手をつけると反発を受けやすい領域です。現実的なのは、自分の担当範囲だけで要件と受け入れ基準を文書化し、レビューを1回通してもらう進め方です。

そこで手戻りが減った実感が共有できてから、チームへ広げるかどうかを客先に判断してもらいます。順番を逆にすると、ツール導入の話にすり替わって終わります。

評価・単価への反映

仕様を書いて合意を取る工程は、実装だけを請け負う役割より上流に位置します。上流工程を任せられる人材として扱われるかどうかは、案件のレンジに影響することがあります。ただし単価は技術領域・稼働条件・商流でも変わるため、SDDの経験だけで決まるものではありません。

スキルシートには「SDDの経験あり」とだけ書くより、どの文書を誰と合意し、どこまでの変更を自分が判断したかを書いたほうが伝わります。上流スキルの積み上げ方はエンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップで段階別に整理しました。

単価レンジの考え方そのものは【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとまっています。いま自分がどのレンジを狙えるかを知りたい場合は、無料のフリーランスエンジニア単価診断で目安を確認できます。参画できそうな案件を具体的に見たい方は案件一覧もあわせてどうぞ。

ケース別｜SDDの始め方

ケース1：一人で開発している

3文書をフルセットで作る必要はありません。要件と受け入れ基準だけを1ファイルに書き、設計はアーキテクチャの決定事項を箇条書きで残す程度から始めます。

一人開発で効くのは、むしろ過去の自分への引き継ぎとしての効果です。2週間空けて戻ってきたとき、仕様が残っているかどうかで再開の速度が変わります。

ケース2：既存プロダクトへ後付けする

既存コード全体の仕様を起こそうとすると、まず終わりません。新規に追加する機能からSDDを適用し、既存部分は触るたびに少しずつ仕様を書き足していく進め方が現実的です。

このとき、生成された仕様が既存実装と食い違っていないかは人が確認する必要があります。AIに既存コードを読ませて仕様を書かせる場合、もっともらしい誤りが混ざるため、ハルシネーション対策｜LLMの誤回答を減らす実装と運用設計で触れている検証の考え方が役立ちます。

ケース3：複数人＋複数エージェントで動かす

タスク分解の粒度と、並行実行できるタスクの印が効いてきます。担当の境界が曖昧なまま並行させると、同じファイルの取り合いが起きます。

複数エージェントを前提にした分担設計はマルチエージェントとは｜設計パターン5つと単一エージェントの違いで扱っています。

よくある失敗と対策

失敗1：仕様書とコードの二重管理で破綻する

もっとも多い崩れ方です。急ぎの修正でコードだけ直し、仕様の更新を後回しにする。これが数回続くと、仕様書は「読んではいけない古い情報」に変わります。

対策はシンプルで、少なくとも仕様に影響する変更では、仕様を更新しないプルリクエストを通さない運用にすることです。レビュー観点に1項目足すだけで済みます。緊急の障害対応や軽微な修正まで条件に含めると運用が詰まるため、例外の扱いは先に決めておいてください。加えて、週1回でよいので仕様と実装の差分を棚卸しする時間を取ると、ずれが溜まりません。

失敗2：仕様書が増えすぎて「正」が分からなくなる

機能ごとに仕様を切っていくと、似た記述が複数のファイルに散らばります。どれが現行かを判断できなくなった時点で、SSoTは成立していません。

索引になるファイルを1つ決め、そこから辿れないものは参考資料として別ディレクトリへ落とす。機械的な整理ですが、これだけで迷子はかなり減ります。

失敗3：仕様を細かく書きすぎる

受け入れ基準に画面の文言やマージンまで書き込むと、更新コストが実装コストを超えます。仕様に書くのは変わったら合意し直す必要があるものに絞ります。実装の都合で変えてよいものは、仕様ではなくコードに置いたほうが保守が楽です。

失敗4：ツール導入をゴールにしてしまう

SDD対応のIDEを入れただけでは何も変わりません。決めるべきは、仕様の置き場所、承認者、更新のタイミングという運用のルールです。ツール選定はそのあとで構いません。

実践チェックリスト

着手前と運用中に分けて確認します。

着手前

• この変更にSDDを適用するか判断したか（3ファイル以上または関係者2人以上が目安）

• 要件に「作らないもの」を1行以上書いたか

• 受け入れ基準が、第三者が合否を判定できる書き方になっているか

• 仕様の置き場所と承認者が決まっているか

• 契約上、仕様書が成果物に含まれるかを確認したか（業務委託の場合）

運用中

• 実装と仕様がずれたとき、どちらを直すか毎回決めているか

• 仕様を更新しないまま実装だけ変えたプルリクエストが混ざっていないか

• 週1回、仕様と実装の差分を見る時間を確保しているか

• 仕様ファイルの索引が最新か

• AIが生成した仕様を、人がレビューしたうえで確定しているか

まとめ

仕様駆動開発とは、コードより先に仕様を固め、その仕様を唯一の正として扱う開発プロセスです。ツールの導入ではなく、直す順番を決める運用の話だと捉えると判断を誤りません。

• 人が合意する文書は要件・設計・タスクの3つ。ツールが変わっても構成は変わらない

• TDDとは先行させる対象が違い、排他ではなく併用できる

• ウォーターフォールとの違いは、仕様を直して作り直す前提が組み込まれているかどうか

• 適用の目安は、実装が3ファイル以上にまたがるか、関係者が2人以上いるか

• 短命なPoCやプロトタイプでは、仕様の維持コストが回収できないことがある

• 失敗の中心は仕様の二重管理。仕様を更新しないプルリクエストを通さない運用で防ぐ

• 業務委託で参画する場合は、仕様書が契約上の成果物に含まれるかを着手前に確認する

まずは、担当している案件が「長く保守するか」「合意する相手が複数いるか」の2点で適用可否を判断してください。そのうえで、直近に実装した機能をひとつ選び、要件と受け入れ基準だけを後追いで書いてみることを勧めます。書けない箇所が出たら、そこが合意の抜けていた部分です。

参照した一次情報は次のとおりです。

• github/spec-kit（GitHub）

• Spec-Driven Development: A Spec-First Approach to AI-Native Engineering（Microsoft for Developers）

• Specs（Kiro 公式ドキュメント）

• EARS（Alistair Mavin）