仕様駆動開発（Spec-Driven Development）実践ガイド — AIエージェント時代の開発ワークフロー
はじめに
AIエージェントによるコード生成が一般的になった今、新しい問題が浮上しています。「AIが書いたコードが要件と合っていない」「途中で方向転換が多く手戻りが頻発する」「人によってAIへの指示が違い、成果物の品質がバラつく」。
これらの問題の根本は、コードを書く前に「何を作るか」が明確でないことにあります。
仕様駆動開発（Spec-Driven Development）は、AIエージェントに直接コードを書かせるのではなく、まず仕様書を生成させ、仕様に基づいて実装を進める開発手法です。この記事では、なぜこの手法が生まれたのか、バイブコーディングとの違い、そして具体的な実践方法を解説します。
バイブコーディングの台頭と限界
バイブコーディングとは
2025年2月、OpenAI の元研究者 Andrej Karpathy が「バイブコーディング（Vibe Coding）」という言葉を提唱しました。「コードの中身を理解しなくても、AIに雰囲気（vibe）で指示してソフトウェアを作る」というアプローチです。
Cursor や Claude Code などのAIコーディングツールの性能が急速に向上したことで、プログラミング経験が浅い人でもアプリケーションを作れるようになりました。Karpathy 自身も「コードの存在を忘れて、完全にバイブに身を任せる」と表現しています。
バイブコーディングの問題
しかし、バイブコーディングは「週末の使い捨てプロジェクト」には向いていても、本番環境で使うソフトウェア開発には深刻な問題を抱えていることが明らかになりました。
- セキュリティ脆弱性: バイブコーディングで作られたアプリの中には、個人情報が誰でもアクセスできる状態で公開されていたケースが報告されています
- コード品質の低下: コードの重複が約4倍に増加し、マージ直後に書き直される「コードチャーン」もほぼ倍増
- 理解なき開発: 開発者がAI生成コードの動作を理解していないため、バグやセキュリティホールが検出されない
- メンテナンス不能: 長期的な保守が困難になり、技術的負債が急速に蓄積
皮肉なことに、Karpathy 自身も後のプロジェクトでは「AIエージェントを何度か試したが、まったく使い物にならなかった」と述べ、手書きコードに戻っています。
バイブコーディングを全否定するわけではありません。プロトタイピングや学習目的には有効です。問題は、この手法を本番レベルの開発にそのまま適用することにあります。
仕様駆動開発の誕生と広がり
なぜ生まれたのか
仕様駆動開発は、バイブコーディングの限界に対する業界の回答として 2025年に登場しました。
「仕様に基づいてコードを生成する」という考え方自体はLLM以前から存在していましたが、従来のツールでは自然言語の仕様書から実用的なコードを生成する精度が不十分でした。LLM のコンテキストウィンドウが拡大し、自然言語の理解力が飛躍的に向上したことで、仕様駆動のアプローチが初めて現実的になりました。
OpenAI の Sean Grove は「新しい希少スキルは、意図と価値観を完全に捉える仕様を書くことだ。プロンプトでもコードでもなく、仕様がプログラミングの基本単位になりつつある」と述べています。
普及の流れ
2025年以降、仕様駆動開発を支えるツールが続々と登場しました。
| 時期 | ツール / 動向 |
|---|---|
| 2025年7月 | Amazon が Kiro をプレビュー公開。「バイブコーディングからバイアブル（実用的な）コードへ」をスローガンに、仕様駆動ワークフローを IDE として実装 |
| 2025年9月 | GitHub が Spec Kit をオープンソース公開。CLI・テンプレート・プロンプトを提供し、仕様→計画→タスク→実装のフローを標準化 |
| 2025年末 | Thoughtworks が Technology Radar に仕様駆動開発を掲載。「2025年に登場した最も重要なプラクティスの一つ」と評価 |
現在の普及度
2026年現在、仕様駆動開発はまだ「成熟した手法」とは言い切れませんが、急速に認知が広がっています。Kiro、GitHub Spec Kit、Claude Code、Cursor など主要なAI開発ツールが仕様駆動のワークフローをサポートし始めており、Thoughtworks は「2026年にはさらに大きな変化が見込まれる」としています。
バイブコーディングから仕様駆動開発へ
では、具体的に何が変わるのでしょうか。
開発フローの比較
バイブコーディング:
開発者: 「ユーザー認証機能を作って」
AI: コードを生成
開発者: 「ちょっと違う、JWTを使って」
AI: コードを修正
開発者: 「リフレッシュトークンも追加して」
AI: さらに修正...（以下ループ）
仕様駆動開発:
開発者: 「ユーザー認証機能を作って」
AI: 要件定義書を生成（機能要件・非機能要件・制約）
開発者: レビュー・承認
AI: 技術設計書を生成（アーキテクチャ・API設計・データモデル）
開発者: レビュー・承認
AI: タスクリストを生成（優先順位付き実装ステップ）
開発者: レビュー・承認 → 実装フェーズへ
仕様駆動開発のポイントは「AIが仕様を書き、人間がレビューする」という役割分担です。人間は要件の妥当性と設計判断に集中でき、構造化・文書化の作業はAIに任せます。
ワークフロー
仕様駆動開発の基本的な流れはシンプルです。
開発者が要件を伝える → AIが仕様書を生成 → 人間がレビュー → 実装
開発者が自然言語で要件を伝えると、AIが構造化された仕様書を生成します。ツールによって出力形式は異なりますが、一般的には以下のような成果物が生成されます。
要件定義書（Requirements）
何を作るかをまとめたもの。機能要件・非機能要件・制約条件がリストアップされます。各要件にIDを振ることで、設計やタスクからの参照が可能になります。
## 機能要件
- FR-001: メールアドレス + パスワードによるログイン
- FR-002: JWT によるセッション管理
## 非機能要件
- NFR-001: レスポンスタイム 200ms 以内
- NFR-002: パスワードは bcrypt でハッシュ化技術設計書（Design）
どう作るかをまとめたもの。アーキテクチャ、API設計、データモデル、セキュリティ設計などが記載されます。要件IDへの参照を含めることで、設計の根拠が明確になります。
タスクリスト（Tasks）
どの順番で作るかをまとめたもの。優先順位付きの実装ステップがチェックリスト形式で出力されます。
生成された仕様書は人間がレビューし、問題があれば修正を指示します。仕様が固まったら、その仕様に基づいて実装を進めます。
仕様駆動開発のポイントは「AIが仕様を書き、人間がレビューする」という役割分担です。仕様を先に確定させることで、実装フェーズでのAIへの指示が具体的になり、手戻りが大幅に減ります。
主要ツールのアプローチ
仕様駆動開発を支える各ツールは、それぞれ異なるアプローチを取っています。
- Amazon Kiro: IDE 内で「Spec」を作成すると、要件→設計→タスクの順に仕様を生成。人間がレビューして承認するとコード生成に進む
- GitHub Spec Kit: CLI + テンプレートで仕様→計画→タスクのフローを標準化。既存のエディタやAIエージェントと組み合わせて使う
- Claude Code / Cursor: Plan Mode やルールファイルを活用し、仕様を先に生成してから実装するワークフローを構築できる
いずれも共通するのは「コードの前に仕様を書く」という原則です。
チーム開発への適用
仕様レビューの導入
コードレビューの前に「仕様レビュー」を導入します。
要件定義 → 仕様レビュー → 設計 → 仕様レビュー → 実装 → コードレビュー
仕様の段階で認識のズレを検出できれば、実装後の手戻りを大幅に減らせます。仕様書は Markdown ファイルとして Git 管理されるため、Pull Request ベースのレビューフローがそのまま使えます。
仕様の Git 管理
.specs/
├── user-auth/
│ ├── requirement.md
│ ├── design.md
│ └── tasks.md
├── payment/
│ ├── requirement.md
│ ├── design.md
│ └── tasks.md
└── ...
仕様書をコードと同じリポジトリで管理することで、仕様と実装の乖離を防ぎます。実装の変更に伴い仕様の更新が必要になった場合も、同一 PR で管理できます。
Agent Skills による標準化
仕様駆動開発のワークフローは Agent Skills として標準化できます。スキルとして手順を定義しておけば、チームメンバーが誰でも同じ品質の仕様書を生成できます。
私たちが公開している agent-skills では、仕様生成に加えて独自の拡張も実装しています。
- spec-generator: 仕様書（要件定義・設計・タスクリスト）の自動生成
- spec-inspect: 生成された仕様書の品質を自動検証（ID不整合、曖昧表現、設計矛盾の検出）
- spec-to-issue: 仕様書から GitHub Issue を自動生成
仕様検証や Issue 化は SDD 自体の定義には含まれませんが、チーム開発で仕様駆動開発を運用する際に便利な仕組みです。詳細は告知記事をご覧ください。
まとめ
仕様駆動開発は、AIエージェントの活用方法を「いきなりコード生成」から「まず仕様を書き、レビューしてから実装」へと転換する考え方です。
- AIが要件定義・設計・タスクリストを構造化された形式で生成
- 人間が仕様をレビューし、問題があれば修正
- 合意した仕様に基づいて実装を進める
「コードを書く前に仕様を書く」という古くからの原則を、AIエージェントの力で現実的に実践できるようにする。それが仕様駆動開発の本質です。
ZenChAIne では、この仕様駆動開発のワークフローに検証や Issue 化の仕組みを加え、Agent Skills として実装・公開しています。
