仕様駆動開発（SDD）とは？バイブコーディングとの違い・Spec Kit／Kiro／EARS記法【2026年版】

執筆: 笠井秀行（x3d株式会社 CTO / 主席研究員）
公開日: 2026年7月21日

【結論】仕様駆動開発（SDD）とは、自然言語の仕様書を起点にAIエージェントへ実装させる開発手法です。

GitHubが2025年9月2日にOSSツールキット「Spec Kit」を公開、AWSは仕様駆動のIDE「Kiro」を2025年11月17日に一般提供開始。主要ベンダーが揃って推す標準手法になった
「思いつきの指示で書かせる」バイブコーディングと対をなし、仕様→計画→タスク→実装の順で進める
使い捨ての試作はバイブ、本番・長期保守のコードは仕様駆動——という使い分けが実務の判断基準

この記事では、AIコーディングの品質に課題を感じる開発責任者・PM・エンジニア向けに、仕様駆動開発の定義・バイブコーディングとの対比・Spec Kit／Kiro／EARS記法などの代表ツール・手法・導入判断の基準を解説します。

仕様駆動開発（SDD）とは — 定義

仕様駆動開発（SDD: Spec-Driven Development）とは、自然言語で書いた仕様書を「唯一の正（single source of truth）」とし、その仕様からAIエージェントに計画・実装・検証を進めさせる開発手法です。

従来の開発では、仕様書は「コードを書き始めたら捨てられる足場」でした。仕様駆動開発はこの関係を逆転させます。GitHubはSpec Kitの公開にあたり「仕様は実行可能（executable）な成果物になり、実装を導くのではなく実装を直接生成する」と説明しています（出典：GitHub公式ブログ（2025年9月2日））。

技術コンサルティング企業Thoughtworksは、2025年11月のTechnology Radar Vol.33で仕様駆動開発を「Assess（評価・試用段階）」に位置づけ、「構造化された機能仕様から始まり、複数のステップを経て小さな断片・解決策・タスクに分解していくワークフロー」と整理しました（出典：Thoughtworks Technology Radar）。用語の定義はまだ揺れていますが、「AIに書かせる前に、何を作るかを構造化して固定する」という中核は共通しています。

バイブコーディングとの対比 — なぜ仕様駆動が必要になったか

仕様駆動開発は、2025年に広まった「バイブコーディング」の限界への回答として登場しました。バイブコーディングは、Andrej Karpathy氏が2025年2月に提唱した、自然言語の指示でAIにコードを書かせる開発スタイルです（詳しくはバイブコーディングとは？意味・やり方・企業導入の注意点）。試作の速度は劇的に上がる一方、「意図と実装のずれ」「仕様が残らない」「保守できないコード」という課題が本番開発では顕在化しました。

観点	バイブコーディング	仕様駆動開発（SDD）
起点	思いついた指示（プロンプト）	構造化された仕様書
進め方	指示→生成→動かして確認の反復	仕様→計画→タスク分解→実装の段階進行
成果物	コードのみ（仕様は残らない）	コード＋仕様・計画・タスクの文書一式
強み	試作・検証の速度	再現性・トレーサビリティ・チーム開発
向く場面	プロトタイプ・使い捨てツール	本番システム・長期保守・複数人開発

両者は排他的ではありません。x3dの支援現場でも「探索はバイブで速く、本番は仕様から」という使い分けが定着しつつあります。この判断基準は後述します。

代表ツール1: GitHub Spec Kit — エージェント非依存のOSSツールキット

GitHub Spec Kitは、GitHubが2025年9月2日にMITライセンスで公開したOSSツールキットです。Specify CLIとテンプレート群で構成され、GitHub Copilot・Claude Code・Gemini CLIをはじめ30以上のAIコーディングエージェントに対応します（出典：github/spec-kit リポジトリ）。既存のエディタ・エージェントをそのまま使える「後付け型」である点が特徴です。

ワークフローはスラッシュコマンドで段階的に進みます（2026年7月時点の最新版はv0.12.5）。

/speckit.constitution: プロジェクトの憲章（不変の原則）を定める
/speckit.specify: 「何を・なぜ作るか」を仕様化する（技術選定はまだ書かない）
/speckit.plan: 技術スタックとアーキテクチャを決め、実装計画を作る
/speckit.tasks: 実装タスクに分解する
/speckit.implement: タスクを実行してコードを生成する

代表ツール2: Kiro — 仕様駆動を前提に設計されたAWSのIDE

Kiro（キロ）は、AWSが開発した仕様駆動前提のエージェント型IDEです。2025年7月にプレビュー公開され、2025年11月17日に一般提供（GA)が開始されました（出典：AWS公式ブログ（2025年11月17日））。

Kiroの仕様（Spec）は3つのファイルで構成されます。要求を書くrequirements.md、技術設計を書くdesign.md、実装計画を書くtasks.mdです。requirements.mdの受け入れ条件には、後述するEARS記法が採用されており、曖昧さのない要求を書けるよう設計されています（出典：Kiro公式ドキュメント）。GA版では、仕様と実装の整合を検証するプロパティベーステストや、ターミナルで使えるKiro CLIも追加されました。

EARS記法 — 要求の曖昧さを構文で排除する

EARS（Easy Approach to Requirements Syntax）とは、英Rolls-Royce社のAlistair Mavin氏らが考案し、2009年のIEEE国際要求工学会議（RE’09）で発表した要求記述の構文ルールです（出典：EARS公式ガイド（Alistair Mavin））。ジェットエンジン制御システムの要求分析から生まれた手法で、少数のキーワードと語順の固定により、自然言語のまま曖昧さを排除します。

パターン	構文	用途
ユビキタス	The システム shall 振る舞い	常に成り立つ要求
イベント駆動	When トリガー, the システム shall 振る舞い	イベント発生時の応答
状態駆動	While 状態, the システム shall 振る舞い	特定状態の間の動作
オプション	Where 機能条件, the システム shall 振る舞い	特定構成でのみ有効な要求
望ましくない挙動	If 条件, then the システム shall 対処	異常系・エラー処理

航空・自動車など安全性重視の業界で使われてきたこの記法が、KiroのようなAI開発ツールに採用された理由は明快です。AIは書かれたとおりに実装するため、要求の曖昧さがそのまま実装のずれになります。人間のチームなら会話で埋められた行間を、構文ルールで先に埋めておく——これがAI時代にEARS記法が再評価されている背景です。

導入判断の基準 — 仕様駆動を使うべき場面

仕様駆動開発は万能ではありません。Thoughtworksも「ワークフローが重厚で、タスクの規模・種類によって挙動が大きく変わる」「レビューしづらい長大な仕様ファイルが生成されることがある」と課題を指摘しています（出典：Thoughtworks Technology Radar）。x3dの支援現場の知見も踏まえると、判断基準は次のように整理できます。

仕様駆動が向く: 本番システム・長期保守するコード・複数人やAIエージェント複数体で並行開発する場合・監査やトレーサビリティが必要な領域
バイブコーディングで十分: 使い捨ての試作・アイデア検証・個人の小さな業務ツール・数時間で作り直せる規模のもの
迷ったら: 「このコードを3ヶ月後も保守するか」「他人（または別のAI）が引き継ぐか」で判断する。いずれかがYesなら仕様を書く

x3dのAIDDマスター（職能別プログラム）でも、「ノリで書くか、仕様から書くか」の使い分け判断と、Spec Kit／Kiro／EARS記法を使ったSDD実践を扱っています。仕様駆動開発は「AIに任せる範囲を広げながら品質を守る」ための技術であり、その土台にはAIに何を見せるか（コンテキスト）・どんな仕組みで回すか（ハーネス・ループ）の設計があります。この全体像はAIエンジニアリング4層理論で体系化しています。

導入の始め方 — 小さく試して基準を作る

仕様駆動開発の導入は、いきなり全プロジェクトに適用するのではなく、次の順で進めることをおすすめします。

1機能で試す: 中規模の新機能1つを選び、Spec KitまたはKiroで仕様→計画→実装まで一通り回す
仕様の粒度を調整する: 生成された仕様が過剰・過小でないかをチームでレビューし、テンプレートを自社流に調整する
使い分け基準を明文化する: 「どの規模・領域から仕様駆動を必須にするか」をルール化する
開発フロー全体に組み込む: Issueテンプレート・レビュー基準・CIとの連携まで含めて定着させる

仕様駆動開発は、開発フロー全体をAI前提に再設計するAI駆動開発（AIDD）の中核プラクティスです。組織的な導入と人材育成を体系的に進めたい場合は、AI時代のエンジニア・PM育成研修もご活用ください。

よくある質問（FAQ）

Q1. 仕様駆動開発（SDD）とは何ですか？

仕様駆動開発とは、自然言語で書いた仕様書を唯一の正とし、そこからAIエージェントに計画・実装・検証を進めさせる開発手法です。仕様→計画→タスク分解→実装の段階を踏むことで、AIコーディングの再現性と品質を確保します。

Q2. 仕様駆動開発とバイブコーディングの違いは何ですか？

起点と成果物が違います。バイブコーディングは思いついた指示から始まり、コードだけが残ります。仕様駆動開発は構造化した仕様から始まり、仕様・計画・タスクの文書とコードが揃って残ります。試作はバイブ、本番は仕様駆動が基本の使い分けです。

Q3. GitHub Spec Kitとは何ですか？

GitHubが2025年9月2日にMITライセンスで公開した、仕様駆動開発のためのOSSツールキットです。Specify CLIとテンプレートで構成され、GitHub Copilot・Claude Code・Gemini CLIなど30以上のAIコーディングエージェントに対応しています。

Q4. Kiroとは何ですか？

AWSが開発した仕様駆動前提のエージェント型IDEです。2025年7月のプレビューを経て2025年11月17日に一般提供が開始されました。要求・設計・タスクの3ファイルで仕様を管理し、要求の記述にEARS記法を採用している点が特徴です。

Q5. EARS記法とは何ですか？

Rolls-Royce社のAlistair Mavin氏らが考案し2009年に発表した、要求記述の構文ルールです。When・While・If等のキーワードと語順の固定により、自然言語のまま要求の曖昧さを排除します。KiroのようなAI開発ツールにも採用されています。

Q6. 仕様駆動開発はどんな場面に向いていますか？

本番システム、長期保守するコード、複数人・複数エージェントでの並行開発、監査対応が必要な領域に向いています。逆に使い捨ての試作やアイデア検証には重厚すぎるため、バイブコーディングで速く回すほうが適しています。

Q7. 仕様駆動開発に欠点はありますか？

あります。ワークフローが重厚で、小さなタスクには過剰になりがちです。Thoughtworksも、レビューしづらい長大な仕様ファイルが生成される場合があると指摘しています。適用範囲の線引きと仕様粒度の調整が導入の鍵になります。

Q8. 仕様書は誰が書くのですか？

初稿はAIが生成し、人がレビュー・修正するのが標準的な流れです。Spec KitもKiroも、自然言語の指示から仕様のドラフトを自動生成します。人の仕事は「何を・なぜ作るか」の判断と、生成された仕様の妥当性確認に集中します。

Q9. x3dで仕様駆動開発を学べる研修はありますか？

あります。x3dのAI時代のエンジニア・PM育成研修では、AIエンジニアリング4層理論を土台に、職能別プログラム「AIDDマスター」でバイブコーディングとの使い分け判断やSpec Kit／Kiro／EARS記法を使ったSDD実践を扱っています。

参考文献・出典

本記事は2026年7月時点の公開情報に基づいています。ツールの仕様・バージョン・提供形態は変化が速いため、最新情報は各公式サイトをご確認ください。

笠井秀行（かさいひでゆき）
x3d株式会社（クロスサード）CTO / 主席研究員（テクニカルフェロー）。AIシステム・AIエージェント開発、生成AIの実装・内製化支援を統括。x3dは2017年から企業向けAI導入・研修に従事し、累計1,700社超・受講者5,000名超に生成AI研修・開発支援を提供してきた。技術と現場運用の両面から、企業のAI活用の内製化を支援している。

x3d株式会社では、本記事で解説した仕様駆動開発（SDD）を含むAI駆動開発の企業研修・導入支援を提供しています。「速く作る」と「品質を守る」を両立する開発体制づくりは、まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら