superpowers × ECC で Claude Code を「作業の背骨」にする―構成の意思決定と棲み分け

はじめに

この記事では、Claude Code を「たまにコードを書かせるツール」から「開発も調べ物も日々の記録も乗せる作業の背骨」に引き上げるために、superpowers と ECC という2つのプラグインを併用するハーネスを組んだ話を書いていきます。

得られるのは、スキルやエージェントが大量にあるハーネスを「破綻させずに」使うための棲み分けの考え方と、実際にハマった落とし穴です。想定読者は、Claude Code をそれなりに使い込んでいて、プラグインやスキルを入れ始めたら逆に散らかってきた、という人です。

きっかけは単純で、会社員を辞めて時間が自由になったタイミングで、開発だけじゃなく調べ物や日々の記録まで全部 Claude Code に乗せたくなったからです。ただ、いざプラグインを漁ると数が膨大で、そのまま全部入れると自動起動が競合してぐちゃぐちゃになるのが目に見えていました。そこで一度立ち止まって、構成そのものを設計することにしました。

なお、この記事で扱うのは「進め方をどう組むか」という設計の話が中心です。個々のスキルの使い方カタログではありません。

そもそも superpowers と ECC って?

どちらも Claude Code にかぶせて使うプラグイン群です。ただ、性格がかなり違います。

superpowers（obra/superpowers）: 開発の「進め方」をきっちり型にしたフレームワーク。ブレインストーミング → 設計 → 計画 → TDD 実装 → レビュー → マージ、という規律を持っていて、git worktree での隔離や「設計が承認されるまで実装しない」というハードゲートが標準装備です。計画はファイルに残るし、実装はサブエージェントに隔離される。この「進め方を型にする」部分がすごくよくできています。
ECC（Everything Claude Code、affaan-m 作の OSS）: README 曰く "the agent harness operating system" を名乗る、とにかく物量のライブラリです。導入した時点でスキルが278個、コマンドが94個、サブエージェントが67個ありました。言語別のコードレビュアーやセキュリティ監査など、かなり幅広い専門作業をカバーします。
episodic-memory（obra/episodic-memory）: 過去の会話を自動でアーカイブして、あとからセマンティック検索できるようにするツール。「あの判断、なんでそうしたんだっけ」を議事録から引ける感覚です。

つまり superpowers は「進め方の作法」、ECC は「専門作業の道具箱」、episodic-memory は「記憶」。この時点で、なんとなく役割が分かれそうな匂いがしていました。

文章だけだと分かりにくいので、図にするとこんな構成です。

課題: スキルが278個あると、逆に散らかる

問題は、ECC のスキルが description 依存でモデルに自動起動されることです。放っておくと、計画も実行もレビューも ECC 側の色々なスキルが勝手に立ち上がってきて、superpowers の「型」と競合します。同じ「計画」でも superpowers の brainstorming と ECC の plan 系スキルがバッティングする、といった具合です。

かといって、ECC のプラグインファイルを直接書き換えて特定スキルを止めるのは筋が悪い。プラグインを更新するたびに上書きされて消えるからです。列挙式で「これとこれを無効化」と書き並べても、ECC が新しいスキルを追加した瞬間にドリフトします。

なので考えたのは、「どっちを主にして、どう線を引くか」を、更新に強い形で決めることでした。

決めたこと: superpowers を背骨に、ECC を専門ライブラリに

最初に選択肢を並べて比べました。

選択肢	判定	理由
superpowers 一本	見送り	開発方法論に特化していて、調べ物や日々の記録などをカバーしない
ECC 一本	悪くない	単体で広い範囲＋独自ワークフロー＋学習機構まで持つ。頭の中のモデルが1つで済む
superpowers ＋ ECC	採用	進め方の規律は superpowers が一番洗練されている。ECC は専門ライブラリに徹してもらう

ECC 一本が一番シンプルなのは分かっていました。それでも併用にしたのは、開発の「進め方」の完成度は superpowers に軍配が上がると感じたからです。設計ゲートの固さ、レビューの二段構え、worktree の扱い――このあたりは譲りたくなかった。追加のコストは、後述する「原則1文」だけで済む、という見立てもありました。

役割はこう固定しました。

superpowers = 背骨（1つだけ）: 計画 → 実行 → 検証の規律を仕切る
ECC = 専門ライブラリ: 言語別レビュー、セキュリティなどのドメイン作業に徹してもらう
episodic-memory = 会話の記憶: 過去の会話をあとから検索できるようにする

棲み分けは「原則1文」で固定する

ここがこの記事で一番言いたいところです。

棲み分けを列挙式で書くとドリフトする、と書きました。なので、グローバルの CLAUDE.md に原則を1文で書く方式にしました。中身はこんな感じです。

- ワークフローの背骨は superpowers。計画→実行→レビューは superpowers を使う。
- ECC スキルは専門作業（言語レビュー/セキュリティ等）でのみ使い、
  ワークフロー駆動には使わない。
- レビュー時は superpowers から ECC 言語別reviewer / security-reviewer を委譲呼び出しする。
- Git/PR は自作スキルを使う。
- 記憶: 会話再生=episodic-memory / 本能=ECC instincts / 正典=自作ワークスペース。

ポイントは、「plan-orchestrator を止めて、multi-plan を止めて……」という個別のスキル名を書かないことです。「進め方＝superpowers、専門作業＝ECC」という原則だけ書いておけば、ECC が新スキルを100個足してきても、その原則の側に自動で振り分けられる。設定を一度やったら基本さわらなくていい、いわゆる set-once-forget が成立します。

大量のスキルを持つハーネスを破綻させないコツは、スキルを1個ずつ手なずけることではなく、主従と線引きを1文に凝縮しておくことでした。

分かりやすいのがレビューです。「いつレビューするか」は superpowers が仕切って、実際にコードを見る中身は ECC の言語別レビュアーに委譲する。しかもこの最終レビューは superpowers が自動で立ち上げるので、原則を1文書いておくだけで、そのタイミングに ECC の深いレビューがちゃんと差し込まれます。ここでも set-once-forget です。

記憶をどこに置くか（記憶の三層）

もう一つ整理したのが記憶です。ひとくちに「記憶」といっても、性質が違うものを3つに分けて併用しています。

記憶	担当	何を覚えるか
正典（意図した記録）	Joifup（自作の md ワークスペース）	自分で選んで書いたノート。grep できて可搬
エピソード記憶	episodic-memory	過去の会話そのもの。「あのときどうやったっけ」を検索できる
手続き記憶（本能）	ECC instincts	繰り返しから抽出された行動のクセ＋確信度

正典を担う Joifup は、自分で作っている md ベースのワークスペースです。ノートやタスクを Markdown＋フロントマターで書いて、ローカルの DuckDB に載せて検索できるようにしています。記憶の「正典」をここに寄せているのは、開発以外の文脈でも同じ地図で動けるようにするためです。

面白かったのは instincts で、PreToolUse などのフックが裏で操作を観測して、バックグラウンドの安いモデルがパターンを抽出し、繰り返すほど確信度が上がっていく仕組みでした。「この人は新しい関数を書くとき関数型を好む」みたいなクセが、普段は意識しないところで勝手に溜まっていきます。エピソード記憶が「出来事の生ログ」、instincts が「そこから抽出した習慣」で、層が違うから両方入れる意味がある、という整理に落ち着きました。

ハマったポイント

ここからが本題みたいなものです。構成そのものより、実際に組むときに引っかかった落とし穴のほうが役に立つと思うので、正直に書きます。

1. いきなりフックに止められる（GateGuard）

ECC を入れて最初に Bash を叩いた瞬間、GateGuard というフックに止められました。「最初のコマンドを実行する前に、ユーザーの要求とコマンドの目的の2点を提示せよ」と要求してくるゲートです。

何が起きたのか一瞬分からず戸惑いましたが、これは事実確認を強制する安全機構でした。要求と目的をちゃんと言語化して再試行したら通ります。しつこいと感じるなら環境変数で無効化もできます。安全側に倒した設計だと分かってからは、むしろ納得しました。

2. コスト通知に一瞬ビビる

作業していると、セッションの累計が「$45」「$65」みたいなコスト警告として出てきて、サブスクで使っているのに、これは一体何の請求だと少し焦りました。

調べたら、ECC のコンテキスト監視フックがトークン量 × API の従量単価で計算した「参考見積り」でした。サブスクなら実際に課金されるわけではない。閾値も WARNING が $10、CRITICAL が $50 に設定されていました。分かってしまえば便利な指標なのですが、初見はちょっと心臓に悪かったです。コスト警告だけを消す環境変数があったので、それで黙らせました。

3. settings.json が symlink で編集を拒否される

そのコスト警告を消そうと settings.json を編集しにいったら、symlink だからと編集を拒否されました。dotfiles で管理していて、~/.claude/settings.json が実体へのリンクになっていたんです。

readlink でリンク先の実体パスを解決して、そっちを直接編集したら通りました。ちなみにこの手の設定は次のセッションから反映なので、その場で効かないのも一瞬「あれ効いてない?」と勘違いするポイントでした。

やってみてどうだったか

正直、整備した日はかなり満足度が高かったです。朝から夕方までほぼノンストップで環境をいじり倒して、その日の終わりに「明日からの開発フローがちょっと楽しみかもしれない」と思えました。

設計として効いたなと思うのは2つです。

1つ目は「計算と永続化を分ける」こと。 ECC を自作スキルの内部から呼び出すラッパー方式は、実は品質が劣化しやすい（呼ぶ側が前後に指示を割り込ませて出力を歪める）と分かりました。なので ECC は無改変のまま「計算」に徹してもらい、その成果物をファイルに書き出す。永続化は別のスキルが担当する。この間をファイルの受け渡しで繋ぐと、お互いのコンテキストが混ざらず綺麗に分離できます。

2つ目は「機械が扱う面は英語、人が読む面は日本語」という言語の切り分け。コミットメッセージのように機械が扱う面は英語（フレームワークのネイティブに合わせて綱引きしない）、PR 本文やノートのように人が読む面は日本語、と割り切ったら迷いが消えました。

副産物として気づいたのは、しっかりタスクを起票してから進めるほうが達成感がある、ということです。一日でどのタスクを終えられたかが可視化できるので、モチベーションも保ちやすい。ツールの話をしていたはずが、最後は「自分がどう働くと気持ちよく続けられるか」の話に着地したのは、ちょっと意外でした。