Spec-Driven Development（SDD）：AI コーディングを「感覚頼み」から「仕様に基づく開発」へ

1. Vibe Coding の時代は来た。しかし企業が求めるのは「速さ」だけではない

2025年2月、OpenAI の共同創業者 Andrej Karpathy 氏が SNS 上で新しい言葉を提唱しました――Vibe Coding（バイブコーディング）。開発者がコードを1行ずつ書くのではなく、自然言語で AI に「何を作りたいか」を伝え、AI が直接コードを生成するというアプローチです。

このコンセプトは瞬く間にソフトウェア業界全体へ広がりました。2023年時点で GitHub と Wakefield Research の共同調査により、米国の企業エンジニアの 92% が既に AI コーディングツールを使用している ことが明らかになっていました。2026年には JetBrains の開発者エコシステム調査で、世界の開発者の 90% が週に1回以上 AI コーディングツールを使用し、68% は毎日使用している ことが確認されています。Vibe Coding はもはやギークの実験室を飛び出し、あらゆる現場で現実に進行している生産性革命です。

しかし、多くの企業がすぐに共通の壁に直面しました。「AI がコードを書くスピードは確かに速い。しかし、間違ったコードを量産するスピードも同じく速い」 という現実です。

AI がシステムのインターフェース規約やビジネスルール、アーキテクチャ上の制約を正確に把握していない場合、生成されるコードにはフィールド名の不一致、状態遷移の誤り、さらにはセキュリティ脆弱性が紛れ込みます。プロジェクト規模が拡大し、関わるチームが増えるほど、この「高速なカオス」がもたらす手戻りのコストは膨大になります。

そこで先進企業が実践し始めているのが、AI に「自由に書かせる」のではなく「仕様に従って実行させる」アプローチです。これが Spec-Driven Development（SDD：仕様駆動開発）です。

先行企業の実践事例

SDD の核心思想――「まず仕様を定義し、その仕様からコードを生成する」――は、すでにグローバルなテックカンパニーで採用・検証されています。以下に代表的な事例を紹介します。

🇺🇸 Stripe ── グローバル API-First の代表格

Stripe は世界的な決済テクノロジー企業です。すべてのプロダクト開発が OpenAPI 仕様を起点として運用されています。まずインターフェース仕様を厳密に定義し、そこからツールチェーンによって 7 言語の SDK・ドキュメント・テストコードを自動生成します。あらゆる API の変更は仕様レビューを通過しなければならず、「コードより先にまず仕様を直す」ことが組織の鉄則となっています。

📖 How Stripe Builds APIs — Postman Engineering の詳細ケーススタディ

🇺🇸 Amazon / AWS ──「仕様ファースト」の徹底

AWS は独自のインターフェース定義言語 Smithy を開発・OSS 化しています。S3 や DynamoDB をはじめとする数百の AWS クラウドサービスでは「仕様先行（Spec-First）」が義務付けられています。Smithy で API 仕様を定義し、ジェネレーターによってサーバー側のスケルトンコードやクライアント SDK を自動派生させています。

📖 AWS Developer Tools Blog — Smithy IDL & Toolchain

🇯🇵 メルカリ ── Vibe Coding から ASDD へ

日本最大のフリマアプリを運営するメルカリは、「感覚で AI にコードを書かせる」手法の限界をいち早く振り返り、ASDD（Agent Spec-Driven Development） という方法論を提唱しています。同社の実践では、構造化された仕様ファイルを AI にコンテキストとして与えることで、曖昧な自然言語による指示に比べ、生成コードの品質と一贯性が大幅に向上することが実証されました。現在、メルカリにおける AI ツールの利用率は 95%、AI によるコード生成率は 70% に達しています。

📖 AI-Native な開発の実践に向けて — Mercari Engineering Blog

📖 決済プラットフォームに常駐する自律AIエージェントの設計と運用

🌐 GitHub ── Spec Kit フレームワークの提供

2025年9月、GitHub は SDD を実践するためのオープンソースフレームワーク Spec Kit を公開しました。「仕様の定義 → 計画立案 → タスク分解 → AI による仕様遵守の実装」という標準ワークフローを提供しており、企業における SDD 導入のデファクトスタンダードになりつつあります。

一言で言えば、先進企業の共通認識は「仕様なき AI コーディングは、極めてコストの高い高速カオスを生む」ということです。

SDD は理論上の概念ではなく、Stripe、AWS、メルカリといった現場ですでに稼働しているエンジニアリングプラクティスです。

2. 比喩で理解する：SDD は何をしているのか

SDD の技術的な詳細に入る前に、シンプルな比喩で全体像を整理してみましょう。

従来のウォーターフォール開発 はビルの建設に似ています。概要設計で青写真を描き → 基本設計で構造を決め → 詳細設計で施工図を起こし → 施工チームが図面通りに施工し → 検収で確認する。各フェーズの担当者が前フェーズのドキュメントを読み解き、自身の成果物に落とし込みながら段階的にバトンを繋ぎます。

純粋な Vibe Coding は、AI シェフに口頭で「何かおいしいものを作って」とだけ頼むようなものです。期待以上の傑作ができることもあれば、食べられないものが出来上がるリスクもあります。

SDD は、AI に標準化されたエンジニアリング仕様書（設計データ） を渡すアプローチです。インターフェース定義、状態遷移ルール、データの制約条件がすべて機械可読な形式で記述されています。AI は仕様に従って厳格にコードを組むため、出力は安定的で再現性があります。誰が（どの AI が）同じ仕様を読み込んでも、同じ品質の成果物を再現できます。

SDD の本質は次の通りです。

これまで人の頭の中、Word、Excel、会議の議事録や Slack に散在していたシステムの制約事項を、構造化・バージョン管理可能・機械可読な「エンジニアリング仕様（Specification）」に集約すること。

この仕様は、人間が「目を通すだけ」の受動的な文書ではありません。

• 機械（AI・ツール）が直接パースできる
• コードが仕様に合致しているかを自動検証できる
• 仕様の変更が、コード骨格・テスト・ドキュメントへ自動的に波及・追従する

3. 従来のウォーターフォール vs SDD：業務シナリオで見る全工程の違い

違いを具体的にイメージできるよう、カメラ機材のオンラインレンタルサービス（日本の Rentio などのビジネスモデル）を題材に、従来の開発工程（要件定義〜保守）に沿って比較します。

業務シナリオ：ユーザーがアプリ上でソニー製カメラ（DEV-SONY-A7M4）のレンタルを予約し、デポジットを決済して機材を受け取り、レンタル期間終了後に返却・検品を行う。

主要なビジネスルール：

1. 注文・デポジット決済完了 → 在庫をロック（貸出可能 → 予約済み）
2. 機材の引き渡し・利用開始（予約済み → レンタル中）
3. 期限超過で未受取 → 在庫を自動解放（予約済み → 貸出可能）
4. レンタル中の機材は、検品完了を経ずに勝手に在庫復帰させてはならない（状態スキップの禁止）

1. 要件分析と概要設計

シナリオ説明

事業部門からレンタルサービスの要件が提示され、要件整理とシステムアーキテクチャの基本方針を決定するフェーズです。

従来のウォーターフォール

• インプット：ビジネス要求仕様書（BRD / 企画書）
• 主なプロセス：
  1. システムアナリストが Word で「要件定義書」を作成し、機能要件・利用ロール・業務ルールを整理
  2. アーキテクトが「概要設計書」を作成し、システム構成方針・採用技術・モジュール構成を定義
  3. レビュー会議を実施し、事業部と開発責任者の合意（サインオフ）を得て仕様を凍結
• アウトプット：要件定義書.docx、概要設計書.docx

SDD（仕様駆動）フロー

• インプット：ビジネス要求仕様書（BRD / 企画書）
• 主なプロセス：
  1. コアとなる業務ルールを構造化された状態遷移表（Markdown / Mermaid 形式）として定義し、「貸出可能」→「予約済み」→「レンタル中」といった有効な状態遷移パスを明確化
  2. 仕様管理ツールチェーン（OpenAPI 3.0 + JSON Schema 等）と実行基盤スタックを決定
  3. 技術スタックの選定結果を設定ファイルとしてコードリポジトリにコミットし、バージョン管理を開始
• アウトプット：構造化された状態遷移仕様ファイル、リポジトリの初期構成ファイル

比較表

2. 基本設計と詳細設計

シナリオ説明

概要設計の方針に基づき、画面・API・データ構造を具体化するフェーズです。フロントエンドや外部システムと通信するレンタル API を定義します。

従来のウォーターフォール

• インプット：概要設計書.docx
• 主なプロセス：
  1. 開発担当者が「基本設計書」を作成し、機能一覧・画面レイアウト・I/F 一覧を定義
  2. 「詳細設計書」で各 API のフィールド名、型、必須チェック、バリデーションルールを Excel の表形式（API 仕様書）に記述
  3. フロントエンド／バックエンド合同で設計書を突き合わせて仕様レビュー
  4. フロントエンド担当は Excel を見ながらローカル用のモックデータを作成し、バックエンド担当は手動でパッケージ構成やコードのスケルトンを作成
• アウトプット：基本設計書.docx、詳細設計書.docx、API仕様書.xlsx、手作業で作成したモックスクリプト・雛形コード

SDD（仕様駆動）フロー

• インプット：構造化された状態遷移仕様、リポジトリ構成
• 主なプロセス：
  1. OpenAPI 3.0 標準に準拠した形式で API 仕様を記述し、フィールド名・データ型・制約条件・エラーコードを厳密に定義
  2. コード生成ツールを実行し、型安全な DTO（Data Transfer Object）や API のスケルトンコード（インターフェース雛形）を自動生成
  3. 同時にフロントエンド用 SDK とモックサーバーを自動起動し、フロント・バックエンドが初日から並行開発に着手
  4. 仕様から受入テストケース（アサーション定義）を自動生成し、コーディング前に完了条件（Acceptance Criteria）を確定
• アウトプット：OpenAPI 仕様ファイル、自動生成されたコードスケルトン・型定義 DTO、クライアント SDK・モックサーバー、テストケース雛形

比較表

3. 開発と単体テスト

シナリオ説明

設計内容に基づき、レンタル業務ロジック（予約処理、貸出開始、タイムアウト解放、検品・返却処理など）を実装し、単体テストを実施するフェーズです。

従来のウォーターフォール

• インプット：詳細設計書.docx、API仕様書.xlsx
• 主なプロセス：
  1. プログラマーが詳細設計書を参照しながら、IDE 上で各層のコードをフルスクラッチで記述
  2. 実装完了後、テックリードがコードレビューを行い、設計書通りに実装されているかを目視確認
  3. 実装後にプログラマーが単体テストコードを作成し、正常系・異常系のカバレッジを確保
  4. テストを実行し、エビデンスとして「単体テスト結果報告書」を作成
• アウトプット：プロダクトコード、単体テストコード、単体テスト結果報告書.xlsx

SDD（仕様駆動）フロー

• インプット：仕様ファイル、自動生成されたコードスケルトン、事前生成されたテストケース
• 主なプロセス：
  1. テストファーストの実践：コーディング前にまずテストを実行（ロジック未実装のため必ず Red/失敗となり、満たすべき要件が明確化される）
  2. エンジニアおよび AI が、自動生成されたスケルトン上に業務ロジックを実装し、すべてのテストが Green（成功）になるまでリファクタリングを継続
  3. ArchUnit などのアーキテクチャテストを自動実行し、コードのパッケージ依存関係やレイヤリング規約が守られているかを機械的に検証
• アウトプット：テストで検証済みのプロダクトコード、自動生成されたテスト実行レポート

比較表

4. 結合テスト

シナリオ説明

単体テスト完了後、テスト環境にモジュールをデプロイし、フロントエンドとバックエンドの通信疎通およびシステム間連携を検証するフェーズです。

従来のウォーターフォール

• インプット：デプロイパッケージ、API仕様書.xlsx、テスト計画書
• 主なプロセス：
  1. QA / テスト担当者が設計書に基づき「結合テスト仕様書」を作成
  2. 結合環境で疎通確認を実施し、フィールド名のタイポや型変換エラー、HTTP ステータスコードの解釈不一致などのバグを検出・改修
  3. テスト項目を順次消化し、障害管理表（チケット）に起票・再テスト
  4. 最終的な結果を取りまとめ「結合テスト報告書」「システムテスト報告書」を作成
• アウトプット：結合テスト仕様書.xlsx、障害管理表、結合テスト報告書.docx

SDD（仕様駆動）フロー

• インプット：仕様ファイル、ビルド成果物、ソースコード
• 主なプロセス：
  1. CI パイプライン上で、仕様から派生したコントラクトテスト（契約テスト）を自動実行し、リクエスト／レスポンスの型やステータスコードの整合性を完全に機械検証
  2. 開発初期から同一のスキーマから生成された SDK・モックを利用しているため、低レベルな I/F の不一致はすでに解消済み。テストチームは並行処理時の競合状態（Race Condition）や異常系シナリオ、複合的な業務フローの検証にリソースを集中
• アウトプット：コントラクトテスト実行レポート、E2E / 統合テスト実行レポート

比較表

5. 要件変更

シナリオ説明

本番リリース後、事業部門から「利用期間の延長（延長レンタル）機能を追加したい」という仕様変更要望が発生したケースです。

従来のウォーターフォール

• インプット：仕様変更依頼書、本番稼働中のコード、過去の設計書アーカイブ
• 主なプロセス：
  1. アーキテクトおよび開発者が既存の設計書とコードを突き合わせ、影響範囲を調査
  2. 「概要設計書」「基本設計書」「詳細設計書」「API 仕様書」の関連箇所を手動で修正し、コードも追随して改修
  3. 変更箇所周辺の単体テスト・リグレッションテスト（回帰テスト）を実施し、リリース判定を実施
• アウトプット：更新版の各種設計書、修正版リリースパッケージ

SDD（仕様駆動）フロー

• インプット：変更要件定義、既存の仕様ファイル
• 主なプロセス：
  1. 仕様の更新が起点：OpenAPI 仕様に延長リクエスト用フィールドを追加し、状態遷移表に「延長申請」の遷移パスを追記
  2. 差分検出ツールが新旧仕様の差分（Diff）を自動解析し、破壊的変更の有無や影響範囲リストを出力。同時にテストケースを自動更新
  3. コードスケルトンを再生成し、開発者（または AI）が追加ロジックを実装してテストを Green にする
  4. CI パイプラインが既存機能を含めた回帰テストを全件自動実行し、互換性を担保
• アウトプット：バージョン管理された新仕様ファイル、変更影響分析レポート、新バージョンのビルド成果物

比較表

全工程の比較サマリー

4. SDD は AI コーディングにどんな「ガードレール」を提供するのか

「AI が書くコードは本当に信頼できるのか？」という懸念に対し、SDD の回答は明快です。「AI に白紙から自由に書かせるのではなく、厳格なルールの境界線（ガードレール）の中で作業させる」 ということです。

これは、新人のジュニアエンジニアに仕事を依頼する場面を想像すると分かりやすいでしょう。「適当にいい感じで作っておいて」と丸投げすることはなく、API 定義書、コーディング規約、コードのテンプレート、そして合格基準となるテストケースを渡すはずです。SDD が AI に対して提供する環境も、まったく同じ構造です。

1. システムの構造を伝える：AI が API スキーマを読み込み、各フィールドの名前・データ型・許容値の範囲を正確に把握する
2. ビジネスルールを伝える：AI が状態遷移表を読み込み、どの操作が正常で、どの操作を不正として拒否すべきかを理解する
3. 作業境界を制約する：アーキテクチャルールにより、AI が変更してよいファイル範囲を限定し、想定外のコード改変を防止する
4. 出力を自動検証する：AI がコードを出力すると直ちにテストが走り、仕様に違反している箇所を機械的に検知する

AI がコードを間違えた場合はどうなるか？ テストの失敗ログやエラーメッセージが即座に AI へフィードバックされ、AI はそのエラーログを元に自律的に修正を試みます。「生成 → テスト → エラー検知 → 自己修正」という自動化ループが回り、すべての仕様テストをクリアするまで実装が洗練されます。

強調すべき点：SDD はシステム開発のすべてを AI に丸投げするものではありません。システム全体のアーキテクチャ設計、ビジネスルールの定義、重要な意思決定、そして最終的な品質承認は、今後もエンジニアが責任を持ちます。AI は、人間が設計した仕様の枠組みの中で、最高速度で実装を形にする強力なペアプログラミングパートナーです。

5. SDD が実現する 4 層の品質保証モデル

SDD では、コードの書き手が人間か AI かに関わらず、以下の 4 つの防衛線で品質を担保します。

この 4 層の仕組みにより、「入力時の制約」から「出力時の自動検証」に至る完全な品質ループが完成します。問題が起きてから事後対応するのではなく、プロセスの構造によって不具合の混入を未然に防ぐ設計思想です。

6. セキュリティと機密保持：AI に社内データを学習されるリスクはないのか

企業の導入検討において最も重視されるのがセキュリティとデータガバナンスです。SDD を採用した開発において、情報漏洩リスクは次のように制御されます。

AI が参照するのは「メタデータ（構造定義）」のみであり、「本番データ（実データ）」ではありません。

• ✅ AI に渡されるもの：orderId: string、quantity: integer といったスキーマ定義やインターフェース情報
• ❌ AI に渡されないもの：顧客の個人情報、クレジットカード番号、決済履歴、本番データベースのレコード

開発フェーズにおいて AI が本番データベースと通信する必要はありません。AI が扱うのはあくまで「データの型と骨格」であり、業務データそのものが外部に送信される経路は存在しません。

さらに、エンタープライズ向けの主要 AI クラウド（Azure OpenAI Service、AWS Bedrock、Anthropic Commercial API、Google Cloud Vertex AI）では、以下のセキュリティ基準が契約上保証されています。

• 顧客のプロンプトや生成コードを公開モデルの学習（トレーニング）に使用しない
• 処理完了後のリクエストデータは保持されず、セキュアに破棄される（ゼロデータリテンション対応）
• SOC 2、ISO 27001、GDPR などの主要な国際セキュリティ認証に準拠

📖 Microsoft Azure OpenAI Data Privacy ｜ AWS Bedrock Security ｜ Anthropic Commercial Terms ｜ Google Cloud Vertex AI Data Governance

7. SDD の適用限界：何ができて、何ができないのか

SDD は銀の弾丸（万能の特効薬）ではありません。導入にあたっては以下の限界やトレードオフを正しく認識しておく必要があります。

1. 初期の仕様設計に工数がかかる：曖昧な自然言語でドキュメントを書くのに比べ、構造化された仕様を定義するには設計初期にある程度の思考力と工数を要します（ただし、後工程の結合デバッグや手戻り工数を大幅に削減するため、プロジェクト全体ではプラスになります）。
2. すべての関心事を仕様で表現できるわけではない：高度なアルゴリズムの最適化、複雑なパフォーマンスチューニング、直感的な UI/UX の微調整などは、依然として熟練エンジニアの経験と判断が不可欠です。
3. 組織的なマインドセットの転換が必要：「とりあえずコードを書き始める」文化から「まず仕様を明確に定義して合意する」開発スタイルへの意識改革が求められます。
4. 人間の最終レビュー責任は残る：仕様の制約下にあるとはいえ、AI が生成したロジックがビジネス要件を真に満たしているかの最終判定は人間が行う必要があります。

8. もし将来 AI を使わなくなっても、プロジェクトは保守できるのか

完全に保守可能です。 この点こそが、特定の「AI 専用ノーコード/ローコードプラットフォーム」に依存するアプローチと SDD との決定的な違いです。

SDD で利用する技術スタックは、業界標準として広く普及しているオープンソースと標準規格で構成されています。

• 仕様フォーマット：OpenAPI 3.0（Linux Foundation 傘下の標準規格）、JSON Schema、Markdown
• コードジェネレーター：OpenAPI Generator（ローカル環境で動作する OSS ツール）
• アーキテクチャ検証：ArchUnit（Java などの標準的な単体テストライブラリ）
• ビルド・テスト環境：Gradle / Maven、JUnit 等の一般的なツールチェーン

AI は開発速度を高める「加速装置」であり、アーキテクチャの「依存先」ではありません。 万が一 AI の利用を停止した場合でも、作成した仕様ファイル、自動生成されたスケルトンコード、テスト自動化スイートはそのまま機能し続けます。エンジニアは普段使い慣れた IDE を使い、従来のエンジニアリング手法でメンテナンスを継続できます。

9. 企業が SDD を導入するための 3 ステップ

全社規模で一度に導入する必要はありません。小さな成功体験を積み重ねながら段階的にスケールさせることを推奨します。

ステップ 1：スモールスタート（パイロットプロジェクト）

• 新規機能や独立したマイクロサービスを 1〜2 個選定し、リポジトリ内に specs/ ディレクトリを配置
• 「仕様の策定 → スケルトンの自動生成 → テスト自動実行による実装」のサイクルを検証
• 手戻りの削減と開発スピードの向上をチームで体感する

ステップ 2：仕様ガバナンスと CI パイプラインの整備

• サービス横断の共通規約を策定（共通エラーレスポンス、ページネーション構造、認証ヘッダーの標準化など）
• CI/CD パイプラインに仕様の Linter やスキーマ検証、コントラクトテストを組み込み、品質ゲートを自動化

ステップ 3：AI エージェントとの本格的な協調開発

• 整備された仕様ファイルとアーキテクチャ制約を AI にコンテキストとして提供
• 自動テストによる安全網（セーフティネット）を効かせた状態で、AI とのペアプログラミングを推進
• AI の生成比率を徐々に高め、開発スループットの向上を定量的に計測・改善

10. まとめ

SDD の本質は、奇抜な新技術を導入することではなく、「すでにある設計知識を、人間と機械の双方が扱える構造化データとして正しく管理する」ことにあります。

散在していたシステム制約を、検証可能で持続的なエンジニアリング資産へと昇華させる――それこそが SDD の狙いです。AI を活用する現場において、SDD は AI を「頼れる開発パートナー」へと変えるための最も堅牢な基盤となります。