はじめに
AI コーディングツールが普及し、Claude Code や Cursor などで「とりあえず AI に聞いてコードを生成させる」開発スタイル（Vibe Coding）が一般的になってきました。しかし、こんな悩みを抱えていませんか？
- 生成されたコードが期待と違う
- セッションを跨ぐと前回の内容を忘れられる
- 何度も同じ説明を繰り返す必要がある
- コードの品質にばらつきがある
これらの課題を解決する新しいアプローチが**仕様駆動開発（Spec-Driven Development、SDD）**であり、それを実践するための国産ツールが cc-sdd です。
本記事では、cc-sdd を実際に使ってみた経験をもとに、その特徴や使い方、実践的な Tips を紹介します。
cc-sdd とは
cc-sdd は、日本発のオープンソース仕様駆動開発ツールです。Amazon の Kiro スタイルと互換性があり、構造化された開発ワークフローを AI 開発ツール上で実現します。
主な特徴
- 日本語完全対応 - 日本語での要件定義・設計が可能
- マルチツールサポート - Claude Code、Cursor、Gemini CLI、Codex CLI、GitHub Copilot、Windsurf をサポート
- 段階的な承認プロセス - 要件定義 → 設計 → タスク分解 → 実装の各段階でレビュー可能
- TDD 前提の実装 - テスト駆動開発が標準で組み込まれている
- Project Memory 機能 - プロジェクト固有のコンテキストやパターンを記憶
GitHub リポジトリ
- リポジトリ: gotalab/cc-sdd
- スター数: 1.1k+
- サポート: 7 つのエージェント × 12 言語
従来の Vibe Coding の課題
まず、従来のアプローチの課題を整理しましょう。
Vibe Coding の問題点
- 曖昧さの蓄積 - 口頭ベースの指示では詳細が抜け落ちる
- 再現性の低さ - セッションごとに異なる実装になる
- 一貫性の欠如 - プロジェクト全体でコードスタイルがバラバラ
- 品質のばらつき - レビュープロセスが不明確
これらは、従来の人間同士の開発でも「仕様書がない」場合に起こる問題と同じです。
SDD アプローチの利点
仕様駆動開発では、人間が開発する際と同じく「要件定義 → 設計 → 実装」という流れで段階的に進めます。
SDD がもたらすメリット
- 明確な仕様 - 各段階で文書化されるため、後から見返せる
- 高い再現性 - 設計書に基づくため、一貫した実装が可能
- 効率的なレビュー - 実装前に設計を確認できる
- 品質の向上 - TDD が標準で組み込まれている
- コンテキストの維持 - Steering Documents により一貫性を保持
インストール方法
cc-sdd のインストールは非常にシンプルです。
Claude Code の場合
npx cc-sdd@latest --lang ja
Cursor IDE の場合
npx cc-sdd@latest --cursor --lang ja
Gemini CLI の場合
npx cc-sdd@latest --gemini-cli --lang ja
インストール後、カスタムスラッシュコマンドが自動的に追加されます。
開発フローの詳細
cc-sdd は 5 つの段階で開発を進めます。
1. Steering Documents の作成（推奨）
まず、プロジェクトの全体像を AI に理解させます。以下のどちらかのコマンドを実行します。
# プロジェクトメモリとコンテキストを作成/更新
/kiro:steering
# 専門ドメイン知識を追加
/kiro:steering-custom
これにより以下が生成されます：
- プロジェクト概要
- アーキテクチャの理解
- コーディング規約やパターン
効果: セッションを跨いでも一貫性のあるコード生成が可能になります。
2. 要件定義
プロジェクトの初期化と要件の詳細化を行います。
/kiro:spec-init "TODO アプリを作りたい"
次に要件を詳細化します：
/kiro:spec-requirements
生成されるファイル: requirements.md
このファイルには以下が含まれます：
- 機能要件
- 非機能要件
- ユーザーストーリー
- 制約条件
3. 設計
要件を承認後、技術設計を行います。
/kiro:spec-design
生成されるファイル: design.md
設計書には以下が含まれます：
- システムアーキテクチャ
- データモデル
- API 設計
- 技術スタック
- セキュリティ考慮事項
重要: この段階で設計をレビューし、必要に応じて修正できます。実装前に問題を発見できるため、手戻りを大幅に削減できます。
4. タスク分解
設計を実装可能な単位のタスクに分解します。
/kiro:spec-tasks
生成されるファイル: tasks.md
タスクは以下のように構造化されます：
- タスク ID
- タスク名
- 依存関係
- 実装の優先順位
5. 実装
全タスクまたは特定のタスクを実装します。
# 全タスク実装
/kiro:spec-impl
# 特定タスクのみ
/kiro:spec-impl task-001
TDD による実装: cc-sdd はテスト駆動開発が前提のため、以下が自動的に行われます：
- テストケースの作成
- 実装
- テストの実行と検証
実践 Tips
実際に使用して得られた実践的な知見を共有します。
1. プロジェクトの適切なタイミング
cc-sdd が最も効果を発揮するタイミング：
- ✅ 中規模以上のプロジェクト - 複数の機能を持つアプリケーション
- ✅ チーム開発 - 仕様を共有する必要がある場合
- ✅ 長期プロジェクト - 保守性が重要な場合
- ⚠️ 骨組み作成後 - ゼロからではなく、Vibe Coding で骨組みを作った後に cc-sdd で作り込むのが効率的
2. 要件定義のコツ
要件定義では具体的に記述することが重要です：
良い例:
- ユーザーは TODO アイテムを作成できる
- 各 TODO には期限を設定できる
- 期限が過ぎた TODO は赤色でハイライトされる
- TODO は完了/未完了でフィルタリングできる
悪い例:
- TODO を管理できる
- 使いやすい UI
3. 設計レビューの重要性
設計段階で以下をチェックしましょう：
- データモデルは適切か
- API 設計は RESTful か
- セキュリティ考慮は十分か
- パフォーマンスの懸念はないか
- 既存のプロジェクト構造と整合性があるか
4. Steering Documents の活用
Steering Documents を作成すると、以下のメリットがあります：
- コーディングスタイルの統一
- アーキテクチャパターンの継承
- 命名規則の一貫性
- フレームワーク固有の慣習の尊重
推奨: プロジェクトの初期段階で必ず作成しましょう。
5. タスクの粒度調整
タスク分解では適切な粒度が重要です：
- 大きすぎる: 実装が複雑になり、レビューが困難
- 小さすぎる: 管理コストが増加
- 適切: 1 タスク = 1 つの機能または 1 つのコンポーネント
ハマりどころと解決策
実際に使用して遭遇した問題と解決策を共有します。
1. コンテキスト圧縮による精度低下
問題: 長いセッションでコンテキストが圧縮され、精度が低下する
解決策:
- Steering Documents を活用してコンテキストを外部化
- 定期的に新しいセッションを開始
- 重要な仕様は requirements.md や design.md に明記
2. 既存の CLAUDE.md との共存
問題: プロジェクト固有の CLAUDE.md と cc-sdd の指示が競合する
解決策:
- cc-sdd の Steering Documents に既存の CLAUDE.md の内容を統合
- または、CLAUDE.md で cc-sdd の使用を明記
3. 大規模な要件変更
問題: 途中で大きな要件変更があった場合の対応
解決策:
- requirements.md を手動で編集
-
/kiro:spec-designを再実行して設計を更新 - 影響範囲を確認してから実装フェーズに進む
4. テストが失敗する
問題: TDD で生成されたテストが失敗する
解決策:
- design.md でテスト戦略を明確に記述
- 外部依存がある場合はモックの使用を設計書に明記
- 失敗の原因を AI に分析させて修正
他のツール・アプローチとの比較
cc-sdd vs Vibe Coding
| 項目 | cc-sdd（SDD） | Vibe Coding |
|---|---|---|
| 仕様の明確さ | ✅ 文書化される | ❌ 口頭ベース |
| 再現性 | ✅ 高い | ❌ 低い |
| レビュー | ✅ 段階的に可能 | ❌ 実装後のみ |
| 学習コスト | ⚠️ 中程度 | ✅ 低い |
| 適用場面 | 中〜大規模 | 小規模・プロトタイプ |
cc-sdd vs 従来の手動設計
| 項目 | cc-sdd | 従来の手動設計 |
|---|---|---|
| 設計速度 | ✅ 高速 | ❌ 時間がかかる |
| AI 支援 | ✅ あり | ❌ なし |
| 柔軟性 | ✅ 高い | ⚠️ 中程度 |
| ドキュメント保守 | ✅ コマンドで更新可能 | ❌ 手動更新 |
実際の使用感
cc-sdd を実際に使用して感じたことをまとめます。
良かった点
- 納得感のある開発 - 「これで本当に良いのか」という不安が解消される
- 手戻りの削減 - 設計段階で問題を発見できる
- 品質の向上 - TDD が標準で組み込まれており、テストカバレッジが高い
- 日本語対応 - 日本語で自然に要件を記述できる
- 次のアクションが明確 - 各コマンド実行後、次に何をすべきか教えてくれる
改善を期待したい点
- 学習コスト - 初めての場合、コマンド体系の理解に時間がかかる
- 小規模プロジェクトでは過剰 - シンプルなスクリプトには不向き
- IDE との統合 - より深い IDE 統合があると便利
cc-sdd が向いているプロジェクト
以下のようなプロジェクトに特に有効です：
- ✅ 業務アプリケーション - 明確な要件と設計が必要
- ✅ チーム開発 - 複数人で仕様を共有
- ✅ 長期保守が必要 - 後からメンテナンスする可能性が高い
- ✅ 品質が重要 - テストカバレッジを高めたい
- ✅ 複雑なドメインロジック - ビジネスルールが複雑
まとめ
cc-sdd は、AI コーディング時代における新しい開発スタイルを提案する優れたツールです。
重要なポイント
- 仕様駆動開発（SDD） は、Vibe Coding の課題を解決する有力なアプローチ
- cc-sdd は、日本語対応で使いやすい国産ツール
- 段階的な承認プロセス により、品質と納得感を両立
- 中〜大規模プロジェクト で特に効果を発揮
- Steering Documents の活用が成功の鍵
AI と協働する開発スタイルは今後も進化していくでしょう。cc-sdd のような構造化されたアプローチは、AI 駆動開発の標準となる可能性を秘めています。
ぜひ一度試してみて、自分のプロジェクトに適しているか検証してみてください。
参考リンク
関連記事
本記事の作成にあたり、以下の記事を参考にさせていただきました：