目次

1. 開発の工程と、cc-sdd が担う範囲

2. cc-sdd で進めてみる

　2.1. 要件定義

　2.2. 設計

　2.3. 作業の分割

3. 実装とレビューの繰り返し

4. 始め方の選択肢と、文書に残るもの

2026年6月の記事「 AIの結果、そのまま信じて大丈夫ですか？ 」では、AIが出した結果を人が確かめられる形にする、という考え方を主題にしました。記事では触れていませんが、そこで取り上げた自動化を組み立てるときに使っていたのが cc-sdd です。
この記事では、cc-sdd が開発工程のどこを担い、生成される資料をどう読むのかを説明します。
確かめたのは cc-sdd v3.0.2 で、2026年8月時点の動作です。

1. 開発の工程と、cc-sdd が担う範囲

開発は、利用者や業務の要求を整理する要求定義、それをシステムの要件に落とし込む要件定義、どう作るかを決める基本設計と詳細設計、それに沿って作る実装、作ったものを確かめる単体テストから受入テストまで、という段階を追って進みます。
実装を底にして、要求定義から詳細設計までを下りに、単体テストから受入テストまでを上りに並べた図をV字モデルといいます。同じ高さで向かい合う工程が対になり、どの工程で決めたことをどのテストで確かめるのかが明確になります。

工程ごとに決めたことを実装に入る前に文書として確定させ、その文書を根拠に実装する手法を「仕様駆動開発」といいます。
また、仕様駆動開発の手順をAIコーディングツールに持ち込むツールを、cc-sdd といいます。
cc-sdd が扱うのは、上の図の枠で囲んだ範囲です。要求定義と受入テストは人が確かめることになります。
この範囲を、工程ごとのコマンドで進めます。

- `/kiro-spec-requirements` … 要件定義
- `/kiro-spec-design` … 基本設計
- `/kiro-spec-tasks` … 詳細設計以降の作業への分解
- `/kiro-impl` … 実装からシステムテストまで

工程ごとに文書が作成され、次の工程の入力となります。文書を読まないまま進めると、そこに書かれた内容が確かめられないまま後の工程に引き継がれます。工程を進めるには承認が必要で、`spec.json` の該当行を `true` に書き換えるか、次の工程のコマンドに `-y` を付けます。人が文書を読むための仕組みです。

2. cc-sdd で進めてみる

cc-sdd を`npx cc-sdd@latest --lang ja --os linux` で導入して始めます。今回は Claude Code で動かしています。既定の言語は英語のため、日本語に指定するオプションを追加しています。工程の手順は `.claude/skills/` に、文書のひな型は `.kiro/settings/` に置かれており、これから生成される文書は次の場所にまとまります。

今回は作るものが決まっているため`/kiro-spec-init` から始めます。備品貸出管理を題材にして、「社内の備品を、誰がいつまで借りているか分かるようにしたい」という一文だけを渡しました。情報が足りず質問されることもあります。今回は「困っている人」、「現状の記録のしかた」、「目指す状態」を尋ねられました。答えた内容は、次の工程で作られる要件定義に渡されます。

2.1 要件定義

`/kiro-spec-requirements` で要件定義となる requirements.md が作られます。文書は渡した一文、答えた内容、対象の説明、扱う範囲、要件の本体で構成されています。扱う範囲では、この仕様が持つもの、持たないもの、前提として使うが自分では持たないものが分かれています。持たないものが書き出されるので、どこまでが対象範囲かが読めます。要件の本体は、要件ごとに二つの書式で書かれます。一つは Objective で、誰が何をしたくて、それによって何が得られるのかを一文で書きます。得られるものまで書くので、その要件が必要かどうかをここで判断できます。

> Objective: As a 利用者, I want 借りる備品と返却予定日を自分で登録できること, so that 口頭で伝えなくても貸し借りが記録に残る

もう一つは Acceptance Criteria で、その要件が満たされたと判断する条件を並べます。書式は EARS（Easy Approach to　Requirements Syntax）と呼ばれ、満たしたかどうかを一つずつ判定できるように、条件と、そのときシステムが何をするかを一文で書きます。

EARS の型は五つです。

| 型 | 書かれること |
|---|---|
| When | 事象が起きたときの応答 |
| While | ある状態が続くあいだの振る舞い |
| If … then | 誤りや失敗など、望ましくない状況への応答 |
| Where | 採るかどうかを選べる機能 |
| The … shall | 条件なしで常に成り立つ性質 |


▲ When から始まる型の記載例

型を示すこれらの語句は英語で固定されていて、日本語になるのは条件と結果の中身だけです。
EARS の型は条件・主語・応答という論理構造なので、特定の自然言語に依存しません。
cc-sdd は要件定義を書き終える前に、この語句を含む受け入れ基準が各要件にあるかを機械的に確かめます。中身の妥当性を判断する前に、形式の抜けを落とす仕掛けです。

要件の内容を読み、確認・追加・修正を行い認識の合意を進めます。AIも万能ではないため、考慮漏れや認識齟齬は発生します。
問題や確認したい箇所がなくなったら `spec.json` の該当行を `true` にして次に進みます。

2.2. 設計

続いて `/kiro-spec-design` で要件をどう実現するかを決める文書（design.md）が作られます。生成された文書は要件定義と要件番号でつながれています。

| 要件番号 | 概要 | 部品 | 呼び出し |
|---|---|---|---|
| 2.2, 2.3, 2.4 | 貸出の記録と確定時の再判定 | LoanService, LoanRepository | registerLoan |

要件番号から、それを実現する部品をたどれるため、直したい要件があるときはどこを触ることになるのかがここで分かります。
試験の方針も design.md にあります。実装のあとに何を確かめるかを設計の時点で決めておくもので、単体・結合・E2E（画面の操作をひととおり通す試験）の三段に分かれています。

> 管理者が備品を登録し、代行で貸出を登録し、全体一覧で確認するまで（1.1, 6.1, 4.1）

今回は技術を一つも指定していませんが、言語とデータベースのバージョンまで決まり、選んだ理由と選ばなかった理由が添えられています。
採らなかった構成の案は、設計と同時に作られる調査の記録に残るので、何と比べて決めたのかまで読めます。

2.3. 作業の分割

`/kiro-spec-tasks` で tasks.md が作られます。大きな作業の下にサブタスクが並び、サブタスクごとに、やること、完了したと判断する条件、対応する要件番号が付きます。
着手する前に、どこまでやれば終わりかが決まっている形です。

> 同一備品に未返却の貸出行を2件挿入しようとすると一意制約違反になることをテストで確認できる
> _Requirements: 1.6, 2.3, 3.3, 5.2, 6.5_

同じ要件番号が、requirements.md の受け入れ基準、design.md の部品と試験項目、tasks.md のサブタスクを結びます。実装のあとに何を確かめるかが、この三つの文書に揃った状態です。

3. 実装とレビューの繰り返し

作業の分割を承認すると、`/kiro-impl` で実装に入ります。コマンドにタスク番号を付けるとそのタスクだけを、付けなければ残っているタスクを順に進めます。今回は番号を指定して、一部のタスクだけを実行しました。
実装とレビューは別の役が担います。実装を書いた役ではなく、その実装に関わっていない役がレビューします。人が承認するのは工程のあいだで、実装のなかのレビューはAIが行います。
次の順で繰り返されます。

1. 実装役がテストを書き、続けて実装のコードを書く
2. 書き終えると、レビュー役が独立して検証する
3. 差し戻された場合は実装役に戻る（3回目の差し戻しで原因調査に移る）
4. 承認されたら、完了したという申告をその場で取り直した証拠と照らす
5. 問題なければ tasks.md の該当タスクをチェック済みに変える
6. 途中で分かったことを tasks.md の末尾に書き足す

1で使われているのはテスト駆動開発と呼ばれる進め方で、小さな単位に区切って次の3つを繰り返します。
まず、これから作る動きを確かめるテストを書きます。実装がまだないので、この時点では失敗します。
次に、そのテストを通すためだけの実装を書きます。
最後に、それまでに書いたテストがすべて通る状態を保ったままコードの重複を削って整えます。
1で最初に失敗を確かめるのは、そのテストが狙った動きを見ているかどうかの判定になるためです。
まだ実装していないのに通ってしまうなら、そのテストは別のものを見ているので書き直します。
cc-sdd では、テストの中身をここで新しく決めません。何をどう確かめるかは、requirements.md の受け入れ基準と tasks.md の完了の条件で、すでに決まっています。

3の繰り返しは2回までで、3回目に入ると原因調査に移ります。原因調査は1タスクにつき2周までで、それでも通らなければそのタスクは停止した扱いになります。
残っているタスクがすべて止まった場合は、そこで `/kiro-impl` が停止して理由が報告されます。全体の可否を見る `/kiro-validate-impl` も、すべてのタスクが済んでいない状態では通りません。
6で書き足したものは、次のタスクの実装役に、その境界や依存に関わるものだけが渡されます。同じつまずきを繰り返さないような仕組みです。

実際に走らせると、続けて実行した3つのタスクで、いずれもレビューが差し戻しになりました。

▲ 前のタスクで直したあとも、次のタスクで同じ型の指摘が出ている

どれも実装は動いていて、テストも通っていました。前提が落ちたかどうかは、実装役自身には確かめられません。

差し戻しを直しながら進めて、できあがった画面が次のものです。UIについては決めなかったため質素ですが、管理者は登録した備品を状態つきで見ることができます。

▲ 登録した備品が名称・識別番号・状態で並ぶ

利用者が借りる側の画面では、選択肢の出方が変わります。

▲ 貸出可能な3件だけが並ぶ

要件定義に書いた「貸出可能な備品のみを選択の対象として提示する」が、そのまま画面の挙動になっています。

この進め方のため、AIを呼び出す回数はタスクの数に比例して増えます。
レビュー役は毎回新しく立ち、tasks.md で並行して進められる印が付いたものも1件ずつ処理されるので、差し戻しや原因調査が入ればさらに増えます。
規模の大きいものをまとめて任せるときは、消費するトークンの量に気をつける必要があります。

4. 始め方の選択肢と、文書に残るもの

一文を渡すだけでも、足りない情報を聞かれながら進められました。
今回は作るものと進め方が決まっていたため`/kiro-spec-init` から始めましたが、進め方が決まっていないときは `/kiro-discovery` から始められます。新しく仕様を作る、既存の仕様を更新する、仕様を作らずに直接実装する等、進め方のどれが合うかを、対話しながら振り分けてくれます。
また、cc-sddは決定事項や進行状況をファイルに残す決まりのため、途中からの再開や、別の人への引き継ぎができます。最初に要件を渡すだけで実装まで実施されることはなく、各工程で文書を承認するまで次へ進まないので、作成された文書から人とAIの認識を合わせて手戻りの少ない開発ができます。
開発経験の有無にかかわらず、一度cc-sddを用いた開発を始めてみてはいかがでしょうか。