こんにちは、とまだです。
みなさん、AWS Kiroの仕様駆動開発（Spec-Driven Development）は試したことあるでしょうか？
仕様駆動開発は「要件定義→設計→実装」の順番でAIと協働しながら進める開発スタイルです。
ただ、Kiroはウェイトリストに登録しないと使えないし、使えるモデルも限られているんですよね。
今回は、この仕様駆動開発をClaude Codeで実現できる国産ツール「cc-sdd」を実際に使ってみたので、その導入から実践まで詳しく解説します。
忙しい人のために要約
- cc-sddは仕様駆動開発をClaude Codeで実現する国産ツール
- AWS Kiroのスタイルと互換性があり、日本語完全対応
- 要件→設計→タスク分解→実装の段階的承認フローで品質向上
-
npx cc-sdd@latest --lang jaの1コマンドで導入可能 - 既存プロジェクトでもステアリング機能でスムーズに導入可能
- Cursor IDEやGemini CLIにも対応
動画でも解説してます！
仕様駆動開発（Spec-Driven Development）とは？
従来の開発スタイルの課題
皆さん、Claude Codeで開発をする時にはどのようなスタイルで進めていますでしょうか？
適当にバイブスコーディングを進めていると、思いつくままに実装してしまい、要件や完成物がブレてしまうという経験はありませんか？
AIが優秀になったからこそ、「とりあえず作って」と伝えると、AIが勝手に判断して進めてしまいます。
その判断がプロジェクトの方向性と合っていればいいのですが、AIはコンテキストの全てを理解しているわけではありません。
その結果、完成してから「思っていたものと違う」となることが多いかもしれません。
これは時間の無駄になるだけでなく、作り直しによるモチベーション低下にもつながります。
仕様駆動開発の流れ
仕様駆動開発は、以下の順序で進めます。
- 要件定義：何を作るか明確にする
- 設計：どう作るか計画する
- 実装計画：タスクに分解する
- 実装：実際にコードを書く
この流れのポイントは、各フェーズが独立していることです。
要件を決めてから設計、設計が固まってからタスク分解、という具合に、前のフェーズが完了してから次に進みます。
重要なのは、各フェーズで人間による承認が必要という点です。
この承認プロセスがあることで、AIが独断で進めることを防ぎ、人間の意図を正確に反映できるようになります。
AIが勝手に進めないので、先にあるべき姿（クリア条件）が明確になっています。
そのため、人間もAIも迷わない開発が進められるというメリットがあります。
さらに、仕様書として残るので、後から「なぜこういう実装になったのか」を振り返ることも容易です。
cc-sddの特徴
国産ツールならではの強み
cc-sddは日本の開発者が作ったツールです。
日本のエンジニアのニーズを理解した上で設計されています。
具体的な特徴は以下の通りです。
- 完全日本語対応：ドキュメント、コマンド、エラーメッセージすべて日本語
- すぐに使える：ウェイトリスト不要、npmコマンド一発で導入
- 既存プロジェクト対応：ステアリング機能で既存コードを理解してから開始
日本語対応は単に翻訳されているだけでなく、日本語として自然な表現になっています。
エラーメッセージも「何が問題で、どう解決すればいいか」が明確に書かれています。
英語のエラーメッセージを翻訳する手間もありません。
日本の方が開発者なので、ドキュメントは日本語対応されています。
Zennなどの技術プラットフォームでも盛り上がりを見せ始めている状況です。
AWS Kiroとの比較
AWS Kiroとcc-sddの違いを表にまとめました。
それぞれのツールの特徴を比較することで、cc-sddの利点が明確になります。
| 項目 | cc-sdd | AWS Kiro |
|---|---|---|
| 利用開始 | 即時・無料 | ウェイトリスト必要 |
| 言語 | 日本語ネイティブ | 英語メイン |
| 使用可能モデル | 制限なし | 指定モデルのみ |
cc-sddの大きな利点は、すぐに使い始められることです。
Kiroのウェイトリストに登録して待つ必要がなく、今すぐ仕様駆動開発を試すことができます。
また、使用できるLLMモデルに制限がないため、最新のClaude 3.5 Sonnetなど、好きなモデルを使うことができます。
良い意味で似ています。
Kiroを待たずに同じような開発ができるのは嬉しいですね。
生成される仕様書のフォーマットもKiroと互換性があるため、将来Kiroに移行する際もスムーズです。
一般的に認知されている Kiro の仕様駆動開発の流れとも同一ですので、違和感なく使えました。
Kiroのドキュメントや記事を読んだことがある方なら、すぐに理解できるはずです。
インストールと初期設定
基本的なインストール手順
インストールは簡単です。
プロジェクトのルートディレクトリで以下のコマンドを実行するだけです。
npx cc-sdd@latest --lang ja
このコマンドは、デフォルトでClaude Code対応の設定をインストールします。
--lang jaオプションで日本語モードを有効にします。
実行時の注意点として、以下を確認してください。
-
CLAUDE.mdの上書き確認が出るので、既存のCLAUDE.mdがある場合はバックアップを推奨 - デフォルトでClaude Code対応なので、他のツールを使う場合は別途オプション指定が必要
インストールが完了すると、必要なコマンドファイルと設定ファイルが自動的に配置されます。
その他のプラットフォーム対応
cc-sddは、Claude Code以外のAIツールにも対応しています。
それぞれのツールに合わせたオプションを指定することで、適切な設定がインストールされます。
# 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
※Codex CLI らしきカスタムコマンドファイルもありましたが、READMEには記載がなかったので省略。
Cursor IDEを使っている方は--cursorオプションを指定してください。
Gemini CLIを使っている方は--gemini-cliオプションを指定します。
また、仕様書の保存先をカスタマイズしたい場合は、--kiro-dirオプションで指定できます。
デフォルトでは.kiroディレクトリに保存されますが、プロジェクトの構成に合わせて変更可能です。
生成されるファイル構造
インストール後、プロジェクトには以下のようなディレクトリ構造が追加されます。
.claude/
├── commands/
│ └── kiro/ # スラッシュコマンド格納
docs/
├── steering/ # プロジェクトコンテキスト
│ ├── product.md # プロダクト概要
│ ├── tech.md # 技術情報
│ └── structure.md # ディレクトリ構造
└── specs/ # 機能仕様
それぞれのディレクトリには明確な役割があります。
-
.claude/commands/kiro/：仕様駆動開発用のスラッシュコマンドが格納されます -
docs/steering/：プロジェクト全体のコンテキスト情報を保存 -
docs/specs/：各機能の仕様書を管理
この構造により、仕様書とコードが同じリポジトリで管理できます。
Gitでのバージョン管理も容易になります。
実践：既存プロジェクトでの開発フロー
実際に個人開発中のアプリに使ってみました。
実際の開発の流れを、具体的なコマンドと生成されるファイルを交えて説明します。
今回は、体調を記録するアプリに「次の数時間の体調を予測する機能」を追加した流れを紹介します。
ステップ1：ステアリング（プロジェクト理解）
まず最初に、既存プロジェクトの全体像をAIに理解してもらう必要があります。
これがステアリング（舵取り）と呼ばれるフェーズです。
/kiro:steering
このコマンドを実行すると、Claude Codeが既存のプロジェクトファイルを分析します。
具体的には、README、package.json、tsconfig.json、ディレクトリ構造などを読み込みます。
その結果、プロジェクトの全体像を把握します。
分析が完了すると、以下の3つのドキュメントが自動生成されます。
- product.md：開発中のプロダクト情報（機能、ユーザー価値、ビジネスロジック）
- tech.md：技術スタック情報（フレームワーク、ライブラリ、アーキテクチャ）
- structure.md：ディレクトリ構造とファイル構成
これらのドキュメントは、今後の開発でAIが参照する「プロジェクトの記憶」となります。
生成されたproduct.md（一部）
実際に生成されたproduct.mdを見てみましょう。
既存のコードとREADMEから、プロダクトの本質を的確に理解してくれました。
# Product Overview - ADHD Body Check
## Product Overview
ADHD Body Check is a minimal health tracking app specifically designed for people with ADHD.
The core principle is **3-second mood recording with zero cognitive load**.
The app features a black background with neon colors for visual impact and sensory accommodation.
## Core Features
- **3-Second Mood Recording**: Simple emoji-based mood selection (😊😐😣) with immediate celebration effects
- **Today's Color Bar**: Dynamic width visualization showing mood patterns throughout the day
- **Weekly Pattern Grid**: Premium feature showing 7-day mood patterns
このドキュメントがあることで、新機能を追加する際も既存の設計思想を守った実装ができます。
「3秒で操作完了」「認知負荷ゼロ」という設計思想が明確になっています。
方向性を見失ったときに振り返る良いきっかけにもなりそうです。
プロジェクトが大きくなると、当初の理念を忘れがちです。
こうして文書化されていると原点に立ち返れます。
ステップ2：機能初期化
プロジェクトの理解ができたら、新機能の仕様作成を開始します。
/kiro:spec-init "次の体調を予報としてforecastタブに表示する機能（数時間分）"
このコマンドの特徴は、曖昧な要求でも受け付けることです。
上記の例では「数時間分」という曖昧な表現を使っていますが、これで問題ありません。
なぜなら、後のフェーズで詳細化されるからです。
最初から完璧な仕様を書く必要はありません。
AIと相談しながら最適な仕様を決められるイメージです。
実行すると、docs/specs/forecast-mood-prediction/というディレクトリが作成されます。
spec.jsonファイルが生成されます。
ステップ3：要件定義
機能の概要が決まったら、具体的な要件を定義します。
/kiro:spec-requirements forecast-mood-prediction
このコマンドで、Claude Codeが既存コードとステアリング文書を参照します。
その結果、詳細な要件定義書を生成します。
生成される要件定義書の特徴は、「受入基準」が明確に記載されることです。
これにより、開発完了の定義が曖昧になることを防げます。
生成されたrequirements.md（一部）
# 要件定義書
## 要件1: 体調予測画面の表示
**目的:** ユーザーとして、Forecastタブで数時間先の体調予測を視覚的に確認したい。
そうすることで、今後の活動計画を立てやすくなる。
#### 受入基準
1. WHEN ユーザーがForecastタブをタップした場合 THEN Forecastアプリは数時間先の体調予測画面を表示する
2. WHEN 予測画面が表示される場合 THEN Forecastアプリは現在時刻から活動時間終了まで（最大8時間）の時間別予測を表示する
3. IF ユーザーが活動時間を設定している場合 THEN Forecastアプリは設定された活動時間内のみの予測を表示する
どうなっていればクリアと言えるかが明確に定義されます。
これは開発者にとってもレビュアーにとっても、完成の判断基準として非常に重要です。
要件定義書には他にも、データ不足時の対応、パフォーマンス要件、エラーハンドリングなども記載されます。
ステップ4：設計
要件が固まったら、技術的な設計に入ります。
/kiro:spec-design forecast-mood-prediction
このフェーズの良い点は、既存コードのパターンを分析することです。
車輪の再発明を避ける設計を生成してくれます。
例えば、既存のリポジトリパターンがあれば、それに合わせた設計を提案してくれます。
命名規則やディレクトリ構造も、既存のものに合わせてくれます。
プロジェクト全体の一貫性が保たれます。
生成されたdesign.md（一部）
設計書には、システムアーキテクチャの図解も含まれます。
# 技術設計書: 予測機能
## 2. アーキテクチャ設計
### 2.1 システム全体図
┌─────────────────────────────────────────────────────────────┐
│ Forecastタブ画面 │
│ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐ │
│ │ 次の時間予測 │ │ 数時間先予測 │ │ 信頼度表示 │ │
│ │ NextSlotPred. │ │ HourlyForecast │ │ Confidence │ │
│ └─────────────────┘ └─────────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
↓ データ要求
┌─────────────────────────────────────────────────────────────┐
│ ForecastRepository │
│ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐ │
│ │ 予測アルゴリズム │ │ パターン解析 │ │ 信頼度計算 │ │
│ │ PredictionCore │ │ PatternAnalysis │ │ Confidence │ │
│ └─────────────────┘ └─────────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
アルゴリズム設計も含まれています。
重み付き平均を使った予測ロジックが、既存のyabaDetection機能を活用する形で設計されています。
## 予測アルゴリズム
// メイン予測関数
static async generatePrediction(targetHour: number): Promise<PredictedMood | null> {
// 重み付き予測計算
const weights = {
weekly: 0.4, // 週間パターン
hourly: 0.3, // 時間帯傾向
recent: 0.3 // 直近トレンド
};
この設計書があることで、実装者が迷うことなく開発を進められます。
ステップ5：タスク分解
設計が完了したら、実装可能な単位にタスクを分解します。
/kiro:spec-tasks forecast-mood-prediction
AWS Kiroと同様のタスク表を生成します。
これはチェックリスト形式になっており、進捗管理が容易です。
生成されたtasks.md（一部）
# 実装計画
- [ ] 1. データアクセス基盤と予測アルゴリズムの実装
- [x] 1.1 予測機能に必要な型定義の作成
- 予測結果、時間別予測、パターン分析結果の型を定義する
- 設定値と信頼度計算用のインターフェースを作成する
- _Requirements: 要件2, 要件3, 要件4_
- [x] 1.2 予測データアクセス層の構築
- MoodRecordRepositoryを活用した過去データ取得機能を実装する
- 時間帯別の履歴データ検索機能を構築する
- _Requirements: 要件2, 要件5_
各タスクには以下の情報が含まれます。
- チェックマーク付きのタスクリスト（完了状況の管理）
- 具体的な実装内容の説明
- 対応する要件番号（トレーサビリティの確保）
段階的な実装（動作確認しながら進める）ができるよう、依存関係を考慮した順序になっています。
最適化は後半にまとめるなど、実践的な構成になっています。
ステップ6：実装
いよいよ実装フェーズです。
/kiro:spec-impl forecast-mood-prediction 1
数字はタスク番号を指定します。
タスク1から順番に実装していくことも、複数タスクを同時に実装することも可能です。
このコマンドの特徴は、TDD（テスト駆動開発）形式で進めることです。
まずテストを書いて、そのテストを通すように実装するという流れです。
品質の高いコードが生成されます。
実装時は、設計書とタスクリストを参照しながら進めます。
仕様から外れることがありません。
ステップ7：進捗確認
開発中はいつでも進捗を確認できます。
/kiro:spec-status forecast-mood-prediction
このコマンドで、視覚的な進捗表示が行われます。
どのフェーズが完了していて、どのタスクが残っているのか、一目で把握できます。
フェーズ別の承認状況とタスクの完了状況が表示されます。
プロジェクトマネージャーやチームメンバーとの進捗共有も簡単です。
spec.jsonによる状態管理
cc-sddのかしこい点は、各フェーズの状態をspec.jsonファイルで管理していることです。
{
"feature_name": "forecast-mood-prediction",
"created_at": "2025-09-14T00:00:00Z",
"updated_at": "2025-09-15T00:00:00Z",
"language": "ja",
"phase": "tasks-generated",
"approvals": {
"requirements": {
"generated": true,
"approved": true
},
"design": {
"generated": true,
"approved": true
},
"tasks": {
"generated": true,
"approved": true
}
},
"ready_for_implementation": true
}
このファイルによる管理には、以下のメリットがあります。
- 状態の永続化：Claude Codeのセッションが切れても、どこまで進んだか分かる
- 承認管理：各フェーズの承認状況が記録される
- チーム共有：Gitで管理することで、チームメンバーと進捗を共有できる
requirements、design、tasksの状態をboolean値で記録します。
コンテキストリセット後も状態を維持します。
これにより、長期間のプロジェクトでも安心して使えます。
ベストプラクティス
推奨される使い方
cc-sddを効果的に使うために、以下のベストプラクティスを守ることをおすすめします。
- 常にステアリングでプロジェクト理解：既存プロジェクトでは最初に実行し、大きな変更があったら都度更新
- フェーズを飛ばさない：要件→設計→タスクの順序を守ることで、手戻りを防ぐ
-
定期的な進捗確認：
/kiro:spec-statusで状態を把握し、迷子にならない - 大きな変更後はステアリング更新：プロジェクト構造が変わったら再実行して、AIの理解を更新
次に実行するコマンドが毎回表示されます。
日本語で出てくるのが嬉しいですね。
初めて使う人でも、画面の指示に従うだけで仕様駆動開発ができます。
実務での活用イメージ
cc-sdd を使った仕様駆動開発は個人開発だけでなく、チーム開発でも威力を発揮しそうです。
- ビジネスサイドやデザイナーと要件承認：requirements.mdをレビューして、認識齟齬を防ぐ
- テックリードと技術設計レビュー：design.mdを一緒に確認し、アーキテクチャの妥当性を検証
- Git管理でチーム開発：仕様書をコミットして共有し、プルリクエストでレビュー
- デイリースクラムでの進捗共有：spec-statusの結果を共有し、ブロッカーを早期発見
仕様書があることで、エンジニア以外のメンバーも開発状況を理解しやすくなります。
初心者へのメッセージ
AWS Kiroで噂になった仕様駆動開発。
難しそうと思っているけれどもチャレンジしてみたい方は、まずはCC-SDDでチャレンジしてみてはいかがでしょうか。
以下の点で初心者にも優しい設計になっています。
- 日本語で全て完結：英語のドキュメントを読む必要なし
- 次のコマンドが表示される：何をすればいいか迷わない
- エラーメッセージも日本語：問題が起きても対処しやすい
- 既存プロジェクトでも簡単に始められる：ゼロから作り直す必要なし
最初は小さな機能から試してみてください。
慣れてきたら大きな機能に挑戦するのがおすすめです。
まとめ
cc-sddを使った仕様駆動開発で、スムーズな新機能の開発を試せました。
個人的にもいろんな形で応援をしていきたいと思うほど、便利なツールです。
AWS Kiroを待ちきれない方、仕様駆動開発に興味がある方は、ぜひcc-sddから始めてみてはいかがでしょうか？
小さな機能から試してみて、その効果を実感してもらえれば幸いです。
Claude Code の関連記事
他にも Claude Code や AI 駆動開発の記事を書いていますので、よかったらこちらもご覧ください。