SDD（仕様駆動開発）とは？AIコーディングを仕様で制御する開発手法を解説

こんにちは、大平です。

ここ数か月、経営者や開発責任者の方から「SDDというものが流行っていると聞いたが、何なのか」と質問される機会が増えました。 SDD（Spec-Driven Development、仕様駆動開発）とは、AIにコードを書かせる前に仕様を文書として確定させ、その文書を基準に実装と検証を進める開発手法です。思いつくままにプロンプトでAIへ指示するvibe coding（バイブコーディング）の限界が見え始めたことを受けて、その次の進め方として2026年に入ってから急速に注目されています。この記事では、SDDの定義と仕組み、注目される背景、代表的なツールであるSpec KitとKiro、そして導入判断の考え方までを、現場でAI駆動開発を回している立場から解説します。

SDD（仕様駆動開発）とは何か

SDDを一言でいえば、「AIへの指示を、会話ではなく文書にする」開発手法です。

これまでのAIコーディングは、チャットでAIに指示を出し、返ってきたコードを見て、また次の指示を出す、という会話の往復で進むのが普通でした。この進め方には構造的な弱点があります。何を作ろうとしていたのか、どんな制約があったのかという情報が会話の中に埋もれ、コード以外のどこにも残らないことです。翌週に同じ機能を直そうとしたとき、頼りになるのは生成されたコードと人間の記憶だけになります。

SDDはこの順序を入れ替えます。コードを書く前に、仕様（何を、なぜ作るか）、計画（どう作るか）、タスク（どの順で作るか）を文書として作成し、人間がレビューしてからAIに実装させます。これらの文書はソースコードと同じリポジトリに置かれ、同じようにバージョン管理され、プルリクエストでは実装コードとセットでレビューされます。仕様書が実装の唯一の基準（source of truth）になり、コードは仕様から導かれる成果物になる、という関係の逆転が「仕様駆動」という名前の由来です。

仕様が使い捨てのプロンプトではなく、コードと同格の成果物になる。これがSDDの中心にある考え方です。

なぜ今SDDが注目されるのか

背景には、vibe codingの限界があります。

2025年ごろから、細かいことは決めずにAIと対話しながら動くものを高速に作るスタイルとして、vibe codingが世界的に広まりました。プロトタイプが数時間で形になる体験は衝撃的で、僕自身もこの進め方の恩恵を受けてきました。ただ、実務のプロダクト開発に持ち込むと、別の顔が見えてきます。

AIは実装を速くしますが、要件の曖昧さは埋めてくれません。曖昧な指示を受けたAIは、学習した「よくあるパターン」でスキマを埋め、それらしく動くものを返してきます。動いているので要件が固まったように錯覚しますが、AIが埋めたのは一般論であって、その事業に固有の業務ルールや例外ではありません。人間だけで開発していた時代は、手を動かすのが遅いこと自体がブレーキになり、途中で仕様のおかしさに気づく余地がありました。 AI駆動開発ではこのブレーキが効かず、ズレた成果物と手戻りがこれまでより速く積み上がります。

品質面の数字もあります。セキュリティ企業Veracodeの調査（2025 GenAI Code Security Report）では、素のAIモデルが生成したコードの45%にOWASP Top 10の脆弱性が含まれていました。この数字はレビューもテストも通していない生の出力を測ったものであり、実務での欠陥率は、モデルの周りにどんな工程を組むかで決まります。 SDDは、この「工程の設計」を仕様起点で型化したものだと捉えると分かりやすいはずです。

検索データに見る、日本でのSDDの立ち上がり

面白いのは、この動きが日本で先に立ち上がっていることです。

僕はAI駆動開発まわりの検索トレンドをGoogle Trendsで定点観測しています。日本語の「Spec駆動開発」という検索語は、2026年5月から6月にかけて、ほぼゼロの状態から急に立ち上がりました。関連クエリには「spec kit」「kiro」「sdd」が並び、「AI駆動開発」の関連語でも「とは」「入門」という定義を求める検索が上位に来ています。

同じ観測では、AI駆動開発の関連トピックとして入門書や教科書が急上昇しており、手探りの実験期から、体系立てて学ぶ時期へ移り変わりつつあることも読み取れます。

一方、英語圏の「spec-driven development」の検索量は、vibe codingの10分の1以下にとどまっています（2026年7月時点の観測で、値は相対値です）。世界はまだvibeが主流で、日本では仕様回帰が先に検索行動として現れている。この非対称が定着するのか、日本のエンジニアコミュニティの議論が一時的に先行しているだけなのかは、まだ分かりません。ただ、少なくとも日本の開発現場でSDDが「知っておくべき語」になったことは、データから言えます。

Spec Kitに見るSDDの進め方

では、仕様を挟む開発は具体的にどう進むのか。ここでは代表的なツールであるGitHubのSpec Kitを例に取ります。

Spec Kitを導入すると、手持ちのコーディングエージェントに6つのコマンドが追加され、この順番で開発を進めます。

順	工程	やること
1	constitution	プロジェクトの原則と制約を定義する
2	specify	機能の「何を、なぜ」を仕様書にする。技術の話はまだ書かない
3	clarify	AIが仕様の曖昧な点を逆質問し、仕様書を更新する
4	plan	ここで初めて技術選定と設計を行う
5	tasks	依存関係つきでタスクに分解する
6	implement	タスクを順に実装する

型として面白いのは3のclarifyです。人間が仕様を完璧に書き切るのではなく、AIの側から「この場合はどうしますか」と質問させて曖昧さを潰していく。要件定義の壁打ちが、属人的なスキルではなく工程として組み込まれているわけです。

もう一つの特徴は、6のimplementが、前段の成果物がそろっていないと実行を拒否することです。仕様と計画を飛ばしていきなり実装へ入るショートカットが、仕組みとして塞がれています。機能ごとに専用のブランチと仕様フォルダが切られるため、プルリクエストには仕様書と実装コードが一緒に載り、レビューする側は「仕様は妥当か」と「実装は仕様どおりか」を分けて確認できます。

SDDの主なツール（Spec KitとKiro）

2026年7月時点で、SDDのツールとして名前が挙がるのは主に2つです。

Spec Kit：GitHubが公開しているOSSで、無料です。本体はコードを書かず、テンプレートとコマンド群をリポジトリに配置するだけで、実行エンジンには手持ちのコーディングエージェント（Claude CodeやCopilotなど30種類以上に対応）をそのまま使います。セットアップもCLIを1つ入れて初期化するだけで、既存の開発環境を変えずに足せるのが利点です。

Kiro：AWSが提供するSpec駆動のIDEです。エディタ自体に仕様作成から実装までのワークフローが組み込まれており、無料枠つきの有料プランで提供されています。

このほかBMADのようなOSSの手法・ツールも次々に登場しており、入れ替わりの激しい領域です。すでにClaude CodeやCopilotを使っているチームなら、環境を変えずに試せるSpec Kitから触るのが現実的だと思います。どのツールも発展途上で更新が速いため、ツール選定に時間をかけるよりも、「仕様を挟む進め方」自体にチームが慣れることを優先した方がよい段階です。

TDDやウォーターフォールとの違い

仕様を先に固めてから作る、と聞いて「ウォーターフォールへの逆戻りではないか」と感じた方もいるはずです。

違いは仕様の単位と寿命にあります。ウォーターフォールはシステム全体の仕様を最初に確定させ、実装までに数か月単位の距離があります。 SDDが仕様化するのは機能1つぶんで、仕様から実装までのサイクルは数時間から数日です。仕様書は変更禁止の契約書ではなく、clarifyや実装の過程で更新され続けるドキュメントとして扱われます。アジャイルの反復の中に、仕様という中間成果物を挟み直した手法、と捉える方が実態に近いです。

TDD（テスト駆動開発）とも混同されがちですが、対立する概念ではありません。 TDDはテストコードに仕様の役割を持たせて先に書く手法で、SDDは自然言語の仕様書を起点に置き、テストはそこから導きます。仕様書に受け入れ条件を書き、それをTDDで実装する、という併用も普通に成り立ちます。

従来の設計書を使った開発と比べたときの違いは、仕様書の読み手にAIが含まれることです。人間向けの設計書は多少曖昧でも行間や口頭で補えますが、SDDの仕様書はAIがそのまま実装の入力に使うため、曖昧さがそのまま成果物のズレになって返ってきます。だからこそ、clarifyのように曖昧さを機械的に潰す工程が型へ組み込まれているのです。

SDDはどこから始めるべきか

すべての開発をSDDにする必要はありません。向き不向きがはっきりある手法です。

向いているのは、複数人や複数のAIエージェントが並行して開発する場面、引き継ぎとレビューが前提になるプロダクト開発、業務ルールや例外の多い業務システムです。仕様が文書として残ることの価値が、書く手間を上回ります。逆に、一人で使い捨てのプロトタイプを探索的に作るなら、vibe codingで十分です。成果物の寿命が長いか、関わる人数（エージェント数）が多いか、業務ルールが複雑か。この3つのうち2つ以上に当てはまるなら、SDDを試す価値があります。

試すコスト自体は高くありません。捨ててよいリポジトリを用意し、小さなCLIツール程度のお題でSpec Kitの6コマンドを1周する。所要は1〜2時間で、追加費用はコーディングエージェントの通常利用分だけです。

導入時のつまずきどころも書いておきます。よくあるのは、最初から本番プロジェクトの大きな機能に適用して、仕様書づくりの重さに耐えられず止まるパターンです。 SDDの仕様書は詳細設計書ではありません。書き込みすぎれば維持されなくなり、vibe codingより遅いだけの工程が残ります。まず小さなお題で1周し、自分たちのプロジェクトに必要な粒度を測ってから本番に持ち込む。この順番を守るだけで、導入のつまずきは減らせます。

実は、CodeKnightsでもSpec Kitの登場前から、プロジェクトの原則をリポジトリのルール文書に書き、定型の指示をテンプレート化するという自己流の仕様駆動をやってきました。 Spec Kitを触った実感は、「現場が各自で編み出していた工夫が、公式に標準化された」というものです。その意味でSDDは突飛な新手法ではなく、AI駆動開発の先行チームが既にやっていた工夫の共通言語化だと言えます。

SDDで人の役割はどう変わるか

SDDの工程のなかで、AIが代替できないのは仕様を書く部分です。曖昧な要求を整理し、業務ルールと例外を言語化し、受け入れ条件まで定義する。実装がAIへ移るほど、この力を持つ人の希少性が上がります。

仕様を書ける人は、経営と開発の翻訳者でもあります。事業上の狙いを開発可能な粒度へ落とし、技術上の制約を経営判断の言葉へ戻す。 SDDはこの往復を、個人の暗黙知ではなくリポジトリに残る文書として回す仕組みです。

つまりSDDの導入は、ツールの導入というより、仕様を書ける人材への投資という性格を持ちます。リードエンジニアやCTOが検討すべきは「どのツールを入れるか」よりも、「仕様を書く力を誰がどう身につけるか」です。ツールは1〜2時間で試せますが、仕様を切る力は一朝一夕には育ちません。検索データが示す通り、日本ではこの手法の立ち上がりが早い。先に型を持ったチームとそうでないチームの差は、これから静かに開いていくと見ています。