コンテンツにスキップ
Process Compass（プロセスコンパス）

仕様駆動開発(SDD, Spec-Driven Development)

既存プロセスの体系 ／ 種別: 実務プラクティス(開発者レベルの技法)

自然言語(主に Markdown)で書いた仕様書を AI コーディングエージェントへの唯一の信頼できる情報源として与え、AI がそこからコードを生成する開発手法。「vibe coding」への対抗概念として2025年に注目された

ひとことで言うと: 「先に仕様を文書で固め、AI にコードを書かせる」進め方。人間は仕様を書き・レビューし・承認する側に回り、AI が実装する。各段階に人間の承認ゲートを置くのが、場当たりAI生成(vibe coding)との決定的な違い

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["仕様定義(Specify / Requirements)"]
  ph1["計画・設計(Plan / Design)"]
  ph0 -->|"仕様承認"| ph1
  ph2["タスク分解(Tasks)"]
  ph1 -->|"設計承認"| ph2
  ph3["実装(Implement)"]
  ph2 -->|"タスク承認"| ph3
  ph4["検証(Verification / 反復)"]
  ph3 -->|"テスト承認(Spec Kit 憲法 Article III)"| ph4
  click ph0 "/process-compass/processes/sdd/specify/" "仕様定義(Specify / Requirements)の詳細へ"
  click ph1 "/process-compass/processes/sdd/plan/" "計画・設計(Plan / Design)の詳細へ"
  click ph2 "/process-compass/processes/sdd/tasks/" "タスク分解(Tasks)の詳細へ"
  click ph3 "/process-compass/processes/sdd/implement/" "実装(Implement)の詳細へ"
  click ph4 "/process-compass/processes/sdd/verify/" "検証(Verification / 反復)の詳細へ"

目的と成果

目的(purpose): 仕様を唯一の真実の源とし、AI に構造化された文脈を与えることで、場当たり的なプロンプトによる破綻を防ぎ、意図と実装の一貫性・検証可能性を確保する

成果(outcomes):

  • spec.md(要件)/ plan.md・design.md(計画・設計)/ tasks.md(実行可能タスク)という段階的成果物が積み上がる
  • それらから AI が生成した実装コードが得られる
  • 各成果物が次段階の構造化された入力になり、その場限りのプロンプトが永続的でレビュー可能な文書に置き換わる

原典: 単一の提唱者はいない。2025年の複数潮流。GitHub Spec Kit(Specify→Plan→Tasks→Implement)、AWS Kiro(requirements→design→tasks、EARS記法)、Sean Grove の講演「The New Code」が起点

ISO/IEC/IEEE 12207 対応: 主に「テクニカル(要件定義・設計を Markdown 成果物として明示化し、実装への機械翻訳の入力にする)」プロセス群をカバー

ロール

ロール責任日本の現場での実態
仕様の著者(人間)意図・要件・制約・成功基準を記述する。曖昧性を解消し仕様を確定させる。SDD では最も価値の高い活動多くは1人の開発者/PM が兼務。専任の仕様担当は稀
承認者(人間)各フェーズ成果物(仕様/設計/タスク/テスト)をレビューし次段階へ進める decision を下す仕様著者と同一人物が兼ねることが多く、セルフレビュー化して統制が形骸化するリスクがある
AI コーディングエージェント仕様→計画→タスク→コードの各変換を実行する。実装の主たる担い手Copilot / Claude / Gemini / Codex / Kiro など。Spec Kit は30以上のエージェントに対応
ステークホルダー(非技術者含む)仕様が自然言語 Markdown なので、非エンジニアもレビュー・貢献できる(建前)制度としては未成熟。実態は開発者主導

ゲート(決裁・レビュー)

ゲート種別Deliverables判定基準判定者判定結果
仕様承認 ※この人間 decision ゲートの有無が、vibe coding(ゲートなしの即時生成)との決定的違い決裁(Go/Kill)spec.md / requirements.md意図と要件が正確・完全か / 曖昧点が解消されたか人間(仕様著者/レビュア)承認 / 修正差し戻し
設計承認決裁(Go/Kill)plan.md / design.md技術選択の妥当性 / 憲法/steering との整合人間承認 / 差し戻し
タスク承認決裁(Go/Kill)tasks.md分解粒度・依存・網羅性が妥当か人間承認 / 差し戻し
テスト承認(Spec Kit 憲法 Article III) ※Kiro の Quick Plan は承認ゲートを外して一括自動生成する。つまりゲートは運用者が着脱でき、統制強度を決める設計変数になる決裁(Go/Kill)テストコードテストが要件を表現し、かつ失敗することを確認(実装はこの後)人間承認 / 差し戻し

成果物(information items)

成果物作成者説明
spec.md / requirements.mdAI コーディングエージェント何を作るか(ユーザーストーリー・受け入れ基準)。人間の意図を元に AI が生成し人間が承認する。Kiro は EARS 記法で記述
plan.md / design.mdAI コーディングエージェント技術選択・データモデル・API 契約・アーキテクチャ・シーケンス図。AI 生成・人間承認
tasks.mdAI コーディングエージェント依存順・並列マーク付きの実行可能タスク。AI 生成・人間承認
constitution.md / steering(プロジェクトの不変原則)仕様の著者(人間)プロジェクト全体の永続的な原則・規約(Spec Kit の憲法、Kiro の steering)。全フェーズの制約になる
実装コード+テストAI コーディングエージェント仕様の「射影」。真実は仕様側にある。修正はコードでなく仕様に立ち返って再生成するのが原則

アンチパターン(建前 vs 実態)

仕様の逆流(コード直接編集による陳腐化)

建前(あるべき姿)仕様が真実、コードは従属。修正は仕様に立ち返って再生成する
実態生成後にコードを直接いじって仕様と乖離させ、仕様が陳腐化する
なぜ起きるか目の前のコードを直す方が早く、仕様更新の習慣が根付かないため
弊害「仕様=真実」の前提が崩れ、SDD の一貫性・検証可能性が失われる

ゲートを飛ばして vibe coding 化

建前(あるべき姿)各フェーズの人間承認ゲートで意図と実装の一致を確認する
実態Kiro の Quick Plan のようにゲートを飛ばし、場当たり生成に戻る
なぜ起きるかゲートが着脱可能で、急ぐと外したくなるため
弊害SDD の統制力が消え、破綻を防ぐという目的そのものが失われる

独立した確認の空白

建前(あるべき姿)仕様・設計を独立した視点で検証する
実態仕様著者・承認者・実装レビュアが1人に集約されセルフレビュー化する
なぜ起きるか小規模・個人利用が多く、専任の承認者を置けないため
弊害ゲート判定者が仕様の書き手と同一だと統制が形骸化する

建前と実運用(日本の現場)

  • SDD の「フェーズごとの人間承認ゲート」は、日本企業の上流工程での多段レビュー・承認文化(要件定義書レビュー→設計レビュー)と構造的に親和しうる
  • 「人間=発注者/仕様の書き手、AI=受注者/実装者」という構図は、日本の SIer の要件定義書・外部設計書の文化(仕様書=発注仕様=検収基準)とそのまま接続しやすい。本プロジェクトの「AIが外注相当を担う」議論の参照実装になる
  • ゲートの着脱(Kiro Quick Plan)= チーム成熟度・機能の重要度に応じた「統制強度の可変設計」。「チーム体制・事業フェーズに合わせて最適プロセスを提案」に直接使える設計軸
  • 日本発 OSS の cc-sdd が登場(日本語仕様記述に最適化、12言語対応)。ツール未成熟・実装力の空洞化・仕様と実装の乖離が国内の実践課題として指摘されている

フェーズ一覧(第2階層へ)

参考文献