ネットワークと LLM ゲートウェイ

社内ネットワークの制約（プロキシ、TLS 検査、クライアント証明書、外向き通信の制限）の下で Claude Code を動かす設定と、組織が運用するゲートウェイ（Claude Code とモデル提供元の間に置くプロキシ）を使う方法のページです。主な読者はネットワーク・セキュリティの管理者で、開発者向けの接続手順も含みます。

要点#

• 設定は環境変数で行い、settings.json の env ブロックにも書ける。シェルで export した値は起動時に1回だけ読まれる
• ゲートウェイを使うと、認証・利用状況の把握・予算・監査ログを1か所に集められる。開発者は提供元の資格情報を持たない
• ゲートウェイは、Claude Code に含まれる自前のもの（Claude apps gateway）か、すでに組織が運用しているもの（このページの「ほかの LLM ゲートウェイ」）から選ぶ
• バックグラウンドのエージェントは、シェルの環境変数を引き継がないことがある。ネットワーク関連の変数は設定ファイルの env に書く
• 通信先の許可リスト（allowlist）は、利用する機能と導入方法によって必要なホストが変わる

プロキシ#

標準のプロキシ環境変数に従います。

# HTTPS プロキシ（推奨）
export HTTPS_PROXY=https://proxy.example.com:8080
# HTTP プロキシ（HTTPS が使えない場合）
export HTTP_PROXY=http://proxy.example.com:8080
# プロキシを迂回する（空白区切りでもカンマ区切りでもよい）
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"
# すべての要求で迂回する
export NO_PROXY="*"

プロキシの URL は、起動時に確認される唯一の設定です。解釈できない値（http:// が無いなど）は、直すべき変数名を示して起動を止めます。

CA 証明書#

既定では、同梱の Mozilla の CA 証明書と OS の証明書ストアの両方を信頼します。OS ストアの読み取りには tls.getCACertificates のある実行環境が要ります（ネイティブインストーラは常に対応。npm 版は Node 22.15 以降）。古い Node では、同梱のセットと NODE_EXTRA_CA_CERTS だけが効きます。OS ストアにルート証明書が入っていれば、企業の TLS 検査プロキシは追加設定なしで動きます。

export CLAUDE_CODE_CERT_STORE=bundled      # 同梱のセットだけ
export NODE_EXTRA_CA_CERTS=/path/to/ca-cert.pem

mTLS（クライアント証明書）#

証明書と鍵は、起動時と設定を適用するたびに（たとえば managed settings の env がセッション中に変わったとき）読み直します。更新するときは、同じパスのファイルを置き換えます。接続リセットや TLS ハンドシェイクのエラーで API リクエストが失敗すると、両方を読み直し、新しい組でやり直します（v2.1.232 以降）。

• ファイルの監視はしない。置き換えた瞬間には何も起きず、失敗後のやり直し、または次に設定を適用するときに新しい組を使う
• ゲートウェイが接続リセットや TLS の拒否を返したときは読み直す。ハンドシェイクを完了して HTTP エラーを返したときは読み直さない（次に設定を適用するか再起動したときに読まれる）
• 書き換え途中で証明書と鍵が食い違っていたら、前の組を保ち、次の失敗で読み直す
• OTLP テレメトリのエクスポーターは、最初の使用時に読んだ証明書を保つ。更新を届けるには Claude Code を再起動する
• 更新が反映されたか確かめるには、デバッグログを有効にして、Stale connection — reloaded rotated mTLS client material を探す。設定の適用で拾った場合はこの行が出ないので、無いだけでは失敗とは言えない
• 現在の組が期限切れになる前にファイルを置き換える

設定ファイルの env を無視する場面#

設定の確認#

プロキシの間違いや証明書のパスの誤りは、たいてい後のリクエストで接続エラーや証明書エラーとして出ます。確認するには、デバッグログを付けて起動します。出力は ~/.claude/debug/<session-id>.txt（または --debug-file <path> で指定した場所）に出ます。

claude --debug

CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERT
mTLS: Loaded client key from CLAUDE_CODE_CLIENT_KEY

読めなかったときは、理由とともに Failed to read か Failed to load の行が出ます。対話セッションの /status でも、次の行を見られます。

バックグラウンドのエージェントに適用する#

バックグラウンドエージェントは、起動したターミナルの中では動きません。ユーザーごとのスーパーバイザーのプロセスがオンデマンドで起動し、シェルより長く生きます。そのため、シェルで export しただけのプロキシ・CA・mTLS の変数は、そのシェルがたまたまスーパーバイザーを最初に起動したときだけ届き、別のシェルが起動したときは黙って届きません。OS にインストールされたスーパーバイザーは、シェルの環境を全く受け取りません。

社内ランチャーを設定で指定する#

すべての Claude Code のプロセスを、サンドボックスやネットワーク制御、資格情報の注入を行う社内ランチャー経由で起動させたい組織向けの設定です。スーパーバイザーとワーカーは PATH の claude ではなく固定のパスから起動するので、PATH の手前に置いたラッパーは迂回されます。processWrapper 設定（環境変数は CLAUDE_CODE_PROCESS_WRAPPER。両方あれば環境変数が優先）が、それらをランチャーの下で起動します。

ランチャーが対象にするプロセス#

• claude agents とバックグラウンドセッションが、必要に応じて起動するバックグラウンドサービス
• エージェントビューの各行の端末ホストと Claude Code のセッション（待機中のウォームスタンバイを含む）
• 更新や異常終了のあとで、サービスが再起動するセッション
• 更新を完了するための Claude Code の自己再起動（エージェントビューの「更新のため再起動」を含む）
• リモートコントロールが起動するセッションのプロセス（v2.1.210 以降）
• tmux や iTerm2 でエージェントチームが起動する分割ペインのチームメイト（v2.1.210 以降）

Windows では変数が無視され、ラップなしで起動します（exec に依存するため。デバッグログに警告が出るだけ）。展開の計画では、Windows のマシンは「ラップされない」と数えてください。

ランチャーを通らないプロセス#

• ランチャーの設定前に作られたユニットファイルから、launchd や systemd が起動するインストール済みのバックグラウンドサービス。/status と claude daemon status が、不一致の間は警告を出す。サービスが再起動してからは、サービスが起動するセッションはランチャーを通る
• 自分でターミナルから起動したセッション。カバーするには、PATH の手前に、実体を呼ぶランチャーを実行する claude というスクリプトを置く（管理されたシンボリックリンクは置き換えない）
• claude-cli:// のディープリンクの最初のプロセス（OS のプロトコルハンドラが直接起動する）。その後にバックグラウンドで起動するものはランチャーを通る。この経路を完全に閉じるには、disableDeepLinkRegistration 設定でハンドラの登録を止める（ディープリンク）
• --worktree と --tmux を組み合わせたときの再起動（ターミナルマルチプレクサが起動する）
• Claude in Chrome が登録するネイティブメッセージングホスト（ブラウザが起動する）

ランチャーを設定すると、ps などで claude bg-pty-host と claude bg-spare のラベルが見えなくなります（ランチャーの exec が引数を作り直すため）。隠す意図のある動作ではありません。

設定の手順#

1. 絶対パスに実行可能なスクリプトを置く（例 /opt/corp/launcher）。Claude Code のコマンド全体を引数にして実行されるので、最後に exec "$@" で自分を置き換える
2. 設定ファイルの env に CLAUDE_CODE_PROCESS_WRAPPER を書く（シェルの export では足りない）。1台なら ~/.claude/settings.json、全社なら managed settings。複数の場所にあるときは managed settings の値が、~/.claude/settings.json とシェルの export より優先される
3. 動いているバックグラウンドサービスと開いているセッションを再起動する。claude daemon stop --any でオンデマンドのサービスを止める（インストール済みのサービスは --any なし）。設定の配布のあとに最初に起動するセッションが、ラップされていない古いサービスを自動で退かせることもある
4. /status の Self-exec の行で、解決された起動コマンドと、動いているサービスとの不一致の警告を確認する。claude daemon status も同じ情報を出し、変数を外したあとでも見られる

#!/bin/sh
# 組織の処理（サンドボックスへの入場・ネットワーク制御・資格情報の注入など）
exec "$@"

{
  "env": {
    "CLAUDE_CODE_PROCESS_WRAPPER": "/opt/corp/launcher"
  }
}

• processWrapper は、managed settings をキー単位で配る組織向け。リモートの managed settings で配ると、管理者提供の実行ファイルを動かす設定として、セキュリティの承認ダイアログに出る
• プロジェクト・ローカルの設定では設定できない。.claude/settings.json と .claude/settings.local.json の CLAUDE_CODE_PROCESS_WRAPPER は警告つきで無視され、processWrapper キーも読まれない
• ~/.local/bin/claude のシンボリックリンクをランチャーに置き換えていたら、同じ変更で元に戻す（置き換えたままだと、バックグラウンドサービスが2つのランチャーを通り、インストールが外部管理の扱いになる）

ランチャーの契約#

起動できないランチャーでは、Claude Code はラップなしで起動せず、起動自体を拒否します。

値の形式は、変数も設定も同じです。多くは絶対パスを書きます。ランチャーに引数を渡すなら、パスのあとに書きます。シェルのコマンドではなく引数のリストとして解釈されます。

• 空白でトークンを分け、空白を含むトークンは二重引用符で囲む
• [ で始まる値は、JSON の文字列の配列として読む（例 ["/opt/corp/launcher", "--profile", "cc"]）
• シェルの構文は使えない（変数展開・グロブなし）。引用符で囲んでいない ;・|・&・$( は、設定エラーとして拒否する

使えない値のときは、起動を拒否して理由を報告します。CLAUDE_CODE_SHELL_PREFIX との違いは、CLAUDE_CODE_PROCESS_WRAPPER が Claude Code 自身のプロセスを包んでコマンドを別々の argv として渡すのに対し、CLAUDE_CODE_SHELL_PREFIX は Claude が実行するシェルコマンド（Bash ツール・フック・stdio MCP サーバー）を包み、1つのシェルエスケープ済み文字列を $1 で渡す点です。片方向けに書いたランチャーはもう片方では動きません。

ストリームの無通信タイマー#

応答が静かになったストリームを、4つの独立したタイマーが中断します。死んだ接続がハングせず、失敗して再試行になるようにするためです。

CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1 を設定すると、Bedrock ではバイト単位の監視が本文の無通信タイムアウトに置き換わります。CLAUDE_STREAM_IDLE_TIMEOUT_MS も、Bedrock のストリームが静かでいられる時間を決めます。Bedrock でバイトが届いても、イベント単位の監視はリセットされません。デバッグログには、ストリームごとに wire-heartbeat: _chunkTimes absent で始まるメッセージが出ます。

監視が止まったストリームを中断すると、ストリームの途中の失敗として扱われ、どこまで届いていたかに応じて、再試行するか、エラーでターンを終えるか、完了分を残して不完全な応答の通知を出すか、通常どおり終えるかが決まります。エラー一覧を見てください。

通信先の許可リスト#

次の URL へのアクセスを、プロキシとファイアウォールで許可します。コンテナや制限のある環境では特に重要です。初回の接続確認が api.anthropic.com か platform.claude.com へ届かないときは、このリストを見ます。

• npm 経由か自前のバイナリ配布なら、エンドユーザーはネイティブインストーラと自動更新のための downloads.claude.ai が要らない。一方、npm と bun のインストールには、組織がミラーしていなければ registry.npmjs.org が要る
• 2つの Datadog のホストは省略可のテレメトリだけで、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で両方を止められる。サードパーティのプロバイダでは、ホストが CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST を設定してテレメトリの指標が既定でオンでも、これらには送らない
• Bedrock・Vertex AI・Foundry、またはサインイン済みの Claude apps gateway のセッションでは、モデルの通信と認証は提供元かゲートウェイに行き、api.anthropic.com・claude.ai・platform.claude.com へは行かない。WebFetch は、設定で skipWebFetchPreflight: true にしない限り、ドメイン安全確認で api.anthropic.com を呼ぶ
• ANTHROPIC_BASE_URL でゲートウェイを通していても、fast mode の可用性の確認は api.anthropic.com を呼ぶ（HTTP プロキシには従う）。ブロックが原因なら、プロキシで api.anthropic.com を許可する。ゲートウェイが発行した資格情報を Anthropic が拒否したときも同じ接続エラーになり、そのときは許可リストでは直らない（直す変数は fast mode の項を参照）

組織の IP 許可リストとプロキシの出口#

組織が Claude の IP 許可リストを有効にしているなら、bridge.claudeusercontent.com を claude.ai や api.anthropic.com と同じプロキシの出口へ通します（Zscaler の同じアプリセグメントや Netskope のステアリングポリシーなど）。それができないときは、プロキシがそのホストへ使う出口アドレスを許可リストに足します。ただし、そのアドレスが組織専用のときだけです。共有の出口の範囲は、プロキシ事業者の他の顧客も通します。Anthropic はそのホストへの接続を、届いたアドレスで IP 許可リストと照合するので、許可リストに無いアドレスから出ると、ほかが動いていても Chrome 拡張だけつながりません。

GitHub の許可リストとファイアウォール#

Anthropic ホストの環境のクラウドセッションとコードレビューは、Anthropic が管理するインフラからリポジトリへ接続します。セルフホスト環境のセッションは、Anthropic の git プロキシを選ばない限り、ネットワークの内側から接続します。

• GitHub Enterprise Cloud の組織が IP アドレスで制限しているなら、インストール済みの GitHub App への IP 許可リストの継承を有効にし、Anthropic の送信 IP アドレスも許可リストへ足す。継承が及ぶのは、Claude の GitHub App がインストールとして行うリクエストだけで、ユーザーに代わって行うリクエストには及ばない
• ファイアウォールの内側の GitHub Enterprise Server は、Anthropic の送信 IP アドレスを許可して、Anthropic のインフラから clone やレビューコメントの投稿ができるようにする。セルフホスト環境のセッションは内側から GHES に届くので、この公開が要るのは、Anthropic ホストのセッションと、リポジトリの選択などホスト側の事前フローと、Anthropic の git プロキシを選んだセルフホストのランナーだけ。SCM コネクタは使えないので、内側からしか届かない GHES には、ホスト側の事前フローが届かない

デスクトップと claude.ai#

上の表は単体の CLI の分です。デスクトップアプリとブラウザの claude.ai は、アプリのコードとユーザーのコンテンツを、ほかの Anthropic の CDN のホスト（assets-proxy.anthropic.com と、アーティファクトを配信するそのほかの *.claudeusercontent.com）から読み込みます。claude.ai だけ許可してこれらを止めると、エラーではなく白紙のページになります（デスクトップアプリも参照）。

デスクトップアプリと claude.ai は、会話の中の一部のツールの結果を、対話型のウィジェットとして描くこともあります（コネクタが提供する MCP Apps など）。そのウィジェットは claudemcpcontent.com の生成されたサブドメインから読み込まれるので、*.claudemcpcontent.com をワイルドカードのまま許可します。ブロックしても、アプリのほかの部分は動きますが、そのウィジェットは読み込まれません。

• Google Fonts の書体を使うアーティファクトは、fonts.googleapis.com と fonts.gstatic.com も要求する。どちらも省略可。ブロックすると代替の書体で描画される
• アーティファクトが読み込める JavaScript ライブラリの配信元は、cdnjs.cloudflare.com・cdn.jsdelivr.net・cdn.tailwindcss.com・code.jquery.com・unpkg.com だけ。ブロックすると、ライブラリに依存する部分が動かず、フォントと違って代替が無い
• どちらも、サイレントなドロップではなく即時の拒否でブロックする（初回描画が遅れず、すぐ失敗する）

ゲートウェイの全体像#

ゲートウェイは、組織が Claude Code とモデル提供元の間に置くプロキシです。Claude Code は API の通信を、提供元ではなくゲートウェイへ送り、ゲートウェイが組織の持つ資格情報で転送します。開発者は提供元の資格情報を持たず、ゲートウェイへ認証します。そのため、認証・利用状況の把握・予算・監査ログを、組織が管理する1か所で行えます。提供元は Anthropic の API でも、Bedrock・Vertex AI・Foundry でもよく、ゲートウェイの設定で決まります。

2種類の資格情報があります。

ゲートウェイの選び方#

Claude apps gateway のサインインはブラウザの SSO の段で、サービストークンの流れは無いので、承認する開発者のいない CI パイプラインは認証できません（提供元に直接設定します）。開発者がサインイン済みのマシンでの Agent SDK のセッションと claude -p は、そのマシンのゲートウェイのセッションを使い、そのポリシーに従います。

サブスクリプションとの関係#

ゲートウェイの資格情報で接続すると、使用量は組織の提供元アカウントへ API の料金で課金され、開発者の claude.ai のサブスクリプションは使われず、課金もされません。ゲートウェイ用に ANTHROPIC_AUTH_TOKEN を設定するか、Claude apps gateway へ /login でサインインすると、そのセッションではサブスクリプションのログインが止まります。apiKeyHelper が有効なときも同じです。

例外は、ANTHROPIC_BASE_URL だけを設定して、ゲートウェイの資格情報を設定しない場合です。リクエストはゲートウェイを通りますが、保存済みの claude.ai ログインが有効な資格情報のままなので、サブスクリプションの使用量の上限と課金が適用されます。この通信を Anthropic へ渡すゲートウェイは、anthropic-beta の OAuth の capability を転送しなければなりません。

ゲートウェイとは別に設定するもの#

• どのモデルが答えるか：/model かモデルの環境変数で選ぶ。ゲートウェイが決めるのは行き先で、開発者の選択ではない。Claude apps gateway はグループごとの availableModels で選択肢を絞れる
• ほかのネットワーク通信：バージョン確認とダウンロードは、ゲートウェイを通らず Anthropic へ直接行く。上の通信先への出口を許可するか、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で省略可のストリームを止める
• クライアントのテレメトリ：Claude apps gateway にサインインしたセッションでは、Anthropic 宛てのクライアント分析を止める。サインイン前の起動時の分析も止めるには、各端末のクライアント側の managed settings で DISABLE_TELEMETRY を配る。ほかのゲートウェイでは、提供元で決まる
• 社内の HTTP プロキシ：HTTPS_PROXY は、ゲートウェイを含むすべての相手との間に入る。必要ならゲートウェイとは別にプロキシも設定する。自前でホストする Claude apps gateway では、サインインがプロキシのホストも私設ネットワークにあるかを確かめる。そうでなければ、ゲートウェイのホストを NO_PROXY に足して、CLI が直接つなぐようにする

ほかの LLM ゲートウェイ#

サポートされる API 形式（下の「API 形式」）を公開していれば、どのゲートウェイでも使えます。ここでの「ゲートウェイ」は、Claude apps gateway ではなく、すでに組織が運用しているものです。ゲートウェイの製品はその文書に従って立て、Claude Code 側は次の手順で整えます。

ゲートウェイで1か所にまとめられるのは、資格情報（提供元のキーはサーバー側に置き、開発者はゲートウェイの資格情報を持つ）・利用状況（開発者やチーム単位）・コストの制御（予算とレート制限）・監査ログ・提供元の切り替え（開発者のマシンを触らずに）です。提供元の切り替えは、上流にかかわらず、ゲートウェイが単一の Anthropic 形式のエンドポイントを公開している場合のみです。代わりに、提供元独自の形式を公開すると、クライアントの設定がその提供元に結びつきます。代償は、ゲートウェイが組織の運用するインフラになることです。Claude Code はリリースごとに機能を足すので、それを転送しないゲートウェイでは、対応する機能が壊れます。

開発者向け：ゲートウェイへ接続する#

組織が管理者に配らせていれば、設定は何も要りません。確かめるには次の順に見ます。

1. claude を起動する。ログイン画面が出たら、ゲートウェイの資格情報が配られていない
2. セッションが始まったら /status の「Status」タブで、Anthropic base URL（ゲートウェイのアドレスがあるときだけ出る）と、Auth token か API key の行（ANTHROPIC_AUTH_TOKEN・ANTHROPIC_API_KEY・apiKeyHelper の名前）を見る。Login method に claude.ai のアカウントが出ていれば、資格情報は配られていない
3. 適当なプロンプトを送って、エラー無しで応答が返ることを確かめる

自分で設定するには、ゲートウェイの担当者から、ベース URL と資格情報（キーかトークンの文字列、またはそれを取るコマンド）をもらいます。

変数は、資格情報を送るヘッダーが違います。ANTHROPIC_AUTH_TOKEN は Authorization: Bearer、ANTHROPIC_API_KEY は x-api-key、apiKeyHelper は両方です。間違った変数だと、ゲートウェイが読まないヘッダーに入って 401 になります。

export ANTHROPIC_BASE_URL=https://llm-gateway.example.com
export ANTHROPIC_AUTH_TOKEN=sk-gateway-key

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm-gateway.example.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-gateway-key"
  }
}

• シェルの export はそのターミナルのセッションだけに効く。ドックやスタートメニューから起動したエディタには届かない。バックグラウンドエージェントにも確実には届かないので、必ず通したいゲートウェイは設定ファイルに書く
• 設定ファイルは ~/.claude/settings.json（全プロジェクト）か .claude/settings.local.json（1プロジェクト）。シェルの export と設定ファイルの env で同じ変数を設定したときは、設定ファイルの値が効く
• 手で作った .claude/settings.local.json は、先に gitignore へ入れておく

最初は、シェルの export のまま、Claude Code の前に直接 curl で確かめます。

curl -sS -w '\n%{http_code}\n' -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 1, "messages": [{"role": "user", "content": "."}]}'

{"id":"msg_ で始まる JSON で "content":[...] があれば、到達できて資格情報も有効です。未知のモデル名のエラーでも、認証は通っているので、URL と資格情報は確認できます。401 なら資格情報が拒否されています。キーを x-api-key で受けるゲートウェイでは、Authorization のヘッダーを x-api-key: $ANTHROPIC_API_KEY に替えます。

既存のログインとの関係は次のとおりです。ゲートウェイの資格情報の変数は、保存済みの claude.ai ログインや Console のキーより優先され、変数を外せばログインに戻ります。ANTHROPIC_AUTH_TOKEN は即座に優先され、ANTHROPIC_API_KEY は対話モードで1回承認を求められます。どちらが有効かは /status で見ます。保存済みのログインを消して、ゲートウェイの資格情報だけにするには /logout です。

画面（サーフェス）ごとの設定#

env:
  ANTHROPIC_BASE_URL: https://llm-gateway.example.com
steps:
  - uses: anthropics/claude-code-action@v1
    with:
      anthropic_api_key: ${{ secrets.GATEWAY_API_KEY }}

追加の設定#

{
  "apiKeyHelper": "~/bin/get-gateway-key.sh"
}

ANTHROPIC_BASE_URL がゲートウェイを指していると、Claude Code は自分のテレメトリを、ゲートウェイの資格情報なしで Anthropic へ送ります。資格情報の変数か apiKeyHelper も有効だと、Console の分析ダッシュボードへ使用量のメトリクスを報告しません（v2.1.246 より前は、Anthropic 宛てのテレメトリにゲートウェイの資格情報が付くことがあった。モデルのリクエストは常にゲートウェイ宛て）。

クラウドプロバイダ用のベース URL で通す#

ANTHROPIC_BASE_URL の代わりに、プロバイダ別のベース URL の変数でゲートウェイを指す構成です。担当者が Bedrock・Vertex AI・Foundry・Claude Platform on AWS を名指ししたときだけ使います。Bedrock と Vertex AI のゲートウェイは、そのプロバイダ独自のリクエスト形式を受け、Claude Code も、そのプロバイダが受けるベータヘッダーとリクエストのフィールドの範囲に絞って送ります。Foundry と Claude Platform on AWS のゲートウェイは、Anthropic Messages 形式を受けます。

• Bedrock・Vertex AI・Claude Platform on AWS のブロックにある skip の変数は、クラウドの資格情報で署名しないことを伝える（ゲートウェイが持つため）。ゲートウェイ自身のトークンも要るなら、ブロックのあとに ANTHROPIC_AUTH_TOKEN を足す（Authorization: Bearer で送られる）。別の方式なら ANTHROPIC_CUSTOM_HEADERS を使う。どちらでも skip の変数は残す（無いと、ANTHROPIC_AUTH_TOKEN・apiKeyHelper・ANTHROPIC_CUSTOM_HEADERS が足した Authorization を外す）
• Vertex AI でも、モデルごとのリージョン（VERTEX_REGION_CLAUDE_*）とモデルの固定（ANTHROPIC_DEFAULT_OPUS_MODEL など）は、ゲートウェイ経由でも効く。Claude Code が知らないモデル ID を固定すると、effort や拡張思考などの機能が無効のままになることがある。その場合は ANTHROPIC_DEFAULT_OPUS_MODEL_SUPPORTED_CAPABILITIES（Sonnet と Haiku にも同じ形の変数）で、モデルが持つ機能を宣言する
• 確認は /status の Status タブ。Bedrock なら API provider: Amazon Bedrock・Bedrock base URL・AWS auth skipped の行が出る。ほかのプロバイダも同じ行を、そのプロバイダの名前で出す（Vertex AI は Vertex base URL と GCP auth skipped）。ベース URL の行が無ければ、変数がセッションへ届いていない

ゲートウェイ経由のエラー#

ゲートウェイの設定を外したあとも繰り返しログインを求められるなら、原因は資格情報の保存先であることが多く、ゲートウェイではありません（エラー一覧）。

管理者向け：ゲートウェイを導入する#

導入の順番は、どの製品でも同じです。

1. ゲートウェイを立て、提供元の資格情報を持たせる
2. 開発者ごとにゲートウェイの資格情報を発行する（利用の帰属と、退職時の失効が1つで済む）
3. 設定を managed settings と秘密情報の配布の仕組みで配る。ベース URL と資格情報の両方を配れば、開発者の設定は不要になる
4. 各開発者に、Claude Code で設定が届いているかを確認してもらう

配布の仕組みが無い場合は、開発者に上の接続手順で自分で設定してもらいます（組織の設定の配り方は組織への導入と管理設定）。

前提とゲートウェイの要件#

GET /v1/models を公開すれば、/model を、モデルの検出（上の追加の設定を参照）で埋められます。

導入は5段で、各段に確認があります。確認では、資格情報を次のように呼び分けます。

1. ゲートウェイが、使うモデルを振り分けているか確かめる。次のリクエストを、設定した Claude のモデル名ごとに1回ずつ試す。200 と content があれば提供元まで届いている。404 はその名前が振り分けられていない。提供元から 401 なら、ゲートウェイの提供元の資格情報が間違っている。リダイレクトの後ろに置かない（本文や資格情報のヘッダーが落ちる。モデルの検出もリダイレクトを失敗とみなす）
2. 開発者ごとに資格情報を発行し、同じリクエストで、発行したキーを確かめる。ここで 401 なら、キーが違うか、まだ有効になっていない。Bearer を読むゲートウェイなら開発者は ANTHROPIC_AUTH_TOKEN、x-api-key を読むなら ANTHROPIC_API_KEY を使う
3. 配る前に、自分の端末で、配る設定と同じ構成を、ターミナルに直接入力して試す（ファイルには書かない）。claude -p "Reply with one word: connected" が応答を返し、ゲートウェイのログに /v1/messages への POST が 200 で残れば合格。Claude Code は ?beta=true のようなクエリを付けるので、パスで照合する。Not logged in は、ゲートウェイのログが空なら資格情報がセッションへ届いていない。x-api-key の 401 が出ていれば ANTHROPIC_API_KEY に替える。Failed to authenticate. API Error: 401 は、資格情報は送られて拒否された。api.anthropic.com や提供元を名指しする 401 なら、ゲートウェイの提供元の資格情報が違う。間違った URL は、バックオフで何分も無出力になる。止まって見えたらゲートウェイのログを見て、リクエストが無ければ URL が違う
4. ベース URL と資格情報を配る（下記）
5. 開発者のマシンから、ストリーミングのリクエストを送り、エンドポイント・ストリーミングの通過・モデルの振り分けを一度に確かめる（curl -N で、data: の行が少しずつ届けば正常。一括で届くならバッファしていて、Claude Code が止まる）

curl -N -X POST "https://llm-gateway.example.com/v1/messages" \
  -H "Authorization: Bearer <developer-key>" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 16, "stream": true, "messages": [{"role": "user", "content": "count to 3"}]}'

配る設定#

ほとんどの導入は、ANTHROPIC_BASE_URL と資格情報があれば足ります。必要なら次の行を足します。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm-gateway.example.com"
  },
  "apiKeyHelper": "/usr/local/bin/get-gateway-key"
}

• managed settings の env に入れて、MDM・レジストリポリシー・構成管理で配る。managed の ANTHROPIC_BASE_URL は強制され、開発者のシェルの export では上書きできない
• ゲートウェイの資格情報と一緒に、managed settings に forceLoginMethod・forceLoginOrgUUID・forceLoginGatewayUrl を入れない。forceLoginMethod か forceLoginOrgUUID は、値に関係なく、起動時に ANTHROPIC_API_KEY・ANTHROPIC_AUTH_TOKEN・apiKeyHelper を拒否し、開発者は進めなくなる
• サーバー管理の設定の配布は api.anthropic.com への直接接続が要るので、ゲートウェイ経由のセッションには届かない。ファイルの managed settings の経路を使う（同じキーを強制できる）
• 資格情報は、apiKeyHelper のコマンドを1つ配る（コマンドが、ローカルの開発者として秘密情報の置き場所へ認証するので、マシンごとに自分のキーが届く）。または、既存の仕組みで各開発者にキーを渡し、ANTHROPIC_AUTH_TOKEN を自分で設定してもらう
• 別に配るもの：デスクトップアプリは、サードパーティ推論の設定（managed settings ではなく）を読むので、そのファイルも MDM で配る。CI のランナーは、ランナーの環境に ANTHROPIC_BASE_URL と資格情報が要る。管理された Windows の WSL は、wslInheritsWindowsSettings が true のときだけ Windows の managed settings を読む
• 配布の確認は、開発者のマシンで claude がログイン画面なしで始まり、/status の Anthropic base URL にゲートウェイのアドレスが出て、Setting sources に managed settings が含まれること。ログイン画面や Anthropic base URL の行の欠落は、設定が届いていない

導入後の症状は1つの原因に絞れます。ログインを求められたら資格情報が足りない（/status の Setting sources に managed settings が無ければ配布が届いておらず、あれば開発者の資格情報が届いていない）。Failed to authenticate はゲートウェイのログで、どの資格情報が失敗かを見る（ゲートウェイが自分でログに残す拒否は開発者のキー、api.anthropic.com や提供元からの 401 はゲートウェイの提供元の資格情報）。x-api-key を読むゲートウェイで ANTHROPIC_API_KEY を使うと、初回は1回のキー承認が出る（ANTHROPIC_AUTH_TOKEN では出ず、静かに引き継ぐ）。fast mode を使うなら /fast も試す。最後に、ゲートウェイのログで、資格情報が開発者を表し、x-claude-code-session-id ヘッダーがセッション単位で束ねることを確かめます。

導入後の保守#

クライアントは、一時的な失敗（429 を含む）を、バックオフしながら最大10回再試行し、Retry-After に従います。キーごとのレート制限を決めるときは、これを見込んでください。

バージョンアップで、ゲートウェイの設定が変わらなくても、挙動が変わることがあります。requiredMaximumVersion で試験済みのバージョンに固定するか、自前の配布経路なら DISABLE_UPDATES を使います。固定を上げる前に、変更履歴を読み、ゲートウェイに対して試します。エラーにならない、バージョン依存の変化は次のとおりです。

特定のゲートウェイの管理者は、allowedProviders を managed settings で ["customEndpoint"] にし、同じファイルの env にゲートウェイの ANTHROPIC_BASE_URL を入れると、管理下のマシンが使える行き先を、ANTHROPIC_BASE_URL のゲートウェイだけにできます。Anthropic 直結や開発者自身のプロキシへ向けたセッションは拒否され、ANTHROPIC_BASE_URL はそこで設定した値だけを受け入れます（v2.1.285 以降）。プロバイダ別のエンドポイント変数（ANTHROPIC_BEDROCK_BASE_URL など）で通すゲートウェイでは、allowedProviders の項目が、どの変数を固定するかを示します。

ゲートウェイの互換性（運用者向け）#

API 形式#

ゲートウェイは、次の形式のうち少なくとも1つを公開しなければなりません。

Foundry と Claude Platform on AWS は、Anthropic Messages 形式です。Claude Code は専用の変数（ANTHROPIC_FOUNDRY_BASE_URL・ANTHROPIC_AWS_BASE_URL）で届けますが、手前に置くゲートウェイは、上の Anthropic Messages の行を実装します。Claude Platform on AWS の手前のゲートウェイは、すべてのリクエストで必要な anthropic-workspace-id ヘッダーも転送しなければなりません。

• トークン計数のエンドポイントだけが省略可能。無ければ、コンテキストの使用量を、文字数ベースの推定にする
• 照合はフルの URL ではなくパスで行う。推論は /v1/messages?beta=true へ POST される
• 起動時に、拒否しても問題ない通信が届く。Anthropic Messages 形式のゲートウェイには HEAD /api/hello（接続のウォームアップ。HTTP プロキシかクライアント証明書があるときは省く）。Bedrock 形式には GET /inference-profiles?type=SYSTEM_DEFINED と、設定したモデルが推論プロファイルのときの GET /inference-profiles/{profile}
• fast mode の可用性確認と WebFetch のドメイン安全確認は、ゲートウェイを通らず api.anthropic.com を直接呼ぶ

ストリーミング#

Claude Code は、ストリームで返る推論の応答を、イベントごとに届いた順に読むので、ゲートウェイがストリームをどう中継するかが、ユーザーに見えるものを左右します。

• ゲートウェイが応答を完了するまでバッファすると、Claude Code は止まる
• Claude Code は、各応答の全イベントを、順に、最後の message_delta と message_stop まで受け取る前提で動く。コンテンツブロックが始まったあと、最後の message_delta の前に本文がクリーンに終わると、Claude Code はその応答を切断と同じに扱う（そのときユーザーに見えるものはエラー一覧の「The response above may be incomplete」、リクエストを出し直す条件は同じページの自動の再試行）
• Amazon Bedrock のガードレールが返信をブロックするとき、Bedrock が送るイベントが、すでに content_block_stop が届いたコンテンツブロックを参照することがある。Claude Code は、送られたとおりにそれらを受け取る前提で動く（その返信の終わり方はBedrockの AWS ガードレールの節）
• Claude Code は、ストリーミングの応答に、ストリームの無通信のタイムアウトより長くバイトが届かないと中断する。長い思考の間は、上流の SSE の ping だけがストリーム上のバイトになることがあり、それを外したりバッファしたりするゲートウェイは、応答の途中でそのタイムアウトに引っかかる。ping を持たない上流（Bedrock のバイナリのイベントストリームなど）から変換するゲートウェイも、自前の ping を出さなければ同じ隙間ができる
• Amazon Bedrock の InvokeModel 形式では、Claude Code は /model/{model}/invoke-with-response-stream の応答を、Bedrock が返すバイナリの application/vnd.amazon.eventstream の本文として読む。ゲートウェイが SSE へ変換したり、その Content-Type ヘッダーを書き換えたりすると、解析できない（そのときユーザーに見えるものはBedrockのゲートウェイやプロキシ越しのストリーミングのエラーの節）

形式の不一致#

クライアントが話す形式で、ゲートウェイが受けるものが決まります。よくある失敗は、クライアントがゲートウェイへ送る形式と、背後の提供元が受ける形式の不一致です。クライアントが Bedrock か Vertex AI の形式で話すなら、Claude Code は、それらが受け入れる機能の部分集合だけを送ります。Anthropic Messages 形式で話すなら、上流が Bedrock や Vertex AI でも、全部を送ります。その差を埋めるのはゲートウェイの仕事です。上流が Bedrock か Vertex AI なら、その提供元の形式を公開すれば、橋渡しは要りません。

接続方法による違い#

認識しないモデル ID については、コンテキストウィンドウは200K（ID に [1m] があれば1M）と仮定します。実際の値を宣言する方法は、モデルの設定（モデル）を見ます。モデルの機能を別名へ渡すには、そのモデルの Anthropic ID を別名へ対応づける modelOverrides を、配る設定に入れます。

リクエストヘッダー#

ヘッダー名は大文字小文字を区別しません。anthropic-version と anthropic-beta、上流が Claude Platform on AWS なら anthropic-workspace-id を変えずに転送します。それ以外は、ゲートウェイがルーティング・帰属・トレースのために読んでよく、転送は必須ではありません。

サブエージェントの ID は、起動のたびに新しく作られます。チームメイトのエージェントは、再接続しても名前ベースの安定した ID を使います。どちらもエージェントの ID で、人や端末の ID ではありません。開発者が ANTHROPIC_CUSTOM_HEADERS を設定していれば、それもリクエストに入ります。

ゲートウェイのヒントヘッダー#

ゲートウェイやルーターが、スケジュール・キャッシュ・帰属に使える、リクエストごとの情報です（v2.1.273 以降）。値は固定の語彙・ツール名・時間・ランダムなプロンプト識別子だけで、プロンプトの本文やファイルの内容は入りません。値は印字できる ASCII です。

• Anthropic の API への直接接続：既定で送る
• 独自のベース URL：既定ではオフ（未知のヘッダーを拒否するプロキシで失敗するため）。受け取るには、開発者向けに CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 を設定する（managed settings の env など）
• ほかのバックエンド（Bedrock・Vertex AI・Foundry・Claude Platform on AWS）：CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 のときだけ送る
• CLAUDE_CODE_GATEWAY_HINT_HEADERS=0 で、どの接続でも止まる

x-claude-code-prev-tool-durations を解釈する前に、作り方を確かめます。1つのツール呼び出しにつき1項目（結果が集まった順、ミリ秒の整数）。最大32項目と4KB（先頭から残す）。ツール名はパーセントエンコードされ、%・;・=・カンマ・空白・印字できる ASCII 以外が対象。解析は ; で分け、次に = で分け、名前をデコードする。圧縮の呼び出し・付随のリクエスト・新しいプロンプトの最初のリクエストには付かないので、無いことを「ツールを実行しなかったターン」と読まない。時間は、権限の確認とフックを除き、並列のツール呼び出しはそれぞれが自分の時間を報告するので、合計はリクエストの間隔と一致しない。

開いたリストとして扱う#

ヘッダーと本文のフィールドは、閉じた一覧ではなく開いた一覧として扱います。Claude Code は、リリースごとに、新しい anthropic-beta の値・本文のフィールド・ときに新しい anthropic-* や x-claude-code-* のヘッダーを足します。Anthropic 形式の上流へ転送するなら、anthropic-* のリクエストヘッダーと本文のフィールドを、いま見えているものを許可リストにせず、そのまま通します。例外は、Bedrock や Vertex AI のような Anthropic 以外の上流で、スキーマの差を埋めるのはゲートウェイの仕事です。

レスポンスヘッダー#

ストリームの停止の検出・再試行するかとその待ち時間・使用量の上限の表示に、これらを読みます。エラーの本文も、変えずに転送します。

システムプロンプトの帰属ブロック#

Claude Code は、システムプロンプトの先頭に、クライアントのバージョンと会話から作る指紋を持つ短いブロックを付けます。api.anthropic.com は、最初の system ブロックとして変更なしで届いたとき、処理前にこのブロックを取り除きます。ほかの上流は、プロンプトの一部として受け取ります。この除去は位置で行うので、ゲートウェイが system 配列を変えずに転送したときだけ効きます。

• system 配列を、受け取ったまま、このブロックを先頭にして転送する。別の system ブロックを前に足す・並べ替える・1つの文字列にすると、除去が効かず、ブロックがモデルとプロンプトキャッシュのキーに届く
• ブロックを配列の独立した1項目として保つ。帰属のヘッダーで始まる結合したブロックは、全体が帰属として扱われ、結合された残りのシステムプロンプトも落ちる
• ゲートウェイがシステムの内容を作り直さなければならないなら、CLAUDE_CODE_ATTRIBUTION_HEADER=0 でクライアントがブロックを省く。Anthropic とクラウドの Claude のエンドポイントは、帰属にこのブロックを読むので、ゲートウェイで外したり動かしたりせず、クライアントで省く
• この変数は、ゲートウェイとサードパーティのキャッシュの互換のためで、プライバシーの制御ではない。リクエスト全体は、直接接続でも Anthropic の API に行く
• 次の両方が成り立つとき、0 にしても、auto モードの分類器のリクエストには、ブロックを残す：リクエストが api.anthropic.com へ行く（ANTHROPIC_BASE_URL が未設定か、そのホストを指し、サードパーティのプロバイダが選ばれていない）・有効な資格情報が Anthropic のプロファイルやフェデレーションの資格情報でない。どちらかが成り立たない（LLM ゲートウェイ経由・サードパーティのプロバイダ・プロファイルやフェデレーションの資格情報）なら、0 で分類器のリクエストからも外れる（v2.1.229 より前はこの例外が無く、API が拒否すると、auto モードが分類器へ送る全アクションで失敗した）
• v2.1.181 から、独自のベース URL 経由なら、ブロックは会話のあいだ安定する。ゲートウェイ側の、リクエスト本文全体をキーにするプロンプトキャッシュも、無効にせずに使える。それより前は、リクエストごとのトークンが入って、システムプロンプトの先頭が毎回変わった。その版では、ゲートウェイが本文をキーにするキャッシュを持つとき、またはサードパーティの提供元（Bedrock・Foundry・Vertex AI）へ転送するときに、CLAUDE_CODE_ATTRIBUTION_HEADER=0 にする

機能の通過#

ANTHROPIC_BASE_URL のゲートウェイは、Anthropic 形式のエンドポイントとして扱われ、api.anthropic.com へ送るのと同じベータヘッダーと本文のフィールドを受け取ります（直接接続に限る診断や既定を除く。その集合はリリースで変わるので、内容に依存しない）。本文のフィールドを足す機能は、ベータヘッダーと対で動きます。ヘッダーだけ外して本文を通す、または Anthropic 形式の本文をスキーマの違う上流へ転送すると、400 で失敗します。両方がそろって無いときだけ、機能は黙ってオフになります。内容の検査のために本文を書き換える・伏せるゲートウェイも、同じように対を壊すので、変更せずに検査します。細粒度のツールストリーミングは、直接接続の既定の1つで、独自のベース URL ではオフです。開発者が CLAUDE_CODE_ENABLE_FINE_GRAINED_TOOL_STREAMING=1 にすると、ゲートウェイが受け取ります。

ANTHROPIC_DEFAULT_*_MODEL_SUPPORTED_CAPABILITIES は、プロバイダ構成（CLAUDE_CODE_USE_BEDROCK・CLAUDE_CODE_USE_VERTEX・CLAUDE_CODE_USE_FOUNDRY・CLAUDE_CODE_USE_MANTLE）でだけ、モデルの機能を宣言できます。ANTHROPIC_BASE_URL のゲートウェイの背後では効きません。

上流が拒否したときの自動の再試行#

bound to a different conversation は、API の保存された思考の確認が、system・tools・前の messages の内容が思考を作ったリクエストと違うと失敗するために出ます。それらを書き換えるゲートウェイが、この拒否を起こすことがあります。再試行の判断は上流のエラーの文言に一致して動くので、エラーの本文は変えずに転送します。独自の封筒で包むと、ステータスコードを保っても、復旧が壊れます。封筒のメッセージに、安定した capability_rejected: のトークンを入れれば別です（Claude apps gateway が、クラウドの文言の代わりに入れる。例 capability_rejected: prompt_too_long）。

プレリリースの機能を止める#

ゲートウェイか上流が、プレリリースの anthropic-beta の値や、それと対の本文のフィールドを拒否し、両方を転送できないときは、開発者に CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定させます。設定すると、Claude Code は、プレリリースの機能と、それと対の anthropic-beta の値を送らなくなります。外れるものは次のとおりです。

• コンテキスト管理と、その context_management の本文のフィールド
• strict・defer_loading などのベータのツールスキーマのフィールド（標準の name・description・input_schema・cache_control のツールのフィールドは残る）
• 構造化出力の output_config.format フィールド（v2.1.287 以降）
• output_config.task_budget フィールド
• MCP のツール検索。組織が管理設定でオンのままにしていなければ、すべての MCP ツールが最初に読み込まれる

この変数は、すべての anthropic-beta の値を外すわけではありません。残るものは次のとおりです。

• 拡張コンテキスト・インターリーブ思考・effort の anthropic-beta の値（クラウドプロバイダーも受け付ける）

• output_config.effort フィールド（上流が拒否したときは、上の自動の再試行の節）

• ベータヘッダーを持たない、適応的な推論の thinking フィールド

• サブスクリプションの認証が要る OAuth の anthropic-beta の値

• 開発者が ANTHROPIC_BETAS や CLAUDE_CODE_EXTRA_BODY で自分で足したヘッダーの値と本文のフィールド

• 組み込む側のホストのプラットフォームが CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST を設定したとき、この変数は、Bedrock・Vertex AI・Foundry・Claude apps gateway での auto モードのセッションが、サーバーに分類器のレビューを求めるのを止めない。そのレビューは、anthropic-beta の値と safeguards のリクエストのフィールドを足す。止めるには CLAUDE_CODE_AUTO_MODE_SERVER=0

• v2.1.227 以降では、managed settings で、この変数の下でも、MCP のツール検索を有効のままにできる。直接接続か ANTHROPIC_BASE_URL のゲートウェイでは、ツール検索のベータヘッダー・defer_loading のツールのフィールド・tool_reference のブロックを送り続け、残りを外す。クラウドプロバイダや Claude apps gateway のサインインでは、この上書きは効かない

モデルの検出#

ANTHROPIC_BASE_URL が Anthropic Messages 形式のゲートウェイを指すとき、起動時にゲートウェイの /v1/models を呼び、返ったモデルを /model に足せます。CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1 で有効にします（開発者の環境か managed settings）。既定でオフなのは、共有の API キーで動くゲートウェイが、キーで見えるモデルをすべてのユーザーに出さないようにするためです。

• 動かない場面：CLAUDE_CODE_USE_* のプロバイダ変数が設定されている（ANTHROPIC_BASE_URL も設定されていても）・ANTHROPIC_BASE_URL が未設定か api.anthropic.com を指す。省略可の通信を止めていても動く（v2.1.257 より前は動かなかった）
• リクエストは GET /v1/models?limit=1000。既定のタイムアウトは3秒（CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS で延ばせる。v2.1.269 以降）。リダイレクトは、資格情報が漏れないよう失敗として扱う（http から https でも）。遅いゲートウェイやリダイレクトは、黙って失敗する。設定したベース URL で直接提供する
• 資格情報は両方のヘッダーで送り、値が決まらないヘッダーは省く（v2.1.248 以降。それより前は ANTHROPIC_AUTH_TOKEN があれば Authorization だけ、なければ x-api-key だけ）。Authorization は ANTHROPIC_AUTH_TOKEN、なければ apiKeyHelper の値を bearer として。x-api-key は解決した API キー（ANTHROPIC_API_KEY など）。ヘルパーの値だけのときは両方に入る。ANTHROPIC_CUSTOM_HEADERS のヘッダーも送り、値が空でない同名のヘッダーは、組み込みのヘッダーに代わる。どちらの資格情報も決まらなければ、検出を省き、claude --debug のデバッグログに [gatewayDiscovery] skipped を書く。ANTHROPIC_CUSTOM_HEADERS だけで資格情報を渡しても省かれる
• 応答は、data 配列の各項目から、id・省略可の display_name・省略可の description を読む

{
  "data": [
    {
      "id": "claude-sonnet-4-6",
      "display_name": "Claude Sonnet 4.6",
      "description": "Default model for everyday coding tasks"
    },
    { "id": "claude-opus-4-8" }
  ]
}

• id に claude か anthropic が（大文字小文字を区別せず）含まれる項目だけを残す。vertex_ai/claude-sonnet-4-6 や bedrock/anthropic.claude-sonnet-4-5 のように、提供元の接頭辞が付いた ID も通る（v2.1.223 より前は、claude か anthropic で始まる ID だけ）
• ピッカーの項目名は、display_name（id と違うとき）。無ければ、Claude Code が id を認識するならモデル名、しないなら id。たとえば my-gateway-claude-sonnet-4-6 で display_name なしなら Sonnet 4.6。説明は1行に縮め、無ければ「From gateway」（v2.1.257 より前は常に「From gateway」）
• 検出が足すのは、availableModels の managed 設定が許可するモデルだけ
• すでにある行と一致する ID は、独自の行にならない。同じ ID（または同じ Fable バージョンの別の綴り）。内蔵のエイリアスがいま解決するモデルと同じ明示の ID は、エイリアスの行だけが出る（例：sonnet が claude-sonnet-5-5 に解決される間、見つかった claude-sonnet-5-5 は sonnet の行にまとまり、claude-sonnet-5 は独自の行になる）
• 結果は ~/.claude/cache/gateway-models.json（Windows は %USERPROFILE%\.claude\cache\gateway-models.json。CLAUDE_CONFIG_DIR があればその下）にキャッシュされ、起動のたびに更新される。リクエストが失敗するか /v1/models が無ければ、前回の起動のキャッシュか内蔵の一覧に戻る。検出のフィルタに合わない別名で Claude のモデルを出すなら、開発者がモデルの環境変数で手動で足す