2026.08.24
スペック駆動開発（SDD） ― AI時代の仕様中心主義
- AI
- プロジェクト推進
- 技術戦略
Spec-Driven Development（仕様駆動開発）― AIDD時代の新しい開発スタイル
ソフトウェア開発の現場では、長らく「コードが正」でした。仕様書はあっても、実装が進むうちに乖離していきます。3か月後には仕様書とコードの中身が違っていて、誰も仕様書を見なくなります。これが多くの企業の実態でした。AIDDの普及によって、この構造が変わろうとしています。仕様書を一級のソースとして扱い、AIへの指示書として機能させる開発スタイル ― それが Spec-Driven Development（SDD）です。
GitHubが提唱した「Spec Kit」、Anthropicが推奨する「仕様駆動の対話設計」、各社のSDD実践など、流派は複数あるが共通する思想は同じ。仕様を中心に置き、コードは仕様の派生物と捉えます。本記事では、SDDの基本思想・実践フロー・適用範囲・落とし穴を整理します。
要点：SDDは「仕様＝指示書、コード＝結果」のパラダイム。AIDD時代に親和性が高く、仕様の陳腐化を構造的に防ぎます。ただし全領域に向くわけではなく、適用範囲の見極めが重要。
1. SDDが生まれた背景
従来の開発では、仕様書とコードは別々の世界に存在していました。仕様書はWordやConfluenceにあり、コードはGitにあります。両者を同期する仕組みは弱く、ほとんどの場合「コードが現実、仕様書はドラフトの遺物」になっていました。これは技術的な問題ではなく、経済合理性の問題 です。仕様書を維持するコストが、得られる便益を上回るから、誰も維持しません。
AIDD時代になって、この経済合理性が反転します。AIに実装を任せるなら、AIへの指示書として仕様書の価値が劇的に上がります。曖昧な指示で精度の低い実装が出てくるより、明確な仕様で精度の高い実装が出てくるほうが圧倒的に効率的です。仕様書を維持するコストが、AIによる実装精度向上で十分回収できるようになりました。
これがSDDの本質的な意味です。仕様書をAIへの「契約書」として位置づけることで、仕様の陳腐化を構造的に防ぎます。仕様が変わればAIに再実装させる。コードを直接いじるより、仕様を更新してAIに任せるほうが速い、という逆転が起きます。
従来 vs SDDのパラダイム比較
| 観点 | 従来の開発 | SDD |
|---|---|---|
| 仕様書の位置づけ | ドラフト・参考資料 | 一級のソース |
| 実装の決定権 | コード | 仕様 |
| 仕様書の更新頻度 | 開発初期のみ | 継続更新 |
| 仕様 vs コードの優先度 | コード優先 | 仕様優先 |
| AI活用の相性 | 補完的 | 中心的 |
| 監査・証跡 | コードのコメントから推測 | 仕様書が一次資料 |
2. SDDの基本思想
SDDの中核にある思想を一言で言えば、「仕様書はコードと同等以上に重要な成果物」 です。これを徹底すると、開発のあり方が大きく変わります。
第一に、仕様書のフォーマットを機械可読にします。MarkdownやYAML、OpenAPI仕様、JSON Schema、Gherkin（Given-When-Then）など、AIが読み取りやすい構造化フォーマットを使います。WordやPDFではなく、GitHubで管理します。これによって仕様書もバージョン管理・差分レビュー・CIの対象になります。
第二に、仕様書を契約として扱います。受け入れ条件（Acceptance Criteria）を明確に書き、AIにも人間にも何が完成かを定義します。「だいたいこんな感じ」では契約として機能しません。Given-When-Then形式の受け入れ条件は、テストとしても機能するため、SDDと相性がいいです。
第三に、仕様変更を仕様→実装の方向で行います。コードを直接修正するのではなく、まず仕様を更新し、そこから実装を再生成します。これによって仕様とコードの乖離を構造的に防ぎます。
3. なぜSDDがAIDD時代に有効か
AIDD時代におけるSDDの価値は、4つの観点で説明できます。
第一に、AIの精度は指示の明確さで決まります。曖昧な指示なら曖昧な実装、明確な仕様なら精度の高い実装が返ってきます。SDDは仕様を磨くことに開発リソースを集中させるため、AIの実装精度を最大化できます。
第二に、仕様変更が容易になります。仕様を更新してAIに「この新仕様で再実装して」と頼めば、影響範囲を含めて自動で対応できます。従来は仕様変更のたびに人間が全箇所を追って修正していたのが、AIに任せられる。
第三に、ステークホルダー対応がしやすいです。経営層や事業部長は仕様レベルで議論したいです。コードを見せても判断できません。SDDは仕様が一級なので、ステークホルダーが「これが仕様です」と確認できる対象が明確になります。
第四に、監査対応に強いです。規制業界や金融・医療では、「何を実装しているか」を文書で示す必要があります。SDDなら仕様書がそのまま監査証跡になります。コードのコメントから事後的に書き起こす必要がありません。
SDDが特に効果を発揮する4領域
| 領域 | 理由 |
|---|---|
| 規制業界（金融・医療・公共） | 監査証跡として仕様書が機能 |
| API中心のサービス | OpenAPI仕様が自然にSDDの形 |
| エンタープライズB2B | 顧客との契約書としても機能 |
| マルチベンダー開発 | 仕様が共通言語になる |
4. SDDの実践フロー
実務で機能するSDDのフローは、5ステップで整理できます。
Step 1：仕様の明文化（1〜3日）
ユーザーストーリー、受け入れ条件、データモデル、API仕様、UI仕様、非機能要件を、構造化フォーマットで書きます。ここで時間をかけることが、後の高速化につながります。
Step 2：仕様レビュー（半日〜1日）
ステークホルダー（事業部・法務・セキュリティ・運用）が仕様を確認し、合意します。この段階で議論を尽くします。
Step 3：AIによる実装（数時間〜数日）
仕様書をAIに渡し、実装を生成させる。Claude Codeなどのエージェントが仕様→コード変換を担います。
Step 4：仕様 vs 実装の検証（半日〜1日）
受け入れテストで仕様通りに動くか確認。仕様逸脱があれば、AIに再生成を依頼。
Step 5：継続更新（リリース後継続）
仕様変更があれば、まず仕様を更新→AIに再実装→検証、というループを回します。
SDDのフローと従来開発の時間比較
| ステップ | 従来開発 | SDD | 差分 |
|---|---|---|---|
| 仕様化 | 1日 | 3日 | +2日 |
| 設計 | 3日 | 0日（仕様に統合） | -3日 |
| 実装 | 10日 | 1日 | -9日 |
| テスト | 3日 | 1日 | -2日 |
| 修正・調整 | 5日 | 1日 | -4日 |
| 合計 | 22日 | 6日 | -16日（73%短縮） |
💡 ポイント：SDDは「仕様化に時間を投資して全体を短縮する」モデル。前倒しの投資が後工程の劇的な短縮を生みます。
5. 仕様書のフォーマット設計
SDDで使う仕様書のフォーマットは、機械可読性と人間可読性の両立が肝です。実務でよく使われる構成を紹介します。
# 機能名: 経費申請承認フロー
## 概要
社員が経費申請を提出し、上長が承認する基本フロー。
## ユーザーストーリー
- 社員として、領収書写真とともに経費申請を提出したい
- 上長として、申請を一覧で確認し、承認/却下したい
- 経理として、承認済み申請を会計システムに連携したい
## 受け入れ条件（Given-When-Then）
### シナリオ1: 申請提出
- Given: ログイン済み社員
- When: 領収書写真と金額を入力し提出
- Then: 申請が「承認待ち」状態で保存される
### シナリオ2: 承認
- Given: 上長権限でログイン
- When: 申請一覧から「承認」を押下
- Then: ステータスが「承認済み」になり、申請者に通知
## データモデル
- ExpenseRequest: id, applicant, amount, receipt_url, status
- Approval: request_id, approver, decided_at, status
## API
- POST /api/expense
- GET /api/expense/list
- POST /api/expense/{id}/approve
## 非機能要件
- 同時申請: 100件/秒
- 承認画面表示: 2秒以内
6. 受け入れ条件（Acceptance Criteria）の書き方
SDDで最も重要なのが受け入れ条件です。これがAIへの「完成定義」になり、テストにもなります。
Given-When-Then形式は標準的だが、書き方にコツがあります。抽象的すぎず、過剰に具体的すぎず。「正しく動く」では曖昧、「ボタンの色が#3B82F6で〜」では過剰。境界条件・エラーケース・正常系の3種を網羅的に書くのが目安です。
良い受け入れ条件 / 悪い受け入れ条件
| 観点 | ❌ 悪い例 | ✅ 良い例 |
|---|---|---|
| 抽象度 | 「ユーザーが快適に使える」 | 「画面表示が3秒以内」 |
| 検証可能性 | 「正しく動く」 | 「ステータスが『承認済み』に変わる」 |
| 網羅性 | 正常系のみ | 正常・異常・境界 |
| 主語 | 不明 | アクターが明示 |
| 実装詳細 | UIの色まで指定 | 振る舞いに集中 |
7. SDDのチーム体制
SDDで機能する組織は、従来とは違うロール設計が必要になります。
Spec Owner は仕様の最終責任者。ビジネス理解と技術理解の両方が必要で、プロダクトマネージャーとテックリードのハイブリッドのような役割になります。仕様の品質が、開発全体の品質を決めます。
Builder は仕様→実装を担います。AI活用が中心で、AIに仕様を渡し、実装させ、レビューします。従来のフルスタックエンジニアの後継だが、コードを書く時間が大幅に減り、仕様読解と検証に時間を使います。
Reviewer は実装の妥当性を確認する役割。仕様通りか、品質基準を満たしているか、セキュリティ・パフォーマンスに問題がないか。AIが一次レビュー、人間が最終判断、という分業が成立します。
SDDチームのロール設計
| ロール | 主担当 | 必要スキル | 1チームあたりの人数 |
|---|---|---|---|
| Spec Owner | 仕様策定・更新 | ビジネス＋技術 | 1〜2人 |
| Builder | 仕様→実装 | AI活用力 | 2〜4人 |
| Reviewer | 実装検証 | 設計判断・品質意識 | 1〜2人 |
| Stakeholder | 仕様承認 | ドメイン知識 | 必要数 |
8. SDDが向くケース・向かないケース
SDDは万能ではありません。向く領域と向かない領域があります。
向くケース：仕様が比較的安定している領域、ステークホルダーが多く合意形成が重要な領域、規制対応や監査が必要な領域、API中心のサービス、複数チームが連携する大規模開発。これらは仕様を一級にする価値が高いです。
向かないケース：完全な探索開発（何を作るか自体が未定）、UI/UXの試行錯誤フェーズ、仕様が日々変わるスタートアップ初期、仕様化困難な領域（ML・データサイエンス・クリエイティブ）。これらは仕様書を維持するコストが便益を上回ります。
向き・不向きの判断マトリクス
| プロジェクト特性 | SDDが向く度 |
|---|---|
| 規制業界・監査必須 | ⭐⭐⭐⭐⭐ |
| 大規模・複数チーム | ⭐⭐⭐⭐⭐ |
| API中心のサービス | ⭐⭐⭐⭐ |
| エンタープライズB2B | ⭐⭐⭐⭐ |
| 一般的な業務システム | ⭐⭐⭐ |
| スタートアップ初期 | ⭐⭐ |
| クリエイティブ領域 | ⭐ |
| ML・データサイエンス | ⭐ |
💡 判断のコツ：「仕様変更を年に何回するか」で考えます。月10回以上変わるなら仕様を維持するコスト過大。月1回以下なら仕様を維持する便益が圧倒的。
9. SDDの落とし穴と対策
SDDを導入する際に陥りがちな落とし穴を整理します。
第一に、仕様書の陳腐化。仕様書とコードがまた乖離する古典的問題。対策はCI連動で「仕様変更がない実装変更」を検知し、警告を出すこと。仕様→実装の方向を制度として強制します。
第二に、過剰な仕様詳細。仕様書を完璧にしようとして、書ききれない領域まで書き込み、結局誰も読まなくなります。対策は粒度の規約を決めること。「2000字以上の仕様書は分割する」など。
第三に、仕様の合意不足。Spec Ownerが書いただけで、ステークホルダーが見ていません。対策はレビュープロセスの徹底と、合意の電子記録（誰がいつ承認したか）。
第四に、AIが仕様を逸脱。仕様にない機能を勝手に追加します。対策は受け入れテストの厳密化と、AIへの「仕様にないことはしない」明示。
10. 経営観点での価値
SDDの経営価値は、4つの観点で整理できます。
第一に、仕様＝資産。組織のドメイン知識が仕様書として蓄積します。エンジニアが退職しても、仕様書が残れば再構築できます。受託会社に依存しなくなります。
第二に、監査対応コストの削減。規制業界では、監査時に「何を実装しているか」の証拠を出すコストが大きいです。SDDなら仕様書がそのまま証跡。コンサル費用や監査対応工数が劇的に減ります。
第三に、人材交代耐性。引き継ぎが仕様書ベースで行えるため、属人化が減ります。これは人材流動性の高い時代に組織防衛として効きます。
第四に、AI活用の精度向上。仕様駆動でAIに指示するため、AIの出力品質が上がります。同じAIツールを使っていても、SDD組織のほうが成果が出やすいです。
まとめ
Spec-Driven Developmentは、AIDD時代の新しい標準的開発スタイルとして広がっています。仕様＝一級のソース、コード＝派生物、AI＝仕様→実装の変換装置 という構造で、仕様の陳腐化を防ぎ、AIの実装精度を最大化します。規制業界・大規模開発・エンタープライズB2Bで特に効果が大きい一方、探索開発やクリエイティブ領域には不向き。導入時は仕様書フォーマット・受け入れ条件・チームロール・CI連動を整備することで、落とし穴を回避できます。経営価値は「資産化・監査対応・人材交代耐性・AI精度」の4軸で語れます。
導入チェックリスト
- [ ] 仕様書フォーマット（Markdown/YAML/OpenAPI）の標準化
- [ ] Given-When-Then形式の受け入れ条件規約
- [ ] Spec Owner / Builder / Reviewer のロール定義
- [ ] 仕様書のGit管理・PR運用
- [ ] CI連動（仕様変更なき実装変更の検知）
- [ ] AI連携（仕様→実装の自動化）
- [ ] レビュープロセスと合意記録
- [ ] 適用範囲の見極め（向く・向かないの判断）
- [ ] 経営層への価値訴求（資産化・監査対応）
IT COMPASSのAI駆動開発支援
IT COMPASS では、CTO経験者が外部CTO・技術顧問として、Spec-Driven Developmentの導入と運用を伴走支援しています。
支援できること
- 📋 SDD導入支援：仕様書フォーマット・体制・運用ルール
- 🤖 AI連携設計：仕様→実装の自動化フロー
- 🛠 ツール選定とパイロット設計：Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
- 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
- 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート
こんな方におすすめ
- 仕様の陳腐化に悩むCTO・PMの方
- 監査対応や規制業界で運用したい技術責任者の方
- AIの実装精度を上げたい開発リーダーの方
お問い合わせ
スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。
👉 IT COMPASS お問い合わせフォーム
経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。
監修者
西脇 靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）
「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援しています。著書はオライリー・ジャパンから複数刊行。
