産総研AITeC-Generative AI Study Group-第73回-20260526-SDDセッション-公開版

AI 駆動開発の新しい構造 Spec-Driven Development を⼀つの機能で最後まで追う 産総研 AITeC Generative AI Study Group 第73回

鈴⽊ 章太郎 X (Twitter) : @shosuz FPT ジャパン FPT データ& AI インテグレーション エグゼクティブエバンジェリスト 独⽴⾏政法⼈ 国⽴印刷局 デジタル統括アドバイザー兼最⾼情報セキュリティアドバイザー 合同会社デベロッパーアドボケイト 代表社員チーフアドボケイト Developer Advocate 略歴︓ AI 駆動開発勉強会主催。Microsoft エバンジェリスト時代(2003年)から、Dell、 Accenture、Elastic、VMware を経て現職まで、20年に渡り⼀貫して開発者向けに 最新技術を啓発。NVIDIA GPU クラウド技術訴求、 AI 駆動開発コンサルティングを 実施。AI 駆動開発コンソーシアム副座⻑。 政府の仕事は、内閣官房 IT 総合戦略室 政府 CIO 補佐官（併任︓法務省 CIO 補佐官、第4次 安倍改造内閣、 2019年4⽉〜）、 デジタル庁 PM（併任︓⾦融庁 デジタル統括アドバイザー、菅内閣、2021年9⽉〜）を経て2024年10⽉より現職を兼 務。 https://shotaro-evangelist.carrd.co / https://www.docswell.com /user/shosuz AI 駆動開発トレーニング、AI 駆動開発コンサルティング、技術顧問、技術マーケティング ⽀援、クラウドトレーニング、を提供する合同会社デベロッパーアドボケイトを2022年設⽴。 MCT (Microsoft 認定トレーナー) としてエディフィストラーニング社においてGH-300 コース 担当の他、多くの AI 開発系トレーニング講師を担当。 Google Cloud Partner All Certifications Engineer 2025 。

• https://shotaro-evangelist.carrd.co/
• https://www.docswell.com/user/shosuz
• https://www.edifist.co.jp/course/MSCGH300
• https://cloud.google.com/blog/ja/topics/partners/google-cloud-partner-all-certification-holders-2025

本⽇のアジェンダ ̶ 概念ではなく「動く流れ」で⾒る 現状の限界 → 仕様駆動の全体像 → 上流の⽣成 → 3 層統制 → Skills → 業界収束 → 現場適⽤ Ⅰ AI 駆動開発の現状と限界 Ⅱ 仕様駆動の全体像 ̶ 題材を 1 つ通す Ⅲ 上流︓仕様をどう⽣むか（逆質問 / ⽣成） Ⅳ 統制の仕組み ̶ 3 層アーキテクチャ Ⅴ Why Skills ̶ 専⾨知識を装着する Ⅵ 業界収束︓AWS / Microsoft / Anthropic Ⅶ 現場適⽤とまとめ ̶ 組織への問い 汎⽤ EC の「商品検索機能」を題材に、上流から CI まで⼀連の流れを具体例でたどる

AI 駆動開発の現状 ̶ プロンプトだけでは届かない領域 「いい感じに作って」が機能するのは⼩さい範囲だけ ✅ プロンプト駆動が効く領域 ⚠ プロンプトだけでは破綻する領域 ・⼩さい・閉じたタスク（関数⽣成・1 ファイル変更） ・⾔語・FW の⾃動補完 ・短いリファクタリング ・テストコードの定型⽣成 ・「探索的試⾏」のループ ・複数⼊⼒・複数制約・複数エッジケース ・API / スキーマ駆動の整合 ・既存コードベースへの段階的変更 ・セキュリティ・コンプライアンス制約 ・組織独⾃規約・暗黙知の遵守 ・再現性の要求（同じ仕様 → 同じ出⼒） 問題は AI の能⼒ではなく「何を作るか」の記述構造

Spec-Driven Development とは 「コードを書く前に仕様を構造化する」̶ 仕様が実装を駆動する ① Spec ② Plan ③ Tasks 何を作るか どう作るか どこから着⼿ ユーザ視点の要件 / 受け⼊れ基準 / ビジネス要件 技術選定 / アーキテクチャ / 制約 実装可能タスクへの分解 Spec / Plan / Tasks の 3 段で「仕様 → 実装」が再現可能になる

本⽇の題材 ̶ 汎⽤ EC の「商品検索機能」を⼀本で追う 概念の羅列ではなく、1 つの機能が上流から CI まで流れる様⼦を最後まで具体例でたどる 🧵 ec-product-search 題材︓ec-product-search（商品検索機能） ̶ 顧客固有情報を含まない中⽴例 • 「キーワード・カテゴリ・価格帯で商品を検索し、⼀覧 → 詳細に遷移する」ありふれた機能。 • この種の機能はサンプルが世の中に豊富にあり、参考はいくらでも⾒つかる。 意図 AI 逆質問 requirements Constitution. .txt md /speckit. specify Hooks SKILL.md CI ゲート 上流（何を作るか）─────────→ 統制（どう守るか）─────────→ 下流（壊れないことの保証） 💡 この後のスライドは、上のパイプラインの各ブロックを 1 枚ずつ具体例で取り上げる 抽象的な「Constitution.md とは」で終わらせず、ec-product-search の Constitution 抜粋・逆質問・ requirements.txt・hooks.json・SKILL.md・CI 設定を、具体的な記述例として載せる。 「枠だけで中⾝は別途」ではなく、中⾝まで具体例で⽰す

【公開版では割愛】 このページ:「Constitution.md の記述例」 実装の詳細（具体的な設定・コード例）は公開版では削除しています。

上流② INCEPTION ルールの台本がどう動くか 「AI が逆質問する」のは魔法ではなく、Constitution.md に書いた台本の実⾏ 🧵 ec-product-search 1 2 3 4 5 要求を受ける 台本を読む 逆質問する 下書く 確定する 「商品検索を追加」 Constitution の INCEPTION 節を 参照 5 項目＋変種 テンプレを順に質 問 回答から requirements ドラフト⽣成 ⼈間が確認 → spec へ AI の「賢さ」に依存せず、組織が決めた観点を台本として毎回必ず通す

上流③ AI 逆質問でドラフトを⽣成する 「requirements を誰が書くか」̶ ⼈間が⼀から書く → AI が抜けを逆質問して下書く ① 開発者の⼊⼒（数分） 「商品検索機能を追加したい。 キーワードとカテゴリで絞れて、 ⼀覧から詳細に⾶べれば良い」 🧵 ec-product-search ② AI が逆質問（Constitution の台本に沿って） ③ ⼈間が確定 ・検索条件は︖（キーワード / カテゴリ / 価格帯 / 在庫有無） ・ページング⽅式は︖（offset / cursor）/ 1 ページ件数 ・並び順は︖（関連度 / 価格 / 新着）デフォルト は︖ AI の下書きを Tech Lead / PO が確認・補正 し、requirements.txt と して確定 → PR。 ・認可︓未ログインでも検索可能か︖ ・性能要件︓応答 95%ile は何 ms 以内か︖ ・抜けを AI が拾う ・判断は⼈間が握る ・毎回同じ観点で漏れない ・既存の商品テーブル schema・索引は︖ 意図⼀⾔ → AI が抜けを質問 → ⼈間が確定。要件定義の⼯数を圧縮しつつ観点漏れを防ぐ

【公開版では割愛】 このページ:「requirements.txt（TOML マニフェスト）」 実装の詳細（具体的な設定・コード例）は公開版では削除しています。

上流⑤ /speckit.specify で 4 ファイルを⼀括⽣成 Spec Kit（GitHub OSS）の 1 コマンド。Input → Run → Output の 3 段がはっきり分かれている 🧵 ec-product-search $ /speckit.specify ec-product-search ✓ specs/ec-product-search/spec.md ← 何を（要件・受⼊基準） ✓ specs/ec-product-search/plan.md ← どう（API 設計・schema） ✓ specs/ec-product-search/tasks.md ← 着⼿単位に分解 ✓ specs/ec-product-search/requirements.txt ← ⽣成マニフェスト (TOML) spec.md plan.md tasks.md requirements.txt 何を作るか どう作るか 着⼿単位 ⽣成マニフェスト 受⼊基準 / ユーザストーリー / エッジケース REST 設計 / products 索引 / cursor ページング API・Repo・テストに タスク分解 再⽣成・制約・変種を TOML で固定 1 コマンドで仕様⼀式が版管理対象になる ̶ 「仕様 = コードと同じ管理物」へ

統制① Constitution.md を⽀える 3 層 ̶ 常時 / 専⾨ / 強制 3 ツール共通の標準パターン ̶ 同じ API で「思想 → 実装」が動く ①常時 (Always-On) ②専⾨ (On-Demand) ③強制 (Enforcement) 全 turn で auto-load される 基盤層 Progressive Disclosure ̶ メタデータのみ常時、本体は invoke 時 Hooks API ̶ AI を信⽤せず 機械的に enforce 主な内容 ・命名規則 / ファイル構造 ・⾔語・FW 選定 ・INCEPTION ルール ・組織共通の規範 主な内容 ・SDD ステップを skill 化 ・組織のコーディング規約 ・専⾨領域 (security / a11y) ・業界固有のベストプラクティス 主な内容 ・編集前 hook︓危険操作 block ・編集後 hook︓ linter / validator ・intent 検出 → context 注⼊ ・CI の前段で違反を絶つ 💡 context を軽量に保つ 💡 規約が増えても context 肥⼤化しない 💡 AI の柔軟性 × 機械的統制 の両⽴ 「常時で⼟台 / 専⾨で拡張 / 強制で統制」̶ 3 層分業で軽量・拡張・統制を両⽴

統制② 3 ツール共通の標準パターン ̶ Copilot / Codex / Claude Code 異なるベンダーが同じ API 名（PreToolUse / PostToolUse / SKILL.md）に収束 常時 (Auto-Load) 専⾨ (Skills) 強制 (Hooks) GitHub Copilot copilot-instructions.md .github/prompts/*.prompt.md .github/hooks/hooks.json Codex AGENTS.md ~/.codex/skills/ (SKILL.md) ~/.codex/hooks.json Claude Code CLAUDE.md .claude/skills/ (SKILL.md) .claude/settings.json 💡 Hooks のイベント名は 3 ツールで共通: PreToolUse / PostToolUse / userPromptSubmitted / ... ベンダー固有の⽅⾔ではなく、業界収束した「共通標準」として扱える

【公開版では割愛】 このページ:「Hooks（hooks.json）の設定例」 実装の詳細（具体的な設定・コード例）は公開版では削除しています。

Why Skills ̶ IQ300 の Mahesh より、Barry の専⾨知識 「確定申告は経験豊富な税理⼠に頼みたい」̶ AI に IQ ではなく組織の専⾨性を装着する Mahesh ─ IQ300 の数学者 Barry ─ 経験豊富な専⾨家 ・天才的な知能 ・毎回ゼロから解釈 ・経験から得たドメイン知識 ・⼀貫した実⾏ ・専⾨知識を持たない ・あなたの組織の知識を吸収しない vs ・時間が経っても学習しない ・組織の⼿順を熟知 ・新しい分野でも前提を持つ ・即戦⼒ 💡 現在の AI エージェントは Mahesh に近い → Skills（SKILL.md 形式）で「Barry の専⾨知識」を装着する。 組織の⼿順・規約・暗黙知を蓄積し、必要時のみ AI が読み込む。 出典︓Anthropic Skills チーム講演（Barry / Mahesh、2026 年 5 ⽉）

Skills の 3 種類 ̶ Enterprise Skills が組織の競争⼒になる モデルは誰でも同じ。差がつくのは「組織の知識をどれだけ AI に装着できたか」 Foundational Third-Party Enterprise ★ 作る⼈ 作る⼈ 作る⼈ 中⾝ 中⾝ 中⾝ 具体例 具体例 ベンダー公式 外部ベンダー / OSS AI ベンダー（Anthropic 等）公式 汎⽤・分野⾮依存の能⼒ 特定ツール・サービスの操作⼿順 ・Office ⽂書 / PDF の操作 ・科学計算・データ可視化 御社の関与 外部の専⾨ベンダー・OSS 既製をそのまま使う（⾃作しない） ・Notion / Figma 連携 ・各種 SaaS の API 操作 御社の関与 必要なものを選んで追加する ⾃社独⾃ ̶ 本命 御社⾃⾝（DRI・Skill 作成者） 組織固有の規約・⼿順・暗黙知 （外には存在しない知識） 具体例 ・命名 / レビュー規約 ・社内ライブラリの作法 ・過去障害からの禁則 ・業務ドメインのルール 御社の関与 ⾃分で書いて継続的に育てる ★ なぜ Enterprise が本命か ̶ モデルでは差がつかない、組織知識で差がつく AI モデルは誰もが同じものを使える。優位はモデルの賢さではなく、組織独⾃の知識を SKILL.md として AI にどれだけ装着できたかで決まる。書く⼈・レビュー する⼈・保守する⼈を決め、3〜6 ヶ⽉ごとに⾒直して育てる。 Anthropic は 5 週間で⾦融・ライフサイエンス向け Skill パックを展開 ̶ 業界垂直化の速さ

【公開版では割愛】 このページ:「SKILL.md の記述例」 実装の詳細（具体的な設定・コード例）は公開版では削除しています。

Skills が開く「アプリケーション層」 ̶ コンピュータ史と同型の構造 Anthropic 由来のアナロジー︓CPU / OS / App の構造が AI に再現される AI モデル (Claude / GPT / Gemini) 巨⼤な投資、単体では何もできない エージェントランタイム リソース管理、Skills の動的 load Skills (SKILL.md 形式) 誰でも作れる、ドメイン知識のパッケージ ★ = プロセッサー (CPU) = オペレーティング システム = アプリケーション 💡 CPU / OS を作るのは数社、App は数百万⼈が作る ̶ Skills も同じ広がり⽅をする → AI 時代の「アプリケーション開発者」= ドメインエキスパート + プロンプト設計者 AI のアプリケーション層が、初めて⾮ベンダーに開放された

業界収束 ̶ AWS・Microsoft・Anthropic が異なる経路で同じ結論に 「思想 + 仕様 + 共通 API」という枠組みは、ベンダー⽅⾔ではない AWS Microsoft Anthropic AI-DLC（aidlc-workflows） Spec Kit を公式推奨 Agent Skills を提唱 ・6 ツール対応の公式リポジトリ ・「Moving Beyond Prompts」 ・SKILL.md = 共通仕様 ・Constitution + Plan + Tasks 構造 ・Microsoft Learn にトレーニング ・Progressive Disclosure ・1 ⾏設定で各ツール統合 ・Copilot CLI で hooks 標準装備 ・Enterprise Skills で組織知識配布 3 社が独⾃経路で同じパターンに収束 ̶ これは流⾏ではなく業界構造の変化

Anthropic の 5 週間 ̶ Skills + MCP で業界垂直展開 汎⽤エージェントに「業界知識パック」を渡せば、特化エージェントが即完成する 📅 Skills 発表からの 5 週間 Skills + 業界特化 MCP セット の配布で、Anthropic ⾃⾝が 2 つの業界向けサービスをローンチ ⾦融サービス向け ライフサイエンス向け 業界データ MCP + ⾦融専⾨ Skills EHR / バイオインフォマティクス Skills ⽰唆 ・汎⽤ AI モデルは「OS のような共通基盤」 ・業界知識パック（MCP + Skills）が「業界対応アプリ」 ・業界 SIer / コンサルの差別化軸が「Skill ポートフォリオの厚み」になる可能性 「業界対応はモデルではなく Skill で決まる」時代が始まっている

現場適⽤① 既存 IDE / AI ツールと Spec Kit の関係 「Spec Kit は新しいツール」ではなく、既存ツールに思想を導⼊する仕組み 🛠 既存ツール（変えない） ✨ Spec Kit が⾜すもの（思想層） ・GitHub Copilot / Codex / Claude Code の 継続利⽤ ・既存リポジトリ・CI・PR フローはそのまま ・IDE 操作も従来通り ・学習コストはほぼゼロ ・Constitution.md（SSOT） ・/specify /plan /tasks の 3 段階 ・AI 逆質問による要件ドラフト⽣成 ・Skills + Hooks の 3 層構造 ・Brownfield 適⽤パターン ツール乗換ではなく「思想の上乗せ」 ̶ 既存資産を活かしたまま導⼊できる

現場適⽤② Brownfield（既存システム）への適⽤ 既存コードベースに後付けで SDD を導⼊する段階的アプローチ Phase 1 Template 導⼊ Phase 2 SoT 定義 & Spec 化 Phase 3 差分 Spec 開発 Goal CI / Review 完全統合 Spec Kit 初期化 + Constitution.md 整備 重要機能から順次 Spec 化 改修は Spec ファースト ガードレール運⽤、コード変更 には Spec 変更必須 💡 鉄則︓コード変更 PR には対応する Spec 変更が必須 → CI で機械的に強制すれば「Spec とコードの乖離」を構造的に防げる → 全機能を⼀度に Spec 化する必要なし ̶ 改修が⼊る箇所から段階的に切替 Greenfield だけでなく Brownfield にも適⽤可能 ̶ 既存資産を捨てなくて良い

【公開版では割愛】 このページ:「品質ガードレール / CI の実装⼿段」 実装の詳細（具体的な設定・コード例）は公開版では削除しています。

現場適⽤④ 段階的な導⼊ ̶ 即⽇ / 中期 / ⻑期 重い変⾰ではなく、軽量から始めて検証しながら段階的に拡張 即⽇ 1〜3 ヶ⽉ 3〜6 ヶ⽉ 30 ⾏の追加で開始 Spec ファースト切替 CI / ガードレール統合 ・Constitution.md に 30 ⾏追記 ・各ツールの設定に 1 ⾏参照 ・現場の流儀はほぼ無変更 ・改修が⼊る箇所から段階適⽤ ・Skills を 1 つずつ整備 ・プロンプトパターン蓄積 ・constraints の CI 強制 ・Hooks による編集時チェック ・Skills 全社展開 💡 既存投資を活かす ̶ Copilot / Codex / 既存リポジトリはそのまま継続 💡 ベンダーロックインなし ̶ 3 ツール共通標準なので、将来他ツールが台頭しても対応可 💡 可逆的 ̶ 軽量から始めて、効果を確認してから次に進む 「重い変⾰プロジェクト」ではなく「⽇々の改善の延⻑」として導⼊可能

SDD の今後 ̶ 4 つの発展軸 軽量導⼊から始めて、必要に応じて段階的に拡張できる Adaptive Depth Extensions 規模に応じた深度調整 ⾃社規約の上乗せ Minimal / Standard / Comprehensive で過剰品質 を回避 Constitution.md に追記し、全社ガバナンスを AI に伝播 Feature サブディレクトリ 導⼊の選択肢 複数チーム並⾏開発 軽量 / フル を併存 workflow/ を機能単位に分割、並⾏開発に対応 Constitution.md ベース / AI-DLC フル の段階拡張 「重い AI-DLC vs 軽い Constitution.md」ではなく「段階的に進化」する選択肢

組織が考えるべき 3 つの問い SDD を導⼊する際、組織が向き合う本質的な意思決定 Q1 Q2 Q3 暗黙知をどう資産化するか︖ 属⼈化したノウハウを SKILL.md として体系化できる仕組みが組織にあるか。Skill を書く⼈・レビューする⼈・保守 する⼈を誰にするか。 ツール多様性をどう統制するか︖ Copilot / Codex / Claude / Gemini ... が並⾛する現実で、Constitution.md のような SSOT を運⽤で きる組織体制があるか。 「仕様 = 契約」の⽂化に切替えられるか︖ コード変更には Spec 変更が必須、というガードレールを⽂化として定着できるか。レビュアー・PM の役割が再定義 される。 技術ではなく組織 ̶ SDD 導⼊は組織変⾰プロジェクトでもある

まとめ ̶ 3 つのキーメッセージ 本⽇のセッションを 3 ⾏に圧縮するなら 1 2 3 AI 駆動開発は「プロンプト → 仕様」へ プロンプト依存の限界が明確になり、Spec-Driven Development が業界収束しつつある。 これは流⾏ではなく構造変化。 「思想層」を SSOT として管理する Constitution.md を中⼼に、3 層（常時 / 専⾨ / 強制）で AI ツールを統制する設計が成⽴した。 ベンダー⽅⾔ではなく業界共通標準。 Skills が組織の競争⼒になる AI モデルではなく、組織独⾃の知識を SKILL.md として配布できるかが差別化軸。 「Barry の専⾨性」を AI に装着する戦略。 「ツール選定」ではなく「思想と仕組み」を設計する時代に⼊った

参考資料 / 出典 ̶ 本セッションで参照した主な資料 本セッションで参照した公式ドキュメント・記事の⼀覧 公式ツールキット GitHub Spec Kit AWS 公式 awslabs/aidlc-workflows (AI-Driven Lifecycle) Microsoft 公式 Moving Beyond Prompts: Spec-Driven Development (2026/5) Anthropic 講演 Skills チーム講演 (Barry / Mahesh, 2026/5) 実装ドキュメント Claude Code Hooks / Codex CLI Hooks リファレンス github.com/github/spec-kit github.com/awslabs/aidlc-workflows techcommunity.microsoft.com / Microsoft Learn Anthropic 公式 / 国内まとめ記事 code.claude.com / developers.openai.com いずれも公式の⼀次資料 ̶ 詳細は各リンクを参照