スター20万級のエージェント拡張を ~/.claude に入れてよいか、サプライチェーン監査した記録

この記事の問い

AI コーディングエージェント向けの拡張（skill、plugin、MCP サーバ）が GitHub で短期間に大量の star を集めている。
インストールは npx 一発で済み、置き場所は ~/.claude のような自分のホーム配下になる。
この手軽さの裏で、拡張は利用者自身の権限で動く。
postinstall スクリプト、常時起動するフック、自動で立ち上がる MCP サーバは、いずれも任意コード実行の入口になりうる。

そこで、20万 star 級の人気拡張2本を実際にローカルへ導入する前に、read-only で clone してサプライチェーン監査を行った。
題材は公開リポジトリ2本（Superpowers と ECC）で、数値はすべて GitHub API で実測したものを使う。
監査の構造は、CISSP のサプライチェーンリスク管理の文脈にも照らして整理する。

結論を先に置く。

star の絶対数は採用判断に使えない。
判断材料になるのは「拡張が導入時と稼働中に何を実行するか」であり、それはコードを読まないと分からない。

なぜ star を信じてはいけないか

人気拡張の star は数万に達し、最上位は20万に届く。
だが star は買えるし、awesome-list 経由のバイラルや FOMO でも膨らむ。
本気の関与が要る指標、すなわち watcher と issue を見ると、規模の実態が分かる。

GitHub API で実測した値は次のとおりだった。

Superpowers : 212,947★  /  watcher   809  /  issue 291
ECC         : 199,280★  /  watcher   986  /  issue  38

star が20万あっても、その挙動を追っている watcher は1000人に満たない。
issue を立てて実際に使い込んでいる人数はさらに少ない。
star と fork は見栄えの指標として膨らみやすく、watcher と issue は手間がかかるぶん実態に近い。
表示される人気に対して、実アクティブ利用者は桁違いに小さい。

star の増えかたも、タイムスタンプを実測すると性格が分かれた。

Superpowers : 100★=2日   →  1万★=2か月  →  4万★=3.7か月   （加速する有機カーブ）
ECC         : 1万★=3日   →  4万★=19日                      （異常に速い）

Superpowers は時間とともに加速する有機的なカーブを描き、一括投下の痕跡がない。
ECC は1万 star を3日で集めるなど突出して速いが、stargazer は古い実在アカウントで、作者の affaan-m も実在する（Anthropic×Forum Ventures ハッカソン優勝者、follower 6,288）。
つまり bot による捏造ではない。
速いのは hype と FOMO による現象で、star が「品質と採用の証明」にならない点は両者に共通する。

star は安全性とも実用性とも相関しない。
採否は別の根拠で決めるしかない。

何を監査したか

拡張が危険になるのは、利用者の権限で勝手にコードを動かすときである。
そこで、導入時と稼働中の挙動を次の観点で読んだ。

• 配布元と実在性：公式マーケット掲載の有無、作者アカウントの実在、コミット分布
• インストール時実行：package.json の scripts、postinstall、curl | bash や eval の有無
• フック：どのイベント（SessionStart、PreToolUse、PostToolUse、Stop）に、いくつ仕掛かるか
• MCP サーバ：自動起動するか、npx -y で外部パッケージを取りに行くか
• 秘密情報へのアクセス：.env や認証情報を読むか、redact するか
• 外部通信：テレメトリや外向きの HTTP があるか、localhost 限定か
• 依存ツリー：runtime 依存の数と素性

この観点で2本を読むと、悪性かどうかでは差がつかず、稼働時の挙動で性格が大きく分かれた。

結果1：Superpowers は導入時も稼働中も静かだった

Superpowers は、監査した範囲で危険な挙動が一つもなかった。

package.json には scripts も postinstall もなく、依存はゼロだった。
インストールしてもコードは一切走らない。
フックは SessionStart の1個だけで、skill の Markdown をコンテキストに注入するにとどまる。
PreToolUse、PostToolUse、Stop のフックはなく、コマンド実行も権限付与もない。
外部通信もなく、付属の brainstorm サーバは 127.0.0.1 に閉じている。

加えて、Anthropic の公式マーケットに掲載され、752,120 インストールという独立した実績がある。
公式審査を通過した配布経路があること自体が、ひとつの安全シグナルになる。

インストール時にコードを実行せず、フックは注入の1個だけ、外部通信もない。
これがローカル拡張に求めたい最小の挙動である。

結果2：ECC は無害だが「放流型」だった

ECC は、悪性ではないが性格が真逆だった。

まず悪性の兆候はない。
postinstall は echo のバナー表示だけで、remote-exec、curl | bash、eval のいずれもない。
外向き通信はほぼゼロで、唯一の urllib はユーザが明示的に import したときだけ動き、テレメトリもない。
秘密情報の扱いはむしろ防御的で、.env の読み取りをブロックし、秘密を redact する。
既知悪性バージョンの blocklist と AWS メタデータの exfiltration 検知を行う IOC スキャナまで自前で同梱していた。
runtime 依存は3個と少なく、素性もクリーンだった（残り214は開発用依存）。

問題は安全性ではなく、稼働時の重さと侵襲性にある。
ECC は * マッチの PreToolUse と PostToolUse を含め、常時稼働するフックを20個以上仕掛ける（observe、learn、cost、notify など）。
さらに起動時に npx -y で MCP サーバを6個、自動で取りに行って立ち上げる。
無害だと確認できても、これだけのフックと外部取得を常時動かす構成は、攻撃面を自分から広げることになる。

「悪性か」と「導入してよいか」は別の問いである。
ECC は前者では白だが、後者では npx -y の自動取得とフックの物量という攻撃面の広さで引っかかる。

CISSP の観点での位置づけ

この監査は、CISSP の知識体系でいうと二つの領域にまたがる。

ひとつは Domain 1 のサードパーティおよびサプライチェーンのリスクマネジメントである。
star のような人気指標を採用根拠にせず、配布元と実在性を確かめ、稼働時の挙動で受容可否を判断する流れは、そのままサプライヤ評価の縮図になっている。

もうひとつは Domain 8 のソフトウェア開発セキュリティである。
postinstall による任意コード実行、フックを使った永続化、npx -y での外部パッケージ自動取得は、いずれもソフトウェアサプライチェーン攻撃の典型的な入口である。
ECC が同梱していた IOC スキャナ（既知悪性バージョンの blocklist と AWS メタデータ exfiltration の検知）は、CI に組み込む検知の具体例として参考になる。

エージェント拡張は「便利なツール」だが、導入する側から見ればコードを実行するサプライヤである。
評価のレンズは、新しいベンダを採用するときと変わらない。

まとめ

20万 star 級の人気拡張2本を、ローカルへ入れる前に監査した。

• star、fork の絶対数は採用判断に使えない。watcher と issue 比、star の増加カーブのほうが実態に近い。
• 採否を決めるのは挙動である。インストール時実行、フックの種類と数、MCP の自動起動、秘密へのアクセス、外部通信を、コードを読んで確かめる。
• 悪性でないことと、導入してよいことは違う判断になる。Superpowers は安全性も導入適性も満たし、ECC は安全性だけを満たした。

人気拡張をワンライナーで入れる前に、clone して読む手間を惜しまないことが、自分のホーム環境を守る最小の防御になる。