技術拆解 003｜ECC：25 万 star の「AI プログラミング OS」、エージェントに規律を組み込む

一、これは何か

ECC は AI プログラミングエージェント向けの「パフォーマンス最適化システム」（agent harness performance optimization system）だ。一言で言えば：エージェントを賢くするのではなく、規律を守らせるツール である。

公式のスローガンは分かりやすい：Skills（スキル）、Instincts（直感）、Memory（記憶）、Security（セキュリティ）、research-first development（研究先行）。つまり Claude Code、Codex、Cursor といった AI プログラミングツールに、エンジニアリング規律と記憶システムを一式搭載するものだ。

主な事実：

GitHub プロジェクト affaan-m/ECC、約 25.4 万 star。2026 年 1 月に作成され、8 ヶ月でこの規模に到達。MIT ライセンス、本日の GitHub Trending 1 位
複数ツールに対応：Claude Code（プラグインマーケットからインストール可）、Codex、OpenCode、Cursor など。npm パッケージ（ecc-universal）で統一インストールも可能
驚異的な規模：68 個の専用エージェント、286 個のスキル、94 個のコマンド に加え、フック、ルール、記憶システム、セキュリティスキャンを備える
商用ラインあり：ECC Pro + GitHub App（プライベートリポジトリは $19/シート/月〜）

二、コアメカニズム：5 つの部品がそれぞれ役割を担う

ECC で最も学ぶ価値があるのは、「AI に確実に仕事をさせる」ことを役割の明確な 5 つの部品に分解している点だ。README の比較表が分かりやすく説明している：

1. Plans（計画）——「アイデア」を「成果物」に変える。 システムがなければ、計画は話し合った後にチャットログに消えていく。ECC では計画をまず編集可能な正式な成果物とし、確認後に作業を開始する。この細部が重要だ：AI が失敗する最も多いパターンは、よく考えずに手を動かしてしまうこと だからだ。

2. Skills（スキル）——オンデマンドで読み込まれるワークフロー。 286 個のスキルが TDD、セキュリティレビュー、深度調査、フロントエンド、データ、運用などをカバーする。重要な設計は「オンデマンド読み込み」：タスクに必要なものだけを読み込み、リポジトリ全体をコンテキストに詰め込まない。これは「コンテキストウィンドウは希少なリソースである」という清醒な認識に基づいている。

3. Agents（エージェント）——独立したコンテキストを持つ役割分担。 68 個の専用エージェントがそれぞれ計画、レビュー、修正、セキュリティ、アーキテクチャを担当する。最も優れた設計は「新しいコンテキストでのレビュー」だ：コードを書く人とレビューする人のコンテキストは別々——書いた人はレビュアーの「視点」を知らず、レビュアーは全新しい視点で回帰バグや見落としを探す。これで AI プログラミングの難点が解決する：自分で書いたコードを自分でレビューしても、意味がない という問題だ。

4. Hooks（フック）——モデル外での確定的な実行。 「TDD でお願い」はモデルが忘れる可能性のある指示だが、フックはハーネスのイベントでトリガーされるスクリプトで、モデルのコンテキスト外で実行される——ビルド、lint、型チェック、テストは、実行すべきものが必ず実行され、モデルの自主性に依存しない。「覚えていてほしい」を「必ず通過しなければならない」に変える のだ。

5. Memory + Instincts（記憶と直感）——セッションをまたいだ蓄積。 セッションが終わってもゼロにはならない：ECC はセッションを要約、再利用可能なスキル、信頼度付きの「直感」（実際のセッションから学んだパターン）に蒸留し、次回関連する時に呼び出す。Memory Vault は統一された Markdown 形式（.ecc/memory/）を使い、Claude、Codex、Kimi など異なるツールで同じプロジェクト記憶を共有する——ツールを変えても記憶は引き継がれる。さらに境界線を明確にしている：記憶は「未審査のコンテキスト」であり「実行可能な戦略」ではない。重要な結論は人間が確認した後でなければプロジェクト文書に昇格できない。

もう一つの亮点は AgentShield（セキュリティスキャン） だ：エージェントの設定自体を攻撃対象とみなし——プロンプト、フック、MCP 設定、権限、秘密鍵をスキャンする。「エージェントにサードパーティ製スキルをインストールする」のが流行る現在、これは希少な清醒な視点だ。

三、技術評価：亮点と境界

亮点：

「証拠連鎖」の思考が全体に貫かれている。 TDD ワークフローでは次の手順を要求する：計画を作成 → TDD をアクティベート → まず RED（失敗テスト）の証拠を取得 → GREEN になるまで実装 → 新しいコンテキストでレビュー → 修正し回帰テストを追加 → ビルド/lint/型/テストを検証。生み出されるのはコードだけでなく、証拠の軌跡だ。これは私が企業向けソリューションで話す「トレーサビリティ」と全く同じ思想——AI の仕事は、速さよりも痕跡を残すことが重要だ。
コンテキストの経済学が優れている。 Skills のオンデマンド読み込み、Rules の選択的常駐、Hooks のモデルコンテキスト外移行、Agents のコンテキスト分離——すべての設計が「コンテキストは希少なリソース」を中心に展開されている。これは大規模エージェントを実際に使ったことがある人だけが持つ感覚だ。
ハーネスをまたぐ記憶形式。 単一ツールに縛られず、オープンな Markdown で記憶を保存する——モデルやツールの反復がこれほど速い現在、これは正しい賭けだ：ツールは変わっても、資産は残すべき。

境界：

重い。 68 エージェント + 286 スキルは諸刃の剣——個人の小規模プロジェクトにはこの規模は不要で、インストールするとかえって管理負担が増える。対象は真剣なエンジニアリングチームと長周期プロジェクトだ。
学習曲線が現実に存在する。 5 つの部品にはそれぞれ役割があり、使いこなすには「どの問題が誰の担当か」を理解する必要があり、一つのコマンドで習得できるものではない。
セキュリティ注意喚起はエコシステムのリスクを裏付けている。 README の冒頭で「公式チャネルからのみインストールしてください。第三者による転載にはマルウェアが含まれている可能性があります」と警告している——こうしたエージェント強化ツール自体がサプライチェーン攻撃の標的になっているのだ。
記憶は「未審査のコンテキスト」である。 公式自身も認めている：instincts と記憶には誤りが含まれる可能性があり、使用前に検証する必要がある。真理の宝库として扱ってはならない。

四、Superpowers と比べてどう選ぶか

ECC を語る上で Superpowers（obra/superpowers）は避けて通れない——この分野のもう一つのトッププロジェクトで、約 28.3 万 star と ECC より一歩リードしている。2025 年 10 月作成、同じく MIT ライセンス、同じく Claude Code/Codex/Cursor など十数種類のハーネスに対応する。両者はよく比較されるが、実は方向性が異なる。

Superpowers は一つの「方法論」だ。 自身の位置づけは「ソフトウェア開発方法論 + 組み合わせ可能なスキル」。コアは完全なワークフローだ：まずブレインストーミングで要件を明確にさせる → git worktree で作業領域を分離 → 計画を書く（2-5 分の小タスクに分解し、ファイルパスまで明確に） → サブエージェントがタスクごとに実行（各タスクで 2 段階レビュー） → 厳格な TDD（まず失敗テストを書き、テストのないコードは削除される） → 深刻度に応じてレビューを階層化 → 仕上げてマージ。哲学はたった 4 つ：TDD、場当たりよりもシステマティック、複雑さの削減、主張よりも証拠。強みは「一本の主线を最後まで走り抜ける」こと——エージェントが数時間自律的に作業しても道を踏み外さないのは、この連鎖のおかげだ。

ECC は一つの「オペレーティングシステム」だ。 Superpowers に対して ECC が持っているもの：セッションをまたぐ Memory Vault（ツール間で記憶を共有）、信頼度付きの Instincts、そして AgentShield セキュリティスキャン——Superpowers の重心は「単回開発のプロセス規律」にあり、ECC の重心は「長期プロジェクトの資産蓄積 + 設定のセキュリティ」にある。規模的にも一つの量级差がある：Superpowers は精心設計された一本の主线、ECC は 68 エージェント + 286 スキルのフルセットだ。

選び方、三つの言葉で：

個人開発者、開発習慣を良くしたい人 → Superpowers の方が適している：インストールしたらすぐ使え、一本の主线で 68 個のエージェントの役割を理解する必要がない
エンジニアリングチーム、長周期プロジェクト、複数ツールを併用する場合 → ECC の方が適している：セッションをまたぐ記憶の蓄積、セキュリティスキャン、オンデマンドで拡張できるスキルライブラリは、組織レベルでの使用を想定している
両者の理念は高度に同源（TDD、計画先行、サブエージェントレビュー、証拠優先）で、どちらを選んでも損はない——本当の違いは良し悪しではなく、あなたが求めているのが一つの規律なのか、それとも一式のインフラなのか だ

ちなみに：Superpowers の発表公告には明確に書かれている——作者 obra の長年のソフトウェアエンジニアリング実践の蓄積から生まれ、方法論がツールより先に存在した。これがこうしたプロジェクトが数十万 star を獲得できる理由でもある——みんなが不足していたのはツールではなく、AI が実行できるエンジニアリング規律なのだ。

五、価値判断：誰が使うべきで、誰が使わなくていいか

これが解決する真の問題：AI プログラミングが「書ける」から「任せられる」になるまでの距離 だ。単回の会話では AI の性能が良くても、実際のエンジニアリングは長周期で多セッション、多役割の協働だ——計画は失われ、規律は緩み、経験は蓄積されない。ECC はこの 3 つをすべてエンジニアリング化している。

最も使うべき 3 種類の人：

AI で本格的なプロジェクトをするエンジニアリングチーム——トレーサブルでレビュー可能、蓄積可能な開発プロセスが必要な人
ヘビーなエージェントユーザー——複数ツールを併用し、記憶と習慣を統一したい人
企業向け AI 導入をする人——「計画の成果物化 + 証拠連鎖 + 新しいコンテキストでのレビュー」は自分のソリューションにそのまま取り入れられる

急がなくていい人：スクリプトを書いたり一回限りのタスクをする軽量ユーザー——単純なルールファイルの方が適している；「規律」に需要のないチームは、インストールしても飾りになるだけだ。

一言で判断するなら：ECC は AI プログラミングに「エンジニアリング管理」を導入するための重装備だ——それが賭けているのは「将来の真剣なソフトウェア開発には、エージェントの規律システムが必要になる」という方向だ。方向には同意するが、25 万 star のためにインストールするのではなく、自分のプロジェクトにこのプロセスが必要かどうかをまず考えよう。

六、導入方法

Claude Code ユーザー（推奨パス）：

npx ecc-universal setup

ガイド付きインストール（Node.js 18+、Git、Claude Code 2.1+ が必要）。または Claude Code 内で：

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

どちらのパスでも同じプラグインがインストールされる。一つを選び、重ねてインストールしないこと（README で特に強調されている）。

習得の順番の推奨：

まず /ecc:plan（計画ワークフロー）だけを使う——「計画が成果物になる」ことの価値を体験する
次に TDD ワークフローをオンにする——「RED の証拠 → GREEN → 新しいコンテキストでのレビュー」の証拠連鎖を体感する
それから Memory Vault を初期化する（ecc memory init --scope project）——経験の蓄積を始める
最後に必要に応じてスキルを選ぶ——286 個を欲張らず、よく使うシーンの 10 個程度で十分
チームでの協働/プライベートリポジトリなら Pro + GitHub App を検討する

セキュリティの底线：公式チャネル（GitHub リポジトリ、npm 公式パッケージ ecc-universal/ecc-agentshield、プラグインマーケット）からのみインストールする；サードパーティ製エージェントツールをインストールする前に、AgentShield のスキャンレポートを確認する。

七、自分で同様のソリューションを作る方法

ECC の 5 つの部品は、自分で軽量版を組むことが十分可能で、やる価値もある——コアはコードではなく思想だからだ。

第一に、計画を成果物化する。 あなたのエージェントワークフローにルールを設ける：半日以上かかるタスクは、まず AI に計画ドキュメントを作成させ（チャットではなくファイルに保存する）、人間が確認または修正してから作業を開始する。一行のルールで CLAUDE.md に書き込める。

第二に、レビューを分離する。 コードを書き終わったら、新しいセッションを開く（またはエージェントのサブエージェントを使う）でレビューを行い、明確な指示を出す：「あなたは新しく加わったレビュアーです。回帰リスクと見落としを探してください。」コストはほぼゼロで、効果はすぐに出る。

第三に、フックで兜底する。 ビルド、lint、テストをハーネスのフック（Claude Code の hooks、git hooks、CI など何でも）に書き込み、チェックがモデル外で必ず実行されるようにする。モデルは忘れるが、スクリプトは忘れない。

第四に、記憶を蓄積する。 各セッションの終わりに、AI に 3 つのことを蒸留させて Markdown で保存する：今回何をしたか、どんな坑にはまったか、次回注意すべきこと。プロジェクトの .memory/ ディレクトリに置き、次回作業を始める前に AI に読ませる。これが簡易版の Memory Vault + Instincts だ。

第五に、セキュリティの自スキャン。 定期的に AI に、インストールしているすべてのエージェントツールをチェックさせる：どんな権限を要求しているか、フックでどんなスクリプトを実行しているか、MCP 設定はどこに接続しているか。信頼は与えるが、再確認は必要だ。

この自作版と ECC の差は「深度統合」（ECC は 5 つのことを一つのシステムに織り上げている）にあるが、思想レベルでは 80% を得られる。まず自作版を使ってみて、どこが一番痛いかを体感してから重装備にするかどうかを決めればいい——これはすべてのオープンソースフレームワークを評価するための通用する方法でもある。

結論

ECC の価値は 25 万 star にあるのではなく、「AI プログラミングの信頼性」を玄学からエンジニアリングに変えた点にある：計画は成果物にすべき、レビューはコンテキストを変えるべき、チェックはモデル外で行うべき、経験はファイルに落とすべき、設定は攻撃対象とみなすべき。

この 5 つは、ECC をインストールするしないに関わらず成立する。ツールは時代遅れになるが、規律はならない——これが 8 ヶ月で 25 万 star を獲得した本当の理由だろう：誰もが気づいた、AI プログラミングの次の目的地は、より賢いモデルではなく、より信頼できるプロセスなのだと。

参考出典

GitHub リポジトリ：https://github.com/affaan-m/ECC
公式サイト：https://ecc.tools
npm インストールパッケージ：ecc-universal、ecc-agentshield