ECC (Everything Claude Code) — これは何か、使う価値はあるか？

GitHubのAIコーディング領域でECCというプロジェクトを見かけたなら、スター数に驚いたはずです——本稿執筆時点でaffaan-m/ECCは約20万スターを獲得しており、AIツール系リポジトリでも異例の規模です。しかしREADMEを開くと、多くの人の第一印象は「これは一体何?」です。

ECCの公式ポジショニング：The agent harness performance optimization system — Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond. 平たく言えば、Claude Code・Codex・Opencode・Cursorなどのエージェントの上に乗る実行力強化フレームワークで、Skills・Instincts・Memory・Securityの4次元をカバーします。

要するに：Claude CodeやCursor Agentをある程度複雑なタスクに使うと、迷子になりがちです——コンテキストを失い、遠回りし、作業を繰り返し、触るべきでないファイルを修正する。ECCは、これらの問題を再利用可能な「接着層」で解決し、エージェントの動作をより予測可能で安全かつ持続的にすることを目指します。

1. 背景：Claude Codeにハーネスが必要な理由

Claude Codeはすでに市場で最も強力なコード生成ツールのひとつです。Anthropicはツール使用、マルチステップ計画、ファイルシステムの読み書きを組み込みました。しかし実際のエンジニアリング環境では、開発者はすぐに構造的な限界に突き当たります：

• コンテキストウィンドウは有限。タスクがセッションのトークン予算を超えると、エージェントは履歴を切り捨てるか最初からやり直すかのどちらかで、既知の制約や中間結論がすべて失われます。
• セッション横断メモリがない。「このプロジェクトはESLintでなくBiomeを使う」と伝えても、次のセッションでは完全に忘れています。
• ガードレールがない。エージェントは時に触るべきでないファイルを修正し、予期しない依存関係をインストールし、ネットワーク呼び出しを試みます。本番リポジトリではリアルなリスクです。
• スキルが移植できない。あるプロジェクトでエージェントにテストの書き方を教えても、次のプロジェクトでは最初からやり直しです。

ECCはこの4点すべてに対処します。Claude Codeを置き換えるのではなく、その上に乗ります——レーシングハーネスがドライバーを守るように、車を替えることなく。

2. 4つの柱：Skills・Instincts・Memory・Security

2.1 Skills

Skillsは最も直感的に分かりやすいモジュールです。再利用可能なタスクステップを呼び出し可能なスキルユニットとしてパッケージ化できます——コードロジックではなくエージェント動作を記述する関数のようなもの。「プロジェクト規約に従ったユニットテストを書く」「コミット前にlintと型チェックを実行する」「APIレスポンスをパースしてTypeScript型を生成する」——これらの高頻度オペレーションをSkillsとしてパッケージ化し、プロジェクトをまたいで再利用できます。Skillsは合成もサポートしており、複数のSkillsをパイプラインとして連結できます。

2.2 Instincts

InstinctsはECCで最も創意に富んだコンセプトのひとつです。Skillsが「何をするか」を教えるとすれば、Instinctsは「特定の状況に直面したときデフォルトでどう反応するか」——決定ではなく反射です。具体的にはトリガー・レスポンスルール：「エージェントがpackage.jsonを変更しようとしたら一時停止して確認を求める」「テストファイルが欠けていたら自動でスケルトンを生成する」「未知のAPIエンドポイントに遭遇したらまずドキュメントを調べる」。ルールはデフォルトでオフ、選択的に有効化、フル拡張可能。Instinctsの価値は暗黙の規約を明示化することです。

2.3 Memory

ECCのMemoryモジュールはセッション横断の忘却問題を解決します。プロジェクト制約・技術的決定・デバッグの結論・既知の落とし穴を格納する軽量の永続化ナレッジストアを維持します。このストアは構造化されインデックス化されており、新しいセッション開始時にエージェントが関連エントリを自動取得して現在のコンテキストウィンドウに注入——「プロジェクトをすでに知っているエンジニア」のように動作します。

2.4 Security

Securityモジュールはエンタープライズシナリオで最も説得力のある機能です：権限境界と行動監査システム。ファイルシステムパスのallowlist、アウトバウンドネットワークリクエストのブロック（明示的なオプトイン要）、事後監査のための構造化ログ、コードやコミットメッセージに特定内容を書かせないセンシティブワードフィルター。本番リポジトリでエージェントを直接動かすチームにとって、これらはオプションではなく基本要件です。

3. 誰に向いているか？

4. 類似ツールとの比較

ECCはコードワークフロー特化（すべての設計決定がコード生成とエンジニアリング自動化に向いている）、軽量（ベクターDB不要、Redis不要、別サーバー不要）、追加型（既存のIDE設定やCIスクリプトを置き換えず、上に乗る）という点で差別化されています。

5. 始め方：最小構成

リポジトリ：github.com/affaan-m/ECC。推奨ルート：READMEを最後まで読む、2〜3個のSkillsから始める、隔離環境でテスト、InstinctsとSecurityを段階的に有効化、CI組み込み前に十分な手動テスト。

git clone https://github.com/affaan-m/ECC.git
cd ECC
ls -la
# READMEとdocs/でSkills/Instincts設定フォーマットを確認

6. クラウドMac上でECC + Claude Codeを動かす

長時間実行または複数プロジェクトの並行エージェントタスクでは、ローカルMacBookには明確な限界があります：蓋を閉じると中断、ディスク圧迫、日常の開発環境との干渉。ECC + Claude Codeを常時起動したクラウドMac miniに移行することが一般的になりつつあります。MemoryモジュールはMacBookのディスクを圧迫しない永続ストレージが必要です。M4 Mac miniはサーマルスロットリングなしの安定した性能を提供。固定出口IPでSaaSのallowlist設定が容易。OpenClawをCI/CDに使っている場合、分業は明確です：OpenClawがビルドトリガーとRunnerを管理、ECCがエージェント層のメモリ・境界・監査を担保。

7. 使う価値はあるか——正直な判断

約20万スターは、コミュニティが問題を本物と認識し、ECCの方向性が正しいと判断していることを示します。しかしスターは成熟度でもあなたのユースケースへの適合性でもありません。率直な判断：エージェントタスクが一回性・低リスクなら、今はスキップ。エージェントを日常ワークフローに組み込み始めたがまだセッション横断ドリフトを経験していないなら、アーキテクチャを理解して待つ。実際のリポジトリに対して複数セッション・複数日にわたってエージェントを動かしているなら、4つのモジュール全てに直接価値があります。

プロジェクト：https://github.com/affaan-m/ECC