GitHubの「Spec Kit」を試してみた ─ 仕様駆動開発で始める新しい開発フロー
-
2025年11月13日
こんにちは。
Cocone EngineeringのWeb Development Unit所属のフロントエンジニアの猿田です。
今回はGitHubが2025年9月に公開した、仕様駆動開発のためのツールキット「Spec Kit」について、実際に試してみた感想を概要を交えて紹介したいと思います。
どうぞよろしくお願いします。
「Spec Kit」とは？
https://github.com/github/spec-kit
SpecKitは、GitHubがOSSとして2025年9月に公開した仕様駆動開発（Spec-Driven Development（SDD））を支援するツールです。
近年、AIによる自動コード生成の精度が上がる一方で、仕様の曖昧さによるトラブルも増えています。SpecKitは、その根本を正す「仕様から始める開発」をGitHub公式として体系化したものです。
設計書に基づいた開発を行うことで、AIの「推測任せ」を防ぎ、コードと意図の整合性を確保、さらに、各段階での検証機能により「行き過ぎたコード生成」や「要件の抜け」を防止し、堅牢な開発フローを実現します。
コアとなる考え方
仕様駆動開発（Spec-Driven Development（SDD））では、次の点を大切にします：
・意図を重視した開発：どう作るかよりも、「何を作るのか」をまず明確にする
・充実した仕様づくり：ガイドラインや組織の原則を活かして、しっかりとした仕様を整える
・一度で完成させず、段階的にブラッシュアップする
・AIの高い理解力を活用して仕様を解釈する
競合となる仕様駆動開発ツールと比較
2025年10月時点で、SpecKitと競合になる仕様駆動開発ツールは以下になります。
・Kiro
それぞれのツールを比較してみました。
| 項目 | ⭐SpecKit | Kiro | spec-workflow-mcp | cc-sdd | Claude Code Spec Workflow |
|---|---|---|---|---|---|
| 提供元 | GitHub（2025/9公開） | AWS系スタートアップ | コミュニティ実装 | 日本発OSS | Anthropic周辺コミュニティ |
| ライセンス | クローズド（GitHub公式） | クローズド | OSS的ワークフロー実装 | OSS | OSS的ワークフロー |
| 仕様記述形式 | 専用フォーマット（YAML/Markdown連携想定） | 独自形式／IDE連携 | Markdown/DSL | 日本語対応DSL | Markdownベース |
| AI連携 | GitHub Copilot, OpenAI系と連携前提 | AWS系モデルに最適化 | Claude / GPT両対応 | 任意LLM接続可能 | Claude特化 |
| 強み | GitHub公式の安心感、CI/CD統合が強力 | エンタープライズ指向、IDE統合 | 承認フロー重視、品質ガバナンス | 日本語対応、軽量で学習しやすい | Claudeと仕様駆動の標準化実験的アプローチ |
| 課題 | クローズドで拡張性制限あり | クローズド＆利用実績が限られる | 成熟度が低い、実装例少ない | 大規模案件での実績不足 | 機能が限定的、Claude依存 |
| 対象ユーザー | GitHubユーザー全般、SDD初学者〜実務 | 大規模組織、AWSユーザー | 品質ガバナンスを重視するチーム | OSS志向、日本語利用者 | Claudeを利用中のチーム |
| 成熟度 | 高い（公式サポート＋ドキュメント整備） | 中程度（クローズドβ的段階） | 低〜中（限定利用） | 低（コミュニティ成長段階） | 低（試験的） |
補足
SpecKit自体は仕様策定に特化したプロンプト集のようなツールです。GitHub CopilotやClaudeなど、別のAIアシスタントと組み合わせて利用します。
導入方法（Getting Started）
uv のインストール
SpecKitのCLIはPythonパッケージマネージャーuvが必要です。uvをインストールするには以下のコマンドを実行します。
curl -LsSf <https://astral.sh/uv/install.sh> | shSpecify CLI のインストール
以下のコマンドでインストールします。
specify-cli は SpecKit のCLIフロントエンドとして提供されており、SpecKitリポジトリ内に同梱されています。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git開発の流れ
開発工程は7つです。
・「工程1：プロジェクト原則の作成 /constitution」は原則1度だけ実行します。
・「工程3：技術的実装計画の作成」「工程6：整合性チェック」の実行は2025年10月時点では任意です。
それぞれの工程をコマンドで実行します。
| 工程 | 作業内容 | コマンド |
|---|---|---|
| 1 | プロジェクト原則の作成 | /constitution |
| 2 | 仕様の作成 | /specify |
| 3 | 仕様の明確化 | /clarify |
| 4 | 技術的実装計画の作成 | /plan |
| 5 | タスクの整理 | /tasks |
| 6 | 整合性のチェック | /analyze |
| 7 | 実装 | /implement |
実際の作業
リアルタイムチャットの構築を例に進めます。
（準備）プロジェクトの初期化
以下のコマンドで 最新テンプレートから新しい Specify プロジェクトを初期化します。
# 新規で作成
specify init <PROJECT_NAME>
# 既存プロジェクトで作成
$ specify init --here
# 自動で設定されるgitの設定を無視したい場合
$ specify init <project-name> --no-git
AIアシスタントを選択します。今回は copilot (GitHub Copilot) を選択しました。
スクリプトを選択します。今回は sh を選択しました。
-- セキュリティ --
プロジェクトの準備が整いました。一部のエージェントは、プロジェクト内のエージェントフォルダに認証情報、認証トークン、その他の識別情報や秘密の成果物を保存する場合があります。
認証情報の漏洩を防ぐために、.github/（またはその一部）を .gitignore に追加することを検討してください。
--- 次のステップ --
1. プロジェクトフォルダへ移動: cd speckit-project │
2. AIエージェントでスラッシュコマンドを使い始めましょう: │
2.1 /constitution - プロジェクトの原則を確立 │
2.2 /specify - ベースライン仕様を作成 │
2.3 /plan - 実装計画を作成 │
2.4 /tasks - 実行可能なタスクを生成 │
2.5 /implement - 実装を実行 │
--- 拡張コマンド --
○ /clarify（任意） - 曖昧な部分をリスク回避するための構造化された質問を行う（使用する場合は /plan の前に実行）
○ /analyze（任意） - 成果物間の一貫性と整合性のレポートを生成（/tasks の後、/implement の前に実行）※ Specify-cli をインストールせず直接実行する方法も存在します。2025年10月時点では、コマンドのインストールを推奨しています。
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>プロジェクトのディレクトリ構造
以下のディレクトリ構成でプロジェクトがセットアップされます。
tree -a -I '.git|node_modules' -L 4
.
├── .github
│ └── prompts # プロンプト
│ ├── analyze.prompt.md
│ ├── clarify.prompt.md
│ ├── constitution.prompt.md
│ ├── implement.prompt.md
│ ├── plan.prompt.md
│ ├── specify.prompt.md
│ └── tasks.prompt.md
└── .specify
├── memory # AI の行動規範を定義
│ └── constitution.md
├── scripts
│ └── bash # プロジェクト運営の自動化スクリプト
│ ├── check-prerequisites.sh
│ ├── common.sh
│ ├── create-new-feature.sh
│ ├── setup-plan.sh
│ └── update-agent-context.sh
└── templates # 仕様・計画・タスクを文書化するための雛形
├── agent-file-template.md
├── plan-template.md
├── spec-template.md
└── tasks-template.md
1. プロジェクト原則を確立： /constitution
・書き出しはコマンド「 /constitution 」で始めます。
・開発ツールや、開発スタイル、コーディング規約を指定します。
・基本は初回に1度実行します。修正が必要な場合、再度実行します。
・実行後、.specify/memory/constitution.md が生成/更新されます。
・以降、基盤として活用されます。
👨💻 実行例：
/constitution コード品質、テスト標準、UX、パフォーマンス要件、セキュリティ、ドキュメント整備の原則の作成
1. コード品質
- すべてのコードは、定められたスタイルガイドとリンティングルールに従うこと。
- すべてのプルリクエストにはコードレビューを必須とする。
- 可読性と拡張性を維持するため、必要に応じてリファクタリングを優先する。
2. テスト基準
- 各機能には、エッジケースを含むユニットテストを必ず実装する。
- 重要な処理フローには統合テストを実施する。
- コアモジュールのテストカバレッジは常に85%以上を維持する。
3. UXの一貫性
- UIは共通のデザインシステムに準拠すること。
- アクセシビリティ基準（WCAG 2.1 AA以上）を必ず満たす。
- リリース前にクロスデバイス・クロスブラウザの動作検証を行う。
4. パフォーマンス要件
- ページの読み込み時間は標準的なデバイスで2秒以内を目標とする。
- API応答時間は通常負荷下で300ms以内を目標とする。
- 各スプリントごとにパフォーマンス監査を実施する。
5. セキュリティ
- すべての依存ライブラリは定期的に更新し、脆弱性をチェックする。
- 機密情報（APIキー、パスワードなど）はコードベースに含めない。
- OWASP Top 10を意識したセキュリティレビューを行う。
6. ドキュメント整備
- 日本語で記載する。
- 新機能や重要な変更点には、必ず開発者向けドキュメントを更新する。
- README・セットアップ手順・API仕様は常に最新状態を維持する。
- ユーザー向けガイドやチュートリアルはリリースと同時に公開・更新する。2. 仕様の作成：/specify
・書き出しはコマンド「 /specify 」で始めます。
・プロジェクトの仕様を指定します。
・対象はビジネス関係者であり、開発者ではありません。
・プロジェクトの意図である「ユーザーが何を必要としているか」「なぜ必要なのか」を指定します。
・この工程では技術スタック、API、コード構造等、実装方法には触れてはいけません。
・技術スタックは次の /plan で指定し、対象は開発者になります。
・仕様が曖昧な場合、[NEEDS CLARIFICATION] マークが付与されます。こちらはAIに相談しながら明確化していきます。
・実行後、.specs/ 以下にブランチ（例: 001-1-google-2） specs/001-1-google-2 ディレクトリが生成されます。
・上記ディレクトリ以下に spec.md が生成されます。
👨💻実行例：
/specify シンプルなリアルタイムチャットの作成
1. 認証システム
- Google アカウントでログイン
- 自動ユーザー情報同期
- セッション管理
2. リアルタイムチャット
- 即座のメッセージ送受信
- WebSocket による双方向通信
- 30分間のメッセージ履歴
- 自動メッセージクリーンアップ（30分経過後）
3. ユーザビリティ機能
- PC、スマホを配慮
- 入力中表示（タイピングインジケーター）
- オンライン参加者一覧（アイコン表示）
- 100文字制限＋文字数カウンター
- Enter キーでの送信、Shift+Enter での改行
- 色はモノクロでコントラスを高めに
- テキストは全ての環境で見えやすい大きさに
- レスポンシブデザイン
4. パフォーマンス＆保守性
- Error Boundary によるエラーハンドリングspec.md 生成後、AIから未確定事項の質問があがったので回答しました。
未確定事項（Clarification 必須）
- タイピングインジケーター消去までの X 秒（提案: 3 秒維持後フェードアウト）
- タイピングイベント送信スロットル間隔（提案: 500ms）
- 再接続時一括同期の最大メッセージ件数（提案: 200 件）
- 重複メッセージ（内容・タイムスタンプ近接）の抑制要/不要（現行は許容設計）
- 複数タブ/複数デバイス同時接続の扱い（PresenceSession モデル 1:1 制約を緩めるか）
- オフライン復帰時のバッチサイズ上限（提案: 200 件 or 30 分期間内全件）3. 仕様の明確化： /clarify
・書き出しはコマンド「 /clarify 」で始めます。
・作成した仕様で、AIから見て不足な点を明確化します。
・/plan の前に実行する必要があります。
・明確化を進めた場合、前述の spec.md が更新されます。
👨💻実行例：
/clarify 仕様の不足、不明点の確認AIからの質問がある場合、回答します。
🤖質問例：
Presence（在席）判定のためのハートビート間隔とタイムアウト閾値を選んでください。
(定義: クライアントは一定間隔で heartbeat を送信。サーバは最終受信時刻との差分が閾値を超えたら「離脱」とみなす)
Option Description
A 10s 間隔 / 25s で離脱 (2連続欠損＋猶予)
B 15s 間隔 / 45s で離脱 (3連続欠損)
C 5s 間隔 / 15s で離脱 (3連続欠損) / 反応性優先
D 8s 間隔 / 24s で離脱 (3連続欠損, 中庸)
E Short回答を続けると、 終了の趣旨の回答を得ることがでます。
これ以上 Clarification は上限到達のため終了です。
次ステップとして /plan 実行を推奨します。進めてよければ「/plan 実行」や「plan」と返信してください。4. 技術的実装計画の作成：/plan
・書き出しはコマンド「 /plan 」で始めます。
・実装技術や実装方針など、使用する技術スタックを具体化します。
👨💻実行例：
/plan 技術スタックは以下を採用
- フロントエンド：Next.js 15 (App Router)
- スタイリング：TailwindCSS
- 状態管理：Zustand
- 認証：Clerk (Google OAuth)
- バックエンド、データベース：Convex (リアルタイムデータベース)
- Typeセーフティ: TypeScript
- 単体テスト: Vitest
- UIテスト: React Testing Library実行後、/specify で作成されたディレクトリ以下に、以下のファイルが生成されます。
.
├── contracts # 各モジュール・エージェント間の通信仕様を格納
│ ├── heartbeat.json # システムの生存確認やヘルスチェック用の通信仕様。エージェントが動作しているか確認
│ ├── message.json # 一般的なメッセージ送受信の仕様。送信者・受信者・本文・タイムスタンプなどを定義
│ ├── presence.json # エージェントの「オンライン／オフライン」状態など、プレゼンス情報を扱う契約
│ └── typing.json # 「入力中（typing）」などリアルタイムな状態を通知する契約。チャットや共同編集系で利用
├── data-model.md # データ構造・スキーマ定義
├── plan.md # 実装計画・進行方針
├── quickstart.md # 初期セットアップガイド
├── research.md # 調査・検討記録
└── spec.md # 2. 仕様の作成：`/specify` で生成5. タスクの整理：/tasks
・書き出しはコマンド「 /tasks 」で始めます。
・技術計画から実行可能なタスクリストを作成します。
・実行後、/specify で作成されたディレクトリ以下に、tasks.md が生成されます。
👨💻実行例：
/taskstasks.md の例：
## Phase 3.1: Setup
- [ ] T001 Initialize project manifest & tooling (Node 22.16.0 via .nvmrc, package.json with Next.js 15.5.4, React 19, TypeScript, Tailwind, shadcn/ui, Zustand, Convex, Clerk, ESLint, Prettier, Vitest, React Testing Library). Files: `.nvmrc`, `package.json`, `.eslintrc.cjs`, `tsconfig.json`, `vitest.config.ts`, `.prettierrc`.
- [ ] T002 Configure Tailwind & shadcn/ui (generate config, add base styles). Files: `tailwind.config.ts`, `postcss.config.js`, `app/globals.css`.・タスクは「タスク（T）」でリスト化されます（例：T008）。
・タスクのまとまりは「フェーズ（Phase）」で分類されます。
6. 整合性のチェック：/analyze
・書き出しはコマンド「 /analyze 」で始めます。
・仕様・計画・タスクの一貫性をチェックします。
👨💻実行例：
/analyze実行後、分析結果と、AIから修正するかどうかの質問があります。
A) 今すぐ修正タスクを実装する（推奨：コーディング前）
B) 現在のタスクをそのまま進める（リスク：「全ての機能テスト」ゲートを満たせない可能性あり）実行後、/specify で作成されたディレクトリ以下のファイルが更新されます。
例：
logging.md # 新規追加
spec.md # 更新
tasks.md # 更新7. 実装：/implement
・計画に従い、タスクを消化し実装を進めます
👨💻実行例：
/implement上記の場合、全フェーズを実行してしまうため、バグ発生時の対応、コードレビューが難しくなります。 基本はフェーズごとに、AIの提案を参考にタスクごとに実行＋都度レビューしながら進めました。
👨💻実行例：
/implement Phase 3.1: Setup
/implement contract の拡張 (T064, T069)
/implement T012 → (並行) T013, T014, T015, T016, T017, T018 を順次追加
/implement T060 群の追加
/implement 残りのリメディエーション系統合テスト骨組み追加 (T060–T068) も先に failing で用意実行後、tasks.md のタスクリストで完了したタスクにチェックが入ります。
例：
## Phase 3.1: Setup
- [x] T001 Initialize project manifest & tooling (Node 22.16.0 via .nvmrc, package.json with Next.js 15.5.4, React 19, TypeScript, Tailwind, shadcn/ui, Zustand, Convex, Clerk, ESLint, Prettier, Vitest, React Testing Library). Files: `.nvmrc`, `package.json`, `.eslintrc.cjs`, `tsconfig.json`, `vitest.config.ts`, `.prettierrc`.
- [x] T002 Configure Tailwind & shadcn/ui (generate config, add base styles). Files: `tailwind.config.ts`, `postcss.config.js`, `app/globals.css`.使ってみた感想
※良かった点
・コマンドラインインターフェース（CLI）、プロンプトなどがあらかじめ整備されており、導入障壁の低さを感じました。
・仕様ありきで構築しているため、プロジェクトの目的に対しずれにくく、品質の高いコードが生成されました。同様に、自動テストの生成、ドキュメントを自動生成がスムーズでした。
・実装コマンド「 /implement 」について、細かい指定で依頼して進めたため、検証・修正が無理なく行え、問題の早期発見と修正ができました。
※気になった点
・開発前に詳細な仕様をまとめる作業に時間を要します。スピード重視のプロジェクトでは負担になりそうです。
・技術スタックのバージョンは明示したほうが良さそうです。例えばNext.jsについて、当初「15」で依頼しましたが、古いバージョンでした。「v15.5.4」と明確に指示したほうが良さそうです。
※その他
・前述のようにSpecKit 自体はプロンプト集のようなもので、コードの品質は保証しません。AIモデルの選択は慎重に進めたほうが良さそうです（今回は「Agent + GTP-5」で進めました）。
・仕様を明確化するコマンド「 /clarify 」で、仕様の精度が高くなる印象を受けました。現在、任意コマンドとして用意されていますが、実行したほうが良さそうです。
最後に
SpecKit は「仕様駆動型開発」を促す強力なツールであり、設計精度を高めたいフェーズに非常に有効だと感じました。
おそらく、「要件が複雑でチーム間認識を揃えたい開発が必要なプロジェクト」にはフィットしそうです。
一方で「プロトタイピング・スピード重視のプロジェクトには」にはオーバーヘッドになりやすく大変不向きな印象でした。
本記事で興味を持っていただけたら幸いです。
