Claude Code プラグインマーケットプレイスとは、Claude Code のプラグインを配布するためのカタログであり、発見、バージョン管理、自動更新を 1 か所で扱う。プラグイン自体は、いくつかの種類のコンポーネントを束ねたパッケージである。Skills は Claude が参照するガイドラインを保持し、/create-pr のようなスラッシュコマンドが実際に置かれる場所でもある。Agents は特定の仕事を自律的に遂行するサブエージェントである。Hooks はタスク完了のような特定のイベントで発火する処理である。そして外部サービスに接続するための MCP サーバー設定がある（Model Context Protocol を参照）。
用法
使えるプラグインにたどり着くには 1 段階ではなく 2 段階を要し、この区別は実務上重要である。マーケットプレイスを追加しても、そのカタログが見えるようになるだけで、プラグインはまだ 1 つもインストールされていない。各プラグインはそこから個別にインストールする（/plugin marketplace add <org>/cc-plugin-marketplace、続いて /plugin install my-plugin@cc-plugin-marketplace）。
構造は 2 層になっている。マーケットプレイス自体は、Git リポジトリのルートにある 1 つの JSON ファイル .claude-plugin/marketplace.json であり、配布するすべてのプラグインの名前とリポジトリ内のパスを列挙する。そして各プラグインのディレクトリは、そのプラグイン自身のメタデータ（名前、バージョン、説明）を保持する独自の .claude-plugin/plugin.json を持つ。マーケットプレイスファイルのエントリは、プラグイン自身のメタデータの内容に source パスを加えたものであり、このパスが相対パスであるため、プラグインをリポジトリ内の特定の場所に配置する必要はない。パスが一致してさえいれば、マーケットプレイスはプラグインを好きなようにまとめられる。ただし、この相対パスの形式で届くのは同じリポジトリ内のプラグインだけであり、他のリポジトリにあるプラグインは GitHub ソースなど別の手段で参照できる。
バージョンの扱いには、意図的に最小限にとどめた選択肢がある。プラグインのメタデータから version フィールドを省略すると、Claude Code は Git のコミット SHA をバージョンとして扱うため、マージすることそのものが最新バージョンを出荷する行為になる。
検証には公式のコマンドが用意されている。カタログで検出する価値のある構造上の欠陥として、JSON の構文、必須フィールドの欠落、プラグイン名の重複、SKILL.md とエージェントのフロントマターの欠陥、hooks.json の構文が挙げられており、そのチェックのほとんどは claude plugin validate に任せられる。README の有無と、独自のメタデータファイルを持ちながらカタログに登録されていないプラグインは、このコマンドが扱わないものとして挙げられている。このコマンドはまた、../ を使うものなど、マーケットプレイスのルートの外を指す source パスを拒否する。プラグインはインストール時にキャッシュディレクトリへコピーされるため、ルートの外にあるソースは、単に形式が不正であるだけでなく、動作しなかったり意図しない場所に届いたりするおそれがある。
もう 1 つの記述である Software 3.0 時代、Harness による組織生産性の底上げ は、カタログの作り方よりも、組織がこの方法で何を配布するかに関心を向けている。その主張は、この仕組みは組織の仕事の進め方を公開するためのプラットフォームとして読むほうがよいというものである。共有モジュールはワークフローのプラグインになり、ライブラリの公開はマーケットプレイスへのアップロードになり、変わるのは中身がコードからプロンプトとエージェントのロジックになることだけだという。2 つの使い方が素描されている。1 つは、main ブランチへのコミットの試みを捕捉し、エージェントにフィーチャーブランチを作成するよう誘導するフックで、その記事はこれを単にブロックするだけのリンターと対比している。もう 1 つは、優れたエンジニアの機能開発ワークフロー全体を 1 つのスラッシュコマンドに載せ、チームの誰もが呼び出せるようにすることである。同じ記事は、この目的にはマーケットプレイスのほうが検索拡張生成（RAG）よりも予測可能だと主張しており、その根拠として、プラグインは開発者が完全に制御する明示的なテキストであり、デプロイなしにローカルで修正・検証できることを挙げている。そのすべてはそこでは成果ではなく方向性として示されており、その記事へのあるコメントは、何層にも重なった多数のプラグインのうちどれが有効になっているかを追跡すること自体が、可視性の問題になるだろうと論じている。
適用される場面
この仕組みは、人が手渡されるのではなく自ら発見して採用することが想定されるプラグイン群を配布するのに向いている。発見と更新が、インストールする側に任されるのではなくこの仕組みに組み込まれているのはそのためである。消費者が到達できる Git リポジトリを前提としており、相対パスの形式では、プラグインが同じリポジトリ内にあることも前提とする。
複数チームで1つのClaude Codeプラグインマーケットプレイスを育てる ── 共同運用で直面した5つの課題と対策 に記述されている構造上の弱点は、マーケットプレイスが配布するものすべてが 1 つの共有ファイルに列挙されることである。複数のチームが 1 つのカタログに貢献する場合、あらゆる変更がそのファイルに集中するため、マージが衝突する。さらに、そのファイルこそがカタログそのものであるため、構文が壊れたファイルは /plugin marketplace update をマーケットプレイス全体で失敗させ、すべての消費者が新しいものを何も取得できなくなる。その記述はまた、この形式が表現しないものについても指摘している。プラグインのメタデータには作者が記録されるが、プラグインが 1 つのチーム向けなのか全員向けなのか、壊れたときに誰が修正の責任を負うのかを示すものは、構造のどこにもない。
どの程度確立しているか：仕組みそのものは Claude Code 自身のもので、そのベンダーが文書化している。上記の運用面の特徴づけは、共有マーケットプレイスをおよそ 10 か月運用したある組織の記述によるもので、著者らはこれを 2026 年 8 月時点のものとしている。
関連用語
- Agent Skills — プラグインが最もよく配布対象とするコンポーネント
- エージェントフック — プラグインが束ねられる別の種類のコンポーネント
- Model Context Protocol — プラグインが持てる MCP サーバー設定の背後にあるプロトコル
- 段階的開示（Progressive Disclosure） — この方法で配布される
SKILL.mdファイルに適用される慣習 - 実行可能な SSOT（Executable SSOT） — チームの知識を文書ではなくプラグインとして保持すべきだという主張
- 底上げ（Raising the Floor） — ある記述がプラグインを配布する目的として挙げる組織上の目標