--- title: Spec-Driven Development は消えたのか？ - AI 駆動開発が収束する方向性 -公開版 tags: #.net #c #github copilot #spec kit #sdd #仕様駆動開発 #claude code #codex #anthropic #openai #agentic engineering #harness engineering #context engineering author: [Shotaro Suzuki](https://image.docswell.com/user/shosuz) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GJ8D89GLJD.jpg?width=480 description: Spec-Driven Development は消えたのか？ - AI 駆動開発が収束する方向性 ※ DEMO 動画は後日この説明内で URL 公開します 「Spec-Driven Development (SDD)、もう聞かなくなったね？」と言われたりすることがあります。 確かに SDD という言葉自体は、以前ほど聞かれません。しかし廃れたのではなく、当たり前になっただけです。 本セッションでは GitHub Spec Kit を入口に、AWS の AI-DLC、Anthropic の Claude Code、OpenAI のCodex、そして各社の最新モデルが、異なる仕組みを用いつつも実質的に同じ方向へ収束している現在地を、デモを交えて紐解きます。 個別の新機能に振り回されず、変わらない「型」をどう掴むか。Spec Kit から業界全体の収束を読み解きます。 https://event.shoeisha.jp/devsumi/20260716/session/6904 published: July 17, 26 canonical: https://image.docswell.com/s/shosuz/K9N9P1-2026-07-17-152549 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GJ8D89GLJD.jpg) Spec-Driven Development は消えたのか？ - AI 駆動開発が収束する方向性 鈴木 章太郎 Executive Evangelist, FPT Data & AI Integration FPT Japan Holdings # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LJLMRWGQER.jpg) 鈴木 章太郎 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 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/47MYR9LK7W.jpg) アジェンダ 「消えたのか」を問い、Spec Kit から業界の収束を読み解く 1 「SDD は消えた」のか - 問いの背景 2 GitHub Spec Kit とは - 6 コマンドのワークフロー 3 デモ - Spec Kit で作る 4 重要概念 - constitution / extensions / presets 5 各社は実質同じに - 業界の方向性の収束 6 まとめ - 名前ではなく「型」を学ぶ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/P7R9RGK6E9.jpg) 1 「SDD は消えた」のか - 問いの背景 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/PJXQRXLD7X.jpg) 「SDD は消えた」のか 言葉は消えた - だが、なくなったわけではない ● 「Spec-Driven Development、もう聞かなくなったね？」と言われ始めている ● X は個別トピック (新機能・新ツール) の洪水 - 次々追って焦らされる ● だが SDD は廃れたのではなく、当たり前になって各社に溶け込んだ ● 本セッション: GitHub Spec Kit を入口に「実質は同じ」を確かめる 言葉が聞かれなくなった - 普及して標準になった証 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/3JK9RWLDJD.jpg) 2 GitHub Spec Kit とは - 6 コマンドのワークフロー # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LE3W813PE5.jpg) GitHub Spec Kit とは GitHub が公開する仕様駆動開発のツールキット Spec Kit 「コードを書く前に仕様を構造化する」を支援する OSS 既存のリポジトリ・エージェントに被せられる / 主要エージェントに対応 (思想は共通) GitHub Copilot Claude Code OpenAI Codex その他 CLI デモで使用 Anthropic Agent HQ / AGENTS.md Gemini / Cursor 等 特定の AI に縛られず、思想を共通化できるのが強み # Page. 8 ![Page Image](https://bcdn.docswell.com/page/8EDKMX437G.jpg) 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 の源泉になる # Page. 9 ![Page Image](https://bcdn.docswell.com/page/V7PKRPMPJ8.jpg) Spec Kit ワークフロー前半 - 仕様を固める まず「原則」と「何を作るか」を構造化する ① constitution ② specify ③ clarify 最初に作る「憲法」 何を作るかを言語化 曖昧さを対話で潰す ・命名規則・規約・思想を 1 ファイルに集約 ・ユーザ視点で要件を記述 (What) ・AI が抜け漏れを逆質問 ・答えて仕様の精度を上げる ・全コマンドが参照する土台 ・受け入れ基準まで構造化 ・/speckit.clarify ・/speckit.constitution ・/speckit.specify ・ 中身（規約・命名・理由） は人間が渡す ここを丁寧にやるほど、後半の実装が安定する # Page. 10 ![Page Image](https://bcdn.docswell.com/page/2JVVR29VJQ.jpg) Spec Kit ワークフロー後半 - 計画して実装する 仕様から実装可能な単位へ落とす ④ plan ⑤ tasks ⑥ implement どう作るかを設計 実装単位に分解 タスクを順に実装 ・技術スタック / 構成 / データモデルを決定 ・AI が実行できる粒度へ ・AI が 1 つずつ実装 ・依存関係を整理 ・人間はレビューに集中 ・/speckit.tasks ・/speckit.implement ・What を How へ翻訳 ・/speckit.plan 人間はレビューに集中し、AI が手を動かす # Page. 11 ![Page Image](https://bcdn.docswell.com/page/5EGLMRZ1JL.jpg) Constitution.md → requirements.toml はどこで効くか 問題提起 - 分かれ目は「新規 / 保守」ではなく、要件が「白紙」かどうか ここまで requirements.toml は「AI 逆質問で生成する」前提で説明してきた - でも、それは常に要る？ 要件定義まで済んでいる ＝ 大多数 要件が白紙 ＝ 完全な新規事業（例外）★ ・保守・派生開発 ・通常の新規開発（受託） ← 新規でもここ ・ゼロから事業を立ち上げる ・誰もまだ要件を持っていない → 要件はもうある。生成はほぼ不要 （使っても抜け漏れ検証＝clarify 程度） → ★ ここで初めて AI 逆質問で requirements.toml を生成する価値 問題提起：分かれ目は「新規 / 保守」ではなく「要件が白紙か」 Constitution.md → requirements.toml 生成が本当に要るのは、要件が白紙の "完全新規事業" だけ では？ Constitution.md 自体は常に必須 - シナリオで要否が変わるのは requirements.toml 「生成」だけ # Page. 12 ![Page Image](https://bcdn.docswell.com/page/4JQYRVLN7P.jpg) 3 デモ - Spec Kit で作る # Page. 13 ![Page Image](https://bcdn.docswell.com/page/K74W8MD3E1.jpg) デモの流れ - 仕様から実装まで デモ (約 15 分) は 3 段で構成 ① 仕様化 ② 計画・分解 ③ 実装・実行 constitution → specify plan → tasks implement ・原則と要件を先に固める ・技術設計を生成 ・AI がタスクを実装 ・clarify で曖昧さを除く ・実装単位へ分解 ・動作確認しながら進む ・コードはまだ書かない ・依存関係を整理 ・アプリが形になる 対話しながら進む様子をデモで見せる # Page. 14 ![Page Image](https://bcdn.docswell.com/page/LJ1Y28ZZEG.jpg) デモ: 既存 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 なし） # Page. 15 ![Page Image](https://bcdn.docswell.com/page/GJWGRZ9672.jpg) デモ動画は後日公開予定 VS Code 上で、Spec Kit と .NET／C#、GPT-5.6 Terra を使用し、 ECサイトの機能拡張を進めるデモです。 デモ動画は後日 VEED.IO で公開し、こちらの Docswell の説明欄に 動画リンクを追加します。 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/4EZLR19R73.jpg) デモの結果 ワークフローだけで動くアプリが完成 1 2 3 仕様駆動で成果物まで到達 手書きの実装をほぼせず、仕様から動くものができる AI が実装、人間はレビュー 人間はコードを書くのでなく、仕様とレビューに集中する 再現可能 手順 (仕様) が残るので、誰でも同じ成果を再現できる 「速い」より「仕様から再現できる」ことが価値 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/Y76WRLK17V.jpg) 4 重要概念 - constitution / extensions / presets # Page. 18 ![Page Image](https://bcdn.docswell.com/page/G75M81PL74.jpg) 統制と拡張の全体像 小さなコアを 3 つの仕組みで支える constitution 3 層構造 拡張で伸ばす プロジェクトの憲法 常時 / 専門 / 強制 extensions / presets ・常時：毎回効く原則 (CLAUDE.md / AGENTS.md / Constitution.md) ・コアは小さく保つ ・原則だけをコアに残す （詳細は外出し） ・全コマンドの共通土台 (SSOT) ・専門：必要時の知識 (Skills 相当) ・強制：必ず通すルール （Hooks) ツール選定ではなく「思想と仕組み」を設計する時代へ ・extensions で機能追加 (現在 100 近い) ・presets で要件を方向づけ # Page. 19 ![Page Image](https://bcdn.docswell.com/page/9J29K163ER.jpg) extensions の上に重ねる - hooks と presets 機能を「追加」する extensions、「方向づける」presets hooks presets 重ね方 (layering) プロセスに差し込む 挙動を方向づける 優先度つきで合成 ・各ステップに処理を フックできる ・機能追加でなく「影響」 ・append / prepend / wrap / total replace ・組織 / チーム単位で配布 ・例: Git 連携は hook として実装 ・現在 約 20 種 (A11Y 等) ・例: PII 禁止を全 PJ 強制 constitution を「各自任せ」から「組織で強制」へ # Page. 20 ![Page Image](https://bcdn.docswell.com/page/DEY4NZ98JM.jpg) 適用範囲と運用の勘所 新規・既存どちらにも効く / 文脈管理が鍵 (エンプラ向け) greenfield brownfield context 管理 新規プロジェクト 既存プロジェクト 長時間作業の文脈維持 ・立ち上げ時から仕様駆動 ・全置換は不要 改修箇所から SDD 化 ・context window を意識 ・最初に原則を定義 ・compaction で文脈を保つ ・既存資産を活かす ・きれいに積み上げ ・仕様が文脈を補完 ・段階的に広げる 既存システムでも「改修箇所から」始められる # Page. 21 ![Page Image](https://bcdn.docswell.com/page/VJNYX3L978.jpg) 文脈を設計する - Context Engineering の 4 要素 「文脈管理が鍵」を具体に - WHAT / HOW / WHY / FEEDBACK の 4 層で設計する WHAT HOW WHY ★ FEEDBACK スタック・構造 規約・命名 設計の理由 検証コマンド 技術・フォルダ構成 正例 / 反例つきで 具体化 欠けやすく高コストな 誤りの元 test / build / lint と期待出力 運用は ContextOps - Capture（暗黙知を規約化）→ Version → Distribute（各ツール形式へ）→ Govern（違反を pre-commit で検知） # Page. 22 ![Page Image](https://bcdn.docswell.com/page/YE9P8943J3.jpg) 過程を残す - Observability と監査証跡 LLM 入出力＋エージェントの過程を、自己ホストの受け皿へ集約する ① Proxy 層 ② エージェント OTel 層 ③ 受け皿（集約・監査） LLM の入出力を記録 過程を記録 集めて保存・検索・監査 （行って帰った内容） ツール呼び出し・判断 Langfuse 等セルフホスト可 ＝社内に置ける 過程の記録＝監査証跡＝完了の証 - テストが受け入れ基準として残るのと同じ考え方 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/GE8D89QLED.jpg) 5 各社は実質同じ方向性 - 業界の方向性の収束 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/LELMRWXQ7R.jpg) 異なる仕組みを用いつつも実質的に業界は 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 を駆動している # Page. 25 ![Page Image](https://bcdn.docswell.com/page/4JMYR93KJW.jpg) 天井を上げるのは Agentic Engineering - モデルより規律 失敗もするエージェントを、品質を保ったまま統率する ※ Andrej Karpathy（現 Anthropic、元 OpenAI 創設メンバー / 元 Tesla AI 責任者） Vibe Coding ＝ 最低ラインを上げる Agentic Engineering ＝ 到達できる上限を上げる ・誰でも「記述」でアプリを作れる ・失敗しやすいエージェントを統率 ・開発の入り口を下げる ・正確性 / セキュリティ / taste / 保守性を保つ「専門規律」 この資料の SDD / ハーネス設計 ＝ Agentic Engineering（到達できる上限を上げる側） # Page. 26 ![Page Image](https://bcdn.docswell.com/page/PJR9RGQ679.jpg) 失敗からルールを育てる 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 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/PEXQRX5DJX.jpg) マルチツールの規約を 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 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/3EK9RW6DED.jpg) 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 をどう走らせるかの中心に残っている # Page. 29 ![Page Image](https://bcdn.docswell.com/page/L73W816P75.jpg) ハーネスの中身 - 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 を使い切る # Page. 30 ![Page Image](https://bcdn.docswell.com/page/87DKMXV3JG.jpg) GitHub は中立なハブになる 1 2 3 全モデルを取り込む Copilot はどのモデルでも動く - 特定ベンダーに賭けない 全エージェントを取り込む Spec Kit はエージェント非依存 - 各社ツールをそのまま乗せる 標準は中立の場（AAIF）へ - GitHub はそれに乗る AGENTS.md / MCP は AAIF (Agentic AI Foundation＝ガバナンス/標準化団体) へ - 規約の標準化の中心に座る # Page. 31 ![Page Image](https://bcdn.docswell.com/page/VJPKRPVPE8.jpg) 6 まとめ - 名前ではなく「型」を学ぶ # Page. 32 ![Page Image](https://bcdn.docswell.com/page/2EVVR2ZVEQ.jpg) キーメッセージ 持ち帰ってほしい 3 つの核心 1 2 3 コードの前に仕様を構造化する Spec Kit は Constitution.md を起点に、仕様 → 計画 → タスク → 実装をつなぐ 異なる仕組みを用いつつも実業界は同じ方向へ 各社は違うツールでも、同じ方向に向かっていること- SDD は消えたのではなく収束した 追うべきは個別機能でなく「型」 個別技術は陳腐化する。考え方は陳腐化しない 「どのツールを使うか」より「どう仕様を構造化するか」が問われる # Page. 33 ![Page Image](https://bcdn.docswell.com/page/57GLMR41EL.jpg) 次のステップ - 明日から試す 小さく試して効果を確かめる ● 手元のリポジトリに spec-kit を入れて /speckit.specify を 1 回実行する ● - /speckit.constitution を実行して、チームの規約・思想を constitution にする ● brownfield なら、改修が入る箇所から段階的に SDD 化する ● 個別の新機能を追うより、6 コマンドの「型」を身につける 次は、自分の題材で plan → implement まで回してみる # Page. 34 ![Page Image](https://bcdn.docswell.com/page/4EQYRVGNJP.jpg) 参考資料 参考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 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/KJ4W8M5371.jpg) Thank you!