TL;DR
- チャットベースの指示は「揮発性」が高く、大規模開発には向かない
- Spec（仕様書）を Source of Truth に据え、AI のコンテキストを固定する
- 人間は「コードを書く選手」から「仕様を承認する審判」へと役割を変える
このシリーズについて
AIエージェント（Copilot, Cursor, Gemini）とのペアプログラミングは楽しいですが、同時に**「指示が伝わらない」「勝手にコードを書き換えられる」**といったストレスも生みます。
「もっと賢いAIが来れば解決する」？ いいえ、問題はモデルの賢さではなく、**「指示の出し方（アーキテクチャ）」**にあります。 チャット欄に自然言語でお願いするスタイルから脱却し、Spec Driven Development (SDD) という新しい開発パラダイムへ移行しましょう。
SDD の 3 つのコア原則
- Explicit Over Implicit: 暗黙的な了解を排し、すべてを Spec にマッピングする
- File Over Chat: 会話ログではなく、構造化されたファイルを真実のソースとする
- Approve Over Write: 人間はコードを書かず、AI の Plan を審査・承認する
開発スタイルの対比
| 項目 | チャット駆動開発 | Spec 駆動開発 (SDD) |
|---|---|---|
| 情報の所在 | 会話ログ（揮発性） | 仕様書ファイル（永続性） |
| 指示の解釈 | AI の推論に依存 | 厳格な要件・設計に基づく |
| 複雑度への耐性 | コンテキストが溢れると破綻 | 階層化された Spec で管理可能 |
| 人間の役割 | コードを書く / 指示を繰り返す | 仕様を定義し、Plan を承認する |
Chapter 1: なぜ仕様書が必要なのか？
なぜAIエージェントは「仕様書」を無視するのか？：Spec Driven Development (SDD) の必要性
会話ログは流れますが、仕様（Spec）は残ります。AIの記憶力を嘆く前に、私たちが「正解（Source of Truth）」をどこに置くべきかを再考する必要があります。 チャット駆動開発の限界と、仕様書駆動開発（SDD）の基本概念を解説します。
Chapter 2: 時間軸で管理するSpec
会話は流れるがファイルは残る：Requirements/Design/Tasksによる「時間軸」管理術
仕様書といっても、何をどう書けばいいのか？ 重要度と更新頻度に応じてドキュメントを「過去（Requirements）」「現在（Tasks）」「未来（Design）」に3分割する、具体的かつ実用的なディレクトリ構成を紹介します。
Chapter 3: 人間はコードを書くな
エージェント開発の「人間」の役割：コードを書くのをやめ、承認ボタンを押す仕事へ
SDD環境下において、人間の仕事は大きく変わります。もはやコードを書く「選手」ではなく、AIの提案を審査する「審判」です。 GitHub Issueと承認ゲート（Approval Gate）を組み合わせた、最も効率的な Human-in-the-loop ワークフローを定義します。
SDD ワークフロー図
graph TD
A[Requirements] --> B[Design]
B --> C[Tasks]
C --> D{Human Approval}
D -->|Approve| E[Execution]
D -->|Reject| B
結論
AIを「ただの便利な検索エンジン」で終わらせるか、「自律的かつ制御可能なパートナー」に昇華させるか。その違いはこのSDDアーキテクチャにあります。 エージェントに振り回される日々は、今日で終わりにしましょう。
参考・一次資料
SDD は各社の仕様駆動ツールが実装パターンを公開しています。原典で前提を確認すると導入判断がぶれません。
- AWS Kiro: Spec-driven development — requirements/design/tasks を分離する公式モデル
- GitHub spec-kit — 仕様駆動開発のツールキットとテンプレート
Related Series
各章で「何が分かるか」を一言で示します。読了順に並べているので、詰まっている工程から読み進めてください。
- 第1章：なぜAIエージェントは「仕様書」を無視するのか？ — チャット指示が破綻する根本原因が分かる
- 第2章：仕様駆動開発の失敗パターン7選と対策 — 導入で陥る典型失敗と回避策が分かる
- 第3章：Issueテンプレで要件解像度を上げる — AIが迷わない依頼文の4点セットが分かる
- 第4章：受入条件を先に書くTDD実践 — 手戻りを減らすチェック設計が分かる
- 第5章：時間軸で管理するSpec（Requirements/Design/Tasks） — 仕様を3層で時間管理する型が分かる
- 第6章：意思決定ログと証拠管理の型 — 「合意の再燃」を防ぐ記録術が分かる
- 第7章：AI時代の仕様品質マネジメント運用モデル — 品質ゲートの運用設計が分かる
関連記事（シリーズ外）
SDD と組み合わせると効果が高い周辺トピックです。
- 人間はコードを書くな（Human-in-the-loop） — 人間がレビューに専念する境界線が分かる
- AI生成コードのテスト戦略 — 生成コードをどう検証するかが分かる
FAQ
Q. Chapter 1について教えてください。 A. 本記事ではChapter 1について詳しく解説しています。記事本文をご参照ください。
Q. Chapter 2について教えてください。 A. 本記事ではChapter 2について詳しく解説しています。記事本文をご参照ください。
Q. Chapter 3について教えてください。 A. 本記事ではChapter 3について詳しく解説しています。記事本文をご参照ください。
