システム開発の現場では、テスト駆動開発（TDD）や振る舞い駆動開発（BDD）といったアプローチが広く知られています。
これらはいずれも「テスト」や「振る舞い」といった要素を軸に開発を進める手法ですが、近年注目されているのが 仕様駆動開発（Specification-Driven Development：SDD） です。
そして、そのSDDを実践するための一つの方法論が cc-sdd（Continuous Contract-based Specification-Driven Development） です。
この記事では、cc-sddとは何か、SDDとの関係、そして実際に使ってみた流れをご紹介します。
仕様駆動開発（SDD）とは？
SDDはその名の通り、「仕様（Specification）」を開発の中心に据える考え方です。
- TDD: テストコードを起点にする
- BDD: ユーザーの振る舞いを起点にする
- SDD: 形式的な仕様（API定義や契約仕様）を起点にする
SDDでは、仕様書が単なるドキュメントではなく、コード生成やテスト検証の基盤として機能します。
つまり、「仕様＝実装のソース」となり、コードと仕様の乖離を最小化できます。
cc-sddとは何か
cc-sdd（Continuous Contract-based SDD） は、仕様駆動開発をより実務的に回すための実践手法です。
- Continuous（継続的）: 開発サイクルの中で仕様と実装を常に同期させる
- Contract-based（契約ベース）: 仕様を「契約（Contract）」として扱い、実装やテストの根拠にする
- Specification-Driven Development: 仕様を起点にした開発手法
これにより、「仕様を定義 → テスト生成 → 実装 → 自動検証」 の流れをスムーズに回せます。
特にAPI開発やマイクロサービス開発において、仕様と実装のズレを防ぐ強力な武器となります。
実際にcc-sddを使ってみた
それでは環境を構築して実際に使ってみましょう。どんなものかをひとまず試してみたいので、Geminiの無料枠内でやってみたいと思います。
必要なものは下記の２つです。
✅️ cc-sdd
✅️ Gemini-CLI
cc-sddのインストール
最初にプロジェクトフォルダを作り、下記のコマンドでcc-sddをインストールします。
今回はGemini CLIを使うので、Gemini用のオプション。日本語指定でインストールしています。
npx cc-sdd@latest --gemini-cli --lang jaインストールすると、プロジェクトフォルダに下記のファイルが作成されます。
Gemini CLIのインストール
続いてGemini CLIのインストールを行います。
こちらも下記のコマンドだけでインストールが可能です。
npm install -g @google/gemini-cliGemini CLI の起動と認証
インストールできたのでGemini CLIを起動します。
ターミナルやコマンドプロンプトで「gemini」と入力します。
gemini
初回起動時は認証方法を聞かれるので、「1. Login with Google」を選択します。
ブラウザが開くので、Googleアカウントを選択して認証を行います。
以上で必要なセットアップは終わりです。
cc-sddの前提
それではcc-sddを実行していきます。
cc-sddのコマンドはヘルプから確認できます。日本製だけあって日本語のREADMEが用意されていて助かりますね。
今回は新規プロジェクトのケースを参考に進めてみます。
https://github.com/gotalab/cc-sdd/blob/main/docs/README/README_ja.md
https://github.com/gotalab/cc-sdd/blob/main/tools/cc-sdd/README_ja.md
なお、cc-sddはGemini CLIを通して実行するようになります。
（何気にここが重要だったりします。最初わからずコマンドプロンプトに必死に投げてました・・・）
機能仕様の初期化
最初に、作成する機能の仕様を作成します。コマンドは「/kiro:spec-init {仕様}」です。
今回は在庫管理システムを作ってみたいと思うのでGeminiに入力してみます。
（ブログ書きながら思ったのですが、仕様があまりにも曖昧ですね。。。）
途中、ファイル生成するため確認が入りました。
都度承認するのも面倒なので「2. Yes, allow always …」を選択します。
処理が終わったようですが、正直何が行われているかよくわかってないです・・・
出力されたコメントを読んでも要領を得ないですが、このあたりはGeminiの影響かもですね。
とりあえずspec.jsonとrequirements.mdが作られたようです。
入力された仕様がファイルに落ちていますね。
あと、今更気づいたのですが「”feature_name”: “inventory-management-system”」って書いてあります。この後のコマンドで使うのですが、この時はよくわからず進めてしまっています。
要件定義
続いて要件を作成します。コマンドは「/kiro:spec-requirements {feature_name}」です。
feature_nameの部分に作業内容書いてしまってますが、今回の場合は”inventory-management-system”が正しいのだと思います。
途中に承認が入りますが、前回同様「2. Yes, allow always …」を選択します。
完了すると、requirements.md に機能要件が記載されていました。
内容も在庫管理システムとしての要件は満たしていそうです。微妙な部分があれば直接修正可能です。
技術設計
次は要件定義にもとづいた技術設計の作成です。
コマンドは「/kiro:spec-design {feature_name}」です。
このあたりの手順が理解できておらず試行錯誤していましたが、まずは要件定義の承認が必要なようです。「-y」をつけることで承認できるようです。
要件定義を承認すると、技術仕様が作成され始めます。
技術設計書の生成が終わり、design.md が新しく作成されました。
変更内容を追加指示したり、design.md を直接修正することもできます。
タスク生成
技術設計が終わったので、実装するためのタスクを洗い出していきます。
コマンドは「/kiro:spec-tasks {feature_name}」です。
技術設計書の承認が必要そうなので、「-y」を指定して実行します。
タスクの生成が終わり、tasks.md が作成されました。
１９個のタスクに分割されていました。
実装
タスクの洗い出しが終わったので、タスクを実行していきます。
この実行方法がよくわからなかったので、キャプチャでは変なことしてますが、
コマンドは「/kiro:spec-impl {feature_name} {タスク番号}」のようです。
今回のサンプルでは「/kiro:spec-impl inventory-management-system 1.1」が正しかったようですね。
実装コードの作成後、テストコードも作ってくれました。
実際にテスト実行もしてくれるようです。
出力内容を確認しながら進めて行き、１つのタスクが終わったら次のタスクを指示という流れで進めます。
次々タスクを進めていたのですが、タスク2.3（タスク５個目）でGemini 2.5 Proの無料枠上限に引っかかってしまいました。
１日あたり1,000件のリクエストなので、このくらいかもですね。
Gemini 2.5 Proで引き続き行いたいので、後日続きを試したいと思います。
まとめ
cc-sddを使うことで、要件定義から実装までを段階的に進められ、生成物が積み重なっていく感覚があります。
要件定義や技術仕様の段階では、人が介在して方向性を確認・修正できるため、生成結果を柔軟にコントロールできる点も魅力的でした。
また、要件が requirements.md の単一ファイルにまとめられることで可読性が高い一方、要件が膨らむと分割したくなるケースも想定されます。このあたりは今後、ツールや運用方法の工夫を調査していく必要がありそうです。
実際に使ってみて、cc-sddには大きな可能性を感じました。
これまでバイブコーディング的な散発的実装に不安を覚えていましたが、cc-sddなら業務で利用できるレベルの出力が十分に期待できます。
今後は、cc-sddが扱える規模感やチーム開発における作業性、さらには既存プロジェクトへの適用などを試しながら、深堀りしてみたいと思います。
コメント