Spec Kit（GitHub）とは？使い方・インストール・コマンド一覧をv1.2で解説【2026年10月】

Spec Kit（スペックキット）は、GitHubが公開しているオープンソースのツールキットです。AIコーディングエージェントに「仕様→計画→タスク→実装」の順で作業させ、各段階の成果物をMarkdownでリポジトリに残します。2026年10月28日公開の最新版v1.2.5は uv tool install specify-cli の1行で入り、エージェントのチャットで /speckit-specify などのスキルを呼び出して使います。2025年に書かれた解説の多くはgitのURLから入れる手順や --ai フラグを前提にしていますが、v1.2.5ではそのまま通らない箇所があります。本記事では、v1.2.5を2026年10月31日に実際に導入して確かめた内容をもとに、インストール・初期化・コマンド一覧・エージェント別の呼び出し方・使いどころをまとめます。

まとめ：Spec Kit v1.2.5で押さえる要点

• 導入はPyPIから：uv tool install specify-cli で入ります。PyPIの specify-cli は公式ドキュメントが「2つの公式配布経路」の1つと明記しており、gitのURLを指定する従来の手順も引き続き使えます。
• 初期化は specify init <名前> --integration <キー>：Claude Codeを選ぶと30個のファイルが生成されました。旧来の --ai フラグはv1.2.5では存在せず、エラーで終了します。
• コマンドは10個：中核は constitution・specify・plan・tasks・implement・converge の6つ。converge は実装後に仕様との差を探し、足りない作業を tasks.md に追記します。
• 呼び出し方はエージェントで違う：Claude CodeとGitHub Copilotは /speckit-specify、Codex CLIは $speckit-specify です。資料に多い /speckit.specify はドキュメント上の表記です。
• 本体は無料（MITライセンス）。費用は組み合わせるエージェント側で発生し、各コマンドの指示ファイルだけで8〜23KBあるため、数行の修正に使うとトークンと確認の手間が見合いません。

Spec Kitの仕組みとv1.0までの変化

Spec Kitは、ターミナルで使う Specify CLI（specify コマンド）と、エージェントのチャットで使う スキル（またはスラッシュコマンド）、.specify/ 配下のテンプレート・スクリプトの3つでできています。CLIはプロジェクトにファイルを配置するだけで、仕様書やコードを書くのはエージェントです。仕様駆動開発という進め方そのものは 仕様駆動開発（SDD）とは？TDDとの違いと3つの段階 で解説しているので、本記事はSpec Kitの操作に絞ります。

2025年9月の公開からv1.0までの経緯

リポジトリの最初のコミットは2025年8月21日で、GitHubは2025年9月2日の公式ブログで公開を告知しました。公式のプロジェクト履歴によると、2026年1月22日に主任メンテナーがManfred Riem氏へ交代し、2月に拡張機能（extension）、3月にプリセット、4月にワークフローの仕組みが入りました。6月5日のv0.9.5でバグ修正用のbug拡張、7月17日のv0.13.0でアイデア評価用のassess拡張が加わり、2026年8月21日にv1.0.0が公開されています。v1.0.0の時点でエージェント連携は38件と記録されています。

2025年の解説記事の手順が通らない変更点

公開直後に書かれた解説記事を見ながら操作すると、次の箇所で詰まります。いずれもCHANGELOGとv1.2.5の実行結果で確かめました。

Windsurfの連携は「Cognition Devinに吸収された」、Roo Codeは「拡張機能の提供終了」を理由に外されています。組み込み連携で使いたい場合は対応一覧にあるエージェントを選び、一覧に無いエージェントで使う場合は、コマンドの置き場所を自分で指定する generic 連携を使います。

Spec Kitのインストール手順（uv・pipx・pip）

必要なのはPython 3.11以上、uv（またはpipx・pip）、対応するAIコーディングエージェントです。Gitは公式のインストール手順で「git拡張を有効にするときだけ必要」とされています。Specify CLIはPython製なので、npmでは入りません。

# uv（推奨）
uv tool install specify-cli

# pipx または pip でも入る
pipx install specify-cli
pip install specify-cli

# 確認
specify version

2026年10月31日にmacOSで実行すると、specify version は「CLI Version 1.2.5」を表示しました。この実行記録ではPython 3.14.6が使われています。uvは要件を満たす既存のPythonも利用し、必要な版が見つからなければ、既定ではPythonを自動取得できます。

Spec Kitのバージョン固定とGitHubソースからの導入

チームで版をそろえるなら、版番号を指定します。PyPIの版番号はGitHubのリリースタグと一致します（PyPIの1.2.5＝タグv1.2.5）。

# PyPIから版を指定
uv tool install specify-cli==1.2.5

# GitHubのリリースタグから（先頭のvを付ける）
uv tool install specify-cli --from git+https://github.com/github/[email protected]

2025年の記事にあるタグなしの --from git+https://github.com/github/spec-kit.git も動きますが、その時点のmainブランチが入るため、再現性を求めるならタグを付けます。インストールせずに一度だけ試すなら uvx --from git+https://github.com/github/[email protected] specify init demo のように一時実行もできます。

Specify CLIとプロジェクトファイルの更新・CLIの削除

同じ uv tool install specify-cli を再実行しても、入っている版のまま更新されません。新しい版があるかは specify self check で確かめられ、最新なら「Up to date: 1.2.5」と表示されます。更新は、最初に使ったツールと同じもので行います（公式のアップグレードガイド）。

# PyPI経由で入れた場合
uv tool install --force specify-cli

# CLI自身に更新させる場合（uv toolとpipxの導入を自動判別）
specify self upgrade --dry-run
specify self upgrade

# プロジェクト内のファイルも新しい版にそろえる
specify integration upgrade claude
specify extension update

# 削除
uv tool uninstall specify-cli

specify self upgrade はGitHubのリリースから入れ直すため、PyPI経由の導入を保ちたいときは uv tool install --force specify-cli を使います。pipで入れたものをuvで更新すると specify が2つでき、古い方がPATHの先に残ることがあります。

specify initによるプロジェクト初期化と生成ファイル

新しいプロジェクトは、使うエージェントの連携キーを指定して作ります。キーを省くと対話画面で選べますが、CIなど対話できない環境ではGitHub Copilot（copilot）が既定になります。

specify init my-project --integration claude
cd my-project

Claude Codeを指定したv1.2.5の実行では、合計30ファイルが生成されました。主な構成は次のとおりです。.git は作られません。

• .claude/skills/speckit-*/SKILL.md：エージェントが読むスキル10本
• .specify/memory/constitution.md：プロジェクトの原則（最初は穴埋めのテンプレート）
• .specify/templates/：spec・plan・tasks・checklist・constitutionのテンプレート5本
• .specify/scripts/bash/：機能ディレクトリの作成などを行うシェルスクリプト6本
• .specify/workflows/speckit/workflow.yml：specify→plan→tasks→implementを確認の関門付きで回すワークフロー

旧来の specify init demo --ai claude は「No such option: –ai」で終了コード2になりました。古い記事のコマンドをそのまま貼ってこのエラーが出たら、--ai を --integration に置き換えます。

既存リポジトリへのSpec Kit導入

既存コードのあるディレクトリで specify init . --integration claude を実行すると、空でないことを理由に終了コード1で止まりました。既存プロジェクト向けの公式ガイドの手順は次のとおりです。

# 作業中の変更をコミットしてから、専用ブランチで
specify init --here --force --integration claude

# ブランチ作成まで任せたい場合だけ
specify extension add git

--force は衝突するパスのファイルを置き換えることがあるため、必ずコミット済みの状態で実行し、差分を確認します。今回の実測では既存の app.py はそのまま残りました。初期化は既存コードから仕様を逆生成しません。ガイドは、最初の仕様を「既存システム全体の文書化」にせず、CSV出力の追加のような区切れる変更から始めるよう勧めています。

対応エージェントと呼び出し方の違い

v1.2.5の specify integration list には43個の連携キーが並びました。このうち generic（任意のエージェント用）と none（エージェント用ファイルを置かない共通構成）を除く41件が特定のエージェント向けです。Claude Code・GitHub Copilot・Cursor（cursor-agent）・Codex CLI・Gemini CLI・Antigravity（agy）・Kiro CLI・Devin for Terminal・Zedなどが含まれます。

呼び出し方とファイルの置き場所は連携ごとに違います。公式の呼び出し方の比較表と、実際に初期化して確かめた配置先は次のとおりです。

公式ドキュメントのコマンド表は /speckit.specify というドット区切りで書かれていますが、これは説明用の表記です。スキルとして入るClaude CodeやCopilotでは、実際に打つのは /speckit-specify です。Claude Codeのスキルの仕組み自体は anthropic skillsとは？公式19スキルの中身とClaude Code・API・claude.aiでの導入手順 で扱っています。

Claude Codeでは、Spec Kitのスキルは既定でモデルが自分から呼べる状態で入り、説明文が常にコンテキストに載ります。ほかのスキルと合わせて数が多い場合は、--integration-options="--no-model-invocation" を付けて初期化すると、中核コマンドのスキルはユーザーが明示的に呼び出した場合だけ実行されます。拡張スキルは対象外です。中核コマンドを呼ぶ必須フックがある場合は、このオプションを指定しないでください。

複数エージェントが混在するチームでのSpec Kit運用

メンバーごとに使うエージェントが違うなら、共通部分だけを specify init my-project --integration none で作ってコミットし、各自が手元で specify integration switch claude のように切り替えます。公式は、コミット前に specify integration switch none で戻し、specify integration status で既定が none だけになっていることを確かめる運用を示しています。生成されたスキルファイルは手で書き換えず、変更はプリセットか、プロジェクト単位の上書きで管理します。

Spec Kitのコマンド一覧と実行順

公式のコマンドリファレンスが示す順序は constitution→specify→clarify→plan→checklist→tasks→analyze→implement→converge です。必須なのは specify が plan より先に来ることだけで、clarify・checklist・analyze は曖昧さが残るときに挟む品質の関門です。右端の列は、Claude Code向けに生成されたSKILL.mdの大きさ（v1.2.5で実測）です。

tasks は Setup・Foundational（前提作業）・ユーザーストーリーごとのフェーズ・Polish の順にタスクを並べ、並列に実行できるものに印を付けます。analyze はファイルを書き換えない読み取り専用の点検で、問題が見つかったら、その問題を生んだ段階（要件なら specify か clarify、設計なら plan）に戻って直します。taskstoissues はv1.1.3で非推奨になり、今後のマイナー版で削除される予定です。Issue化は specify extension add github で入るgithub拡張に移っています。

convergeによる実装漏れの検出とタスク追記

converge はv0.11.2で加わった、implement の後に回すコマンドです。コードを仕様・計画・タスクと突き合わせ、重大度付きの指摘を出したうえで、結果を2通りのどちらかで返します。差がなければ「Converged」と表示して tasks.md を一切変えません。差があれば tasks.md の末尾に Convergence の節を追記し、その件数を伝えます。コードを書き換えたり消したりはせず、書き込むのはタスクの追記だけです。公式のREADMEは、Converged が出るまで implement と converge を繰り返す流れを最小手順として示しています。

Spec Kitの使い方：仕様から実装までの流れ

以下はClaude Codeでの例です。各スキルは1つずつ実行し、出力を読んでから次へ進みます。

1. 原則を決める：/speckit-constitution テストを先に書く。公開APIの互換性を壊さない。 のように、チームが実際に守っている規約を渡します。架空の規則を足すと、後の計画と分析で余計な指摘が増えます。
2. 仕様を書く：/speckit-specify の後に、技術スタックを含めずに「何を・なぜ」を書きます。specs/001-equipment-loan-tracking/spec.md のような機能ディレクトリに、仕様と要件の品質チェックリストが作られます。
3. 曖昧さを潰す：/speckit-clarify で質問に答えると、回答が spec.md に書き戻されます。
4. 計画を立てる：/speckit-plan Next.jsとPostgreSQLを使う。 のように、ここで初めて技術の選択を渡します。
5. タスクに分けて実装する：/speckit-tasks→（任意で /speckit-analyze）→/speckit-implement。大きな機能は「SetupとFoundationalのフェーズだけ実装」のように範囲を区切って実行します。
6. 差を詰める：/speckit-converge が Converged を返すまで implement と交互に回します。

2026年10月22日にv1.2.2とClaude Code（sonnetモデル）で /speckit-specify を1回実行した記録では、「社内の備品貸出を記録するWebアプリ。社員は備品を借りて返す。返却期限を過ぎた貸出は管理者が一覧で確認できる。」という3文から、137行の spec.md ができました。中身はユーザーストーリー4本・機能要件17件（FR-001〜FR-017）・成功基準7件・前提8項目で、確認の質問は0件でした。依頼に無い「管理者が備品を登録・管理する」ストーリーが追加されており、前提の欄には「最大貸出日数の制限は設けない」などの既定値が書かれていました。質問が出なかったことは、仕様が正しいことを意味しません。前提の欄を読んで、意図と違う既定値を clarify か手作業で直す工程が要ります。

個々の操作を手で打つ代わりに、specify workflow run speckit --input spec="作りたいものの説明" で付属のワークフローを回すこともできます。付属ワークフローの承認・却下の関門はspecifyの後とplanの後の2か所で、却下すると停止します。tasksからimplementへは承認ゲートを挟まず進みます。

bug拡張によるバグ修正とassess拡張によるアイデア評価

v1.x のSpec Kitは、仕様駆動開発だけでなく、バグ修正とアイデア評価の手順も同梱しています。どちらもSDDの工程を先に済ませる必要はなく、必要なときに拡張として追加します。

specify extension add bug
specify extension add assess

bug拡張を追加すると、speckit-bug-assess・speckit-bug-fix・speckit-bug-test の3つのスキルが増えました。原因の評価・修正・元の症状が消えたかの検証を別々の報告として .specify/bugs/<slug>/ に残し、最終判定は verified・partial・failed のいずれかです（公式のバグ修正ガイド）。assess拡張は intake→research→define→shape→decide の5段階で、作るかどうかを go・needs-clarification・kill のいずれかで判断します。go になった案件だけを specify に渡す使い方ができます。

Spec Kitの工程をMCPサーバーのダッシュボードで承認しながら進めたい場合は、別製品の spec-workflow-mcpとは？導入手順とClaude Code・Cursor・Codexの設定、配布版2.2.5の注意点 も選択肢になります。

Spec Kitの料金とトークン消費の目安

Spec Kit自体はMITライセンスで、利用料はかかりません。費用はClaude Code・GitHub Copilot・Codex CLIなど、組み合わせるエージェントの契約で決まります。

注意すべきはトークンの消費です。v1.2.5でClaude Code向けに生成された中核スキル10本のSKILL.mdは英文で合計139,576バイト（約140KB）あり、specify は18.7KB、checklist は22.8KBです（1KB＝1,000バイト）。各コマンドは実行のたびにこの指示と、その工程に必要な成果物（plan なら spec.md、implement なら tasks.md など）を読み込むため、入力トークンが増える要因になります。直接依頼する場合との総消費量の差は、モデルや実行回数、修正の往復によって変わります。従量課金やプレミアムリクエスト数の上限がある契約では、最初は小さな機能で1周回して消費量を測ってから、チームに広げるのが安全です。

Spec Kitを使うべき場面と見送る場面

ThoughtworksのBirgitta Böckeler氏は、2025年10月15日にmartinfowler.comで公開した評価で、既存のダッシュボードに概要表示を足す課題にSpec Kitを使い、「レビューするMarkdownファイルが非常に多く、互いに、また既存コードとも重複していた」と書いています。同じ時間があれば通常のAI支援コーディングで機能を作れただろう、とも述べています。この評価はconvergeやbug拡張が入る前の版に対するものですが、1つの機能ごとに spec.md・plan.md・tasks.md を人が読んで確かめる前提はv1.2.5でも同じです。

Spec Kitを使うべきなのは、1つの機能が複数の画面やAPIにまたがり、要件を文章にできる人がいて、生成された spec.md と plan.md を読む時間をレビュー工程として確保できるチームです。仕様がリポジトリに残るので、担当者やエージェントが替わっても意図を引き継げます。見送るべきなのは、数行のバグ修正・設定変更・使い捨ての試作、そして生成物を誰も読まずに implement へ進めてしまう体制です。読まれない仕様書は、指示ファイルの分だけトークンを増やすだけです。小さな修正にSpec Kitを使うなら、SDDの工程ではなくbug拡張を使います。

要件の受け入れ条件を厳密に書きたい場合は、EARS記法とは？読み方と5つの基本型の書き方を日本語例文で解説【Kiro対応】 の型を specify の入力に使うと、条件と応答の組を1文ずつ書き分けられます。AIコーディングを開発プロセスへ組み込む設計や社内展開を外部に相談したい場合は、一創の生成AI導入支援で、要件整理から運用定着まで支援しています。

よくある質問

Spec Kitの料金はいくらですか？

Spec Kit自体は無料です（MITライセンス）。費用は組み合わせるAIエージェントの契約で発生します。各工程で指示ファイルや必要な成果物を読み込むため、入力トークンが増える要因になります。直接依頼した場合との総消費量の差は、同じモデルと課題で比較して確認してください。

PyPIのspecify-cliは公式のパッケージですか？

公式です。Spec Kitのインストール手順は、GitHubのリポジトリとPyPIの specify-cli を「2つの公式配布経路」と明記しており、READMEの最初の手順も uv tool install specify-cli です。PyPIの版番号はGitHubのリリースタグと一致します。

「No such option: –ai」と表示されるのはなぜですか？

--ai フラグはv0.7.1で非推奨になり、v1.2.5では存在しないためです。specify init my-project --integration claude のように --integration に置き換えます。逆に、古いCLIで --integration を使うと「No such option: –integration」になるので、specify version で版を確かめてください。

Spec Kitで日本語の仕様書は書けますか？

書けます。テンプレートの見出しは英語ですが、日本語で指示すると本文は日本語で生成されます。v1.2.2で日本語の3文を渡した記録では、「User Scenarios & Testing」などの見出しは英語のまま、ユーザーストーリーや受け入れ条件は日本語で書かれました。READMEには日本語版（README.ja.md）もあります。

Spec KitとKiro・OpenSpecは何が違いますか？

Spec Kitは機能ごとに仕様・計画・タスクをそろえ、41件のエージェントで同じ手順を使えるCLIです。Kiroは仕様の工程を組み込んだAWSの開発環境、OpenSpecは変更ごとの差分として仕様を書くCLIです。比較は 仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpecの違いと選び方【2026年10月】 にまとめています。

関連記事

• 仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】
• 仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpecの違いと選び方【2026年10月】
• OpenSpecとは？使い方・インストール・/opsxコマンドをv1.14で解説
• Kiro IDEとは？使い方・料金・specの仕組みをIDE 1.4で解説
• spec-workflow-mcpとは？導入手順とClaude Code・Cursor・Codexの設定、配布版2.2.5の注意点【2026年10月】