GitHub製Spec駆動開発支援ツールSpec Kitをいろいろ試してみる
びーぐるです🐶
2025年9月2日、GitHubからSpec Kitがリリースされました。
このツールはSpec駆動開発(Spec-Driven Development: SDD)を支援するツールですが、これがGitHubからリリースされたことに大きな意味があります。
今回はこのSpec Kitについて調査し、実際にSpecファイルを作成してKiroとの比較を行いたいと思います。
更新履歴
- 2025/09/06 公開しました
- 2025/09/18 Cursorに対応をした件を追記しました
Spec Kitとは？
冒頭で述べた通り、GitHubがリリースしたSpec駆動開発を支援するツールです。
これ自体で動作するわけではなく、他のコーディングエージェントにSDDを組み込むためのアドオンのような位置づけになります。
組み込めるコーディングエージェントは
- GitHub Copilot
- Claude Code
- Gemini CLI
- Cursor (9/18追記)
があります。
Codexは未対応のようです。
Spec駆動開発とは？
仕様書駆動開発とも呼ばれます。
ソフトウェア開発において、AIと開発者は対話により仕様書(Spec)を先に作成し、その後仕様書に基づいたコーディングを指示する開発方式です。
仕様書がソフトウェアの中心であり、コードは仕様書を言語・フレームワークを用いて体現したもの、という位置づけになります。
つまり、AIをドキュメントにより制御することで、確実に仕様に基づいた実装を行う目的があります。
AIドリブンな開発において、ここ最近はとても注目され、採用されている方式です。
Spec Kitの導入と操作方法
流れはKiroのSDDとよく似ています。
一度Kiroを触れたことがある方であれば簡単に理解できるでしょう。
1. 導入
uvxを利用してインストールするため、Pythonの環境及びuvの準備が必要です。
uvはデファクトスタンダードとなりつつあるPythonのパッケージマネージャーです。
環境が整ったら、以下のコマンドでSpec Kitを実行します
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
<PROJECT_NAME>の部分は任意のプロジェクト名に置き換えます。しかし実行ディレクトリ直下に<PROJECT_NAME>が作成されてしまうので、カレントディレクトリで実行したい場合は
uvx --from git+https://github.com/github/spec-kit.git specify init --here
とします。この場合はカレントディレクトリ名が<PROJECT_NAME>となります。
上記コマンドを実行すると、コーディングエージェントを選択するように促されますので、利用したいエージェントを選択します。
選択すると、何やら色々ファイルが生成されますが、これはSDDを実行するためのテンプレートやスクリプトです。
2. 仕様の作成
ここからは選択したコーディングエージェントによって多少違いますが、基本的には先程作成したディレクトリに移動してコーディングエージェントを起動します。
その後
/specify [要件]
と入力します。
ここでいう要件とは、いまから作りたいモノの、基本的な要求や機能要件のことを指します。
Spec Kitの説明では Focus on the what and why, not the tech stack. とありますので、何をどのように作りたいか明確に指示しましょう。
要件は複数行になっても構いません。事前に他のエディタで記入したものをペーストするのがよいでしょう。
私はマークダウン記法で記述しましたが、サンプルは自然言語で記述していたため、どのような形式でもよさそうです。
入力して暫く待つと、ファイルが増えています。
001-[英数文字列]のようなディレクトリの中にあるspec.mdが仕様書ファイルとなります。
これはKiroのrequirements.mdに相当するものです。
なお、この英数文字列のことをブランチ名と呼ぶようです。
内容を確認し、要件を満たしていない部分がある場合は、修正を指示することもできます。
問題なければ次へ…と行きたいところですが、現実問題、このドキュメントが妥当かを評価するのはかなり難しいです。
そのために、次の特徴的な機能があります。
3. 仕様のセルフチェック
spec.mdをご覧になればわかるのですが、Review & Acceptance Checklistというチェックリストが存在しており、コーディングエージェントに要件を満たしているかのセルフチェックをさせることができます。
以下のようなプロンプトを利用することで、セルフチェックを開始できます。
レビューおよび承認チェックリストを確認し、機能仕様が各基準を満たしている場合はチェックリストの各項目にチェックを入れてください。
基準を満たしていない場合は空欄にしておいてください。
すると、実際に満たしている項目のチェックリストにチェックが入ります。
満たしていない点はチェックされず、確認すべき点、修正すべき点等がコーディングエージェント側から(恐らく)伝えられると思います。
もしくは、「未確定事項を詰めますがよろしいですか？」という旨の確認が入るかもしれません。
いずれにせよ、ここからはコーディングエージェントとの「対話」により残りの項目を満たすように修正していきます。
ここがKiroの要件定義との大きな違いで、手軽さは失われるものの、より仕様書としての完成度を高めることができるようになっています。
余談: spec.mdファイルは誰に向けたもの？
このspec.mdを見ていくと、面白いことが書かれています。
## ⚡ Quick Guidelines
- ✅ Focus on WHAT users need and WHY
- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)
- 👥 Written for business stakeholders, not developers
Spec Kitの中では、spec.mdは開発者向けではなく、ステークホルダーに向けて書かれるものとしています。
確かに、spec.mdからドキュメントとしての体裁を整えれば、決裁者への説明資料としても使えそうな気がします。
4. 実装計画の作成
spec.mdの作成が終わったら、次は
/plan [要件]
と入力します。
ここでいう要件とは、技術・アーキテクチャ要件や非機能要件のことを指します。
先程同様、複数行になっても構いません。
初学者にとってみればここを的確に入力するのは難しいかもしれませんが、わからない部分は飛ばしてある程度の記述であっても、LLMがいい感じには仕上げてくれるはずです。
入力して暫く待つと、ファイルが増えています。これらのファイルはKiroのdesign.mdに相当するものです。
プロジェクトによっては存在しないファイルもありますが、概ね
-
plan.md設計の概要と、タスク分割へのブリッジとなる中心的なドキュメント -
research.md技術要件や実装方針に関するドキュメント -
data-model.mdSQLのテーブル定義など、データモデルに関するドキュメント（クラスも含む？） -
quickstart.md開発環境のセットアップ方法や、プロジェクトのビルド・実行方法に関するドキュメント -
contractsディレクトリ フロントエンドとバックエンドのAPI仕様に関するドキュメント
となっています。
ここでも内容を確認し、要件を満たしていない部分がある場合は、修正を指示することもできます。
5. 実装計画のセルフチェック
実装計画もセルフチェックをさせることができます。
例えば以下のようなプロンプトが利用できます。
実装計画と詳細な実装手順書の監査を行ってください。
ここに記載されていない重要な作業があるかもしれないので、見落としがないか確認してください。
実施すべきタスクの順序が明確に示されているかどうかをチェックしてください。
ここは実際のプロジェクトに応じて、自信のない部分を重点的に確認させましょう。
「論理的に破綻していないか」や「不確実性の高いタスクはあるか」、「不明瞭な仕様はあるか」などを使って、コーディングエージェントと対話してドキュメントを固めます。
6. タスクリストの作成と実装開始
ここまで問題なければ
/tasks
と入力します。
今度は後ろに何か入力する必要はありません。
タスクリストであるtasks.mdが生成されます。
念の為、tasks.mdの正当性をチェックし、問題なければplan.mdのチェックボックスを埋めてくださいのようなセルフチェックを入れてもよいでしょう。
ここでコーディングエージェントから実装の開始を薦められる場合もあります。
任意のタイミングで実装を開始する場合はtasks.mdを参照し、タスクの最初から順に実装を開始してくださいのように指示します。
Spec Kitを使った実際の開発(Spec作成まで)
ここでは実際にSpec Kitを使って、実際にSpecを作成しました。
今回は振替伝票に関するWebアプリケーションを想定しました。
Gemini CLIを利用したパターン、GitHub Copilot + GPT-5を利用したパターンの2通り作成しましたが、そこまでの大きな違いはありませんでした。
具体的なプロンプトは以下の通りです(各工程終了の前にセルフチェックを実行をしました)。
/specify
/specify
振替伝票を作成できるWebアプリケーションを作成してください
1. アプリケーション名
Denpyo
2. アプリケーションの目的
- 紙の振替伝票に手書きする行為をアプリケーションで置き換える
- 振替伝票の作成履歴を記録する
3. アプリケーションの機能要件
- 振替伝票を作成できる
- 振替伝票をPDF化して保存、もしくは印刷することができる
- 入力した情報をデータベースに記録できる
- 利用者は1名であり、アカウントは不要。ただし他者に閲覧されるのを防ぐため、利用時にパスワードを設定できる。
4. 振替伝票の利用ケース
経費を支払ったとき、既定の領収書が入手できなかった場合に代わりに作成する(例えば業務中の移動に関する電車代を自身の財布から建て替えた場合)
5. 振替伝票の項目
- 日付
- 借方／貸方科目
- 借方／貸方金額
- 摘要
- 借方／貸方合計金額
- ナンバー(任意)
6. 振替伝票の要件
- 貸方、借方の合計金額は一致している必要がある
- 借方／貸方科目は一般的な勘定科目をプルダウンで選べるようにするが、「その他」を作成し自由入力も可能とする
/plan
/plan
アプリケーションの技術要件
- Webアプリケーション
- バックエンドにはDeno + Honoを利用する
- フロントエンドはReactを利用する
- できるだけTypeScriptを利用する
- JavaScript / TypeScriptに関しては、できるだけクラスを利用しない
- データベースはsqliteを利用する
- t-wada氏が提唱するテスト駆動開発を利用する
完成したSpecとKiroとのSpecとの比較
- Gemini CLI + Gemini 2.5 Pro + Spec Kit
- GitHub Copilot + GPT-5 + Spec Kit
- Kiro + Claude Sonnet 4
Kiroは3ファイルでシンプルにまとまっていますが、Spec Kitはかなり詳細にわたって仕様が記述されています。
複雑になりすぎている感もありますが、Specとしての完成度は高いです。
LLMによるSpecの評価
さすがに人力で評価するのは骨の折れる作業ですので、今回はいくつかのLLMに代わりに評価をしてもらいます。
ちょっとしたLLM-as-a-Judgeですね。
Jules
GitHubリポジトリごと与えて評価してもらいます。
このディレクトリのはSpec駆動開発で使われるSpecが含まれています。
これらは別のモデルに同じ要件を与えたものです。
これらのSpecsを比較・評価を行い、最も良いものとその根拠を示してください。
なお.kiroディレクトリは他の2つに比べてフォーマットやファイル数も異なりますが
他と同様に比較してください。
GPT-5が高評価です
Moonshot Kimi K2
GPT-5、企業レベルのアプリケーション開発に最も適した仕様であり、セキュリティ、パフォーマンス、保守性のすべてにおいて優れた基準を設定しています。
他の2つの仕様も良い点を持っていますが、GPT-5の仕様は包括性と堅牢性において明確に優れています。
xAI Grok 4
GPT-5が優れている
全体的なバランス: 完全性と詳細度で最高点を獲得し、Spec駆動開発の核心（要件から実装へのスムーズな移行）を最もよく実現。
GeminiやKiro生成のSpecsは良いが, バランスではGPT-5に及ばない
Claude Opus 4.1
GPT-5を最良のSpecとして推奨します。
詳細度と実用性のバランスが最も優れていて、小規模プロジェクトながら、将来の拡張性も考慮されています
評価の全文は省きますが、いずれもGPT-5を高評価としました。
LLMから見て、バランスがよいようです。
流石に本家ですので、GitHub Copilotとの相性がよいのは間違いないと思います。
雑感とまとめ
Spec Kitは、非常に重厚で詳細なSpecを作成できるツールです。
GitHubがリリースしたツールだけあって、エンタープライズレベルでの導入を想定した作りになっており、仕様書としての完成度は非常に高いものが生成されます。
当然、IDEで容易に扱えるKiroに比べ、手軽さには劣ります。
セルフチェック機能により仕様の品質は向上しますが、そもそもできあがるSpecが小規模な開発には少し大げさに感じられることもあります。
個人開発や小規模チームでの迅速な開発を求める場面では、Spec Kitのプロセスが重く感じられるかもしれません。
その一方で、中規模以上のプロジェクトでの採用を見込めるのも確かです。
複数の開発者が関わるプロジェクトや、長期的な保守が必要なシステムでは、Spec Kitが生成する詳細な仕様書は大きな価値を持ちます。
ステークホルダーとの認識合わせ、設計の論理的な検証・実装方針の明確化にSpecが役立つことも考えられます。
AIドリブンな開発が当たり前になる時代において、コーディングエージェントの制御は避けて通れない重要な課題です。
SDDはその有力な解決策の一つであり、Spec Kitはその実現に向けた強力なツールと言えるでしょう。
前述の通り、重厚なSpecが不要な場合はKiroや他のツールも依然選択肢となりますので、双方を置き換えるものではありません。
Spec Kit自体は無料です。ということは、Gemini CLIと組み合わせるとすべて無料で利用できてしまいます。
AIの評価でGitHub Copilot(GPT-5)に劣ってはいましたが、十分に性能の高いSpecが生成できるので、まずはこちらで試してみるのがよいでしょう。
SDDに関する他のツール
Gota氏のclaude-code-specはClaude Codeの他、Geminiにも対応しています
こちらのほうがSpec Kitよりも先輩です
MCPサーバーでSDDを実現する方法もあります
Clineも別の形でSDDを実現しています
宿題
- Claude Codeで試す
現在Claudeは無課金なので、試せませんでした。 - GitHub Copilot + 複数モデルで比較する
本記事では長くなるため、次回以降があれば試してみます。 - 実際に実装してみる
これも次回以降があれば試してみます。
Discussion