---
title: Spec Kit –  この4日間で変更された 3 つの内容
tags:  #github copilot #sdd #spec driven development #openai #azure #github #martin fowler #spek kit  
author: [Shotaro Suzuki](https://docswell.com/user/shosuz)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LE3WMN91E5.jpg?width=480
description: AI Hack BAR — POP-UP NIGHT in SHINJUKU 5分でスライド作ってLT 急遽やりました！ お酒の席でMartin Fowlerの話しちゃいましたw https://aid.connpass.com/event/407351/
published: October 14, 26
canonical: https://docswell.com/s/shosuz/ZQ2J1J-2026-10-14-200957
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LE3WMN91E5.jpg)

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.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/8EDK6WGK7G.jpg)

鈴⽊ 章太郎
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.


# Page. 3

![Page Image](https://bcdn.docswell.com/page/V7PKY933J8.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2JVVGM4NJQ.jpg)

⽤語 - 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.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5EGL8G15JL.jpg)

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.


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JQY9XDL7P.jpg)

変更の要約 - 版・コマンド・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.


# Page. 7

![Page Image](https://bcdn.docswell.com/page/K74WX6Z5E1.jpg)

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.


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LJ1YNVR2EG.jpg)

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.


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GJWG4L1272.jpg)

必須 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.


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EZL2MP473.jpg)

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.


# Page. 11

![Page Image](https://bcdn.docswell.com/page/Y76WVNMG7V.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/G75MD5ZX74.jpg)

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.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9J298NRQER.jpg)

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.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DEY46PDYJM.jpg)

まとめ - 資料と現場をどう直すか
資料の直し
チームで決めること
・「必須 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.


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJNYZ56R78.jpg)

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