every Tech Blog

株式会社エブリーのTech Blogです。

トップ > AI > 仕様駆動開発ツールcc-sddを実務で使ってみた

仕様駆動開発ツールcc-sddを実務で使ってみた

AI バックエンド

はじめに

こんにちは、開発1部でソフトウェアエンジニアをしている新谷です。 今回は、AIエージェントで仕様駆動開発を実現する国産ツール「cc-sdd」を実務で約1ヶ月使用してみたので紹介します。

cc-sddとは

cc-sddは、仕様駆動開発をAIエージェントで実現する国産ツールです。

github.com

2025年10月10日時点では、以下のAIツールに対応しています。

  • Claude Code
  • Cursor IDE
  • Gemini CLI
  • Qwen Code

本記事の事例では、Claude Codeを使用しています。

cc-sddは、3つのファイルを順次承認制で作成していく仕組みになっています。

  • requirements.md: 要件定義フェーズで使用するファイル。受け入れ基準がEARS記法で書かれます
  • design.md: 技術設計書として使用するファイル。実装の詳細な設計を記述します
  • task.md: 実装可能な単位にタスクを分解したファイルです

各ファイルの具体的な内容については、後述の実務事例で紹介します。

仕様駆動開発を実務で導入したいモチベーション

端的に言うと、設計書を書けばシステムが完成するという開発フローが、チームでの開発生産性を大きく向上させると考えているからです。

見込める開発効率

具体的には、以下のような開発効率の向上が見込めると考えています。

  • コードを書くときにはAIとやり取りしなくていいので、その間別タスクが可能
  • design.mdを作るときにチームで設計が問題ないか認識を合わせられる
  • 事前に設計などを共有できているため、コードレビューの負担が軽減される

課題

一方で、以下のような課題もあると考えています。

  • 結局実装しないと分からない部分もあるのではないか
  • design.mdをどの粒度まで作り込むべきか判断が難しい

実務で取り組んだ事例

実際に2つのAPI開発でcc-sddを使用してみました。

前提条件

  • チーム全員が使っているわけではなく、私だけが使用
  • バックエンドのAPI開発での適用
  • まだ1ヶ月程度の使用期間
  • 既存サービスに新しいAPIを追加する実装
  • 最低限のCLAUDE.mdは作成済み
  • 事前にsteeringファイルは作成済み

事例1: アプリ内のプッシュ通知設定API

要件の概要

  • アプリにプッシュ通知のon/offボタンを作成
  • 現在の状態を取得するAPIと、状態を変更するAPIを実装

作成されたファイルの例

requirements.md（一部）

### Requirement 1: 通知設定の永続化
**User Story:** アプリのユーザーとして、プッシュ通知の受信設定を保存し、その設定が永続的に維持されることを期待する

#### Acceptance Criteria

1. WHEN ユーザーが初めてアプリを利用開始する THEN システムはプッシュ通知設定をデフォルトで「有効」として初期化 SHALL
2. IF データベースにユーザーの通知設定が存在しない THEN システムはデフォルト値として「有効」を返す SHALL
3. WHEN ユーザーが通知設定を変更する THEN システムはその設定をデータベースに即座に永続化 SHALL
4. IF データベース保存に失敗した THEN システムはエラーレスポンスを返し、設定は変更されない SHALL
5. WHERE 同一ユーザーが複数デバイスを使用している THE SYSTEM SHALL 全デバイスで統一された通知設定を適用

design.md（一部）

## コンポーネントと インターフェース

### バックエンドサービス & メソッドシグネチャ

#### NotificationSettingService

type NotificationSettingService struct {
    repo domainRepository.UserNotificationSettingRepository
}

// GetUserNotificationSetting ユーザーの通知設定を取得
func (s *NotificationSettingService) GetUserNotificationSetting(ctx context.Context, userID int64) (*domainModel.UserNotificationSetting, error)

// UpdateUserNotificationSetting ユーザーの通知設定を更新
func (s *NotificationSettingService) UpdateUserNotificationSetting(ctx context.Context, userID int64, enabled bool) (*domainModel.UserNotificationSetting, error)

task.md（一部）

## パート1: 通知設定API機能

### フェーズ1: データモデルとマイグレーション

- [x] 1. データベーススキーマとマイグレーションの作成
  - db/migrations/配下に新しいマイグレーションファイルを作成
  - user_notification_settingsテーブルのCREATE文を実装
  - インデックス設計（user_id, enabled）を含める
  - ロールバック用のDROP文も実装
  - _要件: REQ-1, REQ-6_

cc-sddの適用結果

  • design.mdは、チームへの共有も含めて3日ほどかけて作成・修正しました
  • task.mdは少し修正した程度で済みました
  • 実装後にコードの大きな修正は不要でした

事例2: ミッション達成計算API

要件の概要

  • ゲームでよくあるアクションによって実績が解除される機能
  • 事前に決めたミッションをユーザーが達成しているかどうかを判定
  • ミッションは複数あり、入れ替わりや制限期間はなし

作成されたファイルの例

requirements.md（一部）

### Requirement 1: ミッション管理機能
**Objective:** 管理者として、ミッションの定義と管理を柔軟に行いたい、将来的な拡張が容易にできるようにするため

#### Acceptance Criteria

1. WHEN システムが起動される THEN ミッションサービス SHALL サーバー設定から全てのミッション定義を読み込む
2. IF 新しいミッション定義がサーバー設定に追加される THEN ミッションサービス SHALL アプリケーション再起動なしに新ミッションを有効化する
3. WHERE ミッション定義が存在する THE ミッションサービス SHALL 以下の情報を管理する：ミッションID、名称、達成条件、表示順序
4. WHEN ミッション定義が不正な形式で設定される THEN ミッションサービス SHALL エラーログを出力し、該当ミッションを無効化する

design.md（一部）

### Domain Layer

#### Mission

**Responsibility & Boundaries**
- **Primary Responsibility**: ミッション定義とその達成条件を管理
- **Domain Boundary**: ミッションドメイン
- **Data Ownership**: ミッションのメタデータと達成条件
- **Transaction Boundary**: 読み取り専用（設定ファイルから）

**Dependencies**
- **Inbound**: MissionService
- **Outbound**: なし
- **External**: なし

**Contract Definition**

type Mission struct {
    ID               string          `json:"id"`
    Title            string          `json:"title"`
    RequiredCount    int             `json:"required_count"`
}

task.md（一部）

## ミッション機能Phase1 実装タスク

- [x] 1. データベースとドメインモデルの基盤構築
- [x] 1.1 ユーザーミッション達成記録テーブルの作成
  - user_mission_completionsテーブルのマイグレーションファイル作成
  - user_id, mission_id を複合主キーとして定義
  - created_atインデックスの追加
  - ロールバック用のダウンマイグレーション作成
  - _Requirements: 1.3, 7.1, 8.1_

cc-sddの適用結果

  • design.mdは5日ほどかけて作成・修正しました
  • task.mdは少し修正した程度でした
  • 実装に関しては、コードの責務や書き方などが不適切で大きく修正が必要でした

うまくいかなかった原因

  • ロジックが複雑だったにもかかわらず、design.mdに詳細を記載できていなかった
  • CLAUDE.mdの記載が不足していた
    • ロジックをどこに配置すべきか、責務の定義が不明確
    • テストの書き方の指針が不足
  • task.mdのレビューが不十分だった

design.md作成について

今回初めてdesign.mdを作成しましたが、思った以上に時間がかかりました。 原因としては、以下のようなものがあると考えています。

  • 自分の設計力不足
  • どの粒度で記載すべきかの判断に迷った
  • 別タスクとの並列作業によるスイッチングコスト
  • チームへの設計共有時に発生するレビュー時間

まとめ

cc-sddを約1ヶ月実務で使用してみて、以下のことがわかりました。

  • 簡単な新規のAPI追加実装であれば、CLAUDE.mdを適切に書いておくことで修正不要で実装できる可能性がある
  • 複雑なロジックを持つAPIや既存APIの改修については、まだチューニングが必要
  • design.mdにどこまでの粒度で記載すべきか、まだ明確な基準が定まっていない
  • design.mdの作成には3〜5日かかっており、設計スキルやツールへの習熟が必要

仕様駆動開発は、設計とレビューだけで実装が完了する世界を作れる可能性があると考えています。 今後も試行錯誤を重ねながら、開発速度を爆速にできるよう取り組んでいきたいと思います。