Spec-Driven Development (SDD)
AIは与えられた構造以上のものにはなりません。AI-SDDは曖昧なプロンプトを正確な仕様に変え、正確な仕様を動作するソフトウェアに変えます。
ソフトウェア開発方法論の進化
"ソフトウェアは高価で、遅く、人間の能力によって制限されていました。"
方法論は、人間の能力と複雑さを調整されたチームで管理する必要性から生まれました。
予測可能性と完全なドキュメント化に最適化
反復的な適応と継続的デリバリーに最適化
仕様を共有された真実の源として
AIが開発のボトルネックを変えた
人間がボトルネックでした。コードの一行一行に時間とお金がかかりました。方法論はそのコストを管理し、手戻りを最小限に抑え、チームを調整するために生まれました。
実行速度はもはや主要な制約ではありません。新しいボトルネックは意図の明確さ — AIを導く仕様の品質です。
「単なるプロンプト」ではスケールしない。
間違った問題を解決するコード
構造化された要件がなければ、AIはあなたが必要としているものではなく、あなたが望んでいると思うものを生成します。出力は本番環境に到達するまで正しく見えます。
意図の痕跡がない
生のAI出力には監査証跡がありません。6ヶ月後、誰もなぜその決定がなされたのかを知りません — コードが存在することだけがわかります。レビューは推測作業になります。
利益を打ち消す手戻りサイクル
方向性のないAIの加速は、より速く迷子になるだけです。チームはAIが節約した時間を、ずれた実装の修正に費やします。
修正コストは指数関数的に増加する
"30分の仕様レビュー = 30日の手戻りを防止。"
要件段階で検出された欠陥は、本番環境で発見された同じ欠陥よりも平均して100倍低コストです。明確な仕様はチームができる最良の投資です。
出典: IBM System Science Institute
スペック駆動開発：仕様を真実の源として
SDDでは、人間が意図を表現し、AIが仕様を生成します。コード、テスト、ドキュメント — すべてがそこから派生します。仕様は人間とAIの間の唯一のコントラクトであり、明確で、バージョン管理され、監査可能です。
仕様を唯一の真実の源として維持し、コード、テスト、ドキュメントはそこから派生する — 決して逆ではない。
Is SDD the True Parent of TDD, BDD, and DDD?
TDD、BDD、DDDは仕様が既に存在することを前提としています。SDDはそれらのどれも持っていない上流のレイヤーです。 — ai-sdd.com
三つの役割、一つのコントラクト
ディレクター
高レベルで意図とビジネスコンテキストを表現します。AIが残りを構造化し、人間は各フェーズをレビューして承認してから次に進みます。
コントラクト
バージョン管理されたテキストによる形式的な仕様。EARS形式の要件、アーキテクチャ設計、曖昧さのないアトミックなタスク。
エグゼキューター
人間の意図を構造化された仕様に変換します。コントラクトに沿ったコード、テスト、ドキュメントを生成します — 曖昧さはありません。
"AIがコントラクトを生成し、実行する。人間が意図を定義する。"
EARS (Easy Approach to Requirements Syntax)：高コストな曖昧さを排除する
「システムはユーザーが何か重要なことをしたときに通知を送信するべきである。」
5人の開発者 = 5つの異なる実装
- 「何か重要なこと」 — 具体的に何か？
- 通知の種類は？メール？プッシュ？SMS？
- 誰が受け取るのか？いつ期限切れになるのか？
WHEN 支払いシステムによって注文が確認された場合 AND 合計金額が50,000円を超える場合 THEN システムSHALL登録ユーザーに確認メールを送信する WITHIN 支払い確認から60秒以内。 WHERE ユーザーがメール通知を無効にしている場合、 システムSHALLモバイルアプリでプッシュ通知を送信する。
- 正確で測定可能なトリガー
- 必須の動作 (SHALL)
- 代替ケースがカバーされている
ステアリング：チーム全体の自動ガバナンス
product.md 製品ビジョン、ペルソナ、ビジネス目標、制約。AIが戦略的コンテキストを見失うことはありません。
tech.md 技術スタック、コードパターン、命名規則、セキュリティルール。
structure.md フォルダ構成、モジュール、責任境界、アーキテクチャパターン。
AIとのすべての会話がゼロから始まります。機能間の不整合、パターンの分岐、絶え間ない手戻り。
AIがすべてのセッションでプロジェクトコンテキストを読み込みます。一貫した決定、より少ないレビュー、首尾一貫したコード。
ステアリングはAIを汎用アシスタントから、製品、スタック、プロジェクトの規約に深い知識を持つチームのスペシャリストメンバーに変えます。
ステアリングから出荷まで
6つのフェーズ、それぞれにAIが進行する前の人間のチェックポイントがあります。
ステアリング
プロジェクト全体のコンテキストを確立：製品ビジョン、技術スタック、コード構造。AIエージェントは各タスクでこれを読み取ります — 何かを生成する前に。
仕様初期化
機能を自然言語で説明します。AIが構造化された仕様シェルを生成 — それを要件の出発点に洗練させます。
要件定義
AIが説明を正式なEARS要件に展開します。人間がレビューして承認してから次に進みます — これが最も重要なゲートです。
設計
AIが要件に沿った技術設計を生成します。アーキテクトがアーキテクチャの決定を検証します。設計が承認されるまでコードはありません。
タスク
設計は原子的でテスト可能な実装タスクに分解されます — 各タスクは特定の要件に追跡可能です。実装ロードマップ。
実装
AIがタスクごとに実装します。開発者がそれぞれをレビューします。検証は元の要件に対して実行されます — 単に「テストに合格するか」だけではありません。
高レベルで意図を説明する — 解決すべき問題とビジネスコンテキスト。
EARS形式で構造化された要件を生成 — 正確で、曖昧さがなく、検証可能。
要件をレビューして承認 — または進む前に調整を要求。
アーキテクチャ設計を提案 — コンポーネント、統合、文書化された技術的決定。
設計をレビューして承認 — 制約と製品ビジョンとの整合性を確保。
実装タスクをアトミック化 — 各タスクは要件に追跡可能で、受け入れ基準が定義されている。
バックログをレビューして承認 — 実行前にスコープ、優先順位、粒度を検証。
仕様タスクを実行し、TDDでテストを自動生成 — 承認された設計と要件に準拠したコード。
実装をレビューしてマージを承認 — デリバリー前の最終検証。
マージとデプロイを実行 — 元の意図が本番環境にデリバリーされ、エンドツーエンドで追跡可能。
"ソフトウェアは人間とAIが誤解し合うために失敗する。
— スペック駆動開発の中心テーゼ
AIはコントラクトを実行する — 意図を推測しない。"
SDDはAIにより多くの自律性を与えることではありません。AIがその全実行能力を人間の意図のために使用できるようにする、正確なコントラクトを作成することです。
