「消えた」のではなく標準になった、入口としての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が手を動かしていく。
仕様→計画→タスク→実装──6コマンドの「型」
今回のセッションでは、スイーツ店の商品管理API（商品約100件、一覧・検索・基本的なデータ操作）にカート機能を1つだけ追加する工程がデモとして披露された。既存プロジェクトへの機能追加という、現場でよくあるパターンだ。
技術には.NET（ASP.NET Core Minimal API／C#）を採用。鈴木氏によれば、型のあるコンパイル言語はAIの出力のブレが少なく、機械的な正誤信号が効きやすいためだ。constitutionにプロジェクトの原則や制約を渡し、specifyでは「既存のAPIにカート機能を追加してください」と依頼するだけで、ユーザーストーリーや禁止事項まで含むspec.mdが生成される。そこからplan、tasksを経て、任意コマンドであるanalyzeが検出した2件の不整合を修正し、implementではxUnitのテストを自動実行して検証をループしながら、手書きの実装をほぼ行うことなく、動くアプリが完成するまでの一連の流れを実演した。
この手法の価値は、（1）仕様駆動で成果物まで到達できること、（2）AIが実装し、人間は仕様とレビューに集中できること、（3）そして手順（仕様）が残るので誰でも再現可能であることだ。「速い」ことより「仕様から再現できる」ことが価値であり、既存プロジェクトでも改修箇所から段階的にSDD化できるため、保守案件が大半を占めるSIやエンタープライズ開発とも親和性が高いと、鈴木氏は強調した。
Spec Kit自体も進化している。当初は、constitutionに何でも入れる想定だったが、直近では原則だけをコアに残し、詳細は外出しする設計が明確になった。構造としては、常時参照されて挙動に影響を与える原則（Constitution.md、CLAUDE.md、AGENTS.md）、必要時に読み込む専門知識（Skills相当）、必ず通す強制ルール（Hooks）の3層構造を形成している。さらにコアは小さく保ち、機能を追加するextensions（現在100近い）と、要件・挙動を方向付けるpresetsなどで拡張していく（例えばPII禁止を強制するなど）。鈴木氏は「ツール選定ではなく『思想と仕組み』を設計する時代へ」と説明する。
適用範囲と運用の勘どころとして、鈴木氏は新規プロジェクト（greenfield）なら立ち上げ時から仕様駆動で始め、最初に原則を定義してきれいに積み上げていける。一方で既存プロジェクト（brownfield）でも全置換は不要で、改修が入る箇所からSDD化し、既存資産を活かしながら段階的に広げられる。保守や既存プロジェクトが7割ほどを占めるSIの現場では、こちらが現実的な入り方になるだろう。
そしてエンタープライズでの運用の鍵になるのが、長時間作業での文脈維持、すなわちコンテキスト管理だ。鈴木氏はコンテキストエンジニアリングの4要素として「WHAT／HOW／WHY／FEEDBACK」の4要素を挙げる。WHATは技術スタックやフォルダ構成、HOWは正例・反例つきで具体化した規約や命名、WHYは設計の理由、FEEDBACKはtest・build・lintといった検証コマンドと期待出力だ。中でも欠けやすく、欠けると高コストな誤りの元になるのがWHYだという。運用面では、暗黙知を規約化（Capture）し、バージョン管理して各ツール形式へ配布（Distribute）、違反はpre-commitで検知する（Govern）という「ContextOps」のサイクルを回していく。
過程を記録することも重要だ。小規模の開発ならすぐトレースできるが、長時間の自律的な作業では、AIが本当に仕様どおりに動いたのか、どのようなやりとりを経たのかを後から追えることが重要になる。具体的にはLLMの入出力を記録するProxy層と、ツール呼び出しや判断といったエージェントの過程を記録するOTel層を設け、Langfuseのようにセルフホストできる受け皿へ集約すれば、機密を社内に置いたまま保存・検索・監査ができる。過程の記録は監査証跡であり、完了の証となる。テストが受け入れ基準として残るのと同じ考え方だ。
業界各社は実質同じ方向へ、SDDは「ハーネス」設計の中核として残る
そして方向性が収束している現状に目を向けてみよう。AnthropicはCLAUDE.md（constitution相当）とAgent Skills、OpenAIはAGENTS.mdによる文脈・規約の外部化とplan／specモード、GitHubは先述したようにconstitutionからimplementまでをフルに形式化したSpec Kit、AWSはAI逆質問を人間が検証しながら要件化するAI-DLCなどを提供している。
各社とも明確に「SDD」とうたわないものの、構造化された仕様でAIを駆動するという同じ原理に到達している。鈴木氏は「誰もSDDと言わなくなったが、実質的に各社は同じことをやっていると言っていいのではないか」と指摘する。ツールごとに分かれていた規約ファイルをAGENTS.mdに正本化する動きや、AGENTS.mdとMCPの標準化がLinux Foundation傘下の中立団体AAIF（Agentic AI Foundation）に委ねられたことも、この収束を裏付けることができるだろう。
鈴木氏はAndrej Karpathy氏（現Anthropic、元OpenAI 創設メンバー）の考えを引用した。バイブコーディングは誰でも記述だけでアプリを作れるようにする、いわば開発の「最低ラインを上げる」もの。対してエージェンティックエンジニアリングは、失敗もするエージェントを正確性・セキュリティ・保守性を保ったまま統率する専門規律であり、「到達できる上限を上げる」ものだという。SDDやハーネス設計は後者にあたる。失敗を先回りしてCLAUDE.mdにルールとして刻む実践なども、同じく規律で上限を上げる取り組みといえる。
近年の進化を振り返ると、2022年以降は単発プロンプトのプロンプトエンジニアリング、2024年以降はRAGやマルチターンのコンテキストエンジニアリングを経て、2026年以降は自律・並列・本番運用を前提としたハーネスエンジニアリングへと移ってきた。
ハーネスとはAIが走り出す前に「どう走るか」を伝える層のこと。Spec Kitのconstitution／specify／clarifyはその具体的な実装にあたる。lint・型・build・test・CIで逸脱を機械的に検知するガードレールと組み合わせることで、モデルの周りを設計していく。各社とも、SDDの基本的な発想は消えておらず、ハーネス設計の中核として、AIをどう走らせるかが中心にある。
最後に鈴木氏は、持ち帰ってほしいポイントを3つにまとめた。1点目はコードの前に仕様を構造化すること。2点目は異なる仕組みを用いつつも、業界各社は同じ方向へ向かっており、SDDは消えたのではなく収束したこと。そして3点目は追うべきは個別機能ではなく「型」であること。個別技術は陳腐化するが、考え方は陳腐化しない。問われるのは「どのツールを使うか」よりも「どう仕様を構造化するか」だ。
まずは次のステップとして「手元のリポジトリにspec-kitを入れて/speckit.specifyを1回実行してみよう」と提案し、鈴木氏は講演を締めくくった。
ＦＰＴジャパンホールディングスからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
