管理者が決める設定

前回は、Claude Codeを組織に入れるときに必ず聞かれる4つの論点の地図を示しました。今回はその1つ目、セキュリティとコンプライアンスの入り口にあたる部分です。設定をどう配り、何を強制できるかを扱います。

新しく入れたツールが、社員一人ひとりの判断に委ねられたままでは、情報システム部門は落ち着きません。ある人は危険なコマンドを確認なしで実行する設定のままにし、別の人は勝手なMCPサーバーをつなぐ。Claude Codeには、こうした個人の判断に任せず、組織側で決めて配布し、下のどのスコープからも上書きさせない設定の仕組みがあります。マネージド設定と呼ばれるものです。

このレッスンでは、設定の階層のどこにマネージド設定が座るか、実際に配る4つの方法、強制できる主な項目、そして全社に広げる前に試す手順を順番に見ていきます。

ㅤ

設定には階層があり、マネージド設定が一番上に立つ

Claude Codeの設定は、自分のマシン全体に効くuser設定、リポジトリで共有するshared project設定、自分だけのproject local設定、そして組織が配るmanaged設定の4スコープから読み込まれます。同じキーが複数のファイルにあれば、優先順位が高い順に、managed設定 > コマンドライン引数 > project local > shared project > userの順で採用されます。

個人・チームの設定とマネージド設定

個人・チームの設定

user・shared project・project localの3スコープ。値は上書きも結合もされる。誰かが書き換えれば、そのぶん挙動が変わる

マネージド設定

組織が配布する別枠の設定。ごく一部の安全側キーを除き、下のどのスコープからも上書きできない

この「上書きできない」という一点が、マネージド設定を個人設定と分ける境界線です。 優先順位の詳しい仕組み(配列キーが結合される話や、逆に現場の厳しい値が勝つ9個の例外キーなど)は、用語辞典のsettings.jsonにまとめてあります。ここから先は、組織側が実際にどう配り、何を強制できるかに絞って見ていきます。

ㅤ

配り方は4系統、優先順位がある

マネージド設定は、1つの仕組みではありません。優先順位が異なる4つの経路があり、同じ端末に複数の経路が届いた場合は、既定では優先順位が最も高い経路だけが採用されます。

① サーバー管理設定

claude.aiの管理画面(Admin Settings > Claude Code > Managed settings)からJSONを設定する。Owner・Primary Ownerだけが編集でき、Team・Enterpriseプランが必須。MDMは不要で、起動時とセッション中1時間ごとに対象の端末へ届く

② MDM・OSレベルポリシー

macOSは管理プリファレンスドメイン、Windowsはレジストリのポリシーキーへ配布する。JamfやIntune、Group Policyといった端末管理ツールで全社に届けられる

③ ファイル配置型(managed-settings.json)

OSごとに決まったシステムディレクトリへ、直接JSONファイルを置く方式。端末を絞って動作を確かめるのに向く

④ Windowsユーザーレジストリ

ユーザー単位のレジストリ値。4系統の中では最も優先順位が低い

配り方の4系統(優先順位が高い順)

③のファイル配置型は、OSごとにパスが決まっています。macOSは/Library/Application Support/ClaudeCode/managed-settings.json、Linux・WSLは/etc/claude-code/managed-settings.json、WindowsはC:\Program Files\ClaudeCode\managed-settings.jsonです。古いWindowsパスであるC:\ProgramData\ClaudeCode\managed-settings.jsonは読まれなくなっているので、以前の手順書をそのまま使い回さないでください。

注意

配るだけでは「境界」にならない

公式ドキュメントは、この仕組みの限界をはっきり書いています。

Server-managed settings provide centralized policy enforcement, but they operate as a client-side control, not a security boundary. On unmanaged devices, a user doesn't need admin or sudo access to bypass them. (サーバー管理設定は一元的なポリシー適用を提供するが、あくまでクライアント側の制御であり、セキュリティ境界ではない。管理されていない端末では、管理者権限がなくてもこれを回避できる)

改造したバイナリを動かせば、クライアント側の制御は素通りします。「絶対に破られたくない」制約は、設定の配布だけに頼らず、MDM配下の端末管理と組み合わせてください。

ㅤ

強制できる主な項目

配り方が決まったら、次は中身です。マネージド設定でしか使えない専用キーも含め、公式ドキュメントは強制できる項目を次のように整理しています。

権限ルール

permissions.allowとpermissions.denyで、確認なしで実行してよいコマンドと、拒否するコマンドを配布する

バイパスモードの無効化

permissions.disableBypassPermissionsModeで、--dangerously-skip-permissionsフラグそのものを拒否させる。値は文字列disableのみ

管理者のルールだけ使わせる

allowManagedPermissionRulesOnlyをtrueにすると、許可ルールの情報源がマネージド設定だけになる。他スコープのallow・ask・denyや--allowedToolsは無視され、常に許可の選択肢も画面から消える

フックの制限

allowManagedHooksOnlyをtrueにすると、組織が配ったフック以外(個人・プロジェクト・他プラグインのフック)はすべてブロックされる

MCPの許可・拒否

allowedMcpServersとdeniedMcpServersで個別に許可・拒否し、allowManagedMcpServersOnlyでマネージド設定のアローリストだけに限定する

サンドボックス

sandbox.enabledでBashサンドボックスを有効化し、sandbox.network.allowManagedDomainsOnlyでネットワークの許可ドメインをマネージド設定だけに固定する

モデル

availableModelsで選べるモデルを絞り、maxEffortLevelでエフォートレベルの上限を設定する

バージョン

minimumVersionで自動更新の下限を、requiredMinimumVersionとrequiredMaximumVersionで起動できるバージョンの範囲そのものを固定する

強制できる主な項目

このうちallowManagedPermissionRulesOnlyとallowManagedHooksOnlyは、特に強力です。個人やチームが自分の設定ファイルに何を書いても、その内容ごと無視させられます。「まず全部止めてから、必要な分だけ許可リストに足す」というホワイトリスト運用に切り替えたいときに使う項目です。

ㅤ

最小の設定例

実際にどう書くかを、公式が示すサンドボックス強制の例で見てみます。組織全体でBashサンドボックスを有効にし、サンドボックスが使えない環境では警告で流さずに起動そのものを止める、という最小限のmanaged-settings.jsonです。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

出典: Claude Code公式ドキュメント「サンドボックス」(Configure the sandbox for your organization)

enabledでサンドボックスそのものを有効化し、failIfUnavailableでOS側の依存関係が欠けている環境では動かさずにエラーで止め、allowUnsandboxedCommandsをfalseにすると、サンドボックス内で失敗したコマンドをサンドボックス外で再試行する「エスケープハッチ」自体を無効化します。このJSONを、前のセクションで見た4つの配り方のどれかで届ければ、そのまま組織の強制設定になります。

ㅤ