SPEC.Kitと「実行可能な仕様」：AI開発を秩序に戻すGitHubの挑戦

AIがソフトウェア開発を支えるようになった今、私たちが直面しているのはスピードではなく秩序の問題です。
思いついたことをAIに投げてコードを吐き出させる「Vibe-Coding（雰囲気コーディング）」は便利ですが、その場しのぎに終わりやすく、あとで必ずツケが回ってきます。

GitHubが公開した SPEC.Kit は、その無秩序をただすための「フレームワーク」です。
コードではなく仕様を出発点とする「仕様駆動型開発（Spec-Driven Development, SDD）」を可能にします。

なぜSPEC.Kitが必要なのか

Vibe-Codingの落とし穴

一見うまく動くコードが出ても、本来の意図とずれている
本番に向かない技術スタックを選んでしまう
チームで維持するには不安定で、負債が積み上がる

「すぐ動くけど、あとで直すのに倍以上かかる」――そんな経験がある人は多いはずです。

SPEC.Kitの考え方

仕様が王様：コードは仕様を表現した結果にすぎない
仕様は実行可能：AIがその仕様をもとに実装やテストを生成できる
秩序ある流れ：仕様 → 計画 → タスク → 実装の順に進め、各段階で人がチェック

つまり、「設計図なしの家づくり」をやめ、「仕様書を土台にした開発」へと発想を転換させるのです。

SPEC.Kitの全体像

主な構成要素

CLI（コマンドライン）
プロジェクト初期化や仕様作成を進めるための操作窓口
テンプレート
仕様・計画・タスクの雛形がそろっている(マークダウン形式)
プロンプト
AIエージェント（Copilot、Claude、Geminiなど）に渡すための最適化済み指示文

プロジェクト構造（例）

スクロールできます

ディレクトリ/ファイル	役割
memory/constitution.md	プロジェクトの「憲法」。守るべきルールを記載
templates/	仕様や計画のテンプレート群
specs/	実際に生成された仕様ファイル
scripts/	ブランチ作成などの補助スクリプト

とくに重要なのが constitution.md。
ここに「ライブラリは優先的に使う」「セキュリティはOWASP準拠」といった原則を書いておくと、AIはそれを破れなくなります。

四段階ワークフロー：SPEC.Kitの使い方

SPEC.Kitの流れはシンプルですが、徹底されています。

1. Specify（仕様定義）

「何を、なぜ作るのか」を書きます。
実装方法はあえて書かないのがポイント。

例）

/specify
ユーザーはタスクを追加・完了・一覧できる。
受け入れ基準：E2Eテストで3操作が通ること。
非機能要件：TTI 2秒以内、XSS/CSRF回避。

2. Plan（計画）

仕様を受けて、どう実装するかを決めます。

例）

/plan
フロント：Next.js  
UI：shadcn/ui  
API：REST(JSON)、OpenAPI雛形を生成  
DB：PostgreSQL  
認証：httpOnlyセッショントークン

3. Tasks（タスク化）

計画を小さな作業に分解します。
テスト駆動を前提にするのが特徴です。

例）

/tasks
- POST /api/tasks のスキーマとテスト  
- GET一覧（ページング含む）  
- UIフォームのバリデーション  
- E2Eシナリオ（追加→完了→一覧）  
- CSRF対策と入力エスケープ

4. Implement（実装）

AIがタスクごとに実装。人間は「検証者」としてレビューします。

導入手順（クイックスタート）

前提環境：Linux/macOSまたはWSL2、Python 3.11以上、uv、Git。

新規プロジェクトの場合：

uvx --from git+https://github.com/github/spec-kit.git specify init my-app

既存ディレクトリで利用する場合：

uvx --from git+https://github.com/github/spec-kit.git specify init --here

その後、利用するAIエージェントを選び、
/specify → /plan → /tasks → 実装 の流れで進めます。

Windows×GitHubCopilotで使うための全体像

必要なもの（WSL側に入れる）

項目	どこに入れる	備考
WSL2（Ubuntuなど）	Windowsに有効化	`wsl --install` が最短。WSL2が既定。(Microsoft Learn)
Python 3.11+	WSL内	uvで入れるのが速い。(Astral Docs)
uv	WSL内	ツール実行ランチャー。`uvx --from ...` がポイント。(Astral Docs)
Git	WSL内	認証はGit Credential Managerも使える。(GitHub)
SPEC.Kit（Specify CLI）	WSL内	`uvx --from git+... specify init` で初期化。(The GitHub Blog)
VS Code + WSL拡張	Windows（VS Code本体）	WSL内のフォルダをVS Codeで開く。(Visual Studio Code)
GitHub Copilot（Chat）	VS Code拡張	セットアップはVS Codeの公式手順どおり。(Visual Studio Code, GitHub Docs)

セットアップ（15〜30分）

1. WSL2を有効化（Windows）

PowerShell（管理者）で：

wsl --install

再起動後、Ubuntu等の初期設定を完了。WSL2が既定です。(Microsoft Learn)

2. VS Code + WSL拡張（Windows）

VS Code をインストール
拡張機能「WSL」を入れる（Remote – WSL）
「WSL: Open Folder」でWSL内のプロジェクトを開く
（WSL拡張は、Linux環境の開発をWindows上のVS Codeで快適にするための公式手順です。）(Visual Studio Code)

3. uv & PythonをWSL内に導入（Ubuntu想定）

WSLのターミナルで：

# uv を導入（公式インストーラ）
curl -LsSf https://astral.sh/uv/install.sh | sh

# Python 3.11+ を用意（uvはPythonも管理できる）
uv python install 3.11
uv python install --default 3.11  # python/python3を指すエイリアスに設定（実験的フラグ）

（uv公式ドキュメントの手順に準拠）(Astral Docs)

4. Git をWSL内に

Ubuntuなら sudo apt-get update && sudo apt-get install -y git。
Git認証で困ったらGit Credential Manager（Linux版）も利用可（SPEC.KitのREADMEのトラブルシューティング記載）。(GitHub)

5. GitHub Copilot（VS Code）

VS CodeのCopilotセットアップを実施（サブスク契約 → 拡張導入 → サインイン）。Chat拡張も自動または併せて導入。(Visual Studio Code, GitHub Docs, Visual Studio Marketplace)

プロジェクトの作成（Copilot想定）

1. SPEC.Kitを初期化（WSL内）

uvx --from git+https://github.com/github/spec-kit.git specify init my-app --ai copilot
# 既存ディレクトリで始めるなら
uvx --from git+https://github.com/github/spec-kit.git specify init --here --ai copilot

--ai copilot を公式が明示。SPEC.KitはCopilot/Claude/Gemini対応。(GitHub)

なぜuvx？
uvの--from git+...で、GitHub上のCLIを即時実行できるからです。(Astral Docs)

2. できあがる構成（抜粋）

memory/constitution.md … プロジェクトの憲法（原則・禁止事項）
templates/ … spec-template.md / plan-template.md / tasks-template.md
specs/ … 実際の仕様書が入る場所
（構成はREADMEに記載）(GitHub)

よくある質問と対処

Windowsネイティブじゃだめ？

WSL2前提です（Linux/macOS、WindowsはWSL2）。(GitHub)

Copilotで本当に使える？

使えます。 公式がCopilot / Claude / Gemini対応を明記。初期化時に --ai copilot を指定できます。(The GitHub Blog, GitHub)

エージェント検出で詰まる

--ignore-agent-tools を付けてテンプレートだけ取得も可能。(GitHub)

Git認証が通らない（WSL）

Git Credential Manager（Linux版）の導入スクリプトがREADMEのTroubleshootingにあります。(GitHub)

「憲法」サンプル（抜粋）

# Principles
- Library-First（車輪の再発明をしない）
- Test-First（受入基準→テスト→実装）
- Security Baseline（OWASP ASVS L2）

# Prohibitions
- 仕様にないAPIの追加禁止
- 認証の独自実装禁止

（理念は公式ブログの説明する「仕様を真ん中に置く」流れに合致）(The GitHub Blog)

つまずきにくい運用のコツ

コストを抑える（トークン・時間）

1仕様＝1機能に小分け
差分更新の思考（すべてやり直さない）
E2Eの合格条件を最初に固定（迷いを減らす）
（「段階ごとに検証する」—公式の型と一致）(The GitHub Blog)

VS Code側のベストプラクティス

WSL拡張は必須（補完・デバッグ等の面で推奨）(Microsoft Learn)
CopilotセットアップはVS Codeの手順に沿う（サインイン→拡張）(Visual Studio Code, GitHub Docs)

参考：公式が示す全体フロー（確認用）

Prerequisites（Linux/macOS、WindowsはWSL2、Copilot/Claude/Gemini、uv、Python 3.11+、Git）(GitHub)
初期化コマンド：uvx --from ... specify init <PROJECT_NAME>（--ai copilot可）(The GitHub Blog, GitHub)
ワークフロー：/specify → /plan → /tasks → 実装（エージェント横断）(The GitHub Blog)

出典

GitHub SPEC.Kit リポジトリ（README/詳細手順/Prerequisites）：WSL2・Copilot/Claude/Gemini対応、--ai copilot、Troubleshooting等。(GitHub)
GitHub 公式ブログ：SPEC.Kitの狙いと4フェーズ、複数エージェント対応。(The GitHub Blog)
WSL 公式（Microsoft Learn）：wsl --install、WSL2の基本、VS Codeとの接続。(Microsoft Learn)
uv 公式ドキュメント：インストール方法、uvx --from git+... の使い方、Python導入。(Astral Docs)

これで、Windows + GitHub CopilotでSPEC.Kitを実際に使えるはずです。

競合との比較：Kiro.devとSPEC.Kit