仕様駆動開発（SDD）とは？Kiro・Spec Kit で広がる AI 開発手法を解説

仕様駆動開発（SDD: Spec-Driven Development）は、最初に仕様を固め、それを「信頼できる唯一の情報源」として AI にコード・テスト・ドキュメントを生成させる開発手法です。この記事では、仕様駆動開発が広まった経緯、AWS Kiro と GitHub Spec Kit の仕組み、仕様の書き方、課題と限界、組織で実践するときの考え方を解説します。

---

仕様駆動開発とは

仕様駆動開発とは、AI にコードを書かせる前に「何を作るか」「どう振る舞うべきか」を仕様として明文化し、その仕様を正としてコード生成・テスト・レビューを進める開発手法です。

背景にあるのは、バイブコーディングの課題です。曖昧な指示で AI に作らせると、AI が前提を勝手に補完し、意図と違う実装が生まれ、認識合わせと手戻りのコストが膨らみます。この反省から「上流で仕様を固めてから AI に渡す」流れが 2025年後半に急速に広まりました。

仕様駆動開発は、開発プロセス全体を AI 前提で設計し直す AI駆動開発（AIDD）の中の、上流工程に焦点を当てたアプローチと位置づけられます。

広まった契機: AWS Kiro と GitHub Spec Kit

仕様駆動開発という言葉を一般化させたのは、2025年に登場した 2 つのツールです。

AWS Kiro（2025年7月発表、同年11月に一般提供開始）は、仕様を中心に据えた AI IDE です。1 つのプロンプトから次の 3 ファイルを段階的に生成し、各段階で人間の承認を挟みます。

• requirements.md: 要求をユーザーストーリーに展開し、EARS 記法で受け入れ基準を記述する
• design.md: コードベースと承認済み要件をもとに、データフローやインターフェースなどの技術設計をまとめる
• tasks.md: 依存関係順に並んだ実装タスクへ分解する

GitHub Spec Kit（2025年9月公開）は、既存の AI コーディングエージェント（GitHub Copilot、Claude Code、Gemini CLI など）に仕様駆動のワークフローを追加するオープンソースのツールキットです。/specify（誰のどんな課題を解くかから仕様を生成）→ /plan（技術スタックを指定して実装計画）→ /tasks（検証可能なタスクへ分解）→ 実装、という 4 段階で進めます。

どちらにも共通するのは、「AI との対話の結果」を仕様ファイルとして残し、実装がその仕様に従っているかを検証できる形にすることです。

従来の開発手法との違い

「仕様を先に書く」と聞くとウォーターフォール開発を連想しますが、両者は別物です。

ウォーターフォールの仕様書が「人間が読むための文書」で、実装が進むにつれて乖離しがちだったのに対し、仕様駆動開発の仕様は AI への入力そのものです。仕様を直せば実装に反映され、実装からの学びは仕様に還元する。この反復を前提にしている点が決定的に違います。

仕様の書き方: EARS 記法と Gherkin

仕様駆動開発では、曖昧さのない仕様の書き方として 2 つの記法がよく使われます。

EARS 記法（Easy Approach to Requirements Syntax）は、要求文を「（条件）、システムは（動作）しなければならない」という定型の語順で書く手法です。常時要件（Ubiquitous）、状態駆動（While）、イベント駆動（When）、望ましくない挙動（If-Then）などのパターンがあり、Kiro の requirements.md が採用したことで広く知られるようになりました。

Gherkin（Given / When / Then） は、受け入れ基準を「前提・操作・期待結果」の 3 段で書く記法です。「Given: ログイン済みのユーザーが、When: 注文を確定したとき、Then: 確認メールが送信される」のように、そのままテストシナリオとして使える粒度で書きます。

gaipack でも、受け入れ基準を Gherkin 形式で顧客と事前合意することを開発ルールにしています。仕様の曖昧さを実装前に潰しておくと、AI の生成物を「合意した基準を満たすか」で機械的に検証でき、レビューの争点が明確になります。

仕様駆動開発の課題と限界

仕様駆動開発は万能ではありません。導入前に知っておきたい限界が 3 つあります。

• 小さな変更にはオーバーヘッドが大きい: 数時間で終わるバグ修正のために仕様 3 ファイルを書くのは割に合いません。使い捨てのプロトタイプや単純な CRUD にも過剰です
• 仕様のメンテナンスコスト: 実装中の学びを仕様に還元しないと、仕様と実装が乖離して形骸化します。「書いて終わり」の運用では、ウォーターフォールの仕様書と同じ道をたどります
• 定義がまだ揺れている: ツールごとに「仕様駆動」の意味する範囲が異なります。Martin Fowler のサイトに掲載された分析も、仕様を書きっぱなしにせず「仕様を書く → 実装する → 学ぶ → 仕様を更新する」の反復として運用すべきだと指摘しています

つまり、仕様駆動開発が効くのは「本番運用を前提とし、複数人・複数機能で整合性が問われる開発」です。適用対象を選ぶことが、手法そのものと同じくらい成果を左右します。

組織で回すための実践

ツールを導入するだけでは、仕様駆動開発は個人の作業改善で止まりがちです。チームや組織の開発方式にするには、仕様の書き方と検証の仕組みを共通化する必要があります。gaipack では次のような形で実践しています。

• 仕様の階層化: プロジェクト計画から画面定義・受け入れ基準まで仕様を階層で管理し、上位の設計に下位の仕様が準拠する構造を作る。機能をまたぐ整合性を、レビューの頑張りではなく構造で担保する
• ガードレールの明文化: 根拠のない仕様を AI にも人にも書かせない、未確定事項は TBD として確認先と期日を明示する、受け入れ基準は Gherkin で書く、といったルールを仕様作成の前提にする
• スキルとしての標準化: 仕様生成・実装・テスト・トレーサビリティ確認の手順を再利用可能なスキルとして整備し、案件をまたいで同じ品質で回せるようにする

このハーネス（AI が期待どおりの結果を出せるよう制約と検証を組み込んだ実行環境）の作り方は「AIエージェントに「ルールを破らせない」仕組みをどう作ったか」で詳しく紹介しています。仕様以外も含めて AI に何を読ませるかを設計する考え方は「コンテキストエンジニアリングとは」を参照してください。

よくある質問

仕様駆動開発とバイブコーディングはどちらを使うべきですか？

用途で分かれます。アイデア検証や試作は速さを優先してバイブコーディング、本番運用を前提とした開発は仕様駆動開発が向きます。試作で得た学びを仕様に起こして本開発へ進む、という組み合わせも実践的です。

ウォーターフォールに戻るということですか？

戻りません。ウォーターフォールの仕様書は一度固めたら変更しにくい前提でしたが、仕様駆動開発の仕様は AI への入力であり、更新と再生成を繰り返す前提です。上流を重視する点は共通しますが、反復を織り込んでいる点が異なります。

何から始めればよいですか？

新規の 1 機能を対象に、Spec Kit や Kiro で「仕様を書いてから AI に実装させる」流れを一度体験するのが早道です。要件定義そのものの品質から整えたい場合は、AI で要件定義を構造化する AIDD 要件定義のようなサービスを使う方法もあります。

まとめ

• 仕様駆動開発（SDD）とは、仕様を唯一の情報源として AI にコードを生成させ、仕様で検証する開発手法。バイブコーディングの手戻り問題への反省から 2025年後半に普及した
• AWS Kiro と GitHub Spec Kit が代表的なツールで、要求 → 設計 → タスク → 実装の段階的なワークフローを提供する
• 仕様の書き方には EARS 記法や Gherkin が使われ、曖昧さを実装前に取り除く
• 小さな変更にはオーバーヘッドが大きく、仕様の更新を怠ると形骸化する。適用対象の選定と、組織としての仕組み化が成果を分ける

KDDIアイレットの gaipack は、要件定義から実装・テストまで仕様を軸に整合を取る AI駆動開発のサービス群を提供しています。仕様駆動開発をチームの開発方式として定着させたい方は、お気軽に KDDIアイレットへお問い合わせください！