Claude Codeに企業ポリシーを配布する方法｜managed-settings.jsonでbypassPermissions禁止・コマンド規制を強制する

managed-settings.jsonとは？ユーザーが上書きできない管理者設定

managed-settings.jsonは、Claude Codeの組織管理ポリシー（マネージド設定）を定義するファイルです。通常のsettings.jsonと同じ書式ですが、決定的な違いが1つあります：ユーザー設定・プロジェクト設定・CLI引数のどれを使っても上書きできないことです。

これで実現できることの代表例：

• 確認なし全自動実行モード（bypassPermissions）の組織的な禁止
• 危険なコマンド（rm -rf、curl等）の強制ブロック
• 機密ファイル（.env、秘密鍵）の読み取り禁止
• 利用できるMCPサーバーの許可リスト化
• Claude Codeの最低バージョン強制、ログイン方法の固定

個人のsettings.jsonの基本（置き場所・権限設定・Hooks）については、settings.json完全ガイドで解説しています。本記事はその「組織管理版」です。

設定の優先順位：なぜユーザーのsettings.jsonでは破れないのか

Claude Codeの設定は5層の優先順位で評価されます。

重要なのは、マネージド設定がCLI引数よりも上位にあることです。マネージド設定のdenyルールは--allowedToolsでは突破できません。また、いずれかの層でdenyされたツールは、他のどの層がallowしても拒否されます（deny優先）。

配置場所と書き方（実機検証済みの完全手順）

OS別の配置パス

macOSでの配置手順

# 1. ディレクトリを作成（要管理者権限）
sudo mkdir -p "/Library/Application Support/ClaudeCode"

# 2. ポリシーファイルを配置
sudo cp managed-settings.json "/Library/Application Support/ClaudeCode/"

# 3. 配置を確認
cat "/Library/Application Support/ClaudeCode/managed-settings.json"

配置後、実行中のClaude Codeセッションには反映されません。新しいセッションを起動してください。反映確認は新セッションで/permissionsを実行すると、ルールと「どの設定ファイル由来か」が一覧表示されます。

実例①：確認なし全自動実行モード（bypassPermissions）を組織で禁止する

Claude CodeのbypassPermissionsモード（--dangerously-skip-permissionsフラグ）は、すべての確認プロンプトをスキップしてAIが自律実行するモードです。隔離されたコンテナ等では有用ですが、開発者の手元のマシンで使われると、誤操作やプロンプトインジェクションの被害が一気に大きくなります。

これを組織全体で禁止する設定が次の1行です。キーの位置に注意してください——トップレベルではなくpermissionsの中に書きます（これも検証失敗の典型原因です）。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

実機検証：本当にbypassが無効化されるのか

このポリシーを配置した状態で、--dangerously-skip-permissions付きのClaude Codeにファイル作成を指示したところ、許可された作業ディレクトリ内への書き込みすらブロックされました。

# ポリシーあり ＋ --dangerously-skip-permissions での実行結果
touch in '（作業ディレクトリ）/bypass-check-1' was blocked.
For security, Claude Code may only create or modify files in the
allowed working directories for this session: ...
→ ファイルは作成されない（bypassが実質無効化されている）

対照実験として、disableBypassPermissionsModeだけを外した同じポリシーに差し替えて同じコマンドを実行すると、今度はファイルが正常に作成されました。ブロックがこの設定の効果であることが確定しています。

あわせて、AIが安全性を自動判断して承認を省略する自動承認（Auto Mode）を禁止したい場合は、同じ場所に"disableAutoMode": "disable"を追加します。

実例②：コマンド規制ルールの設計

評価順序の基本：deny → ask → allow

権限ルールはdeny → ask → allowの順で評価され、最初にマッチしたルールで結果が決まります。denyが常に最優先なので、「原則許可しつつ危険なものだけ塞ぐ」設計が素直に書けます。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(.env*)",
      "Read(//**/.ssh/**)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ]
  },
  "allowManagedPermissionRulesOnly": true
}

最後のallowManagedPermissionRulesOnly: trueがポイントで、これを有効にするとユーザー・プロジェクト側のallow/ask/denyルールが一切無視され、マネージド設定のルールだけが適用されます。ユーザーが自分のsettings.jsonに広いallowを書いても効きません。

パターンの書き方で知っておくべきこと

• スペースの有無で意味が変わる：Bash(ls *)はls -laにマッチしますがlsofにはマッチしません。Bash(ls*)は両方にマッチします
• 複合コマンドは分解して評価：safe-cmd && rm -rf /のような連結では、各サブコマンドが独立にルール評価されます
• ラッパーは剥がされる：timeout 30 npm testはBash(npm test *)にマッチします（timeout・nice・nohup等は自動で除去して照合）
• 引数の規制は脆い：Bash(curl http://github.com/ *)のようにURLを縛る書き方は、オプションの位置や変数展開で簡単にすり抜けられます。ネットワーク規制は「curlごとdeny＋WebFetchのドメイン許可」の組み合わせが堅実です
• ファイルパスはgitignore形式：絶対パスは//始まり（Read(//Users/alice/secrets/**)）、ホームは~/、/pathはプロジェクトルート相対です

実例③：そのほかの企業向けロック設定

マネージド設定でのみ効く（ユーザー設定に書いても無効な）代表的なキーです。

Hooksを使った検査の自動化（編集後のチェック等）についてはClaude Code Hooksの自動化10選も参考にしてください。

動作検証の手順（コピペで再現可能）と「効いていないように見える」3つの罠

ポリシーを配るなら、配布前に必ず実機検証をおすすめします。以下は私たちが実際に使った、無害なテスト用ポリシーでの検証キットです。

手順1：テスト用ポリシーを配置

{
  "permissions": {
    "deny": [
      "Bash(touch /tmp/managed-policy-test*)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

denyルールの対象が「/tmp/managed-policy-testで始まるファイルのtouch」だけなので、誤って業務に影響することがありません。

手順2：denyルールの検証（対照実験つき）

# 新しいターミナルで、非対話モードのClaude Codeに2つのコマンドを依頼
claude -p "次の2つを実行して結果を報告して: \
(1) touch /tmp/managed-policy-test1 (2) touch /tmp/control-test1" \
  --allowedTools "Bash"

# 期待結果：
#   (1) → Permission denied（ポリシーで拒否）
#   (2) → 成功（対照コマンド）
# ファイルの有無でも確認：
ls /tmp/managed-policy-test1   # → ない＝拒否された
ls /tmp/control-test1          # → ある＝Bash自体は動いている

ポイントは「禁止したコマンド」と「ほぼ同じだが禁止していないコマンド」をペアで実行させることです。両方失敗したら原因は別にあり、片方だけ失敗したらポリシーが効いています。

手順3：bypass抑制の検証

# 書き込みを伴うコマンドをbypassフラグ付きで依頼
claude -p "touch ./bypass-check-1 を実行して" --dangerously-skip-permissions

# 期待結果：ブロックされ、./bypass-check-1 が作成されない

罠①：read-onlyコマンドでテストしてしまう（最重要）

Claude Codeはecho・ls・cat・pwdなどを「read-onlyコマンド」として、どのモードでも確認なしに実行します。つまりechoでbypass抑制をテストすると、抑制が効いていても普通に実行されるため、「ポリシーが効いていない」と誤判定します。私たちも検証中に一度この罠にはまりました。検証には必ずtouchなどの書き込み系コマンドを使ってください。

罠②：ブロック時のメッセージが紛らわしい

bypass抑制が効いたときのエラーは「bypassモードは組織により無効化されています」ではなく、「作業ディレクトリ外への書き込みはブロックされました」という趣旨のメッセージで表示されることがあります（許可ディレクトリ内への書き込みでも出ます）。メッセージの文面だけ見ると別の原因に見えるので、対照実験とセットで判断してください。

罠③：再起動忘れ・配置場所ミス・キー位置ミス

• 設定は新しいセッションから有効。起動中のセッションには反映されない
• macOSは~/Libraryではなく/Library（sudo必須）
• disableBypassPermissionsModeはpermissionsの中。トップレベルに書くと無視される

配布方法：MDM・スクリプト・サーバー管理設定

• 小規模チーム：配置スクリプト（sudo mkdir＋cp）を配って各自実行、または構成管理ツール（Ansible等）で配布
• macOSの台数が多い組織：Jamf等のMDMで/Library/Application Support/ClaudeCode/にファイルを配布。MDM／OSレベルポリシー（plist・レジストリ）としての配布にも対応しています
• Enterpriseプラン：Anthropicの管理コンソールから配布する「サーバー管理設定」が利用できます。ファイル配布と違って端末上で削除できず、forceRemoteSettingsRefreshで「設定が取得できなければ起動させない」フェイルクローズ運用も可能です

よくある質問（FAQ）

Q. ユーザーがCLIフラグ（–allowedTools等）で突破できませんか？

できません。マネージド設定はCLI引数より優先度が上です。実機検証でも、マネージドのdenyルールは--allowedTools "Bash"を指定した状態でも有効でした。

Q. bypassPermissionsモード中でもdenyルールは効きますか？

効きます。検証では、bypassフラグ付きのセッションでも、マネージド設定のdenyルールに該当するコマンドは「Permission denied」で拒否されました。denyルールとbypass抑制は二重の防御線として機能します。

Q. 個人でも使う意味はありますか？

あります。disableBypassPermissionsModeは「自分が誤ってbypassモードを使うこと」を防ぐ自己拘束としても有効です（どのスコープの設定ファイルでも機能します）。うっかり--dangerously-skip-permissionsで走らせて事故るのを構造的に防げます。

Q. 設定ミスがあるとClaude Codeが起動しなくなりますか？

なりません。不正なエントリはログに記録されたうえでスキップされ、有効な設定だけが適用されます。ただし「エラーにならない＝気づきにくい」ということでもあるので、配布前の実機検証（上記の検証キット）を強くおすすめします。

まとめ：ポリシーは「書く」より「検証する」が9割

managed-settings.jsonによる企業ポリシー配布の要点を整理します。

• 配置場所はmacOSなら/Library/Application Support/ClaudeCode/（~/Libraryではない）
• bypass禁止はpermissions.disableBypassPermissionsMode: "disable"（permissionsの中に書く）
• コマンド規制はdeny優先の評価順序を活かし、allowManagedPermissionRulesOnlyでユーザー側ルールを無効化
• 検証は「無害なdenyルール＋対照コマンド」のペアで。read-onlyコマンド（echo等）でのテストは誤判定のもと

AIエージェントに権限を委ねる時代の統制は、「使わせない」ではなく「安全に使わせる」が本筋です。まず無害なテストポリシーで検証の感覚をつかみ、そこから自組織のルールを段階的に固めていくことをおすすめします。

参考リンク

• Claude Code Docs: Configure permissions（公式）
• Claude Code Docs: Claude Code settings（公式）
• Claude Code Docs: サーバー管理設定（公式）

本記事の検証は2026年6月12日、Claude Code v2.1.170（macOS）で実施しました。設定キー・挙動はバージョンにより変わる可能性があります。