AIエージェント開発の「新常識」SDD：チャット指示をやめて仕様書を書こう

TL;DR

• チャットベースの指示は「揮発性」が高く、大規模開発には向かない
• Spec（仕様書）を Source of Truth に据え、AI のコンテキストを固定する
• 人間は「コードを書く選手」から「仕様を承認する審判」へと役割を変える

このシリーズについて

AIエージェント（Copilot, Cursor, Gemini）とのペアプログラミングは楽しいですが、同時に**「指示が伝わらない」「勝手にコードを書き換えられる」**といったストレスも生みます。

「もっと賢いAIが来れば解決する」？ いいえ、問題はモデルの賢さではなく、**「指示の出し方（アーキテクチャ）」**にあります。 チャット欄に自然言語でお願いするスタイルから脱却し、Spec Driven Development (SDD) という新しい開発パラダイムへ移行しましょう。

SDD の 3 つのコア原則

1. Explicit Over Implicit: 暗黙的な了解を排し、すべてを Spec にマッピングする
2. File Over Chat: 会話ログではなく、構造化されたファイルを真実のソースとする
3. 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アーキテクチャにあります。 エージェントに振り回される日々は、今日で終わりにしましょう。

Related Series

• 第1章：なぜAIエージェントは「仕様書」を無視するのか？
• 第2章：時間軸で管理するSpec（Requirements/Design/Tasks）
• 第3章：人間はコードを書くな（Human-in-the-loop）
• AI開発の品質を支える運用モデル
• AI生成コードのテスト戦略