3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@y-morimatsu(Yuki Morimatsu)inNEC゜リュヌションむノベヌタ株匏䌚瀟

🚀 cc-sdd v3で仕様駆動開発を䜓感する 〜Claude Codeず挑む半日の瀟内システム党芁件実装〜

3
Last updated at Posted at 2026-04-17

はじめに

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 から開始

📚 参考

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?