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 管理コンソールからのサーバー管理設定の場所を取ります。
  • テレメトリ:Datadog、Splunk、ClickHouse などの各設定先は、デフォルトではトークン数、モデル、ユーザーアイデンティティ、レイテンシを含むOpenTelemetry Protocol(OTLP)メトリクスを受け取り、ログとトレースは宛先ごとのオプトインです。
  • アップストリームルーティング:クライアントは Anthropic Messages API をゲートウェイに話しかけ、ゲートウェイは各アップストリーム(Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry、または Anthropic API)に対して変換し、それらの間でフェイルオーバーします。開発者が気付いたり再設定したりすることなく、リージョン、プロバイダー、またはフェイルオーバー順序を変更できます。
Claude 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 ゲートウェイは、SSO サインイン、管理設定配信、およびテレメトリ用の Claude apps ゲートウェイ固有のエンドポイントを追加して、その契約のスーパーセットを GET /protocol で提供します。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 にのみ解決するホスト名を付けます。Anthropic が運用するパブリックゲートウェイエンドポイントは例外です。/loginhttps:// 経由でそれらを受け入れます。これらは Anthropic 自体が運用する小さな固定セットのゲートウェイです。これらは選択または設定できるデプロイメントオプションではありません。リストは Claude Code にコンパイルされているため、設定がホスト名をリストに追加することはできず、ホストするゲートウェイは免除の対象にはなりません。v2.1.206 より前では、/login はそれらのエンドポイントを他のパブリックアドレスと同様に拒否していました。

前提条件

開始する前に、以下を用意してください。 ゲートウェイサーバーはネイティブ claude バイナリが必要です。Claude Code のインストールで説明されているようにピン留めされたリリースをダウンロードします。サーバーは Claude Code が Node の下で実行されるときに利用できないランタイム機能を使用します。起動時に requires the native binary が表示される場合は、スタンドアロンインストール方法の 1 つに切り替えます。

ステップ

1

IdP で OAuth クライアントを登録する

リダイレクト URI がそれと一致する必要があるため、まずゲートウェイのホスト名を決定します。新しい OIDC ウェブアプリケーションを作成し、リダイレクト URI を https://claude-gateway.<your-domain>/oauth/callback に設定します。ホストはステップ 3 で listen.public_url として設定する値と同じです。client_idclient_secret をメモします。IdP ごとの手順はID プロバイダーセットアップにあります。
2

PostgreSQL データベースをプロビジョニングする

最小管理層を含む任意の Postgres 14 以降が機能します。ゲートウェイは起動時に独自のスキーママイグレーションを実行するため、データベースユーザーは CREATE TABLE 権限が必要です。セキュリティポリシーがアプリケーションロールからの DDL を禁止する場合は、代わりにスキーマを事前作成します。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:InvokeModelbedrock:InvokeModelWithResponseStream を持つ AWS プリンシパルが必要であり、Bedrock コンソールで必要な Claude モデルのモデルアクセスが有効になっています。EKS の IRSA、ECS タスクロール、または EC2 インスタンスプロファイルではなく、静的キーを使用して認証情報を提供します。upstreams リファレンスには、完全な IAM 詳細、クロスクラウド認証情報マトリックス、および他のプロバイダーの auth ブロックがあります。
4

実行する

イメージ要件を満たす claude バイナリの周りにコンテナイメージを構築し、Postgres と一緒に実行します。
docker-compose.yaml
ゲートウェイは、設定を読み取り、IdP に対して OIDC ディスカバリーを実行し、Postgres スキーママイグレーションを適用し、アップストリームクライアントを構築し、リッスンを開始する単一の Linux バイナリです。起動は設定、5 秒タイムアウト付き Postgres 接続、OIDC ディスカバリー、およびアップストリームクライアント構築に対して失敗時に閉じられます。これらのいずれかが到達不可能または設定が誤っている場合、ゲートウェイは低下した状態でトラフィックを提供するのではなく、エラーで終了します。成功した起動は推論パスを検証しません。Amazon Bedrock と Google Cloud の Agent Platform インスタンス認証情報は起動時ではなく最初のリクエストで解決されるためです。起動シーケンスについて stderr を監視します。ログ行は [gateway] <timestamp> <level> <message> 形式を使用し、監査イベントは evt フィールド付きの単一行 JSON であり、起動バナーは以下で省略され、マイグレーションとリッスン行の間に出力されます。順番に以下が表示されます。
起動が 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.yamlpublic_url: http://localhost:8080 を設定し、ゲートウェイが public_url から IdP redirect_uri を構築するため、ステップ 1 の OAuth クライアントに 2 番目のリダイレクト URI として http://localhost:8080/oauth/callback を追加します。検証リンクはローカルブラウザで開きます。Windows PowerShell では、curl.exe を実行します。ベア curlInvoke-WebRequest のエイリアスであり、これらのフラグを拒否します。まず、ディスカバリードキュメントを取得します。これはゲートウェイが起動し、設定が有効であり、すべての起動チェックが合格したことを確認します。
応答には response_types_supportedscopes_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 リーフ証明書を最初の接続時にフィンガープリントし、ホスト名ごとにピン留めします。期待されるフィンガープリント SHA-256 をゲートウェイ URL と一緒に公開して、開発者が比較するものを持つようにします。証明書ファイルから openssl x509 -noout -fingerprint -sha256 -in cert.pem でフィンガープリントを取得します。/login プロンプトはダイジェストの最初の 16 文字を小文字の 16 進数で区切り文字なしで表示します。 証明書がローテーションされると、すべての開発者は再度信頼プロンプトを見るため、ローテーションを計画されたイベントとして扱い、フィンガープリントを再公開します。 サインイン後、モデルピッカーは開発者の availableModels 許可リストのモデルを表示し、管理設定は起動時に適用され、1 時間ごとに更新され、テレメトリはコレクターにルーティングされます。セッションは ttl_hours 有効期限の前にサイレントに更新され、IdP プロビジョニング解除後の失敗した更新は再ログインを促します。

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

MDM 経由またはディスク上で直接デプロイする OS ごとの管理設定ファイルに両方のキーを設定し、/login は URL が入力された状態で Cloud gateway 画面で直接開きます。
開発者は Enter キーを押して接続します。最初の接続 TLS フィンガープリントプロンプトは引き続き表示されます。 開発者が手動で選択するためのログインピッカーにゲートウェイオプションはなく、forceLoginGatewayUrl は開発者独自の設定ファイルでは無視されます。URL なしの forceLoginMethod のみでは、開発者を「IT 管理者に連絡してください」メッセージのままにします。両方のキーは、マシンにプッシュするファイルに属し、ゲートウェイの managed.policies[].cli ブロックには属しません。これは既に接続されているクライアントにのみ到達します。

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

無人パイプラインのサービストークンフローはありません。ゲートウェイサインインは常にブラウザデバイスフローを実行するため、サインインを承認する開発者がない CI ジョブは認証できません。これらをプロバイダーに対して直接設定します。 開発者がサインインすると、そのマシンでのすべての Claude Code 呼び出しはゲートウェイセッションを使用します。非対話的な claude -p 実行と Agent SDK によって開始されたセッションを含み、ゲートウェイポリシーはすべてに適用されます デバイスフローはポーリング CLI を承認ブラウザから分離するため、ディスプレイのないリモート開発ボックスは引き続き機能します。開発者はリモートマシンで SSH 経由で /login を実行し、ラップトップのブラウザで検証リンクを開きます。

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

これらの保証はすべてのサインイン済みゲートウェイセッションに適用されます。
  • モデルアクセス:ポリシーが許可しないモデルのリクエストは 400 を返し、/model ピッカーはポリシーの availableModels 許可リストにフィルタリングされます。ポリシーで enforceAvailableModels: true を設定して、Default オプションが Claude Code の組み込みデフォルトではなく availableModels 内のモデルに解決されるようにします。なしでは、Default は選択可能なままであり、そのモデルが許可されていない場合、リクエスト時に拒否されます。
  • テレメトリ宛先テレメトリ転送が設定されている場合、OTLP エクスポートエンドポイントはゲートウェイにピン留めされ、ゲートウェイがプッシュした設定はローカルに設定された OTEL_* 変数をオーバーライドします。
  • 認証情報:ゲートウェイトークンはセッションの唯一の認証情報です。ANTHROPIC_AUTH_TOKENANTHROPIC_API_KEYapiKeyHelper、および以前の claude.ai ログインはサインイン中は無視されるため、開発者は最初に claude.ai からログアウトする必要はありません。
  • 管理設定:ロックされたキーはローカルでオーバーライドできません。CLI はポリシーを起動時と毎時間のポーリングで適用します。
  • 起動:サインイン済みセッションは、ゲートウェイが到達不可能な場合、約 10 秒後に起動時にエラーで終了し、設定なしで起動するのではなく。
  • プロビジョニング解除:ユーザーが IdP で無効化されたセッションは、次の更新が失敗したときに ttl_hours 内に期限切れになります。

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

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

可用性と制限

表は、開発者がゲートウェイを通じて接続するときに機能する Claude Code 機能と、ゲートウェイサーバー自体がサポートするものをカバーしています。何かがサポートされていない場合、Notes 列は代替案を提供します。 ゲートウェイは、CLI がすべてのアップストリームに送信する anthropic-beta 値を配信するため、オペレーターはベータ許可リストを維持しません。Amazon Bedrock の場合、ヘッダーを無視し、ゲートウェイは値をリクエストボディの anthropic_beta フィールドに移動します。他のアップストリームは送信されたままヘッダーを受け取ります。CLI のゲートウェイセッションベータセットは、ファーストパーティのみのベータと拡張キャッシュ TTL ベータを省略します。これが以下の行がサポートされていないと表示される理由です。

次のステップ

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