株式会社TIMEWELLの濱本隆太です。
2025年、Andrej Karpathyが「Vibe Coding」という言葉をX（旧Twitter）に投稿してから、開発の世界は一変した。CursorやCline、Devin、GitHub Copilot Agentといったツールが次々と登場し、「プロンプトを打てばコードが出てくる」体験は、もはやエンジニアの日常になりつつある。私自身、TIMEWELLの開発現場でこれらのツールを毎日のように使っている。生産性は確実に上がった。だが、正直なところ、Vibe Codingだけでプロダクトを作り切ろうとして、痛い目にあった経験も少なくない。AIが生成したコードが一見動いているように見えて、3日後にバグが連鎖して崩壊する。仕様が曖昧なまま突っ走った結果、チームメンバーが書いたコードとまったく整合しない。そんな「AI開発の落とし穴」に何度もハマった末に、私がたどり着いた考え方がある。それが「AI仕様駆動開発（AI-SDD）」だ。
TDDとBDD──テストが先か、振る舞いが先か
AI仕様駆動開発の話をする前に、ソフトウェア開発の歴史を少しだけ振り返りたい。開発手法の進化を理解しないまま新しい概念を語っても、それは砂上の楼閣に終わるからだ。
テスト駆動開発（TDD）をKent Beckが体系化したのは2003年のこと。「まず失敗するテストを書き、そのテストを通す最小限のコードを実装し、リファクタリングする」──Red・Green・Refactorと呼ばれるこのサイクルは、当時のソフトウェア業界に衝撃を与えた。それまで「コードを書いてからテストする」のが常識だった世界で、順序を逆転させたわけだ。テストを先に書くことで、開発者は「このコードは何を満たすべきか」を実装前に考えざるを得なくなる。結果として設計の質が上がり、バグの早期発見にもつながった。
ただし、TDDには構造的な限界がある。テストコードはプログラミング言語で書かれるため、エンジニア以外には読めない。プロダクトマネージャーが「この機能はビジネス要件を満たしているか？」を確認したくても、JUnitやpytestのコードを眺めて判断するのは現実的ではない。TDDが担保するのはあくまで「技術的な正しさ」であり、「ビジネス的な正しさ」は射程外なのだ。
この課題を解決するために2006年頃に登場したのが、振る舞い駆動開発（BDD）だ。Dan Northが提唱したこの手法は、TDDを一段上のレイヤーに引き上げた。BDDでは、Gherkin記法と呼ばれる自然言語に近いフォーマットで「システムの振る舞い」を記述する。「Given（前提条件）→ When（操作）→ Then（期待結果）」という構造は、エンジニアだけでなく、QAチームやプロダクトオーナー、ビジネスサイドの担当者にも読める。CucumberやSpecFlowといったツールがこのGherkin記法を実行可能なテストに変換してくれるため、「仕様書がそのままテストになる」という理想に一歩近づいた。
ベリサーブの調査によれば、BDDを導入したプロジェクトでは、開発者とビジネス担当者間の認識齟齬によるやり直しが平均30〜40%減少するというデータもある [1]。つまりBDDは、「何を作るべきか」についてチーム全員の認識を揃えるコミュニケーションツールとしても機能するわけだ。
しかしBDDにも弱点はある。Gherkin記法でシナリオを書くのは、思ったほど簡単ではない。特に複雑なビジネスロジックをGiven/When/Thenの型に押し込もうとすると、シナリオが冗長になりすぎたり、逆に抽象的すぎて実装の指針にならなかったりする。そして何より、TDDもBDDも「人間がコードを書く」ことが前提の手法だ。AIがコードを生成する時代に、テストや振る舞いの記述だけで十分なのだろうか。
仕様駆動開発（SDD）── 仕様を「北極星」にする
2025年後半から、Vibe Codingの反動として「仕様駆動開発（Spec-Driven Development / SDD）」という概念が急速に広まり始めた。GitKon 2025でのErik Hanchettの講演「Stop Vibe Coding Everything」は象徴的だった。彼のメッセージはシンプルだ──「AIに何を作るかを正確に伝えないかぎり、AIは正確なものを作れない」。
SDDの核心は、コードを書く前に仕様を徹底的に定義することにある。ここで言う「仕様」とは、従来のウォーターフォール型の要件定義書のような重厚長大なドキュメントではない。ユーザーストーリー、受け入れ基準、API契約、画面遷移、エッジケースの列挙──こうした情報を、AIが解釈可能な粒度で構造化したものだ。KDDIのエンジニアチームがメッセージ配信プラットフォームの開発で実践した事例では、SDDの導入によって「AIが生成したコードの手戻り率が60%以上減少した」と報告されている [2]。
SDDの開発フローは、大きく3つのフェーズに分かれる。第1フェーズの「Design」では、ユーザーストーリーと受け入れ基準を定義し、アーキテクチャとAPIの設計を固める。第2フェーズの「Build」では、定義した仕様に基づいてAIがコードを生成し、仕様から自動生成されたテストで検証する。第3フェーズの「Refine」では、変更が発生するたびに仕様を更新し、仕様を「生きたドキュメント」として維持する。
ここで重要なのは、SDDがTDDやBDDを否定するものではないという点だ。むしろSDDは、TDDとBDDの系譜を正当に受け継いでいる。TDDが「テストファースト」でコードの品質を担保し、BDDが「振る舞いファースト」でビジネス要件との整合を図ったのと同じように、SDDは「仕様ファースト」で開発の全体像を規定する [3]。
AI駆動開発の現在地──全自動の幻想と現実
一方で、「AI駆動開発」という言葉も2025年を通じて急速に浸透した。日経クロステックの報道によれば、2026年はAIが要件定義から設計、実装、テスト、運用保守まで開発ライフサイクル全体をカバーする「全自動開発」の萌芽が見える年になるという [4]。国内大手SIer各社もAI駆動開発への投資を加速させており、Findyが主催したAI Engineering Summit Tokyo 2025では、CursorのVP of Developer ExperienceであるLee氏が「2025年だけで最も良いツールが7回変わった」と語っている [5]。
ただし、私の実感として言えば、「AI駆動開発＝AIに丸投げ」という理解は危険だ。TIMEWELLでは複数のAI開発ツールを業務に組み込んでいるが、AIが真価を発揮するのは「明確な指示がある場面」に限られる。曖昧なプロンプトからAIが推測で書いたコードは、一見動くように見えても、エッジケースの考慮が抜けていたり、既存のコードベースとの整合性が取れていなかったりする。「AIは詳細な指示に従うことには長けているが、曖昧な指示から意図を汲み取ることは苦手」なのだ [3]。
これはAIの欠陥ではなく、特性だ。LLMは膨大なコードパターンを学習しているから、明確なインプットがあれば驚くほど正確なアウトプットを返す。しかし「いい感じにやっておいて」という指示には、「いい感じ」の定義がない以上、平均的で無難な──つまり退屈で使い物にならないコードしか返せない。ここに、Vibe Codingの根本的な限界がある。
AI仕様駆動開発（AI-SDD）── なぜ「仕様×AI」の掛け算が必要なのか
ここまでの話を整理しよう。TDDは「テスト」を起点に技術的品質を担保する。BDDは「振る舞い」を起点にビジネス要件との一致を図る。SDDは「仕様」を起点に開発全体の方向性を定める。そしてAI駆動開発は、AIの生成能力を開発プロセスに組み込む。どれも正しい。だが、それぞれ単独では足りない。
私が提唱する「AI仕様駆動開発（AI Spec-Driven Development / AI-SDD）」は、SDDとAI駆動開発を意図的に融合させた開発手法だ。一言で定義するなら、**「AIを最大限に活用するために、仕様の質を最大限に高める開発アプローチ」**ということになる。
従来の駆動開発との違いを整理するとこうなる。TDDでは「テストコード」が開発を駆動する一次成果物だった。BDDでは「Gherkinシナリオ」がその役割を担った。SDDでは「仕様書」が中心に据えられる。AI-SDDでは、仕様書は依然として中心にあるが、その仕様書自体がAIとの協働で作成・進化し、かつAIが実装・テスト・レビューの全工程で仕様を参照しながら動く。つまり、仕様がAIの「コンテキストウィンドウ」における最上位の情報源になるのだ。
具体的なワークフローを説明しよう。まず、人間とAIが対話しながら仕様を策定する。この段階ではCursorやClaude、ChatGPTといったツールを使い、ユーザーストーリーの洗い出し、受け入れ基準の定義、API設計、画面仕様、エッジケースの列挙を行う。ポイントは、AIに「仕様を書かせる」のではなく、AIを「壁打ち相手」として使い、人間が最終的な仕様をオーソライズすることだ。AIに仕様のドラフトを出させた後、「この仕様に矛盾はないか？」「見落としているエッジケースはないか？」と問いかけるだけで、仕様の精度は格段に上がる。
次に、確定した仕様をAIエージェントに渡し、実装とテストコードの同時生成を行う。ここが従来のSDDとの最大の違いだ。SDDでは仕様から人間がコードを書く場面も多かったが、AI-SDDではAIが仕様を直接読み取り、コードとテストを一気に生成する。仕様が十分に明確であれば、AIの生成精度は飛躍的に高まる。TIMEWELLの社内プロジェクトで計測したところ、仕様の詳細度を「ユーザーストーリー＋受け入れ基準＋エッジケース5件以上」のレベルまで引き上げた場合、AIが生成したコードのファーストパス合格率（修正なしでテストをパスする率）が従来の35%から78%に跳ね上がった。
そして、開発中に発生した変更や気づきは即座に仕様に反映する。この「仕様の継続的更新」もAI-SDDの重要な柱だ。コードだけを修正して仕様を放置すると、次にAIがコードを生成する際に古い仕様を参照してしまい、不整合が生まれる。仕様はプロジェクトの「Single Source of Truth（唯一の信頼できる情報源）」であり続けなければならない。
4つの駆動開発を俯瞰する──何が、何を、駆動するのか
ここで、TDD・BDD・SDD・AI-SDDの関係性を改めて整理しておきたい。
TDDの世界では、開発者がテストコードを書き、そのテストが実装を駆動する。焦点は「コードが技術的に正しいか」であり、検証のサイクルはRed→Green→Refactorの数分〜数十分単位だ。エンジニア個人の技術力に依存する部分が大きく、ビジネスサイドとの接点は薄い。
BDDの世界では、プロダクトオーナーやQAを含むチーム全体がGherkinシナリオを書き、その振る舞い定義が実装を駆動する。焦点は「システムがユーザーの期待通りに振る舞うか」であり、ビジネス価値との整合が検証の中心になる。コミュニケーションツールとしての側面が強く、チーム開発に向いている。
SDDの世界では、仕様書が開発全体を駆動する。要件定義からテスト、デプロイまで、あらゆる工程が仕様に立ち返る。BDDとの違いは、SDDの仕様がGherkinシナリオに限定されず、API定義、データモデル、非機能要件まで包括的にカバーする点だ。
そしてAI-SDDでは、仕様書が人間とAIの両方を駆動する。人間は仕様を読んで判断し、AIは仕様を読んでコードを生成する。仕様の策定自体にもAIが参加するが、最終的なオーソリゼーションは人間が行う。この「人間がWhatを決め、AIがHowを実行する」という分業こそが、AI-SDDの本質だ。
私がこの手法にこだわるのには理由がある。TIMEWELLはAIを活用した業務支援サービスを提供している会社だが、私たち自身がAIを使ってプロダクトを開発する中で痛感したのは、「AIの性能は、インプットの質に律速される」という事実だ。どれだけ高性能なLLMを使っても、仕様が曖昧なら出力も曖昧になる。逆に、仕様さえしっかりしていれば、AIは驚くほど忠実に、高品質なコードを生成してくれる。AIの能力を解放する鍵は、モデルの性能ではなく、仕様の精度にある。
AI仕様駆動開発を、開発現場の「共通言語」に
最後に、なぜ私が「AI仕様駆動開発」という言葉を広めたいと考えているかを率直に話したい。
2026年現在、AI開発ツールの進化は凄まじいスピードで進んでいる。Cursorの「最も良いツールが年に7回変わる」という話が象徴するように、ツールは次々と入れ替わる。しかし、ツールが変わっても変わらないものがある。それが「仕様」だ。Cursorを使おうがCopilotを使おうがClaude Codeを使おうが、良い仕様があれば良いコードが出る。悪い仕様からは、どんなツールを使っても悪いコードしか出ない。
日経クロステックの報道にもあるように、2026年はAIが開発の全工程をカバーし始める年だ [4]。だからこそ、「AIをどう使うか」ではなく「AIに何を伝えるか」にフォーカスすべきタイミングが来ている。TDDがテストの書き方を変え、BDDがチームのコミュニケーションを変えたように、AI-SDDは「仕様の書き方」を変える。そしてそれは、AIとの協働における最も本質的なスキルになると私は確信している。
AI仕様駆動開発という言葉が、開発現場の共通言語として定着する日はそう遠くないと思っている。
参考文献
[1] ベリサーブ. "振る舞い駆動開発（BDD）とは？TDDとの違いからGherkin記法の活用まで徹底解説." https://www.veriserve.co.jp/helloqualityworld/media/20251008001/ (2025-10-08)
[2] KDDI Tech note. "仕様が先導し、AIが実装する─仕様駆動開発（SDD）によるエンタープライズ開発の実践." https://tech-note.kddi.com/n/ne68f4f243f19 (2025)
[3] TestCollab. "From Vibe Coding to Spec-Driven Development." https://testcollab.com/blog/from-vibe-coding-to-spec-driven-development (2025)
[4] 日経クロステック. "AI駆動でシステム開発は全自動へ エンジニアの価値再編." https://xtech.nikkei.com/atcl/nxt/column/18/03401/120200007/ (2025-12)
[5] Findy. "エンジニア採用・組織づくりのトレンド予測2026." https://note.com/yuichiro826/n/n6338ef1df6b5 (2025)