Claude Code の管理設定（managed settings）とは何か

**Claude Code 管理設定（managed settings）**とは、組織の管理者が全端末に配る設定で、設定の段階（スコープ）の中で最も強い層です。
個人設定（~/.claude/settings.json）やプロジェクト設定（.claude/settings.json）では上書きできません（出典: Settings files and precedence 2026-10-23確認）。

ここまでは公式ドキュメントの冒頭に書いてあります。
法人のセットアップで私がつまずいたのは、そのあとでした。
最上位に置いたはずの設定が、端末によっては効いていない。
サーバー管理設定とMDMのplistを併用した端末で、/status に表示される設定の出どころがサーバー管理設定だけになり、plist で配ったキーは無視されていました。

管理設定は「全員に配って、個人には外させない設定」

配れるのは、権限のルール、外部連携（MCP）の許可リスト、ログイン方式の指定、サンドボックス（作業できる範囲を区切る仕組み）の範囲などです。
どれも、開発者が自分の設定ファイルを書き換えても外せない形で届きます。
逆に言えば、開発者が自由に調整していい項目をここに入れると、現場から「動かない」という問い合わせが来ます。

必要なプランと、編集できる人

Claude Code は有料プランすべてに含まれます（出典: Claude pricing 2026-10-23確認）。
ただし管理コンソールから配るタイプは別で、サーバー管理設定は Team か Enterprise プランが必要です。
編集できるのは管理コンソールの最上位権限（Primary Owner）とその次の権限（Owner）だけです（出典: Configure server-managed settings）。

導入全体の段取りは法人導入のチェックリストにまとめました。

管理設定はどこまで強制できるのか

優先順位は5段階

高い順に、管理設定、コマンドライン（起動してから終えるまでの1回（セッション）だけ効く --settings）、プロジェクトローカル、プロジェクト共有、ユーザーです（出典: Settings files and precedence）。

下位のより厳しい値が勝つ例外が11キーある

公式に「Exceptions to managed settings precedence」という表があり、対象はちょうど11キーです。
この11キーでは下位スコープのより厳しい値が勝ちます。
たとえば remoteControlAtStartup（別の端末から操作を引き継ぐ機能の起動時自動接続）では、プロジェクト設定かローカル設定に書いた false だけが管理設定の true より優先されます。
disableClaudeAiConnectors（Claude の外部連携を止める設定）と permissions.blockReadsOutsideWorkingDirectories（作業フォルダの外側の読み取りを止める設定）がここに入ります。
全11件は公式の表（settings#exceptions）で確認してください。

permissions の allow と deny はマージされる

permissions の allow と deny は、全スコープが合算されます。
公式の組織導入ページには「developers can extend managed lists but not remove from them」とあり、開発者はリストに追加できるが削除はできないと書かれています（出典: Set up Claude Code for your organization）。
管理設定のルールだけを有効にしたい場合は allowManagedPermissionRulesOnly を true にします。

権限ルールの評価順は deny（禁止）、ask（都度確認）、allow（許可）で、最初に一致したものが結果を決めます（出典: Configure permissions）。
allowManagedPermissionRulesOnly を使わない場合、管理設定の allow がプロジェクトの ask を上回ることはありません。

配り方は4つ。どの経路を選ぶか

サーバー管理設定（管理コンソールから配る）

4経路の優先度は、サーバー管理設定が最高、plist（macOSの設定ファイル）とレジストリ（Windowsが設定を保存する領域）のポリシーが高、ファイル配置が中、Windows の HKCU が最低です（出典: Set up Claude Code for your organization）。
サーバー管理設定は起動時に取得し、セッション中は1時間ごとに設定を取り直します。
api.anthropic.com への到達が必要で、ブラウザ上で動かすクラウドセッションにも届くのはこの経路だけです。

macOS のパスはシステム領域の /Library です。
利用者の ~/Library ではないので、ここを間違えると静かに読まれません。

MDM と、ファイル配置

MDMのテンプレートは公式リポジトリの examples/mdm に実物があります。

HKCU は管理者権限の昇格なしで書き込めるため、公式は「enforcement channel ではなく便宜上の既定値として扱え」、つまり強制の経路ではなく便宜上の初期値として扱えとしています。
WSL は既定で Linux のパスだけを読みます。
Windows 側のポリシーを継承させるなら wslInheritsWindowsSettings を true にします。

既定では管理設定どうしがマージされない

ここが、私が最初に効かないと思った原因でした。
管理設定の層は、既定では優先度の高い順に見て、設定が1つでも入っている最初の配布元だけを使い、残りの配布元は読みません（サーバー管理設定→端末側の順）。
managedSourcesBehavior を "merge" にすると、すべての配布元の設定を適用する動作に変わります。
サーバー管理設定を入れた途端に、MDM側で配っていた内容が無視されることがあります。

最初に入れる設定の例（4つから始める）

個人アカウントでの業務利用を止める

forceLoginMethod の値は claudeai（claude.ai のログイン画面）、console（Anthropic Console のログイン画面）、gateway（自社で立てるサインインの中継のログイン画面）の3つで、forceLoginOrgUUID（配列）と併用します（出典: Authentication）。

ただし穴が3つあります。
ターミナルの対話ログイン画面では方式を事前選択するだけで、強制はしません。
サーバー管理設定は「すでに自組織に認証済みのアカウント」にしか届かないため初回ログインを誘導できず、公式は同じキーを両方の配布元に書くよう指示しています。
自社で立てるサインインの中継（gateway）からのサインインに forceLoginOrgUUID は適用されません。

ネットワーク層で補うなら Tenant Restrictions があります。
Enterprise プランと、Anthropic Console で作った組織（Console 組織）のみが対象で、社内の通信を中継するプロキシが anthropic-allowed-org-ids というヘッダを付け加え、通信を復号して中身を検査する仕組み（TLSインスペクション）が必須です（出典: Enforce network-level access control with Tenant Restrictions）。

forceLoginMethod か forceLoginOrgUUID を設定すると、APIキーで認証する方法（環境変数の ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN、設定の apiKeyHelper）を使うセッションは起動時にブロックされます。
私の現場でもっとも多い事故は、ログインでAPIキー方式を選んでしまい、プランの月額（1人あたりの席の料金）とは別に、そのセッション分が API 料金で請求されることです。

.env などの読み取りを禁止する

公式サンプルの permissions.deny は3行だけです。
Bash(curl *)、Read(./.env)、Read(./secrets/**)。
あわせて、権限の確認を飛ばして実行するモードを使えなくする permissions.disableBypassPermissionsMode には、値として true/false ではなく文字列の disable を入れます（出典: Example settings files）。

外部連携（MCP）を許可したものだけにする

MCPは allowedMcpServers と allowManagedMcpServersOnly: true を組み合わせます。
許可リストの各項目は serverUrl・serverCommand・serverName のどれか1つを持つオブジェクトで書きます（出典: Control MCP server access for your organization）。
managed-mcp.json（外部連携のサーバーを定義するファイル）はサーバー管理設定では配れません。
サーバー管理設定でリモートのサーバーを配るときは、代わりに managedMcpServers キーを使います（v2.1.259 以降）。

外部連携は便利な反面、もっとも攻撃を受けやすい入口になります。
数を絞り、つないだものは実際に1回操作が成功するところまで確かめる。
これを引き渡し前の確認項目に入れています。

deny だけでは止まらない。サンドボックスとの二層にする

Read(./.env) と Bash(curl *) が止めないもの

Read(./.env) は Claude がファイルを読む機能と、cat .env のようにファイル名を指定するコマンドは止めますが、ディレクトリ全体への grep -r は止めません（出典: Example settings files）。
この穴は sandbox.filesystem.denyRead が埋めます。
Read の deny パスを、サンドボックス下の全コマンドに効かせるキーです。

Bash(curl *) も同じ性質です。
Claude が書いた通りの curl にはマッチしますが、/usr/bin/curl や sh -c の中の curl にはマッチしません。
Claude がウェブページを読む機能（WebFetch）を deny しても、コマンドを実行する機能（Bash）が許可されていれば curl や wget は任意のURLに到達できます（出典: Set up Claude Code for your organization）。

接続先はサンドボックス側で絞る

接続先は sandbox.network.allowedDomains と sandbox.network.allowManagedDomainsOnly で絞ります。
公式例では sandbox ブロックの中に enabled と allowUnsandboxedCommands（false）が入っています（出典: Example settings files）。
allowUnsandboxedCommands は、サンドボックスの外でコマンドを動かすことを許すかどうかの設定です。

前提として外せない制約が1つあります。
サンドボックスが動くのは macOS、Linux、WSL2 で、WSL を使わず Windows 上で直接動かす場合は、サンドボックスなしでコマンドが動きます（出典: Configure the sandboxed Bash tool）。
Windows 中心の会社は、WSL2 を前提にするか、別の制御を足すことになります。

配った設定が効いているかを確かめる

まず1台で /status を見る

公式のMDMテンプレートのREADMEは、全台に広げる前に1台で試すよう指示しています。
確認するのは /status の Setting sources（設定の出どころ）の行です。
ここに「Enterprise managed settings (plist)」や「(HKLM)」が出るのを確かめてから展開します（出典: examples/mdm）。
ファイル配置なら (file) と出ます（出典: Deploy managed settings）。
サーバー管理設定が届いたかは、ターミナルで claude doctor（端末の状態を調べるコマンド）を打ち、Managed settings (remote) の行を見ます。
この行は v2.1.248 以降で出ます。
権限は Claude Code の中で /permissions、外部連携はターミナルで claude mcp list と打って確認します。

キーごとの最小バージョンを満たしているか

配るキーの版の条件を満たさない端末では、設定は効きません。

配るキーが必要とする版を requiredMinimumVersion に書いておきます。
この版より古い端末では、Claude Code が起動しません。
設定ファイルは厳格JSONで、// のコメントも末尾のカンマも構文エラーになります。
$schema には https://json.schemastore.org/claude-code-settings.json を指定できます。
ただし公式は、設定の書き方を検査する定義（スキーマ）が、コマンドで動かす本体（CLI）の最新版に追いつかないことがあると明記しています。

「できたつもり」を残さない完了判定

私の完了判定は3点です。
つないだツールで実際に1つ操作が成功すること、お客様の主目的の業務を1つ最後まで実行できること、お客様が自分の手で1回再現できること。
キックオフから設定を終えるまでは2〜4週間が目安です。

効かないときに疑う順番

環境変数で取得がスキップされていないか

CLAUDE_CODE_USE_BEDROCK のように端末ごとに持たせる設定値（環境変数）や、既定以外の ANTHROPIC_BASE_URL をターミナルの設定ファイルに書いて有効にする（export）と、サーバー管理設定の取得そのものがスキップされます（出典: Configure server-managed settings）。
配布側を疑う前に、端末のターミナルの設定ファイルを見たほうが早いことがあります。

forceRemoteSettingsRefresh を true にすると取得失敗時に起動を止める動作になります。
api.anthropic.com に到達できない環境では誰も Claude Code を使えないので、入れる前にネットワークポリシーを確認してください。

届かない相手が3つある

初回ログインにはサーバー管理設定が届きません。
端末側の管理設定はクラウドセッションに届きません。
WSL は既定で Linux のパスだけを読みます。
この3つは設定の書き方では直らないので、配布経路で手当てします。

配布元の取り違えとバージョン

管理設定の層は既定でマージしないため、サーバー管理設定を入れたあともMDM側に同じキーを残します。
公式は forceLoginMethod と forceLoginOrgUUID を両方の配布元に書くよう指示しています。

そしてバージョンです。
2026年10月だけで管理設定まわりの変更が複数ありました（2026-10-14 の v2.1.299、2026-10-20 の v2.1.305 など）。
2026-10-23時点で、公式の変更履歴（changelog）の先頭は 2026-10-22 の v2.1.309 です（出典: Claude Code changelog）。
半年前の記事に載っている設定を、そのまま配るわけにはいきません。

完成した managed-settings.json の実例

最小構成（まずこれだけ配る）

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["00000000-0000-0000-0000-000000000000"],
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowedMcpServers": [{ "serverUrl": "https://mcp.example.com/*" }, { "serverUrl": "https://*.internal.example.com/*" }],
  "allowManagedMcpServersOnly": true
}

サンドボックスまで入れた構成

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["00000000-0000-0000-0000-000000000000"],
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.example.com/*" }, { "serverUrl": "https://*.internal.example.com/*" }],
  "allowManagedMcpServersOnly": true,
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./.env", "./secrets/**"]
    },
    "network": {
      "allowedDomains": ["api.anthropic.com"],
      "allowManagedDomainsOnly": true
    }
  }
}

これは推奨の基準ではありません。
組織のUUID（組織ごとに割り当てられた識別子）は自社の値に書き換えてください。
requiredMinimumVersion は、本文の表に版の条件があるキーを配るときだけ書き足します。
allowManagedPermissionRulesOnly: true を入れると、プロジェクトや個人が足した権限ルールは効きません。
現場のルールを残すなら外します。
この例の allowedDomains と allowedMcpServers に無い接続先と外部連携は、使えなくなります。
業務で使うものを先に書き足してください。
各キーの階層と値の書式は、全設定キー一覧で最終確認をお願いします。

よくあるご質問

今日やること3つと、配ったあとに残る仕事

今日やること3つ

優先順位は5段階で管理設定が最上位ですが、例外が11キーあり、allow（許可）と deny（禁止）は合算されます。
配り方は4経路で、既定ではマージされません。

今日やることは3つです。
自社の配布経路を決める。
ログイン制限、読み取り禁止、MCPの許可リストを1台で試す。
配るキーに版の条件がある場合だけ、その版を requiredMinimumVersion に書く。

管理設定だけでは使われる状態にならない

統制と生産性は二者択一ではありません。
社内の指示書（CLAUDE.md）とよく使う作業の手順（スキル）で前提を書き残し、そのうえで管理者の設定とサンドボックスで触れる範囲を区切ります。

Re-rail は Claude Code と Codex の法人セットアップで、約50社・20業界に導入しました（2026年7月時点）。
アカウントを配って終わりにせず、会社の業務で使い続けられる状態をつくるところまでを導入と呼んでいます。
配布と動作確認を含むセットアップの進め方は、Claude Code / Codex 法人セットアップにまとめました。