Claude CodeのallowedProvidersで接続先を管理設定で限定する

allowedProvidersは端末の接続先を絞るキー

allowedProvidersは、Claude Codeを使う端末がどのサービス経由でClaudeに接続してよいかを、管理設定で限定するキーです。Anthropic API、Amazon Bedrock、LLMゲートウェイなどから、組織が認める先だけをリストで指定します。v2.1.285で追加されました。

リストにないプロバイダーのセッションは、起動時、ログイン時、次にAPIへ通信するときの3か所で拒否されます。セッションの途中で未許可のプロバイダーへ切り替えても同じです。既定は未設定で、その場合はどのプロバイダーも使えます。

スコープはManagedだけです。ユーザー設定やプロジェクト設定に書いても効きません。個人が自分の判断で外せない点が、このキーの意味です。

指定できる値と対応するサービス

配列の要素は、次の8種類の文字列です。

クラウド各社の値は、そのサービス自身のリージョン別・FIPS・プライベートのエンドポイントも含みます。リージョンごとに値を増やす必要はありません。

mantleには注意点が1つあります。MantleをInvoke APIと並べて使うセッションは、2つのプロバイダーを使うことになります。その構成ではbedrockとmantleを両方書きます。Mantleの構成はBedrock Mantleエンドポイントの使い方にあります。

設定ファイルの書き方

managed-settings.jsonに1キーを足すだけです。AnthropicのAPIとBedrockだけを許す例を示します。

{
  "allowedProviders": ["anthropic", "bedrock"]
}

これで、VertexやFoundry、ゲートウェイ経由のセッションは拒否されます。拒否されたときのメッセージは、許可されているプロバイダーの一覧から始まります。

Your organization's managed settings allow Claude Code to use: Anthropic API, Amazon Bedrock.

メッセージにはTo continue:で始まる手順も付きます。管理者向けにはAdmins:で始まる行があり、追加すべきエントリやpinすべき値を示します。

anthropicを許可しても、サインインの種類までは縛れません。claude.aiの個人アカウントでのログインも、このままでは通ります。ログイン方法も絞りたいときは、forceLoginMethodかforceLoginOrgUUIDを組み合わせます。ゲートウェイ側の関連キーはforceLoginGatewayUrlの解説にあります。

customEndpointは管理env側でpinする

customEndpointは、書くだけでは通りません。接続先ホストを管理設定のenvブロックにも書いて、その値と完全に一致するときだけ許可されます。この固定を、設定リファレンスはpinと呼びます。

LLMゲートウェイだけに接続させる構成は、次のようになります。

{
  "allowedProviders": ["customEndpoint"],
  "env": {
    "ANTHROPIC_BASE_URL": "https://gateway.example.com"
  }
}

pinが必要になるのは、次の3つの場面です。

• customEndpointのセッション。接続先を決める変数(ANTHROPIC_BASE_URLなど)をpinします
• Amazon Bedrockで、AWS_ENDPOINT_URL・AWS_ENDPOINT_URL_BEDROCK・AWS_ENDPOINT_URL_BEDROCK_RUNTIMEがBedrock自身のサービスの外を指すとき。このセッションはcustomEndpointではなくbedrockのままです
• ゲートウェイ経由のサインイン。セッションはgatewayのままで、forceLoginGatewayUrlもpinとして数えられます

どのenvがpinとして数えられるかは、リストの置き場所で変わります。端末側の管理者ソース(MDMやファイル)がリストを持つなら、数えられるのはその端末側のenvだけです。サーバー管理設定だけがリストを持つなら、サーバー管理設定のenvも数えられます。

リストが見ないものもあります。クラウドの認証情報、テナント、HTTPS_PROXYや証明書設定といったネットワーク経路です。これらは管理envで別に配ります。ゲートウェイ固定の背景と互換性はLLMゲートウェイ互換性の解説が詳しく扱っています。

構成別の書き分け

組織の接続方針ごとに、リストの中身は決まります。

最後の行の併用は、リストにある限り、開発者がどちらでも選べるという意味です。選択肢を1つに絞りたいなら、リストを1要素にします。

空のリストと綴り間違いの扱い

ここが一番の落とし穴です。

空のリスト[]を配ると、すべてのプロバイダーが拒否され、Claude Codeはその端末で起動しなくなります。全エントリが認識できない値(綴り間違いなど)のリストも同じ結果です。このとき表示されるメッセージはallowedProviders is an empty list、またはallowedProviders lists only unrecognized entriesを含みます。

一部のエントリだけが不明な場合は、そのエントリが取り除かれて報告され、残りは有効なままです。たとえば["anthropic", "bedrok"]ならbedrokが落ち、anthropicだけが許可されます。気づかないうちにBedrock利用者が締め出される形です。

値の型そのものが不正なときは、「値が直るまで空の許可リストとして扱う」挙動になり、やはり全プロバイダーが拒否されます。全台へ配る前に、少数の端末で/statusと起動の可否を確かめる運用が安全です。

複数の管理ソースがあるときの合成

端末のMDMやファイルと、サーバー管理設定の両方がリストを持つ場合、セッションが使えるのは両方のリストに載るプロバイダーだけです。サーバー管理のリストは範囲を狭められますが、広げられません。

一方、サーバー管理設定だけでリストを配る場合は、サーバー管理設定を取得するセッションにしか届きません。サーバー管理設定は、利用者がCLAUDE_CODE_USE_BEDROCKなどで第三者プロバイダーを自分で選ぶと使われない仕様です。そのため、Bedrockなどへの流出を止めたい用途では、端末側のMDMかファイルで配るのが確実です。

管理ソースが複数あるときの選ばれ方は、managedSourcesBehaviorで変わります。詳細はmanagedSourcesBehaviorの解説にあります。

Claude Desktop、IDE拡張、Agent SDKアプリのようにClaude Codeを起動する側のアプリは、SDKのmanagedSettingsオプションで独自の管理設定(親の設定)を渡せます。allowedProvidersの場合、選ばれた管理ソースにリストがあれば、親が渡したリストは使われません。managedSourcesBehaviorを"merge"にしたときは、どの管理ソースのリストでも親のリストより優先されます。いずれもv2.1.285以降の挙動です。Desktopなどで配る管理者は、親側にリストを置くより、端末側の管理ソースに置くほうが意図どおりに効きます。

拒否された通信の見つけ方

許可されない宛先への通信は、OpenTelemetryのrefusedイベントにprovider_not_allowedというerror.typeで残ります。v2.1.285以降です。拒否の件数を監査ログで追いたい場合は、OTEL_LOG_MANAGED_SETTINGSの記事の手順で管理設定の解決結果と並べて見られます。

開発者の手元では、起動時のメッセージがそのまま手がかりになります。

拒否メッセージの種類と対処

メッセージの出だしを見ると、原因を切り分けられます。

どの文言でも、開発者はTo continue:で始まる手順に従うか、管理者に連絡します。自分の設定ファイルでは許可を広げられません。管理者はAdmins:で始まる行に従い、追加するエントリかpinする値を決めます。

ポリシーファイルの読込失敗は、allowedProvidersの中身とは別の原因です。それでも、この状態ではサインイン、すでに動いているセッションからのAPIリクエスト、claude gatewayサーバーが、allowedProvidersを名指しした文言で拒否されます。管理者はまずDetail:の行が示す原因を直し、配布したソースが読めるようにするか、そのソースを外します。OSに読み取りを拒否されたとき(root専用のファイルなど)は、この拒否にはならず、そのソースのポリシーなしで起動します。JSONとして解釈できないソースは、ソース名を挙げる別のメッセージで終了します。開発者側にできる対処はなく、メッセージを管理者に渡します。

導入前に確かめること

少数の端末から段階的に広げる手順です。

配布経路は端末側の管理ソースが確実で、サーバー管理設定だけだと届かないセッションが出ます。管理設定全体の設計はClaude Code組織管理ガイドが入口になります。

追加の経緯はv2.1.285のリリースノート(v2.1.285の変更点)にあります。

まとめ

allowedProvidersは、接続先をリストで固定する、利用者側の設定では上書きできない管理側のキーです。判断の中心は2つあります。customEndpointは管理envのpinとセットで書くこと、そして空や全て不明のリストは「何も許さない」になることです。配布は端末側の管理ソースを基本にして、少数の端末で起動できることを確かめてから広げると、締め出し事故を避けられます。