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

仕様駆動開発は、自然言語で書いた仕様書をAIに渡し、「仕様策定→コード生成→仕様との整合性検証」のサイクルで開発を進める手法です。
従来の「コードが主、仕様書が従」という関係を逆転させ、仕様書を開発の中心に据える点が特徴です。
SDDの定義と基本プロセス
SDDの基本プロセスは4ステップです。
ユーザーストーリー・機能要件・制約条件を自然言語で記述する。
仕様書をもとにAIがアーキテクチャとタスク分解を提案する。
AIが仕様に沿ってコードを生成する。
生成コードが仕様を満たしているかを自動テストで確認する。
AWS Kiroの「Requirements→Design→Implementation」モデルもこの流れに沿っています。開発者の仕事は「コードを書くこと」から「仕様を書き、AIの出力をレビューすること」に変わります。
バイブコーディングとSDDの決定的な違い

バイブコーディングは「プロンプト→コード→動作確認」で即興的にコードを生成する手法です。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つあります。それぞれの特徴と向いている場面を整理します。
AWS Kiro:仕様からコード・テストまでワンストップ
KiroはAWS製のAgentic IDEで、2025年11月にGA(一般提供)となりました。VS Codeベースで、Amazon Bedrock経由のClaudeモデルを使用します。最大の特徴は仕様策定→設計→実装の3フェーズをIDE内で完結できる点です。
導入事例では、ヤマトプロテックがAI-OCR書類電子保管システムを2日で構築し、手入力作業を85%以上削減しています(出典:AWS公式ブログ)。エスツーアイは実働約10日間で経費精算システムを新規開発しました(出典:AWS公式ブログ)。

Claude Code(CLAUDE.md):既存ワークフローにSDDを組み込む
プロジェクトルートにCLAUDE.mdファイルを置き、spec.md(仕様書)へのリンクやコーディング規約を記述します。Claude Codeがこのファイルを読み込み、仕様に沿った開発を進めます。
cc-sddフレームワークを使えば、仕様策定→実装→PR作成→レビューまでをスラッシュコマンドで自動化できます。Kiroが「ワンストップIDE」なら、Claude Codeは「既存環境にSDDを後付けする」アプローチです。GitHubベースのワークフローが確立されたチームに向いています。

GitHub Spec Kit:仕様テンプレートのオープンソース標準
GitHubが2025年9月に公開したオープンソースツールキットです。2026年5月時点で29の名前付きAIコーディングエージェントとGenericオプションを合わせた計30エージェントに対応しています(出典:github/spec-kit README、Visual Studio Magazine)。
「specify→plan→tasks→implement」の4ステップワークフローとspec.mdテンプレートを提供します。特定ツールに依存せず仕様書フォーマットを統一できるため、チーム全体でSDDの文化を定着させるのに有効です。
DX推進担当者が知るべき「SDD発注のポイント」
SDDは開発者だけの話ではありません。開発を外注する立場のDX推進担当者にとっても、発注品質を変える重要な概念です。
開発ベンダーにSDD採用を要件として伝える方法
RFP(提案依頼書)にSDDの要件を盛り込む際は、以下の3点を明記することを推奨します。
この3点があるだけで、納品後の「何を作ったのかわからない」問題を大幅に軽減できます。
SDDを採用すると開発コスト・期間はどう変わるか
仕様策定フェーズが追加される分、初期コストは増加します。一般的な目安として、仕様策定に全体工数の15〜20%を見込む必要があります(プロジェクトの複雑さにより変動します)。
しかし手戻り削減の効果は大きく、エスツーアイの事例では仕様が明確だったため手戻りがほぼ発生せず、実働10日間で経費精算システムを開発しました。「仕様を書く時間」は「手戻りを減らす時間」です。投資対効果は十分に見合います。
よくある質問(FAQ)
Q1. 仕様駆動開発(SDD)とテスト駆動開発(TDD)は何が違いますか?
Q2. バイブコーディングとSDDはどちらを選ぶべきですか?
Q3. SDDを採用すると開発期間は長くなりますか?
Q4. 非エンジニアのDX推進担当者でもSDDを理解する必要がありますか?
Q5. spec.md(仕様書)はどのように書けばよいですか?
まとめ
仕様駆動開発はバイブコーディングの否定ではなく、進化です。探索フェーズ(PoC・プロトタイプ)ではバイブコーディング、収束フェーズ(本番実装・チーム開発)ではSDDという使い分けが2026年の開発トレンドの主軸になりつつあります。
Kiro・Claude Code・Spec Kitのいずれも無料枠で試せます。まずは次の社内プロジェクトで「仕様を先に書いてからAIにコードを生成させる」体験をしてみてください。
小売業界でブランド品のバイヤーなどを経験したのちIT業界に転身。 株式会社ライブドアのインフラ事業の営業責任者を担当。 ベンチャー企業の運営に関わった後、2016年にデザインワン・ジャパン(現GMOデザインワン株式会社)へ入社。 「エキテン」事業の営業・サポート部門責任者を務めたのち受託開発事業の立ち上げを担当し、 現在は執行役員兼エキテン事業、受託開発事業とその所管グループ会社を統括。
AI活用ガイド
AIニュース
AI活用ガイド