claude-plugins-community解説｜Anthropic公式プラグイン市場2,282件を中身から読む

Claude Codeのプラグインをどこから入れるかは、そのまま供給網（サプライチェーン）の問題になる。プラグインはgitリポジトリからcloneされてローカルに展開され、スキルやフックとしてエージェントの振る舞いに入り込むからだ。その配布経路として、Anthropicは anthropics/claude-plugins-community というリポジトリを公開している。

READMEは短く、「コミュニティ・プラグイン・マーケットプレイスの読み取り専用ミラー」とだけ書かれている。だが実体である marketplace.json とgit履歴、そして .github/ 以下の自動化を読むと、審査基準・固定方式・削除理由まで公開されていることが分かる。この記事ではリポジトリをcloneして、その中身を数字で確認する。数値はすべて2026年8月23日時点の実測値である。

この記事ではClaude Codeのプラグイン配布経路を扱います。Claude Code本体の設定・運用全般は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き をご覧ください。

claude-plugins-communityとは——PRが自動クローズされる「読み取り専用ミラー」

このリポジトリはGitHub上で開発されているわけではない。READMEに明記されているのは次の3点だ。

・.claude-plugin/marketplace.json がインストール可能なコミュニティ・プラグインの一覧そのものであること
・Anthropic社内のレビューパイプラインから夜間同期されていること
・掲載されている各プラグインは claude.ai 経由で申請され、自動セキュリティスキャンを通過し、配布を承認されたものであること

そして「このリポジトリに直接開かれたプルリクエストは自動的にクローズされる」と書かれている。これは方針の表明にとどまらず、.github/workflows/close-external-prs.yml として実装されていた。pull_request_target の opened / reopened で発火し、投稿者を見てクローズする。自動化自身が開くPRだけが例外として除外されている。

使い方は1行で足りる

導入手順はREADMEに書かれている通り、マーケットプレイスを追加してからプラグイン名で入れる。

# マーケットプレイスを追加する
claude plugin marketplace add anthropics/claude-plugins-community

# プラグインを入れる（@claude-community が上で追加した市場を指す）
claude plugin install <plugin-name>@claude-community

入れる前に中身を確認したいなら、台帳を直接読むほうが早い。JSONなので jq で引ける。

# 台帳だけを取得する（リポジトリは軽い）
git clone --depth 1 https://github.com/anthropics/claude-plugins-community
cd claude-plugins-community

# 登録件数を数える
jq '.plugins | length' .claude-plugin/marketplace.json

# 特定のプラグインのソースURLと固定SHAを見る
jq -r '.plugins[] | select(.name=="<plugin-name>") | [.name, .source.url, .source.sha] | @tsv' \
  .claude-plugin/marketplace.json

2,282件の中身を数える——提供元1,864アカウント、89%が1本だけ

marketplace.json をパースして構造を数えた結果はこうなった。

説明文の長さのばらつきも大きい。中央値は274字だが、最長は munin-memory の6,581字で、2,000字を超えるものが8件ある一方、100字未満が220件（9.6%）ある。台帳の説明欄をREADME代わりに使っている登録と、一行で済ませている登録が同居している。CLIやUIで一覧を眺めるときは、説明文の厚さが品質の指標にはならない点に注意したい。

git-subdir が401件あるのも実務的に重要だ。これは1つのリポジトリの中の特定ディレクトリだけをプラグインとして切り出す指定で、複数プラグインを1リポジトリで管理している提供元がそれなりにいることを示す。裏を返せば、そのリポジトリのどこかが侵害されたとき、影響範囲は登録された1件にとどまらないことになる。

リポジトリ内に直接置かれた5件

台帳の大半は外部リポジトリを指すが、5件だけソース指定が文字列で、実体がこのリポジトリ内に置かれている。eli5 / quickdesign / testdino / tres-finance-plugin と、cowork-plugin-management だ。ディレクトリを開くと skills/<name>/SKILL.md と .claude-plugin/plugin.json が入っている。SHA固定が「なし」に分類される5件はこれで、外部を指していない以上ピン留めの対象にならない。なお eli5 については ELI5スキル解説 で個別に扱っている。

台帳にはもう1つ renames というフィールドがあり、qodo-skills → qodo、wordpress-com → build-with-wordpress、auth0-sdks → auth0、twilio → twilio-developer-kit の4件が記録されている。改名しても旧名でのインストールが壊れないようにするリダイレクト表で、配布台帳として運用されている証拠のひとつだ。

ベンダー名がついていても公式とは限らない

削除理由に「無関係なブランド名の使用」が8件あった以上、現行の台帳にも同じ性質のものが残っていないかは確認したくなる。実在サービス名を冠する登録を抜き出して homepage を見ると、公式配布とサードパーティ製が混在していた。

サードパーティ製が悪いという話ではない。公式が出していない領域を埋める良質なプラグインはあるし、審査自体は通っている。ただ、「Shopifyのプラグインを入れた」つもりで実際には個人開発のものを入れているという取り違えは起こりうる。入れる前に jq で1行確認しておけば防げる。

# 名前で引いて、提供元とhomepageを確かめる
jq -r '.plugins[] | select(.name|test("shopify"))
       | [.name, .source.url, .homepage] | @tsv'   .claude-plugin/marketplace.json | column -t -s$'\t'

homepage がGitHub以外の独自ドメインを指す登録は790件（34.6%）あった。自社サイトを持つ提供元がそれなりにいる一方、残る約65%はGitHubリポジトリがそのまま窓口になっている。Claude Code プラグインの供給元は、企業と個人がフラットに並んだ市場だと考えたほうが実態に近い。

成長は4月で止まっていた——git履歴で見る収録数の推移

marketplace.json を触ったコミットは2,245件ある。各時点のファイルを復元して登録件数を数えると、成長曲線が出る。

立ち上げから約3か月で2,200件に達したあと、6月以降は2,200〜2,300の帯で横ばいになっている。8月は削除が新規登録を上回って純減した。市場が飽和したのか、審査の通過率が下がったのかは公開情報からは判断できないが、「毎月増え続けている」わけではないことは履歴から確認できる。

コミットの大半はSHAの更新

2,288件のコミットのうち、2,166件が bump(<プラグイン名>): <旧SHA> → <新SHA> (#PR番号) という形式だった。対象となった個別プラグインは715件で、全2,282件の31.3%にあたる。

# SHA更新コミットの数と、対象プラグインの数を数える
git log --format="%s" | grep -c "^bump("
git log --format="%s" | grep -oP '^bump\(\K[^)]+' | sort -u | wc -l

つまりこの市場の日常運用は、新規追加ではなく既存プラグインのピンを1件ずつ進める作業でできている。upstreamが更新されても台帳は自動で追いかけず、1件1件がレビュー可能なPRとして現れる設計だ。

審査の中身——セキュリティ審査プロンプトが全文公開されている

最も価値がある発見はここだった。.github/actions/scan-plugins/policy/prompt.md に、プラグイン審査に使われているプロンプトの全文が置かれている。冒頭は “You are a security reviewer evaluating a Claude Code plugin.”（あなたはClaude Codeプラグインを評価するセキュリティレビュアーです）で始まる。審査そのものをClaudeが実行している。

宣言されていないファイルこそ読め、と指示している

このプロンプトで最も実務的な部分は、走査範囲の指定だ。plugin.json / .mcp.json / skills/ / agents/ / commands/ / hooks/ といった宣言されたサーフェスに加えて、.claude/ などのドットディレクトリ、scripts/、examples/、tests/、そしてツリー内のあらゆる .ts/.js/.mjs/.py/.sh/.go を読めと明示している。

理由も書かれている。gitソースから導入されたプラグインはリポジトリ全体がユーザーのディスクにcloneされるため、.claude/ 内のコードはClaude Codeに自動ロードされないとしても、同梱され、到達可能であり、エージェントが実行するよう誘導されうる——ロード可能な別のSKILL.mdがそれを実行するよう指示することさえある、という説明だ。プロンプトは「宣言されたサーフェスでないことはファイルを読み飛ばす理由にならない」と結んでいる。

主眼は「クロスサービスの資格情報流出」

もう1つの中心は資格情報の扱いで、ハードコードされた秘密とは明確に区別されている。探すべきは、資格情報ストアからユーザーの生きた秘密を読み、その資格情報が属するサービスとは別のサービスへ送るコードだ。

「プラグインがその資格情報をどう扱っているつもりか」ではなく「その資格情報の名前が示すサービスと、送信先のサービスが一致しているか」で判定する、という基準の立て方は明快だ。開発者向けセキュリティの観点では、自分のCI設定やスキルを点検するときにもそのまま流用できる。

42件の削除理由——公開されたモデレーション記録

掲載後に降ろされたプラグインもある。git履歴のコミットメッセージには、削除の理由が明示的に書かれていた。2026年6月30日から8月12日までを集計すると計42件になる。

注目したいのは「無関係なブランド名の使用」8件だ。実在企業の名前を冠しながらその企業とは無関係なプラグインが、8件まとめて降ろされている。パッケージレジストリで繰り返されてきたタイポスクワッティング・ブランド詐称と同じ問題が、プラグイン市場でも起きていることになる。

「フォークからのvendoring」2件も同種の警戒だ。原作者のリポジトリではなくフォークを参照している登録は、原作者が知らないところで内容を差し替えられる余地を残す。

# 自分が入れているプラグインが、今も台帳に載っているか確認する
git -C claude-plugins-community pull --quiet
for p in $(claude plugin list --format=name 2>/dev/null); do
  jq -e --arg n "$p" '.plugins[] | select(.name==$n)' \
    claude-plugins-community/.claude-plugin/marketplace.json >/dev/null \
    && echo "OK      $p" || echo "NOT-LISTED  $p"
done

claude-plugins-communityの供給網防御——SHA固定・アカウント同一性の監視・9つの不変条件

.github/actions/ には4つの自作アクションが置かれていて、それぞれが供給網の別の穴を塞いでいる。

アカウント名の再取得を検出する仕組み

owner-liveness-sweep が検出するもののうち、最も重要なのが identity_changed だ。

これは、記録されている提供元のログイン名が以前と違うGitHubアカウントIDに解決されるようになった状態を指す。GitHubのアカウントIDはアカウントの生涯を通じて安定しているため、IDが変わったということはそのログイン名がいったん解放され、別人に再登録されたことを意味する。READMEは「そのオーナー配下の全エントリは、以降のbumpの前にレビューが必要」としており、この検出だけは実行を失敗させる扱いになっている。

基準線は .github/owner-baseline.json に「ログイン名（小文字化）→ 初回記録時のアカウントID」として保存される。解決しないオーナーは基準線に入れず、報告に回す設計だ。ほかに owner_missing（削除・改名）、repo_moved（リポジトリの改名・移管）、repo_missing（削除・非公開化）も検出する。

入れる前の3分チェック

ここまでで見えた性質を、導入前の手順に落とすとこうなる。台帳が公開されているので、すべてローカルで完結する。

・提供元を見る：source.url の組織名が、そのサービスの公式組織かどうか。名前だけで公式と判断しない
・固定を見る：source.sha が入っているか。入っていれば、いま自分が入れるものは台帳に記録されたその1コミットで確定する
・同梱物を見る：審査プロンプトが警告している通り、gitソースからの導入はリポジトリ全体が手元に落ちる。.claude/ や scripts/ に何が入っているかは、インストール前にcloneして確認できる
・更新履歴を見る：そのプラグインが過去に何回ピンを進められたかは、台帳リポジトリの bump(<名前>) コミットで分かる。まったく更新されていないものは、upstreamが動いていない可能性がある

# 1) 台帳での登録内容を確認する
jq -r '.plugins[] | select(.name=="<plugin-name>")
       | "url: \(.source.url)\nsha: \(.source.sha)\nhome: \(.homepage)"' \
  .claude-plugin/marketplace.json

# 2) 固定SHAの中身を、入れる前に手元で見る
git clone --filter=blob:none <source.url> /tmp/inspect && cd /tmp/inspect
git checkout <source.sha>
find . -type f \( -name "*.sh" -o -name "*.py" -o -name "*.js" -o -name "*.ts" \)   -not -path "./.git/*" | head -40   # 同梱スクリプトを列挙する

# 3) 過去にピンが動いた回数を数える（台帳リポジトリ側で実行）
git -C claude-plugins-community log --oneline --format="%ad %s" --date=short \
  | grep -c "^.* bump(<plugin-name>):"

2番目が要点になる。インストールコマンドを叩く前に、同じSHAの中身を自分の目で確認できるのは固定方式の副産物だ。ブランチ追従の配布では「いま入るもの」が事前に確定しないため、この確認自体が成立しない。

第三者の検索ハブとの使い分け

同じ「Claudeの拡張を探す」でも、第三者の索引サイトとは役割が違う。buildwithclaudeとは｜Claude Skills・Agents・Pluginsを横断検索できる発見ハブ のようなハブはGitHub上に散在する拡張を広く索引して見つけやすくするもので、収録数はこちらより桁違いに多い。一方この公式マーケットプレイスは、審査を通ったものだけを載せる代わりに固定SHA・審査基準・削除理由を公開している。

探すのは第三者ハブ、入れるのは公式台帳、という使い分けが実態に合う。なお、Xで話題になるスキルが必ずしもここに載っているわけではない点は アンチスロップ・スキル10本を全部cloneして実測比較 で確認した通りで、話題性と公式流通は連動していない。

まとめ

このリポジトリの読みどころは、収録されているプラグインそのものよりも運用の設計が全部見えていることにある。何を固定し、何を検査し、何を理由に降ろしたかがgit履歴と .github/ に残っていて、審査プロンプトに至っては全文が読める。自分でプラグインやスキルを配布する側に回るとき、あるいは社内で拡張を審査する基準を作るときに、そのまま参考にできる水準の資料になっている。

一方で、審査を通っていることと安全であることは別だ。8月6日に16件がまとめて降ろされた事実は、掲載後に問題が見つかる経路が現に動いていることを示している。台帳は信頼の出発点としては優秀だが、終着点ではない。

参照ソース

・anthropics/claude-plugins-community — README・marketplace.json（2,282件）・git履歴。本記事の数値の大半の出所
・scan-plugins のポリシープロンプト全文 — 走査範囲・クロスサービス資格情報流出の判定基準・除外条件
・owner-liveness-sweep の README — identity_changed などの検出クラスと基準線の運用
・validate-plugins の README — I1〜I9の不変条件と claude plugin validate の位置づけ
・commit f4c9452（本記事が集計した時点のHEAD） — 2,282件・2,288コミットを数えたリビジョン