はじめに

「AIにコードを書かせたら、想定と違う実装が大量に出てきた」
「レビューで仕様の認識ズレが発覚し、大幅な手戻りが発生した」
AIコーディングエージェントを使う現場では、こうした問題が珍しくありません。原因は、AIの性能不足より前に、何を作るかが曖昧なまま実装を始めていること にあります。GitHub社も、いわゆる バイブコーディングは素早い試作には向く一方、既存コードベースや本番向け開発では意図の取り違えが起きやすいと整理しています※1。

この記事では、その問題を構造的に減らすアプローチとして 仕様駆動開発（SDD / Spec-Driven Development） を解説します。TDDやウォーターフォールとの違い、GitHub Spec Kit・Kiroでの実践方法、さらに導入効果をどの指標で追うべきかまで整理します。AIエージェントを個人の便利ツールではなく、チームで再現可能な開発フロー に変えたいEM・テックリード向けの内容です。

仕様駆動開発（SDD）とは何か

仕様駆動開発とは、コードを書く前に仕様を明文化し、その仕様を開発の基準点として設計・実装・検証を進めるやり方 です。GitHub社は仕様駆動を、「仕様を単なる静的ドキュメントではなく、実装を導く”shared source of truth”として扱う発想」で説明しています※1。

ここでいう仕様は、重い要件定義書とは限りません。Markdownベースの仕様ファイルでも成立します。重要なのは形式より、受け入れ条件・対象外・依存関係・設計上の前提が、実装前にチームで共有されていること です。AIエージェントは仕様が明確なほど安定して働きます。逆に、仕様が曖昧なままでは、それらしいコードを高速に量産するだけです。

TDD・ウォーターフォールとの違い

仕様駆動開発は、その名前や手法からTDDやウォーターフォールと混同されやすいですが、同じものではありません。

TDDは、まず失敗するテストを書き、そのテストを通す最小限の実装を行い、テストが通ることを保ちながらリファクタリングを繰り返す開発手法です※2。

これに対し仕様駆動開発は、何を作るか、どこまでをスコープとするか、どのような振る舞いや受け入れ条件を満たすべきかを先に仕様として明確化し、その仕様を基準に設計・実装・検証を進める考え方です。両者は競合ではなく、むしろ相性がいいです。先に仕様を明確にしたうえで、TDDで実装を進める運用は十分に両立可能です。

ウォーターフォールとの違いは、仕様の扱いです。ウォーターフォールでは仕様が前工程の成果物として固定化されやすい一方、仕様駆動開発では仕様は更新される前提の開発資産 です。GitHub社も、仕様はプロジェクトとともに育てるものであり、複雑化したら見直し、タスクが大きすぎれば分解するものとして説明しています※3。

なぜ「仕様」が先に来るのか

コードを先に書いて仕様を後から整備する進め方では、実装時の解釈が人やAIごとにぶれやすく、レビューや統合の段階で認識齟齬が顕在化して手戻りにつながることがあります。GitHub社やKiroの公式説明でも、仕様を先に明示することで推測や要件確認の往復を減らせる点が強調されています※1※4。

AIエージェントが加わると、その危うさはさらに増します。AIは不足している前提を自力で補完してしまうため、認識ズレを含んだ実装が人間より速い速度で積み上がる からです。GitHub社も、曖昧な依頼はモデルに多数の未記述要件を推測させ、その一部は必ず外れると説明しています※1。

仕様駆動開発では、コードより先に、仕様ファイルを「コードより先に存在するチームの合意文書」として合意を作ります。機能の受け入れ条件、エッジケース、他モジュールとの境界を先に仕様へ落とし、それをレビューしてから実装へ進みます。

なぜ今、仕様駆動開発が注目されているのか

バイブコーディングが生んだ「手戻りの構造的原因」

バイブコーディングとは、AIに対して厳密な仕様を与えるのではなく、「こんな感じで作って」という自然言語の大まかな指示でコードを生成させる手法です。OpenAI設立メンバーのひとりであるAI研究者Andrej Karpathy氏が2025年2月にX（旧Twitter）への投稿で提唱した概念で生成AIの登場によって急速に広まりました※5。

GitHub社はこの言葉を引用しつつ、quick prototype には有効でも、本格的な開発では信頼しにくいと指摘しています※1。問題は、バイブコーディング自体が悪いことではありません。問題なのは、曖昧な指示のままチーム開発に持ち込むこと です。

「認証を作って」「画像共有を追加して」といった依頼では、認証方式、権限制御、例外時の動作、既存設計との整合が抜け落ちます。AIはその空白を埋めますが、その解釈は必ずしもチームの意図と一致しません。結果として、あとからの認識合わせコストが増大し、期待していた実装速度の向上は得られないケースが発生するのです。

AIエージェントと仕様は相性がいい

AIエージェントは、曖昧な依頼を正確に読むのは苦手ですが、構造化された仕様から実装へ落とすこと は得意です。GitHub社がSpec Kitで採っている流れも、まず仕様を作り、次に計画を立て、最後に実装タスクへ落とし込むものです※1。これは、AIを万能な相棒として扱うのではなく、明確な設計図を渡された実装者として扱う 発想です。

AIエージェントは、Markdownなどの構造化されたテキストを読み込んだ上でコードを生成するタスクを非常に得意とします。つまり、仕様ファイルが整っているほど、AIの出力は安定し再現性が高まります。「設計図なしに作業を依頼する」という状態から、「設計図を実装者に渡し、実装を任せる」という状態へ移行するイメージです。

この考え方を実装したツールキットの1つが GitHub Spec Kit です。Spec Kitは spec.md（仕様）・plan.md（計画）・tasks.md（タスク分解）の仕様ファイルを起点として開発を進める構成を採用しています※3。AIエージェントはこれらのファイルを参照しながらコードを生成するため、担当者が変わっても、日をまたいでセッションが切り替わっても、同じ設計思想に基づいた実装が得られます。

主要ツールの対応状況

Spec Kit

Spec Kit は、GitHub社 が 2025年9月2日に公開した、Spec-driven development 向けのオープンソースツールキットです。GitHub社公式ブログでも、GitHub Copilot、Claude Code、Gemini CLI などのコーディングエージェントと組み合わせて使う前提で紹介されています※1。

初期化は specify init で行います。現行の公式 README では、コアの流れは次の順です※3。

specify init my-project --ai claude

/speckit.constitution
/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement

specify init my-project --ai claude

/speckit.constitution
/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement

役割を分けて見ると、こうなります。

constitution = 開発原則を決める
specify      = 何を作るかを定義する
plan         = どう作るかを設計する
tasks        = 実装単位に分解する
implement    = タスクに沿って実装する

constitution = 開発原則を決める
specify      = 何を作るかを定義する
plan         = どう作るかを設計する
tasks        = 実装単位に分解する
implement    = タスクに沿って実装する

重要なのは、Spec Kit は単なるテンプレート集ではなく、仕様を中心に spec -> plan -> tasks -> implement と工程を分けることで、AI の出力を一発生成ではなく段階的に扱えるようにしている点です。GitHub社も、Spec Kit を「structured process」として説明しており、spec を工程の中心に置くとしています※1※3。したがって、Spec Kit の価値は「AI に丸投げすること」ではなく、「AI が触る前に、どの意図で、どの設計で、どの作業単位で進めるかを明示すること」にあります。

要求が曖昧なまま実装しない
       ↓
spec を確認してから plan へ進む
       ↓
plan を確認してから tasks に落とす
       ↓
tasks を確認してから implement する

要求が曖昧なまま実装しない
       ↓
spec を確認してから plan へ進む
       ↓
plan を確認してから tasks に落とす
       ↓
tasks を確認してから implement する

Kiro

Kiro は、2025年7月14日に preview として公開され※4、2025年11月17日に一般提供が始まったエージェント型 IDE です※6。Kiro の公式ブログは、バイブコーディングの速さと、仕様書による明確さを両立する方向で位置づけています※4。

Kiro の Feature Specs には、Requirements-First と Design-First の2つの流れがあります。Feature Specs の公式 Docs では、それぞれ次のように整理されています※7。

Requirements-First
Requirements -> Design -> Tasks

Design-First
Design -> Requirements -> Tasks

Requirements-First
Requirements -> Design -> Tasks

Design-First
Design -> Requirements -> Tasks

Requirements-First は「まず振る舞いを定義する」流れです。Design-First は「まず設計制約やアーキテクチャを置く」流れです。要件が先にあるプロダクト開発では前者が自然で、厳しい性能要件や既存設計がある場合は後者が向いています。

Requirements の書き方にも型があります。Kiro の requirements.md は EARS 記法を使い、公式 Docs では次の形が示されています※7※8。

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

たとえば、次のような要件です。

ユーザーが不正なデータを含むフォームを送信したとき、
システムは該当する入力欄の横にバリデーションエラーを表示しなければならない

ユーザーが不正なデータを含むフォームを送信したとき、
システムは該当する入力欄の横にバリデーションエラーを表示しなければならない

Kiro の強みは、仕様を書くところで終わらないことです。Hooks を使うと、保存・作成・削除といったファイルイベント、ユーザープロンプト送信やエージェント応答、ツール実行の前後、spec task 実行の前後などをトリガーに、自動アクションを差し込めます※9。つまり、レビュー観点や品質チェックを「その都度ちゃんとやる」ではなく、IDE 側の自動化として埋め込みやすいわけです。

Trigger: file save
Action : lint を回す / 規約チェックを走らせる

Trigger: before spec task execution
Action : 前提条件を検証する

Trigger: after tool invocation
Action : 変更差分をレビュー観点で確認する

Trigger: file save
Action : lint を回す / 規約チェックを走らせる

Trigger: before spec task execution
Action : 前提条件を検証する

Trigger: after tool invocation
Action : 変更差分をレビュー観点で確認する

2つを一言でまとめると

公式 Docs の構成から実務上の理解を整理すると、以下のようになります。

Spec Kit   = 工程を明示的に分けるためのツールキット
Kiro       = IDE の中に spec workflow と自動化を持ち込む環境

Spec Kit   は「工程の型」が強い
Kiro       は「IDE内の流れ」と「自動化」が強い

Spec Kit   = 工程を明示的に分けるためのツールキット
Kiro       = IDE の中に spec workflow と自動化を持ち込む環境

Spec Kit   は「工程の型」が強い
Kiro       は「IDE内の流れ」と「自動化」が強い

アジャイル・スクラムとの共存

仕様駆動開発はウォーターフォール回帰ではない

仕様駆動開発（SDD）を聞いた際、「仕様書を事前に全部書くということは、ウォーターフォールに近い概念だ」と感じる方は少なくありません。しかし、仕様駆動開発はアジャイル・スクラムと対立するものではありません。

鍵となる運用パターンは、仕様ファイル作成をスプリント内の正式なタスクとして扱うことです。各ユーザーストーリーについて、受け入れ条件・対象外スコープ・依存関係を記述した仕様ファイルをまず作成し、その内容が合意されたものから実装に着手します。仕様整理を開発タスクの前段に明示的に置くことで、スプリント中の手戻りや認識齟齬を減らせます。

ウォーターフォール型組織と仕様駆動開発の相性：移行期の「橋渡し」として使う

一方で、ウォーターフォール型の開発プロセスを採用している組織にとっても、仕様駆動開発は親和性が高い手法です。ウォーターフォールはもともと「要件定義→設計→実装→テスト」という工程分離を前提としており、各工程の成果物をドキュメントとして残す文化が根付いています。
仕様駆動開発に必要な「仕様ファイルを先に書く」という行為は、この文化と構造的に矛盾しません。

仕様駆動開発が特に力を発揮するのが、ウォーターフォールからアジャイルへ移行している過渡期の組織です。完全なアジャイルへの移行は一朝一夕には進まず、「設計ドキュメントは重厚なまま、実装はスプリントで回す」という混在状態が長く続くことがよくあります。

この移行期に仕様駆動開発を導入すると、従来の設計ドキュメントをスプリント単位のスペックファイルへ段階的にスリム化する起点として機能します。
既存の設計書文化がある組織では、まず既存文書から受け入れ条件や依存関係を抜き出して、Gitで扱える軽量な仕様ファイルに落とすだけでも前進です。完全にドキュメントを捨てるのでも、従来の重い設計書を抱え続けるのでもなく、更新可能な仕様資産に変換すること が重要です。

具体的には、次のような段階的な移行が現実的です。

フェーズ1：既存の設計書から「受け入れ条件」だけを抜き出し、スペックファイルを作る

フェーズ2：新規機能はスペックファイルから書き始め、AIエージェントに渡す習慣をつける

フェーズ3：スプリント単位での仕様管理に切り替え、重厚ドキュメントを段階的に廃止する

フェーズ1：既存の設計書から「受け入れ条件」だけを抜き出し、スペックファイルを作る

フェーズ2：新規機能はスペックファイルから書き始め、AIエージェントに渡す習慣をつける

フェーズ3：スプリント単位での仕様管理に切り替え、重厚ドキュメントを段階的に廃止する

ウォーターフォールの資産（既存の設計書・要件定義の知見）を活かしながら、AIエージェント時代の開発スタイルへ移行するための実践的な経路として、仕様駆動開発は有効な選択肢です。

チームへの導入ステップ

ステップ1：まずはスペックファイルの雛形を1本作る

まず、最小構成の仕様テンプレートを用意します。
1つの機能に対して、必要な項目は4つです。

概要：この機能が何を解決するかを1〜2文で記述する
受け入れ条件：「〜のとき、〜になる」形式で検証可能な条件を列挙する
対象外：今回のスコープに含まないものを明示する
依存：関連するAPI・コンポーネント・前提仕様を記載する

概要：この機能が何を解決するかを1〜2文で記述する
受け入れ条件：「〜のとき、〜になる」形式で検証可能な条件を列挙する
対象外：今回のスコープに含まないものを明示する
依存：関連するAPI・コンポーネント・前提仕様を記載する

導入の第一歩は、既存プロジェクトの機能を1つ選び、このテンプレートに当てはめてみることです。新機能ではなく「すでに動いている機能」に適用することで、仕様の解釈が正しいかどうかを既存の動作で検証できます。

ステップ2：AIに渡す前に仕様レビューを挟む

スペックファイルをAIエージェントに渡す前に、チームで仕様レビューを実施します。確認すべき観点は以下のとおりです。

受け入れ条件がテストとして検証可能な形式になっているか
境界ケース（空リスト・最大値・エラー系）が明示されているか
対象外が曖昧でなく、判断基準として機能するか
依存する仕様・APIが特定されているか

受け入れ条件がテストとして検証可能な形式になっているか
境界ケース（空リスト・最大値・エラー系）が明示されているか
対象外が曖昧でなく、判断基準として機能するか
依存する仕様・APIが特定されているか

仕様レビューをコードPRレビューと分離することで、レビューの目的が明確になります。コードPRでは「実装がスペックを満たしているか」だけを確認すればよく、レビュアーの認知負荷が下がります。結果として、レビューの往復回数が減り、マージまでのリードタイムが短縮されます。

ステップ3：まずは1つのユーザーストーリーで小さく回す

雛形とレビュー観点が整ったら、次は実際のユーザーストーリーで小さく運用してみます。

仕様ファイルもスプリント内の正式なタスクとして扱い、内容が合意できたものから実装に進みます。

流れは次のようになります。

ユーザーストーリーに対して仕様ファイルを作る
↓
チームでレビューし、受け入れ条件・対象外・依存関係を確定する
↓
合意できたら実装に着手する
↓
実装後に、仕様の不足や曖昧さを振り返る

ユーザーストーリーに対して仕様ファイルを作る
↓
チームでレビューし、受け入れ条件・対象外・依存関係を確定する
↓
合意できたら実装に着手する
↓
実装後に、仕様の不足や曖昧さを振り返る

ここで大事なのは、最初から全案件に広げないことです。

まずは1件、あるいは少数のストーリーで試し、どの項目が不足しやすいか、どこで認識齟齬が起きるかを見ます。導入初期に必要なのは完成度の高い仕組みではなく、小さく回せる運用です。

ステップ4：定量的に観測し、改善サイクルを回す

SDDを定着させるには、導入して終わりにしないことが重要です。

運用がうまく回っているかどうかを、感覚ではなく指標で確認します。

導入初期にまず見るべきなのは、DORAのような上位成果指標だけではありません。

先に確認すべきなのは、SDDの運用自体が回っているかを示す近接指標です。たとえば次のようなものです。

- 仕様レビューでの差し戻し件数
- 実装中に発生した仕様変更件数
- PRで発生した仕様起因の指摘件数
- ストーリー着手からマージまでの時間
- 仕様に書いていなかったために止まった回数

- 仕様レビューでの差し戻し件数
- 実装中に発生した仕様変更件数
- PRで発生した仕様起因の指摘件数
- ストーリー着手からマージまでの時間
- 仕様に書いていなかったために止まった回数

こうした指標を見ることで、テンプレートの不足やレビュー観点の甘さを改善できます。

そのうえで、運用が安定してきた段階では、DORAのFour Keys（デプロイ頻度、変更リードタイム、変更失敗率、MTTR）を成果指標として確認します。特に、仕様の曖昧さによる手戻りが減れば、変更リードタイムや変更失敗率の改善が期待できます。

Findy Team+のように、PRのコミット〜マージまでのサイクルタイム、プロジェクト全体のプロセスタイムや、Four Keysの推移を継続的に見られる環境があれば、仕様駆動開発とAI活用の効果をより追いやすくなります。

まずは運用の近接指標を見て、仕組みが回る状態を作るところから始めましょう。

まとめ：仕様を「育てる」文化がAI時代の開発品質を決める

本記事のポイントを整理します。

• 仕様駆動開発（SDD） は、AIエージェントに実装を委ねる前に仕様を合意しておくことで、手戻りと認識齟齬を構造的に減らす開発アプローチです
• TDDとSDDは対立しない ：仕様駆動開発は「何を作るか」の合意を先行させ、TDDは「作ったものが正しいか」をコードで検証します。両者は組み合わせて使えます
• スクラムとの共存は可能 ：「仕様ファイル作成をスプリント内の正式なタスクとして扱う」という運用で、アジャイルの速度を保ったまま仕様の品質を担保できます
• 導入は1スプリント分のスペックファイル1本から ：全機能に一度に適用しようとせず、小さく試して反復することが定着の近道です
• 効果を観測する ：効果を定量的に観測することで、さらに改善サイクルを回すことが可能になります

仕様駆動開発は銀の弾丸ではありません。チームが仕様を継続的に書き、レビューし、更新し続ける実践の積み重ねが、AI時代の開発品質を支えます。

仕様駆動開発をこれから実践したい方や、仕様駆動開発導入後の効果を定量的に把握したい方には、Findy Team+の2週間無料トライアルをお試しください。

参考・出典

※1 GitHub Blog, Spec-driven development with AI: Get started with a new open source toolkit, 2025-09-02.
https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
※2 Martin Fowler, TestDrivenDevelopment.
https://martinfowler.com/bliki/TestDrivenDevelopment.html
※3 GitHub github/spec-kit README.
https://github.com/github/spec-kit
※4 Kiro Blog, Introducing Kiro, 2025-07-14.
https://kiro.dev/blog/introducing-kiro/
※5 Andrej Karpathy, X post on “vibe coding”, 2025-02-02.
https://x.com/karpathy/status/1886192184808149383
※6 Kiro Blog, Kiro is generally available, 2025-11-17.
https://kiro.dev/blog/general-availability/
※7 Kiro Docs, Feature Specs.
https://kiro.dev/docs/specs/feature-specs/
※8 EARS format.
https://kiro.directory/tips/ears-format
※9 Kiro Docs, Hooks.
https://kiro.dev/docs/hooks/