Claude Codeプラグイン配布を自社基盤で統制する

Q: Claude Codeプラグインは何を配布する仕組みか

プラグインはskills・commands・agents・hooks・MCP/LSPサーバー・bin/実行ファイルを1つにまとめて配布する単位である。

Q: 独自マーケットプレイスはどう構築するか

マーケットプレイスは.claude-plugin/marketplace.jsonを置いたリポジトリで、name・owner・plugins配列が必須項目になる。

Q: プラグインの信頼モデルはどう機能するか

マーケットプレイス名は公式・コミュニティ・サードパーティの3層に分かれ、github.com/anthropics/以外からの名乗りは拒否される。

Q: 組織全体にどう強制適用するか

managed settingsのextraKnownMarketplacesとenabledPluginsで、社内マーケットプレイスとプラグインをセッション開始時に自動導入できる。

Claude Codeを使うメンバーが増えると、社内標準のコマンドやフックをどう配布するかが課題になる。Slackでスクリプトを共有し、各自が手元にコピーする運用は、更新が反映されない・誰が何を使っているか分からないという状態にすぐ陥る。

エージェントガバナンスの観点では、配布そのものを設定に落とし込む必要がある。Claude Codeにはプラグインとその配布カタログであるマーケットプレイスの仕組みが公式に用意されており、自社製のマーケットプレイスを作れば、コマンド・エージェント・フック・MCPサーバーをひとつの単位として全社に配れる。本記事では構築から強制適用までの設計を整理する。

Claude Codeプラグインは何を配布する仕組みか

プラグインはskills・commands・agents・hooks・MCP/LSPサーバー・bin/実行ファイルを1つにまとめて配布する単位である。

公式ドキュメントによれば、プラグインはこれら複数の構成要素を1パッケージにまとめられる。skills・commands・agentsはClaudeの文脈に指示として入るだけだが、hooksはツール呼び出しの前後でシェルコマンドを実行し、MCP/LSPサーバーはプロセスとして起動し、bin/配下の実行ファイルはBashツールのPATHに追加される。つまりプラグインを1つインストールするだけで、ユーザー権限でコードを実行できる経路が複数増える。配布する側はこの前提で設計する必要がある。

独自マーケットプレイスはどう構築するか

マーケットプレイスは.claude-plugin/marketplace.jsonを置いたリポジトリで、name・owner・plugins配列が必須項目になる。

plugins配列の各エントリはnameとsourceを持ち、sourceはマーケットプレイス直下の相対パスか、github・git-subdirなどのソースオブジェクトで指定する。claude plugin validate ./my-marketplaceでJSON構文・必須項目・相対パスの..混入を検査できる。ローカルで動作確認したら、Gitリポジトリとしてホストし、メンバーはclaude plugin marketplace add /で登録、claude plugin install @でインストールする流れになる。

プラグインの信頼モデルはどう機能するか

マーケットプレイス名は公式・コミュニティ・サードパーティの3層に分かれ、github.com/anthropics/以外からの名乗りは拒否される。

公式・コミュニティの予約名（claude-plugins-officialなど）はgithub.com/anthropics/配下のソースでしか通らず、社内マーケットプレイスは必ずサードパーティ層になる。hooksとMCP/LSPサーバーはClaude Codeのサンドボックスとパーミッションルールの外で動くため、Claudeのツール呼び出しに対する許可設定を厳しくしても、プラグイン自身のコードは素通りする。配布前にhooks/hooks.jsonと.mcp.jsonの中身を必ず読む運用を前提にすべきだ。

組織全体にどう強制適用するか

managed settingsのextraKnownMarketplacesとenabledPluginsで、社内マーケットプレイスとプラグインをセッション開始時に自動導入できる。

extraKnownMarketplacesでマーケットプレイスを登録し、enabledPluginsにplugin-name@marketplace-name: trueを並べると、対象ユーザーの次回セッション開始時に自動でインストール・有効化される。逆にfalseを指定すれば、全スコープでそのプラグインをブロックしユーザー側の一覧からも隠せる。さらにstrictKnownMarketplacesでソースの許可リストを敷けば、社内マーケットプレイスと公式マーケットプレイス以外からのインストールを拒否でき、disableSideloadFlagsと組み合わせれば--plugin-dirによる抜け道も塞げる。

規模別の留意点（SMB / エンタープライズ）

数名〜十数名のチームであれば、まずGitHubの private リポジトリでマーケットプレイスを作り、claude plugin marketplace addをオンボーディング手順に入れるだけで十分に統制できる。数百台規模の端末を持つエンタープライズでは、server-managed settingsまたはmanaged-settings.json経由でenabledPluginsを強制配布し、strictKnownMarketplacesで自社リポジトリと公式マーケットプレイスのみを許可する構成が前提になる。大規模なマルチチーム統制やベンダーリスク評価を含めた設計は、KuuのRDEが支援領域としている。

参考

まとめ

Claude Codeのプラグインとマーケットプレイスは、社内標準のコマンド・フック・MCPサーバーを「共有ドキュメント」から「設定として強制適用できる配布物」に変える。ただしhooksとMCP/LSPサーバーはサンドボックスの外で動くため、配布する側が中身を審査する責任は変わらない。まずは小さなマーケットプレイスで配布ルートを作り、規模が大きくなったらmanaged settingsのallowlistとenabledPluginsで強制へ移行するのが現実的な順序だ。設計に迷う場合は、KuuのAI Opsに相談してほしい。