Claude CodeのLLMゲートウェイ互換性 — 対応製品とサブスクの関係
Claude Codeとゲートウェイ製品の互換性はAPI形式で決まります。対応形式・Claude apps gatewayとの違い・サブスクリプションとの関係をまとめます。
Claude Codeがどのゲートウェイ製品と互換性を持つかは、製品名ではなく対応するAPI形式で決まります。Anthropic Messages形式を話せるゲートウェイであれば製品を問わず動き、Anthropicは特定の製品を推奨・保証・監査しておらず、ゲートウェイ経由でClaude以外のモデルへルーティングすることもサポートしていません。どの製品を選ぶかの比較やサブスクリプションとの関係はClaude CodeのLLMゲートウェイにまとめており、この記事では互換性を左右する仕組み(対応API形式・転送要件・機能差分)に絞って掘り下げます。
Claude Codeがどんな形式のゲートウェイと互換性を持つか
Claude Codeはゲートウェイに対して3つのAPI形式のいずれかで話しかけます。どの形式を使うかはClaude Code側の環境変数で決まり、ゲートウェイ側がその形式を実装していれば製品は問いません。
| 形式 | 選択する変数 | 主なエンドポイント |
|---|---|---|
| Anthropic Messages | 選択する変数ANTHROPIC_BASE_URL | 主なエンドポイント/v1/messages |
| Amazon Bedrock InvokeModel | 選択する変数ANTHROPIC_BEDROCK_BASE_URL + CLAUDE_CODE_USE_BEDROCK=1 | 主なエンドポイント/model/{model}/invoke系 |
| Google Cloud's Agent Platform rawPredict | 選択する変数ANTHROPIC_VERTEX_BASE_URL + CLAUDE_CODE_USE_VERTEX=1 | 主なエンドポイント:rawPredict系 |
もっとも多くのゲートウェイ製品が実装しているのはAnthropic Messages形式です。Microsoft FoundryとClaude Platform on AWSも同じくAnthropic Messages形式を話しますが、Claude CodeからはANTHROPIC_FOUNDRY_BASE_URL・ANTHROPIC_AWS_BASE_URLという別の変数で振り分けます。Claude Platform on AWSを前段に置くゲートウェイはanthropic-workspace-idヘッダーの転送も必要です。
3形式に共通する条件が2つあります。1つ目はレスポンスをストリーミングで中継することです。バッファすると応答が固まったように見えるだけでなく、ANTHROPIC_BASE_URL・ANTHROPIC_AWS_BASE_URL経由の場合はストリーム中に送られるkeep-alive pingの転送まで含めて必要です。これらの経路のクライアントは中継されるバイト数そのものを監視しており、既定300秒の沈黙が続くとストリームを打ち切ります。pingを剥がす、あるいは一定量たまるまでバッファしてから流すゲートウェイを挟むと、長い思考やツール実行を挟む応答が途中で切断されます。一方ANTHROPIC_BEDROCK_BASE_URL・ANTHROPIC_VERTEX_BASE_URL・ANTHROPIC_FOUNDRY_BASE_URL経由はこのバイト監視の対象外で、代わりに5分のアイドルタイムアウトが効くため、pingの転送有無そのものはこの3経路では問題になりません。2つ目はヘッダー・リクエストボディを許可リストではなく無改変で転送することです。Claude Codeはリリースごとに新しいanthropic-beta値やボディフィールドを追加するため、ゲートウェイ側が特定の項目だけを転送する作りだと、次のリリースで新機能から静かに、あるいは400エラーとともに取り残されます。
もうひとつ見落としやすい点があります。Claude CodeがAnthropic Messages形式で話しているとき、ゲートウェイの先がBedrockやVertexであっても、Claude Codeはフル機能セットを送ります。BedrockやVertexの形式自体で直接話しかけている場合はその2社が受け付ける範囲のサブセットしか送りません。Anthropic Messages形式を受けてBedrock/Vertexへ中継するゲートウェイは、両者の差を橋渡しする責任を負います。ここが噛み合わないと、コンテキスト管理やアダプティブ推論のような新しめの機能が400エラーで拒否される原因になります。
Claude apps gatewayと自社運用の他ゲートウェイ製品の違い
Claude Codeには2つのゲートウェイの選択肢があります。claudeバイナリに同梱されたAnthropic純正のClaude apps gatewayと、社内ですでに動いている別のゲートウェイ製品です。両者の認証・保守追従・切替容易性を軸にした選定比較はClaude CodeのLLMゲートウェイの比較表に譲り、ここでは互換性に直結する制約を1つだけ挙げます。Claude apps gatewayのサインインは社内IdPでのブラウザSSOのみで、ANTHROPIC_AUTH_TOKENのようなサービストークン方式を持ちません。承認する開発者がその場にいないCIパイプラインやバッチジョブはこの方式で認証できず、そうした自動化からはAnthropic Console・Bedrock・Vertexなどのプロバイダーに直結する構成が別途必要になります。
サブスクリプションとゲートウェイはどう関係するか
ゲートウェイを挟んだときに開発者のclaude.aiサブスクリプションがどうなるかは、設定する変数の組み合わせで決まります。認証情報変数(ANTHROPIC_AUTH_TOKEN・ANTHROPIC_API_KEY)またはapiKeyHelperが有効な間はサブスクリプションログインが使われず、課金先は認証情報の持ち主に切り替わります。ANTHROPIC_BASE_URLだけを設定し認証情報変数を設定しない場合は、保存済みのclaude.aiログインが有効なまま残り、その利用上限と課金が適用されます(このときゲートウェイはanthropic-betaヘッダーのOAuth能力値を転送する必要があり、転送し損なうと401で失敗します)。どちらの構成を選ぶかの判断材料はClaude CodeのLLMゲートウェイで扱っています。
ゲートウェイを選ぶときに確認すべきポイント
ゲートウェイが一箇所にまとめる管理項目は5つです。プロバイダーの鍵をサーバー側だけに置く認証情報の集約、開発者・チーム単位の利用量の可視化、予算やレート制限の統制、コンプライアンス向けの監査ログ、そして開発者のマシンを触らずにプロバイダーを切り替えられるプロバイダー切り替えです。最後のプロバイダー切り替えだけは、ゲートウェイがAnthropic形式の単一エンドポイントを公開している場合に限られます。プロバイダー独自の形式をそのまま公開するゲートウェイは、クライアント側の設定がそのプロバイダーに固定されます。
引き換えにゲートウェイ自体が自社で運用するインフラになります。Claude Codeはリリースのたびに機能を追加するため、転送していない項目があると対応する機能が壊れます。すでに動いているゲートウェイ製品に乗せるなら、その製品が転送ルールをどれだけ追従させられるか(自動なのか手動更新が必要なのか)を、認証やコスト管理の機能そのものより先に確認しておくと後々の手間が変わります。実際に接続する開発者向けの設定手順はClaude CodeをLLMゲートウェイに接続する方法にまとめています。
ゲートウェイが扱わない設定
ゲートウェイに任せられると誤解されがちな設定として、モデル選択(/modelコマンドや環境変数で開発者が選ぶ)・ゲートウェイ以外の通信(バージョンチェックなどはゲートウェイの外へ直接送られる)・クライアント側のテレメトリ(送信先はサインイン方法で決まる)の3点があり、詳細はClaude CodeのLLMゲートウェイにまとめています。互換性の観点で押さえておくべきなのは、これらがどれもAPI形式の話ではなく認証・ネットワーク設定の話だという点です。企業プロキシ環境も同様にゲートウェイとは別に設定します。HTTPS_PROXYはClaude Codeが話すすべての相手(ゲートウェイ自体を含む)との間に入るため、ネットワークがプロキシを要求するならゲートウェイの設定に加えて明示的に構成します。
Claude apps gateway経由で挙動が変わる機能
Anthropic純正のClaude apps gatewayを選んだ場合でも、直接接続と全く同じというわけではありません。主な違いは次のとおりです。
| 機能 | 状態 | 理由 |
|---|---|---|
| サーバーサイドのWeb検索 | 状態使えない | 理由Claude Codeがどのプロバイダーに届いているか分からず対応を確認できないため |
| Remote Control | 状態使えない | 理由ゲートウェイセッションでは非対応というエラーが表示される |
| 1時間のキャッシュTTL | 状態使えない | 理由ルーティング先の全プロバイダーが1時間TTLに対応しているとは限らないため、5分TTLで動く |
| ファーストパーティ限定の最適化(グローバルキャッシュスコープ等) | 状態使えない | 理由直接接続専用の最適化として扱われる |
| 標準のプロンプトキャッシュ | 状態使える | 理由cache_controlをどのプロバイダーにも転送する |
| Auto mode | 状態使える | 理由ただしサードパーティプロバイダーで使えるモデルに限られる |
自社運用の他ゲートウェイ製品でも、この一覧はおおむね同じ理由(Claude Codeがプロバイダーを特定できない・全プロバイダーが対応しているとは限らない)で当てはまります。導入前にどの機能が必須かを洗い出しておくと、導入後に「使えるはずの機能が無い」という問い合わせを減らせます。
よくある質問
一般的なAPIゲートウェイ製品ならどれでもそのまま使えますか
Anthropicは特定の製品を推奨・保証・監査していませんが、Anthropic Messages形式を含む対応API形式のいずれかを実装していれば製品は問いません。ストリーミングの中継とヘッダー・ボディの無改変転送ができているかが実質的な判定基準になります。
ゲートウェイ経由でClaude以外のモデルにルーティングできますか
Anthropicはゲートウェイ経由でClaude以外のモデルへルーティングすることをサポートしていません。
ゲートウェイ製品を途中で乗り換えると開発者側の設定も変わりますか
ゲートウェイがAnthropic形式の単一エンドポイントを公開している限り、開発者側は変わりません。ベースURLと認証情報の値をゲートウェイの設定側で変えるだけで済みます。プロバイダー独自の形式をそのまま公開するゲートウェイから乗り換える場合は、開発者側の変数もプロバイダー専用のものに変える必要があります。
認証情報を配らずベースURLだけ配ることに意味はありますか
あります。ルーティングと監査ログだけをゲートウェイに集約しつつ、個人のサブスクリプションをそのまま使い続けたい場合の構成です。ゲートウェイ側がanthropic-betaヘッダーを転送できることが条件になります。
まとめ
ゲートウェイとの互換性はAPI形式で決まり、製品を選ぶ基準はAnthropic Messages形式を含む対応形式を実装しているかどうかです。Anthropic純正のClaude apps gatewayはデータレジデンシー要件のある組織向けの選択肢で、すでに社内でゲートウェイ製品を運用しているなら継続利用が手数の少ない選択になります。どちらを選ぶにしても、認証情報変数を配るかどうかがサブスクリプションと課金の扱いを分ける分岐点です。
関連する記事
Claude Code をもっと見る →Claude Code(クロードコード)とは — できること・料金・使い方・CLIから8つの拡張機構まで
Claude Codeの機能比較 — Bedrock・Vertex・Foundry別対応表
Bedrock/Vertex/FoundryでClaude Codeが使えない機能一覧
GitHub Actions Bedrock連携 — Claude CodeをVertex/Foundryにも対応
VS Code拡張でサードパーティプロバイダーを使う設定 — Bedrock/Vertex/Foundry
Claude Code v2.1.158 — Auto modeがBedrock・Vertex・Foundryに対応