GITHUB SPEC-KIT · ENGINEERING INTENT · 2026 / 05 / 11

GitHub Spec-Kit—「Vibe Coding」を終わらせる「仕様駆動開発」キット

プロンプト工学から仕様工学へ — AIに「察してもらう」のをやめ、意図(Intent)を構造化された仕様で表現する

「動いた、でも違うものができた」— AI コーディングが生む不可逆な技術的負債の正体は 「意図の喪失(Intent Loss)」。Spec-Kit は 4 つのスラッシュコマンド（/specify → /plan → /tasks → /implement）で意図を Markdown 仕様に結晶化し、AI を「察して書く存在」から 「仕様を実装するパートナー」へ転換する。

GitHub 公式の OSS（github.com/github/spec-kit）。Constitution.md でプロジェクト全体のガードレールを宣言、Copilot / Claude Code / Cursor / Gemini CLI など主要エージェントに横断対応。コードではなく仕様こそが 「真の資産(Source of Truth)」になる。

→ なぜ Spec-Kit か 4 コマンドを見る

Project: github/spec-kit (OSS)
Workflow: /specify → /plan → /tasks → /implement
Governance: Constitution.md
Agents: Copilot / Claude / Cursor / Gemini

GitHub Spec-Kit: Engineering Intent cover — **GITHUB SPEC-KIT** · 仕様こそ真実(Source of Truth) — プロンプトから仕様への *パラダイムシフト*

KEY METRICS

4 つの数字で読む Spec-Kit のインパクト

仕様を書く時間が増えるのに「全体の開発速度は上がる」— この一見矛盾した結果が、世界中の開発者を Specification-First へ動かしている。Spec-Kit は GitHub の DevOps チームと外部コントリビュータが共同設計した、公式準拠の構造化ワークフローだ。

4スラッシュコマンド

4+対応AIエージェント

3Markdown 成果物

OSSgithub/spec-kit 公式

Spec-Kit PDF page 1 — Engineering Intent · プロジェクト全体像

Spec-Kit PDF page 2 — Vibe Coding と Spec-Driven の対比

CHAPTER 1 · INTENT LOSS

「動いた、でも違うものができた」— プロンプト工学の構造的限界

AIコーディングの普及で見えてきた逆説：プロンプトを上手く書けば書くほど、何を作ろうとしていたかが薄れていく。チャットの履歴に散らばった意図、修正に修正を重ねたパッチ、誰も全体像を持っていないコードベース — これらは「Vibe Coding(雰囲気コーディング)」が残す不可逆な負債だ。

「意図(Intent)」はチャット履歴に蒸発する — その瞬間、技術的負債が生まれる

最初の指示は明確だった。「ユーザー登録フォームを作って」。だが質問と回答を 30 往復した頃には、なぜ確認メール送信を「後で」と判断したか、なぜ DB スキーマを途中で変えたか、誰も思い出せない。完成したコードは動く。けれど、誰のために何を解いたコードなのか、コードからは読み取れない。

Symptom 1

仕様のチャット蒸発

判断根拠が会話履歴に散逸し、半年後の自分が読み解けない。レビュー観点も再現不能。

Symptom 2

修正の上塗り化

「微妙な要件」を後から後から差し込み、AIは元の意図を見失ったままパッチワークを重ねる。

Symptom 3

エージェントロックイン

同じ機能を別のエージェント (Copilot → Claude → Cursor) で再現できない。プロンプトが 暗黙の知識 になり共有不能。

これは「AI のせい」ではない。コードが完成した瞬間、「なぜそれを作ったか」が消えてしまう — これは古典的なソフトウェア工学の問題が、AI コーディング時代に増幅されただけだ。Bertrand Meyer は 1990 年代にすでにこう書いた：「コードは仕様の偶発的副産物(accidental byproduct)である」。Spec-Kit はこの古い真理を、AI 時代の言葉で再発明する。

CHAPTER 2 · SPEC-FIRST REDISCOVERY

仕様こそ「真実(Source of Truth)」— Spec-Kit の中核思想

Spec-Kit は新しい AI 機能ではない。むしろ 「仕様」というソフトウェア工学の古い概念を、AI コーディング時代に再武装する 試みだ。コードは仕様の偶発的副産物に過ぎず、変更されるべきは仕様であり、コードはそこから派生する。これは Specification-First の単純で強力な逆転である。

「コードから仕様」ではなく「仕様からコード」— 矢印を逆向きにする

Vibe Coding の世界では、人間がプロンプトを書き、AI がコードを書き、テストでバグを見つけ、人間がさらにプロンプトで修正する。仕様は「コードから読み解く」もの。Spec-Driven の世界では、人間が仕様を書き、AI が仕様から計画を作り、計画からタスクを切り、タスクからコードを書く。仕様こそが起点であり、コードは終点。

Before · Vibe Coding

プロンプト工学：察してもらう

意図が会話履歴に散在。コードが「結果」として残るが、なぜそうなったかは 蒸発済み。再現性なし。

→

After · Spec-Driven Development

仕様工学：構造化された意図

仕様 (spec.md) が 真実の源。計画 (plan.md) とタスク (tasks.md) は仕様から派生。コードは仕様の 翻訳結果。

GitHub が公式に支援する OSS である点も重要だ。これは個人の野心プロジェクトではなく、「コードホスティングのデファクト企業が、コーディングのデファクト方法論を提案している」という構造的なシグナルである。Microsoft / GitHub エコシステムは Spec-Kit を起点に、Copilot・Codespaces・Actions と統合した「仕様駆動 DevOps」へ向かっている。

Spec-Kit PDF page 3 — Spec-First Rediscovery · 矢印の向きを逆にする

Spec-Kit PDF page 4 — Source of Truth · 仕様こそ真実

CHAPTER 3 · THE 4-COMMAND WORKFLOW

4 つのスラッシュコマンドが意図を実装まで運ぶ — `/specify` → `/plan` → `/tasks` → `/implement`

Spec-Kit の中核は、わずか 4 つのコマンドで構成される直列ワークフローだ。各コマンドは独立した Markdown 成果物を生成し、次のコマンドの入力になる。仕様 → 計画 → タスク → 実装と、抽象度が段階的に降りていく構造である。

抽象度の階段を降りる — 各ステップが独立した Markdown 成果物を残す

優れた建築は、設計図 → 構造計算 → 工程表 → 施工の順で進む。Spec-Kit は同じ階段をソフトウェアに敷く。「なぜ作るのか」「何を作るのか」「どう作るのか」「何をするのか」 を分離し、それぞれを Markdown ファイルとして版管理可能にする。

/specify

何を作るか (WHAT)

ユーザーストーリーと受入条件を構造化。ビジネス要件と非機能要件を分離して記述。

→ spec.md

/plan

どう作るか (HOW)

技術選定・アーキテクチャ・データモデル・API 設計を仕様から導出。テスト戦略も明示。

→ plan.md

/tasks

何をするか (TASKS)

計画を粒度の揃った実行可能タスクへ分解。依存関係と完了定義を明示する。

→ tasks.md

/implement

実装 (CODE)

AIエージェントがタスクを順次消化し、仕様に 逆引きできる コードへ翻訳する。

→ source code

# 1. 初期化 (uvx で取得)
uvx --from git+https://github.com/github/spec-kit.git specify init my-project

# 2. AI エージェント内で 4 コマンドを順次実行
/specify  → spec.md  : ユーザーストーリーと受入条件を構造化
/plan     → plan.md  : 技術選定・アーキテクチャを仕様から導出
/tasks    → tasks.md : 実行可能タスクへ分解 (依存関係明示)
/implement → コード  : エージェントが順次タスクを消化

# 3. 変更は仕様から: コードではなく spec.md を編集 → /plan 再実行
git commit -m "spec: ユーザーログインに 2FA 要件を追加"

Spec-Kit PDF page 5 — /specify · ユーザーストーリーと受入条件

Spec-Kit PDF page 6 — /plan · 技術選定と非機能要件

Spec-Kit PDF page 7 — /tasks · 実行可能タスクへ分解

Spec-Kit PDF page 8 — /implement · AIエージェントによる実装

CHAPTER 4 · CONSTITUTION

Constitution.md — プロジェクトの「憲法」が AI の暴走を防ぐ

Spec-Kit のもうひとつの中核が 「Constitution.md(憲法)」。プロジェクト固有の 不変条件 — テスト戦略、コード規約、セキュリティ要件、デプロイ制約 — を宣言的に記述し、すべてのコマンドが暗黙にこれを参照する。「許可なき自由」ではなく「制約された自律」を実現する仕組みだ。

AI の「自由」を制約することで、本物の生産性が生まれる — ガードレールの設計学

AI に「ベストプラクティスで作って」と頼むと、20 種類のベストプラクティスから 1 つを勝手に選んでくる。Constitution.md は 「このプロジェクトでは Test-Driven、Postgres 必須、認証は OIDC、CI は GitHub Actions」と 1 度だけ宣言する。以後、すべての /plan と /implement は自動的にこの制約を満たす。

Constitution は単なる README ではない。それは 「実行可能なポリシー」であり、エージェントが計画段階で 必ず参照しなければならない 拘束力を持つ。プロジェクトに新しいメンバー（人間 or AI）が参加した瞬間、Constitution を読むだけでチームの「文化」が伝わる。

# constitution.md (抜粋)
## Testing
- すべての PR は単体テストカバレッジ 80% 以上
- TDD 必須: テストを先に書く

## Security
- 認証は OIDC 経由のみ
- 入力検証は Zod スキーマで型レベル保証

## Style
- TypeScript strict mode
- Prettier + ESLint Airbnb準拠

Pillar 1

Quality Gate

テスト戦略・カバレッジ・レビュー基準。AIが勝手にテストを省略しない。

Pillar 2

Security Default

認証・認可・データ保護の最小要件。新機能でも自動で適用される。

Pillar 3

Style & Stack

採用言語・FW・コード規約。プロジェクト全体の一貫性をエージェントが保証。

Pillar 4

Operational

デプロイ・観測性・SLO。本番運用の文脈を計画段階から織り込む。

Spec-Kit PDF page 9 — Constitution.md · プロジェクト憲法の4本柱

Spec-Kit PDF page 10 — Quality Gate · AIの「自由」を制約する設計

CHAPTER 5 · MULTI-AGENT FUNGIBILITY

同じ仕様で Copilot / Claude / Cursor / Gemini が動く — エージェントロックインの解消

「このプロンプトは Cursor でしか動かない」「Claude Code 用のコンテキスト構築を Copilot で再現できない」— これらの問題が解消する。Spec-Kit の Markdown 仕様は エージェント中立 な記述形式であり、4 主要エージェントが同じ仕様ファイルを読んで実装できる。

Agent 1

GitHub Copilot

VS Code / JetBrains ネイティブ統合。Workspace モードで spec.md を参照しタスク実装。

Agent 2

Claude Code

CLI / SDK。Skills や Managed Agents と組み合わせて長時間自律稼働。

Agent 3

Cursor

エディタ統合。Composer モードで複数ファイル横断の仕様準拠実装。

Agent 4

Gemini CLI

ターミナル統合。Jules 連携で対話型実装。1M トークン文脈で大規模仕様も処理可能。

仕様駆動の真価は「エージェントを切り替えられる自由」— ベンダーロックインの逆転

軸	Vibe Coding (プロンプト工学)	Spec-Kit (仕様工学)
意図の所在	チャット履歴に散在	spec.md に集約
再現性	同じプロンプトでも結果が異なる	同じ仕様 → 一貫した実装
エージェント切替	プロンプトを書き直す必要あり	同じ仕様で別エージェントが動く
ガバナンス	個人の暗黙知	Constitution.md による明示宣言
変更管理	パッチを重ねる	spec を編集 → 再生成
レビュー対象	コード差分のみ	仕様差分 + コード差分

エージェントロックインの解消は、単なる利便性ではなく 「組織の交渉力(Bargaining Power)」 を取り戻すこと。仕様が資産であれば、エージェント提供者を切り替えてもプロジェクトは継続する。これはエンジニアリング組織にとって戦略的な選択肢の保持である。

Spec-Kit PDF page 11 — Multi-Agent Fungibility · 4 エージェント横断対応

Spec-Kit PDF page 12 — Vibe vs Spec · 戦略的比較表

CHAPTER 6 · REALITY CHECK

銀の弾丸ではない — Spec-Kit が向かない場面とトレードオフ

Spec-Driven は強力だが、誇張は禁物だ。仕様を書く前提コストは確実に存在し、すべてのプロジェクトに最適とは限らない。導入前に 3 つの現実的な制約を理解しておくべきである。

Cost 1

仕様メンテナンスコスト

仕様とコードを同期し続ける運用が必要。Drift（乖離）が起これば仕様の信頼が崩れる。CI で spec-drift check を入れる発想が必須。

Cost 2

学習曲線

「とりあえず動かす」までの時間は 長くなる。試作・スパイク・hackathon では Vibe Coding が今も合理的。Spec-Kit は本番運用フェーズで真価を発揮する。

Cost 3

仕様の表現力

Markdown 自然言語の曖昧さは残る。「ユーザーフレンドリーな UI」 は仕様にならない。具体的な受入条件 (Given/When/Then) で表現する技術が必要。

適材適所のフレーム — Spec-Kit を「いつ使うか」

Spec-Kit は 「複数人 × 長期運用 × 規制業界」の組み合わせで価値が指数的に増す。逆に、1 人で 1 日のスパイクなら spec.md を書く時間が短納期の敵になる。プロジェクトのフェーズと規模を見極めることが、ツールチョイスの本質だ。

シナリオ	推奨アプローチ	理由
個人プロトタイプ・PoC	Vibe Coding (素のCopilot/Cursor)	仕様コストが学びの速度を阻害
本番運用 SaaS	Spec-Kit 必須	仕様 = レビュー対象 + 監査証跡
規制業界 (金融/医療)	Spec-Kit + Constitution 強化	監査・コンプライアンスを仕様化
OSS ライブラリ	Spec-Kit (軽量運用)	外部コントリビュータが意図を理解可能
研究プロジェクト	Vibe Coding	仮説変更が頻繁すぎて仕様が陳腐化

Spec-Kit PDF page 13 — Reality Check · 適材適所のフレーム

CHAPTER 7 · FROM VIBE TO ENGINEER

結末—「AIに書いてもらう」から「AIと協働でエンジニアリングする」へ

Spec-Kit は単なる新ツールではない。「AI とどう協働するか」のメタ的な再設計である。プロンプトから仕様へ、暗黙知から明示知へ、個人の技から組織の資産へ — このシフトは、AI コーディング時代の 第二期 の始まりを告げる。

仕様こそが資産 — 「コードは仕様の偶発的副産物」を真に受け止める

2026 年、AI コーディングの第一期（プロンプト工学）が終わろうとしている。次に来るのは、仕様という古い概念を新しい意味で蘇らせる時代だ。人間は意図を構造化し、AI は構造化された意図を実装する。両者の責任が、ようやく明確に分かれる。

これは「人間の仕事が減る」のではなく、「人間の仕事が変わる」。書くべき行は減り、設計すべき意図は増える。エンジニアという職能は、コードを書く存在から、「意図を構造化する存在(Intent Architect)」 へ進化する。Spec-Kit はそのための最初の標準ツールだ。

“

「コードは仕様の偶発的副産物である」—
この 1990 年代の真理を、AI コーディング時代に再武装すること。それが Spec-Kit のすべて。

— Engineering Intent with GitHub Spec-Kit · 2026 / 05 / 11

Spec-Kit PDF page 15 — From Vibe to Engineer · 第二期 AI コーディングへ