多くの人が AI プログラミングの使いにくさを嘆く。Claude Code が書いたコードはいつも何かが少し足りない気がする。問題はたいてい AI ではなく、要件の表現が曖昧すぎる点にある。
GitHub がオープンソース化した Spec-Kit（Spec-Driven Development Toolkit）はまさにこの問題を解決する。その核心理念はシンプルすぎてほとんど退屈に思えるほどだ：先に仕様を書け、それからコードを書け。
だが、この「退屈」な理念こそが、多くの人と AI の協働の仕方を変えつつある。
コードの書き方は教えない、「人 language」の話し方を教える
Spec-Kit は新たな AI プログラミングアシスタントではない。AI とのコミュニケーションの仕方を教えるツールチェーンだ。
ワークフローは4ステップしかない：
- Specify：何をしたいかを定義
- Plan：どうやるかを計画
- Tasks：小さなタスクに分解
- Implement：実行と実装
プロダクトマネージャーの日常業務によく似ている。だが違いは、Spec-Kit がこれらのステップを AI が理解できる形式に構造化している点だ。
4つのシナリオ：どう使うか
新規プロジェクト立ち上げ：以前は AI に「React プロジェクトを組んで」と言うだけで、AI が不要な設定を山盛り投げてくることもあった。今は uvx --from git+https://github.com/github/spec-kit.git specify init my-project を実行。プロジェクトが解決する問題、技術スタックの選択、コア機能モジュールの入力をガイドしてくれる。生成された spec.md が、以降のすべての AI プログラミングの統一基準になる。
複雑な機能開発：「ユーザー権限システム」を作るとしよう。まず仕様ファイルを作成し、権限モデル（RBAC/ABAC）を定義し、制御が必要なリソースと操作を列挙し、境界条件を説明する。仕様ドキュメントを書き終えた時点で、問題はほぼ考え尽くされている。それから AI にコードを書かせれば、たいてい一度で使える。
チーム協働：チーム内で Claude Code を使う人、Cursor を使う人、Copilot を使う人が混在。コードスタイルはバラバラ。Spec-Kit の解決策は spec.md を single source of truth にすること。誰がコードを書いても、まず同じ仕様ファイルを読み、AI ツールの出力はアーキテクチャレベルで自然に一致する。
レガシープロジェクトのリファクタリング：他人の古いコードを引き継いだら、specify analyze コマンドでコード構造を分析し、仕様ドキュメントを生成し、リファクタリングモジュールを特定する。コアビジネスロジックをまず仕様として抽出し、AI にゼロから書き直させれば、歴史的 baggage なしでリファクタリングできる。
4つの実践アドバイス
- 仕様ドキュメントを細かく書きすぎない：「何が欲しいか」を明確にし、「どうやるか」は書くな。細かく書きすぎると逆に AI の发挥を制限する。「ログイン成功後ホームページにリダイレクト」で十分。「API を呼び出して status===200 か判定…」まで書く必要はない。
- AI に仕様を書かせる：まず AI と要件についてチャットし、構造化ドキュメントに整理させる。チャットプロセス自体が一度の要件明確化になる。
- 仕様ドキュメントは生きている：粗い版を書く → AI がコード生成 → 問題を発見して仕様を更新 → イテレーションを続ける。サインして捨てる契約ではない。
- CLAUDE.md と併用する：
spec.mdが「何を」を定義し、CLAUDE.mdが「どうやって」を定義する。両者を組み合わせれば、AI が書くコードはまるで自分が書いたようになる。
いつは必要ないか？
簡単なスクリプト、クイックプロトタイプ、数行のコード修正——直接 AI に言えばいい。Spec-Kit を走らせる必要はない。
Spec-Kit のポジショニングは明確だ：AI は単なる実行者、あなたがアーキテクト。Spec-Kit があなたにアーキテクトという役割をきちんと演じさせ、曖昧なアイデアを実行可能な構造化ドキュメントに変え、AI に実装を任せる。