Spec Kit完全ガイド｜Claude Code×Copilot両対応のAI駆動開発

GitHubが公開する仕様駆動開発フレームワーク「Spec Kit」を、Claude CodeとGitHub Copilotで使いこなす方法を解説。インストールから実装まで、忖度なしの実用ガイドです。

まず結論

Spec Kit はGitHubがオープンソースで公開する「仕様駆動開発」のためのフレームワーク
「仕様 → 計画 → タスク → 実装」をMarkdownで体系化し、AIエージェントに渡す設計図にする仕組み
Claude CodeとGitHub Copilot両対応。同じリポジトリで併用できるので、チーム内でツールが混在しても安心
セットアップは uv を使って数分。完全無料（オープンソース）
AIに「いきなり実装させて手戻り祭り」が起きる人にこそ、知ってほしい仕組みです

ニュース元: Spec KitでAI駆動開発を始める：Claude CodeとGitHub Copilot両対応ガイド（Zenn）

1. Spec Kitって何？まずは仕組みから

Claude CodeやCopilotで開発していて、こんな経験ありませんか？

「コードを書いて」と一言頼んだら、想定と全然違うものが出てきた
何度も修正指示を出しているうちに、AIが最初の意図を忘れてしまう
チャットが長くなるほど、提案の質が落ちていく

これ、AIの能力不足というより、「何を作るか」が言語化されていないことが原因なんですよね。

Spec Kitはここに切り込みます。仕様を先にMarkdownで固めて、それをAIに渡す——たったそれだけのことを、フレームワーク化したオープンソースプロジェクトです。

Spec Kitの基本ワークフロー

constitution → specify → clarify → plan → tasks → analyze → implement

カタカナだらけで身構えそうですが、要するに次の流れです。

constitution（憲法）: プロジェクトの不変ルールを決める（言語、フレームワーク、コーディング規約など）
specify（仕様化）: 「何を作るのか」を spec.md に書く
clarify（明確化）: 曖昧な部分をAIと対話して詰める
plan（計画）: 実装方針を plan.md にまとめる
tasks（タスク分割）: 実装手順を tasks.md に細かく分ける
analyze（分析）: タスク間の依存関係や順序をチェック
implement（実装）: 上記すべてをコンテキストとしてAIに渡し、コードを生成

各段階でMarkdownファイルが残るのがミソです。チャットの中身は揮発しますが、ファイルは残る。だから途中でAIが「ブレた」と感じたら、spec.md を読み返させればすぐ軌道修正できます。

2. なぜClaude CodeとCopilotの両対応が重要なのか

正直に言うと、わたしは最初「両対応？ふーん」くらいに思っていました。が、よく考えるとこれ、地味に革命的なんですよね。

よくある現場の課題

シチュエーション	起きがちな問題
チーム内でツールが混在	「俺はClaude、お前はCopilotか…」プロンプトの再利用ができない
プロジェクトを引き継ぐとき	前任者のAI指示文が共有されておらず、ゼロからやり直し
自分一人でも複数ツール使ってる	ChatGPTで設計、Claude Codeで実装、Copilotで補完…で意図が散らかる

Spec Kitは、ツール側ではなくリポジトリ側に「AI向けの設計図」を置く発想です。

生成されるファイルを見ると、その思想がはっきり出ています。

.specify/        ← フレームワーク本体
.claude/skills/  ← Claude Code 用のスキル定義
.github/agents/  ← GitHub Copilot 用のエージェント定義
.github/prompts/ ← Copilot 用のプロンプト定義

.claude/ と .github/ の両方に同じ情報源（.specify/）から自動生成された定義が入る。つまり**「同じ仕様を、両方のAIエージェントが読める形で用意してくれる」**わけです。

個人開発者にもメリットあり

「自分一人だし関係ない」と思った人、ちょっと待ってください。

今日はClaude Codeで気分よく書きたい
明日はVS Code内のCopilotでサクッと書きたい
来月にはまた別の新しいAIエージェントが出ているかもしれない

ツールを乗り換えても、仕様ファイル（spec.md / plan.md / tasks.md）が残っていれば、新しいツールにすぐ慣れさせられる。これ、AIツールがどんどん入れ替わる時代において、地味だけど強い保険です。

3. インストール手順｜実は5分で終わる

前提・準備するもの

uv（PythonのモダンなパッケージマネージャをCargo的に使うツール）
Claude Code または GitHub Copilot を使える環境
Git リポジトリ（既存でも新規でもOK）
所要時間: 5〜10分

uv が入っていない人は先に入れておきましょう。

curl -LsSf https://astral.sh/uv/install.sh | sh

ステップ1: 新規プロジェクトを作る

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

uvx は「一時的にインストールして実行する」コマンドです。pip install 的なものを汚さずに済むのが嬉しいところ。

ステップ2: 既存プロジェクトに導入する

すでに動いているプロジェクトに後付けする場合はこちらです。

cd <既存プロジェクト>
uvx --from git+https://github.com/github/spec-kit.git specify init --here

.specify/ 配下にフレームワークの本体が、.claude/ と .github/ 配下にエージェント定義が自動で生成されます。Gitリポジトリ直下に置くのが推奨です。

ステップ3: constitutionを書く

最初に .specify/memory/constitution.md を編集します。プロジェクトの「絶対に守るルール」を書く場所です。

例えばこんな感じ。

# プロジェクト憲法

- 言語: TypeScript（strictモード必須）
- フレームワーク: Next.js 15（App Router）
- テスト: Vitest
- スタイル: Tailwind CSS
- コミットメッセージ: 日本語、Conventional Commits準拠
- DB操作はPrismaのみ、生SQL禁止

ここで決めたルールは、以降のすべてのAI生成のベースラインになります。

ステップ4: spec.mdを書いてAIに渡す

機能ごとに spec.md を作って、Claude Code（または Copilot）に /specify コマンドで読ませる流れです。

# 機能: ユーザー認証

## 目的
ログイン機能を追加し、未ログインユーザーをトップページへリダイレクトする

## 要件
- メールアドレス + パスワードのログイン
- セッションはJWT（24時間有効）
- パスワードはbcryptでハッシュ化
- ログイン失敗時のエラーメッセージは日本語

## やらないこと（重要）
- ソーシャルログイン
- 2段階認証
- パスワードリセット（次のスプリント）

💡 ここでつまずきやすい

「やらないこと」を書くのがコツです。AIは放っておくと親切心で色々足してくれるので、明示的に範囲を絞っておかないと、想定の3倍くらいのコードが返ってきます（経験談）。

4. 応用テクニック｜Synthがやっている工夫

テクニック1: clarify を必ず通す

specify のあとに clarify を挟むと、AIが「ここ、決まってないですよね？」と質問してくれます。

正直、最初は面倒くさいんですよ。「いいから早く実装してよ」って言いたくなる。

でも、ここで5分追加するだけで、実装後の手戻りが平均で30〜40%減ります（わたしの体感値）。実装してから「あ、そっち想定してなかった」をやるのが一番もったいない。

テクニック2: tasks.md を人間がレビューする

tasks.md はAIが「実装手順を細分化」したものです。これをそのまま実装に流す前に、人間が一度目を通すのを強くおすすめします。

理由は、たまにAIが順序を逆にするから。たとえば「DB マイグレーション → API実装 → フロント実装」となるべき所が、「API → マイグレーション」になっていたり。

# tasks.mdを開く
$ open .specify/specs/feature-auth/tasks.md

中身を確認して、変な順序になっていたら手動で並び替え。これだけで実装中のエラーが激減します。

テクニック3: 失敗ログを constitution に追記していく

開発中に「この種類のバグ、何度も踏むな」と気づいたら、その回避策を constitution.md に追記する。

例:

- Server Action で fetch を使うとき、必ず `revalidatePath` を呼ぶ
  → 忘れるとキャッシュが効いて画面が更新されない

これをやると、AIが同じ罠を二度と踏まなくなります。プロジェクト固有の知見が憲法として蓄積されるイメージ。

5. 正直な評価｜ここは良い・ここは微妙

使い心地の総評（筆者の実感）: ★★★★☆

仕様の言語化習慣: ★★★★★（強制されるので嫌でも身に付く）
セットアップの手軽さ: ★★★★☆（uvが入っていれば数分）
学習コスト: ★★★☆☆（最初の数日は「型」に慣れが必要）
速度: ★★★☆☆（仕様化に時間がかかる分、立ち上がりは遅い）
ツール非依存性: ★★★★★（Claude/Copilot両対応は強い）

✅ ここが良い

AIが「何を作るか」を見失わない（コンテキスト劣化への耐性が圧倒的）
仕様ファイルがそのままドキュメントになる（後任への引き継ぎが楽）
Markdownなので人間にもAIにも読みやすい
完全無料・オープンソース（GitHubが公式メンテ）

❌ ここが微妙

小規模なスクリプト1本書くだけなら、明らかにオーバースペック
最初に仕様を書く時間が必要なので、「とにかく早くコード書きたい」気分の日はストレス
uv が前提なので、Pythonに馴染みがない人は環境構築でつまずく可能性
まだ歴史が浅いので、運用ノウハウは自分で蓄積していく感じ

💡 正直な本音

すべてのプロジェクトに使うものではない、と思っています。書き捨てスクリプトや個人の趣味コードに導入したら、たぶん面倒で続きません。

ただ、「3日以上かかる開発タスク」や「他人と共有する可能性のあるコード」には、ほぼ確実に効きます。AIに無計画に指示して手戻りで時間を溶かしている人は、一度試す価値ありです。

6. よくある質問

Q1: Cursorでも使えますか？ A. 公式に対応しているのは現時点ではClaude CodeとGitHub Copilotの2つです。ただし生成される spec.md などはただのMarkdownなので、Cursorに手動で読ませる形なら使えます。

Q2: 既存のプロジェクトに途中から入れて大丈夫？ A. 大丈夫ですが、最初の constitution.md に「既存コードのスタイルに合わせる」と明記しないと、AIが独自ルールで書き始めることがあります。

Q3: 仕様が頻繁に変わるプロジェクトでも使える？ A. 使えます。むしろ仕様変更のたびに spec.md を更新する運用が回るので、「仕様と実装の乖離」が起きにくくなります。

Q4: 本当に無料？ A. はい、GitHub公式のオープンソースプロジェクトで完全無料です。利用するAI側（Claude Code Pro等）の料金は別途かかります。

あなたへの影響

立場別に整理します。

個人開発者（副業/趣味で書く人） → 1日で終わる作業ならスキップでOK。3日以上の開発に使うと効果絶大
チーム開発者 → 仕様共有の標準化に使える。spec.md がそのままレビュー対象になるのが便利
AIで書き始めたけど挫折気味の人 → これ、たぶんあなた向けです。「AIに丸投げ」と「全部自分で書く」の中間が見つかります
Claude CodeとCopilotを併用してる人 → むしろ使わない手はない。両者の出力品質が揃うのは本当に助かる

特に「AIに指示しても思った通りに動かない」とフラストレーションを溜めている人。原因の8割は指示の解像度不足です。Spec Kitは、それを構造的に解決するためのツールです。

💡 本格的にAIプログラミングを学びたい人へ DMM WEBCAMP 学習コース無料相談（PR） — 独学で詰まりがちなプログラミング学習を、現役エンジニアのメンタリング付きで進められます。Claude CodeやCopilotといったAIツールも学習対象に含まれています

まとめ

Spec Kitは「AIに何を作るかを伝える」プロセスを、Markdownで仕組み化したものです。AIを賢く使うために、人間側が言語化を頑張る——その手助けをしてくれる、地味で強いツールでした。

3日以上かかる開発をAIと進める予定がある人は、一度試してみる価値ありです。仕様を書く30分が、実装の3時間を救うことがあります。

ーー Synth