GitHub Spec Kit を導入する利点

本記事の前提となる Craft ERP（生成AI × 仕様駆動開発による小売業向け基幹業務システムの開発プロジェクト）の概要・目的・技術選定方針は Craft ERP Overview にまとめています。なお Craft ERP での Spec Kit の本格的な採用評価は今後行う段階で、本記事は「導入の利点」の整理です。

0. 位置づけ（前提）

Craft ERP は、Spec Kit 導入以前から生成AI × 仕様駆動開発を実践しています。要件定義・設計・Markdown による仕様管理・GitHub での変更管理・AGENTS.md 運用・Notes 運用などを進める中で、運用上の課題や改善点が見えてきました。

GitHub Spec Kit は、その「すでに進めている仕様駆動開発」を支援・改善するために調査・導入したツールです。つまり本記事の主役は生成AI × 仕様駆動開発であり、Spec Kit はそれを始めるための出発点ではなく、支える支援ツールという位置づけで読んでください。

1. 結論

GitHub Spec Kit を導入する最大の利点は、AI への指示をその場限りのプロンプトで終わらせず、仕様・計画・タスク・実装を連続した開発プロセスとして管理できることです。特に次の状態を作りやすくなります。

• 実装前に「何を作るか」「なぜ作るか」を明確にする
• 曖昧な要件を、計画や実装に入る前に洗い出す
• 仕様から技術計画、タスク、実装までを一貫させる
• AI が参照すべき情報を Markdown ファイルとして残す
• 仕様・計画・コードの不整合を確認する
• Codex、Claude Code など複数の AI コーディングエージェントを同じ開発方式で利用する
• 開発ルールや品質基準を、プロジェクト全体へ継続的に適用する

ただし、Spec Kit を導入しただけで仕様が自動的に正しくなるわけではありません。仕様を更新する運用、生成物をレビューする工程、テストによる検証は引き続き必要です。

2. GitHub Spec Kit とは

GitHub Spec Kit は、仕様駆動開発（Spec-Driven Development: SDD）を実践するためのオープンソースのツールキットです。通常の AI コーディングでは会話欄へ直接「この機能を作って」と依頼してそのまま実装へ進みがちですが、Spec Kit では実装前に次の成果物を段階的に作成します。

• プロジェクト原則 → 機能仕様 → 技術計画 → 実装タスク → 実装結果

各段階の成果物は Markdown として保存され、次の工程で AI へ渡す構造化されたコンテキストになります。基本フローは次のとおりです。

constitution
    ↓
specify
    ↓
clarify
    ↓
checklist
    ↓
plan
    ↓
tasks
    ↓
analyze
    ↓
implement

小規模な試作では、次の簡易フローも利用できます。

specify → plan → tasks → implement

3. 導入すると何ができるようになるか

4. 具体的にどう便利になるか

4.1 AI への指示が属人的になりにくい

Spec Kit を使わない場合、仕様や注意点が会話履歴・個人の記憶・複数のプロンプトへ分散しがちです。Spec Kit ではプロジェクト原則・機能仕様・技術計画・タスクがファイルとして残るため、AI が参照すべき情報を共有しやすくなります。情報の置き場所が明確になり、担当者や AI ツールが変わっても作業を再開しやすくなります。

4.2 「要件」と「実装方法」を分けて考えられる

specify では利用者に何を提供するか・どんな結果が必要かを整理し、技術スタックや内部設計は後続の plan で扱います。この分離により、技術的に作りやすいものへ要件が引っ張られることを防ぎやすくなります。

4.3 曖昧なまま実装へ進むことを防ぎやすい

AI は曖昧な部分が残っていても、それらしい前提を補って実装することがあります。clarify と checklist を入れることで、対象ユーザー・異常系・権限/セキュリティ・性能/データ量の前提・完了条件・既存機能との関係などを実装前に確認できます。

4.4 大きな作業を管理可能な単位へ分解できる

tasks は技術計画を実装可能な単位へ分解します。これにより AI が一度に広範囲を変更することを避け、実装順序・並行作業・依存関係・テスト対象・完了区分・Issue との対応を管理しやすくなります。

4.5 実装前に整合性を確認できる

analyze は仕様・計画・タスク間の不整合（要件がタスクに未反映、計画のセキュリティ対策がタスクに無い、仕様にない機能の追加、テスト不足など）を発見しやすくします。

4.6 AI ツールを変更しても開発方式を維持できる

Spec Kit は Codex CLI、Claude Code、GitHub Copilot など 30 以上の AI コーディングエージェントに対応しています。重要なのは AI モデルを固定することではなく、仕様と開発プロセスを固定することです。同じ仕様とタスクを基準に、異なる AI へ作業を引き継げます。

4.7 開発ルールを毎回説明しなくてよくなる

constitution には「仕様を唯一の信頼できる情報源とする」「データ変更には根拠と監査可能性を持たせる」「過剰な抽象化を避ける」「テストなしで完了としない」「AI 生成コードを無条件で採用しない」などの原則を定義できます。AI が継続的に参照できるため、会話ごとの指示漏れを減らせます。

5. 導入前後の違い

6. 作成される成果物の役割

代表的な成果物は次のとおりです（実際の構成はバージョン・Integration・Preset・Extension により変わる場合があります）。

.specify/
├── memory/
│   └── constitution.md
├── templates/
└── scripts/

specs/
└── 001-feature-name/
    ├── spec.md
    ├── plan.md
    ├── tasks.md
    └── その他の補助資料

7. 既存プロジェクトでも使えるか

Spec Kit は新規開発だけでなく、既存プロジェクトの機能追加や改修にも利用できます。公式ドキュメントでは既存仕様を維持する考え方として主に次の3方式が示されています。

仕様を SSOT として扱いたいプロジェクトでは、基本は Living Spec が理解しやすい方式です。変更の証跡を厳密に残す必要がある機能では Flow-Forward Spec が適する場合があります。

8. Craft ERP へ導入する場合の利点

Craft ERP には既にプロジェクト定義書・DB 設計書・API 仕様書・セキュリティ方針・開発ガバナンス・AGENTS.md・Notes・GitHub Issues 運用といった資産があります。そのため Spec Kit はゼロから開発方法を作るためではなく、既存の方針と仕様を、AI が実装へつなぐ標準工程として補強する用途に向いています。

既存文書をすべて Spec Kit へ置き換える必要はありません。全体文書（定義書・設計書）と機能単位の仕様（spec/plan/tasks）を分け、重複を避けることが重要です。

相性がよい点: 仕様を Markdown と Git で管理する方針に合う / SSOT 重視の思想に合う / Codex と Claude Code の併用を標準化できる / Issue 駆動の実装へつなげやすい / 追跡性を高められる / AI が勝手に前提を補うリスクを抑えやすい / 将来のチーム開発や監査へ発展させやすい。

9. 導入時の注意点

• 文書が増える — 小さな修正にフル工程を適用するとコード変更より文書作成が重くなる。軽微な変更は簡易フロー、影響の大きい機能だけ全工程を通す。
• AI が作った仕様もレビューが必要 — AI は自然な文章に整えられても、業務上正しい要件を保証できない。業務運用・例外処理・法務/セキュリティ・更新根拠・将来変更耐性を人が確認する。
• 仕様とコードは自動同期しない — コードだけ変えると乖離する。「仕様→計画→タスク→analyze→実装・テスト」の順を基本とし、実装中の発見は仕様/計画へ戻す。
• バージョン更新が速い — 無条件追従せず、使用バージョンを固定して更新内容を確認してから上げる。2026年6月18日時点の最新安定版は v0.11.1。
• Community Extension は公式本体と同じ扱いにしない — 配布元・ソース・更新状況・実行スクリプト・外部通信・書き換え範囲・ライセンスを導入前に確認する。

10. 推奨する導入方法

最初から全機能へ適用するより、1 つの独立した機能で試行する方が適切です。

• 第1段階: 小規模な機能（CSV 取込、棚卸差異登録、権限別画面制御、操作ログ等）でフル工程を試す。
• 第2段階: 現行文書との重複を確認する（constitution と定義書、spec と API 仕様書、plan と恒久設計書、tasks と Issue が二重管理になっていないか）。
• 第3段階: 運用ルールを決める（どの規模から使うか、Living/Flow-Forward のどちらを基本にするか、仕様承認者、Issue 化のタイミング、完了時レビュー、アップグレード担当と頻度）。

Craft ERP では「基本は Living Spec、監査対象は Flow-Forward、軽微な修正にフル工程を強制しない、Claude Code を主な実装パートナーとし、ChatGPT を設計・技術評価の相談役、Codex を実装補助に使い分け、最終判断は仕様・テスト・人のレビューで行う」運用が適しています（→ AI Development Workflow）。

11. まとめ

GitHub Spec Kit は、AI にコードを書かせるためだけのツールではありません。導入の本質は次の3点です。

• AI へ渡す前提を、仕様として明示する
• 仕様、計画、タスク、実装をつなげる
• AI や担当者が変わっても、同じ判断基準を維持する

Craft ERP のように定義書・設計書・GitHub Issues・AI コーディングエージェントを既に活用しているプロジェクトでは、Spec Kit は既存資産を置き換えるものではなく、機能単位の仕様から実装までを標準化する層として導入するのが適切です。まずは 1 機能で試し、重複・作業量・仕様精度・手戻り削減効果を確認したうえで適用範囲を広げるのが安全です。

参考資料

• GitHub Spec Kit 公式ドキュメント
• GitHub Spec Kit 公式リポジトリ
• GitHub Spec Kit Releases