Claude Code LLM gatewayとは — 選び方と全体設計

Claude Codeをゲートウェイ経由で使う設計とは

ゲートウェイは、Claude Codeとモデルプロバイダーの間に組織が立てるプロキシです。Claude Codeはプロバイダーへ直接ではなくゲートウェイの宛先へAPIトラフィックを送り、ゲートウェイが組織側の認証情報を使って転送します。開発者はプロバイダーの認証情報を持たずゲートウェイに対して認証するだけになるため、認証・利用状況の追跡・予算管理・監査ログが1か所に集約されます。

ここで動く認証情報は2種類です。開発者ごとの開発者クレデンシャル(ゲートウェイが発行し、ゲートウェイへの認証と利用状況の紐付けに使う)と、組織で1つだけ持つプロバイダークレデンシャル(転送されたトラフィックすべてが共有する)です。

ゲートウェイを選ぶ選択肢は2つあります。Claude Codeのclaudeバイナリに組み込まれたAnthropic製のClaude apps gatewayを使うか、組織がすでに運用している社内の既存LLMゲートウェイにそのまま接続するかです。

どちらもプロバイダーとしてAnthropic API・Amazon Bedrock・Claude Platform on AWS・Google Cloud's Agent Platform・Microsoft Foundryを選べます。ゲートウェイを介さずプロバイダーへ直接つなぐ設定は、Bedrockなら/setup-bedrockウィザード、Google CloudのAgent Platformなら/setup-vertexウィザードが別途用意されています。

比較対象: Claude apps gatewayと既存のLLMゲートウェイ

Claude apps gatewayはAnthropic自身が作り、Claude Codeの各リリースと一緒にテストされているセルフホスト型ゲートウェイです。開発者は企業のIDプロバイダー(IdP)経由の/loginでサインインし、ゲートウェイがIdPグループ単位でモデルアクセスとmanaged settingsを強制し、組織自身の可観測性スタックへOpenTelemetry Protocol(OTLP)の利用状況メトリクスを送ります。

社内の既存LLMゲートウェイは、組織がすでに投資済みの製品をそのまま使う選択肢です。Anthropicはこうした製品を推奨・保守・監査しておらず、ゲートウェイ経由でClaude以外のモデルへルーティングすることもサポート対象外です。

起動までの経路も違います。Claude apps gatewayはclaude gateway --config gateway.yamlでその場からサーバーとして立ち上がるため、別製品を調達する調達プロセス自体が要りません。社内の既存ゲートウェイでは、Claude Codeが期待するエンドポイント・ヘッダー・リクエストフィールドの仕様に沿って製品側の設定や実装を合わせ込む作業が先に必要です。稼働中のClaude apps gatewayは、この仕様のスーパーセットをGET /protocolで自己申告するため、どこまで対応しているかを実装側で都度確認できます。

評価軸: 何で選ぶか

比較の軸は次の5つです。

• 認証方式: ブラウザSSOか、ゲートウェイ製品固有の方式か
• 保守負担: Claude Codeのリリースに自動追従するか、ヘッダーやリクエストフィールドの変更を自分たちで追いかける必要があるか
• アップストリームの切替容易性: 開発者の端末設定を変えずにプロバイダーを切り替えられるか
• CI・非対話パイプラインへの対応: サービストークンのような無人認証の手段があるか
• サブスクリプション課金との関係: ゲートウェイ経由の利用がclaude.aiのサブスクリプションとどう切り分かるか

Claude apps gatewayはClaude Codeと同じバイナリに含まれ同時にテストされるため、Claude Codeが送るヘッダーやリクエストフィールドをそのまま転送でき、運用側が追従用のリストを保守する必要がありません。別々に保守されているゲートウェイは、リリースのたびに変わるヘッダーやフィールドの転送ルールを自分たちで更新し続ける必要があります。

比較表

強み・弱み

Claude apps gatewayの強みは、追加の製品導入なしにゲートウェイを持てること、リリース追従の手間がかからないこと、SSOとOTLPテレメトリが標準で組み込まれていることです。弱みは、Linuxサーバーでしか動かないこと、CIパイプラインのような無人セッションを直接は認証できないこと(この場合はプロバイダーに直結する構成が必要)、そしてゲートウェイ自体の設定が管理コンソールを持たないYAMLファイルであることです。

既存LLMゲートウェイの強みは、すでにある投資と運用体制を活かせること、Claude以外のモデルも含めた組織全体のゲートウェイ戦略に統合できることです。弱みは、Claude Codeの進化に合わせて転送ルールを自分たちで更新し続ける必要があること、そして製品がAnthropic形式のエンドポイントを公開していない場合はプロバイダーを切り替えるたびに開発者の端末設定が影響を受けることです。

サブスクリプションとの関係で誤解しやすい点

ゲートウェイ用の認証情報を使って接続すると、その開発者のclaude.aiサブスクリプションは使われず、利用状況は組織のプロバイダーアカウントに従量課金で計上されます。ANTHROPIC_AUTH_TOKENを設定するか、Claude apps gatewayに/loginでサインインした時点で、そのセッションのサブスクリプションログインは無効になります。

ここで見落としやすいのが、ANTHROPIC_BASE_URLだけを設定してゲートウェイ用の認証情報を設定しないケースです。この場合トラフィックはゲートウェイ経由でルーティングされますが、保存済みのclaude.aiログインがそのまま有効な認証情報として残るため、サブスクリプションの利用上限と課金がそのまま適用されます。「ゲートウェイに向けたから課金方式も切り替わった」と思い込むと、想定と違う請求区分になります。

ゲートウェイの外で決まること

ゲートウェイが担うのはモデルAPIリクエストのルーティングだけで、次の4点は別の場所で設定します。

• どのモデルが応答するか: /modelコマンドやモデル関連の環境変数で開発者が選びます。Claude apps gatewayはグループ単位のavailableModels許可リストで選択肢を絞れますが、その範囲内で選ぶのは開発者自身です
• ゲートウェイを通らないネットワークトラフィック: バージョンチェックやダウンロードはゲートウェイとは別にAnthropicへ直接送られます。ネットワークには引き続き必要なドメインへの疎通が要り、任意のストリームを止めたい場合は専用の環境変数で無効化します
• 社内のHTTPプロキシ: HTTPS_PROXYはゲートウェイを含むすべての通信先の手前に立つため、ゲートウェイとは別に設定が必要です。Claude apps gatewayを自社でホストする場合、サインイン時のチェックはプロキシのホストもプライベートネットワーク上にあることを求めるため、そうでなければゲートウェイのホストをNO_PROXYに加えてCLIが直接接続できるようにします
• クライアント側のテレメトリ送信: OpenTelemetryのメトリクス送信先など、開発者の端末が持つクライアント側のテレメトリ設定はゲートウェイの管理範囲外で、別途設定します

これらの設定はいずれも、開発者の端末に配布するmanaged settingsファイルを通じて組織側から統制するのが基本です。ゲートウェイのURLや許可モデルの一覧を個々の開発者に手動設定させると、ゲートウェイを選んだ利点である「1か所で管理する」という前提が崩れます。

使い分け早見表

よくある質問

Claude apps gatewayと社内ゲートウェイを両方運用してもいいですか

構成上は可能です。開発チームごとにグループが分かれていて、一部はデータレジデンシー要件でClaude apps gatewayを使い、別のチームはClaude以外のモデルも扱う社内ゲートウェイを使う、という併用は矛盾しません。ただし監査ログと利用状況の集計先が分かれるため、組織全体の可視化をどちらか一方に寄せるか、両方のテレメトリを同じバックエンドに集約するかを先に決めておくと、後から利用実態を追跡しやすくなります。

ゲートウェイを使わずに直接プロバイダーへ接続する場合と何が違いますか

ゲートウェイを介さない直接接続では、開発者ごとにプロバイダーの認証情報を配布することになり、オフボーディング時の失効やモデルアクセスの制御を個々の設定ファイルやIAMポリシーで行う必要があります。ゲートウェイはこの管理をゲートウェイ側の1か所に集約する仕組みで、認証情報自体を開発者に渡さずに済む点が最大の違いです。

まとめ

Claude Codeをゲートウェイ経由で使う設計は、認証・保守負担・アップストリーム切替・CI対応・サブスクリプション課金という5つの軸で選び分けます。追加のインフラを持ちたくない組織や、Claude Codeのリリースに自動で追従したい組織にはClaude apps gatewayが向き、すでに社内ゲートウェイへ投資済みで複数プロバイダーのモデルを一元管理したい組織はその継続が向きます。どちらを選んでも、ANTHROPIC_BASE_URLだけの設定ではサブスクリプション課金が維持される点と、承認する開発者が誰もいないCIのような無人パイプラインはゲートウェイのブラウザSSOでは認証できない点(サインイン済みの端末上で動くclaude -pやAgent SDKのセッションは対象外)は共通の注意点です。