スペック駆動開発（SDD）× Claude Code｜Requirements→Design→Tasks→Implementationで品質を担保する

AI コーディングを実務で回していると、「指示が抽象的で実装がブレた」「期待と違うコードが出てきて 3 回やり直した」「チームで意図が共有されていない」といった手戻りが出てきます。この手戻りの本質は、仕様の曖昧さであり、それを AI に押し付けても解決しません。

2025〜2026 年にかけて急速に広がった スペック駆動開発（SDD; Spec-Driven Development） は、「コードより先に仕様を書き、AI はその仕様から実装を生成する」というワークフローです。本記事では、Claude Code での SDD 実践手順を、GitHub Spec-Kit・cc-sdd・claude-code-spec-workflow などのツールチェーンと合わせて整理します。TDD との関係はClaude Code TDDワークフロー、基本はClaude Code完全ガイドを参照してください。

結論 ── SDD は「仕様を第一級成果物にする」AI コーディングのワークフロー

スペック駆動開発（SDD）は、コードより先に要件（Requirements）・設計（Design）・タスク（Tasks）を仕様書として人間が承認し、AI が仕様から実装を生成するワークフローです。 Claude Code では /add-feature、GitHub Spec-Kit、cc-sdd、claude-code-spec-workflow などが実践ツールとして使えます。

「仕様書は開発中に読まれない紙」という従来の認識に対して、SDD は **仕様書を第一級成果物（first-class artifact）**として扱い、コードは仕様から派生する二次成果物と位置付けます。AI コーディングとの親和性が非常に高く、2026 年時点で急速に普及しているアプローチです。

SDD が必要な理由（AI コーディングの課題と SDD の解）

AI コーディングで頻発する失敗パターンと、SDD による解決の対応は以下の通りです。

失敗パターン	SDD の解
「こんな感じで」と曖昧に指示、意図と違う実装が返る	仕様書で意図を明文化、AI は仕様を読む
タスクが大きすぎて AI が迷子になる	Tasks フェーズで小さく分割
一部だけやり直したいのに全体をやり直し	Design → Tasks の粒度で差分再実行
チーム内で「誰が何を作るか」が曖昧	Requirements・Design でレビュー
実装後にレビューしても手戻りが大きい	実装前に仕様レビューを挟む

結果として、AI コーディングは「速い」だけでなく「正しい」方向に舵を切れるようになります。

4 フェーズ詳細

Requirements（要件定義）

「何を作るか」を定義するフェーズ。ユーザーストーリー、受入基準、非機能要件を記述します。

# Requirements: ユーザー検索機能

## ユーザーストーリー
As a 管理者
I want ユーザー名・メールアドレスで検索できる
So that 特定のユーザーをすぐ見つけられる

## 受入基準
- [ ] 管理画面の検索フォームに名前を入力すると部分一致で結果が返る
- [ ] メールアドレスを入力すると完全一致で結果が返る
- [ ] 結果は最大 50 件表示、ページネーション対応
- [ ] 権限のない一般ユーザーからは検索フォームが見えない

## 非機能要件
- 検索レスポンスタイム: p95 で 500ms 以内
- インデックス活用のため、WHERE 句のカラムに B-tree インデックスを持つ

受入基準は Given-When-Then 形式で書くと、後工程のテストと 1:1 対応しやすくなります。

Design（設計）

「どう作るか」を定義するフェーズ。API スキーマ、DB スキーマ、コンポーネント構成、使用ライブラリの選定を記述します。

# Design: ユーザー検索機能

## API スキーマ
GET /api/users?q={query}&by={name|email}&page={n}

## DB スキーマ
users テーブル:
  - 既存カラムで対応
  - インデックス追加: CREATE INDEX idx_users_email ON users(email);
  - 部分一致用: pg_trgm または citext で ILIKE 検索

## フロントエンド
- SearchForm コンポーネント（shadcn/ui Form）
- ResultList コンポーネント（useSWR でデータ取得）
- 権限ガード: hasPermission('admin:users:read')

Tasks（タスク分解）

「どの順で作るか」を定義するフェーズ。依存関係を考慮しながら、実装単位のタスクに分解します。

# Tasks: ユーザー検索機能

1. DB マイグレーション（idx_users_email + pg_trgm 拡張）
2. API 実装（GET /api/users）+ 単体テスト
3. 権限チェックミドルウェア適用 + 単体テスト
4. SearchForm コンポーネント（フロント）+ Storybook
5. ResultList コンポーネント + Storybook
6. ページネーション実装
7. E2E テスト（管理者ログイン → 検索 → 結果表示）

Implementation（実装）

Tasks の順に AI に実装させます。各タスクは小さく独立していて、1 PR に収まる粒度が理想です。Claude Code なら /add-feature コマンドや各種 SDD ツールが、このフェーズを半自動化してくれます。

ツールチェーン比較

ツール	提供元	対応エディタ	特徴
Spec-Kit	GitHub org	多くの AI エディタ	公式スターターキット、シンプル
cc-sdd	コミュニティ	Claude Code / Codex 安定、他はベータ	Kiro スタイル、4 フェーズを強制
cc-spex	コミュニティ	Claude Code 中心	cc-sdd 派生、カスタム trait 対応
claude-code-spec-workflow	コミュニティ（Pimzino）	Claude Code	新規機能 + バグ修正の 2 ワークフロー

cc-sdd の対応マトリクス（README ベース、2026-04-18 時点）:

• Stable: Claude Code / Codex
• Beta: Cursor / GitHub Copilot / Windsurf / OpenCode / Gemini CLI / Antigravity

最新の対応状況は各リポジトリの README を必ず確認してください。

Claude Code での実践

/add-feature コマンドの対話フロー

Claude Code に /add-feature スキルをインストールしておくと、以下のような対話フローが走ります。

> /add-feature ユーザー検索機能

【Phase 1: Requirements】
以下の観点で要件を整理します：
- どういうユーザーが、何のために、何をしたいか？
- 受入基準は？（Given-When-Then で書けますか？）
- 非機能要件（レスポンスタイム・同時接続数・権限）は？

> （対話で詰める）

生成された requirements.md をレビューしてください...

/add-feature の実装はClaude Code Skillsガイドに詳しく、プロジェクトごとにカスタマイズできます。

仕様書の配置場所

プロジェクトルート直下の .steering/ 配下にフェーズごとのディレクトリを作る構成が広く使われています。

.steering/
  specs/
    user-search/
      requirements.md
      design.md
      tasks.md
      notes.md          # レビューコメントや判断の根拠

この配置は koromo プロジェクト（本ブログの運営元）でも採用しており、Claude Code の各スキル（/add-feature, /fix-bug, /refactor）と自然に連動します。

各フェーズのレビュー基準

フェーズ	レビュー基準
Requirements	受入基準が 1 テストに対応する粒度になっているか / 非機能要件が数値で書かれているか
Design	採用したライブラリ・スキーマの理由が書かれているか / 競合案と採用案の比較があるか
Tasks	依存関係が明確か / 1 タスクが 1 PR に収まる粒度か / テストタスクが含まれているか
Implementation	各 Tasks のテストが通っているか / 静的解析・型チェックが通っているか

実例: 新規機能を SDD で開発する（通し実装）

Step1: Requirements 作成

/add-feature を起動、対話で要件を詰めます。受入基準を Given-When-Then 形式で最低 5 つ書く、非機能要件は数値で書く、の 2 点だけ意識すれば十分です。

Step2: Design 作成

Requirements を受けて、Claude Code に「3 案出して比較してください」と依頼すると、trade-off 表付きで選定根拠が出てきます。採用案を人間が選び、design.md に確定版を書きます。

Step3: Tasks 作成

Design から依存関係を意識してタスクに分解。Claude Code に「このタスクを 1 PR に収まる粒度に再分解してください」と指示すると、適切な粒度まで落としてくれます。

Step4: Implementation

各タスクを 1 PR ずつ進めます。TDD と組み合わせるなら、ここで「テストを先に書く（Red）→ 実装（Green）→ リファクタ」のサイクルを回します。

TDD との併用パターン

SDD と TDD は補完関係です。SDD で仕様を固めたあと、TDD で実装品質を担保します。

観点	SDD	TDD
焦点	何を作るか	どう動くべきか（テスト）
時期	実装前（上流）	実装時（下流）
主な成果物	仕様書	テストコード
レビュー対象	仕様書	テスト + 実装

Claude Code で併用する場合、以下のフローが自然です。

/add-feature → Requirements → Design → Tasks
                                          ↓
  各 Task について  → テストを書く → 実装 → リファクタ
                     （TDD Red）   （Green）

Gotcha ── SDD が失敗するパターン

仕様書が詳細すぎて AI が動けない

細部まで指示しすぎると、AI の判断余地がなくなり、「行間の読み方」ができなくなります。「何を」と「制約」は詳しく、「どう」は抽象的に書くのがコツです。

逆に抽象的すぎて実装がブレる

「ユーザーが使いやすい検索機能」だけでは AI が勝手に範囲を広げます。受入基準・非機能要件の数値化が必要です。

レビューが形骸化する

「AI が書いた Requirements を人間が AI 的に読み飛ばす」が最悪パターン。5 分のレビューでも、最低 3 つの具体的な指摘を残すルールを設けると効きます。

仕様書に秘密情報（API キー・DB 接続文字列・個人情報）を書いてしまう

.steering/ は git に含める運用が多いため、API キーや個人情報を書くと漏洩します。秘密情報は環境変数・シークレットマネージャ、仕様書には「環境変数 DB_URL 経由で提供」のように抽象的に書く。

よくある質問

まとめと次のステップ

スペック駆動開発（SDD）は、「AI が速く書けるようになったから、人間は仕様を正しく書くことに集中する」という分業の提案です。Claude Code の /add-feature や Spec-Kit / cc-sdd などのツールチェーンを組み合わせれば、Requirements → Design → Tasks → Implementation の 4 フェーズを数時間〜数日で回せます。

導入するなら、まず 1 機能を SDD で通しで回してみる、次に受入基準の書き方をチームで揃える、最後にレビュー基準を整備する、の順序が現実的です。

次のステップ:

• テスト駆動の併用 → Claude Code TDDワークフロー
• スキルをカスタマイズ → Claude Code Skillsガイド
• 大規模リファクタでの活用 → Claude Code リファクタリングガイド
• サブエージェント活用 → Claude Codeサブエージェントガイド

関連記事

• Claude Code完全ガイド
• Claude Codeスラッシュコマンド集