メインコンテンツへスキップ
Claude apps gateway デプロイメントは、慣例的に gateway.yaml という 1 つの YAML ファイルで設定されます。このファイルは、ゲートウェイが行うすべてのことを定義します:どこでリッスンするか、開発者がどのようにサインインするか、推論がどこに行くか、どのポリシーとテレメトリーが適用されるかです。このページは、そのファイル内のすべてのオプションのリファレンスです。最初のファイルを作成するには、クイックスタートから始めてください。これは最小限の動作設定を構築して実行します。設定に満足したら、デプロイメントガイドで、Kubernetes、Cloud Run、または独自のプラットフォームでのコンテナ化とホスティングについて説明しています。 ゲートウェイは、claude gateway --config /path/to/gateway.yaml でスタートアップ時にファイルを 1 回読み込みます。すべてのオプションはブート時にスキーマに対して検証されるため、形式が正しくない設定は、最初の使用時ではなく、フィールドレベルのエラーで開始時に失敗します。 このページの最後にある完全な例は、すべてのセクションを実行します。

ファイル構造

5 つのセクションが必須です。他のすべてのセクションはオプションであり、省略されたセクションはデフォルトを使用します。不明なキーはブートに失敗するため、タイプミスは無視された設定ではなく、名前付きエラーとして表示されます。 必須セクション:
  • listen:バインドアドレス、パブリック URL、TLS 終了
  • oidc:ID プロバイダー(IdP)、発行者、クライアント、クレームマッピング、サインイン可能なユーザーを含む
  • session:ゲートウェイが発行するベアラートークン、シークレット、有効期間
  • store:デバイスグラント、レート制限カウンターの PostgreSQL
  • upstreams:推論がどこに行くか、Anthropic、Bedrock、Agent Platform、または Foundry かどうか
オプションセクション:
  • admin:Admin API 認証、支出制限の保持
  • enforcement:支出制限のフェイルオープンまたはフェイルクローズ動作
  • modelsauto_include_builtin_models:管理者がキュレーションしたモデルリスト、アップストリームごとの ID
  • managed:IdP グループ別のマネージド設定ポリシー
  • telemetry:OTLP を観測可能性スタックに転送
  • access_controllimitstimeoutsrate_limits:IP 許可/拒否、リクエストサイズキャップ、アップストリーム初バイト時間、IP ごとのサインイン制限

シークレット展開

client_secretjwt_secretpostgres_url などのシークレットを gateway.yaml に直接書き込まないでください。以下のいずれかの形式で参照すると、ゲートウェイはブート時に環境変数またはファイルから値を解決します:
形式解決先用途
${VAR}環境変数 VAR。未定義の場合はブート失敗。コンテナ環境変数、env インジェクション経由の AWS Secrets Manager
${file:/path}ファイルの内容、トリミング済みKubernetes Secret ボリュームマウント、Vault Agent、SOPS

必須セクション

listen

listen ブロックは、ゲートウェイがサービスを提供する場所を制御します:バインドアドレスとポート、外部から見えるオリジン、オプションの TLS 終了。
フィールド必須説明
hostいいえバインドアドレス。デフォルト 0.0.0.0
portいいえバインドポート。デフォルト 8080
public_urlプロキシの背後外部から見える https:// オリジン。IdP redirect_uri と検出メタデータを構築するために使用されます。ALB、Ingress、Cloud Run などの TLS 終了プロキシの背後では必須です。ゲートウェイは独自のオリジンを構築する際に X-Forwarded-* ヘッダーを信頼しないためです。これらはクライアントがスプーフ可能です。trusted_proxies 以下はクライアント IP 解決のみを管理します。また、テレメトリを有効にするためにも必須です。ゲートウェイはこの URL からクライアントにプッシュする OTLP エンドポイントを構築するためです。
tls.cert / tls.keyいいえゲートウェイが TLS 自体を終了する場合の PEM パス
trusted_proxiesいいえゲートウェイの前にあるロードバランサーの CIDR または IP。設定すると、ゲートウェイはこれらのピアからのみ X-Forwarded-For を信頼し、IP ごとのレート制限と監査のための実際のクライアント IP を記録します。nginx set_real_ip_from と同等。

oidc

OpenID Connect(OIDC)は、ゲートウェイが ID プロバイダーで使用する SSO プロトコルです。IdP 側で登録する内容については、ID プロバイダー設定を参照してください。oidc ブロックはゲートウェイを ID プロバイダーに接続し、サインイン可能なユーザーを決定します。発行者と OAuth クライアントに名前を付け、メールとグループを含むクレームをマップし、メールドメインまたはグループによるサインインを制限します。
フィールド必須説明
issuerはいOIDC 検出ベース。/.well-known/openid-configuration で検出を提供する必要があります。本番環境では HTTPS を使用してください。ゲートウェイは http:// 発行者を受け入れます。http://localhost:8081 などのループバック発行者は、CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 がゲートウェイの環境に設定されていない限り、SSRF ガードによって拒否されます。
client_id / client_secretはいOAuth クライアント登録から
allowed_email_domainsいいえemail クレームがこれらのドメインのいずれかにない id_token を拒否します。大文字小文字を区別しません。マルチテナント IdP の設定ミスに対する多層防御。この設定とは無関係に、email_verified クレームが明示的に false である id_token は常に拒否されます。
allowed_groupsいいえサインインを groups_claim に対してマッチしたこれらの IdP グループのメンバーに制限します。許可されたメールドメイン内にあるが、これらのグループのいずれにも属していないユーザーは拒否されます。IdP がグループクレームを発行する必要があります。
groups_claimいいえグループメンバーシップを含む id_token クレーム。デフォルト groups。Microsoft Entra はアプリロールを roles の下に発行します。フラットキーまたは /resource_access/gateway/roles などのネストされたクレーム用の RFC 6901 JSON ポインタを受け入れます。
google_groupsいいえGoogle Workspace Admin SDK Directory API を通じてサインインしたユーザーのグループを検索します。Google の id_token はグループクレームを含まないためです。service_account_json_pathhttps://www.googleapis.com/auth/admin.directory.group.readonly スコープでドメイン全体の委任を持つサービスアカウントキーファイルに設定し、admin_email をサービスアカウントが偽装する Workspace 管理者に設定します。Directory API は実際の管理者サブジェクトが必要です。各ユーザーのグループメールアドレスがグループクレームになるため、allowed_groupsmanaged.policies.match.groups はグループメールでマッチします。
email_claimいいえユーザーのメールを含む id_token クレーム。デフォルト email。ADFS や Entra B2C などの一部の IdP は、代わりに upn または preferred_username を発行します。フラットキー、JSON ポインタ、または最初に存在するキーが使用されるフォールバックキーのリストを受け入れます。
scopesいいえゲートウェイが要求する OIDC スコープの完全なオーバーライド。デフォルト [openid, profile, email, offline_access]。IdP が認識しないスコープを拒否する場合、またはグループまたはメールを発行するカスタムスコープが必要な場合に設定します。openid を含める必要があります。offline_access を削除するとリフレッシュトークンが無効になるため、開発者は session.ttl_hours ごとにブラウザログインを再実行します。Google のリフレッシュトークンフロー などの IdP ごとのスコープレシピについては、ID プロバイダー設定を参照してください。
extra_auth_paramsいいえIdP 認可リクエストに逐語的に追加される追加クエリパラメータ。これは、Google リフレッシュトークンの access_type: offline、一部の Entra テナントの domain_hint、またはステップアップフローの acr_values など、IdP 固有の動作のオーバーライドメカニズムです。ゲートウェイが管理するプロトコルパラメータはオーバーライドできません:statenonceredirect_uri、PKCE、scoperesponse_typeresponse_modeclient_id
userinfo_fallbackいいえid_token がメールまたはグループを省略する場合、/userinfo から取得します。Keycloak 軽量アクセストークン、Okta org サーバー、ADFS 最小トークンに必要です。id_token は権威的なままです。userinfo はギャップのみを埋めます。デフォルト false
use_pkceいいえ認可リクエストで PKCE(S256)チャレンジを送信します。デフォルト true。IdP がこの機密クライアントの PKCE を拒否する場合のみ false に設定します。
clock_skew_secondsいいえid_token 時間クレームを検証する際にクロックドリフトを許容します。デフォルト 0(厳密)。サインイン直後のホスト/IdP クロックスキューによる「トークン期限切れ/まだ有効でない」エラーが表示される場合は、増やします。
token_endpoint_auth_methodいいえトークンエンドポイント認証方法をオーバーライドします。client_secret_basic または client_secret_post を受け入れます。デフォルトで自動ネゴシエーション。
id_token_signed_response_algいいえ予想される id_token 署名アルゴリズム。デフォルト RS256。ES256、PS256、または EdDSA で署名する IdP に設定します。
additional_authorized_partiesいいえclient_id を超えて受け入れる追加の azp 値。Keycloak ブローカーとトークン交換フロー用。
discovery_urlいいえissuer から派生させるのではなく、この URL から検出ドキュメントを取得します。プロキシの背後にある IdP の場合、発行者ホストを書き直します。パスは /.well-known/ を含む必要があります。
form_action_originsいいえ/device ページの Content-Security-Policy: form-action ディレクティブの追加オリジン。ゲートウェイはすでに 'self' と検出された authorization_endpoint オリジンを許可していますが、Chrome は全リダイレクトチェーンに対して form-action を強制します。IdP が Azure AD から ADFS へのフェデレーション、ハブスポーク Okta、または企業 SSO インターセプターなど、2 番目のホストを通じてリダイレクトする場合、認可リクエストがリダイレクトする可能性のあるすべてのオリジンをリストします。
ca_cert_pemいいえIdP リクエストのみのシステムトラストストアを置き換える PEM CA 証明書。企業 PKI の背後にある Keycloak または Dex に使用します。

session

session ブロックは、サインイン後にゲートウェイが発行するベアラートークンの形状を決定します:それらに署名するシークレットと、どのくらい長く生きるか。
フィールド必須説明
jwt_secretはい少なくとも 32 バイトのエントロピー。例えば openssl rand -base64 32 から。ゲートウェイの HS256 ベアラートークンに署名します。単一の文字列または回転用の配列を受け入れます:インデックス 0 が署名し、すべてのエントリが検証します。回転するには、新しいシークレットを先頭に追加し、ttl_hours 待機してから古いものを削除します。
ttl_hoursいいえゲートウェイベアラートークンの有効期間。デフォルト 1。CLI は IdP がリフレッシュトークンを発行する場合、有効期限前に無言でリフレッシュします。有効期間が短いほど、より速くプロビジョニング解除されます。長いほど、IdP ラウンドトリップが少なくなります。IdP が offline_access が利用できないため、リフレッシュトークンを発行できない場合、無言リフレッシュはないため、開発者が 1 時間ごとにブラウザログインに戻されるのを避けるために、これを 8 または 12 に上げます。

store

store ブロックは、ゲートウェイを PostgreSQL データベースに指します。このデータベースは、デバイスグラントとレート制限カウンターを保持します。
フィールド必須説明
postgres_urlはいpostgres:// または postgresql:// URL。必須:デバイスグラント集合場所。ブラウザコールバックが書き込み、ポーリング CLI が読み込む場所。レプリカ間の状態が必要です。ゲートウェイはブート時に独自のスキーママイグレーションを実行するため、ロールはターゲットスキーマで CREATE TABLE が必要です。セキュリティポリシーがアプリケーションロールからの DDL を禁止する場合、マイグレーションを管理者ロールで実行し、最初と新しいリリースがマイグレーションを出荷するたびに、アプリロールに SELECT, INSERT, UPDATE, DELETE をゲートウェイのテーブルで付与します。アップグレードPostgres を参照してください。
usernameいいえpostgres_url のユーザーをオーバーライド
passwordいいえデータベース認証情報。postgres_url ではなくここに設定して、認証情報を URL から外します。任意の文字を受け入れ、URL 認証情報よりも優先されます。
max_connectionsいいえレプリカごとの Postgres 接続プール サイズ。デフォルト 5。共有データベースに対して保守的でフレンドリーです。支出制限が有効な場合、ホットパスは推論リクエストごとに数回の操作を実行するため、専用データベースの負荷の下で増やし、レプリカ × これをデータベースの max_connections 以下に保ちます。
ローカル開発の場合、postgres_url を使い捨て Postgres コンテナに指します。例えば docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres

upstreams

upstreams は順序付きリストです。ゲートウェイは、要求されたモデルを解決する最初のアップストリームに推論を転送します。5xx429、またはタイムアウト時に次にフェイルオーバーします。他の 4xx はしません。これらのエラーはリクエストではなくアップストリームに起因するためです。同じプロバイダーの複数のアップストリームは、異なる name: を設定する必要があります。 Bedrock、Agent Platform、Foundry クライアントはスタートアップ時に 1 回構築され、SDK は内部的に認証情報をリフレッシュするため、クラウド認証情報のローテーションは再起動を必要としません。静的 Anthropic API キーとベアラーはスタートアップ時に読み込まれます。Anthropic API を参照してください。

Anthropic API

最小限の Anthropic アップストリームは、Claude Console からの API キーです:
upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}
    # または OAuth ベアラー(例:Workload-Identity-Federation 交換トークン):
    #   oauth_token: ${file:/var/run/secrets/anthropic-oauth-token}
    # base_url: https://api.anthropic.com   # デフォルト;フォワードプロキシの場合はオーバーライド
2 つの認証情報形式は、送信するヘッダーが異なります:
  • api_keyx-api-key を送信します。Claude Console でローテーションし、env var を更新します。
  • oauth_tokenAuthorization: Bearer を送信します。組織が長期 API キーではなく短期トークンを発行する場合、ベアラー形式を使用します。ベアラーはスタートアップ時に 1 回読み込まれるため、シークレットを再マウントして再起動することで更新します。
静的キーまたはベアラーの代わりに、Workload Identity Federation を使用できます。Workload Identity Federation ガイドに従って、フェデレーションルールを作成し、ワークロードの OIDC JWT をファイルとしてマウントします。例えば、Kubernetes プロジェクトサービスアカウントトークンまたは CI プラットフォームの id-token。ゲートウェイは JWT を短期ベアラーと交換し、自動的にリフレッシュします。トークンファイルはすべての交換で再読み込みされるため、ローテーションされたプロジェクトトークンは再起動なしで取得されます。
upstreams:
  - provider: anthropic
    auth:
      federation_rule_id: ${ANTHROPIC_FEDERATION_RULE_ID}
      organization_id: ${ANTHROPIC_ORGANIZATION_ID}
      identity_token_file: /var/run/secrets/anthropic/id-token
      # workspace_id: wrkspc_...       # ルールが 1 つ以上のワークスペースをカバーする場合は必須
      # service_account_id: svac_...   # オプションの予想ターゲットチェック

Amazon Bedrock

ゲートウェイが置き換えるまたはフロントする、クライアント側の Bedrock デプロイメントについては、Amazon Bedrock の Claude Code を参照してください。ゲートウェイ側のアップストリーム:
upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}                           # 推奨:AWS デフォルト認証情報チェーン
    # または明示的な認証情報:
    # auth:
    #   aws_access_key_id: ${AWS_AKID}
    #   aws_secret_access_key: ${AWS_SK}
    #   aws_session_token: ${AWS_ST}
    # または Bedrock API ベアラートークン:
    # auth:
    #   aws_bearer_token: ${AWS_BEARER_TOKEN}
    # FIPS または VPC エンドポイントデプロイメント用に bedrock-runtime エンドポイントをオーバーライド:
    # base_url: https://bedrock-runtime-fips.us-east-1.amazonaws.com
空の auth ブロックは AWS SDK のデフォルト認証情報チェーンを使用します:env vars、~/.aws/credentials、ECS タスクロール、EC2 インスタンスメタデータ、または EKS の IRSA。本番環境では、コンテナイメージに静的キーを埋め込むのではなく、ゲートウェイポッドに IAM ロールを付与します。
セットアップ方法
IAM 権限ゲートウェイのプリンシパルに bedrock:InvokeModelbedrock:InvokeModelWithResponseStream を推論プロファイル ARN と基盤モデル ARN の両方に付与します。US リージョンの組み込みカタログの場合:arn:aws:bedrock:<region>:<account>:inference-profile/us.anthropic.*arn:aws:bedrock:*::foundation-model/anthropic.*
モデルアクセスBedrock コンソールで、リージョンごとに、必要な Claude モデルのモデルアクセスをリクエストして有効にします。クロスリージョン推論プロファイル(us.anthropic.*)は、プロファイルがスパンする各リージョンでモデルアクセスが必要です。
EKS(IRSA)上記のポリシーと、クラスターの OIDC プロバイダーのトラストポリシーを持つ IAM ロールを作成します。ゲートウェイのサービスアカウントにスコープされます。サービスアカウントに eks.amazonaws.com/role-arn: arn:aws:iam::<acct>:role/claude-gateway でアノテーションを付けます。auth: {} がそれを取得します。
ECS / EC2IAM ロールをタスク定義またはインスタンスプロファイルにアタッチします。auth: {} がそれを取得します。
その他の場所AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN env vars を通じて認証情報を渡すか、auth:${VAR} 展開を使用して明示的に設定します。
リージョンregion: は API エンドポイントリージョンです。クロスリージョン推論プロファイルは、どれを選択するかに関わらず、地域(US、EU、APAC)全体でルーティングします。US 以外のリージョンまたはプロビジョニングスループット ARN の場合、正しいアップストリームごとの ID を持つ models: ブロックを追加します。

Google Cloud Agent Platform

同等のクライアント側セットアップについては、Google Cloud の Claude Code を参照してください。ゲートウェイ側のアップストリーム:
upstreams:
  - provider: vertex
    region: us-east5
    project_id: example-prod
    auth: {}                           # 推奨:Application Default Credentials
    # またはサービスアカウントキーファイル:
    # auth: { service_account_json: /secrets/sa.json }
    # Private Service Connect 用に aiplatform エンドポイントをオーバーライド:
    # base_url: https://us-east5-aiplatform.p.googleapis.com
空の auth ブロックは Application Default Credentials を使用します:GOOGLE_APPLICATION_CREDENTIALS、GCE メタデータ、または GKE Workload Identity。サービスアカウント JSON キーファイルはサポートされていますが、推奨されません。Workload Identity を使用するか、GCE または Cloud Run インスタンスにサービスアカウントをアタッチします。 region: global を設定して、地域のエンドポイントの代わりに Agent Platform のグローバルエンドポイントを使用します。Google は各リクエストを利用可能なリージョンにルーティングするため、リージョンごとのモデル可用性を追跡する必要はありません。特定のリージョンを設定すると、すべてのリクエストがそれにピンされます。
セットアップ方法
IAM 権限ゲートウェイのサービスアカウントに roles/aiplatform.user をプロジェクトに付与するか、aiplatform.endpoints.predict を持つカスタムロール。Agent Platform API(aiplatform.googleapis.com)を有効にします。
モデルアクセスModel Garden で、プロジェクトの Claude モデルを有効にします。特定のリージョンに公開されます。サポートされているリージョンについてはモデルカードを確認してください。
GKE(Workload Identity)GCP サービスアカウントをゲートウェイの Kubernetes サービスアカウントにバインドし、KSA に iam.gke.io/gcp-service-account: claude-gateway@<proj>.iam.gserviceaccount.com でアノテーションを付けます。auth: {} がそれを取得します。
Cloud Run / GCEサービスのサービスアカウントを roles/aiplatform.user を持つものに設定します。auth: {} がそれを取得します。
その他の場所auth: { service_account_json: /secrets/sa.json }。JSON キーファイルへのパス。シークレットとしてマウントされます。フィールドはキーの内容ではなくファイルパスを取得するため、${file:…} 展開は関係ありません。

Microsoft Foundry

クライアント側の Foundry デプロイメントについては、Microsoft Foundry の Claude Code を参照してください。ゲートウェイ側のアップストリーム:
upstreams:
  - provider: foundry
    resource: example-foundry              # https://example-foundry.services.ai.azure.com
    auth: { use_azure_ad: true }        # 推奨:DefaultAzureCredential / Managed Identity
    # または API キー:
    # auth:
    #   api_key: ${FOUNDRY_API_KEY}
use_azure_ad: trueDefaultAzureCredential を通じて解決します:AKS、ACI、または App Service の Managed Identity、Azure CLI、または環境認証情報。API キーは機能しますが、プロジェクト全体であり、自動的にローテーションされません。Foundry のエンドポイントは resource: から派生します。Azure Government などのソブリンクラウドの場合、オプションの base_url を設定してオーバーライドします。
セットアップ方法
RBACゲートウェイのアイデンティティに Azure AI User または Cognitive Services User を Foundry リソースに付与
デプロイメントFoundry は正規モデル ID ではなく、管理者が選択したデプロイメント名を使用します。各正規 ID をデプロイメント名にマップする models: ブロックを追加します。
AKS(ワークロードアイデンティティ)User-Assigned Managed Identity をクラスターの OIDC 発行者とフェデレーションし、ゲートウェイのサービスアカウントにバインドします。use_azure_ad: trueWorkloadIdentityCredential を通じてそれを取得します。
ACI / App Serviceリソースでシステム割り当てまたはユーザー割り当てマネージドアイデンティティを有効にします。use_azure_ad: true がそれを取得します。
その他の場所auth: { api_key: "${FOUNDRY_API_KEY}" }{ } 内の ${…} をクォートします。

複数のアップストリーム

同じプロバイダーは、異なる name: で複数回表示できます。これは異なるリージョン、異なる認証情報チェーン経由の異なるアカウント、プロビジョニングスループット対オンデマンド、クロスプロバイダーフェイルオーバーをカバーします。 ゲートウェイはアップストリームを順番に試します。5xx429、タイムアウト、および欠落エンドポイント(501)はフェイルオーバーします。他の 4xx はしません。429 はアップストリーム容量ごとです。プロビジョニングスループット(PT)枯渇はオンデマンドにフェイルオーバーします。要求されたモデルを解決できないアップストリームはネットワークラウンドトリップなしでスキップされます。 この例は、プロビジョニングスループット Bedrock 割り当てを最初にルーティングし、オンデマンドと 2 番目のアカウントにオーバーフロー、最後に Anthropic API にフォールバックします:
upstreams:
  # プライマリ:ホームリージョンのプロビジョニングスループット。
  - name: bedrock-pt
    provider: bedrock
    region: us-east-1
    auth: {}
  # オーバーフロー:オンデマンドクロスリージョン。
  - name: bedrock-od
    provider: bedrock
    region: us-west-2
    auth: {}
  # 異なるアカウント:想定ロール認証情報経由の別の Bedrock 割り当て。
  - name: bedrock-acct2
    provider: bedrock
    region: us-east-1
    auth:
      aws_access_key_id: ${ACCT2_AKID}
      aws_secret_access_key: ${ACCT2_SK}
  # 最後の手段:直接 Anthropic API。
  - name: anthropic-fallback
    provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

# アップストリームごとのモデル ID はアップストリームの `name:` でキーイングされます。`name:` のないアップストリームはプロバイダー文字列(例:`bedrock`)にデフォルト設定されます。モデルにリストされていないアップストリームはスキップされます。これは、プロビジョニングスループットにモデルをルーティングしながら、他のすべてがオンデマンドのままである方法です。
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      bedrock-pt: arn:aws:bedrock:us-east-1:111111111111:provisioned-model/abcdef
      bedrock-od: us.anthropic.claude-opus-4-8
      bedrock-acct2: us.anthropic.claude-opus-4-8
      anthropic-fallback: claude-opus-4-8
レバー方法
異なるリージョンリージョンごとに 1 つの Bedrock アップストリーム。それぞれ独自の region: を持ちます。auto_include_builtin_models: true を使用すると、クロスリージョン推論プロファイルは自動的にルーティングされます。リージョンピンデプロイメントの場合、models: ブロックを使用します。
異なるアカウントアカウントごとに 1 つの Bedrock アップストリーム。それぞれ auth: で独自の認証情報を持ちます。デフォルトチェーン(auth: {})はポッドのアイデンティティを使用します。2 番目のアカウントの場合、明示的な認証情報またはベアラートークンを設定します。
プロビジョニングスループットそのアップストリームの名前の models: でプロビジョニングスループット ARN にモデルをマップします。他のアップストリームはオンデマンド ID を保持するため、PT 容量はフェイルオーバー前に枯渇します。
VPC / FIPS エンドポイントアップストリームで base_url: を VPC エンドポイントまたは FIPS エンドポイント URL に設定します。
モデルスコープルーティングモデルの upstream_model: マップからアップストリームを省略し、そのアップストリームはそのモデルでスキップされます。例えば、Opus をプロビジョニングスループットにルーティングし、Sonnet と Haiku をオンデマンドにルーティングします。
クラウドプロバイダー間、または直接 Anthropic API へのフェイルオーバーは、リクエストを管理する契約、地域、その他の条件を変更します。 CLI は、どのアップストリームが特定のリクエストを提供するかに関わらず、ゲートウェイに同じ機能ゲーティングを適用するため、フェイルオーバーはアップストリームが拒否するボディフィールドを送信しません。

オプションセクション

admin

オプション。/v1/organizations/spend_limits を有効にします。これは Anthropic のパブリック Admin API をミラーリングし、/v1/messages で開発者ごとの支出強制を行います。支出制限で、キャップがどのように設定および強制されるかを参照してください。このセクションは、機能をオンにしてチューニングする gateway.yaml キーをカバーします。
admin:
  # 管理エンドポイント用の名前付き静的 API キー。x-api-key として送信されます。
  # ID は監査ログに admin-key:<id> として表示されるため、各キーは
  # 属性可能です。回転用の配列:新しいキーを追加し、クライアントをロール、
  # 古いものを削除します。
  write_keys:
    - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
    - { id: ci,        key: "${GATEWAY_ADMIN_WRITE_KEY_CI}" }
  read_keys:
    - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
  # 通常のゲートウェイ JWT(API キーなし)経由で完全な管理者を付与された IdP グループ。
  admin_groups: [platform-finops]
  blocked_message: request an increase at https://go.example.com/claude-limits
フィールド必須説明
write_keysいいえ{id, key} の配列。これらのいずれかと一致する x-api-key は、支出制限をリスト、設定、削除できます。キー値は少なくとも 32 文字である必要があります。idread_keyswrite_keys 全体で一意である必要があります。
read_keysいいえ{id, key} の配列。読み取り専用:すべての GET エンドポイント。キャップのリスト、ID による 1 つの取得、/effective/audit の読み取りを含みます。
admin_groupsいいえIdP グループ名。groups クレームがこれらのいずれかを含むゲートウェイ JWT は、完全な管理者アクセス、読み取りと書き込みを持ち、oidc:<sub> として監査されます。人間の管理者に使用します。マシンに API キーを使用します。
blocked_messageいいえブロックされた開発者が見る 429 billing_error に逐語的に追加されます。URL または Slack チャネルなど、完全な指示を書きます。未設定の場合、エラーは spend limit reached です。
audit_retention_daysいいえデフォルト 365。古い admin_audit 行はスイープされます。
spend_retention_monthsいいえデフォルト 13。この期間より古い spend カウンター行はスイープされます。デフォルトは、年間比較レポート用に完全な年と現在の部分月を保持します。
identity_retention_daysいいえデフォルト 90principal_emails 行の最後に見た TTL。各開発者のメール、表示名、グループ(PII)を保持します。意図的に支出保持より短いため、プロビジョニング解除されたアイデンティティは、その匿名支出カウンターが残っている間に期限切れになります。
group_limit_modeいいえmin(デフォルト)または max。開発者が複数のグループにキャップがある場合、min は最も制限的なものを強制し、max は最も制限的でないものを強制します。強制と /effective の両方で使用されます。

enforcement

enforcement ブロックは、ストアが利用できない場合の支出制限チェックの動作を制御します。
フィールド必須説明
fail_closed_on_errorいいえデフォルト false。支出強制は Postgres 停止時にオープンで失敗するため、推論は稼働したままです。true に設定してクローズで失敗:上限を超えた開発者はブロックされますが、ストアに到達できない場合は他のすべてもブロックされます。admin: ブロックなしでは効果がありません。

models

models ブロックはオプションの管理者がキュレーションしたモデルリストで、/v1/models で提供され、アップストリームごとのモデル ID を変換するために使用されます。US 以外の Bedrock リージョン、Bedrock プロビジョニングスループット ARN、Foundry デプロイメント名に必須です。
auto_include_builtin_models: true   # false:以下のリストのみを公開
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    # description:オプションのテキスト。クライアントに表示される場合がある
    upstream_model:
      anthropic: claude-opus-4-8
      bedrock: us.anthropic.claude-opus-4-8   # または推論プロファイル ARN
      foundry: your-opus-deployment-name

managed

managed ブロックは、IdP グループまたはメールドメインでキーイングされた、ロールベースのアクセスポリシーを定義します。ポリシーは順番に評価されます。最初のマッチが選択され、以下で説明する match: {} キャッチオール基盤にマージされます。ユーザーごとに GET /managed/settings で ETag/304 キャッシング付きで提供されます。
managed:
  policies:
    # 特定のグループを最初に。
    - match: { groups: [eng-contractors] }
      cli:
        availableModels: [claude-sonnet-4-6]
        permissions: { deny: ["WebFetch", "WebSearch"] }
    # デフォルトキャッチオール最後:認証されたすべてのユーザーにマッチします。
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
match: {} キャッチオール。慣例的に最後にリストされます。基盤層として扱われます。他のすべてのポリシーは、設定しないキーについてキャッチオールから継承するため、ロール別エントリは組織デフォルトから異なるものだけをリストする必要があります。マージルールはキータイプに依存します:
  • 許可リストavailableModelspermissions.allow。特定のポリシーのリストは基盤のリストを完全に置き換えます。
  • 拒否リストとフックアレイpermissions.denypermissions.askdisabledMcpjsonServersdeniedMcpServersblockedMarketplaces、およびすべての hooks イベントタイプアレイ。これらは基盤とポリシーの和集合を取得するため、組織全体の拒否または監査フックは、ロール別オーバーライドによって誤ってドロップされることはできません。
  • レコードタイプキーenvmodelOverridesskillOverrides。これらは浅くマージするため、ロール別 env ブロックは設定するキーをオーバーライドし、基盤から残りを継承します。
availableModels/v1/messages でサーバー側でも強制されるため、拒否されたモデルはクライアントが送信するものに関わらず 400 を返します。
マッチャー動作
match: {}認証されたすべてのユーザーにマッチします。これで開始し、後で上にグループスコープポリシーを追加します。
match: { groups: [a, b] }JWT の groups クレームがリストされたグループのいずれかを含む場合にマッチします。大文字小文字を区別します:グループは IdP の正確な大文字小文字と一致する必要があります。
match: { email_domain: example.com }JWT の email クレームの最後の @ の後の部分にマッチします。大文字小文字を区別しません。ポリシーごとに 1 つのドメインを受け入れます。
match: { groups: [a], email_domain: example.com }両方の条件がマッチする必要があります。
ポリシーにマッチしない認証されたユーザーは、ゲートウェイのデフォルトを取得します。これは、カタログ内のすべてのモデルと管理設定なしを意味します。最後に match: {} キャッチオールを追加して、保証されたデフォルトポリシーが必要な場合。
ゲートウェイは独自のユーザーディレクトリを保持しません。ユーザーの IdP トークンから各リクエストを認可し、トークンの groups クレームからグループメンバーシップを読み込み、それに対してポリシーを評価します。列挙するロスターはなく、事前作成するアカウントもありません。したがって、SCIM エンドポイントはありません。SCIM が同期するものがないためです。ユーザーとグループのライフサイクル管理を、真実の源である IdP のネイティブ SCIM プロビジョニングまたは専用アイデンティティガバナンスプラットフォームで実行します。メンバーシップとプロビジョニング解除はそこで管理され、トークンを通じてゲートウェイに自動的に流れます。Claude アカウント自体の SCIM プロビジョニングが必要な場合、それは Claude for Enterprise 機能です。2 つの伝播クロックが適用されます:
  • ポリシーコンテンツ:ポリシーを編集して再デプロイすると、接続されたクライアントの次のマネージド設定ポーリング時に到達します。1 時間以内。
  • グループメンバーシップ:ユーザーのグループメンバーシップを変更すると、どのポリシーが彼らにマッチするかが変わります。これは次のセッション再発行時に有効になります。つまり、次の無言リフレッシュ。session.ttl_hours で制限されます。

cli に何が入るか

cli 値は、完全な Claude Code managed-settings.json ドキュメントです。MDM または /etc/claude-code/managed-settings.json を通じてデプロイするのと同じスキーマ。ここでは YAML として表現されます。CLI は、マネージド層で配信されたドキュメントを適用します。ユーザーとプロジェクト設定の上。 ゲートウェイは、ブート時に CLI の設定スキーマに対して各ドキュメントを検証するため、認識されないトップレベルキーまたは認識されたキーで形式が正しくない値は、すべての違反キーに名前を付けるエラーでブートに失敗します。スキーマの意図的にオープンな部分は、新しいクライアントがゲートウェイのスキーマが認識しないエントリを認識する可能性があるため、任意の値を受け入れます。これらのオープンキーは envpluginConfigspermissions の下にネストされたキーです。 検証はゲートウェイのインストール済みバージョンにバンドルされたスキーマを使用するため、新しい Claude Code リリースで導入されたトップレベル設定キーをマネージド設定に入れるには、最初にゲートウェイをアップグレードする必要があります。新しいポリシーを 1 つのクライアントでスモークテストしてから、ロールアウトします。 完全なキーリファレンスは Claude Code 設定 にあります。オペレーターが最初に到達するキー:
managed:
  policies:
    - match: {}
      cli:
        # モデルアクセス(/v1/messages でサーバー側でも強制)
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]

        # 権限ポリシー
        permissions:
          deny:
            - "WebFetch"
            - "Read(./.env)"
            - "Read(./secrets/**)"
          disableBypassPermissionsMode: disable   # --dangerously-skip-permissions をブロック
        allowManagedPermissionRulesOnly: true     # ユーザー/プロジェクト権限ルールを無視

        # CLI プロセスにプッシュされた環境。DISABLE_UPDATES はバックグラウンドと手動更新をブロック;DISABLE_AUTOUPDATER はバックグラウンド更新のみを停止。
        env:
          DISABLE_UPDATES: "1"                    # 独自の配布経由でバージョンをピン

        # 組織全体のフック。フックコマンドはゲートウェイではなく開発者マシンで実行されるため、パスはポリシー内のすべてのクライアント OS に存在する必要があります。
        hooks:
          PostToolUse:
            - matcher: "Edit|Write"
              hooks:
                - { type: command, command: /usr/local/bin/audit-edit.sh }
キー強制者効果
availableModelsゲートウェイ + CLIモデル許可リスト。/v1/messages でもチェックされるため、パッチされたクライアントはバイパスできません。
permissions.allow / .denyCLIツールとコマンドルール。権限を参照してください。
permissions.disableBypassPermissionsModeCLIdisable に設定して bypassPermissions をブロック。すべてのツール呼び出しを自動承認するモード、および --dangerously-skip-permissions フラグ。
allowManagedPermissionRulesOnlyCLItrue の場合、ユーザーとプロジェクト権限ルールは無視されます。このドキュメントのルールのみが適用されます。
envCLICLI プロセスにマージされた環境変数。テレメトリ、自動更新、モデル名オーバーライドに使用します。
hooksCLI組織全体の フック
これらの設定はネットワーク経由で到着するため、CLI は、シェルコマンドを実行したり、トラフィックがどこに行くかを変更したりできるものを適用する前に、各開発者に 1 回限りのセキュリティ承認ダイアログを表示します。ダイアログは以下をカバーします:
  • hooks
  • env 変数。CLI の組み込みセーフリストにない
  • apiKeyHelperstatusLine などのシェル実行設定
  • マネージド CLAUDE.md コンテンツ
セーフリストは、どの env 変数が承認なしで適用されるかを決定します:
  • セーフリスト上:自動更新とモデル名変数
  • セーフリストにない:プロキシ変数、ベース URL 変数、OTEL_EXPORTER_OTLP_ENDPOINT
ゲートウェイの テレメトリ 設定は OTEL_EXPORTER_OTLP_ENDPOINT をプッシュするため、telemetry.forward_to を設定すると、各インタラクティブクライアントで承認ダイアログがトリガーされます。-p フラグを使用した非インタラクティブ実行は、ダイアログをスキップし、承認なしで設定を適用します。ダイアログは、組織から開発者を保護するのではなく、開発者のマシンを侵害または敵対的なゲートウェイから保護するため、-p スキップは意図的なギャップではなく意図的です。 開発者が拒否した場合、Claude Code は設定を適用せずに終了します。新しいフックまたは非セーフ env var を広いポリシーにプッシュすることは、マッチする開発者の次の起動時に承認プロンプトを意味します。 cli キーは以前のリリースで settings という名前でした。その綴りはまだエイリアスとして受け入れられていますが、新しいデプロイメントは cli を使用する必要があります。

他のマネージドソースとの優先順位

デバイスにローカル managed-settings.json または MDM 配信ポリシーもある場合、マネージドソースはマージされません。最優先ソースはすべてのポリシー設定を提供します。この順序でランク付けされます。最優先順位が最初:
  1. ポリシーヘルパー
  2. ゲートウェイ配信設定
  3. MDM。Windows の HKLM レジストリまたは macOS の plist 経由
  4. managed-settings.json ファイル
  5. HKCU レジストリ。Windows のみ
埋め込みホストは SDK managedSettings オプションを通じてポリシーを提供できます。デフォルトでは無視され、マネージドソースが parentSettingsBehavior: "merge" でオプトインした場合のみ適用されます。ポリシーを厳しくできますが、緩くすることはできません。 例外は、管理者ソースが設定する場合に尊重される小さなキーセットです。ユーザー書き込み可能な HKCU 層は除外されます:
  • sandbox.network.allowManagedDomainsOnlysandbox.filesystem.allowManagedReadPathsOnly:ロックされている場合、対応する許可リストはソース全体で和集合されます。
  • allowAllClaudeAiMcps:claude.ai MCP サーバー許可リストの許可のみオーバーライド
  • sandbox.bwrapPathsandbox.socatPathサンドボックスヘルパーバイナリへのファイルシステムパス
allowManagedPermissionRulesOnlydisableBypassPermissionsMode はクロスソースではないため、勝利ソースの値のみが適用されます。 ゲートウェイポリシーはマシン上のすべての Claude Code 呼び出しに適用されます。非インタラクティブ claude -p 実行と Agent SDK によって生成されたセッションを含みます。ゲートウェイがスタートアップ時に到達不可能な場合、署名されたセッションはポリシーなしで実行するのではなく、エラーで終了します。
ポリシーの cli ブロック内の mcpServers はゲートウェイブートで拒否されます。グループごとの MCP 配布は利用できません。各デバイスでファイルベースの managed-mcp.json を通じて MCP サーバーをデプロイするか、開発者がローカルで追加できるようにします。

telemetry

CLI は OpenTelemetry Protocol(OTLP)を HTTP メトリクス、ログ、有効な場合はトレースでゲートウェイに送信します。ゲートウェイはそれらを逐語的に各設定先にリレーします。使用状況の監視で、CLI が発行するメトリクスとイベントを参照してください。 CLI は、ゲートウェイ発行 JWT から読み込まれた認証されたユーザーのアイデンティティで各エクスポートにスタンプを付けます:user.iduser.emailuser.groups 属性。開発者ごとのコストと使用状況の属性は、開発者側の設定なしで機能します。
telemetry:
  forward_to:
    - url: https://otel-collector.internal.example.com
      headers:
        Authorization: ${OTLP_TOKEN}
      # シグナルごとのオプトイン。デフォルト:メトリクスのみ。
      metrics: true
      logs: false
      traces: false
    - url: https://api.datadoghq.com/api/v2/otlp
      headers:
        DD-API-KEY: ${DD_API_KEY}
各宛先は metricslogstraces に独立してオプトインし、デフォルトはメトリクスのみです。シグナルは感度が異なります:
  • メトリクス:トークンカウント、リクエストカウント、レイテンシなどの集計カウンター
  • ログとトレース:完全な bash コマンド、ツール入力、ファイルパスを含むことができます。Claude Code が開発者のマシンで行うすべてをカバーします。
ログとトレースは、アクセス制御と保持ポリシーがデータを保証する宛先でのみ有効にします。
テレメトリは CLI でデフォルトでオフです。telemetry.forward_tolisten.public_url と一緒に設定するとオンになります。ゲートウェイは 5 つの env var を /managed/settings を通じてすべての接続されたクライアントにプッシュします:
  • CLAUDE_CODE_ENABLE_TELEMETRY=1
  • OTEL_METRICS_EXPORTER=otlp
  • OTEL_LOGS_EXPORTER=otlp
  • OTEL_TRACES_EXPORTER=otlp
  • OTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
プッシュされたエンドポイントはパブリック URL から構築されるため、メトリクスとログは開発者またはポリシーからの OTEL 設定を必要としません。プッシュされた設定はマネージド層で適用され、開発者がローカルで設定する OTEL_* 変数をオーバーライドします。 トレースはさらに各クライアントで CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 を必要とします。ゲートウェイはその変数をプッシュしないため、マネージドポリシーの env ブロックを通じて設定します。CLI のセーフリストにはないため、ポリシーを通じてそれを配信することは、プッシュされた OTLP エンドポイントがすでにトリガーする同じ セキュリティ承認ダイアログでカバーされます。 protobuf と JSON OTLP エンコーディングの両方がリレーされ、OpenTelemetry 互換バックエンドは宛先として機能します。

HTTP チューニング

4 つのオプションのトップレベルブロック、access_controllimitstimeoutsrate_limits。HTTP サーフェスをチューニングします。デフォルトはほとんどのデプロイメントに適しています。
ブロックキーデフォルト説明
access_controlallow_cidrs / deny_cidrstrusted_proxies 解決後のクライアントアドレスによるインバウンド IP 許可/拒否。deny_cidrs が最初にチェックされます。クライアントがマッチする場合、allow_cidrs もマッチしても拒否されます。allow_cidrs が空でない場合、ゲートウェイはデフォルト拒否です。/healthz/readyzallow_cidrs から除外されます。
limitsmax_request_bytes32 MiB最大インバウンドリクエストボディ。サイズを超えるリクエストはボディがバッファリングされる前に 413 を取得します。大きなファイルまたは画像リクエストの場合は増やします。
limitsmax_request_header_bytes未設定設定すると、サイズを超えるヘッダーは 431 を返します。
limitsmax_url_length未設定設定すると、長すぎる URL は 414 を返します。
timeoutsupstream_ttfb_ms120000アップストリームのレスポンスヘッダー(初バイト時間)を待つ最大時間。レスポンスボディはその後、ウォールクロックキャップなしでストリーミングされます。直接 Anthropic アップストリームパスに適用されます。Bedrock、Agent Platform、Foundry はプロバイダー SDK 独自のタイムアウトで制限されます。
rate_limitsdevice_authorization.max / .window_seconds30 / 600認証されていないデバイス認可エンドポイントの IP ごとのレート制限。共有エグレス IP または NAT の背後にある大規模な組織の場合は増やします。これらの制限は、デバイスグラント サインインフローにのみ適用され、/v1/messages 推論には適用されません。ユーザーコードブルートフォース耐性を参照してください。
rate_limitsdevice_verify.max / .window_seconds10 / 600/device での user_code 送信の IP ごとのレート制限。

完全な例

この完全なリファレンス設定はすべてのコアセクションを実行します。HTTP チューニングブロックはデフォルトを保持します。コピーして、不要なものを削除し、値を入力します。クイックスタートの設定はこれの最小バージョンです。
gateway.yaml
# 実行:
#   claude gateway --config gateway.yaml
#
# 運用ログの詳細度は CLAUDE_GATEWAY_LOG_LEVEL
# 環境変数で制御されます(info | warn | error;デフォルト info)。監査イベントには影響しません。常に発行されます。

listen:
  host: 0.0.0.0
  port: 8080
  public_url: https://claude-gateway.internal.example.com
  # TLS 終了 ingress の背後で実行する場合は tls ブロックを省略します。
  # tls:
  #   cert: /certs/gateway.crt
  #   key: /certs/gateway.key
  # trusted_proxies:
  #   - 10.0.0.0/8

oidc:
  issuer: https://example.okta.com
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains:
    - example.com
  # Okta org サーバーが発行者の場合は必須。id_token はメールとグループを省略できます。ゲートウェイは /userinfo から埋めます。
  userinfo_fallback: true
  # allowed_groups: [claude-code-users]
  # Okta はグループスコープがリクエストされ、アプリのグループクレームフィルターが許可する場合のみグループを発行します。以下のコントラクターポリシーはグループでマッチするため、スコープはここでリクエストされます。
  scopes: [openid, profile, email, offline_access, groups]
  # extra_auth_params: { access_type: offline, prompt: consent }  # Google
  # groups_claim: groups          # Entra アプリロール:`roles` を使用
  # email_claim: email

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}   # openssl rand -base64 32
  # ttl_hours: 1

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}
  # max_connections: 5

# /v1/organizations/spend_limits を有効にします(Anthropic Admin API をミラーリング)
# および /v1/messages での開発者ごとの支出強制。無効にするには省略します。
# キャップ自体は admin API 経由で設定されます。ここではありません。
# admin:
#   write_keys:
#     - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
#   read_keys:
#     - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
#   admin_groups: [platform-finops]
#   blocked_message: request an increase at https://go.example.com/claude-limits
#   # audit_retention_days: 365
#   # spend_retention_months: 13
#   # identity_retention_days: 90
#   # group_limit_mode: min

# enforcement:
#   fail_closed_on_error: false

upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

  # - provider: bedrock
  #   region: us-east-1
  #   auth: {}

  # - provider: vertex
  #   region: us-east5
  #   project_id: example-prod
  #   auth: {}

  # - provider: foundry
  #   resource: example-foundry
  #   auth: { use_azure_ad: true }

auto_include_builtin_models: true
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      anthropic: claude-opus-4-8
      # bedrock: us.anthropic.claude-opus-4-8
      # vertex: claude-opus-4-8
      # foundry: <your-opus-deployment-name>
  - id: claude-sonnet-4-6
    label: Claude Sonnet 4.6
    upstream_model:
      anthropic: claude-sonnet-4-6
  - id: claude-haiku-4-5
    label: Claude Haiku 4.5
    upstream_model:
      anthropic: claude-haiku-4-5

managed:
  policies:
    - match: { groups: [contractors] }
      cli:
        availableModels: [claude-haiku-4-5]
        # Default ピッカーオプションを availableModels に制限します。デフォルトの代わりに、コントラクターが default で 400 を取得しないようにします。
        enforceAvailableModels: true
        # allow はこれらのツールを自動承認します。残りをブロックしません。
        # ツールを制限するには deny ルールを追加します。
        permissions: { allow: [Read, Grep] }
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
        permissions:
          allow: [Read, Grep, Bash, Edit]
          deny: ["WebFetch"]
        env: { HTTP_PROXY: http://proxy.example.com:8080 }

telemetry:
  forward_to:
    - url: https://otel.internal.example.com:4318
      headers:
        Authorization: Bearer ${OTEL_TOKEN}

クライアント側マネージド設定

上記のすべてはゲートウェイサーバーを設定します。開発者マシンをそれに指すことは、各デバイスで別々に設定されます。Claude Code の マネージド設定 を通じて。ゲートウェイはこれらのキーをプッシュできません。ゲートウェイがどこにあるかをクライアントに伝えるものだからです。 CLI の場合、OS ごとの managed-settings.json に両方のキーを設定します:
{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
そのファイルを各デバイスにデプロイします。通常は MDM プラットフォーム経由。ファイルパスはプラットフォームによって異なります:
プラットフォームパス
macOS/Library/Application Support/ClaudeCode/managed-settings.json、または com.anthropic.claudecode マネージド設定ドメイン
Linux と WSL/etc/claude-code/managed-settings.json
WindowsC:\Program Files\ClaudeCode\managed-settings.json、または HKLM レジストリ経由のグループポリシー
forceLoginGatewayUrlforceLoginMethod"gateway" 値は、管理者制御マネージド層からのみ尊重されます。開発者が独自の ~/.claude/settings.json で設定しても効果がありません。