2時間 Vibe Learning

SPEC駆動開発を、2時間で「使える」ところまで

AIエージェントに「いい感じに作って」と頼むのをやめて、仕様（SPEC）を一次成果物にする開発の型を身につけます。読むだけで終わらせず、最後にあなた自身の機能1つ分の spec.md / plan.md / tasks.md を書き上げて持ち帰ります。

2時間のタイムテーブル

ゴール：SDDが「ドキュメントを厚く書く手法」ではないことを、自分の言葉で説明できる。

1-1. 一番の誤解を先に潰す

この逆転が効くのは、AIエージェントがコードを書く速度が上がったからです。生成が速くなるほど、ボトルネックは「書く速度」ではなく「何を作るべきかの合意の精度」に移ります。曖昧な意図を渡せば、AIは曖昧なまま高速に大量のコードを書いてしまいます。

1-2. 中心にあるのは「What before How」

SDDが徹底するのは、「何を・なぜ作るか」と「どう作るか」を分離することです。この分離が崩れると、仕様が特定の実装手段に過剰適合し、後から技術を変えられなくなります。

1-3. もうひとつの柱「multi-step refinement」

SDDは仕様から一気にコードを生成しません。段階的に精緻化します。各段階で人間がレビューできる中間成果物が残ることが重要で、これが「AIが何を根拠にそのコードを書いたか」の追跡可能性を生みます。

出典 ── What is Spec-Driven Development? — GitHub Spec Kit https://github.github.com/spec-kit/concepts/sdd.html ／ GitHub Spec Kit https://github.github.com/spec-kit/

ゴール：短縮フローと本番フローの違い、各ステップの責務を説明できる。

2-1. まず覚える最小フロー

要求を仕様化し、技術設計へ変換し、依存関係を持つ実装タスクへ分解し、実装する。仕様からいきなりコードへ飛ばないのが要点です。

2-2. 本番向けフロー（品質ゲート付き）

実際にプロダクトへ適用する場合、Spec Kit のフローは4ステップでは終わりません。間に実装前に仕様の欠陥を潰すゲートが入ります。

黄色が品質ゲート。Clarify / Checklist / Analyze は実装前、Converge は実装後に効きます。

2-3. 別実装でもほぼ同じ構造になっている

これはSpec Kit固有のローカルルールではありません。独立した実装である Kiro も、同型の多段階構造を採用しています。2つの独立した実装が同じ形に収束していることは、この構造が本質的である傍証として重要です。

出典 ── Quick Start Guide — Spec Kit https://github.github.com/spec-kit/quickstart.html ／ Agentic SDD — Spec Kit https://github.github.com/spec-kit/reference/agentic-sdd.html ／ Feature Specs — Kiro https://kiro.dev/docs/specs/feature-specs/ ／ Best practices — Kiro https://kiro.dev/docs/specs/best-practices/

ゴール：曖昧さのない、テスト可能な要求を書けるようになる。ここが2時間で最も価値のある30分です。

3-1. SPECの骨格

GitHubが実際にAIへ与えている spec-template.md は、以下の要素で構成されています。抽象論を読むより、この構造をそのまま使うのが最短です。

3-2. EARS ─ 曖昧でない要求を書く記法

「速い」「大きい」「適切に処理する」といった解釈の余地が大きい表現を避けるために、条件・トリガー・期待動作を型にはめて書くのがEARS（Easy Approach to Requirements Syntax）です。2009年の原著論文で提示され、現在のKiroでもテスト可能な要求記述に使われています。

# 悪い例
検索は速くなければならない。エラー時は適切に処理すること。

# EARSで書き直した例
FR-001  When the user submits a search query,
        the system shall display the result list within 2 seconds.

FR-002  If the search service is unavailable,
        then the system shall display a retry option
        and preserve the entered query.

FR-003  While the user is not signed in,
        the system shall hide the saved-search menu.

If the selected file exceeds 20 MB,
then the system shall reject the upload
and shall display the maximum allowed size.

While the device has no network connection,
the system shall allow viewing of previously loaded documents
and shall queue edits for later synchronisation.

Where the signed-in user holds the administrator role,
the system shall display the audit log and the billing status
on the account detail screen.

出典 ── spec-template.md — Spec Kit https://github.com/github/spec-kit/blob/main/templates/spec-template.md ／ EARS — Alistair Mavin https://alistairmavin.com/ears/ ／ Easy Approach to Requirements Syntax (EARS) — IEEE (2009) https://ieeexplore.ieee.org/document/5328509/ ／ Feature Specs — Kiro https://kiro.dev/docs/specs/feature-specs/

ゴール：コードではなく要求仕様をレビュー対象にできるようになる。

4-1. なぜ実装前にレビューするのか

曖昧な仕様のまま実装させると、AIは曖昧さを勝手に埋めてコードを書きます。埋め方が意図と違っていた場合、発見できるのは実装が全部終わった後です。Spec Kit の clarify / checklist / analyze、Kiro の Analyze Requirements は、この手戻りを実装前に潰すために存在します。

4-2. 何を探すのか（レビュー観点）

機能：チームのタスク共有

FR-001 ユーザーはタスクを作成できる。
FR-002 タスクは高速に一覧表示されなければならない。
FR-003 タスクは作成者だけが編集できる。
FR-004 チームメンバーは誰でもタスクのステータスを更新できる。
FR-005 通知は適切なタイミングで送られる。
FR-006 データはリアルタイムに同期され、オフラインでも全機能が使える。

Success Criteria:
- ユーザーが満足すること
- PostgreSQLのクエリが100ms以内で返ること

出典 ── Agentic SDD — Spec Kit https://github.github.com/spec-kit/reference/agentic-sdd.html ／ Analyze Requirements — Kiro https://kiro.dev/docs/specs/analyze-requirements/ ／ ISO/IEC/IEEE 29148:2018 https://www.iso.org/standard/72089.html

ゴール：仕様と技術設計の境界を引き、AIエージェントが実行できる粒度までタスクを割れる。

5-1. どこからがPlanの領分か

plan-template.md が扱うのは、仕様から意図的に排除した「HOW」です。この境界表を頭に入れておくと、仕様に実装詳細が混入したときすぐ気づけます。

5-2. タスクは「TODOリスト」ではない

tasks-template.md のタスクは、AIエージェントが独立して実行できるように、以下の情報を持ちます。

• どのUser Storyに対応するか（トレーサビリティ）
• 依存関係（何が終わっていれば着手できるか）
• 並列実行できるか（[P] マーク）
• 変更対象のファイルパス
• 独立してテスト可能か

並び順にも構造があります。

Setupはプロジェクト初期化、Foundationalは複数ストーリーが共通で必要とする土台。その後はUser Story単位で並べます。こうすると「P1のストーリーまで実装した時点で、単体で価値が検証できる」状態が作れます。

## Phase 1: Setup
T001  プロジェクト構成とlint設定を追加   files: package.json, .eslintrc

## Phase 2: Foundational
T002  Tagデータモデルを定義              files: src/models/tag.ts
T003  タグ永続化層を実装 (depends: T002) files: src/repo/tagRepo.ts

## Phase 3: User Story 1 (P1) — 記事にタグを付ける
T004 [P] タグ付与APIを実装 (depends: T003)  files: src/api/tags.ts
T005 [P] タグ表示UIを実装 (depends: T003)   files: src/ui/TagList.tsx
T006  受け入れシナリオ AS-1 の結合テスト (depends: T004, T005)
      → ここまでで US-1 が独立に検証可能

出典 ── plan-template.md — Spec Kit https://github.com/github/spec-kit/blob/main/templates/plan-template.md ／ tasks-template.md — Spec Kit https://github.com/github/spec-kit/blob/main/templates/tasks-template.md ／ Agentic SDD — Spec Kit https://github.github.com/spec-kit/reference/agentic-sdd.html

ゴール：テストが緑になっただけでは終わりではない理由を説明できる。

6-1. テスト成功では足りない

6-2. 2つのアプローチ

# EARS要求
FR-002  If the search service is unavailable,
        then the system shall display a retry option
        and preserve the entered query.

# ここから取り出せるプロパティ
Property: サービス停止時、どんな入力クエリ文字列に対しても、
          再試行UIが存在し、かつ入力値が保持されている
          → クエリ文字列をランダム生成して総当たりで検証できる

出典 ── Agentic SDD — Spec Kit https://github.github.com/spec-kit/reference/agentic-sdd.html ／ Correctness with Property-based tests — Kiro https://kiro.dev/docs/specs/correctness/

ゴール：SDDを実務に持ち込むときに壊れやすい箇所を、事前に知っておく。

7-1. 仕様はいつまで「真実」なのか ─ Spec Persistence Models

実装中には必ず発見があります。「仕様に書いていなかったことが必要だった」「書いたとおりに作ると破綻する」。そのとき仕様をどう扱うかには複数のモデルがあり、Spec Kit はこれを整理しています。

7-2. 要件が変わったときの再同期

既存プロジェクトで要件が変わったら、下流の成果物も順番に更新し直します。この順序を守らないと、タスクだけが古い仕様を参照した状態になります。

7-3. Brownfieldでは仕様だけでは足りない

既存リポジトリへSDDを適用すると、仕様には書かれない文脈──既存API、アーキテクチャ、命名規則、社内の慣習──が不足します。2026年の研究でも、SDDエージェントをリポジトリ情報で明示的にgrounding（接地）することの重要性が検証されています。実務では「仕様＋リポジトリの文脈」をセットで渡す前提で考えてください。

7-4. 過信しないための限界

出典 ── Spec Persistence Models — Spec Kit https://github.github.com/spec-kit/concepts/spec-persistence.html ／ Evolving Specs in Existing Projects — Spec Kit https://github.github.com/spec-kit/guides/evolving-specs.html ／ ISO/IEC/IEEE 29148:2018 https://www.iso.org/standard/72089.html ／ Spec Kit Agents: Context-Grounded Agentic Workflows https://arxiv.org/abs/2604.05278（preprint）／ From Prompt to Process https://arxiv.org/abs/2606.04967（preprint）／ Citation Discipline in Spec-Driven Development https://arxiv.org/abs/2606.30689（preprint）

ゴール：あなたの機能1つ分の Spec Pack を書き出して持ち帰る。

最終チェックリスト

この後やること（持ち帰り3つ）

1. 書いたSpec Packを実際のプロジェクトに置き、AIエージェントにP1のタスクだけ実装させる。
2. 実装が終わったら、コードではなく仕様と突き合わせてギャップを確認する。
3. チームで Flow-back / Flow-forward / Living Spec のどれを採るか合意する。

参考資料

この教材が根拠にした一次情報。★は最初に読むべきもの。

この教材は上記の一次情報のみを根拠に構成されています。情報は2026年8月14日時点のものです。ツールのフローやテンプレートは更新されるため、実務適用時は公式ドキュメントで最新版を確認してください。