組織への導入と管理設定

Claude Code は、開発者のローカル設定より優先される管理設定（managed settings）で、組織のポリシーを強制します。管理設定は、claude.ai の管理コンソール・MDM（モバイルデバイス管理）・ディスク上のファイルから配ります。設定で、Claude が使えるツール・コマンド・サーバー・ネットワークの宛先を制御します。

• 導入の判断は、API プロバイダー → 設定の届け方 → 強制する内容 → 使用状況の見える化 → データの扱い、の順
• 管理設定の配布方法は 4 種類（サーバー管理・plist／レジストリ・ファイル・Windows の HKCU）で、既定では優先度の最も高い 1 つだけが使われる
• MCP サーバーは、managed-mcp.json・managedMcpServers・許可／拒否リストで制御できる
• 機能の提供状況はプロバイダーとプランで違う
• 導入後の広報とチャンピオン（社内の推進役）向けの手引きもある

導入の判断の流れ#

API プロバイダーを選ぶ#

Claude Code は、複数の API プロバイダーのどれかを通じて Claude につながります。選択は、課金・認証・引き継ぐコンプライアンスの姿勢・開発者が使える Claude Code の機能に影響します。

• 一部の機能は claude.ai アカウントが要ります。クラウドセッション・ルーティン・コードレビュー・リモートコントロール・Chrome 拡張は、Console の API キーやクラウドプロバイダーの資格情報だけでは使えません。Bedrock・Vertex AI・Foundry で導入するなら、開発者にも Teams か Enterprise の席が要るかを計画します。各機能のページにプランの要件があります
• プロバイダー別の認証・リージョン・機能の対応の比較は、エンタープライズ導入の概要を見ます。プロキシとファイアウォールの要件は、プロバイダーにかかわらず適用されます（ネットワークと LLM ゲートウェイ）。複数のプロバイダーの前に 1 つのエンドポイントを置きたい、またはリクエストのログを一元化したいなら、LLM ゲートウェイを使います

設定の届け方を決める#

管理設定が組織のポリシーを定めます。Claude Code は、下の 4 つの取得元を優先度の順に調べます。

• サーバー管理設定は、起動時に取得し、セッション中は 1 時間ごとに更新します。配布するエンドポイントのインフラは要りません。claude.ai の管理コンソール経由は Teams か Enterprise のプランが必要です。Bedrock・Vertex AI・Foundry の導入は、Claude apps gateway を動かして同じリモート配布を得るか、ファイルや OS レベルの方式を使います（Claude apps gateway）
• プロバイダーが混在する組織は、claude.ai のユーザー向けのサーバー管理設定に加えて、ファイルか plist／レジストリのフォールバックを設定すると、他のユーザーにも管理ポリシーが届く
• plist と HKLM のレジストリは、どのプロバイダーでも動き、書き込みに管理者権限が要るので改ざんに強い。HKCU は昇格なしで書けるので、強制の経路ではなく便宜上の既定として扱う
• 既定では、WSL は /etc/claude-code の Linux のファイルパスだけを読む。同じマシンの Windows レジストリと C:\Program Files\ClaudeCode のポリシーを WSL へ広げるには、これらの管理者専用の Windows 取得元のどちらかで wslInheritsWindowsSettings: true を設定する
• どの方式でも、管理値はユーザー設定とプロジェクト設定より優先される。例外はセキュリティ上の少数のもの。permissions.allow や permissions.deny などの配列は、全取得元のエントリを統合するので、開発者は管理リストに足せるが、取り除けない。fallbackModel・availableModels・modelPicker は、統合ではなく管理値が下位の層を置き換える

Claude Code Desktop の WSL セッション#

Windows の Claude Code Desktop は、Code セッションを WSL 2 のディストリビューション内で動かせます。そのセッションの Claude Code プロセスはディストリビューション内で動くので、上の WSL の探索パスで管理設定を解決します。wslInheritsWindowsSettings: true を配らない限り、Windows 専用の取得元は届きません。

Claude Desktop は、組織管理と検出したデバイス（C:\Program Files\ClaudeCode\managed-settings.json がある場合など）では、既定で WSL セッションをオフにします。オンにするには、Windows のレジストリポリシーを配ります（Claude Desktop v1.19367.0 以降）。

• HKLM\SOFTWARE\Policies\Claude の下に disableWslSessions という値を作り、REG_SZ の文字列 false か REG_DWORD の 0 にする。この値は、管理設定を運ぶ ClaudeCode キーとは別の、Claude Desktop のポリシーキーの下に置く。書き込みに管理者権限が要る HKLM に配る。HKCU の値では WSL セッションは有効にならない
• C:\Program Files\ClaudeCode\managed-settings.json を配っているなら、そのまま残す。HKLM の disableWslSessions が false になれば、そのファイルがあっても Desktop は WSL セッションを許す
• Desktop は WSL セッションが始まるたびにポリシーを読むので、配った後にアプリを再起動する必要はない

それでもデバイスが WSL セッションを拒否するなら、そのデバイスの Claude Desktop で「Help > Troubleshooting > Show Logs in Explorer」を開き、ログフォルダのコピーをダウンロードに保存します。そのコピーの main.log から [wslPolicyGate] denying WSL session を探すと、拒否の理由が (cli-file-present) のように括弧で続きます。.exe インストーラーで入れたなら、%APPDATA%\Claude\logs\main.log を直接読めます。

WSL セッションを有効にしたあとは、管理設定を WSL にも広げます。

• wslInheritsWindowsSettings: true を、HKLM のレジストリか C:\Program Files\ClaudeCode のファイルで配り、WSL セッションがホストのセッションと同じポリシーを引き継ぐようにする
• WSL セッション内で /status を実行し、Setting sources の行を読んで確かめる

WSL 2 のユーティリティ VM 内のプロセスは、Windows 側のエンドポイント検知センサーから見えません。ディストリビューション内のプロセスとファイルの活動を観測するには、エンドポイント検知ベンダーの WSL のガイダンスで、ディストリビューション内で動かせる Linux センサーと必要な除外設定を確認します。Claude Code の OpenTelemetry のツール実行のテレメトリは、WSL でもネイティブでも同じように出ます（利用状況の計測）。

強制する内容を決める#

管理設定で、ツールの制限・サンドボックス実行・MCP サーバーとプラグインの取得元の制限・動かすフックの制御ができます。

メンバーが claude.ai か Anthropic API でサインインしていて Claude Enterprise プランなら、何も配らずに、組織の管理設定からもモデルを管理できます。

• 組織のモデル制限：個別のモデルを無効にする。サーバー側で強制される
• 組織の既定モデル：新しいセッションが始まるモデルを決める。メンバーはモデルを切り替えられる。起動時に組織の既定へ戻すには、その節にある上書きをオンにする。選べるモデルを限るには、組織のモデル制限を使う
• 組織の effort の上限：ロールごとに effort レベルの上限を決める。サーバー側で強制される

これらは、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Claude Platform on AWS のセッションには届きません。それらのプロバイダーでは管理設定を使います：制限には availableModels、既定には model、effort の上限には maxEffortLevel です。

• クラウドセッションには、claude.ai に独自の管理画面があります
  • Cloud environments のページ：オーナーが、メンバーのクラウドセッションの、ネットワークアクセスレベル・環境変数・セットアップスクリプトを決める組織共有の環境を作る
  • 既定の環境：組織の既定の環境は、claude.ai/admin-settings/claude-code でオーナーが別に選ぶ
  • GitHub のページ：組織に関連づけた GitHub アカウントは、次の「連携済みの GitHub アカウント」を見る
• 権限ルールとサンドボックスは別の層です。WebFetch を deny すると Claude の fetch ツールはブロックされますが、Bash が許可されていれば curl や wget はどの URL にも届きます。サンドボックスは、OS レベルで強制するネットワークのドメイン許可リストでこの穴を塞ぎます

連携済みの GitHub アカウント#

Team と Enterprise のプランでは、「Organization settings > GitHub」に、Claude GitHub App を通じて Claude の組織に関連づけた GitHub の組織と個人アカウントが一覧で出ます。Claude Code・Claude Tag・Claude Security が同じ一覧を共有します。開くには、Claude の組織の管理者のロールが要ります。

関連づけは、管理者でもメンバーでもできます。

• 管理者による連携：管理者がそのページの「Connect」を押し、GitHub の組織に Claude GitHub App を入れる。この方法で組織を関連づけるには、GitHub の組織のオーナーであり、かつ Claude の組織の管理者でもある人が要る
• メンバーによる連携：メンバーが自分の GitHub アカウントを Claude につなぐとき（たとえばクラウドセッションの設定の途中）、Claude は、そのメンバーが所有するアカウントのうち Claude GitHub App がすでに入っているものを関連づける。個人アカウントと、所有する GitHub の組織が含まれうる

「Not linked」と印のついた行は、自分の GitHub のサインインから来たものです。GitHub で見えるアカウントのうち Claude GitHub App が入っているものです。

アカウントを Claude の組織から外すには、その行のメニューで「Unlink from this workspace」を選びます。外しても GitHub 上の Claude GitHub App は入ったままで、そのアカウントは、所有者の誰かが次に GitHub を Claude につなぐと、また関連づけられます。再び関連づけられないようにするには、GitHub でそのアカウントから Claude GitHub App をアンインストールします。

Enterprise のプランでは、関連づけと解除の Compliance API のアクティビティの種類は github_app_installation_linked と github_app_installation_unlinked です。

使用状況の見える化#

Teams と Enterprise のユーザー別の使用量と支出の数値は、分析ダッシュボードではなく、組織の分析設定の Spend report から取ります。クラウドプロバイダーの支出は、AWS Cost Explorer・GCP Billing・Azure Cost Management で見ます。Claude chat・Claude Code・Cowork をまたぐ Enterprise の予算計画は、Claude Enterprise の consumption guide を参照します。

データの扱いを確認する#

Team・Enterprise・Claude API・クラウドプロバイダーのプランでは、Anthropic はあなたのコードやプロンプトでモデルを学習しません。保持とコンプライアンスの姿勢は、API プロバイダーで決まります。

リクエスト単位の監査ログが要る、またはデータの機微さで通信を振り分けたいなら、開発者とプロバイダーの間にゲートウェイを置きます：IdP の ID つきでリクエストごとの監査ログを記録するセルフホストの Claude apps gateway、または別の LLM ゲートウェイです。規制要件と認証は Legal and compliance を参照します。

検証と開発者の立ち上げ#

管理設定を配ったら、開発者に Claude Code で /status を実行してもらいます。「Status」タブの Setting sources の行に、Enterprise managed settings と、勝った取得元が括弧で出ます。

• 開発者に共有する資料：クイックスタート（インストールからプロジェクトでの作業までの最初のセッション）、よくある作業の進め方（コードレビュー・リファクタリング・デバッグなど。よくある作業の進め方）、Claude Academy の無料の自習コース「Claude Code 101」と「Claude Code in Action」
• ログインの問題の主な対処：/logout のあと /login でアカウントを切り替える。企業の認証の選択肢が出ないなら claude update を実行する。更新後はターミナルを再起動する。トラブルシューティングはトラブルシューティングにあります
• 「You haven't been added to your organization yet」と出たら、その開発者の席に Claude Code のアクセスが含まれていないので、管理コンソールで席を更新する

次の段階の詳細な設定は、サーバー管理設定（下の節）・設定キー一覧・設定ファイルの仕組み・モノレポ向けのディレクトリ別設定のパターン・プロバイダー別の導入（Bedrock・Vertex AI・Foundry）にあります。

管理設定を配る#

管理設定は、組織が全開発者のマシンに配る設定です。Claude Code はそれを他のどのレベルよりも上に適用し、ユーザー・プロジェクト・ローカル・--settings のどの値も上書きできません。ただし、下位レベルのより厳しい値が数えられる、セキュリティ上の少数の例外があります。ここは、管理設定を配る、または適用されない理由を調べる管理者向けです。

管理設定ファイルを配る#

マシンごとにポリシーを置く最短の方法は、managed-settings.json ファイルです。

1. managed-settings.json を書く。settings.json と同じ JSON の形で、強制すると決めたキーを入れる。下の例は、2 つのファイルの読み取りをブロックし、bypass mode をオフにし、ユーザー・プロジェクト・ローカルのファイルと --allowedTools の権限ルールを Claude Code に無視させる

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

2. OS のシステムディレクトリへ managed-settings.json として置く（機器管理の既存の仕組みで配る）
   • macOS：/Library/Application Support/ClaudeCode/managed-settings.json
   • Linux と WSL：/etc/claude-code/managed-settings.json
   • Windows：C:\Program Files\ClaudeCode\managed-settings.json
3. 1 台で Claude Code の /status を実行し、Setting sources の行に Enterprise managed settings (file) と出るか確認する。そのあとフリート全体へ広げる

ログイン方法・モデル・MCP サーバー・マーケットプレイスを含む、より多くの管理キーの形の例は、設定ファイルの仕組みのページの組織の管理設定の例を見ます。

配布方式を選ぶ#

上のファイルは、管理設定をマシンへ届ける 4 つの方法の 1 つです。どの方式も settings.json と同じポリシーキーを運ぶので、設定キー一覧がすべてに当てはまります。一部のキーは特定の取得元に結びつき、各エントリの Scope の行が示します。

• 配布の制御キー：policyHelper・wslInheritsWindowsSettings・managedSourcesBehavior
• ゲートウェイのログインキー：forceLoginGatewayUrl・gatewayInternalNetworks・forceLoginMethod の "gateway" の値

管理設定ファイル・MDM のプロファイル・claude.ai のコンソールは、届く全員に 1 つのポリシーを適用します。ある開発者グループに別のポリシーを与えるには、そのグループへ別のファイルかプロファイルを配ります。claude.ai のコンソールはまだグループを対象にできませんが、セルフホストの Claude apps gateway は IdP のグループごとに管理設定を配ります。同じマシンに複数の方式でポリシーが届くと、Claude Code は既定で 1 つを使い、ほかを無視します（順序と、すべてを適用する設定は次の「管理の取得元の統合」）。MDM とファイルの行をまとめて、ポリシーが開発者のデバイスに置かれるのでエンドポイント管理の設定と呼び、Claude Code が取得するサーバー管理と区別します。

Jamf・Iru・Intune・グループポリシーの雛形は、MDM の例のリポジトリ（anthropics/claude-code の examples/mdm）にあります。MDM とファイルのどれにも添えて配れる管理 MCP サーバー（managed-mcp.json か managedMcpServers）は、下の「MCP サーバーの制御」を参照します。

ポリシーが届く場所とタイミング#

• サーフェス：開発者のマシンでは、ターミナル・VS Code と JetBrains の拡張・デスクトップアプリの Code タブ・Agent SDK のセッションが、これらすべての取得元を読む。Agent SDK のセッションは、settingSources がユーザー・プロジェクト・ローカルのファイルを除いても管理設定を読み込む
• クラウドセッション：Anthropic がホストする環境のセッションは、デバイスの MDM プロファイルもファイルも読まないので、ポリシーはサーバー管理設定から届ける。セルフホスト環境のセッションは、ランナーのイメージの管理設定ファイルも読む（既定では、サーバー管理設定がポリシーキーを届けないときだけ。全取得元から読むキーは別）
• Claude Tag のセッション：クラウド環境で動くが、サーバー管理設定を受け取らない。セルフホスト環境では、ランナーのイメージの管理設定ファイルを読む。Claude Tag 自体は Claude Tag の管理設定で構成する（Slack と Claude Tag）
• Cowork のセッション：Claude Desktop アプリの Cowork は、セッションを Claude Code の上で動かす。Cowork のセッションでは、Team か Enterprise のアカウントでサインインしても、Claude Code は claude.ai の管理コンソールからサーバー管理設定を取得しない。どのポリシーが適用されるかは、セッションの動く場所による
  • ユーザーのマシン上：既定では、Claude Code はそのデバイスの MDM か OS レベルのポリシーと管理設定ファイルを読むので、そこへポリシーを配る
  • フル VM サンドボックス内：Claude Desktop の管理構成が requireCoworkFullVmSandbox を設定すると、Claude Code はデバイスの MDM ポリシーも管理設定ファイルも無い仮想マシンの中で動く
  • リモートの Cowork セッション：Anthropic が管理する VM で動き、Claude Code が読むデバイスのポリシーは無い
  • どこで動いても、claude.ai は、claude.ai の git リポジトリか Cowork タブの「Customize」からマーケットプレイスを足すとき、管理コンソールの strictKnownMarketplaces と blockedMarketplaces のリストを自分で適用する
• 動作中のセッション：ほとんどの変更は、配布方式の表の周期で、再起動なしに動作中のセッションへ届く
  • forceRemoteSettingsRefresh・requiredMinimumVersion・一部のユーザーが編集できるキーの変更は、次のセッション開始で有効になる
  • 新規または変更した policyHelper のエントリは、次の起動で有効になる。その起動でサーバー管理設定がヘルパーを覆っていたら、取得でそれらの設定が外れたと報告された時点でヘルパーが動く
• 承認が要る変更：次の起動まで待つ更新を除き、承認が要る設定（フックや env 変数など）のサーバー管理の変更は、対話セッションでは開発者がダイアログを受け入れるまで待ち、IDE 拡張や Agent SDK がホストするセッションでは現在の実行に適用される。ほかのサーバー管理の変更は、次のポーリングで適用される
• 長く動くセッション：何週間も開いたセッションは、展開に遅れることがある。requiredMinimumVersion は古いバイナリの起動を止めるが、すでに動いているセッションは終了させない

各方式のポリシーの保管場所#

キーはどこでも同じですが、方式ごとに保管場所と形が違います。

ファイルベースのポリシーをチームで分ける#

1 つのポリシーの各部分を複数のチームが持つなら、共有の 1 ファイルを編集せず、managed-settings.json と同じシステムディレクトリの managed-settings.d/ に、部分ごとのファイルを置きます。Claude Code は、まず managed-settings.json を統合し、次にそのディレクトリの *.json を英数字順に統合します。順序は、10-telemetry.json・20-security.json のように数字の接頭辞で制御します。隠しファイルと .json で終わらないファイルは無視されます。2 つのファイルが同じキーを設定したときの統合規則です。

管理の取得元の統合#

同じマシンに複数の管理の取得元が届くと、managedSourcesBehavior キーが、ほかの取得元の扱いを決めます。

この節で繰り返す用語です。

• ポリシーキー：2 つの制御キー（wslInheritsWindowsSettings と managedSourcesBehavior）以外の、あらゆる設定キー。この 2 つだけを含む管理設定ファイルや MDM のポリシーは数えず、Claude Code は次の取得元へ進む
• 管理者の取得元：下の最初の 3 つのどれか。HKCU レジストリはユーザーが書き込めるので含まれない

優先度の高い順に、Claude Code は取得元を次の順に調べます。

1. リモート設定：claude.ai からサーバー管理設定として、または Claude apps gateway から届く。セッションが Anthropic の API へ、対象のログインかキーで直接認証するか、ゲートウェイへ /login でサインインするときだけ、この取得元を取得する。ほかのプロバイダーや、ANTHROPIC_BASE_URL が Anthropic の API 以外を指すときは、次の取得元から始まる
2. MDM か OS レベルのポリシー：macOS の plist か HKLM のレジストリキー
3. 管理設定ファイル：managed-settings.d/*.json と managed-settings.json を統合したもの
4. Windows の HKCU レジストリ。WSL では、HKLM のレジストリか Windows の管理設定ファイルが wslInheritsWindowsSettings をオンにし、HKCU の値もそれを設定したとき。上位に管理者のドキュメントが無く、ホストが渡す親設定が制限的なキーを供給しないときだけ読む

管理者のドキュメントが存在するとみなす場合#

管理の取得元の順位づけで、Claude Code は、ユーザーが書き込める HKCU レジストリを、存在する管理者のドキュメントの下には決して適用しません。ドキュメントが「存在する」のは、次のときです。

• どれかのポリシーキーを null 以外の値（Claude Code が読めない値でも）に設定している
• HKLM の値・管理設定ファイル・managed-settings.d ディレクトリで、存在するのに読めない

WSL では /etc/claude-code もユーザーが書き込めます。

全管理者取得元から読むキー#

既定の "first-wins" では、Claude Code は、ほとんどのキーを選んだ取得元からだけ読み、選んだ取得元がそのキーを未設定でも、下位の取得元の値は無視します。一部のキーは例外で、すべての管理者取得元から読むので、選ばれた取得元が設定していなくても、下位の MDM ポリシーや管理設定ファイルが設定できます。ユーザーが書き込める HKCU レジストリはこの走査から外れます（HKCU が唯一の取得元で、ホストが親設定を供給しないときは、選ばれた取得元と同じく適用される）。

• sandbox.network.allowManagedDomainsOnly と sandbox.filesystem.allowManagedReadPathsOnly：どの管理者取得元でも true ならロックがオンになる。ロックがオンのあいだ、ロックされる許可リスト（sandbox.network.allowedDomains と WebFetch(domain:...) の allow ルール、または sandbox.filesystem.allowRead）は、全管理者取得元で和集合になる。ロックがなければ、許可リストは他のキーと同じ扱いで、"first-wins" では選ばれなかった管理者取得元のリストは無視される
• allowAllClaudeAiMcps
• allowManagedMcpServersOnly：どの管理者取得元でも true なら MCP の許可リストのロックがオンになる。オンのあいだ、管理の allowedMcpServers リストは、それを設定する最も優先度の高い管理者取得元から来る。サーバー管理のリストは、下位の取得元のリストと結合せず置き換える。どの管理者取得元もリストを設定しなければ、拒否リストを通るすべてのサーバーが読み込まれる（親設定がリストを供給する場合を除く）。ロックがなければ、allowedMcpServers は適用する管理の取得元から読むので、"first-wins" では選ばれなかった取得元のリストは無視される。v2.1.273 以降
• deniedMcpServers と disableClaudeAiConnectors：どの管理者取得元でも、エントリか true があれば適用される。v2.1.273 以降
• サンドボックスのバイナリのパス sandbox.bwrapPath と sandbox.socatPath
• サンドボックスの ripgrep バイナリ sandbox.ripgrep
• sandbox.filesystem.disabled と sandbox.network.strictAllowlist
• useAutoModeDuringPlan・syncClaudeAiSkills・syncClaudeAiPlugins：どの管理者取得元からでも false ならその動作はオフになる。開発者のユーザー設定やローカル設定の false でもオフになる。各キーは拒否することしかできない
• enableArtifact：どの管理者取得元からでも false ならアーティファクトツールがオフになる。開発者のユーザー・プロジェクト・ローカル設定の false でもオフになり、どの取得元もオンに戻せない。v2.1.242 以降
• maxEffortLevel：どの管理者取得元でも最も低い上限が適用される。開発者が自分の設定か --settings でより低い上限を設定すれば、そちらが適用される。どの取得元も上限を上げられない。v2.1.267 以降
• attribution（または非推奨の includeCoAuthoredBy）のコミットトレーラーのオプトアウト。どの階層からでも
• forceRemoteSettingsRefresh
• env：管理者取得元をまたいで変数ごとに統合される。各変数は、それを定義する最も優先度の高い取得元から来て、上位が未設定の変数を下位が埋める。一部の変数は独自の規則に従う（サーバー管理設定の「全管理の取得元をまたぐキーごとの例外」）。v2.1.223 以降（それより前は、選んだ取得元の env ブロック全体だけを適用していた）

ゲートウェイのログインキーは別の規則に従います。Claude Code はそれらをサーバー管理設定から読まないので、サーバー管理設定が選ばれた取得元であっても、ポリシーキーを持つ、マシン上の最も優先度の高い管理者取得元が供給します。それより優先度の低い管理者取得元や HKCU レジストリの値は無視されます。allowedProviders は独自の規則を持ちます（v2.1.285 以降。マシンに設定したリストとサーバー管理のリストの組み合わせ方は、そのエントリの Scope の注記にあります）。管理者取得元が allowManagedMcpServersOnly か allowedMcpServers リストを設定していても、その値が有効になっていない場合は、/status と claude doctor が、その取得元とキーを示します。

すべての管理の取得元を合成する#

Claude Code に、組織が届けるすべての管理者取得元を適用させるには、配る中で最も優先度の高い取得元で managedSourcesBehavior を "merge" にします。Claude Code はこのキーを、そのキーかポリシーキーを持つ最も優先度の高い取得元からだけ読みます。下位の取得元が、自分から上位の取得元との統合にオプトインすることはできません。サーバー管理設定を受け取らないマシンは、MDM のプロファイルにもこのキーが要ります。ユーザーが書き込める HKCU レジストリは、ほかの取得元と統合されません（v2.1.242 以降）。

"merge" では、Claude Code は下位の取得元のリストのエントリ（permissions.allow のルールやフック）をポリシーに加えるので、最上位より下のすべての取得元が管理者の管理下にあるときだけオンにしてください。"merge" でのキーの種類ごとの統合のしかたです。

マシンでどの取得元が統合されたかは、/status の Setting sources の行で確認します。

ヘルパープログラムでポリシーを算出する#

policyHelper は、MDM のポリシーか管理設定ファイルが指名する実行ファイルで、Claude Code が起動時に動かして管理設定を算出します。選ばれた取得元がヘルパーを設定し、ヘルパーが managedSettings オブジェクトを出力すると、読み込みが変わります。出力された managedSettings オブジェクトが、そのセッションの唯一の管理設定になります（全管理者取得元から読むはずのキーも同じ。forceRemoteSettingsRefresh は起動時の独自の規則を持つ）。どのヘルパーの実行が失敗とみなされ、失敗したら Claude Code がどうするかは、設定キー一覧の Helper failures を見ます。

埋め込みホストにポリシーを足させる#

別のアプリ（Claude Desktop・IDE 拡張・Agent SDK のアプリなど）が Claude Code を起動するとき、そのホストは、SDK の managedSettings オプションで自前の管理設定を渡せます。Claude Code はこれを親設定（parent settings）と呼びます。既定では、管理者取得元（サーバー管理設定・MDM か OS レベルのポリシー・管理設定ファイル）があるかぎり、親設定は無視されます。

• 親設定を管理者取得元と統合するには、最も優先度の高い管理の取得元で parentSettingsBehavior を "merge" にする（Claude Code はこのキーをその取得元からだけ読む）
• そのとき、Claude Code はホストの値のうち、Claude ができることを制限するものだけを残す。ただし、allowManaged*Only のロックも設定しない限り、ホストの権限の allow ルールとサンドボックスの許可リストは引き続き適用される点に注意（Claude apps gateway の「Restrict parent settings」にロックの説明がある）
• policyHelper は、このキーにかかわらず親設定の統合をオフにできる

Claude Code は、親が供給した値にも次の確認を単独で適用します。

• どの管理者取得元でも allowManagedPermissionRulesOnly が設定されていると、上位の取得元がそのキーを未設定でも、親が供給した権限の allow ルールと additionalDirectories は、読み込み時に捨てられる
• forceLoginOrgUUID と allowedMcpServers は、適用する管理設定の値が強制され、親が供給した値はブロックされる。MCP の許可リストのロックの外では、Claude Code が適用しない下位の管理者取得元の値は、親の値を適用も妨げもしない。v2.1.273 以降は、allowManagedMcpServersOnly がオンのあいだ、それを設定する最も優先度の高い管理者取得元の allowedMcpServers が適用され、親のリストをブロックする（全管理者取得元から読むキーとして）。親のリストが適用されるのは、どの管理者取得元もリストを設定していないときだけ。v2.1.223 より前は、どの管理者取得元の値でも親の値をブロックしていた
• availableModels は、適用する管理設定の値が強制され、親が供給したリストはブロックされる
• strictKnownMarketplaces も同様に、適用する管理設定のリストが強制され、親が供給したものはブロックされる。親のリストが適用されるのは、適用された管理の取得元のどれもリストを設定していないときだけ。v2.1.282 以降
• allowedProviders は、選ばれた管理の取得元のリストが、親が供給したリストをブロックする。managedSourcesBehavior を "merge" にしているときは、どの管理者取得元のリストでもブロックする。v2.1.285 以降
• 親が供給した blockedMarketplaces は、管理の取得元が設定するブロックリストに加えて適用される。v2.1.282 以降

管理ルールだけが適用されるときの Cowork のフォルダアクセス：Claude Desktop の Cowork は、セッションを Claude Code の上で動かし、セッションの起動時に Cowork が供給する allow ルールで、ユーザーが接続したフォルダなどの作業フォルダへのアクセスを与えます。管理ポリシーが allowManagedPermissionRulesOnly を設定すると、Claude Code は管理ポリシーの allow ルールだけを残し、ホストが親設定・--allowedTools・設定ファイルとして供給した allow ルールを捨てるので、それらのフォルダへの書き込みの事前承認がなくなります。編集の前に確認する Cowork のセッションでは、Cowork が確認を表示できず、Claude はパスが保護された場所か接続フォルダの外に解決されるとして、書き込みごとにブロックされたと報告します。

書き込みを戻すには、それらのマシンで Claude Code が選ぶ管理の取得元に、フォルダの allow ルールを足します（MDM 管理のフリートでは、別の管理設定ファイルではなく MDM ポリシー）。次の例はファイルの形で、MDM ポリシーも同じキーを取ります。allowManagedPermissionRulesOnly を設定したまま、各ユーザーのホームディレクトリの CoworkProjects フォルダの下の編集を許可します。パスは、ユーザーが接続するフォルダに置き換えます。

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "allow": [
      "Edit(~/CoworkProjects/**)"
    ]
  }
}

ポリシーを配ったあとは、新しい Cowork セッションで、Claude がそのフォルダの下にファイルを保存できます。パスの書き方（絶対パスの // の形を含む）は、権限ルールの Read と Edit のルールを見ます。

開発者が変えられること#

開発者自身の設定ファイル・--settings の値・プロジェクトのファイルは、管理値を上書きしません。例外は、より厳しい下位レベルの値を数えるだけです。この規則の外にあるのは次の場合です。

• セッションのモデル：管理の model は既定であってロックではない。--model と ANTHROPIC_MODEL が、そのセッションのモデルを選べる。選択を制限するには availableModels を配る
• セッションの自動圧縮のウィンドウ：管理の autoCompactWindow も既定である。--autocompact フラグと CLAUDE_CODE_AUTO_COMPACT_WINDOW 環境変数が、そのセッションの自動圧縮のウィンドウを決められる
• ローカルの管理者権限：マシンの管理者である開発者は、管理の取得元そのものを編集できる。MDM のツールがプロファイルやファイルを定期的に配り直せるのも、HKLM レジストリと macOS の管理される環境設定のドメインがあるのも、そのため
• サーバー管理のキャッシュ：サーバー管理設定は Anthropic のサーバーから来る。ローカルのキャッシュの編集は、次に取得が成功するまでしか続かない
• ほかのツール：管理設定は Claude Code だけを縛る。ほかのツールから API を呼ぶ開発者は、その対象外

ポリシーが効いているか確認する#

開発者がポリシーが効いていないと報告するか、フリートへ広げる前に展開が届いたかを確かめたいとき、そのマシンの 2 つのコマンドが答えます：/status は Claude Code が選んだ管理の取得元を示し、claude doctor は捨てたものを一覧にします。

/status で取得元を読む#

開発者のマシンで Claude Code の /status を実行し、Setting sources の行を読みます。管理の取得元が有効なとき、この行は Enterprise managed settings と、選んだ取得元を括弧で示します。

Claude Code がマシンで管理の取得元を見つけたのに選ばなかった場合は、2 行目の Skipped sources が、そのような取得元を挙げます。ポリシーがマシンに届いていないのか、届いたが上位の取得元に上書きされたのかを見分けるのに使います（v2.1.242 以降）。ポリシーが効いていないとき、Setting sources の行で次のどちらかが分かります。

• 行が無い：Claude Code が、ポリシーキーを届ける管理の取得元を見つけなかった。管理設定ファイルを配ったなら、OS ごとのパスにあるか、制御キーだけでなくポリシーキーを含むかを確認する。有効な JSON でないファイルはこの状態にならず、Claude Code は起動を拒否する。サーバー管理設定で配ったなら、claude doctor を実行して取得の結果を見る
• 配ったものと別の取得元が出る：より優先度の高い取得元があり、Claude Code があなたのものを無視した。Skipped sources がそれを挙げる

Claude Code が捨てたエントリを見つける#

管理設定ファイル・MDM のプロファイル・レジストリ値・サーバー管理のペイロードがスキーマ検証に失敗すると、Claude Code はまず、直せる個々のエントリ（1 つの無効な権限ルールなど）を飛ばして、それぞれ警告します。そのうえで、フェイルクローズするキーの値を除き、それでも失敗する値を捨てます。

• policyHelper が出力する managedSettings には、より厳しく対応する。同じエントリの修復はするが、残ったスキーマ違反があるとヘルパーの実行全体が失敗し、起動時に Claude Code は、非ゼロで終了したヘルパーと同じように起動を拒否する
• 管理設定ファイル・ドロップインのファイル・MDM の plist・HKLM のレジストリ値が、存在するのに JSON オブジェクトとして解析できないと、別の管理者取得元が有効なポリシーを届けていても、Claude Code は起動を拒否し、取得元を挙げたエラーを出す。各取得元がこう失敗するのは、次のときです
  • 管理設定ファイルかドロップインのファイル：有効な JSON でない、またはトップレベルがオブジェクトでない
  • MDM の plist：macOS の plutil が plist を不正と報告する、または変換した内容が JSON オブジェクトでない
  • HKLM のレジストリ値：Settings の値が文字列でない、空、または JSON オブジェクトを持たない
• この拒否にならない 3 つの状態：ファイル・プロファイル・レジストリ値が無いのは失敗ではなく、その取得元なしで動く。空の管理設定ファイルは {} として数える。ユーザーが書き込める HKCU レジストリキーの不正な値は、起動を止めず、/status と claude doctor に通知として出る
• 管理設定ファイル・ドロップイン・managed-settings.d/ ディレクトリ・MDM のプロファイル・HKLM のレジストリ値が存在するのに読めず、どの管理者取得元もポリシーを供給しない場合、動作は読めなかった理由による
  • OS が読み取りを拒否した（root だけのファイルなど）：すべてのセッションがその取得元のポリシーなしで始まる。/status と claude doctor が失敗を記録し、-p の実行は stderr にも出す
  • それ以外の読み取りの失敗（I/O エラーなど）：すべてのセッションが、管理者に連絡するよう促すメッセージを出して起動時に終了する

捨てられたエントリを見つけるには、次の 3 か所のどれかを見ます。

• 対話セッションは、起動時に無効なエントリを挙げるダイアログを出す
• -p の非対話実行は、stderr に要約を出す
• claude doctor が、無効なエントリごとに、取得元と項目を挙げる（設定のデバッグ）

フェイルクローズするキー#

管理の取得元が、allowManagedPermissionRulesOnly・disableAutoMode・skipDangerousModePermissionPrompt のような、制限的な値が 1 つだけのトップレベルのキーを Claude Code が読めない値に設定すると、直すまで、そのキーはその制限的な値として読まれます。報告は、キーが was present but invalid であることと、Claude Code が扱う値を示します。sandbox の中のキーは次の節を見ます。

次の場合はフェイルクローズしません。

• null はキーを取り除く
• 無効な disableAllHooks（引用符付きの真偽値も）は、警告つきで捨てられる。true を強制すると、自分の管理設定が配るフックまで外れてしまうため
• この規則が対象とするほかのすべての真偽値のキーでは、文字列 "true" か "false" はその真偽値として読まれ、/status が引用符を外すよう通知する

Claude Code は、permissions・autoMode・worktree・attribution のブロックを、まるごと捨てずに項目ごとに修復します。

• ブロックの中のロック（permissions.disableBypassPermissionsMode など）は、その制限的な値として読まれる
• 無効な permissions.defaultMode は default として読まれる
• permissions の deny か ask のリストが読めないあいだ、Claude Code は allow と additionalDirectories を保留する。隣に書かれた制限なしに、許可が適用されないようにするため。報告は、保留した許可と読めなかったリストを挙げる
• autoMode では、soft_deny か hard_deny のリストが読めない、または無効なエントリを失ったとき、同じように allow と environment を保留する

制限的な値が 1 つだけのキーのフェイルクローズと、項目ごとの修復は、v2.1.282 以降です。次のキーは、独自のフォールバックを持ちます。

• allowedHttpHookUrls と httpHookAllowedEnvVars は設定ファイルをまたいで統合されるので、管理リストが空のあいだも、ユーザー・プロジェクト・ローカル設定のエントリは引き続き適用されます
• その 2 つのキーと allowedChannelPlugins のフォールバックは v2.1.267 以降です（それより前は、値かどれかのエントリが無効だとキー全体を捨てる）。strictKnownMarketplaces と blockedMarketplaces のフォールバックは v2.1.277 以降、strictPluginOnlyCustomization と enabledPlugins のフォールバックは v2.1.282 以降です
• requiredMinimumVersion と requiredMaximumVersion は設計上フェイルオープンで、無効な値は強制されず捨てられます
• この寛容さは管理設定だけに当てはまります。ユーザー・プロジェクト・ローカルの設定ファイルは厳しいままで、JSON かトップレベルの形が検証に失敗したファイルはまるごと拒否されて報告され、個々のエントリの失敗（不正な権限ルールなど）は、警告つきで飛ばされて、ファイルの残りは適用されます

sandbox 内の無効な値#

管理の sandbox ブロックの 1 つの値が無効でも、Claude Code はブロック全体を捨てず、項目ごとに検証します。この項目ごとの扱いは v2.1.283 以降です（それより前は、credentials の外の値が無効だと、credentials 以外のすべての sandbox 項目を捨てる）。無効な項目の警告は項目名と扱いを示します。扱いは、その項目が制御するもので決まります。

• 真偽値のキーを引用符付きの "true" か "false" にしたら、その真偽値として数える。警告の代わりに、/status が引用符を外すよう通知する
• failIfUnavailable が無効なら、true として扱わず値を捨てる。読めない値が、フリート全体でセッションの起動を止めないようにするため
• ほかの無効な真偽値は、直るまでサンドボックスを最も厳しく保つ値として扱う。サンドボックスやその制限をオンにするキー（enabled・network.allowManagedDomainsOnly など）は true、緩めるキー（allowUnsandboxedCommands など）は false
• credentials の外のリスト（excludedCommands・network.allowedDomains など）では、無効なエントリを捨てて、残りのリストを保つ。配列でない、または有効なエントリが無いリストは、まったく適用されない
• network.deniedDomains かそのどれかのエントリが無効なあいだ、Claude Code は network.allowedDomains も保留するので、deny リストを直すまで、管理の許可リストは何も許可しない
• filesystem.denyRead・filesystem.denyWrite、またはどちらかのどれかのエントリが無効なあいだ、Claude Code は filesystem.allowRead と filesystem.allowWrite の両方も保留する

管理の取得元だけが設定できるキー#

Claude Code は、次のキーを管理の取得元からだけ読みます。ユーザーやプロジェクトの設定ファイルに置いても効果はありません。多くはロックです：ロックが制御する値（権限ルールや sandbox.network.allowedDomains など）はどのレベルでも設定できる普通のキーで、ロックは Claude Code に管理値だけを尊重させます。表は、権限・プラグイン・配布の制御を扱います。ここに無いキーは、設定キー一覧の索引の Scope の列が、管理専用かを示します。

組織のテレメトリを止める#

Claude Code は、Anthropic の API を使うセッション（直接でも、LLM ゲートウェイ経由でも、独自の ANTHROPIC_BASE_URL 経由でも）で、既定で Anthropic の運用テレメトリを送ります（どのプロバイダーで送るかはセキュリティとデータの扱い）。各人のシェルに頼らず、全開発者でオフにするには、管理設定の env ブロックで DISABLE_TELEMETRY を配ります。

{
  "env": {
    "DISABLE_TELEMETRY": "1"
  }
}

• Claude Code は、値 1 を、承認ダイアログをユーザーに見せずに適用する
• テレメトリをオフにすると、ポリシーが届く開発者について、組織の分析ダッシュボードに入る使用量データの送信が止まる。この変数は、それらの開発者の機能フラグの取得も止める（リモートコントロールはリモートコントロールとモバイルの要件を見る）
• 顧客管理の暗号化キーを使い、Claude Code をゲートウェイ経由にしている組織で、これらのセッションにこの変数が要る理由は、エンタープライズ導入の概要の「Configure proxies and gateways」を見ます

サーバー管理設定#

サーバー管理設定を使うと、組織のオーナーが claude.ai のコンソールの「Organization settings > Claude Code > Managed settings」から、Claude Code を一元的に設定できます。ユーザーが対象の資格情報で、サーバー配信に対応したプラットフォームで認証すると、Claude Code のクライアントがこの設定を自動で取得します。デバイス管理のインフラは要りません。

要件#

• Claude for Teams か Claude for Enterprise のプラン
• 設定の表示と編集に、Claude 組織のオーナー（Owner）か Primary Owner のロール
• api.anthropic.com へのネットワークアクセス

サーバー管理とエンドポイント管理の使い分け#

デバイスが MDM やエンドポイント管理に登録されているなら、設定ファイルを OS レベルでユーザーの変更から守れるので、エンドポイント管理設定のほうが強い保証になります。ただしエンドポイント管理設定は、Anthropic がホストする環境のクラウドセッションには届かないので、開発者がクラウドセッションを使う組織は、サーバー管理設定も設定します。セルフホスト環境のセッションは、ランナーのイメージの管理設定ファイルも読みます。

設定する#

1. claude.ai のコンソールで「Organization settings > Claude Code > Managed settings」を開く。リンクが別の Organization settings のページへ飛ぶなら、アカウントに必要なロールが無い。Admin などオーナー以外のロールは管理設定を表示・編集できないので、組織のオーナーか Primary Owner に変更を頼む
2. 設定を JSON で追加する。OS レベルのポリシー配信に限られるものを除き、settings.json で使えるすべての設定が使える（「現在の制限」を参照）。フック・環境変数・allowManagedPermissionRulesOnly のような管理専用の設定も含む
3. 保存する。Claude Code のクライアントは、次の起動か 1 時間ごとのポーリングで、更新された設定を受け取る

次の例は、権限の deny リストを強制し、ユーザーが権限をバイパスするのを防ぎ、権限ルールを管理設定で定義したものに限ります。Bash(curl *) のルールは、Claude が書いたとおりの curl に一致し、/usr/bin/curl や sh -c 'curl …' には一致しません。コマンドの文面に依存しないネットワークの強制には、allowManagedDomainsOnly を持つ sandbox ブロックを足します（サンドボックス）。

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

フックは settings.json と同じ形式です。次の例は、組織全体で、ファイルを編集するたびに監査スクリプトを動かします。

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

フックはシェルコマンドを実行するので、対話セッションのユーザーには、適用前にセキュリティ承認ダイアログが出ます。auto mode の分類器に、組織が信頼するリポジトリ・バケット・ドメインを教えるには、同じようにして autoMode ブロックを配ります。

配信を確認する#

設定が適用されているか確かめるには、ユーザーに Claude Code を再起動してもらいます。設定にセキュリティ承認ダイアログを起こすものが含まれていれば、Claude Code が次に管理設定を取得したとき（次の起動か、動作中の対話セッションで 1 時間以内）、ユーザーに管理設定の説明が出ます。管理の権限ルールが有効かは、ユーザーが /permissions を実行して、有効な権限ルールを見ても確かめられます。

特定のマシンでの取得の結果は、ユーザーに claude doctor を実行してもらい、Managed settings (remote) の行を読みます（v2.1.248 以降）。行は次の 4 つの結果のどれかを報告します。

• 配信された設定を読み込んだ
• 組織にサーバー管理設定が設定されていない
• 取得に失敗した。原因と、キャッシュされたポリシーがまだ適用されているかが出る
• Claude Code が取得を飛ばした。理由が出る（飛ばすプロバイダーと構成は「提供される場所」の節）

取得がまだ進行中なら、その旨が出ます。動作中のセッションでは、取得が失敗したあと、およびサードパーティのプロバイダー変数やユーザーのシェルで export した独自の ANTHROPIC_BASE_URL のような取得を飛ばす一部の原因のときに、/status が同じ行を示します。デバッグには、claude --debug-file <path> で起動し、ログで Remote settings を探します。組織へ広げる前に、テストマシンで claude doctor でペイロードの変更を検証します。

アクセス制御#

サーバー管理設定を管理できるロールは、Primary Owner と Owner です。設定の変更は組織の全ユーザーに適用されるので、アクセスは信頼できる担当者に限ります。

管理専用の設定#

ほとんどの設定キーはどのスコープでも使えます。一部のキーは管理設定からだけ読まれ、ユーザーやプロジェクトの設定ファイルに置いても効果がありません（権限とプラグインの制御は前の「管理の取得元だけが設定できるキー」）。

現在の制限#

• 設定は組織の全ユーザーに一律に適用される。グループごとの設定にはまだ対応していない
• managed-mcp.json をサーバー管理設定で配ることはできない。代わりに allowedMcpServers と deniedMcpServers のポリシーキーを配る。v2.1.259 以降は、managedMcpServers でリモートサーバーも提供でき、http と sse のサーバーだけを受け付け、ファイルのような排他的な制御はしない。システムパスに配置した managed-mcp.json は、管理設定の層とは別に読まれるので、サーバー管理設定が有効でもファイルは適用される
• policyHelper や wslInheritsWindowsSettings のような、OS レベルのポリシーの取得元に限られる設定は有効にならない。MDM かシステムの managed-settings.json で配る。そのように配った policyHelper は、管理層の優先順位で、その取得元が選ばれたときだけ動く

設定の優先順位#

サーバー管理設定とエンドポイント管理設定は、どちらも Claude Code の設定の階層の最上位にあります。ほかのどの設定レベルも、コマンドライン引数を含めて上書きできません。例外は、管理設定の優先順位に対するセキュリティ上の少数のものだけです。

• 管理層の中では、既定で、ポリシーキーを 1 つ以上届ける最初の取得元を使う。サーバー管理設定を先に、エンドポイント管理設定を次に調べる（例外のキーは次の節）
• 選ばれた取得元が、policyHelper が管理設定を供給する MDM ポリシーか管理設定ファイルなら、ヘルパーの出力が、その実行の唯一の管理設定として、その取得元に代わる。サーバー管理設定がポリシーキーを届けているあいだ、Claude Code は MDM やファイルの設定の policyHelper を参照しない
• あとの取得でサーバー管理設定が外れたと分かったら、Claude Code は次の起動を待たずに、すぐそのヘルパーを動かす
• コンソールでサーバー管理の構成を消して、エンドポイント管理の plist やレジストリのポリシーへ戻すつもりなら、キャッシュされた設定が、次に取得が成功するまでクライアントに残ること、model のような次の起動でしか適用されないキーが、各クライアントが再起動するまで有効なままであることに注意する。どの管理の取得元が有効かは /status で見る

全管理の取得元をまたぐキーごとの例外#

次のキーは、統合しない規則の例外です。

• 取得元をまたぐロックのキー：サンドボックスの許可リストのロックなど、少数のキー（管理設定のページに一覧）。管理者が制御するどの管理の取得元が設定しても、Claude Code はそれを尊重する。ユーザーが書き込める HKCU のレジストリ層は含まれない。policyHelper が管理設定を供給するときは、その出力がこれらの確認が読む唯一の取得元（起動時に管理者取得元から直接読む forceRemoteSettingsRefresh を除く）
• env ブロック：下の 2 つ（テレメトリの単位と、資格情報キーと組になる経路の変数）を除き、管理者が制御する取得元をまたいでキーごとに統合する。各環境変数は、それを定義する最も優先度の高い取得元が勝ち、下位の管理者取得元が、上位が未設定の変数を埋める。したがって、サーバー管理の構成がその変数を未設定のあいだ、または、その変数のキャッシュされたサーバーの値が、サーバーの確認待ちで保留されているあいだは、エンドポイント管理の env のエントリが適用される。v2.1.223 以降（それより前は、選んだ取得元の env ブロック全体だけを適用する）
  • テレメトリの単位：OTEL_EXPORTER_OTLP_* のエクスポーターのキー・OTEL_LOG_* の内容取得のトグル・OTEL_LOGS_EXPORTER・ベータトレースの変数 ENABLE_BETA_TRACING_DETAILED と BETA_TRACING_ENDPOINT は、いずれかを設定する最上位の取得元に、ひとまとまりで従う。otelHeadersHelper の資格情報キーを届ける取得元もこの単位を主張するが、選ばれた取得元のときだけこれらの変数が反映される。選ばれていないが、そのキーを届ける取得元は、これらの変数を 1 つも寄与せず、それでも下位の取得元がそれらを埋めるのを防ぐ。どちらにせよ、ある取得元のエクスポーターのエンドポイントが、別の取得元の資格情報と組になることはない
  • 資格情報と組になる経路：apiKeyHelper や otelHeadersHelper のような、選ばれた取得元だけの資格情報キーと経路の変数を組にする取得元は、その枠を勝ち取ったときだけ、それらの経路の変数を寄与する
• allowedProviders：マシンに設定したリストとサーバー管理のリストは、そのエントリの Scope の注記のとおりに組み合わさる。v2.1.285 以降
• ゲートウェイのサインインのキー：Claude Code は、forceLoginGatewayUrl・gatewayInternalNetworks・forceLoginMethod の "gateway" の値を、サーバー管理設定からは読まないので、そこにある値は、MDM ポリシーや管理設定ファイルで設定した値を適用も隠しもしない

取得とキャッシュの動作#

Claude Code は、起動時に Anthropic のサーバーから設定を取得し、アクティブなセッション中は 1 時間ごとに更新をポーリングします。Claude apps gateway でサインインしたクライアントは、設定をゲートウェイから取得し、セッションが始まる前にその取得を待つので、以下の取得の話は当てはまりません（失敗時の動作は後の「フェイルクローズの起動を強制する」）。

キャッシュされた設定が無い最初の起動

• 開発者が起動時にサインインするとき（初回の実行や /logout のあと）、Claude Code は、セッションを開く前に最大 5 秒、取得を待つ。ポリシーが間に合えば、最初の画面から強制し、companyAnnouncements をそこに表示する。ペイロードにセキュリティ承認が要るときは、待つのをやめ、開発者が承認したあとでペイロードを適用する
• それ以外の起動と、5 秒の待ちが尽きたときは、取得が続くあいだにセッションを開くので、設定が読み込まれて制限が効くまで、短い空白がある
• 取得が失敗すると、Claude Code はサーバー管理設定なしで続け、対話セッションで、リモートのポリシーが適用されないと警告する。エンドポイント管理設定は引き続き適用される。管理の取得元が forceRemoteSettingsRefresh を設定していれば、Claude Code は代わりに終了する

キャッシュされた設定がある以降の起動

• キャッシュされた設定は起動時にすぐ適用される。ただし、キャッシュされた modelPricing と managedMcpServers の値、およびサーバーがペイロードを確認するまで Claude Code が保留する環境変数を除く
• キャッシュされた modelPricing は、セッションの取得がペイロードを確認するまで適用されない。それまで、開発者が /usage とステータスラインで見るコストの数値は定価（コストを抑える）
• キャッシュされた managedMcpServers ブロックは、セッションの取得がペイロードを確認するまで適用されない。Claude Code は MCP サーバーへ接続する前に、その取得を最大 30 秒待つ。取得が失敗するかタイムアウトすると、セッションは組織のサーバーなしで始まり、/status がそう示し、あとの取得が確認した時点で接続する（v2.1.259 以降）
• Claude Code は、バックグラウンドで新しい設定を取得する
• キャッシュされた設定は、ネットワーク障害をまたいで残る。起動時の取得が失敗すると、Claude Code は対話セッションで、キャッシュされたポリシーが有効だと警告する
• 取得が成功するまで、起動時に保留した値は保留のまま

Claude Code は、サーバーがセッションのペイロードを確認するまで、キャッシュされた env ブロックのいくつかの変数の種類を保留します。キャッシュされたプロキシ・認証局・エンドポイント・資格情報の値が、ペイロードを確認する設定取得そのものを、リダイレクト・傍受・再認証しないようにするためです。この強化はサーバー取得の設定のキャッシュだけに適用され、MDM や managed-settings.json で配るエンドポイント管理設定には影響しません。保留は v2.1.198 以降です（それより前は、キャッシュされた env ブロック全体が起動時に適用された）。保留される種類は次のとおりです。

• プロキシと 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 など
• 設定ディレクトリの選択 CLAUDE_CONFIG_DIR
• 資格情報の取得元と設定ディレクトリの選択（v2.1.223 以降）：ANTHROPIC_FEDERATION_RULE_ID や ANTHROPIC_IDENTITY_TOKEN のような Workload Identity Federation の変数・プロファイルと設定ディレクトリの選択 ANTHROPIC_PROFILE と ANTHROPIC_CONFIG_DIR・OS のディレクトリ変数 HOME・XDG_CONFIG_HOME・APPDATA・USERPROFILE

Claude Code は、Workload Identity Federation の変数と ANTHROPIC_PROFILE・ANTHROPIC_CONFIG_DIR の選択を起動時にだけ読むので、サーバーが配った値は、取得が成功してもセッションの資格情報の取得元を切り替えません。v2.1.223 以降でそれらの選択を配るには、MDM や managed-settings.json のようなエンドポイント管理設定を使います。CLAUDE_CONFIG_DIR と OS のディレクトリ変数は、保留自体が保護で、キャッシュされた値は、サーバーがペイロードを確認するまで環境に入りません。キャッシュされた env ブロックのほかのすべてのキーは、起動時に適用されます。サーバーがペイロードを確認し、セキュリティ承認が要るならあなたが承認すると、保留された変数がセッションの残りの間、適用されます。

組織が api.anthropic.com に届くのにプロキシを要する場合、保留はサーバーが配る env ブロック自体にだけ影響します。MDM や managed-settings.json のエンドポイント管理の env ブロック・シェルの環境・ユーザー設定に設定したプロキシは、設定取得に届きます。エンドポイント管理の取得元は v2.1.223 以降が要り、キャッシュされたサーバー管理のプロキシの値は取得が確認するまで保留され、エンドポイント管理の値がキーごとに埋まって取得自体に届きます。v2.1.223 より前は、キャッシュされたサーバーのペイロードと並べてプロキシを適用するために、シェルの環境かユーザー設定を使います。最初の起動にはキャッシュが無いので、最初の取得には、エンドポイント管理の取得元・シェルの環境・ユーザー設定が引き続き要ります。

Claude Code は、ほとんどの設定の更新を、再起動なしに動作中のセッションへ適用します。一部の更新は、次の起動でだけ適用されます：OpenTelemetry のエクスポーターの設定・model キー・env ブロックからの変数の削除などです。

配信された設定の無効なエントリ#

ペイロードの一部がスキーマ検証に失敗すると、Claude Code は検証エラーを示し、残りの有効な設定をすべて適用します（捨てるものと、より厳しい値へフォールバックするキーは前の「Claude Code が捨てたエントリを見つける」。v2.1.169 以降）。サーバー管理の配信は、次の動作を加えます。

• ~/.claude/remote-settings.json のキャッシュで動く起動は、キャッシュを書いた取得と同じように無効なエントリを扱う

  • 検証に失敗したエントリは捨てられたまま
  • フェイルクローズするキーは、より厳しい値を保つ
  • 無効な cleanupPeriodDays か desktopSessionCleanupPeriodDays の値はキャッシュされたコピーに残り、適用されない

• 次の 3 つがすべて当てはまると、Claude Code はペイロードから何も適用せず、キャッシュを変えない

  • ペイロードのすべての設定が検証に失敗する
  • どれもより厳しい値へフォールバックしない
  • ペイロードに、その 2 つの保持のキー以外のキーがある

  このとき、起動時の通知・/status・claude doctor が、no setting in the server response could be applied as written という原因つきで読み込みの失敗を報告し、そのエントリが、セッションがどのポリシーで動くかを示す。フェイルクローズの起動を強制するクライアントは、代わりに起動時に終了する

• セキュリティ承認ダイアログは、救済したペイロードを評価するので、取り除かれた無効なエントリは承認に出されず、実行もされない

フェイルクローズの起動を強制する#

既定では、起動時にリモート設定の取得が失敗すると、CLI は最後に成功した取得のキャッシュされた設定で続けます（取得が成功するまで保留する値を除く）。一度も取得したことがないマシンでは、サーバー管理設定なしで続け、デバイスのエンドポイント管理設定は引き続き適用します。クライアントがキャッシュされた、または無いサーバー管理設定で起動するのを止めるには、管理設定で forceRemoteSettingsRefresh: true を設定します。

{
  "forceRemoteSettingsRefresh": true
}

• この設定が有効で、サーバー管理設定を取得するセッションでは、CLI はリモート設定を新しく取得するまで起動でブロックする。取得が失敗したら、ポリシーなしで進まず、CLI は終了する
• この設定は自己永続的：サーバーから一度配られると、ローカルにもキャッシュされ、新しいセッションの最初の取得成功より前でも、以降の起動が同じ動作を強制する。サーバー管理設定を取得しないセッションは、待たずに始まる
• MDM のプロファイルかシステムの managed-settings.json にも設定でき、サーバーのペイロードが届く前の最初の起動でフェイルクローズを強制できる。このフラグは前の優先順位の規則の例外：管理者が制御するどの管理の取得元が設定しても Claude Code は尊重し、キャッシュされたサーバー管理のペイロードがあっても、MDM が配った値を無視しない
• policyHelper が管理設定を供給するときは、起動後に読むキーについて、その出力がほかのすべての管理の取得元に代わる。取得設定の取得は Cache-Control: no-cache ヘッダーも送り、中間の HTTP プロキシが古い応答を返さないようにする
• 有効にする前に、ネットワークのポリシーが api.anthropic.com への接続を許可しているか確認する。そのエンドポイントに届かないと、CLI は起動時に終了し、ユーザーは Claude Code を起動できない
• claude auth login などの claude auth サブコマンドは、この確認とゲートウェイの起動時の終了から除外され、期限切れの資格情報が設定取得の失敗の理由のとき、ユーザーが再認証できる

Claude apps gateway でサインインしたクライアントは、この設定の有無にかかわらず起動時の取得を待ち、取得の失敗を次のように扱います。

• ゲートウェイが、有人の対話の起動に 401 で答え、この設定がオフなら、ゲートウェイがそのサインインを終了している。Claude Code は Cloud gateway session expired — run /login to reconnect. と出力し、ユーザーが /login を実行するまで、ゲートウェイからサインアウトした状態でセッションを開く
• それ以外の失敗、または claude auth サブコマンド以外のほかの種類の起動では、クライアントはエラーで終了する

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

セキュリティリスクになりうる一部の設定は、対話セッションで Claude Code が適用する前に、ユーザーの明示的な承認が要ります。

• シェルコマンドの設定：apiKeyHelper・statusLine・otelHeadersHelper など、シェルコマンドを実行する設定
• サンドボックスのバイナリの設定：sandbox.bwrapPath・sandbox.socatPath・sandbox.ripgrep。どれも実行ファイルを指し、Claude Code がそれを実行する
• サンドボックスのネットワークと隔離の設定：サンドボックスのプロキシが通信を読む・振り向ける・認証する、またはサンドボックスの隔離を弱める設定：sandbox.network.tlsTerminate・sandbox.network.httpProxyPort・sandbox.network.socksProxyPort・sandbox.credentials・sandbox.allowAppleEvents・sandbox.enableWeakerNestedSandbox・sandbox.enableWeakerNetworkIsolation・sandbox.filesystem.disabled・sandbox.network.allowAllUnixSockets・sandbox.network.allowUnixSockets・sandbox.network.allowMachLookup。deny ルールだけを持つ sandbox.credentials ブロックは、プロキシに資格情報を与えずサンドボックスを制限するので承認が要らない。v2.1.251 より前は、これらの設定を承認なしに適用していた
• カスタムの環境変数：プロキシやベース URL の変数など、ユーザーの承認が要る、配信された env 変数
• フックの設定：あらゆるフックの定義

これらの設定があると、ユーザーには、何が設定されるかを説明するセキュリティのダイアログが出て、続けるには承認が必要です。ユーザーが拒否すると、Claude Code は終了します。claudeMd キーで配る管理の CLAUDE.md は、Claude Code が実行するコマンドではなく Claude への指示テキストなので、承認が要りません（v2.1.260 より前は claudeMd の値も承認が要った）。

承認の記憶#

Claude Code は、承認を設定ディレクトリ（CLAUDE_CONFIG_DIR を設定しない限り ~/.claude）に記録します。記録される内容は、設定取得に使う資格情報で決まります。

• sandbox.credentials か sandbox.network.tlsTerminate の承認は、同じ配信された設定の sandbox.network.allowedDomains のエントリもカバーします（どちらの設定もその許可リストに作用するため）。管理者がそれらのエントリを足すか外すと、sandbox.network.allowedDomains 自体は承認が要らなくても、ダイアログが再び出ます
• 保存した claude.ai のログインでは、サインアウトして入り直す、または別の組織へ切り替えて後で戻っても、その設定が変わらない限りダイアログは再び出ません（同じ設定ディレクトリで、別のアカウントがその間にその組織について承認した場合を除く）。同じ組織に別のアカウントでサインインすると、設定が変わらなくてもダイアログが再び出ます。そのアカウントの承認が前のものを置き換えるので、戻るとまた出ます

Claude Code がダイアログを出せない場合があります。

環境変数と承認ダイアログ#

Claude Code は、配信された一部の env 変数を、承認ダイアログをユーザーに見せずに適用します。

• 機能とコマンドのトグル
• ANTHROPIC_MODEL・DISABLE_PROMPT_CACHING・CLAUDE_CODE_EFFORT_LEVEL などのモデルの選択と挙動の設定
• DISABLE_AUTO_COMPACT などのコンテキストウィンドウと圧縮の設定
• ターミナル UI とアクセシビリティのオプション
• 数値の上限・予算・タイムアウト

ほかの配信された変数は、効く前にユーザーの承認が要ることがあります。空でないプロキシ・ベース URL・OTEL_EXPORTER_OTLP_ENDPOINT の値は常に要ります。配信された変数が承認を要するとき、ダイアログがそれを名指しするので、ユーザーはポリシーが何を設定しようとしているかを正確に見られます。v2.1.218 より前は、ユーザーに確認せず適用する変数が少なく、DISABLE_AUTO_COMPACT のような設定も、空でない任意の値でダイアログを出していました。

• 4 つのプライバシーのトグル（CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC・DISABLE_ERROR_REPORTING・DISABLE_TELEMETRY・DO_NOT_TRACK）は、変数名ではなく配信された値で承認の要否が決まります。1 や true のような真と解される値は、追跡・報告・必須でない通信をオフにするだけなので、ユーザーに確認せず適用します。ほかの空でない値では、ダイアログを出します。v2.1.218 より前は、DO_NOT_TRACK 以外のすべてが、どの値でも承認なしに適用され、DO_NOT_TRACK は空でない任意の値でダイアログを出していました
• API_FORCE_IDLE_TIMEOUT も配信された値で決まります。真と解される値は、本文のアイドルタイムアウトをオンにするだけなので、確認せず適用し、ほかの空でない値ではダイアログを出します。v2.1.248 より前は、空でない任意の値でダイアログを出していました
• ANTHROPIC_CUSTOM_HEADERS も配信された値で決まります。Accept-Language のようにリクエストにタグを付けるだけのヘッダーは、ダイアログなしで適用されます。資格情報・組織やテナントの選択・経路やホストの上書き・API の挙動のヘッダー（Authorization・X-Api-Key・Host・anthropic-beta・X-Amzn-Bedrock-* ヘッダーなど）を名指しする行は承認が要ります。名前が有効な HTTP ヘッダーのトークンでない、または値に HTTP ヘッダーが運べない文字がある行も要ります。この確認はヘッダー名の中の語に一致するので、client と version を含む X-Client-Version も承認が要ります。v2.1.251 より前は、ANTHROPIC_CUSTOM_HEADERS のどの値も承認なしに適用されていました
• ENABLE_BETA_TRACING_DETAILED と OTEL_LOG_RAW_API_BODIES の 0 や false のような偽と解される値は、詳細トレースか生の API 本文の取得をオフにするだけなので、ダイアログなしで適用されます。どちらの変数も、ほかの空でない値は承認が要ります

サーバー管理設定が届く場所#

サーバー管理設定は、api.anthropic.com への直接の接続が要ります。配信には、セッションが次のどれかの資格情報で認証していることも要ります。

• Team か Enterprise の OAuth ログイン
• CLAUDE_CODE_OAUTH_TOKEN で渡した OAuth トークン
• 直接設定した API キー
• user_oauth の Anthropic プロファイル。プロファイルが Anthropic の API 以外の base_url を設定している場合を除く。v2.1.257 以降

apiKeyHelper スクリプトが返すキーも、Workload Identity Federation の資格情報も、設定の取得を起こしません。

• Claude Desktop アプリの Cowork のセッションでは、ユーザーが Team か Enterprise のアカウントでサインインしても、Claude Code は claude.ai の管理コンソールからサーバー管理設定を取得しません。claude.ai は、Cowork のユーザーが、claude.ai の git リポジトリか Cowork タブの「Customize」からマーケットプレイスを足すとき、strictKnownMarketplaces と blockedMarketplaces のリストを自分で適用します
• シェルで CLAUDE_CODE_USE_* のプロバイダー変数か、既定でない ANTHROPIC_BASE_URL を export していると、Claude Code はそのセッションで設定の取得を飛ばします。claude doctor と /status が、飛ばした取得とその原因を報告します
• サーバー管理の env ブロックでその export を消すことはできません（ブロックは、その export が妨げる取得で届くため）。エンドポイント管理設定の env ブロックも取得を復活させません（Claude Code は管理の env ブロックを適用する前に適格性を確認するので、エンドポイント管理の値はセッションのプロバイダーの選択を変えるが、取得は飛ばされたまま）
• サーバー管理の配信を戻すには、シェルから export を取り除くか、適格性の確認の前に適用される、ユーザー設定の env ブロックで、その変数を "" にします。ユーザーにシェルを変えさせずにポリシーを強制するには、代わりにエンドポイント管理の経路で配ります
• Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Claude Platform on AWS の導入では、セルフホストの Claude apps gateway が同等のリモート管理設定の配信を提供します。ゲートウェイでサインインしたクライアントは、api.anthropic.com ではなくゲートウェイから管理設定を取得します。起動時の失敗の扱いは違い、ゲートウェイに届かないゲートウェイのクライアントは、キャッシュされた設定へフォールバックせずエラーで終了し、1 時間ごとのバックグラウンド更新は、どちらの経路でもフェイルオープンです

監査ログ#

設定の変更の監査ログのイベントは、コンプライアンス API か監査ログのエクスポートで使えます。アクセスは Anthropic の担当チームに連絡します。監査イベントは、行った操作の種類・操作したアカウントとデバイス・前と新しい値への参照を含みます。

セキュリティ上の考慮#

サーバー管理設定は、ポリシーを一元的に強制しますが、セキュリティの境界ではなく、クライアント側の制御として動きます。管理されていないデバイスでは、ユーザーは管理者権限も sudo も要らずにそれを回避できます。

• managed-settings.json を含むローカルの設定ファイルの編集を記録するには、ConfigChange フックを使います（フックのリファレンス）。Claude Code は、サーバー管理設定が届いたり更新されたりしたとき、MDM プロファイルやレジストリポリシーが変わったときにはそれらを動かさず、フックは policy_settings の変更をブロックできません
• クライアントが与える資格情報でユーザーが入れる組織を制限するには、Claude Help Center の Tenant Restrictions によるネットワークレベルのアクセス制御を参照します。より強い強制の保証には、MDM に登録されたデバイスのエンドポイント管理設定を使います

MCP サーバーの制御#

既定では、Claude Code を使う人は誰でも好きな MCP サーバーにつなげます。Anthropic はコネクターを、Anthropic Directory に載せる前に掲載基準で審査しますが、MCP サーバーのセキュリティ監査も管理もしません。管理者は、組織で動かせるサーバーを、承認済みの固定の組を配るところから MCP の完全な無効化まで制限でき、全ユーザーにサーバーを提供することもできます。

これらの制限は、Claude Code が自分で読み込むサーバー（claude.ai から取得するコネクターを含む）が対象です。デスクトップアプリがローカルと SSH のセッションへ渡すコネクターはプロセス内で届き、claude.ai の組織設定で管理します（どの制御がどの種類のセッション（クラウドセッションを含む）のコネクターに適用されるかは、MCP サーバーをつなぐの「How connectors reach Claude Code」）。MCP の脅威モデルと、承認前のサーバーの評価は、セキュリティとデータの扱いにあります。

パターンを選ぶ#

制限のレベルは幅広く、各パターンは、固定の組を配る managed-mcp.json・ユーザーが追加したものに加えてサーバーを提供する managedMcpServers・ユーザーの設定を絞る allowedMcpServers／deniedMcpServers の 1 つ以上を使います。

managed-mcp.json による排他的な制御#

managed-mcp.json を配ると、Claude Code は次の MCP サーバーだけを読み込みます。

• ファイルが定義するサーバー
• managedMcpServers で提供するサーバー
• セッションを始めたアプリが登録するプロセス内のサーバー（VS Code 拡張自身のサーバーや、デスクトップアプリが配るコネクターなど）
• 管理された組と並べて許可した場合の、組み込みの Claude in Chrome サーバー

ユーザーは、プラグインが提供するサーバーや --mcp-config CLI フラグで渡したサーバーを含め、ほかの MCP サーバーを追加・変更・使用できません。ファイルは、管理された組と並べて許可しない限り、Claude Code が自分で取得する claude.ai のコネクターも抑止します。

managed-mcp.json を配る#

managed-mcp.json は単独のファイルなので、サーバー管理設定では配れません。排他的な制御なしに管理設定でサーバーを配るには、managedMcpServers を使います。管理者権限でシステムパスに書き込めるプロセスなら、ファイルを配れます。フリートでは通常、macOS の Jamf や構成プロファイル・Windows のグループポリシーや Intune・Linux の任意のフリート管理など、デバイス管理のツールを使います。Claude Code は、次のパスのどれかでファイルを探します。

ファイルは、プロジェクトの .mcp.json と同じ形式です。

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    },
    "company-internal": {
      "type": "stdio",
      "command": "/usr/local/bin/company-mcp-server",
      "args": ["--config", "/etc/company/mcp-config.json"],
      "env": {
        "COMPANY_API_URL": "https://internal.example.com"
      }
    }
  }
}

ユーザーごとの資格情報で認証する#

マシンのどのユーザーもこのファイルを読めるので、env ブロックに API キーなどの資格情報を保存してはいけません。ユーザーごとの資格情報は、次のどれかで渡します。

• ${VAR} の展開で、各ユーザーの環境からシークレットを読む
• OAuth かユーザーごとのヘッダーで、各ユーザーが自分として認証する
• headersHelper で、接続時に資格情報を生成する

--mcp-config や --strict-mcp-config で渡したサーバー#

Claude Code が読めて解析できる managed-mcp.json が配られているセッションが、--mcp-config でサーバーを受け取ると、ユーザーに見えるものは、ワークステーションとクラウドセッションで違います。

• ワークステーション：Claude Code は起動時に You cannot dynamically configure MCP servers when an enterprise MCP config is present で終了する
• ファイルを配ったホスト（セルフホストのランナーなど）のクラウドセッション：Claude Code は管理されたサーバーだけで始まり、claude.ai のコネクターと、クラウドホストが --mcp-config で届けるほかのサーバーを飛ばす。セッション内では、どのサーバーが外れたかユーザーに伝わらない。Claude Code は stderr の警告でそれらを挙げ、セルフホストのランナーは debug ログレベルで記録する

--strict-mcp-config フラグは、管理された組を置き換えるよう求めます。そのようなファイルが配られているときにユーザーがこれを渡すと、Claude Code は、ワークステーションでもクラウドセッションでも起動時に終了します。

許可リストと拒否リストが管理された組に適用される仕方#

拒否リストは、managed-mcp.json のサーバーをさらに絞れます。

• deniedMcpServers は管理されたサーバーにも適用されるので、エントリに一致する管理されたサーバーは読み込まれない
• ユーザー自身の deniedMcpServers が自分の設定から統合されるので、ユーザーは管理されたサーバーを自分用にブロックできる

allowedMcpServers は、managed-mcp.json のサーバーには適用されません。例外は 1 つ：定義が ${VAR} 展開を使うサーバーは、有効な構成がファイルだけでなく各ユーザーの環境から来るので、Claude Code は引き続き許可リストと照合します。v2.1.259 より前は、許可リストがあるあいだ、すべての管理されたサーバーが通過する必要がありました。

設定を検証する#

ファイルが有効かを確かめるには、管理されたマシンで 2 つの確認をします。

1. claude mcp list が、managed-mcp.json のサーバーと、managedMcpServers で提供するものだけを表示する。ほかの結果は、何かが誤っていることを意味する
   • ユーザー自身のサーバーがまだ出るなら、Claude Code がファイルを読んでいないので、パスと親ディレクトリの権限を確認する
   • ファイルのサーバーが出ず、「MCP config diagnostics」の節が企業の構成の解析失敗を示すなら、Claude Code がファイルを読めないか解析できない。その節が名指しするエラーを直し、ユーザーに Claude Code を再起動してもらう
2. claude mcp add --transport http test https://example.com/mcp が Cannot add MCP server: enterprise MCP configuration is active and has exclusive control over MCP servers で失敗する。ポリシーの確認が、何かに接続する前にコマンドを拒否するので、URL は実在するサーバーである必要がない

MCP を完全に無効にする#

空のサーバーのマップを持つ managed-mcp.json を配ると、排他的な制御のもとで読み込まれるものを除き、すべての MCP サーバーをブロックします。

{
  "mcpServers": {}
}

claude mcp add は上の企業ポリシーのエラーで失敗します。ユーザーが以前に設定したサーバーは、次にセッションを始めたときから読み込まれなくなり、ポリシーが理由だという警告は出ません。managedMcpServers で提供するサーバーと、管理された組と並べて許可したほかのものは、空のマップでも読み込まれ続けるので、MCP を完全にオフにするにはそれらのキーを未設定にします。

管理された組と並べて claude.ai のコネクターを許可する#

既定では、managed-mcp.json を配ると、Claude Code が自分で取得する claude.ai のコネクター（管理者が claude.ai の管理コンソールで組織向けに設定したコネクターを含む）が抑止されます。それらのコネクターを managed-mcp.json のサーバーと並べて読み込むには、管理設定の取得元で "allowAllClaudeAiMcps": true を設定します。

• 有効にすると、Claude Code は、managed-mcp.json が配られていなければ読み込むはずの claude.ai のコネクターを、同じように読み込む。許可リストと拒否リストは引き続きそれらに適用されるので、deniedMcpServers で特定のものをブロックできる。この設定が影響するのは、Claude Code が自分で取得する claude.ai のコネクターだけで、プラグインが提供するサーバーは抑止されたまま
• クラウドセッションと、デスクトップアプリのローカルと SSH のセッションは、別の方法でコネクターを受け取る。クラウドセッションを動かすホスト（セルフホストのランナーのホストなど）の managed-mcp.json は、allowAllClaudeAiMcps の設定にかかわらず、そのセッションのコネクターを抑止する。デスクトップアプリがローカルと SSH のセッションへ渡すコネクターには、どの managed-mcp.json も届かない
• Claude Code は allowAllClaudeAiMcps を、管理者が制御するポリシー層（サーバー管理設定・MDM で配った plist か HKLM のレジストリキー・システムの managed-settings.json）からだけ読む。ユーザーやプロジェクトの設定に置いても効果がなく、排他的な制御が抑止したコネクターを、ユーザーが再び有効にすることはできない

管理された組と並べて Claude in Chrome を許可する#

既定では、managed-mcp.json を配ると、Claude Code はターミナルセッションで、組み込みの Claude in Chrome サーバーをブロックします。ユーザーには拡張機能のインストールを促す表示が出ず、ユーザーが Chrome を既定でオンにしているセッションは、警告なしに Chrome なしで始まります。本来 Claude in Chrome を使えるユーザーが claude --chrome で起動すると、Claude Code は、allowClaudeInChromeWithManagedMcp 設定を名指しするエラーを出して起動時に終了します。

• managed-mcp.json のサーバーと並べて Claude in Chrome を使わせるには、デバイス自身の管理設定で "allowClaudeInChromeWithManagedMcp": true を設定する。MDM で配った plist・HKLM のレジストリキー・システムの managed-settings.json のうち、そのデバイスで Claude Code が選ぶものに置く。v2.1.282 以降
• Claude Code は、サーバー管理設定がポリシーの残りを配っていても、これらのデバイスの取得元だけから設定を読む。claude-in-chrome の deniedMcpServers のエントリは、設定がオンでもサーバーをブロックする

管理設定でサーバーを提供する#

MCP の排他的な制御を取らずに、全ユーザーにリモート MCP サーバーの組を渡すには、管理設定の取得元（サーバー管理設定・Claude apps gateway のポリシー・MDM のプロファイルかレジストリのポリシー・managed-settings.json）の managedMcpServers に挙げます。ユーザーは自分で追加したサーバーを保ち、あなたのものを追加で受け取ります。v2.1.259 以降で、それより前のクライアントはこのキーを無視します。

値は、サーバー名をキーにしたオブジェクトです。各エントリは、プロジェクトの .mcp.json の HTTP か SSE サーバーと同じ形で、任意の headers と oauth のメンバーを含みます。次の例は、各ユーザーが OAuth でサインインする検索サーバーと、組織が発行するヘッダーを送る記録サーバーを提供します。

{
  "managedMcpServers": {
    "search": {
      "type": "http",
      "url": "https://search.example.com/mcp"
    },
    "records": {
      "type": "http",
      "url": "https://records.example.com/mcp",
      "headers": {
        "X-Records-Key": "key-issued-for-all-claude-code-users"
      }
    }
  }
}

エントリに入れられるもの#

Claude Code は、次の確認をすべて通ったエントリだけを読み込みます。1 つでも失敗したエントリは捨て、/status で読める通知を記録し、ほかのエントリは読み込みます。

• type が http か sse。.mcp.json と同様に streamable-http は http の別名として受け付けられる
• url が https:// の URL。プレーンな http:// の URL は（localhost を指すものも）拒否される
• エントリに command・args・env・headersHelper のメンバーが無い（管理設定のドキュメントが、ユーザーのマシンで動かすプログラムを指名しないようにするため）
• どの値にも ${VAR} の参照が無い。Claude Code はこれらのエントリで環境変数を展開しないので、リテラルの値を書く
• サーバー名は英字・数字・ハイフン・アンダースコアだけで、どのキーも値も、制御文字や不可視の書式文字を含まない

Claude Desktop には同名の管理設定があり、その値は別のエントリの形の配列なので、一方をもう一方へ写さないでください。Claude Code は配列の形を受け付けず、読み込まずに通知を記録します。Claude apps gateway は、起動時に同じ確認を行います。

提供されたサーバーの読み込み#

提供されたサーバーが、別のサーバー定義やこのページの別の設定と重なるとき、何が読み込まれるかの規則です。

• 提供されたサーバーは、ローカル・プロジェクト・ユーザーのスコープの同名のサーバーや、同じ URL を指すプラグインのサーバーや claude.ai のコネクターより優先される
• managed-mcp.json も配っている場合、Claude Code はそのサーバーと提供されたサーバーを一緒に読み込み、両方が同じ名前を定義するときはファイルのエントリが優先される
• 提供されたサーバーは、strictPluginOnlyCustomization が mcp のサーフェスをロックしても読み込まれ続ける
• deniedMcpServers は、ユーザー自身の設定のエントリを含め、提供されたサーバーに適用されるので、ユーザーは自分用に 1 つをブロックできる。提供されたサーバーには allowedMcpServers のエントリが要らない

managed-mcp.json を配っていない場合、実行ごとのフラグは本来の意味を保ちます。

• ユーザーが --mcp-config で同じ名前で渡したサーバーは、その実行では提供されたものを置き換え、allowedMcpServers と照合される
• --strict-mcp-config は、ほかの設定済みのサーバーと並べて、提供されたサーバーも除外する

managed-mcp.json が配られていると、両方のフラグは上の排他的な制御の節の説明どおりに動きます。

ユーザーに見えるものと変えられるもの#

ユーザーは、提供されたサーバーを編集も削除もできません。

• claude mcp remove は、そのサーバーが組織から提供されていると報告する
• managed-mcp.json を配っていないとき、ユーザーが同じ名前で追加したエントリは保存されるが、あなたのものがあるあいだは使われない
• ユーザーは、提供されたサーバーを /mcp で自分用にオフにはできる（/mcp は提供されたサーバーを「Managed MCPs」の下に挙げる）

claude mcp get と /mcp は、提供されたサーバーの URL をホストだけ（例：https://mcp.example.com/…）で示し、claude mcp get はヘッダーの名前を値なしで示します。

managedMcpServers が適用される場所#

Claude Code は managedMcpServers を、管理の取得元の統合で選ぶ管理の取得元から読みます。その取得元が managedSourcesBehavior を "merge" にしているときは、代わりにすべての管理者取得元からサーバーを提供し、2 つの取得元が同じ名前を定義すると、優先度の高い取得元のエントリがまるごと適用されます。ユーザーが書き込める HKCU のレジストリ、埋め込みホストが供給する親設定、ユーザー・プロジェクト・ローカルの設定ファイルからは決して読まず、そこでは警告つきでキーを捨てます。

サードパーティの導入での Claude Desktop アプリの Code タブと、アプリの Cowork のセッションでは、Claude Desktop がそれらのセッションの MCP サーバーを自分で供給してロックするので、Claude Code はこのキーを読みません。管理設定がそこでこのキーを持つとき、/status と claude doctor がそう示します。

提供されたサーバーが接続するとき#

managedMcpServers がサーバー管理設定で届くとき、そのタイミングは取得とキャッシュの動作に従います。

• キャッシュされた設定のあるマシン：Claude Code は、サーバーがセッションの設定を確認するまでこのキーのキャッシュされたコピーを保留し、MCP サーバーを読み込む前にその確認を待つ。確認が失敗すると、セッションは提供されたサーバーなしで続き、/status が保留されていると示す
• マシンの最初の起動（まだキャッシュが無い）：設定が届く前に始まった対話セッションは、届いた時点で提供されたサーバーに接続する。すでに始まった claude -p の実行は、それらなしで終わることがある
• ゲートウェイでのサインインでは、Claude Code はセッションが始まる前にポリシーを読み込むので、どちらの場合も提供されたサーバーを遅らせも飛ばしもしない

すでに動いている対話セッションは、キーへの編集を次のように適用します。

• サーバーを追加：更新された設定が届いたとき、再起動なしで接続する
• サーバーのエントリを変更：それらのセッションは、新しい定義で再接続する
• サーバーを削除：動いている対話セッションは、変更された設定を読んだ時点で切断する。非対話（-p）の実行は終わるまで保つ

許可リストと拒否リストによる、ポリシーベースの制御#

許可リストと拒否リストは、設定されたサーバーのどれが読み込まれてよいかを絞ります。レジストリではありません：どちらのリストが適用される前にも、ユーザー・プラグイン・組織がサーバーを追加している必要があります。

• 組織が managedMcpServers で配るサーバーは、許可リストのエントリなしで読み込まれる（managed-mcp.json のサーバーは評価の節）。拒否リストは、プロセス内の type: "sdk" のエントリを除き、出どころにかかわらずすべてのサーバーに適用される
• ユーザーにサーバーを配るには、managed-mcp.json か managedMcpServers を使う。どちらのリストも、プロセス内の type: "sdk" のエントリを除き、ユーザーが --mcp-config CLI フラグで渡すサーバーも絞る。--strict-mcp-config は、読み込む設定ファイルを限るだけで、どちらのリストも迂回しない
• 許可リストを決定的にするには、管理設定の取得元（サーバー管理設定や配った managed-settings.json ファイルなど）で allowedMcpServers と allowManagedMcpServersOnly: true を一緒に設定する
• ロックは、管理者が制御するすべての管理の取得元から適用されるので、MCP に触れないサーバー管理設定も使っているときでも、配ったファイルのロックダウンは適用される。ロックがオンのあいだ、管理の許可リストは、それを設定する最も優先度の高い管理者取得元から来る。ロックと許可リストを取得元をまたいで読むのは v2.1.273 以降
• allowManagedMcpServersOnly がなければ、すべての設定スコープの許可リストが統合され、ユーザー自身の ~/.claude/settings.json も含むので、ユーザーはあなたの許可リストが許すものを広げられる。拒否リストは、どのスコープでも常に統合される

URL・コマンド・名前でサーバーを照合する#

allowedMcpServers と deniedMcpServers はエントリのリストです。各エントリは、サーバーを URL・コマンド・名前で識別する、キーが 1 つのオブジェクトです。

allowedMcpServers を未設定にするのと、空の配列にするのは違います。

エントリがスキーマ検証に失敗したときの動作は、前の「Claude Code が捨てたエントリを見つける」を見ます。

serverName の検証は、2 つのリストで違います。

• deniedMcpServers：serverName は、先頭と末尾に空白のない任意の空でない文字列を受け付けるので、claude.ai のコネクターを表示名でブロックできる。たとえば { "serverName": "claude.ai Slack" } は Slack のコネクターをブロックする。名前の変更に強い拒否が要るとき、またはコネクター名が衝突して (N) の接尾辞が付くときは、serverUrl のエントリを使う
• allowedMcpServers：serverName は英字・数字・ハイフン・アンダースコアに限られる。Claude Code が自分で取得する claude.ai のコネクターを許可リストに入れるには serverUrl を使う。クラウドホストがセルフホストのセッションに届けるコネクターには、セルフホスト環境の導入のドキュメントの「Connector traffic leaves your network」にあるエントリを使う

Claude Code が自分で取得する claude.ai のコネクターをすべてオフにするには、disableClaudeAiConnectors を使います。

サーバーの評価のされ方#

サーバー（managed-mcp.json のものを含む）を読み込む前に、Claude Code は次の 3 つの確認を順に行います。ユーザーが /mcp でサーバーを再接続するか、無効にしたものを再び有効にするときも、もう一度行います。セッションを始めたアプリが登録するプロセス内の type: "sdk" のサーバーは、3 つとも飛ばします。

1. リストを統合する：すべての設定スコープの許可リストと拒否リストのエントリが、1 つの許可リストと 1 つの拒否リストになる。allowManagedMcpServersOnly が true なら、管理の許可リストだけが残る。拒否リストは常にすべてのスコープから統合される。管理の取得元が複数あるときは、どれが管理スコープのリストを供給するかが管理設定の「全管理者取得元から読むキー」にある
2. 拒否リストを確認する：URL・コマンド・名前のどれかで、拒否リストのエントリに一致するサーバーはブロックされる。拒否リストの一致を上書きするものはない
3. 許可リストを確認する：allowedMcpServers がどこにも設定されていなければ、拒否リストを通ったすべてのサーバーが読み込まれる。設定されていれば、サーバーが一致すべきものは、種類で決まる（下の表）

許可リストの確認を飛ばす 3 つのグループがあります。

• 組織自身のサーバー：すべての managedMcpServers のエントリと、値が ${VAR} 展開を使わないすべての managed-mcp.json のエントリ
• Claude in Chrome・実行中の VS Code か JetBrains の IDE へ Claude Code がつなぐ ide サーバー・CLI 自身が設定するサーバーなどの組み込みサーバー
• Claude Tag のセッションの Slack のツール：スレッドを読み、返信を投稿するために使うサーバーは、許可リストのエントリなしで読み込まれる

コマンド・引数・env・URL・ヘッダーで ${VAR} 展開を使う managed-mcp.json のサーバーは、引き続き確認されます。ユーザー・プラグイン・claude.ai が追加するすべてのサーバーと、ユーザーが --mcp-config で渡すすべてのサーバーも同様です。

これらの確認の中の 3 つの照合規則です。

• コマンドは完全一致する：すべての引数が順番どおりに一致する。["npx", "-y", "server"] は ["npx", "server"] にも ["npx", "-y", "server", "--flag"] にも一致しない
• serverCommand と serverUrl の値は照合の前に展開される：ポリシーのエントリも、サーバーの設定値も、${VAR} と ${VAR:-default} の展開を通るので、["${HOME}/bin/server"] と書いたエントリは、同じ参照を使うか展開されたパスを使うサーバー設定に一致する。Windows では ${HOME} ではなく、そこで設定されている ${USERPROFILE} のような環境変数を参照する。serverName の値は文字どおりに照合され、展開されない。2 つの側は別の環境を読む（次の表）
• URL はパターンのどこにでも * のワイルドカードが使える（スキームを含む）。ホスト名の照合は大文字小文字を区別せず、末尾の FQDN のドットを無視するので、https://Mcp.Example.com/* は https://mcp.example.com/api に一致する。パスは大文字小文字を区別する

ポリシーのエントリの展開のされ方：サーバーの設定値は、.mcp.json のほかの部分と同じく、実行中のプロセスの環境から展開されます。ポリシーのエントリは、代わりに固定された環境から展開されるので、プロジェクトやユーザーの設定ファイルが設定した変数で、許可リストのエントリの意味が変わることはありません。ポリシーのエントリは、参照する変数について起動したシェルの値に依存するので、強制に頼るエントリにはリテラルの URL とコマンドを使います（v2.1.219 以降）。

設定の例#

次の設定は、拒否リスト付きの厳格な許可リストです。ハイライトの行は、リストの残りの評価を変えます。

{
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://mcp.sentry.dev/*" },
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] },
    { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] },
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverName": "dangerous-server" },
    { "serverCommand": ["npx", "-y", "unapproved-package"] },
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

• 最初の serverUrl のエントリ（許可リストの 1 行目）：1 つあると、すべてのリモートサーバーが URL パターンに一致する必要があるので、ユーザーが許可された名前を付けて、リストにないリモートサーバーを通すことはできない
• 最初の serverCommand のエントリ：stdio サーバーでも同じ効果で、すべてのローカルサーバーが、挙げたコマンドに完全に一致する必要がある
• 拒否リストの serverName のエントリ：拒否リストのエントリは常に適用されるので、dangerous-server という名前のサーバーは、URL やコマンドにかかわらずブロックされる
• この許可リストの serverName のエントリは、どちらのトランスポートの種類にもより厳しいエントリがあるので、何にも一致しない

ほかの許可リストと拒否リストの組み合わせでの評価を、次の例で見ます。

URL だけの許可リスト（https://mcp.example.com/* と https://*.internal.example.com/*）

コマンドだけの許可リスト（["npx", "-y", "approved-package"]）

名前とコマンドが混在する許可リスト（serverName: github と ["npx", "-y", "approved-package"]）

名前だけの許可リスト（github と internal-tool）

拒否リストが上書きする許可リスト（許可 https://*.example.com/*、拒否 https://staging.example.com/*）

許可リストを管理設定だけに限る#

管理された許可リストだけを適用するには、管理設定ファイルで allowManagedMcpServersOnly を設定します。

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" }
  ]
}

allowManagedMcpServersOnly が true のとき、ユーザー・プロジェクト・ローカルの設定の許可リストは無視されます。拒否リストは引き続きすべての設定スコープから統合されるので、ユーザーはいつでも自分用にサーバーをブロックできます。

制限がユーザーにどう見えるか#

managed-mcp.json が配られ、セッションに --mcp-config のサーバーもあるときの起動時の表示は、排他的な制御の節を見ます。その他の報告を見分け、変更を展開する前にユーザーへ伝えることを決めるのに、次の表を使います。

サーバーが黙って消えると、ポリシーが理由だという合図がユーザーに届かないので、新しい制限を展開するときは、影響を受けるユーザーにどのサーバーがブロックされるかを伝えます。

MCP の使用を監視する#

OpenTelemetry のエクスポートを設定すると、Claude Code は、ユーザーがどの MCP サーバーとツールを呼んだかを記録できます。OTEL_LOG_TOOL_DETAILS=1 を設定すると、ツールのイベントとコスト・トークンのカウンターに MCP のサーバー名とツール名が入り、コレクターで集計すると、ユーザーが実際につなぐサーバーが分かります（エクスポーターの設定と全イベントのスキーマは利用状況の計測）。

設定のまとめ#

このページが扱うすべてのファイルと設定、制御するもの、配る方法です。

機能の提供状況#

Claude Code の CLI と、ローカルで動くものは、どのプロバイダーでも使えます。プロバイダーごとの設定は、エンタープライズ導入の概要を見ます。下の表と一覧で、「○」は使える、「×」は使えない、条件つきの記述は、その範囲に限られることを意味します。「管理者の有効化が必要」は、組織の管理者がオンにするまで機能がオフであることを指します。

認証方法とプロバイダーの対応#

認証の方法で、Claude Code が届く機能が決まります。自分の列は次で見分けます。

どのプロバイダーでも使える機能#

• CLIと Agent SDK
• VS Code と JetBrains の拡張
• サブエージェント・フック・スラッシュコマンド・スキル
• CLAUDE.md とメモリ・プラグイン・MCP サーバー
• チェックポイント・サンドボックス・ワークフロー
• OpenTelemetry のメトリクスと管理設定ファイル

これらには、プロバイダー固有の違いがあります。

• MCP サーバー：claude.ai のコネクターは、claude.ai のサブスクリプションが有効な認証方法のときだけ読み込まれる。ツール検索は、ANTHROPIC_BASE_URL が自社以外のホストを指すときは既定でオフで、Claude 4.5 世代より前の Google Cloud の Agent Platform のモデルと、Azure でホストする Microsoft Foundry のデプロイでは使えない
• サブエージェント：メイン会話が Fable で動くとき、組み込みの Explore サブエージェントは、Claude サブスクリプション・Anthropic Console のアカウント・ANTHROPIC_BASE_URL で届く LLM ゲートウェイでは Opus で動く。Claude Platform on AWS を含むほかのプロバイダーでは Fable で動く
• コマンド
  • /design-sync と、claude import のサブコマンド形を含む /import は、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Claude Platform on AWS と、Claude apps gateway 経由では使えない
  • /voice は claude.ai アカウントが要る
  • /list-agents とその別名 /peers は、セッション間メッセージが有効なセッションでだけ使える

Claude サブスクリプションが要る機能#

claude.ai アカウントでのサインインが要り、Anthropic Console の API キーやサードパーティのプロバイダーからは届きません。

• クラウドセッション・モバイルの Claude Code・Slack の Claude Code（Slack と Claude Tag）
• デスクトップアプリ
• ルーティン（/schedule）
• ultrareview（コードレビューと ultrareview）
• コードレビュー：Team と Enterprise のプラン
• リモートコントロール
• Chrome 拡張
• コンピュータ操作：Pro と Max のプラン
• アーティファクト：Pro・Max・Team・Enterprise のプラン
• 音声入力（ターミナル・表示・音声入力）

デスクトップアプリは部分的な例外です。ゲートウェイの経路は、アプリか管理者が設定でき、Enterprise の導入では、管理設定で Desktop を Google Cloud の Agent Platform やゲートウェイのプロバイダーへ向けられます。Claude Desktop on 3P は、Code タブを Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・セルフホストの LLM ゲートウェイで動かします。

プロバイダーで違う CLI の機能#

ローカルの CLI で動くものの、サーバー側の機能に依存し、すべてのプロバイダーが提供するわけではない機能です。

• auto mode の補足：v2.1.158 から v2.1.206 では、これらのプロバイダーで auto mode を使うのに CLAUDE_CODE_ENABLE_AUTO_MODE=1 の設定も必要でした。v2.1.207 で要件は外れました
• セッション間メッセージの補足：macOS と Linux（WSL 2 内の Linux を含む）では Claude Code v2.1.224 以降、ネイティブの Windows では v2.1.234 以降が必要。API キー認証では同じマシン内に限る。Amazon Bedrock・Claude Platform on AWS・Google Cloud の Agent Platform・Microsoft Foundry では、同じマシン内に限り、v2.1.248 以降が必要。クラウドセッションと別のマシンのセッションを Claude が見つけられるのは、リモートコントロールにつながっているセッションからだけで、つなぐには claude.ai のサインインとリモートコントロールの他の要件が要る

管理と分析#

プロバイダー別のまとめ#

各プロバイダーで使えない、または部分的にしか使えないものと、代替です。ここに挙がらないものは、上のプロバイダー固有の違いを除き、Claude サブスクリプションと同じに動きます。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Claude Platform on AWS では、Anthropic へのエラー報告とテレメトリは既定でオフです（セキュリティとデータの扱い）。

サブスクリプションのプランごとの提供状況#

Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Anthropic Console の API キーで認証するなら、この節は当てはまりません。claude.ai アカウントでサインインするときは、プランが次の機能の提供状況を決めます。

モデルとコンテキストウィンドウの大きさがプロバイダーとリージョンでどう違うかは、モデル・effort・fast modeを見ます。ビジョン・PDF 入力・extended thinking は Claude Code の機能ではなくモデルの能力で、そのモデルを提供するどのプロバイダーでも動きます。プロンプトキャッシュは、ほとんどのプロバイダーで同じに動き、Amazon Bedrock ではモデルによって対応が違います。

導入の広報とチャンピオン向けの手引き#

組織へ Claude Code を広めるときの、広報の考え方と社内の推進役（チャンピオン）の動き方です。公式ドキュメントには、そのまま貼れる文面の下書き（メール・Slack・Teams 用）が付いています。ここでは、構成と要点だけをまとめます。

広報キット（管理者とエンジニアリングリード向け）#

告知は、標準の全社向けの 1 つを 2 つの形式（メール、Slack か Teams）で用意し、任意の変種が 2 つあります。標準の告知は、Claude Code とは何か・2 分のインストール手順・試す具体的な作業 1 つ・コードがどこへ行くかへの答えをまとめます。

送る前の確認事項です。どれも、リリース当日のサポートの混乱につながる穴を塞ぎます。

• 標準の告知：Claude Code の説明（ターミナルで動き、実際のコードベースを読み、デバッグ・リファクタリング・テスト・PR を最後まで進める。オートコンプリートでもチャット画面でもない。ファイルを編集し、コマンドを実行する）。2 分で動かす手順（インストール・リポジトリへの cd・claude の起動・一度だけ /init）。リポジトリで試す作業の例（不安定なテストの調査と修正・モジュールの説明・push 前の差分のリスクの確認）。コードの行き先（ターミナルで動き、Anthropic の API と直接通信する。Team か Enterprise のプランでは、コードとプロンプトでモデルを学習しない）。質問先と担当者。エディタ派向けに VS Code 拡張と JetBrains プラグインがあることも添える
• 経営層スポンサー版：CTO・CIO・エンジニアリング担当の SVP などが自分の名前とアカウントから送る。依頼を 1 つに絞り、「インストールして、実際の作業 1 つで動かす」だけを頼む。方法は標準の告知と #claude-code に任せる
• パイロットグループ版：段階的な展開で、パイロットの集団にだけ送る。最初の波であることと、1 つ以上の実際の作業に使い、#claude-code-pilot に、うまくいったこと・煩わしかったこと・驚いたことを書いてほしい、という依頼。最初の複数ファイルの変更で、Shift+Tab を「plan」が出るまで押すと、ソースを編集せずに Claude が意図を示すので、どこまで信頼するかを調整する最速の方法になる、という追加の助言を添える
• チャンピオンの勧誘 DM：リリース後、#claude-code で最も活発な 2〜3 人に送る。その人の投稿が告知より採用に効いていることを伝え、準公式の役割として、今の投稿を続ける・新機能を最初に試す・Anthropic のチームへの直接の窓口を持つ、という軽い負担を提案する

ティップスのキャンペーン#

リリース後に機能の活用を促すための、Slack か Teams にそのまま貼れるメッセージの案です。どれも、フック・得られるもの・「今すぐ試す」の促し・ドキュメントへのリンクという同じ型で、順序の指定はなく、#claude-code に週に 1〜2 本ずつ流すか、チームの不足に合うものを選びます。扱う題材は次のとおりです。

モデルの使い分けです。

よくある質問への短い返答#

エンジニアが最初のプロンプトに迷うときに共有するプロンプトのひな形です（[ ] は自分のリポジトリのものに置き換える）。

チャンピオンキット（社内の推進役のエンジニア向け）#

すでに Claude Code を使っていて、チームの採用を手伝いたい個人のエンジニア向けの手引きです。開発者ツールの採用は、リリースの告知では進まず、誰かが上手に使い、公開で話し、他の人が真似しやすくすることで進みます。

チャンピオンの役割は、互いを強め合う 3 つの行動です。

週の中に収まる目安です。役割は、既存の仕事を増幅するもので、追加のサポート業務にしないようにします。

何を共有するか#

最も役に立つ投稿は、完了した成果ではなく、同僚が明日使える技の説明です。技は広がるほど積み上がりますが、進捗報告はそうなりません。再利用できる技の例です。

• @src/components/ のようにディレクトリを @ で指して、テストが無いコンポーネントを尋ねると、見落としていた 2 つが出てきた
• plan mode（Shift+Tab）は、先に提案する変更を示すので、共有のコードに使っても安心できる
• Stop フックを設定して、長い作業の完了をデスクトップ通知で受け取る。設定はスレッドに載せる
• /init がリポジトリから CLAUDE.md を生成するので、規約を何度も聞かれなくなる

形式は、スクリーンショットと 1 行の文脈、または簡潔な前後の説明が適切です。流し読みする人にも要点が入る短さにします。長い書き込みは後で読むために保存されて忘れられがちで、スクリーンショット付きの短い投稿のほうが、真似されて試されます。

聞かれる人になる#

いくつか例を共有すると、質問が来ます。ここがチャンピオンの最も役立つところで、1 人への良い答えは、同じチャンネルを見ている複数の人の行き詰まりを解きます。

• 説明ではなくプロンプトで答える：同僚にどうやったかを聞かれたら、最も役に立つ返答は、実際に使ったプロンプト。自分の問題でそれを動かすほうが、どんな説明より学べて、すぐ行動できる
• ドキュメントではなく機能を指す：「plan mode を試して。Shift+Tab を、出るまで押す」のほうが、その場ではドキュメントへのリンクより役に立つ。深さが要るなら、あとで自分で見つける

聞かれそうな質問です。

輪を広げる#

目標は、自分が積極的に推進するのをやめた後も勢いが続く、軽い習慣を少数つくることです。プログラムを作ったり、展開を主導したりする必要はありません。チャンネルの質問に自分以外の人が答えているなら、役割は果たせています。

緩い計画が要るなら、ほとんどのチームでうまくいく流れの目安です。自由に調整してください。

さらに深く知りたい人には、自分は温かい紹介であって、オンボーディングのプログラムではないと考え、クイックスタートとよくある作業の進め方を案内します。自分では見つけにくい便利な機能の短い節があります。

よくある懸念への返し方#

健全な懐疑は想定内で、エンジニアは自分のコードに触れるツールに慎重であるべきです。最も効果的な返し方は、一般論の議論ではなく、懸念を認め、短く見方を変え、その人自身のコードで具体的な実演を 1 つ提案することです。ほとんどの懸念は、1 回の成功体験で解けます。

最初の試用から日常の利用へ最も確実に進める技を、次の表にまとめます。チャンネルに固定するか、単独で共有します。