CC-SDDとは何か — Claude Codeと仕様駆動開発を組み合わせる実践ガイド
バイブコーディングに疲れた開発者が、次に試すのが何かと問われれば、最近の現場では「CC-SDD」という答えが返ってくるようになってきた。
聞き慣れない言葉かもしれない。CC-SDD（Claude Code SDD）とは、Anthropicが提供するAI開発CLI「Claude Code」と、仕様駆動開発（Specification-Driven Development）を組み合わせた開発アプローチだ。「仕様書をAIが読める形で書く」という発想をベースに、コード生成から設計レビューまで一貫してClaudeと協働するやり方を指す。
なぜCC-SDDが注目されるようになったのか
バイブコーディングは確かに速い。「これを実装して」とプロンプトを投げるだけでコードが出てくる。最初の数週間は魔法のようだ。
ところが、開発が進むにつれて違和感が出てくる。AIが生成したコードは動くが、「なぜそうなっているのか」という設計意図がどこにも残らない。次のスプリントでAIに修正を頼むと、前回と矛盾した実装を提案してくる。AIはコンテキストを持続させないからだ。
この問題の核心は、仕様書の不在にある。
人間がチームで開発するとき、設計書があれば「なぜこの実装を選んだか」が共有できる。AIも同じだ。仕様書という「文脈の持ち運び先」がなければ、会話をまたいで一貫した開発は難しい。
CC-SDDはこの問題を正面から解決しようとする試みだ。コードを書く前に「AIが読める仕様書」を整備し、それをClaudeに渡しながら開発を進める。バイブコーディングの速さは保ちつつ、技術的負債の蓄積を抑える。
CC-SDDの3つの原則
原則1: 仕様が先、コードが後
CC-SDDでは、実装の前に必ず「仕様のスナップショット」を書く。長大なWBS文書ではなく、AIに渡すことを前提にした短い構造化テキストだ。
## 機能: ユーザー認証
- 入力: メールアドレス + パスワード
- 処理: JWTトークンを発行し、DBにリフレッシュトークンを保存
- 出力: アクセストークン（有効期限24h）
- 制約: パスワードはbcryptでハッシュ化必須こういった「機能仕様カード」を書いてからClaudeに「この仕様を実装して」と依頼する。バイブコーディングのように「ユーザーログインを作って」と曖昧なプロンプトを投げるのとは対照的だ。
Claudeは仕様を受け取ると、実装だけでなく「この仕様では考慮されていないエッジケース」も指摘してくれる。人間がレビューしている感覚に近い。
原則2: 仕様を「生きた文書」として管理する
一度書いた仕様は、実装が進む中で変化する。CC-SDDでは、コードと仕様書をセットで変更管理する。実装を変えたら仕様も更新する。これだけだ。
難しく聞こえるが、GitHubのPRに「仕様書の変更」を含める習慣をつければいい。Claude Codeで実装を変更するとき、「この変更に合わせて仕様書も更新して」と一言添えれば、Claudeが仕様書の更新も提案してくれる。
原則3: 仕様書をプロジェクトのコンテキストとして渡す
Claude Codeには`CLAUDE.md`というプロジェクト固有の設定ファイルがある。ここにプロジェクトの仕様サマリを書いておくと、Claudeはセッションをまたいでもそのコンテキストを持ち続けられる。
# CLAUDE.md の例
## プロジェクト: 在庫管理SaaS
- DB: PostgreSQL 16
- 認証: JWT + リフレッシュトークン
- 主要エンティティ: User, Product, StockEntry, StockAlert
- 命名規約: snake_case（DB）, camelCase（TypeScript）
- テスト方針: ユニットテスト必須、E2Eは重要フローのみこれがCC-SDDの「仕様書ベースのコンテキスト管理」の根幹だ。AIは毎回ゼロからではなく、この文書から理解を始める。
実際にCC-SDDで開発を進めると何が変わるか
弊社では複数のプロジェクトでCC-SDDを試してきた。正直に言うと、最初は「仕様書を書く手間が増えた」という感覚が強かった。バイブコーディングのほうが明らかに速い。
変化を感じたのは、プロジェクトが2〜3ヶ月を超えたあたりからだ。
バイブコーディングで進めていたプロジェクトでは、「なぜこの実装になっているのか」をAIに説明するたびに時間を食うようになっていた。AIはコードを読んでくれるが、意図を読むことはできない。
CC-SDDで進めていたプロジェクトでは、仕様書があるので「この仕様書の通りに修正して」とだけ言えばよかった。AIの応答精度が明らかに違った。
数字で示すと、レビューサイクル（実装→レビュー→修正）の1サイクルあたりの時間が、バイブコーディングに比べて約40%短縮した。仕様書作成のコストを差し引いても、中長期でペイする。
CC-SDDが特に有効なケース
すべての開発にCC-SDDが適しているわけではない。実際に試してみてわかった「向いているケース」と「向いていないケース」を共有する。
向いているケース
- 複数人で開発するプロジェクト（仕様書が共通言語になる）
- 3ヶ月以上続く中長期プロジェクト
- 機能変更・追加が頻繁に発生するプロダクト開発
- AIの生成コードを非AI開発者もレビューする必要がある環境
向いていないケース
- プロトタイプ・PoC（速さが最優先）
- 仕様が確定していないフェーズの探索的開発
- 担当者1人で完結する小規模スクリプト
要するに、CC-SDDは「チームで長く続けるプロダクト開発」に向いている。バイブコーディングを完全に否定するのではなく、フェーズに応じて使い分けるのが現実的だ。
CC-SDDを始めるための最小ステップ
「全部やろうとすると続かない」という失敗パターンが多いので、最小限のステップから始めることを勧めている。
Week 1: CLAUDE.mdを作る
既存プロジェクトでも、今日か ら`CLAUDE.md`を作れる。プロジェクトの概要、使用技術、命名規約を100行以内にまとめるだけでいい。これだけで、Claude Codeの応答品質が変わる。
Week 2: 機能仕様カードを書いてみる
次に新機能を実装するとき、プロンプトを投げる前に1分で機能仕様カードを書いてみる。入力・処理・出力・制約の4項目だけでいい。
Week 3: PRに仕様変更を含める
実装変更のPRには必ず仕様書の変更も含める。このルールを徹底するだけで、仕様書が「生きた文書」として機能し始める。
難しいことは何もない。ただ、「コードの前に仕様を書く」 という習慣をつけるだけだ。
仕様書はAIへのインターフェース
CC-SDDを試してみて気づいたことがある。仕様書の本質的な価値は「人間への共有」ではなく、「AIへのインターフェース」としての役割に変わりつつある。
コードはAIが読める。ドキュメントもAIが読める。だが、なぜそのコードをそのように書いたかの意図は、仕様書にしか残らない。そして、AIはその意図があってはじめて、正確に「次の実装」を考えられる。
AI時代の仕様書は、プロジェクト管理のための形式的なドキュメントではない。AIと人間が協働するための共通言語だ。
プロジェクトの規模や技術スタックは違っても、この考え方は普遍的に使えるはずだ。CC-SDDに興味を持ったら、まずはCLAUDE.mdを1つ作ることから始めてみてほしい。
Atsumellでは、AI開発の設計から実装まで伴走するサービスを提供しています。CC-SDDの導入支援や、AIと協働できる仕様書の設計についても相談を受け付けています。お問い合わせはこちら
