Spec Kit – この4日間で変更された 3 つの内容

GitHub Spec Kit v1.2.0 Spec Kit – この4⽇間で変更された 3 つの内容 Shotaro Suzuki Microsoft MVP for Developer Technologies (.NET / Developer Tools) Developer Advocate © 2026, Developer Advocate, LLC.

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

• https://shotaro-evangelist.carrd.co/
• https://www.docswell.com/user/shosuz
• https://mvp.microsoft.com/en-US/mvp/profile/f053766f-57f3-48da-bde8-73706d4b2da6
• https://aid.connpass.com/
• https://www.edifist.co.jp/course/MSCGH300
• https://cloud.google.com/blog/ja/topics/partners/google-cloud-partner-all-certification-holders-2025

Codex ではじめるエージェンティックコーディング --AI エージェントによる⾃律的システム開発ガイド 9/10 発売 https://amzn.asia/d/0g8bJDp0

• https://amzn.asia/d/0g8bJDp0

⽤語 - SDD / spec / Spec Kit この資料で使う意味をそろえる SDD（仕様駆動開発） 「何を作るか」を先に構造化し、そのドメインに合ったテストでループを回す 成功条件を「コマンドが⾛った」から「結果が仕様どおりか」へ変える spec（仕様） 作るものを、⼈と AI が同じ意味で読める形に書いたもの spec.md が起点。ここから plan・tasks・実装へ枝分かれする Spec Kit その spec を書き、下流の成果物まで作る⼿順と雛形を⼊れる GitHub のツール群 specify init で導⼊し、コーディングエージェントにコマンドとして⼊る spec は 1 つ、⼊⼝は 1 タスク - コードも 3D もモバイルも、全部ここから枝分かれする Developer Advocate © 2026, Developer Advocate, LLC.

Spec Kit が置く成果物 - 1 feature = 1 ディレクトリ 各段階が Markdown を 1 つ⽣み、それが次の段階の⼊⼒になる。この後の話はすべてこの 3 つの扱いの話 constitution.md spec.md plan.md tasks.md 原則・制約 何を作るか どう作るか 作業の単位 プロジェクト全体で 1 つ。 feature をまたいで効く この feature の意図。⼈が読 んで合意する対象 技術の選択と設計。spec か ら導く 実装の⼊⼝。converge はこ こに残作業を⾜す feature ごとにディレクトリとブランチを作る 開発が終わった後、このディレクトリを記録として置くのか、直し続けるのか - そこが v1.2.0 の論点 要件に ID を振って spec.md に書き、テストに同じ ID を埋めると、spec とテストを機械で突き合わせられる Developer Advocate © 2026, Developer Advocate, LLC.

変更の要約 - 版・コマンド・spec の持ち⽅ いずれも 2026-10 の 1 か⽉で⼊った。影響が⼤きいのは ③ ① 版 ② コマンド ③ spec の持ち⽅ v1.2.0 必須 6 + 任意 3 3 つのモデル 2026-10-13 公開 1.1.3 から 2 週間で patch を 6 本重ねた上の minor taskstoissues が core から外れ github extension へ移った 残りの並びは変わらない 開発完了後に成果物をどう保つかを Flow-Back / Flow-Forward / Living Spec として⽂書化 ③ は「spec を書いたあと、どう保つのか」という問いに Spec Kit が初めて答えを並べたもの 既定は⽰していない。選ぶのはチームで、選んだ結果を onboarding ⽂書に書くよう求めている Developer Advocate © 2026, Developer Advocate, LLC.

v1.0.13 から v1.2.0 まで - 何が積み上がったか リリースノートで確認できたものだけを並べた v1.0.13 github extension を同梱。taskstoissues 相当の働きをそちらへ v1.1.0 core の taskstoissues を deprecated。独⾃の step 種別をローカルから⼊れられる v1.1.2 MCP に artifact ⼀覧と version の道具。preset info / extension info が --json に対応 v1.1.3 workflow の実⾏⽊を⼀本化。catalog から⼊れた外部エージェントのアダプタに対応 v1.2.0 開発完了までと、その後の spec 保持の境⽬を⽂書で整理。Claude 向けに --no-modelinvocation 版の間隔は短い。コマンド名と⼿順を資料に書くときは、必ず版を併記する Developer Advocate © 2026, Developer Advocate, LLC.

Spec Kit のコマンド⼀式 - 必須 6 + 任意 3 いずれも speckit プレフィックス付きで⼊る（constitution → specify → plan → tasks → implement → converge） ① ② ③ ④ ⑤ ⑥ constitution specify plan tasks implement converge 原則・制約 仕様（What） 設計（How） 作業単位に分解 実装 残作業を追加 任意 3 コマンド - 必要に応じて差し込む（品質と精度を上げる） ・clarify - spec の曖昧な箇所を対話で詰める（plan の前に推奨） ・analyze - spec / plan / tasks の整合と網羅をチェック（tasks の後、implement の前） ・checklist - 要件の完全性・明確さ・⼀貫性を検証する品質チェックリストを⽣成 変わったのは ⑤ だけ。旧 ⑤ taskstoissues が core から外れ、implement と converge が繰り上がった converge は既存コードを spec / plan / tasks と突き合わせ、未実装分を tasks.md に追加する Developer Advocate © 2026, Developer Advocate, LLC.

必須 7 → 6 - taskstoissues が core から出た コマンドが消えたのではなく、同梱の extension に移った これまで（必須 7） v1.2.0（必須 6） constitution → specify → plan → tasks → taskstoissues → implement → converge constitution → specify → plan → tasks → taskstoissues が 5 番⽬に居た Issue 化は github extension が担う implement → converge 移った経緯 v1.0.13 taskstoissues の働きを持つ github extension を同梱した v1.1.0 core の taskstoissues を deprecated とし、extension を使うよう案内 v1.2.0 必須は 6 本。テンプレートには taskstoissues が残るが core の⼿順ではない Developer Advocate © 2026, Developer Advocate, LLC.

core を薄く、周りは extension へ specify extension add <名前> で⾜す。core の⼿順を増やさずに機能を増やす形 github bug assess Issue 化 不具合の 3 コマンド 着想の 5 コマンド tasks.md から Issue を作る 旧 core taskstoissues の後継 bug-assess で原因を⾒極め bug-fix で直し bug-test で症状が消えたか確かめ る assess-intake / research / define / shape / decide go なら specify に渡せる v1.1.0 以降、extension / preset / workflow / step はいずれも catalog から版を指定して⼊れられる v1.1.3 では catalog から⼊れた外部エージェントのアダプタにも対応した core の 6 本だけ覚えれば⾜りる。増えた分は⼊れたチームだけが⾒る形になった Developer Advocate © 2026, Developer Advocate, LLC.

開発と保守は別の問い - v1.2.0 が整理したこと 開発完了までの道筋は共通。分かれるのは、その後 開発完了までのループ - どのモデルでも同じ specify plan tasks implement converge ⼆つの問いを分ける 問い 1 開発が終わるまでに spec をどう使うか ここは Spec Kit が⼿順として決めている（上のループ） 問い 2 開発が終わった後、要件が変わったとき成果物をどうするか ここは決めていない。チームが 3 つのモデルから選ぶ converge は tasks.md に残作業を⾜すだけで、保持のしかたは強制しない。既定も要件も無い Developer Advocate © 2026, Developer Advocate, LLC.

spec の保持 - 3 つのモデル docs/concepts/spec-persistence.md と docs/guides/evolving-specs.md で整理された Flow-Back Spec 受け⼊れた発⾒で、開発完了後も spec.md / plan.md / tasks.md の どれでも直す 向く場⾯ ︓ 少⼈数で、発⾒が計画を作り替える前提のとき。速さを採る 注意 ︓ 下位だけ直して spec.md に戻さないと、黙って離れていく Flow-Forward Spec 開発が終わった成果物は触らない。次の変更は新しい feature ディレクトリを 作る 向く場⾯ ︓ 監査の要るとき。feature の切り分けと変更の順序が明確なとき 注意 ︓ 同じ記述が増え、⽂脈がディレクトリに散る Living Spec spec.md を契約として直し、plan.md と tasks.md は作り直す派⽣物と ⾒る 向く場⾯ ︓ 製品の契約が安定しているとき。作り直しに抵抗が無く、⼀貫性を採るとき 注意 ︓ 捨てた派⽣物と⼀緒に、実装時の判断の理由が消える どのモデルでも共通 ︓ 実装で⾒つかったことは、意図の代わりではなく、チームが判断するための材料として扱う Developer Advocate © 2026, Developer Advocate, LLC.

martinfowler.com の三段階と、どう噛み合うか Birgitta Böckeler「Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl」2025-10-15 当時の評価 ︓ 「spec-kit は spec-first にとどまり、spec-anchored ではない」 根拠 ︓ spec ごとにブランチを作る作りは、spec を feature の寿命ではなく変更要求の寿命の産物と⾒ている 三段階（記事）と 3 モデル（v1.2.0）の対応 - 本資料の整理 spec-first spec-anchored spec-as-source spec は先に書くが、作業が終われば捨ててよい Flow-Forward に近い （開発完了後は記録として置くだけ） 作業の後も spec を保ち、以後の変更と保守に 使う Flow-Back （成果物を揃え直す） ⼈が直すのは spec だけ。コードには触らない Living Spec （spec.md が契約、下流は再⽣成） v1.2.0 は、この指摘のあった箇所を「選べる 3 つ」として⽂書に書き下した。既定は置かず、チームに委ねている Developer Advocate © 2026, Developer Advocate, LLC.

まとめ - 資料と現場をどう直すか 資料の直し チームで決めること ・「必須 7 + 任意 3」→「必須 6 + 任意 3」 ・開発完了後の feature ディレクトリは ・taskstoissues は github extension 記録か、直す対象か ・コマンドの話には版を併記する ・spec.md を唯⼀の真実とするか ・converge は brownfield で使う ・決めたら onboarding ⽂書に書く 多くのアプリでは Living Spec に近い形を採っている spec.md の要件 ID をテストに埋め、work/check_fr_coverage.sh で突き合わせる spec を直せばテストの不⾜が出る 出典 github/spec-kit releases（v1.2.0, 2026-10-13）／ docs/concepts/spec-persistence.md ／ docs/guides/evolving-specs.md ／ martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html Developer Advocate © 2026, Developer Advocate, LLC.

Thank you for your attention! Developer Advocate © 2026, Developer Advocate, LLC.