「Claude Code や Cursor を業務で使い始めて、エージェントへの設定（CLAUDE.md・skills・hooks）を自前で整備し始めたものの、気づけば設定が断片化して再現性がなくなってきた」——そんな状態に心当たりはないでしょうか。チームに展開しようとしても標準化されておらず、新しいプロジェクトを立ち上げるたびに似た設定を作り直している、というケースは珍しくありません。
そうした課題の受け皿として GitHub で大きな注目を集めているのが、ECC（旧称: Everything Claude Code）という OSS です。20 万を超えるスターが付いており、SNS や GitHub Trending で見かけて気になっている方も多いはずです。ただ、規模が大きいぶん「自分のプロジェクトに本当に必要なのか」「類似の OSS とどう違い、どれを選べばいいのか」「導入して運用が破綻しないか」と、導入を判断する段階で迷いが生じやすいのも事実です。
本記事は、こうした「導入する前の意思決定」に焦点を当てます。インストール手順を網羅的になぞるのではなく、ECC が解決する課題・主要コンポーネント・類似 OSS（awesome-claude-code / SuperClaude）との選定軸・メンテナンス状況を整理し、初見のエンジニアが「自分の用途に合うかどうか」を自力で判断できる材料を提供することを目的とします。
なお本記事は、リポジトリの README・公式サイト・公式ドキュメントを読み込んだドキュメントベースの調査に基づいています。インストールや実行といった動作検証は行っていません。数値はすべて GitHub API から取得した実測値（後述）を基準にしています。それでは、まず ECC が何をする OSS なのかから見ていきましょう。
ECCとは｜Claude Codeを最適化するエージェントハーネスOSS
ECC（Everything Claude Code）は、AI コーディングエージェントの「ハーネス（harness）」のパフォーマンスを最適化するためのシステムとして公開されている OSS です。リポジトリの説明文では「The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.」と定義されています（GitHub リポジトリ）。
ここで重要なのは、ECC が「単なる設定ファイルの寄せ集めではない」と位置づけられている点です。README では「Not just configs. A complete system: skills, instincts, memory optimization, continuous learning, security scanning, and research-first development.」と述べられており、skills・instincts・メモリ最適化・継続学習・セキュリティスキャン・リサーチファースト開発までを含む「完成したシステム」を標榜しています（出典: ECC README）。
開発の背景として、README には実プロダクト開発で 10 か月以上にわたり日次で集中的に使い込んだノウハウを進化させたものだと記載されています。つまり、机上の設計ではなく実運用から生まれた構成である、という主張です。
リポジトリの基本情報
導入判断の土台として、まずリポジトリの客観的な情報を押さえておきましょう。以下は GitHub API から取得した実測値です（取得日: 2026 年 6 月 5 日）。
項目 | 値 |
|---|---|
owner/name | affaan-m/ECC |
主要言語 | JavaScript |
ライセンス | MIT |
スター数 | 207,849 |
フォーク数 | 31,895 |
直近の push | 2026 年 6 月 4 日 |
アーカイブ / フォーク / 無効化 | いずれも該当なし（active なオリジナルリポジトリ） |
このリポジトリはアーカイブされておらず、他リポジトリのフォークでもありません。独立して開発が続けられている本体リポジトリです。ライセンスは MIT で、OSS としての利用・改変・再配布の自由度が高い点も確認できます。
なお、README の冒頭には「182K+ stars」といった概数のバッジ表記が見られますが、本記事では API から取得した実測値（207,849 スター / 31,895 フォーク）を採用しています。概数が独り歩きしている場合があるため、導入判断の際は数値の出どころを確認しておくと安心です。
ECCが解決する課題とエージェントハーネスという考え方
ECC を理解するうえで鍵になるのが「エージェントハーネス（agent harness）」という考え方です。ここでのハーネスとは、AI コーディングエージェントに対して「どう振る舞うべきか」「どんな手順で作業するか」「何を参照するか」を与える、設定・指示・補助ツールの集合体を指します。Claude Code でいえば CLAUDE.md・slash command・subagent・hooks といった要素がこれにあたります。
個人やチームでこれらを自前で整備していくと、次のような課題が起きやすくなります。
- 設定が複数ファイルに散らばり、全体像を把握しづらくなる（断片化）
- プロジェクトごとに似た設定を作り直すことになり、再現性が確保できない
- チームメンバーへ展開しても標準が共有されず、品質がばらつく
- Claude Code 用に整えた設定が、Cursor や Codex など別のツールでは流用できない
ECC は、これらの設定・スキル・フックを再利用可能な「システム」としてまとめることで、こうした課題に応えようとしています。とくに特徴的なのが、対応範囲を Claude Code に限定していない点です。リポジトリの説明文にあるとおり、Claude Code・Codex・OpenCode・Cursor などを横断（クロスハーネス）して使える構成を志向しています。1 つのプロジェクトで複数の AI ツールを併用している、あるいは将来ツールを乗り換える可能性があるチームにとっては、この「ツールをまたいで設定資産を使い回せる」という点が採用検討の動機になり得ます。
逆に言えば、Claude Code 単体しか使っておらず設定もごく軽量で済んでいる場合は、ここまで包括的なシステムが過剰になる可能性もあります。「自分の課題がクロスハーネスや標準化にあるのか」を見極めることが、最初の判断軸になります。
ECCの主要コンポーネント（agents・skills・hooks・instincts）
ECC がどの程度のものを提供しているのか、規模感を具体的に把握しておきましょう。README には、公開されている資産の規模として「63 agents, 251 skills, and 79 legacy command shims」と明記されています（出典: ECC README）。コンポーネントの体系は公式サイト（ecc.tools）でも確認できます。
これらの数字は導入の手応えを左右します。以下、主要なコンポーネントを順に見ていきます。
Agents（subagents）
委任先となる専門エージェント群です。README ではタスクの委任先となる「specialized subagents」として位置づけられています。リリースノートには、typescript-reviewer・java-reviewer・kotlin-reviewer といった言語特化のレビュアーや、pytorch-build-resolver・java-build-resolver・kotlin-build-resolver といったビルド解決系のエージェントが追加され、言語カバレッジを 10 言語に拡張したことが記載されています。plan・設計・コードレビュー・セキュリティレビューといった開発の各局面に応じたエージェントを呼び分ける構成です。
Skills
言語別・フレームワーク別のベストプラクティスをまとめたコンポーネントです。ECC は Agent Skills のオープン標準に準拠する形でこれらを提供しており、ワークフローの中核を担う部分にあたります。自前でベストプラクティスを言語化・整備する手間を、既製のスキル群で肩代わりするイメージです。
Hooks
エージェントのライフサイクル上の特定ポイントで自動的に発火する仕組みです。ECC では ECC_HOOK_PROFILE（minimal / standard / strict）や ECC_DISABLED_HOOKS といった環境変数でフックの挙動をランタイムに制御できる設計になっています。「フックは便利だが全部は要らない」という場合に、プロファイルで段階的に有効化できる点は、導入時の負荷を抑える観点で重要です。
Instincts と memory 永続化
ECC が「単なる設定集ではない」と主張する根拠が、この継続学習まわりのコンポーネントです。instincts は、セッション中のパターンを自動的に抽出し、再利用可能なスキルとして取り込んでいく仕組みとされています。加えて memory persistence により、セッションをまたいでコンテキストを保存・読み込みするフックが提供されます。一度きりの設定にとどまらず、使い込むほど構成が洗練されていくことを意図した設計と言えます。
ここまでが「ECC を導入すると何が手に入るか」の概観です。規模が大きいぶん全体を一度に使いこなす必要はなく、後述するようにプロファイルを絞って段階的に取り入れる選択肢が用意されています。
ECCの導入方法と注意すべき落とし穴
導入手順そのものは公式の Quick Start（ECC README の Quick Start）に一次情報があります。本記事では「導入して破綻しないか」という不安に直結する、注意すべきポイントに絞って整理します。
README が推奨するデフォルトは、Claude Code のプラグイン経由でのインストールです。以下のコマンドがマーケットプレイス追加とプラグインインストールの手順として記載されています。
# Add marketplace
/plugin marketplace add https://github.com/affaan-m/ECC
# Install plugin
/plugin install ecc@ecc
（出典: ECC README）
フックを全体に効かせたくない、あるいはルール・エージェント・コマンドと中核的なワークフロースキルだけを使いたい場合は、最小プロファイルでの手動インストールも選べます。
./install.sh --profile minimal --target claude
（出典: ECC README）
ここで最も注意したいのが、README が繰り返し強調している「インストール経路を 1 つに絞る」という点です。README には「Do not stack install methods.（インストール方法を重ねるな）」とあり、最も多い壊れ方として「/plugin install を先に実行し、その後で install.sh --profile full や npx ecc-install --profile full を重ねてしまうパターン」が挙げられています（出典: ECC README）。プラグインインストールがすでにスキル・コマンド・フックを読み込んでいるため、その後にフルインストーラを走らせると同じものがユーザーディレクトリに二重にコピーされ、スキルの重複やランタイム挙動の重複を招くと説明されています。導入前にこの注意を把握しておくだけで、最頻の失敗パターンを回避できます。
もう 1 つの混乱しやすいポイントが、ECC が持つ 3 つの公開識別子です。README の「Naming + Migration Note」には、以下の 3 つが相互に互換ではない（interchangeable ではない）と明記されています（出典: ECC README）。
- GitHub のソースリポジトリ:
affaan-m/ECC - Claude マーケットプレイス/プラグインの識別子:
ecc@ecc - npm パッケージ:
ecc-universal
GitHub 上のリポジトリ名、プラグインのインストール時に指定する名前、npm パッケージ名がそれぞれ異なります。これは意図的な設計だと説明されていますが、ドキュメントやブログ記事を参照する際に「どの名前で何を指しているのか」を取り違えると設定ミスにつながります。導入時にはこの 3 つの使い分けを意識しておくとよいでしょう。
ECCと類似OSSの違い｜選定軸で比べる
「Claude Code まわりの設定資産を OSS で揃えたい」と考えたとき、候補は ECC だけではありません。検索でよく並ぶ類似の OSS と比較しておくと、自分の用途に対する適合度を判断しやすくなります。ここでは代表的な 2 件を取り上げます。
比較対象1: awesome-claude-code（キュレーションリスト型）
hesreallyhim/awesome-claude-code は、Claude Code 向けの skills・hooks・slash command・エージェントオーケストレーター・プラグインなどへのリンクを集めた、いわゆる「awesome リスト」型のキュレーションリストです。性格としては、外部リソースへの索引・カタログにあたります。
ECC が「インストールしてすぐ使える実装本体（agents/skills/hooks/rules）」であるのに対し、awesome-claude-code は「どんなリソースが存在するかを俯瞰するための索引」です。両者は競合というより役割が異なります。「まず何があるのかを広く知りたい」段階なら awesome-claude-code、「即座に使える完成済みの構成が欲しい」なら ECC、という棲み分けになります。
比較対象2: SuperClaude_Framework（設定フレームワーク型）
SuperClaude-Org/SuperClaude_Framework は、Claude Code を構造化された開発プラットフォームへと拡張する設定フレームワークです。slash command・エージェント・振る舞いモード（behavior mode）といった、コマンドとペルソナ・モードを主軸とする構成が特徴です。
ECC との違いは「対象範囲の広さ」に集約されます。SuperClaude は Claude Code を中心に据えたフレームワークであるのに対し、ECC は Codex・Cursor・OpenCode・Gemini などを横断するクロスハーネス対応、instincts による継続学習、メモリ永続化、そしてセキュリティ面までを射程に入れています。Claude Code に集中して使い込みたいのか、複数ツールをまたいで設定資産を運用したいのかが、両者を分ける判断軸になります。
選定軸での比較表
3 者を主要な選定軸で整理すると、次のようになります。なお、ECC のスター数・フォーク数は GitHub API 実測値、他 2 件は調査時点の概数です。
観点 | ECC | awesome-claude-code | SuperClaude_Framework |
|---|---|---|---|
性格 | 完成済みのシステム本体 | キュレーションリスト（索引） | 設定フレームワーク |
対応ハーネス | クロスハーネス（Claude Code/Codex/Cursor/OpenCode 等） | Claude Code 中心 | Claude Code 中心 |
継続学習・メモリ | あり（instincts / memory 永続化） | リスト掲載のリソース次第 | モード・コマンド主軸 |
スター数（目安） | 207,849（API 実測値） | 約 3.7 万（概数） | 約 2.1 万（概数） |
主な向き先 | 即使える包括的な構成が欲しい | まず情報収集したい | Claude Code を構造化して使いたい |
用途別の選び方
以上を踏まえると、選び方は次のように整理できます。
- まず「どんなリソースがあるか」を広く把握したい段階 → awesome-claude-code で索引的に探す
- Claude Code 単体で、コマンドやモードを構造化して開発したい → SuperClaude_Framework
- 複数ツールをまたいで設定資産を再利用したい、継続学習やセキュリティまで含めて本格運用したい → ECC
「Claude Code 単体で軽く始めたいだけ」なのか、「クロスハーネスで本格的に運用したい」のかによって、最適な選択肢は変わります。自分の用途がどこに位置するかを起点に選ぶと、過不足のない判断ができます。
ECCのメンテナンス状況・ライセンス・採用判断のまとめ
最後に、「導入して破綻しないか」という観点でメンテナンスの健全性とライセンスを確認し、採用判断のチェックリストで締めます。
メンテナンス状況については、GitHub API の実測値で直近の push が 2026 年 6 月 4 日（取得日の前日）になっており、活発に更新が続いていることが確認できます。フォーク数は 31,895、スター数は 207,849 と、利用者・関心の母数も大きい状態です。アクティブに保守されているか不安な OSS を避けたい場合、この「直近で動いているか」という指標は重要な判断材料になります。
ライセンスは MIT です（ライセンス）。OSS 本体は MIT のもとで自由に利用でき、商用利用・改変・再配布が許容されます。README には、OSS 本体は無料で提供しつつ、ホスト型の有償プランや GitHub Sponsors を開発の資金源とする旨が記載されています。OSS 本体の利用が有償プランへの加入を前提としていない点は、まず無償で試したいチームにとって安心材料になります。日本語の概要を確認したい場合は、リポジトリ内の日本語 READMEも参照できます。
採用を判断する際は、次のチェックリストで自分の状況と照らし合わせてみてください。
- 用途: クロスハーネス（複数ツール併用）か、Claude Code 単体か。単体かつ軽量なら、より小さい構成の選択肢でも足りる可能性がある
- チーム規模・標準化ニーズ: 設定をチームで標準化・再利用したいなら ECC のシステム化が効く。個人の小規模利用ならプラグインの最小プロファイルから段階的に試せる
- 継続学習・セキュリティ要件: instincts による継続学習やセキュリティ面まで一体で運用したいなら ECC の対象範囲の広さが活きる
- 導入の落とし穴の回避: 「インストール経路は 1 つに絞る」「3 つの識別子（
affaan-m/ECC/ecc@ecc/ecc-universal）を取り違えない」を事前に把握しておく - メンテナンス健全性: 直近の更新が継続しているか、ライセンスが自社の利用条件に合うかを確認する
ECC は「設定が散らかってきた」「複数ツールにまたがって設定を使い回したい」「使い込むほど洗練される仕組みが欲しい」というニーズに対して、包括的な答えを用意している OSS です。一方で、Claude Code 単体で軽量に済んでいる場合は過剰になり得ます。本記事で整理した課題・コンポーネント・選定軸・メンテナンス状況を手がかりに、まずは自分の用途を見極めたうえで、公式の Quick Start で実際の導入手順を確認することをおすすめします。
