Spec-Driven Development は消えたのか？ - AI 駆動開発が収束する方向性 -公開版

Spec-Driven Development は消えたのか？ - AI 駆動開発が収束する方向性 鈴木 章太郎 Executive Evangelist, FPT Data & AI Integration FPT Japan Holdings

鈴木 章太郎 X (Twitter) ： @shosuz https：//www.docswell.com/user/shosuz FPT ジャパン FPT データ& AI インテグレーション エグゼクティブエバンジェリスト 独立行政法人 国立印刷局 デジタル統括アドバイザー兼最高情報セキュリティアドバイザー Microsoft MVP for Developer Technologies (.NET/Developer Tools, 2026~) 略歴： AI 駆動開発勉強会主催。Microsoft エバンジェリスト時代から、Dell、 Accenture、Elastic、VMware を経て現職まで一貫して開発者向け に最新技術を啓発。GPU クラウド技術訴求、AI 駆動開発推進。 政府の仕事は、内閣官房 政府 CIO 補佐官、 デジタル庁 PM を経て、 現職を兼務。 2 / 12

• https://www.docswell.com/user/shosuz

アジェンダ 「消えたのか」を問い、Spec Kit から業界の収束を読み解く 1 「SDD は消えた」のか - 問いの背景 2 GitHub Spec Kit とは - 6 コマンドのワークフロー 3 デモ - Spec Kit で作る 4 重要概念 - constitution / extensions / presets 5 各社は実質同じに - 業界の方向性の収束 6 まとめ - 名前ではなく「型」を学ぶ

1 「SDD は消えた」のか - 問いの背景

「SDD は消えた」のか 言葉は消えた - だが、なくなったわけではない ● 「Spec-Driven Development、もう聞かなくなったね？」と言われ始めている ● X は個別トピック (新機能・新ツール) の洪水 - 次々追って焦らされる ● だが SDD は廃れたのではなく、当たり前になって各社に溶け込んだ ● 本セッション: GitHub Spec Kit を入口に「実質は同じ」を確かめる 言葉が聞かれなくなった - 普及して標準になった証

2 GitHub Spec Kit とは - 6 コマンドのワークフロー

GitHub Spec Kit とは GitHub が公開する仕様駆動開発のツールキット Spec Kit 「コードを書く前に仕様を構造化する」を支援する OSS 既存のリポジトリ・エージェントに被せられる / 主要エージェントに対応 (思想は共通) GitHub Copilot Claude Code OpenAI Codex その他 CLI デモで使用 Anthropic Agent HQ / AGENTS.md Gemini / Cursor 等 特定の AI に縛られず、思想を共通化できるのが強み

Spec Kit 6 コマンドの前に - AI 逆質問で要件を固める 一言の意図から AI に逆質問させ、AI に要件を作らせる - その上で 6 コマンドが回る ① Constitution.md ② AI が逆質問 ③ requirements.toml プロジェクトの原則・憲法 人間は一言の意図だけ AI が生成する要件 ・命名規則・規約・思想 ・全体の最上位の前提 ・AI が対象・制約・非機能 を逆に質問してくる ・人間は答えてキュレート ・AI が作る要件の SSOT ・人間が書くのではない ・これが spec の源泉 requirements.toml は Spec Kit の 6 コマンドには非搭載 - 要件をどう用意するかを補う私案の上流層 ここまでが「AI 逆質問で要件を固める」上流 - ここから下流へ requirements.toml を源泉に、Spec Kit の 6 コマンドが回る (constitution → specify → clarify → plan → tasks → implement) requirements.toml は人間が書くのでなく、AI 逆質問で作らせる - それが spec の源泉になる

Spec Kit ワークフロー前半 - 仕様を固める まず「原則」と「何を作るか」を構造化する ① constitution ② specify ③ clarify 最初に作る「憲法」 何を作るかを言語化 曖昧さを対話で潰す ・命名規則・規約・思想を 1 ファイルに集約 ・ユーザ視点で要件を記述 (What) ・AI が抜け漏れを逆質問 ・答えて仕様の精度を上げる ・全コマンドが参照する土台 ・受け入れ基準まで構造化 ・/speckit.clarify ・/speckit.constitution ・/speckit.specify ・ 中身（規約・命名・理由） は人間が渡す ここを丁寧にやるほど、後半の実装が安定する

Spec Kit ワークフロー後半 - 計画して実装する 仕様から実装可能な単位へ落とす ④ plan ⑤ tasks ⑥ implement どう作るかを設計 実装単位に分解 タスクを順に実装 ・技術スタック / 構成 / データモデルを決定 ・AI が実行できる粒度へ ・AI が 1 つずつ実装 ・依存関係を整理 ・人間はレビューに集中 ・/speckit.tasks ・/speckit.implement ・What を How へ翻訳 ・/speckit.plan 人間はレビューに集中し、AI が手を動かす

Constitution.md → requirements.toml はどこで効くか 問題提起 - 分かれ目は「新規 / 保守」ではなく、要件が「白紙」かどうか ここまで requirements.toml は「AI 逆質問で生成する」前提で説明してきた - でも、それは常に要る？ 要件定義まで済んでいる ＝ 大多数 要件が白紙 ＝ 完全な新規事業（例外）★ ・保守・派生開発 ・通常の新規開発（受託） ← 新規でもここ ・ゼロから事業を立ち上げる ・誰もまだ要件を持っていない → 要件はもうある。生成はほぼ不要 （使っても抜け漏れ検証＝clarify 程度） → ★ ここで初めて AI 逆質問で requirements.toml を生成する価値 問題提起：分かれ目は「新規 / 保守」ではなく「要件が白紙か」 Constitution.md → requirements.toml 生成が本当に要るのは、要件が白紙の "完全新規事業" だけ では？ Constitution.md 自体は常に必須 - シナリオで要否が変わるのは requirements.toml 「生成」だけ

3 デモ - Spec Kit で作る

デモの流れ - 仕様から実装まで デモ (約 15 分) は 3 段で構成 ① 仕様化 ② 計画・分解 ③ 実装・実行 constitution → specify plan → tasks implement ・原則と要件を先に固める ・技術設計を生成 ・AI がタスクを実装 ・clarify で曖昧さを除く ・実装単位へ分解 ・動作確認しながら進む ・コードはまだ書かない ・依存関係を整理 ・アプリが形になる 対話しながら進む様子をデモで見せる

デモ: 既存 API に Spec Kit でカート機能を追加 人間が書いたスイーツ店の商品管理 API に、Spec-Driven Development で 1 機能だけ足す 既存 (before) Spec Kit 追加後 (after) スイーツ店 商品管理 API + カート機能 商品 約100件 / 一覧・検索・CRUD 入れる・一覧・数量変更・合計 やり方: 仕様 → 計画 → タスク → 実装 を Spec Kit のコマンドで順に作る /constitution /specify /clarify /plan /tasks /implement スコープ: カートは「入れる・一覧・数量・合計」まで - 決済 (Stripe 連携) は範囲外 技術：Java / .NET（型のある言語＝機械的な正誤信号＝「門」が効く） デモは .NET - ASP.NET Core Minimal API / C# / インメモリ（DB なし）

デモ動画は後日公開予定 VS Code 上で、Spec Kit と .NET／C#、GPT-5.6 Terra を使用し、 ECサイトの機能拡張を進めるデモです。 デモ動画は後日 VEED.IO で公開し、こちらの Docswell の説明欄に 動画リンクを追加します。

デモの結果 ワークフローだけで動くアプリが完成 1 2 3 仕様駆動で成果物まで到達 手書きの実装をほぼせず、仕様から動くものができる AI が実装、人間はレビュー 人間はコードを書くのでなく、仕様とレビューに集中する 再現可能 手順 (仕様) が残るので、誰でも同じ成果を再現できる 「速い」より「仕様から再現できる」ことが価値

4 重要概念 - constitution / extensions / presets

統制と拡張の全体像 小さなコアを 3 つの仕組みで支える constitution 3 層構造 拡張で伸ばす プロジェクトの憲法 常時 / 専門 / 強制 extensions / presets ・常時：毎回効く原則 (CLAUDE.md / AGENTS.md / Constitution.md) ・コアは小さく保つ ・原則だけをコアに残す （詳細は外出し） ・全コマンドの共通土台 (SSOT) ・専門：必要時の知識 (Skills 相当) ・強制：必ず通すルール （Hooks) ツール選定ではなく「思想と仕組み」を設計する時代へ ・extensions で機能追加 (現在 100 近い) ・presets で要件を方向づけ

extensions の上に重ねる - hooks と presets 機能を「追加」する extensions、「方向づける」presets hooks presets 重ね方 (layering) プロセスに差し込む 挙動を方向づける 優先度つきで合成 ・各ステップに処理を フックできる ・機能追加でなく「影響」 ・append / prepend / wrap / total replace ・組織 / チーム単位で配布 ・例: Git 連携は hook として実装 ・現在 約 20 種 (A11Y 等) ・例: PII 禁止を全 PJ 強制 constitution を「各自任せ」から「組織で強制」へ

適用範囲と運用の勘所 新規・既存どちらにも効く / 文脈管理が鍵 (エンプラ向け) greenfield brownfield context 管理 新規プロジェクト 既存プロジェクト 長時間作業の文脈維持 ・立ち上げ時から仕様駆動 ・全置換は不要 改修箇所から SDD 化 ・context window を意識 ・最初に原則を定義 ・compaction で文脈を保つ ・既存資産を活かす ・きれいに積み上げ ・仕様が文脈を補完 ・段階的に広げる 既存システムでも「改修箇所から」始められる

文脈を設計する - Context Engineering の 4 要素 「文脈管理が鍵」を具体に - WHAT / HOW / WHY / FEEDBACK の 4 層で設計する WHAT HOW WHY ★ FEEDBACK スタック・構造 規約・命名 設計の理由 検証コマンド 技術・フォルダ構成 正例 / 反例つきで 具体化 欠けやすく高コストな 誤りの元 test / build / lint と期待出力 運用は ContextOps - Capture（暗黙知を規約化）→ Version → Distribute（各ツール形式へ）→ Govern（違反を pre-commit で検知）

過程を残す - Observability と監査証跡 LLM 入出力＋エージェントの過程を、自己ホストの受け皿へ集約する ① Proxy 層 ② エージェント OTel 層 ③ 受け皿（集約・監査） LLM の入出力を記録 過程を記録 集めて保存・検索・監査 （行って帰った内容） ツール呼び出し・判断 Langfuse 等セルフホスト可 ＝社内に置ける 過程の記録＝監査証跡＝完了の証 - テストが受け入れ基準として残るのと同じ考え方

5 各社は実質同じ方向性 - 業界の方向性の収束

異なる仕組みを用いつつも実質的に業界は SDD に収束 構造化された意図を「一級市民」にする同じ原理へ Anthropic / Claude OpenAI / Codex GitHub AWS CLAUDE.md / Agent Skills AGENTS.md / plan・ spec Spec Kit AI-DLC ・CLAUDE.md = 毎回効く原則 (constitution 相当) ・Agent Skills = SKILL.md ・agentskills.io で標準化 ・AGENTS.md = 文脈・規約の外部化 ・plan / spec モード ・Goal / Context / Constraints / Done ・constitution → spec → plan → tasks → implement ・最もフルに形式化 ・標準化潮流の中核 ・Mob Elaboration で intent を要件化 ・AI 逆質問 → 人間が検証 ・各フェーズで clarify を繰り 返す 各社「SDD」とは呼ばないものの、実質的に構造化仕様で AI を駆動している

天井を上げるのは Agentic Engineering - モデルより規律 失敗もするエージェントを、品質を保ったまま統率する ※ Andrej Karpathy（現 Anthropic、元 OpenAI 創設メンバー / 元 Tesla AI 責任者） Vibe Coding ＝ 最低ラインを上げる Agentic Engineering ＝ 到達できる上限を上げる ・誰でも「記述」でアプリを作れる ・失敗しやすいエージェントを統率 ・開発の入り口を下げる ・正確性 / セキュリティ / taste / 保守性を保つ「専門規律」 この資料の SDD / ハーネス設計 ＝ Agentic Engineering（到達できる上限を上げる側）

失敗からルールを育てる CLAUDE.md LLM がどこで間違うかから導いた 4 つの行動ルール ① Think Before Coding ② Simplicity First ③ Surgical Changes ④ Goal-Driven Execution 誤った前提を置かない 混乱を隠さない 問題を解く 最小コードだけ 触る所だけ 無関係に波及しない 検証可能な基準にし、 検証までループ Karpathy(2026/1/26): 「モデルは勝手に誤った前提を置き、確認せず走り、押し戻さない」 各ルールは失敗の裏返し - 失敗を先回りで CLAUDE.md に刻む 「追加の指示ゼロでエージェントが働けるように、CLAUDE.md や REVIEW.md、Skills、ドキュメントを書くべきだ」 - Boris Cherny https://x.com/bcherny/status/2077460395279692197

• https://x.com/bcherny/status/2077460395279692197

マルチツールの規約を 1 つに - AGENTS.md を正本に Codex・Claude・Gemini が別ファイルを読む断片化を、AGENTS.md へ寄せて解く 問題：断片化 解：AGENTS.md を正本に 各ツールが別ファイルを読む ・AGENTS.md を Canonical （正本）に ・Codex → AGENTS.md ・Claude → CLAUDE.md ・Gemini → GEMINI.md ・ツール固有ファイルは symlink で補う ・60k+ OSS・30+ ツールで採用 Spec Kit の Constitution.md とは両立 – 常時規約は AGENTS.md、spec 生成は Constitution.md

SDD は「ハーネス」設計の中核 「infra 化できるドメイン知識は、もう lint や型やテストで表現できる範囲に留まら ない。コメント・Skills・CLAUDE.md・メモリとして、ほぼ全ての暗黙知を刻める」 - Boris Cherny https://x.com/bcherny/status/2077460395279692197 各社が収束した先は、モデルではなく "ハーネス" を設計する時代 Prompt Engineering 2022〜 単発プロンプト ➜ Context Engineering 2024〜 RAG・マルチターン ➜ Harness Engineering 2026〜 ★ 自律・並列・本番 • ハーネス ＝ AI が走り出す前に「どう走るか」を伝える層 • Spec Kit の constitution / specify / clarify はその具体実装 ハーネス（進路を示す・主観） ガードレール（道を外れない・客観） ・Constitution / Skills / プラン設計 ・lint / 型 / build / test / CI ・「どう走るか」を事前に設計する - Hooks で自動発火・違反をブロック（PreToolUse / PostToolUse） - 逸脱を機械的に検知・阻止する したがって、ここでも SDD が消えたわけではない ハーネス設計の中核として、AI をどう走らせるかの中心に残っている

ハーネスの中身 - 3 層で設計する 「ハーネス設計の時代」を具体に - モデルの周り全部を 3 層に分ける Model（中核） Internal Harness External Harness ★ • 推論エンジン • Opus / Sonnet / Fable • context から出力を決める • agent loop・tools・context 管理 • モデルを「エージェント」にする層 • Claude Code 自体がこれ • Constitution.md・spec （＝ SDD の成果物）・ CLAUDE.md・Skills・ Hooks・MCP • ユーザーが設計・改善する層 • ハーネス工学の主戦場 運用 3 原則 - 小さく保つ / 可搬に保つ（Markdown で他ツールへ）/ built-in を使い切る

GitHub は中立なハブになる 1 2 3 全モデルを取り込む Copilot はどのモデルでも動く - 特定ベンダーに賭けない 全エージェントを取り込む Spec Kit はエージェント非依存 - 各社ツールをそのまま乗せる 標準は中立の場（AAIF）へ - GitHub はそれに乗る AGENTS.md / MCP は AAIF (Agentic AI Foundation＝ガバナンス/標準化団体) へ - 規約の標準化の中心に座る

6 まとめ - 名前ではなく「型」を学ぶ

キーメッセージ 持ち帰ってほしい 3 つの核心 1 2 3 コードの前に仕様を構造化する Spec Kit は Constitution.md を起点に、仕様 → 計画 → タスク → 実装をつなぐ 異なる仕組みを用いつつも実業界は同じ方向へ 各社は違うツールでも、同じ方向に向かっていること- SDD は消えたのではなく収束した 追うべきは個別機能でなく「型」 個別技術は陳腐化する。考え方は陳腐化しない 「どのツールを使うか」より「どう仕様を構造化するか」が問われる

次のステップ - 明日から試す 小さく試して効果を確かめる ● 手元のリポジトリに spec-kit を入れて /speckit.specify を 1 回実行する ● - /speckit.constitution を実行して、チームの規約・思想を constitution にする ● brownfield なら、改修が入る箇所から段階的に SDD 化する ● 個別の新機能を追うより、6 コマンドの「型」を身につける 次は、自分の題材で plan → implement まで回してみる

参考資料 参考URL一覧（リソース） Agent HQ 関連 https://github.blog/news-insights/companynews /welcome-home-agents / https://github.blog/news-insights/company-news/pickyour-agent-use-claude-and-codex-on-agent-hq/ https://docs.github.com/en/copilot/how-tos/use-aimodels/change-the-chat-model https://code.visualstudio.com/blogs/2025/11/03/unifiedagent-experience https://code.visualstudio.com/docs/copilot/agents/overv iew GitHub Copilot https://github.com/features/copilot https://github.com/features/copilot/agents https://docs.github.com/en/copilot Spec-Driven Development https://github.com/github/spec-kit Agent Skills & MCP https://github.com/aktsmm/vscode-agent-skill-ninja https://marketplace.visualstudio.com/items?itemName= yamapan.agent-skill-ninja https://claude.com/blog/extending-claude-capabilitieswith-skills-mcp-servers Claude https://www.anthropic.com/claude https://www.anthropic.com/news/claude-opus-4-6 https://x.com/bcherny/status/2023801162634572082?s =46&t=x8ThQ5xz1EucrC3ss1gHig FPT AI Factory https://factory.fpt.ai/ja/ Spec Kit (docs / extensions / hooks / presets) https://github.github.com/spec-kit/ https://github.github.io /spec-kit/reference/presets.html AGENTS.md https://agents.md Agentic AI Foundation (AAIF) https://aaif.io https://www.linuxfoundation.org /press /linuxfoundation-announces-the-formation-of-the-agentic-aifoundation MCP https://modelcontextprotocol.io Agent Skills https://agentskills.io OpenAI Codex https://github.com/openai/codex Open Source Friday with Spec-Kit https://youtu.be /2IArMAhkJcE

• https://github.blog/news-insights/company-news/welcome-home-agents/
• https://github.blog/news-insights/company-news/pick-your-agent-use-claude-and-codex-on-agent-hq/
• https://docs.github.com/en/copilot/how-tos/use-ai-models/change-the-chat-model
• https://code.visualstudio.com/blogs/2025/11/03/unified-agent-experience
• https://code.visualstudio.com/docs/copilot/agents/overview
• https://github.com/features/copilot
• https://github.com/features/copilot/agents
• https://docs.github.com/en/copilot
• https://github.com/github/spec-kit
• https://github.com/aktsmm/vscode-agent-skill-ninja
• https://marketplace.visualstudio.com/items?itemName=yamapan.agent-skill-ninja
• https://claude.com/blog/extending-claude-capabilities-with-skills-mcp-servers
• https://www.anthropic.com/claude
• https://www.anthropic.com/news/claude-opus-4-6
• https://x.com/bcherny/status/2023801162634572082?s=46&t=x8ThQ5xz1EucrC3ss1gHig
• https://factory.fpt.ai/ja/
• https://github.github.com/spec-kit/
• https://github.github.io/spec-kit/reference/presets.html
• https://agents.md
• https://aaif.io
• https://modelcontextprotocol.io
• https://agentskills.io
• https://github.com/openai/codex
• https://youtu.be/2IArMAhkJcE

Thank you!