はじめに

AIコーディングエージェントによる開発が当たり前になる中で、こんな悩みはないでしょうか。

✨ コード生成は速いが、仕様との整合性が怪しい
🌀 セッションが長くなると文脈が散らかる、実装が迷走する
🧩 機能ごとの責任範囲（境界）が曖昧で、リファクタの度にバグが出る
📜 人間レビューのタイミングが掴めず、気付いたらコードが独り歩きしている

こうした課題に真正面から向き合うのが、gotalab氏が公開しているOSSの cc-sdd です。2026年4月にリリースされた v3.0 では、仕様駆動開発（Spec-Driven Development、以下SDD）のワークフローが大きく刷新され、長時間の自律実装と境界中心の設計を軸に据えた強力なフレームワークへと進化しました。

本記事では、cc-sdd v3 の特徴と使い方を紹介したうえで、1,200行・約2万文字（約80ページ相当）の要求仕様書を1ファイル投入し、ある社内システムの1.0次開発をcc-sdd v3で「実人間作業約半日」で完走させた実体験を、正直な振り返りを交えて共有します。サンプルアプリではなく、現場で実際に受け取る規模の仕様書がエントリとなる点がポイントです。

💡 この記事で学べること

cc-sdd v3 が提供する Spec-Driven Development の全体像

/kiro-discovery から /kiro-impl までのコマンドパイプライン

複数スペックを分割・並列実装する際のコツ

実際のプロジェクトで直面した「良かったこと」「つまずいたこと」

cc-sdd v3 を使いこなすためのベストプラクティス

🧭 cc-sdd とは何か

cc-sdd は、AIコーディングエージェント向けの 仕様駆動開発（Spec-Driven Development）フレームワーク を、ワンコマンドで任意のリポジトリに導入できるCLIツールです。コンセプトは一言で次のとおりです。

🎯 「承認済みの仕様を、長時間でも壊れない自律実装ワークフローに変える」

公式READMEの表現を借りれば 「Kiro スタイルの SDD ワークフロー」 を各種AIエージェントのCLI上で扱えるように整備したツール、とイメージすると掴みやすいでしょう。TypeScript 99.6%で実装され、MITライセンスで公開されています（2026-04時点で⭐3.1k）。

SDDが解決しようとしている問題

従来のAI支援開発では、プロンプトに「要件→実装→テスト」をひとまとめに渡すアプローチが主流でした。これには次のような弱点があります。

🔎 要件・設計・実装が混ざり、どこに誤りがあるか追跡しにくい
🧨 一発で大量コードが生成され、レビューのコストが膨大になる
🔁 途中で方針が変わっても追従が難しい（AIは前の文脈に引きずられる）

SDDでは、要件 → 設計 → タスク → 実装という4段階を明示的に分離し、それぞれが承認可能な成果物を生成します。cc-sdd はこれを .kiro/ ディレクトリに集約し、Markdownファイル（requirements.md、design.md、tasks.md など）として残すため、AIエージェントのセッションが切れてもコンテキストが失われません。

従来型開発と SDD の違い

以下の図は、従来型AI支援開発とcc-sddによるSDDの流れを比較した図です。

この図のポイントは3つです。

従来型は人間の頭の中の要件をいきなりコードに落とすため、途中で軌道修正できない
cc-sdd v3 はフェーズごとに文書化された成果物が積み上がり、セッションをまたいで継続可能
最終的なコードはどの要件・どの設計に紐づくかが一意に追跡できる

✨ v3 で何が大きく変わったのか

cc-sdd v3.0.0 は2026年4月9日にリリースされたメジャーバージョンです。コンセプトレベルの進化が4つあります。

1. 新しいエントリポイント `/kiro-discovery`

/kiro-discovery は「何を作るか、どう分割するか」を最初に決める新しい入口コマンドです。ユーザーの依頼を自動分類し、次のいずれかを選択します。

判定結果	実施内容
🆕 新規スペック	空のスコープから `brief.md` を生成
➕ 既存スペック拡張	既存の `spec.json` を更新
🧩 大規模分解（Path D）	複数スペックへ分割し `roadmap.md` を生成

これにより、大きすぎる要件を単一スペックで飲み込み、20個以上のタスクで崩壊するという従来の問題が解消されました。

2. 長時間自律実装 `/kiro-impl`

v3の目玉は /kiro-impl による自律実装ループです。従来の /kiro-impl-task よりも大幅に強化され、タスクごとにコンテキストを分離して実装します。

この図のポイントは次のとおりです。

Fresh Implementer: 毎タスクごとに新しいコンテキストで実装者サブエージェントを起動。前のタスクの思い込みを持ち込まない
Independent Reviewer: コード品質ではなく**「境界違反」を機械的に検証**する別エージェント
Auto-debug Pass: 失敗時は自動で根本原因分析。盲目的リトライではないのが特徴
各タスクの知見は tasks.md の Implementation Notes に集約され、次のタスクへ引き継がれる

3. 境界中心の設計（Boundary-first Design）

v3では design.md に File Structure Plan を必ず含めるルールが導入されました。これにより、各タスクがどのファイルを作成・編集するのかが事前に決まり、タスク間のファイル衝突やコンポーネントの責任重複を防ぎます。

tasks.md の各タスクには次のようなアノテーションが付きます。

- [x] 3.2 (P) 同意サービスを実装する（ConsentService）
  - _Boundary: ConsentService_
  - _Depends: 3.1_
  - _Requirements: 3.1, 3.2_

アノテーション	役割
`(P)`	並列実行可能なタスク
`_Boundary:_`	このタスクが所有するコンポーネント
`_Depends:_`	先に完了すべきタスク
`_Requirements:_`	`requirements.md` への逆引きトレース

4. 複数スペックの並列生成 `/kiro-spec-batch`

大規模イニシアティブを複数スペックに分解したあと、/kiro-spec-batch でまとめて requirements → design → tasks を生成できます。生成後には cross-spec review が自動実行され、以下をチェックします。

❌ スペック間で責務が重複していないか
❌ 他スペックのインターフェースとのミスマッチがないか
❌ データモデルの矛盾がないか

🗺️ アーキテクチャと主要コマンド

cc-sdd v3 のワークフローを俯瞰すると、以下のような4層のパイプラインになっています。

この図のポイントは次の3つです。

Discovery層 が起点。新規・拡張・分解を自動判定する
Spec層 は要件→設計→タスクの3段階。どの段階でも人間が承認可能
Impl層 は自律的に動くが、Validate層で随時介入できる設計

主要コマンド早見表

コマンド	役割	成果物
`/kiro-steering`	プロジェクト共通のガイド	`.kiro/steering/product.md`, `tech.md`, `structure.md`
`/kiro-discovery`	スコープ判定・ロードマップ生成	`brief.md`, `roadmap.md`
`/kiro-spec-init`	個別スペックの骨組み	`spec.json`, `brief.md`
`/kiro-spec-requirements`	EARS形式で要件記述	`requirements.md`
`/kiro-spec-design`	Mermaid図付き設計 + 境界定義	`design.md`
`/kiro-spec-tasks`	タスク分解（並列性・依存アノテーション付）	`tasks.md`
`/kiro-spec-batch`	複数スペックの並列生成	複数 spec × 上記成果物
`/kiro-impl`	自律実装ループ	コード + テスト + 更新された `tasks.md`
`/kiro-validate-gap`	既存コードと要件のGAP検出	`research/gap-analysis.md`
`/kiro-validate-design`	設計レビュー	`research/design-review.md`
`/kiro-validate-impl`	実装の要件充足検証	`research/impl-validation.md`

Spec成果物の関係

各成果物のトレーサビリティを図にすると次のようになります。

この図のポイントは、tasks.md が design.md と requirements.md の両方に逆引き可能 になっていることです。実装後に「要件XはどのコードでカバーされているのかC」を問われたとき、grep _Requirements: X_ tasks.md で一発で特定できます。

🌐 8つのAIエージェントへの統一スキル配信

v3最大の特徴のひとつが、同一の17スキルセットを8つのエージェントに配信できる点です。

この図のポイントは、cc-sdd v3 を使うとツール選定に引っ張られないということです。チームでClaude Codeを使う人、Cursorを使う人、Codex CLIを使う人が混在していても、同じ .kiro/ 構造の成果物を共有できます。

スキルモード指定方法

エージェント	インストールコマンド	安定度
Claude Code	`npx cc-sdd@latest` （デフォルト）	⭐ Stable
Codex	`npx cc-sdd@latest --codex-skills`	⭐ Stable
Cursor	`npx cc-sdd@latest --cursor-skills`	🔬 Beta
GitHub Copilot	`npx cc-sdd@latest --copilot-skills`	🔬 Beta
Windsurf	`npx cc-sdd@latest --windsurf-skills`	🔬 Beta
OpenCode	`npx cc-sdd@latest --opencode-skills`	🔬 Beta
Gemini CLI	`npx cc-sdd@latest --gemini-skills`	🔬 Beta
Antigravity	`npx cc-sdd@latest --antigravity`	🧪 Beta実験版

多言語対応も充実しており、--lang ja（日本語）、--lang zh-TW（繁体字中国語）、--lang ko（韓国語）など13言語がサポートされています。

⚙️ インストールと初期セットアップ

基本インストール

Node.jsが入っていれば、ワンコマンドで導入できます。

# Claude Code + 日本語 でセットアップ
npx cc-sdd@latest --lang ja

これだけで、リポジトリ直下に次のディレクトリが追加されます。

.kiro/
├── steering/          # プロジェクト共通ガイド
├── specs/             # 機能スペック置き場
└── settings/
    └── templates/     # 共通テンプレート

.claude/
└── commands/          # Claude Code用のスラッシュコマンド

⚠️ 注意: 既存の .kiro/ や .claude/commands/ がある場合は上書きされる可能性があります。事前に git status で確認しておきましょう。

初手の鉄板フロー（推奨）

初めてのプロジェクトでは次の順に実行するのがおすすめです。

# 1. プロジェクト共通のステアリングを作る
/kiro-steering

# 2. 作業のスコープを決める
/kiro-discovery "〇〇機能を追加したい"

# 3. 単一spec なら
/kiro-spec-requirements <feature-name>
/kiro-spec-design <feature-name>
/kiro-spec-tasks <feature-name>

# 4. 実装
/kiro-impl <feature-name>

後述の体験記にも書きますが、/kiro-steering を最初にやるかやらないかで後工程の冗長さがまったく違います。ここはサボらないのが正解です。

🚀 実際に使ってみた〜社内システム 1.0次開発を半日で実装した記録〜

ここからが本題です。cc-sdd v3 を使い、ある社内業務システム（1.0次開発）の要件定義書 をゼロから実装しました。

⏱️ 作業時間の内訳（Claude Codeログから集計）

「1日で作れた！」の類のブログは世に多くありますが、今回は Claude Code のセッションログの実タイムスタンプから厳密に集計 しました。休憩・睡眠を除いた実人間作業時間は次の通りです。

区分	時間	備考
ウォールクロック（開始→最後の検証）	約18時間	2026-04-16 19:42 JST → 2026-04-17 13:48 JST
うち人間による作業（休憩・睡眠除外）	約6〜7時間	≒ 半日
うち AI サブエージェントが自律実行していた時間	約5時間	深夜帯（人間は睡眠中）

💡 ポイント: 「半日」は比喩ではなくログに基づく事実です。人間がPCの前にいた時間は約半日、その間に要件定義書1ファイルが動くシステムに変換されたと考えると、cc-sdd v3 のインパクトがイメージできるかと思います。深夜は人間が寝ている間もサブエージェントが自律的に実装を進めていました。

📥 インプット：1,200行／約2万文字の要求仕様書

今回 cc-sdd v3 に与えたインプットは、1,200行・約20,000文字の要求仕様書 1ファイルだけです。ページ数換算すると約80ページ相当のボリュームで、業務機能・データモデル・非機能要件・個人情報保護・外部システム連携ポリシーなどが一式盛り込まれた、いわゆる「普通の業務要件定義書」です。

区分	値
入力ファイル数	1ファイル（`system-requirements.md`）
行数	約1,200行
文字数	約20,000文字
ページ換算	約80ページ
機能カテゴリ数	6大カテゴリ・71要件項目

対象とする要件の抽象的な構成

要件定義書に含まれていた機能群を、業務固有の名称を取り除き一般化すると次のような構成です。

🔐 共通基盤機能: OIDC認証、個人情報取り扱い同意、トップページ、サービス提供時間管理、ロールベースアクセス制御（RBAC）
👤 ユーザー自身による情報登録: 階層マスタを用いた情報登録、登録内容の承認ワークフロー、履歴管理、論理削除
📝 実績・評価の記録: 外部連携データに対する手動補正、除外フラグ、上司による評価入力
🔎 複合条件検索機能: 複数条件のAND/OR検索、個人/組織軸の切替、CSV出力、ダウンロード履歴
📊 マスタ管理: 階層構造マスタ、論理削除/復元、Excelインポート/エクスポート
🔁 外部システム連携: 複数の日次バッチ、リトライ制御、スタブ/本番の切替、連携ログ管理
🛡️ 個人情報保護: 同意状態に応じたデータ可視性制御、組織境界によるアクセス制限

このすべてを、Spring Boot 3.3 / Java 21 / React 18 / MySQL で一気通貫で実装することになりました。

フェーズ0：Discoveryで「これは分割すべき」と即判断

まず最初にやったのは /kiro-discovery の起動でした。

/kiro-discovery "次の要求仕様書を実装 system-requirements.md"

すると cc-sdd は要求仕様書を読み込み、「単一スペックでは20タスク超で管理不能」と判定。自動的に Path D（多スコープ分解） を提案してきました。人間（私）はこれを承認するだけで、次のような依存構造が自動生成されました。

この図のポイントは次のとおりです。

6つのスペックに分割され、依存関係が明示的になっている
app-foundation が共通基盤となり、他スペックはここから派生する構造
app-search が最終的な集約点で、前段すべてに依存する

.kiro/steering/roadmap.md には、プロジェクト全体のゴール・スコープ・制約・分割方針が自動的に記述されていました。この時点で所要時間30分。人間の脳内の「どう分割すればいいか」を、AIが明示的な文書に落としてくれたのは大きい体験でした。

フェーズ1：6スペックの生成を淡々と

次に、各スペックについて requirements → design → tasks を生成していきました。

/kiro-spec-requirements app-foundation
/kiro-spec-design app-foundation -y
/kiro-spec-tasks app-foundation -y

これを6スペック分繰り返したところ、各スペック約20分 × 6 = 約2時間で全てのSpec成果物が完成しました。

📝 反省ポイント: /kiro-spec-batch を使えば並列生成で時間を短縮できたのですが、今回は順次実行してしまいました。次回からは /kiro-discovery の直後に /kiro-spec-batch でまとめて生成するのが正解です。

生成された各スペックの規模感は次の通りです。

スペック	`requirements.md`	`design.md`	`tasks.md`	サブタスク数
app-foundation	66行	605行	205行	24
app-master	〜50行	〜500行	〜150行	18
app-integration	〜60行	〜550行	〜180行	18
app-registry	〜55行	〜500行	〜160行	17
app-records	〜55行	〜480行	〜150行	16
app-search	〜60行	〜520行	〜170行	15
合計	-	-	-	108タスク

フェーズ2：`/kiro-impl` で自律実装を走らせる

いよいよ実装フェーズです。各スペックに対して次のコマンドを順次実行しました。

/kiro-impl app-foundation
/kiro-impl app-master
/kiro-impl app-integration
/kiro-impl app-registry
/kiro-impl app-records
/kiro-impl app-search

各spec内部でのTDDサイクルは次のように回っていました。

実際の体感としては、「テストがないのに動くコードがある」という状態が一切発生しないのが心地よいポイントでした。従来のAI実装では「とりあえず書いて後でテスト」になりがちですが、/kiro-impl はテスト先行を物理的に強制します。

実装フェーズのタイムライン（Claude Codeログ基準）

📝 補足: 以下のガントチャートは Claude Code のセッションログに含まれる実タイムスタンプ に基づいて作成しています。時刻はすべてJST。人間作業（青系）、AI自律実行（赤）、睡眠（グレー）を色で区別しています。

この図のポイントは次の3点です。

青バー（人間作業）は合計で約6〜7時間＝半日。4/16 夕方から真夜中までと、翌日昼前の検証フェーズが主。
赤バー（AI自律実行）は約5時間。人間が就寝している間もサブエージェントが淡々と実装を継続
グレー（睡眠） は意図的に表示している。「寝てる間にAIが進めてくれる」という体験価値を視覚化した

この図のポイントは次のとおりです。

Spec生成とImpl実装が交互に走る 構成（今回は下位スペックをSpec生成→実装→次のスペック、のように進行）
app-foundation だけは前日夜から走らせ、朝起きたら完成している状態にできた
すべてを合計して実人間作業約半日（6〜7時間）・単一セッションでカバー（AIサブエージェントが深夜帯も自律実行）

生成されたコードの規模

最終的に生成されたコードは次のとおりでした。

区分	ファイル数	総行数	実装行数
バックエンド（Java）	113	9,286	7,236
├ 本番コード	87	5,610	4,310
└ テストコード	26	3,676	2,926
フロントエンド（TS/TSX）	54	4,654	4,122
├ 本番コード	46	3,892	3,410
└ テストコード	8	762	712
合計	167	13,940	11,358

テスト結果は以下の通り、計約178テストが全PASSでした。

✅ バックエンド ユニットテスト: 15ファイル / 約95ケース / 全PASS
✅ バックエンド 統合テスト:     11ファイル / 約59ケース / 全PASS
✅ フロントエンド テスト:       8ファイル / 24ケース  / 全PASS
──────────────────────────────────────────
   合計                          約178ケース / 全PASS

要件充足率サマリー

要件定義書に対する最終的な充足状況は次のとおりです。

カテゴリ	要件数	✅完全	▲スタブ	❌未実装	充足率
共通（ログイン・トップ）	6	6	0	0	100%
ユーザー情報登録・実績記録	19	19	0	0	100%
検索機能	12	10	2	0	83%
マスタ管理	10	10	0	0	100%
システム連携	12	9	3	0	75%（スタブ含む）
個人情報保護	5	4	1	0	80%（スタブ含む）
非機能要件	7	4	2	1	57%
全体	71	62	8	1	87%完全／99%カバー

✨ 結論: 「実装しきれていないもの」は意図的にスタブ化された外部連携（日次バッチ3本）と、要件書で「1.5次」と明記されていた一部の検索機能のみ。**1.0次開発のアプリケーション機能は実質100%**という結果でした。

フェーズ3：`/kiro-validate-impl` で仕上げの検証

最後に /kiro-validate-impl を走らせ、既存E2Eテスト23件の通過を確認したうえで、カバー不足だった6カテゴリ38テストを追加しました。さらに手動のスクリーンショット確認で2件のUI系バグを発見・修正できました。

#	現象	根本原因	修正内容
1	トップページに「アクセスが拒否されました」が2件表示	`RoleGuard` で `fallback ?? <AccessDeniedPage />` と書いたため、`fallback={null}` でも `??` が null をすり抜け描画された	`fallback !== undefined ? fallback : <AccessDeniedPage />` に修正
2	個人メニューがリンクではなくプレーンテキスト	TopPageが `<li>テキスト</li>` のみで `<Link>` import が漏れていた	`<Link to="...">` に置換

⚠️ 学び: API層のテストでは拾えない「見た目のバグ」 は手動確認頼みになりがち。次回からは Playwright の UI 確認テストを tasks.md に明示的に組み込むのが良さそうです。

💎 良かったこと・つまずいたこと（リアルな振り返り）

✅ 良かったこと

1. 仕様の「なぜ」が常に残る

従来の実装では「なぜこの設計にしたか」がコメントや口伝頼りでした。cc-sdd では requirements.md（WHAT）→ design.md（HOW）→ tasks.md（WHEN）の3層が独立ファイルとして残るため、コードを読まなくても意図が追えるのが大きな価値です。

例えば、RoleGuard のバグを修正するときも、design.md の Boundary Commitments セクションを読むだけで「このGuardがアクセス制御の責任を持つ」と即座に確認できました。

2. Boundary Commitments が境界を守ってくれる

design.md にある Boundary Commitments（This Spec Owns / Out of Boundary） が明示されていたため、スペックをまたいだ責任の越境が発生しませんでした。

この図のポイントは、「どちらが責任を持つか曖昧になりそうな機能」が事前に明示されていることです。後から「あれ、これどっちがやるんだっけ？」という会話が一切発生しませんでした。

3. `(P)` マーカーで並列実装

tasks.md には並列実行可能なタスクに (P) が付与されます。この並列マーカーの存在自体が設計の疎結合性を担保してくれるのが嬉しいポイントでした。なお現時点（v3.0.x）では /kiro-impl の実行時に (P) で実際に並列サブエージェントを起動するかは Issue #112 で議論されている段階で、ランタイム挙動はシーケンシャル寄りです。それでも「並列可能な粒度」で分解されたタスクは独立性が高く、レビュー・差し替え・リトライがしやすくなります。

4. TDDサイクルがデフォルト

/kiro-impl はテストファーストを原則とするため、「テストは後で」にならないのが圧倒的に心地よかったポイントです。

5. トレーサビリティが最後まで途切れない

各タスクに _Requirements: 1.1, 3.2_ が付くため、実装後に「要件Xは本当に実装されているか？」を検証するときも、grep だけで対応コードが見つかりました。

6. スペック間の結合テストを cc-sdd が助けてくれる

/kiro-validate-impl の機械検証は、E2Eテストを38件自動追加してくれました。「テストが足りない領域を機械が指摘する」のは、人間レビューでは見逃しがちな部分なので助かりました。

⚠️ つまずいたこと・課題

1. `-y` フラグの乱用で人間レビューを省きすぎた

全フェーズで -y（自動承認）を使って requirements → design → tasks を連続生成したところ、設計の前提が誤っていても検知タイミングがなく、実装完了後に初めて「設計と実コードが微妙にズレている」ことに気づくケースがありました。

💡 教訓: requirements.md だけは必ず人間が読んで承認する。design.md 以降は -y でも可。

2. E2Eテストの仕様仮定ミス

Consent APIのリクエスト形式や日付フォーマット、HTTPステータスコードなどで、AIが誤った仮定でE2Eテストを書いていたケースがありました。

項目	AIの仮定	正解
Consent API	`{ consentType: "AGREED" }`	`{ agreed: true, version: "1.0" }`
日付フォーマット	`"2026-04-17 10:00:00"`	`"2026-04-17T10:00:00"`
POST /announcements	201 Created	200 OK

💡 教訓: design.md の API 仕様セクションに リクエスト/レスポンスのサンプル JSON を必ず記載する。

3. スペック間のコードレベル依存が実行時に判明

roadmap.md には依存関係が書かれていても、「app-records が app-integration の外部連携エンティティを参照する」といったクラス名レベルの依存は実装時まで不明でした。結果、先行スペックが完成していない状態で次のスペックを始めるとインポートエラーが出ます。

💡 教訓: design.md の File Structure Plan に 依存する他スペックのクラスパス を明示する。tasks.md の _Depends:_ も具体的なクラス名まで書く。

4. Steering ファイルを生成し忘れた

今回、最初に /kiro-steering を実行しなかったため、.kiro/steering/ には roadmap.md しか存在しない状態でした。結果、各specの design.md で技術スタック（Spring Boot 3.3 / React 18 / Aurora MySQL）を毎回書き直す冗長作業が発生しました。

💡 教訓: プロジェクトの最初に /kiro-steering を走らせて product.md / tech.md / structure.md を先に作る。

5. UIレベルのバグは手動確認頼み

前述のRoleGuard null処理バグとメニューのLink漏れは、API層テストでは検出できない見た目の問題でした。

💡 教訓: Playwright の UI 動作確認テスト（ui-verify.spec.ts）を tasks.md に明示的に含める。

6. Spec生成そのものに時間がかかる

6スペックのSpec生成で合計約2〜3時間かかりました。コード生成量に対してオーバーヘッドが大きめです。

💡 教訓: /kiro-spec-batch で並列生成に切り替えれば時間短縮可能。

🏆 総合評価

振り返ってスコアカードにすると次のようになります。

観点	評価	コメント
仕様と実装の一致性	⭐⭐⭐⭐⭐	requirements→design→tasks→code の全トレース
実装速度	⭐⭐⭐⭐☆	実人間作業約半日で約13,940行・要件99%カバー（完全実装87%）
コード品質	⭐⭐⭐⭐☆	TDD強制・境界明示により疎結合
バグ検出力	⭐⭐⭐☆☆	APIは強力、UIは手動確認が必要
設計の透明性	⭐⭐⭐⭐⭐	Boundary Commitmentsで責任範囲が常に明確
学習コスト	⭐⭐⭐☆☆	オプション（-y, (P), Boundary:）の理解に時間が必要

💡 一番の価値

仕様書から動くシステムまでの距離をAIが埋め、人間は「何を作るか」と「承認」に専念できる

従来は数週間かけて行う工程を、実人間作業約半日（6〜7時間）・単一セッションで完走できたのは衝撃的でした（生成規模: 167ファイル／約13,940行／テスト約178件全PASS／要件充足率99%カバー）。

🎓 cc-sdd v3を使いこなすベストプラクティス

今回の実体験から抽出した、次回以降絶対に守りたいプラクティスを5つにまとめます。

✅ 1. Steeringは必ず最初に作る

# プロジェクトの最初に必ず実行
/kiro-steering

product.md（何を作るか）／tech.md（技術スタック）／structure.md（ディレクトリ方針）を先に固めておくと、各 spec.json の constraints に同じことを書く冗長作業が消えます。

✅ 2. Requirementsだけは人間が承認する

# NG: すべて -y
/kiro-spec-requirements feature -y
/kiro-spec-design feature -y
/kiro-spec-tasks feature -y

# OK: requirements だけ人間承認
/kiro-spec-requirements feature
/kiro-spec-design feature -y
/kiro-spec-tasks feature -y

要件の時点で誤りがあると、以降すべてが連鎖的にズレます。ここだけはサボらないのが正解です。

✅ 3. `design.md` に API サンプル JSON を含める

design.md の API 仕様セクションに、リクエスト/レスポンスのサンプルJSONを記載しておくと、E2Eテストの仮定ズレが激減します。/kiro-spec-design のプロンプトで明示的に指示するのが良いです。

✅ 4. `/kiro-spec-batch` で並列生成

Discovery で複数スペックに分解された場合、個別に spec-requirements → spec-design → spec-tasks を実行せず、/kiro-spec-batch でまとめて並列生成するのが時短になります。

✅ 5. UIコンポーネントテストを tasks に明示

tasks.md 生成時に、単なるAPI E2Eだけでなく、Playwrightによる見た目のテスト もタスクとして含めるように要件で指示します。

- [ ] 8.3 (P) TopPage UI動作確認テスト
  - _Boundary: ui-verify.spec.ts_
  - _Requirements: 4.1, 4.2_

🌟 まとめと次のステップ

cc-sdd v3 は、AIコーディングエージェントによる開発を「その場しのぎ」から「工学的なプロセス」へ引き上げるツールでした。

この記事のポイントをおさらいします。

🎯 cc-sdd v3 は Kiro スタイル SDD を 8つのAIエージェント に統一配信する OSS（gotalab/cc-sdd）
✨ v3 の目玉は /kiro-discovery（スコープ判定）、/kiro-impl（自律実装ループ）、境界中心設計、/kiro-spec-batch（並列spec生成）
🚀 実プロジェクト（ある社内システムの1.0次開発）では 実人間作業約半日で167ファイル・13,940行・テスト約178件全PASS、要件充足率99%カバーを達成
📌 実体験からのベストプラクティスは 「Steeringを先に作る」「Requirementsは人間承認」「design.md に API サンプルJSONを入れる」

次のステップ

まだ cc-sdd に触れたことがない方は、まずは小さな機能で試してみるのがおすすめです。

mkdir my-first-sdd-project && cd my-first-sdd-project
git init
npx cc-sdd@latest --lang ja
# その後 Claude Code を開いて /kiro-steering から開始

📚 参考

gotalab/cc-sdd — GitHubリポジトリ
cc-sdd 日本語README
cc-sdd Releases（v3.0.0 / v3.0.1 / v3.0.2）
Kiro（AWS） — cc-sdd が参照する「Kiro スタイル SDD」の元となった IDE