📋 この記事の前提
- GitHub Copilot Pro以上のサブスクリプションを契約済み
- AIコーディングエージェント（GitHub Copilot CLI等）を使ったことがある
- 前回の記事「GitHub Copilot CLIでSuperpowersスキルを導入してみた」を読んでいると理解しやすい
- TDD（テスト駆動開発）の基本的な考え方を知っている
結論: 自分のワークフローを組み立てる時代
先に結論を書いておく。
Everything Claude Code（ECC） と Superpowers はどちらも優秀なAIエージェントハーネスだが、性格がまったく違う。ECCは「何でも揃った総合ツールボックス」で、Superpowersは「厳格なワークフロー教官」。
どちらが上かという話ではなくて、両方使ってみて初めて「私に必要なものは何か」が見えてきた。私の場合、Superpowersの「TDDのREDを絶対にスキップさせない」厳格さと、ECCの「開発ドキュメントを自動生成してくれる」便利さ。両方のいいとこ取りをして、私だけのハーネスをカスタマイズしていくのがベストだと思っている。
| 条件 | おすすめ |
|---|---|
| TDDを厳格に徹底したい | Superpowers |
| 多言語・大規模プロジェクトをまるごと管理したい | ECC |
| ドキュメント自動生成やセッション学習がほしい | ECC |
| GitHub Copilotなど複数プラットフォームで使いたい | Superpowers |
| 両方の良いところを取りたい | 自分でカスタマイズ（この記事の結論） |
Everything Claude Code（ECC）とは
Everything Claude Codeは、Affaan Mustafa氏を中心に開発されたAIエージェントハーネス（エージェント性能最適化システム）だ。GitHubスター数は50,000以上、フォーク6,000以上、Anthropicハッカソンの受賞歴もある。
ひとことで言うと、「AIコーディングエージェントを、単なるチャットボットから本格的なエンジニアリングチームへ格上げするための総合パッケージ」。
もともとClaude Code向けに作られたが、いまはCursor、Codex、OpenCode、Antigravityなど複数のハーネスに対応している。私はGitHub Copilot CLIでSuperpowersを使う前に、ECCのスキルやルールを手動でコピーしてワークフローに取り入れていた。
規模感がすごい
まず驚くのはその物量だ。
| コンポーネント | 数 | 例 |
|---|---|---|
| エージェント | 28個 | planner, code-reviewer, tdd-guide, architect, doc-updater等 |
| スキル | 116個 | tdd-workflow, continuous-learning, security-review等 |
| コマンド | 59個 |
/tdd, /plan, /code-review, /learn, /e2e等 |
| 対応言語ルール | 12言語 | TypeScript, Python, Go, C#, Java, Kotlin, Rust, C++, Swift, PHP, Perl等 |
| フック | 多数 | セッション開始/終了時の自動処理、ファイル編集時のチェック等 |
正直、最初は「こんなに必要か？」と思った。でも実際に使うと、この規模のプリセットが揃っていることの意味がわかる。
ECCの導入方法
ECCの導入方法は2つある。
方法1: プラグインインストール（Claude Code向け）
Claude Codeを使っている場合は、2コマンドで入る：
# マーケットプレイスを追加
/plugin marketplace add affaan-m/everything-claude-code
# プラグインをインストール
/plugin install everything-claude-code@everything-claude-code
ただし、rules（常に従うべきガイドライン）はプラグインとして配布できないため、手動でコピーする必要がある：
# リポジトリをクローン
git clone https://github.com/affaan-m/everything-claude-code.git
cd everything-claude-code
# 依存パッケージをインストール
npm install
# macOS/Linux
./install.sh typescript # 使う言語を指定
# Windows PowerShell
.\install.ps1 typescript
方法2: 手動インストール
個別にコンポーネントを選んでコピーする方法もある：
# エージェントをコピー
cp everything-claude-code/agents/*.md ~/.claude/agents/
# ルールをコピー（共通 + 使う言語のみ）
cp -r everything-claude-code/rules/common/* ~/.claude/rules/
cp -r everything-claude-code/rules/typescript/* ~/.claude/rules/
# コマンドをコピー
cp everything-claude-code/commands/*.md ~/.claude/commands/
方法2のほうが「何を入れたか」が明確になるので、私はこちらを使っていた。116個のスキルを全部入れると、コンテキストウィンドウを圧迫する可能性があるからだ。Claude Codeを使っていない場合は、方法2が実質的な唯一の選択肢になる。
ECCの構成 — 5つの柱
ECCを理解するには、5つのコンポーネントの関係を押さえるとわかりやすい。
1. エージェント（agents/）
特定の役割を持った「専門家」を定義するMarkdownファイル。YAML フロントマターで名前、使用モデル、使えるツールを指定する。
たとえばtdd-guide.mdはこんな構成：
---
name: tdd-guide
description: Test-Driven Development specialist...
tools: ["Read", "Write", "Edit", "Bash", "Grep"]
model: sonnet
---
You are a Test-Driven Development (TDD) specialist...
「planner → architect → tdd-guide → code-reviewer」のように、開発フローに合わせて複数のエージェントを順番に使う想定になっている。
2. スキル（skills/）
ワークフローのナレッジベース。エージェントが参照する「教科書」のようなもの。tdd-workflowスキルなら「テストを先に書け」「カバレッジ80%以上を確認しろ」といった具体的な手順が書いてある。
ここが面白いのは、116個のスキルの中にフレームワーク固有のものがたくさんある点。Django用のTDDスキル、Spring Boot用のセキュリティスキル、Laravel用の検証スキルなど、かなり幅広い。
3. コマンド（commands/）
ユーザーが直接呼び出すスラッシュコマンド。/tddと打てばtdd-guideエージェントが起動して、TDDのワークフローに入る。/planならplannerエージェントが起動する。
# 新機能の開発フロー
/plan "ユーザー認証機能を追加する" # plannerが設計
/tdd # tdd-guideがテスト→実装
/code-review # code-reviewerがレビュー
4. ルール（rules/）
「常にこのルールに従え」というガイドライン。言語共通のルールと、言語固有のルールに分かれている。
rules/
├── common/ # 全言語共通（コーディングスタイル、Git、テスト、セキュリティ等）
├── typescript/ # TypeScript固有
├── python/ # Python固有
├── csharp/ # C#固有（これは嬉しかった）
├── golang/ # Go固有
└── ... # 計12言語
ルールとスキルの違いがちょっとわかりにくいけど、ルールは「常に適用」、スキルは「必要な時に参照」 という棲み分け。
5. フック（hooks/）
ツール使用前後に自動で実行される処理。たとえば：
- セッション開始時: 前回のコンテキストを自動で読み込む
- セッション終了時: 学んだパターンを保存する
-
ファイル編集後:
console.logが残っていたら警告する
フックはJSON形式で定義される。この「セッション横断でコンテキストを保持する」仕組みが、ECCの特徴的なポイントだ。
ECCの気に入っていた機能
/learn コマンド — セッションからパターンを抽出する
個人的に一番気に入っていた機能がこれ。開発中に「あ、これは今後も使えそうなパターンだな」と思ったら /learn を実行する。するとエージェントがセッションの内容を分析して、再利用可能なパターンを~/.claude/skills/learned/にスキルファイルとして保存してくれる。
抽出対象はこんなもの：
| パターン種別 | 内容 |
|---|---|
| エラー解決パターン | 特定のエラーの原因と解決策 |
| デバッグ手法 | 効果的だったデバッグ手順 |
| ワークアラウンド | ライブラリのクセや制限の回避策 |
| プロジェクト固有パターン | コードベースの慣習や設計判断 |
次のセッションで同じ問題にぶつかったとき、学習済みのスキルが自動で参照される。これは地味にありがたかった。
ドキュメント自動生成（doc-updater エージェント）
もうひとつ気に入っていたのが doc-updater エージェント。/update-docsや/update-codemapsコマンドで呼び出すと、コードベースの構造を解析して、アーキテクチャのコードマップを自動生成してくれる。
docs/CODEMAPS/
├── INDEX.md # 全体概要
├── frontend.md # フロントエンド構造
├── backend.md # バックエンド構造
├── database.md # データベーススキーマ
└── integrations.md # 外部サービス連携
コードを書いたらドキュメントも自動で更新される。「ドキュメントとコードの乖離」は開発チームの永遠の課題だけど、ECCはこれをエージェントに任せるアプローチを取っている。
Superpowersにはこの機能に相当するものがない。ここはECCの明確な強みだ。
Superpowersとの比較 — 何が違うか
前回の記事で紹介したSuperpowersと、ECCをさまざまな角度から比較してみた。
設計思想の違い
| 観点 | Everything Claude Code | Superpowers |
|---|---|---|
| コンセプト | 総合パフォーマンスシステム | ワークフロー教官 |
| アプローチ | 多機能・モジュール構成 | 少数精鋭・プロセス徹底 |
| スキル数 | 116個 | 14個 |
| コマンド数 | 59個 | なし（自動トリガー） |
| カスタマイズ性 | 高い（コンポーネント単位で追加/削除） | 中程度（スキル追加は可能） |
| 学習機能 | あり（/learn、Continuous Learning） |
なし |
| ドキュメント生成 | あり（doc-updater、codemaps） | なし |
ここ、ちょっと面白いんだけど、Superpowersはコマンドを持っていない。スキルが「自動的にトリガーされる」設計で、ユーザーが明示的に呼び出す必要がない。「機能を作りたい」と話しかけるだけで、brainstormingスキルが自動で起動する。
ECCは逆に/tdd、/planのようにユーザーが明示的にコマンドを叩く設計。どちらが良いかは好みだけど、Superpowersの「勝手にやってくれる」感覚は使っていて気持ちがいい。
プラットフォーム対応の違い
| プラットフォーム | ECC | Superpowers |
|---|---|---|
| Claude Code | ✅ ネイティブ対応 | ✅ プラグインマーケットプレイス |
| GitHub Copilot CLI | △ 直接対応なし | ✅ プラグインマーケットプレイス |
| VS Code (Copilot拡張) | △ 直接対応なし | ✅ settings.jsonでスキルフォルダを指定 |
| Cursor | ✅ .cursor/に設定あり |
✅ プラグインマーケットプレイス |
| Codex | ✅ AGENTS.md対応 | ✅ 手動セットアップ |
| Gemini CLI | △ 直接対応なし | ✅ gemini extensions install
|
Superpowersはスキル中心の設計なので、スキルファイルさえ読み込めるプラットフォームなら動く。私がGitHub Copilot CLIで使えているのもこのおかげ。
ECCは元々Claude Code向けに設計されているため、hooks（Claude Codeの機能）やCLAUDE.md（Claude Code固有のファイル）に依存する部分が多い。Claude Code以外で使おうとすると、活かせない機能が結構ある。
TDDでのREDの強制力 — ここが一番の違い
正直に言うと、ECCからSuperpowersに乗り換えた最大の理由がこれ。
ECCのTDDワークフロー
ECCの/tddコマンドは、tdd-guideエージェントを起動する。エージェントの定義には「テストを先に書け」「RED→GREEN→REFACTORのサイクルを徹底しろ」と明記されている。
tdd-workflowスキルにも手順が詳しく書いてある：
- ユーザージャーニーを書く
- テストケースを生成する
- テストを実行して失敗を確認する（RED）
- 最小限のコードを実装する（GREEN）
- リファクタリングする
- カバレッジ80%以上を確認する
手順自体は正しい。でも実際に使ってみると、エージェントがREDフェーズをスキップすることが結構あった。
具体的にはこんな感じ：
- テストを書く前に実装コードを書き始める
- テストと実装を同時に書いてしまう（テストが最初から通る状態になる）
- 「最小限の実装」のはずが、余計な機能まで一気に書いてしまう
ECCのTDDスキルは「Tests BEFORE Code」「ALWAYS write tests first」と書いてある。でも、これは推奨であって強制ではない。エージェントが「まあ効率的だしテストと一緒に書いちゃおう」と判断してしまうと、それを止める仕組みがない。
SuperpowersのTDDスキル
一方、Superpowersのtest-driven-developmentスキルには、こんなルールがある：
テストを先に書かなかったら、書いたコードを削除してやり直す
この**「削除してやり直す」**という強制力が決定的な違い。Superpowersではテストを書く前にコードを書くことが「禁止」されていて、もし書いてしまったらロールバックする。提案ではなくルールとして機能する。
実際に使ってみた感触では、Superpowersのほうが圧倒的にREDフェーズを守ってくれた。テストがまず失敗することを確認してから実装に入る。余計なコードも書かない。「最小限の実装」が本当に最小限になる。
なぜこの違いが生まれるのか
私なりに考えた結果、スキル定義の粒度と強制力の違いが原因だと思っている。
ECCはTDDの手順を「ワークフローの知識」として提供している。エージェントに「こうやるべきだ」と教えるが、守るかどうかはエージェントの判断に委ねている。
Superpowersは「こうやらなければならない。やらなかったら巻き戻す」と制約をかけている。スキル定義がより厳格で、エージェントの裁量を意図的に狭くしている。
TDDに限った話ではなく、Superpowersは全体的に**「プロセスの規律」を重視**する設計になっている。brainstormingスキルでは要件を深掘りしてからでないとコードに入れないし、verification-before-completionスキルでは「完了」を宣言する前に必ず検証コマンドを実行する。
ECCが勝っている点 — フェアに見る
SuperpowersのTDD強制力を褒めたけど、ECCのほうが優れている点も正直に書いておく。
1. 継続学習システム
ECCの/learnコマンドとContinuous Learningスキルは、セッションごとの学びを蓄積していく。v2ではInstinct（本能）ベースの学習システムになっていて、学んだパターンに信頼度スコアが付く。信頼度が低い（矛盾する情報が出た）パターンは自動的に減衰する。
/instinct-status # 学習済みInstinctの一覧と信頼度を確認
/instinct-export # 他の人と共有するためにエクスポート
/evolve # 関連するInstinctをまとめてスキルに進化させる
この「使えば使うほど賢くなる」仕組みは、Superpowersにはない。
2. 多言語対応の深さ
ECCのルールとスキルは12言語に対応している。C#のルールもある（これは私にとって嬉しかった）。言語ごとのベストプラクティス、テストパターン、ビルドエラー解決エージェントまで用意されている。
Superpowersは言語に依存しない汎用的な設計で、これはこれで良いのだが、「TypeScriptならこう、Goならこう」という言語固有の指導はしてくれない。
3. セキュリティスキャン
ECCにはAgentShieldというセキュリティ監査ツールが統合されている。CLAUDE.md、設定ファイル、MCPサーバー設定、フック定義を自動でスキャンして脆弱性を検出する。--opusフラグで3つのOpusエージェントがRed Team/Blue Team/Auditorの構成で攻防戦を繰り広げるのは、なかなか面白い仕組みだ。
4. マルチエージェントオーケストレーション
/multi-plan、/multi-execute、/orchestrateなどのコマンドで、複数のエージェントを並列に動かせる。大規模プロジェクトでフロントエンドとバックエンドを同時に開発するような場面で威力を発揮する。
全体比較表
| 観点 | Everything Claude Code | Superpowers |
|---|---|---|
| TDD RED強制力 | △ 推奨レベル | ✅ 強制（違反時はロールバック） |
| スキルの自動トリガー | ❌ コマンド明示実行 | ✅ 状況に応じて自動発火 |
| 学習機能 | ✅ Continuous Learning v2 | ❌ なし |
| ドキュメント自動生成 | ✅ doc-updater + codemaps | ❌ なし |
| セキュリティ監査 | ✅ AgentShield統合 | ❌ なし |
| マルチエージェント | ✅ 並列オーケストレーション | △ サブエージェント対応 |
| 導入の手軽さ | △ ルール手動コピーが必要 | ✅ 2コマンドで完了 |
| プラットフォーム汎用性 | △ Claude Code中心 | ✅ スキル中心で汎用的 |
| 機能量 | ✅ 28エージェント、116スキル | ○ 14スキル（少数精鋭） |
| コンテキスト消費 | △ 多機能ゆえに消費大 | ✅ 軽量 |
これからの私の方針 — ハーネスは「組み立てる」もの
両方を使い込んで、いま一番強く感じているのは**「既製品をそのまま使うのではなく、私のワークフローに合わせてカスタマイズするのが重要だ」**ということ。
具体的には、こんなイメージを持っている：
- TDDの規律はSuperpowersから取り入れる — REDフェーズの強制力は譲れない
- ドキュメント生成はECCの思想を参考にする — doc-updaterの「コードからドキュメントを生成する」アプローチは真似したい
- 学習機能は自分で小さく作る — ECCのContinuous Learningの考え方を、私のプラットフォーム（GitHub Copilot CLI）に合わせて実装したい
-
スキルは自分で書く — SuperpowersもECCも
writing-skillsや/skill-createで自作スキルの仕組みを用意している。最終的には私のプロジェクトに特化したスキルを作るのが一番効率がいい
Superpowersのwriting-skillsスキルを使えば、新しいスキルの作り方をガイドしてもらえる。ECCの/skill-createコマンドは、Gitの履歴からパターンを抽出してスキルを自動生成してくれる。どちらのアプローチも面白い。
AIエージェントハーネスは「導入して終わり」ではなく、使いながら自分好みに育てていくものだと日々感じている。
まとめ
- Everything Claude Code は28エージェント・116スキル・59コマンドを備えた総合AIハーネス。学習機能やドキュメント自動生成が強み
- Superpowers は14スキルの少数精鋭で、TDDのRED強制やワークフローの規律が圧倒的に強い
- ECCのTDDは「推奨」、SuperpowersのTDDは「強制」。この違いが実際の開発品質に明確に影響した
- Superpowersはスキル中心の設計なので、GitHub Copilot CLIなど複数のプラットフォームで使いやすい
- ECCのドキュメント生成や学習機能はSuperpowersにないユニークな強み
- 結論: 既製品をそのまま使うのではなく、両方の良い部分を取り入れて自分のハーネスを育てていくのがベスト
📌 前回のSuperpowers記事と合わせて読むと、AIハーネスの全体像がつかめるはず。「いいね」してもらえると次の記事のモチベーションになります！
よくある質問
Q. Everything Claude CodeとSuperpowersは同時に使えますか？
技術的には同時インストール可能ですが、スキルやルールが競合する可能性があります。実用的には、どちらかをベースにして、もう一方から必要な部分だけ取り入れるのがおすすめです。
Q. ECCはGitHub Copilot CLIで使えますか？
ECC全体をGitHub Copilot CLIで使うのは難しいです。hooks（Claude Code固有機能）や一部のコマンドが動きません。ただし、スキルファイル（SKILL.md）を手動でコピーすれば、スキル単体は参照可能です。
Q. どちらが初心者向きですか？
Superpowersのほうが導入が簡単で、スキル数も少ないため理解しやすいです。ECCは機能が豊富ですが、その分「何から使えばいいか」が最初はわかりにくいかもしれません。
Q. 自分でスキルを作るにはどうすればいいですか？
Superpowersにはwriting-skillsスキルが含まれていて、スキルの作り方をガイドしてくれます。ECCには/skill-createコマンドがあり、Gitの履歴からパターンを自動抽出してスキルファイルを生成できます。どちらもSKILL.md形式のMarkdownファイルを作成する方式です。
Q. AIハーネスを自作する場合、何から始めるべきですか？
まずは既存のハーネス（SuperpowersまたはECC）を使ってみて、「自分の開発で一番効果があった機能」と「足りないと感じた機能」を把握するところから始めるのがおすすめです。その上で、重要なワークフロー（TDD、コードレビュー、ドキュメント生成など）をスキルとして定義していくと、効率的にカスタマイズできます。
📝 この記事は Zenn で最初に公開されました。
最新版はZennをご覧ください。