Claude Code blockedMarketplacesで特定マーケットプレイスを遮断する設定

blockedMarketplacesで何ができるか

blockedMarketplacesは、組織のmanaged settingsだけに書ける配列キーです。指定した供給元からのプラグイン取得を組織全体で禁止します。判定はマーケットプレイスの追加時だけでなく、プラグインのインストール・更新・再取得・自動更新のすべての経路で走ります。ダウンロードより前に判定するため、ブロック対象はファイルシステムに一切触れません。ポリシーを設定する前に誰かがローカルで登録済みのマーケットプレイスがあっても、以後はそこからプラグインを取得できなくなります。

たとえば、社内のセキュリティ監査で特定のGitHubリポジトリが不審なプラグインを配布していると分かったとします。そのリポジトリをblockedMarketplacesに加えれば、すでに一部の開発者が/plugin marketplace addで登録済みでも、以後のインストール・更新・自動更新はすべて失敗します。個別の端末を回って設定を消して回る必要はありません。

似た名前のstrictKnownMarketplacesは許可リストで、blockedMarketplacesは拒否リストです。両者は判定の作り自体が違うので、使い分けは後の節で並べて比較します。

特定の供給元を名指しで遮断する設定

managed-settings.jsonに次のように書きます。

{
  "blockedMarketplaces": [
    { "source": "github", "repo": "untrusted/plugins" }
  ]
}

blockedMarketplacesのスコープはManagedだけです。書けるのは組織が配信するmanaged-settings.json・MDMポリシー・サーバー管理設定のいずれかに限られます。開発者個人の~/.claude/settings.jsonやプロジェクトの.claude/settings.jsonに書いても効きません。配信経路と優先順位はClaude Code組織管理ガイドにまとめています。個々のフィールドの全体像はClaude Code設定ガイドを参照してください。

供給元の指定方法はstrictKnownMarketplacesと共通で、次の種類があります。

社内でnpmパッケージとしてプラグインカタログを配布している場合は、{ "source": "npm", "package": "@acme-corp/claude-plugins" }のように書けば、そのパッケージ単位で遮断できます。file / directoryはネットワークを介さないローカル供給元向けで、共有ドライブや配布用イメージにmarketplace.jsonを直接配置する社内運用を遮断したいときに使います。

skills-dirエントリだけは性格が違います。供給元を遮断するのではなく、@skills-dirプラグインとしての~/.claude/skills/自動読み込みそのものを止めます。このエントリの意味はblockedMarketplacesとstrictKnownMarketplacesの外では成立しません。

hostPatternでホストごと遮断する場合、供給元の種類によって判定できるホストの取り方が異なります。githubソースは常にgithub.comと比較します。urlソースはURLからそのままホスト名を取ります。gitソースはURLの形式次第でホストの取れ方が変わります。

gitソースのうち、https://やssh://のようにスキーム付きのURLなら、そのままホスト名を取れます。git@git.example.com:tools/plugins.gitのようなスキームなしのSSH形式(user@host:path)でも、@と:の間からホストを取れます。それ以外のスキームなしの書き方では、Claude Codeはホストを特定できません。

ホストを特定できないこの書き方は、strictKnownMarketplacesのhostPatternには一致しません。一方blockedMarketplacesのhostPatternは、より広い書式からホストを取り出せるため一致することがあります。許可リスト側では素通りしてしまう表記でも、拒否リスト側なら捕まえられる場合があるということです。なお、v2.1.234より前はstrictKnownMarketplacesのhostPatternが、gitがSSH形式とみなさない一部の書式にも誤って一致していました。file / directoryソースはそもそもホストを持たないのでhostPatternには一致せず、代わりにpathPatternを使います。

{
  "blockedMarketplaces": [
    { "source": "pathPattern", "pathPattern": "^/mnt/shared/" }
  ]
}

このエントリは/mnt/shared/配下のファイルシステムマーケットプレイスをまとめて遮断します。社内共有ストレージの特定領域だけを締め出したいときに使えます。

遮断が強化されてきた経緯

blockedMarketplacesは最初から全経路をカバーしていたわけではありません。バージョンごとの補強を並べると、拒否リストとしての実効性がどう積み上がったかが分かります。

v2.1.119の修正が示すとおり、hostPattern / pathPatternは初期の実装では正しく強制されていませんでした。ホスト単位・パス単位でまとめて遮断する設定を組んでいた環境ほど、この時期は拒否リストに穴が空いていたことになります。

v2.1.232の変更はurlエントリに限った話です。ユーザーがhttps://github.com/...のようなベアなリポジトリURLを追加しようとすると、Claude Codeはそれをmarketplace.jsonとして取得せずgit clone扱いにします。この形は以前はurlエントリと比較されず、事実上ブロックの対象外でした。v2.1.232以降は.git拡張子や#以降のref指定を無視したうえで同じURLとして突き合わせるため、表記ゆれが抜け道になりません。

4回の変更を並べて見えるのは、blockedMarketplacesが一度作って終わりの設定ではなく、プラグインの取得経路が増えるたびに追いつくように補強されてきた設定だという点です。特定のバージョンで意図どおりに遮断できていたとしても、新しい取得経路が加わればそこだけ穴が残る可能性があります。managed-settings.jsonを配る対象のClaude Codeバージョンが、狙った遮断ルールに対応しているかは設定のたびに確認しておくと安全です。

strictKnownMarketplacesとの使い分け

判定範囲の広さがちょうど逆向きに設計されています。拒否リストは取りこぼして通してしまうことがリスクなので表記ゆれを広く同一視し、許可リストは意図せず許可を広げてしまうことがリスクなので一致条件を狭く取ります。特定の危険な供給元だけを狙い撃ちで塞ぎたいならblockedMarketplaces、公式または自社リポジトリ以外を丸ごと締め出したいならstrictKnownMarketplacesという役割分担です。

strictKnownMarketplacesの空配列[]は完全ロックダウンという特別な意味を持ちますが、blockedMarketplacesの空配列にドキュメント上の特別な挙動は記載されていません。拒否リストとしての性質上、空にすれば実質的に未設定と同じで何も遮断しない扱いになります。この非対称を知らずにblockedMarketplaces: []を「安全側の初期値」として書いても、遮断の効果はありません。

両方を同じmanaged-settings.jsonに書いて、許可リストと拒否リストを重ねて運用することもできます。

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/*" }
  ],
  "blockedMarketplaces": [
    { "source": "github", "repo": "acme-corp/deprecated-plugins" }
  ]
}

acme-corp配下を丸ごと許可しつつ、その中の1リポジトリだけを名指しで遮断する構成です。関連する設定にdisableSideloadFlagsがあります。--plugin-dirや--mcp-configのようなCLIフラグでstrictKnownMarketplacesを単発で回避されるのを防ぐものです。ただし公式ドキュメントが説明しているのはstrictKnownMarketplacesのバイパス対策としての役割で、blockedMarketplacesとの関係は明記されていません。

GHESやGitLabの内部サーバーを許可リスト化する運用はGHESプラグインマーケットプレイスを許可リストで運用するで扱っています。マーケットプレイスや/pluginコマンドの全体像はClaude Codeプラグイン(Plugins)完全ガイドを参照してください。

マーケットプレイス単位の遮断とプラグイン単位の遮断は別物

blockedMarketplacesが遮断するのは供給元、つまりマーケットプレイス単位です。許可されているマーケットプレイスの中にある特定のプラグイン1つだけを狙って止めたい場合、この設定では実現できません。個別のプラグインを止めるにはmanaged設定のenabledPluginsを使い、"plugin-name@marketplace-name": falseと書きます。managed settingsでのfalseはそのプラグインをすべてのスコープでインストール不可にし、マーケットプレイス一覧からも隠します。

判定の対象が「供給元」だけである点は、もう1つ見落としを生みます。マーケットプレイス自体は許可していても、そこに登録されたプラグインがcommandソース(マーケットプレイスが指定したコマンドを実行して取得する形式)を使っていることがあります。strictKnownMarketplacesの判定はマーケットプレイスの供給元しか見ないため、この経路は素通りします。コマンドソース経由の取得そのものを止めたい場合は、disableCommandPluginSourcesをtrueにします。blockedMarketplaces / strictKnownMarketplaces / enabledPlugins / disableCommandPluginSourcesは、供給元・個別プラグイン・実行経路という別々の層を担当します。どれか1つを設定しても、残りの層は自動的には塞がりません。

設定するときに見落としやすい点

{
  "blockedMarketplaces": [
    { "source": "github", "repo": "untrusted-org/*" }
  ]
}

このエントリはGitHubのuntrusted-org配下すべてのリポジトリをマーケットプレイス供給元として遮断します。*単体やacme-corp/tools-*のような部分ワイルドカードは文字通り比較されるため、どのリポジトリにも一致しません。オーナー名全体をowner/*の形で書く必要があります。

v2.1.232ではキーの別名も追加されましたが、対象はextraKnownMarketplaces(additionalMarketplaces)とstrictKnownMarketplaces(allowedMarketplaces)の2つだけです。blockedMarketplacesに別名は用意されておらず、書けるのはこの1つのスペルだけです。設定ファイルを複数のバージョン混在環境に配る際は、この非対称に注意します。

配信したblockedMarketplacesが実際に読み込まれているかは、開発者側のセッションで確認できます。

/status

出力の設定ソースの行に、どの経路(サーバー管理・MDMポリシー・managed-settings.jsonなど)から設定が適用されているかが表示されます。ファイルベースで配ったつもりが優先度の高いサーバー管理設定に上書きされている、といった食い違いはここで見つかります。

まとめ

blockedMarketplacesは、許可リストを作り込む前に特定の供給元だけをピンポイントで塞ぎたい場面に向いた設定です。管理設定にしか書けず、マーケットプレイス追加からインストール・更新・自動更新まで一貫して効きますが、オーナーワイルドカードの対応バージョンや、キーに別名が用意されていない点は事前に確認しておく必要があります。組織全体を許可リストで縛りたい場合はstrictKnownMarketplacesとの併用を検討します。配信後は/statusで反映状況まで確認して、設定した側と読み込んだ側の食い違いを残さないようにします。