# 2026年にClaude CodeでSpec Kitを設定する方法：プロンプトではなく仕様
> Claude CodeでGitHub Spec Kitを設定する方法：4つのフェーズ—Specify、Plan、Tasks、Implement。GitHub Spec Kitの公式情報に基づくガイドです。
Source: https://ailoot.ai/blog/ja/spec-kit-claude-code-spec-driven-development/
Canonical: https://ailoot.ai/blog/ja/spec-kit-claude-code-spec-driven-development/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-219
Revision: sha256-6fffbbcc08770010811632d1f0f4b8f31bd368af00c562a098fa5e66e71c237c
重要なポイント
Spec KitはGitHubのツールです。自然言語でタスク仕様を書くと、Claude Codeが計画をまとめ、タスクに分解して、コードを書きます。これは理論ではありません。8か月でGitHubスターを107,000件獲得し、AWSはこの方法論を使って数か月ではなく3週間で創薬プロジェクトを構築しました。このガイドでは、インストール、テンプレート、最終チェックを含むワークフローの4つのフェーズ、そしてCLAUDE.mdとの連携方法を説明します。
[Ailootドキュメント](https://ailoot.ai/docs/) — サービスの使い方に関する参考資料。
## 2026年5月、バイブコーディングに何が起きたのか？
重要なポイント
GitHub Spec Kitは8か月で107,000スターを獲得し、AWSはある機能で80時間以上を削減したと報告する事例研究を発表しました。5月の週ごとのトレンドは、即興に代わる仕様でした。
1年後の2026年2月4日、彼は振り返りのスレッドを公開しました。
Sequoia Ascent 2026での講演では、さらに明確にこう表現しました。「バイブコーディングはソフトウェアで誰もができることの底上げをする。エージェント型エンジニアリングは、プロの開発の品質基準という天井を維持する。」同じステージで、業界の語彙に加わる一言も述べました。「バイブコーディングを理由に脆弱性を持ち込むことは許されない。これまでと同じく、ソフトウェアに対する責任はあなたにある。」
2つの出来事が並行して起きました。2025年9月、GitHubは[Spec Kit](https://github.com/github/spec-kit)ツールを公開し、8か月で107,000スターを獲得しました。2026年2月、AWSは「仕様からビジネスロジックの95%を生成し、80時間以上を削減した」と報告する[詳細な創薬事例](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)を発表しました。
2026年5月末までに、英語圏の情報空間では合意が形成されました。作業方法としてのバイブコーディングは初心者向けの段階であり、その次にSpec-Driven Developmentが来ます。このガイドでは、その導入と適用方法を説明します。
## Spec KitとSpec-Driven Developmentとは？
重要なポイント
Spec-Driven Development（SDD）は、AIエージェントへの従来のアプローチを逆転させます。これまではコードが信頼できる情報源で、仕様は付随する書類でした。今では仕様が信頼できる情報源であり、コードはその最終段階、つまり実装になります。Spec KitはGitHubのCLIツールで、4つのフェーズ（Specify、Plan、Tasks、Implement）と最後のConvergeチェックを、Claude Code、Cursor、Copilot、その他30以上のエージェントですぐ使えるコマンドにします。
この方法論の核となる考え方は、GitHub公式ドキュメントの一文にまとめられています。
Spec-Driven Developmentは階層を変えます。仕様がコードに奉仕するのではなく、コードが仕様に奉仕します。仕様が主要な成果物となり、コードは特定の言語やフレームワークで表現したものになります。
— GitHub Spec Kit Docs、https://github.com/github/spec-kit/blob/main/spec-driven.md
実際には、これは4つのフェーズで進みます（Spec Kitには、後述するconstitutionというゼロ番目のフェーズが追加されています）。
1. **Specify** - 作りたいものの仕様を自然言語で書きます。何をするか、そしてなぜするか。どのようにするかではありません。
2. **Plan** - エージェントが仕様をもとに、技術、アーキテクチャ、コンポーネントをまとめた技術計画を作ります。
3. **Tasks** - エージェントが計画を、依存関係を含む具体的で検証可能なタスクに分解します。
4. **Implement** - エージェント（またはそのサブエージェント）がタスクを進め、コードを書きます。
Implementの後、現行バージョンのSpec KitにはConvergeという検証ステップがあります。エージェントが完成したコードを仕様、計画、タスクと照合し、見落としがあれば`tasks.md`に追加します。Convergeが「Converged」と返すまで、ImplementとConvergeを繰り返します。
各フェーズはリポジトリ内の個別のMarkdownファイルになります。Claude Codeでは各フェーズが個別のスラッシュコマンドです。`/speckit-specify`、`/speckit-plan`、`/speckit-tasks`、`/speckit-implement`を使い、チェックには`/speckit-converge`を使います。Spec Kitのドキュメントでは同じコマンドをドット付き（`/speckit.specify`）で記載していますが、Claude CodeではSpec Kitがスキルとしてインストールされ、ハイフン付きで呼び出します。どの段階でも問題があれば、Markdownファイルを編集して次のフェーズを再実行します。
Spec KitはSDDの具体的な実装の一つです。2026年5月時点で、すでに30以上のAIエージェントとの統合があります。同じリポジトリ内なら、Claude Code、Cursor、GitHub Copilot、Codex CLI、Windsurf、Qwen、Tabnine、Amazon Q、Gemini、Gooseなど、さらに十数種類のエージェントでも同じように動作します。
| Spec Kitのフェーズ | スラッシュコマンド | リポジトリ内の成果物 |
|----|----|----|
| Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` |
| Specify | `/speckit-specify` | `specs/###-feature/spec.md` |
| Clarify（任意） | `/speckit-clarify` | `spec.md`内の編集 |
| Plan | `/speckit-plan` | `specs/###-feature/plan.md` |
| Checklist（任意） | `/speckit-checklist` | 要件品質チェックリスト |
| Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` |
| Analyze（任意） | `/speckit-analyze` | 仕様、計画、タスクのレポート |
| Implement | `/speckit-implement` | プロジェクト内のコード |
| Converge | `/speckit-converge` | 「Converged」の判定、または`tasks.md`内の新しいタスク |
実行後、リポジトリにはコードだけでなく仕様、計画、タスクも含まれます。1か月後にプロジェクトに戻って`spec.md`を読めば、何をしたのか、なぜそうしたのかが分かります。これはもう「バイブコーディングでコードの存在を忘れた」という状態ではなく、プロジェクトの作業記憶です。
## コードを書かないバイブコーダーになぜ必要なのか？
重要なポイント
バイブコーダーの主な悩みは予測できないことです。今日はエージェントが20分で動く機能を作ってくれても、明日は似たタスクでスパゲッティコードを出すかもしれません。Spec Kitは、曖昧なタスクという予測不能の原因を取り除きます。テンプレートを使って仕様を書けば、明確な信頼できる情報源があるため、エージェントは一貫して作業します。さらに、1か月後に戻って確認できる成果物がリポジトリに残ります。
Spec Kitは計画を複数の段階に分け、4つのスラッシュコマンドで形式化します。考える作業と実装を別々にし、それぞれ異なるコンテキストウィンドウで行います。各段階には、前のフェーズで散らかっていない新しいコンテキストが与えられます。
バイブコーダーにとって具体的な利点は3つあります。
- **予測可能性。** エージェントに「メール確認付きの登録フォームを作って」と伝えると、エージェントは自分で10個の詳細を推測し、そのうち3つはあなたの意図と異なるかもしれません。User Stories、Acceptance Scenarios、曖昧な点ごとの`[NEEDS CLARIFICATION]`マーカーを含む`spec.md`があれば、推測する必要がありません。
- **プロジェクトの記憶。** 1か月後には、チャットでエージェントと何を話したか覚えていないでしょう。しかし、`spec.md`、`plan.md`、`tasks.md`はコードとともにリポジトリの`specs/###-feature/`フォルダにあります。何をしたかだけでなく、なぜそうしたのかも分かります。
- **規模への対応。** 1～2ファイルの機能なら差はほとんどありません。20ファイルと5つのデータエンティティを扱う機能なら、「4時間後にすべて書き直す」か「4時間後にすべてがメインブランチに入っている」かの違いになります。AWS KiroはTargetIDプロジェクトで、仕様からビジネスロジックを95%自動化したことを示しました。
バイブコーディングの大きな錯覚は、最初は速く見えることです。30分でプロトタイプができます。しかし1週間もすれば壊れ、捨ててしまうほうが簡単になります。Spec-Driven Developmentは最初に少し時間がかかります（30分ではなく1時間）が、1週間後も同じリポジトリで作業を続けています。
## Claude CodeにSpec Kitをインストールする方法（4ステップ）
重要なポイント
Spec KitはAstralのPythonパッケージマネージャーuvを通じてインストールします。コマンドは1行です。インストール後、リポジトリに移動して`--integration claude`フラグ付きで`specify init`を実行するか、エージェント一覧からClaude Codeを選ぶと、constitution、仕様、計画、タスクのテンプレートと、Claude Code内で使える`/speckit-*`コマンドが揃った構造ができます。uvがすでにインストールされていれば5分、最初からインストールする場合は10分です。
**ステップ1. uvをインストールします。** 一度だけ実行すれば、システムに残ります。
```bash
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```
uvがインストールされたことを確認します。
```bash
uv --version
```
**ステップ2. Spec Kitをインストールします。** コマンドは1つです。
```bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
```
確認します。
```bash
specify --version
```
**ステップ3. リポジトリを初期化します。** プロジェクトフォルダに移動（または新しいフォルダを作成）して、次を実行します。
```bash
specify init --here --integration claude
```
`--integration claude`フラグでClaude Codeを直接選択します。このフラグがない場合、Spec Kitは対話型リストからエージェントを選ぶよう求めます。また、スクリプトの種類を尋ねられる場合もあります（macOSとLinuxでは`sh`のままにします）。フォルダが空でない場合、Spec Kitは既存ファイルと自身のファイルをマージすると警告します。先に作業をコミットしてから、`--force`フラグ付きでコマンドを再実行してください。
その後、リポジトリに次のものが作成されます。
```
.specify/
memory/
constitution.md # プロジェクト規則。/speckit-constitutionが記入
scripts/
templates/
spec-template.md
plan-template.md
tasks-template.md
.claude/
skills/
speckit-constitution/SKILL.md
speckit-specify/SKILL.md
speckit-clarify/SKILL.md
speckit-plan/SKILL.md
speckit-checklist/SKILL.md
speckit-tasks/SKILL.md
speckit-analyze/SKILL.md
speckit-implement/SKILL.md
speckit-converge/SKILL.md
speckit-taskstoissues/SKILL.md
```
**ステップ4. Claude Codeを開いてスラッシュコマンドを確認します。** 同じフォルダで次を実行します。
```bash
claude
```
セッション内で`/speckit`と入力すると、候補に`/speckit-*`コマンドが表示されます。表示されない場合は、Claude Codeを再起動して`.claude/skills/`を読み直させます。プロジェクトのルートにすでに`CLAUDE.md`がある場合、Spec Kitはそのファイルを変更せず、`.specify/memory/constitution.md`で併用します。
Spec KitはClaude Codeなしでも使えます（30以上のエージェントに対応）。ただし、このガイドではClaudeとの設定を扱います。2つのツールをすぐにインストールしたい場合は、[CLAUDE.mdの設定](https://ailoot.ai/blog/ja/claude-md-template/)と[Claude CodeのPlan Mode](https://ailoot.ai/blog/ja/claude-code-plan-mode/)に関する別ガイドを参照してください。
Spec Kitは「エージェントの雇用契約」を構成する最初の要素です。完全なセットアップには3つすべてが含まれます。AIクローン（Skillsとサブエージェントという形のあなたの方法論）、第二の脳（エージェントが毎回参照する`business/`構造）、そしてコンテキストエンジニアリング（Spec Kit、Plan Mode、/compact）です。これらは、AIが幻覚を起こさないための3本柱です。
## 最初の仕様を書く方法（Specify）
重要なポイント
Spec Kitでは機能を自由形式で説明します。するとテンプレートを使って`spec.md`を作成します。そこには優先度P1/P2/P3付きのUser Stories、Given/When/Then形式のAcceptance Scenarios、Functional Requirements（FR-001、FR-002など）、測定可能な結果を示すSuccess Criteriaが含まれます。エージェントが判断に迷う箇所には`[NEEDS CLARIFICATION: ...]`マーカーが挿入されます。Planに進む前に、それらへ回答します。
Claude Codeで次を入力します。
```
/speckit-specify
```
続いてエージェントが機能の説明を求めます。この段階では技術用語を使わず、平易な言葉で説明します。
```
I want a registration form in my app. The user enters an email
and password, receives a confirmation email, and after confirming
lands on the dashboard. Confirmation expires after 48 hours. If the
email is still unconfirmed, delete the account within 5 minutes after
that deadline; never delete a confirmed account.
```
この例では、48時間の期限後5分以内という削除許容遅延を明確にしています。実製品ではPlanの前に許容を合意してください。正確に48時間が必要なら、それを強制する設計とテストが必要です。エージェントは`specs/001-registration/spec.md`を作成します。開くと次の構造です。
```markdown
# Feature Specification: User Registration
**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."
## User Scenarios & Testing *(mandatory)*
### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.
### Acceptance Scenarios
1. **Given** I am on the registration page,
**When** I submit valid email and password,
**Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
**When** I land on the dashboard,
**Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
**When** cleanup runs within the next 5 minutes,
**Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
**When** cleanup runs,
**Then** the account is not deleted.
## Requirements *(mandatory)*
### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
delete still-unconfirmed accounts no later than 5 minutes after that
deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]
### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at
## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)
```
`[NEEDS CLARIFICATION: ...]`マーカーに注目してください。Spec Kitは、あなたの記述から明確な回答を得られなかった箇所に意図的に挿入します。Planに進む前に、`spec.md`で手動回答するか、`/speckit-clarify`を実行します。するとエージェントが不明点を確認し、対話形式で質問します。
Spec Kitでは、組み込みの`/speckit-clarify`コマンドが、口頭での「質問してください」に置き換わります。効果は同じです。`spec.md`から`[NEEDS CLARIFICATION]`マーカーがなくなるまで、Planに進みません。
`spec.md`に技術は含めません。React、Postgres、Prisma、Redisへの言及もありません。仕様では、ユーザーとビジネスの視点からシステムが何をするかを記述します。技術スタックは次のフェーズで扱います。
## PlanフェーズでClaudeは何をするのか？
重要なポイント
`/speckit-plan`コマンドは完成した仕様をもとに、使用する技術、アーキテクチャ、モジュール、データエンティティ、API契約を含む技術計画を作成します。計画は`specs/###-feature/plan.md`に書かれ、契約は別の`contracts/`フォルダに、データモデルは`data-model.md`に出力されます。この段階ではClaudeはCLAUDE.mdとconstitutionからスタックを把握しているため、「すべてRustで書き直そう」と提案するのではなく、既存のプロジェクトに合う計画を作ります。
`spec.md`が完成したら、次を実行します。
```
/speckit-plan
```
必要に応じて、コマンドに技術のヒントを直接渡せます。
```
/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email
```
Claudeは3つの情報源を読みます。`spec.md`、`CLAUDE.md`（または`memory/constitution.md`）、そしてリポジトリ内の既存コードです。出力される`plan.md`は、概ね次の構造になります。
```markdown
# Implementation Plan: User Registration
## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider
## Architecture Decisions
### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.
### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.
### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.
## Data Model
See data-model.md
## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation
## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests
```
`data-model.md`にはエンティティとその関係が記述されます。`contracts/`にはAPI契約のひな形（OpenAPI YAMLまたはTypeScriptのリクエスト／レスポンスタイプ）が含まれます。これはコードではなく、Claudeが後で実際のルートに変換する意図を記したものです。
Planフェーズの主な利点は、コンテキストが整理されていることです。Claudeは仕様と実装の両方を同時に頭に入れようとはしません。まず考えをまとめ、ファイルに判断を記録してから次に進みます。
次に任意の`/speckit-analyze`コマンドがあります。Tasksフェーズの後、Implementの前に実行します。`spec.md + plan.md + tasks.md`の組をレビューし、矛盾を探して、仕様のすべての要件が計画とタスクでカバーされているか確認します。ファイルは編集せず、レポートだけを出します。実装前に形式的な健全性チェックを行うものです。
## 作業をタスクに分割する方法（Tasks）
重要なポイント
`/speckit-tasks`コマンドは計画を具体的なタスクに分割します。各タスクには依存関係、見積もり、「並行化可能」または「厳密に順次実行」というマーカーが含まれます。出力される`tasks.md`では、`[ ] T-001: ...`というチェックリスト形式でタスクを記します。続いて`/speckit-implement`で実装に回すか、`/speckit-taskstoissues`でGitHub Issuesに変換し、チームや複数のClaude Codeセッションに割り振れます。
`spec.md`と`plan.md`ができたら、次を実行します。
```
/speckit-tasks
```
Claudeは計画を`tasks.md`に展開します。
```markdown
# Tasks: User Registration
## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)
## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)
## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation
## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page
## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
and protection of confirmed accounts
## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)
```
`parallel-safe`と`after T-NNN`のマーカーに注目してください。これは、後で複数フェーズを並行実行するための依存関係グラフです。Spec Kitの高速化アプローチ全体は、この仕組みに基づいています。5つの異なるClaude Codeセッションに渡せるタスクもあれば、厳密に順番に実行しなければならないタスクもあります。
Spec Kitなら、標準機能として1つのコマンドで自動的にこれを行います。
任意の`/speckit-taskstoissues`コマンドは`tasks.md`を受け取り、一覧からGitHub Issuesを作成します。それぞれのIssueには`spec.md`へのリンクが付きます。チームで作業するときや、GitHub Projectsで進捗を追いたいときに便利です。
## サブエージェントを使って実装する方法（Implement）
重要なポイント
最後の`/speckit-implement`フェーズで実装を開始します。Claudeは`tasks.md`を先頭から進め、完了したタスクに`[x]`を付けます。複数のClaude Codeセッションを同時に並行実行することもでき、セッションごとに1つのフェーズを担当します。各セッション内ではClaudeが異なる作業向けのサブエージェントを起動します。コードのレビュー担当、チェックのテスター、READMEを書くドキュメント担当です。Opus 4.8の公開時にAnthropicが述べた「1000の並行サブエージェント」とは、Spec Kitでは特別な製品ではなく、普通の作業モードです。
```
/speckit-implement
```
Claudeは`tasks.md`の最初のタスクから始めます。各タスクでは、関連ファイルを読み、差分を書き、テストを実行し、`[x]`を付けるという小さなサイクルを進めます。必要に応じてサブエージェントが自動的に呼び出されます。コードレビュー担当、リンター実行担当、回帰確認担当がそれぞれ別に動きます。
そして、ルールについてはこう述べています。
Spec Kitでは、このサイクルが形式化されています。信頼できる情報源としての`spec.md`、技術判断を記録する`plan.md`、チェックリストとしての`tasks.md`があります。Claudeがどこかで道を外れたら、仕様に戻って「これはFR-003と一致しません。やり直してください」と伝えます。「話し合ったことを覚えておいて」といった長いプロンプトは不要です。履歴全体がファイルに残っています。
[Opus 4.8のDynamic Workflows](https://ailoot.ai/blog/ja/claude-code-dynamic-workflows/)を連携している場合、Spec Kitを完全自動化モードにできます。`/speckit-implement`を1回実行すると、Claudeが作業を並列化し、結果を統合してチェックします。同時に実行できる上限は1,000のサブエージェントです。多くの機能では10～30で十分です。
すべての`[x]`にチェックが付き、次のセクションのチェックが「Converged」を返したら、PR（タスクが多ければ一連のPR）をレビューしてマージします。成果物の`spec.md`、`plan.md`、`tasks.md`は、機能のドキュメントとしてリポジトリに残ります。1年後に、コードからロジックを逆解析する必要はありません。
## エージェントが見落としをしていないか確認する方法（Converge）
重要なポイント
Implementの後、現行バージョンのSpec Kitには`/speckit-converge`というチェック段階があります。エージェントは完成したコードを`spec.md`、`plan.md`、`tasks.md`と照合します。すべて一致すれば「Converged」と返し、ファイルは変更しません。抜けがあれば`tasks.md`の末尾に新しいタスクとして追加します。その後、`/speckit-implement`を再実行し、続けて`/speckit-converge`を再実行します。「Converged」と返るまで繰り返します。
```
/speckit-converge
```
まずエージェントは、重大度レベル付きで見つかった内容を要約し、その後2つの結果のどちらかを返します。「Converged」は抜けがなく、`tasks.md`がバイト単位で変わっていないことを意味し、レビューに進めます。「Tasks appended」は抜けが見つかり、`tasks.md`のConvergenceセクションに追加されたことを意味します。エージェントは追加数も知らせます。
Convergeはコードを編集も削除もしません。書き込みは`tasks.md`に新しいタスクを追加することだけです。そのため安心して実行できますが、現在の`tasks.md`に沿った`/speckit-implement`がすでに完了している必要があります。実行するたびに、見つかる抜けは減っていきます。
## Spec KitはCLAUDE.mdやPlan Modeとどう違うのか？
重要なポイント
これらのツールを比較するときによく出る質問です。簡単に言えば、CLAUDE.mdはプロジェクト全体に関するエージェントの「雇用契約」であり、唯一の信頼できる情報源です。Plan Modeは特定の依頼に対する一度きりの事前計画です。Spec Kitは説明から実装まで、1つの機能を扱う全ライフサイクルで、成果物をリポジトリに残します。互いに置き換えるのではなく、全体コンテキスト（CLAUDE.md）→プロジェクトコンテキスト（Spec Kitのconstitution）→機能コンテキスト（spec.md + plan.md + tasks.md）という3層のシステムを構成します。
5つの特性で比較します。
| 特性 | CLAUDE.md | Plan Mode | Spec Kit |
|----|----|----|----|
| 実行タイミング | すべてのセッション | 要求時（Shift+Tabまたは/plan） | スラッシュコマンド/speckit-*で実行 |
| 有効期間 | プロジェクト全体 | 1セッション | 1機能 |
| 保存場所 | リポジトリのルート | Claudeのコンテキスト内 | `specs/###-feature/*` |
| 保存する内容 | スタック、規則、用語集 | 現在の計画と観察内容 | spec + plan + tasks + contracts |
| テンプレート | 自由形式（リポジトリ規則） | なし | 構造化Markdown |
| 最適な役割 | プロジェクトの規則とスタック | 大きな変更前の再確認 | WHATからCODEまでの機能全体のサイクル |
Spec Kitの用語では、これは`.specify/memory/constitution.md`にあたります。初期化時に、既存のCLAUDE.mdをconstitutionの基礎に使うか、別ファイルを隣に作るかを選べます。私は通常、CLAUDE.mdを全体的な「契約」（スタック、用語集、デプロイ手順）として保ち、Spec Kitのconstitutionは機能固有の規則に使います。たとえば「すべてのフォームをZodで検証し、手動チェックは禁止」といった規則です。
Plan Modeとの関係はもっと単純です。Plan Modeは1つのセッション内で「コードを書く前に計画する」ための簡易モードです。バグ修正や関数のリファクタリングなど、小さな変更に向いています。大きな機能では、1つのセッションのコンテキストウィンドウが3,000行の計画を扱うには小さすぎるため、Plan Modeでは不十分になります。ライブセッションでも、次のように説明しています。
Spec Kitは具体的なコンテキストエンジニアリングのツールです。「アーキテクチャのテーブルクロス」をチャットからファイルに移します。`Spec.md`はリポジトリに残り、新しいClaudeセッションのたびに読み込まれるので、同じことを繰り返す必要はありません。
大規模プロジェクト向けの構成は次のとおりです。
1. **CLAUDE.md** - スタック、用語集、禁止事項。ルートに置きます。
2. **.specify/memory/constitution.md** - Spec Kit用の、このワークフローに固有の規則。
3. **specs/001-feature-A/spec.md、plan.md、tasks.md** - 最初の機能。
4. **specs/002-feature-B/spec.md、plan.md、tasks.md** - 2つ目の機能。
5. 日々の作業には、準備済みタスク向けの`/speckit-implement`、または変更前の簡単な再確認向けの`/plan`を使います。
## 実際にどんな事例で成果が出ているのか？
重要なポイント
Spec KitとSDDのアプローチは、大企業ですでに測定可能な成果を出しています。AWSの創薬プロジェクトでは、仕様からビジネスロジックの95%を生成し、1つの機能で80時間以上を削減しました。Rackspace Technologyでは52週間分の作業を3週間に圧縮し、効率が90%以上向上しました。Spec Kit自体も8か月でGitHubスターを107,000件獲得しました。
具体的な事例を紹介します。
- **AWS Kiro — 創薬エージェント。** 2026年2月18日付の[AWS Industriesブログ記事](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)では、TargetIDプロジェクトが説明されています。開発者3人、3週間、創薬エージェントというプロジェクトです。記事によると、Kiroがビジネスロジックのコードを95%以上生成し、開発時間を80時間以上削減しました。さらに「Kiroが書いたREADMEのドキュメントで推定8時間を節約」「反復的なプロンプトと修正のサイクルが40%減少」と報告しています。
- **Rackspace Technology。** 同じAWSブログで、Rackspaceは「推定52週間分の作業をわずか3週間で完了」「効率が90%向上」と報告しています。これはもう小さな機能ではなく、企業全体のプロジェクトです。
- **GitHub Spec Kitの成長。** 5月31日には107,000件になりました。3週間で14,000件増えたことになります。この成長率は、このアプローチの市場シェアが広がっている明確な兆候です。
読者にとって重要なのは、この方法が理論上のものではなく、すでに本格的なチームで本番利用されていることです。
## Spec Kitが向いていないのはどんな場合か？
重要なポイント
Spec Kitはどんな場面にも適しているわけではありません。明確な対象外は3つあります。小さな編集（バグ修正、変数名の変更）、実験やプロトタイプ（何を望んでいるのか分からないこと自体がバイブコーディングの目的である場合）、複雑な状態を持つレガシーコード（仕様を書き終えるより速く仕様が古くなる場合）です。こうした事例への真剣な批判もあります。仕様が役に立たない場面で時間を無駄にしないため、そうした議論も知っておく価値があります。
**向いていない場合その1 — 小さな編集。** タスクが「変数名を変更する」「コピーの誤字を直す」「ログを追加する」なら、Specify → Plan → Tasksを通すほうが編集そのものより時間がかかります。小さな編集なら、Plan ModeかClaude Codeへの直接のプロンプトのほうが速いでしょう。
**向いていない場合その2 — 実地の実験。** 何を望んでいるのかまだ分からず、インターフェースを「いろいろ試す」必要があるときや、「うまくいくか」確かめるためにプロトタイプを素早く組み立てるとき、仕様を書く意味はありません。価値はまさに即興することにあります。アイデアを「試している」段階で機能するのは、仕様ではなく、まさにバイブです。
**向いていない場合その3 — 状態が複雑なレガシーコード。** 強い反論があります。現実は仕様より速く変わります。サブスクリプションの請求処理を例に挙げます。チームは請求サイクルと税規則を記述したものの、1週間後に経理部門から欧州VATへの対応を求められ、リリース前に仕様が古くなりました。ビジネスロジックが急速に変化すると、仕様の維持が負担になります。
さらなるリスクは、管理できているという錯覚です。構造は洗練されていても、エージェントは指示を無視することもあれば、逆にテンプレートに厳密に従いすぎることもあります。その結果、構造的には正しくても、あなたのリポジトリには合わないコードになることがあります。仕様があるからといって、エージェントがあなたの意図どおり理解したとは限りません。
業界の分析者はウォーターフォールについて警告しています。コードを書く前に大きな仕様を作成することは、かつて200ページの要件定義書の時代に業界を行き詰まらせた道です。それ以来、エンジニアたちはこのアプローチに慎重であり、その警戒には根拠があります。
**どう対応するか。** 私は、機能の規模と仕様を書く時間を比べる簡単なルールを提案します。実装に2時間もかからない機能なら、仕様を書かず、Plan Modeを使うほうが速いでしょう。実装に1週間かかる機能なら、必ずSpec Kitを使ってください。仕様に1時間かけても、時間の節約で5倍になって返ってきます。2時間から1週間の間なら、自分で判断してください。私は、リポジトリに成果物が残る価値は節約できる30分を上回ると考えているので、半日かかる機能でも仕様を書きます。
## 次にすること：プロジェクトにSpec Kitを導入するには？
重要なポイント
最も簡単な第一歩は、既存プロジェクト全体ではなく、新しい小さな機能でSpec Kitを試すことです。インストールしてリポジトリを初期化し、1つの機能に対して`/speckit-specify`を実行し、生成された成果物を見てください。1～2週間すれば、いつ使い、いつ素早いプロンプトのままにするか感覚がつかめます。完全な方法論はCLAUDE.md + Spec Kit + Skills + サブエージェントを組み合わせます。
次の7日間の具体的な計画です。
- **1日目。** uvとSpec Kitをインストールします（5～10分）。Claude Codeに`/speckit-*`コマンドが表示されることを確認します。既存のプロジェクトに適用しようとせず、新しいプロジェクトから始めてください。
- **2日目。** 作る予定の実際の機能を選びます。自由形式の説明で`/speckit-specify`を実行します。`spec.md`を開いて読み、`[NEEDS CLARIFICATION]`にすべて回答します。Planを急がないでください。
- **3日目。** スタックのヒントを添えて`/speckit-plan`を実行します。`plan.md`、特にArchitecture Decisionsセクションを読みます。合わない内容があれば手動で編集します。
- **4～5日目。** `/speckit-tasks`を実行し、続いて仕様、計画、タスクの組を確認するために`/speckit-analyze`を実行し、その後`/speckit-implement`を実行します。Claudeが`tasks.md`の項目に`[x]`を付ける様子を見てください。どこかで行き詰まることもありますが、問題ありません。`spec.md`に戻って要件を明確にし、具体的なタスクを指定して`/speckit-implement`を再開します。タスクを完了したら`/speckit-converge`を実行し、「Converged」と返るまでImplementとConvergeを繰り返します。
- **6～7日目。** PR（または複数のPR）をレビューし、マージします。`spec.md`と`plan.md`を読み返してください。今後1年間、機能を説明するドキュメントになります。
並行して読むとよい資料です。
- [2026年にCLAUDE.mdを設定する方法](https://ailoot.ai/blog/ja/claude-md-template/) - Spec Kitのconstitutionの基礎。
- [Claude CodeのPlan Mode](https://ailoot.ai/blog/ja/claude-code-plan-mode/) - 小さなタスク向けの簡易な代替手段。
- [2026年のコンテキストエンジニアリング](https://ailoot.ai/blog/ja/context-engineering/) - Spec Kitが機能する理由。
- [Skills、Subagents、MCP、それともPlugins](https://ailoot.ai/blog/ja/skills-subagents-mcp-plugins-claude-code/) - ワークフローにSpec Kitとともに追加するもの。
- [Claude CodeのDynamic Workflows](https://ailoot.ai/blog/ja/claude-code-dynamic-workflows/) - Implementフェーズで多数のサブエージェントを一度に起動する方法。
### 出典
- [GitHub Spec Kit - リポジトリ](https://github.com/github/spec-kit)
- [GitHub Spec Kit - 公式ドキュメント](https://github.github.com/spec-kit/)
- [Spec-Driven Development - 方法論の公式テキスト](https://github.com/github/spec-kit/blob/main/spec-driven.md)
- [Specテンプレート - GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md)
- [AWS Industries Blog - 仕様から本番へ：Kiroの創薬エージェント（2026年2月18日）](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)
- [Claude Code Documentation - Subagents](https://code.claude.com/docs/en/sub-agents)
- [Claude Code Documentation - Skills](https://code.claude.com/docs/en/skills)
- [Claude Code Documentation - Commands](https://code.claude.com/docs/en/commands)
完全なコンテキストワークフロー：AIクローン + 第二の脳 + コンテキストエンジニアリング。
[Ailoot](https://ailoot.ai/)で、さらに多くの資料をご覧いただけます。
## 2026年にClaude CodeでSpec Kitを設定する方法：プロンプトではなく仕様：よくある質問
### 48時間後に削除する要件に、毎日の処理ではなぜ足りませんか？
毎日の実行直後に期限へ達したアカウントは、ほぼ1日余計に待ちます。許容遅延を仕様で明確にし、それに合う頻度を選び、48時間の境界と最大遅延の両方を試してください。
### plan.mdとspec.mdが矛盾したら？
実装前に要件へ戻って解消します。仕様、計画、タスク、合格検査を一緒に更新し、Analyzeと実装検査で同じ合意動作を検証してください。
## Ailoot · 企業とそのプロジェクト群
Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。
企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。
Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。