🏗

Claude Code最強プラグイン「Everything Claude Code」徹底解説 ― 13のサブエージェントで開発を自動化する

2026/02/28に公開

TL;DR： Everything Claude Code（ECC）は、13のサブエージェント・31コマンド・28スキル・24ルールを含む Claude Code 向け包括的プラグイン。サブエージェントによる分業と自動委任で、計画→実装→テスト→レビュー→セキュリティ検証の開発サイクルを自動化できる。

 はじめにClaude Code は単体でも強力だが、「毎回同じ指示を繰り返す」「レビューを忘れる」「セキュリティチェックが属人化する」といった課題は残る。これらを解決するのが Everything Claude Code（ECC） だ。
ECC は Anthropic ハッカソン優勝者 Affaan Mustafa が開発したプラグインで、GitHub で 41K+ スターを獲得している。本記事では ECC の全体像と、中核をなす 13のサブエージェント の設計思想・使い方を解説する。
!本記事はシリーズの第1回です。

記事1（本記事）： ECC 全体像 + サブエージェント
記事2：マルチエージェント実践
記事3：検証ループ・Eval・TDD
記事4：トークン最適化・コスト管理

 ECC の5層アーキテクチャECC は5つのレイヤーで構成される。それぞれが独立しつつ連携する設計だ。


レイヤー
格納先
数
役割


Agents
~/.claude/agents/
13
専門特化したサブエージェント

Commands
~/.claude/commands/
31
スラッシュコマンドで呼び出す操作

Skills
~/.claude/skills/
28
Claude の振る舞いを定義するパターン

Rules
~/.claude/rules/
24
コーディング規約・セキュリティルール

Hooks
hooks.json
7種
イベント駆動の自動化トリガー

ポイントは Agents がすべての起点になる ことだ。/plan コマンドは Planner エージェントを、/tdd コマンドは TDD Guide エージェントを呼び出す。Commands はエージェントへの入り口であり、Skills はエージェントの行動パターンを定義し、Rules は品質基準を設定し、Hooks がそれらを自動で接続する。

 インストールと初期設定
 プラグインとしてインストール（推奨）# マーケットプレイスを追加
/plugin marketplace add affaan-m/everything-claude-code

# プラグインをインストール
/plugin install everything-claude-code@everything-claude-code
または ~/.claude/settings.json に直接追加する。
{
  "extraKnownMarketplaces": {
    "everything-claude-code": {
      "source": { "source": "github", "repo": "affaan-m/everything-claude-code" }
    }
  },
  "enabledPlugins": {
    "everything-claude-code@everything-claude-code": true
  }
}

 Rules の手動インストールプラグインシステムの制約で、Rules は手動コピーが必要だ。
git clone https://github.com/affaan-m/everything-claude-code.git
cp -r everything-claude-code/rules/common/* ~/.claude/rules/

# 言語別ルールを選んでコピー
cp -r everything-claude-code/rules/typescript/* ~/.claude/rules/  # TypeScript
cp -r everything-claude-code/rules/python/* ~/.claude/rules/      # Python
cp -r everything-claude-code/rules/golang/* ~/.claude/rules/      # Go
!要件： Claude Code CLI v2.1.0 以上が必要。claude --version で確認すること。

 13のサブエージェント一覧ECC のサブエージェントは3つのカテゴリに分類できる。

 コア開発エージェント

エージェント
目的
使用ツール
起動コマンド


Planner
実装計画の作成
Read, Grep, Glob
/plan

Architect
システム設計・ADR作成
Read, Grep, Glob
/orchestrate

TDD Guide
テスト駆動開発の強制
Read, Write, Edit, Bash, Grep
/tdd

Code Reviewer
コード品質レビュー
Read, Grep, Glob, Bash
/code-review

Doc Updater
ドキュメント・コードマップ生成
Read, Write, Edit, Bash, Grep, Glob
/update-docs

Refactor Cleaner
デッドコード削除・整理
Read, Write, Edit, Bash, Grep, Glob
/refactor-clean


 エラー解決エージェント

エージェント
目的
使用ツール
起動コマンド


Build Error Resolver
ビルドエラーの最小diff修正
Read, Write, Edit, Bash, Grep, Glob
/build-fix

Go Build Resolver
Go ビルド・vet・linter修正
Read, Write, Edit, Bash, Grep, Glob
/go-build


 専門特化エージェント

エージェント
目的
使用ツール
起動コマンド


Security Reviewer
OWASP Top 10 脆弱性検出
Read, Write, Edit, Bash, Grep, Glob
/orchestrate security

Database Reviewer
PostgreSQL最適化・RLS設計
Read, Write, Edit, Bash, Grep, Glob
—

E2E Runner
Playwright E2Eテスト実行
Read, Write, Edit, Bash, Grep, Glob
/e2e

Go Reviewer
Go コードレビュー（並行性・慣用パターン）
Read, Grep, Glob, Bash
/go-review

Python Reviewer
Python PEP 8・型ヒントレビュー
Read, Grep, Glob, Bash
/python-review


 サブエージェントの設計思想
 全エージェントが Opus モデルを使用ECC の全サブエージェントは model: opus で動作する。コスト効率より判断の正確さを優先する設計だ。特に Security Reviewer は「脆弱性を見逃すコスト > Opus のトークンコスト」という考え方に基づいている。

 ツールアクセスの最小権限エージェントごとにアクセスできるツールが厳密に制限されている。
Planner:       Read, Grep, Glob            ← コード変更不可
Architect:     Read, Grep, Glob            ← コード変更不可
Code Reviewer: Read, Grep, Glob, Bash      ← 読み取り+実行のみ
TDD Guide:     Read, Write, Edit, Bash, Grep ← テスト実行のため変更可能
Planner と Architect が Write/Edit ツールを持たない のは意図的だ。計画段階でコードを変更すると、レビューされていない変更がコードベースに入り込むリスクがある。計画は計画に徹し、実装は別のフェーズで行う。

 Iterative Retrieval パターンサブエージェントはメインのコンテキストウィンドウから分離された環境で動作する。つまり どのファイルが必要かを事前に知らない。この「コンテキスト問題」を解決するのが Iterative Retrieval パターンだ。
DISPATCH（広範な検索）
  → EVALUATE（関連性スコアリング 0.0〜1.0）
    → REFINE（検索条件の改善）
      → LOOP（最大3サイクル）
停止条件： 関連性 ≥ 0.7 のファイルが3件以上見つかり、重大なギャップがないこと。
実際の例を見てみよう。「トークン有効期限のバグ修正」というタスクでは：

サイクル1： auth token で検索 → auth.ts, tokens.ts を発見（関連性 0.9）

サイクル2： トークン管理で追加検索 → session-manager.ts, jwt-utils.ts を発見
コードベースが「rate limit」ではなく「throttle」という用語を使っていた場合、サイクル1で見つからなくても、サイクル2以降で用語のズレを学習して正しいファイルにたどり着く。

 実践例：機能実装の自動化フロー新機能「ユーザー認証にレート制限を追加する」を ECC で実装する場合のフローを見てみよう。

 Step 1: /orchestrate feature で自動パイプラインを起動/orchestrate feature "Add rate limiting to authentication endpoints"
このコマンドは以下の4エージェントを順番に起動する。
Planner → TDD Guide → Code Reviewer → Security Reviewer

 Step 2: Planner が実装計画を作成Planner は Read/Grep/Glob だけで既存コードを分析し、計画を出力する。
# Implementation Plan: Rate Limiting

## Phase 1: Core Implementation
1. **Create rate limiter middleware** (File: src/middleware/rate-limiter.ts)
   - Action: sliding window algorithm を実装
   - Risk: Low

2. **Apply to auth routes** (File: src/routes/auth.ts)
   - Action: ミドルウェアを login/register に適用
   - Dependencies: Step 1

## Testing Strategy
- Unit: rate limiter のロジックテスト
- Integration: API エンドポイントのレート制限テスト
ユーザーの確認を待ってから次のフェーズに進む。これが Planner の重要な特性だ。

 Step 3: TDD Guide がテストファーストで実装TDD Guide は RED → GREEN → REFACTOR サイクルを強制する。
RED:      rate-limiter.test.ts を作成（テストが失敗する状態）
GREEN:    rate-limiter.ts を実装（テストがパスする最小限のコード）
REFACTOR: 重複除去・定数化・命名改善

 Step 4: Code Reviewer がレビューCode Reviewer は git diff で変更を確認し、4段階で問題を報告する。


重要度
対象
例


CRITICAL
セキュリティ脆弱性
ハードコードされた API キー

HIGH
コード品質
50行超の関数、エラーハンドリング漏れ

MEDIUM
パフォーマンス
O(n²) アルゴリズム、N+1 クエリ

LOW
ベストプラクティス
TODO コメント、マジックナンバー

CRITICAL または HIGH の問題があれば Block（マージ不可）を出す。

 Step 5: Security Reviewer がセキュリティ検証Security Reviewer は OWASP Top 10 を基準に、以下をチェックする。
ハードコードされたシークレット
SQL / コマンドインジェクション
XSS・SSRF
認証・認可の不備
金融操作の競合状態
レート制限の不十分さ

 Step 6: 最終レポート全エージェントの結果が統合され、最終レポートが生成される。
ORCHESTRATION REPORT
━━━━━━━━━━━━━━━━━━━
Summary: Rate limiting implementation complete
Recommendation: SHIP

Agent Results:
  Planner:          COMPLETE (2 phases, 4 steps)
  TDD Guide:        PASS (92% coverage)
  Code Reviewer:    APPROVE (0 CRITICAL, 0 HIGH, 2 MEDIUM)
  Security Reviewer: PASS (OWASP Top 10 clear)

Files Changed: 5
Tests Added: 12

 Handoff ドキュメント — エージェント間の引き継ぎエージェント間のコンテキスト共有は Handoff ドキュメント で行われる。前のエージェントの出力が次のエージェントへの入力になる。
## HANDOFF: Code Reviewer → Security Reviewer

### Context
Rate limiting middleware added to auth endpoints

### Findings
- No CRITICAL issues
- 2 MEDIUM issues (magic numbers, missing JSDoc)

### Files Modified
- src/middleware/rate-limiter.ts (new)
- src/routes/auth.ts (modified)
- src/middleware/__tests__/rate-limiter.test.ts (new)

### Open Questions
- Rate limit の閾値（100 req/min）は適切か？

 カスタムワークフロー/orchestrate はデフォルトの4種類に加え、カスタムワークフローも作成できる。
# デフォルトワークフロー
/orchestrate feature "..."   # planner → tdd-guide → code-reviewer → security-reviewer
/orchestrate bugfix "..."    # explorer → tdd-guide → code-reviewer
/orchestrate refactor "..."  # architect → code-reviewer → tdd-guide
/orchestrate security "..."  # security-reviewer → code-reviewer → architect

# カスタムワークフロー
/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
独立したチェック（code-reviewer と security-reviewer など）は並列実行もされるため、全体の実行時間が短縮される。

 まとめECC の価値は「個々のエージェントの能力」よりも「エージェント間の連携設計」にある。

最小権限の原則： エージェントごとにツールを制限し、意図しない変更を防ぐ

Iterative Retrieval： コンテキスト不足を3サイクルの探索で解決する

Handoff ドキュメント： エージェント間の引き継ぎを構造化する

確認ゲート： Planner が計画段階でユーザー確認を挟む
次回の記事では、これらのサブエージェントを 並列に走らせるマルチエージェントパターン について解説する。
!シリーズ記事リンク

記事1（本記事）： ECC 全体像 + サブエージェント
記事2：マルチエージェント実践
記事3：検証ループ・Eval・TDD
記事4：トークン最適化・コスト管理

レイヤー	格納先	数	役割
Agents	`~/.claude/agents/`	13	専門特化したサブエージェント
Commands	`~/.claude/commands/`	31	スラッシュコマンドで呼び出す操作
Skills	`~/.claude/skills/`	28	Claude の振る舞いを定義するパターン
Rules	`~/.claude/rules/`	24	コーディング規約・セキュリティルール
Hooks	`hooks.json`	7種	イベント駆動の自動化トリガー

エージェント	目的	使用ツール	起動コマンド
Planner	実装計画の作成	Read, Grep, Glob	`/plan`
Architect	システム設計・ADR作成	Read, Grep, Glob	`/orchestrate`
TDD Guide	テスト駆動開発の強制	Read, Write, Edit, Bash, Grep	`/tdd`
Code Reviewer	コード品質レビュー	Read, Grep, Glob, Bash	`/code-review`
Doc Updater	ドキュメント・コードマップ生成	Read, Write, Edit, Bash, Grep, Glob	`/update-docs`
Refactor Cleaner	デッドコード削除・整理	Read, Write, Edit, Bash, Grep, Glob	`/refactor-clean`

エージェント	目的	使用ツール	起動コマンド
Build Error Resolver	ビルドエラーの最小diff修正	Read, Write, Edit, Bash, Grep, Glob	`/build-fix`
Go Build Resolver	Go ビルド・vet・linter修正	Read, Write, Edit, Bash, Grep, Glob	`/go-build`

エージェント	目的	使用ツール	起動コマンド
Security Reviewer	OWASP Top 10 脆弱性検出	Read, Write, Edit, Bash, Grep, Glob	`/orchestrate security`
Database Reviewer	PostgreSQL最適化・RLS設計	Read, Write, Edit, Bash, Grep, Glob	—
E2E Runner	Playwright E2Eテスト実行	Read, Write, Edit, Bash, Grep, Glob	`/e2e`
Go Reviewer	Go コードレビュー（並行性・慣用パターン）	Read, Grep, Glob, Bash	`/go-review`
Python Reviewer	Python PEP 8・型ヒントレビュー	Read, Grep, Glob, Bash	`/python-review`

重要度	対象	例
CRITICAL	セキュリティ脆弱性	ハードコードされた API キー
HIGH	コード品質	50行超の関数、エラーハンドリング漏れ
MEDIUM	パフォーマンス	O(n²) アルゴリズム、N+1 クエリ
LOW	ベストプラクティス	TODO コメント、マジックナンバー

GitHubで編集を提案

Claude Code最強プラグイン「Everything Claude Code」徹底解説 ― 13のサブエージェントで開発を自動化する

はじめに

ECC の5層アーキテクチャ

インストールと初期設定

プラグインとしてインストール（推奨）

Rules の手動インストール

13のサブエージェント一覧

コア開発エージェント

エラー解決エージェント

専門特化エージェント

サブエージェントの設計思想

全エージェントが Opus モデルを使用

ツールアクセスの最小権限

Iterative Retrieval パターン

実践例：機能実装の自動化フロー

Step 1: `/orchestrate feature` で自動パイプラインを起動

Step 2: Planner が実装計画を作成

Step 3: TDD Guide がテストファーストで実装

Step 4: Code Reviewer がレビュー

Step 5: Security Reviewer がセキュリティ検証

Step 6: 最終レポート

Handoff ドキュメント — エージェント間の引き継ぎ

カスタムワークフロー

まとめ

Discussion