二千のプラグイン、誰が検査しているのか

AI Radar・トレンド読解 #2 ｜ 問題領域：エージェント・プラグインの供給網データ期間：2026-W35〜W36 ｜ 一次証拠：公開ディレクトリ二件の完全スナップショット2026-09-05

プラグインディレクトリを眺めていて、ちょうど使えそうなものを見つけた。

インストールは一行。コピーして貼って Enter。三秒で終わる。

押す直前に、ひとつ引っかかった。これは誰が書いたのか。

わからない。目録にあるのは名前と一行の説明だけだ。ソースは読んでいないし、 これからも読まない。プラグインを一つ入れるために数千行のコードを読み通す人はいない。 コンセントを買うのに内部配線を検証しないのと同じだ。

そしてそれは、入れた瞬間から自分の端末で、自分の権限で動き、自分のファイルを見る。

だから本当の問いは「このプラグインは良いか」ではない。

Enter を押す前に、誰かが自分の代わりに検査してくれたのか。

そもそも「プラグインディレクトリ」とは何か

前回こう例えた。MCP（Model Context Protocol、モデル・コンテキスト・プロトコル）が AI 世界の USB 規格なら、プラグインマーケットプレイスは電器店である。

規格が答えるのは「挿さるかどうか」。 店が答えるのは別のことだ。どれを買えばいいのか、そして売っているのは誰か。

Anthropic は二軒出している。

• `claude-plugins-official` ——公式厳選、ベンダーが審査に出したもの
• `claude-plugins-community` ——コミュニティ開放、誰でも投稿できる

どちらも GitHub 上に完全公開されている。つまり以下の数字はすべて、 筆者を信用せずに誰でも再計算できる。この点には最後に戻る。

数えた結果

数字は両リポジトリの特定コミットから取っている。コミットとは、ある一瞬の完全な 凍結スナップショットだと思えばいい。同じスナップショットを取れば同じ結果になる。

公式ディレクトリ（`anthropics/claude-plugins-official` @ `85cce03`、2026-09-04）

出しているのは誰か。Anthropic 自身が 38、Google 14、SAP 9、AWS 7。 残りは Oracle、Atlassian、Shopify、Grafana、Carta といった名前に散っている。

これは趣味人の市場ではない。ベンダーが AI の既定の道具箱に自社を差し込もうと 競っている場だ。

コミュニティディレクトリ（`anthropics/claude-plugins-community` @ `a727be1`、2026-08-24）

上流アカウントが 1,764 ということは、千七百組を超える人々がそれぞれ手を動かしている ということだ。少数のベンダーによる水増しではなく、実際に生態系が育っている。

ここまで、数字の形は前回とよく似ている。急増、出所の分散。 前回の結論は「検証している目録は存在しない」だった。同じ文をもう一度書く準備ができていた。

そして `.github/` を開いた

今週いちばんの意外はこれだった。この目録の防衛線は、想定よりはるかに整っている。

四つの仕組みがあり、すべてソースを直接読める。 一つずつ、それが止める具体的な攻撃とともに述べる。

一、版の固定 —— 「後からのすり替え」を止める

各エントリが記録しているのは「GitHub の某プロジェクトを取ってくる」ではなく、 「某プロジェクトのコミット abc123 を取ってくる」である。2,277 件中 2,274 件がこの形だ。

止める攻撃はこうだ。まず綺麗な版を出し、三か月待って数千人が入れ評判が立った頃に、 中身をこっそり有害なものへ差し替える。入れた全員が次の更新で被害を受ける。

版を固定してあれば、上流が何をしようとこちらには流れてこない。 今日入れたものは、目録が審査したものと同一である。

契約時に双方が認証謄本を一部ずつ持つのに似ている。相手が後から自分の分に書き足しても、こちらの一部とは無関係だ。

二、身元の固定 —— 「アカウント乗っ取り」を止める

これは予想していなかった。四つの中で最も精巧でもある。

ファイル名は `owner-baseline.json`。記録しているのは アカウント名ではなく、アカウント id である。

なぜそれが効くのか。こういう話だ。

alice という開発者が、多くの人に使われるプラグインを書いた。二年後に興味を失い、GitHub アカウントを削除する。`alice` という名前はこれで解放される。 >攻撃者はすぐに同じ `alice` で新規登録する。名前も URL も同一——だが別人である。 >そして「alice のプロジェクト」として有害な更新を出す。alice を信頼していた全員が沈む。

供給網攻撃の古典的手口だ。防御の要は一点にある。 アカウント名は持ち主が変わりうるが、アカウント id は変わらない。

だからある名前が別の id を指し始めた瞬間、システムはこのアカウントは持ち主が変わったと 判断し、その配下の全エントリを要再確認として印を付ける。

三、「固定しきれない部分」を捕まえる —— 個人的に最も評価する一点

版の固定は万全に聞こえるが、穴がある。

プラグインの起動コマンドが `npx some-server@latest` と書かれている場合、 実際に動くコードは起動時にパッケージレジストリから取得される。 固定したコミットの中には存在しない。

こう考えるとよい。メニューを一字も変えられないよう固定した。だがメニューの一品が「本日のシェフのおすすめ」と書いてある。メニューは変わらないのに、皿に載って出てくるものは毎日違う。 >固定したのは紙切れであって、紙切れには「外へ取りに行け」と書いてある。

目録にはこの形（`npx` / `bunx` / `uvx` / `pipx` に `@latest` や版範囲が付くもの）を 専門に検出する静的チェックがあり、検出すると「未固定の自動実行」として印を付ける。

自分の釘が届かない場所を把握したうえで、そこを塞ぎに行っている。 自らの破れ目を明示する防衛線は、隙がないと主張する防衛線よりも信頼できる。

四、アカウント生存確認とポリシースキャン

変更されたエントリごとにポリシースキャンが走り、 外部通信を行うか、追加ソフトウェアをダウンロードするかといった項目が出力される。 別に定期ジョブが上流アカウントの存続を確認している。

では読解を誤ったのか。半分は

「前回の穴はこの層にも同じようにある」と書く準備ができていた。それは誤りで、削った。

ただしソースを読み終えたあと、「ここは安全だ」と結論できない理由が二つ残った。

一、これらは既定では止めない

公式文書にそのまま書いてある。ポリシースキャンは `Non-blocking by default`—— 検出結果は黄色い警告と要約表になるだけで、実際に失敗させるには `fail-on-findings: true` を別途設定する必要がある。

浮動ランチャーの検査も同様で、既定は注記のみ、深刻度は「per-consumer」—— 使う側が自分で重く見るかどうかを決める。

こういう建物を想像してほしい。入退室管理も監視カメラも巡回警備も揃っている。だが正面の扉は開けっ放しで、見知らぬ人が入ってきても警備員は「記帳をお願いします」と言って通す。 >設備一覧は立派だ。だがその建物が安全かどうかを決めるのは、扉が閉まっているかどうかである。

仕組みの一覧は安全水準ではない。既定値が安全水準である。

二、上流がいま壊れているプラグインが 49 件ある

リポジトリには `freeze-shas.txt` がある。上流の最新版が検証を通らないため、 自動更新させず古い版に意図的に凍結したエントリの記録だ。 2026-06-13 のスナップショットで 49 件。

凍結は正しい処置だ。壊れた版を利用者に配るほうが悪い。だがこれは次を意味する。

その目録には、上流がすでに壊れた古いスナップショットを掴まされるプラグインが 49 件あり、 一覧上では他の 2,233 件と見分けがつかない。

読解

供給網の安全は、できるかどうかの問題ではない。誰が責任を持つかの問題である。

技術的には、この四つの仕組みに新発明は一つもない。版のロック、アカウント id の紐付け、 静的スキャン、生存確認——いずれも従来のソフトウェア供給網では十年以上前からある道具だ。

前回の 10.8 万件の MCP サービスに欠けていたのは 技術ではなく、その一覧全体に責任を持つ人間だった。

プラグインディレクトリにはその人がいるから、この防衛線がある。 MCP レジストリにはいないから、何もない。

同じ組織、同じ時期、同じ技術者たち——違いは所有者がいるかどうかだけである。

同じことは他所でも起きる。まったく同じ二棟の集合住宅でも、管理組合があるかないかで三年後の状態はまるで違う。違うのは建材ではない。自分ごととして扱う人がいるかどうかだ。

この読解が誤りうる箇所

1. 読んだのは設定であって挙動ではない。 仕組みの存在と既定値は確認したが、 実際に阻止された事例は一度も観測していない。 走ると書いてあるコードと、 実際に検出して止めることは別である。
2. 二つのスナップショットは 11 日ずれている（公式 09-04、コミュニティ 08-24）。 規模の比較（291 対 2,282）には影響しないが、成長率は算出していない。 時点が一つしかないためである。
3. 49 という数字は 2026-06-13 のスナップショット、三か月前のものだ。 修復済みの上流もあるはずで、実数はより低い可能性も、高い可能性もある。

あのインストールコマンドに戻る

最初の問いはこうだった。Enter を押す前に、誰かが自分の代わりに検査してくれたのか。

電器店の裏側を一通り見た答えは、こうなる。

検査している人はいる。しかも想定より細かく見ている。 ただしその結果は壁に貼り出すだけで、扉は施錠していない。

自分にとってはむしろ受け入れられる。判断を他人に委ねるつもりは元からない。 四道フィルターが存在する理由がまさにそれだ。目録の仕事は情報を開くこと、 選別は自分の仕事である。

考えを変えさせたのは別の点だった。

上記の数字をすべて書けるのは、この二つの目録がスキャン規則も 49 件の凍結リストも含めて、 まるごと GitHub 上に公開されているからだ。 誰かの主張を信じる必要がない。取ってきて、自分で数えた。

壊れたエントリが何件あるかを外部に数えさせる目録は、 安全だと主張する目録よりはるかに信頼できる。

あなたにとっての意味

プラグインを入れる前に、三つ確かめてほしい。この三つを目録は代わりに問わない。

1. 起動コマンドに `@latest` が入っていないか。 入っていれば固定できない。固定したのは紙切れであって、取ってくる中身ではない。 目録は印を付けるが、既定では止めない。
2. 上流アカウントは生きているか。 最終更新を見る。凍結リストの 49 件は、外見からは判別できない。
3. 外部通信や追加ソフトのダウンロードを行うか。 スキャン結果にその二項目がある。見に行くこと。

もう一つ、最も飛ばされやすい問いがある。

入れる理由は、自分にその痛みがあるからか。それとも凄そうに見えるからか。

先月、四道フィルターを通した七つのツールのうち一つは四道すべてを通過したが、 採用しなかった。ProfitVision LAB にそれが解く問題が存在しなかったからだ。

道具が良いかどうかと、自分に必要かどうかは、別の問いである。

出典

いずれも公開リポジトリであり、コミットがそのまま引用元となる。

• `anthropics/claude-plugins-official` @ `85cce03`（2026-09-04）
• `anthropics/claude-plugins-community` @ `a727be1`（2026-08-24） —— `.github/actions/scan-plugins/`、`.github/owner-baseline.json`、`.github/freeze-shas.txt` を参照

本記事は ProfitVision LAB の AI Radar と開発チームの共同制作による。 候補プール、フィルター判定、および完全な証拠チェーンは ai-radar registry にて公開している。