はじめに
今月から、SDD（Spec Driven Development）を導入しているプロジェクトに参画しました。
これまでにも、AIを使ったバイブコーディングの開発経験はありましたが、
SDDを使った案件は初めてで、開発の主役を「コード」から「仕様」に移す構造に
少々苦戦しました。
この記事では、わたしが一ヶ月で学んだことの備忘録として、次の基本情報を整理します。
- そもそもSDDとは何か
- 従来型開発との違い
- OpenSpec / Spec Kit / AI-DLC のアプローチ差
- 実際に触れて感じたメリット・デメリット
そもそもSDDとは何か
仕様を SSoT（Single Source of Truth） として運用し、
実装より先に仕様の合意を進める開発スタイルを、SDD（Spec Driven Development）と呼びます。
従来の開発では、仕様書は説明資料として扱われることが多く、
変更や改善の起点はコード側になりやすい傾向があります。
レビューやリリース判断も動くコード中心になりやすいため、
仕様更新は「後でまとめて直す作業」として後回しになりがちです。
さらに、緊急修正や小さな仕様追加がコード側で先行すると、
仕様へ反映するタイミングを失いやすく、
実装が進むほど仕様とコードの乖離が発生しやすくなります。
SDDではこの関係を逆転させて仕様をGitなどで管理し、
その仕様をSSoTに置きます。コードやテストは仕様に従う立場となり、
場合によっては、開発者が実行した生成ツールやAIエージェントが、
仕様をもとにAPIの型定義やテストのひな形を自動生成することもあります。
生成そのものが本質なのではなく、仕様を中心に据える構造そのものが本質です。
従来の開発との違い
まず、従来の開発の流れを図にするとこうなります。
なお、従来型の開発でもアジャイルやTDDのように反復は存在しますが、
その循環の中心はコードにあります。
変更や改善は主にコードを起点に行われ、仕様は参照資料の立場になりやすく、
変更が入ると、仕様書は後から修正されるか、修正されないままになることもある、
という構造です。
一方、SDDでは流れが次のように変わります。
SDDでは、仕様が一度きりの出発点ではなく、常に基準であり続けます。
実装や検証の結果は仕様にフィードバックされ、
更新された仕様が再び生成・実装の起点になります。
ここでの違いは「循環するかどうか」ではなく、循環の中心がどこにあるかです。
OpenSpec / Spec Kit / AI-DLC のアプローチ差
まず大前提として、この3つは厳密には同じレイヤーの比較対象ではありません。
- OpenSpec: 仕様差分を運用するためのフレームワーク
- Spec Kit: 仕様作成フローを定型化するためのツールキット
- AI-DLC: 開発ライフサイクル全体を定義する方法論
あえてこの3つを並べるのは、SDDそのものを学び始めた時期に、
有名どころとして最初に目にしたのがこの3つだったため、ここではその整理を目的にまとめています。
OpenSpec
これはどういうものか
OpenSpecは、specs（現行仕様）とchanges（提案差分）を分離して管理する、差分運用型のSDDフレームワークです。
1つの変更提案を1つのフォルダに閉じ込めるため、
次を同じ単位でレビューできます。
- なぜ必要か（
proposal.md） - 何を実装するか（
tasks.md） - 仕様がどう変わるか（
spec.md）
提案作成から /opsx:archive で本体仕様へ統合するまでを、1つのサイクルとして管理できます。
そのため、意思決定の履歴を後から追いやすいのが実務上の強みです。
主なディレクトリ構成
<project-root>/
└── openspec/ # OpenSpecの管理ルート
├── config.yaml # OpenSpecの設定ファイル
├── specs/ # 現在採用されている仕様（SSoT）
│ └── <domain>/spec.md # ドメインごとの本体仕様
└── changes/ # 変更提案ごとの作業領域
└── <change-name>/ # 1つの変更提案を表すフォルダ
├── proposal.md # 変更の背景・目的
├── design.md # 実装方針・設計内容
├── tasks.md # 実装タスクの一覧
└── specs/<domain>/spec.md # 本体仕様に対する差分仕様（delta）
向いているケース
既存システムを段階的に改善しながら、
変更ごとのレビュー単位を小さく保ちたい案件に向いています。
また、実装PRだけでなく仕様差分PRも残して後から判断理由を追跡したい場合や、
並行開発で提案フォルダ単位の衝突管理をしたい場合とも相性がよいです。
Spec Kit
これはどういうものか
Spec Kitは、仕様駆動開発の進め方を 原則定義 -> 要件化 -> 計画化 -> タスク化 -> 実装 という段取りに
固定するためのツールキットです。
各段階で作る成果物がテンプレート化されており、spec.md（要件）・plan.md（実装計画）・tasks.md（作業分解）を混ぜずに管理できます。
そのため、AIに実装を依頼するときも「どの文書を根拠に動くか」を明示しやすくなります。
主なディレクトリ構成
<project-root>/
├── .specify/ # 初期化時に作られるテンプレート群
│ ├── memory/constitution.md # プロジェクト原則（憲章）
│ ├── scripts/ # 補助スクリプト
│ ├── templates/ # 各成果物のテンプレート
│ └── specs/001-<feature>/spec.md # feature単位の仕様ドラフト
└── specs/001-<feature>/ # feature単位の作業ディレクトリ
├── spec.md # 要件仕様
├── plan.md # 実装計画
├── tasks.md # 実装タスク分解
├── research.md # 調査メモ
├── data-model.md # データモデル定義
├── quickstart.md # 実行手順
└── contracts/ # API等の契約定義
向いているケース
Spec Kitは、仕様作成の手順をチーム全体でそろえたいときに向いています。
要件・設計・タスクが混在してレビューが長引きやすい現場でも、
spec.md -> plan.md -> tasks.mdの順序を固定することで、議論の前提を合わせやすくなります。
特に、担当者や途中参加メンバーが多いプロジェクトで、
今どの段階の成果物を確認すべきかを明確にしたい場合に効果が出やすいです。
AI-DLC
これはどういうものか
AI-DLCは、AI活用前提で開発ライフサイクル全体を設計する方法論です。
大枠は「立ち上げ / 実装 / 運用」の3フェーズで整理し、
必要に応じて各フェーズ内に詳細な工程を置いて進めます。
人間承認ゲートを明確に置く点も特徴です。
大きなポイントは「適応深度（Adaptive Depth）」で、
変更の規模やリスクに応じて、
通すフェーズ範囲と成果物・承認ゲートの厳しさを調整します。
たとえば軽微な変更なら実装フェーズ中心で成果物を簡略化し、
影響範囲が広い変更では3フェーズを通して進める、といった運用が可能です。
適応深度のイメージは、ざっくり次のように考えると運用しやすいです。
- 深度小（軽微変更）: 実装フェーズを中心に進め、一部フェーズをスキップ
- 深度中（通常変更）: 立ち上げフェーズと実装フェーズを通して実装
- 深度大（高リスク変更）: 立ち上げ -> 実装 -> 運用 の3フェーズを通し、承認ゲートも厳密化
主なディレクトリ構成
<project-root>/
├── AGENTS.md または CLAUDE.md # エージェントに守らせるルールの入口
├── .aidlc-rule-details/ # AI-DLCの詳細ルール群
│ ├── common/ # 全フェーズ共通ルール
│ ├── inception/ # 立ち上げフェーズ用ルール
│ ├── construction/ # 実装フェーズ用ルール
│ └── operations/ # 運用フェーズ用ルール
└── aidlc-docs/ # 実行時に生成される成果物格納先
向いているケース
複数チームが関わる開発で、承認責任や監査証跡まで含めて設計したい場合に向いています。
また、小さな修正と大型改修が混在する現場で、適応深度に応じてフローを調整したい場合や、
実装だけでなく運用準備や引き継ぎまで標準化したい場合に適しています。
SSDに実際に触れて感じたメリット・デメリット
メリット
- 実装前に受け入れ条件まで合意できるため、実装後レビューで「要件の認識違い」が見つかる手戻りを減らせる
- 変更ごとに仕様差分が残るため、「いつ・なぜ・どこを変えたか」をPRと一緒に追跡しやすい
- レビュー単位を仕様差分とタスクで分けられるため、レビュアーが機能意図とコード品質を切り分けて確認しやすい
- 障害対応時に現行仕様と過去差分を参照して影響範囲を特定しやすく、調査の初動を短縮しやすい
デメリット
- 導入初期はテンプレート整備や合意プロセス設計にコストがかかる
- 運用後も仕様レビューと更新の継続コストが発生する
- 小さな改修でもドキュメント負荷が先に立つ
- 仕様中心のため、新規参画者のオンボーディングコストが高くなりやすい
まとめ
SDDは、コード生成のテクニックというより、
実装前に合意の解像度を上げるための運用設計だと感じています。
API契約、受け入れ条件、主要ユースケース、例外系まで先にそろえておくことで、
実装段階の手戻りと仕様乖離を抑えやすくなります。
また、OpenSpec / Spec Kit / AI-DLC は優劣で選ぶ対象ではなく、
何を標準化したいかで使い分けると整理しやすくなります。
仕様差分の運用単位を固めたいなら OpenSpec、仕様作成の手順を固めたいならSpec Kit、
承認ゲートを含むライフサイクル運用を固めたいなら AI-DLCという見方です。
一方で、仕様中心の開発は新規参画者にとって、
最初にドメイン知識と仕様構造を読む負荷が高くなりやすい点には注意が必要です。
ただし、仕様資産が多いぶん、AIによる要約や差分整理を併用すれば、
オンボーディングの負担を実務上かなり軽減できる可能性もあります。