2026年にClaude CodeでSpec Kitを設定する方法：プロンプトではなく仕様

2026年5月、バイブコーディングに何が起きたのか？#

1年後の2026年2月4日、彼は振り返りのスレッドを公開しました。

Sequoia Ascent 2026での講演では、さらに明確にこう表現しました。「バイブコーディングはソフトウェアで誰もができることの底上げをする。エージェント型エンジニアリングは、プロの開発の品質基準という天井を維持する。」同じステージで、業界の語彙に加わる一言も述べました。「バイブコーディングを理由に脆弱性を持ち込むことは許されない。これまでと同じく、ソフトウェアに対する責任はあなたにある。」

2つの出来事が並行して起きました。2025年9月、GitHubはSpec Kitツールを公開し、8か月で107,000スターを獲得しました。2026年2月、AWSは「仕様からビジネスロジックの95%を生成し、80時間以上を削減した」と報告する詳細な創薬事例を発表しました。

2026年5月末までに、英語圏の情報空間では合意が形成されました。作業方法としてのバイブコーディングは初心者向けの段階であり、その次にSpec-Driven Developmentが来ます。このガイドでは、その導入と適用方法を説明します。

Spec KitとSpec-Driven Developmentとは？#

この方法論の核となる考え方は、GitHub公式ドキュメントの一文にまとめられています。

実際には、これは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など、さらに十数種類のエージェントでも同じように動作します。

実行後、リポジトリにはコードだけでなく仕様、計画、タスクも含まれます。1か月後にプロジェクトに戻ってspec.mdを読めば、何をしたのか、なぜそうしたのかが分かります。これはもう「バイブコーディングでコードの存在を忘れた」という状態ではなく、プロジェクトの作業記憶です。

コードを書かないバイブコーダーになぜ必要なのか？#

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ステップ）#

ステップ1. uvをインストールします。 一度だけ実行すれば、システムに残ります。

# 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がインストールされたことを確認します。

uv --version

ステップ2. Spec Kitをインストールします。 コマンドは1つです。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

確認します。

specify --version

ステップ3. リポジトリを初期化します。 プロジェクトフォルダに移動（または新しいフォルダを作成）して、次を実行します。

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を開いてスラッシュコマンドを確認します。 同じフォルダで次を実行します。

claude

セッション内で/speckitと入力すると、候補に/speckit-*コマンドが表示されます。表示されない場合は、Claude Codeを再起動して.claude/skills/を読み直させます。プロジェクトのルートにすでにCLAUDE.mdがある場合、Spec Kitはそのファイルを変更せず、.specify/memory/constitution.mdで併用します。

Spec KitはClaude Codeなしでも使えます（30以上のエージェントに対応）。ただし、このガイドではClaudeとの設定を扱います。2つのツールをすぐにインストールしたい場合は、CLAUDE.mdの設定とClaude CodeのPlan Modeに関する別ガイドを参照してください。

Spec Kitは「エージェントの雇用契約」を構成する最初の要素です。完全なセットアップには3つすべてが含まれます。AIクローン（Skillsとサブエージェントという形のあなたの方法論）、第二の脳（エージェントが毎回参照するbusiness/構造）、そしてコンテキストエンジニアリング（Spec Kit、Plan Mode、/compact）です。これらは、AIが幻覚を起こさないための3本柱です。

最初の仕様を書く方法（Specify）#

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を作成します。開くと次の構造です。

# 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は何をするのか？#

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は、概ね次の構造になります。

# 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）#

spec.mdとplan.mdができたら、次を実行します。

/speckit-tasks

Claudeは計画をtasks.mdに展開します。

# 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]を付けるという小さなサイクルを進めます。必要に応じてサブエージェントが自動的に呼び出されます。コードレビュー担当、リンター実行担当、回帰確認担当がそれぞれ別に動きます。

そして、ルールについてはこう述べています。

Spec Kitでは、このサイクルが形式化されています。信頼できる情報源としてのspec.md、技術判断を記録するplan.md、チェックリストとしてのtasks.mdがあります。Claudeがどこかで道を外れたら、仕様に戻って「これはFR-003と一致しません。やり直してください」と伝えます。「話し合ったことを覚えておいて」といった長いプロンプトは不要です。履歴全体がファイルに残っています。

Opus 4.8のDynamic Workflowsを連携している場合、Spec Kitを完全自動化モードにできます。/speckit-implementを1回実行すると、Claudeが作業を並列化し、結果を統合してチェックします。同時に実行できる上限は1,000のサブエージェントです。多くの機能では10～30で十分です。

すべての[x]にチェックが付き、次のセクションのチェックが「Converged」を返したら、PR（タスクが多ければ一連のPR）をレビューしてマージします。成果物のspec.md、plan.md、tasks.mdは、機能のドキュメントとしてリポジトリに残ります。1年後に、コードからロジックを逆解析する必要はありません。

エージェントが見落としをしていないか確認する方法（Converge）#

/speckit-converge

まずエージェントは、重大度レベル付きで見つかった内容を要約し、その後2つの結果のどちらかを返します。「Converged」は抜けがなく、tasks.mdがバイト単位で変わっていないことを意味し、レビューに進めます。「Tasks appended」は抜けが見つかり、tasks.mdのConvergenceセクションに追加されたことを意味します。エージェントは追加数も知らせます。

Convergeはコードを編集も削除もしません。書き込みはtasks.mdに新しいタスクを追加することだけです。そのため安心して実行できますが、現在のtasks.mdに沿った/speckit-implementがすでに完了している必要があります。実行するたびに、見つかる抜けは減っていきます。

Spec KitはCLAUDE.mdやPlan Modeとどう違うのか？#

5つの特性で比較します。

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を使います。

実際にどんな事例で成果が出ているのか？#

具体的な事例を紹介します。

• AWS Kiro — 創薬エージェント。 2026年2月18日付のAWS Industriesブログ記事では、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が向いていないのはどんな場合か？#

向いていない場合その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を導入するには？#

次の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を設定する方法 - Spec Kitのconstitutionの基礎。
• Claude CodeのPlan Mode - 小さなタスク向けの簡易な代替手段。
• 2026年のコンテキストエンジニアリング - Spec Kitが機能する理由。
• Skills、Subagents、MCP、それともPlugins - ワークフローにSpec Kitとともに追加するもの。
• Claude CodeのDynamic Workflows - Implementフェーズで多数のサブエージェントを一度に起動する方法。

完全なコンテキストワークフロー：AIクローン + 第二の脳 + コンテキストエンジニアリング。

Ailootで、さらに多くの資料をご覧いただけます。