本文へスキップ

Claude CodeのANTHROPIC_BASE_URLが効かない:症状別の原因と直し方

ログイン要求、401、400、VS Codeだけ効かないなど、症状ごとに直す場所は違います。2.1.299で直った不具合と、stable版が2.1.292のままである点も確認できます。

••37 分で読めます•Claude Code
Claude Codeの/status画面でAnthropic base URLの行は出ているがLogin methodがclaude.aiのままで、ANTHROPIC_AUTH_TOKENが足りないことを示す図

ANTHROPIC_BASE_URLはリクエストの送り先を変える変数で、認証情報までは変えません。設定したのに効かないときの原因の多くは、変数がClaude Codeのプロセスに届いていない、認証情報を入れた変数(つまり送られるヘッダー)が違う、URLの形が違う、ゲートウェイがClaude Codeの送る内容を拒否している、の4つのどれかです。残りは特定バージョンの不具合と、もともと対応していない使い方です。

最初にClaude Codeの中で/statusを開き、Statusタブの2行を見てください。

  • Anthropic base URLの行がない:変数がセッションに届いていません。起動方法と設定場所を確認します。
  • その行はあるが、Login methodとしてclaude.aiのアカウントが表示される:認証情報の変数(ANTHROPIC_AUTH_TOKENなど)が届いていません。リクエストはゲートウェイへ向かっても、保存済みのclaude.aiログインが使われ、サブスクの上限と課金が適用されます。
  • 2行とも正しいのにメッセージが失敗する:エラー文で原因を絞ります。401は変数とヘッダーの取り違え、400はゲートウェイによるフィールドの拒否、接続エラーやHTMLの応答はURLかネットワーク経路の問題です。

バージョンも確認してください。2026年10月14日公開の2.1.299で、カスタムベースURLに関わる不具合が4件修正されました。一方、2026年10月15日時点でnpmのstableは2.1.292のままです。また、DeepSeekやローカルモデルなどClaude以外のモデルにつないでいる場合、AnthropicはどのゲートウェイについてもClaude以外のモデルへの接続をサポートしていません。設定を直しても動かない機能があることを前提に読み進めてください。

ANTHROPIC_BASE_URLが効かない症状と原因の早見表

見えている症状から、原因と最初に触る場所を選べます。エラー文は公式のゲートウェイ接続ガイドに載っている表記のままです。

見えている症状主な原因最初の対処
/statusにAnthropic base URLの行がない変数がこのプロセスに届いていない起動方法と設定ファイルを確認する
curlは通るのにclaude.aiへのログインを求められる認証情報の変数がない、またはプロジェクトの.claude/settings.jsonにだけ書いたANTHROPIC_AUTH_TOKENをシェルか~/.claude/settings.jsonに入れる
ゲートウェイ経由のはずなのにサブスクの上限が減るANTHROPIC_BASE_URLだけを設定し、保存済みログインが使われている認証情報の変数を設定し、/logoutする
ANTHROPIC_API_KEYを設定したのに何も聞かれず無視される初回の承認で一度拒否した/configのUse custom API keyで有効にする
401(トークンが無効・認識できない)変数とヘッダーの組み合わせ違い、またはキーの失効もう一方の変数に移して再確認する
ConnectionRefused、ENOTFOUNDアドレスの誤り、VPNやファイアウォールcurlで同じ経路を試す
API returned an empty or malformed response (HTTP 200)ゲートウェイや途中のプロキシがHTMLのエラーページなどを返したURLのパスとゲートウェイのルートを確認する
HTML本文の403で、ゲートウェイのログに記録がないゲートウェイ手前のWAFがリクエスト本文を遮断/v1/messagesを本文検査の対象から外す
400でExtra inputs are not permittedやcontext_management上流が未対応のフィールドを拒否CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1
400でコンテキスト上限(ゲートウェイ独自の文言)自動圧縮が働かない/compactとCLAUDE_CODE_AUTO_COMPACT_WINDOW
長い応答の途中で切れる無通信タイムアウト2.1.299以降へ更新、API_FORCE_IDLE_TIMEOUT
ターミナルでは動くがVS Codeやデスクトップ版で効かない画面ごとに設定場所が違うclaudeCode.environmentVariables、デスクトップ版は専用の設定
/modelにゲートウェイのモデルが出ないモデル名が組み込みの一覧にないCLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
MCPツール検索、Remote Control、音声入力が使えないAnthropic以外のホストでは仕様でオフ不具合ではないため、設定では戻らない

/statusの2行とcurl1回で設定側かゲートウェイ側かを分ける

原因を絞る前に、問題がClaude Code側の設定にあるのか、ゲートウェイ側にあるのかを分けます。使うのは/statusとcurlの2つだけです。

/statusのStatusタブでは、次の行を見ます。

  • Anthropic base URL:ゲートウェイのアドレスが設定されているときだけ表示されます。行がなければ、変数がセッションに届いていません。
  • Auth tokenまたはAPI key:ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、apiKeyHelperのどれかが表示されれば、ゲートウェイ用の認証情報が有効です。代わりにLogin methodとしてclaude.aiのアカウントが出る場合は、認証情報が届いていません。

次に、Claude Codeを通さずにゲートウェイへ1トークンだけのリクエストを送ります。下のコマンドはシェルの変数を読むため、settings.jsonに値を書いている場合でも、同じ値をそのシェルでexportしてから実行してください。

bash
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": "."}]}'

Windowsでは公式ドキュメントにあるPowerShell版を使います。

powershell
Invoke-RestMethod -Method Post -Uri "$env:ANTHROPIC_BASE_URL/v1/messages" `
  -Headers @{ "Authorization" = "Bearer $env:ANTHROPIC_AUTH_TOKEN"; "anthropic-version" = "2023-06-01" } `
  -ContentType "application/json" `
  -Body '{"model": "claude-sonnet-4-6", "max_tokens": 1, "messages": [{"role": "user", "content": "."}]}'

ゲートウェイがx-api-keyヘッダーでキーを受け取る場合は、Authorizationの行をx-api-key: $ANTHROPIC_API_KEYに置き換えます。結果の読み方は次のとおりです(公式の確認手順より)。

curlの結果意味次に見る場所
{"id":"msg_で始まるJSONURLも認証情報も正しいClaude Code側の設定(変数の届き方、送るフィールド)
未知のモデル名を指摘するエラーURLと認証情報は通っている。モデル名が拒否されただけ認証テストとしては成功。モデル名は後で合わせる
401認証情報が拒否された変数(ヘッダー)を入れ替える
HTML、404送り先のパスが違う、またはゲートウェイ以外が応答しているベースURLの形
すぐに接続失敗アドレスかネットワーク経路の問題URL、VPN、ファイアウォール

curlが成功するのにClaude Codeで失敗するなら、原因はClaude Code側にあります。curlの時点で失敗するなら、Claude Codeの設定を触る前にURLとキー、ネットワークを直してください。例のモデルIDはclaude-sonnet-4-6ですが、認証の確認だけならゲートウェイが提供していないモデル名でも判断できます。

/statusのAnthropic base URL行、認証情報の行、curlの結果(401、HTML・404、接続失敗、msg_で始まるJSON)の順に原因を絞る判定フロー

claude.aiへのログインを求められる・サブスクのまま使われる

ログインを求められる、あるいはゲートウェイに向けたはずなのにサブスクの上限が減っていくときは、ゲートウェイ用の認証情報がClaude Codeに渡っていません。公式の説明では、ANTHROPIC_BASE_URLだけを設定してもサブスクは置き換わりません。リクエストはゲートウェイを通りますが、保存済みのclaude.aiログインが使われ続け、その上限と課金が適用されます。サブスクの上限を避けるためにゲートウェイへ切り替えた場合は、この状態だと目的を果たせません(上限の仕組みは「Claude Codeのレート制限ガイド:5時間・週次上限と429の見分け方」で確認できます)。

原因と対処は次のとおりです。

  • 認証情報の変数がない:ゲートウェイから発行されたキーをANTHROPIC_AUTH_TOKEN(またはANTHROPIC_API_KEY)に入れます。認証情報の変数は保存済みのclaude.aiログインより優先されます。
  • curlは通るのにログイン画面が出る:Claude Code自体は認証情報を持っていません。到達できるベースURLは認証情報の代わりにならず、さらに対話セッションでは、プロジェクトの.claude/settings.jsonや.claude/settings.local.jsonのenvは初回ウィザードとフォルダーの信頼確認が済んでから適用されます。ANTHROPIC_AUTH_TOKENは、シェルのexport、~/.claude/settings.jsonのenv、または管理設定のように、初回セットアップより前に読まれる場所に置いてください。
  • ANTHROPIC_API_KEYが黙って無視される:この変数は対話モードで一度だけ承認を求められ、過去に拒否したキーは確認なしで無視されます。/configのUse custom API keyで有効にします。ANTHROPIC_AUTH_TOKENには、この承認はありません。
  • 起動時に2つの認証情報の名前とauth may not work as expectedで終わる警告が出る(古いバージョンではAuth conflict: Both a token (SOURCE) and an API key (SOURCE) are set):ゲートウェイ用の認証情報と保存済みログインが両方有効です。ゲートウェイを使うなら/logoutで保存済みログインを消し、claude.aiを使うなら変数を外します。OpenRouterのドキュメントは、この競合が分かりにくいモデル未検出エラーとして現れることがあると説明しています。
  • This machine's managed settings require a first-party loginと表示される:管理設定にforceLoginMethodやforceLoginOrgUUIDが入っており、ゲートウェイ用の認証情報と併用できません。管理者に設定の変更を依頼するしかありません。

認証情報はコミットされるプロジェクトの.claude/settings.jsonに書かないでください。リポジトリを複製した全員に共有されます。

変数が届かない:settings.json・VS Code・デスクトップ版

/statusにAnthropic base URLの行がないときは、Claude Codeを起動した経路に変数が渡っていません。どこに書いた値がどの画面に届くかは、次のように決まっています。

settings.jsonのenvはシェルのexportより優先される

同じ変数をシェルのexportと設定ファイルのenvの両方で指定すると、設定ファイルの値が使われます(公式ドキュメントの規則で、Ollamaのドキュメントにも同じ注意があります)。シェルで新しいURLをexportしても、~/.claude/settings.jsonや.claude/settings.local.jsonに古い値が残っていれば、そちらが勝ちます。値を変えても反映されないときは、まず設定ファイルのenvを確認してください。/statusには、実際に使われているベースURLと認証情報の出どころが表示されます。

なお、モデルの指定については、環境変数ANTHROPIC_MODELが設定項目modelより先に読まれます。

シェルのexportは、そのターミナルから起動したものにしか届かない

exportした値は、そのターミナルと、そこから起動したプログラムにだけ適用されます。DockやスタートメニューからエディターやClaude Codeを起動すると、値は見えません。新しいターミナルでも使うなら~/.zshrcや~/.bashrc、PowerShellの$PROFILEに書きます。バックグラウンドエージェントにはシェルだけの設定が確実には届かないため、常にゲートウェイを通したい場合は設定ファイルのenvを使います。

ほかに、届かない原因になりやすい書き方が2つあります。

  • プロジェクトの.envファイル:ネイティブインストーラー版のClaude Codeは標準の.envファイルを読みません(OpenRouterのドキュメントによる)。
  • ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"のような展開:シェルプロファイルを読み込んだ時点で展開されるため、OPENROUTER_API_KEYがそれより後、別ファイル、またはシークレット管理ツールで後から定義されると空文字になり、すべてのリクエストが認証エラーになります。

VS Code拡張機能はclaudeCode.environmentVariablesに書く

VS Code拡張機能は、起動前にVS Codeのユーザー設定にあるclaudeCode.environmentVariablesから認証情報を確認します。~/.claude/settings.jsonの値は起動されたプロセスには届きますが、拡張機能自身のログイン確認には使われません。コマンドパレットの「Preferences: Open User Settings (JSON)」で開き、次のように書きます。

json
{
  "claudeCode.environmentVariables": [
    { "name": "ANTHROPIC_BASE_URL", "value": "https://llm-gateway.example.com" },
    { "name": "ANTHROPIC_AUTH_TOKEN", "value": "sk-gateway-key" }
  ]
}

デスクトップ版はANTHROPIC_BASE_URLを読まない

Claudeのデスクトップアプリは、ANTHROPIC_BASE_URLもsettings.jsonも読みません。ゲートウェイの経路は、管理者が配布するサードパーティ推論の設定か、アプリ内のフォームで決まります。自分で設定する場合は、Help → Troubleshooting → Enable Developer Modeで再起動し、Developer → Configure Third-Party InferenceにゲートウェイのベースURLを入力します。管理者が配布した設定がある場合はそちらが優先され、フォームは読み取り専用になります。Gateway was unreachableと表示されたら、起動時に設定済みのベースURLへ到達できなかったという意味なので、前述のcurlで経路を確かめます。

GitHub ActionsとAgent SDK

GitHub Actionsのclaude-code-actionは、ワークフローのenvからANTHROPIC_BASE_URLとANTHROPIC_CUSTOM_HEADERSを読みます。ゲートウェイのキーはanthropic_api_key入力で渡し、これはx-api-keyとして送られます。Bearerトークンを読むゲートウェイでは、同じキーをenvのANTHROPIC_AUTH_TOKENにも入れてください。Agent SDKのTypeScript版はoptions.envを指定すると環境変数が丸ごと置き換わるため、...process.envを展開して既存の変数を残します。Python版は継承した環境変数に上書きで追加されます。

401が返る:ANTHROPIC_AUTH_TOKENとANTHROPIC_API_KEYの取り違え

401は、認証情報がゲートウェイの読まないヘッダーで届いているか、キーそのものが無効なときに返ります。2つの変数は送られるヘッダーが違います。

変数送られるヘッダー使う場面
ANTHROPIC_AUTH_TOKENAuthorization: Bearer「Bearerトークン」「Authorizationヘッダー」と案内されたとき。分からない場合もこちら
ANTHROPIC_API_KEYx-api-key「APIキー」「x-api-key」と案内されたとき
apiKeyHelper両方キーが定期的に変わる、保管庫から取り出す

curlで401が出たら、もう一方の変数に移して試します。それでも401ならキーの失効を疑い、ゲートウェイ側で再発行します。

よく使われる接続先は、提供元のドキュメントで次の値になっています。手順ではなく、自分の設定と照らし合わせるための値です。

接続先ANTHROPIC_BASE_URL認証情報ANTHROPIC_API_KEY
OpenRouterhttps://openrouter.ai/apiANTHROPIC_AUTH_TOKENにOpenRouterのキー""(明示的に空にする)
Ollama(ローカル)http://localhost:11434ANTHROPIC_AUTH_TOKEN=ollama""
Ollama(クラウド)https://ollama.comANTHROPIC_AUTH_TOKENにOLLAMA_API_KEY―

ANTHROPIC_API_KEYを空にするのは、シェルに本物のAnthropic APIキーが残っていると、それがx-api-keyとして送られ、ゲートウェイではなくAnthropic側で認証されてしまう場合があるためです(OpenRouterのドキュメントによる)。プロファイルに残ったこのキーは/logoutでは消えません。プロファイルを直してシェルを読み込み直してください。

接続エラー・HTML・403:ベースURLの形とネットワーク経路

ベースURLは末尾に/v1を付けない

Claude CodeはANTHROPIC_BASE_URLの後ろに/v1/messagesを付けて送ります。公式の確認コマンドも$ANTHROPIC_BASE_URL/v1/messages宛てです。そのため、値にはゲートウェイのルートだけを書きます。OpenRouterはhttps://openrouter.ai/api、Ollamaはhttp://localhost:11434で、どちらも/v1を 含みません。

ドキュメントに明記はありませんが、パスの組み立て方から考えると、https://openrouter.ai/api/v1のように/v1まで書くと/v1/v1/messagesへ送られることになります。そのときに返るのが404か、HTMLのページか、別のエラーかはゲートウェイ次 第です。

ConnectionRefused・ENOTFOUND・HTTP 200の不正な応答

  • Connection refused — a firewall or proxy may be blocking it (ConnectionRefused):そのアドレスで何も応答していません。URLの誤りか、VPNやファイアウォールが経路を塞いでいます。
  • Can't reach the API server — check your internet or DNS (ENOTFOUND):ホスト名が名前解決できません。
  • どちらもClaude Codeが自動で再試行するため、表示までしばらく無反応に見えることがあります。curlなら同じ原因ですぐに失敗するので、そちらで確かめます。
  • API returned an empty or malformed response (HTTP 200):ゲートウェイや途中のプロキシが、Claude APIの応答ではないもの(HTMLのエラーページやログインページなど)を返しています。curlで中身を見て、該当するルートを直します。

403とHTML本文、またはTLSエラー

403 ForbiddenのようなHTML本文が返り、しかもゲートウェイのログに何も残っていない場合は、ゲートウェイの手前にあるWAFやリバースプロキシがリクエスト本文を遮断しています。Claude Codeのプロンプトにはソースコードや<tag>形式の文字列が含まれ、クロスサイトスクリプティング対策の本文ルールに引っかかるためです。短いcurlは通り、実際のセッションだけが失敗するのはこのためです。/v1/messagesのパスを本文検査の対象から外します。AWS WAFではCrossSiteScripting_Bodyのマネージドルールが該当します。

curlは通るのにSSL certificate verification failedやSelf-signed certificate detectedが出るなら、社内のTLS検査プロキシの証明書をClaude Codeの実行環境が信頼していません。NODE_EXTRA_CA_CERTSにCA証明書のパスを設定します。

ゲートウェイ以外への通信を止めたいネットワーク

外部への通信がゲートウェイだけに制限されたネットワークでは、バージョン確認やテレメトリーなど、ゲートウェイを通らない通信が失敗します。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1で止められますが、この設定は自動更新も止めます。後述の2.1.299のような修正を受け取るには、手動で更新する必要があります。

ゲートウェイ経由でも529や500が表示される場合は、「Claude 529 overloaded_errorとは?原因と対処法を表示別に整理」と「Claude API 500 エラー:闇雲にリトライする前に request_id を残す」で、エラーの意味と記録しておくべき情報を確認できます。

400で止まる:ゲートウェイが拒否するフィールドと回避変数

curlの1トークンは通るのに、実際のセッションで400が返る場合は、Claude Codeが送るフィールドやベータ機能を、ゲートウェイかその先の上流が受け付けていません。エラー文に含まれる語で変数を選びます。

400のエラー文原因回避方法
context_management、Extra inputs are not permitted、その他の認識できないフィールド上流がAnthropic形式のリクエストの一部を拒否CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1。この変数で止まらないベータは、対応するCLAUDE_CODE_USE_*の変数を設定する
thinking、adaptive(例:Input tag 'adaptive' found)上流のモデルがadaptive thinkingを受け付けないゲートウェイの上流を更新する。Opus 4.6とSonnet 4.6ならCLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1でも回避できる
構造化出力の拒否(セッションタイトル、メモリーの呼び出し、プロンプトフックが失敗する)上流がoutput_config.formatを受け付けない2.1.288以降でCLAUDE_CODE_DISABLE_STRUCTURED_OUTPUTS=1。ほかのベータ機能は残る
ContextWindowExceededError、prompt token count of N exceeds the limit of Mなど、ゲートウェイ独自のコンテキスト上限Claude Codeが「長すぎる」エラーと認識できず、自動圧縮と再送が働かない/compactで復旧し、予防にはCLAUDE_CODE_AUTO_COMPACT_WINDOWをゲートウェイの上限に合わせる

CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1はプレリリースのヘッダーとフィールドの大半を取り除くため、MCPツール検索など、それに依存する機能も止まります。構造化出力だけが問題なら、範囲の狭いCLAUDE_CODE_DISABLE_STRUCTURED_OUTPUTSを先に試してください。

コンテキスト上限の設定には注意点があります。

  • CLAUDE_CODE_AUTO_COMPACT_WINDOWは200000のような整数で書きます。200kと書くと200として読まれ、下限の100,000に切り上げられます。
  • 値は100,000から、そのモデル本来のコンテキストウィンドウまでの範囲に収められます。ゲートウェイの上限が100,000未満なら合わせられないため、/compactで都度復旧するしかありません。
  • 出力側も、CLAUDE_CODE_MAX_OUTPUT_TOKENSをゲートウェイのモデルの出力上限より小さくします。
  • 2.1.285以降、カスタムベースURL経由のセッションでも、1Mコンテキストを持つモデル(Opus 4.7以降、Sonnet 5以降、Fable)では1Mのウィンドウが使われます。ゲートウェイが200Kで止まるなら、セッション内で/autocompact 200kを実行します。

GitHubで報告されている未解決の400

Anthropicが確認したものではありませんが、厳格なゲートウェイで起きる400について、2026年10月15日時点で未解決の報告が2件あります。

  • #95087:カスタムベースURLでは、セッション最初のリクエストにtool_additionブロック(ベータmid-conversation-tool-changes)が含まれ、厳格なエンドポイントが400で拒否します。Claude Codeはそれを外して黙って再送するため、通常は表に出ません。ただし2026年10月13日のコメントでは、2.1.296で再送が働かず、会話が使えなくなったゲートウェイが報告されています。
  • #101897(2026年10月13日):2.1.269から2.1.296に更新した後、セルフホストのモデルでOpenAI形式のmaximum context lengthという400が出続け、圧縮でも防げず復旧もしないという報告です。報告者は2.1.269に戻して回避しました。

どちらも2.1.299で直るかどうかは公表されていません。コンテキスト上限の400には、上の表の/compactとCLAUDE_CODE_AUTO_COMPACT_WINDOWが公式の対処です。

2.1.299で直ったゲートウェイ関連の不具合とstable版の遅れ

2.1.299は日本時間2026年10月14日9時23分にnpmで公開され、同じ日の23時27分に2.1.300が続きました。CHANGELOGの2.1.299には、カスタムベースURLに関わる修正が4件あります。

修正内容関係する人
機能フラグ、起動時、fast mode、プロフィール、フィードバックのAnthropic宛てリクエストに、ANTHROPIC_BASE_URL用に設定した外部ゲートウェイのAPIキーが付いていた(AnthropicのAPIキーは引き続き送られる)ゲートウェイのキーを使っている全員
管理設定ファイルでANTHROPIC_BASE_URLを指定している場合に、サーバー管理設定のリクエストにもゲートウェイのキーが付いていた管理者が設定を配布している組織
カスタムベースURL経由のストリームが、無通信のまま180秒で打ち切られていた。300秒待つように変更応答が遅いゲートウェイ、ローカルモデル
ゲートウェイ固有のモデル名を使うセッションが、200Kトークン付近でPrompt is too long · automatic compaction failedで止まっていたClaude Codeが認識しないモデル名を使う人

1件目について、修正前に画面上でどんな症状が出ていたかはCHANGELOGに書かれていません。分かっているのは、修正前はAnthropic宛ての一部のリクエストにゲートウェイのキーが付いていたという事実です。

2026年10月15日時点でstableは2.1.292、latestは2.1.300で、ゲートウェイ関連の4件の修正を含む2.1.299がstableにまだ届いていないことを示すバージョンの図

自分の環境に修正が入っているか確かめて更新する

claude --versionでバージョンを確認し、2.1.299より前なら更新を検討します。

  • ネイティブインストール:claude update。ただし設定中のリリースチャンネルに従います。
  • npm:npm install -g @anthropic-ai/claude-code@latest
  • Homebrew:claude-codeはstable、claude-code@latestはlatestを追います。Homebrew、WinGet、aptは自動更新しません。
  • 特定のバージョンを入れる:curl -fsSL https://claude.ai/install.sh | bash -s 2.1.299

リリースチャンネルの既定はlatestで、stableは通常1週間ほど前の、大きな不具合のあったリリースを除いたバージョンです。2026年10月15日時点でnpmのstableは2.1.292、latestは2.1.300です。ここから推測すると、stableを使っている人は、stableが2.1.299以上に進むか、latestへの切り替えや版の指定をするまで、上の4件の修正を受け取れません。stableがいつ進むかは公表されていません。チャンネルは/configの「Auto-update channel」で変えられます。リリースノートの読み方と更新の判断は「Claude Codeのリリースノートの読み方と更新判断」で確認できます。

長い応答が途中で切れる:180秒・300秒と5分のタイムアウト

ローカルモデルや遅いゲートウェイで、応答の途中で接続が切れる場合は、無通信のタイムアウトが関係します。

  • 2.1.299より前は、カスタムベースURL経由のストリームがデータの届かない状態で180秒続くと打ち切られていました。2.1.299で300秒に延びています。
  • 環境変数API_FORCE_IDLE_TIMEOUTは、ストリーミング中にバイトが届かないと応答を打ち切る5分間のアイドルタイムアウトを上書きします。Anthropic APIに直接つなぐ場合以外では既定で有効です。チャンクの間が5分以上空くモデルでは0にすると無効になります。
  • リクエスト全体のタイムアウトはAPI_TIMEOUT_MSで、既定は600000(10分)です。

300秒の制限とAPI_FORCE_IDLE_TIMEOUTがどう関係するかは、環境変数のリファレンスにもCHANGELOGにも書かれていません。300秒より長く無通信になるゲートウェイでは、2.1.299以降でも打ち切られる可能性があります。

設定を直しても動かないもの:Claude以外のモデルと一部機能

ここまでの確認で設定に誤りがないのに動かないものは、仕様上の制限であることが多く、設定の調整では解決しません。

  • Claude以外のモデル:Anthropicはサードパーティのゲートウェイを保証・保守・監査しておらず、どのゲートウェイについてもClaude CodeをClaude以外のモデルにつなぐ使い方をサポートしていません。OpenRouterも、Claude Codeの動作を保証しているのはAnthropic自身のプロバイダー経由だけです。Ollamaでは、ホスト型のWebSearchや高度なツール制御が完全にはサポートされておらず、ツール呼び出しに対応したモデルを選ぶ必要があります。大きめのリポジトリでは64k以上のコンテキストを設定するよう案内されています。
  • MCPツール検索:Anthropic以外のホストを指定すると既定でオフになり、MCPツールは最初からすべて読み込まれます。ゲートウェイがtool_referenceブロックを転送できる場合に限り、ENABLE_TOOL_SEARCH=trueで有効にできます。
  • Remote Control:2.1.196以降、ANTHROPIC_BASE_URLがapi.anthropic.com以外を指していると無効です。ゲートウェイ用の認証情報が有効な間は、Remote Controlと音声入力のどちらも使えません。
  • fast mode:利用可否の確認はANTHROPIC_BASE_URLに従わず、api.anthropic.comへ直接送られます。直接の通信が塞がれていると/fastが使えない旨を表示します。
  • /modelの一覧:ゲートウェイのモデル名はClaude Codeの組み込み一覧にないため表示されません。CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1を設定すると、起動時にゲートウェイから一覧を取得して追加します。特定のモデルが出ない原因の切り分けは「Claude CodeでFable 5.1が出ない・使えない原因」も参考になります。

Claude以外のモデルで、必要な機能がこれらの制限に当たっている場合は、設定をいじり続けても結果は変わりません。その機能をあきらめるか、Claudeのモデルを提供する経路に戻すかを決める段階です。

ANTHROPIC_BASE_URLについてのよくある質問

ANTHROPIC_BASE_URLの末尾に/v1は付けますか?

付けません。Claude Codeが/v1/messagesを自動で付け足すため、ゲートウェイのルートだけを書きます。OpenRouterならhttps://openrouter.ai/apiです。

settings.jsonとexportでは、どちらの値が使われますか?

同じ変数が両方にある場合は、settings.jsonのenvの値が使われます。シェルで値を変えても反映されないときは、~/.claude/settings.jsonとプロジェクトの.claude/settings.local.jsonに古い値が残っていないか確認してください。

ゲートウェイをやめてclaude.aiのログインに戻すには?

シェルのプロファイルと設定ファイルのenvから、ANTHROPIC_BASE_URLと認証情報の変数(ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、apiKeyHelper)を外します。claude.aiのログインは変数を設定している間も保存されたまま使われていないだけなので、変数を外せば元に戻ります。/logout済みの場合は再ログインが必要です。ログインで500や403が出る場合は「Claude Codeにログインできないときの対処法:500・403・Invalid code」を参照してください。

更新したら直りますか?

2.1.299で修正された内容(Anthropic宛てリクエストへのゲートウェイのキーの付与、180秒での打ち切り、200K付近の圧縮失敗)に当てはまる症状なら、2.1.299以降で直ります。変数の届き方、ヘッダーの取り違え、URLの形、ゲートウェイ側の拒否は設定の問題なので、更新では直りません。stableチャンネルでは、2026年10月15日時点でまだ2.1.299に届いていません。

内容の誤りや、記事で扱っていない問題に気づいたら、記事の URL と状況を hi@laozhang.ai までお送りください。確認のうえ記事を更新します。