Claude Code を日常的に使う開発者にとって、「設定をどう最適化するか」は永遠のテーマだ。CLAUDE.md にどこまで書くか、hooks をどう設計するか、sub-agent をどう分割するか——答えは人によって違う。
そんな中、Everything Claude Code（ECC） というリポジトリが 82,000 GitHub Stars を突破し、Claude Code 設定リポジトリとして史上最多のスターを獲得した。作者は Affaan Mustafa（@affaanmustafa）。10ヶ月以上の日常使用から生まれたこのプロジェクトは、単なる設定集を超え、「エージェントハーネス最適化システム」を名乗る。
この記事では、ECC の構造・設計思想・コミュニティの評価を分解し、開発者として何を取り入れるべきか を考える。
ECC の誕生：ハッカソン優勝から爆発的成長へ
Affaan Mustafa は Anthropic x Forum Ventures ハッカソン（NYC開催）で、Claude Code だけを使い 8時間で zenith.chat を構築 して優勝した。賞金は $15,000 分の API クレジット。
その後、ハッカソンで使った設定をベースに「The Shorthand Guide to Everything Claude Code」を X に投稿。スレッドは 90万ビュー・1万ブックマーク を記録し、設定一式をオープンソース化した。
2026年3月時点で v1.8.0。GitHub Stars は 82K を超え、Fork は 10.7K、コントリビューターは 30人以上。日本語を含む5言語に翻訳されている。
中身の全貌：28エージェント・116スキル・59コマンド
ECC は Claude Code プラグインとして 2 コマンドでインストールできる。
| カテゴリ | 数量 | 主な内容 |
|---|---|---|
| エージェント | 28 | planner, architect, tdd-guide, code-reviewer, security-reviewer, e2e-runner 等 |
| スキル | 116 | coding-standards, backend-patterns, frontend-patterns, pytorch-patterns, mcp-server-patterns 等 |
| コマンド | 59 | /plan, /harness-audit, /loop-start, /quality-gate, /model-route, /security-scan 等 |
| ルール | 12言語 | TypeScript, Python, Go, Java, Kotlin, C++, Rust, PHP, Perl, Swift 等 |
| テスト | 997 | エージェント・スキル・フック・ルールの横断検証 |
3つの設計判断が際立つ
1. Hook ランタイムコントロール（v1.8.0〜）
コミュニティからの「hook 競合」報告を受け、環境変数でフックの厳格度を制御できるようにした。
ECC_HOOK_PROFILE=minimal|standard|strict— 編集なしで切り替えECC_DISABLED_HOOKS=...— 特定フックを ID 指定で無効化
これまでは hooks.json を直接編集する必要があり、アップデート時のマージコンフリクトが頻発していた。
2. クロスプラットフォーム対応
同一リポジトリから 4 つのツールに設定を提供する：
| ツール | 設定方式 |
|---|---|
| Claude Code | プラグインシステム |
| Cursor | .cursor ディレクトリ |
| OpenCode | .opencode ディレクトリ |
| Codex | .codex + AGENTS.md |
v1.6.0 で正式対応し、v1.8.0 でツール間の挙動一貫性を強化した。
3. NanoClaw v2（組み込みオーケストレーション）
モデルルーティング（タスクに応じたモデル自動選択）、スキルのホットロード、セッションの分岐・検索・エクスポート・コンパクト・メトリクスを提供する。ここが ECC を「設定集」から「システム」に押し上げている部分だ。
全員がハマる罠：インストール時の注意点
最頻出の問題：フック重複検出エラー
Claude Code v2.1 以降は、インストール済みプラグインの hooks.json を自動読み込みする。.claude-plugin/plugin.json にも hooks フィールドを宣言すると重複エラーが発生する。対処法は plugin.json に hooks を手動宣言しないこと。
ルールは自動配布されない
Claude Code のプラグインシステムでは、agents・commands・skills・hooks は自動ロードされるが、rules は手動コピーが必要。これは「1コマンドで全部入る」という期待を裏切る。
# ルールは手動コピーが必要
git clone https://github.com/affaan-m/everything-claude-code.git
./install.sh typescript # または python, golang 等
コミュニティの評価：二極化する意見
r/ClaudeCode（週 4,200+ アクティブ投稿者）を中心に、ECC への評価ははっきり分かれている。
高く評価されている点
- 参照アーキテクチャとしての価値: ECC を直接インストールしなくても、agent や skill の定義ファイルからパターンを借用する開発者が多い
- code-reviewer エージェント: 信頼度 80% 以上の問題のみ報告、類似 issue を自動統合、セキュリティ脆弱性を優先——プロンプト設計の模範例として評価が高い
- TDD ワークフロースキル: 「失敗するテストを先に書く → 実装 → テスト通過確認」のサイクルを強制。sub-agent と組み合わせる使い方が広まっている
繰り返し指摘される課題
| 課題 | 詳細 |
|---|---|
| 過度な複雑性 | 997テスト・多言語ルールアーキテクチャ・オーケストレーションエンジンは大多数のチームに不要。「良い CLAUDE.md が 60〜200行あれば 80% カバーできる」 |
| ルール手動配布 | プラグイン経由で agents/skills/hooks は入るが rules は手動コピー。セットアップの一貫性が崩れる |
| Star 数と実利用の乖離 | 82K Stars に対し GitHub Discussions はほぼ不活発。バイラルなXスレッドがスター数を牽引した可能性 |
代替手段との比較
| 項目 | Everything Claude Code | Awesome Claude Code | 自作 CLAUDE.md |
|---|---|---|---|
| アプローチ | フルフレームワーク | キュレーションリスト | 最小構成 |
| セットアップ | 2コマンド + ルール手動 | 参照のみ | 手書き |
| カスタマイズ性 | 環境変数で調整可能 | N/A | 完全自由 |
| 学習コスト | 高い | 低い | 中程度 |
| メンテナンス | 週次アップデート追従 | N/A | 自己管理 |
| 対象ユーザー | パワーユーザー / チーム | 全レベル | 個人開発者 |
単品でも使える3つのコンポーネント
フルインストールを見送る場合でも、以下の 3 つはコミュニティで最も高い評価を受けている：
1. code-reviewer エージェント
信頼度 80% 未満の指摘をフィルタリングし、類似の問題を自動統合、セキュリティ脆弱性（ハードコードされた認証情報・SQL インジェクション・XSS）を最優先で報告する。このプロンプト設計は awesome-claude-code リストでも特に言及されている。
2. TDD ワークフロースキル
「失敗テスト先行 → 実装 → テスト通過確認」のサイクルをスキルとして定義。Claude Code の sub-agent 機能と組み合わせ、テスト作成を sub-agent に委譲しながらメインエージェントがアーキテクチャに集中するパターンが広まっている。
3. セッション要約フック
Stop ライフサイクルフェーズで自動的にセッション要約を ~/.claude/sessions/ に書き出す。v1.8.0 で SessionStart から Stop に移行。理由は「Stop フェーズだけが完全なトランスクリプトにアクセスできるから」。Claude Code の長時間セッションにおけるコンテキスト喪失問題への実用的な対策。
AgentShield：組み込みセキュリティスキャン
ECC には AgentShield が統合されており、/security-scan コマンドで OWASP Top 10 に対応したセキュリティスキャンを実行できる。
| 項目 | 数値 |
|---|---|
| セキュリティルール | 102 |
| テスト数 | 912 |
| カバー範囲 | OWASP Top 10 全項目 |
ハードコードされた認証情報、SQL インジェクション、XSS、未検証のユーザー入力を検出する。
2026年のClaude Codeワークフロー：Redditの最適解
r/ClaudeCode と r/ChatGPTCoding で最も支持されているワークフローは ツール併用 だ：
- Claude Code → アーキテクチャ設計・コードレビュー・複雑な推論
- Codex → 日常的なコーディング（レート制限がピーク品質より重要な場面）
- 2つのツール間で 自動クロスレビュー を設定する上級者もいる
この文脈で ECC は、「Claude Code セッションあたりの品質を最大化する」ためのフレームワークとして位置づけられている。
まとめ：導入すべきか、参照に留めるべきか
| ユーザータイプ | 推奨アプローチ |
|---|---|
| Claude Code を毎日使うチーム | フルインストールを検討。hook ランタイムコントロールで段階的に導入可能 |
| 個人開発者（週数回使用） | フルインストールは過剰。agent/skill の markdown を読み、自分の CLAUDE.md にパターンを借用 |
| 設定最適化に興味がある人 | 参照アーキテクチャとして最良。code-reviewer・TDD skill・セッション要約フックの3つは特に参考になる |
結論： ECC は「最も完全な Claude Code フレームワーク」だ。ただし「最も完全」と「全員に必要」は別の話。自分のワークフローに合う粒度で取り入れるのが最適解だろう。
ソース一覧：
- GitHub: affaan-m/everything-claude-code（82K+ Stars）
- X: @affaanmustafa の元スレッド（49万+ ビュー）
- Medium: Inside the 82K-Star Agent Harness
- awesome-claude-code Issue #547
📝 編集部コメント
997テストを持つ設定リポジトリは前例がない。ただし Hook ランタイムコントロールの設計は実戦的で、既存プロジェクトへの段階導入を可能にしている。code-reviewer の信頼度フィルタリング（80%閾値）は、ノイズの多い AI レビューへの現実的な対処法として参考になる。
116スキルという数は圧巻だが、開発者体験（DX）としては選択のパラドックスが生じる。「まず3つだけ試す」という段階的オンボーディングパスが公式にあれば、採用のハードルは大きく下がるはず。
82K Starsとバイラル拡散は注目に値するが、GitHub Discussions の低活性度は気になる。Star数＝アクティブユーザー数ではない。GitHub Marketplace への展開（free/pro/enterprise）はマネタイズへの布石か。エコシステム化の行方を追いたい。
ECC は「Claude Code の設定をどう体系化するか」という問いへの最も野心的な回答。フルインストールの是非は分かれるが、参照アーキテクチャとしての価値は揺るがない。まずは code-reviewer エージェントの定義ファイルを読むところから始めてみよう。