AIコーディングで「指示した内容と違うものができた」「直させたら別の場所が壊れた」という手戻りが続くなら、原因はモデルの性能より、指示の曖昧さにあることが多いです。仕様駆動開発（Spec-Driven Development、以下SDD）は、コードを書かせる前に仕様を書き、その仕様をAIの参照元にする開発手法です。

この記事では、定義と3段階の分類、代表ツールの違い、Claude Codeで日々回す手順と仕様書の書き方、そして向かない案件や失敗パターンまで扱います。後半では、国内企業が公開している実践報告から、うまくいった点とつまずいた点を拾います。

この記事でわかること

  • 仕様駆動開発の定義と、バイブコーディングとの違い
  • spec-first、spec-anchored、spec-as-sourceという3段階の考え方
  • Spec Kit、Kiro、OpenSpecなど代表ツールの違いと選び方
  • Claude Codeで仕様駆動開発を回す手順と、仕様書に書く項目の具体例
  • 向く案件・向かない案件の判断基準と、国内企業の実践から見えた落とし穴

仕様駆動開発は「コードより先に仕様を書き、AIの参照元にする」手法

仕様駆動開発とは、実装の前に仕様を書き、その仕様をもとにAIエージェントにコードの生成・テスト・検証をさせる開発スタイルです。仕様はコードの振る舞いに対する契約として扱われます。GitHubの公式ブログでも、仕様から始めて、エージェントが生成と検証の際にそれを参照する流れとして説明されています。

バイブコーディングが「会話で探る」のに対し、SDDは「先に決めて検証する」

バイブコーディングは、ふわっとした依頼を投げて、出てきたものを見ながら直していくやり方です（AI駆動開発とはも参照）。試作や使い捨てのスクリプトなら、これがいちばん速いです。

ただ、依頼に書かれていない要件を、モデルは推測で埋めます。エラー時の挙動、権限の扱い、既存コードとの整合といった部分で推測が外れると、手戻りになります。コーディングエージェントは検索エンジンのような相手ではなく、書かれたことを文字通りに解釈するペアプログラマーに近い、という捉え方が出発点です。

SDDでは、推測されたくない部分を先に文章にします。人間の役割も変わります。コードを書く人から、仕様を書いて出てきた結果を検証する人へ、重心が移ります。

なぜ今注目されているのか

理由は2つあります。ひとつは、AIがコードを書く速度が上がり、「何を作るか」の曖昧さが全体の足を引っ張るようになったこと。もうひとつは、AIとのやり取りが会話のログに散らばると、設計意図が誰にも残らないことです。

国内では、AWSのKiroがSDDを前面に出したことをきっかけに、複数のメディアで取り上げられるようになりました。複雑な業務システムでバイブコーディングだけに頼ると仕様管理が追いつかない、という文脈で紹介されることが多いです。

正直なところ、当協会では「新しい手法」というより、要件定義と設計をAI時代の形に直したものと考えています。だから、昔の設計書がたどった運命も同じようにたどりかねません。この点は後半の「批判」と「失敗パターン」で扱います。

3段階の分類で「どこまでやるか」を決める

SDDと呼ばれるものには、仕様をどれだけ重く扱うかで3つの段階があります。この整理はMartin Fowlerのサイトに載った分析で広まりました。

段階仕様の扱い人間が編集するもの現実の採用状況
spec-first最初にしっかり書き、そのタスクの実装に使う仕様とコードの両方ほぼすべてのツールがここに該当
spec-anchoredタスク後も仕様を残し、機能の改修・保守にも使う仕様とコードの両方少数。仕様を維持する戦略が曖昧
spec-as-source人間は仕様だけを編集し、コードは生成物になる仕様のみ探索段階。モデル駆動開発の再来という懸念もある

多くのチームが実際にやっているのはspec-firstです。まずここから始めるのが現実的で、spec-anchoredに進むかどうかは「仕様を最新に保つ運用が回るか」で決まります。spec-as-sourceは、仕様が硬直しやすいこととAIの出力が毎回同じとは限らないことが重なる懸念があり、今は様子見で足ります。

Spec KitやKiroなど仕様駆動開発ツールは「進め方の重さ」で選ぶ

主要ツールの違いは、機能の多さより、手順の重さと仕様の置き場にあります。2026年10月時点で押さえるのは、Spec Kit、Kiro、OpenSpec、cc-sddの4つです。

ツール形態進め方向く場面
Spec KitGitHubのOSS（MIT）。Claude Code、GitHub Copilot、Gemini CLIなど複数のエージェントに対応原則 → 仕様 → 計画 → タスク → 実装の段階をスラッシュコマンドで進める新規開発。手順を型にはめたいチーム
KiroAWSのエージェント型IDE／CLI要件 → 設計 → タスクの3ファイルを承認しながら進める受け入れ基準を厳密に書きたい案件
OpenSpecOSS（MIT）。30以上のAIアシスタントに対応変更ごとのフォルダで提案 → 実装 → アーカイブ既存システムへの段階導入
cc-sddKiro流の進め方をClaude CodeやCodexなどで使うOSS要件 → 設計 → タスクKiroのワークフローをエディタ非依存で使いたいとき

Spec Kitは手順がコマンドになっている

Spec Kitでは、プロジェクトに1回だけ原則（憲法）を定め、機能ごとに /speckit-specify、/speckit-plan、/speckit-tasks、/speckit-implement と進みます。実装と検証を Converged になるまで繰り返す /speckit-converge もあります。

仕様の段階では「何を・なぜ」だけを書き、技術スタックは計画の段階まで持ち越します。曖昧な点には [NEEDS CLARIFICATION] というマーカーを残すテンプレートで、AIが勝手に推測するのを防ぎます。

一方で、中規模の機能に使うとオーバーキルになりやすいという評価もあります。生成されるMarkdownが多く、仕様よりコードを読むほうが早く感じる場面があるためです。

Kiroは受け入れ基準を型にはめる

Kiroは、機能ごとに requirements.md、design.md、tasks.md を作ります。要件はEARS記法という「WHEN〜 THE SYSTEM SHALL〜」の形で書く受け入れ基準です。バグ修正用の仕様、承認ゲートなしで3ファイルを一気に作る簡易モードもあります。

恒久ルールは .kiro/steering/ に product.md、tech.md、structure.md として置きます。AGENTS.md も読み込むので、他のエージェントとコンテキストを共有できます。

OpenSpecとcc-sddは既存の開発環境に足しやすい

OpenSpecは、変更ごとにフォルダを切って提案・仕様差分・設計・タスクを置き、完了時にアーカイブして仕様本体を更新します。すでに動いているシステム（brownfield）に、機能単位で少しずつ入れられるのが利点です。

cc-sddはKiro流の「要件→設計→タスク」を、Claude CodeやCodexで使えるようにしたOSSです。日本語での利用（--lang ja）にも対応しており、国内ではWHITEPLUSなどが導入を報告しています。

なお、Tesslは当初、仕様だけを編集してコードを生成物にするspec-as-sourceを探索していました。2026年10月時点の公式サイトは、Skills、Loops、Evalsなどを束ねた基盤として自社を説明しており、SDDフレームワークとしての現状は公式発表では確認できていません。

Claude Codeで仕様駆動開発を回す手順

Claude Codeには、SDD専用の公式機能はありません。ただし、Plan mode、インタビューからの仕様作成、サブエージェントによる照合、フックによる検証といった部品はそろっています。これらを組み合わせると、Spec Kitなどを入れなくても軽量なSDDは回せます。Claude Code自体の概要はClaude Codeとはで整理しています。

恒久ルールと機能仕様を別ファイルに分ける

最初に決めるのは、情報の置き場です。

CLAUDE.md は毎セッション読み込まれる常時文脈です。ここに入れるのは、ビルドとテストのコマンド、コーディング規約、触ってはいけない領域のように、どの機能でも変わらないルールだけ。長くすると指示が無視されやすくなるため、消してもミスしない行は削ります。育て方はCLAUDE.mdの育て方で解説しています。

機能ごとの仕様は SPEC.md のような別ファイルに置きます。時々しか必要ない手順や知識は、Agent Skillsに切り出します。「恒久ルールはCLAUDE.md、機能の仕様はSPEC.md、必要なときだけ読む手順はSkills」という分担が、SDDとの相性がよい形です（この対応づけは当協会の整理です）。

8つのステップで回す

実際の流れは次のとおりです。Claude Code公式が推奨する「調べる → 計画する → 実装する → コミットする」を、仕様の観点で細かくしたものです。

  1. CLAUDE.mdを整える: テストコマンドと規約、触らない領域を書きます。機能仕様は入れません
  2. Plan modeで調べる: Shift+Tab で切り替えるか claude --permission-mode plan で起動します。読み取り専用で、承認するまでファイルは編集されません
  3. インタビューさせて仕様を書かせる: 大きな機能は、Claudeに質問させながら SPEC.md を書かせます
  4. 人間が仕様を読んで直す: 曖昧な点、スコープ外、未確定事項を人間が確定させます。いちばん時間をかけるべき工程です
  5. 新しいセッションで実装する: 仕様作成時の会話を引きずらず、SPEC.md を読み込んだ状態で始めます
  6. 検証手段を持たせる: テスト、型チェック、リンターの合否をClaude自身が確認できるようにします
  7. サブエージェントで仕様と差分を照合する: 実装漏れ、エッジケースのテスト不足、スコープ外の変更を見つけさせます
  8. 仕様の更新をコードと同じPRに含める: 実装中に変わった判断は SPEC.md に戻します

3の依頼文は、たとえば次のようになります。

通知設定画面に「メール通知の頻度」を追加したい。実装はまだしないでください。AskUserQuestionで私に質問しながら、目的、スコープ内外、受け入れ基準、エッジケースを詰めて、SPEC.mdにまとめてください。

7の照合は、次のように依頼します。

SPEC.mdと現在のdiffを照合して、実装されていない要件、テストされていないエッジケース、仕様にない変更を挙げてください。

照合で上がった指摘を全部直すと過剰設計になる、とClaude Code公式も注意しています。直すのは仕様に紐づく指摘だけにして、好みの問題は無視する、くらいがちょうどいいです。

差分を一文で説明できるほど小さい変更なら、計画自体を省きます。仕様を書く手間が、実装より重くなるからです。

仕様書に書く項目と、受け入れ基準の例

仕様書の項目は、各ツールの共通部分を取り出すと次の形に収まります。

項目書く内容書かないこと
目的・背景誰のどんな課題を解くか実装方法
スコープ内／外今回やること、やらないこと「など」で濁した範囲
受け入れ基準条件と期待結果のペア「使いやすいこと」のような主観
エッジケース空入力、権限なし、通信失敗など正常系だけの記述
非機能要件応答時間など数値で測れるもの「高速に」の一言
未確定事項まだ決まっていない点を明示推測で埋めた断定
検証手順最後に確認するE2Eの流れ検証なしの完了宣言

スコープ外の欄は、AIが親切心で余計な修正を足す事故を防ぎます。最初にこの欄を埋めておくと、仕様全体の輪郭が決まりやすくなります。

受け入れ基準は、EARS形式なら次のように書きます。

## 受け入れ基準
- WHEN ユーザーが頻度を「毎日」に変更して保存したとき、THE SYSTEM SHALL 翌日0時から日次の通知メールを送る
- WHEN 保存に失敗したとき、THE SYSTEM SHALL 入力値を保持したままエラーメッセージを表示する
- IF ユーザーのメールアドレスが未認証の場合、THEN THE SYSTEM SHALL 頻度の変更を受け付けず、認証を促す

## スコープ外
- 通知文面の変更
- 管理者向けの一括設定

## 未確定事項
- [NEEDS CLARIFICATION] 週次の送信曜日をユーザーが選べるか

GIVEN-WHEN-THENの形でも構いません。どちらの書式でも、条件と結果がテストコードにそのまま写せる粒度になっていれば役目を果たしています。

完了を人間の目視ではなくゲートで判定する

エージェントは、検証手段がなければ「完了しているように見えること」を成功の合図にしてしまいます。テストの合否を返す仕組みを与えるのが、最も効く対策です。

Claude Codeでは、Stopフックで終了時に検査を走らせたり、/goal で検証条件を満たすまで継続させたりできます。この種の仕組みづくりはハーネスエンジニアリングの領域です。仕様に「検証手順」を書いておけば、そのままゲートの設計図になります。

仕様の書き方、CLAUDE.mdの設計、レビューの運用は、読んで理解してもすぐにはできません。チームで実務演習を通して身につけたい場合は、Claude Code研修が手段になります。

仕様駆動開発が向く案件・向かない案件は規模で決まる

SDDは万能ではありません。仕様を書くコストが、手戻りを減らす効果を上回る案件では逆効果になります。判断軸は、変更の規模、設計意図を共有する必要性、既存コードの複雑さの3つです。

規模別の使い分け

案件推奨理由
小さなバグ修正、文言変更仕様なし。Claude Codeにそのまま依頼仕様を書くほうが実装より重い
中規模の機能追加軽量な SPEC.md ＋ Plan mode目的、スコープ外、受け入れ基準だけで足りる
複数人・複数リポジトリにまたがる機能Spec Kit、Kiro、OpenSpecなど手順つきのツール設計意図を共有し、レビューを段階化する必要がある
既存の大規模システムOpenSpecで変更単位に導入全体の仕様を後から書き起こすのは現実的でない
試作、使い捨てスクリプトバイブコーディング捨てるものに仕様は要らない

向く条件を言い換えると、AIが暗黙の前提を外しやすい案件、複数人で設計意図を揃えたい案件、走りながら考える文化のチームです。向かないのは、知識が会話だけで伝わる少人数のチームや、すでに完全なウォーターフォールで設計書が二重になる組織です。

批判は「ウォーターフォールの再来」に集約される

SDDへの批判は、ほぼ一点に集まります。仕様を最初に固める以上、ウォーターフォールの繰り返しではないか、という指摘です。

Marmelabの記事は、文脈を見ない、Markdownが多すぎる、二重レビューになる、安心感が偽物になる、大規模な既存コードでは非現実的、とまとめています。ThoughtworksのTechnology Radarでも、SDDは試して評価する段階（Assess）に置かれ（2025年11月版。現行版には掲載されていません）、冗長な仕様ファイルがレビューしにくい点と、AIへの詳細ルールを手作りする方法が最終的にスケールしない点が懸念されています。

反論もあります。SDDは全体を一度に作り込む設計ではなく、小さな仕様を作って実装し、また書くという短いサイクルだ、という見方です。サイクルが短ければ、ウォーターフォールの弱点だった変更への鈍さは生じにくくなります。

ここは立場が分かれます。当協会では、1回に書く仕様の大きさを絞れば別物になると考えます。仕様を数日分の機能ごとに区切り、分厚い設計書を最初に一式作らない。これが守れなければ批判のとおりになります。

失敗パターンは4つに絞れる

実践報告と批判に共通する失敗は、次の4つです。

  • レビュー負荷: 生成されたMarkdownが長く、読む時間が実装時間を超える
  • 仕様と実装の乖離: 実装中に変わった判断が仕様に戻らず、仕様が古くなる
  • エージェントが仕様を無視する: 既存クラスを重複して作る、テストを書かずに完了扱いにする
  • 上流への偏り: 仕様ばかり整えて、検証や運用が手薄になる

対策もあります。レビュー対象を要約文書に絞る、仕様の変更をすぐ主ブランチにマージする、仕様の更新をPRテンプレートやCIで強制する、手書きのドラフトを推論モデルに精緻化させる、といった方法です。

国内企業の実践報告が共通して示すこと

国内でも公開事例が増えています。いずれも自社ブログでの報告で、工期や手戻りを数値で示したものはありません。

企業ツールと規模うまくいった点つまずいた点と対策
Hacobell約3か月運用設計意図がチームに残る仕様が大きくレビューに時間がかかった。要約文書の導入と、毎日1時間のモブでのレビューで対処
Dress CodeOpenSpec、約4か月、仕様変更43件、開発者12人中9人が使用要件の明確さが向上全体として速くなった感覚はなく、AI生成のGIVEN/WHEN/THENは人間に読みにくい
WHITEPLUScc-sdd手戻りの減少と意図の一致非エンジニアとの要件の二重管理、コードの直接編集を止める仕組みがない
KAKEHASHIOpenSpec、6リポジトリ、エンジニア4名導入約3週間で、体感として予定より先行仕様の変更をすぐ主ブランチにマージする運用で乖離を抑制

4社に共通するのは、「速くなった」より「意図が揃った」という報告が中心なことです。速度の話は体感止まりで、レビュー負荷の増加を訴える報告と並んで出てきます。

当協会の読みでは、SDDの効果は実装の速さではなく、手戻りの種類が変わることにあります。実装後に「違う」と気づく手戻りが、仕様レビュー段階の手戻りに前倒しされるのです。前倒しした分が安くつくかどうかは、仕様のレビューを回せる体制があるかで決まります。

よくある質問

仕様駆動開発とTDD（テスト駆動開発）は何が違いますか？

TDDは先に書くものがテストコードで、SDDは自然言語を中心にした仕様です。両者は併用できます。SDDの受け入れ基準を、そのままTDDのテストに落とせます。

Claude Codeで仕様駆動開発を始めるには、ツールが必要ですか？

必須ではありません。CLAUDE.md、SPEC.md、Plan modeがあれば軽量なSDDは回せます。複数人で手順を揃えたいときに、Spec Kitなどの導入を検討してください。

小さな修正でも仕様書を書くべきですか？

書かなくて大丈夫です。差分を一文で説明できる変更は、仕様を書く手間のほうが大きくなります。目的とスコープ外を数行で伝える程度で足ります。

Spec KitとKiroはどちらを選べばよいですか？

手順をコマンドで型にはめたい新規開発ならSpec Kit、受け入れ基準を厳密に書きたい案件ならKiroが向きます。まず軽量なSPEC.mdで試す方法もあります。

仕様の分量はどれくらいが適切ですか？

数日で実装できる機能1つ分を単位に、1〜2ページに収めます。読み切れない仕様はレビューされなくなり、実質的に存在しないのと同じになります。

まとめ

最初の一歩は、次の中規模な機能追加で、いつもの依頼文の前に「質問しながらSPEC.mdを書いてください」と頼むことです。ツールは要りません。目的、スコープ外、受け入れ基準の3項目だけでも、手戻りの出方が変わります。

それが回り始めたら、検証ゲートを足してください。テストの合否をClaude自身が確認できるようになると、仕様が「読むもの」から「検査できるもの」に変わります。複数人で運用する段階になって初めて、Spec KitやOpenSpecのような手順つきのツールを検討すれば間に合います。

仕様を書く力は、AIに指示する力そのものです。チームで揃えるなら、仕様の書き方、CLAUDE.mdの設計、仕様レビューの運用を実務演習で身につけるClaude Code研修をご検討ください。

次に読みたい関連記事