GitHub の Spec Kit は、AI コーディング向けの新しいツールキットです。目的は、開発者が Spec-Driven Development、つまり仕様駆動開発を実践しやすくすることです。
解決しようとしている問題はとても明確です。現在の AI コーディングのワークフローは、「会話しながら書く」形に寄りすぎています。人間が大まかなアイデアを渡すと、Agent はすぐにコードを変更し始めます。短期的には速く見えますが、要件の境界、受け入れ基準、技術的なトレードオフ、タスク分解が十分に定着しないことがよくあります。プロジェクトが少し複雑になるだけで、一回限りの vibe coding になりがちです。
Spec Kit の考え方はその逆です。まず仕様を明確に書き、その後で計画、タスク、実装へ進みます。コードが最初のステップではなく、仕様が最初のステップになります。
Spec Kit とは？
Spec Kit は、GitHub がオープンソースで公開している仕様駆動開発のためのツールキットです。specify CLI、テンプレート、スクリプト、AI coding agent 向けのコマンドを提供し、チームが同じ構造化された成果物を軸に開発を進められるようにします。
強調しているのは、「AI に質問を減らさせる」ことではありません。AI がコードを書く前に、次の内容を生成し、改善することです。
- プロジェクト原則：品質、テスト、体験、性能などに関するチームの制約；
- 機能仕様：何を作るのか、なぜ作るのか、ユーザーストーリーと機能要件；
- 技術計画：どの技術スタックを使うのか、どう実装するのか、どのようなアーキテクチャ上の判断があるのか；
- タスクリスト：計画を実行可能なステップに分解する；
- 実装プロセス：一度に雑に変更するのではなく、タスクに沿って段階的にコードを修正する。
この流れによって、AI コーディングは一回のプロンプト芸ではなく、よりエンジニアリング上の協作に近づきます。
基本的な利用フロー
公式 README では、入門の流れがおおよそ次のように示されています。
|
|
初期化後、プロジェクトには .specify ディレクトリ、テンプレート、スクリプト、Agent 連携用のコマンドが生成されます。その後、対応している AI coding agent の中で /speckit.* コマンドを使い、開発を進めます。
典型的な順序は次の通りです。
|
|
/speckit.constitution はプロジェクト原則を作り、/speckit.specify はプロダクト要件を記述し、/speckit.clarify は曖昧な点を補い、/speckit.plan は技術計画を生成し、/speckit.tasks はタスクに分解します。最後に /speckit.implement が実装を実行します。
これは、Agent に直接「アプリを作って」と頼むのとは大きく違います。Spec Kit では、まず「何を作るのか」と「どう受け入れるのか」を明確にしてから、Agent に手を動かさせます。
AI コーディングの入口を変える
従来の AI コーディングは、しばしばコードから始まります。
|
|
Spec Kit は、むしろ次のような形です。
|
|
この変化は重要です。AI はコンテキストに基づいて実行するのが得意ですが、コンテキスト自体が緩いと、実行が速いほど方向から外れるのも速くなります。Spec Kit はコンテキストをファイルとテンプレートに変え、要件、計画、タスクをレビュー、修正、バージョン管理できるようにします。
言い換えると、AI をより「自由」にするのではなく、より明確なエンジニアリング上の軌道で自由に力を発揮させるものです。
コアコマンドの理解
/speckit.constitution
これはプロジェクトの「憲法」です。.specify/memory/constitution.md を生成または更新し、コード品質、テスト基準、ユーザー体験の一貫性、性能要件、技術判断のルールなど、プロジェクトが長期的に守る原則を記録します。
このステップは、単一機能の要件ではなく、チームの共通認識を書くのに向いています。
/speckit.specify
これは機能仕様の段階です。何を構築するのか、ユーザーは誰か、どの問題を解決するのか、どのような主要フローがあるのかを記述します。
公式では、この段階で技術スタックに早く入りすぎないことが特に強調されています。まず what と why を明確にし、それから how を議論します。
/speckit.clarify
これは疑問点を埋める段階です。多くの要件は、最初に書いた時点では穴があります。権限をどう扱うのか、異常状態は何か、データは永続化するのか、境界条件をどう受け入れるのか、といった点です。
/speckit.clarify の価値は、Agent が仕様内の不確実な点を能動的に見つけ、その回答を仕様ドキュメントへ書き戻すことで、後の手戻りを減らせるところにあります。
/speckit.plan
これは技術計画の段階です。ここで初めて、フレームワーク、データベース、アーキテクチャ、API、テスト戦略、制約を明確にしていきます。
/speckit.specify がプロダクトの言語だとすれば、/speckit.plan はエンジニアリングの言語です。
/speckit.tasks
このステップでは、計画を実行可能なタスクに分解します。良いタスクリストは、Agent が段階的に進められるだけでなく、人間にも各ステップの目的が理解できるものであるべきです。
/speckit.implement
最後に実装へ入ります。Agent は、前段で定着させた仕様、計画、タスクに基づいてコードを修正します。この時点では、巨大な prompt ひとつから要件を推測するのではなく、一連の構造化されたドキュメントの中で実行します。
なぜ AI コーディングに向いているのか
Spec Kit の価値は、特定の魔法のコマンドにあるわけではありません。AI コーディングで失われやすいものを取り戻す点にあります。
- 要件をレビューできる；
- 計画を議論できる；
- タスクを追跡できる；
- 意思決定にコンテキストがある；
- 成果物を Git 履歴に入れられる；
- チームがテンプレートと原則を再利用できる；
- Agent の実装が、一回限りのチャット記録だけに依存しなくなる。
これは複雑なプロジェクトで特に有用です。複数人で協作し、長期的に保守し、高い品質が求められるプロジェクトほど、一時的な prompt だけで開発を進めることはできません。
Extensions と Presets
Spec Kit には、2種類のカスタマイズ機能もあります。
- Extensions：新しいコマンド、新しいテンプレート、外部ツール連携を追加する；
- Presets：既存の仕様、計画、タスクテンプレートの形式や用語を変える。
簡単に言えば、新しい能力を追加したいなら Extension、ワークフローのスタイルを変えたいなら Preset です。
たとえば、チームは Preset によってセキュリティレビュー、コンプライアンス追跡、ドメイン用語、テスト優先のルールを強制できます。また、Extension によって Jira 連携、コードレビュー、プロジェクト健全性チェックなどの新しい段階を追加できます。
つまり Spec Kit は、すべてのチームを同じフローに閉じ込めようとしているわけではありません。仕様駆動開発のための拡張可能な骨格を提供しているのです。
誰に向いているのか
Spec Kit は、次のような場面に向いています。
- AI coding agent で新規プロジェクトのプロトタイプを作る；
- vibe coding を振り返り可能なプロセスに変える；
- AI にコード生成させる前の要件と計画の形式をチームで統一する；
- 明確な受け入れ基準とテスト要件が必要なプロジェクト；
- 要件、計画、タスク、実装プロセスをすべてバージョン管理に入れたい場合；
- GitHub Copilot、Claude Code、Codex CLI などのツールをチームで活用する方法を探っている場合。
とても小さな一回限りのスクリプトには、必ずしも向いていません。数行のコードで解決できる問題に対しては、完全な仕様フローは重く感じられるかもしれません。ただし、タスクが複数ページ、複数モジュール、状態管理、権限、データモデル、長期保守に関わり始めると、Spec Kit の構造化による利点ははっきりしてきます。
私の理解
Spec Kit は、AI コーディングツールの重要な方向転換を示しています。「Agent により速くコードを書かせる」ことから、「Agent をより信頼できる形でソフトウェアエンジニアリングに参加させる」ことへの転換です。
これまでの AI コーディングは、プロンプトとモデル能力に注目してきました。Spec Kit は、プロセス、成果物、制約により強く注目します。AI がコードを書く速度が上がるほど、仕様、計画、受け入れ基準を省略してはいけないことを思い出させてくれます。
すでに AI に機能を直接実装させることに慣れているなら、Spec Kit で最初の一手を変えてみる価値があります。
まず AI に要件を仕様として書いてもらい、その後でコードを書いてもらう。
この一手は一見遅く見えますが、実際には後から「コードはできたけれど、欲しかったものではない」となる手戻りを減らします。