アリババエンジニアリング、Spec-Driven Development で AI プログラミングを再定義

王砚舒（彦纾） 2026年9月4日 18:08 浙江

Spec-Driven Development（以下 SDD）について、本稿でいくつかの経験と考察を共有します。

これは 2026 年第 58 回の記事です。

（本文の読了時間：約 20 分）

序章：「5 人 7 日」実験

本稿では、ある具体的な事例を紹介します。5 人のチームが 7 日間をかけて Qoder を活用し「QoderWork」を開発しました。従来であれば 20 人が数週間を要する作業量を、わずか 1 週間で完了させたのです。

このプロジェクトのタイムラインは、毎日振り返る価値があります。

DAY 0：コードは一行も書かず、仕様（Spec）のみを作成。

チームは丸一日をかけて以下の 4 つの作業に集中しました。MVP の範囲を定義し、モジュールを分解し、各モジュールごとの仕様書を作成し、それらを Repo Wiki に集約するのです。この日の成果物はゼロ行のコードですが、その後の 6 日間を決定づける重要な役割を果たしました。

DAY 1-2：Qoder を活用したアーキテクチャ開発。

フレームワークとコンテナは並行して開発されました。チームメンバー全員が「仕様エンジニア」として振る舞い、「コードがどのようなものであるか」を定義します。Skill（スキル）によって並進を推進し、Quest モードで複数の開発タスクを同時に実行しました。わずか 2 日で、システムの骨格が完成したのです。

DAY 3-4：仕様の反復によるインクリメンタルな要件追加。

新たな要件やバグが見つかった場合でも、従来のようにスケジュールを組む必要はありません。その場で増分仕様（incremental Spec）を作成し、Quest に実行を委ねます。AI が自動的にコードを書き、PR を提出します。人間はレビューとマージを担当するだけでよく、1 人で 1 日に複数の PR を処理できるため、効率が劇的に向上しました。

DAY 5-6：磨き上げと Dogfooding（社内利用）。

QoderWork の初期バージョンで QoderWork 自体をテストします。問題が見つかったら仕様書を作成し、Quest が修正を行います。これは自己増殖する正のフィードバックループです。

DAY 7：正式リリース。

7 日間で、ゼロから利用可能な製品が生まれました。

この事例が驚異的な理由は、「AI がコードを書くのが速い」からではありません。速度は単なる表象に過ぎません。真に問われるべきは、なぜ 5 人のチームが AI を駆使してこれほど多くの並行タスクを同時に進めながら、制御不能にならなかったのかという点です。

その答えは DAY 0 にあります。「何もしていない」ように見えるその日に、チームが書き記した仕様こそが、プロジェクト全体のアンカー（錨）となったのです。この手法には正式名称があり、「Spec-Driven Development（SDD）」と呼ばれます。

01 SDD とは：コードは仕様の副産物に過ぎない

#### 1.1 一言で定義する

Spec-Driven Development（SDD）とは、仕様書（Specification）を唯一の真実源（Single Source of Truth）とし、コードはその派生物として扱う開発手法です。

より平易な言葉で言えば、「WHAT（何を）」を先に定義し、AI に「HOW（どのように）」を実行させるのです。

API フォーカス開発、契約による設計（Design by Contract）、あるいは厳格な TDD に取り組んだ経験があれば、SDD（Spec-Driven Development）は懐かしい響きに聞こえるかもしれません。しかし、SDD の本質的な違いは、これが AI によるプログラミング時代のために特別に設計されたエンジニアリング手法である点にあります。

従来の開発において、仕様書（Spec）の良し悪しは主にコミュニケーションの効率に影響します。一方、AI プログラミングの時代においては、仕様の質がそのままコードの品質を決定づけます。なぜなら AI は「この境界ケースはどう処理すべきか」といった問いかけをしてくることはなく、与えられた文脈に基づいて最大限に推論するだけだからです。推論が当たればそれは幸運ですが、外れればバグとなります。

1.2 一人の発明家ではなく、一つの時代の集約

SDD に単一の発明者はいません。2025 年、複数の方向性がこの理念へと収束しました。

• Karpathy が提唱した「Vibe Coding（2025 年 2 月 2 日）」は反面教師として機能し、「コードを無視してビブス（雰囲気）だけを追う」ことの致命的な欠陥を露呈させ、コミュニティに「AI プログラミングにはどのような制約が必要か」を考えさせるきっかけとなりました。
• GitHub は Spec Kit を発表し、特定のエージェントに依存しない SDD ツールチェーンを提供しました。
• AWS は Kiro をリリースし、SDD ワークフローが組み込まれた最初の IDE となりました。
• Fission-AI の OpenSpec は、軽量な反復開発の道筋を示しました。
• アリババの QoderWork は、Qoder Quest モードを通じて SDD の大規模実行を実践しました。

このように複数のプレイヤーが同時に動き出した状況は、SDD が AI プログラミングの発展段階において構造的に必要とされていることを示しています。

1.3 Microsoft の鋭い指摘

Microsoft は SDD について以下のように精髄を突いた評価を下しています。

「SDD is version control for your thinking.」

従来のバージョン管理はコードの変遷履歴を管理するものですが、SDD が管理するのは思考の変遷履歴です。なぜこの機能を実装するのか、境界はどこにあるのか、成功の基準は何なのか——これらです。AI によって数秒でコードが書き換えられる時代において、真に価値があるのはコードそのものではなく、その背後にある意思決定です。

02

SDD の完全なプロセス分解

2.1 4 つの段階モデル

SDD の標準的なフローは以下の 4 つの段階に分かれます。

Specify（仕様定義）→ Plan（計画策定）→ Implement（実装）→ Validate（検証確認）

• 段階：主導者 / 主要成果物 / 重要なアクション
• Specify：人間 / spec.md / 問題定義、境界設定、成功基準の明確化
• Plan：人間 + AI / plan.md / アーキテクチャ選定、モジュール分割、インターフェース定義
• Implement：AI / コードとテスト / plan に基づきタスクごとに実装
• Validate：人間 + AI / テストレポート / 自動化されたテスト実行と人的レビュー

このプロセスにおける人間と AI の役割分担の核心原則は、「人間が WHAT（何を）を定義し、AI が HOW（どのように）を実行する」ことです。

実際の運用では、Specify と Plan の間には複数回の反復が行われ、Implement と Validate の間にも継続的な循環が発生します。

2.2 3 ファイル体系：Spec Kit の核心設計

GitHub の Spec Kit は、シンプルかつ効果的な 3 つのファイルからなる体系を提案しています。

spec.md —— 要求仕様書

これは「唯一の真実（Single Source of Truth）」です。ここでは「何を」「なぜ」行うのかを定義し、「どのように」行うかについては一切触れません。

Feature: ユーザー権限管理モジュール

課題の定義

現状のシステムでは、細粒度の権限制御が不足しています。ユーザーは「管理者（全権限）」か「一般ユーザー（読み取り専用）」かの二択しかなく、部門ごとの多様なニーズに対応できていません。製品チームは、最低でも 5 つの役割を定義できる仕組みを必要としています。

成功指標

• カスタムロールの作成が可能で、各ロールに 20 種類以上の独立した権限を設定できること
• 権限検証 API の P95 レスポンスタイムが 50ms 未満であること
• 権限変更は即時反映され、ユーザーの再ログインを不要とすること
• 既存の管理者・一般ユーザーの振る舞いを維持する後方互換性の確保

ユーザーストーリー

1. システム管理者として、カスタムロールを作成し、必要な権限を組み合わせて割り当てることができる。
2. 部門主管として、所属メンバーをまとめて特定のロールに割り当てることができる。
3. 一般ユーザーとして、権限変更が即座に反映され、再ログインの手間がかからない。

受入基準

• [ ] RBAC モデルで役割の継承（最大 3 レベル）をサポートする
• [ ] 1 ユーザーが複数のロールを保持でき、権限はそれらの和集合として適用される
• [ ] 権限変更の監査ログを提供し、90 日間保存する
• [ ] 権限検証でワイルドカードマッチング（例：resource:*:read）に対応する

対象外項目

• 本スコープでは組織横断的な権限委任は実装しない
• 時間帯に依存した一時的な権限のサポートはない
• UI レベルでの権限管理画面は提供せず、フロントエンドチームが別途仕様（Spec）を作成する

制約条件

• 既存の OAuth2.0 認証フローとの完全な互換性を維持すること
• 権限データは既存の PostgreSQL インスタンスに保存し、新規ストレージコンポーネントを導入しないこと
• 権限モデルの設計は AWS IAM Policy の構文規範を参照すること

この仕様（Spec）には、以下の重要な特徴があります。

成功基準は明確でテスト可能です。「システムが速い」といった曖昧な表現ではなく、「P95 < 50ms」という定量的な数値で定義されています。

「非目標（Non-Goals）」は境界を明確に定義し、AI に「これらは行わないでほしい」と指示します。

一方、「制約条件（Constraints）」は技術選定を縛り、AI が独断で新たなコンポーネントを導入するのを防ぎます。

plan.md —— 建築設計案

これは spec.md をもとに生成された技術的な解決策です。通常、このステップの草案作成は AI が行い、人間がその内容を審査・修正します。

Plan: ユーザー権限管理モジュール

アーキテクチャ意思決定

RBAC（Role-Based Access Control）モデルを採用し、権限エンジンには Casbin を使用します。

モジュール構成

1. permission-model - 権限モデルの定義と Casbin へのアダプター層
2. permission-api - RESTful API レイヤー

1. permission-cache - Redis キャッシュ層（P95 レイテンシ 50ms 未満の要件を満たす）
2. permission-audit - 監査ログモジュール

インターフェース契約

POST /api/v1/roles

GET /api/v1/users/{userId}/permissions

PUT /api/v1/roles/{roleId}/permissions

（API の詳細定義は省略）

リスク評価

• リスク: 役割の継承階層が深すぎると、権限計算のパフォーマンスが低下する可能性があります。
• 緩和策: 最大継承深度を 3 レベルに制限し、権限結果は事前計算してキャッシュします。

tasks.md（タスクリスト）

計画を実行可能な原子レベルのタスクに分解し、各タスクには独立して検証できる成果物が対応付けられます。

タスク

タスク 1: データベーススキーマ設計

• roles、permissions、role_permissions、user_roles の 4 つのテーブルを作成する
• 役割の継承をサポートする parent_role_id フィールドを追加する
• 検証：空のデータベース上で migration スクリプトが正常に実行されることを確認する

タスク 2: Casbin 適応層の実装

• RBAC モデルに対応した Casbin の設定を実装する
• ワイルドカードマッチングをサポートする
• 検証：ユニットテストのカバレッジを 90% 以上に引き上げる

タスク 3: 権限検証 API の実装

• GET /api/v1/users/{userId}/permissions エンドポイントを実装する
• Redis キャッシュを統合する
• 検証：負荷試験で P95 レイテンシが 50ms を下回ることを確認する

（以降のタスクは省略）

2.3 constitution.md：プロジェクトの不変原則

三ファイル体系に加えて、Spec Kit は「constitution.md」という重要な概念を導入しています。これはプロジェクトレベルの「憲法」であり、絶対に守らなければならない制約条件を定義します。すべての Spec はこれに従わなければなりません。

プロジェクト憲法（Project Constitution）

不変原則

1. API デザイン

• すべての API は RESTful 規範に則り、バージョン化されたパス（/api/v1/...）を使用する
• エラー応答は RFC 7807 Problem Details フォーマットで統一する
• すべての API には OpenAPI 3.0 ドキュメントを必ず用意する

2. セキュリティ

• すべてのユーザー入力は検証とクリーニングを経る必要がある
• 機密データ（パスワード、トークン）はログに出力してはならない
• データベースクエリはパラメータ化されたクエリを使用し、文字列の連結を禁止する

3. コード品質

• ユニットテストのカバレッジは 80% 以上を保つ
• すべての公開メソッドにはドキュメントコメントを付与する
• セキュリティ監査を受けていないサードパーティ製ライブラリの導入を禁止する

4. インフラストラクチャ

• すべてのサービスはグレースフルシャットダウン（Graceful Shutdown）をサポートする必要がある
• 設定項目は環境変数から注入し、ハードコーディングを禁止する
• ログフォーマットは構造化 JSON に統一する

constitution.md の価値は、チームの技術判断を AI の「暗黙知」として固定化できる点にあります。これがないと、各 Spec で「パラメータ化クエリを使う」「ユニットテストを書く」といった基本的な制約を毎回記述する必要が出てしまいます。

03

Spec の書き方：良質な Spec と不十分な Spec を分ける生死線

Spec の作成は、SDD（仕様駆動開発）において最も重要でありながら、もっとも過小評価されがちな工程です。この事実は経験則によって裏付けられています。DAY 0 に整整と一日を費やして Spec を書くのは、その品質が DAY 1 から DAY 6 の作業効率を直接決定づけるからです。

#### 3.1 良質な Spec の 6 つの要素

• 要素：役割 / 具体例
• Problem Statement（問題定義）：「なぜ行うのか」を定義する / 「現在のシステムでは、細粒度な権限制御がサポートされていない」
• Success Metrics（成功指標）：「どこまで達成すれば完了とみなすか」を定義する / "P95 < 50ms"、20 種類以上の権限タイプをカバー
• User Stories（ユーザーストーリー）：「誰が、どのような場面で利用するのか」を定義する / 「管理者として、カスタムロールを作成できること」
• Acceptance Criteria（受入基準）：「どのように検証するか」を定義する / 「単一ユーザーに複数のロールを付与した場合、権限は並列集合となる」
• Non-Goals（非目標）：「何を行わないか」を定義する / 「今期は組織間での権限委任機能は実装しない」
• Constraints（制約条件）：「技術的な制約」を定義する / 「既存の OAuth2.0 フローとの互換性を維持しなければならない」

#### 3.2 良質な Spec と不十分な Spec：対比

不十分な Spec の例：

システムには高速な検索機能が必要である。検索結果は関連性が高く、正確でなければならない。

UI は美しく、使いやすいものであるべきだ。

この Spec には、致命的な問題が 4 つあります：

1. 曖昧さ：「高速」とは具体的にどの程度の速度を指すのか？100 ミリ秒か、それとも 1 秒や 10 秒なのか。

1. 境界の欠落：何を検索対象とするべきか。全文を対象にするのか、タイトルだけなのか、模糊的な一致（ファジーマッチ）もサポートするのか。

1. 理由の不在：なぜこの検索機能が必要なのか。どのような課題を解決するためのものなのか。

1. HOW の混入：「UI は美しくあるべし」という要件は UI の仕様書に記述すべきものであり、バックエンド機能の仕様には含めるべきではありません。

優れた Spec の例：

Problem Statement（問題定義）

ユーザーフィードバックによると、10,000 件以上のドキュメントが蓄積されたナレッジベース内で目的のドキュメントを見つけるまでの平均時間は 3 分かかる。この検索時間を 10 秒以内へ短縮することを目標とする。

Success Metrics（成功指標）

• 検索 API の応答時間 P95 が 200 ミリ秒未満であること
• 検索結果の上位 5 件の関連性精度が 85% を超えること（人手によるラベル付け済みテストセットに基づく）
• 中国語と英語の混合クエリに対応すること

Non-Goals（対象外事項）

• 意味論的検索の実装は行わない（今期はキーワードマッチングと分かち書きのみとする）
• ドキュメント添付ファイルの中身を検索対象としない（ドキュメントタイトルと本文のみを対象とする）

本質的な違い：優れた Spec は「テスト可能」であり、劣った Spec は「解釈の余地がある」ものです。

「システムは高速であるべき」という記述は AI に対して無限の解釈空間を与えてしまいます。AI は「自分にとって十分速い」実装を選択する可能性があります。一方、「P95 < 200ms」という数値目標は明確なハード制約です。AI はこの指標を満たす実装を確実に行わなければならず、そうでなければ失敗とみなされます。

3.3 粒度の制御：実用的な検証基準

Spec の粒度を適切に調整するのは容易ではありません。粗すぎると AI が詳細部分を勝手に補ってしまい、細かすぎると本質的に「疑似コード」を書いていることになり、SDD（仕様駆動開発）の意味が失われます。

Spec Kit では、この課題に対する洗練された検証基準を提案しています。

「異なる技術スタックを用いてこの Spec を実装した場合、その Spec は依然として有効か？」

もし Spec に「Redis の ZSET 構造を使用してランキングデータを保存する」と記述されていれば、それは Redis 方案にしか通用しません。PostgreSQL で実装すれば仕様は破綻してしまいます。これは「HOW（手段）」を「WHAT（目的）」の中に混入させている典型的な例です。

もし仕様書に「ランキング機能はリアルタイム更新に対応し、遅延は 1 秒以内とする。Top-100 のクエリもサポートする」と明記されていれば、基盤として Redis を使うか PostgreSQL か、あるいは独自開発のストレージを採用するかに関わらず、その仕様の要件は満たされます。これが正しい粒度です。

もちろん、制約（Constraints）セクションには技術的な制限事項を記載することは可能です。ただし、それは「既存の PostgreSQL インスタンスを使用しなければならない」といった外部からの制約であり、「実装方案」そのものではありません。

3.4 淘特チームの実践経験

SDD（仕様駆動開発）を実践する淘特チームは、重要な法則を発見しました。それは、仕様の作成には合格に至るまで 3〜5 回の反復が必要だということです。

最初のバージョンの仕様書には往々にして問題が山積みです。例えば、境界条件の漏れや成功基準の曖昧さ、あるいは「非目標（Non-Goals）」の定義不足などが挙げられます。AI に最初の仕様に基づいて計画（plan）を作成させた後、改めて仕様を見直すと、多くの盲点が浮き彫りになります。「仕様→計画→仕様の見直し→修正→再計画」というサイクルは通常 3〜5 回繰り返されます。

これは、従来の開発手法で「開発の半ばになって要件に問題があることに気づく」リスクを、コストが最も低い段階へ前倒ししたものです。1 行の仕様書を変更するコストは、100 行ものコードを書き換えるコストよりも遥かに低いです。

04

ツールエコシステムの全体像

SDD は急速に成長するツールエコシステムを形成しており、主要なツールの比較は以下の通りです。

• 項目：Spec Kit (GitHub) / OpenSpec (Fission-AI) / Kiro (AWS) / QoderWork (アリババ)
• 位置づけ：Agent-agnostic フレームワーク / 軽量な反復ツール / SDD ネイティブ IDE / Qoder Quest 実行エンジン
• Agent サポート：8 つ以上の Agent / 25 以上のツール / 内蔵 Agent / Qoder エコシステム
• 核心機能：3 ファイル体系＋憲章（constitution） / 軽量で高速な反復 / 完全な IDE 統合 / 仕様と Quest の並列実行
• 適用シーン：汎用プロジェクト

小型かつ迅速な反復開発

AWS エコシステムでのプロジェクト

アリババ・エコシステムでのプロジェクト

学習曲線は緩やか

低

中

中（Quest の理解が必要）

核となる理念：Spec はドキュメントである

Spec は対話の基盤である

Spec はワークフローそのものである

Spec はタスク管理票である

4.1 各ツールの使い分けガイド

汎用性を求めるなら「Spec Kit」がおすすめ。特定の Agent に縛られず、Claude、GPT、Gemini など主要なモデルを柔軟にサポートします。3 つのファイルで構成される体系は明確で理解しやすく、43.7k のスター数はコミュニティからの高い評価を示しています。

軽量さとスピードを重視するなら「OpenSpec」を選びましょう。「Spec は一度に完璧である必要はなく、対話の中で徐々に洗練させていけばよい」という考え方が根底にあります。小規模プロジェクトには特に適しています。

AWS エコシステム内での開発なら、「Kiro」が最も手間がかかりません。SDD（Spec-Driven Development）のワークフローは IDE に直接組み込まれており、独自のツールチェーンを構築する必要がありません。

QoderWork の「Quest」モードこそが、SDD を実行する最適なエンジンです。「5 人 7 日」で 20 人の開発規模を完遂した事例がその証明です。Spec を記述し、それを Quest に委ねるだけで、AI が自動的にコードを書き、PR を作成し、テストを実行します。

05

実戦データ：成功と失敗の両方を可視化する

5.1 成功事例における確かな数値

API 変更の効率化

ある arXiv の論文は、金融分野での SDD 実践を記録しています。その結果、API 変更にかかる期間が 75% 短縮されました。これは、API の Spec がインターフェース契約、エラーコード、データ形式などを完全に定義しているため、AI が Spec に準拠したコードを直接生成できるからです。これにより、膨大なコミュニケーションコストや手戻りが不要となりました。

コードのバグ率低下

研究データによると、人間が Spec を精査・改良することで、LLM によるコードの誤りを 50% も削減できます。これは、優れた Spec が AI の「推測余地」を排除した結果です。バグの多くは、AI が曖昧な要件を誤って解釈したことに起因します。

Stripe の大規模実践

Stripe は「Harness Engineering」という手法（SDD をその重要な一部として採用）を用いて、1300 件の AI 生成 PR をリリースしました。この数字が示すのは「制御可能性」です。1300 件もの PR がシステム全体に悪影響を与えることなく完了したことは、Spec の制約下にある AI プログラミングが大規模化可能であることを意味します。

5.2 失敗事例から得られる教訓

Spec による制約がない場合のセキュリティ災害

Veracode の 2025 年レポートによれば、AI が生成したコードの 45% にセキュリティ上の脆弱性が含まれています。ただしこれは「Spec による制約がない状態」でのデータです。一方、Spec 内に「パラメータ化クエリを使用すること」「機密データをログに出力しないこと」といった明確なセキュリティ制約を定義しておけば、脆弱性の発生率は劇的に低下します。

この 45% という数字と、前述の「バグが 50% 減少する」というデータは鮮明な対比を生んでいます。

• シナリオ：重要指標
• Spec 制約なしの AI プログラミング：コードの 45% にセキュリティ脆弱性が存在
• Spec 制約ありの AI プログラミング：コードの誤りが 50% 減少

コード重複率という見えないコスト

GitClear が 2.11 億行に及ぶコードを対象に行った調査では、AI プログラミング時代においてコードの重複率が過去 4 年間で 4 倍に増加したことが明らかになりました。これは当然の結果です。AI は学習データに含まれる類似パターンを「コピー＆ペースト」する傾向があるためです。SDD では、constitution.md におけるコーディング規約や plan.md でのモジュール設計によってこの問題をある程度緩和できますが、完全には解消できません。

06

SDD と Vibe Coding：正面から向き合うべき議論

6.1 Vibe Coding とは何か

2025 年 2 月 2 日、アンドレイ・カルパティ（Andrej Karpathy）がソーシャルメディアで「Vibe Coding」という概念を提唱しました。

"Forget that the code even exists."（コードの存在など忘れるのだ。）

Vibe Coding の核心は、コードを読んだり理解したりする必要はないという主張です。自然言語で何を望むかを記述し、AI にすべてを任せるのです。エラーが発生すれば、そのエラーメッセージを AI へ投げつけて、自身で修正させるだけです。

一見すると魅力的に思えるかもしれません。確かに、迅速なプロトタイプ検証や個人用のツールスクリプト、あるいは一度きりのデータ処理タスクといった特定のシナリオでは、このアプローチは有効です。

しかし、根本的な問題は持続可能性にあります。

6.2「3 ヶ月目の壁」：Vibe Coding の死活問題

コミュニティでは、「3 ヶ月目の壁」と呼ばれる反復出現するパターンが観察されています。その推移は以下の通りです。

• 段階：期間 / 状態 / 典型的な反応
• 興奮期：1〜3 ヶ月 / 高生産性 / "AI は素晴らしい！機能一つが一日で完成する！"
• プラトー（停滞）：4〜9 ヶ月 / 停滞 / "なぜ新機能が既存機能を壊すのか？"
• 衰退期：10〜15 ヶ月 / 崩壊 / "このコードは誰もメンテナンスできない。書き直したほうがマシだ"

なぜ壁にぶつかるのでしょうか。それは Vibe Coding が本質的に「文脈なしのプログラミング」だからです。

プロジェクトが数百行のコードに留まっているうちは、AI は全貌を把握でき、その推論や予測は概ね正確に機能します。しかし、プロジェクトが数万件のコード、数十のモジュール、数百のインターフェースへと肥大化すると、AI のコンテキストウィンドウ（記憶容量）には全てのコードを収めきれなくなります。結果として、AI は局所的な情報に基づいて判断を下すようになりますが、その判断は他のモジュールと衝突することが多々あります。

SDD（Spec-Driven Development）の Spec（仕様書）はこの問題を解決します。Spec はコードの圧縮表現です。10 万行に及ぶプロジェクトでも、それを記述する Spec システムは数千行のテキストで収まる可能性があります。AI は全ての Spec を容易に読み込み、グローバルな制約を理解した上でコード変更を実行できます。

6.3 核心的な違い：比較対照

• 次元：Vibe Coding / SDD
• 核心となる仮定：AI はあなたの意図を理解できる / AI は正確に実行するために明確な仕様を必要とする
• 起動速度：極めて速い / 遅め（まず Spec を記述する必要がある）
• 保守性：悪い（ドキュメントも制約もない） / 良い（Spec がそのままドキュメントとなる）
• 協働性：悪い（"Vibe" の感覚は作者しか知らない） / 良い（Spec は共有言語となる）
• セキュリティ：悪い（セキュリティ脆弱性の 45% が発生） / 比較的良好（Spec がセキュリティの境界を制約する）
• 適用規模：小規模プロジェクト（< 1000 行） / 中〜大規模プロジェクト
• 天井（限界）："3 ヶ月目の壁" / Spec システムの品質に依存

6.4 私の判断：二者択一ではない

Vibe Coding と SDD は、ある連続体の両端にあるものです。アイデアを検証するための週末プロジェクトであれば、Spec を書くのはオーバエンジニアリング（過剰設計）です。しかし、長期的にメンテナンスが必要な本番システムにおいては、Vibe Coding は慢性自殺行為と言えます。

より現実的な選択肢は、ハイブリッド戦略を採用することです。

1. 探索段階では Vibe Coding を活用：迅速な試行錯誤を行い、実現可能性を検証する。
2. 開発決定と同時に Spec を記述：探索段階で見つけた知見を仕様として固定化する。
3. 正式な開発フェーズでは厳格に SDD を適用：すべての変更はまず Spec を更新し、その後コードを変更する。

私が実践しているアプローチもこの戦略のバリエーションです。DAY 0 に Spec を記述する前には、チームはすでに QoderWork のプロダクト形態について十分な探索と議論を行っており（これはより早期の Vibe 段階に該当）、しかし実際に着手することを決定した瞬間に、すぐに Spec-Driven モードへ切り替えます。

7. SDD と Harness Engineering の関係

AI を用いたプログラミング手法の進化には、明確な三段階の連鎖が存在します。

Prompt Engineering → Context Engineering → Harness Engineering

• Prompt Engineering："どのようにすれば効果的な指示（プロンプト）を書けるか"に焦点を当てます。
• Context Engineering："AI に如何にして十分かつ正確な文脈を提供するか"に焦点を当てます。
• Harness Engineering："AI を制約し、駆動するための体系的なフレームワークをどう構築するか"に焦点を当てます。

SDD は、この Context Engineering と Harness Engineering が交差する領域に位置しています。

コンテキストエンジニアリングの観点から見れば、Spec（仕様書）とは、AI にすべてのコードを投げつける（ノイズが多すぎる）わけでも、単に一言で指示する（曖昧すぎる）わけでもない、極めて構造化された文脈提供手段です。適切な情報密度を提供することで、AI の理解と実行を支援します。

ハーネスエンジニアリングの観点からは、SDD（仕様駆動開発）は HE（ハーネスエンジニアリング）の重要な応用モデルと言えます。constitution.md が制約層、spec.md が要求層、plan.md が実行層、そして tasks.md がスケジューリング層を担います。これら 4 つのレイヤーが組み合わさることで、「AI を操るための完全なフレームワーク（ハーネス）」が構築されます。

Stripe が 1300 件の AI 生成 PR を実装した事例は、HE の手法を体現する典型例です。その中で SDD は「各 PR に明確な仕様と验收基準を設ける」ための不可欠なコンポーネントとして機能しました。

五大の罠と限界：SDD の影に目を向ける

SDD を導入する前に、以下の 5 つの罠を正直に直視する必要があります。

罠その一：過剰な仕様化（Over-Specification）

症状： Spec がコードよりも長くなり、実装の詳細まで細かく規定されてしまう状態です。

結果： 本質的に「自然言語による疑似コードの記述」に退化し、「人間が WHAT を定義し、AI が HOW を実現する」という SDD の核心的な利点を完全に失います。

対策： 前述した粒度のチェック基準を用いてください。「技術スタックを変えても、この Spec は有効か？」という問いに対して「いいえ」と答えられる場合、それは Spec に HOW（実装方法）が混入している証拠です。

罠その二：仕様の腐敗（Spec Rot）

症状： コードはすでに十数バージョンにわたって更新されているのに、Spec は V1 のまま更新されていない状態です。

結果： Spec とコードの間に乖離が生じ、新人が Spec を読む場合とコードを読む場合で理解するシステムが別物になってしまいます。AI による増分開発を行う際、古い Spec に基づいて生成されたコードは既存のコードと必ず衝突します。

対策： チームの実践から学ぶべき点があります。DAY 3-4 で示されたように、「要件の変更やバグ発見があれば、即座に増分の Spec を記述する」ことが重要です。Spec の更新は、コード変更と同期した日常業務の一部として位置づける必要があります。

罠その三：仕様の官僚化（Spec Bureaucracy）

症状： ボタンの色を変えるような些細な変更であっても、「Spec 作成 → Spec 審査 → Plan の更新 → Tasks の生成」という完全なフローを踏まなければならない状態です。

結果： チームは Spec フローを迂回して直接コードを変更するようになり、SDD は形骸化します。

対策： 大規模な変更と微小な変更を区別してください。すべての変更で完全な Spec プロセスが必要なのではありません。「他のモジュールの動作に影響を与える可能性があるか」が判断基準です。もし影響があるなら Spec が必要です。一方、純粋な局所的な修正（テキストの変更やスタイル調整など）であれば、直接コードを変更すれば十分です。

罠その四：偽りの自信（False Confidence）

症状： 詳細な Spec が存在するため、チームが AI 生成コードのレビューを怠ってしまう状態です。

結果： Spec は「何を行うか」のみを定義するものであり、AI の実装が正しいか、安全か、効率的かを保証するものではありません。45% というセキュリティ脆弱性のデータは、Spec があっても AI 生成コードには厳格なレビューが必要であることを示唆しています。

対策： Spec は要件定義書の代わりにはなりますが、Code Review（コードレビュー）の代わりにはなりません。SDD の Validate 段階こそが、このプロセスにおいて最後かつ最も重要な安全網です。

罠その五：ツールの複雑化（Tool Overhead）

症状： 「SDD を正しく行う」ために、Spec Kit、Kiro、CI/CD 統合、カスタム検証スクリプト、Spec Linter など、多数のツールを導入してしまう状態です。

結果： ツールチェーン自体が重荷となり、チームは Spec を書く時間よりもツールの設定に費やす時間が多くなってしまいます。

対策： 最もシンプルな方案から始めましょう。spec.md ファイル一つと、すでに使用している AI エージェントがあれば十分です。「SDD のため」に SDD を行う必要はありません。

「SDD は Markdown 版のウォーターフォールモデル」という批判への正面回答

これは SDD が直面する最も鋭い批判の一つであり、真剣に取り組む価値があります。

批判者の論理は、SDD が「まず仕様書を書き終えてからコードを書く」と要求するため、本質的にウォーターフォールモデルの再来だと主張するものです。つまり、要件を完全に定義した後に線形的に実装を進めるという、敏捷開発運動によってすでに否定された手法が、単に名前を変えただけではないかという指摘です。

私の見解はこうです。「批判には半分だけ理があるが、結論は誤りである」。

「半分だけ理がある」というのは、もし SDD を「2 週間かけて巨大な仕様書を作成し、それを一度も変えずに実行する」という形で実践した場合、確かにウォーターフォールモデルの焼き直しになり、失敗するのは必然だからです。

しかし、「結論は誤り」である理由は、SDD における仕様書（Spec）は生きた文書であり、死んだ文書ではないからです。チームが DAY 3-4 で示した事例が最も良い反証となります。仕様書は随時、増分的に更新される生きたドキュメントです。新しい要件が見つかったら、その分だけ仕様に追加します。バグが発見されれば、制約条件として補足します。これはむしろ「継続的な要件の精緻化」に近いアプローチです。

より本質的な違いは、イテレーション（反復）の粒度にあります。

ウォーターフォールモデルにおけるイテレーションの粒度はプロジェクト全体です（要件定義完了 → 開発完了 → テスト完了）。

一方、SDD のイテレーションの粒度は単一の機能モジュールです。つまり、「一つのモジュールの仕様 → そのモジュールの計画 → そのモジュールの実装 → そのモジュールの検証」というサイクルを回し、次のモジュールへ進むというものです。

SDD は実質的に「仕様のレベルでの反復」に近く、各仕様書が最小限の納品単位となります。書き終えたら実行し、実行したら検証し、検証が終われば次へと進みます。これはアジャイル開発のスプリント（Sprint）の理念と矛盾せず、単にユーザーストーリーをより構造化された仕様書へ升级させたものに過ぎません。

「ウォーターフォール論」への反証となるもう一つの事実は、SDD における仕様の平均寿命が、従来のウォーターフォールモデルにおける要件定義書の寿命よりもはるかに短いという点です。ある仕様書が作成されてから AI によって実装されるまでには、数時間あるいは数分しかかかりません。一方、ウォーターフォールモデルの要件定義書の寿命は月単位で計られます。

もちろん、SDD がウォーターフォール化するリスクがないわけではありません。しかし、それは実践上の問題であり、方法論そのものの欠陥ではありません。包丁が料理に使われることもあれば、人を傷つける道具にもなり得ますが、問題は包丁そのものにはありません。

SDD の未来：3 段階のスペクトルモデル

SDD は固定された不変の方法論ではなく、3 つのレベルからなるスペクトル上で進化を続けています。

• レベル：名称 / 現状 / 特徴 / 代表的な実践
• L1：Spec-First（仕様ファースト） / 現在の主流 / コーディング前に仕様を書くが、仕様とコードの間にズレが生じる可能性がある / Spec Kit、多くのチーム
• L2：Spec-Anchored（仕様のアンカー化） / 先進的な実践 / 仕様とコードを継続的に同期させ、テストによって整合性を強制する / Kiro の組み込みワークフロー
• L3：Spec-as-Source（仕様即ソース） / 将来のビジョン / 人間は仕様のみを編集し、コードは完全に AI が生成・維持する / 成熟した実践はまだなし

L1: Spec-First（仕様ファースト）

これは現在、多くのチームが採用している実践状態です。プロジェクト初期において仕様書は大きな価値を発揮しますが、プロジェクトが進むにつれて、仕様とコードの間にズレが生じるのはほぼ避けられません。なぜなら、整合性を強制する自動化メカニズムが存在しないからです。

L2: Spec-Anchored（仕様のアンカー化）

これは現在、先進的なチームが模索している状態です。その核心となる考え方は、自動化されたテストを用いて仕様とコードの整合性を「アンカー（錨）」で固定することです。

具体的な手法は以下の通りです。仕様の受入基準（Acceptance Criteria）から自動的にテストケースを生成し、あらゆるコード変更がこれらのテストに合格することを必須とします。もしコードが変更されたにもかかわらず、テスト（つまり仕様の自動化されたマッピング）に変更がない場合、CI システムはマージを拒否します。これは「型システム」が型エラーを防ぐのと同じように、「仕様テスト」が仕様のズレを防ぐ仕組みです。

AWS Kiro はこの方向へ進んでいます。その SDD ワークフローには、仕様からテストへの自動生成ループが組み込まれています。

L3: Spec-as-Source（仕様即ソース）

これは SDD の究極のビジョンです。コードは「コンパイル」されるものとなります——仕様書からコンパイルされたコードとして生まれるのです。

このパラダイムにおいて、人間のエンジニアの役割は完全に「仕様（Spec）」の策定に集中します。機能追加が必要なら仕様の改訂を、バグ修正が必要なら仕様の改訂を、リファクタリングが必要なら仕様の改訂を行います。AI はその仕様の改変を自動的にコードへ反映する役割を担います。

一見するとSF のような話に聞こえるかもしれませんが、チームの DAY 3-4 ではすでに L3 の雏形（原型）が実現されています。「バグを発見 → インクリメンタルな仕様（Spec）を作成 → Quest が自動的にコードを修復し PR を提出」という循環です。このサイクルがスムーズで、かつカバー範囲が十分であれば、L3 はもはや幻想ではありません。

Thoughtworks の技術レーダーでもこのトレンドに注目が集まっています。Vol.33（2025 年 11 月）では SDD が「Assess」リングに掲載され、「調査の価値はあるが、まだ全面的な採用には至っていない」と評価されました。しかし Vol.34 では、SDD を採用するチームが増え、現在は「Trial」リングへと移行しつつあります。

結び：DAY 0 は最も高価であり、最も価値のある一日

前述の「5 人 7 日間」の事例に戻りましょう。

表面的に見れば、奇跡は DAY 1 から DAY 6 の間に起こったように思えます。AI が飛躍的にコードを記述し、自動的に PR を提出し、複数のタスクを並行して推進するのです。

しかし、真の要となるのは DAY 0 です。

DAY 0 は「何もしていない」ように見えますが、実際には最も重要なことを一つ実行しています。それは、人間の思考——すなわち要件の境界線、成功基準、技術的制約、そして非目標リスト——を構造化して仕様（Spec）に固定化することです。

これらの仕様が、その後の 6 日間におけるナビゲーションシステムとなりました。5 人のチームが AI を駆使して大量のタスクを並行して進めつつも失控しなかったのは、各クエスト（Quest）が明確な仕様のアンカーによって支えられていたからです。AI は「何をすべきか」「何をすべきでないか」、そして「どこまでやれば完了とみなされるか」を正確に理解しています。

これが SDD の本質的な価値です。SDD は AI を賢くするのではなく、AI を制御可能にするのです。

AI のプログラミング能力が月単位で飛躍的に進化している今日、「AI を賢くすること」は私たちが気にする必要はありません。モデルベンダーが競い合うでしょう。人々が本当に懸念すべきは、AI がますます強力になる中で、それを驾驭できるかどうかです。

SDD が示す答えはこうです。AI のコードの一行一行を理解して制御しようとするのではなく、その「WHAT（何を）」を定義することに精力を注ぐべきです。「WHAT」こそが、人類が守るべき領土なのです。

今日から、次の機能要件に取り組む前に、まずは spec.md を作成してみましょう。

完璧である必要はありません。3〜5 回の反復を経て良くなっていきます。複雑なツールチェーンも不要です。Markdown ファイル一つで十分です。全員に広める必要もありません。一人のエンジニア、一つのモジュールから始めてください。

DAY 0 は最も「高価」な一日ですが、同時に最も「価値ある」一日でもあります。

コメント欄で一緒に議論しましょう。

WeChat で詳細を見るにはこちらへ