Claude Codeの403エラー：地域制限・ゲートウェイ・TLS・ログイン

Claude CodeでHTTP 403が返っても、それだけでアカウントが利用停止になったとは判断できません。ここで扱う診断表示、ゲートウェイ、証明書の修正を含むClaude Code 2.1.318以降を使ってください。そのうえで、ログインを繰り返すのではなく、表示されたエラーに合う手順で原因を調べます。

2.1.317のリリースノートでは、地域・ネットワークによる遮断とログイン失敗を区別しています。2.1.318のリリースノートには、証明書ファイルに問題がある場合の処理と、保存済みログインの期限切れを明示する改善が記載されています。これらは障害の原因を見分けるための変更です。アクセス制限を解除したり、あらゆるゲートウェイ設定を修復したりするものではありません。

修正済みのバージョンと小さなリクエストで確認する

2026-11-10時点で、ここで扱う修正をすべて含む最小バージョンは2.1.318です。最新バージョンが2.1.318だという意味ではありません。個々の修正が初めて入ったバージョンは次のとおりです。

症状	該当する修正を初めて含むバージョン	最初に確認すること
地域・ネットワークによるHTTP 403がログイン失敗として表示される	2.1.317	遮断の説明を読み、応答したサービスを特定します
地域・ネットワークによる遮断後にVS Codeがログイン画面を開く	2.1.317	問題が起きたVS Codeの画面から再試行します
Base URLに指定したゲートウェイが安全性チェックに403または422を返し、Autoが毎ターン失敗する	2.1.317	ManualとAutoを比較します。apiKeyHelper使用時の403は例外のままです
TLS通信を検査するプロキシのルート証明書更新後にunable to get local issuer certificateが出る	2.1.317	組織が承認した証明書チェーンとクライアントのバージョンを確認します
NODE_EXTRA_CA_CERTSのファイルが空、PEM以外、または先頭の証明書が破損していて接続に失敗する	2.1.318	証明書ファイルを修正し、起動時の警告を確認します
必須のClaude apps gatewayに接続できない	2.1.317	ネットワーク経路と証明書の信頼設定を確認します
保存済みのclaude.aiログインが有効期限に達する	2.1.318	ネットワークではなく、使用中のログインを更新します

Bashで、実際に使っているCLIを確認します。

claude --version
claude auth status

CLIリファレンスでは、claude auth statusは認証状態を報告するコマンドとされています。設定されている認証の状態を調べるために使います。モデルへのリクエストが成功することを保証する結果ではありません。

インストール方法に対応した更新手順を使ってください。ネイティブ版をインストールした場合は、次を実行します。

claude update
claude --version

パッケージマネージャー経由の導入や組織による一括管理の場合は、インストールと更新の手順に従ってください。表示されたバージョンが必要な最小バージョン以上であることを確認します。再試行は、失敗が起きたインターフェースで行います。ターミナルから成功しても、VS Codeからの接続が正常だと確認できたことにはなりません。

次に、バージョンと認証状態を確認したのと同じBash環境から、小さなリクエストを1つ送ります。

claude -p 'Reply with exactly OK. Do not use tools.'

確認時に期待するのは、接続エラーも認証エラーも発生せず、モデルからOKという応答が返ることです。これで確認できるのは、モデルへの基本的なリクエストです。Autoモードの安全性判定の経路や、すべての機能との互換性を検証するものではありません。

地域・ネットワークの遮断とログイン期限切れを区別する

エラーが遮断を示している場合は、ネットワークやアクセス拒否の理由を調べてください。この症状に対して、最初から再認証を行う必要はありません。

2.1.317の変更履歴には、次のように記載されています。以下は訳です。

地域またはネットワークによる遮断（HTTP 403）がログイン失敗として表示される問題を修正しました。エラーには遮断の説明が表示されるようになりました。

同じリリースでは、この状況でVS Codeがログイン画面を開く問題も別途修正されています。どちらの記載も、更新すれば遮断されたリクエストが許可されるとは述べていません。

Claude Codeを起動して/statusを実行します。ゲートウェイ接続の手順に沿って、現在の接続先と認証情報の取得元を確認してください。アカウントを調べる前に、Anthropicへ直接送信しているのか、設定したゲートウェイを使っているのかを特定します。

社内ネットワークでは、問題が起きたプロセスに適用されるプロキシ設定をIT担当者に確認してもらってください。対象にはHTTPS_PROXYとHTTP_PROXYも含まれます。これらの変数はネットワーク設定ガイドに記載されています。地域制限が確認できた場合は、認証情報の更新を繰り返すのではなく、提供元にサービスの利用可否を確認します。

取得できる範囲で、レスポンス本文、送信先ホスト名、時刻、リクエストIDを保存してください。サポートへの問い合わせに、環境変数の一括出力、認証情報、プロンプト全文を添付しないでください。

アカウントの保留・停止を明示する通知が別にある場合は、アカウントのサポート窓口で調べる問題です。Anthropicのエラーリファレンスでは、その状態をアカウントの停止と説明しています。別の可能性として、要求したモデルの利用権限がない場合もあります。インストールと認証のガイドには、認証が成功しても、そのモデルを使えないアカウントには403が返る場合が記載されています。

確認のため、意図した承認済みの経路から、もう一度小さなリクエストを送ります。引き続き403になる場合は、現在のエラー説明と提供元の記録を照合し、拒否の理由を特定してください。ステータスコードだけでアカウントの利用停止と判断しないでください。

ゲートウェイ経由でAutoが毎ターン失敗する場合

同じゲートウェイでManualは動作し、Autoだけが繰り返し失敗する場合は、安全性チェックの経路を調べます。2.1.317の修正には明確な適用範囲があります。変更履歴の訳は次のとおりです。

ベースURLに指定されたLLMゲートウェイがサーバー側の安全性チェックに403または422を返すと、Autoモードが毎ターン失敗する問題を修正しました。apiKeyHelperを使う場合の403の挙動は変わりません。

この例外を見落とさないでください。apiKeyHelperが有効な状態での403は、この変更の対象ではありません。ヘルパーが返す秘密情報を公開せずに、ゲートウェイ管理者へ認証情報とアクセス許可の処理を確認してもらいます。

ゲートウェイ互換性ガイドには、サーバー側の判定に使うanthropic-betaの値と、リクエストのsafeguardsフィールドが記載されています。ゲートウェイがこの機能を拒否する場合と、認証情報を拒否する場合では、調べる対象が異なります。そのリクエストで機能が拒否されたのか、認証情報が拒否されたのかは、ステータスコードだけを見ても特定できません。

信頼できるGitリポジトリの作業コピーで、2つのセッションを比較します。モデル、エンドポイント、認証情報、依頼する作業は同じにしてください。

claude --permission-mode defaultで起動します。Claudeに、Bashでgit status --shortを実行し、ファイルを変更せずに結果を報告するよう依頼してください。コマンド実行の許可を求める確認が表示された場合は、その操作を承認してください。

そのセッションを終了し、claude --permission-mode autoで起動して同じ作業を依頼します。権限モードの操作手順で、指定したモードが実際に有効になっていることを確認してください。Autoになっていないセッションの成功は、Autoの動作確認にはなりません。

Autoのセッションだけが失敗した場合は、失敗したリクエストをゲートウェイの記録と照合します。管理者には、互換性ガイドに沿って拒否の理由を調べてもらってください。この比較で調査範囲は絞れますが、原因となった具体的なゲートウェイルールまでは証明できません。

管理者の承認を得たうえで、一時的な診断としてサーバー側の判定を切り替える方法もあります。代わりに、操作を評価するClaude Code自身の分類器リクエストを使います。

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

この切り替えは環境変数リファレンスに記載されています。判定を行う場所を変える設定であり、権限チェックを無効化する設定ではありません。この設定を使っても、分類器による判定のためにモデルへのリクエストは引き続き発生します。設定を残す前に、リクエストの使用量と待ち時間を確認してください。

このセッションは成功し、通常のAutoは失敗する場合、サーバー側の判定との互換性を調べます。どちらも失敗する場合は、表示された認証情報、モデル、ゲートウェイのエラーを調べてください。今回の修正が当てはまると決めつけないことが重要です。

課金上の違いは、サーバー側分類器の課金と代替処理の挙動を参照してください。分類器の独立したリクエストを、オフラインで動く代替手段や、必ず無料になる代替手段と考えないでください。

認証ではなく証明書の信頼設定を修正する

unable to get local issuer certificateは、証明書の信頼設定に関する問題として扱います。HTTPでアクセス許可に関する応答が返る場合とは、障害が起きる層が異なります。

2.1.317の変更履歴には、次のように記載されています。以下は訳です。

一部のTLS検査プロキシで、ルート証明書の更新後にAPIリクエストが”unable to get local issuer certificate”で失敗する問題を修正しました。

この修正が対象にしているのは、ルート証明書の更新後に、一部のTLS検査プロキシで発生するという条件付きの問題です。発行元証明書に関するすべてのエラーが、同じ原因で起きるという意味ではありません。

まずクライアントのバージョンを確認します。次に、プロキシのルート証明書が変更されたかをIT担当者に確認してください。クライアントが信頼すべき認証局（CA）の証明書バンドルも確認します。出所を確認できない証明書をコピーするのではなく、組織が承認したPEM形式のバンドルを使ってください。

独自の証明書バンドルが必要な環境では、IT担当者から受け取ったファイルを$HOME/company-ca.pemとして保存します。同じBashシェルから、Claude Codeの新しいプロセスを起動してください。

export NODE_EXTRA_CA_CERTS="$HOME/company-ca.pem"
claude -p 'Reply with exactly OK. Do not use tools.'

これは、文書化されている独自CAの設定手順に沿ったものです。例のパスは、利用者が選ぶローカルファイル名です。証明書の内容は、必ず所属組織から提供されたものを使ってください。

発行元証明書のエラーなしでリクエストが完了すれば、この確認は成功です。まだ失敗する場合は、提供されたバンドルと、プロキシ経由で提示される証明書チェーンをIT担当者に調べてもらってください。

NODE_TLS_REJECT_UNAUTHORIZED=0は設定しないでください。Anthropicの証明書エラーへの対処ガイドでは、この設定が証明書の検証を無効化すると警告しています。

NODE_EXTRA_CA_CERTSファイルが空または破損している場合

追加CAのファイル自体に問題がある場合は、2.1.318以降を使ってください。変更履歴には次のように記載されています。以下は訳です。

NODE_EXTRA_CA_CERTSのファイルが空、PEM形式ではない、または先頭の証明書が破損している場合に、すべての接続が失敗する問題を修正しました。読み取れる証明書を使い、stderrに警告を出すようになりました。

接続の成否だけでなく、警告も確認してください。この修正は、読み取れる証明書を使えるようにするものです。ファイルそのものを修復したり、プロキシに必要な証明書の不足を補ったりするものではありません。

空または破損したバンドルは、承認済みのPEMファイルに置き換えます。意図せず設定されたNODE_EXTRA_CA_CERTSを削除する場合は、先にその環境で不要であることを確認してください。その後、新しいプロセスを起動して、小さなリクエストを再実行します。

リクエストに成功しても、証明書ファイルの警告が残る場合は、バンドルを修正してください。警告が残ったままで設定が完了したとは判断しないでください。

必須のClaude apps gatewayに接続できない場合

有効なログイン情報を変える前に、必須ゲートウェイへの接続を復旧してください。2.1.317の記載は次のとおりです。以下は訳です。

必須のClaude apps gatewayに接続できない場合の起動エラーを改善しました。ログインではなくネットワークの問題を示し、ゲートウェイのTLS証明書を検証できない場合も明示します。

この記載の対象は、必須のClaude apps gatewayです。任意のサードパーティーのANTHROPIC_BASE_URLエンドポイントにも当てはまると判断しないでください。

問題が起きたホスト名と、機密情報を除いたエラーをゲートウェイ管理者に渡します。サービスへの到達性、DNS、プロキシのポリシー、証明書の信頼設定を確認してもらってください。証明書の検証を示すメッセージなら、認証情報をリセットするのではなく、CAの確認手順に進みます。

検証は2段階で行います。まずClaude Codeがゲートウェイの起動エラーを越えて起動できることを確認し、次に小さなモデルリクエストを完了させます。その後に認証エラーが出た場合は、別の結果として調べてください。

ログインを更新するのは、その認証情報が期限切れの場合

保存済みのclaude.aiログインが期限切れだとエラーが示している場合は、ログインを更新します。2.1.318のリリースノートでは、このケースをネットワークの遮断と区別しています。以下は訳です。

保存済みのclaude.aiログインが有効期限に達したときのログイン失敗を修正しました。期限切れであることを明示し、claude -pではclaude auth loginとclaude setup-tokenを案内します。

claude.aiログインを使う対話型の作業では、Bashで次を実行してください。

claude auth login
claude auth status
claude -p 'Reply with exactly OK. Do not use tools.'

ログインが完了してから、認証状態の確認とリクエストに進みます。期待する結果は、意図した認証状態が確認でき、その後のリクエストにも成功することです。

このリリースでは、非対話型の実行環境で認証を復旧する方法としてclaude setup-tokenも案内しています。トークンをスクリプトに埋め込まず、該当する認証手順に従ってください。

ゲートウェイが発行した認証情報は、その発行元で復旧する必要があります。claude.aiへのログインでは、その認証情報を検証できません。ログインを更新しても地域、ネットワーク、ゲートウェイのエラーが出る場合は、該当する確認手順に戻ります。ログインの繰り返しで解決しようとしないでください。

ANTHROPIC_BASE_URLと使用中の認証情報を確認する

設定をさらに変える前に、問題が起きているセッション内で接続経路を確認してください。接続ガイドでは、有効なBase URLと認証情報の取得元を確認するために/statusを推奨しています。

ゲートウェイの文書にある、Anthropic互換のベースアドレスを使います。プロトコルガイドでは、ANTHROPIC_BASE_URLをAnthropic Messages形式および/v1/messagesに対応付けています。プロトコルを確認せずに、OpenAI互換のURLをこの設定へコピーしないでください。その違いは、Base URLとエンドポイントのトラブルシューティングガイドで説明しています。

認証情報を設定する変数は、ゲートウェイが要求するヘッダーに合わせて選びます。Anthropicの文書では、ANTHROPIC_AUTH_TOKENはAuthorization: Bearer、ANTHROPIC_API_KEYはX-Api-Keyとして送信する認証情報です。同じ認証情報を利用可能なすべての変数に入れるのではなく、ゲートウェイの手順に従ってください。

既存のBetterToken API接続では、Claude Code向けの手順に従い、/v1を付けないhttps://bettertoken.aiとANTHROPIC_AUTH_TOKENを使います。2026-11-10時点で、カタログにはclaude-sonnet-5-5が掲載されています。BetterTokenを使うこの接続経路で提供されるのは、独立したAPIアクセスです。Claudeのサブスクリプションではなく、Claude Codeのすべての機能が動くという保証でもありません。

実際のセッションで有効になっている接続先が、自分で意図した設定と異なる場合は、Claude Codeが使う提供元の確認手順に従ってください。小さなリクエストを意図した提供元の記録と照合し、その後に失敗していた操作を再実行します。基本的な接続の確認なら、単純な返答で十分です。Autoモードの障害では、Autoの比較テストも成功する必要があります。