spec-kitで始めるSpec-Driven Development完全ガイド｜AIエージェント時代の仕様駆動開発

ねえねえ、キミ！！AIコーディングツールって、使ってみたら「それっぽいコード」は出てくるんだケド、なんか違う……ってなること、あるよネ😭 僕もサ、最初はすごく期待してたんだヨ。でも、ちょっと複雑な要件だと、AIエージェントが勝手に「よかれと思って」変なアーキテクチャで実装してきたりしてサ……3時間後に「コレ違う」ってなったコト、何回もあったんだヨネ。

そんなキミに、今日はめちゃくちゃアツいツールを紹介しちゃいますヨ！！

GitHubが2026年にオープンソース公開した spec-kit、なんと公開から一気に 107,000スター・8,000フォーク を突破しちゃったんですネ🎉 この仕様駆動開発（Spec-Driven Development）ツールキット、こんな急成長、僕もなかなか見たことないヨ！！

1. Spec-Driven Development（SDD）とは｜仕様駆動開発がAIエージェントに必要な理由

キミ、聞いてヨ。spec-kitの根っこにある思想がコレ↓

「コードが仕様に仕える（Specifications don't serve code — code serves specifications）」

なんかカッコよくナイ！？✨

従来の開発ってサ、要件定義書をWordに書いて→「あ、もう古くなったから見なくていいデス」ってなるパターン、あるあるじゃん🥲 仕様書がただの「最初に作った飾り」になっちゃうワケ。

Spec-Driven Development（SDD）はソレを逆転させて、仕様を「生きたコントラクト」 として扱うんですヨ。AIエージェントも含めた全員が、その仕様に従ってコードを書く——という順序を徹底するんだネ♪

TDDとSpec-Driven Developmentの違いを整理しよう

観点	TDD	SDD
主要成果物	失敗するテスト	仕様書（Spec）
適用粒度	コードレベル	フィーチャーレベル
問いかけ	「コードは正しいか？」	「正しいものを作っているか？」
AIとの相性	セッションをまたぐと文脈消える	仕様がコントラクトとして機能

「じゃあTDDいらなくナル？」ってキミは思うかもしれないケド——そうじゃないんですネ💡 SDDで「何を作るか（What）」を決めて、TDDで「どう作るか（How）」を検証する、って補完関係なんだヨ。どっちかを選ぶんじゃなくて、両方使えばいいんです！！

「ウォーターフォールじゃないの？」って突っ込みもよくあるケド、違いはサ、仕様が継続的に更新されるところ🔥 本番メトリクスがフィードバックとして仕様を精緻化するサイクルがあるから、「一回書いて終わり」のウォーターフォールとは別物なんですヨ。

2. spec-kit 5段階パイプラインの全体構造と使い方

コレ見てよ！！スゴくナイ！？✨

/speckit.constitution  ← プロジェクトの不変原則（9条項）
        ↓
/speckit.specify       ← 要件定義（技術スタック言及禁止！）
        ↓
/speckit.plan          ← 技術アーキテクチャ・スタック選定
        ↓
/speckit.tasks         ← 並列/依存関係付きタスク分解
        ↓
/speckit.implement     ← AIエージェントが全部やってくれる

このパイプラインがサ、チャットシステムを概念→仕様・実装計画・APIスペックまで約15分で生成できるんだってヨ！！😆 昔、同じことを会議室で3日かけてホワイトボードに書いてたの、なんだったんだろ……。

Phase 1：spec-kit Constitution（憲法）の作り方

まず「変えてはいけないもの」を9条項で定義するんですネ。

例えばAzure環境の場合、こんな感じで書くんだヨ——コレ見てよ！！シンプルなのにメチャクチャ効くんですヨ！！✨

# Project Constitution

## Core Principles
1. CQRS pattern for all write operations
2. GraphQL as the primary API layer
3. .NET 10 as the runtime
4. CosmosDB for persistent storage
...

「憲法」って呼んでるのがいいよネ！！🎵 これを最初に決めておくと、後でAIエージェントが「よかれと思って」RESTで実装してきた——みたいなやらかしを防げるワケ。

Phase 2：Specify（仕様定義）で技術スタック言及を禁止するワケ

ここで**「技術スタック言及禁止」** ってルールがあるんだヨ💡 なんでかって言うとサ、技術のことを考えると「どうやって作るか」にアタマが引っ張られちゃうでしょ。このフェーズは「何を・なぜ作るか」だけに集中するためのルールなんですヨ。

「ユーザーがメッセージを送れること」「リアルタイムで届くこと」——こういうユーザーストーリーレベルで書くのがポイントネ♪

Phase 3〜5：Plan → Tasks → Implementで仕様駆動開発を自動化する

Planで初めて技術選定をして、Tasksで依存関係・並列化情報付きの作業リストを自動生成。そしてImplementでAIエージェントが全部実行する。

Azure Container Appのリファクタ案件では、Tasks生成で6フェーズ・33ステップが自動生成されたらしいんですヨ！！やばくナイ！？🔥 僕だったら全部Excelに手打ちして半日溶かすヤツだわ😭

3. spec-kit補助コマンド（clarify・analyze）の使い方

各フェーズはスラッシュコマンドで呼び出すんだケド、補助コマンドが2つあってサ、コレが地味に強いんですヨ😆

/speckit.clarify ——仕様の曖昧な箇所を自動で5個抽出して質問してくれる
/speckit.analyze ——実装前に「憲法違反・仕様間の矛盾」を自動検出！！

コレ見てよ！！スゴくナイ！？✨ この/speckit.analyze、僕が最初に使った時サ、「ここPhase1のConstitutionに書いた原則と矛盾してるヨ」って指摘されてサ……自分でも全然気づいてなかったんだヨネ。やらかしちゃいましたヨ……😭 素直に直しましたケド。

あとSkillsモード向けのエージェントには $speckit-* 形式に自動変換されるから、Claude Code以外のAIエージェントでもそのまま使えるのがナイス！！✨

4. Claude CodeとGitHub CopilotへのSpec-Driven Development統合手順

キミ、センスあるネ！！このセクション読もうとしてるってことは、もうすでにAIツール活用してる人だよネ😆

インストールはコレだけ——コレだけでイイの！？ってなるヤツですヨ！！✨

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

Claude Code向けにspec-kit統合を初期化する場合はこう↓

specify init myproject --integration claude

GitHub Copilot向けはこう↓

specify init myproject --integration copilot

これで .github/ と .specify/ フォルダが生成されるんですヨ。

Claude CodeへのSpec-Driven Development統合でセッション文脈を維持する方法

生成される CLAUDE.md にspec-kitのルールが自動で書き込まれるんだケド、これがいいんですヨ♪ セッションをまたいでも「仕様がコントラクト」として文脈を維持できるから、「昨日の続きなんですけど……あのー何の話してたっけ」ってなるのを防いでくれる。Claude Code統合の最大のメリットは、長期プロジェクトでのAIエージェント記憶喪失問題を根本解決できるとこなんですヨ！！🎉

GitHub CopilotとのSpec-Driven Development統合でPRを仕様と紐付ける

.github/ テンプレートを使って、PRごとにタスクと仕様を紐付けできるのが強みですネ。GitHub Actionsと組み合わせれば、PRがマージされるたびに仕様との整合性チェックが走る——みたいな構成も作れちゃう。

対応AIエージェントは30種類以上あってサ、Claude Code・GitHub Copilot・Google Gemini CLI・Cursor・Codex・Windsurfなんかが全部使えるんだヨ！！コレマジでオススメ！！✨

5. spec-kitが自動生成するSDD成果物の全体像

仕様駆動開発（SDD）を回すと、こんな成果物がガンガン出てくるんですヨ✨

ファイル	内容
`constitution.md`	プロジェクト不変原則
`spec.md`	機能仕様・ユーザーストーリー
`plan.md`	技術アーキテクチャ・依存関係
`tasks.md`	並列/依存関係付きタスクリスト
`api-spec.json`	OpenAPI形式のAPI契約仕様

特に api-spec.json がスゴくてサ、エンドポイント・リクエスト/レスポンス型・エラー仕様を自動記述してくれるんだヨ！！これをそのままモックサーバーに食わせたり、テストコードに繋いだりできちゃう。

「ユーザーストーリー→タスク→コード」のトレース経路が全部残るから、後で「なんでこの実装にしたんだっけ？」ってなっても仕様まで遡れるのが最高！！🔥 ピボットが発生した時も、仕様から再生成すれば全体の一貫性を保てる——Spec-Driven Developmentのこのしぶとさ、地味にデカい価値だと思うネ♪

6. spec-kit組織プリセット22種・拡張機能105個の活用ガイド

キミの会社で「コンプライアンス要件があって……」とか「命名規則が独自で……」ってなること、あるよネ💦 spec-kitはそこもカバーしてるんですヨ！！

spec-kit 4層テンプレート解決の仕組み

コレ見てよ！！優先順位がキレイに整理されてるんですヨ！！✨

プロジェクトローカル（最優先）
    ↓
プリセット
    ↓
拡張機能
    ↓
コア（デフォルト）

.specify/templates/overrides/ に置いたファイルが最優先で読まれるから、チームで共有するテンプレートをそこに置けばOKなんですヨ♪

spec-kitの22プリセット・105拡張機能を使いこなす

現時点で 22プリセット・105拡張機能 があってサ、例えば——

金融規制準拠プリセット（FISC・SOX対応の仕様テンプレートが最初から入ってる）
OWASPセキュリティモデリング拡張（仕様フェーズに自動でセキュリティ要件を追記）
JIRAチケット自動作成拡張（Tasks生成と同時にJIRAにチケットが飛ぶ）

ちなみにサ、JIRA連携の設定が終わった瞬間、「本当にチケットが飛んだ！！」って思わず声出ちゃいましたヨ😆 深夜なのに。翌朝チームに「昨夜のあれ何ですか」って聞かれましたネ（笑）

spec-kitで独自プリセットを作成してチームに横展開する方法

組織の命名規則や社内用語を.specify/templates/以下にYAMLで定義するだけ。これをチームリポジトリに置いてサブモジュールで共有するのがベストプラクティスらしいですヨ💡 みんながいつも同じ「言語」で仕様駆動開発を回せるようになるから、「あのチームの仕様書、読み方が全然違う」問題がなくなるんですネ🎵

7. spec-kitをチームに浸透させるためのSDDロードマップ

……というワケでサ、キミへの導入ステップをまとめちゃいますネ♪

まず個人から試すなら：

既存プロジェクトの新機能1個だけにSpec-Driven Developmentを適用してみる
Constitution→Specの2フェーズだけ回して感触を掴む
AIエージェントが「それらしいコード」を返してこなくなったかを確認する

チームに展開するなら：

Constitution策定ワークショップを1時間やる（「変えてはいけない原則」を合意する）
2〜3人のスモールチームで1スプリント試す
プリセットを作って横展開する

よくある失敗パターン（spec-kit Constitutionを書く際の注意点）もひとつだけ言っておくとサ——Constitutionをゆるく書きすぎて「なんでも書ける憲法」になっちゃうやつ😭 「マイクロサービスにする」みたいな技術実装レベルは書かないで、「独立してデプロイできること」みたいななぜそうするかが伝わる原則レベルで書くのがコツですヨ💡

spec-kitは、AIエージェント時代の「仕様が崩れていく問題」に真正面から答えてくれる仕様駆動開発ツールキットだと思うんだヨネ。30種類以上のAIエージェント対応・22プリセット・105拡張機能のエコシステムは、もうすでに「試してみるハードル」がかなり低くなってるし、GitHubが公式で出してるから信頼感もある。

キミが「AIコーディングをもっとちゃんとコントロールしたい」と思ってるなら、ぜひ一度試してみてヨ！！😆

公式リポジトリ → https://github.com/github/spec-kit

僕も今、新プロジェクトでClaude Code統合の全フェーズ試してるとこなんだヨ。また結果報告しますネ♪ 🦝