仕様駆動開発ツールcc-sddを使ってみました(その１)

今年に入ってずっとClaudeCodeを使ってバイブコーディングをやってきました。

作ったものとしたら、ワークフロー、経理システム、Zoom議事録、ブログ自動投稿サービス、メール管理システムなどなど。。
また、変わったところでは、スクラッチで組んでいたレガシーシステムのメンテや拡張に利用してみたり。

平均して１〜２ヶ月単位で、ベータリリースまで持って行ってました。
ちなみにベータ止まりなのは、お客さんの方がついてこれてない感じはありますw

仕様駆動開発ツールcc-sddを使ってみました(その２)

AIはうそつき。。

バイブコーディングをやってる人ならお分かりだと思います。

なんか動き変だなぁ。。。なんで？？？
あ！ダミーデータでした！！

お〜い、ページ404になるよ〜！！さっきできましたって報告したやん！
すみません！実は実装してませんでした。。

CLAUDE.mdに書いてる動き守ってないやん！
読んでませんでした。。

これで動くはずです。たぶん。。。
※たぶんってなんやねん！！

まぁ、こんなの可愛い方です。AIとの付き合いは、もう忍耐の世界です(^^;
Sonnet4.5になったらちょっとは治るかと思いましたが。。。

そんなこんなで、最近は、起動時に「CLAUDE.md読んで理解してね」って必ず依頼するようにしています(^^;

仕様駆動開発ってなんじゃらほい？

ちょっと前からこの状況はなんとかせねばとは思ってました。

ただ、CopilotのようにAIエディタでは、面白みを感じず、あくまでもバイブでなんとかやりたいなぁってのは譲れませんでした。
SuperFrame入れて、テストの構成やら、品質管理を対策してみたり、Serenaで効率を対策してみたりはしていたのですが、あいも変わらず弄ばれる日々が続いていましたorz

そんなとき、仕様駆動開発(Spec Driven Development)というのを知りました。
仕様駆動開発は以下の流れでAIと協議をしながら進める開発スタイルです。
１）要件定義：何を作るか明確にする
２）設計　　：どう作るか計画する
３）実装計画：タスクに分解する
４）実装　　：実際にコードを書く
そして各フェーズは、人間が承認することで進むことができるようになっています。
最初知ったのは、githubから提供されている「Spec Kit」だったのですが、調べていく中で今回使用した「cc-sdd」を知ることとなりました。

cc-ssdとは？

cc-sddは日本の開発者が作ったツールです。
ですので、完全日本語対応となっているのが気になった1番のポイントです。
完全無料のオープンソースとして提供されていて、本当にありがたいことです。
エラーメッセージやドキュメントも日本語なのは嬉しいところです(^^)
また、AWS Kiroのスタイルと互換性があり、コマンド自体も/kiro:xxxxとなっていて、将来Kiroに移行する際もスムーズです。

日本語ドキュメント：こちら

cc-sddでの一般的な流れは以下のようになります。

✅ Phase 1: 初期化 (完了)
↓
⏳ Phase 2: 要件定義 (/kiro:spec-requirements)
↓
⏳ Phase 3: 設計 (/kiro:spec-design)
↓
⏳ Phase 4: タスク生成 (/kiro:spec-tasks)
↓
⏳ Phase 5: 実装 (/kiro:spec-impl)

重要: 各フェーズは人間によるレビューと承認が必要です。フェーズをスキップすることはできません。

インストールと開発の流れ

STEP0：インストールします

インストールをします。

・ClaudeCode利用時
% npx cc-sdd@latest –lang ja

・Cursor IDE用
npx cc-sdd@latest –cursor –lang ja

・Gemini CLI用
npx cc-sdd@latest –gemini-cli –lang ja

・カスタムディレクトリ指定
npx cc-sdd@latest –kiro-dir docs/specs

わたしはClaudeCode用を利用しています。

STEP1：ステアリングドキュメントの作成

/kiro:steering
・ディレクトリ構造

cc-sdd/
├── .claude/ 　　# Claude Code 設定とコマンド
│ └── commands/ # カスタムスラッシュコマンド
│ └── kiro/ 　　　# Kiro SDD コマンドグループ
spec-design.md
spec-impl.md
spec-init.md
spec-requirements.md
spec-status.md
spec-tasks.md
steering-custom.md
steering.md
validate-design.md
validate-gap.md
├── .kiro/ 　　　　# Kiro SDD データディレクトリ
│ └── steering/ 　# プロジェクトコンテキスト
product.md　　　　　# プロダクト概要
structure.md　　　　# 技術情報
tech.md　　　　　　　# ディレクトリ構造

作成されたファイル

1. product.md (4.7 KB)- ビジネスコンテキストがすべての開発決定に必要
– プロダクト概要と説明
– コア機能（ステアリング管理、スペック作成、実装と検証、進捗管理）
– ターゲットユースケース（新機能開発、複雑なプロジェクト構造化、AI支援開発の標準化）
– 主要な価値提案（体系的ワークフロー、Claude Code ネイティブ統合、柔軟なステアリングシステム）
2. tech.md (7.8 KB)- 技術的制約がすべてのコード生成に影響
– アーキテクチャと設計原則
– バックエンド技術（Claude Code、マークダウンベースのコマンド、JSON メタデータ）
– 開発環境とセットアップ手順
– よく使うコマンド一覧
– ディレクトリ構造とバージョン管理
3. structure.md(10.5 KB)- アーキテクチャ決定がすべてのファイル組織に影響
– ルートディレクトリ構成
– サブディレクトリの詳細構造
– ファイル命名規則
– コード組織パターン
– 主要アーキテクチャ原則
– 拡張ガイドラインとベストプラクティス

STEP2：新しい機能の仕様を初期化

/kiro:spec-init <詳細なプロジェクト説明>

今回はサンプルにあったのを実装してみました。
/kiro:spec-init “次の体調を予報としてforecastタブに表示する機能（数時間分）”

⏺ ✅ 仕様の初期化が完了しました

生成された機能名と根拠

機能名: health-forecast

選定理由:

– 「体調予報（health forecast）」という機能の本質を端的に表現
– forecastタブでの表示という主要な特徴を反映
– ケバブケース形式で命名規則に準拠
– 簡潔で理解しやすい英語表記

プロジェクト概要

数時間分の体調予報をforecastタブに表示する機能を実装します。ユーザーが今後の体調変化を予測し、適切な行動計画を立てられるようにします。

作成されたファイル

📄 .kiro/specs/health-forecast/spec.json

– フェーズ: initialized
– 言語: ja（日本語）
– 承認状態: すべて未承認（requirements, design, tasks）

📄 .kiro/specs/health-forecast/requirements.md

– プロジェクト説明を含むテンプレート
– 要件セクションは次フェーズで生成

📝 [CLAUDE.md](http://claude.md/)

– Active Specifications セクションに health-forecast を追加

次のステップ

段階的な開発ワークフローに従って、次のコマンドを実行してください：

/kiro:spec-requirements health-forecast

このコマンドは：

– EARS フォーマットに基づいた詳細な要件を生成
– [requirements.md](http://requirements.md/) を完成させる
– spec.json のフェーズを requirements-generated に更新

重要な注意事項

段階的開発の原則:

– 現時点では spec.json と [requirements.md](http://requirements.md/)（テンプレート）のみを作成
– [design.md](http://design.md/) と [tasks.md](http://tasks.md/) は後続フェーズで作成されます
– 各フェーズで承認を得てから次に進む設計

承認フロー:

1. 要件生成 → レビュー → 承認
2. 設計作成 → レビュー → 承認
3. タスク生成 → レビュー → 承認
4. 実装開始

STEP3：要件定義書の作成

/kiro:spec-requirements health-forecast

✅ 要件ドキュメントの生成が完了しました

生成された要件の概要

health-forecast 機能の詳細な要件を EARS フォーマットで定義しました。

要件カテゴリー（10項目）

1. 体調予報データの生成 – 過去データに基づく予測生成と信頼度スコア
2. 予報の時間粒度と範囲 – 1時間単位で最大8時間先までの予報
3. 予報データの視覚化 – 時系列グラフでの直感的な表示
4. 予報精度の表示 – 信頼度インジケーターと精度レベル表示
5. 体調傾向の通知 – 大きな変化の事前警告
6. 過去予報との比較 – 予報精度の検証機能
7. 予報アルゴリズムの選択 – 複数の予測手法から選択
8. データ不足時の対応 – 適切なフィードバックとガイダンス
9. 予報更新の通知 – 自動・手動更新の通知
10. 予報データのエクスポート – CSV形式でのデータ出力

EARS フォーマットの活用

すべての受入基準は EARS 構文に従って記述されています：

– WHEN [イベント] THEN [システム] SHALL [応答] – イベント駆動の要件
– IF [条件] THEN [システム] SHALL [応答] – 条件付き要件
– WHILE [継続条件] [システム] SHALL [継続動作] – 継続的な動作
– WHERE [場所/コンテキスト] [システム] SHALL [動作] – コンテキスト依存の要件

更新されたメタデータ

📄 .kiro/specs/health-forecast/spec.json

– フェーズ: requirements-generated
– requirements.generated: true
– requirements.approved: false ← レビューが必要

—

次のステップ

要件をレビューしてください：

✅ 要件が適切な場合

次のコマンドで設計フェーズに進みます：

/kiro:spec-design health-forecast -y

– y フラグにより要件を自動承認し、設計ドキュメント生成に直接進みます。

🔄 修正が必要な場合

修正内容をお知らせください。[requirements.md](http://requirements.md/) を更新した後、再度このコマンドを実行します。

—

レビューのポイント

– 要件の範囲は適切か？
– EARS フォーマットの受入基準は明確か？
– 追加すべき機能はないか？・
– 削除すべき不要な機能はないか？