所感・結論
cc-sdd（Claude Code Spec-Driven Development）を初めて使ってみた。
結論から言うと、かなり品質よく、手戻りがほぼない状態で実装を進めることができた。今回ユーザー管理機能の実装という名目で、ファイル差分が71ファイル（そのうち約30ファイルは仕様書などのMarkdownドキュメント）に及んだが、最終的に大きな手戻りはほぼ発生しなかった。
cc-sddの特徴は、決められた順番通りに実行していくという点にある。仕様決め→設計→タスク分解と段階を踏み、実装前の各フェーズで人間が深く関与してブラッシュアップを行う。その後、決められた内容をもとに実行順序も自動で決めてくれるので、それに沿って実装タスクをお願いするだけ。
個人的な所感として特に良かったのは、最初の仕様を詰める段階で考慮漏れを発見できたこと。要件定義のフェーズでEARS形式の要件を生成してくれるのだが、その過程で「あ、この条件考慮してなかった」という気づきが複数あった。
また、どこまでやるかの線引きも正確につけてくれて、今回はこの機能開発はやりませんよ(ex. 2要素認証、ユーザーのプロフィール画像管理...ect)というのを明確にし、今回のスコープ及び今後の開発項目としての考慮もしてくれるのがありがたいなと感じた。
一方で、vibe-coding（その場で試行錯誤しながら進める開発スタイル）と比べると、try&error形式ではないため、動かしながら作るようなケースには向いていないと感じた。割と大きな塊をお願いする時には最適だが、小さな変更を繰り返すような開発とは趣向が違いそう。
また、時間と確認作業がやっぱりかかる印象。各フェーズで生成されたドキュメントを確認し、承認する作業が必要になる。ただ、慣れてくれば工夫ポイントは幾つもありそうで、本当に仕様詰めと設計だけやって丸投げで作業を進めてもらうくらいまではいけそうだなと思った。今後慣れていきたい。
技術スタック
- cc-sdd v2.x（kiroコマンド群）
- Claude Code - AIペアプログラミングツール
- Next.js 15 (App Router) + TypeScript
- Prisma ORM + PostgreSQL RLS
- NextAuth.js 4.x - 認証基盤
- shadcn/ui + Radix UI - UIコンポーネント
- Zod - バリデーション
cc-sddとは
cc-sdd（Claude Code Spec-Driven Development）は、AIコーディングエージェントを活用した仕様駆動開発を実現するツール。従来の「とりあえず動くコードを書いてから調整する」アプローチとは異なり、仕様→設計→タスク分解→実装という順序で開発を進める。
/kiro:spec-init
→ /kiro:spec-requirements
→ /kiro:spec-design
→ /kiro:spec-tasks
→ /kiro:spec-impl
主な特徴：
- 仕様ファーストの保証: 実装前に要件・設計を承認
- 並列実行対応: タスク依存関係を追跡しながら同時実行可能
- チーム統一テンプレート: カスタマイズテンプレートを全エージェントで共有
- プロジェクトメモリ: セッション間でアーキテクチャやパターンを記憶
実装の流れ
今回のユーザー管理機能追加では、以下の流れで開発を進めた。
Phase 0: セットアップ
まずはcc-sddのインストールから。
npx cc-sdd@latest --claude --lang ja
続いて、プロジェクト情報を設定する/kiro:steeringを実行。これにより、プロジェクトの技術スタック、ディレクトリ構造、コーディング規約などがAIに共有される。
Phase 1: 仕様定義
/kiro:spec-init user-management
/kiro:spec-requirements user-management
このフェーズで生成されたのが、EARS（Easy Approach to Requirements Syntax）形式の要件定義書。7つの主要要件が定義された：
- ユーザー登録 - フォームバリデーション、パスワード複雑性、成功通知
- ユーザー一覧・検索 - ページネーション、検索・フィルタ・ソート
- ロール・権限管理 - ADMIN/OPERATOR/VIEWER、最後の管理者保護
- ユーザー編集・削除 - 情報更新、ソフトデリート、自己削除防止
- セッション・セキュリティ - JWT、7日間有効期限
- マルチテナント分離 - Prisma RLS、organizationId自動適用
- UI/UX・アクセシビリティ - レスポンシブ、トースト通知、キーボードナビ
ここで重要だったのは、要件の承認プロセス。 生成された要件を読み込む中で、「自分自身を削除できないようにする」「最後の管理者を降格できないようにする」といった考慮漏れに気づくことができた。
Phase 2: 設計
/kiro:spec-design user-management
このコマンドで1,015行の詳細設計書が生成された。内容には：
- システムフロー（Mermaidダイアグラム）
- コンポーネント設計
- データモデル（論理・物理）
- エラーハンドリング戦略
- テスト戦略
- セキュリティ考慮事項
設計書のおかげで、実装フェーズに入る前にアーキテクチャの全体像が明確になった。
Phase 3: タスク分解
/kiro:spec-tasks user-management
ここで生成されたのが、6つのメインセクション、27個のサブタスクからなる実装計画。特に便利だったのが：
- 並列実行可能なタスクの識別: フェーズ1のタスク1.1、1.2、2.1は並列実行可能
- 要件とタスクのトレーサビリティ: 各タスクがどの要件に対応するか明記
### タスク実行順序の推奨
#### フェーズ1: 基盤セットアップ（並列可能）
- タスク 1.1, 1.2, 2.1 を並列実行
#### フェーズ2: バックエンド実装（並列可能）
- タスク 3.1, 3.2, 3.3, 3.4 を並列実行（APIインターフェースが独立）
Phase 4: 実装
/kiro:spec-impl user-management [task-numbers]
実装フェーズでは、生成されたタスクを依存関係に従って順次実行。各コミットメッセージには、どのタスクを完了したか、どの要件に対応するかが記載される。
feat: implement user validation schemas with comprehensive tests
Task 1.1完了: パスワード複雑性検証を含むZodバリデーションスキーマを実装
Requirements: 1.4, 1.6, 7.8
vibe-codingとの比較
| 観点 | cc-sdd | vibe-coding |
|---|---|---|
| 適した場面 | 大規模・計画的開発 | 小規模・探索的開発 |
| 事前準備 | 多い（仕様→設計→タスク） | 少ない |
| 手戻り | 少ない | 多くなりがち |
| 確認作業 | フェーズごとに必要 | 都度判断 |
| ドキュメント | 自動生成 | 手動作成 |
| 学習コスト | やや高い | 低い |
| チーム展開 | しやすい（標準化） | 属人化しやすい |
どちらを選ぶべきか
cc-sddが向いているケース:
- 新機能の追加（特に複数ファイルにまたがる変更）
- チームでの開発（標準化されたプロセス）
- 後から仕様を確認する必要がある機能
- 品質を重視する本番向け実装
vibe-codingが向いているケース:
- プロトタイピング・検証
- 小さなバグ修正
- 一人での短期開発
- 仕様が固まっていない探索的な開発
チーム導入を検討する際のポイント
メリット
- 品質の標準化: 仕様→設計→実装の順序が強制される
- ドキュメント自動生成: 要件定義書、設計書、タスクリストが成果物として残る
- コードレビューの効率化: 各変更がどの要件に紐づくか明確
- オンボーディング改善: 新メンバーが仕様書を読んで機能を理解できる
考慮事項
- 学習コスト: コマンド体系とワークフローの理解が必要
- 確認作業の増加: 各フェーズで生成物を確認・承認する時間が必要
- 柔軟性のトレードオフ: 仕様変更時は設計・タスクの再生成が必要
導入のステップ案
- 個人での試用: 1つの機能で試してみる（本記事のような）
- チーム内共有: 体験をチームに共有し、フィードバックを収集
- テンプレートのカスタマイズ: プロジェクト固有の要件に合わせて調整
- 段階的展開: 新機能開発から適用し、徐々に範囲を広げる
学んだこと
意外だった落とし穴
- マネージドDBサービスの制約がテスト戦略に影響することがある
- 並行してブランチ開発していると、コンフリクト解消作業が発生する
- 生成されたタスクをそのまま実行するだけでなく、レビュー指摘への対応も必要
今後使えそうな知見
- 仕様承認後は丸投げ可能: 設計とタスク分解が終われば、実装は比較的自動化できる
- 要件トレーサビリティ: 各変更がどの要件に対応するかを追跡できるのは、監査やドキュメント作成に有用
- 並列タスク実行: 独立したタスクを並列で進めることで効率化できる
今後試してみたいこと
- テンプレートのカスタマイズ（プロジェクト固有のパターンを反映）
- 複数人での並列実装（タスクを分担して同時進行）
-
/kiro:validate-implによる実装検証の活用
終わりに
cc-sddは、AIコーディングツールの使い方を「とりあえず書いてもらう」から「仕様から設計、実装まで一貫して進める」へとシフトさせるツールだ。
今回の71ファイルにおよぶユーザー管理機能の実装では、品質を維持しながら手戻りを最小限に抑えることができた。特に、仕様定義段階で考慮漏れを発見できたことと、生成されたドキュメントが後から参照できることが大きなメリットだった。
一方で、vibe-codingと比べて事前準備と確認作業が増えるため、小さな変更には向いていない。**「大きな塊を計画的に進める」**というユースケースで真価を発揮するツールだと感じた。
チームへの導入を検討している方は、まず個人で1つの機能を試してみることをお勧めする。その体験をもとに、チームの開発スタイルに合うかどうかを判断できるはずだ。
この記事で紹介した内容は、実際の開発体験を簡略化したものです。プロジェクト固有の情報は一般化して記載しています。
関連技術: cc-sdd, Claude Code, Next.js 15, TypeScript, Prisma ORM, NextAuth.js, PostgreSQL RLS, 仕様駆動開発
参考リンク:
筆者: 91works開発チーム
Discussion