【Claude Code 連載第48回】サーバー管理設定 — MDM なしで組織全体に設定を配る

よっしー

こんにちは。よっしーです(^^)

背景
1. 一言でいうと何か
2. どういう場面で役立つか
3. 前提条件と、設定の実例
4. まとめ＋次回予告

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

サーバー管理設定は、claude.ai の管理コンソールに JSON を1つ書いておくと、組織の全員の Claude Code がそれを自動で取ってくる仕組みです。

従来、組織全体に Claude Code の設定を強制するには、MDM（デバイス管理）で macOS の管理設定プロファイルを配る、Windows レジストリにポリシーを書く、各マシンに managed-settings.json を置く——といったエンドポイント側の作業が必要でした。サーバー管理設定はこれを置き換えます。Admin Settings > Claude Code > Managed settings に構成を保存すれば、ユーザーが組織の OAuth ログインまたは直接構成された API キーで認証した時点で、クライアントが設定を取得します。

想定されている読者は明確です。デバイス管理インフラを持っていない組織、あるいは管理されていないデバイス上のユーザーの設定を管理する必要がある組織。BYOD が混在している、業務委託メンバーがいる、MDM 導入まで手が回っていない——そういう状況で、とりあえず組織ポリシーを効かせたいときの選択肢です。

ただし、この記事でいちばん重要な一文を先に置きます。**サーバー管理設定はクライアント側の制御であって、セキュリティ境界ではありません。**公式ドキュメントがそう明言しています。管理されていないデバイスでは、ユーザーは管理者権限も sudo も持たずにこれをバイパスできます。「配れる」ことと「破られない」ことは別問題です。

もうひとつ、逆方向の重要事実。**エンドポイント管理設定はクラウドセッションに届きません。**したがって、MDM を持っている組織であっても、ウェブ上で Claude Code を使うならサーバー管理設定も併せて構成する必要があります。「MDM があるからこっちは不要」とはならない。

利用条件は Claude for Teams または Claude for Enterprise です。

2. どういう場面で役立つか

シーン1：MDM を持たない組織が、まず最低限のガードレールを引く

秘密ファイルの読み取り禁止、外部への curl 禁止、権限バイパスモードの禁止——このあたりを組織全員に効かせたいが、そのために MDM を導入するのは重い。管理コンソールに JSON を貼るだけで済むなら、導入コストはほぼゼロです。効果の確実性は MDM に劣りますが、何もない状態よりは圧倒的に良いという判断が成り立つ場面は多いでしょう。

シーン2：ウェブ／クラウドセッションにポリシーを届ける

前述のとおり、エンドポイント管理設定はクラウドセッションに到達しません。ウェブ版 Claude Code を組織で使っているなら、サーバー管理設定は代替ではなく必須の追加です。MDM 完備の組織でも、この理由でサーバー管理設定を構成することになります。

シーン3：オートモードの信頼インフラを全社に配る

前回（第47回）扱った autoMode.environment は、まさに「全開発者に同じ内容を配りたい」設定です。各自が ~/.claude/settings.json に自社の GitHub 組織や S3 バケットを書くのは無駄が多い。管理設定から配れば一度で済みます。

シーン4：全員に監査フックをかける

ファイル編集のたびに監査スクリプトを走らせる、といったフック構成も配布できます。ただしフックはシェルコマンドを実行するため、適用前にユーザー側でセキュリティ承認ダイアログが出ます（後述）。黙って全員のマシンでスクリプトが走り始めるわけではありません。

不要・向かないケース

強い強制力が必要なとき。MDM に登録済みのデバイスなら、エンドポイント管理設定のほうが強い保証を提供します。設定ファイルを OS レベルでユーザーの変更から保護できるからです。規制業界や機微データを扱う環境では、こちらを選ぶべきです。
グループごとに設定を分けたいとき。**設定は組織内の全ユーザーに均一に適用されます。**グループ別構成は未サポートです。部署ごとに違うポリシーを、という要件には現時点で応えられません。
サードパーティのモデルプロバイダーを使っているとき。Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、Claude Platform on AWS、ANTHROPIC_BASE_URL や LLM ゲートウェイ経由のカスタムエンドポイント——これらではサーバー管理設定は利用できません。この場合は自己ホスト型の Claude apps ゲートウェイが同等の配信を提供します。
OS レベルのポリシーソースに限定された設定を配りたいとき。policyHelper や wslInheritsWindowsSettings は尊重されません。MDM かシステムの managed-settings.json 経由でデプロイしてください。
managed-mcp.json を配りたいとき。これは配布できません。代わりに allowedMcpServers / deniedMcpServers のポリシーキーを配信します。
Owner ロールを持っていないとき。Admin ロールでも閲覧・編集できません（後述）。

サーバー管理とエンドポイント管理の選び分け

アプローチ	最適な用途	セキュリティモデル
サーバー管理設定	MDM がない組織、または管理されていないデバイス上のユーザー	認証時に Anthropic のサーバーから配信される設定
エンドポイント管理設定	MDM またはエンドポイント管理がある組織	MDM 構成プロファイル、レジストリポリシー、または管理設定ファイルを通じてデバイスに配置される設定

判断軸は単純です。デバイスを管理できているならエンドポイント管理、できていないならサーバー管理。ウェブを使うなら、どちらの組織もサーバー管理を追加。

3. 前提条件と、設定の実例

要件

Claude for Teams または Claude for Enterprise プラン
Claude 組織の Owner または Primary Owner ロール（設定の表示・編集に必要）
api.anthropic.com へのネットワークアクセス

2番目は運用上よく詰まる点です。**Admin ロールその他の Owner 以外のロールでは、管理設定を表示も編集もできません。**管理コンソールのリンクを開いたのに Claude Code ページではなく別の Admin Settings ページにリダイレクトされたら、それはロール不足のサインです。組織内の Owner か Primary Owner に依頼してください。

設定変更は組織内の全ユーザーに適用されるため、このアクセスは信頼できる担当者に限定すべきです。

バージョン要件

機能	必要バージョン
`claude auth` サブコマンドが fail-closed チェックから除外	v2.1.139 以降
配信ペイロードの無効エントリの寛容なパース（該当エントリだけ削除して残りを適用）	v2.1.169 以降
`forceRemoteSettingsRefresh` が優先順位ルールの例外になる	v2.1.191 以降
キャッシュされた `env` のトランスポート／ルーティング／認証変数を保留	v2.1.198 以降
非対話実行が設定を承認済みとして保存しなくなる	v2.1.207 以降

設定を書く

管理コンソールで Admin Settings > Claude Code > Managed settings を開き、JSON を追加します。settings.json で使えるすべての設定がサポートされます（OS レベルのポリシー配信に限定されているものを除く）。hooks、環境変数、allowManagedPermissionRulesOnly のような管理専用設定も含まれます。

権限拒否リストを適用し、バイパスを防ぎ、権限ルールを管理設定で定義されたものに制限する例：

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

hooks は settings.json と同じ形式です。全ファイル編集後に監査スクリプトを走らせる例：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "/usr/local/bin/audit-edit.sh" }
        ]
      }
    ]
  }
}

オートモードの分類器に、組織が信頼するリポジトリ・バケット・ドメインを教える例：

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com"
    ]
  }
}

autoMode の各フィールド（特に "$defaults" を省くとデフォルトが丸ごと消える件）については前回の記事を参照してください。ここでは「管理設定から配れる」という点だけ押さえれば十分です。

保存すると、クライアントは次回起動時、または1時間ごとのポーリングサイクルで更新を受け取ります。

管理専用設定という区分

ほとんどの設定キーは任意のスコープで機能しますが、いくつかのキーは管理設定からのみ読み込まれ、ユーザー設定やプロジェクト設定に置いても効果がありません。完全なリストは公式の「管理専用設定」を参照してください。逆に、そのリストにない設定は管理設定に置くことができ、その場合最高の優先度を持ちます。

配信されたことを確認する

3つの確認手段があります。

ユーザーに Claude Code を再起動してもらう。セキュリティ承認ダイアログをトリガーする設定が含まれていれば、起動時に管理設定を説明するプロンプトが出ます。
ユーザーに /permissions を実行してもらい、有効な権限ルールを見る。
/status を実行して、どの管理ソースがアクティブかを確認する。

配信の問題をデバッグするなら claude --debug-file <path> を実行してログから Remote settings を検索します。そして組織にロールアウトする前に、テストマシンで claude doctor を使ってペイロードの変更を検証してください。全員に一斉に壊れた設定が飛ぶ事故を防げます。

優先順位——「マージされない」が肝

ここは誤解しやすいので丁寧に整理します。

サーバー管理設定とエンドポイント管理設定は、設定階層の最上位を占めます。コマンドライン引数を含む他の設定レベルはこれらをオーバーライドできません。

管理層の内部では、こうなっています。

policyHelper が設定されていれば、他のすべての管理ソース（サーバー管理設定を含む）に優先する。その出力が唯一の管理構成になる。
それ以外の場合、Claude Code は空でない構成を配信する最初のソースを使う。サーバー管理設定が先にチェックされ、次にエンドポイント管理設定。
**ソースはマージされません。**サーバー管理設定がキーを配信すれば、他のエンドポイント管理設定は無視されます。サーバー管理設定が何も配信しなければ、エンドポイント管理設定が適用されます。

「サーバー管理で A を、MDM で B を配って両方効かせる」はできない、ということです。片方が勝ち、もう片方は丸ごと無視されます。

例外がひとつ。クロスソースロックキー（サンドボックスホワイトリストロックなど）の小さなセットは、管理者が管理する管理ソースが設定していれば尊重されます。ただしユーザーが書き込み可能な HKCU レジストリ層は除外されます。

もうひとつの落とし穴：管理コンソールでサーバー管理構成をクリアしても、キャッシュはクライアントに残ります。「エンドポイント管理の plist やレジストリポリシーにフォールバックさせるつもりでコンソールを空にした」場合、次の成功したフェッチまでキャッシュが効き続けます。/status で実際にどのソースがアクティブかを確認してください。

フェッチとキャッシュの挙動

Claude Code は起動時にフェッチし、アクティブなセッション中は1時間ごとにポーリングします。

キャッシュがない初回起動：非同期でフェッチする。フェッチが失敗したら管理設定なしで続行する。設定が読み込まれるまでの短い未適用ウィンドウがある。

キャッシュがある後続の起動：キャッシュが即座に適用される。バックグラウンドで新しい設定をフェッチする。キャッシュはネットワーク障害を越えて保持される。

ここに v2.1.198 で入った重要な強化があります。**キャッシュされた env ブロックのうち、3カテゴリの変数はサーバーがセッションのペイロードを確認するまで保留されます。**狙いは明確で、キャッシュされたプロキシ・CA・エンドポイント・認証情報の値が、設定フェッチそのものをリダイレクト・傍受・再認証してしまうのを防ぐためです。保留されるのは次の3つ。

プロキシと TLS 構成：HTTPS_PROXY、NODE_EXTRA_CA_CERTS、mTLS クライアント証明書変数 CLAUDE_CODE_CLIENT_CERT および CLAUDE_CODE_CLIENT_KEY など
API ルーティングとプロバイダー選択：ANTHROPIC_BASE_URL、CLAUDE_CODE_USE_BEDROCK、CLAUDE_CODE_USE_VERTEX、ANTHROPIC_BEDROCK_BASE_URL などのプロバイダーエンドポイント URL を含む
認証認証情報：ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、CLAUDE_CODE_OAUTH_TOKEN など

テレメトリや OpenTelemetry 構成など、それ以外のキーは従来どおり起動時に適用されます。フェッチが成功すれば、保留されていた変数もセッションの残り期間に適用されます。なおこの強化はサーバーがフェッチした設定キャッシュにのみ適用され、MDM や managed-settings.json 経由のエンドポイント管理設定は影響を受けません。

この仕様から導かれる実務上の注意：**api.anthropic.com に到達するのにプロキシが必要な組織は、プロキシ設定を管理 env ブロックだけに置いてはいけません。**シェル環境かユーザー設定で設定してください。初回起動にはキャッシュがないので、そもそもこれらのソースが初期フェッチに必要だったのです。

また、設定更新は自動的に適用されますが、OpenTelemetry 構成のような高度な設定は完全な再起動が必要です。

無効なエントリが混ざったとき

配信ペイロードは他の管理ソースと同じルールで寛容にパースされます。スキーマ検証に失敗するエントリがあれば、そのエントリだけを削除し、検証エラーを表示し、残りの有効な設定をすべて適用します（v2.1.169 以降）。

サーバー管理配信に固有の挙動が3つ。

キャッシュ（~/.claude/remote-settings.json）には、無効エントリを除去した「救済済み」ペイロードが保存されます。生の無効ペイロードは永続化されません。
救済できないフィールドがあった場合、最後に受け入れられたキャッシュ設定を保持し、致命的なエラーを記録します。
セキュリティ承認ダイアログは救済済みペイロードを評価するため、削除された無効エントリは承認対象として提示されず、実行もされません。

起動を fail-closed にする

デフォルトでは、起動時のフェッチが失敗すると管理設定なしで続行します。この未適用ウィンドウが許容できない環境では、次のキーを設定します。

{
  "forceRemoteSettingsRefresh": true
}

これがアクティブだと、CLI はリモート設定が新しくフェッチされるまで起動をブロックし、フェッチが失敗すればポリシーなしで続行せず終了します。この設定は自己永続化します——サーバーから配信されるとローカルにもキャッシュされるので、新しいセッションで最初の成功フェッチが起きる前でも、後続の起動に同じ動作が適用されます。

MDM プロファイルやシステムの managed-settings.json でこのキーを設定すれば、サーバーペイロードが配信される前の初回起動から fail-closed にできます。v2.1.191 以降、このフラグは前述の優先順位ルールの例外です。キャッシュされたサーバー管理ペイロードが存在していても、任意の管理ソースで設定されていれば尊重されるため、MDM 配信値が無視されることはありません。またフェッチは Cache-Control: no-cache ヘッダーを送るので、中間 HTTP プロキシが古い応答を返すこともありません。

**有効化する前に、ネットワークポリシーが api.anthropic.com への接続を許可していることを必ず確認してください。**到達できなければ CLI は起動時に終了し、ユーザーは Claude Code を開始できなくなります。救済措置として、v2.1.139 以降 claude auth login などの claude auth サブコマンドはこのチェックから除外されているので、期限切れの認証情報が原因なら再認証はできます。

セキュリティ承認ダイアログ

セキュリティリスクをもたらしうる設定は、適用前に明示的なユーザー承認を要求します。対象は4種類。

シェルコマンド設定：シェルコマンドを実行する設定
カスタム環境変数：既知の安全なホワイトリストにない変数
フック構成：任意のフック定義
管理 CLAUDE.md コンテンツ：管理設定を通じて配信される claudeMd 値

これらが含まれると、ユーザーには構成内容を説明するダイアログが出ます。承認しなければ続行できず、拒否すると Claude Code は終了します。

非対話実行（claude -p や Agent SDK セッション）ではダイアログを出せません。この場合、Claude Code はその実行のためだけに設定を適用し、ローカルキャッシュに承認済みとして記録も書き込みもしません。次の対話セッションではダイアログが出ます。つまりユーザーが対話セッションで承認するまで、非対話実行は毎回起動時に設定を再フェッチします。v2.1.207 より前は非対話実行が承認済みとして保存してしまっていたため、後続の対話セッションでダイアログが出ませんでした。挙動が変わっている点に注意してください。

プラットフォームの可用性

配信の条件は2つ。api.anthropic.com への直接接続と、組織 OAuth ログインまたは直接設定された API キーでの認証です。apiKeyHelper スクリプトが返したキーは設定フェッチをトリガーしません。

サードパーティプロバイダー（Bedrock、Agent Platform、Foundry、Claude Platform on AWS、カスタムエンドポイントや LLM ゲートウェイ）では利用できません。

ここに厄介な仕様があります。シェルで CLAUDE_CODE_USE_* プロバイダー変数やデフォルト以外の ANTHROPIC_BASE_URL をエクスポートすると、Claude Code はそのセッションの設定フェッチをスキップします。そしてエクスポートがフェッチを防いでいるので、サーバー管理 env ブロックでそのエクスポートをクリアすることはできません。エンドポイント管理設定の env ブロックでもフェッチは復元しません。適格性チェックが管理 env ブロックの適用より前に走るため、オーバーライドはプロバイダー選択を変えはしても、フェッチはスキップされたままです。

復旧手段は2つ：シェルからエクスポートを削除するか、ユーザー設定の env ブロックで変数を "" に設定する（これは適格性チェックより前に適用されます）。ただし、ユーザーがシェルを変更することに依存せずにポリシーを適用したいなら、エンドポイント管理チャネルで配信するべきです。

Bedrock / Agent Platform / Foundry のデプロイでは、自己ホスト型の Claude apps ゲートウェイが同等のリモート管理設定配信を提供します。ゲートウェイにサインインしたクライアントは api.anthropic.com ではなくゲートウェイから設定を取得します。起動時の失敗セマンティクスが異なる点に注意：ゲートウェイに到達できないクライアントは、キャッシュにフォールバックせずエラーで終了します。ただし1時間ごとのバックグラウンド更新は両チャネルとも fail-open です。

監査ログとバイパス経路

設定変更の監査ログイベントは、コンプライアンス API または監査ログエクスポートから利用できます（アクセスは Anthropic アカウントチームに問い合わせ）。イベントにはアクションの種類、実行したアカウントとデバイス、前の値と新しい値への参照が含まれます。

そして冒頭で述べた最重要事項に戻ります。**これはクライアント側の制御であり、セキュリティ境界ではありません。**公式は具体的なバイパスシナリオを表で列挙しています。代表的なものを挙げると——

キャッシュ設定ファイルを編集する：改ざんされたファイルは起動時に適用されるが、次のサーバーフェッチで正しい設定が復元される（v2.1.198 以降、env の3カテゴリは保留されるので改ざんの効果が限定される）。
キャッシュ設定ファイルを削除する：初回起動の挙動になり、短い未適用ウィンドウが生じる。
変更された Claude Code バイナリを実行する：クライアント側の制御はバイパスできる。
古いバージョンを実行する：サーバー管理設定より前のバージョンはフェッチも適用もしない。
別の組織で認証する：管理対象組織外のアカウントには配信されない。
サードパーティプロバイダーを構成する：サーバー管理設定はバイパスされる（CLAUDE_CODE_USE_BEDROCK、CLAUDE_CODE_USE_MANTLE、CLAUDE_CODE_USE_VERTEX、CLAUDE_CODE_USE_FOUNDRY、CLAUDE_CODE_USE_ANTHROPIC_AWS、デフォルト以外の ANTHROPIC_BASE_URL）。
トラフィックが傍受・リダイレクトされる：TLS 検証が無効化されたり傍受されたりすれば、クライアントが受け取る設定を変えられる。

（全シナリオと詳細な挙動は公式の表を参照してください。）

対策として公式が挙げているのは3つです。ランタイムの構成変更を検出するなら ConfigChange フックで変更をログするか、有効になる前に不正な変更をブロックする。クライアントが提供する認証情報でアクセスできる組織を制限するならテナント制限によるネットワークレベルのアクセス制御。そしてより強い保証が必要なら、MDM に登録されたデバイスでエンドポイント管理設定を使う。

4. まとめ＋次回予告

サーバー管理設定は、claude.ai の管理コンソールから組織全体に Claude Code の設定を配る仕組み。MDM 不要。Teams / Enterprise 向け。
必要なのは Owner または Primary Owner ロール。Admin では見ることすらできない。
settings.json のほぼ全設定を配れる。hooks、env、管理専用設定も含む。ただし policyHelper / wslInheritsWindowsSettings のような OS ポリシー限定のキーと managed-mcp.json は不可。
グループ別構成は未サポート。全ユーザーに均一に適用される。
ソースはマージされない。サーバー管理が何か配信すればエンドポイント管理は無視される。policyHelper があればそれが全部に勝つ。
起動時フェッチ＋1時間ポーリング。初回はキャッシュがないので短い未適用ウィンドウがある。許容できないなら forceRemoteSettingsRefresh: true（ただし api.anthropic.com に到達できないと起動不能になる）。
v2.1.198 以降、キャッシュされた env のプロキシ／ルーティング／認証変数はサーバー確認まで保留される。プロキシ設定は管理 env だけに置かず、シェルかユーザー設定に書く。
**シェルでプロバイダー変数や独自 ANTHROPIC_BASE_URL をエクスポートするとフェッチごとスキップされ、管理設定側から取り消せない。**確実に効かせたいならエンドポイント管理チャネルを使う。
フック・カスタム env・シェルコマンド設定・管理 CLAUDE.md はユーザーの承認ダイアログを経る。拒否されると Claude Code は終了する。
**クライアント側の制御であって、セキュリティ境界ではない。**強制力が要るなら MDM ＋エンドポイント管理設定。

実務的な導入順序としては、テストマシンで claude doctor 検証 → 小さく配信 → /status と /permissions で反映確認 → 範囲を広げる。いきなり forceRemoteSettingsRefresh を入れると、ネットワーク要件を満たさないユーザーが起動できなくなるので、最後に検討する項目です。

次回予告（暫定）：Bedrock / Agent Platform / Foundry 環境でサーバー管理設定の代わりを務める、**Claude apps ゲートウェイ（claude-apps-gateway）**を取り上げる予定です。

※連載の実際の次テーマは未確定です。