Spec Kitの使い方｜AIエージェントに渡す3つの開発プロセス

「spec-kit チュートリアル」で見つけた日本語の解説記事を開きながら Spec Kit を触ろうとすると、手順が噛み合わない場面に遭遇します。記事にある /speckit.specify をエージェントに投げても反応がない、--ai claude というフラグが受け付けられない、uvx --from git+... の長いコマンドが公式のどこにも見当たらない。こうしたズレは、どこかで自分の環境設定を間違えたのではないかという疑いを生み、最初の一歩に無駄な時間を使わせます。

原因の多くは環境ではなくリリース速度にあります。Spec Kit は 2026年9月22日に v1.0.10、24日に v1.0.11、25日に v1.0.12 が公開されており、パッチリリースが数日間隔で続いている状況です（リリース一覧）。この間にコマンドの呼び出し記法やインストール経路の推奨が変わっているため、2025年に書かれた記事の手順が現行版と一致しないことは、むしろ自然な結果といえます。

加えて、Spec Kit を「仕様書から実装を生成するツール」という一面だけで捉えていると、導入判断を誤りやすくなります。現行の README は、このツールキットが 3 つの独立した入口を持つと明示しており、フルセットのプロセスを回さなくても使い始められる設計になっています。

本記事では、公式 README・公式ドキュメントサイト・CHANGELOG と GitHub API から取得した公開値のみを根拠に、現行版の使い方と採用判断の材料を整理します。過去の spec-kit チュートリアルとどこがずれているのかも、差分の形で対照します。動作検証やインストールは行っておらず、公開ドキュメントの記述を照合してまとめた内容である点をあらかじめお伝えします。 手元の環境で挙動を確認する際は、必ず一次情報である公式ドキュメントを併せて参照してください。

Spec Kitとは｜AIコーディングエージェントに開発プロセスを渡すOSS

Spec Kit（github/spec-kit の README）は、GitHub が公開しているオープンソースのツールキットです。README は自身の位置づけを次のように定義しています。

Spec Kitは、AIコーディングエージェントに構造化されたプロセス、再利用可能なテンプレート、記録に残る成果をもたらすオープンソースのツールキットです。

（出典: 公式の日本語 README）

ここで押さえておきたいのは、Spec Kit が単一のプロセスを強制するツールではないという点です。README には「These are independent entry points, not three mandatory phases.（これらは独立した入口であり、3つの必須フェーズではありません）」と明記されており、後述する 3 つのプロセスは、どれか 1 つだけを選んで使い始められます。

なお、このツールキットが前提としている開発の考え方そのもの（仕様を起点に実装を進めるアプローチと、従来の要件定義との位置づけの違い）については、仕様駆動開発とは？要件定義との違いで整理しています。本記事はエンジニア視点での導入手順と選定判断に絞り、概念の掘り下げは扱いません。

3つの独立したプロセスと得られる成果

README の「利用するプロセスを選択する」では、やりたいことごとに入口が整理されています。

（出典: 公式の日本語 README）

コアに同梱されているのは仕様駆動開発（SDD）のみで、バグ修正とアイデア評価はバンドル拡張として後から追加する構成です。「大がかりなプロセスを丸ごと導入しないと試せない」という前提は、現行版には当てはまりません。

リポジトリ基本情報とライセンス

GitHub API から 2026年9月28日時点で取得した公開値は次のとおりです。

ライセンスは MIT であり、商用プロジェクトへの組み込みにあたっての制約は小さい部類です。また、アーカイブ済みリポジトリでもフォークでもないため、上流の更新をそのまま受け取れる本家として扱えます。

もう一点、初見時に混乱しやすいのが名前の対応関係です。リポジトリ名は spec-kit ですが、インストールする PyPI パッケージ名は specify-cli、実行するコマンド名は specify です。3 つがすべて異なるため、検索時にどの名前で探すべきか迷いやすい箇所です。

Spec Kitの使い方｜CLIの導入から最初のスキル呼び出しまで

ここからは、公式ドキュメントが示している現行の導入手順を順に追います。全体の流れは「CLI をインストールする」→「プロジェクトを初期化してエージェント連携ファイルを生成する」→「エージェントのチャットからスキルを呼び出す」の 3 段です。

前提環境とインストール方法の3経路

インストールガイドが挙げている前提は次の内容です。

• Python 3.11 以降
• uv（推奨）または pipx
• 対応する AI コーディングエージェント
• Linux / macOS、または PowerShell が使える Windows
• Git（git 拡張を有効にする場合のみ必要）

インストール経路は 3 つ用意されています。ソースからの導入はバージョンを固定できるため、同ガイドでは推奨経路として提示されています。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

（出典: インストールガイド）

PyPI 経由で入れる場合は、パッケージマネージャーに応じて次のいずれかを使います。

uv tool install specify-cli
pipx install specify-cli
pip install specify-cli

（出典: インストールガイド）

PyPI 経由でもバージョン指定は可能で、uv tool install specify-cli==0.12.11 のようにバージョンを固定できます。3 つめの経路として、uvx による一回限りの実行も案内されています。数日間隔でパッチが出ている状況を踏まえると、チームで足並みを揃えるならバージョンを固定する経路のほうが扱いやすいでしょう。

導入後の確認コマンドとして、同ガイドは specify version と specify self check の 2 つを挙げています。前者は入っているバージョンを表示し、後者は最新の GitHub リリースと照合します。

specify init のフラグと連携キーの指定

README が示す「はじめる」の手順は 3 行です。

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

（出典: github/spec-kit README）

README はこの例について「この例では GitHub Copilot のデフォルトのスキルモードを使用しています。他の対応エージェントを使う場合は、copilot をお使いのエージェントの連携キーに置き換えてください」と補足しています。つまり --integration に渡す値が、使うエージェントを決める鍵になります。

specify init の主なフラグは次のとおりです。

（出典: インストールガイド）

初期化を実行すると、選択したエージェント向けのファイルが生成されます。連携キーの一覧によれば、生成先はエージェントごとに異なり、Claude Code は .claude/skills、GitHub Copilot は .github/skills/、Cursor は .cursor/skills に配置されます。

同リファレンスでは 50 以上の AI コーディングエージェントに対応していることと、そのうち 28 件が multi-install safe として宣言されていることが示されています。multi-install safe は、複数の連携を同時にインストールしても管理ファイルが衝突しない条件を満たすものを指します。チーム内で使うエージェントが分かれている場合は、この 28 件に自分たちの組み合わせが含まれるかが実務上の確認ポイントになります。連携の管理には specify integration list / install <key> / switch <key> / upgrade が用意されています。

/speckit-* はターミナルコマンドではなくエージェントのスキル

初見で最も詰まりやすいのがこの点です。README は次のように明記しています。

各 /speckit-* スキルはエージェントのチャット内で、1つずつ呼び出し、結果を確認してから次に進んでください。これらはターミナルコマンドではなく、エージェントのスキルです。

（出典: 公式の日本語 README）

シェルに打ち込むものだと思って実行すると、当然コマンドが見つからないというエラーになります。投げる先はエージェントのチャット欄です。

さらに、呼び出しの記法自体がエージェントごとに異なります。連携キーの一覧には次の差異が記載されています。

自分が使っているエージェントの記法を確認せずに、他のエージェント向けに書かれた記事の記法をそのまま打ち込むと反応がありません。「コマンドが通らない」の原因として、まず疑うべき箇所です。

3つのプロセスの使い分けと生成される成果物

3 つのプロセスは、呼び出すスキル列と生成先、最終判定値がそれぞれ異なります。横並びで眺めると、どこから試すべきかを判断しやすくなります。

各コマンドの詳細はコマンドリファレンスに整理されています。

仕様駆動開発（SDD）— constitution から converge まで

コアに同梱されているプロセスです。README が示す呼び出し例は次のとおりです。

/speckit-constitution Create principles focused on code quality, testing, and maintainability.
/speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album.
/speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite.
/speckit-tasks
/speckit-implement
/speckit-converge

（出典: github/spec-kit README）

各コマンドの役割と成果物は次のように整理されています。

（出典: コマンドリファレンス）

運用のリズムについて、README は「プロジェクトごとに一度だけ全体ルール（constitution）を定め、機能ごとに 仕様化（specify）→ 計画（plan）→ タスク化（tasks）→ 実装（implement）→ 収束（converge）を行います」と説明しています。constitution はプロジェクト単位で 1 回、それ以降は機能単位で反復するという分担です。

ここで重要なのは、9 つのステップすべてが必須ではないことです。コマンドリファレンスによれば、/speckit-plan の前に必須なのは /speckit-specify のみで、clarify / checklist / analyze は任意の品質ゲートとして位置づけられています。小さく始めて、必要になったゲートを後から差し込む運用が想定されています。

最終ステップの converge については、README が「収束結果が Converged と報告されるまで、implement → converge を繰り返します」と記しています。1 回の実装で完了と見なさず、評価を挟んで反復する設計です。

バグ修正 — assess から test まで

バグ修正はバンドル拡張として追加します。

specify extension add bug

追加後の呼び出し例は次のとおりです。

/speckit-bug-assess "Submitting an empty password crashes the login form." slug=login-crash
/speckit-bug-fix slug=login-crash
/speckit-bug-test slug=login-crash

（出典: github/spec-kit README）

診断（assess）→ 修正（fix）→ 検証（test）の 3 段構成で、成果物は .specify/bugs/<slug>/ 以下に assessment.md / fix.md / test.md として残ります。最終判定は verified / partial / failed の 3 値で、バグ修正ガイドは partial を「一部の検証が完了せず追加の証跡が必要な状態」、failed を「検証で問題が残っていることが判明し、診断または修正を見直すべき状態」と説明しています。

この設計思想を端的に示しているのが、README にある「Missing verification is not a successful fix.（検証の欠落は修正の成功ではない）」という一文です。修正コードが書けた時点ではなく、検証が記録された時点をゴールに置いています。

このプロセスは SDD の機能ワークフローを先に回す必要がありません。既存プロジェクトの不具合対応だけに絞って試せるため、導入の入口として最も軽い選択肢になります。

アイデア評価 — intake から decide まで

アイデア評価も拡張として追加します。

specify extension add assess

呼び出し例は 5 ステップです。

/speckit-assess-intake "Let users work offline and sync when they reconnect." slug=offline-mode
/speckit-assess-research slug=offline-mode
/speckit-assess-define slug=offline-mode
/speckit-assess-shape slug=offline-mode
/speckit-assess-decide slug=offline-mode

（出典: github/spec-kit README）

成果物は .specify/assessments/<slug>/ に生成され、最終判定は go / needs-clarification / kill の 3 値です。アイデア評価ガイドが扱う範囲にはソースコードが必要ないため、まだ実装が始まっていないプロジェクトでも単独で成立します。

go と判定された場合は、そのまま /speckit-specify に引き渡して仕様化に進めます。逆に kill も価値ある結果として扱われており、README は「stopping with a documented reason is also a useful result.（記録された理由をもって止めることも有用な結果である）」と述べています。作らない判断を成果物として残す設計は、企画段階のドキュメントが散逸しやすいチームにとって検討に値する部分です。

日本語の解説記事と手順が合わないときに確認する5つの差分

冒頭で触れた「記事どおりに動かない」問題は、現行の公式記述と過去の記述を対照すると、原因がはっきりします。2025年時点の記述が残る解説では、次の点が現行版と食い違っている可能性があります。

変わった5点の差分

これに加えて、SDD の最終ステップである /speckit-converge は比較的新しい追加であり、これに言及していない解説は現行のリズムを反映していない可能性があります。日本語ドキュメントの状況も変わっており、CHANGELOG の v1.0.11 には日本語 README を追加した記載があります。非公式の翻訳記事に頼らず、公式の日本語 README を起点にできる状態になっています。

補足として、公式ドキュメントサイトのページによっては、ドット区切りの旧記法が残っている箇所も見受けられます。記法で迷った場合は、更新頻度の高い main ブランチの README と CHANGELOG を優先して参照するのが安全です。

手元のバージョンを確認する

自分の環境が現行版かどうかは、次のコマンドで切り分けられます。

アップグレードガイドでは、CLI 本体の更新（specify self upgrade）と、プロジェクト内に生成済みのファイルの更新（specify integration upgrade / specify extension update）が別のコマンドとして分かれている点が示されています。CLI を上げただけではプロジェクト側のファイルが古いまま残るため、記法の不一致に遭遇したときは両方を確認する必要があります。

カスタマイズの幅｜extensions・presets・workflows・bundles

自社の開発ルールをどこまで載せられるかは、採用判断の大きな論点です。Spec Kit は 4 つの区分でカスタマイズ手段を整理しています。

（出典: カスタマイズガイド）

一度限りの調整には、再利用可能な preset を作らずにプロジェクトローカルのオーバーライドを使う方法が案内されています。カスタマイズガイドは、テンプレートの解決順序がプロジェクトローカルのオーバーライド → インストール済み preset → 拡張 → コアの既定値であると説明しており、組織全体の共通部品に影響を与えずに個別プロジェクトだけを調整できる構造になっています。

リポジトリの中身も、この 4 区分に対応する形で整理されています。extensions/ には agent-context / assess / bug / git / selftest / template と 2 種類のカタログ（公式・コミュニティ）、presets/ には constitution-sync / lean / scaffold / self-test、bundles/ には assess / bugfix が置かれています。templates/ には spec / plan / tasks / checklist / constitution の各テンプレートが揃っており、これらを差し替えることで出力される成果物の形式を自社の書式に寄せられます。拡張開発者向けには API リファレンスや公開手順のドキュメントも同ディレクトリに含まれています。

注意点として、CHANGELOG を追うとコミュニティ拡張やプリセットのカタログ更新が高頻度で記録されています。エコシステムが動いているという肯定的な材料である一方、コア側の仕様も短い周期で変化しうることを示す材料でもあります。カスタマイズを深く作り込むほど、上流の変更に追従するコストが上がる構造にあります。

類似OSSとの違い｜OpenSpec・BMAD-METHOD・Agent OSとの比較

同じ領域には複数の OSS が存在します。まず、GitHub API から 2026年9月28日時点で取得した公開値を並べます。

スター数では Spec Kit が最大で、最終 push を見ると上位 3 件はいずれも調査時点から数日以内に更新されています。Agent OS は 1 か月ほど間隔が空いており、規模・更新頻度とも他 3 件より小さい位置にあります。

ライセンスで注意が必要なのは BMAD-METHOD です。GitHub API が返す SPDX 識別子が NOASSERTION であり、標準的な識別子に紐づいていません。企業で利用する場合は、LICENSE 本文を個別に確認する工程が追加で必要になります。Spec Kit / OpenSpec / Agent OS はいずれも MIT です。

以下の機能特性の比較は、各リポジトリの公開ドキュメントと公開されている比較記事をもとに整理したものです（参照: aicodingpatterns.com の比較記事、DEV Community の比較記事）。

選定軸3つで見た使い分け

1つめは、プロセスの重さです。 OpenSpec は仕様を差分（delta）として管理する最軽量の路線で、フェーズや品質ゲートを持たず、プレーン Markdown 中心でオーバーヘッドを抑える設計と説明されています。規律はツールではなく利用者側が担う形です。BMAD-METHOD は対極で、アナリスト・PM・アーキテクト・UX・スクラムマスター・開発・QA・テクニカルライターなど 12 以上の専門エージェントでアジャイルチームを模擬します。オーケストレーター主導のフローを持つ分、習熟コストとトークンコストが高いと指摘されています。Spec Kit はこの中間で、フェーズを持ちながら clarify / checklist / analyze を任意ゲートとして切り離せるため、重さを段階的に調整できます。

2つめは、カバーするプロセス範囲です。 Spec Kit は仕様駆動開発に加えてバグ修正とアイデア評価を独立した入口として持ちます。OpenSpec は仕様の差分管理に焦点を絞り、BMAD-METHOD は企画から品質保証までの全ライフサイクルを射程に入れます。Agent OS は方向性が異なり、既存コードベースの実際の規約を逆引きして標準文書化する「Discover Standards」に重点があります。プロセス全体を管理するのではなく、規約をエージェントに注入することが主眼です。

3つめは、エージェント対応の幅です。 ここが Spec Kit の最も明確な差別点になります。50 以上のエージェントに対応する統合層を持ち、そのうち 28 件が multi-install safe として宣言されています。Claude Code と GitHub Copilot と Cursor が社内で混在しているような状況では、この統合層の広さがそのまま導入のしやすさに直結します。逆に、チームで使うエージェントが 1 種類に統一されているなら、この差別点の価値は相対的に小さくなります。

整理すると、既存コードベースの規約を整えたいなら Agent OS、仕様の差分管理を最小構成で回したいなら OpenSpec、役割分担まで含めたプロセス全体を作り込みたいなら BMAD-METHOD、複数エージェントが混在する環境でプロセスを段階的に標準化したいなら Spec Kit という対応になります。

Spec Kitを採用するかの判断チェックポイント

ここまでの材料を、採用判断の形に落とします。

メンテナンス健全性を公開値から読む

活発さは疑う余地がない一方、この更新速度は「導入後に何もしなくてよい」状態ではないことも意味します。記法やフラグが変わりうる前提で、specify self check を定期的に回す運用が必要になります。

向くケースと慎重に判断したいケース

判断材料になりやすい条件を、両方向から並べます。

判断材料がプラスに働きやすい条件

• チーム内で複数の AI コーディングエージェントが混在しており、プロセスだけを共通化したい（50 以上の統合層と 28 件の multi-install safe が効く）
• 既存の開発規約やレビュー観点を、成果物として残る形に落としたい（テンプレート差し替えと preset で自社書式に寄せられる）
• まずバグ修正またはアイデア評価だけを小さく始めたい（拡張の追加だけで独立して成立し、仕様駆動開発を先に回す必要がない）
• 企画段階で「作らない」判断を記録として残したい（アイデア評価の kill 判定が成果物になる）

慎重に判断したい条件

• 数日間隔のパッチリリースに追従する運用コストを継続的に負えない。CLI とプロジェクト内ファイルの更新が別コマンドに分かれているため、追従作業は 1 手では済みません
• 要件変更が頻繁で、仕様の進化のさせ方まで含めた運用ルールを自前で決める余力がない。SDD の考え方は、要件変更後に仕様をどう進化させるかを規定していないことを文脈依存の問題として明示しています
• 外部にインターフェースを露出するコンポーネントが中心となるプロジェクトです。同ドキュメントは、こうしたコンポーネントでは実装前に観測可能な責務を定めるため、契約駆動開発の併用が必要だと述べています
• カスタマイズを深く作り込む前提で検討しています。カタログ更新の頻度が高く、上流の変更が自作部分に波及するリスクを見込む必要があります

公式ドキュメント自身が適用範囲の限界を明示している点は、判断材料としてむしろ扱いやすい部分です。万能なプロセス管理ツールとして評価するのではなく、上記の限界が自プロジェクトの事情と衝突しないかを確認する順序が現実的です。

導入前に確認する3点

試す前に潰しておくと手戻りが減る確認事項を 3 つに絞ります。

1. Python 3.11 以降と uv（または pipx）を入れられるか。 開発端末の管理が厳しい環境では、ここが最初の関門になります。インストールガイドにはエアギャップ環境や企業環境向けの専用ガイド（オフライン wheel バンドル、Git Credential Manager の扱い）も用意されています
2. 使っているエージェントが連携キーに存在し、必要なら multi-install safe に含まれるか。 連携キーの一覧で、対象エージェントの呼び出し記法（/speckit-* / $speckit-* / /skill:speckit-*）も併せて確認しておくと、最初のスキル呼び出しでつまずきません
3. specify version と specify self check を運用に組み込めるか。 リリース速度を踏まえると、バージョン確認を個人任せにせず、チームの手順として持つかどうかが導入後の安定度を左右します

まとめ

Spec Kit について、公開ドキュメントから確認できる要点は 3 点に整理できます。

1 点目は、3 つの入口を持つツールキットであることです。仕様駆動開発はコアに同梱されていますが、バグ修正とアイデア評価は拡張として独立して追加でき、どれか 1 つだけを選んで試せます。導入の入口としては、成果物のパスと判定値が明確なバグ修正が最も軽い選択肢です。

2 点目は、現行の記法です。スキルの呼び出しはハイフン区切りの /speckit-* で、投げる先はターミナルではなくエージェントのチャットです。エージェント指定は --integration で、記法自体もエージェントごとに異なります。spec-kit チュートリアルを参照して手順が噛み合わないときは、まず specify version と specify self check で自分の版を確認するのが近道です。

3 点目は、選定軸です。プロセスの重さ、カバーする範囲、エージェント対応の幅の 3 つで比べると、複数エージェントが混在する環境でプロセスを段階的に標準化したい場合に Spec Kit の統合層の広さが効きます。一方で、数日間隔のリリースに追従する運用と、公式が規定していない領域（要件変更後の仕様の進化、外部インターフェースの契約定義）を自前で埋める余力は、導入前に見積もっておく必要があります。

本記事は公開ドキュメントと GitHub API の公開値を照合して整理した内容です。導入を進める際は、更新頻度の高さを踏まえて公式ドキュメントサイトとCHANGELOGを一次情報として確認してください。

関連情報

AIコーディングエージェントを前提とした開発プロセスの設計や、既存プロジェクトへの標準化の進め方についてご検討中の方は、お問い合わせフォームからご相談いただけます。要件が固まっていない構想段階からのご相談にも対応しています。

参考リンク

• github/spec-kit（GitHub リポジトリ・README）
• 公式の日本語 README
• 公式ドキュメントサイト
• インストールガイド
• 連携キー・呼び出し方リファレンス
• コマンドリファレンス
• バグ修正ガイド
• アイデア評価ガイド
• カスタマイズガイド
• アップグレードガイド
• SDD の考え方（concepts）
• CHANGELOG