「消えた」のではなく標準になった、入口としてのGitHub Spec Kit
SNSを眺めていると、新機能や新ツールなどの個別トピックが洪水のように流れてくる。それらは断片的な情報が多く、それぞれの位置付けをつかむのは難しい。そうした中で「SDDについてはもう聞かなくなった」と言われ始めているが、鈴木氏は「SDDは廃れたのでなく、当たり前になって各社に溶け込んだ。普及して標準になった証」と説明する。
GitHubがOSSで公開している仕様駆動開発のツールキット「Spec Kit」は、コードを書く前に仕様を構造化することを支援する。構造化された仕様が唯一の情報源（SSOT：Single Source of Truth）となり、後から変更があっても追随できるトレーサビリティを持つのが利点だ。既存のリポジトリやエージェントに被せる形で導入でき、今回のデモで用いるGitHub Copilotのほか、Claude Code、OpenAI Codex、Gemini、Cursorなど、主要エージェントに対応する。特定のAIに縛られず、思想を共通化できるのが強みとなる。
Spec Kitのワークフローでは、必須と任意の6コマンドを順に実行していく（詳しくは後述）。鈴木氏はこれらのコマンドに入る前に「AI逆質問」を提案する。人間は意図だけを渡し、AIから対象・制約・非機能要件を逆に質問させ、人間は答えてキュレートしていく。その結果として生成されるのが、要件のSSOTとなる「requirements.toml」だ。要件を人間が書くのではなく、AIに逆質問させて作らせるのがポイントといえる。
ただし、このrequirements.tomlは常に必要というわけではない。実際には保守・派生開発でも通常の新規開発（受託）でも、要件定義まで済んでいるケースが大多数だ。これならrequirements.tomlを生成する必要はほぼない。
必要となるのは要件が全く白紙のケースだ。ゼロから事業を立ち上げ、誰もまだ要件を把握していないような、完全な新規事業に限られる。つまり分かれ目は「新規か保守か」ではなく「要件が白紙かどうか」。Constitution.md自体は常に必須だが、シナリオによりrequirements.toml生成の要否が変わる。
Spec Kitのワークフローは6つのコマンドで構成される。前半は（1）constitution（命名規則・規約・思想を集約したファイルを作成）、（2）specify（何を作るか言語化）、任意で（3）clarify（曖昧さを除去）があり、ここまでが仕様を固めるフェーズとなる。ここを丁寧にやるほど後半の実装が安定する。
後半は実装フェーズで、（4）plan（どう作るか設計）、（5）tasks（AIが実行できる粒度に分解して依存関係を整理）、（6）implement（タスクを順に実装）へと進めていく。人間はレビューに集中し、AIが手を動かしていく。
