GitHub Copilot × cc-sdd で仕様駆動開発を「最初の一周」回す

この記事のゴール

cc-sdd を GitHub Copilot（VS Code 拡張）に導入し、
初回セットアップから基本フローを一度体験するところまでを扱います。

※ 本記事は 2026-01-08 時点の cc-sdd 公式 README に基づいています。

はじめに

https://zenn.dev/toji_inoue/articles/3664be04922978

前回の記事では、AI が正しく判断できる保守案件（After）と
そうでない案件（Before）の違いを可視化しました。

本記事では、その「After の状態」を あなたの GitHub Copilot 環境で実際に構築する手順を解説します。

cc-sdd は「便利なコマンド集」ではありません。
仕様 → 設計 → 実装 という開発の順番を、AI にも人間にも守らせるための仕組みです。

最初に大事なのは設定を完璧に理解することではなく、
cc-sdd ではどんな順番で何をするのか を一度体験として理解することです。

---

1. cc-sdd を GitHub Copilot に導入する

必要なもの

• Node.js（npx が使えること）
• VS Code
• GitHub Copilot
• GitHub Copilot Chat（VS Code 拡張）

インストール

npx cc-sdd@latest --copilot --lang ja

オプション	意味
--copilot	GitHub Copilot（VS Code 拡張）向けの構成を生成
--lang ja	生成される仕様書（requirements / design / tasks）を日本語にする

インストール後のフォルダ構成

your-project/
├── .kiro/
│   ├── steering/      # プロジェクトの前提（憲法）
│   ├── specs/         # 機能ごとの仕様（変更単位）
│   └── settings/      # 型・ルール（初回は触らない）
└── .github/
    └── prompts/       # GitHub Copilot 用の進行指示

この時点で覚えておくのは 2点だけ で十分です。

• .kiro/steering：プロジェクト全体の前提条件
• .kiro/specs：機能ごとの仕様を置く場所

---

2. cc-sdd の基本フローを先に理解する（重要）

ここを理解できれば、この記事の8割は理解できています。

cc-sdd では、いきなりコードを書きません。必ず次の順番で進みます。

承認とは何か

cc-sdd における「承認」とは、

人間が内容を確認し、「この内容で進めてよい」と合意すること

AI が生成した内容をそのまま進めるのではなく、
各フェーズごとに人間がレビューすることが前提です。

-y オプションについて

-y は「自動で承認する」という意味ではありません。

「前のフェーズをすでに人間が確認・合意済み」 であることをAIに伝えるフラグです。
中身を見ずに -y を連打すると、誤った仕様のまま進んでしまい手戻りの原因になります。
必ず requirements.md → design.md → tasks.md を確認してから使用してください。

---

3. Steering：プロジェクトの記憶を作る

なぜ Steering が必要か

AI は ステートレス です。セッションが変わると、使用技術・制約・命名規則といった前提をすべて忘れます。

Steering は、これらを永続的なファイルとして残すための仕組みです。

Steering はプロジェクト開始時に一度作成すれば、通常は毎回実行不要です。
技術スタックの大幅変更・プロジェクト構成変更時のみ更新・再実行を検討します。

コマンド実行

Copilot Chat で実行します。

/kiro-steering

生成ファイル	内容
product.md	プロダクトの目的・価値
tech.md	技術スタック・設計方針
structure.md	ディレクトリ構成・命名規則

---

4. 要件定義：何を作るかを明確にする

まず機能単位のワークスペースを作成します。

/kiro-spec-init <やりたいことを書く>
例：/kiro-spec-init ユーザー一覧画面を作成する

続いて要件定義を行います。

/kiro-spec-requirements <spec-id>

spec-id は /kiro-spec-init 実行時に作られるフォルダ名（英語スラッグ）です。
以降の design / tasks / impl でも同じ spec-id を使います。

AI は自然言語の要望を EARS 形式（明確な要件記述フォーマット）に変換します。
曖昧な表現があればこの段階で修正します。

---

5. 設計：実装前に止めるための最重要フェーズ

/kiro-spec-design <spec-id> -y

設計フェーズは後戻りを防ぐために最も重要な工程です。
ここで承認した内容が、以降のタスク分解と実装の基盤になります。

---

6. 設計の検証：要件との整合性を確認する

/kiro-validate-design <spec-id>

設計が要件を正しく網羅しているかをAIが検証します。
設計フェーズで承認した design.md と requirements.md を照合し、抜け漏れや矛盾がないかチェックします。

問題が検出された場合は設計フェーズに戻って修正します。
ここをスキップすると、タスク分解・実装まで進んだ後で手戻りが発生するリスクがあります。

---

7. タスク分解：AI が迷わない粒度にする

/kiro-spec-tasks <spec-id> -y

1タスク 1〜3時間程度の粒度に分解することで、AI が迷わず実装できる状態が整います。

---

8. 実装：ここで初めてコードを書く

/kiro-spec-impl <spec-id> 1 -y

1 は tasks.md に書かれているタスク番号です。
この時点で AI は Steering・Requirements・Design・Tasks すべてを理解した状態で実装します。

---

9. 実装の整合性確認：仕様書との最終チェック

/kiro-validate-impl

実装完了後、仕様書との整合性を最終チェックします。
requirements.md・design.md ・tasks.md のすべてと実装内容が一致しているかをAIが確認します。

ここで差分が検出された場合は、実装の修正か仕様書の更新かを判断します。
「仕様通りに作ったつもり」が「実は漏れていた」を防ぐための最後の砦です。

---

10. まとめ

• cc-sdd はツールではなく開発フロー
• 最初に理解すべきは設定ではなく順番
• 承認前提で進めることが仕様駆動開発の核
• -y は「確認済み」のシグナル。中身を必ず確認してから使う

---

次に読む

操作方法を覚えただけでは、まだ現場では戦えません。
次の記事では、保守案件での**AI時代の「思考の順番」**を整理します。

https://zenn.dev/toji_inoue/articles/ecf96868048c58

---

【付録】cc-sdd コマンド完全リファレンス

セットアップ・共通ルール

コマンド	意味・用途
/kiro-steering	プロジェクトの憲法（product.md, tech.md, structure.md）を生成・更新
/kiro-steering-custom	チーム共通ルールを読み込み、AI のコンテキストを最新化

基本開発サイクル（上から順に実行）

順序	コマンド	意味・用途
1	/kiro-spec-init <概要>	新しい機能のワークスペース（Spec フォルダ）を作成
2	/kiro-spec-requirements <ID>	要望を EARS 形式に変換し requirements.md を生成
3	/kiro-spec-design <ID> -y	アーキテクチャ・データフローを設計し design.md を生成
4	/kiro-spec-tasks <ID> -y	実装粒度に分解し tasks.md を生成
5	/kiro-spec-impl <ID> <No> -y	指定タスク番号の実装を実行（例: /kiro-spec-impl user-list 1 -y）

検証・品質担保

コマンド	意味・用途
/kiro-validate-gap	既存コードと新要件の差分を分析（Brownfield 改修時）
/kiro-validate-design <ID>	設計が要件を正しく網羅しているか検証
/kiro-validate-impl	実装完了後、仕様書との整合性を最終チェック

進捗管理

コマンド	意味・用途
/kiro-spec-status <ID>	現在のフェーズと承認ステータスを表示

---

参考

https://github.com/gotalab/cc-sdd