図: 生成AIにより作成
はじめに
ゼンリンデータコムで、開発部門に所属している村田です。
普段は様々な案件の運用から開発に携わっており、最近は運用フロー改善から開発までAIを活用しています。
「AIにコード書かせたら爆速だったのに、レビューで"なぜこの実装？"と聞かれて固まった」——そんな経験、ありませんか？
私もVibeコーディングにどっぷりハマっていた一人です。確かに速い。でも設計意図が不明確、仕様変更の影響範囲が把握できない、チームのスキル差で品質がばらつく。気づけばAIとの壁打ちで膨れ上がったコードはスパゲッティ状態、メンテナンスも困難に。
そこで出会ったのが SDD（仕様駆動開発） です。勉強会で発表した内容を元に、実践知見を共有します。
SDD（仕様駆動開発）とCC-SDD
図: 生成AIにより作成
SDD（Specification-Driven Development）は仕様書を起点に開発を進める手法です。
設計意図が明確になり、AIへの指示も構造化されるため生成コード品質が安定します。
Vibeコーディングの問題点——設計意図が曖昧、仕様変更の影響把握が困難、ドキュメントと実装の乖離が常態化——を仕様というレイヤーで解決するアプローチです。
SDDツールはKiro IDEやSpec-kit等もありますが、CC-SDD（gotalab/cc-sdd） を選択しました。
（※ダウンロードと細かい操作手順はこちらを参照）
選んだ理由は、現在利用しているCursorにそのまま統合できること、OSSで導入ハードルが低いこと、そしてClaude・Gemini・Copilotなど主要AIエージェントに幅広く対応しており、他のエージェントを利用しているチームへの展開も可能な点です。
CC-SDDの開発フロー
図: 生成AIにより作成
私が行っているフローは「要望書 → 要件定義書 → 見積 → 実装」の4ステップです。
本来のCC-SDDのフローには見積はありませんが、Cursorカスタムコマンドで見積生成を追加しています。要望書と要件定義書をプロンプトに与えることで、AIが機能の全体像・非機能要件・技術的制約を把握した状態で工数を算出するため、ゼロから見積もるより格段に精度の高いたたき台が得られます。
① 要望書： テンプレートを利用し、実装予定メモヒアリング結果を構造化して記録します。それに加え、非機能要件や案件特有の情報などを細かく記載する事で、後続処理の精度が高まります。
② 要件定義書： /kiro:spec-requirements でEARS形式の要件定義書を自動生成します。EARS形式は「〇〇の場合、システムは△△すること」のように条件と振る舞いを明確に分離する記法で、曖昧さが排除されAIが正確にタスク分解しやすくなります。
③ 見積： カスタムコマンドで要望書・要件定義書に基づく工数を自動算出。機能単位の工数明細が得られるため、レビューや調整がしやすく、そのまま社内見積のたたき台として活用できます。
④ 実装： /kiro:spec-design で技術設計書を生成、/kiro:spec-tasks で実装タスクを自動分解、/kiro:spec-impl でタスクに沿ったコードを生成します。仕様→設計→実装が一本の線で繋がるため、「なぜこの実装？」にいつでも答えられます。
変更に強いフロー
実装段階で要件や設計に変更が加わった際には、再度要望書に追加しフローを流し直します。これにより、AI活用前のフローでありがちだった「設計書だけ直して要件定義には反映されていない」といった問題を防ぐことができます。仕様から実装まで一気通貫で再生成できるため、変更が発生しても小さなアジャイルサイクルのように素早く回すことも可能です。
よかったこと＆注意点
よかったこと
要件定義時にヒアリング漏れのチェックができ精度が向上しました。
決まったルールで生成されるためドキュメント品質が上がり、見積のひな型作成も効率化できました。
以前は担当者の経験頼みだった見積が、機能単位の明細が自動で出るため「この機能はなぜこの工数？」にすぐ答えられるようになり、レビューでの手戻りも減りました。
要件漏れがあってもコマンドで後続ドキュメントに追加でき、修正が楽です。
従来は要件変更が入ると要件定義書・設計書・見積を個別に修正する必要がありましたが、CC-SDDでは要望書に追記してフローを流し直すだけで後続ドキュメントが再生成されるため、修正漏れの心配がなくなりました。
注意点
AIの出力を全面的に信じてはいけません。おかしな点は必ずあるので人間レビューは必須です。
テンプレートについては、最初は汎用的なもので始めたところ、案件固有の制約（既存DBの構造や外部API連携など）がうまく反映されず精度の低い状態でした。
AIに対し明確に伝えるよう、非機能要件や技術スタックの記載欄を追加していくことで徐々に実用レベルになっており、この試行錯誤はまだ続いています。
カスタムルールでAI挙動をコントロールする工夫も必要でした。
AIと言えど、良かれで行う行動がしばしば見られるため、〇〇の後は△△をすることといったルールや、自己チェックを行いレポートを出力するルールを設定することで、タスク完了時の内容の信頼性もアップしました。
EARS形式はAIフレンドリーな構造のため、人間が読むには慣れが必要で人のレビューに適さない内容のため、AIにCC-SDDの要件定義書を読ませ、日本語寄りに変換した要件定義書や要件トレーサビリティも出力したりもしています。
最後に
実際にCC-SDDを適用したところ、開発フロー改善効果は高くカスタムルールの追加などを行うことで、更なる効率アップが期待出来ると感じました。
AIの「速さ」に「質」を加えたい方、CC-SDDは試す価値ありです。 ぜひ gotalab/cc-sdd を試してみてください。
今後の展望
現在、既存のCC-SDDワークフローを壊さない形での機能追加に取り組んでいます。
特に注目しているのが VSDD（Verified Spec-Driven Development） という概念です。
仕様→テスト→実装の順序を機械的に強制し、最終的に「欠陥を探すことだけを命じられたAI」によるレビューを通過したコードだけを完了とみなす、という考え方です
https://gist.github.com/dollspace-gay/d8d3bc3ecf4188df049d7a4726bb2a00
CC-SDDへカスタムルールなどでの統合を現在模索しています。