仕様駆動開発 のためのオープンソースのツールキット GitHub Spec Kit についての GitHub の発表である。記事は、コーディングエージェントが強力になるにつれて現れてきたと著者が言うパターンから始まる。目標を説明するとコードが返ってきて、それは一見正しそうに見えるが、どこかうまく動かないことが多い。記事はこのアプローチを「バイブコーディング」と呼び、手早いプロトタイプには向いているが、ミッションクリティカルなアプリケーションや既存のコードベースにはあまり信頼できないとしている。
記事の診断は、問題はエージェントのコーディング能力ではなくアプローチにある、というものだ。開発者はコーディングエージェントを検索エンジンのように扱っているが、むしろ言葉どおりに受け取るペアプログラマー、つまりパターン認識には優れているものの曖昧さのない指示を必要とする相手として扱うべきだという。提案される答えは、仕様を、プロジェクトとともに進化し共有された信頼できる情報源として機能する、生きた実行可能な成果物として捉え直すことである。
要点
- 記事は仕様駆動開発を、先にコードを書いて後からドキュメント化するのではなく仕様から始めることと定義している。仕様とはコードがどう振る舞うべきかについての契約であり、ツールやエージェントがコードを生成し、テストし、検証するために使う信頼できる情報源となる。
- Spec Kit のプロセスはチェックポイントを伴う 4 つのフェーズで進み、著者は現在のタスクが完全に検証されるまで次のフェーズには進まないと述べている。Specify：何をなぜ作るのかを高いレベルで記述し、そこからエージェントが、技術スタックではなくユーザージャーニーと成果についての詳細な仕様を生成する。Plan：スタック、アーキテクチャ、制約を与えるとエージェントが技術計画を作成する。比較のために複数のバリエーションを求めることもできる。Tasks：エージェントが仕様と計画を、それぞれ単独で実装・テストできる小さなレビュー可能な単位に分割する。Implement：エージェントがタスクを順にこなし、開発者は何千行ものコードの山ではなく、焦点の絞られた変更をレビューする。
- 著者は、開発者の役割は舵取りだけでなく検証でもあると強調している。プロセスには、生成されたものを批判的に検討し、抜けを見つけ、軌道修正するための明示的なチェックポイントが組み込まれている。AI が成果物を生成し、開発者がそれが正しいことを確かめるのである。
- Spec Kit は GitHub Copilot、Claude Code、Gemini CLI などのコーディングエージェントで動作し、
specifyコマンドラインツールをインストールしてセットアップしたうえで、/specify、/plan、/tasksコマンドで操作する。 - このアプローチがうまくいく理由として挙げられているのは、言語モデルはパターンの補完には並外れて優れているが、心を読むことはできないという点である。曖昧なプロンプトは、明示されていない潜在的に何千もの要件をモデルに推測させることになり、その推測の一部は、実装がかなり進むまで発覚しない形で誤ったものになる。
- 大規模な組織については、仕様と計画が、セキュリティポリシー、コンプライアンス規則、デザインシステムの制約、統合要件に、誰かの頭の中や誰も読まない wiki、散らばった Slack の会話の中ではなく、AI が実際に使える居場所を与えると論じている。
- このアプローチが特にうまく機能する 3 つのシナリオが挙げられている。グリーンフィールド（ゼロからイチ）のプロジェクト、既存システムにおける機能開発（N から N+1）―― 記事はこれを最も強力なケースと呼んでいる。仕様によって、その機能が既存のものとどう相互作用するかを明確にせざるを得なくなるからだ ――、そしてレガシーモダナイゼーションである。レガシーモダナイゼーションでは当初の意図が失われていることが多いが、再構築の前にそれを現代的な仕様として取り戻せるという。
- 記事は中核的な利点を、安定した「何を」と柔軟な「どのように」を分離し、高くつく書き直しなしに反復的な開発を可能にすることだとしている。そしてより大きな転換を、「コードが信頼できる情報源である」から「意図が信頼できる情報源である」への移行として位置付け、それはドキュメントがより重要になったからではなく、AI が仕様を実行可能にしたからだとしている。
- GitHub は、このアプローチがどのツールや企業よりも大きなものであるためにツールキットをオープンソース化したと述べ、真のイノベーションはツールではなくプロセスにあるとし、Spec Kit をその転換を現実のものにするための実験だと説明している。
背景
これは GitHub 自身のブログにおける GitHub 自身のツールキットの当事者による発表であり、このアプローチについての主張は、評価、ベンチマーク、ユーザー調査ではなく、言語モデルの振る舞いについて著者が述べた推論に基づいている。記事自体が Spec Kit を実験と表現し、読者に何を改善すべきかを尋ねて締めくくっており、これは公開時点でこのアプローチがどの程度固まっていたかを的確に表している。
記事の「バイブコーディング」という枠組みは、記事が提唱する実践に対する対比の用語であり（バイブコーディング を参照）、その 4 フェーズで人間がゲートを担う構造は、仕様駆動開発 が包含する複数の具体的な実装のうちの 1 つである。既存システムでの機能開発には高度なコンテキストエンジニアリングの実践が必要になるかもしれないという記事の指摘は、コンテキストエンジニアリング を指している。