Claude Code マーケットプレイス完全ガイド｜公式・private・marketplace.json【2026】

Claude Code を使い込むほど、「毎回同じ手順を入力している」「MCP サーバーやサブエージェントを手で連携するのが面倒」と感じるようになります。その体験を配布可能な単位にパッケージ化する仕組みが Claude Code のプラグインで、それを目録（カタログ）として束ねた配布インフラが マーケットプレイス（marketplace） です。2026 年には Anthropic 公式マーケットプレイス claude-plugins-official に 180 件前後のプラグイン（うち Anthropic 製は 30 数件、残りはサードパーティ）が集積し、エンタープライズパートナー向けの Claude Marketplace、社内向けの private marketplace、そして自由度の高い コミュニティマーケットプレイス（claudemarketplaces.com 等） が並立する 4 チャネル構造になりました。

本記事では、4 配布チャネルの違いと Anthropic Verified バッジの位置付け、/plugin install と /plugin marketplace add の使い分け、marketplace.json のフィールド全網羅、5 種類のプラグインソース（github / url / git-subdir / npm / 相対パス）、社内 private marketplace 構築 10 ステップ、extraKnownMarketplaces / strictKnownMarketplaces によるエンタープライズガバナンス、CI/コンテナへのシード配置、おすすめプラグイン 20 種類、セキュリティ監査チェックリスト 10 項目と稟議書テンプレまでを、Anthropic 公式ドキュメントを一次ソースに整理します。スキル単体の解説はClaude Code Skillsガイド、サブエージェントはClaude Codeサブエージェントガイド、エンタープライズ視点のセキュリティはClaude Code セキュリティ・エンタープライズガイド、企業導入の全体像はClaude Code 企業導入ガイド、トラブルシューティングはClaude Code エラー一覧と解決手順を参照してください。

結論 ── 4 配布チャネル + ガバナンスで「組織の Claude Code 基盤」が完成する

Claude Code のプラグイン配布は 4 チャネル構造です。1) Anthropic 公式マーケットプレイス（claude-plugins-official、起動時に自動利用可能）、2) エンタープライズ向け Claude Marketplace（Replit・GitLab・Harvey・Lovable などのパートナーを支出コミットメント枠で利用）、3) 社内 private マーケットプレイス（GitHub Enterprise / GitLab / Bitbucket のリポジトリに .claude-plugin/marketplace.json を配置）、4) コミュニティマーケットプレイス（claudemarketplaces.com 等、自己責任） の 4 つを目的別に使い分けます。公式マーケットプレイス内のプラグインのうち、追加審査を通過したものには「Anthropic Verified」バッジが付与される場合があります（本記事執筆時点で詳細な運用ルールは Anthropic 側から公開されていません）。最新のパートナー一覧は claude.com/plugins で確認してください。

組織で本格運用するなら、配布チャネルだけでなく3 つのガバナンス設定（extraKnownMarketplaces / enabledPlugins / strictKnownMarketplaces）をセットで設計します（詳細はエンタープライズガバナンス節）。「品質担保・パートナー統合・自社統制・自由度」のどれを優先するかでチャネルを使い分け、ガバナンス設定でリスクを抑えるのが 2026 年版の正解です。

マーケットプレイスの全体像 ── 4 配布チャネルの違い

4 チャネル比較表

チャネル	リポジトリ / URL	管理	信頼度	デフォルト利用可	主な利用シーン
Anthropic 公式	github.com/anthropics/claude-plugins-official	Anthropic 直営	高（審査済）	あり	標準ツール、LSP、Anthropic 製プラグイン
Claude Marketplace（パートナー）	claude.com/plugins	Anthropic + パートナー	高	別途契約	Replit / GitLab / Harvey / Lovable などの統合
private（社内）	自社の GitHub Enterprise / GitLab / Bitbucket	自社	自社責任	extraKnownMarketplaces 設定で配布	業務固有スキル、社内データ連携
コミュニティ	claudemarketplaces.com など	個人・コミュニティ	自己責任	手動追加	ニッチ用途、実験的プラグイン

「Anthropic official marketplace」「claude default marketplace」「anthropic plugin marketplace」などの呼称はいずれも claude-plugins-official を指します。

Anthropic 公式マーケットプレイス（claude-plugins-official）

Anthropic が直接運営する公式マーケットプレイスは、Claude Code が 起動時にデフォルトで自動利用可能な、信頼度の最も高い配布チャネルです。

項目	内容
リポジトリ	github.com/anthropics/claude-plugins-official
管理	Anthropic 直営
利用条件	Claude Code インストール済みなら追加設定不要
審査プロセス	コミュニティ提出 → Anthropic による審査（詳細は非公開）→ 通過分が掲載
カタログ	リポジトリ内の .claude-plugin/marketplace.json がプラグイン一覧の正本
掲載数	本記事執筆時点で 180 件前後（うち 30 数件が Anthropic 製、残りはサードパーティ）。最新は marketplace.json で確認
更新頻度	コミュニティからの PR ベースで継続更新

ユーザー側で「公式マーケットプレイスを有効化する」操作は不要で、/plugin install <name>@claude-plugins-official を打てばそのままインストール候補に出ます。何らかの理由で自動利用できない環境では、次のコマンドで明示的に追加します。

/plugin marketplace add anthropics/claude-plugins-official

Anthropic Verified バッジの位置付け

公式マーケットプレイス内のプラグインのうち、Anthropic による追加審査を通過したものに「Anthropic Verified」バッジが付与される運用が告知されています。公式ドキュメントには審査基準・失効条件の詳細が掲載されていないため、本節の内容は 2026 年 5 月時点で公開情報・コミュニティ運用から推定した位置付け です。

観点	想定される運用（公式に非公開部分を含む推定）
付与条件	基本審査通過後、追加の品質・安全性審査をクリア
公開範囲	バッジ運用ルールの詳細は非公開
永続性	永続保証ではない ── セキュリティ問題発覚時などに失効する可能性
確認方法	/plugin の Discover タブ、または公式マーケットプレイスのカタログ表示
失効時の挙動	バッジ表示が消える。インストール済みプラグインは自動削除されない

「Verified が付いているから永久に安全」と考えないのが運用の基本です。重要なプラグインは半年に 1 回程度、/plugin で Verified 状態と作者・リポジトリの動向を再確認することを推奨します。

Claude Marketplace（エンタープライズパートナー向け）

Anthropic が別途運営する Claude Marketplace（claude.com/plugins）は、Claude モデルをベースにしたサードパーティのパートナーツールを販売する場です。代表的なパートナー（記事更新時点）:

パートナー	主な提供内容
Replit	クラウド開発環境との統合
GitLab	DevOps パイプライン連携
Harvey	法律業務向け AI
Lovable	ノーコード / ローコード開発

※パートナーは継続的に追加されているため、最新一覧は claude.com/plugins で確認してください。

既存の Anthropic 支出コミットメントを、これらのパートナーツールにも適用できるのがエンタープライズ観点での強みです。経理処理が単一ベンダーに一本化できるため、調達工数が大幅に削減されます。

private（社内）マーケットプレイス

社内独自のプラグインを限定配布したい場合、自社の Git ホスティング（GitHub Enterprise / GitLab / Bitbucket / 自己ホスト型）のリポジトリに .claude-plugin/marketplace.json を配置し、利用者側は /plugin marketplace add <owner>/<repo> でそのマーケットプレイスを購読します。詳細は後述の社内 Private Marketplace 構築 10 ステップを参照してください。

社内向け配布の特徴:

観点	仕様
ホスティング	GitHub / GitHub Enterprise Server / GitLab / Bitbucket / 自己ホスト型 Git すべて対応
認証	HTTPS（gh auth login / Git credential helper）または SSH（ssh-agent + known_hosts）
自動更新	環境変数 GITHUB_TOKEN / GITLAB_TOKEN / BITBUCKET_TOKEN でバックグラウンド更新可能
統制	strictKnownMarketplaces で「社内マーケットプレイスのみ許可」のホワイトリスト運用が可能
デフォルト配布	extraKnownMarketplaces + enabledPlugins でチーム加入時に自動有効化

コミュニティマーケットプレイス

公式以外にも、コミュニティが運営するマーケットプレイス（例: claudemarketplaces.com、各個人ブロガーのリポジトリ等）が存在します。公式審査を経ていないため、セキュリティ面は自己責任で評価する必要があります。

利用検討時のチェック:

確認項目	観点
作者の素性	GitHub プロフィール、所属、メンテナンス継続性、SNS での活動状況
ソースコード公開	リポジトリが公開されているか、最終コミット日時、Issue 対応の活発さ
実行権限	プラグインは任意コードを実行可能。実装内容（特に hooks や mcpServers）が妥当か
依存先	外部 API キー・サードパーティサービスへのアクセス範囲、データ送信先
ライセンス	商用利用可・改変可・帰属表示の要否（SPDX 識別子）
更新運用	バージョン管理が CHANGELOG で追跡できるか、セマンティックバージョニングが守られているか

どのチャネルを使うべきか ── 判断フローチャート

質問1: 公式 / Anthropic 製の標準機能で足りるか？
  ├─ Yes → Anthropic 公式マーケットプレイス
  └─ No → 質問2

質問2: パートナーツール（Replit / GitLab / Harvey 等）の統合が必要か？
  ├─ Yes → Claude Marketplace（エンタープライズ契約）
  └─ No → 質問3

質問3: 業務固有のスキルや社内データ連携を含むか？
  ├─ Yes → private（社内）マーケットプレイス
  └─ No → 質問4

質問4: ニッチ用途で、実装内容を自分でレビューできるか？
  ├─ Yes → コミュニティマーケットプレイス（自己責任）
  └─ No → 公式に戻る、または要件を再検討

プラグインとスキル / サブエージェント / Hooks の関係

「プラグイン」と「スキル」「サブエージェント」「Hooks」「MCP サーバー」「LSP サーバー」は混同されがちですが、プラグインはそれらを束ねるパッケージ単位です。

構成要素	役割	プラグインに含められるか
Skill（SKILL.md）	単一のタスクや動作を定義（コマンド呼び出し・ナレッジ提供）	はい
Command（コマンド）	.md ファイル形式のスキル。/<name> ショートカットを生成	はい
Subagent（サブエージェント）	特定タスクに特化した内部エージェント。Claude が自動呼び出し	はい
Hook	PreToolUse / PostToolUse などのライフサイクル介入	はい
MCP サーバー	外部 API・データソースとの接続	はい
LSP サーバー	言語サーバー（コード補完・診断）	はい
Monitor	バックグラウンドで外部イベント・ログを監視し Claude に通知	はい

例えば「TDD 支援プラグイン」なら、「テスト生成スキル」「/tdd-start コマンド」「コミット前 Hook」「レビューサブエージェント」を 1 つにまとめて配布できます。スキル単体の詳細はClaude Code Skillsガイド、サブエージェントはClaude Codeサブエージェントガイド、Hooks はClaude Code Hooksで自動化する5つの実例、MCP はClaude Code MCP連携ガイドを参照してください。

観点	スキル	プラグイン
範囲	単一機能（例: コード整形）	スキル + コマンド + Hooks + サブエージェント + MCP / LSP の束
配布単位	単体	パッケージ化
設定	skills/ ディレクトリ単体	.claude-plugin/plugin.json で宣言
インストール	手動配置	/plugin install で標準化された手順で導入
名前空間	グローバル	プラグイン名で名前空間化（/<plugin>:<skill> で衝突回避）

/plugin install と /plugin marketplace add の使い分け

/plugin install の基本構文

Claude Code のセッション内で実行します。マーケット名を @ で明示するのが推奨です（公式 Discover and install plugins を参照）。

/plugin install <plugin-name>@<marketplace-name>

例: 公式マーケットプレイスから GitHub プラグインをインストールする場合:

/plugin install github@claude-plugins-official

マーケット名を省略すると優先順位に従って解決されますが、複数マーケットを購読していると衝突する可能性があるため、@<marketplace-name> で明示するのが安全です。

インストールスコープ（user / project / local）

プラグインの有効範囲は 3 つから選びます。

スコープ	範囲	保存先	主な用途
user	全プロジェクト共通	~/.claude/settings.json	個人で常用するツール
project	プロジェクト限定（チーム共有）	<repo>/.claude/settings.json（コミット対象）	チーム標準ツール
local	プロジェクト限定（個人用）	<repo>/.claude/settings.local.json（gitignore）	検証中のツール

マーケットプレイス追加 ── /plugin marketplace add

非公式（社内・コミュニティ）マーケットプレイスを追加するには、/plugin marketplace add を使います。

/plugin marketplace add <owner>/<repo>           # GitHub ショートハンド
/plugin marketplace add <owner>/<repo>@v2.0       # 特定タグ・ブランチに固定
/plugin marketplace add https://gitlab.example.com/team/plugins.git
/plugin marketplace add https://example.com/marketplace.json   # 直接 URL
/plugin marketplace add ./my-marketplace          # ローカルパス（テスト用）

非対話的（CI / スクリプト）に実行する場合は claude plugin marketplace サブコマンドが同等です。

claude plugin marketplace add acme-corp/claude-plugins
claude plugin marketplace add acme-corp/claude-plugins@v2.0
claude plugin marketplace add acme-corp/monorepo --sparse .claude-plugin plugins
claude plugin marketplace add acme-corp/claude-plugins --scope project

--sparse はモノレポでサブディレクトリのみクローンしたい場合に有用です。--scope project を指定すると <repo>/.claude/settings.json に記録され、チームメンバーがリポジトリを開いたときに自動的にマーケットプレイス追加が促されます。

一覧・有効化・無効化・更新

/plugin                                      # 対話 UI で一覧・有効化・無効化・アンインストール
claude plugin list                           # CLI で一覧確認
claude plugin marketplace list               # CLI でマーケットプレイス一覧
/plugin install <plugin-name>@<marketplace>  # マーケット指定で明示インストール
/plugin uninstall <plugin-name>              # アンインストール
/plugin marketplace update [<name>]          # マーケットプレイス情報を最新化
/plugin marketplace remove <name>            # マーケットプレイス削除
/reload-plugins                              # 設定変更後の反映

/plugin marketplace remove を実行すると、そのマーケットプレイスからインストールしたプラグインもアンインストールされる点に注意してください。プラグインを保持したまま情報だけ更新したい場合は /plugin marketplace update を使います。

marketplace.json リファレンス

marketplace.json はリポジトリの .claude-plugin/ ディレクトリ直下に配置するカタログファイルです。最低限 name・owner・plugins の 3 フィールドが必要で、各プラグインエントリには name と source が必須です。

トップレベル必須フィールド

フィールド	型	説明	例
name	string	マーケットプレイス識別子（kebab-case、スペース不可）。/plugin install <plugin>@<marketplace-name> で参照される	"acme-tools"
owner	object	メンテナー情報（後述）	{"name": "DevTools Team"}
plugins	array	プラグインエントリの配列	後述

owner オブジェクト

フィールド	型	必須	説明
name	string	必須	メンテナー / チーム名
email	string	任意	連絡先メール

トップレベル任意フィールド

フィールド	型	説明
$schema	string	エディタ補完用の JSON Schema URL。Claude Code はロード時に無視
description	string	マーケットプレイスの簡潔な説明
version	string	マーケットプレイスマニフェストのバージョン
metadata.pluginRoot	string	相対プラグインソースに前置される基本ディレクトリ。例: "./plugins" を指定すれば "source": "./plugins/foo" の代わりに "source": "foo" と書ける
allowCrossMarketplaceDependenciesOn	array	このマーケットプレイス内のプラグインが依存できる他マーケットプレイスのホワイトリスト

description と version は後方互換のため metadata.description / metadata.version の形でも受け入れられます。

プラグインエントリ必須フィールド

フィールド	型	説明
name	string	プラグイン識別子（kebab-case）
source	string | object	プラグインの取得元（後述のプラグインソース 5 タイプ）

プラグインエントリ任意フィールド

カテゴリ	フィールド	型	説明
メタデータ	displayName	string	UI 表示用の人間可読名（Claude Code v2.1.143+）
メタデータ	description	string	プラグインの簡潔な説明
メタデータ	version	string	プラグインバージョン（ピン留めされる）
メタデータ	author	object	{"name", "email"}
メタデータ	homepage	string	プラグインホームページ / ドキュメント URL
メタデータ	repository	string	ソースコードリポジトリ URL
メタデータ	license	string	SPDX ライセンス識別子（MIT / Apache-2.0 など）
メタデータ	keywords	array	検索・分類用タグ
メタデータ	category	string	カテゴリ（"development" "productivity" など）
メタデータ	tags	array	検索性向上用タグ
動作制御	strict	boolean	plugin.json を権限とするか（デフォルト true）
コンポーネント	skills	string | array	スキルディレクトリのカスタムパス
コンポーネント	commands	string | array	コマンドファイル / ディレクトリのカスタムパス
コンポーネント	agents	string | array	エージェントファイルのカスタムパス
コンポーネント	hooks	string | object	Hooks 設定 or hooks.json パス
コンポーネント	mcpServers	string | object	MCP サーバー設定 or 設定ファイルパス
コンポーネント	lspServers	string | object	LSP サーバー設定 or 設定ファイルパス
コンポーネント	outputStyles	string | array	カスタム出力スタイルファイル / ディレクトリのパス

予約名（使えないマーケットプレイス名）

Anthropic 公式のために予約されており、サードパーティでは利用できません。

• claude-code-marketplace / claude-code-plugins / claude-plugins-official
• anthropic-marketplace / anthropic-plugins
• agent-skills / anthropic-agent-skills
• knowledge-work-plugins / life-sciences

official-claude-plugins anthropic-tools-v2 のような 公式になりすます派生名もブロックされます。社内では acme-tools acme-internal-plugins のように 自社識別子を含む名前を採用してください。

strict モード（true / false）

strict フィールドは、plugin.json がコンポーネント定義（skills / agents / hooks / MCP / 出力スタイル）の権威であるかどうかを制御します。

値	動作	適する場面
true（デフォルト）	plugin.json が権威。マーケットプレイスエントリは追加コンポーネントで補足可能、両ソースがマージされる	プラグイン作者が自管理
false	マーケットプレイスエントリが完全な定義。plugin.json がコンポーネントを宣言していると衝突して読込失敗	マーケットプレイス運営者が完全制御したい場合

strict: false は、社内向けにマーケットプレイス運営者がプラグインの公開範囲を再構成したい場合に有用です。プラグインリポジトリは生ファイルを提供し、マーケットプレイスエントリでどのファイルを skill / agent / hook として公開するかを決めます。

marketplace.json サンプル（コピペ可）

$schema 行は任意です。Claude Code はロード時にこのフィールドを無視しますが、エディタ補完のために anthropics/claude-plugins-official で採用されている下記 URL を踏襲しています。

{
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "acme-tools",
  "description": "Acme Corp's internal Claude Code plugins",
  "owner": {
    "name": "Acme DevTools Team",
    "email": "devtools@acme.example.com"
  },
  "metadata": {
    "pluginRoot": "./plugins"
  },
  "plugins": [
    {
      "name": "code-formatter",
      "source": "code-formatter",
      "description": "Automatic code formatting on save",
      "version": "2.1.0",
      "category": "development",
      "author": { "name": "Acme DevTools Team" }
    },
    {
      "name": "deployment-tools",
      "source": {
        "source": "github",
        "repo": "acme/deploy-plugin",
        "ref": "v1.4.2"
      },
      "description": "Deployment automation tools",
      "category": "productivity"
    },
    {
      "name": "monorepo-utils",
      "source": {
        "source": "git-subdir",
        "url": "https://github.com/acme/monorepo.git",
        "path": "tools/claude-plugin",
        "ref": "main"
      },
      "description": "Utilities curated from the monorepo",
      "strict": false
    }
  ]
}

実際の運用例は、公式マーケットプレイスの anthropics/claude-plugins-official/.claude-plugin/marketplace.json を参照してください。180 件前後のエントリが並んでおり、source の使い分けや category 分類の参考になります。

プラグインソース 5 タイプ

source フィールドはプラグインの取得元を指定します。相対パス / github / url / git-subdir / npm の 5 種類があり、それぞれ Git の ref（ブランチ・タグ）・sha（コミット SHA）でピン留めできます。

5 ソース比較表

ソース	型	主なフィールド	ピン留め	主な用途
相対パス	string（"./..."）	—	コミット単位	同一リポジトリ内のプラグイン
github	object	repo、ref?、sha?	ref + sha	公開 GitHub リポジトリ
url	object	url、ref?、sha?	ref + sha	GitLab / Bitbucket / 自己ホスト Git
git-subdir	object	url、path、ref?、sha?	ref + sha + sparse clone	モノレポのサブディレクトリ
npm	object	package、version?、registry?	semver 範囲	npm パッケージ配布（公開・プライベート）

1. 相対パス

同じリポジトリ内にプラグインを置く最もシンプルなパターン。./ で始める必要があり、マーケットプレイスルート（.claude-plugin/ を含むディレクトリ）からの相対パスです。

{
  "name": "code-formatter",
  "source": "./plugins/code-formatter"
}

metadata.pluginRoot を設定していれば、"source": "code-formatter" のように省略形が使えます。

注意: 相対パスは Git 経由でマーケットプレイスを購読している場合にのみ機能します。marketplace.json を直接 URL で配信している場合、相対パス先のファイルはダウンロードされないため、github / url / git-subdir / npm を使ってください。

2. github

最も一般的なソースタイプ。owner/repo 形式で指定します。

{
  "name": "code-review",
  "source": {
    "source": "github",
    "repo": "anthropics/code-review-plugin",
    "ref": "v2.0.0",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}

フィールド	必須	説明
repo	必須	owner/repo 形式
ref	任意	ブランチまたはタグ。省略時はデフォルトブランチ
sha	任意	40 文字の完全な Git コミット SHA。正確に固定したい場合

3. url（GitLab / Bitbucket / 自己ホスト）

GitHub 以外の Git ホスト（GitLab、Bitbucket、Azure DevOps、AWS CodeCommit、自己ホスト型 Gitea / Gogs など）から取得する場合。https:// または git@ 形式の URL を指定します。

{
  "name": "internal-formatter",
  "source": {
    "source": "url",
    "url": "https://gitlab.example.com/team/plugin.git",
    "ref": "main"
  }
}

.git サフィックスは省略可能で、Azure DevOps や AWS CodeCommit のサフィックスなし URL もそのまま使えます。

4. git-subdir（モノレポ）

Git リポジトリのサブディレクトリにプラグインがある場合に使います。スパースクローンで必要なディレクトリだけを取得するため、巨大なモノレポでも帯域幅を抑えられます。

{
  "name": "monorepo-plugin",
  "source": {
    "source": "git-subdir",
    "url": "https://github.com/acme/monorepo.git",
    "path": "tools/claude-plugin",
    "ref": "v2.0.0"
  }
}

url フィールドは GitHub ショートハンド（owner/repo）や SSH URL（git@github.com:owner/repo.git）も受け付けます。

5. npm（公開・プライベートレジストリ）

npm パッケージとして配布されているプラグイン。npm install でインストールされます。

{
  "name": "acme-claude-plugin",
  "source": {
    "source": "npm",
    "package": "@acme/claude-plugin",
    "version": "^2.0.0",
    "registry": "https://npm.example.com"
  }
}

フィールド	必須	説明
package	必須	パッケージ名（@org/plugin のスコープ付きも可）
version	任意	バージョン or semver 範囲（2.1.0 ^2.0.0 ~1.5.0）
registry	任意	カスタム npm レジストリ URL。省略時は npmjs.org

${CLAUDE_PLUGIN_ROOT} と ${CLAUDE_PLUGIN_DATA}

hooks や mcpServers の設定で外部スクリプト・バイナリを参照するときに使う環境変数です。

変数	用途
${CLAUDE_PLUGIN_ROOT}	プラグインのインストールディレクトリ（読み取り専用）。更新時に上書きされる
${CLAUDE_PLUGIN_DATA}	プラグインの永続データディレクトリ。更新後も保持される

プラグインはインストール時にキャッシュロケーション（~/.claude/plugins/cache/...）にコピーされるため、相対パスでスクリプトを参照すると見つからない場合があります。Hook や MCP サーバーの設定では必ず ${CLAUDE_PLUGIN_ROOT} を使うのが鉄則です。

社内 Private Marketplace 構築 ── 10 ステップ

社内固有のスキルやプラグインを、安全にチーム配布するための標準手順です。GitHub Enterprise / GitLab / Bitbucket いずれでも応用できます。

ステップ 1 ── 配布用リポジトリを作成

acme-org/claude-plugins（または claude-marketplace）のように マーケットプレイス専用リポジトリを 1 つ用意します。プラグイン本体を同じリポジトリに置く「単独リポジトリ型」と、別リポジトリに置く「カタログ分離型」のどちらかを選びます。

運用パターン	プラグイン数	管理者の数	推奨ケース
単独リポジトリ型	1-3	1 チーム	開始時、PoC
カタログ分離型	3 以上	複数チーム	プラグインごとに開発チームを分けたい
公式と並列購読型	任意	—	公式を残しつつ社内を追加

ステップ 2 ── ディレクトリ構造を作成

単独リポジトリ型の場合:

acme-org/claude-plugins/
├── .claude-plugin/
│   └── marketplace.json
├── plugins/
│   ├── acme-formatter/
│   │   ├── .claude-plugin/
│   │   │   └── plugin.json
│   │   └── skills/
│   │       └── acme-formatter/
│   │           └── SKILL.md
│   └── acme-deploy/
│       ├── .claude-plugin/
│       │   └── plugin.json
│       └── commands/
│           └── deploy.md
└── README.md

カタログ分離型の場合は、plugins/ ディレクトリを置かず、marketplace.json の source でそれぞれ別リポジトリを指します。

ステップ 3 ── プラグインの中身を作る

最小構成のスキルプラグイン例。my-marketplace/plugins/quality-review/skills/quality-review/SKILL.md を作成します。

---
description: Review code for bugs, security, and performance
disable-model-invocation: true
---

Review the code I've selected or the recent changes for:
- Potential bugs or edge cases
- Security concerns
- Performance issues
- Readability improvements

Be concise and actionable.

ステップ 4 ── plugin.json を記述

各プラグインの .claude-plugin/plugin.json を作成します。

{
  "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
  "name": "quality-review",
  "version": "1.0.0",
  "description": "Adds a quality-review skill for quick code reviews",
  "author": { "name": "Acme DevTools" },
  "homepage": "https://github.acme.example.com/acme-org/claude-plugins",
  "license": "Apache-2.0"
}

version を明示すると、リリースのたびに数値を上げないと既存ユーザーには更新通知が届きません。逆に version を省略すれば、すべてのコミットが自動的に新バージョンとして扱われ、内部チーム向けには便利です。

ステップ 5 ── marketplace.json を記述

リポジトリ直下の .claude-plugin/marketplace.json にプラグイン一覧を書きます。

{
  "name": "acme-tools",
  "description": "Acme Corp internal Claude Code plugins",
  "owner": {
    "name": "Acme DevTools Team",
    "email": "devtools@acme.example.com"
  },
  "metadata": { "pluginRoot": "./plugins" },
  "plugins": [
    {
      "name": "quality-review",
      "source": "quality-review",
      "description": "Review code for bugs, security, and performance",
      "category": "quality"
    }
  ]
}

ステップ 6 ── ローカルでテスト

リポジトリをまだ push しなくても、ローカルディレクトリのまま動作確認できます。

/plugin marketplace add ./claude-plugins-local
/plugin install quality-review@acme-tools
/quality-review:quality-review

JSON 構文の検証は claude plugin validate . または /plugin validate . を実行します。plugins[0].source: Path contains ".." のようなエラーが出る場合は、相対パスが .. を含んでいないか確認してください。プラグインソースに ../external/plugin のような親ディレクトリ参照を書くと、このエラーで読み込みが失敗します。

ステップ 7 ── 社内 Git ホストへ push

GitHub Enterprise / GitLab / Bitbucket の private リポジトリに push します。

git remote add origin git@github.acme.example.com:acme-org/claude-plugins.git
git push -u origin main

push 後、別マシンから /plugin marketplace add acme-org/claude-plugins でアクセスできることを確認します。

ステップ 8 ── チームメンバーへの配布（手動）

メンバーには次のコマンドを共有します。

/plugin marketplace add acme-org/claude-plugins
/plugin install quality-review@acme-tools

GitHub Enterprise の場合は acme-org/claude-plugins、自己ホスト型 Git の場合は完全 URL で指定します。

ステップ 9 ── チームメンバーへの配布（自動）

リポジトリの .claude/settings.json にマーケットプレイス指定を入れておくと、メンバーがプロジェクトフォルダを信頼した瞬間にインストール提案が表示されます。

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "github",
        "repo": "acme-org/claude-plugins"
      }
    }
  },
  "enabledPlugins": {
    "quality-review@acme-tools": true,
    "acme-deploy@acme-tools": true
  }
}

GitHub Enterprise Server の場合、source に URL を指定する代替パターンもあります。

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "url",
        "url": "https://github.acme.example.com/acme-org/claude-plugins.git"
      }
    }
  }
}

ステップ 10 ── 更新運用フローを確立

リリースのたびに以下を回します。

1. プラグインリポジトリで PR を作成
2. レビュー（後述のセキュリティ監査チェックリスト）を経て main にマージ
3. plugin.json の version を上げる（または version を省略している場合は自動更新）
4. リリースタグを切る（任意）
5. 利用者は /plugin marketplace update acme-tools で最新化（バックグラウンド自動更新を有効化していれば自動）

GitLab / Bitbucket / GitHub Enterprise からの配信パターン

GitHub 以外でも、url ソースまたは完全 URL 経由で配信できます。認証方式と環境変数を押さえれば、ほぼ同じ操作で動きます。

認証方式の選択

環境	推奨方式	設定方法
GitHub.com / GHES	HTTPS + gh auth login または PAT	gh auth login で対話的にログイン
GitHub.com / GHES（CI）	GITHUB_TOKEN 環境変数	export GITHUB_TOKEN=ghp_xxx
GitLab	HTTPS + PAT または OAuth	GITLAB_TOKEN / GL_TOKEN
Bitbucket	HTTPS + アプリパスワード	BITBUCKET_TOKEN
自己ホスト Git	SSH + ssh-agent	known_hosts 追加済み、ssh-agent に鍵ロード

手動インストールでは Git の認証情報ヘルパー（macOS Keychain / git-credential-store / gh auth login）が使われるため、ターミナルで git clone できれば Claude Code でもアクセスできます。

バックグラウンド自動更新の有効化

Claude Code は起動時に裏側でプラグイン情報を更新しますが、その際は対話的なプロンプトを表示せずに進めるため、環境変数でのトークン設定が必須です。

# GitHub Enterprise / GitHub.com
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

# GitLab
export GITLAB_TOKEN=glpat_xxxxxxxxxxxxxxxxxxxx

# Bitbucket
export BITBUCKET_TOKEN=ATBBxxxxxxxxxxxxxxxxxxxx

CI 環境では Secrets 機能で環境変数を注入してください。GitHub Actions は同一組織内リポジトリに対して GITHUB_TOKEN を自動提供します。

Git 操作のタイムアウト調整

デフォルトの Git タイムアウトは 120 秒です。大規模リポジトリや低速回線では CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS で延長できます。

export CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS=300000  # 5 分

オフライン環境での挙動

オフライン / エアギャップ環境では git pull が失敗すると Claude Code は古いキャッシュを削除して再クローンを試みます。これを抑止するには CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1 を設定し、失敗時にも既存キャッシュを保持させます。

export CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1

完全に隔離された環境では、後述のCI/コンテナへのシード配置パターンを使ってビルド時にプラグインを固定するのが安全です。

エンタープライズガバナンス

組織で本格運用するなら、extraKnownMarketplaces・enabledPlugins・strictKnownMarketplaces の 3 設定をセットで設計します。役割と保存先を整理した早見表が以下です。

3 設定の役割早見

設定	役割	保存先	強制力
extraKnownMarketplaces	チームに推奨するマーケットを自動的に登録・追加提案	プロジェクト or 管理設定	推奨（ユーザーが拒否可能）
enabledPlugins	指定プラグインをデフォルトで有効化	プロジェクト or 管理設定	自動 ON（無効化は可能）
strictKnownMarketplaces	ホワイトリスト統制（リスト外はブロック）	管理設定（個別ユーザーは上書き不可）	強制ロック

strictKnownMarketplaces ── ホワイトリスト統制

管理設定（managed-settings.json）に書くと、個別ユーザーやプロジェクト設定で上書きできません。組織全体で「許可マーケットプレイスのみ」運用したい場合の中核設定です。

値	動作
未定義（デフォルト）	制限なし。任意のマーケットプレイスを追加可能
[]（空配列）	完全ロックダウン。新規マーケットプレイス追加不可
ソースリスト	ホワイトリストと完全一致するマーケットプレイスのみ追加可能

完全ロックダウン:

{
  "strictKnownMarketplaces": []
}

特定マーケットプレイスのみ許可:

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/approved-plugins" },
    { "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" },
    { "source": "url", "url": "https://plugins.acme.example.com/marketplace.json" }
  ]
}

hostPattern / pathPattern による正規表現マッチング

社内 Git サーバーをまとめて許可したい場合、hostPattern を使うのが便利です（GitHub Enterprise Server や自己ホスト型 GitLab の推奨パターン）。

{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.acme\\.example\\.com$"
    }
  ]
}

ファイルシステムパスを許可する場合は pathPattern:

{
  "strictKnownMarketplaces": [
    {
      "source": "pathPattern",
      "pathPattern": "^/opt/approved/"
    }
  ]
}

ホワイトリストは原則 完全一致 のため、URL の末尾スラッシュや .git サフィックス、ssh:// と https:// の違いは別物として扱われます。組織のマーケットプレイスが複数 URL 形式でクローンできる場合は、hostPattern でまとめて許可する設計が現実的です。

extraKnownMarketplaces と組み合わせる

「許可するだけ」だと利用者は手動で /plugin marketplace add を実行する必要があります。自動的に登録するには extraKnownMarketplaces と組み合わせます。

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/claude-plugins" }
  ],
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/claude-plugins" }
    }
  },
  "enabledPlugins": {
    "code-formatter@acme-tools": true
  }
}

これで「許可されたマーケットプレイスのみ、自動的に登録され、特定プラグインが最初から有効化されている」状態になります。エンタープライズ全般のセキュリティ運用はClaude Code セキュリティ・エンタープライズガイド、組織導入の進め方はClaude Code 企業導入ガイドも参照してください。

CI / コンテナへのシード配置

用語: 本記事では Docker イメージや CI 環境にプラグインをあらかじめ配置する操作を シード配置（seeding） と呼びます。同じ概念を一部「事前ロード」「プリビルド」と表現する場合がありますが、すべて CLAUDE_CODE_PLUGIN_SEED_DIR を使ったビルド時固定を指します。

Docker イメージや CI 環境で Claude Code を実行する場合、起動のたびにマーケットプレイスをクローンするとビルド時間と帯域幅を消費します。CLAUDE_CODE_PLUGIN_SEED_DIR を使えば、ビルド時にプラグインディレクトリを シード配置（事前固定） しておき、実行時はクローンせずに起動できます。

シードディレクトリの構造

シードは ~/.claude/plugins の構造をミラーします。

$CLAUDE_CODE_PLUGIN_SEED_DIR/
  known_marketplaces.json
  marketplaces/<name>/...
  cache/<marketplace>/<plugin>/<version>/...

Dockerfile 組み込みパターン

FROM node:20

# Claude Code 本体のインストール（公式手順に従う）
RUN curl -fsSL https://code.claude.com/install.sh | bash

# シード用ディレクトリにマーケットプレイスとプラグインを直接インストール
ENV CLAUDE_CODE_PLUGIN_CACHE_DIR=/opt/claude-seed
RUN claude plugin marketplace add acme-corp/claude-plugins && \
    claude plugin install code-formatter@acme-tools && \
    claude plugin install quality-review@acme-tools

# 実行時はシードから読み込む
ENV CLAUDE_CODE_PLUGIN_SEED_DIR=/opt/claude-seed

CLAUDE_CODE_PLUGIN_CACHE_DIR でインストール時の保存先を強制し、結果をそのまま CLAUDE_CODE_PLUGIN_SEED_DIR として再利用する手順です。

シード運用の挙動

観点	動作
読み取り専用	シードディレクトリには書き込まれない。自動更新は無効化
シード優先	シードのマーケットプレイスはユーザー設定の同名エントリを上書き
オプトアウト	シード提供プラグインを個別に外したい場合は /plugin disable <name> を使う（マーケットプレイス削除では不可）
パス解決	実行時に $CLAUDE_CODE_PLUGIN_SEED_DIR/marketplaces/<name>/ をプローブ。ビルド時と異なるパスでマウントしても動作
変更ブロック	/plugin marketplace remove / update は失敗（シードイメージ更新を促す）
複数シード	:（Unix）または ;（Windows）で複数パスをレイヤー可能

CI/CD パイプラインでの組み込みパターンは、docker build 時に上記 Dockerfile を回し、ビルド済みイメージを docker run するだけで完結します。エアギャップ環境やインターネット制限下のオンプレ環境で特に有効です。シード配置したプラグインを個別に外したい場合は /plugin disable <name> を利用してください（マーケットプレイス削除は失敗します）。

バージョン管理とリリースチャネル

プラグインのバージョンはキャッシュパスと更新検出を決めます。同じバージョン文字列に解決される限り、Claude Code はキャッシュ済みのコピーを保持し、/plugin update も自動更新もスキップします。

バージョン解決ルール

優先順に以下が評価されます。

1. プラグインの plugin.json の version
2. マーケットプレイスエントリの version
3. Git コミット SHA（github / url / git-subdir の場合）

plugin.json とマーケットプレイスエントリの 両方 に version を書くと、plugin.json 側が常に優先される点に注意してください。バージョン管理の単一情報源（Single Source of Truth）は plugin.json にまとめるのが安全です。

社内向けに version を省略する場合、すべてのコミットが新バージョンとして扱われ、メンバーはマージのたびに最新化を受け取ります。

リリースチャネル設計（stable / latest）

「安定版」と「最新版」を別チャネルで配布したい場合は、同じプラグインリポジトリを 別 ref で参照する 2 マーケットプレイスを用意します。

stable マーケットプレイス:

{
  "name": "acme-stable",
  "owner": { "name": "Acme" },
  "plugins": [
    {
      "name": "code-formatter",
      "source": {
        "source": "github",
        "repo": "acme-corp/code-formatter",
        "ref": "stable"
      }
    }
  ]
}

latest マーケットプレイス:

{
  "name": "acme-latest",
  "owner": { "name": "Acme" },
  "plugins": [
    {
      "name": "code-formatter",
      "source": {
        "source": "github",
        "repo": "acme-corp/code-formatter",
        "ref": "latest"
      }
    }
  ]
}

利用者グループに応じて extraKnownMarketplaces で配布先を切り替えます。安定運用が必要な本番系チームには acme-stable、検証チームには acme-latest を配るパターンです。

重要: 各チャネルが異なるバージョンに解決される必要があります。明示的な version を使う場合は plugin.json を各 ref ごとに違うバージョン文字列にしないと、Claude Code は同一として扱い更新をスキップします。

プラグイン依存関係バージョンピン

プラグインが他プラグインに依存する場合、semver 範囲で依存バージョンを制限できます。{plugin-name}--v{version} 形式の Git タグ規約と組み合わせて、依存関係の破壊的変更を防ぎます。詳細は公式のプラグイン依存関係バージョンを制限するを参照してください。

プラグイン開発ハンズオン ── hello-world から公開まで

ステップ 1 ── 最小ディレクトリ構造

my-plugin/
  .claude-plugin/
    plugin.json
  skills/
    hello-world/
      SKILL.md
  commands/
    hello.md
  agents/
    greeter.md
  hooks/
    hooks.json
  mcpServers/
    servers.json
  README.md
  CHANGELOG.md
  LICENSE

ステップ 2 ── plugin.json を書く

{
  "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
  "name": "hello-world",
  "version": "0.1.0",
  "description": "Hello World plugin demonstrating skills, commands, agents, hooks, and MCP",
  "author": { "name": "Your Name", "email": "you@example.com" },
  "homepage": "https://github.com/your-org/hello-world-plugin",
  "repository": "https://github.com/your-org/hello-world-plugin",
  "license": "MIT",
  "keywords": ["sample", "tutorial"],
  "commands": ["./commands"],
  "agents": ["./agents/greeter.md"],
  "skills": ["./skills"],
  "hooks": "hooks/hooks.json",
  "mcpServers": "mcpServers/servers.json"
}

ステップ 3 ── スキル / コマンド / サブエージェント を追加

スキル（skills/hello-world/SKILL.md）:

---
description: Greet the user warmly
disable-model-invocation: true
---

Greet the user by name and ask how you can help today.

コマンド（commands/hello.md）:

---
description: Say hello
---

Print "Hello, world!" and explain what this plugin does.

サブエージェント（agents/greeter.md）:

---
name: greeter
description: Specialized agent for warm onboarding conversations
model: sonnet
effort: medium
maxTurns: 10
---

You are a friendly assistant who specializes in onboarding new users to Claude Code.
Always start by asking their name and what they want to accomplish today.

ステップ 4 ── Hook を追加

hooks/hooks.json:

{
  "PostToolUse": [
    {
      "matcher": "Write|Edit",
      "hooks": [
        {
          "type": "command",
          "command": "${CLAUDE_PLUGIN_ROOT}/scripts/notify.sh"
        }
      ]
    }
  ]
}

${CLAUDE_PLUGIN_ROOT} は 必須です。プラグインはキャッシュにコピーされてから実行されるため、相対パスでスクリプトを呼ぶと見つかりません。永続化が必要な状態（DB ファイルなど）は ${CLAUDE_PLUGIN_DATA} に置きます。

ステップ 5 ── MCP サーバーを追加

mcpServers/servers.json:

{
  "hello-mcp": {
    "command": "${CLAUDE_PLUGIN_ROOT}/servers/hello-mcp",
    "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"]
  }
}

MCP サーバー自体の作り方はClaude Code MCP連携ガイドを参照してください。

ステップ 6 ── ローカル検証

claude plugin validate .

JSON 構文エラー・スキーマ違反・YAML frontmatter の不備をまとめて検出します。問題がなければ次に進みます。

/plugin marketplace add ./my-plugin-marketplace
/plugin install hello-world@my-plugin-marketplace
/hello-world:hello

ステップ 7 ── 公開準備（README / CHANGELOG / LICENSE）

公開前に整備しておくべきドキュメント:

• README.md ── インストール手順、提供する commands / agents / skills の一覧、ユースケース、依存 MCP サーバー
• CHANGELOG.md ── セマンティックバージョニングに沿った変更履歴
• LICENSE ── SPDX ライセンス識別子（MIT / Apache-2.0 等）
• SECURITY.md ── 脆弱性報告先と対応 SLA
• 依存 MCP サーバーのライセンス明記

ステップ 8 ── Anthropic 公式マーケットプレイスへの提出

1. 自作プラグインを GitHub の公開リポジトリで管理
2. claude.ai/settings/plugins/submit または platform.claude.com/plugins/submit から提出申請、もしくは anthropics/claude-plugins-official リポジトリへの PR で .claude-plugin/marketplace.json にエントリを追加
3. Anthropic の自動審査（詳細は非公開）を経て掲載
4. 追加の品質・安全性審査を通過すると Anthropic Verified バッジが付与される可能性

実例として、公式 marketplace.json の 42crunch-api-security-testing airtable box agent-sdk-dev などのエントリを参考にすると、source の使い分けや category の付け方が把握できます。

セキュリティ監査チェックリスト 10 項目 + 稟議書テンプレ

Claude Code のプラグインは ユーザー権限で任意コードを実行できる 設計です。だからこそ、社内採用前のセキュリティ評価が極めて重要になります。

セキュリティ監査チェックリスト 10 項目

• 1. 作者・運営の素性 ── 個人名 / 企業名 / GitHub プロフィール / 連絡先が明示されているか
• 2. ソースコード公開 ── リポジトリが完全公開で、hooks / mcpServers / agents の中身を読めるか
• 3. メンテナンス状況 ── 最終コミット 6 ヶ月以内、Issue / PR 対応の活発さ
• 4. 実行権限 ── hooks で外部コマンドを呼ぶ場合、その中身が業務上妥当か
• 5. 外部送信先 ── mcpServers の接続先が想定範囲内か（外部 API キー・サードパーティ送信が無いか）
• 6. ライセンス ── SPDX 識別子（MIT / Apache-2.0 等）が明示、商用利用 OK か
• 7. Anthropic Verified バッジ ── 公式マーケットプレイス内なら Verified の有無、失効履歴の確認
• 8. バージョン管理 ── セマンティックバージョニングに沿って version が運用されているか、CHANGELOG があるか
• 9. 機密情報露出リスク ── プラグインが環境変数・トークン・ソースコードを送信していないか
• 10. 更新運用 ── 自動更新の挙動を理解しているか（手動承認制にするなら enabledPlugins: false）

これらをスキャンする標準フォーマットを社内で持っておくと、新規プラグイン採用のたびに数十分で評価が完結します。

稟議書テンプレート（コピペ可）

経営層やセキュリティ部門に説明する稟議書ひな型です。

件名: Claude Code プラグイン「<plugin-name>@<marketplace>」の社内利用承認依頼

1. 概要
   - プラグイン名: <plugin-name>
   - 配布元: <claude-plugins-official / acme-tools / claudemarketplaces.com / community>
   - バージョン: <x.y.z>
   - ライセンス: <MIT / Apache-2.0>
   - 想定利用部署: <チーム名>

2. 業務上の効果
   - 解決したい課題: <例> 毎日のコードレビューで PR ごとに 15-30 分の手作業が発生
   - 期待効果: <例> 4 エージェント並列レビューにより 1 PR あたり 5 分以内に短縮
   - 影響範囲: <利用人数 / プロジェクト>

3. セキュリティ評価（チェックリスト10項目）
   - [x] 作者・運営の素性
   - [x] ソースコード公開
   - [x] メンテナンス状況
   - [x] 実行権限
   - [x] 外部送信先
   - [x] ライセンス
   - [ ] Anthropic Verified
   - [x] バージョン管理
   - [x] 機密情報露出
   - [x] 更新運用
   - 残課題: <Verified なし。社内では手動承認制で運用>

4. 運用ルール
   - インストール承認: 情報システム部
   - 更新承認: 月次レビュー
   - 廃止条件: 6 ヶ月以上メンテナンスが停止した場合、または重大な脆弱性発覚時

5. リスクと緩和策
   - リスク1: 任意コード実行
     緩和策: strictKnownMarketplaces で許可マーケットを限定、定期的にソースコードを再レビュー
   - リスク2: 外部依存
     緩和策: mcpServers の接続先を社内プロキシ経由に限定

6. 監査
   - ログ保管期間: <1 年>
   - 監査主体: <情報セキュリティ部門>

このテンプレを使うと、技術的に不慣れな承認者でも判断に必要な情報が一目で揃います。社内利用ポリシーはClaude Code セキュリティ・エンタープライズガイドと組み合わせて運用してください。

おすすめプラグイン 20 種 ── カテゴリ別

公式マーケットプレイス（claude-plugins-official）には本記事執筆時点で 180 件前後のプラグインが登録されており、内訳は development / productivity / security / quality / data など多岐にわたります。実務で導入効果が高いものをカテゴリ別に整理します（プラグイン名・機能内容は時期により大きく入れ替わります。本節は本記事執筆時点の公式 marketplace.json で確認したものと、コミュニティで広く認知されている代表例を整理した参考リストです。導入前に必ず github.com/anthropics/claude-plugins-official/.claude-plugin/marketplace.json で実在性と最新仕様を確認してください）。

開発ワークフロー系

プラグイン	役割	主要コンポーネント
feature-dev	フェーズ別開発ワークフロー（要件・設計・実装・テスト・PR）	サブエージェント + スキル
plugin-dev	プラグイン開発支援（テンプレ生成、検証）	スキル + コマンド
commit-commands	コミット・プッシュ・PR 作成までの Git ワークフロー自動化	コマンド
frontend-design	shadcn/ui ベースの UI 生成	スキル
tdd-workflow	TDD 支援（Red→Green→Refactor） — Claude Code TDDワークフロー参照	スキル + Hook

レビュー・品質系

プラグイン	役割
code-review	複数の特化エージェントによる並列レビュー、信頼度スコアで低品質コメントをフィルタ
pr-review-toolkit	プルリクエスト専用の特化エージェント群、GitHub PR 自動コメント
coderabbit	外部 AI レビューサービス連携（公式 marketplace.json への掲載状況は時期により変動）
quality-review	バグ・セキュリティ・パフォーマンス・可読性の総合チェック

セキュリティ系

プラグイン	役割
security-guidance	コード内のセキュリティ警告
42crunch-api-security-testing	API セキュリティの自動テスト

MCP / 外部サービス連携

プラグイン	役割
context7	React / Next.js / Tailwind / Prisma / Django / Spring などのリアルタイムドキュメント取得
playwright	ブラウザ自動操作・E2E テスト
github	GitHub PR / Issue / Actions 連携
vercel	Vercel デプロイ・ログ取得
airtable	Airtable をエージェントのデータベース層・運用層として利用
box	Box のコンテンツ管理（契約書類・ファイル参照などのワークフロー）

LSP（言語サーバー）系

公式マーケットプレイスは複数の言語サーバープラグインを提供しており、clangd-lsp（C/C++）を筆頭に、TypeScript・Python・Go・Rust などコード補完と診断機能を補強する LSP プラグインが揃っています。lspServers フィールドで設定が宣言されているのが特徴です。

思考力・セカンドオピニオン系

プラグイン	役割
superpowers	ブレインストーミング、サブエージェント開発、デバッグ、TDD、スキル作成（コミュニティ製。公式 marketplace.json への掲載状況は時期により変動）
codex（OpenAI）	OpenAI モデルによるセカンドオピニオン（コミュニティ製）

個人開発者向け推奨セット

• feature-dev + commit-commands + tdd-workflow + context7 + playwright

チーム開発向け推奨セット

• code-review + pr-review-toolkit + security-guidance + github + airtable

PR 自動化の応用はClaude CodeでPR自動化、UI 設計はClaude Designガイド、コマンド全般はClaude Codeスラッシュコマンド集を併せて参照してください。

業界別プラグイン構成パターン（5 業界）

業界の業務特性に応じて、おすすめプラグイン構成は変わります。代表的な 5 業界で参考構成を整理します。

業界	重視ポイント	推奨コア構成	補強プラグイン	想定リスクと対策
金融	監査ログ・データ漏洩防止	security-guidance + code-review + private marketplace	42crunch-api-security-testing、github	任意コード実行 → strictKnownMarketplaces でホワイトリスト統制
法務	契約書・ドラフトの社内参照	box + private marketplace	commit-commands、coderabbit	機密文書漏洩 → 接続先を社内アカウントに限定、監査ログを保管
医療	HIPAA 等のコンプライアンス	private marketplace + security-guidance + ローカル LSP	tdd-workflow、code-review	PHI 露出 → MCP 接続先を社内プロキシ経由に限定
小売	API 連携・在庫管理	airtable + context7 + playwright	feature-dev、vercel	外部 SaaS 障害 → 重要オペは MCP 切替の備えを用意
SaaS	開発速度 + 品質	feature-dev + code-review + pr-review-toolkit + commit-commands	frontend-design、tdd-workflow	自動更新で挙動変化 → リリースチャネル分離（stable/latest）で本番安定化

金融・医療・法務は private marketplace + strictKnownMarketplaces のホワイトリスト統制が必須です。外部 SaaS 連携が必要な場合でも、mcpServers の接続先を社内プロキシ経由に限定する運用と組み合わせます。

失敗事例とトラブルシューティング

よくある失敗 8 パターン

#	症状	原因	対処
1	Invalid JSON syntax: Unexpected token...	カンマ過不足・引用符忘れ	claude plugin validate . で構文チェック、エディタの JSON フォーマッタで整形
2	プラグイン読込失敗	strict: true で plugin.json とマーケットエントリが衝突	どちらか片方に統一、または strict: false で運営者制御に切替
3	URL ベース配信でプラグインが not found	marketplace.json を直接 URL で配信した上で相対パス source を使用	source を github / url / git-subdir / npm のいずれかに変更
4	Git pull timed out after 120s	大規模リポジトリ or 低速回線	CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS=300000 で 5 分に延長
5	自動更新が失敗	バックグラウンド更新時にトークン未設定	GITHUB_TOKEN / GITLAB_TOKEN / BITBUCKET_TOKEN を環境変数で設定
6	Duplicate plugin name	同名プラグインが複数エントリに存在	プラグイン名を kebab-case でユニーク化
7	/<command> 名が衝突	複数プラグインが同じコマンド名を提供	/plugin の Installed タブで衝突確認、必要なら片方を無効化（プラグイン名で名前空間化される /plugin:command 形式を使う）
8	予約名エラー	anthropic-marketplace 等の予約名を使用	自社識別子を含む名前（acme-tools）に変更

marketplace.json の typo パターン

{
  "name": "acme tools",  // ❌ スペースは kebab-case 違反
  "owner": "Acme Team",  // ❌ object でなく string
  "plugins": [
    {
      "Name": "code-formatter",  // ❌ JSON フィールド名は小文字 name が正しい（大文字始まりはスキーマと一致しないため認識されない）
      "source": "../external/plugin"  // ❌ ".." を含む相対パスは禁止（Path contains ".." エラー）
    }
  ]
}

修正後:

{
  "name": "acme-tools",
  "owner": { "name": "Acme Team" },
  "plugins": [
    {
      "name": "code-formatter",
      "source": "./plugins/code-formatter"
    }
  ]
}

詳細なエラーパターンはClaude Code エラー一覧と解決手順も併用してください。

更新運用フロー ── PR → main → version → 自動更新

社内マーケットプレイスを継続運用するための標準フロー。

[1] 開発者がプラグインリポジトリに PR 作成
       ↓
[2] レビュー（セキュリティチェックリスト10項目）
       ↓
[3] main へマージ
       ↓
[4] plugin.json の version を上げる（または省略で自動コミット SHA 化）
       ↓
[5] リリースタグを切る（v1.2.3）
       ↓
[6] CI で marketplace.json の plugins[].version も同期更新
       ↓
[7] バックグラウンド自動更新 → 利用者の Claude Code に反映
       ↓
[8] 利用者は /plugin で更新差分を確認、必要なら /plugin disable

version を省略している場合は すべてのコミットが新バージョン として扱われるため、上記フロー [4]-[6] は不要です。安定運用が必要なチームには明示的バージョニング、社内検証チームには無バージョン運用、と使い分けるのが現実的です。

Gotcha ── プラグイン運用の落とし穴

プラグインの権限モデル（任意コード実行前提）

Claude Code のプラグインは ユーザー権限で任意のコードを実行可能 です。悪意あるプラグインをインストールすると、コード抜き取り・環境変数漏洩・任意コマンド実行のリスクがあります。Anthropic 公式の方針も「プラグインは任意コードを実行できる前提で、信頼できるソースのみインストールせよ」です。

• 公式 / Verified / 信頼できる作者のプラグインを優先
• /plugin の Discover タブで homepage / repository を確認
• コミュニティマーケットプレイスからのインストールは、作者とソースコードを実際に読んでから
• 組織で配布範囲を制御する場合は strictKnownMarketplaces のホワイトリスト統制を採用

Anthropic Verified の失効（再掲）

前述の通り、Verified バッジは永続保証ではなく失効する可能性があります。Gotcha として再確認しておくと、運用ルールに織り込みやすくなります。重要プラグインは半年に 1 回程度、/plugin の Discover タブで状態と作者の動向を確認してください。

権限モードの明示

プラグインが内部で呼び出すサブエージェントやスキルについて、パーミッションモード（default / acceptEdits / bypassPermissions）を必ず明示します。bypassPermissions は監査ログが残らないため、業務では default か acceptEdits を推奨します。

コマンド名の衝突

複数プラグインが同じコマンド名（例: /review）を定義することがあります。/plugin の Installed タブまたは claude plugin list で現在の割当を確認し、必要なら名前空間付き /<plugin>:<command> 形式を使って明示的に呼び分けてください。

自動更新の挙動

プラグイン更新は 手動が基本ですが、extraKnownMarketplaces で配布したマーケットプレイスはバックグラウンド更新の対象になります。更新時に権限要求が変わる可能性があるため、更新差分は /plugin で確認してから承認するのが安全です。

ファイル参照の落とし穴

プラグインはインストール時にキャッシュロケーション（~/.claude/plugins/cache）にコピーされます。../shared-utils のように プラグインディレクトリ外 を参照するパスは、コピー対象外のためエラーになります。共有ファイルが必要なら symlinks か、別プラグインとして切り出して依存させてください。

よくある質問

まとめと次のステップ

Claude Code プラグインマーケットプレイスは、「個人の工夫を組織の資産に変える」配布インフラです。Anthropic 公式 / Claude Marketplace パートナー / 社内 private / コミュニティの 4 配布チャネルと、extraKnownMarketplaces / enabledPlugins / strictKnownMarketplaces の 3 ガバナンス設定を組み合わせれば、毎日の Claude Code 体験を段階的に底上げしながら、組織のセキュリティ要件も満たせます。

自作プラグインの公開はハードルが高そうに見えますが、個人のワークフローをパッケージ化して公開するだけでも価値があります。まずはチーム内で .claude-plugin/marketplace.json を作って限定公開するところから始め、需要が見えたら公式マーケットプレイスへの提出を検討するのが現実的です。

次のステップ:

• スキル単体を学ぶ → Claude Code Skillsガイド
• MCP 統合を進める → Claude Code MCP連携ガイド
• サブエージェント活用 → Claude Codeサブエージェントガイド
• セキュリティ・統制 → Claude Code セキュリティ・エンタープライズガイド
• 企業導入の進め方 → Claude Code 企業導入ガイド
• 環境構築 → Claude Code インストール・初期設定
• エラー解決 → Claude Code エラー一覧と解決手順
• ビジネスとしての MCP → MCPサーバービジネスガイド

関連記事

• Claude Code完全ガイド
• Claude Codeスラッシュコマンド集
• Claude CodeでPR自動化
• Claude Code Hooksで自動化する5つの実例
• Claude Code TDDワークフロー
• Claude Designガイド