Claude CodeやGitHub Copilot といったAIコーディングエージェントの登場はソフトウェアの開発方法を根本的に変革しました。「自然言語で指示を与えるだけで、AIがコードを書いてくれる」数年前までは夢物語だったことが、今や日常の現実となっています。しかし、導入が拡大するにつれて、以下のような共通の課題が顕在化しています：

• 「3 時間前に立てた計画はどうだったっけ？」 というチャット履歴をスクロールする時間が増加している

• AI にタスクを依頼した後、想定外の機能を実装してしまう（過剰設計）
• 会話が続くにつれて、重要な仕様がコンテキストの中に埋もれてしまう
• セッションを切り替える際、再度AIにコンテキストを説明しなければならない

だからこそ、より多くのチームが純粋な「Vibe Coding（感覚的コーディング）」ワークフローから離れ、Spec-Driven Development（SDDまたは仕様駆動開発）に注目するようになっています。散発的なプロンプトに依存するのではなく、SDDは開発プロセスの中心に仕様を据えます。仕様は実装全体を通じてエンジニアとAI コーディングエージェントの双方にとっての共通参照ポイントとなるのです。

1. Spec-Driven Development（SDD）とは？

1.1 定義

Spec-Driven Development（SDD）とは仕様書を「単一の信頼源（Single Source of Truth）」と位置付け、コーディングエージェントがその仕様に基づいてコード生成を行う開発手法です。

従来の開発では通常「コードファースト」のワークフローが採用されます。開発者がまずコードを書き、その後でドキュメントを更新します。SDD はこれとは逆のアプローチを取ります。実装を開始する前に、チームは構造化された仕様を通じて「何を実装するか」をまず定義します。要件が明確になった時点で、開発者と AI エージェントはその仕様を実装の基盤として活用します。

この「仕様ファースト」の考え方がSpec-Driven Developmentの核となる概念です。

1.2 ソフトウェア開発の進化におけるSDDの位置付け

仕様駆動開発は全く新しい概念ではありません。多くの点において、開発チームが数十年にわたって実践してきた馴染みのあるエンジニアリング原則「要件定義 → 設計 → 実装 → テスト」というワークフローを再構築したものです。異なるのは、このワークフローが現在、AI時代に合わせて適応されている点にあります。

AIコーディングツールの能力が向上するにつれ、チームは大規模開発においてプロンプト単独では不十分であることに気づき始めています。構造化された仕様がなければ、コンテキストは不安定になり、出力結果の制御も困難になります。SDDはすべての情報をチャット会話内に残すのではなく、要件や決定事項を永続的な形式で文書化することで、この問題に対処します。

このアプローチはThoughtworksが2025年11月発行のTechnology Radar Vol.33においてSpec-Driven Developmentを「Assess（評価）」ステージに位置付けたことを契機に、より広範な注目を集め始めました。ほぼ同時期に、AWSも要件→設計→タスク→コード生成というワークフローを軸に据えたAI統合開発環境「Kiro IDE」を発表しています。

1.3 Spec-Driven Development 対 Vibe Coding

Vibe Coding と Spec-Driven Development の違いは日常の開発ワークフローにおいてより明確になります。

2. Spec-Driven Developmentにおける実務的なメリット

Spec-Driven Developmentは2025年〜2026年現在においても依然として新興のプラクティスであり、業界全体としてその影響を測定する統一された方法はいまだ確立されていません。しかし、弊社（Haposoft）では、実際のプロダクションプロジェクトにおいて仕様ファーストのワークフローを導入した結果、納品速度とプロジェクト実行において測定可能な改善が確認されました。これらのワークフローは、後にCafeKit（弊社の新サービス）の基盤となりました。

2.1 プロジェクト全体工数を30％削減

従来の開発ワークフロー（Code-Firstで開発を進め、後からドキュメントを整備する方式）と、SDDおよびCoding Agentを導入した新しい開発ワークフローを比較し、キックオフから本番リリースまでに実際に投入された総工数（Man-Hour）を測定しました。

対象は開発期間3〜12か月程度の中〜大規模なWebシステムおよびSaaS開発プロジェクトです。

分析の結果、プロジェクト全体で約30％の工数削減を確認しました。

工数削減効果は開発ライフサイクル全体にわたって発生しています。

• 要件定義・設計フェーズ
  開発初期段階から構造化された仕様を作成することで、顧客との認識合わせや要件確認のためのコミュニケーション回数を削減できます。また、認証（Authentication）、決済（Payment）、通知（Notification）などの共通機能については、過去プロジェクトで利用した仕様モジュールを再利用できるため、設計工数の削減にもつながります。
• 実装フェーズ
  Coding Agentは仕様を基準としてコードを生成するため、初回から要件に沿った実装を行いやすくなります。その結果、エンジニアとAIとの間で発生するプロンプトの試行錯誤や修正指示の往復回数が減少しました。
• テストフェーズ
  仕様に定義されたAcceptance Criteria（受け入れ条件）をもとにテストケースを生成できるため、実装完了後にテストケースをゼロから作成する必要がありません。
• 手戻り（Rework）削減
  最も大きな効果が現れたのは手戻り工数の削減です。人間とAIが実装前に同じ仕様を共有することで、「実装完了後に要件の解釈違いが発覚する」といったケースを大幅に減らすことができました。これは、日本企業とベトナム企業によるオフショア開発において、言語やコミュニケーションのギャップによって発生しやすい無駄の削減につながっています。
• ドキュメント作成フェーズ
  納品資料や関連ドキュメントは仕様から自動生成できます。ドキュメント品質への要求が高い日本企業に対しても、一貫性のある資料を効率的に作成できます。

2.2 SDLCのデリバリー速度を50％向上

従来のCode-Firstプロジェクトと、SDDワークフローおよびAIコーディングエージェントを活用したプロジェクトについて、キックオフから初回本番リリースまでに要した期間を比較しました。

分析の結果、中〜大規模のグリーンフィールド開発プロジェクトにおいて、最大50％のデリバリー速度向上を確認しました。

主な要因は以下の通りです。

• 要件が仕様として事前に整理・合意されているため、開発途中での認識齟齬が減少する
• Coding Agentが仕様を基準として実装を進められるため、コード生成の精度が向上する
• テストケースを仕様のAcceptance Criteriaから生成できるため、テスト準備にかかる時間を削減できる
• 引継ぎ資料や関連ドキュメントを仕様から生成できるため、開発後工程の負荷を軽減できる

特に、従来は実装後に発覚していた問題の多くを仕様策定段階で発見できることが、デリバリー速度向上の大きな要因となりました。

一方で、小規模な保守案件やホットフィックスでは、仕様作成のオーバーヘッドが得られる効果を上回る場合があります。そのため、CafeKitでは軽微な変更に対して一部フェーズをスキップできる仕組みを用意しています。

2.3 その他の定性的効果

測定可能な指標に加え、Spec-Driven Development導入後には運用面でも以下の改善が確認されました。

• 人間とAIの役割分担の明確化
  仕様は「何を作るか」を定義し、AIはその実装を担います。この役割分担により、開発スピードを維持しながらプロジェクトの方向性を管理しやすくなりました。
• セッションや担当者変更をまたいだ継続性の確保
  Claude Codeのセッションが中断された場合や、担当エンジニアが変更になった場合でも、仕様ファイルが残っていれば新しい担当者が短時間でプロジェクトを引き継ぐことができます。
• ドキュメントの自動蓄積
  要件、設計上の意思決定、プロジェクトの進捗などが構造化されたMarkdownファイルとしてリポジトリ内に保存されます。これにより、数週間から数か月後であってもプロジェクトのコンテキストを再構築しやすくなり、オンボーディングや引継ぎにかかる負荷を軽減できます。これは、日本のPMとベトナムの開発チームが協業するオフショアプロジェクトにおいて特に有効でした。

---

3. SDD の典型的なワークフロー

では、実際の開発現場において Spec-Driven Development はどのように機能するのでしょうか？チームやツールによってワークフローは異なる場合がありますが、ほとんどの SDD プロセスは以下の 6 つのコアフェーズに従います。

フェーズ 1：要件定義

チームは、ビジネス目標、ユーザーが抱える課題、機能要件、非機能要件を自然言語で記述します。この段階では、開発者はしばしば AI ツールと協働しながら、アイデアをユーザーストーリーや受け入れ基準に構造化します。目的は、最初から完璧なドキュメントを作成することではありません。むしろ、「何を構築すべきか」についての共通理解を構築することに重点を置きます。

フェーズ 2：設計

アーキテクチャの決定、データモデル、API 構造、画面フロー、システム動作などを含みます。多くのチームは、特定の技術的決定がなぜなされたかを記録するために、設計ドキュメントや ADR（Architecture Decision Record）を活用します。これらの決定を文書化しておくことは、プロジェクトが拡大したり、新しいエンジニアが参画したりした際に、後々特に有用となります。

フェーズ 3：タスク分解

設計を実行可能なタスクに分解します。「1 タスク＝1 コミット」という基準を採用することで、進捗管理とレビューの効率化が図れます。

フェーズ 4：実装

各タスク単位で AI にコード生成を依頼します。仕様を同時に参照しながら実装を行うため、AI は「全体像を見失う」ことなく、一貫性のあるコードを記述できます。

フェーズ 5：テスト

仕様から導出された受け入れ基準に基づき、テストコードを生成・実行します。仕様とテストが 1 対 1 で対応しているため、カバレッジの可視化が容易になります。

フェーズ 6：レビュー

人間のエンジニアが、仕様との整合性、コード品質、セキュリティを確認します。仕様書が「判断基準」として機能するため、レビューの基準が明確になります。

---

4. Spec-Driven Development における主要ツール

Spec-Driven Developmentへの関心が高まるにつれ、Claude Codeなどの AI 支援ワークフローやコーディングエージェントを取り巻くツールも増加しています。各ツールは SDD に対して異なるアプローチを取っています。

ドキュメンテーションワークフローに注力するものもあれば、要件、実装、テスト、AI 生成コードを一貫して接続するエンドツーエンド環境を提供するものもあります。

4.1 GitHub Spec Kit

GitHub Spec Kit は「AI は明確な仕様に基づいて作業した方が性能を発揮する」という考え方を軸に構築された公式ツールキットです。このツールキットは、実装開始前に PRD、設計ドキュメント、ADR などの文書を作成・管理することを支援します。プロンプトのみに依存するのではなく、開発者はプロジェクトコンテキストをより再利用可能な形式で構造化できます。

4.2 Kiro IDE

Kiro IDE はAWS が提供する AI 統合開発環境です。本プラットフォームは、自然言語による要件から、設計、タスク分解、実装、テスト、コード生成といった構造化されたフェーズへと移行するワークフローをサポートします。AI を単なる自動補完ツールとして扱うのではなく、Kiro は AI エージェントを開発ワークフロー全体の一部として位置付けています。

4.3 claude-code-spec-workflow

OSSコミュニティから生まれた CLI ツールです。Claude Code 向けに SDD フローを実装しており、単一のコマンドで新機能開発ワークフローを起動できます。Claude Code を中心に作業を行っているチームにとって、この種のワークフローは開発中のプロンプト断片化を軽減するのに役立ちます。

4.4 cc-sdd / OpenSpec

このグループの軽量ツール群は、さまざまな哲学に基づき「仕様→タスク→実装」というフローを提供します。選択はプロジェクトの規模や嗜好に依存します。ツールによっても哲学が異なるため、チームはプロジェクト規模やエンジニアリング文化に適合したワークフローを選択できます。

4.5 CafeKit

CafeKitはHaposoftのチームが開発したオープンソースのSDDツールキットです。

本ツールは Claude Code ワークフローに特化して設計されており、6フェーズの Spec-Driven Development プロセスに従います。仕様を静的なドキュメントとして扱うのではなく、CafeKit は仕様を開発全体を通じて実装、テスト、プロジェクト管理と密接に連携させた状態で維持します。

---

5. Spec-Driven Development 導入の始め方

Spec-Driven Developmentをワークフローに導入することに興味をお持ちのチームにとって、移行は一度にすべてを行う必要はありません。多くの場合、開発プロセス全体を即座に再設計しようとするよりも、小規模から始める方が効果的です。
 

ステップ 1：小規模プロジェクトから始める

初日から大規模プロジェクト全体に SDD を適用することは避けてください。より良いアプローチは、小規模な内部ツール、独立した機能、または新規サイドプロジェクトから始めることです。これにより、チームは不必要なデリバリーリスクを追加することなく、仕様ファーストのワークフローに慣れる時間を確保できます。
 

ステップ 2：仕様テンプレートを準備する

適切に構造化されたテンプレートはチーム全体で SDD を一貫して導入するのを大幅に容易にします。プロジェクト種別に応じて、要件、設計ドキュメント、API 仕様、受け入れ基準などのテンプレートを準備できます。すべてをゼロから作成するよりも、既存のテンプレートを出発点として徐々にカスタマイズしていく方が、現実的です。
 

ステップ 3：タスク、コミット、仕様の整合を維持する

有用なプラクティスの一つはタスク、コミット、仕様更新の間に密接な関係を維持することです。

一部のチームでは以下のようなシンプルな構造を採用しています：

• 1つのTodo = 1つのコミット = 1回の仕様更新 

 

ステップ 4：レビューを仕様段階に前倒しする

従来のワークフローでは実装完了後のコードレビューに大きく依存する傾向があります。SDD は、開発開始前に仕様をレビューすることで、そのレビュープロセスの一部を前段階にシフトします。

実装段階で要件のギャップを発見するよりも、仕様段階で発見する方が、通常ははるかにコストが低く済みます。

ステップ 5：チーム全体でツールを標準化する

個人個人が異なるツールを使用すると、仕様フォーマットが混沌としてしまいます。チーム全体で一貫したツール（例：CafeKit）を使用することが望ましいです。

---

6. Spec-Driven Development 導入における一般的な課題

あらゆる開発手法と同様に、Spec-Driven Developmentもすべての状況における完璧な解決策ではありません。SDD を導入するチームは、移行段階において以下のような共通の課題に直面することがよくあります。

落とし穴 1：仕様の過剰記述

最も一般的なミスの一つは最初からすべてを過剰に文書化することです。

チームが完璧な仕様を作成することに時間をかけすぎると、AI 支援開発の速度優位性は急速に失われます。実際には、軽量な仕様でも開始には十分な場合がよくあります。「いくつかの箇条書きから始める」という穏やかなアプローチも非常に効果的です。AI が仕様の拡張を支援してくれます。

落とし穴 2：仕様とコードの同期ずれ

もう一つの一般的な課題は実装が変更された後に仕様が更新されない場合に発生します。時間が経つにつれて、古い仕様は信頼性を失い、チームはドキュメント全体を信頼しなくなります。これを避けるためには、仕様と実装はプロジェクトライフサイクル全体を通じて共に進化させる必要があります。

落とし穴 3：AI 生成出力への過信

構造化された仕様があったとしても、AI コーディングエージェントは依然としてミスを犯します。仕様は一貫性を向上させますが、あらゆるケースで正しい実装を保証するものではありません。SDD は、AI をエンジニアリング判断の完全な代替手段としてではなく、開発パートナーとして扱う場合に最も効果を発揮します。

 

7. CafeKit：エンタープライズ向けのSDDツール

7.1 CafeKitとは？

CafeKit（cafekit.haposoft.com）はClaude Code向けに特別に設計されたオープンソースCLI ツールセットであり、6 フェーズの Spec-Driven Development ワークフローを実装しています。

CafeKit背後にある主要な目的の一つは、ドキュメンテーション、レビュープロセス、長期的な保守性がデリバリーにおいて重要な要素となるエンタープライズ開発環境において、SDDワークフローをより適用しやすくすることでした。

7.2 CafeKit におけるコア6フェーズワークフロー

CafeKitは日本の開発環境で馴染みのある用語を使用し、以下のフェーズを提供しています：

要件定義 → 設計 → タスク分解 → 実装 → テスト → レビュー

各フェーズはリポジトリ内に直接保存される構造化された Markdown ファイルを生成し、Git による管理が可能です。仕様はコードベースと一緒にバージョン管理されるため、チームは変更を一貫して追跡でき、時間の経過に伴うプロジェクト履歴をより明確に維持できます。また、全員が同じ文書化されたコンテキストに基づいて作業するため、エンジニア、レビュアー、AI コーディングエージェント間の協業も容易になります。

7.3 なぜCafeKitが日本企業に適しているか

✅ 日本語ネイティブ対応

コマンド、テンプレート、生成される文書のすべてが日本語に対応。「要件定義書」「基本設計書」「詳細設計書」など、日本のSIerやSaaS企業で使われるドキュメント文化と自然に統合できます。

✅ ウォーターフォール文化との橋渡し

日本企業に多い「承認プロセス重視」「ドキュメント文化」とAIエージェントの相性問題を解決。仕様書という共通言語があることで、経営層・PM・エンジニアの三者が同じ前提で議論できます。

✅ Claude Code完全対応

CafeKitはClaude Codeの仕組み（CLAUDE.md、スラッシュコマンド、サブエージェント）を前提に設計されており、追加のIDEや高価なライセンスは不要です。

✅ OSSとして無償提供

GitHubで公開されており、商用利用も可能。自社のプロジェクトに合わせてカスタマイズすることもできます。

7.4 CafeKitを始める

CafeKitのセットアップは数分で完了します。

1. 動作環境

Node.js（v18以上）および npm / npx がインストールされていることを確認してください。

2. プロジェクトのルートディレクトリへ移動

ターミナルを開き、提案のルートディレクトリへ移動します。

3. CafeKitを初期化

以下のコマンドを実行してください。

npx@haposoft/cafekit

上記のコマンドを実行すると、CafeKit CLI が自動的にダウンロードされ、起動します。

画面の案内に従ってプロジェクトの設定を行ってください。

セットアップ手順の詳細や関連ドキュメントについては、CafeKit公式サイトをご覧ください。

 

8. Spec-Driven Development がエンジニアキャリアに与えうる変化

AI コーディングツールの台頭はエンジニアスキルの評価方法も変化させています。AI による実装コード生成の能力が向上するにつれ、単に「コードを書く」ことの価値は次第に差別化されにくくなる可能性があります。

同時に、要件定義、問題の構造化、システム設計に関連するスキルの重要性が高まっています。

これがSpec-Driven Development が生産性以外にも注目を集める理由の一つです。

SDDワークフローではエンジニアは不明確なビジネス要件を、人間と AI の双方が一貫して理解できる構造化された仕様に変換することが期待されます。多くの点において、SDD はエンジニアの役割の一部を、純粋な実装から仕様設計と意思決定へとシフトさせます。「コーダー」から「仕様設計者」へとキャリアをシフトさせたい方にとって、SDD は確実に習得すべきスキルセットです。

まとめ

Spec-Driven Developmentは単に AI を用いてコード生成を高速化することではありません。それは、人間と AI が同じ信頼源に基づいて作業できる、より構造化された開発プロセスを構築することなのです。AI 支援開発が進化を続ける中で、明確な仕様を軸に据えたワークフローは、現代のソフトウェアチームにおいてより一般的になる可能性が高いでしょう。

エンタープライズ開発においてSDDの活用を開始したいとお考えの場合は、ぜひ CafeKit（cafekit.haposoft.com）をご検討ください。Claude Code 完全対応、無料の OSSとして今日から導入可能です。

CafeKitに関するお問い合わせ、サポート、エンタープライズ向けカスタマイズ、またはSDD関連コンサルティングについては、Haposoftまでお気軽にお問い合わせください。

• 公式サイト: http://haposoft.com/ja
• Haposoft: ベトナム・ハノイに本社を構え、東京（渋谷）にも拠点を展開するソフトウェア開発企業です。AWS Select Tier Partner、ISO 9001:2015、ISO 27001 認証取得しています。

AI時代の開発を、確かな仕様設計から。