仕様駆動開発（Spec-Driven Development）でGitHub発の「Spec Kit」で試してみた
巷で話題になっている Spec Kit をインストールして使ってみました。
すでに触っている方やブログ記事にしている方も多いですが、自分なりにまとめました。
最近、仕様駆動開発に興味があり、GitHubの記事を教えてもらい触ってみることにしました。
仕様駆動開発（Spec-Driven Development）とは
仕様駆動開発（Spec-Driven Development）とは、「仕様書（要件）を開発の中心に据えるアプローチ」 です。
AI IDE の Kiro の登場によって注目され始めた開発スタイルでもあります。
AI コーディングエージェントが Vibe Coding を通じて試行錯誤される中で、ガードレール（Rules や Knowledge）を工夫する過程から生まれた手法と認識しています。
プログラム実装やテストケースはすべて「仕様」に従うため、仕様がコードやテストの唯一の真実の源泉（Single Source of Truth）となります。
コードを書く前に仕様を整理して、それをチケット・設計・実装・テストへと落とし込んでいく。
AI コーディングエージェントを活用した新しい開発スタイルです。
「仕様駆動開発」と聞いて、真っ先に思い浮かべるのは ウォーターフォール開発 ではないでしょうか。
「ウォーターフォールの再発明」と言われる理由
仕様駆動開発はよく 「ウォーターフォールの再発明」 と言われています。
U字プロセス（要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト → 統合テスト）に近い流れを持つためです。
ただし大きく違うのは、AI コーディングエージェントを活用する点 です。
この U字プロセスと仕様駆動開発の違いをまとめると以下のようになります。
| U字プロセス | 仕様駆動開発 | |
|---|---|---|
| 要件定義・設計 | Confluence など外部ツールにまとめる | Kiro や Spec Kit・Cursor を使い、リポジトリ内に Markdown ベースで記録 |
| 実装 | エンジニアが実装 | AI ツールが仕様や設計をもとに実装 |
| テスト | エンジニア・QA が実施 | Jest や Playwright といったテストを AI が生成・実行 |
従来のプロセスでは、次のような課題を感じていました。
- 運用が進むにつれてドキュメントの更新が滞る
- 最新のドキュメントを探せなくなる
- コードに落とし込まれた経緯がドキュメントに残らない
- 新規参入者がドキュメントを見つけられず、コードベースで解釈せざるを得ない
- 開発者ごとに解釈が異なってしまう
- ドキュメント更新が後回しになりがち
こうした課題を考えると、ウォーターフォール型の現場では仕様駆動開発がフィットする可能性が高いと思います。（AI を導入できない環境は別ですが）
U字プロセス全体を置き換えるのは難しいものの、要件定義・設計・実装 といった部分は仕様駆動開発のワークフローに組み込めます。
さらにアジャイル開発でも「動くものを作る → 改善する」サイクルにおいて仕様駆動開発は活用可能です。
例えばスプリントのプランニングでは、次のように仕様駆動開発を組み込めます。
- プランニング前に要件をリストアップする
- AI エージェントに要件を渡し、仕様・設計・タスクを整理する
- プランニング中に生成された仕様や設計を確認し、タスクを修正する
- このとき AI と対話しながら仕様・設計・実装を詰めていく（モブプロ的に）
- 確定した仕様をもとに、スプリント中に実装（AI エージェントを活用）
- 実装された PR をメンバー同士でレビュー
- 動作確認・デグレ観点でレビュー
- 単体テストの正しい動作を確認
- 結合・統合テストを実施（MCP を活用）
このようにスクラムをベースにしたワークフローへも、仕様駆動開発は十分当て込めると感じます。
「作るもの」を先に明確にすることで齟齬が減り、過去にどのようなやりとりやセッションを経て仕様が決まったのかを、リポジトリ内に共有できます。
結果として、人同士のコミュニケーションの質も上がり、さらに Markdown ベースなのでナレッジとしても機能します。
GitHubからオープンソースとしてリリースされた「Spec Kit」
さて、ここからが本題です。
仕様駆動開発の流れにのって、GitHubから 「Spec Kit」 というオープンソースのツールキットが登場しました。
この「Spec Kit」は、GitHub Copilot / Claude Code / Gemini CLI / Cursor といったツールを組み合わせて仕様駆動開発を行うことができます。
特徴は「コードから仕様を書く」のではなく、仕様からスタートすること。
公式でもこんなふうに説明されています。
Spec Kitは、仕様書をエンジニアリングプロセスの中心に据えます。仕様書を書いて放置するのではなく、実装やチェックリスト、タスクの内訳を仕様書が決定づけます。あなたの主な役割は舵取りであり、コーディングエージェントが大部分のライティングを担います。
Kiro と同様に、仕様書 / 実行計画 / タスク を自動生成してくれる仕組みです。
| Spec Kit | Kiro |
|---|---|
| 各CLIツールのコマンドで操作できる | エディタ画面のチャットで操作できる |
つまり、コマンド操作派はSpec Kit、チャット派はKiro といった住み分けになりそうです。
Spec Kit 自体が特別な魔法を提供しているわけではなく、
「仕様をフォーマット化するルール」を提供するスターターキットに近い立ち位置。
CLIツールを軸に“仕様文化”を広めていこう、という感じです。
利用できるツール
Spec Kit に対応しているのは次の4つ。
- GitHub Copilot
- Claude Code
- Gemini CLI
- Cursor
Cursor はリリース当初は対象外でしたが、自分がインストールした時点ではすでに対応済みでした。
ただし Cursor での動作は未検証なので、別記事で試してみたいと思います。
インストールとセットアップ
まず uv が必要です。
以下のコマンドでインストールします。
curl -LsSf https://astral.sh/uv/install.sh | sh
実行するとこんな感じでセットアップされます👇
downloading uv 0.8.17 aarch64-apple-darwin
no checksums to verify
installing to /Users/xxxx/.local/bin
uv
uvx
everything's installed!
To add $HOME/.local/bin to your PATH, either restart your shell or run:
source $HOME/.local/bin/env (sh, bash, zsh)
source $HOME/.local/bin/env.fish (fish)
WSL / Mac の場合は POSIX Shell を指定。
Windows で使うなら PowerShell を選びます。
セットアップ
今回は検証用に Gemini CLI を選びました。
インストールしたいディレクトリに移動して、以下を実行します。
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
<PROJECT_NAME> を指定すると、その名前のディレクトリが作成されます。
Geminiの場合
.gemini/commands に Gemini 用のコマンドが格納されます。
-
memory
- 憲章ファイルを格納（組織やプロダクトのルール用テンプレート）
-
scripts
- 仕様作成や前提条件を組み合わせたシェルスクリプト
-
templates
- エージェントファイル・仕様駆動の plan / spec / task のテンプレート
templates はプロダクトに合わせてカスタマイズ可能です。
-
/specify: 仕様書 -
/plan: 実装計画 -
/tasks: 実行タスク
実際にはコマンドを実行して、仕様書・計画・タスクを生成します。
// Gemini
├── .gemini
│ └── commands
│ ├── plan.md
│ ├── specify.md
│ └── tasks.md
├── memory
│ ├── constitution_update_checklist.md
│ └── constitution.md
├── scripts
│ └── bash
│ ├── check-task-prerequisites.sh
│ ├── common.sh
│ ├── create-new-feature.sh
│ ├── get-feature-paths.sh
│ ├── setup-plan.sh
│ └── update-agent-context.sh
└── templates
├── agent-file-template.md
├── plan-template.md
├── spec-template.md
└── tasks-template.md
仕様書を作成する
/specify コマンドを実行して仕様を会話形式で詰めていきます。
/specify TODOアプリをつくりたい・要件はNode / Nest / Next
すると create-new-feature.sh が走り、仕様書が生成されます。
生成結果は例えば /specs/002-todo-node-nest/spec.md のように保存されます。
現状はすべて英語で出力されますが、テンプレートを整備すれば Kiro と同じように仕様駆動開発が可能 になりそうです。
Cursorの場合
.cursor/commands には Cursor 用のコマンドが格納されます。
// Cursor
├── .cursor
│ └── commands
│ ├── plan.md
│ ├── specify.md
│ └── tasks.md
├── memory
│ ├── constitution_update_checklist.md
│ └── constitution.md
├── scripts
│ └── bash
│ ├── check-task-prerequisites.sh
│ ├── common.sh
│ ├── create-new-feature.sh
│ ├── get-feature-paths.sh
│ ├── setup-plan.sh
│ └── update-agent-context.sh
└── templates
├── agent-file-template.md
├── plan-template.md
├── spec-template.md
└── tasks-template.md
まとめ
自分の開発スタイルがコマンド中心でない場合は、Kiro や Cursor のチャットベースのほうが使いやすいと感じました。
逆に Claude Code や Gemini CLI を普段使っている人には親和性が高そうです。
チーム開発を想定するなら Cursor CLI と組み合わせると運用がしやすいかもしれません。
Kiro を使う場合はチーム全員の IDE を揃えると余計なカスタマイズが不要になりますし、
コマンドベースと IDE が混在するチームなら Spec Kit で統一するのもアリ。
学習コストを抑えて導入できるのではないでしょうか。
参考リンク
Discussion