Claude Codeの公式カタログ全件を実測：Anthropic製は一部だけ

関連記事としては Blog200Kが1Mになった3日間、Claude Code 2.1.74〜76で起きたことClaude Code v2.1.74〜76の3日間で何が変わったか。メモリリーク修正・セキュリティパッチ、Opusコンテキスト200K→1M（同一料金）、MCP Elicitation追加まで実運用視点でまとめ。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

Claude Code で /plugin と打つと、拡張機能がずらりと並びます。データベース、監視、決済、デザインツール。名前を見ているだけでも楽しい。

ですが、そのうちの一つを入れようとして、手が止まりました。これ、誰が作ったものなんだろう。

公式のカタログに載っているのだから大丈夫だろう、という気もします。一方で、拡張機能というのは自分のパソコンの中で動くものです。全部疑ってかかると、そもそもクラウドサービスを使うこと自体を否定することになってしまう。かといって全部信じるのも、それはそれで雑です。

判断の物差しが欲しくなりました。そこで、カタログに登録されている全件を機械で数えて、提供元を確定させることにしました。

まず勘違いしていたことがあります。

このカタログは確かに Anthropic が運営しています。ですが、中身の大半は他社と個人が、自分たちの GitHub リポジトリから配布しているものでした。Anthropic 自身が作ったものは、全体の一部にとどまります。

例えるなら、百貨店です。看板は百貨店のものですが、並んでいる商品を作っているのは各メーカーで、百貨店が一つひとつの中身を検品しているわけではない。

これは悪いことではありません。Google も AWS も SAP も Shopify も、自社の公式アカウントから自社製品向けの拡張機能を出しています。むしろ健全です。ただ、「公式カタログにあるから公式が保証している」という読み方は事実と違う、ということです。

では提供元はどこを見れば分かるのか。カタログには author（作者）という欄があります。最初はこれを使おうとしました。

使えませんでした。理由は二つです。

一つは、相当数のエントリで author 欄が空だったこと。もう一つが本質的で、author 欄は自己申告の自由記述だということです。誰でも好きな文字列を書けます。企業名を名乗ることも、技術的には妨げられていません。

「企業名らしいかどうか」を機械で検査する方法もありません。結局「何か書いてあるかどうか」になってしまい、それは素性の判定になっていない。

そこで発想を変えました。自己申告できない情報は何か。

一つだけありました。コードがどこに置かれているかです。

github.com/cloudflare/ の下にコードを置けるのは Cloudflare だけです。ここは名乗りではなく、GitHub のアカウント管理という外形的な事実で守られています。他人が勝手に押し込むことはできない。

そこで、カタログの各エントリが指しているリポジトリの URL から、GitHub の組織アカウント名だけを取り出し、その組織が実在する企業のものかを一つひとつ照会していく方式にしました。名乗りは一切見ない。置き場所だけを見る。

この方針で全件を振り分けた結果が、三つの区分です。

1. Anthropic公式 — Anthropic 自身が作り、自身のリポジトリに置いているもの
2. 企業が自社製品として提供 — その企業自身の GitHub 組織から公開されているもの
3. 個人・コミュニティ提供 — 上記以外。個人アカウント、周辺組織、確認材料が足りないもの

なお、第3区分に「怪しい」という意味は持たせていません。検証の状況を述べているだけです。実際、利用者数の上位には個人開発者の作品が入っており、区分と人気はまったく相関しませんでした。

機械で判定するにあたって、危うい罠がいくつかありました。同じことをやる人のために書いておきます。

一つめ。ホームページのURLから提供元を推定してはいけない。

一部のプラグインは、Anthropic の配布リポジトリに同梱される形で置かれています。この場合、ホームページ欄が Anthropic の URL を指します。ここから提供元を拾うと、Microsoft 製や Google 製の拡張機能に「Anthropic公式」の札が立ちます。他社の製品を別の会社の名前で紹介することになるので、この企画で起こしうる最悪の表記事故です。コードの側で禁止し、テストで固定しました。

二つめ。GitHub の「認証済み」表示は使えない。

組織アカウントには認証バッジが付くことがあります。これを条件にしようとしたのですが、実測したところ Cloudflare も Stripe も MongoDB も Spotify も PayPal も Oracle も未認証扱いでした。これを条件にすると、信頼して使いたい提供元ほど下位に落ちてしまう。

三つめ。組織名の突き合わせを部分一致でやると事故る。

組織名と製品名を照らし合わせる処理を部分一致で書いたところ、ある組織名に含まれる「security」という語がたまたま一致して、本来なら人が確認すべき提供元が自動で昇格しました。security、labs、cloud、data のような汎用語を照合対象から外して修正しています。これは「名乗れば通ってしまう」のと同じ穴でした。

提供元とは別に、もう一つ数えたものがあります。その拡張機能が何を持っているかです。

拡張機能には四種類の部品があり、権限の強さがはっきり違います。

• フック — 呼ばなくても、条件が揃うと自動でコマンドが実行される。いちばん強い
• 外部サービス接続（MCP） — 外のサービスにつながる。作業内容が外に出る経路になりうる
• エージェント・スキル — 指示文。悪意ある指示が混ざれば誘導される余地はある
• コマンド — 呼んだときだけ動く。比較的おとなしい

数えてみると、自動で動く仕組みを持つものが一定数あり、外部サービスへつながるものは全体の四割を超えていました。

ここが実務的な結論です。提供元の区分と、この「何を持っているか」は別の軸です。企業製でもフックを持つものはありますし、個人製でも呼んだときしか動かないものはある。入れる前に見るべきは、名前の知名度ではなくこの二つの軸でした。

全件に日本語の説明を付ける作業も生成モデルにやらせたのですが、ここでも一つ学びがありました。

説明を書かせる役と、その説明が正しいかを採点する役を、別のモデルに分けました。ところが採点役に、書く役と同じ材料を渡していなかったのです。

結果、書く役だけが知っている正しい情報（実在する機能の名前など）が、採点役から「原文にない事実をでっち上げている」と機械的に弾かれ続けました。極端な例では、プラグイン名そのものに含まれている製品名について「原文に言及がない」と指摘されたり、実在する製品名を「実在しない造語と考えられる」と判定されたりしています。

検品役と作業役の持っている情報が違うと、正しい仕事が不合格になる。 人間の組織でも見かける話でした。採点の基準を作り直すこと4回、これが今回いちばん時間を食った作業です。

• 「公式カタログにある」は「公式が作った」でも「公式が中身を保証した」でもない
• 提供元の欄（author）は自己申告で、素性の判定には使えない
• 判定の土台になるのは、コードが置かれている GitHub の組織アカウントという詐称できない一点
• 入れる前に見るべき二つめの軸は、呼ばなくても自動で動くか、外部につながるか
• 全件を三区分で分類し、日本語の説明を付けた一覧を用意しました。具体的な件数や個別の提供元は、そちらでご確認ください

カタログは今後も増えていきます。数を覚えるより、物差しを一つ持っておくほうが長持ちします。

分類した一覧はこちらです。提供元の区分・持っている部品・利用者数の帯で絞り込めるようにしてあります。

▶ Claude Code プラグイン一覧（提供元で分類）

出典

• Claude Code 公式プラグインカタログ（Anthropic が運営する GitHub リポジトリ anthropics/claude-plugins-official）
• 各プラグインの提供元情報は、上記カタログが記録している配布元リポジトリの URL、および GitHub の組織アカウント情報より取得

検証日・環境

• 検証日: 2026年8月20日〜21日
• 対象: 公式マーケットプレイスに登録されている全エントリ（他のマーケットプレイスは対象外）
• 方法: カタログのローカルキャッシュから機械抽出し、提供元の組織アカウントを GitHub の公開 API で全件照会。分類ロジックは回帰テストで固定
• 日本語説明: 生成モデルで作成し、別系統のモデルで「原文にない事実の混入」を全件採点したうえで掲載

• META-MARK

• Blog200Kが1Mになった3日間、Claude Code 2.1.74〜76で起きたことClaude Code v2.1.74〜76の3日間で何が変わったか。メモリリーク修正・セキュリティパッチ、Opusコンテキスト200K→1M（同一料金）、MCP Elicitation追加まで実運用視点でまとめ。→
• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→
• BlogClaude Code の /effort 完全ガイド｜low〜maxの使い分けと『コストが増える本当の理由』Claude Code の /effort（low〜max・ultracode・auto）は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！