AIに「いい感じのアプリを作って」と投げるだけでは、意図と実装がずれやすい。GitHubが公開したオープンソースのSpec Kitは、コードを書く前に要件を文章化し、AIコーディングエージェントへ段階的に渡す開発フローを提供します。
この記事では、Spec Kitの概要と具体的な使い方、類似アプローチとの違いを整理します。
この記事でわかること
- Spec-Driven Development（仕様駆動開発）がvibe codingの課題にどう効くか
- Spec Kitの基本ワークフローとスラッシュコマンド一覧
- プロジェクト初期化から実装までの手順
- 料金体系と対応AIエージェント
- 似た手法との使い分け
vibe codingの課題と仕様駆動開発
vibe codingとは、曖昧なプロンプトだけを頼りにAIへ実装を任せるやり方です。試行錯誤は速い一方、要件の抜けや仕様のブレが後から表面化しやすくなります。
Spec Kitが採用するSpec-Driven Development（SDD、仕様駆動開発）は、従来「実装が終わったら捨てる付属物」だった仕様書を中心に据えます。公式ドキュメントでは、仕様を「実行可能な成果物」として扱い、実装の出発点にする考え方と説明されています。
X上では、Spec Kitが「コードに触れる前にAIへ意図を理解させる」手段として紹介され、短期間で高いスター数を集めた点も話題になりました（参考）。GitHub APIの時点（2026年6月）では、リポジトリは2025年8月公開からスター数11万超、フォーク1万超です。
Spec Kitとは
Spec Kitは、GitHubがMITライセンスで公開しているCLIツール群です。specifyコマンドでプロジェクトを初期化すると、.specifyフォルダに仕様・計画・タスク用のMarkdownテンプレートと、選択したAIエージェント向けのプロンプト定義が配置されます。
中核は4段階のフローです。Spec（何を作るか）→ Plan（どう作るか）→ Tasks（作業分解）→ Implement（実装）。各段階の成果物が次の段階へ渡るため、AIは毎回ゼロから推測するのではなく、蓄積された文脈を参照します。
対応エージェントは30種類以上で、GitHub Copilot、Claude Code、Gemini CLI、Cursor、Windsurf、Zedなどが公式に挙がっています。エージェントを変えてもspecify initの--integrationオプションで切り替えられるため、特定ベンダーへのロックインはありません。
使い方：初期化から実装まで
前提条件
Spec KitのCLIはPython製で、パッケージ管理にuv（Astral製の高速Pythonツール）が必要です。uvを入れたうえで、次のいずれかでCLIを使います。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
一時利用ならuvxでも起動できます。
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --integration copilot
--integrationには利用するエージェント名を指定します。一覧はspecify integration listで確認できます。未対応ツール向けにはgeneric統合も用意されています。
基本ワークフロー
プロジェクト初期化後、AIエージェントのチャットでスラッシュコマンドを順に実行します。クイックスタート向けの最短ルートは次の4コマンドです。
/speckit.specify— 何を・なぜ作るかを記述（技術選定はまだ書かない）/speckit.plan— 技術スタックとアーキテクチャを決める/speckit.tasks— 実装タスクへ分解/speckit.implement— タスクを実行してコードを生成
本番向けや要件が曖昧な機能では、公式が推奨する品質ゲートを挟みます。
/speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.checklist → /speckit.tasks → /speckit.analyze → /speckit.implement → /speckit.converge
/speckit.constitutionはプロジェクト憲章と呼ばれるルール集を作ります。テスト方針やセキュリティ要件など、以降の全フェーズが参照する原則を先に固定します。
/speckit.clarifyは仕様の曖昧さを洗い出し、/speckit.checklistは要件の網羅性を検証するチェックリストを生成します。/speckit.analyzeは仕様・計画・タスクの整合性を実装前に確認し、/speckit.convergeは実装後に残作業をタスクへ追記します。収束レポートで未完了が出た場合は、再度/speckit.implementを回す流れです。
機能ブランチとの連携
Spec KitはGitブランチ名（例：001-feature-name）から作業中の機能を自動検出します。別機能の仕様へ切り替えるときはブランチを変えるだけで、エージェントが参照する文脈も切り替わります。
拡張とカスタマイズ
コア以外に、コミュニティ製の拡張（extensions）105件、プリセット22件が公開されています。拡張は新コマンドの追加、プリセットはテンプレート文言の差し替えに使います。組織内カタログをホストして、社内標準のワークフローを配布することも可能です。
タスクをGitHub Issuesへ変換する/speckit.taskstoissuesも用意され、Issueベースの進捗管理と組み合わせられます。
料金
Spec Kit本体はMITライセンスで無料です。利用にあたってGitHubへの支払いは発生しません。ただし、連携するAIコーディングエージェント（GitHub Copilot、Claude Codeなど）は各サービスの料金体系に従います。
類似ツールとの違い
仕様を先に書く考え方は、OpenSpecやBMAD-METHODなど他のOSSでも広がっています。Augment Codeの比較記事では、Spec Kitを「静的Markdown仕様・エージェント非依存・クロスエージェント標準化向け」と位置づけています（参考）。
Spec Kitの強みは、GitHub公式がテンプレートとCLIを一体で配布し、30以上のエージェント統合をメンテナンスしている点です。一方、小さな修正1件にフルワークフローを回すと、Markdown成果物のレビュー負荷が相対的に重くなる場面もあります。新規プロジェクト、既存コードへの機能追加、レガシー刷新の3シナリオを公式が主な用途として挙げており、要件の「何を作るか」が安定しているほど効果が出やすい設計です。
始めるときの判断基準
次の条件に当てはまるなら、Spec Kitの導入を検討する価値があります。
- AI生成コードの品質ばらつきを、仕様レビューで抑えたい
- 複数のAIエージェントを使い分けたいが、手順を共通化したい
- PRD（製品要求仕様）に近い文書を、実装前の単一の真実の源にしたい
最新リリースはv0.11.9（2026年6月26日公開）です。CLIの更新確認はspecify self check、アップグレードはspecify self upgradeで行えます。まずは小さな機能で/speckit.specifyから/speckit.implementまで一通り回し、憲章やclarifyなどの品質ゲートを段階的に足していくのが現実的です。