Claude apps gateway のデプロイと運用

1. ID プロバイダーをセットアップする：OAuth クライアントを登録し、Okta、Entra、Google の IdP 固有の注記を確認します
2. ゲートウェイをデプロイする：ピン留めされたコンテナイメージをビルドし、Kubernetes、Cloud Run、または独自のプラットフォームで実行します。このセクションではコスト、バイパス、複数ゲートウェイ、サーバーレスの決定についても説明します
3. 運用をセットアップする：ログ、ヘルスプローブ、障害時の動作、シークレットローテーション、アップグレード。監視とランブックを配線するときに参照するリファレンス
4. セキュリティ体制を確認する：データがどこを流れるか、脅威モデル、コンプライアンスの回答。セキュリティレビュー用のリファレンス

ID プロバイダーのセットアップ

• /.well-known/openid-configuration を提供します。本番環境では HTTPS 経由です。ゲートウェイは http:// issuer を受け入れ、ループバック issuer は追加で CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 が必要です
• 認可コードフローをサポートします。PKCE（Proof Key for Code Exchange）はデフォルトで有効です。サポートしない IdP の場合は oidc.use_pkce: false で無効にします
• id_token で email と必要に応じて groups を返すか、oidc.userinfo_fallback: true で userinfo エンドポイントから提供します

• Okta：https://example.okta.com の org 認可サーバーは、email と groups を省略した薄い id_token を返すため、issuer として使用する場合は常に oidc.userinfo_fallback: true を設定します。https://example.okta.com/oauth2/default などのカスタム認可サーバーは、id_token に email と必要に応じて groups を含め、直接発行し、フォールバックは不要です。Okta は oidc.scopes で groups スコープがリクエストされ、アプリのグループクレームフィルターが許可する場合にのみ groups を発行します。userinfo_fallback は IdP がリクエストされなかったクレームを埋めることはできません。
• Microsoft Entra ID：issuer = https://login.microsoftonline.com/<tenant-id>/v2.0。Entra はグループ名ではなくグループオブジェクト ID を発行するため、managed.policies.match.groups で GUID を使用するか、人間が読める名前のためにアプリロールを使用します。テナントが groups の代わりに roles の下でロールを発行する場合は、oidc.groups_claim: roles を設定します。
• Google Workspace：issuer = https://accounts.google.com。Google の id_token はグループを含みません。Google を IdP として、グループベースの allowed_groups または managed.policies を使用するには、oidc.google_groups を設定します。これは、ドメイン全体の委任を持つサービスアカウントを使用して Admin SDK Directory API を通じて各ユーザーのグループを検索します。これなしで、メンバーシップゲーティングに oidc.allowed_email_domains を使用し、ポリシー割り当てに managed.policies.match.email_domain を使用します。Google は標準の offline_access スコープも無視します。リフレッシュトークンの場合は、oidc.scopes: [openid, profile, email] と oidc.extra_auth_params: { access_type: offline, prompt: consent } を設定します。

デプロイ

• コスト：ゲートウェイの個別ライセンスまたはシートごとの料金はありません。ゲートウェイは claude バイナリの一部であるため、既存のコミットメントを通じて推論に対して支払い、実行するコンピュートに対して支払います。
• バイパス：ゲートウェイは、モデルへの唯一のルートがそれを通過することを強制しません。独自の認証情報を持つ開発者は引き続きプロバイダーを直接呼び出すことができるため、そのパスを閉じることはネットワークポリシーの決定です。例えば、api.anthropic.com へのエグレスをゲートウェイ以外からブロックします。そのエグレスをブロックすると、各開発者のマシンから api.anthropic.com を呼び出す WebFetch ドメインセーフティチェック も破壊されます。管理ポリシーで skipWebFetchPreflight: true を設定して無効にします。
• 複数ゲートウェイ：各ゲートウェイは独自の設定を持つ個別のデプロイメントで、CLI はゲートウェイホスト名ごとに信頼と認証情報を保存するため、チームは競合なしに異なるゲートウェイを使用できます。複数の OIDC issuer を提供するには、個別のインスタンスを実行します。
• サーバーレス：Cloud Run は機能します。min-instances: 1 を設定して、コールド OIDC ディスカバリーを回避します。Lambda と Cloud Functions は機能しません。ゲートウェイは長時間実行 HTTP サーバーであるためです。

• provider: anthropic 以外のすべての上流では、ゲートウェイはストリームが約 15 秒間サイレント状態になった後、SSE ping を 1 回書き込みます。
• provider: anthropic では、ゲートウェイは Anthropic API 独自の ping を含む応答をそのまま渡します。

ゲートウェイのアドレスを選択する

• プライベートアドレス：ゲートウェイを内部ロードバランサーまたは VPN の背後に配置し、RFC 1918 や CGNAT 100.64.0.0/10 などのプライベートアドレスにのみ解決されるホスト名を使用します。ユーザーのマシンはどのアドレスでもかまいません。プライベートネットワークの前提条件 に、受け付けられる範囲が記載されています。
• 宣言済みブロック：内部ネットワークが組織所有のパブリック IPv4 空間を使用している場合は、そのブロックを gatewayInternalNetworks 管理設定に記載します。ゲートウェイとユーザーのマシンの両方がそのブロック内にある必要があります。所有するパブリックアドレス空間上のゲートウェイを許可する を参照してください。

コンテナイメージ

1. ピン留めされたリリースからイメージアーキテクチャの Linux ビルドをダウンロードします。ダウンロード URL については、特定のバージョンをインストールする を参照してください。
2. バイナリの整合性とコード署名 で説明されているように、リリースの GPG 署名付き manifest.json に対して検証します。
3. ビルドコンテキストにコピーします。

• glibc ベースのイメージ：glibc ビルドの唯一の動的依存関係は glibc ライブラリです。Musl ベースのイメージには linux-x64-musl または linux-arm64-musl ビルドが必要で、その唯一の動的依存関係は musl です。
• 書き込み可能な状態ディレクトリ：ゲートウェイは任意のユーザーとして実行されますが、最小限のイメージには書き込み可能なホームがありません。CLAUDE_CONFIG_DIR を /tmp/.claude などの書き込み可能なパスに設定します。
• コンテナコマンド：claude gateway --config /etc/claude/gateway.yaml。設定ファイルは読み取り専用でマウントされ、シークレットは環境変数として提供されます。ゲートウェイは listen.port でリッスンします。デフォルトは 8080 です。

Kubernetes

• ConfigMap から設定をマウントし、Secret からシークレットをマウントします。YAML で ${file:/path/to/secret} または環境変数を通じてシークレットを参照します
• Ingress で TLS を終了し、listen.public_url を Ingress ホスト名に設定します
• readiness プローブを GET /readyz に、liveness プローブを GET /healthz に指定します

Cloud Run

• listen.port をデフォルトの 8080 のままにします。これは Cloud Run のデフォルト PORT と一致するか、port: ${PORT} を設定します
• public_url を外部到達可能なオリジンに設定します。本番環境では、これは通常、内部ロードバランサーのホスト名です。/login は パブリックアドレスを拒否 し、*.run.app URL はそれに解決するため、Cloud Run URL だけは curl またはブラウザスモークテストにのみ機能します。例外は、*.run.app が Private Service Connect と Cloud DNS プライベートゾーンを通じてプライベートに解決するネットワークです。そのトポロジーでは、Cloud Run URL は有効な public_url です。Google Cloud の実装例 は両方をカバーしています。
• シークレットボリュームとして設定をマウントします
• min-instances: 1 を設定して、最初のリクエストでコールド OIDC ディスカバリーを回避します

ゲートウェイ URL を開発者マシンにプッシュする

大規模なロールアウト

• ゲートウェイがロードバランサーの向こう側を見ることができません。 listen.trusted_proxies がない場合、すべての開発者はロードバランサーのアドレスから来ているように見え、1 つの制限を共有します。ゲートウェイは、X-Forwarded-For ヘッダーを初めて無視したときに警告をログに記録します。ロードバランサーが listen.trusted_proxies に含めるべきもの である場合は、他の何かを変更する前にそれを記載してください。それでも開発者が 1 つのアドレスを共有している場合は、rate_limits を引き上げます。
• 多くの開発者が少数の NAT または VPN エグレスアドレスを共有しています。 trusted_proxies が正しい場合でも、それらのアドレスの制限を共有します。rate_limits を引き上げて適合させます。

rate_limits:
  device_authorization: { max: 1000, window_seconds: 600 }
  device_verify: { max: 1000, window_seconds: 600 }

運用

ログ

• 監査イベント: セキュリティに関わるイベントごとに 1 行の JSON を出力します。stderr をログアグリゲーターにパイプしてください。 出力されるイベントは config.load、session.mint、session.refresh、device.authorize、device.verify、device.callback、auth.denied、access.denied、access.public_client、inference、managed.serve、desktop_bootstrap.serve、desktop_bootstrap.denied、spend.blocked、admin.denied、admin.limit.upsert、admin.limit.delete です。フィールドはイベントによって異なります。
  • 成功した mint および refresh イベントには sub、email、client_ip、および結果が含まれます
  • auth.denied と access.denied には理由とクライアント IP が含まれ、auth.denied にはさらにリクエストパスが含まれます。これらの拒否の時点ではユーザー ID が存在しないためです。access.denied の理由のうち 2 つは、イベントに含まれる内容を変えます。
    • xff_unparseable: 読み取れなかった X-Forwarded-For のエントリもイベントに含まれます
    • client_ip_unknown: access_control リストが設定されている状態で接続にピアアドレスがなかったため、イベントにクライアント IP は含まれません
  • access.public_client には、access_control.allow_cidrs が空の状態でパブリックアドレスから届いた、プロセスごとの最初のリクエストのクライアント IP が含まれます。ゲートウェイはそのリクエストを通常どおり処理します。このイベントは、ゲートウェイがパブリックインターネットから到達可能である可能性を示します。何がパブリックとみなされるか、および推奨される許可リストについては、access_control リファレンスを参照してください。
  • inference には、どのアップストリームがリクエストを処理したかと、レスポンスのステータスが記録されます
  • desktop_bootstrap.denied には、拒否された Claude Desktop のブートストラップ取得が、理由（not_configured、policy_not_opted_in、または no_policy_matched）およびユーザーの ID とともに記録されます
  • guardrail.trace には、どのフィルターが発動したかが記録されます。一致したテキストは記録されません
  • admin.denied には、拒否された管理 API の認証試行が、クライアント IP、メソッド、パス、理由とともに記録されます。提示された鍵情報は記録されません。理由は、x-api-key が提示されたもののどの設定済みキーとも一致しなかった場合は invalid_key、Authorization ヘッダーのみが提示され、それが admin.admin_groups のゲートウェイセッションとして検証されなかった場合は bearer_rejected、どちらのヘッダーも提示されなかった場合は no_credentials です
• 運用ログ: 起動、警告、アップストリームのエラーについて、[gateway] というプレフィックスの付いた人間が読める形式の行を出力します。詳細度は CLAUDE_GATEWAY_LOG_LEVEL 環境変数で制御し、debug、info、warn、error のいずれかを指定できます。デフォルトは info です。debug では、サインインとリフレッシュのたびに id_token に含まれるクレームの名前（値ではありません）もログに記録され、userinfo_fallback が何らかのクレームを提供した場合は userinfo クレームの名前も記録されます。これにより、PII をログに残さずに email_claim と groups_claim の設定を診断できます。この設定は監査イベントには影響せず、監査イベントは常に出力されます。

運用ログを JSON として書き出す

{"severity":"INFO","time":"2026-11-04T17:03:21.512Z","message":"claude gateway listening on http://0.0.0.0:8080"}

ヘルスチェック

アップストリームへの同時リクエスト

• レプリカを追加する。
• 各レプリカの上限を引き上げる。ゲートウェイコンテナで BUN_CONFIG_MAX_HTTP_REQUESTS 環境変数を 1 から 65535 までの整数に設定し、コンテナを再起動します。

API_TIMEOUT_MS をゲートウェイの最初のバイトまでの時間より大きく保つ

• provider: anthropic: アップストリームが最初のイベントを送信するまでにかかる最長時間より大きい値を API_TIMEOUT_MS に設定します。
• その他すべてのアップストリーム: アップストリームがレスポンスヘッダーを返すまでにかかる最長時間より 20 秒以上大きい値を設定します。ゲートウェイは、アップストリームの最初のイベントがそれより早く届かない限り、それらのヘッダーの約 15 秒後に最初の keepalive ping を送信します。v2.1.229 より古いゲートウェイは ping を送信しないため、その場合は provider: anthropic のルールを使用してください。

最初のバイトの期限で応答のないリクエストをより早く再試行する

export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000

障害時の挙動

• 既存のセッション: ベアラートークンは JWT シークレットでローカルに検証され、セッションのリフレッシュはストアにアクセスせず、ゲートウェイプロセスは引き続き推論を処理できます
• 新規のサインイン: デバイスフローとそのレート制限カウンターは Postgres に保存されているため、Postgres が復旧するまで失敗します
• 利用額上限の適用: デフォルトでは障害中はフェイルオープンになるため、推論は引き続き流れます。計測なしで稼働するよりもブロックしたい場合は、フェイルクローズに切り替えてください
• Readiness: デフォルトでは、Postgres に到達できなくなるとすぐに /readyz が not-ready を報告するため、すべてのレプリカが同時に readiness チェックに失敗します。チェックに合格したレプリカにのみトラフィックが届く環境では、ゲートウェイがまだ処理できる推論を含むすべてのトラフィックが、Postgres が復旧するまで失敗します。/healthz の liveness プローブはその間も合格し続けます。

Readiness の猶予期間

JWT シークレットのローテーション

1. 新しいシークレットを生成します。それを session.jwt_secret 配列の先頭に追加します。
2. デプロイをロールします。新しいトークンは新しいシークレットで署名され、古いトークンも引き続き検証されます。
3. ttl_hours に余裕を加えた時間が経過したら、古いシークレットを削除して再度ロールします。

Postgres

• データベース: PostgreSQL 本体（セルフホストまたはマネージド）で、最小バージョン以降のもの。分散 SQL データベースなど、Postgres プロトコルを実装しているだけのデータベースはサポートされていません。
• アドレス: store.postgres_url には 1 つのホストを指定します。データベースに複数のノードがある場合は、マネージドサービスのエンドポイント、ロードバランサー、仮想 IP など、それらの前段にあるアドレスを使用してください。フェイルオーバーにかかる時間より長い readiness の猶予期間を設定してください。

接続プールのサイズを決める

• レプリカ数: 同時に稼働する最大数を数えます。オートスケーリングの最大値（オートスケールしていない場合はレプリカ数）から始め、ローリングアップデートで古いレプリカを停止する前に起動される追加のレプリカを加えます。デフォルト設定の Amazon ECS や Cloud Run では、それが同数に及ぶことがあります。
• 残りの接続数: データベースの max_connections から、データベースが予約している分と他のクライアントが保持している分を差し引きます。PostgreSQL は superuser_reserved_connections を予約しており、デフォルトは 3 です。マネージドサービスではさらに多く予約されている場合があるため、そのドキュメントを確認してください。

• データベース: max_connections を引き上げる
• レプリカ: 稼働数を減らすか、ローリングアップデートで起動する追加のレプリカを減らすようオーケストレーターを設定する
• プール: store.max_connections を下げる。ただし、利用額上限が有効な場合は、各レプリカの負荷に十分な大きさを保ってください。そうしないと、利用額チェックが接続を待つ間にタイムアウトする可能性があり、ゲートウェイは spend check failed: spend precheck timed out をログに記録します。

アップグレード

• ドレインウィンドウ: ゲートウェイコンテナで CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS 環境変数を、120000 のようなミリ秒単位の正の整数に設定します。120s のような他の形式の値はゲートウェイに無視され、デフォルトの 25 秒が維持されます
• オーケストレーターの猶予期間: Kubernetes では terminationGracePeriodSeconds、Amazon ECS では stopTimeout

• Fargate 上の Amazon ECS: stopTimeout は最大 120 秒までです
• Cloud Run: SIGTERM の 10 秒後にインスタンスを停止するため、ドレインウィンドウの値にかかわらず、開いているストリームに与えられる時間は最大 10 秒です

セキュリティ

データフロー

脅威モデルの概要

• 開発者は生の上流キーの代わりに短命の JWT を保持します。CLI からゲートウェイへのレッグは RFC 8628 デバイスグラントを使用し、ゲートウェイの IdP との認可コード交換はデフォルト設定で PKCE を実行するため、インターセプトされた IdP 認可コードは無用です。
• デバイス検証ページは同一オリジン POST と RFC 8628 §5.1 ごとの IP ごとのレート制限を実装します。ユーザーコードブルートフォース耐性 を参照してください。
• ゲートウェイの IdP、OTLP コレクター、および provider: anthropic 上流へのリクエストは、サーバー側リクエストフォージェリ（SSRF）ガードを通じて行われます。DNS を解決し、リンクローカルとクラウドメタデータアドレスをブロックし、デフォルトではループバックをブロックし、接続を解決された IP にピン留めするため、オペレーター影響 URL はクラウドメタデータエンドポイントにリダイレクトできません。RFC 1918 プライベート範囲は意図的に許可されます。IdP と OTLP コレクターは一般的にプライベート IP に存在するため。その他のプロバイダーの場合、ゲートウェイは設定をロードするときにそれらのアドレスまたはメタデータホスト名を指定する base_url を拒否し、プロバイダーの SDK は DNS チェックなしで接続します。 プロキシのみのエグレス をオンにすると、そのアドレスチェックはフォワードプロキシに移動します：ゲートウェイはホスト名を渡し、プロキシのアロウリストはそれらの宛先を拒否する必要があります。 ゲートウェイが正当に到達する必要があるもの（ローカル開発 IdP やサイドカー OTLP コレクター（localhost など））がループバック上に存在する場合にのみ、ゲートウェイの環境で CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 を設定します。変数はすべてのオペレーター設定 URL のループバックブロックを緩和し、ポッドがクラウドメタデータエンドポイントに到達できるかどうかをチェックするブート時警告もスキップするため、コレクターに独自の内部アドレスを与えることをお勧めします。

• 侵害されたゲートウェイホスト：ホストは上流認証情報を保持し、管理設定 をすべての接続された開発者に配布するため、ゲートウェイの設定の制御は MDM の制御に匹敵します。CLI の 承認ダイアログ はシェル対応設定のサイレント変更を制限しますが、ホストセキュリティに置き換わりません。
• 悪意のある OIDC プロバイダー：プロバイダーはゲートウェイが信頼する id_token に署名するため、任意のアイデンティティを主張できます。IdP の検証と保護はあなたの責任です。

ユーザーコードブルートフォース耐性

コンプライアンス体制

• データレジデンシー：ゲートウェイ自体のデータプレーンは、Anthropic API が設定された上流の場合を除き、Anthropic に何も送信しません。その場合、既存のデータ処理契約が推論パスに適用されます。テレメトリ、監査、アイデンティティ、設定は設定した宛先にのみ行きます。
• ホストプロセストラフィック：ホストプロセスは Claude Code CLI です。claude gateway は Amazon Bedrock および Google Cloud の Agent Platform デプロイメントと同じサードパーティルールの下で実行され、Anthropic に何も送信しません。v2.1.227 より前では、ホストプロセスは製品バージョンとプラットフォームなどのスタートアップテレメトリを送信していました。これはコンテナ環境で CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 を設定することでオフにできました。これらのリリースはまた、ボート時に本文または認証情報なしで 1 つの HEAD リクエストを https://api.anthropic.com の /api/hello に送信していました。または環境が ANTHROPIC_BASE_URL を設定した場合はそれに、環境が HTTPS_PROXY などのプロキシ変数または mTLS クライアント証明書も設定していない限り。彼らは応答を無視したため、エグレスファイアウォールでそのリクエストをブロックしてもゲートウェイに影響しませんでした。
• クライアント分析：CLI はゲートウェイにサインインしている間、独自の使用分析とエラー報告を無効にします。最初のサインイン前に、CLI はまだ Anthropic にスタートアップイベントを送信します。これには、管理設定がゲートウェイサインインを強制するマシンも含まれます。これらもオフにするには、ゲートウェイサインインを強制する同じ クライアント側管理設定 で DISABLE_TELEMETRY を配信します。
• エラー報告：CLI はモデルリクエストが Anthropic のファーストパーティ API 以外のエンドポイント（Amazon Bedrock やカスタム ANTHROPIC_BASE_URL など）に行くときはいつでもエラー報告をオフにします。
• クライアントマシン：開発者の CLI は、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 と skipWebFetchPreflight: true が設定されていない限り、WebFetch ホスト名チェックとバージョンチェックを Anthropic に送信し続けます。プラグインマーケットプレイスのリクエスト には独自のオフスイッチがあります。データ使用 を参照してください。
• サーベイ評価：ゲートウェイにサインインしている間、CLI は Anthropic バウンド評価アップロードを分析ストリームと一緒に無効にするため、評価を Anthropic に送信しません。
• トランスクリプト共有：サーベイのトランスクリプト共有プロンプトで「はい」を選択すると、Anthropic にアップロードする代わりに ~/.claude/feedback-bundles/ の下にローカルファイルを書き込みます。
• クライアント更新：更新チェックはゲートウェイトラフィックとは別です。独自の配布を通じてバージョンをピン留めし、ラップトップがリリースをフェッチしてはいけない場合は DISABLE_UPDATES を設定します。DISABLE_AUTOUPDATER はバックグラウンド更新のみを停止し、claude update は引き続き機能します。
• TLS：本番環境で public_url を HTTPS 経由で提供します。ゲートウェイ自体のリスナー経由で listen.tls を使用するか、プレーン HTTP レプリカの前の TLS 終了 ingress から listen.public_url を設定します。どちらの場合でも。ゲートウェイはプレーン HTTP を拒否しません。IdP は本番環境で HTTPS を提供する必要があり、Postgres は ?sslmode=require をサポートします。ingress で Strict-Transport-Security を設定します。
• 脆弱性開示：セキュリティ問題の報告 に従います

プラグインマーケットプレイスのリクエスト

• マーケットプレイスリスト：そのマーケットプレイスを含まない strictKnownMarketplaces 許可リスト、またはそのマーケットプレイスを指定する blockedMarketplaces エントリ
• 環境変数：管理設定の env ブロック で CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL を "1" に設定

トラブルシューティング

• Gateway の問題: gateway の stderr（該当するウィンドウの）、gateway.yaml（シークレットは削除）、gateway のバージョン（ランディングページの / と /managed/settings の x-cc-gateway-version レスポンスヘッダーに表示）、および最近の変更内容
• ログイン問題: 開発者が claude --debug-file ./claude-debug.txt を実行して再現し、そのファイルと同じウィンドウの gateway の監査ログを送信
• 推論の問題: リクエストされたモデル、設定されたアップストリーム、およびリクエストの gateway 監査ログ（どのアップストリームがそれを処理したか、およびレスポンスステータスを記録）

サインイン後にリクエストヘッダーが大きすぎる

• v2.1.284 より古い gateway: gateway をアップグレードしてください
• limits.max_request_header_bytes が設定されている: 値を上げるか、キーを削除してください
• いずれにも該当しない、またはその後も 431 が続く: IdP が発行するグループを減らしてください。Okta、Microsoft Entra ID、Google Workspace がグループを提供する方法については、Identity provider setup を参照してください

• oidc.allowed_groups: サインインできるユーザーを決定します
• admin.admin_groups: gateway セッションで管理 API を呼び出せるユーザーを決定します
• managed.policies 内の match.groups: 開発者に適用されるポリシーを決定します
• アップストリームの groups: 開発者に対応するアップストリームを決定します
• rbac_group 支出上限: 開発者に適用されるグループ上限を決定します

長い思考がプロキシのタイムアウトで終わる

• 最初のリクエスト: 最初のレスポンスイベントである message_start を配信した後、Claude が思考している間は ping のみを運ぶストリームです。デフォルト設定では、Claude Code は約 12.5 分後にこのストリームを終了します。
• 残りの 10 件: 同じリクエストをストリーミングなしで送信し、その後再試行したもので、デフォルトでは合計 10 回送信されます。これらには ping が届かないため、応答が遅いとプロキシのタイムアウトに達します。

原因を確認する

Error streaming, falling back to non-streaming mode: Stream idle timeout - no chunks received

値を選ぶ

ポリシーで値を配信する

managed:
  policies:
    - match: {}
      cli:
        env:
          CLAUDE_STREAM_IDLE_TIMEOUT_MS: "1800000"

Anthropic API アップストリームでの長い思考

• 長いリクエスト: message_start を配信した後、Claude が思考している間は ping のみを運ぶストリームです。Claude Code はデフォルト設定では約 20 分後にこれを終了し、変数を上げるとそれより後に終了します。
• エラー: その後 Claude Code がストリーミングなしで送信するリクエストです。それぞれがゲートウェイからの 502 で失敗するか、プロキシのタイムアウトがゲートウェイの待機時間より短い場合はプロキシの 504 で失敗します。その待機時間は timeouts.upstream_ttfb_ms ですが、この修正のために上げる必要はありません。

関連

• Claude apps gateway の概要：クイックスタートと開発者接続
• 設定リファレンス：すべての gateway.yaml オプション