Claude アプリゲートウェイは、開発者の Claude Code クライアントとモデルプロバイダーの間に位置する自己ホスト型サービスです。開発者は API キーやクラウド認証情報を保持する代わりに、企業の ID プロバイダー(IdP)でサインインします。ゲートウェイはアップストリーム認証情報を保持し、IdP グループによるモデルアクセスと管理設定を強制し、使用状況テレメトリを独自の可観測性スタックにリレーします。
これは
claude バイナリに含まれているため、ラップトップで Claude Code を実行する同じ実行ファイルが claude gateway --config gateway.yaml でゲートウェイサーバーを実行します。
このページでは以下をカバーしています。
- Claude アプリゲートウェイを使用する理由、独自に実行する場合に何が追加されるか、および他の何かがより適切な場合
- 前提条件を含むクイックスタート。ゲートウェイをゼロからサインイン済みの開発者まで進めます
- 開発者の接続。管理設定を通じてゲートウェイ URL を設定することを含みます
- 可用性と制限事項。ゲートウェイを通じてどの Claude Code 機能が機能するか、およびサーバーが何をサポートするかをカバーしています
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)に対して変換し、それらの間でフェイルオーバーします。開発者が気付いたり再設定したりすることなく、リージョン、プロバイダー、またはフェイルオーバー順序を変更できます。
ゲートウェイ独自のデータプレーンは、Anthropic API が設定されたアップストリームでない限り、Anthropic インフラストラクチャに何も送信しません。テレメトリ、監査ログ、管理設定、および開発者の IdP アイデンティティがどこに行くかを制御し、ゲートウェイはそれらのいずれも Anthropic に送信しません。残りのトラフィック CLI プロセスが送信できる方法と、それを閉じる方法については、コンプライアンスポスチャを参照してください。
その他のゲートウェイ実装
既に要件を満たす 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 できるゲートウェイがあります。
プライベートネットワークにデプロイします。 Claude Code は、アドレスがプライベートであるゲートウェイにのみ接続します。これはセキュリティガードです。信頼されたゲートウェイは開発者マシンでコマンドを実行する設定をプッシュできるためです。ゲートウェイを内部ロードバランサーまたは VPN の背後に配置し、プライベート IP にのみ解決するホスト名を付けます。内部ネットワークが組織が所有するパブリック IPv4 スペースから番号付けされている場合は、所有するパブリックアドレススペースでゲートウェイを許可するを参照してください。
前提条件
開始する前に、以下を用意してください。ステップ
1
IdP で OAuth クライアントを登録する
リダイレクト URI がそれと一致する必要があるため、まずゲートウェイのホスト名を決定します。新しい OIDC ウェブアプリケーションを作成し、リダイレクト URI を
https://claude-gateway.<your-domain>/oauth/callback に設定します。ホストはステップ 3 で listen.public_url として設定する値と同じです。client_id と client_secret をメモします。IdP ごとの手順はID プロバイダーセットアップにあります。2
PostgreSQL データベースをプロビジョニングする
最小管理層を含む任意の Postgres 14 以降が機能します。ゲートウェイは起動時に独自のスキーママイグレーションを実行するため、データベースロールはテーブルを作成および変更する権限が必要です。
storeを参照してください。3
gateway.yaml を書く
シークレットは この設定は、デフォルト Amazon Bedrock モデルカタログを使用した動作するサインインループに十分です。実行されたら、
${ENV_VAR} 展開経由で読み取られるため、ファイル自体はバージョン管理に存在できます。/login がパブリックアドレスを拒否するため、プライベート IP に解決する public_url ホスト名を使用します。最小設定には 5 つのセクションがあり、他のすべてのフィールドにはデフォルトがあります。gateway.yaml
managed.policies 経由でグループごとの RBAC と管理設定を追加し、telemetry 経由でテレメトリファンアウトを追加し、models 経由でマルチアップストリームフェイルオーバー、プロビジョニング済みスループット ARN、または非米国リージョンを追加します。Amazon Bedrock アップストリームは、
inference-profile/us.anthropic.* ARN と基礎となる foundation-model/anthropic.* ARN の両方に対して bedrock:InvokeModel と bedrock:InvokeModelWithResponseStream を持つ AWS プリンシパルが必要です。また、そのアカウントについて、Bedrock コンソールのモデルカタログから Anthropic の一度限りのユースケースフォームが提出されている必要もあります。静的キーではなく、EKS の IRSA、ECS タスクロール、または EC2 インスタンスプロファイルを使用して認証情報を提供します。upstreams リファレンスには、完全な IAM 詳細、クロスクラウド認証情報マトリックス、および他のプロバイダーの auth ブロックがあります。4
実行する
イメージ要件を満たす ゲートウェイは、設定を読み取り、Postgres に接続してスキーママイグレーションを適用し、IdP に対して OIDC ディスカバリーを実行し、アップストリームクライアントを構築し、リッスンを開始する単一の Linux バイナリです。起動は設定、Postgres 接続、OIDC ディスカバリー、およびアップストリームクライアント構築に対して失敗時に閉じられます。これらのいずれかが到達不可能または設定が誤っている場合、ゲートウェイは低下した状態でトラフィックを提供するのではなく、エラーで終了します。成功した起動は推論パスを検証しません。Amazon Bedrock と Google Cloud の Agent Platform インスタンス認証情報は起動時ではなく最初のリクエストで解決されるためです。起動シーケンスについて stderr を監視します。ログ行は ゲートウェイは、
claude バイナリの周りにコンテナイメージを構築し、Postgres と一緒に実行します。Compose ファイルはイメージを registry.example.com/claude-gateway:2.1.198 として参照します。独自のレジストリとイメージタグに置き換えます。docker-compose.yaml
[gateway] <timestamp> <level> <message> 形式を使用し、監査イベントは evt フィールド付きの単一行 JSON であり、起動バナーは以下で省略され、マイグレーションとリッスン行の間に出力されます。新しいデータベースはスキーママイグレーションごとに 1 行の migration N applied を出力します。既にマイグレーションされたデータベースは出力しません。順番に以下が表示されます。access_control.allow_cidrs が空であることを示す警告もログに記録します。これはここで予想されています。ゲートウェイがサーブするクライアントアドレスを制限するものがないためです。許可リストを設定するまで。access_control リファレンスには推奨範囲があります。起動が claude gateway listening on 行の前に終了する場合、stderr の最後の行は問題を名前付けます。- 到達不可能な Postgres
- DDL 権限のない Postgres ロール
- 到達不可能または無効な OIDC ディスカバリードキュメント
- 違反フィールドパスを含む設定スキーマ違反
claude gateway --config gateway.yaml でバイナリを直接実行します。public_url をイングレスオリジンに設定し、listen をループバックまたはクラスター内アドレスにバインドします。5
認証サーフェスを確認する
3 つのチェックは、ゲートウェイが開発者に渡す前に実際のユーザーを認証できることを確認します。例はゲートウェイのパブリック URL を使用します。イングレスのないローカル Compose セットアップの場合、最初の 2 つのチェックで 応答には 3 番目に、ブラウザで
http://localhost:8080 に置き換えます。3 番目のチェックは verification_uri_complete を開きます。これは public_url から構築されるため、ローカル Compose の場合は gateway.yaml で public_url: http://localhost:8080 を設定し、ゲートウェイが public_url から IdP redirect_uri を構築するため、ステップ 1 の OAuth クライアントに 2 番目のリダイレクト URI として http://localhost:8080/oauth/callback を追加します。検証リンクはローカルブラウザで開きます。Windows PowerShell では、curl.exe を実行します。ベア curl は Invoke-WebRequest のエイリアスであり、これらのフラグを拒否します。まず、ディスカバリードキュメントを取得します。これはゲートウェイが起動し、設定が有効であり、すべての起動チェックが合格したことを確認します。response_types_supported や scopes_supported などの追加フィールドが含まれます。次に、デバイス認可をリクエストします。これはデバイスサインインフローが機能し、Postgres が到達可能で書き込み可能であることを確認します。verification_uri_complete を開いてコードを確認することでブラウザレッグをテストします。IdP のサインインページにリダイレクトされ、サインイン後、ゲートウェイに戻ってサインイン確認に着地する必要があります。最初に失敗したチェックを使用して問題を特定します。- 最初のチェックが失敗:起動が完了しませんでした。stderr を確認してください
- 2 番目のチェックが失敗:Postgres がゲートウェイから到達不可能であるか、ロールが書き込みできません。接続文字列と権限を確認してください
- 3 番目のチェックが IdP に到達しない:IdP のリダイレクト URI が
https://<gateway>/oauth/callbackと正確に一致することを確認してください - 3 番目のチェックが IdP に到達しますが、エラーで戻ります:ゲートウェイの監査ログを読みます。これは
email domain not allowedなどの理由を含むすべての認証拒否を記録します
6
開発者をログインさせる
この最後のステップはサーバーではなく開発者マシンで発生します。そのマシンの管理設定ファイルで
forceLoginMethod を "gateway" に、forceLoginGatewayUrl をゲートウェイの public_url に設定し、/login を実行し、Cloud gateway 画面で Enter キーを押し、ブラウザサインインを完了します。以下のゲートウェイ URL を設定は、スケール時に両方のキーを配布することをカバーしています。開発者を接続する
開発者は独自のラップトップから 1 つのブラウザサインインで接続し、企業の仕事用アカウントを使用します。claude.ai アカウント、API キー、またはサブスクリプションは必要ありません。モデルへのリクエストは組織のアップストリーム認証情報を使用してゲートウェイを通じて行くためです。接続は、MDM 経由でプッシュするクライアント側管理設定によって駆動されるため、開発者側に手動セットアップはありません。このセクションは管理者が設定するものをカバーしています。 CLI はゲートウェイの TLS リーフ証明書を最初の接続時にフィンガープリントし、ホスト名ごとにピン留めします。サインイン時、サイレントセッション更新時、および管理設定フェッチ時にそのピンを再度チェックしますが、推論リクエストはピンなしで標準 TLS 検証を使用します。HTTPS プロキシを通じてルーティングされたリクエストはピンチェックをスキップするため、ゲートウェイホストをNO_PROXY に追加して直接接続を保つようにします。
期待される SHA-256 フィンガープリントをゲートウェイ URL と一緒に公開して、開発者が比較するものを持つようにします。/login プロンプトはフィンガープリントの最初の 16 文字を小文字の 16 進数でコロンなしで表示します。証明書ファイルからこの形式で完全なフィンガープリントを出力するには、以下を実行します。
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 セッションにポリシーを配信するで説明されています。
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 はそれを拒否します。
/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エントリに名前を付けます。
Claude Desktop セッションにポリシーを配信する
Claude Desktop は Cowork タブと Code タブ、および有効にした場合は Chat タブを、埋め込み Claude Code セッションで実行し、それらのモデルリクエストをゲートウェイを通じて送信します。ゲートウェイが/user/bootstrap で提供する設定から構築されたポリシーを各セッションに渡します。モデル許可リスト、無効化されたツール、および一致したポリシーの cli ブロックから派生した出力許可リスト、およびdesktop オーバーレイです。
hooks、env、および Bash(npm *) のようなスコープ付き権限ルールなどの他の cli キーは、/login を通じてサインインするクライアントにのみ到達します。Claude Desktop はゲートウェイ URL を独自の管理設定から読み取り、ゲートウェイ URL を設定するの forceLoginMethod と forceLoginGatewayUrl キーとは別の独自のフローでサインインします。
起動プロセスによって渡される設定は親設定です。Claude Code は、管理者がデプロイした管理ソースを持つマシンで親設定を無視します。ただし、ポリシーを配信するソースが parentSettingsBehavior: "merge" を設定する場合を除きます。
どのマシンがオプトインを必要とするか
Claude Desktop のみを実行するマシンはそれを必要とします。Claude Desktop は埋め込みセッションにモデルリストと無効化されたツールリストを適用しますが、出力許可リストは親設定としてのみそれらに到達します。WebFetch ドメインルールとサンドボックスネットワークルールの形式です。オプトインなしでは、これらのセッションは出力制限なしで実行され、何も警告しません。ゲートウェイはポリシーが許可しないモデルの推論リクエストを引き続き拒否します。
/login を通じてサインインする開発者のマシンはそれを必要としません。各 Claude Code セッションはゲートウェイからポリシーをフェッチします。
policyHelperが管理設定を提供するフリートはそれを使用できません。Claude Code はそれらのフリートで親設定をマージしません。ヘルパーの出力からのみ管理設定を読み取るためです。
オプトインを設定する
ゲートウェイ URL を設定するから管理設定スニペットをデプロイし、ファイルを上回るクライアント側ソースにミラーリングしてから検証します。1
管理設定ファイルにオプトインをデプロイする
上記のスニペットには既に
parentSettingsBehavior: "merge" が含まれているため、マシンにプッシュするファイルはそれを含みます。2
ファイルを上回るソースにスニペットをミラーリングする
Claude Code は
parentSettingsBehavior を選択されたソースからのみ読み取ります。クライアント側ソースにポリシーキーを追加すると、そのソースが選択されたものになる可能性があるため、クライアント側ソースでは parentSettingsBehavior のみではなくスニペット全体をミラーリングします。クライアント側管理設定は Group Policy または設定プロファイルを通じてポリシーを配信するフリートをカバーしています。macOS の管理設定プリストまたは Windows の HKLM ポリシーは managed-settings.json ファイルを上回り、ゲートウェイ独自のリモート管理設定は両方を上回るため、ゲートウェイにサインインするマシンでは、ゲートウェイポリシーの cli ブロックにも parentSettingsBehavior を設定します。3
どのソースが選択されているかを確認する
Claude Desktop のみを実行するマシンで、Agent SDK の
resolveSettings() を呼び出し、その sources リストの managed エントリで policyOrigin を読み取ります。値は選択されたクライアント側ソース plist、hklm、または file に名前を付けます。これはスニペットを含む必要があるソースです。Claude Desktop の埋め込みセッションはゲートウェイポリシーをフェッチしないため、ゲートウェイの cli ブロックは選択されたソースとしてカウントされません。親設定を制限する
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 ロックと、それらが管理する許可リストを、マージオプトインと同じソースに追加します。
cli ブロックにミラーリングし、このファイルをデプロイしたままにします。接続しないマシン(Claude Desktop のみを実行するものを含む)はファイルからのみポリシーを取得するためです。
ソース全体のロック動作
1 つのロックを設定しても、他のロックは制限されません。各キーは設定リファレンスで文書化されています。勝者より下の管理ソースから、2 つのサンドボックスロックは引き続き適用され、allowManagedPermissionRulesOnly は引き続き親が提供した許可ルールと additionalDirectories をブロックします。Claude Code v2.1.273 以降では、MCP サーバーロックも勝者より下のソースから適用され、それがオンの間、管理 allowedMcpServers リストは最優先の管理ソースから来ます。
hooks ロックと allowManagedPermissionRulesOnly の開発者独自のルールへの影響は、デフォルトで勝者ソースが必要です。Claude Code が管理ソースを組み合わせる方法の managedSourcesBehavior マージオプトインの下で、Claude Code はすべてのロックについてすべてのソースが設定する最も厳密な値を適用します。policyHelper フリートでは、ロックはヘルパーの出力からのみ読み取られます。
各ロックは Claude Code が開発者独自のエントリをその設定について無視するようにするため、組織の許可リストをロックの隣に含めます。
- ネットワークドメイン:空の管理ドメインリストでロックするとサンドボックス化された全アウトバウンドトラフィックがブロックされます。
- MCP サーバー:管理またはホストが提供した
allowedMcpServersなしでロックすると、deniedMcpServersがブロックしないすべてのサーバーが読み込まれます。 - 読み取りパス:
allowReadエントリはdenyRead領域内のパスのみを再許可するため、管理denyReadとペアにします。
ロックがカバーしない設定
5 つのロックすべてが設定されていても、6 つの親が提供した設定がフィルターを通過します。デフォルトの最初の勝ちの設定の下で、親をブロックする管理値は最優先の管理ソースにあるものです。ただし、MCP サーバーロックがオンの間はallowedMcpServers を除きます。managedSourcesBehavior マージオプトインの下で、Claude Code が管理ソースを組み合わせる方法は代わりにどのソースの値が適用されるかを示します。
forceLoginOrgUUID:最優先の管理ソースが組織 UUID を設定しない場合、Claude Code は親が提供した値を尊重します。ゲートウェイサインインはこのキーをチェックしません。最優先の管理ソースの組織 UUID は親の値をブロックし、Claude Code が強制するものです。allowedMcpServers:最優先の管理ソースが設定しない場合、Claude Code は親が提供した許可リストを尊重します。allowManagedMcpServersOnlyはそれをブロックしません。ロックは勝者の許可リストを管理値として強制するため、最優先の管理ソースが設定しない場合は親が提供した許可リストを含みます。最優先の管理ソースのリストは親のリストをブロックし、Claude Code が強制するリストです。ロックの隣にそこにallowedMcpServersを設定します。v2.1.223 より前では、任意の管理ソースのいずれかのキーの値は親のリストをブロックしました。availableModels:勝者の管理ソースが設定しない場合、Claude Code は親が提供したモデルリストを尊重します。フリートがモデルを制限する場合、勝者ソースにavailableModelsを設定します。strictKnownMarketplaces:勝者の管理ソースが設定しない場合、Claude Code は親が提供したプラグインマーケットプレイス許可リストを尊重します。フリートがマーケットプレイスを制限する場合、勝者ソースにstrictKnownMarketplacesを設定します。Claude Code v2.1.282 以降が必要です。blockedMarketplaces:親が提供したマーケットプレイスブロックリストは通過し、管理ソースが設定するブロックリストに追加されます。ブロックリストはさらに制限することのみができるためです。Claude Code v2.1.282 以降が必要です。strictPluginOnlyCustomization:このキーはロックに関係なくフィルターを通過し、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許可リストにフィルタリングされます。ポリシーでenforceAvailableModels: trueを設定して、Default オプションが Claude Code の組み込みデフォルトではなくavailableModels内のモデルに解決されるようにします。なしでは、Default は選択可能なままであり、そのモデルが許可されていない場合、リクエスト時に拒否されます。 - テレメトリ宛先:
/loginを通じてサインインしたセッションでは、CLI はローカルに設定されたOTEL_EXPORTER_OTLP_ENDPOINTに関係なく、OTLP/HTTP エクスポートをゲートウェイに送信します。ただし、ポリシーがコレクターをエンドポイントとして指定する場合を除きます。ゲートウェイはtelemetry.forward_toの宛先にそれらをリレーします。- Claude Desktop が起動する埋め込みセッションでは、CLI はエクスポートを設定された
OTEL_EXPORTER_OTLP_ENDPOINTに送信します。CLI はそのエンドポイントがゲートウェイ自体を指す場合にのみ、ゲートウェイセッショントークンをそれらのエクスポートに添付します。 - 信号に設定された宛先がない場合、ゲートウェイはそれを受け入れて破棄します。
- 既に Claude Code テレメトリを直接収集する場合は、コレクターを
forward_to宛先として追加するか、ポリシーで指定してリレーをスキップします。
- Claude Desktop が起動する埋め込みセッションでは、CLI はエクスポートを設定された
- 認証情報:ゲートウェイトークンはセッションの唯一の認証情報です。Anthropic プロファイルおよび以前の claude.ai ログインはサインイン中は無視されるため、開発者は最初に claude.ai からログアウトする必要はありません。設定された
ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、またはapiKeyHelper認証情報については、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 シークレットローテーションを参照してください。
- ゲートウェイの検出ドキュメントがゲートウェイ URL 独自のスキーム、ホスト、およびポートで
組織が見ることができるもの
使用状況テレメトリは開発者のアイデンティティ、トークン数、モデル、およびレイテンシを組織のコレクターに伝えます。ゲートウェイはプロンプトまたは完了コンテンツをログまたは保存しません。ログやトレースなどのより豊富なテレメトリが収集されるかどうか。コマンドやファイルパスを含む可能性があるのは、組織の宛先ごとの選択です。可用性と制限
表は、開発者がゲートウェイを通じて接続するときに機能する Claude Code 機能と、ゲートウェイサーバー自体がサポートするものをカバーしています。何かがサポートされていない場合、Notes 列は代替案を提供します。 ゲートウェイは、CLI がすべてのアップストリームに送信するanthropic-beta 値を配信するため、オペレーターはベータ許可リストを維持しません。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 にデプロイを参照してください。