はじめに
「ログイン機能を作って、と頼んだら、パスワードリセットメールまで勝手に実装されていた。動くけど、私が欲しいものじゃない」
Claude Codeを使い始めたエンジニアが、一度は経験するパターンだ。指示の解釈がズレているというよりも、仕様が曖昧なまま渡してしまったこちら側に構造的な問題がある。
ここで紹介する仕様駆動開発（SDD）は、OpenAPI仕様書によるAPIドキュメント管理の話ではない。ソフトウェア機能要件をどう定義してAIに渡すか、という開発フロー全体を指す。「Vibe Coding」と呼ばれる感覚頼りの開発から脱出するための、実践的な方法論だ。
Vibe Codingの限界：3つの構造問題
Vibe Codingとは、明確な仕様なしに感覚・直感でAIにコードを書かせるアプローチだ。「よしなにやって」という指示が典型例で、短期的には速く動けるが、すぐに3つの問題が噴出する。
| 問題 | 具体例 |
|---|---|
| スコープクリープ | 頼んでいない機能が追加される |
| 設計の一貫性崩壊 | セッションをまたぐと前の決定を無視した実装になる |
| バグの増加 | 仕様が曖昧なため「それっぽい」実装を選んでしまう |
複数の実践事例では、SDDを採用することで手戻りや実装工数が大幅に削減されたと報告されている。手戻りが構造的に減るという経験は多くの実践者が一致して語る。
SDDの本質：承認ゲートを挟む
SDDで変わるのは、実装より先に仕様を固めるという順序だ。スペックが固まるまでコードを書かない。Claude Codeとの文脈では3フェーズで進める。
フェーズ1: Spec（仕様定義）
↓ 承認（人間がレビュー）
フェーズ2: Design（設計確認）
↓ 承認
フェーズ3: Implementation（実装）
↓
仕様書に書いていないことは実装しない
Vibe Codingとの違いは一点に集約される。「承認ゲートを挟むかどうか」だ。
Vibe Coding:
「ログイン機能を作って」
↓
Claudeが「ログイン機能とは何か」を推測して実装
↓
「そうじゃなくて...」（手戻り発生）
SDD:
「ログイン機能のスペックを書いて」
↓ 人間がレビュー・承認
「承認されたスペックに従って実装して」
↓
スペックの範囲内でのみ実装
/create-specコマンドで仕様書を固める
SDDの起点は「仕様書生成コマンド」だ。Claude Codeのカスタムスラッシュコマンドとして定義することで、毎回同じ構造のPRD（Product Requirements Document）が生成される。
# ~/.claude/commands/create-spec.md に配置
# /create-spec として呼び出せるようになる
ファイルの内容はPRDの8セクション構造を指定し、末尾に「PRDを作成したら、実装に進む前に必ず確認を求めること。承認なしに実装を開始してはならない」という制約を加える。
/create-spec ユーザー認証機能（メール・Google OAuth）
このコマンドを受け取ったClaudeは、概要・ゴール・非ゴール・ユーザーストーリー・機能要件・非機能要件・技術設計・受け入れ条件・未解決の質問という8つのセクションを生成して提示する。人間がレビューして承認するまで実装には移行しない。「非ゴール（スコープ外）」を明示させることがスコープクリープ防止に直結する。
cc-sdd：Kiroスタイルの4フェーズワークフロー
AWSが2025年に発表したIDE「Kiro」はスペックファーストを徹底した設計思想を持つ。そのKiroの哲学をClaude Codeに持ち込んだOSSツールがcc-sdd（GitHub: gotalab/cc-sdd）だ。
git clone https://github.com/gotalab/cc-sdd
cd cc-sdd
./install.sh # ~/.claude/commands/ にスラッシュコマンドを配置
インストールすると4つのコマンドが使えるようになる。
| コマンド | 内容 | 出力 |
|---|---|---|
/requirements | 要件の洗い出しと構造化 | spec/requirements.md |
/design | 技術設計の決定 | spec/design.md |
/tasks | タスクの分解とチェックリスト | spec/tasks.md |
/implement | タスクリストに従った実装 | コード |
重要な制約は、/implementがspec/tasks.mdに記載されたタスクのみを実装する点だ。仕様書に書いていないことは実装しない。この制約がVibe Codingのスコープクリープを防ぐ核心になる。
実際のフローはこうなる。
/requirements ショッピングカート機能
→ Claude: 「以下の要件を整理しました。承認してください」
（人間がレビュー・修正・承認）
/design → /tasks → /implement
→ 各フェーズで承認を経て実装へ
CLAUDE.mdでSDDをチーム全体に強制する
個人では習慣化できても、チームで統一するのが難しい。CLAUDE.mdにSDDルールを宣言することで、全セッションで仕様ファーストが自動適用される。
## 開発フロー（必須）
新機能開発の手順
1. まず /create-spec {機能名} でスペックを生成する
2. スペックを提示し、私の承認を待つ
3. 承認なしに実装を開始してはならない
4. スペックに記載のない機能は実装しない
スペックファイルの配置
- spec/requirements.md（機能要件）
- spec/design.md（技術設計）
- spec/tasks.md（実装タスクリスト）
このCLAUDE.mdをリポジトリにコミットすれば、チームメンバー全員が同じSDDルールのもとでClaude Codeを使える。
git add CLAUDE.md
git commit -m "Add SDD workflow to CLAUDE.md"
SDDを使わない方が良いケース
「全部SDDで」とやると、バグ修正の一行変更にもスペックを書くことになって嫌になる。使いどころを絞るほうが長続きする。
SDDが有効なケース（仕様作成コスト ＜ 削減される手戻りコスト）：
- 新機能開発（2時間以上かかるもの）
- 複数のコンポーネントにまたがる変更
- 仕様が曖昧な機能（「よしなに実装して」になりがちなもの）
SDDが不要なケース：
- バグ修正（再現手順が明確な場合）
- リファクタリング（既存テストが通ればOK）
- 設定変更・定数修正
- 単純なCRUD追加（既存パターンに従うだけ）
「すべてSDDで」と決めると、軽微な変更にも仕様書作成が必要になり、開発チームから反発が起きる。適用対象を判断することがSDD定着の鍵だ。
まとめ
SDDを使い始めてから変わったのは、「なんか違うものができた」という感覚がほぼなくなったことだ。承認ゲートを挟むだけで、Claudeが推測で走り続けることを止められる。
今すぐ（10分）：~/.claude/commands/create-spec.mdを作成し、次の新機能開発で/create-specを試す。「スコープ外」を明示させるだけで手戻りが変わる。
今日中：CLAUDE.mdに「承認なしに実装開始禁止」ルールを追加する。1行書くだけで、今日以降の全セッションに適用される。
チーム展開：CLAUDE.mdをリポジトリにコミットし、チーム全員が同じSDDワークフローを使う環境を作る。cc-sddの導入も合わせて検討したい。
コメント