Claude Code でプラグイン機能を使おうと /plugin を開いたとき、ずらりと並ぶプラグインを前に手が止まった経験はないでしょうか。「公式」「コミュニティ」「サードパーティ」といった出所の違う項目が混在しているように見え、どれを・どのマーケットプレイスから入れれば安全なのか、判断材料が見当たらない。チームに導入するとなれば、なおさら「なぜそれを選んだのか」を説明できる根拠が欲しくなります。
この迷いの背景には、「公式マーケットプレイスとは具体的に何を指し、どこまで信頼してよいのか」という情報の不足があります。プラグインのおすすめランキングや作り方ガイドは数多くあっても、「どのディレクトリから入れると安全か」「公式に載っていれば全部安全と考えてよいのか」という意思決定の軸に正面から答える情報は意外と少ないのが実情です。
その判断の起点になるのが、Anthropic が公式に運用するプラグインのカタログ「claude-plugins-official」です。これは個別のプラグインではなく、Claude Code 向けの高品質なプラグインをまとめた「マーケットプレイス（カタログ）」にあたります。仕組みを理解すれば、「どこから・何を・どの程度の信頼度で」導入すればよいかを自分で判断できるようになります。
本記事では、claude-plugins-official が何のリポジトリなのか、内部プラグインと外部プラグインがどう区別されているのか、コミュニティ版とは何が違うのか、そして「公式＝すべて安全」ではないという線引きまでを、GitHub 上の一次情報をもとに整理します。なお本記事はインストールや動作確認を行わず、公開ドキュメントと GitHub API のデータに基づいて構成しています。
claude-plugins-official とは｜Claude Code の公式プラグインマーケットプレイス
claude-plugins-official は、Anthropic が管理する Claude Code 向けプラグインの公式ディレクトリです。GitHub のリポジトリ説明では「Official, Anthropic-managed directory of high quality Claude Code Plugins.（高品質な Claude Code プラグインの、Anthropic が管理する公式ディレクトリ）」と記載されています（anthropics/claude-plugins-official）。
最初に押さえておきたいのは、これが個別のプラグインそのものではなく、複数のプラグインをまとめた「マーケットプレイス（カタログ）」であるという点です。Claude Code でプラグインを探すとき、このカタログを経由して各プラグインにアクセスする構造になっています。検索の出発点で混乱しがちな「これは1つのツールなのか？」という疑問は、ここで解消できます。
リポジトリの基本情報を整理すると次のとおりです（数値は 2026年6月8日時点）。
項目 | 値 |
|---|---|
owner/name | anthropics/claude-plugins-official |
説明 | Official, Anthropic-managed directory of high quality Claude Code Plugins. |
主要言語（GitHub 表示） | Python |
ライセンス | Apache-2.0 |
スター数 | 29,584 |
フォーク数 | 3,180 |
最終更新（pushed_at） | 2026-06-08 |
スター数が約 3 万に達していること、最終更新が当日付であることから、関心の高さとメンテナンスの活発さがうかがえます。アーカイブ化（開発停止）やフォーク（派生）ではなく、Anthropic 本体が現役で管理している公式リポジトリです。
ひとつ注意したいのが、GitHub 上の主要言語が「Python」と表示されている点です。これはディレクトリ運用や検証に使われるスクリプトが Python で書かれているためで、「Python 製のツール」という意味ではありません。プラグインのカタログ実体や個別プラグインの定義は、主に JSON や Markdown で記述されています。「Python のライブラリを入れる」といった誤解をしないよう、ここは切り分けて理解しておくと安全です。
そもそも Claude Code プラグインとは｜何を拡張する仕組みか
公式マーケットプレイスを使いこなす前に、「そもそもプラグインが何を拡張するものか」を押さえておくと、カタログに並ぶ各項目の意味が読み取りやすくなります。
プラグインの構成要素
Claude Code のプラグインは、スキル・スラッシュコマンド・エージェント・フック・MCP サーバー・LSP サーバーといった拡張機能を、ひとつにまとめて配布できる自己完結したディレクトリです。公式ドキュメントによれば、プラグインは次のような要素を束ねられます（Claude Code 公式プラグインドキュメント）。
要素 | 役割 |
|---|---|
| プラグインのマニフェスト（名前・説明・バージョン・作者などのメタデータ） |
| 特定タスクの手順をまとめたスキル定義 |
| スラッシュコマンド |
| カスタムエージェント定義 |
| イベントに応じて動くフック |
| MCP サーバー設定（外部ツール・データ連携） |
| LSP サーバー設定（コード補完や定義ジャンプなどのコードインテリジェンス） |
スキルは名前空間付きで <プラグイン名>:<スキル名> の形式で登録されるため、複数のプラグインを入れても名前の衝突が起きにくい設計になっています。
プラグインの標準ディレクトリ構造
各プラグインは決まったディレクトリ構造に従います。README には、標準構造が次のように示されています。
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Plugin metadata (required)
├── .mcp.json # MCP server configuration (optional)
├── commands/ # Slash commands (optional)
├── agents/ # Agent definitions (optional)
├── skills/ # Skill definitions (optional)
└── README.md # Documentation
（出典: anthropics/claude-plugins-official README）
必須なのは plugin.json（マニフェスト）のみで、MCP・コマンド・エージェント・スキルはいずれも任意です。つまりプラグインは「最小限のメタデータ＋必要な拡張機能の組み合わせ」で構成されており、何を含めるかはプラグインごとに異なります。
このカタログからプラグインを入れる場合、README には次のインストール方法が記載されています。
/plugin install {plugin-name}@claude-plugins-official
（出典: anthropics/claude-plugins-official README）
{plugin-name} の部分に対象プラグイン名を指定するか、/plugin > Discover から一覧を参照して選ぶ流れになります。プラグインの作成手順そのものは本記事の範囲を超えるため、詳しく知りたい場合は前述の公式ドキュメントを参照してください。
claude-plugins-official の内部構造｜内部プラグインと外部プラグインの違い
ここからが、信頼性を判断するうえで核心となる部分です。「公式に載っているプラグインの実体はどこにあるのか」「なぜ再現性が保てるのか」を理解すると、どこまで信頼してよいかの解像度が一段上がります。
内部プラグインと外部プラグインの二層構造
claude-plugins-official のリポジトリは、大きく2つのディレクトリで構成されています。README の「Structure」節では次のように区別されています（出典: anthropics/claude-plugins-official README）。
ディレクトリ | 内容 |
|---|---|
| Anthropic が開発・保守する内部プラグイン |
| パートナーやコミュニティ由来のサードパーティプラグイン |
つまり同じ「公式マーケットプレイス」のなかでも、Anthropic 自身が作っている内部プラグインと、外部の組織が作った外部プラグインが分かれて存在しているということです。この区別は、後述する安全性の判断に直結します。
内部プラグイン（/plugins）には、たとえば次のようなものが含まれています。
- 言語サーバー（LSP）群: TypeScript・Python（pyright）・Go（gopls）・Rust（rust-analyzer）・Java（jdtls）・Ruby・Swift・C#・Kotlin・PHP・Lua・C/C++（clangd）など、主要言語のコードインテリジェンスを提供するプラグイン
- 開発支援: feature-dev（機能開発）、code-review（コードレビュー）、code-modernization（コードのモダン化）、pr-review-toolkit（PR レビュー）、commit-commands（コミット支援）など
- プラグイン・スキル開発: plugin-dev、skill-creator、mcp-server-dev、agent-sdk-dev など、Claude Code 自体を拡張するためのツール
- セットアップ・運用: claude-code-setup、claude-md-management、session-report、security-guidance など
開発者が日常的に使う領域（コード補完、レビュー、コミット、セットアップ）を Anthropic 自身がカバーしている点が、内部プラグインの特徴です。
なお「外部プラグイン」と一口に言っても、実体の置き方には2つのパターンがあります。ひとつは、/external_plugins ディレクトリの中に実体（ファイル一式）を持つパターンです。Discord・GitHub・GitLab・Asana・Linear・Firebase・Terraform・Playwright などのプラグインがこれに該当し、提供元はサードパーティでありながら、コードはこのリポジトリ内に取り込まれています。もうひとつは、実体を別リポジトリに持ち、claude-plugins-official 側からはそれを参照するだけのパターンです。後者の参照の仕組みは、次に見る marketplace.json で管理されています。
marketplace.json とコミット SHA ピン留めの仕組み
このカタログの実体は、リポジトリ内の marketplace.json（.claude-plugin/marketplace.json）というファイルです。各プラグインのエントリには name・description・author・category・source・homepage といった情報が並びます。
ここで注目したいのが source フィールドの扱いです。内部プラグインは "./plugins/xxx" のようにリポジトリ内のパスを指します。外部プラグインの場合は、先ほど触れた2パターンに応じて指定が分かれます。/external_plugins 内に実体を持つものはリポジトリ内のパスを指す一方、実体を別リポジトリに置く外部プラグインは、参照先がコミット SHA で固定（ピン留め）されています。README にある skill-bundle 型エントリの例では、別リポジトリを参照する外部ソースの指定が次のように示されています。
{
"source": {
"source": "git-subdir",
"url": "https://github.com/example-org/sdk.git",
"path": "packages/agent-skills",
"ref": "main",
"sha": "<commit sha>"
}
}
（出典: anthropics/claude-plugins-official README）
sha で特定のコミットを指し示すことで、参照先リポジトリが後から更新されても、カタログが指すバージョンは固定されたままになります。これにより、同じプラグインを入れれば誰でも同じ内容を取得できる再現性と、意図しない更新が勝手に混入しない安全性を両立させているわけです。別リポジトリを参照する外部プラグインは実体がリポジトリの外にありながら、公式カタログ側で「どのコミットを指すか」を管理している、という構造を押さえておくと、信頼の範囲が見えやすくなります。
収録プラグインの規模とカテゴリ｜2026年6月時点のデータ
エコシステムの規模感は、採用判断の重要な材料です。marketplace.json を集計すると、2026年6月8日時点で収録されているプラグインは合計 222 件でした。内訳は、内部プラグイン（/plugins を参照）が 36 件、外部プラグイン（/external_plugins 内に実体を持つもの、または別リポジトリを参照するもの）が約 186 件です。
カテゴリ別の分布は次のとおりです（2026年6月8日時点の集計。プラグインは随時追加・更新されるため件数は変動します）。
カテゴリ | 件数 |
|---|---|
development（開発） | 95 |
productivity（生産性） | 42 |
database（データベース） | 31 |
（未分類） | 14 |
security（セキュリティ） | 13 |
monitoring（監視） | 10 |
deployment（デプロイ） | 6 |
design（デザイン） | 5 |
location（位置情報） | 2 |
learning（学習） | 2 |
math（数学） | 1 |
testing（テスト） | 1 |
開発・生産性・データベースが上位を占め、開発ワークフロー全般をカバーしようとしている傾向が読み取れます。
外部プラグインの提供元には、AWS・Adobe・Atlassian・Auth0・ClickHouse・Apollo GraphQL・Airtable・42Crunch など、大手ベンダーや SaaS 事業者が多数名を連ねています。自社で使っているサービスの公式プラグインが含まれているかどうかは、導入を検討する際の具体的なチェックポイントになります。
メンテナンスの健全性という観点では、リポジトリの最終更新が記事執筆時点で当日付（2026-06-08）であり、スター数も約 3 万と多いことから、活発に運用されているディレクトリと判断できます。
公式マーケットプレイスとコミュニティ版（claude-plugins-community）の違い
検索者が最も混同しやすいのが、「公式（official）」と「コミュニティ（community）」の関係です。Anthropic は2つのマーケットプレイスを運用しており、それぞれ位置づけが異なります。比較対象となる anthropics/claude-plugins-community との違いを整理すると次のようになります。
観点 | claude-plugins-official（公式） | claude-plugins-community（コミュニティ） |
|---|---|---|
管理主体 | Anthropic がキュレーション | コミュニティ投稿のミラー |
収録方針 | Anthropic の裁量で品質基準を満たすものを選定 | 投稿フォーム経由＋審査・セキュリティチェックを通過したもの |
デフォルトの有効性 | 全 Claude Code で自動的に利用可能 | 手動で追加する必要がある |
利用時の指定 |
|
|
スター数（2026-06-08） | 29,584 | 168 |
ポイントは、公式マーケットプレイスは追加作業なしで最初から使えるのに対し、コミュニティ版は明示的に追加しないと使えないという点です。コミュニティ版を利用するには、次のように手動でマーケットプレイスを追加します。
/plugin marketplace add anthropics/claude-plugins-community
（出典: Claude Code 公式プラグインドキュメント）
ここで誤解しやすいのが、外部プラグインの「投稿フォーム」の位置づけです。README に記載されている plugin directory submission form は、外部プラグインを提出するための窓口ですが、これは「公式（official）に直接申請する」ものではなく、審査を経たうえでカタログに反映される仕組みとして案内されています。「フォームから送れば即座に公式入りする」わけではない点に注意しておくと、収録基準への理解がぶれません。
一般的な拡張マーケットプレイス（VS Code Marketplace・npm レジストリ）との設計思想の違い
混同しやすいもう一つの軸が、「VS Code Marketplace や npm レジストリのような、誰でも公開できる一般的なマーケットプレイスと同じものなのか」という点です。両者は「拡張機能を配布するカタログ」という見た目こそ似ていますが、設計思想が異なります。
VS Code Marketplace や npm レジストリは、原則として誰でもパッケージを公開できる自由登録型（オープンレジストリ）です。掲載数が膨大になる一方、各パッケージの品質や安全性は基本的に利用者側の判断に委ねられます。これに対して claude-plugins-official は、Anthropic が掲載対象を選定するキュレーション型（審査済みディレクトリ）です。誰でも自由に公開できるわけではなく、品質・セキュリティ基準を満たしたものだけが並びます。
観点 | claude-plugins-official | 一般的な拡張マーケットプレイス（VS Code Marketplace / npm 等） |
|---|---|---|
登録方式 | キュレーション型（Anthropic が選定） | 自由登録型（原則誰でも公開可能） |
掲載基準 | 品質・セキュリティ基準を満たすもの | 原則制限なし（利用者側で判断） |
バージョン固定 | 外部参照プラグインはコミット SHA でピン留め | パッケージのバージョン指定に依存 |
拡張対象 | Claude Code 固有（skills/agents/hooks/MCP/LSP） | エディタ機能・JavaScript パッケージ等 |
この「自由登録型ではなく審査済みディレクトリである」という設計の違いが、検索者が抱く「公式に載っていれば信頼してよいのか」という問いに対する一つの手がかりになります。少なくとも掲載の段階で一定の基準を通っている、という点は判断材料になります。ただし後述するとおり、それは「すべてを Anthropic が保証している」という意味ではありません。
「とりあえず幅広く探したい」ならコミュニティ版を追加する、「まずは Anthropic が選んだ範囲から安全に始めたい」なら公式マーケットプレイスだけで進める、という使い分けが、この違いから導けます。
安全に使うための注意点｜「公式＝すべて安全」ではない
ここまで読むと「公式に載っているなら全部安全だろう」と考えたくなりますが、その理解は一段補正が必要です。README には、次のような明確な注意書きが記載されています。
⚠️ Important: Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended or that they won't change.
（出典: anthropics/claude-plugins-official README）
要点は、Anthropic はプラグインに含まれる MCP サーバーやファイル等を管理しておらず、意図どおりに動くこと・内容が変わらないことを保証していないという点です。とくに外部プラグインは別の組織が開発・保守しているため、「公式カタログに載っている＝Anthropic が中身を保証している」とは限りません。インストール前に、そのプラグインを信頼してよいかを利用者側で判断する必要があります。
具体的なチェックポイントとしては、次のような確認が現実的です。
- 各プラグインの
homepage（多くは提供元の GitHub リポジトリ）を開き、提供元が信頼できる組織か確認する - そのプラグインがどんな MCP サーバーや外部連携を含むか（どこに接続し、どんな権限を要求するか）を把握する
- ライセンスを確認する
ライセンスについては注意が必要です。リポジトリ自体は Apache-2.0 ですが、README の License 節には「各リンク先プラグインの LICENSE を参照すること」と記載されており、収録される個々のプラグインのライセンスはそれぞれ異なります。社内利用で問題がないかを判断するには、プラグイン単位でライセンスを確認することが欠かせません。
公式マーケットプレイスが提供しているのは「Anthropic が一定の品質・セキュリティ基準で選別したディレクトリ」であって、「すべてのプラグインの動作と安全を Anthropic が保証する場」ではない、という線引きを持っておくと、過信も過度な警戒も避けられます。
claude-plugins-official はこんなチームに向いている｜まとめ
最後に、これまでの内容を意思決定の軸として整理します。
claude-plugins-official が向いているのは、次のようなケースです。
- Claude Code を導入し、信頼できる出所からプラグインを選びたいチーム
- 「なぜそのプラグインを選んだのか」を社内に説明する根拠が欲しい場合（Anthropic 管理のキュレーション済みディレクトリであること、別リポジトリを参照する外部プラグインはコミット SHA で固定されていることが説明材料になります）
- まずは Anthropic 自身が開発した内部プラグイン（LSP・コードレビュー・コミット支援など）から堅実に試したい場合
一方で、注意して使うべきなのは次のようなケースです。
- 外部プラグインの権限や MCP 連携を精査せず、一括でまとめて導入しようとする場合（公式カタログ掲載は中身の保証ではないため、外部プラグインは個別に確認が必要です）
- ライセンスをプラグイン単位で確認しないまま社内展開しようとする場合
次のアクションとしては、まず /plugin > Discover から自分の用途（言語の LSP、コードレビュー、特定 SaaS 連携など）に合うものを1つ選び、その homepage とライセンスを確認したうえで試すのが現実的です。仕組みをさらに深く知りたい場合は、前述の公式プラグインドキュメントで構成要素を確認しておくと、カタログに並ぶ各エントリの意味を読み解きやすくなります。
公式マーケットプレイスの位置づけ（Anthropic がキュレーションする自動搭載のディレクトリ）と、その信頼の範囲（個々のプラグイン、とくに外部プラグインは利用者側の確認が前提）を押さえておけば、大量に並ぶプラグインを前にしても、自分の判断で安全に導入を進められるはずです。
