Claude Codeのプラグイン機能が一般提供されて半年、社内で50人を超えるチームに配るとなると「各自で好きに入れてもらう」では済まなくなる。セキュリティレビューを通さないサードパーティ製コマンドが本番リポジトリに触れる可能性があるし、AWSのMFAトークンを勝手に取りに行くようなhookが紛れ込めば、それだけで監査の対象になる。そこで効いてくるのが`settings.json`の三層ヒエラルキーだ。
優先度は上から Managed（管理者配布）、Project（リポジトリ同梱）、User（各開発者のホーム）の順で、Managedレイヤーは`/etc/claude-code/managed-settings.json`（Linux/macOS）あるいは`C:\ProgramData\ClaudeCode\managed-settings.json`（Windows）に置く。MDMやIntuneで配ればユーザーは上書きできない。ここに`enabledPlugins`のallowlistと`marketplaces`の固定URL、`permissions.deny`でシェル実行やネットワーク送信系のツールを封じるのが基本形になる。
中央マーケットプレイスは社内Gitリポジトリで十分運用できる。`.claude-plugin/marketplace.json`にプラグインのメタデータと署名済みtarballのURLを並べ、CIで検証してからマージする運用が現実的だ。弊社では`git+ssh://[email protected]/platform/claude-marketplace.git`を全社デフォルトにして、承認済みの23プラグインだけを公開している。未承認のプラグインを入れようとしても、Managedレイヤーの`allowedMarketplaces`で弾かれる。
ロールアウトで実際に詰まったのはhook権限の粒度だった。プラグインが`PreToolUse`でシェルを起動するタイプのものは、`permissions.additionalDirectories`の範囲外を触れないよう`workspace`キーで明示的に制限する必要がある。最初これを入れ忘れて、とあるlinterプラグインが`~/.aws/credentials`を読もうとしてブロックされ、エラーログで気づいた。逆に言えばデフォルトで防げている。
監査面ではOpenTelemetry経由で`claude_code.plugin.invocation`スパンをDatadogに流し、誰がどのプラグインを何回呼んだか、どのリポジトリで実行したかを四半期レビューしている。プラグイン単位のコスト按分もここから出せるので、FinOpsチームの納得感が段違いに上がった。
導入のコツは最初から全社強制にしないこと。パイロット部門で2週間走らせ、hook失敗率とユーザー体感を計測してから段階展開する。Managedレイヤーは強力だが、開発者の実験意欲を殺すと結局shadow ITが生まれる。allowlistは広めに、denyは狭く鋭くが鉄則だ。