cc-sdd v3は何が変わったのか｜「仕様書テンプレート」から「自律実装ハーネス」への転換

仕様駆動開発（SDD）をAIコーディングに持ち込むツールとして知られる cc-sdd が、v3で大きく設計思想を変えました。現在の安定版はv3.0.2で、v3.0.0は2026年4月9日にリリースされています。

一見すると「コマンドが増えただけ」に見えますが、実際に中身を追うと、担当範囲そのものが変わっています。

従来は、

要件 → 設計 → タスク → AIに実装させるためのプロンプト集

という位置づけでした。v3はここから踏み出して、

作業の振り分け → 複数仕様への分解 → 境界定義 → タスク単位の自律実装 → 独立レビュー → 自動デバッグ

までを担います。「AIに渡す仕様書のテンプレート」から、「AIエージェントを回すための実行ハーネス」へ、と言い換えてもいいでしょう。

この記事では、v2からの変更点を「導入方式」「入口」「実装ループ」「Specの位置づけ」「移行」の順に整理し、最後に事業者・開発チームとしてどう受け止めるべきかを検討します。

変更点1：コマンド方式からAgent Skills方式へ

v2までは、Claude CodeやCodexといった各環境に、個別のコマンド・プロンプトをインストールする方式が中心でした。v3では、Agent Skillsが標準の導入方式になっています。

# Claude Code
npx cc-sdd@latest --claude-skills --lang ja

# Codex
npx cc-sdd@latest --codex-skills --lang ja

Claude CodeとCodexはstable扱い、Cursor・GitHub Copilot・Windsurf・OpenCode・Gemini CLI・Antigravityはbeta扱いです。各環境に同じ17個のSkillがインストールされ、必要なSkillだけをオンデマンドで読み込む構成になりました。

一方、旧来のインストール方式は非推奨になっています。

npx cc-sdd --claude-code
npx cc-sdd --cursor
npx cc-sdd --copilot

特に旧 --codex のプロンプト方式はv3でブロックされており、--codex-skills への移行が必要です。他のコマンド方式も将来削除予定とされています。

地味な変更に見えますが、意味は小さくありません。常時読み込まれる巨大なプロンプト群ではなく、必要な局面で必要な手順だけを引き込む構成に変わったということです。長時間動かすエージェントにとって、コンテキストの節約はそのまま安定性に効きます。

変更点2：新しい入口は /kiro-discovery

以前は、開発者が最初から機能名を決めて開始する形でした。

/kiro:spec-init user-notification

v3では、原則として最初にこれを実行します。

/kiro-discovery

/kiro-discovery は依頼内容を分析し、作業を次のいずれかに振り分けます。

• 既存Specの拡張
• Spec不要の直接実装
• 新しい単一Specの作成
• 複数Specへの分解
• Spec作成と直接実装を組み合わせた mixed decomposition

その結果を brief.md に保存し、複数Specが必要な場合は roadmap.md も作成します。これにより、セッションをまたいでもスコープを説明し直す必要がなくなります。

ここは重要な変更です。従来は「これはSpecを作る規模か」「Specをいくつに分けるか」を人間が判断していました。v3では、その前段にある作業分類とスコープ設計もエージェントに委ねる方向へ動いています。

なお、すべての修正にSpecを要求するわけではありません。小さな変更については /kiro-discovery が「Spec不要で直接実装」と判断することも、正式なルートとして用意されています。「何でもかんでも仕様書を書かせる」運用にならないよう配慮された設計です。

変更点3：/kiro-impl が自律実装ループになった

v3の中心は、新しい /kiro-impl です。

v2の kiro-spec-impl は、基本的に一度のコンテキストで実装を進める方式でした。v3の /kiro-impl は、タスクごとに複数のサブエージェントを動的に起動します。

/kiro-impl feature-name

内部では、最大で3つの役割が使われます。

Implementer（実装役）

タスクごとに新しいコンテキストで起動します。承認済みのSpecとTask Briefを読み、TDDのRED→GREENで実装します。前のタスクの会話コンテキストを引きずらないため、長時間の実装でコンテキストが汚染されるのを抑える設計です。

Reviewer（検証役）

Implementerとは別コンテキストで起動し、次のような機械的な確認を行います。

• git diff の確認
• テスト実行
• TODOなどの残存確認
• タスクの境界違反
• 承認済みSpecとの不整合

実装者自身にレビューさせるのではなく、独立したReviewerを立てる点がポイントです。自分の書いたコードを自分で採点させると甘くなるのは、人間もAIも変わりません。

Debugger（原因究明役）

Implementerが BLOCKED になった場合、またはReviewerによる再修正が2回失敗した場合に起動します。新しいコンテキストで根本原因を調べ、必要に応じてWeb検索を行い、修正計画を別のImplementerに引き渡します。Debuggerは1タスクあたり最大2回までです。

構造としてはこうなります。

Task 1
 ├─ Implementer
 ├─ Reviewer
 ├─ 必要なら再修正
 └─ 必要ならDebugger

Task 2
 ├─ 新しいImplementer
 ├─ 新しいReviewer
 └─ ...

1回のイテレーションで処理するのは1タスクだけです。そのため、中断後に /kiro-impl を再実行しても、続きから安全に再開できます。

「作る役」と「検証する役」を別コンテキストに分け、行き詰まりを検知したら別の役に上げ、1タスク単位で区切って再開可能にする——この骨格は、当ブログで以前に整理したループエンジニアリングの原則（評価者と作業者の分離、独立した検証、状態の永続化）とほぼ一致します。概念として語られていたものが、標準ツールの内部実装として降りてきた、という受け止め方ができます。

変更点4：Ralph Loopへの外部依存がなくなった

以前のcc-sddには、長時間の実装のためにRalph Loopのような外部ループ機構を組み合わせる考え方がありました。

v3では、各プラットフォームがネイティブに持つサブエージェント機構を使います。Claude CodeではTask tool、CodexではCodex側のサブエージェント機能、といった具合です。固定の .claude/agents/kiro/*.md を用意する方式ではなく、Skillが実行時にImplementer・Reviewer・Debuggerのプロンプトを動的に組み立てて起動します。

つまり、外部の仕組みを足さなくても、v3単体で本格的な自律実装ループが回るようになりました。

変更点5：Specが「詳細な命令書」から「境界契約」になった

v3の設計思想として、おそらく最も重要なのがここです。cc-sdd v3は次の立場を明確にしています。

• コードがSource of Truth
• Specはシステム各部の間の契約
• 人間は境界と責務を承認する
• 境界の内側の実装判断はエージェントに任せる

従来のSDDは、詳細な設計書をAIへの命令書として渡す色が濃いものでした。v3では、実装方法をすべてSpecに書き込むのではなく、

• どの責務を担当するか
• どのファイル・モジュールを変更してよいか
• 依存関係は何か
• 外部に対する契約は何か

を明確にする方向へ寄せています。

そのため design.md に File Structure Plan が追加され、各タスクには次のアノテーションが付きます。

_Boundary:_
_Depends:_

Reviewerも、コードスタイルだけでなく「担当外のファイルや責務に変更が及んでいないか」を検査します。AIに広い裁量を渡す代わりに、触ってよい範囲を機械可読な形で固定するという発想です。裁量と統制のバランスの取り方として、筋が通っています。

変更点6：大きな案件を複数Specに分解できる

v3では /kiro-spec-batch が追加されました。

/kiro-discovery
 ↓
brief.md
 ↓
roadmap.md
 ↓
/kiro-spec-batch

roadmap.md に複数の作業単位が定義されている場合、それぞれを独立したSpecとして並列生成します。さらに Cross-Spec Review を行い、次の問題を確認します。

• Spec間の矛盾
• 責務の重複
• 同一ファイルの競合
• API・インターフェースの不一致
• 依存関係の欠落

Codex向けには、Cross-Spec Reviewを担当する spec-reviewer のカスタムロールも導入されています。

これは「1機能＝1つの大きなSpec」から脱却するための変更と考えられます。公式の思想では、1つのSpecは数時間から数日でリリースできる単位が推奨され、大きすぎる作業は複数Specへ分解します。

変更点7：タスク間で学習内容を引き継ぐ

タスク単位でコンテキストを分離すると、前のタスクで判明した注意事項が失われるという問題が起きます。

v3では、実装中に見つかった横断的な知見を tasks.md の次のセクションに保存します。

## Implementation Notes

後続のImplementerには、このImplementation Notesが自動的に注入されます。たとえば次のような内容です。

## Implementation Notes

- better-sqlite3はElectron向けABI rebuildが必要
- このAPIはテスト環境ではモックサーバーを利用する
- UserRepositoryは直接生成せずDIコンテナから取得する

会話履歴ではなく、リポジトリ内の永続的な状態として知見を受け渡すわけです。エージェントは忘れてもファイルは忘れない——長時間稼働を前提にするなら、合理的な設計です。

変更点8：Feature Flag前提のTDD

v3では、単に「テストを書いてから実装する」TDDから、Feature Flag Protocol付きのTDDへ強化されています。

各タスクを既存機能に影響させず段階的に実装することを想定し、次の流れを採ります。

RED
 ↓
GREEN
 ↓
Feature Flag越しに新機能を追加
 ↓
Reviewerによる検証

移行ガイドでも、v2のBasic TDDからv3のFeature Flag TDDへ変わったと整理されています。

ただし、ここは注意が必要です。すべてのプロジェクトでFeature Flagを導入すべき、という意味ではありません。 小規模な変更まで機械的にFlag化すると、今度はFlag管理そのものが負債になります。テンプレートやSteeringで、自社のFeature Flag方針（どの規模から適用するか、いつ削除するか）を明示しておいたほうが安全です。

従来のSpec資産は基本的に引き継げる

移行にあたって、既存のSpecをすべて作り直す必要はありません。次は互換性が維持されています。

• .kiro/specs/<feature>/ のディレクトリ構造
• steering文書
• templates
• rules
• requirements / design / tasks の基本フェーズ
• /kiro-validate-impl

Kiro形式の既存Specも、そのまま互換性を維持すると説明されています。主に変える必要があるのは、実行方式と入口です。

旧
/kiro:spec-init
 → /kiro:spec-requirements
 → /kiro:spec-design
 → /kiro:spec-tasks
 → /kiro:spec-impl

新
/kiro-discovery
 → 必要に応じて /kiro-spec-batch
 → requirements / design / tasks
 → /kiro-impl

旧コマンド群も当面は残っていますが、公式にはSkillモードを先に参照するよう案内されており、レガシー扱いです。

v2とv3の差分まとめ

評価：手元のコーディングエージェントが「自律開発の基盤」になる

v2までのcc-sddは、位置づけとしてはSDDのテンプレート集でした。長時間の自律開発まで踏み込むなら、外部のループ機構や専用の自律エージェント基盤を別途組み合わせる必要がありました。

v3では、cc-sdd自身が次を持つようになりました。

• 作業分類
• Spec分割
• 長時間実装
• サブエージェント起動
• 独立レビュー
• 自動デバッグ
• 中断・再開
• タスク間の知識伝播

そのため、Claude CodeやCodexをローカルまたはCI上で動かせる体制さえあれば、専用の基盤を追加しなくても自律開発ループを組めるようになりました。すでに手元にあるコーディングエージェントの上にハーネスを載せるだけで、そこまで到達できるという点が、v3の実務的なインパクトです。

それでも残る懸念：自律化した分、前提の質に依存する

一方で、v3には懸念もあります。自律性が上がった分、成果が次の品質に強く依存するようになりました。

• File Structure Planの妥当性
• タスク境界の正しさ
• テストスイートの信頼性
• Feature Flagの運用ルール
• Reviewerが実行する検証コマンド
• SteeringとRulesの品質

とくに危ないのは、最初のDiscoveryやSpec分割を誤ったケースです。境界が間違っていても、その後のImplementerとReviewerは「承認された境界」として一貫してそれを守り続けます。間違った設計が、高い再現性で実装されてしまう。自律ループの怖さはここにあります。

したがってv3では、人間の仕事の重心が移ります。設計書を細かく書くことではなく、Discovery結果・Spec分割・境界・依存関係・検証条件を承認することが中心になります。ここを流し読みして完全自律に任せるのは、率直に言って危険です。

まとめ

• cc-sdd v3は「SDDテンプレート」から「AIエージェント向けの実行ハーネス」へ性格を変えた（安定版v3.0.2、v3.0.0は2026年4月9日リリース）
• 導入方式はコマンドからAgent Skills中心へ。17個のSkillをオンデマンドで読み込む
• 入口は /kiro-discovery。Specを作るか・分割するか・不要かをエージェントが振り分ける
• /kiro-impl はImplementer／Reviewer／Debuggerをタスクごとに起動する自律ループ。中断・再開が可能
• Specの役割は「詳細な命令書」から「モジュール境界の契約」へ
• 既存の .kiro/specs/ 資産・steering・templatesは基本的にそのまま使える
• 自律化した分、境界設計と検証条件の承認が人間の主業務になる

導入を検討するなら、いきなり大きな機能を丸ごと任せるより、境界が明確で検証しやすい一機能からv3のループを一周させ、Discovery結果とSpec分割の精度を自社の目で確かめるのが現実的です。ハーネスの性能より、渡す境界の質が結果を決めるためです。

本記事はcc-sdd v3の公開情報（リリース内容・移行ガイド・公式ドキュメント）をもとに、2026年7月時点の内容を整理したものです。バージョン番号・コマンド名・対応環境は更新される可能性があるため、導入時は最新の公式情報をご確認ください。