GitHub Spec Kit 評価

本記事の前提となる Craft ERP（生成AI × 仕様駆動開発による小売業向け基幹業務システムの開発プロジェクト）の概要・目的・技術選定方針は Craft ERP Overview にまとめています。

1. 導入背景

Craft ERP は「生成AI × 仕様駆動開発（SDD）」を中核に据えます。通常の AI コーディングは会話欄に「この機能を作って」と依頼してそのまま実装に進みがちで、次の課題がありました。

• 何を・なぜ作るかが曖昧なまま実装が進む
• 指示がその場限りで、判断や前提が残らない
• 複数の AI エージェントで開発方式がばらつく

これを解消する枠組みとして GitHub Spec Kit を導入しました。

2. Spec Kit とは（要点）

仕様駆動開発を実践するための OSS ツールキット。実装前に成果物を段階的に作ります。

• プロジェクト原則 → 機能仕様（/specify）→ 技術計画（/plan）→ 実装タスク（/tasks）→ 実装結果
• 各成果物は Markdown として残り、次工程で AI へ渡す構造化コンテキストになる。
• Claude Code / Codex など複数の AI エージェントを同じ方式で扱える。

3. 評価（調査項目別）

4. メリット

• 実装前に「何を・なぜ作るか」を固められ、手戻りが減る
• 判断・前提が Markdown として残り、後から再評価できる
• 複数の AI コーディングエージェントを同じ開発方式で使える
• 開発ルール・品質基準をプロジェクト全体へ継続適用しやすい

5. デメリット / 注意点

• 導入しただけでは仕様は正しくならない — 仕様更新の運用、生成物のレビュー、テストによる検証は引き続き必要
• 小さな変更や試行錯誤フェーズには、工程がオーバーヘッドになりうる
• コマンド・ワークフローの学習コストがかかる
• 仕様とコードの乖離を放置すると、かえって混乱を生む（生きたドキュメント維持が前提）

6. Craft ERP での利用結果

• 機能追加を /specify → /plan → /tasks の流れで進め、実装前に要件の曖昧さを洗い出せた。
• 仕様・計画が残るため、Claude Code / Codex の双方に同じ前提を渡せた（→ AI Development Workflow）。
• ごく小さな修正では全工程を回さず、軽量に扱う運用に落ち着いた（工程の濃淡を使い分ける）。

7. 継続利用判断

• 継続利用する。生成AI × 仕様駆動開発の骨格として有効で、Craft ERP の方針と一致する。
• 運用方針: 変更規模に応じて工程の濃淡を使い分け、仕様の更新・レビュー・テストをセットで回す。
• 学習・運用コストは、判断履歴が残る価値と複数 AI の協調効果で十分に見合う。

8. 将来の再評価条件

• Spec Kit のバージョンアップに伴うコマンド・機能変更
• チーム/エージェント構成の変化（利用する AI が増減した場合）
• 仕様維持コストが実装メリットを上回ると感じられた場合