Claude apps gateway

開発者は API キーやクラウドの認証情報を持たず、企業の IdP (ID プロバイダー) でサインインします。ゲートウェイは利用状況のテレメトリを、組織自身の observability stack (監視基盤) へ中継します。

ゲートウェイは claude バイナリに含まれており、ノート PC で Claude Code を動かすのと同じ実行ファイルで、claude gateway --config gateway.yaml によりゲートウェイサーバーを起動します。リリースごとにテストされているため、Claude Code が送る anthropic-beta の値やリクエストのフィールドを、運用者が別の許可リストを保守しなくても転送します。

ゲートウェイは、サインインしたクライアントへマネージド設定を自ら配布し、claude.ai の管理コンソールからのサーバー管理設定の代わりを担います。標準のプロンプトキャッシュのため、cache_control のブレークポイントはすべてのアップストリームへ転送します。稼働中のゲートウェイは、GET /protocol で自身のプロトコルのリファレンスを返します。

• サインイン後、モデルピッカーには availableModels の許可リストにあるモデルが表示されます。
• 画面の無いリモートの開発マシンでは、SSH 越しに /login を実行し、確認用のリンクを手元のノート PC のブラウザで開きます。
• マネージド設定の無い端末では、各開発者が ~/.claude/settings.json に forceLoginMethod と forceLoginGatewayUrl を追加します。
• Claude Desktop は、マネージド構成の bootstrapUrl を <listen.public_url>/user/bootstrap に設定し、ユーザーのポリシーに desktop キーを加えて接続します。接続後は、有効なすべてのタブのモデルリクエストがゲートウェイを通ります。
• CLI はゲートウェイがどのアップストリームへ振り分けるかを確認できないため、ゲートウェイのセッションでは WebSearch を無効にします。

対象のプランについては、公式のリリースノートには記載がありません。

• 支出上限に達すると、Claude Code の利用警告に上限額、リセット時刻、運用者のメッセージが表示されます (ゲートウェイ側も 2.1.225 が必要です)。
• 支出上限のあるゲートウェイの配下では、/usage に Spend limit バーが表示され、ステータスラインに rate_limits.spend_limit フィールドが使えます。ゲートウェイが対応バージョン以降であれば、「$271.40 / $500.00 spent this month」のようにドル金額で表示されます。
• gateway.yaml に pricing: を設定すると、サインインした Claude Code クライアントがマネージド設定経由で同じ料金を受け取り、/cost とテレメトリが支出メーターと一致します。
• 各メンバーの上限に加えて、グループのメンバーが共有する月次の pooled group budget を、spend limits の管理 API の pooled_budget で設定できます。
• 管理 API の GET /v1/organizations/analytics/cost で、指定した期間の過去の支出を合計・開発者別・日別・IdP グループ別に取得できます。

• ゲートウェイは、プロンプトや応答の内容をログに記録・保存しません。
• 設定したテレメトリの送信先には、トークン数、モデル、ユーザーの ID、レイテンシーを含む OTLP メトリクスが既定で送られます。ログとトレースは送信先ごとのオプトインです。
• Claude Desktop と Cowork がゲートウェイ経由で送るテレメトリにも、ターミナルのセッションと同じく user.email と user.groups が含まれます。
• Anthropic のアップストリームでは、オプトインの forward_user_identity 設定により、サインインしたユーザーの ID をヘッダーで送り、ゲートウェイの背後のプロキシがユーザーごとに支出を帰属できます。
• admin: を設定したゲートウェイでは、各開発者の IdP グループの日次記録が admin.identity_retention_days の間保持され、コストレポートのグループ別集計に使われます。
• desktop: オーバーレイの不明または無効なキーは、起動時の検証で起動失敗になります。Bedrock の guardrail 設定は、すべての Bedrock アップストリームに設定するか、どれにも設定しないかのどちらかにします。

管理者がゲートウェイを立ち上げ、開発者の端末から接続するまでの基本の流れです。

1. IdP に OAuth クライアントを登録します。新しい OIDC の Web アプリケーションを作成し、リダイレクト URI を https://claude-gateway.<your-domain>/oauth/callback に設定します。
2. PostgreSQL 11 以降のデータベースを用意します。マネージドサービスの最小の構成で足ります。
3. listen・oidc・session・store・upstreams の 5 つの節で gateway.yaml を書きます。シークレットは ${ENV_VAR} の展開で読み込むため、ファイル自体はバージョン管理に置けます。
4. claude バイナリを含むコンテナイメージを作り、Docker Compose などで Postgres と並べて起動します。
5. /.well-known/oauth-authorization-server のディスカバリードキュメントを取得し、ゲートウェイの起動と設定の有効性を確認します。
6. /oauth/device_authorization に POST してデバイスのサインインの流れと Postgres への書き込みを確認し、続けて verification_uri_complete をブラウザで開いてコードを確認します。
7. 開発者の端末のマネージド設定で forceLoginMethod を "gateway"、forceLoginGatewayUrl をゲートウェイの public_url、parentSettingsBehavior を "merge" にします。その後 /login を実行し、Cloud gateway (クラウドゲートウェイ) 画面で Enter を押して、ブラウザでのサインインを完了します。