仕様駆動開発の理想と現実、そして向き合い方

AIコーディングにおいて「Vibe Coding」から脱却し、確実な成果を出すための「Spec-Driven Development (SDD / 仕様駆動開発)」について、その理想的なフローと現場で直面する現実（Specの巨大化、検証の難しさ）を紹介。

OSSの仕様駆動開発ツール「cc-sdd」を開発した知見をもとにした実践的ワークフロー、特にProperty-based testsを活用した正確性検証のアプローチについても紹介しています。AIと協働して開発品質とスピードを最大化したいエンジニア向けの資料です。

Transcript

1. 仕様駆動開発の理想と現実、そして向き合い方
 Gota (@gota_bara)
 
 2025/11/19 Findy
 仕様駆動開発〜新たな開発手法の可能性と実践〜 
 1
2. 自己紹介
 Gota (@gota_bara) 所属 データアナリスト & Agentic AI エンジニア やってること ⼩売向けデータプロダクト / AIエージェント開発 / データ整備 興味 AI × 体験 / ⾳声AI / DSPy / 🏕(夏以外) / 明⽇からエアライダー cc-sdd ⭐1.8k Kiro-styleの仕様駆動開発ツール 来週までにKiroに追加された「property based tests」もcc-sdd側にも追加予定 2
3. 詳細設計書の並列実装が可能なタス ク分解を⾏えるように！ 仕様駆動開発ツール cc-sdd
 7エージェント対応 Claude Code / Codex / Gemini CLI / Cursor / Github Copilot / Windsurf / Qwen Code で利⽤可能 テンプレート機能 (独⾃) 各仕様書をチームのワークフローの テンプレートに置き換え可能！ 1度のカスタマイズでどのエージェン トからでも利⽤可能 並列実装のタスク分解 • Kiro式の仕様駆動開発をCoding Agentで利⽤可能！ • 11/10にチーム開発と並列実装に向けたアップデート！ 要求定義 詳細設計 タスク分解 実装 Steering Specs (Kiro⽅式) ‧cc-sddのGithub: https://github.com/gotalab/cc-sdd 3 Kiro GA時の変更に伴い、11/24以降に詳細 設計以降をPropety-based Testsに対応す る形で更新を⼊れます。 実装はTDDも残しますがdeprecated
4. 仕様駆動開発の理想像

5. 5 Vibe Codingと課題
 バイブスに任せてコードの存在を忘れてAIの出⼒が意図通りに動作すると完全に 信頼すること！ 明確な要件定義がないことで運⽤において⼤きな技術的負債となりうる ⼤規模コードベースでの 限界 出⼒のズレによる ⼿戻り発⽣ ナレッジ管理の ⽋如
6. 本番環境レベルの複雑なアプリケーションを構築するためのAgentic IDE 6 Kiroの登場 - Spec-Driven Development の始まり
 ※ Kiroのアイコンのキャラクター名を知りたいです. Ghost?
7. 7 Spec-Driven Development (SDD)とは？
 AIが実⾏可能な明確なSpecを書くことが主要な成果物になるアプローチ 2つの考え⽅の転換 • 開発の共通言語が「コード」から「自然言語」へ • 人間は承認役、 AIが開発の主体
8. 8 Spec-Driven Development (SDD) の良さ
 1. 厳格な承認フローを実施時、実装の⼿戻りが⾮常に少ない 2. Specが構造化されているため、設計レビュー時の認知的負荷が軽減する 3. 並列実装が⾏いやすい 4. 要求定義と技術設計の分離により、同じ要件に対する様々なアーキテクチャパターンを 試しやすい 5. 設計フェーズでチーム全体で議論を⾏うことが開発に良い影響を与える ◦ チーム開発での認識齟齬が減る ◦ 実装後のコードレビューの認識齟齬が減る ◦ 設計についての理解が深まることでコード理解が早くなる
9. 9 そもそも Spec って何？
 AI がそのまま実⾏可能なレベルまで緻密＆構造化されたドキュメント群 1. Specは自然言語で書かれている 2. Specは文書化されている 3. Specは構造化されている 4. Specは下流にわたって検証可能である 5. Specは人とAI両方のSSoTとなる 6. Specは実装のフィードバックを通じてどんどん変化する 理想的なSpec オレオレ6箇条
10. 10 Specに必要な最低限の項目
 • AI がそのまま機能開発可能なレベルで⾃然⾔語で構造化されている • タスクにより不要な要素もある Why & Where 【Intent / 背景】 ‧⽬的: なぜ作るのか ‧解決するユーザ / ビジネス課題 【Scope / Non-Goals】 ‧対象範囲 ‧やらないこと What 【振る舞い仕様】 ‧ユースケース/ユーザーストーリー ‧画⾯遷移 / フロー ‧⼊出⼒‧状態遷移 ‧エッジケース処理 【技術‧品質要件】 ‧インターフェイス / データ契約 (API仕様、スキーマ) ‧制約 / ⾮機能要件 How to Verify 【受け⼊れ条件】 ‧完了の定義 ‧テスト観点 【タスク分解 / 計画】 ‧実装タスク⼀覧 (TODO) ※実⾏可能なレベルまで落とし込む には必要 プロジェクト憲章 / Steering ① ② ③ ④ ⑤ ⑥
11. 11 SDDの理想的な機能追加フロー
 • SDDは繰り返し前提のループ構造 • LLMの不確実度を下げ、⽣成と検証のループを⾼速化すること • AI 時代のアジャイル開発をSpecを中⼼に再設計したものが仕様駆動開発 Spec レビュー/承認 実装 テスト/ メトリ クス検証 フィードバック ここがAIにより爆速になる ⽇単位でのサイクル ※正確性を⼀部犠牲にしています 承認ゲート
12. 12 SDDの忘れがちなポイント①: 検証可能性
 • Specの振る舞い仕様がユニットテストと結びつくことで最終的に検証まで⾃ 動化される • 理想ではコードレビューを⼤幅に軽減&なくせる Spec レビュー / 承認 実装 テスト/ メトリ クス検証 フィードバック ここがAIにより爆速になる ⽇単位でのサイクル Specは下流の検証まで対象 ① ② ③ ④ ⑤ ⑥
13. ① ② ③ ④ ⑤ ⑥ 13 SDDの忘れがちなポイント②: フィードバックループ
 • 理想ではSpecは⼀度きりのものではなく • SDDは仮説と要件を⼀時的にFixした反復プロセスであり、このサイクルが短 いことを前提に成り⽴っている考え⽅ Spec レビュー / 承認 実装 テスト/ メトリ クス検証 フィードバック ここがAIにより爆速になる ⽇単位でのサイクル ※正確性を⼀部犠牲にしています 変更提案のSpec作成 ‧変更したSpecを永続的な Specに追加 ‧実装したSpecをもとに再 度変更
14. 14 理想的なSDDが実現できると...
 ソフトウェア開発の品質とスピードを上げ、顧客に価値を機能追加を最速で届け られる！ SDD最⾼だねと⾔いたいところだが... Spec レビュー/承認 実装 テスト/ メトリ クス検証 フィードバック ここがAIにより爆速になる ⽇単位でのサイクル ※正確性を⼀部犠牲にしています 承認ゲート
15. 15 SDD系ツールの機能とLLMモデル、運⽤が 理想に追いついてない
16. 仕様駆動開発の現実

17. 17 SDD系ツール
 1. Kiro ◦ AWSのAI-DLCに準拠したIDE/CLI。 ◦ Spec/Steering/HooksをIDEから利⽤でき、GUIで低学習コストでSDDを利⽤可能 2. Spec-kit ◦ MicrosoftのSDLCに準拠したSDDツール ⭐49.4k。 ◦ 明確なインターフェイス定義と詳細なタスク分解が可能で複雑なソフトウェア設計でもブレ にくいが、ドキュメント過多 3. Openspec ◦ 既存Specや複数Specへの機能追加が可能なSDDツール ⭐9.5k。 ◦ SpecをSSoTとし、フィードバックループを回す点で優れているが、学習曲線が急 4. cc-sdd ◦ Kiroと同じフローでCoding Agentで利⽤可能なSDDツール。⽇本語対応。 ◦ 軽量で中規模以上の機能追加向き。既存やアーキテクチャ調査にも幅広く対応 5. BMAD Method ◦ SDDと同じ枠組みのアジャイルAI駆動開発。 ◦ タスクに応じて⾃律的に計画トラックを変更できるため、幅広いタスクで活⽤可能
18. 18 SDDフローの現実 (2025/11)
 • SDDツールはまだまだ課題だらけ... Spec レビュー / 承認 実装 テスト/ メトリ クス検証 フィードバック ‧テスト/コードレビューは⼈が主導 ‧Specの正確性の検証する⽅法がない ※正確性を⼀部犠牲にしています ‧Specが反復的なプロセスに利⽤できる ツールは少ない ‧SDDフローは関わるステークホルダーが 多く、組織のプロセスを変える必要性 既存のSSoTのSpecに追記する 仕組みがない ‧Specの作成フローが組織に カスタマイズされてない ‧複雑性の低減や明確な境界 設計が出来ているソフトウェ はアーキテクチャでないと複 雑さをより悪化させる ‧Specを適切に分解出来ない Specデカすぎてレビュー に時間がかかる 複雑すぎると実装漏れ
19. 19 SDDツールでAIが作成したSpecが巨大化する
 • 現状のSDDツールはオーバーヘッドの⼤きいワークフローが固定化されてお り、各タスクに適切なSpecを作るのが難しい • 複雑なSpecの場合、複数のシンプルなストーリーのSpecを作成する必要が あるが、⼈⼒で⾏う必要がある 491⾏ 226⾏ 608⾏ 907⾏ 130⾏ 497⾏ 631⾏ 計3,590⾏ ⼩さな機能追加でも同様のプロセスを踏む
20. 20 大規模プロジェクトではコンテキストが不足しがち
 • 依存関係の多さや複雑性が⾼くなると、SDDでも扱うのが難しい • 複雑性を抑えるアーキテクチャにし、コンテキスト分離できるような設計を ⾏う必要がある
21. 21 SDDはエンジニアだけでは完結しない
 各プロセスでチーム全員が集ま り共同作業を⾏う必要がある • プロダクトオーナー • プロダクトマネージャー • ビジネスアナリスト • ソフトウェアエンジニア • QAエンジニア 組織構成や開発プロセスの上段を変 えないとSDDの価値が発揮されない 出典: AI-DLC ホワイトペーパー
22. 22 Spec実装後の正確性を検証する仕組みがない
 • LLMが確率的な出⼒をする以上Specのみで実装漏れやミスを防ぐのは難しい • Specの正確性検証はSDDの必須要件 Spec レビュー / 承認 実装 テスト/ メトリ クス検証 フィードバック ‧テスト/コードレビューは⼈が主導 ‧Specの正確性の検証する⽅法がない ※正確性を⼀部犠牲にしています Specデカすぎてレビュー に時間がかかる 開発プロセスを変えずにSDDに取り組むと、単純に激重レビューが1回増えるのみ...
23. 23 Kiro - Specの正確性を検証する機能を導入
 AIによる実装がSpecの正確性を担保しているかを検証するアプローチとして Property-based testsを採⽤ (11/18)
24. 24 Property-based testsとは
 システムがどのように動作すべきかをもとに、どのような⼊⼒でも必ず成り⽴つ 性質の⼀般則を検証するテスト 従来のテスト Property-based tests 具体的な⼊⼒例をいくつか⼿で決めて、期待 される出⼒と⽐較する 例: add(2, 3) → 5、add(-1, 1) → 0 テストの 書き⽅ どんな⼊⼒でも常に成⽴するべきプロパティ を定義する 例: 任意の2つの整数でadd(a, b) = add(b, a) ケース数 ⽤意する例の数 (通常5~20個) ⾃動で100以上のランダムデータを⽣成しテ スト エッジケースも⾃動テスト テスト コード量 ケースに⽐例してテストコードが肥⼤化 プロパティ1つで数百ケースカバーできるた め、コード量が少ない ツール Python: pytest, Typescript: vitest Python: Hypothesis, Typescript: fast-check
25. 25 KiroのProperty-based tests について
 ‧Kiroの要求定義からプロパティを抽出し、タスクとしてテストを実⾏する ‧Kiroの受⼊基準のEARS記法と相性が⾮常に良い WHEN [condition/event] THE SYSTEM SHALL [expected behavior] WHEN プレイヤーが推測を送信するとき、 THE Game System SHALL 推測位置と実際の 位置の間の距離をキロメートル単位で計算する 期待される挙動が WHENの条件の時にいつでも成り 立ってほしい ”プロパティ ”となる Property-based tests 任意の2つの有効な地理座標（推測位置と実際の位 置）に対して、システムは Haversine公式を用いて正 確な距離をキロメートル単位で計算する EARS記法 - Geoguessr⾵ゲームの受⼊基準の1つ EARS記法 Property-based tests
26. 26 ちなみに...Kiro Pro+
 初期からシリーズBまでのVC⽀援を受けているスタートアップは1年間分無料で使 えるらしい...(2025/12/31までの期間限定) https://kiro.dev/startups/
27. 仕様駆動開発とどう向き合うべきか？

28. 28 SDDの前にやっておきたいこと
 ‧CI / CD等のDevOpsを最低限整え、評価‧検証サイクルが回る状態にする ‧システム全体を複雑性を抑えたモジュール性の⾼い設計にする AI駆動開発は検証と改善が命！⼟台がないと最⼤限の恩恵を得られない https://www.atlassian.com/ja/devops
29. 29 現状のSDDツールに適しているユースケース
 ‧安定している領域 × 明確な境界が引きやすい構造は向いている ‧未知の未知や⼩規模タスクにはSDDを採⽤しない！ 安定している 明確な境界を引ける • 仕様が変わりにくい ◦ 外部システムとのインターフェイス (API / プロトコル) ◦ データの整合性やDB設計 • リスクや規制が多い ◦ ⾦融 (請求‧会計計算ロジック) ◦ 法律 • 組織⾃体の明確な境界 ◦ 要件定義と開発が明確に分かれてい る ◦ チーム全体が⾼頻度で集合できる • アーキテクチャの境界設計 ◦ モジュール化がしやすい
30. 30 Specの最低限の項目をもとにSDDを小さく始める
 ⾃社開発プロセスに適した形で最⼩限のSpecから育てられると、SDDツールの課 題にハマらず広いユースケースで利⽤可能 Why & Where 【Intent / 背景】 ‧⽬的: なぜ作るのか ‧解決するユーザ / ビジネス課題 【Scope / Non-Goals】 ‧対象範囲 ‧やらないこと What 【振る舞い仕様】 ‧ユースケース/ユーザーストーリー ‧画⾯遷移 / フロー ‧⼊出⼒‧状態遷移 ‧エッジケース処理 【技術‧品質要件】 ‧インターフェイス / データ契約 (API仕様、スキーマ) ‧制約 / ⾮機能要件 How to Verify 【受け⼊れ条件】 ‧完了の定義 ‧テスト観点 【タスク分解 / 計画】 ‧実装タスク⼀覧 (TODO) ※実⾏可能なレベルまで落とし込む には必要 プロジェクト憲章 / Steering
31. 31 (番外編) ソフトウェア設計の勉強や比較の叩きに
 Spec-kitやcc-sddのresearch.mdは技術調査やアーキテクチャパターンの⽐較検討 を⾏っており、新規⼤規模開発時の複雑な設計⽀援も可能！
32. 32 まとめ
 ‧SDDの⼤⽬的は「ソフトウェア開発の品質とスピードを上げ、顧客に価値を機 能追加を最速で届ける！」こと ‧SpecがSSoTとしていくために、実践と変化を楽しむ⼼を忘れない！ Spec レビュー/承認 実装 テスト/ メトリ クス検証 フィードバック ここがAIにより爆速になる ⽇単位でのサイクル ※正確性を⼀部犠牲にしています 承認ゲート
33. ありがとうございました！
 質問やお問い合わせ等あればお気軽に連絡ください！ 
 X: @gota_bara
 cc-sddのGithub