GitHub Spec Kit

GitHub Spec Kit は、仕様駆動開発 のためのオープンソースのツールキットである。2025 年の GitHub による発表では、AI コーディングアシスタントを中心としたワークフローを、明示的なゲートを伴う 4 つのフェーズに 構造化しており、以下ではまずこれを説明する。現在のリポジトリは、これらのフェーズを軸に、より大きなコマンド群と さらに 2 つのプロセスを編成しており、それについては「ツールキットの現在の姿」で説明する。/specify はプロンプトから 詳細な仕様を生成し、/plan は技術アーキテクチャを作成し、/tasks は計画を実装タスクに分解し、最後の実装ステップで タスクごとにコードを生成する。各フェーズで人間が出力をレビューして洗練させてから、ワークフローは次のフェーズへ進む。 これは、エージェントの出力を最後にチェックするだけでなく、プロセス全体を通じて意図と整合させ続けることを意図している。

機能

GitHub 自身によるこのツールキットの発表（AI による仕様駆動開発：新しいオープンソースツールキットを使い始める を参照）は、 各フェーズの目的を説明している。Specify は、何をなぜ構築するのかという高レベルの記述を受け取り、技術スタックでは なく、ユーザージャーニー、体験、そして成功がどのようなものかについての詳細な仕様をエージェントに生成させる。 Plan は、開発者がスタック、アーキテクチャ、制約 —— 標準化された技術、レガシーとの統合、コンプライアンス要件、 パフォーマンス目標 —— を提供し、エージェントが技術計画を作成する段階である。GitHub は、比較のために複数の計画の バリエーションを要求できること、またエージェントが参照できるようにした社内ドキュメントを計画に取り込めることを 指摘している。Tasks は、仕様と計画を、それぞれ単独で実装・テストできる小さなレビュー可能な単位に分解する。 GitHub はこれを、エージェント自身の作業を検証するためのテスト駆動の手段をエージェントに与えることになぞらえている。 Implement はそれらのタスクを順に処理し、その間に開発者は大量のコードの塊ではなく、焦点の絞られた変更をレビューする。

GitHub は、開発者の役割が舵取りだけでなく検証でもあること、そしてチェックポイントは次のフェーズが始まる前に ギャップや漏れを捉えるために存在することを明言している。GitHub 自身の説明によれば、このツールキットはまず specify コマンドラインツールをインストールすることで導入され、このツールがプロジェクト構造を初期化し、その後の ワークフローは /specify、/plan、/tasks の各コマンドによって駆動される。GitHub は、連携するコーディング エージェントとして GitHub Copilot、Claude Code、Gemini CLI を挙げている。

プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 は、このリポジトリが constitution、specification、plan、tasks、 implementation といったコマンドに加え、任意の clarification、analysis、checklist のコマンドを編成していると説明している。 同論文は、Spec Kit 自身のドキュメントに基づき、このツールキットの中心的な考え方を、何を構築するかを記述し、構造化された フェーズを通じて洗練させ、それらの成果物からコードエージェントに実装させること —— そして仕様は使い捨ての文書ではなく 信頼できる唯一の情報源（source of truth）として機能すること —— だと報告している。

採用とエコシステム

GitHub はこのツールキットをオープンソース化し、このアプローチは特定のツールや企業よりも大きなものであり、真の革新は ツールではなくプロセスにあると述べている。GitHub は Spec Kit を、「コードが信頼できる唯一の情報源である」から「意図が 信頼できる唯一の情報源である」へ移行するための実験と位置づけている。GitHub が特に適しているとして挙げる 3 つの シナリオは、グリーンフィールドのプロジェクト、既存システムでの機能開発 —— 仕様によって、その機能が既存のものと どのように相互作用するかを明確にせざるを得なくなるため、GitHub はこれを最も強力なケースと呼んでいる —— 、そして レガシーのモダナイゼーションである。最後のものでは、失われた当初の意図を、再構築の前に現代的な仕様として取り戻す ことができる。

2026 年の実務家による仕様駆動開発ツールの調査（コードから契約へ：AI コーディングアシスタント時代の仕様駆動開発）は、GitHub Spec Kit を Kiro および Tessl と並んで、コーディングワークフローを明示的に仕様を 中心として構造化する、代表的な 3 つの AI 支援型 SDD ツールキットの 1 つに分類している。

6 次元プロセス分類法 のもとで、Spec Kit は仕様で 2、コンテキストで 1、役割で 1、実行で 1、 検証で 1、可搬性で 2 と採点され、合計は 12 点中 8 点である。その研究はこのプロファイルを、役割と検証を犠牲にして高い 可搬性を得たものと読み解いている。同研究は Spec Kit を OpenSpec と並べて、同じ土俵で競合する 2 つの SDD ツールキットの 1 つとし、フェーズと可搬性ではより充実しているのが Spec Kit、より軽量なのが OpenSpec だと している。これらの得点は、独立した実証的測定ではなく、公式ドキュメントに基づくその研究の著者の判断を表すものであり、 同研究は Spec Kit が独立した学術的評価をまだ経ていないことを記録している。

その研究が挙げる脆弱性は、解釈への依存である。明確な仕様は役に立つが、追加のチェックなしに実装、テスト、保守が 整合し続けることを保証するものではない。同研究が Spec Kit について記録している主要なリスクは、検証が弱い箇所で 成果物と実装の間に生じるドリフトである。

ツールキットの現在の姿

プロジェクト自身のリポジトリは、上記の 4 フェーズの説明よりも広いツールキットを提示している。Spec Kit は自らを、 AI コーディングエージェントに構造化されたプロセス、再利用可能なテンプレート、文書化された成果を与えるものと説明しており、 3 つのプロセスを 3 つの必須フェーズとしてではなく、互いに独立した入口として 提供している。すなわち、機能や アプリケーションを構築するための仕様駆動開発、壊れた挙動を診断して修復するためのバグ修正、そしてアイデアに投資する 価値があるかどうかを判断するためのアイデア評価である。仕様駆動開発はコアに含まれており、残りの 2 つは specify extension add bug と specify extension add assess でインストールするオプトイン型の同梱拡張である。

セットアップは CLI のインストール（uv tool install specify-cli）に続いて specify init <project> --integration <key> を実行するもので、統合キーによってプロジェクトをどのコーディングエージェント向けに構成するかを選択する。文書化されている 前提条件は、Python 3.11 以上、uv、そして Linux、macOS、Windows 上のサポート対象エージェントである。プロセス自体は その後、エージェントのチャット内から /speckit-* として駆動される。これらは ターミナルコマンドではなくエージェント スキルである —— リポジトリはこの区別について、また 1 つずつ呼び出して次に進む前にそれぞれの結果をレビューすることに ついて明言している。

リポジトリが文書化している仕様駆動のシーケンスは、/speckit-specify、/speckit-plan、/speckit-tasks、 /speckit-implement、/speckit-converge を実行するもので、implement と converge を、converge が「Converged」と 報告するまで繰り返す。これは、以前の 4 フェーズの枠組みには対応するもののないループである。追加の品質ゲートとして、 clarification、checklist、一貫性分析のコマンドが利用できる。バグ修正のプロセス（/speckit-bug-assess、 /speckit-bug-fix、/speckit-bug-test）は、診断、修復、検証を分離しておくことで、修正が評価された原因に対処し、 チェックが元の症状をテストするようにしている。そのレポートは .specify/bugs/<slug>/ の下に置かれ、verified、 partial、failed のいずれかの判定で終わる。リポジトリは、検証が欠けているものは修正の成功とはみなされないと 述べている。評価のプロセス（/speckit-assess-intake、-research、-define、-shape、-decide）は、ソースコードの ないプロジェクトでも機能し、go、needs-clarification、kill のいずれかの決定で終わる。リポジトリは、文書化された 理由とともに中止することも有用な結果であること、そしてアイデアを構築することになった場合は go の決定を /speckit-specify に引き渡せることを指摘している。

カスタマイズは階層化されている。拡張は機能を追加し、プリセットは既存の挙動を適応させ、ワークフローはステップを 自動化し、バンドルは役割ベースのセットアップをパッケージ化する。一度きりのテンプレート変更のためには、プロジェクト ローカルのオーバーライドがある。このツールキットは MIT ライセンスである。

プロジェクトのドキュメントサイトは、このツールキットを、意図とエビデンスを実装よりも先行させ続ける構造化された プロセスをコーディングエージェントに与えるものと位置づけ、中核となる仕様駆動のシーケンスを Specify → Plan → Tasks → Implement → Converge と述べている。各フェーズは次のフェーズに渡される Markdown の成果物を生み出すため、エージェントは 場当たり的なプロンプトではなく構造化されたコンテキストから作業する。テンプレート、品質チェックリスト、成果物横断の分析は デフォルトで含まれている。サイトは、3 つのプロセスが互いに独立した入口であること、評価は単独で成立しうること、そして 進めるという決定が自動的に実装を開始するわけではないことを強調している。specify init は選択したエージェント向けの コマンドファイルとディレクトリ構造をセットアップし、一覧にないエージェントのための逃げ道として generic 統合が用意されて いる。サイトは、プロセスそのものはプリセット、拡張、ワークフロー、バンドルの中にあるため、プロジェクトは仕様駆動開発に 「あるいはソフトウェアにすら」縛られないと説明している。サイトが挙げるコミュニティ製のプロセスは、プロダクトマネジメント 寄りの SDD の変種や、品質保証ゲートを備えたマルチエージェントのオーケストレーションプロセスから、.NET Framework の 移行や長編小説の執筆にまで及ぶ。組織向けには、Spec Kit が Windows、macOS、Linux 上でオフラインかつファイアウォールの 内側でも動作すること、組織は独自のカタログをホストして、チームが見つけられる統合、拡張、プリセット、ワークフロー、 バンドルを取捨選択できること、そして CI Guard や Architecture Guard といったコミュニティ拡張がコンプライアンスのゲートと ガバナンスを追加することを述べている。

Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、仕様駆動開発 の代表的な 実装を概観する中で、Spec Kit を GitHub の CLI スイートと説明し、その中核概念として Constitution を特に取り上げている。 これはプロジェクトのアーキテクチャ原則を定義する文書であり、同書の説明では上記のフェーズより前に置かれ、Constitution → Specify → Plan → Tasks という流れになる。同書の評価は、このツールキットは志向としてはスペックファーストのままでありつつ、 チームが協働するためのテンプレート化された構造を提供しているというものだが、これは何かを測定した裏付けのない判断として 述べられている。ここで扱っている情報源のうち、Constitution のステップをこのツールの決定的な特徴として扱っているのは これだけである。