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

> Claude Codeのプラグインは自社の`marketplace.json`で配布でき、managed settingsの`enabledPlugins`とallowlistで組織全体への強制適用も設計できる。構築手順を解説する。

- Canonical: https://kuucorp.com/blog/claude-code-plugin-marketplace-governance-design/
- Date: 2026-09-28
- Last modified: 2026-09-28
- Publisher: Kuu株式会社 (https://kuucorp.com)

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

[エージェントガバナンス](/glossary/agent-governance/)の観点では、配布そのものを設定に落とし込む必要がある。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 <owner>/<repo>`で登録、`claude plugin install <name>@<marketplace>`でインストールする流れになる。

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

> マーケットプレイス名は公式・コミュニティ・サードパーティの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](/blog/claude-code-hooks-audit-policy-enforcement-smb/)または`managed-settings.json`経由で`enabledPlugins`を強制配布し、`strictKnownMarketplaces`で自社リポジトリと公式マーケットプレイスのみを許可する構成が前提になる。大規模なマルチチーム統制やベンダーリスク評価を含めた設計は、Kuuの[RDE](https://kuucorp.com/services/rde/)が支援領域としている。

## 参考

- [Create a marketplace - Claude Code Docs](https://code.claude.com/docs/en/plugin-marketplaces)
- [Plugin security and trust - Claude Code Docs](https://code.claude.com/docs/en/plugins/security)
- [Manage Claude Code plugins for your organization - Claude Code Docs](https://code.claude.com/docs/en/plugins/org)

## まとめ

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