2026年2月24日、Anthropic は Claude Code のプライベートプラグインマーケットプレイスを発表しました。これにより管理者は Anthropic のパブリックレジストリに手を加えることなく、プラグインをビルド、ホスト、制御できるようになります。このポストで得られるもの：スキルをバンドリングして配布可能なプラグインに接続するための正確なステップ、プライベート GitHub リポジトリでのホスティング、バージョン固定、2台目のマシンがクリーンなインストールを拒否した際の最も一般的な障害の診断。
チームがプラグインを必要とするとき
パブリックマーケットプレイスは個人の試験的な使用には問題ありません。ただし、2人以上が同じスラッシュコマンドや同じフックスクリプトに依存するようになると、その場しのぎの配布はすぐに崩壊します。誰かがファイルを手動でコピーするとき、わずかに異なるパスを使用し、Claude Code はレジストリが期待する名前と一致しないため、フックを静かに無視します。
プライベートマーケットプレイスの真の引き金は、ヘッドカウントではなく、マシン間の一貫性です。2人の開発者がいて両方が同じデプロイメントフックを必要とする場合、プライベートマーケットプレイスはセットアップの1時間に値します。20人いれば、それはオプションではありません。
もう1つの引き金は機密性です。Anthropic のプラグイン作成ドキュメントは明示しています：プラグインをチーム内部に保つには、プライベートリポジトリでマーケットプレイスをホストします。claude-community に提出するとプラグインが誰でも見たりインストールしたりできるようになります。プライベートリポジトリはそれを完全に避けます。プラグインが内部 API パターン、独自のスラッシュコマンド、またはインデックスされたくない何かを含む場合、プライベートルートが正しい方法です。
注目に値する点：チームが既に本番環境で MCP サーバーを実行している場合、プライベートプラグイン配布が2つのアプローチに重複しているが異なるユースケースを持つため、構造にコミットする前に、その構成にどのように適合するかを確認してください。
既存のスキルとフックをバンドリングする
プラグインはフォルダです。これが正直なまとめです。公式プラグインドキュメントに従うと、最小限の実行可能な構造は次のようになります。
my-plugin/
plugin.json
README.md
skills/
my-skill.md
hooks/
hooks.json
guard.sh
plugin.json はマニフェストです。プラグインに名前を付け、バージョンを宣言し、スキルおよびフックサブディレクトリを指します。切り詰めた説明的な例：
{
"name": "deployment-tools",
"version": "1.2.0",
"description": "Deployment workflow helpers for the platform team",
"skills": ["skills/"],
"hooks": "hooks/hooks.json"
}
スキルは Claude が何をできるかを定義するマークダウンファイルで、スラッシュコマンドはその内部にあります。フックは JSON 宣言で、シェルスクリプトをトリガーポイント（ツール呼び出し前、セッション後など）に接続します。2つの任意の組み合わせを1つのプラグインフォルダにバンドリングできます。スキルのドキュメントは、カスタムコマンドが今やスキルモデルの一部であるため、それらを独立した並列システムとして維持しないでください。
人々を困らせることの1つ：フックスクリプトは実行可能である必要があります。コミット前に chmod +x hooks/guard.sh を実行してください。Claude Code はパーミッションビットをチェックし、設定されていない場合はフックを静かにスキップします。
プライベートマーケットプレイスを作成・配布する
マーケットプレイスは特定のフォルダ構造を持つ GitHub リポジトリです。各プラグインは独自のサブディレクトリに存在します。リポジトリルートには利用可能なものをカタログする registry.json が必要です。プラグインマーケットプレイスドキュメントはこの構造を詳細に説明し、mrlm-xyz/demo-claude-marketplace のコミュニティデモは、スクラッチから構築する前に具体的なリファレンスが必要な場合、エージェント、コマンド、スキルを備えた2つの実行例を示しています。
リポジトリが存在したら、リポジトリルートの .claude/settings.json で Claude Code に知らせます:
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
},
"enabledPlugins": {
"deployment-tools@company-tools": true,
"code-formatter@company-tools": true
}
}
そのファイルをコミットします。これで、プロジェクトフォルダを信頼するすべてのチームメンバーは、別のプロンプトや手動の CLI ステップなしで、自動的にマーケットプレイスが追加されます。enabledPlugins ブロックは、その 2 つのプラグインがデフォルトで有効になっていることを意味します。不要な場合は、誰でもローカルで無効にできます。デフォルトは単に他のみんなの手間を減らすだけです。
Team または Enterprise プランを使用していて、Organisation 設定経由で配布している場合、マーケットプレイス リポジトリはプライベートまたはインターナルである必要があります。Claude GitHub App がそれを読むため、明示的にアクセス権を付与する必要があります。パブリック リポは、そのパスで暗黙的に失敗します。これは、より混乱しやすいエラー モードの 1 つです。
クライアント向け Claude Code 作業を大規模に管理しているチームの場合、Seahawk の Claude Code エージェンシー サービスはマーケットプレイス設定と継続的なプラグイン ガバナンスを処理するため、そのインフラストラクチャ自体を所有する必要はありません。
バージョンを制御し、更新をレビューする
ここがほとんどのプライベート マーケットプレイスで失敗する場所です。誰かが plugin.json でバージョンをピンしておき、同じタグの下で破壊的な変更をプッシュして、ロールバックが機能しなかった理由を不思議に思います。Git タグは、マニフェストのバージョン文字列だけでなく、ここでのバージョン真実の正しい単位です。
実際に機能するワークフロー:
- plugin.json の
versionフィールドをバンプします (semver に従います:1.2.0から1.3.0は後方互換の追加、2.0.0 は破壊的な変更)。 - コミットしてプッシュします。
- Git タグを作成します:
git tag v1.3.0 && git push origin v1.3.0。 registry.jsonを更新して、プラグイン エントリを新しいタグにポイントさせます。
マシンに特定のバージョンをインストールするには:
/plugin install deployment-tools@company-tools --version 1.3.0
前のタグにロールバックするには:
/plugin install deployment-tools@company-tools --version 1.2.0
--version フラグはソース リポジトリの Git タグに対して解決します。タグを付けていない場合、Claude Code はデフォルト ブランチの HEAD にフォールバックします。つまり、「ロールバック」は無意味です。すべてのリリースにタグを付けてください。10 秒かかり、実際の痛みを節約できます。
更新レビューについては、マーケットプレイス リポジトリを他の本番コードベースと同様に扱います: 最低でもプルリクエスト、最低 1 つの承認、および main にマージする前に README.md のチェンジログ エントリが必要です。Anthropic 自身のドキュメントでは、プラグインは任意のコードを実行できる非常に信頼されたコンポーネントであるため、プラグイン リポジトリの 1 人でマージ可能なポリシーはチーム サイズに関係なく悪い考えです。
2 番目のマシンでインストールをテストする
より広いチームに新しいプラグインをプルするよう指示する前に、まったく新しいプロファイルにインストールしてください。別のターミナルウィンドウではありません。埋め込まれたシークレットがなく、既存のプラグイン状態がなく、リポジトリの settings.json を超えた事前設定されたマーケットプレイス エントリがない新しいプロファイル。
クリーン な 2 番目マシン テストのためのチェックリスト:
- プロジェクト リポジトリをクローンします。
- Claude Code を開き、プロンプトが表示されたときにフォルダを信頼します。
/plugin marketplace listでマーケットプレイスが表示されていることを確認します。- プラグインを明示的にインストールします:
/plugin install deployment-tools@company-tools。 - プラグインが公開するスラッシュコマンドを実行し、期待される出力が返されることを確認します。
- 関連するツール呼び出しをトリガーし、出力を検査することで、フックが発火していることを確認します。
- 開発マシンの認証情報やローカルパスがレスポンスに含まれていないことを確認します。
この最後の確認は重要です。絶対パス（/Users/yourname/scripts/...）を参照するフックスクリプトは、他のマシンではすべて破損します。プラグインディレクトリからの相対パスか、チームが一貫して設定できる環境変数を使用してください。
名前、パス、依存関係のトラブルシューティング
インストール失敗のほとんどは3つのうちのいずれかです。
名前の不一致。plugin.jsonのプラグイン名は、マーケットプレイスリポジトリのディレクトリ名およびregistry.jsonで使用される名前と完全に一致する必要があります。大文字と小文字を区別します。plugin.jsonが deployment-tools と言っているのに、レジストリエントリが Deployment-Tools の場合、インストールコマンドは大文字小文字の区別に無関係に見える not-found エラーを返します。
フックのパスの問題。上述のように、絶対パスは「マイマシンではうまくいく」バグの最大の原因です。リリースをタグ付けする前に、ハードコードされたパスについてすべてのフックスクリプトを監査してください。grep -r "/Users" hooks/ で最も一般的なものが見つかります。
依存関係の欠落。フックスクリプトが外部バイナリ（jq、gh、docker、カスタム内部CLI）を呼び出す場合、README.mdでそのサンプルバージョンとともにその依存関係を文書化してください。Claude Codeは外部バイナリの依存関係を解決しません。jqがインストールされていないために静かに終了するフックは、診断が困難です。特にフックの存在を知らないチームメンバーにとってはそうです。
インストールが停止する場合に確認する価値のあるその他のことがいくつかあります。
- GitHub Appは、プライベートマーケットプレイスリポジトリへの読み取りアクセスが必要です。フェッチがハングしている場合は、組織の設定を確認してください。
extraKnownMarketplacesがsettings.jsonにあるのに、フォルダを信頼した後もマーケットプレイスが表示されない場合は、ファイルがコミットされており、信頼プロンプトが受け入れられ、却下されていないことを確認してください。enabledPluginsのプラグイン名は、name@marketplace 形式をきっちり使用する必要があります。マーケットプレイス修飾子なしでdeployment-toolsだけでは解決しません。
より深くしたい場合、dev.toのNagell氏による一連の記事は、自動バージョニングとリリースCIについて詳しく説明しています。CIステップを手動で構築する前に読む価値があります。
プラグイン単独を超えた実際の開発ワークフローにClaude Codeがどのように適合するかについてのより広いコンテキストについては、Claude Codeの超能力に関するこの概要が便利な参考資料です。
FAQ
マーケットプレイスをGitHub以外の場所でホストできますか?
settings.jsonの source フィールドは、現在のプラグインマーケットプレイスドキュメントに従って github と local をサポートしています。ローカルパスは単一マシンまたはマウントされたネットワーク共有で機能しますが、git対応のソースのような自動更新には対応していません。バージョン追跡によるチーム配布については、プライベートGitHubリポジトリが現在実用的な選択肢です。
チームメンバーはプライベートマーケットプレイスリポジトリへの独自のGitHubアクセスが必要ですか?
直接的には不要です。TeamまたはEnterpriseプランの組織設定を使用して配布している場合、Claude GitHub Appは彼らの代わりにリポジトリを読み取ります。settings.json の extraKnownMarketplaces を組織同期パスなしで使用している場合、各ユーザーは独自のGitHub認証情報またはデプロイキーを通じてリポジトリへの読み取りアクセスが必要です。
enabledPlugins と実際にプラグインをインストールすることの違いは何ですか?
settings.json の enabledPlugins は、プロジェクトフォルダが信頼されたときにプラグインを自動的にアクティブにします。これは強制されたインストールではなく、デフォルトです。ユーザーはローカルでプラグインを無効にすることもできます。/plugin install で手動でインストールすると、settings.json が何と言おうと、プラグインが追加されます。2つのメカニズムは一緒に機能します。利便性のためのデフォルト、プロジェクトコンテキスト外のすべての対応。
1つの組織に複数のプライベートマーケットプレイスを持つことはできますか?
はい。extraKnownMarketplaces オブジェクトは複数のキーを受け入れます。各キーはローカルマーケットプレイスのエイリアスであり、各キーは別のソースリポジトリを指します。同じ settings.json に company-tools、data-team-plugins、security-tools をすべて登録することができます。エイリアスが一意であり、claude-plugins-official または claude-community と衝突しないようにしてください。
これはAnthropicの公式マーケットプレイスとどのように相互作用しますか？
両者は共存します。Claude Codeは最初のインタラクティブ起動時に自動的にclaude-plugins-officialを登録します。プライベートマーケットプレイスはその横に追加されます。プライベートマーケットプレイスのプラグインはplugin-name@your-aliasとして参照され、公式プラグインはplugin-name@claude-plugins-officialとなります。プラグイン名が公式のものと重複して解決の曖昧性を引き起こさない限り、衝突は発生しません。
この全体における最も重要な注意点：gitタグは唯一の信頼性のあるロールバック機構です。plugin.jsonのバージョン文字列が対応するタグを持たない場合、それは復旧オプションではなく装飾に過ぎません。