Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry 向け Claude アプリゲートウェイ

SSO サインイン、グループごとのモデルアクセス、OTLP テレメトリを備えた自己ホスト型ゲートウェイを通じて、Amazon Bedrock、Claude Platform on AWS、Google Cloud、または Microsoft Foundry で Claude Code を実行します。

Claude アプリゲートウェイは、開発者の Claude Code クライアントとモデルプロバイダーの間に位置する自己ホスト型サービスです。開発者は API キーやクラウド認証情報を保持する代わりに、企業の ID プロバイダー（IdP）でサインインします。ゲートウェイはアップストリーム認証情報を保持し、IdP グループによるモデルアクセスと管理設定を強制し、使用状況テレメトリを独自の可観測性スタックにリレーします。

これは claude バイナリに含まれているため、ラップトップで Claude Code を実行する同じ実行ファイルが claude gateway --config gateway.yaml でゲートウェイサーバーを実行します。

このページでは以下をカバーしています。

• Claude アプリゲートウェイを使用する理由、独自に実行する場合に何が追加されるか、および他の何かがより適切な場合
• 前提条件を含むクイックスタート。ゲートウェイをゼロからサインイン済みの開発者まで進めます
• 開発者の接続。管理設定を通じてゲートウェイ URL を設定することを含みます
• 可用性と制限事項。ゲートウェイを通じてどの Claude Code 機能が機能するか、およびサーバーが何をサポートするかをカバーしています

関連ページはさらに詳しく説明しています。設定リファレンスはクイックスタートが書き込む YAML ファイルのすべてのオプションをカバーし、デプロイメントガイドは IdP ごとのセットアップ、Kubernetes と Cloud Run デプロイメント、および運用をカバーしています。

Claude apps gateway を使用する理由

ゲートウェイの概要はゲートウェイが何をするか、なぜ実行するかをカバーしています。Claude apps gateway は Anthropic 独自のゲートウェイで、claude バイナリに組み込まれており、各 Claude Code リリースと一緒にテストされているため、Claude Code が送信するヘッダーとリクエストフィールドを、オペレーターが個別の許可リストを維持することなく転送します。デプロイされると、以下が得られます。

• 認証情報：アップストリーム API キーまたはクラウド認証情報は、インフラストラクチャ内にのみ存在します。開発者は企業 SSO で認証し、短期間有効なベアラートークンを受け取るため、オフボーディングは IdP で発生します。ユーザーをプロビジョニング解除すると、ゲートウェイアクセスはセッション有効期間内に期限切れになります。デフォルトは 1 時間です。
• アクセス制御：IdP グループはモデル許可リストと管理設定ポリシーにマップされます。ゲートウェイはモデルアクセスをサーバー側で強制し、許可されていないモデルのリクエストを拒否し、各グループの管理設定ポリシーを選択します。CLI は管理設定層でこれを適用します。異なるチームは異なるモデル、ツール、および権限を取得し、開発者はポリシーがロックしているものをオーバーライドできません。
• 設定配信：ゲートウェイは管理設定をサインイン済みクライアント自体に配信し、claude.ai 管理コンソールからのサーバー管理設定の場所を取ります。
• テレメトリ：各設定先は、デフォルトではトークン数、モデル、ユーザーアイデンティティ、レイテンシを含むOpenTelemetry Protocol（OTLP）メトリクスを受け取り、ログとトレースは宛先ごとのオプトインです。
• アップストリームルーティング：クライアントは Anthropic Messages API をゲートウェイに話しかけ、ゲートウェイは各アップストリーム（Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry、または Anthropic API）に対して変換し、それらの間でフェイルオーバーします。開発者が気付いたり再設定したりすることなく、リージョン、プロバイダー、またはフェイルオーバー順序を変更できます。

ゲートウェイを通じてどの Claude Code 機能が機能するか、およびサーバー自体が何をサポートするかについては、以下の可用性と制限を参照してください。コスト、バイパス、複数ゲートウェイの実行、サーバーレスプラットフォームなどの決定については、デプロイメントガイドを参照してください。

その他のゲートウェイ実装

既に要件を満たす LLM ゲートウェイまたは API ゲートウェイを実行している場合は、それを使い続けてください。その他の LLM ゲートウェイは Claude Code をそれに対して設定することをカバーしています。

ゲートウェイ互換性ガイドは、Claude Code が任意のゲートウェイから期待するもの、つまり呼び出すエンドポイント、転送するヘッダーとボディフィールド、およびそれらが削除されたときに何が機能しなくなるかを文書化しています。実行中の Claude apps ゲートウェイは、GET /protocol で独自のプロトコルリファレンスを提供し、Claude Code クライアントに公開するエンドポイント（SSO サインイン、推論、管理設定配信、モデル検出、テレメトリ）を説明しています。デプロイされたゲートウェイ（例えば、以下のクイックスタートが生成するもの）から curl https://claude-gateway.internal.example.com/protocol で取得します。

プロトコルへの破壊的な変更は事前に発表されますが、無期限の後方互換性は保証されません。

クイックスタート

このクイックスタートは最小限のパスを説明しています。IdP で OAuth クライアントを登録し、gateway.yaml を書き、Docker Compose で Postgres と一緒にゲートウェイを実行し、エンドツーエンドでサインインを確認します。Amazon Bedrock アップストリームを使用します。Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry、および Anthropic API は、設定リファレンスに示されているように upstreams ブロックをスワップすることで同様にサポートされます。最後に、開発者が /login できるゲートウェイがあります。

前提条件

開始する前に、以下を用意してください。

ステップ

listen:
host: 0.0.0.0
port: 8080
# ホストがループバックアドレスでない限り必須。IdP
# redirect_uri とディスカバリードキュメントに使用されます。
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # /.well-known/openid-configuration を提供する必要があります
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # 組織外の id_tokens を拒否します
userinfo_fallback: true                  # id_token が email/groups を省略する IdP の場合。それ以外の場合は無害です

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # IdP プロビジョニング解除時の失効レイテンシもバウンドします

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # 管理 Postgres の場合は ?sslmode=require を追加します

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # 空：AWS デフォルト認証情報チェーン
# （IRSA、EC2/ECS タスクロール、環境変数、~/.aws）

# モデルはアップストリームごとに自動的に変換されます。組み込みカタログ
# は claude-opus-4-8 を us.anthropic.claude-opus-4-8 にマップし、
# Bedrock がサポートするすべての Claude モデルに対して同様にマップします。false に設定し、
# `models:` リストを追加して、特定のモデルのみを公開します。
auto_include_builtin_models: true

services:
gateway:
image: registry.example.com/claude-gateway:2.1.198
ports: ["8080:8080"]
volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
environment:
OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
# AWS 認証情報：本番環境では、これらを省略し、インスタンス
# ロールを使用します。ローカル Compose テストの場合、独自のものを渡します。
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
depends_on:
postgres:
condition: service_healthy
postgres:
image: postgres:16-alpine
environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gw"]
interval: 5s
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
"issuer": "https://claude-gateway.internal.example.com",
"device_authorization_endpoint": "…/oauth/device_authorization",
"token_endpoint": "…/oauth/token",
"grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
"device_code": "…",
"user_code": "WDJB-MJHT",
"verification_uri": "https://claude-gateway.internal.example.com/device",
"verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
"expires_in": 600,
"interval": 5
}

開発者を接続する

開発者は独自のラップトップから 1 つのブラウザサインインで接続し、企業の仕事用アカウントを使用します。claude.ai アカウント、API キー、またはサブスクリプションは必要ありません。モデルへのリクエストは組織のアップストリーム認証情報を使用してゲートウェイを通じて行くためです。接続は、MDM 経由でプッシュするクライアント側管理設定によって駆動されるため、開発者側に手動セットアップはありません。このセクションは管理者が設定するものをカバーしています。

CLI はゲートウェイの TLS リーフ証明書を最初の接続時にフィンガープリントし、ホスト名ごとにピン留めします。サインイン時、サイレントセッション更新時、および管理設定フェッチ時にそのピンを再度チェックしますが、推論リクエストはピンなしで標準 TLS 検証を使用します。HTTPS プロキシを通じてルーティングされたリクエストはピンチェックをスキップするため、ゲートウェイホストを NO_PROXY に追加して直接接続を保つようにします。

期待される SHA-256 フィンガープリントをゲートウェイ URL と一緒に公開して、開発者が比較するものを持つようにします。/login プロンプトはフィンガープリントの最初の 16 文字を小文字の 16 進数でコロンなしで表示します。証明書ファイルからこの形式で完全なフィンガープリントを出力するには、以下を実行します。

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

証明書がローテーションされると、すべての開発者は再度信頼プロンプトを見るため、ローテーションを計画されたイベントとして扱い、フィンガープリントを再公開します。ゲートウェイポリシーに承認が必要な設定が含まれている場合、開発者は新しい証明書を受け入れた後、その承認ダイアログも再度見ます。Claude Code は承認メモリをピン留めされた証明書にキーイングするためです。

ゲートウェイはトークンレスポンスでオプションの email フィールドを返して、サインインが使用したアカウントに名前を付けることができます。そうする場合、開発者は Claude Code が認証情報を保存する前にアカウントを確認します。確認されたサインイン後、/status はアカウントを表示します。

確認には開発者マシンで Claude Code v2.1.275 以降が必要です。そのバージョンより下のクライアントはフィールドを無視します。claude バイナリのゲートウェイサーバーはフィールドを返さないため、そのサインインは確認なしで完了します。

開発者がサインインすると、モデルピッカーは開発者の availableModels 許可リストのモデルを表示します。管理設定は起動時に適用され、1 時間ごとに更新され、テレメトリはコレクターにルーティングされます。

セッションは ttl_hours 有効期限の前にサイレントに更新されます。IdP プロビジョニング解除後の更新が失敗すると、Claude Code は開発者に再度ログインするよう促します。

ゲートウェイ URL を設定する

MDM 経由またはディスク上で直接デプロイする OS ごとの管理設定ファイルに 3 つのキーが入ります。forceLoginMethod と forceLoginGatewayUrl は /login を Cloud gateway 画面で URL が入力された状態で直接開き、parentSettingsBehavior: "merge" は Claude Desktop がゲートウェイの出力許可リストを起動する Claude Code セッションに配信できるようにします。これはClaude Desktop セッションにポリシーを配信するで説明されています。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

開発者は Enter キーを押して接続します。最初の接続 TLS フィンガープリントプロンプトは引き続き表示されます。ファイルがマシンに配置されると、ゲートウェイサインインを完了していない開発者は、Administrator policy requires a Cloud gateway sign-inで説明されているメッセージの 1 つを見ます。CLAUDE_CODE_USE_BEDROCK などの環境変数を通じてクラウドプロバイダーを選択する開発者はゲートウェイサインインを必要としません。

開発者はこれを手動で設定することはできません。ログインピッカーにはゲートウェイオプションがなく、forceLoginGatewayUrl は開発者独自の設定ファイルでは無視されます。URL なしの forceLoginMethod のみでは、開発者を「IT 管理者に連絡してください」メッセージのままにします。ログインキーは、マシンにプッシュするファイルに属し、ゲートウェイの managed.policies[].cli ブロックには属しません。このブロックは既に接続されているクライアントにのみ到達します。

公開アドレス空間でゲートウェイを許可する

一部の組織は、キャリアの独自アドレス空間またはレガシー /8 など、所有する公開 IPv4 ブロックから内部ネットワークに番号を付けるため、ゲートウェイはプライベートアドレスを持つことができません。これらのブロックを gatewayInternalNetworks 管理設定にリストします。/login は、開発者のマシンが同じブロック内のアドレスからそれに接続するときに、リストされたブロック内のゲートウェイを受け入れます。これには開発者マシンで Claude Code v2.1.268 以降が必要です。以前のバージョンはキーを無視し、プライベートアドレスルールを適用します。

キーをログインキーと同じ管理設定ソースに追加します。管理設定ファイル、MDM プロファイル、またはレジストリポリシーです。Claude Code はユーザー、プロジェクト、およびサーバー管理設定でそれを無視します。

この例は 1 つのブロックを宣言します。203.0.113.0/24 を独自のブロックに置き換えます。これはドキュメンテーション範囲であり、Claude Code はそれを拒否します。

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code はゲートウェイに接続する前に /login でリストを検証します。

• 各エントリは IPv4 ブロックで、最初のアドレスと /8 から /32 のプレフィックスとして記述されます。
• リストは最大 4 つのブロックを保持し、2 つは重複しません。
• ブロックはプライベートアドレス空間と重複しません。10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、169.254.0.0/16、および 100.64.0.0/10。/login は既にこのキーなしでそこのゲートウェイを受け入れます。
• ブロックは組織のネットワークになることのない空間と重複しません。198.18.0.0/15 と 192.0.0.0/24。VPN と NAT64 クライアントはローカルアドレスとして保持します。ドキュメンテーション範囲 192.0.2.0/24、198.51.100.0/24、および 203.0.113.0/24。および予約範囲 0.0.0.0/8、192.88.99.0/24、およびマルチキャスト 224.0.0.0/4。一部の大規模ネットワークが内部ユニキャスト空間として使用する 240.0.0.0/4 内のブロックを宣言できます。

managed-settings.json とその managed-settings.d/ ドロップインファイルのブロックは 1 つのリストに結合され、これらの制限は結合されたリストに適用されます。ブロックを絞るには、ドロップインで 2 番目の重複するものを追加するのではなく、そのエントリを置き換えます。/login は重複を拒否します。

エントリがルールを破るか、値が文字列のリストでない場合、Claude Code はそのマシンでのすべての新しいゲートウェイサインインを拒否し、メッセージで問題に名前を付けます。プライベートアドレスのゲートウェイへのサインインも失敗し、既存のサインインは機能し続けます。1 つのマシンでその値を試してからデプロイします。Claude Code はまた、報告する無効な管理設定の中に誤った型の値をリストします。

有効なリストでは、/login はアドレスがリストされたブロック内にあるゲートウェイに 3 つのチェックを適用します。

• ゲートウェイのホスト名が解決するすべてのアドレスはそのブロック内にあります。Claude Code は、プライベートおよび IPv6 アドレスを含む、それの外にもレコードを持つ名前を拒否します。
• 開発者のマシンは同じブロック内からの接続です。Claude Code は NAT の背後、コンテナまたは WSL2 内、またはアドレスプールがブロックの外にある VPN 上のマシンを拒否し、マシンが接続したアドレスに名前を付けます。
• 接続は直接です。HTTPS_PROXY がゲートウェイホストに適用される場合、/login は拒否し、追加する NO_PROXY エントリに名前を付けます。

3 つすべてが通過すると、信頼プロンプトはマシンのアドレス、ゲートウェイのアドレス、および両方を含む宣言されたブロックに名前を付ける行を追加します。

キーは他のゲートウェイについては何も変わりません。プライベートアドレスのゲートウェイへのサインインは以前と同様に機能し、リストされたすべてのブロックの外の公開アドレスのゲートウェイへのサインインは以前と同様に拒否されます。

宣言されたブロックはサインインできるユーザーを絞りますが、マシンがどこにあるかを証明しません。そのため、組織が管理するアドレス空間のみを宣言します。クラウドプロバイダーの公開範囲など、他のテナントと共有されるブロックは、それに含まれるすべてのユーザーが同じチェックを通過できるようにします。

Claude Desktop セッションにポリシーを配信する

Claude Desktop は Cowork タブと Code タブ、および有効にした場合は Chat タブを、埋め込み Claude Code セッションで実行し、それらのモデルリクエストをゲートウェイを通じて送信します。ゲートウェイが /user/bootstrap で提供する設定から構築されたポリシーを各セッションに渡します。モデル許可リスト、無効化されたツール、および一致したポリシーの cli ブロックから派生した出力許可リスト、およびdesktop オーバーレイです。

フック、env、および Bash(npm *) のようなスコープ付き権限ルールなどの他の cli キーは、/login を通じてサインインするクライアントにのみ到達します。Claude Desktop はゲートウェイ URL を独自の管理設定から読み取り、ゲートウェイ URL を設定するの forceLoginMethod と forceLoginGatewayUrl キーとは別の独自のフローでサインインします。

起動プロセスによって渡される設定は親設定です。Claude Code は、管理者がデプロイした管理ソースを持つマシンで親設定を無視します。ただし、ポリシーを配信するソースが parentSettingsBehavior: "merge" を設定する場合を除きます。

どのマシンがオプトインを必要とするか

Claude Desktop のみを実行するマシンはそれを必要とします。Claude Desktop は埋め込みセッションにモデルリストと無効化されたツールリストを適用しますが、出力許可リストは親設定としてのみそれらに到達します。WebFetch ドメインルールとサンドボックスネットワークルールの形式です。オプトインなしでは、これらのセッションは出力制限なしで実行され、何も警告しません。ゲートウェイはポリシーが許可しないモデルの推論リクエストを引き続き拒否します。

プラグインマーケットプレイス許可リストも、埋め込みセッションには親設定としてのみ到達します。Claude Desktop の管理設定でユーザーが追加したプラグインマーケットプレイスをオフにすると、Claude Desktop 2.16120.0 以降は組織がプロビジョニングしなかったマーケットプレイスを非表示にし、それらからのインストールを拒否します。埋め込みセッションがそれらのマーケットプレイスから既にインストールされているプラグインの読み込みを停止するために、親設定として strictKnownMarketplaces リストを送信します。オプトインなしでは、Claude Code はそのリストを無視し、それらのプラグインは読み込み続けます。

/login を通じてサインインする開発者のマシンはそれを必要としません。各 Claude Code セッションはゲートウェイからポリシーをフェッチします。

policyHelperが管理設定を提供するフリートはそれを使用できません。Claude Code はそれらのフリートで親設定をマージしません。ヘルパーの出力からのみ管理設定を読み取るためです。

オプトインを設定する

ゲートウェイ URL を設定するから管理設定スニペットをデプロイし、ファイルを上回るクライアント側ソースにミラーリングしてから検証します。

親設定を制限する

parentSettingsBehavior: "merge" をデプロイすると、Claude Code を起動するホストプロセスは親設定を提供できます。Claude Desktop だけでなく、Agent SDK アプリケーションまたは IDE 拡張機能も同様です。

Claude Code は親設定を制限キーの許可リストに対してフィルタリングしますが、許可されたキーの中には、制限するのではなくアクセスを許可できるものもあります。allowManaged*Only ロックを設定しない限り、ホストが提供する権限許可ルールとサンドボックス許可リストが適用されます。ポリシーの deny ルールと ask ルールはどちらの場合でも有効です。それらは任意の許可ルールの前に評価されます。

Claude Code は親が提供した sandbox.credentials エントリを削除形式で転送します。

• deny エントリ：path または name とモードのみで転送されます。
• mode: maskを持つファイルエントリ：センチネルのみとして転送され、injectHosts が空のリストである全ファイルマスクとして。プロキシは親が提供したエントリの実際の値を任意のプラットフォームで置き換えることはありません。すべての構造化マスキングフィールドも削除されるため、親が提供した抽出パターンは別のソースが同じパスに設定するより厳密なマスクを置き換えることはできません。
• mode: mask を持つ envVars エントリ：転送されません。deny は親チャネルが envVars エントリを通じて表現できる唯一の制限です。
• awsPairs と sigv4：制限のみ転送されます。sigv4 からは deny 値のみが保持され、親が sigv4 ブロックをまったく定義する場合、すべての 3 つのリクエスト形式 streaming、presigned、および sigv4a を deny にピン留めします。awsPairs ペアは再署名できる形式では転送されません。従来の AWS 変数の 1 つに名前を付けるペアは、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、および AWS_SESSION_TOKEN の自動ペアリングを抑制したままにする不活性エントリに置き換えられます。

ロックをデプロイする

親設定をフィルターがサポートする制限のみに可能な限り近く保つために、すべての 5 つの allowManaged*Only ロックと、それらが管理する許可リストを、マージオプトインと同じソースに追加します。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

OS ポリシー（HKLM レジストリポリシーまたは管理設定プリストなど）はこのファイルを上回るため、ファイルではなくそれを通じてスニペット全体を配信します。ゲートウェイのリモート管理設定は OS ポリシーとファイルソースを上回りますが、接続されたクライアントにのみ到達します。ロック、許可リスト、およびマージオプトインをポリシーの cli ブロックにミラーリングし、このファイルをデプロイしたままにします。接続しないマシン（Claude Desktop のみを実行するものを含む）はファイルからのみポリシーを取得するためです。

ソース全体のロック動作

1 つのロックを設定しても、他のロックは制限されません。各キーは設定リファレンスで文書化されています。

勝者より下の管理ソースから、2 つのサンドボックスロックは引き続き適用され、allowManagedPermissionRulesOnly は引き続き親が提供した許可ルールと additionalDirectories をブロックします。Claude Code v2.1.273 以降では、MCP サーバーロックも勝者より下のソースから適用され、それがオンの間、管理 allowedMcpServers リストは、それを設定している最優先の管理ソースから取得されます。

フックロックと allowManagedPermissionRulesOnly の開発者独自のルールへの影響は、デフォルトで勝者ソースが必要です。Claude Code が管理ソースを組み合わせる方法の managedSourcesBehavior マージオプトインの下で、Claude Code はすべてのロックについてすべてのソースが設定する最も厳密な値を適用します。policyHelper フリートでは、Claude Code はロックをヘルパーの出力からのみ読み取ります。

各ロックは Claude Code が開発者独自のエントリをその設定について無視するようにするため、組織の許可リストをロックの隣に含めます。

• ネットワークドメイン：空の管理ドメインリストでロックするとサンドボックス化された全アウトバウンドトラフィックがブロックされます。
• MCP サーバー：どの管理ソースにも親が提供した設定にも allowedMcpServers がない状態でロックすると、deniedMcpServers がブロックしないすべてのサーバーが読み込まれます。
• 読み取りパス：allowRead エントリは denyRead 領域内のパスのみを再許可するため、管理 denyRead とペアにします。

ロックがカバーしない設定

5 つのロックすべてが設定されていても、以下の親が提供した設定はフィルターを通過します。

• forceLoginOrgUUID：最優先の管理ソースが組織 UUID を設定しない場合、Claude Code は親が提供した値を尊重します。ゲートウェイサインインはこのキーをチェックしません。最優先の管理ソースの組織 UUID は親の値をブロックし、Claude Code が強制するものです。
• allowedMcpServers：有効な管理リストがない場合、Claude Code は親が提供した許可リストを尊重します。allowManagedMcpServersOnly はそれをブロックしません。ロックは勝者となったリストを管理値として強制し、どの管理ソースもリストを提供しない場合は親が提供したリストも含まれるためです。最優先の管理ソースのリストは親のリストをブロックし、Claude Code が強制するリストになるため、ロックの隣のそこに allowedMcpServers を設定します。v2.1.223 より前では、任意の管理ソースのいずれかのキーの値は親の値をブロックしました。
• availableModels：勝者の管理ソースが設定しない場合、Claude Code は親が提供したモデルリストを尊重します。フリートがモデルを制限する場合、勝者ソースに availableModels を設定します。
• allowedProviders：勝者の管理ソースが設定しない場合、Claude Code は親が提供した API プロバイダー許可リストを尊重します。フリートが開発者の使用できる API プロバイダーを制限する場合、勝者ソースに allowedProviders を設定します。Claude Code v2.1.285 以降が必要です。
• strictKnownMarketplaces：勝者の管理ソースが設定しない場合、Claude Code は親が提供したプラグインマーケットプレイス許可リストを尊重します。Claude Desktop 2.16120.0 以降は、その管理設定でユーザーが追加したプラグインマーケットプレイスをオフにするときに 1 つを送信します。フリートがマーケットプレイスを制限する場合、勝者ソースに strictKnownMarketplaces を設定します。Claude Code v2.1.282 以降が必要です。
• blockedMarketplaces：親が提供したマーケットプレイスブロックリストは通過し、管理ソースが設定するブロックリストに追加されます。ブロックリストはさらに制限することのみができるためです。Claude Code v2.1.282 以降が必要です。
• strictPluginOnlyCustomization：このキーはロックに関係なくフィルターを通過し、Claude Code が開発者独自のカスタマイズ（保護フックを含む）を無視するようにします。ロックはそれをブロックしません。

デフォルトの最初の勝ちの設定の下では、管理値が親の値をブロックするのは、それが最優先の管理ソースにある場合のみです。ただし、MCP サーバーロックがオンの間の allowedMcpServers は除きます。managedSourcesBehavior マージオプトインの下では、Claude Code が管理ソースを組み合わせる方法が代わりにどのソースの値が適用されるかを示します。

Claude Desktop を接続する

Claude Desktopは異なる MDM キーを通じて同じゲートウェイに接続します。Claude Desktop の管理設定で bootstrapUrl を <listen.public_url>/user/bootstrap に設定し、ユーザーのポリシーを desktop キーでオプトインします。Claude Desktop オーバーレイは両方の部分をカバーしています。ゲートウェイサーバーで Claude Code v2.1.203 以降が必要です。

Claude Desktop は同じブラウザ SSO ステップでゲートウェイのアイデンティティプロバイダーを通じて開発者にサインインし、Anthropic ではなくゲートウェイから設定をフェッチします。モデルアクセスとポリシーは CLI と同じグループごとのルールに従います。CLI と Claude Desktop の両方を使用する開発者は各々に個別にサインインします。ゲートウェイセッションはそれらの間で共有されません。

接続すると、Claude Desktop は有効なすべてのタブからモデルリクエストをゲートウェイを通じて送信します。デフォルトで Cowork タブと Code タブを表示します。Chat タブもオンにするには、Claude Desktop の管理設定で chatTabEnabled を true に設定するか、Claude Code v2.1.227 以降を実行しているゲートウェイのポリシーの desktop ブロックで設定します。

CI パイプラインとリモートマシン

無人パイプラインのサービストークンフローはありません。ゲートウェイサインインは常にブラウザデバイスフローを実行するため、サインインを承認する開発者がない CI ジョブは認証できません。これらをプロバイダーに対して直接設定します。

開発者がサインインすると、そのマシンでの各 Claude Code セッションはゲートウェイセッションを使用します。非対話的な claude -p 実行と Agent SDK によって開始されたセッションを含みます。Claude Code はゲートウェイポリシーをそれぞれに適用します。

デバイスフローはポーリング CLI を承認ブラウザから分離するため、ディスプレイのないリモート開発ボックスは引き続き機能します。開発者はリモートマシンで SSH 経由で /login を実行し、ラップトップのブラウザで検証リンクを開きます。

開発者に何が強制されるか

これらの保証はすべての /login を通じてサインインしたセッションに適用されます。Claude Desktop が起動する埋め込みセッションはClaude Desktop セッションにポリシーを配信するで説明されているようにポリシーを取得し、テレメトリの箇条書きはそれらのエクスポートがどこに行くかを示します。

• モデルアクセス：ポリシーが許可しないモデルのリクエストは 400 を返し、/model ピッカーはポリシーの availableModels 許可リストにフィルタリングされます。これには、開発者がモデルを選択する前にセッションが開始時に使用するモデルも含まれます。ポリシーが許可するモデルでセッションを開始するを参照してください。
• テレメトリ宛先：/login を通じてサインインしたセッションでは、CLI はローカルに設定された OTEL_EXPORTER_OTLP_ENDPOINT に関係なく、OTLP/HTTP エクスポートをゲートウェイに送信します。ただし、ポリシーがコレクターをエンドポイントとして指定する場合を除きます。ゲートウェイは受け取ったエクスポートを telemetry.forward_to の宛先にリレーします。
  • Claude Desktop が起動する埋め込みセッションでは、CLI はエクスポートを設定された OTEL_EXPORTER_OTLP_ENDPOINT に送信します。CLI はそのエンドポイントがゲートウェイ自体を指す場合にのみ、ゲートウェイセッショントークンをそれらのエクスポートに添付します。
  • 信号に設定された宛先がない場合、ゲートウェイはそれを受け入れて破棄します。
  • 既に Claude Code テレメトリを直接収集する場合は、コレクターを forward_to 宛先として追加するか、ポリシーで指定してリレーをスキップします。
• 認証情報：ゲートウェイトークンはセッションの唯一の認証情報です。Anthropic プロファイルおよび以前の claude.ai ログインはサインイン中は無視されるため、開発者は最初に claude.ai からログアウトする必要はありません。設定された ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、または apiKeyHelper 認証情報、あるいは以前の Claude Console ログインで保存された API キーについては、Administrator policy requires a Cloud gateway sign-inを参照してください。
• 管理設定：ロックされたキーはローカルでオーバーライドできません。CLI はポリシーを起動時に適用し、次の起動時にのみ適用される変更を除いて、毎時間のポーリングで変更を適用します。
• ゲートウェイが到達不可能な状態での起動：サインイン済みセッションは、設定なしで起動するのではなく、約 10 秒後に起動時にエラーで終了します。
• ゲートウェイがセッションを終了した後の起動：起動時の失敗クローズを強制するを参照して、どの起動がゲートウェイからサインアウトした状態で開き、どの起動がゲートウェイが 401 で応答するときに終了するかを確認します。
• プロビジョニング解除：ユーザーが IdP で無効化されたセッションは、次の更新が失敗したときに ttl_hours 内に期限切れになります。
• サインアウト：/logout はゲートウェイ認証情報を開発者のマシンから削除します。
  • ゲートウェイの検出ドキュメントがゲートウェイ URL 独自のスキーム、ホスト、およびポートで revocation_endpoint をアドバタイズする場合、/logout は保存されたトークンをそのエンドポイントに送信して、ゲートウェイがその側でセッションを終了できるようにします。リクエストはベストエフォートであるため、エンドポイントが応答するかどうかに関係なく、サインアウトは開発者のマシンで完了します。失効には開発者マシンで Claude Code v2.1.275 以降が必要です。
  • claude バイナリのゲートウェイサーバーはアドバタイズしないため、そこからのサインアウトは開発者のマシンでのみセッションを終了します。サーバー側でセッションを強制的に終了するには、JWT シークレットローテーションを参照してください。

組織が見ることができるもの

使用状況テレメトリは開発者のアイデンティティ、トークン数、モデル、およびレイテンシを組織のコレクターに伝えます。ゲートウェイはプロンプトまたは完了コンテンツをログまたは保存しません。ログやトレースなどのより豊富なテレメトリが収集されるかどうか。コマンドやファイルパスを含む可能性があるのは、組織の宛先ごとの選択です。

利用可能性と制限事項

この表は、開発者がゲートウェイ経由で接続した場合にどの Claude Code の機能が動作するか、およびゲートウェイサーバー自体が何をサポートしているかをまとめたものです。サポートされていない項目については、「注記」列に代替手段を記載しています。

ゲートウェイは、CLI が送信する anthropic-beta の値をすべてのアップストリームに渡すため、運用者がベータの許可リストを管理する必要はありません。Amazon Bedrock はこのヘッダーを無視するため、Amazon Bedrock に対しては、ゲートウェイがこれらの値をリクエストボディの anthropic_beta フィールドに移します。その他のアップストリームは、送信されたとおりにヘッダーを受け取ります。

次のステップ

クイックスタートは Docker Compose で実行されている最小設定を残します。さらに進めるには。

• グループごとの RBAC、マルチアップストリームフェイルオーバー、またはテレメトリ宛先を追加するなど、最小設定を超えて gateway.yaml を拡張します。設定リファレンスはすべてのオプションをカバーしています。
• Compose から Kubernetes または Cloud Run での本番デプロイメントに移動し、IdP を適切に設定し、セキュリティモデルを確認します。デプロイメントおよび運用ガイドは、IdP ごとのセットアップ、コンテナイメージ要件、ヘルスプローブ、およびトラブルシューティングをカバーしています。
• 個々の開発者またはグループに支出キャップを設定して、暴走ワークロードがコミットメント全体を消費できないようにします。支出制限は管理 API と強制がどのように機能するかをカバーしています。
• AWS での完全な実装例については、ECS Fargate または EKS、Amazon RDS、および Secrets Manager を使用して、AWS にデプロイを参照してください。
• Google Cloud での完全な実装例については、Cloud Run、Cloud SQL、Secret Manager を使用して、Google Cloud にデプロイを参照してください。