こんにちは、エンジニアのみっつーです！
今回は、先日公開されたばかりの Spec Kit を取り上げたいと思います。

github.blog

github.com

本投稿が、「スペック駆動開発」について興味を持っていただくきっかけとなればと思います。
Spec Kit そのものは今後次々と更新が行われていくとは思いますが、まずは現在のバージョン（今回試したのは v0.0.13）の内容を見つつ学んでいきましょう！

目次

• 目次
• Spec Kit およびスペック駆動開発とは
• セットアップ方法
• specify
  • 仕様書の生成
  • 仕様定義の更新
• plan
  • プランニングの実行
  • 技術的懸念点のリサーチ
  • プラン内容のレビュー
• tasks
• 実装
• 最後に

Spec Kit およびスペック駆動開発とは

Spec Kit は、GitHub から OSS として公開されている、Spec-Driven Development（スペック駆動開発） を促進するためのプロジェクトテンプレートです。
GitHub Copilot、Claude Code、Gemini CLI に対応したテンプレートが用意されています。

スペック駆動開発というのは、簡単にいうと「要件定義や仕様書・設計書の作成といったドキュメント整備を始めに十分に行い、そこから実装を進めるといった AI Agent の活用手法」 のことです。
まだ世に浸透していないワードのため、このリポジトリ内でも下記ドキュメントに定義の記載があります。

github.com

もちろん、ドキュメント整備も Agent をフル活用して行います。
作成したドキュメントは同ワークスペース内にファイルとして残していくことがこの手法のミソです。
このドキュメントを AI とやり取りする際のコンテキストとして使用するわけですね。

これまではワンショットで AI とやり取りを行ったり、会話履歴をもとにパーソナライズしたり、システムメッセージやインストラクション定義を使ってキャラ付けを行ったりといった方法を中心に AI とやり取りを行ってきましたが、これからはそこにさらに要件定義や仕様書・設計書をドキュメントファイルとして置いて、それを参照させながら（時にドキュメントの刷新も挟みながら）AI とコミュニケーションを取ることで実装やお互いの認識のブレを減らす というアプローチが広まりつつあるということです。

では、実際に README のプロセス例に倣って使い方を見ていきましょう。
本投稿では、GitHub Copilot (VSCode) を使用します。モデルは好みで良いですが、Agent mode で実施してください。

セットアップ方法

README のセットアップ欄には下記コマンドが提示されています。
Python および UV の実行環境があればコマンド実行できることが分かります。

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

が、uvx コマンドを使うのはこのタイミングだけ、つまりUV 実行環境はプロジェクトを初期化するときのみ必要 なため、もし UV 実行環境をセットアップするのが面倒な場合は、最初から出来合いのテンプレートをダウンロードする方法でもスタート可能です。
例えば GitHub Copilot の場合は、リポジトリの Releases の Assets にspec-kit-template-copilot-v0.0.x.zip という名前で添付されています（Claude、Gemini も同様）。specify init を実行する代わりに、これをダウンロードして使用するのでもOKです。

github.com

余談：私は DevContainer 上でコマンド実行を試すため、下記リポジトリを参考にさせていただきました。

github.com

ここまででできあがった or ダウンロードしたファイルを見てみましょう。

.github/prompts/├── plan.prompt.md             # /plan コマンド├── specify.prompt.md          # /specify コマンド└── tasks.prompt.md            # /tasks コマンドmemory/├── constitution.md                    # 原則やルールの定義└── constitution_update_checklist.md   # constitution.md の更新ルールscripts/├── check-task-prerequisites.sh├── common.sh├── create-new-feature.sh├── get-feature-paths.sh├── setup-plan.sh└── update-agent-context.shtemplates/├── agent-file-template.md     # 開発ガイドライン用├── plan-template.md           # 実装計画用├── spec-template.md           # 仕様書用└── tasks-template.md          # タスク一覧用

GitHub Copilot 向けのテンプレートの場合は、.github/prompts に各コマンド用の~.prompt.md ファイルが作られるのが第一の特徴です。
これらのコマンドが他のスクリプトやテンプレートを駆使して、ドキュメントを充実させていきます。
また、「プロジェクトテンプレート」と言いましたが、見ての通りMarkdownファイルとスクリプトファイルしか存在しないため、プロジェクトの開発言語には縛りがありません。あくまで AI ツールの指定があるのみです。

セットアップが終わったら、README のDetailed process 章に沿って、各コマンドを順に実行していきます。

specify

仕様書の生成

プロジェクトがセットアップされたら、まずは/specify を使って仕様を定義していきます。

/specify に続いて、これから開発しようとしているプロジェクトの要件とその理由を具体的な文章でプロンプトとして与えます。
この時、技術スタックの話は含めないようにします。

spec-kit リポジトリの README に書かれているプロンプト例を和訳したものは下記です。

/specify Taskify の開発：チームの生産性向上プラットフォームTaskify は、ユーザーがプロジェクトを作成し、チームメンバーを追加し、タスクを割り当て、コメントを残し、タスクをカンバンスタイルのボード間で移動できるようにするチーム向けの生産性プラットフォームです。この機能の初期フェーズでは「Create Taskify」と呼び、複数のユーザーを扱いますが、ユーザーは事前に定義されたものとします。ユーザーは 2 つのカテゴリに分かれ、1 人のプロダクトマネージャーと 4 人のエンジニアの計 5 人を用意します。サンプルプロジェクトを 3 つ作成し、各タスクのステータスを示す標準的なカンバンの列（「To Do（やること）」「In Progress（進行中）」「In Review（レビュー中）」「Done（完了）」）を用意します。このアプリケーションにはログイン機能はありません。これは基本機能が正しく設定されているかを確認するための最初のテスト段階だからです。タスクカードの UI では、タスクの現在のステータスをカンバンボードの異なる列間で変更できるようにします。また、特定のカードに対して無制限にコメントを残すことができます。タスクカードから有効なユーザーのいずれかを割り当てることができるようにします。Taskify を起動すると、5 人のユーザーの一覧が表示され、そこから選択します。パスワードは不要です。ユーザーをクリックすると、プロジェクト一覧が表示されるメインビューに移動します。プロジェクトをクリックすると、そのプロジェクトのカンバンボードが開きます。列が表示され、カードを異なる列間でドラッグ＆ドロップできます。現在ログインしているユーザーに割り当てられたカードは、他のカードとは異なる色で表示され、自分のカードをすぐに識別できます。自分が投稿したコメントは編集できますが、他人が投稿したコメントは編集できません。また、自分のコメントは削除できますが、他人のコメントは削除できません。

ここでspecify.prompt.md の内容が実行されるわけですが、こちらも和訳したものを見てみましょう。

# 新しい機能の仕様書と機能ブランチを作成する新しい機能の仕様書と機能ブランチを作成してください。これはSpec-Driven Developmentライフサイクルの第1ステップです。引数として与えられた機能説明に基づき、以下を実施してください：1. リポジトリのルートで`scripts/create-new-feature.sh --json "$ARGUMENTS"` を実行し、JSON出力から BRANCH_NAME と SPEC_FILE を取得します。すべてのファイルパスは絶対パスで指定してください。2.`templates/spec-template.md` を読み込み、必要なセクションを把握します。3. SPEC_FILE に仕様書を書き込みます。テンプレート構造を維持しつつ、セクション順や見出しを守り、プレースホルダーは機能説明（引数）から得られる具体的な内容に置き換えてください。4. ブランチ名、仕様書ファイルパス、次フェーズへの準備状況を報告してください。※このスクリプトは新しいブランチの作成・チェックアウトと、仕様書ファイルの初期化を自動で行います。

create-new-feature.sh を実行するところから始まっています。
具体的な処理内容は該当ファイルを見ていただければわかります（/explain をぜひ活用しましょう）が、新規プロジェクト用ディレクトリを連番を振って作成し、spec.md を作成する内容となっています。
そして、その配置パスをスクリプトの出力として渡しつつ、spec.md を仕様書として更新していく内容となっています。

つまり、下記ファイルがプロジェクトに追加されます。

specs/└── 001-create-taskify    └── spec.md

上記より、事前に用意されたプロンプトだけでなく、テンプレートファイルやスクリプトも活用することで Copilot の行動や出力結果のブレが起きにくくされていることがわかります。
これまで Copilot の出力結果に振り回されていた方は、この時点でもこれから起きることへの期待が高まってきましたでしょうか？

仕様定義の更新

続いて機能仕様を明確化していきます。
README では Step2 の内容となりますが、1回のプロンプトで適切に把握されなかった・我々と認識にずれがあった要件を更新する必要があります。

まずはタスクのチェックリスト化を行います。
プロンプト例を和訳したものは下記のとおりです。

各サンプルプロジェクトまたは作成するプロジェクトには、それぞれ5〜15のタスクが含まれている必要があります。各タスクは、完了状態がランダムに分布されるようにしてください。また、すべての完了段階に少なくとも1つのタスクが含まれているようにしてください。

結果が反映されたら、チェック項目に過不足が無いかを確認します。
自身の認識とずれが無ければ、今度はこのチェックリストを確認させます。
プロンプト例の和訳は下記の通りです。

レビューおよび承認チェックリストを読み、機能仕様が各項目の基準を満たしている場合はチェックリストの該当項目にチェックを入れてください。基準を満たしていない場合は空欄のままにしてください。

初回の結果をそのまま使用しないようにする（必ず再チェックを2、3回は通す） のもこの手法のポイントです。
コンテキストのボリュームも膨らんでくるので、2、3度流して見落としを潰していくことが重要になります。
これまでは期待と違う出力結果が多かった場合も、この例のようにチェックリストを作らせて確認させることで見落としを潰すのがかなり楽になる と思うので、ぜひ実際に試して実行結果を見てみてください。

補足：もし未チェック項目が残っていれば、例えば下記のようなプロンプトで確認を促します。

「〇〇（未チェック項目名）」に関する仕様を追加してください。

では、計画の作成に進んでいきます。

plan

プランニングの実行

README では Step3 の内容となりますが、このステップで技術スタックやその他技術要件を定義します。
プロンプト例の和訳は下記の通りです。

/plan これを .NET Aspire を使って生成し、データベースには Postgres を使用します。フロントエンドは Blazor Server を使用し、ドラッグ＆ドロップ可能なタスクボードとリアルタイム更新機能を備える必要があります。また、プロジェクト API、タスク API、通知 API を含む REST API を作成する必要があります。

今度はplan.prompt.md の和訳を見てみましょう。

# 指定された機能の実装計画を立てる指定された機能の実装計画を立ててください。これはSpec-Driven Developmentライフサイクルの第2ステップです。引数として与えられた実装詳細に基づき、以下を実施してください：1. リポジトリのルートで`scripts/setup-plan.sh --json` を実行し、JSONから FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH を取得します。以降のファイルパスはすべて絶対パスで指定してください。2. 機能仕様書を読み取り、以下を分析します：   - 機能要件とユーザーストーリー   - 機能要件・非機能要件   - 成功基準・受け入れ基準   - 技術的制約や依存関係3.`/memory/constitution.md` の憲法を読み、憲法上の要件を理解します。4. 実装計画テンプレートを実行します：   -`/templates/plan-template.md` を読み込みます（IMPL_PLANパスにコピー済み）   - 入力パスに FEATURE_SPEC を設定します   - Execution Flow（メイン関数）のステップ1～10を実行します   - テンプレートは自己完結型で実行可能です   - 指定されたエラーハンドリングやゲートチェックに従います   - テンプレートの指示に従い $SPECS_DIR に成果物を生成します：     * Phase 0：research.md を生成     * Phase 1：data-model.md, contracts/, quickstart.md を生成     * Phase 2：tasks.md を生成   - 引数で与えられた詳細は Technical Context: $ARGUMENTS に反映します   - 各フェーズ完了時に進捗トラッキングを更新します5. 実行が完了したことを検証します：   - 進捗トラッキングが全フェーズ完了を示しているか確認   - 必要な成果物がすべて生成されているか確認   - 実行中にERROR状態がないことを確認6. ブランチ名、ファイルパス、生成された成果物を報告します。すべてのファイル操作はリポジトリルートからの絶対パスで行い、パスの問題を防いでください。

例によってスクリプトでテンプレートファイルをコピーしてきて、複数のコンテキストをもとに内容を膨らませていく流れが書かれています。

このプロンプトを実行することで、specs 配下のディレクトリ構成は下記の通りになります。
（contracts 配下に関してはいずれのプロンプトにもファイル名が明記されていないので、人によって結果が異なる可能性があります。）

specs└── 001-create-taskify     ├── contracts     │     └── openapi.yaml     ├── data-model.md     ├── plan.md     ├── quickstart.md     ├── research.md     └── spec.md

補足：もしこの時点で上記の各 .md ファイルが生成されていない場合は、例えば下記のようなプロンプトで生成を促します。

/plan 「4. Execute the implementation plan template:」に沿ったファイル出力がされていません。確認してください。

ポイントとしては、plan-template.md に書かれている内容に沿って進めていくというところで、plan-template.md の内容を見ると新しく作られる各ファイルの用途がわかります。
簡単に用途を説明すると下記の通りです。

• research.md: 技術コンテキストに対する不明点やそれに対する調査結果・懸念点などの情報が記録されます
• data-model.md: 当プロジェクトのデータモデル情報が記載されます
• quickstart.md: 当プロジェクトの簡易実行手順が記載されます

技術的懸念点のリサーチ

続けて、技術スタックの最新動向を追ったうえでの考慮事項を追記させるためのプロンプトを実行します。

補足：今回は .NET Aspire の例のため、.NET および Aspire の情報を確認する目的で Microsoft Learn の MCP を登録しておくと、よりこのプロンプトの便利さを実感できます。

learn.microsoft.com

プロンプト例の和訳は下記の通りです。

.NET Aspire は急速に進化しているライブラリであるため、実装計画および実装詳細を確認し、さらなる調査が有益となる可能性のある領域を探してください。追加の調査が必要と判断した領域については、Taskify アプリケーションで使用する予定の具体的なバージョンに関する詳細を調査ドキュメントに追記してください。また、Web 上の情報を活用して不明点を明確にするために、並行して調査タスクを立ち上げてください。

間違ったことを調査しているように見受けられたり、周辺情報や最新バージョンに関する考慮が足りないと感じたときは、例えば下記のようなプロンプトを使用することもできます（こちらもREADME記載分の和訳です）。
README 内の注意書きにもありますが、Copilot があれもこれも追加してくるものを全てこちらでレビューするのは大変なので、根拠を提示させるためにも下記のようなプロンプトを追加で流すことを検討すると良いです。

これを一連のステップに分解する必要があると思います。まず、実装中に行う必要があるタスクのうち、確信が持てないものや、さらなる調査が有益と思われるものをリストアップしてください。それらのタスクをリスト化したうえで、それぞれのタスクに対して個別の調査タスクを立ち上げてください。その結果として、すべての具体的なタスクについて並行して調査が進む状態を目指します。私が見た限りでは、あなたは .NET Aspire 全体について調査していたようですが、今回のケースではそれはあまり役に立たないと思います。それはあまりにも的を絞れていない調査です。調査は、特定の明確な疑問を解決するためのものである必要があります。

プラン内容のレビュー

続けて、プラン内容に欠けているものがないかを確認します。
…という手順になっているのですが、ここで参照されるconstitution.md （プロジェクトのルール）は恐らくこの時点でテンプレートから更新されていないと思います。

更新されていない場合は、例えば下記のようなプロンプトで内容を書いてもらいましょう。

#file:constitution.md を、現在の要件定義および仕様内容に合うように、内容を更新してください。

constitution.md が更新されて内容も確認できたら、サンプルの手順に戻ります。
プロンプト例の和訳は下記の通りです。

実装計画と実装詳細ファイルの監査を行ってください。それらを読みながら、そこに記載されている内容から、実施すべきタスクの流れが明確に読み取れるかどうかを確認してください。なぜなら、現時点で記載されている情報が十分かどうか、私には判断がつかないためです。例えば、コア実装の内容を見る際には、各ステップを進める中で、実装詳細のどの部分に関連情報があるのかを参照できるようになっていると、非常に有用です。そのような関連付けがあることで、コア実装やその精緻化の過程をよりスムーズに進めることができるはずです。

constitution.md の内容に沿ったツッコミが入っていることが確認できれば Good です。

補足：実務では、必要に応じてconstitution.md の内容を更新する必要があるかと思います。その際、Spec Kit テンプレートの場合constitution_update_checklist.md を活用したいので、追加したいルールの追記は直接手作業で行うのではなくプロンプトとして実行することを推奨します。

tasks

README にはステップが明記されていませんが、/tasks を実行することで計画内容に応じたタスクリストがtask.md として作成されます。
tasks.prompt.md の和訳を見てみましょう。

# 計画を実行可能なタスクに分解する計画を実行可能なタスクに分解してください。これはSpec-Driven Developmentライフサイクルの第3ステップです。引数として与えられたコンテキストに基づき、以下を実施してください：1. リポジトリのルートで`scripts/check-task-prerequisites.sh --json` を実行し、FEATURE_DIR と AVAILABLE_DOCS リストを取得します。すべてのパスは絶対パスで指定してください。2. 利用可能な設計ドキュメントを読み込み・分析します：   - plan.md（技術スタック・ライブラリ）は必ず読む   - 存在する場合：data-model.md（エンティティ）   - 存在する場合：contracts/（APIエンドポイント）   - 存在する場合：research.md（技術的意思決定）   - 存在する場合：quickstart.md（テストシナリオ）   ※すべてのプロジェクトにすべてのドキュメントがあるわけではありません。   - CLIツールは contracts/ がない場合あり   - シンプルなライブラリは data-model.md が不要な場合あり   - 利用可能なドキュメントに応じてタスクを生成してください3. テンプレートに従ってタスクを生成します：   -`/templates/tasks-template.md` をベースに使用   - サンプルタスクを実際のタスクに置き換えます：     * **セットアップタスク**：プロジェクト初期化、依存関係、Lint     * **テストタスク [P]**：契約ごと、統合シナリオごとに1つ     * **コアタスク**：エンティティ、サービス、CLIコマンド、エンドポイントごとに1つ     * **統合タスク**：DB接続、ミドルウェア、ロギング     * **仕上げタスク [P]**：ユニットテスト、パフォーマンス、ドキュメント4. タスク生成ルール：   - 各契約ファイル → [P]付き契約テストタスク   - data-modelの各エンティティ → [P]付きモデル作成タスク   - 各エンドポイント → 実装タスク（共有ファイルの場合は並列不可）   - 各ユーザーストーリー → [P]付き統合テスト   - 異なるファイル = 並列実行可能 [P]   - 同じファイル = 逐次実行（[P]なし）5. 依存関係順にタスクを並べる：   - セットアップが最初   - テストは実装より前（TDD）   - モデルはサービスより前   - サービスはエンドポイントより前   - コアは統合より前   - すべての仕上げは最後6. 並列実行例を含める：   - 並列実行可能な [P] タスクをグループ化   - 実際のTaskエージェントコマンドを示す7. FEATURE_DIR/tasks.md を作成：   - 実装計画から正しい機能名を記載   - タスクは番号付き（T001, T002, ...）   - 各タスクのファイルパスを明記   - 依存関係メモ   - 並列実行ガイダンスタスク生成のコンテキスト：$ARGUMENTStasks.mdは即座に実行可能であること。各タスクは追加の説明なしでLLMが完了できるほど具体的に記述してください。

このプロンプトを実行することで、/specs/001-create-taskify/tasks.md が生成されます。
できあがったtasks.md の中身を見るとわかりますが、この後実装を進めていく際、このチェックリストに沿って実装が行われます。つまり、AIとはtasks.md 上を通じて進捗状況を共有することが可能になる ということです。

実装

ドキュメントが十分に揃ったところで、実際に実装を行うよう指示します。

#file:plan.md をもとに実装を行ってください。

おおよそタスク単位で実装が進んでいくため、随時ビルド&テスト&コミットを行いながら進めていくと良いでしょう。
また、プロンプト内容や解釈のされ方によりますが、確認のためにタスク単位で一度 Agent 実行が止まるので、実装やテストの指示プロンプトは~.prompt.md 化しておくと便利です。

実装内容に自身の想定とのずれが生じた場合、まずはドキュメント側にずれが生じていないかを確認します。
ドキュメント内に明記されている内容であればその箇所を特に参照したうえで実装するよう指示をする、記載が無ければ追記するような指示をする、といった形で実装を進めることでブレを最小限に抑えていきます。

最後に

スペック駆動開発は、AI エージェントと協働しながら仕様策定ベースで実装を進めるものであり、Spec Kit はそんなスペック駆動開発を簡単に導入・運用できるテンプレート です。
事前に用意されたプロンプト・テンプレート・スクリプトを活用することで、要件定義や設計・計画・タスク分解・実装までの流れが体系化され、AI とのやり取りのブレや認識齟齬を最小限に抑えることができます。

ぜひまずは一度、Spec Kit を使って新しい開発体験を試してみてください。

…というところで、弊社が関わる直近のイベントの宣伝です！

9/20、21 で開催予定の ServerlessDays Tokyo 2025 の Day2（9/21）にて GitHub Copilot を使ったスペック駆動開発のワークショップを実施します！
ぜひご参加いただき知見を深めていただければと思います↓↓↓serverless.connpass.com

もう一つ、9/11 に日本マイクロソフト関西支店にて、GitHub Copilot の実践ワークショップを行います！
こちらは GitHub Copilot の基本的なお話が中心となるので、まだ使い始めの方はもちろん、使い慣れている方は QA の時間にバンバン質問していただくこともできますので、ぜひご参加いただけますと幸いです↓↓↓

msdevjp.connpass.com

以上、本投稿が GitHub Copilot の活用のヒントになれば幸いです！

サービス一覧

www.alterbooth.com

www.alterbooth.com

www.alterbooth.com