Spec Kitとは？GitHub製の仕様駆動開発ツールキットの仕組みと使い方

Spec Kitとは、仕様駆動開発（SDD、Spec-Driven Development）をAIコーディングエージェントで実践するために、GitHubがオープンソースで公開しているツールキットです。コードを書かせる前に、仕様、実装計画、タスクリストを文書として明文化・合意し、それを基準にAIに実装させるという一連のワークフローを、コマンドとテンプレートの形で提供します。

Spec Kitとは何か

AIコーディングエージェントに口頭調の指示だけで実装させると、曖昧な部分をAIが「よくあるパターン」で埋めるため、動くのに意図と違うものができやすくなります。この対策として、先に仕様を文書化してから実装させるSDDという手法が広まりましたが、SDDはあくまで考え方であり、実際に何をどんな順序で書くかは各チームの手探りでした。

Spec Kitは、その手順を型として配布するものです。 GitHubが2025年9月に公式ブログで発表し、公開から1年足らずでGitHubスター12万超（2026年7月時点）と、SDD系ツールの中で最も広く注目を集める存在になりました。週に複数回のリリースが続く活発なプロジェクトで、2026年7月時点の最新はv0.14系です。

特徴は、特定のAIツールに縛られないことです。 Claude Code、GitHub Copilot、Codex CLI、Gemini CLI、Cursorをはじめ35種類のエージェント統合（2026年7月時点）が用意されており、どのツールで開発していても同じワークフローを適用できます。

仕組み

Spec Kitを導入すると、使っているエージェントにSpec Kitのコマンド群が追加されます（多くのエージェントでは/speckit.で始まる形式です）。基本のワークフローは、次の5段階が軸になります。

/speckit.constitution：プロジェクトの原則を決めます。技術選定の方針、品質基準、やらないことなど、以降のすべての判断の土台になる憲法を最初に文書化します
/speckit.specify：作りたいものを要求として書き出します。ここでは「何を、なぜ」だけを扱い、技術スタックには触れません
/speckit.plan：仕様を受けて、使う技術と実装方針を計画に落とします
/speckit.tasks：計画を、実行可能な粒度のタスクリストに分解します
/speckit.implement：タスクリストに沿って、AIが実装を進めます

補助として、仕様の曖昧な箇所をAIが質問して潰す/speckit.clarify、仕様・計画・タスク間の矛盾を検査する/speckit.analyze、品質チェックリストを生成する/speckit.checklist、実装後にコードと仕様の差分を確認する/speckit.convergeなどのコマンドがあります。

各段階の成果物は、リポジトリ内にMarkdownファイルとして残ります。つまりSpec Kitの本体は、高度なAI技術ではなく、「実装前に明文化すべき文書と、その合意手順」を定義したテンプレートとコマンドの集まりです。文書は一度書いたら終わりではなく、実装中の発見に応じて更新していく前提で設計されています。曖昧さを前工程で潰す作業を、コマンドという強制力のある形にしたことが価値の中心です。

導入は、Python製のCLI（specify-cli）をインストールし、specify initでプロジェクトに使用エージェントを指定して初期化するだけです。

実務での使いどころと注意点

効果が出やすいのは、まとまった単位の新規開発です。新しい機能の追加、新規プロダクトの立ち上げ、モジュール単位の作り直しなど、「仕様を書く価値がある大きさ」の作業で、実装前に仕様をレビューできることが、認識違いによる手戻りの削減につながります。書いた仕様・計画がそのままリポジトリに残るため、実装に合わせて更新を続ければ、後から入るメンバーやAIへの引き継ぎ資料が蓄積される副次効果もあります。

一方で、注意点は4つあります。

小さな作業には過剰：1行のバグ修正や軽微な調整にまで5段階のワークフローを通すと、オーバーヘッドの方が大きくなります。定型の修正は普通にエージェントへ指示し、まとまった開発だけSpec Kitに乗せる、という使い分けが現実的です
モノレポでは工夫が要る：複数プロジェクトが同居するリポジトリでは、コンテキストの混線や仕様ファイルの衝突が報告されてきました。現行版にはサブプロジェクト単位で初期化する公式の構成が用意されましたが、ブランチ運用や共通原則の共有は別途設計が必要で、単一プロジェクト構成から試すのが無難です
変化が速い：バージョン0.x台で、コマンド体系も初期の/specify形式から現在の/speckit.形式へ変わるなど、破壊的変更を挟みながら進化しています。導入時は最新のREADMEを正とし、少し古い解説記事を鵜呑みにしないことが必要です
仕様を書く力は要求される：Spec Kitは仕様を書く場所と順序を与えますが、仕様の中身の質までは保証しません。要求を言語化する力がないまま使うと、曖昧な仕様が立派な体裁で確定するだけです

導入判断の目線

Spec Kitの導入は、ツールを1つ増やす話ではなく、「実装前に何を確定させるか」という開発プロセスの規律を導入する話です。そのため、効果はツールの機能よりも、チームが仕様の文書化を続けられるかに依存します。

試す順序としては、まず1つの新機能開発で仕様→計画→実装の流れを一巡させ、手戻りの減り方と文書化の負担を天秤にかけるのが堅実です。無料のオープンソースであり、既存の開発環境に被せるだけで試せるため、導入実験のコストはほぼ工数だけです。 AI駆動開発の品質問題の多くは仕様の曖昧さに根があるため、その対策の型として、現時点で最も試しやすい選択肢の1つです。

関連して読める記事

Spec Kitは、仕様駆動開発（SDD）をエージェントに後付けするツールキットです。SDDの考え方、IDEに内蔵したKiro、方法論としてのAI-DLCとあわせて読むと、仕様駆動の選択肢を比較しやすくなります。

AI駆動開発（AIDD）とは？従来の開発との違いと導入の考え方

AI駆動開発（AIDD）とは、生成AIを開発工程の主役に置き、人間が方針決定と検証を担う開発スタイルです。コード補完との違い、開発工程がどう変わるか、導入の順序と注意点を解説します。

2026年7月25日

SDD（仕様駆動開発）とは？AIコーディングを仕様で制御する開発手法を解説

SDD（Spec-Driven Development、仕様駆動開発）とは、AIにコードを書かせる前に仕様を文書として確定させ、その文書を基準に実装と検証を進める開発手法です。vibe codingとの違い、Spec KitとKiroの使い分け、TDDやウォーターフォールとの違い、導入判断の考え方までを、現場でAI駆動開発を回している立場から解説します。

2026年7月18日

Kiroとは？AWS発の仕様駆動AI IDEの特徴と使いどころ

Kiroとは、AWSのエージェント型AI IDEです。要件・設計・タスクを承認ゲート付きで確定させるSpecs、Hooks、Steeringの仕組みと、CursorやSpec Kitとの違い、導入時の注意点を解説します。

2026年7月27日

AI-DLCとは？AWSが提唱するAI駆動開発ライフサイクルの中身

AI-DLCとは、AWSが提唱するAI前提の開発ライフサイクル手法です。Inception・Construction・Operationsの3フェーズ、スプリントに代わるBoltなどの用語、実務での取り入れ方を解説します。

2026年7月27日