Skip to main content
Claude アプリゲートウェイは、データレジデンシー要件を満たすなど、独自のクラウドプロバイダーを通じて推論をルーティングする必要がある、または希望する組織向けに設計されています。この要件がない場合、SCIM プロビジョニングや web・モバイル上の Claude Code などの他の機能へのアクセスを希望する場合は、Claude Enterprise の方がより適切である可能性があります。すべてのデプロイメント方法の完全な比較については、機能可用性ページを参照してください。
Claude アプリゲートウェイは、開発者の Claude Code クライアントとモデルプロバイダーの間に位置する自己ホスト型サービスです。開発者は API キーやクラウド認証情報を保持する代わりに、企業の ID プロバイダー(IdP)でサインインします。ゲートウェイはアップストリーム認証情報を保持し、IdP グループによるモデルアクセスと管理設定を強制し、使用状況テレメトリを独自の可観測性スタックにリレーします。 これは claude バイナリに含まれているため、ラップトップで Claude Code を実行する同じ実行ファイルが claude gateway --config gateway.yaml でゲートウェイサーバーを実行します。 このページでは以下をカバーしています。 関連ページはさらに詳しく説明しています。設定リファレンスはクイックスタートが書き込む 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 クライアントと Claude Desktop の Chat、Cowork、Code タブがベアラートークンを使用して HTTPS 経由でインフラストラクチャ内の自己ホスト型 Claude apps ゲートウェイに接続し、IdP に対してユーザーにサインインし、PostgreSQL に認証状態を保存し、テレメトリを OTLP コレクターにリレーし、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry、または Anthropic API に推論を転送する図
ゲートウェイ独自のデータプレーンは、Anthropic API が設定されたアップストリームでない限り、Anthropic インフラストラクチャに何も送信しません。テレメトリ、監査ログ、管理設定、および開発者の IdP アイデンティティがどこに行くかを制御し、ゲートウェイはそれらのいずれも Anthropic に送信しません。残りのトラフィック CLI プロセスが送信できる方法と、それを閉じる方法については、コンプライアンスポスチャを参照してください。
ゲートウェイを通じてどの 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 できるゲートウェイがあります。
プライベートネットワークにデプロイします。 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 を書く

シークレットは ${ENV_VAR} 展開経由で読み取られるため、ファイル自体はバージョン管理に存在できます。/login がパブリックアドレスを拒否するため、プライベート IP に解決する public_url ホスト名を使用します。最小設定には 5 つのセクションがあり、他のすべてのフィールドにはデフォルトがあります。
gateway.yaml
この設定は、デフォルト Amazon Bedrock モデルカタログを使用した動作するサインインループに十分です。実行されたら、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

実行する

イメージ要件を満たす claude バイナリの周りにコンテナイメージを構築し、Postgres と一緒に実行します。Compose ファイルはイメージを registry.example.com/claude-gateway:2.1.198 として参照します。独自のレジストリとイメージタグに置き換えます。
docker-compose.yaml
ゲートウェイは、設定を読み取り、Postgres に接続してスキーママイグレーションを適用し、IdP に対して OIDC ディスカバリーを実行し、アップストリームクライアントを構築し、リッスンを開始する単一の Linux バイナリです。起動は設定、Postgres 接続、OIDC ディスカバリー、およびアップストリームクライアント構築に対して失敗時に閉じられます。これらのいずれかが到達不可能または設定が誤っている場合、ゲートウェイは低下した状態でトラフィックを提供するのではなく、エラーで終了します。成功した起動は推論パスを検証しません。Amazon Bedrock と Google Cloud の Agent Platform インスタンス認証情報は起動時ではなく最初のリクエストで解決されるためです。起動シーケンスについて stderr を監視します。ログ行は [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 ディスカバリードキュメント
  • 違反フィールドパスを含む設定スキーマ違反
修正して再起動します。既に TLS 終了イングレスがある場合は、Compose をスキップし、claude gateway --config gateway.yaml でバイナリを直接実行します。public_url をイングレスオリジンに設定し、listen をループバックまたはクラスター内アドレスにバインドします。
5

認証サーフェスを確認する

3 つのチェックは、ゲートウェイが開発者に渡す前に実際のユーザーを認証できることを確認します。例はゲートウェイのパブリック URL を使用します。イングレスのないローカル Compose セットアップの場合、最初の 2 つのチェックで 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 が到達可能で書き込み可能であることを確認します。
3 番目に、ブラウザで 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 進数でコロンなしで表示します。証明書ファイルからこの形式で完全なフィンガープリントを出力するには、以下を実行します。
証明書がローテーションされると、すべての開発者は再度信頼プロンプトを見るため、ローテーションを計画されたイベントとして扱い、フィンガープリントを再公開します。ゲートウェイポリシーに承認が必要な設定が含まれている場合、開発者は新しい証明書を受け入れた後、その承認ダイアログも再度見ます。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 セッションにポリシーを配信するで説明されています。
開発者は 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 以降が必要です。以前のバージョンはキーを無視し、プライベートアドレスルールを適用します。
gatewayInternalNetworks は、公開アドレス空間から番号が付けられている内部ネットワーク用です。ゲートウェイをインターネットに公開することを安全にするわけではありません。信頼されたゲートウェイは開発者マシンでコマンドを実行する設定をプッシュできます。ファイアウォールまたはロードバランサーのルールでゲートウェイをネットワークの外から到達不可能に保ちます。ゲートウェイの access_control.allow_cidrs をここで宣言するのと同じブロックに設定して、ゲートウェイ自体が他の場所からのクライアントを拒否するようにします。ロードバランサーまたはイングレスの背後にある場合、listen.trusted_proxies もそのフロントエンドに設定します。ゲートウェイはそうでなければ allow_cidrs をフロントエンド独自のアドレスではなく開発者のアドレスと照合するためです。
キーをログインキーと同じ管理設定ソースに追加します。管理設定ファイル、MDM プロファイル、またはレジストリポリシーです。Claude Code はユーザー、プロジェクト、およびサーバー管理設定でそれを無視します。 この例は 1 つのブロックを宣言します。203.0.113.0/24 を独自のブロックに置き換えます。これはドキュメンテーション範囲であり、Claude Code はそれを拒否します。
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 オーバーレイです。 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 ロックと、それらが管理する許可リストを、マージオプトインと同じソースに追加します。
OS ポリシー(HKLM レジストリポリシーまたは管理設定プリストなど)はこのファイルを上回るため、ファイルではなくそれを通じてスニペット全体を配信します。ゲートウェイのリモート管理設定は OS ポリシーとファイルソースを上回りますが、接続されたクライアントにのみ到達します。ロック、許可リスト、およびマージオプトインをポリシーの 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 宛先として追加するか、ポリシーで指定してリレーをスキップします。
  • 認証情報:ゲートウェイトークンはセッションの唯一の認証情報です。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 シークレットローテーションを参照してください。

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

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

可用性と制限

表は、開発者がゲートウェイを通じて接続するときに機能する 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 にデプロイを参照してください。