自身がSpec kit（GitHub公式のOSS仕様書駆動開発キット）を使い始めるにあたって、インストール手順の記事は見かけるものの、インストール後の利活用について全体感の把握に時間を要したため、自身で振り返るように纏めました。このため、筆者は数時間、Spec kitを触ってみた程度です。
想定読者：
- ChatGPT / Gemini / GitHub Copilot などのAIチャットは触ったことがある
- ウォーターフォール開発や実装経験がある
- 仕様書駆動開発は初めて、Kiro / Spec kit も未経験
本記事は、Spec kitを最短で使い始めるための「何をする/いつ使う/どの粒度で回す」をサクッと把握できる超入門です。最後に通常の実行順と実行単位をPlantUML図で掲載します。
このガイドでわかること
- 各コマンドの役割（何をする/いつ使う/どの粒度で回す）
- 最短で使い始める5ステップ（MVP想定）
- 実行順と実行単位の定石（小さく速く回す）
- ウォーターフォール工程との読み替え（要件定義/設計/実装/テスト）
最短で始める5ステップ（まずはMVPだけ）
- /constitution でプロダクトの憲法（価値/対象/非対応/成功指標）を固定
- /specify で今回作る範囲（MVP）の仕様を数値とDoD付きで確定
- /plan で実装の骨格（構成/最小ループ/CI）を決める
- /tasks でWBS化（1〜4h/タスク、依存/見積/DoD/テスト観点）
- /implement をタスク単位で反復 → テスト → tasks.mdにチェック
コマンド早見表
/constitution
- 何をする：プロダクトの“憲法”。価値・対象ユーザー・非機能方針（やらないこと）・成功指標を定めます。
- いつ：一番最初。以後は大方針変更がある時だけ。
- 粒度：ドキュメント1本（大きめ）。
/specify
- 何をする：仕様（ユーザー体験・UI・業務/動作ルール・主要数値・MVP境界）を言語化。
- いつ：/constitution の後。各フェーズの開始前に「今作る範囲」を確定。
- 粒度：機能ブロック単位（MVP全体／M2=敵AI など）。
- コツ：技術用語を避け、数値やDoD（受け入れ条件）を入れると後工程が安定。
/plan
- 何をする：どう作るか（技術選定・フォルダ構成・最小ループ・CI）。
- いつ：/specify 直後。骨格を先に固定して迷走を防止。
- 粒度：プロジェクト骨格（1本）。必要に応じて部分更新OK。
/tasks
- 何をする：WBS化（優先度/依存/見積/DoD/テスト観点）。
- いつ：/plan の後。実装に着手する前。
- 粒度：タスク単位（M1-1, M1-2 …）。
/implement
- 何をする：タスクをコードとして実装。/tasks のDoDに沿って開発。
- いつ：実際に手を動かす時。M1→M2→M3…と反復。
- 粒度：タスク単位（推奨）または小さな束（例：M1最小ループ一括）。
（補助）/clarify
- 目的：不明点・前提・制約・外部依存を洗い出し、仮説/選択肢/推奨/意思決定を明確化。
- いつ：/specify の直前・直後、または進行中に曖昧さでブロックされる時。
（補助）/analyze
- 目的：変更点の要約、影響領域・依存関係、リスク、テスト観点を整理。
- いつ：/implement 前、既存資産の変更や回帰が疑われる時。
実行“順”の定石（最小で回す）
- /constitution
- /specify（数値・DoD付きで仕様確定）
- /plan
- /tasks
- /implement（小刻みに反復）
- （手動）動作確認/テスト → tasks.md 更新
- 必要なら /specify → /implement 再反復
- MVP達成後に最適化/デプロイ
実行“単位”の目安
- 初回だけ大きく：/constitution → /specify(MVP) → /plan → /tasks
- 以降は小さく速く：
-
/specify（対象フェーズだけ） →/tasks（追加分だけ） →/implement（タスク単位） - 1タスク＝1〜4h相当が安定（各タスクにDoD/テスト観点を含める）
-
Spec kit 通常フロー（WF対比付き）
用語ミニ辞典（30秒）
- DoD（Definition of Done）: 観測可能な受け入れ条件
- MVP（Minimum Viable Product）: 最小実用のプロダクト
- WBS（Work Breakdown Structure）: 作業分解。1〜4hが安定
- E2E（End-to-End）: 画面〜API〜DBまでを通して動作確認
プロンプト例（最小セット）
/constitution
/constitution
プロダクト名: TeamBoard
対象ユーザー: 5〜50名の開発チーム
提供価値: 1〜4h粒度のタスク運用と軽量DoDで高速反復
非対応: SSO, 多言語, 高可用性
成功指標: 週3回以上のデイリー完了率60%
/specify
/specify M1
範囲: ログイン、ボード作成、タスクCRUD
UI要件: モバイル対応、主要操作はアイコン+ラベル
主要数値: タスクタイトル100字、検索 <300ms
DoD: タスク追加/更新/削除がE2Eで成功
/plan
/plan M1
技術選定: React + Node/Express + SQLite
構成: モノレポ構成、eslint+prettier+vitest
最小ループ: ログイン→タスク追加→一覧反映
CI: pushでlint/test, mainマージでプレビュー
/tasks
/tasks M1 をWBS化
T001 ログイン画面
依存: なし / 見積: 3h
DoD: 未ログインで/loginへ、成功で/homeへ
テスト: E2E成功/失敗
/implement
/implement T001
DoD: ログインフォームが動作しE2Eが成功