Plugin Marketplace は「プラグインのカタログ」です。1つのリポジトリに複数のプラグインの情報をまとめておき、ユーザーは「このマーケットプレイスに置かれているプラグインを使いたい」と購読登録すれば、自分の Claude Code に一括で取り込めます。

1 個のプラグインには、Skills（スラッシュコマンド）／Subagents（補助エージェント）／Hooks（イベント時に動くスクリプト）／MCP サーバー（外部サービス連携）／LSP サーバー（言語サーバー）などをまとめて入れられます。マーケットプレイス経由で配布すると、これら全部が一括で組織のメンバーに届きます。

マーケットプレイスは GitHub・GitLab などの Git ホスティングサービスに置けるので、特別なサーバーを立てなくても organization の private リポジトリ（社内限定の非公開リポジトリ）に置くだけで、社内向けの配布基盤として機能します。Anthropic 公式（github.com/anthropics/claude-plugins-official）も社内向けマーケットプレイスも、まったく同じ仕組みで動いています。

Skill や Subagent をリポジトリ直下の .claude/skills/ や .claude/agents/ にコミットして共有する方法は、1〜2 リポジトリならコピペで十分回ります。問題は3 つ目以降です。同じ Skill を複数のリポジトリにコピーすると、改修するたびに「どのリポジトリのバージョンが最新か」「どこを更新し忘れているか」がわからなくなり、メンテの負担が指数関数的に増えます。

判断のシンプルな目安は「同じ Skill を 3 リポジトリ以上にコピーした瞬間」。1 つでも更新漏れが起きると本番事故につながる Skill（デプロイ・データ操作系）は、1 リポジトリの段階から先回りで Plugin 化する選択も合理的です。

CLAUDE.md と Skills の Git 管理全般についてさらに詳しく知りたい方は、Claude Code の CLAUDE.md と Skills を GitHub で管理する完全ガイド もあわせてご覧ください。

テキストの説明だけだと立体構造が掴みにくいので、ツリー形式で全体を俯瞰します。マーケットプレイス用リポジトリは次のような階層になります。

my-marketplace/                       ← マーケットプレイス用リポジトリ
├── .claude-plugin/
│   └── marketplace.json              ★ プラグインのカタログ（必須）
└── plugins/
    ├── deploy-tools/                 ← プラグイン1
    │   ├── .claude-plugin/
    │   │   └── plugin.json           ★ プラグインのマニフェスト（必須）
    │   ├── skills/
    │   │   └── deploy/
    │   │       └── SKILL.md
    │   ├── agents/
    │   │   └── reviewer.md
    │   └── hooks/
    │       └── pre-deploy.json
    └── data-tools/                   ← プラグイン2
        ├── .claude-plugin/
        │   └── plugin.json
        ├── skills/
        ├── agents/
        └── mcpServers/

必須は2つだけです。.claude-plugin/marketplace.json（カタログ）と、各プラグインの .claude-plugin/plugin.json（マニフェスト）。残りは入れたいコンポーネントだけ作れば動きます。

ユーザーがインストールすると、プラグイン本体は各自のマシンの ~/.claude/plugins/cache にコピーされ、そこから読み込まれます。マーケットプレイス側のリポジトリはあくまで配布元であり、ユーザーが直接そのリポジトリの中身を実行するわけではありません。

まずは公式ドキュメントに沿って、ローカルで動く最小のマーケットプレイスを作ってみます。プラグインは「/quality-review というスラッシュコマンドが使える」だけのものです。

手順1 ディレクトリを作る

mkdir -p my-marketplace/.claude-plugin
mkdir -p my-marketplace/plugins/quality-review-plugin/.claude-plugin
mkdir -p my-marketplace/plugins/quality-review-plugin/skills/quality-review
cd my-marketplace

手順2 SKILL.md を書く（プラグインの中身）

cat > plugins/quality-review-plugin/skills/quality-review/SKILL.md <<'EOF'
---
description: 直近の変更について、簡単なコードレビューを行います
---

直近の変更を分析し、以下の観点で簡潔に指摘してください。
- 命名・可読性
- エラーハンドリングの抜け
- テストの過不足

`!git diff HEAD` の出力を踏まえて、3つの箇条書きで返答してください。
EOF

手順3 plugin.json を書く（プラグインのマニフェスト）

cat > plugins/quality-review-plugin/.claude-plugin/plugin.json <<'EOF'
{
  "name": "quality-review-plugin",
  "description": "/quality-review スキルを追加します",
  "version": "1.0.0"
}
EOF

手順4 marketplace.json を書く（カタログ）

cat > .claude-plugin/marketplace.json <<'EOF'
{
  "name": "my-plugins",
  "owner": { "name": "Your Name" },
  "plugins": [
    {
      "name": "quality-review-plugin",
      "source": "./plugins/quality-review-plugin",
      "description": "/quality-review スキルを追加します"
    }
  ]
}
EOF

手順5 自分の Claude Code に追加してインストール

/plugin marketplace add ./my-marketplace
/plugin install quality-review-plugin@my-plugins

Claude Code のセッションで /quality-review と打てば、Skill が動きます。これがマーケットプレイスからインストールしたプラグインの最小動作確認です。

.claude-plugin/marketplace.json は「マーケットプレイスのカタログ」です。最低限必要なフィールドは name・owner・plugins の3つだけ。実用的な例は次のようになります。

{
  "name": "company-tools",
  "owner": {
    "name": "DevTools Team",
    "email": "devtools@example.com"
  },
  "description": "社内開発チーム向けのプラグイン集",
  "metadata": {
    "pluginRoot": "./plugins"
  },
  "plugins": [
    {
      "name": "code-formatter",
      "source": "formatter",
      "description": "保存時の自動フォーマット",
      "version": "2.1.0",
      "author": { "name": "DevTools Team" }
    },
    {
      "name": "deployment-tools",
      "source": {
        "source": "github",
        "repo": "company/deploy-plugin"
      },
      "description": "デプロイ自動化ツール"
    }
  ]
}

必須フィールド

便利なメタフィールド

metadata.pluginRoot を "./plugins" に指定しておくと、各プラグインの source を "formatter" のように相対パスを省略して書けます。プラグイン数が多いマーケットプレイスでは記述量が大幅に減ります。

各プラグインのルートに .claude-plugin/plugin.json を置きます。最小例は次のような3行です。

{
  "name": "quality-review-plugin",
  "description": "/quality-review スキルを追加",
  "version": "1.0.0"
}

これだけでも動きますが、プラグインが本格化すると Skills や Subagents の置き場所をカスタムしたくなります。その場合は次のようにコンポーネントの場所を明示します。

{
  "name": "deploy-tools",
  "description": "デプロイ系のスラッシュコマンド集",
  "version": "1.4.2",
  "author": { "name": "Platform Team" },
  "homepage": "https://example.com/deploy-tools",
  "license": "MIT",
  "skills": "skills/",
  "agents": "agents/",
  "hooks": "hooks/pre-deploy.json"
}

version を入れるかどうか

version を指定すると、その文字列を変えない限りユーザーは更新を受け取りません。本番運用するプラグインでは必ず version を入れて、リリースのたびに更新するのが推奨です。

逆に version を省略すると、Git のコミット SHA（変更履歴の識別ID）が代わりに使われ、リポジトリへの commit ごとに「新しいバージョン」として配布されます。社内向けの実験的なプラグインで「main にマージしたら即配布したい」用途には便利ですが、本番系は事故りやすいので明示的に version を上げる運用を勧めます。

marketplace.json の中で各プラグインが「どこから来るか」を source フィールドで指定します。これには5パターンあります。

特定バージョンに固定する

github ・ url ソースでは、ブランチ／タグ／commit SHA を指定して固定できます。

{
  "name": "deployment-tools",
  "source": {
    "source": "github",
    "repo": "company/deploy-plugin",
    "ref": "v2.0.0",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}

ref はブランチ名やタグ名、sha は 40文字の commit ハッシュです。本番に絶対に同じバージョンを保証したいなら sha までピン留めするのが堅実です。

社内マーケットプレイスは GitHub の private リポジトリ（社内限定の非公開リポジトリ）に置くのが王道です。Claude Code は git の認証情報保存ツール（credential helper）を使うので、ターミナルで gh auth login 済みのマシンならそのまま private リポジトリのマーケットプレイスを購読できます。

SSH 経由で取得する場合は、SSH 鍵が ssh-agent（鍵を管理する常駐プロセス）に登録され、known_hosts ファイル（接続先リスト）に GitHub のホストが入っていれば追加設定なしで動きます。要するに「git pull できる環境ならそのまま使える」と理解しておけば十分です。

プラグインのバージョン解決は次の優先順位で決まります。

1. marketplace.json のプラグインエントリに version・ref・sha が指定されていればそれを採用
2. 無ければ plugin.json の version を採用
3. どちらも無ければ Git のコミット SHA を「現在のバージョン」として扱う（commit のたびに新版扱い）

stable と beta を分ける運用例

本番用の安定版と、検証中の beta 版を1つのマーケットプレイスで並走させたい場合は、ブランチを使い分けます。

{
  "name": "company-tools",
  "owner": { "name": "Platform Team" },
  "plugins": [
    {
      "name": "deploy-stable",
      "source": {
        "source": "github",
        "repo": "company/deploy-plugin",
        "ref": "stable"
      }
    },
    {
      "name": "deploy-beta",
      "source": {
        "source": "github",
        "repo": "company/deploy-plugin",
        "ref": "beta"
      }
    }
  ]
}

運用チームは deploy-stable を使い、検証メンバーだけ deploy-beta を購読する、といった切り分けができます。事故時の影響範囲を限定する効果が大きいパターンです。

ユーザー側の操作はいたってシンプルです。Claude Code のセッション内で次のスラッシュコマンドを使います。

プラグインはローカルにキャッシュされる

インストールすると、プラグインの中身は ~/.claude/plugins/cache にコピーされ、そこから読み込まれます。マーケットプレイス側のリポジトリは「配布元」、キャッシュは「実際に動く実体」という関係です。

具体的にどう構築・運用するかは、組織の規模や用途で変わります。よく使われる3つのパターンを紹介します。

パターン1 単独リポジトリ型（小規模・立ち上げ初期）

1つの private リポジトリにマーケットプレイスもプラグイン本体も全部置く構成。source は相対パスで指定するだけで済み、立ち上げが最も早いです。プラグイン数が10個未満なら、これで十分。

company-marketplace/
├── .claude-plugin/marketplace.json
└── plugins/
    ├── deploy/
    ├── data-pipeline/
    └── code-review/

パターン2 カタログ分離型（中規模・チーム横断）

マーケットプレイス（カタログ）と各プラグインを別リポジトリにする構成。source は github 指定で他リポジトリを参照します。プラグインごとに開発チームと権限を分けたい場合に向きます。

company-marketplace/                    ← カタログだけ
└── .claude-plugin/marketplace.json     （全プラグインを一覧化）

company/deploy-plugin/                  ← プラグイン1（別リポジトリ）
company/data-pipeline-plugin/           ← プラグイン2（別リポジトリ）
company/code-review-plugin/             ← プラグイン3（別リポジトリ）

パターン3 公式マーケットプレイスとの並列購読

Anthropic 公式マーケットプレイス（github.com/anthropics/claude-plugins-official）と社内マーケットプレイスを両方購読する構成。OSS の Skills と社内固有の Skills を同じ感覚で /plugin install できます。並列で複数のマーケットプレイスを購読できるのは、Claude Code の大きな強みです。

Claude Code の Plugin Marketplace は「組織内で AI ワークフローを再利用可能なパッケージとして配布する」ための仕組みです。marketplace.json と plugin.json という小さな2ファイルさえ書ければ、あとは GitHub に push するだけで配布基盤として機能します。

• 3 リポジトリ以上で同じ Skill を使うなら、Plugin 化する潮時
• マーケットプレイス（カタログ）とプラグイン（中身）の2層構造で考える
• 本番系のプラグインには必ず version を付け、PR レビューと組み合わせる
• private リポジトリは gh auth login 済みなら追加設定なしで購読できる
• 公式マーケットプレイスと社内マーケットプレイスは並列購読できる

Skill や CLAUDE.md を Git で管理する基本パターンの全体像は Claude Code の CLAUDE.md と Skills を GitHub で管理する完全ガイド に整理しています。Marketplace 化の前段として、まずプロジェクト直下の .claude/ でチーム共有を立ち上げるところから踏み出すのが王道の進め方です。