Claude Codeを使った仕様駆動開発が可能なcc-sddをFlutterで試した
はじめに
Claude Code や Cursor などの AI コーディングエージェントを使っていると、こんな経験はありませんか？
- 「この機能実装して」と雑に投げたら、既存のコード規約を無視した実装が返ってきた
- レビューで「設計が違う」と指摘されて、ほぼ全面書き直しになった
- 実装後に「なぜこの設計にしたのか」が分からず、後から困った
こういった課題を解決できると噂の、SDD（Spec-Driven Development：仕様駆動開発） という手法を弊社のFlutterプロジェクトで試してみました。
まず、SDD とは何か
SDD は、AI に実装させる前に「AI が実行可能なレベルの仕様書」を作成し、それをベースに開発を進める手法です。
SDDのアプローチについて
SDD のアプローチ
仕様書を作成
↓
仕様書をレビュー（ここで認識を合わせる）
↓
AI が仕様書に従って実装
↓
実装レビュー（手戻りが少ない）
cc-sdd とは
今回使用した cc-sdd は、Claude Code や Cursor で SDDを実践するためのツールです。
cc-sddは、Kiroという仕様駆動開発ツールの考え方を採用しており、Claude
CodeやCursorといったコーディングエージェント向けにカスタマイズされています。
コマンドを実行すると以下のような仕様書が自動生成されます。
- Steering: プロジェクトのアーキテクチャや規約
- requirements.md: 要求定義（何を作るか）
- design.md: 詳細設計（どう作るか）
- tasks.md: 実装タスクの分解
実際に試してみた
Flutterアプリで「ユーザーのアクセス状態をローカルにキャッシュする機能」を SDD で開発してみました。
使ったコマンド
# 1. プロジェクト情報を学習(これは一度だけ実行すればOK,必要に応じて更新)
/kiro:steering
# 2. 機能の仕様を初期化
/kiro:spec-init "ユーザーのアクセス状態をローカルキャッシュする機能"
# 3. 要求定義を作成
/kiro:spec-requirements cached-access-status
# 4. 詳細設計を作成
/kiro:spec-design cached-access-status -y
# 5. タスク分解
/kiro:spec-tasks cached-access-status -y
# 6. 実装
/kiro:spec-impl cached-access-status 1.1,1.2
design.mdの作り込みが重要
SDD を最低限活用するためには、以下が重要だと考えています。
Plan Mode でのdesign.mdの作り込み
Steering を設定した後、Plan Mode を使って requirements.md や design.md をしっかり作り込むことが重要です。
特にdesign.mdを細かく作り込むのが大事って思います。
Plan Modeでは
- 生成された仕様書を確認し、必要に応じて編集
- 既存コードへの具体的な参照パス（ファイル名や関数名）を追記
- プロジェクト固有の制約や注意点を明記
これらのステップを踏むことで、AI の実装精度が向上したなーって思ってます。
もちろん、プロジェクト固有のアーキテクチャパターンや規約を Steeringにしっかり書いておくことも大事ですが、design.mdの作り込みが最も効果的でした。
良かった点
1. 実装後の手戻りが減った
従来は実装後のレビューで指摘があり手戻りが発生することが時々ありましたが、SDDでは仕様の段階で認識を合わせられて、それらのドキュメントがSSOTになるので、実装後の大幅修正が以前より少なくなりました。
2. チーム開発での並列実装がしやすい
タスクが明確に分解されるため、複数人で並列して実装を進めやすくなりました。
全員が同じ requirement.md、design.md を見ているので、認識のズレが起きにくいです。
3. ドキュメントが自動的に残る
実装後に「ドキュメント書かなきゃ...」となることがなく、仕様書がそのままドキュメントとして機能します。
4. 設計についてチーム全体で議論できる
仕様レビューの段階で、チーム全体で設計について議論する機会が生まれました。
コードレビューで揉めるより、仕様レビューで揉む方が建設的だと感じました。
大変な点
1. 仕様書が長大になる
想像以上に仕様書のボリュームが大きくなります。
小規模な機能でも、生成される仕様書全体を読むのに時間がかかりました。
対策としては以下のようなことをすればいいと思ってます：
- 最初から機能を小さく分割する
- 必要な項目だけに絞る（全セクションを埋める必要はない）
- レビューは重要な判断箇所に絞る
2. 既存コードとの統合が難しい(コードベースが大きければ特に)
大きめなプロジェクトだと、AI がすべてのコンテキストを把握しきれず、既存コードとの整合性が取れないことがあります。
対策（2ステップアプローチ）：
- Steering の充実化: 既存のアーキテクチャパターンや参考実装の場所を詳しく書く
-
Plan Mode での作り込み: 生成された
design.mdを Plan Mode で編集し、既存コードへの具体的な参照を追記する
3. 小規模タスクには不向き
「ボタンの色を変える」「テキスト修正」といった小規模タスクに SDD を使うのは不向きだなーってお思います。
4. 組織、チーム全体のプロセス変更が必要
SDD は単にツールを導入すれば済む話ではなく、「仕様を先に決める」という文化を組織、チーム全体で共有する必要があります。
エンジニアだけで完結しないため、他の業種の方(例: QA) も巻き込む必要があったりもします。
もちろん、共有できるというのはメリットとも言えますが。
SDD が向いているケース・向いていないケース
実際に使ってみて、以下のように整理できました。
| 向いている | 向いていない |
|---|---|
| 中〜大規模の機能追加 | UI の微調整 |
| チーム開発での並列実装 | 1 ファイルだけの修正 |
| API 連携・データモデル・ビジネスロジック | 探索的な開発（仕様が固まっていない） |
| 要件が明確で安定している領域 | プロトタイピング・PoC |
実践のコツ
1. 最小限の仕様から始める
全セクションを完璧に埋める必要はありません。最低限必要なのは以下です。
- Intent（背景）: なぜ作るのか
- 振る舞い仕様: 何を作るのか
- 受け入れ条件: どうなれば完了か
2. レビューコマンドで仕様の品質を担保する
cc-sddには設計品質をレビューするコマンド（/kiro:validate-design）が用意されています。
レビューの流れ：
- design.mdを作成後、
/kiro:validate-design <feature-name>を実行 - AIが設計をレビューし、GO/NO-GO判定を出してくれる
- NO-GOの場合は指摘事項を修正し、GOが出るまで繰り返す
- GOが出た後、人間がさらに細かい部分をレビューして最終調整
この2段階レビュー（AIレビュー → 人間レビュー）により、仕様の品質を高められます。
3. DevOps 基盤が整っていることが前提
SDD は「高速な検証と改善のサイクル」を前提としています。以下が整っていないと効果が半減するので、そこが整ってない場合は、まずは整えましょう。
- CI/CD パイプライン
- 自動テスト環境
- コードレビュープロセス
まとめ
SDD を実際に試してみて、適切な場面で使えば強力な武器になると感じました。
ただし、万能ではありません。小規模タスクには不向きですし、チーム、組織全体のプロセス変更も必要です。
個人的には、design.mdをとにかく作り込むことが最も効果的だったので、まずはこれを意識してやってみると良いかもしれません。
Discussion