📐コードではなくスペックを書け · GitHub Spec Kit によるスペック駆動開発

その瞬間 · 「やりたいことを伝える」だけでは足りなくなるとき

最初のうちバイブコーディングは魔法だ。AIに話しかけ、画面が現れ、動作し、拍手する。だが——ほぼ必ず5つ目か6つ目の機能あたりで——魔法が崩れる瞬間が来る。小さな変更を頼むと、触ってもいない別の何かが壊れる。ログインの動くべき仕組みを、「忘れちゃったから」と3回目の説明をする。翌日プロジェクトを開くと、ファイルの半分がなぜ存在するのか自分でもわからない。それがその瞬間だ。会話が信頼できる情報源として足りなくなり、金魚並みの記憶しかないチャットよりも堅牢な何かが必要になるときだ。

スペック駆動開発（Spec-Driven Development、略してSDD）は、まさにそこで生まれる。考え方はほとんど失礼なほど単純だ。AIが一行のコードを書く前に、アプリが何をすべきかを書く——明確に、整理して、ファイルに保存する。そのドキュメント、スペックが、唯一の信頼できる情報源になる。そしてエージェントはそこから、プラン → タスクのリスト → コードを生成する。その順番で。途中にあなたのチェックポイントを挟んで。

痛み · フランケンシュタインはどこから来るのか

問題はAIが愚かなことではない。AIには意図の記憶がないことだ。各メッセージで、そのメッセージにとっての最善の判断をするが、あなたが何を、なぜ作っているのかの全体像を持っていない。あなたはその全体像を頭の中に持っている——だが頭はエージェントが読めるドキュメントではない。だからAIは空白を推測で埋め、毎回違う推測をする。あるときはカートが税を保存し、別のときは保存しない。あるときはユーザーがプロフィールを編集でき、別のときはリファクタリングでその機能が消える。誰も嘘をついていない。ただ単に何が正しいかを定めた契約が一度も存在しなかっただけだ。

これを直さないとどうなるか？世界の終わりではない——ゆっくりした事故だ。ほぼ動くアプリで終わる。他人（や来週のAI）に説明するのが不可能で、修正するたびに別の何かを壊す独自の確率を持つアプリだ。そしてその確率は容赦しない。同じシリーズのあるブログで27%の数学を語った——各ステップで85%成功するエージェントは、8ステップのフローを27%の確率でしか完遂できない（0.85⁸）。成功は加算ではなく乗算されるからだ。手探りで作ることは、脆いステップをまったく同じように連鎖させる。スペックはその脆さの連鎖を断ち切るものだ。AIに、各ステップを検証する固定点を与え、各ステップが前のステップの幸運頼みになるのを防ぐ。

解決策 · 順番をひっくり返す（スペックが先、コードが後）

バイブコーディングではフローはこうだ。話す → コード → （たまに）ドキュメント化する。SDDでは完全にひっくり返る。スペックを書く → プランを立てる → タスクを生成する → コード。ドキュメントは最後に忘れられる残りかすではなく、出発点になる。そしてこれは官僚主義ではない。各フェーズは、エージェントが前のものからほぼ独力で生成するアーティファクトであり、次に進む前にあなたが承認するチェックポイントが挟まる。あなたが指揮し、AIが実行する。

ツール · GitHub Spec Kit

このフローを手作業で発明する必要はない。GitHub Spec Kitはオープンソースのツールキット——GitHub製、無料、MITライセンス——で、SDDをAIエージェント内の一連のコマンドとしてインストールする。あなたは自然言語でスペックを書き、Spec Kitは構造、チェックポイント、そしてAIがそれをアプリに変えるためのコマンドを提供する。最も急成長したAIツールの一つだ。GitHubで122,000スター、最新の安定版v0.13.0は2026年7月17日にリリースされた。30以上のエージェントを統合している——Claude Code、GitHub Copilot、Cursor、Gemini CLI、そしてあなたが使うもの。

インストール · 2つのコマンドで中に入る

Spec Kitはuv、モダンなPythonパッケージマネージャー（速く、ドラマなし）でインストールする。uvがなければ、まずそれをインストールする——一行だ。次にSpec KitのCLIを永続的にインストールし、エージェントを選んでプロジェクトを初期化する。ターミナルにおびえないでほしい。文字通りこれらのコマンドを順に実行するだけで、本当の作業のためにターミナルに戻ることはない（本当の作業はあなたのAIのチャット内で起きる）。

# 1) uv（Pythonパッケージマネージャー）がなければ、まずインストールする:
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2) Spec KitのCLIを永続的にインストールする（安定版を固定して）:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.13.0

# 3) どのエージェントを選べるか見る（--integration フラグに渡す正確な値）:
specify integration list

# 4) エージェントを選んでプロジェクトを初期化する（ここでは例としてCopilot）:
specify init mi-proyecto --integration copilot

# 5) 新しいバージョンがあるか確認する（何も変更せず、読むだけ）:
specify self check

プロトコル · Spec Kitのコマンド、順番通りに

初期化したら、Spec Kitはエージェント内に書き込む一連のスラッシュコマンドを提供する。魔法ではない。それぞれがAIに、フローの次のアーティファクトを生成するよう指示する。順番が重要だ——各ステップが前のステップに支えられるカスケードだからだ。以下がv0.13.0に入っている実際のものだ。

実際のフロー · あなたのチェックポイントを伴う4フェーズ

すべてを合わせると、プロジェクトは最初から最後までこう見える。各境界であなたが確認して承認してからAIが進むことに注目してほしい。それがコツだ。AIがブレーキなしに独りで働くのではなく、あなたが制御するチェックポイントの間で独りで働くのだ。

習慣 · いつスペックを書き、いつ書かないか

SDDはすべてに使うものではない。一行の変更、ボタンの色、テキスト——それはAIに普通に話しかければ終わりだ。それにスペックを書くのは、絵を掛けるのに建築家の設計図を頼むようなものだ。良い習慣はしきい値を認識することだ。タスクが複数のファイルに触れる、ビジネスルールがある、来週また戻ってくる——そのときこそ、スペックが先だ。そしてそれ以降、新しい大きな機能はすべて衝動からではなくスペックから生まれる。

マスタープロンプト · スペックファーストでプロジェクトを始める

暗記すべき唯一のプロンプトがここにある。（Spec Kitを初期化済みで）AIに渡して、最初の一分から正しく始めるためのものだ。まず憲法を定め、次にあなたと一緒に足りないものを質問しながらスペックを組み立て、そしてあなたが承認するまでコードを書かないよう指示する。コピーして [角括弧] を埋め、本気のプロジェクトを始めるときにエージェントに貼り付けよう。

すでに初期化済みのGitHub Spec Kitを使って、このプロジェクトをスペック駆動開発（Spec-Driven Development）で構築します。まだコードは書かないでください。このフローに私と一緒に従い、各チェックポイントで立ち止まって、進む前に私に承認させてください。

私のプロジェクトは: [何を、誰のために作りたいかを3〜5文で記述]。
やってはいけないこと / 私の制約: [例: クレジットカードを保存しない、モバイルで動作する、機密データをログに残さない]。

ステップ1 — 憲法。何よりもまず /speckit.constitution を実行し、このプロジェクトの侵すべからざる原則（セキュリティ、入力検証、一貫性、当てはまるもの）を提案してください。それらを私に見せ、私のOKを待ってください。

ステップ2 — スペック。次に /speckit.specify を実行し、私の記述からスペックを起草してください: 明確な要件とユーザーストーリー。その後 /speckit.clarify を実行し、曖昧さをなくすために必要なすべての質問を私にしてください——推測せず、私に聞いてください。私がスペックは正しいと言うまで進まないでください。

ステップ3 — プランとタスク。スペックが承認されたら /speckit.plan を実行し、スタックとアーキテクチャを提案してください（なぜそれぞれを選んだかを分かりやすく説明して）。次に /speckit.tasks で分解し、/speckit.analyze でスペック、プラン、タスクが矛盾しないか検証してください。すべてを私に見せ、私の承認を待ってください。

ステップ4 — 実装。私が許可したときだけ /speckit.implement を実行して構築してください。終わったら /speckit.checklist を生成し、構築されたものがスペックを満たすか検証してください。

全プロセスを通じての黄金律: スペックが唯一の信頼できる情報源です。コードの何かがスペックから逸れたら、スペックが勝ちます——または一緒に更新するよう私に知らせてください。決して黙って挙動を変えないでください。

最も簡単な道 · 何をチャットで、何をコマンドでやるか

迷わないように。ほとんどすべてはAIに話しかけることで起きる。ターミナルに触れるのは一度だけ（インストールと初期化）。/speckit.* はエージェントのチャット内に、他のメッセージと同じように書く。そしてスペックは自分の言葉で書く——コードではない。役割分担はこうだ。

これはどこから来たのか（このシリーズの進化）

ライブラリを追ってきたなら、これは目新しくないはずだ——次の段階だ。C-A-Rプロトコルは、バグを送り出さないために構築と監査を分けることを教えた。デザインシステムのリソースは、最初の画面の前にビジュアルのルールを定めることを教えた。両方が同じ一つの考えを共有している。実行する前に契約を決めろ。SDDはその考えを最も純粋な形にする。スペックが契約であり、すべてのアプリ——デザイン、ロジック、挙動——にとって唯一の信頼できる情報源だ。「コンテキストを整理せよ」から「契約を書き、AIにそれを守らせよ」へと進む。