Claude Codeが以前のプロバイダーを使い続ける場合のルート確認方法
Base URLを変更してもClaude Codeの動作が変わらないときに、対象クライアントと有効な設定元を特定し、テストリクエストをプロバイダーの記録と照合する方法です。
目次

ANTHROPIC_BASE_URLを変更したのに、Claude Codeが以前のサービスへ接続しているように見えることがあります。キーの交換やクライアントの再インストールを始める前に、どのプロセスをテストしているか、そのリクエストがプロバイダー側にどんな記録を残したかを確認してください。正しい回答が返ったこと、画面に表示されたモデル名、あるターミナル内の変数だけでは、接続先は確定できません。
この記事は設定がすでに作成済みであることを前提にしています。初回設定や現在の値はClaude Code設定ガイドで確認してください。ここでの目的は、競合する設定元を見つけ、特定のクライアントが使ったルートを検証することです。
再現できる症状から始める
| 観察した症状 | 最初に比較するもの | 切り分けられること |
|---|---|---|
| ターミナルでは動くが、VS Codeは以前のサービスを使っているように見える | 同じディレクトリから各クライアントで1回ずつリクエストする | プロジェクト全体の問題と、拡張機能の起動方法や設定の違い |
| 1つのプロジェクトだけで問題が起きる | 同じクライアントを問題のプロジェクトとテスト用ディレクトリで使う | プロジェクト設定とマシン全体の設定元 |
| 新しく起動するたびに問題が戻る | プロバイダーマネージャーの起動前後で設定を比較する | 保存された変更とツールが再度書き込む値 |
| Claude Codeは応答するが、BetterTokenに一致する記録がない | 時刻、アカウント、キー、履歴フィルターを確認する | 間違った場所を見ている状態と、ルートがまだ未確認の状態 |
これらの比較で調査範囲は狭まりますが、原因が証明されるわけではありません。変更する前に、クライアント、起動方法、ディレクトリ、テスト時刻を記録してください。
shell、設定ファイル、実行中のクライアントを分けて確認する
macOSまたはLinuxでは、CLIを起動する予定のターミナルで次のコマンドを実行します。
printenv ANTHROPIC_BASE_URL
test -n "$ANTHROPIC_AUTH_TOKEN" && echo "ANTHROPIC_AUTH_TOKEN is set"
test -n "$ANTHROPIC_API_KEY" && echo "ANTHROPIC_API_KEY is set"
最初の結果が示すのは、そのshellの値です。ほかの2行は値の有無だけを表示し、キー自体は出力しません。何も表示されなくても、Claude Codeに認証情報がないとは限りません。別の設定元が提供している可能性があります。また、この確認では、すでに起動中のプロセスやVS Code拡張機能の環境は読み取れません。
次に、同じ変数を定義している可能性があるファイルを探します。プロジェクトルートで次のコマンドを実行すると、一般的な場所にある一致ファイルの名前だけが表示されます。
grep -lE '"ANTHROPIC_(BASE_URL|AUTH_TOKEN|API_KEY)"' \
~/.claude/settings.json \
.claude/settings.json \
.claude/settings.local.json 2>/dev/null
これは網羅的な検索ではありません。独自の設定ディレクトリ、組織のmanaged settings、別の起動ツールが他の設定元を追加している場合があります。結果がない場合も、読み取り可能なこの3つの場所に一致がなかったという意味に限られます。Windowsでは、ファイル内容をチャットへ貼り付けず、対応するファイルをエディターで確認してください。
Claude Codeでは設定元に優先順位があり、有効な値をprintenvだけから判断することはできません。公式設定リファレンスを確認し、CLIで/statusを実行して、読み込まれた設定元を特定します。組織ポリシーが適用される場合は、管理者に実効値を確認してもらってください。
ターミナルとVS Codeの違いを切り分ける
ディレクトリとテスト内容を同じに保ちます。VS Codeでは、クライアント設定ガイドに記載されたclaudeCode.environmentVariablesも別途確認してください。拡張機能が統合ターミナルと同じ環境で起動されたとは限りません。
shellスクリプトやプロバイダーマネージャーを使っている場合は、起動時に変数を定義したり、ファイルを書き換えたりしていないか調べます。.envファイルは、起動経路にあるコンポーネントが読み込んだ場合にだけ影響します。ファイルが存在するだけでは、有効である証拠になりません。
見つかった設定元を1つずつ修正し、ファイル内のほかの項目は維持します。2回の起動を比較するには、テスト対象のクライアントを閉じ、同じ方法でもう一度起動してください。拡張機能では、必要に応じてVS Codeを再起動します。再起動の目的は比較を再現可能にすることであり、すべての設定変更に必ず再起動が必要という意味ではありません。
識別できるリクエストで接続先を確認する
機密情報のないテスト用ディレクトリで時刻を記録し、問題が起きているクライアントから次を送信します。
Reply only: ROUTE_CHECK_A7. Do not read files,
change anything, or run commands.
これは短い応答指示であり、セキュリティ境界ではありません。機密性の高いリポジトリではテストせず、追加の操作も承認しないでください。
想定する接続先がBetterTokenなら、Workspaceのリクエスト履歴を開きます。アカウントとフィルターを確認し、記録した時刻付近の新しい履歴を探してください。キーを識別できる場合は、モデル、ステータス、使用量と合わせて照合します。クライアントの1つの操作が複数の呼び出しを生成することがあるため、「1メッセージにつき1行」の対応は必要ありません。
| 結果 | 判断できること | 次の手順 |
|---|---|---|
| 応答があり、想定したキーに一致する記録もある | テスト結果はBetterToken経由のルートと整合する | クライアントを新しく起動した後に再確認する |
| 応答はあるが、一致する記録がない | 接続先はまだ確認できていない | アカウント、フィルター、表示遅延、ほかの設定元を確認する |
| エラーになった記録がある | リクエストはサービスへ到達したが、正常完了しなかった | API KeyとBase URLのガイドに沿って設定を修正する |
| 複数のクライアントや利用者が同時に同じキーを使っている | 時刻だけではテストの記録を特定できない | 個人用キーを使い、ほかの操作がない状態で再テストする |
ROUTE_CHECK_A7はクライアント内の回答を見分けるための文字列です。この文字列がプロバイダーの履歴にも表示されるとは限りません。同じ時刻付近に別のリクエストがあり得る場合、その記録は間接的な証拠にとどまります。
診断を完了できる条件
問題が起きているクライアントが想定したプロバイダーに一致する記録を作り、新しく起動した後も同じ結果を維持できれば、ルートを確認できたと判断できます。VS Codeだけに問題が残る場合は、動作しているCLIを再度変更せず、拡張機能の起動経路と設定を調べ続けてください。
接続先がまだ不明なら、クライアントのバージョン、起動方法、特定のディレクトリに依存するか、タイムゾーンを含む時刻、見つかった設定元、比較結果をサポート向けにまとめます。API Keyの値、認証ヘッダー、プロジェクト内容は削除してください。アクセス情報を渡さずに、再現可能な差分を共有できます。