github/spec-kit

AIのコーディングエージェントに「こういうのを作って」と一言で頼むと、書かれていない部分をAIがそれらしく埋めてしまい、出来上がってから「そうじゃない」が起きる。Spec Kit は GitHub が公開している、この頼み方そのものを変えるための道具一式。先に仕様書を書き、コードはそこから作るという進め方（スペック駆動開発）を、決まった順番の手順として持ち込む。考え方の文書では、これまで「コードが本物で、それ以外は努力目標」だった関係を逆にし、仕様のほうを正本、コードをその出力として扱うと説明している。

中身は、specify というコマンドラインの道具と、エージェントに登録される一連のコマンドでできている。プロジェクトを初期化すると、Claude Code や GitHub Copilot など使っているエージェントに /speckit.〜 という手順用のコマンドが入る。柱になる手順は、プロジェクト全体の原則を決める憲章、何を・なぜ作るかを書く仕様、技術の選び方と構成を決める計画、それを細かい作業に割るタスク、実装、そして出来たコードを仕様・計画・タスクと突き合わせて残りを洗い出す収束。README は、収束が「済んだ」と言うまで実装と収束を繰り返す進め方を示している。その間に、曖昧な点を先につぶす確認や、書類どうしの食い違いを調べる分析などを、必要に応じて挟める。一段ごとに Markdown の書類が残り、次の段はその書類を読んで進む。仕様を書き始めると機能ごとに番号付きのフォルダができ（Git のブランチを切るかどうかは任意で、拡張を入れたときだけ自動で切られる。フォルダ名とブランチ名も結び付いていない）、計画の段では調査メモやデータの形、外に公開する口がある場合はその取り決めまで、別々の書類として出てくる。

仕様を作るコマンドの立て方は、推測をなくすことではなく、推測したことを書き残させるほうにある。仕様を作るコマンドの定義は「文脈と業界の通例から、筋の通った推測をせよ」と指示したうえで、人に聞き返す「要確認」の印は最大3件までと上限を切っている。4件以上になったら、影響の大きい順に3件だけ残して、あとは推測で埋めよ、という決め方だ。埋めたぶんは「前提」の節に書き出され、印が残っているうちは仕様が仕上がったことにならない。計画の段では、憲章に書いた原則（たとえば「最初は構成を増やしすぎない」「テストを先に書く」）に照らした関門があり、外れるなら理由を書かせる。対応しているエージェントは30種類以上。手順を足す拡張や、既存の手順を社内の書式に合わせて差し替えるプリセットの仕組みもある。

AIに頼んだ結果が、毎回どこか思っていたのと違うとき

一言で頼んで直させる、を繰り返しているなら、ずれの原因は多くの場合「書いていなかったこと」にある。仕様の段で、AIがどこを推測で埋めたかが「前提」として書き出されるので、ずれに気づく手がかりが、作る前に残る。

チームで同じ進め方をそろえたいとき

誰がどのエージェントを使っても、仕様・計画・タスクという同じ形の書類が残る。憲章に原則を書き、プリセットで社内の書式に合わせれば、人によって頼み方がばらばらになる状態を抑えられる。

小さな修正には重い。 一つの機能を作るのに、仕様・計画・タスクと書類が何枚も生まれる。README 自身も、自分たちの開発でもすべての変更にこの手順を通しているわけではない、と書いている。1行直したいだけのときに使う道具ではない。

書類を読むのは結局人。 AIが書いた仕様や計画を読まずに次へ進めると、ずれがそのまま書類に固定されるだけになる。確認の段で聞かれたことに、自分で答えられる人向け。

変化が速い。 1.0 に到達したが、README は「いまやただの番号」とする中心開発者の投稿を引き、価値は安定から変化への適応へ移ったと説明している。手順やコマンド名が変わりうる前提で使いたい。導入には Python 3.11 以上と uv（または pipx）、Git が要る。

ライセンスは MIT。