組織向けの mod を管理する

• ユーザーの独自 mod を除外する（独自の mod の有無を問わず）: ユーザーがインストールした mod の読み込みを停止する
• 何も変更しない場合に何が起こるかを確認する: デフォルトで何が起こるかを理解する
• mod を有効にして他の制限を設定する: 許可する範囲を選択する

​

ユーザーがインストールした mod の読み込みを停止する

{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": {
        "allowManagedModsOnly": true
      }
    }
  }
}

• ユーザーが持ち込む mod は読み込まれません：ユーザーがインストールしたプラグイン内の mod、--plugin-dir で読み込まれた mod、および Claude がセッション中に作成した mod が対象です
• 組織の mod は引き続き読み込まれます：組織のものとしてカウントされる mod はチェックされません。その他のすべての mod はユーザーのものとしてカウントされ、読み込まれません。これには、GitHub または他のリモートマーケットプレイスから有効にしたプラグイン内の mod、および組織が claude.ai でメンバー向けに有効にした mod が含まれます。組織のものとしてカウントされるものがない場合、インストールされた mod は読み込まれません
• ユーザーはこれを元に戻せません：ガードはマネージド設定からのみオプションを読み取るため、ユーザー、プロジェクト、またはローカル設定ファイル内の同じエントリ、または --settings で渡されたファイル内のエントリは何も変わりません
• ファイルまたは MDM ポリシーはすべてのプロバイダーに対応します：オプションをファイルとして、または MDM を通じて配信する場合、Amazon Bedrock、Google Cloud の Agent Platform、および Microsoft Foundry で同じように機能します。claude.ai 管理コンソールからの配信については、プラットフォームの可用性 を参照してください
• ユーザーの他のカスタマイズは引き続き機能します：設定ファイル内の hooks、ステータス行、および /goal は影響を受けません
• 組み込み mod は引き続き実行されます：AGENTS.md サポートなど Claude Code に組み込まれた mod には、それぞれ独自のスイッチ があります

​

デフォルトで何が起こるかを理解する

• Mod は有効です。 ユーザーは、プラグイン設定が許可するマーケットプレイスから mod を含むプラグインをインストールするか、--plugin-dir を使用してディレクトリから読み込むことができます。
• 組み込みガードが最初に実行されます。 Claude Code は、ユーザーがインストールしたすべての mod の前に、sec-default@builtin という名前の組み込み mod を読み込みます。ユーザーはそれをオフにすることはできません。/plugin とデバッグログは、それを cc-plugin-sec-default として一覧表示します。ガードは以下のいずれかが真の場合に読み込まれます。
  • マシンに管理設定がある
  • ユーザーが Team または Enterprise プランで Claude Code にサインインしている
  API キー、または Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry を通じて認証するユーザーは、管理設定を持つマシンでのみガードを取得します。
• ガードは管理対象を保護します。 ユーザーの mod は、管理フックが受け取るもの、システムプロンプト、管理対象の CLAUDE.md およびその他の管理対象の指示、mod が設定として読み取るもの、または管理対象の MCP サーバーのツールと説明を変更することはできません。
• その他はすべて許可されます。 ガードは他の制限を追加しません。ユーザーの mod は、ファイルの読み取りと書き込み、プロセスの開始、ネットワークリクエストの実行、ツール呼び出しとプロンプトの書き直し、ツール呼び出しの拒否、そうでなければプロンプトが表示されるツール呼び出しの承認、インターフェイスへの描画をすべてそのユーザーの権限で実行できます。
• 拒否ルールと管理フックが優先されます。 ガードが読み込まれる場所では、ユーザーの mod は、deny ルールが拒否する呼び出しを承認することはできません。ルールを保持する設定ファイルがどれであれ。管理設定の PreToolUse フックからのブロックも最終的です。どちらも Claude のツール呼び出しに適用されます。どちらも mod 独自の $.fs と $.process 呼び出し には適用されません。Read(.env) が拒否されている場合、mod は $.fs.read でそのファイルを読み取るか、それを実行するプログラムを開始できます。これらの呼び出しを制限するには、mod の読み込みを防ぐか、ポリシー mod で呼び出しをフックしてください。
• 他の権限チェックはオーバーライドできます。 ツール呼び出しを承認するユーザーの mod は、ask ルールがプロンプトを表示する呼び出し、または管理設定外の PreToolUse フックがブロックした呼び出しを承認できます。自動モードでは、mod が承認する呼び出しは分類器チェックなしで実行されます。

​

どのコントロールが引き続き適用されるかを知る

• 設定フックは引き続き機能します。 設定ファイルおよびプラグインの hooks/hooks.json 内のコマンド、HTTP、プロンプト、エージェントフックは以前と同じように実行され、mod と並行して実行されます。これについて非推奨のものはありません。
• 拒否ルールはガードが読み込まれる場所で優先されます。 ユーザーの mod は、deny ルールが拒否する呼び出しを承認することはできません。ただし、allowModsToOverrideDenyRules を設定する場合を除きます。
• 管理フックが最初に実行されます。 管理設定の PreToolUse フックは、mod がツール呼び出しを見る前に実行され、そのブロックは最終的です。mod がその後呼び出しを書き直す場合、管理フックは書き直された呼び出しで再度実行されるため、ブロックは引き続き適用されます。他の設定ファイルおよびプラグインからの PreToolUse フックは最後の mod の後に実行されるため、独自の結果を返すツール実行の代わりに返す mod は、それらが実行されるのを防ぎます。Mod が実行される順序 を参照してください。
• ネットワークポリシーは $.http.fetch をカバーします。 組織が Web フェッチをオフにするか、セッションの非必須ネットワークトラフィックがオフになっている場合、Claude Code は mod が $.http.fetch で実行するネットワークリクエストを拒否します。ポリシーは mod が $.process.run で開始するプログラムをカバーしません。そのプログラムはユーザー独自のアクセスでネットワークに到達します。
• プラグインコントロールは mod をカバーします。 Mod はプラグインであるため、ユーザーがインストールできるものを制限する設定（strictKnownMarketplaces など）は、それをインストールできるかどうかを決定します。
• Mod は権限プロンプトを変更できません。 Mod は Claude Code のインターフェイスの大部分を再スタイル化できますが、権限プロンプトはできないため、プロンプトが表示するものを変更できません。Mod は、デフォルトで何が起こるかを理解する で説明されているように、プロンプトが表示される前にツール呼び出しを承認または拒否できます。
• 信頼プロンプトが最初に表示されます。 ユーザーがまだ信頼していないディレクトリでのインタラクティブセッションでは、信頼プロンプトに答えるまで mod は読み込まれません。
• --safe-mode はインストールされた mod をオフにします（独自の mod を含む）。 セッションを claude --safe-mode で開始して、mod が問題を引き起こしたかどうかを確認します。

​

Mod を有効にするかどうかを決定する

​

Mod が実行できることを確認する

claude plugin validate ./some-mod

  ❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
  ❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open

​

許可する範囲を選択する

• allowManagedModsOnly: 組み込みガードのオプション。ユーザーの独自 mod は読み込まれず、設定フック、ステータス行、/goal は引き続き機能します。ユーザーがインストールした mod の読み込みを停止する はそれがカバーするものを一覧表示しています。
• allowManagedHooksOnly: より広い設定。組織の mod と Claude Code に組み込まれた mod のみが読み込まれます。ユーザーが自分でインストールした mod は読み込まれません。設定はユーザー独自の設定ファイル内のフックもブロックします。設定する前に 「allowManagedHooksOnly の下で実行されるもの」 を読んでください。
• disableAllHooks: 最も広い設定。管理設定では、インストールされたすべてのプラグイン（組織のものを含む）の mod を停止し、設定ファイル内のすべてのフックをオフにするため、管理設定の PreToolUse フックはもはや何もブロックしません。カスタムステータス行と /goal も機能しなくなります。設定する前に disableAllHooks を読んでください。
• disableSideloadFlags: スタートアップで --plugin-dir と --plugin-url を拒否するため、誰もディレクトリから mod を読み込まず、Claude がセッション中に作成した mod の読み込みを防ぎます。設定は --agents と --mcp-config も拒否します。設定する前に disableSideloadFlags を読んでください。

​

組み込みガードでオプションを設定する

• ID はここで 1 つのスペルを持ちます: Claude Code はオプションを cc-plugin-sec-default@builtin の下でのみ読み取ります。prependPlugins は sec-default@builtin も受け入れ、pluginConfigs は受け入れません。
• 管理設定のみがカウントされます: ユーザー、プロジェクト、またはローカル設定ファイル内の同じエントリ、または --settings で渡されたファイル内のエントリは、オプションを設定したり、オプションを緩和したりしません
• ガードが読み込まれる必要があります: prependPlugins を設定する場合、リストでガードに名前を付けます。ガードが読み込まれない場所では、どちらのオプションも適用されません。
• ガードは閉じた状態で失敗します: ガードが管理設定を読み取ることができない場合、すべてのユーザーの mod を読み込み時に拒否します。ユーザーの mod が承認した呼び出しの拒否ルールをチェックできない場合、呼び出しを拒否します。

​

組織独自の mod をデプロイする

​

組織の mod をインストールして順序を設定する

• 管理対象の enabledPlugins が mod のプラグインを true に設定する
• 管理対象の設定が、プラグインの marketplace をユーザーのマシン上のディレクトリとして、絶対パスで指定する。extraKnownMarketplaces エントリがそれを行い、ユーザーのマーケットプレイスも登録する
• マーケットプレイスがプラグインを相対パスでリストアップするため、Claude Code はそのディレクトリから in-place で読み込みます

/opt/acme/claude-plugins/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    └── acme-guard/
        ├── .claude-plugin/
        │   └── plugin.json
        └── hooks/
            ├── hooks.json
            └── register.js

{
  "name": "acme-tools",
  "owner": { "name": "Acme" },
  "plugins": [
    { "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
  ]
}

• prependPlugins: 組織の mod はすべてのユーザーの mod の前にすべてのイベントを見て、その後すべての結果を見ます。イベントを変更したり、拒否したり、ユーザーの mod をスキップできます。
• appendPlugins: 組織の mod はすべてのユーザーの mod の後に実行されるため、それらの mod が渡すイベントのみを、渡す形式で見ます。

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
    }
  },
  "enabledPlugins": { "acme-guard@acme-tools": true },
  "prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}

• extraKnownMarketplaces: acme-tools マーケットプレイスを保持するディレクトリに名前を付けます。path は .claude-plugin/marketplace.json を含むディレクトリの絶対パスです。
• enabledPlugins: これらの管理対象の設定を受け取るすべてのユーザーに対して acme-guard をオンにします。
• prependPlugins: acme-guard を最初に、組み込みガードを 2 番目に配置し、両方ともユーザーがインストールする mod の前に配置します。Claude Code はリストアップした順序に従います。

• hooks module acme-guard@acme-tools loaded、tier prepend 付き: mod は組織のものとしてカウントされ、最初に実行されます。
• 同じ行に tier user 付き: Claude Code はそれをユーザーの mod として扱います。2 番目の行、prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped は、リストがそれをスキップしたことを示しています。

• リストはデフォルトを置き換えます: 管理対象の設定で prependPlugins を設定する場合、組み込みガードを保つために sec-default@builtin をそこに名前を付けます。ガードは組み込まれており、enabledPlugins エントリは必要ありません。
• 独自の id は組織のものとしてカウントされる必要があります: 管理対象の設定では、プラグインが組織の mod の 3 つの条件を満たさない id をスキップします。
• リポジトリはそれらを設定できません: Claude Code は両方の設定を管理対象の設定から読み取り、リポジトリの設定ファイルからは読み取りません。ユーザーは ~/.claude/settings.json でそれらを設定して、管理対象の設定がなく、Team または Enterprise プランでサインインしていないマシンでのみ独自の mod の順序を設定できます。他の場所では、Claude Code はユーザー設定の両方のキーを無視します。そこのリストは、組み込みガードを追加したり削除したりしません。

​

独自の mod でポリシーを強制する

// ユーザーの mod が呼び出してはいけないメソッド、各々は namespace.method でスペル
const BLOCKED_CALLS = ['process.run', 'process.spawn']

export function register(on) {
  // 別の mod が読み込まれようとするたびに実行
  on('plugin.register', async ($, e, next) => {
    // その mod のコード内のブロックリストにある呼び出しを保持
    const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
    if (e.tier === 'user' && blocked.length > 0) {
      // refuse を返すと mod の読み込みが防止され、テキストが理由です
      return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
    }
    // 他のすべての mod を読み込ませる
    return next(e)
  })

  // 各ツール呼び出しを記録し、その後変更なしで進める
  on('tool.call', async ($, e, next) => {
    $.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
    return next(e)
  })

  // どの mod がファイルを書き込んだか、その後パスを記録し、mod が選択したため引用符で囲む
  on('fs.write', async ($, e, next) => {
    $.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
    return next(e)
  })
}

• plugin.register: 別の mod が読み込まれるかどうかを決定します。ブロックされたメソッドを呼び出すユーザーの mod を拒否し、他のすべての mod を渡します。
• tool.call: 各ツール呼び出しに対して audit tool.call Bash などの行をデバッグログに書き込み、何も変更しません。
• fs.write: 別の mod が行う各 $.fs.write 呼び出しに対して audit fs.write by reader "/tmp/notes.md" などの行を書き込み、何も変更しません。mod の名前が最初に来て、パスが引用符で囲まれているため、mod が選択するパスは行の別のフィールドとして渡すことはできません。

• e.tier: mod が実行される場所、prepend、user、append、または builtin のいずれか。人がインストールするすべての mod は user です。
• e.uses.calls: mod が呼び出す mod API メソッド、各々は process.run などの namespace.method でスペル、claude plugin validate が出力する $. なし。

​

チェックが失敗したときに mod を拒否する

const BLOCKED_CALLS = ['process.run', 'process.spawn']

// 前と同じチェック、独自の関数に移動
async function checkMod($, e, next) {
  const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
  if (e.tier === 'user' && blocked.length > 0) {
    return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
  }
  return next(e)
}

export function register(on) {
  // ハンドラーは checkMod がスローするか時間制限を超えたときのみ実行
  on('plugin.register', checkMod).catch(async ($, e, next) => {
    // 組織の mod と組み込み mod を読み込ませる
    if (e.tier !== 'user') return next(e)
    // チェックできなかったユーザーの mod を拒否
    return { refuse: 'Acme policy check failed, so this mod was not loaded' }
  })
}

​

次のステップ

• プラグインセキュリティ: ユーザーのマシンで任意のプラグインが実行できることと、インストール前にプラグインを確認する方法
• Mod の概要: mod とは何か、フック、スキル、MCP サーバーとの比較
• Mod が実行される順序: prependPlugins と appendPlugins がユーザーの mod とどのように適合するか
• 設定と環境変数: このページで名前が付けられたすべての設定を 1 つの表で