AI に仕様を書かせ、人がレビューしてから実装に進む。前回の記事「仕様から書くAI駆動開発へ ― cc-sdd 入門」では、この流れを cc-sdd のコマンド方式（v2）で紹介しました。
それから cc-sdd は v3 系に進み、2026年9月には v3.1.0 がリリースされています。v3 での一番大きな変化は、承認済みの spec から、実装・レビュー・コミットまでを AI が自律的に回せるようになったことです。
「仕様は書けた。でも結局、実装は AI に張り付いて見守っている」。そう感じていた方も多いのではないでしょうか。
この記事では、v2 から何が変わったのかを整理します。そのうえで、小さな CLI ツールを題材に、v3.1.0 で discovery から自律実装までを一通り回した結果を紹介します。読み終えるころには、v3 をどこまで AI に任せてよいか、どこに人の目を残すべきかの判断材料がそろっているはずです。
💡本記事は cc-sdd v3.1.0 と Claude Code を前提にしています。仕様駆動開発そのものの考え方や、requirements / design / tasks の役割は前回の記事で解説しているため、ここでは省略します。
1. v3 の全体像：コマンドから Agent Skills へ
v3 では、cc-sdd の提供形態がスラッシュコマンドから Agent Skills に変わりました。17個のスキルとして導入され、/kiro-* で呼び出します。
| 項目 | v2（前回記事） | v3.1.0 |
|---|---|---|
| 提供形態 | コマンド（/kiro:spec-init など） | Agent Skills（/kiro-spec-init など、17スキル） |
| 対応エージェント | コマンド方式で複数エージェントに対応 | 8種。Claude Code / Codex が Stable、Cursor / GitHub Copilot / Devin / OpenCode / Gemini CLI / Antigravity が Beta |
| 依頼の入口 | いきなり spec-init | /kiro-discovery が依頼を振り分ける |
| 実装 | /kiro:spec-impl（1回の実行で実装する） | /kiro-impl（タスクごとに「実装 → 独立レビュー → コミット」を繰り返す自律ループ） |
| 失敗したとき | 人が対処する | デバッグ役が新しいコンテキストで原因を調べる（最大2ラウンド） |
| 最終確認 | /kiro:validate-impl を任意で実行 | 自律ループの最後に /kiro-validate-impl が GO / NO-GO を判定する |
名前の変化は「: が - になった」程度です。ただし中身は、「仕様を作るツール」から「仕様を起点に実装まで回すツール」へと広がっています。
spec は「命令書」ではなく「契約」
v3 の公式ドキュメント（philosophy note）では、spec を「エージェントへの命令書ではなく、システムの各部分の間の契約」と位置づけています。
人は各フェーズの承認ゲートで、境界・責務・依存関係といった契約をレビューします。エージェントは、その契約の内側で自由に実装します。この役割分担が、後述する自律実装の土台になっています。
2. セットアップ
インストールは v2 と同じく1コマンドです。
cd your-project
npx cc-sdd@latest --claude-skills --lang ja
| オプション | 説明 |
|---|---|
--claude-skills | Claude Code 向けのスキルを導入する（既定値） |
--lang ja | 生成ドキュメントを日本語にする。省略すると英語になる |
--dry-run | 実際には書き込まず、追加されるファイルだけを確認する |
v2 で使っていた --claude などのコマンド方式のフラグは非推奨になりました。v2 から移行する場合は、--claude-skills で入れ直してください。既存の .kiro/specs/ と .kiro/steering/ はそのまま使えます。移行の詳細は公式のマイグレーションガイドにまとまっています。
インストールにかかる時間は1秒未満です。.claude/skills/ に17スキル、.kiro/settings/ にテンプレートとルールが配置されます。
3. 実際に動かしてみた
ここからは、v3.1.0 で一連の流れを実際に回した記録です。
- 題材:
mdtodo。ディレクトリ配下の Markdown を再帰的に走査し、チェックボックス形式の TODO（- [ ]/- [x]）を集計する CLI です。 - 初期状態: TypeScript と Vitest の雛形だけを用意しました。
- 進め方: 各フェーズの成果物を読んでレビューし、問題がなければ次のフェーズに進めました。
所要時間とコスト
| ステップ | 所要時間 | コスト |
|---|---|---|
/kiro-steering | 43秒 | $0.25 |
/kiro-discovery | 47秒 | $0.30 |
/kiro-spec-init | 19秒 | $0.19 |
/kiro-spec-requirements（修正の1往復を含む） | 約2分 | $0.80 |
/kiro-spec-design | 約5分 | $1.47 |
/kiro-spec-tasks | 約3分 | $1.44 |
/kiro-impl（自律モード） | 約40分 | $15.62 |
| 合計 | 約52分 | 約$20 |
💡 全工程を上位モデル（Claude Opus）で実行した場合の参考値です。公式は「計画・レビューは上位モデル、実装は標準モデル」を推奨しており、実装を標準モデルに切り替えればコストは下げられます。
discovery：「何を作るか」の前に「spec にすべきか」を判断する
最初に、やりたいことを /kiro-discovery に渡しました。
/kiro-discovery "指定ディレクトリ配下の Markdown ファイルを再帰的に走査し、チェックボックス形式の TODO をファイルごと・全体で集計して表示する CLI を作りたい。未完了タスクの一覧表示と、JSON 出力オプションもほしい"
判定は「新しい単一の spec」でした。brief.md には次の3つが残ります。
- 採用したアプローチ：依存ライブラリを使わず、1行ずつ判定する
- 採用しなかった案とその理由：Markdown パーサを使う案は、依存が増えるため見送り
- 確認せずに決めた前提：対象は
.mdのみ、node_modulesは除外する、など
あとから「なぜこの作りにしたのか」を追えるのは、v2 にはなかった良さです。
試しに「README の文言を1か所直したい」という小さな依頼も渡してみました。こちらは16秒で「spec 不要」と判定され、修正の diff だけが提示されました。すべての変更を spec にするのではなく、契約を明文化する価値がある仕事だけを spec にする、という v3 の考え方がよく表れています。
v2 のころは、依頼のたびに「spec を新しく作るか」「既存の spec を更新するか」「そもそも spec を作らず、kiro コマンドを使わずに実装するか」を自分で判断する必要がありました。v3 では /kiro-discovery が既存の spec とプロジェクトの構成を見たうえで、この振り分けを AI が自動で判断してくれます。何を作るかの本題に入る前のこうした判断に、余計な時間を割かずに済むようになったのは大きな変化だと感じています。
仕様策定：AI が「自分で決めたこと」を申告してくる
requirements・design・tasks の各フェーズで印象に残ったのは、AI が根拠なく決めた点を、自分から「確認してほしい判断」として挙げてくることです。
requirements では、「TODO が0件のファイルは表示しない」「--help は要件に含めていない」など4点の確認を求められました。
--help のない CLI は不自然なので、会話の中でそのまま次のように返しました。
確認事項1〜3はその判断で OK です。--help（使い方を標準出力に表示して終了コード0）は要件に追加してください。--version は不要です。
すると要件全体を作り直すのではなく、requirements.md の差分だけが修正されました（+12行 / -4行）。
design では、AI が実際に Node.js でコードを動かして検証していました。そのうえで、readdir の recursive オプションは「読めないディレクトリが1つあると全体が失敗する」と突き止め、ディレクトリを自前で再帰する設計に切り替えています。
設計書（design.md）には「この spec が何を持ち、何を持たないか」を固定する Boundary Commitments が含まれます。レビューで見るべきなのは細かな記述ではなく、この契約が妥当かどうかです。
| 項目 | 今回の内容（抜粋） |
|---|---|
| This Spec Owns | 引数の仕様、走査のルール、TODO の判定ルール、JSON のスキーマ、終了コード |
| Out of Boundary | 対象ファイルへの書き込み、将来の拡張（ウォッチモードなど）、npm への公開 |
| Allowed Dependencies | Node.js の標準ライブラリのみ。ランタイム依存の追加は禁止 |
| Revalidation Triggers | JSON スキーマや TODO の判定ルールを変えたら再検証する |
一方で、小さな CLI に対して設計書が578行というのは、正直に言って重いと感じました。全文を精読するのではなく、Boundary Commitments と要件との対応表に絞って読むのが現実的です。
tasks では、16個のサブタスクが生成されました。各タスクには、対応する要件（_Requirements:_）、担当範囲（_Boundary:_）、依存するタスク（_Depends:_）が付きます。
/kiro-impl：40分、16コミット、差し戻し2回
feature ブランチを切ってから、/kiro-impl を自律モード（タスク番号を指定しない形）で実行しました。
/kiro-impl todo-aggregation-cli
内部では、タスクごとに次の流れを繰り返します。
- 実装役のサブエージェントが、テストを先に書く TDD で実装する
- 独立したレビュー役のサブエージェントが、
git diffとテスト結果を spec と照らし合わせて検証する - 承認されたらコミットし、
tasks.mdを読み直して次のタスクへ進む
結果は次のとおりです。
| 項目 | 結果 |
|---|---|
| 完了タスク | 16 / 16（_Blocked:_ は0件） |
| コミット | 16件（feat(todo-aggregation-cli): <タスク名> 形式、1タスクあたり平均約2分） |
| レビューでの差し戻し | 1タスクで2回 |
| デバッグ役の起動 | 0回 |
最終検証（/kiro-validate-impl） | GO（テスト190件がすべて成功、要件42項目すべてに実装とテストあり） |
一番面白かったのは差し戻しの中身です。
- 1回目：レビュー役が、本文に特殊な改行文字を含む TODO 行を検出できていないことを指摘しました。
- 実装役はこれを直す際に、チェックボックス直後の空白の扱いを、設計書の定義より広げてしまいました。
- 2回目：レビュー役は「設計に反している」として、再び差し戻しました。
レビュー役が自分の好みではなく、合意した契約（設計書）を根拠に差し戻している点が、v3 の自律ループの肝だと感じました。
最終報告には「仕様違反ではないが気になる点」も挙がっていました。たとえば mdtodo --pending | head -1 のようにパイプを途中で閉じると、エラーのスタックトレースが出ます。要件にも設計にも書いていない挙動なので、どのレビューも止めてくれません。spec に書いたことは守られる。書いていないことは誰も守ってくれない。自律実装を任せるほど、仕様策定フェーズで人が考えるべきことの比重は増すと実感しました。
✅ AI が報告するタスク数には揺れがありました。生成時には「17個」、実装後の報告では「15個」と言っていましたが、実際は16個です。数字は tasks.md と git log で確認するのが確実です。
4. 安全に使うための設定
実際に回してみた経験から、本番のコードに使う場合の設定を整理します。
| 場面 | 推奨 |
|---|---|
承認のスキップ（-y、/kiro-spec-quick --auto） | どちらも「人のレビューを飛ばすスイッチ」です。試作では使ってよいですが、本番に入る spec では各フェーズを人がレビューします |
/kiro-impl のレビュー方式（v3.1.0 で追加） | `–review required |
| ブランチ | 自律モードはタスクごとに自動でコミットするため、必ず feature ブランチで実行します |
| PR の粒度 | 1 spec = 1 PR を基本にします。自動コミットは、必要に応じて squash します |
.kiro/ の扱い | specs/ と steering/ はコミットして共有します。PR の説明には spec へのリンクを書きます |
| モデル | 計画・レビューには上位モデル、実装には標準モデルを使います（公式推奨） |
もう1つ、design フェーズは検証用のスクリプトをリポジトリ外の /tmp/ に作成し、そのまま残していました。AI に検証を任せる場合は、どこに何を書き込んだかを最後に確認する習慣をつけておくと安心です。
5. 向いているケース・向かないケース
迷ったら /kiro-discovery に依頼を渡し、その判定に従うのが基本です。目安は次のとおりです。
| 判断 | 対象 |
|---|---|
| cc-sdd を使う | 数時間〜数日・1 PR 程度の機能開発。複数人や複数エージェントが並行して触る領域。設計の意図を記録として残したい変更 |
| 直接実装する | バグ修正、設定変更、軽微なリファクタ、文言の修正。試作や使い捨てのコード。vibe coding のほうが本当に速い仕事 |
今回の mdtodo は、正直に言えば cc-sdd を使わなくても作れる規模です。ただ、テスト190件・要件との対応付き・判断の記録付きという成果物が、人の介入はレビュー数回だけで手に入りました。チーム開発で「なぜこう作ったか」を残したい場面では、十分に元が取れると感じています。
6. 次の一歩
npx cc-sdd@latest --claude-skills --lang ja --dry-runで、追加されるファイルを確認する- 本番のインストールを実行し、
/kiro-steeringでプロジェクトの記憶を作る - 小さな機能を1つ選んで
/kiro-discoveryに渡し、tasks の承認まで進める - feature ブランチを切って
/kiro-implを実行し、差し戻しの内容と最終レポートを読む
v2 の「仕様を書く」体験に、v3 は「仕様どおりに作らせ、仕様で検証させる」体験を足しました。1周回してみると、人がどこに時間を使うべきかが見えてくるはずです。
参考リンク
公式ドキュメント
- cc-sdd GitHub リポジトリ
- README（日本語）：インストール、対応エージェント、CLI オプション
- スキルリファレンス（日本語）：全17スキルと
/kiro-implの内部の仕組み - cc-sdd という賭け（philosophy note）：設計思想と、向いている・向かない場面
- マイグレーションガイド（日本語）：v2.x から v3 への移行
- Agent compatibility：エージェントごとの実行環境の違い
- リリースノート（日本語）