AI活用ガイドAI活用ガイド

仕様駆動開発(SDD)とは何か|KiroとClaude Codeで実践する方法

sdd-kiro-claude-code
プロンプトを書けばコードが出てくる。バイブコーディングの快適さに慣れた開発チームが、本番投入の段階で品質の壁にぶつかるケースが増えています。仕様のないコード生成は、テストのない開発と同じ危うさを抱えています。2026年、その課題を解決する手法として急速に広がっているのが「仕様駆動開発(SDD:Spec-Driven Development)」です。

目次

この記事でわかること
仕様駆動開発(SDD)の基本プロセスとバイブコーディングとの違い
バイブコーディングだけでは本番投入が難しくなる3つの理由
Kiro・Claude Code・Spec Kitの使い分けと、DX推進担当者が知るべき発注のポイント

仕様駆動開発(SDD)とは

sdd-kiro-claude-code

仕様駆動開発は、自然言語で書いた仕様書をAIに渡し、「仕様策定→コード生成→仕様との整合性検証」のサイクルで開発を進める手法です。

従来の「コードが主、仕様書が従」という関係を逆転させ、仕様書を開発の中心に据える点が特徴です。

SDDの定義と基本プロセス

SDDの基本プロセスは4ステップです。

Step 1: 仕様策定(Specify)

ユーザーストーリー・機能要件・制約条件を自然言語で記述する。

Step 2: 設計(Plan)

仕様書をもとにAIがアーキテクチャタスク分解を提案する。

Step 3: 実装(Implement)

AIが仕様に沿ってコードを生成する。

Step 4: 検証(Verify)

生成コードが仕様を満たしているかを自動テストで確認する。

AWS Kiroの「Requirements→Design→Implementation」モデルもこの流れに沿っています。開発者の仕事は「コードを書くこと」から「仕様を書き、AIの出力をレビューすること」に変わります。

バイブコーディングとSDDの決定的な違い

sdd-kiro-claude-code

バイブコーディングは「プロンプト→コード→動作確認」で即興的にコードを生成する手法です。SDDは「仕様→コード→仕様との検証」で、事前定義した仕様がAIの出力基準になるため品質の再現性が高くなります。

実務上の使い分けはシンプルです。探索フェーズ(PoC・プロトタイプ)ではバイブコーディング、収束フェーズ(本番実装・チーム開発)ではSDD。対立ではなく補完の関係です。

バイブコーディングの"限界":本番投入で起きる3つの問題

結論から言うと、バイブコーディングの現実的な射程はプロトタイピングまでです。本番環境に投入する段階で、以下の3つの問題が表面化します。

問題1:仕様がないから「何を作ったのかわからない」

バイブコーディングで作ったシステムに残るのはプロンプト履歴だけです。プロンプト履歴は仕様書にはなりません。引き継ぎ時に「このシステムは何をするものか」を説明できず、保守・改修のたびに全体像を把握し直す工数が発生します。

問題2:コンテキスト管理の限界でコードの一貫性が崩れる

AIとの対話が長くなると、AIがコンテキストウィンドウの制約で過去の文脈を見失い、矛盾するコードを生成し始めます。モジュールAとモジュールBで異なるデータ構造を使っていた、認証ロジックが2か所で重複していた、といった問題が典型です。

SDDでは仕様書が常に「真実の源泉(Single Source of Truth)」として存在するため、AIのコンテキストが切れても仕様書に立ち返ることで一貫性を保てます。

問題3:テストケースの根拠がないから品質を保証できない

仕様がなければ「何をテストすべきか」も定義できません。バイブコーディングで生成されたコードに対して「動いているから大丈夫」という判断しかできず、エッジケースやセキュリティの検証が抜け落ちます。

複数の研究機関の調査では、AI生成コードの脆弱性混入率が人間によるコードより高い傾向が報告されています。SDDでは仕様書から自動的にテストケースを導出できるため、品質保証の根拠が明確になります。

Kiro・Claude Code・Spec Kit:SDD対応ツール3つの比較と使い分け

2026年現在、SDDを実践できる主要ツールは3つあります。それぞれの特徴と向いている場面を整理します。

3ツールの使い分け早見表
Kiro:新規プロジェクトをゼロから始める場合。ワンストップで完結したいチーム向け
Claude Code + cc-sdd:既存のGitHubワークフローにSDDを組み込みたい場合
Spec Kit:ツールに縛られず、仕様書フォーマットをチーム標準にしたい場合

AWS Kiro:仕様からコード・テストまでワンストップ

KiroはAWS製のAgentic IDEで、2025年11月にGA(一般提供)となりました。VS Codeベースで、Amazon Bedrock経由のClaudeモデルを使用します。最大の特徴は仕様策定→設計→実装の3フェーズをIDE内で完結できる点です。

導入事例では、ヤマトプロテックがAI-OCR書類電子保管システムを2日で構築し、手入力作業を85%以上削減しています(出典:AWS公式ブログ)。エスツーアイは実働約10日間で経費精算システムを新規開発しました(出典:AWS公式ブログ)。


Kiro: Bring engineering rigor to agentic development

Kiro helps you bridge the gap from AI coding to engineering: manage intent, complete long-running tasks across large codebases, validate code correctness with an agent that learns how you work.

kiro.dev

og_img


Claude Code(CLAUDE.md):既存ワークフローにSDDを組み込む

プロジェクトルートにCLAUDE.mdファイルを置き、spec.md(仕様書)へのリンクやコーディング規約を記述します。Claude Codeがこのファイルを読み込み、仕様に沿った開発を進めます。

cc-sddフレームワークを使えば、仕様策定→実装→PR作成→レビューまでをスラッシュコマンドで自動化できます。Kiroが「ワンストップIDE」なら、Claude Codeは「既存環境にSDDを後付けする」アプローチです。GitHubベースのワークフローが確立されたチームに向いています。


Claude

Claude は Anthropic が構築した次世代 AI アシスタントです。安全性、正確性、セキュリティを重視してトレーニングされており、カスタマーの最高の仕事をサポートします。

claude.com

og_img

GitHub Spec Kit:仕様テンプレートのオープンソース標準

GitHubが2025年9月に公開したオープンソースツールキットです。2026年5月時点で29の名前付きAIコーディングエージェントとGenericオプションを合わせた計30エージェントに対応しています(出典:github/spec-kit READMEVisual Studio Magazine)。

「specify→plan→tasks→implement」の4ステップワークフローとspec.mdテンプレートを提供します。特定ツールに依存せず仕様書フォーマットを統一できるため、チーム全体でSDDの文化を定着させるのに有効です。


GitHub - github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development

💫 Toolkit to help you get started with Spec-Driven Development - github/spec-kit

github.com

og_img

DX推進担当者が知るべき「SDD発注のポイント」

SDDは開発者だけの話ではありません。開発を外注する立場のDX推進担当者にとっても、発注品質を変える重要な概念です。

開発ベンダーにSDD採用を要件として伝える方法

RFP(提案依頼書)にSDDの要件を盛り込む際は、以下の3点を明記することを推奨します。

ポイント 1
仕様書の成果物定義
「spec.md形式の仕様書を納品物に含めること」
ポイント 2
仕様と実装の整合性検証
「仕様書に基づく自動テストの実行結果を納品時に提出すること」
ポイント 3
仕様変更管理
「仕様変更はspec.mdの更新→承認→実装の順で管理すること」

この3点があるだけで、納品後の「何を作ったのかわからない」問題を大幅に軽減できます。

SDDを採用すると開発コスト・期間はどう変わるか

仕様策定フェーズが追加される分、初期コストは増加します。一般的な目安として、仕様策定に全体工数の15〜20%を見込む必要があります(プロジェクトの複雑さにより変動します)。

しかし手戻り削減の効果は大きく、エスツーアイの事例では仕様が明確だったため手戻りがほぼ発生せず、実働10日間で経費精算システムを開発しました。「仕様を書く時間」は「手戻りを減らす時間」です。投資対効果は十分に見合います。

よくある質問(FAQ)

Q1. 仕様駆動開発(SDD)とテスト駆動開発(TDD)は何が違いますか?
TDDは「テストを先に書く」手法です。SDDは「仕様を先に書き、仕様からコード・テストをAIが生成する」手法で、TDDを包含する上位概念と言えます。
Q2. バイブコーディングとSDDはどちらを選ぶべきですか?
二者択一ではなく使い分けが正解です。プロトタイプはバイブコーディング、本番実装・チーム開発はSDDが適しています。
Q3. SDDを採用すると開発期間は長くなりますか?
仕様策定フェーズが加わるため初期は工数が増えます。しかし手戻りが減り、トータルでは同等か短縮されるケースが多いです。
Q4. 非エンジニアのDX推進担当者でもSDDを理解する必要がありますか?
はい。RFPに「spec.md形式の仕様書を成果物に含めること」の1行を追加するだけでも、納品物の品質管理が変わります。
Q5. spec.md(仕様書)はどのように書けばよいですか?
GitHub Spec Kitのテンプレートが参考になります。ユーザーストーリー・機能要件・制約条件・受入基準の4要素を自然言語で記述します。プログラミング知識は不要です。

まとめ

仕様駆動開発はバイブコーディングの否定ではなく、進化です。探索フェーズ(PoC・プロトタイプ)ではバイブコーディング、収束フェーズ(本番実装・チーム開発)ではSDDという使い分けが2026年の開発トレンドの主軸になりつつあります。

Kiro・Claude Code・Spec Kitのいずれも無料枠で試せます。まずは次の社内プロジェクトで「仕様を先に書いてからAIにコードを生成させる」体験をしてみてください。

自社のDX推進でお悩みではありませんか?
専門のコンサルタントが、貴社の課題に合わせた最適なソリューションをご提案いたします。まずは無料でご相談ください。
無料相談を申し込む
無料相談を申し込む
本記事は最新のAIエージェントを構成パートナーに迎え、人間とAIのハイブリッド体制で執筆・校閲をおこなっています。(ファクトチェック完了:2026-06-02)
プロフィール画像
記事を書いた人
泉川 学

小売業界でブランド品のバイヤーなどを経験したのちIT業界に転身。 株式会社ライブドアのインフラ事業の営業責任者を担当。 ベンチャー企業の運営に関わった後、2016年にデザインワン・ジャパン(現GMOデザインワン株式会社)へ入社。 「エキテン」事業の営業・サポート部門責任者を務めたのち受託開発事業の立ち上げを担当し、 現在は執行役員兼エキテン事業、受託開発事業とその所管グループ会社を統括。

contact お気軽にご連絡下さい。