手戻りゼロ？ Spec Driven Developmentとは@KAG AI week

仕様駆動開発、SDD、 Spec Driven Development、Claude Code、AIコーディング、AI駆動開発

1. 2026.2.18 KAG AI week 手戻りゼロ？ Spec Driven Developmentとは KDDIアジャイル開発センター株式会社 平井 友樹 1
2. 自己紹介 平井 友樹 (Tomoki Hirai) KDDIアジャイル開発センター株式会社（KAG） スクラムマスター/エンジニア AWS, React, Flutter, AI開発など 2
3. この発表について 対象者: AIコーディングツール（Copilot、Cursor、Claude Code等）を使い始めた方 AIに指示しても思い通りのコードが出ず困っている方 今日のゴール: AIコーディングで手戻りが起きる原因を理解する Spec Driven Development（SDD） という解決策を知る cc-sdd を使った実践の流れをイメージできる ※ 私もSDDに入門したばかりです。一緒に学んでいきましょう！ 3
4. AIコーディング、こんな経験ありませんか？ 4
5. いつものAIコーディング 登録機能を作って できました！ メール形式チェックも追加して...重複時は422で返して...確認メールも送って... 修正しました！...修正しました！... この繰り返しが 複数回実施される → ようやく完成 5
6. なぜ手戻りが起きるのか AIに言ったこと: 頭の中では実はこう思っている: 名前・メール・パスワードが必須フィールド 重複時は422エラーを返す 登録後に確認メールを送る パスワードは8文字以上・英数字混在 AIに伝えていない仕様が手戻りになる ユーザー登録機能を作って 6
7. そこで、Spec Driven Development 7
8. Spec Driven Development(SDD)とは 日本語では 「仕様駆動開発」 と訳される 「仕様を先に整理してからコードを書く」 開発手法 AWSが Kiro でSDDワークフローを提唱 GitHubが spec-kit を公開 「Vibe Coding（とりあえずAIに作らせる） 」とは違う考え方 8
9. SDDのAIコーディング 登録機能の要件・設計をまとめて 要件・設計・タスクをまとめました LGTM! この仕様で実装して 仕様通りに実装しました 途中にレビューは挟むが、手戻りなく完成 🎉 9
10. 比べてみると 通常のAIコーディング すぐコードを書かせる 何度も修正を繰り返す 成果物はコードだけ 修正込みで実は遅い SDD 要件・設計を先に決める 仕様に沿って一発で生成 要件+設計+コードが残る 結果的に速い 10
11. cc-sddで始めるSDD 11
12. cc-sddとは AWSが作ったAIエディタ Kiro のSDDワークフローにインスパイアされたOSSツール Kiroの仕組みを今使っているエディタ・CLIでそのまま使えるようにしたもの 日本語対応: 生成される要件・設計ドキュメントも日本語 マルチエージェント対応: Claude Code / Cursor / Copilot など 導入が簡単: npx 1コマンド、30秒でセットアップ完了 12
13. cc-sddの開発フロー steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 各ステップでAIが成果物を生成 → 人間がレビューしてから次へ進む 次のスライドから各ステップを詳しく見ていきます 13
14. Step 0: steering(コンテキスト作成) コマンド: /kiro:steering アウトプット: .kiro/steering/*.md 開発開始前の下準備 プロダクト概要、技術スタックなどを整理 プロジェクトの文脈や暗黙知をAIに伝える 以降のコマンドはこの文脈を参照 # product.md（プロダクト概要） テスト分類と機能観点のマスタデータを 提供するステートレスなREST API # structure.md（プロジェクト構成） レイヤードアーキテクチャ CDKインフラとLambdaアプリを分離 **Location**: `lib/`, `bin/` **Purpose**: AWS CDKスタック定義と アプリエントリーポイント # tech.md（技術スタック） TypeScript, Hono, AWS Lambda, AWS CDK v2, Zod, Node.js 22.x steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 14
15. Step 1: spec-init（初期化） コマンド: /kiro:spec-init <feature> アウトプット: .kiro/specs/<feature>/ 機能ごとに仕様ワークスペースを作成 以降の成果物がこのフォルダに格納 .kiro/specs/<feature>/ ├── requirements.md ├── design.md ├── tasks.md ├── research.md └── spec.json steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 15
16. Step 2: spec-requirements（要件定義） コマンド: /kiro:spec-requirements <feature> アウトプット: requirements.md ユーザーストーリー + 受入条件の形式 EARS (Easy Approach to Requirements Syntax) 形式 機能要件・非機能要件を構造化 レビューしてOKなら次のプロセスへ ... ### Requirement 1: テスト分類一覧取得 **Objective:** As a API利用者, I want テスト分類の一覧を取得したい, so that どの分類が利用可能か把握できる #### Acceptance Criteria 1. When APIが分類一覧取得リクエストを受信した場合, the Test Viewpoint API shall 11種類の分類（画面、画面遷移、入力あり、 ファイル入力、ファイル出力、CRUD、検索、 メール、バッチ、バックエンド、Bluetooth）とその定義を返却する 2. The Test Viewpoint API shall 各分類について分類名（name）と詳細説明（description） を含むJSON形式で応答する ... steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 16
17. Step 3: spec-design（設計） コマンド: /kiro:spec-design <feature> アウトプット: design.md ,( research.md ) コンポーネント構成・APIの詳細設計 steeringの規約に沿って設計 シーケンス図やER図も生成される 調査が必要な場合は research.md に記録 レビューしてOKなら次のプロセスへ steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 17
18. Step 4: spec-tasks（タスク分解） コマンド: /kiro:spec-tasks <feature> アウトプット: tasks.md TODO形式でタスク分解 各タスクに要件IDが紐付く P0(逐次実行) / P1(並列実行) のラベル付き レビューしてOKなら次のプロセスへ - [x] 1. OpenAPIHono基盤の構築 Req: 4.1, 4.2, 4.3 - [x] 2.1 (P) テスト分類マスタデータ定義 Req: 1.1, 1.2 - [x] 2.2 (P) 機能観点マスタデータ実装 Req: 2.1, 2.2 - [x] 3.1 (P) 分類一覧取得エンドポイント - [x] 3.2 (P) 観点取得・フィルタリング - [x] 4.1 (P) ユニットテスト - [x] 4.2 (P) 統合テスト steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 18
19. Step 5: spec-impl（実装） コマンド: /kiro:spec-impl <feature> [task-ids] アウトプット: コード変更 タスクIDを指定して実装 TDD形式でテストコードも生成される steering コンテキスト作成 → spec-init 初期化 → requirements 要件定義 → design 調査と詳細設計 → tasks タスク分解 → spec-impl 実装 19
20. validate コマンドで各フェーズを検証できる 各ドキュメント間の整合性を、 /kiro:validate-* コマンドでチェックできる コマンド 役割 実施タイミング /kiro:validate-gap ソースコードと requirements.md の差分を分析し gap-report.md を生成 任意（既存PJの改修 時に有効） /kiro:validate- design design.md の整合性・テンプレート準拠をレビュー 開発者レビューの前 後 /kiro:validate- impl 実装済みタスクが tasks.md の受け入れ条件を満た すか確認 spec-impl 完了後 20
21. どう使い分ける？ 通常のAIコーディング プロトタイプ・PoC 使い捨てスクリプト 個人の小規模ツール 仕様が曖昧でも「まず動くもの」が欲しい → スピード重視の場面 SDD 複数人で開発する機能 仕様が複雑・条件分岐が多い 長期運用するプロダクション 認識合わせが必要なチーム開発 → 品質・再現性重視の場面 両方使いこなすのが理想。規模と複雑さで判断 21
22. とはいっても、実際に触ってみないとわかりませんよね？ 1. npx cc-sdd@latest --claude --lang ja (Claude Code) でセットアップ 2. 小さな機能を1つ選んで、一通り流してみる 3. AIが作った要件・設計・タスクを読んでみる 4. 「こんなに整理されるのか」を体験する 好きなAIエージェントにインストールして試してみましょう！ 22
23. まとめ AIコーディングの手戻りは伝えきれていない情報が原因 SDDはコードの前に仕様を決めることで手戻りを防ぐ cc-sddを使って簡単にSDDを始められる 各フェーズで人間がレビューするから安心 SDDで手戻りを減らし、AIコーディングをもっと快適にしましょう！ 23