「Could not load credentials」の直し方 — Claude Code認証エラー

Claude CodeをAmazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由で使っていて資格情報エラーが出たら、原因はほぼ一つです。Claude Code自体ではなく、クラウドプロバイダーのCLIがいま起動しているシェルで認証されていません。3プロバイダーとも症状は「Could not load credentials」系のメッセージで似ていますが、確認コマンドと直し方はプロバイダーごとに違います。

Claude Codeが返す3つの資格情報エラーとプロバイダーの対応

エラー文言を見れば、どのプロバイダー経由で動いているかが分かります。表示は実行しているプロバイダーによって固定です。

どのメッセージも、Claude Code自身が資格情報を作れないわけではなく、各プロバイダーの公式SDKが持つ「資格情報チェーン」を上から順に探して、最後まで何も見つからなかったときに出ます。チェーンの中身と探す順序はプロバイダーごとに決まっているため、対処もプロバイダー別に分けて進めます。

Amazon Bedrockで「Could not load credentials from any providers」が出たとき

このエラーは、Claude Codeを起動したシェルにAWSの資格情報チェーンが解決できる情報が一つも無いことを意味します。まず自分のAWS CLI設定が有効か確認します。

aws sts get-caller-identity

このコマンドがエラーになるなら、Claude Code以前にAWS CLI自体が認証されていません。aws configure でアクセスキーを設定するか、SSOプロファイルを使っているなら aws sso login --profile your-profile-name を実行してから AWS_PROFILE 環境変数でプロファイル名を指定します。IAM Identity Center経由のSSOプロファイルを使う場合、Claude Codeはロールクレデンシャルをプロファイルの sso_region から取得します。この地域はBedrockを実行するリージョンと一致している必要はありません。

aws sts get-caller-identity が成功するのにClaude Code側でエラーが出るなら、CLAUDE_CODE_USE_BEDROCK=1 と AWS_REGION が同じシェルにエクスポートされているかを確認します。設定ファイル(~/.claude/settings.json)の env ブロックに書いた場合は、そのファイルが読み込まれるプロセスで起動しているかも合わせて見ます。

Claude Codeは資格情報チェーンの解決を毎リクエストではなく1回だけ行い、有効期限の5分前まで、または有効期限を持たない資格情報なら1時間、結果をメモリー上に保持します。解決処理自体が60秒でタイムアウトする点も覚えておく価値があります。aws-vault のようなラッパー経由でブラウザーベースのSSO・MFAを使っていて解決が長引く場合は、CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS でタイムアウト値をミリ秒単位で延長できます。タイムアウトすると AWS default-chain credential resolve timed out という別のエラーになるので、両者を混同しないでください。

一度ログインできていたセッションが後から突然401を返すようになった場合は、初回のロードに失敗しているこの記事の状態とは別物です。awsAuthRefresh を設定した環境でセッショントークンが失効したときの挙動はAWS credentials expired or invalidの直し方で扱っています。

Google CloudのAgent Platform(Vertex AI)で「Could not load the default credentials」が出たとき

Google CloudのAgent Platform(旧称Vertex AI)経由でこのエラーが出たら、GCPのApplication Default Credentials(ADC)が設定されていないか失効しています。まず必要な環境変数がシェルに設定されているか確認します。

echo $ANTHROPIC_VERTEX_PROJECT_ID
echo $CLOUD_ML_REGION

どちらかが空なら設定してから、ADCを発行し直します。

gcloud auth application-default login

Claude CodeはこのエラーをAWSの資格情報エラーとは違う扱いにしています。GCPの資格情報が期限切れまたは見つからないと判定すると、キャッシュ済みの資格情報を破棄したうえで最大2回まで自動的に再試行し、設定していれば gcpAuthRefresh コマンドを実行してから、それでも解決しなければエラーとして報告します。v2.1.228より前は、失敗し続ける資格情報を通常のリトライ予算いっぱいまで試してからエラーを出していたため、エラー表示までの体感時間が今より長い版でした。

自動再試行があるからといって、gcloud auth application-default login を実行し直す必要が無くなるわけではありません。再試行はキャッシュのクリアと設定済みコマンドの実行だけを行うので、ADCそのものが失効していれば結局は手動での再認証が必要です。

Microsoft Foundryで「ChainedTokenCredential authentication failed」が出たとき

Microsoft Foundry経由のこのエラーは、Azureの認証情報チェーンがどの方法でも資格情報を解決できなかったことを示します。Foundryには2つの認証方式があり、どちらか一方が有効になっていれば通ります。

ANTHROPIC_FOUNDRY_API_KEY 環境変数が設定されているか確認します。設定していないか、値が空・無効な場合は、Azure CLIでサインインして既定の資格情報チェーンがアカウントを見つけられるようにします。

az login

az login の完了後、同じシェルでClaude Codeを起動し直します。APIキー方式とAzure CLI方式を両方設定している場合の優先順位は公式のプロバイダー別設定に従うため、想定と違う方式が使われていると感じたら、片方だけを一時的に unset して切り分けると原因が絞りやすくなります。

VS CodeやJetBrains拡張だけ資格情報エラーになる場合

ターミナルでは aws sts get-caller-identity や gcloud auth application-default login が成功するのに、VS CodeやJetBrainsの拡張機能内でClaude Codeを実行したときだけ資格情報エラーが出ることがあります。これは3プロバイダー共通で、原因はほぼ一つです。IDEが起動したプロセスは、あなたが手動で設定したシェルの環境変数を引き継いでいません。

.zshrc や .bashrc に書いたプロバイダー用の環境変数は、対話的なターミナルからClaude Codeを起動したときは読み込まれますが、IDEがGUIから直接プロセスを起動する経路では反映されないことがあります。対処は2つです。

• プロバイダーの環境変数をIDE自体の設定(起動時に渡す環境変数の設定)に明示的に書く
• すでに環境変数がエクスポートされているターミナルからIDEそのものを起動する(macOSの .app を直接開くのではなく、ターミナルから code . のように起動する)

どちらの方法でも、IDE内のClaude Codeプロセスが起動した時点で環境変数を持っているようにするのが目的です。設定後に一度IDEを完全に再起動して確認してください。

3プロバイダーの認証確認コマンド早見表

原因の切り分けに使う一次コマンドと、対応する提供元選択の環境変数をまとめます。

3つとも共通するのは、Claude Codeより先にプロバイダーのCLIそのものが認証済みであることを前提にしている点です。Claude Code側の設定を疑う前に、まずCLI単体でコマンドが通るかを確認すると、切り分けの時間が短くなります。

よくあるつまずき

• エラー文言だけで検索して見つからない: 3プロバイダーとも「Could not load」という語幹は共通ですが、続く語(from any providers / the default credentials)と対処が違います。まずどのプロバイダーの環境変数(CLAUDE_CODE_USE_BEDROCK 等)が設定されているかを /status で確認します
• CLIの認証は通っているのにClaude Codeだけ失敗する: 提供元選択の環境変数(CLAUDE_CODE_USE_BEDROCK 等)が、Claude Codeを起動したのと同じシェルにエクスポートされているか確認します
• ターミナルでは動くのにIDE拡張だけ失敗する: IDEが起動したプロセスがシェルの環境変数を引き継いでいません。IDE自体の設定に環境変数を明示するか、環境変数が読み込まれたターミナルからIDEを起動します
• 前は動いていたのに急に失敗するようになった: 初回ロードの失敗ではなくトークンの失効です。詳しい切り分けは前段の「Amazon Bedrockで〜」節を参照してください。Bedrockのストリーミング応答自体でエラーになる場合は別種の不具合で、Bedrock content-typeエラーの原因と対処にまとめています

まとめ

「Could not load credentials」系のエラーは、Claude Codeではなくクラウドプロバイダー側のCLI認証がそのシェルで通っていないことを示します。Bedrockなら aws sts get-caller-identity、Google CloudのAgent Platformなら gcloud auth application-default login、Foundryなら az login で、まずプロバイダーCLI単体の認証を確認してください。IDE拡張だけで再現する場合は環境変数の継承漏れを疑います。Bedrockの料金体系やモデル選択の背景はAWS BedrockのClaude料金は直接APIとどう違うかにまとめています。

よくある質問

/statusではこのエラーの原因は分かりますか

/status は現在アクティブな認証元(APIキー・ログイン・プロバイダー変数のどれか)は表示しますが、そのプロバイダーCLI自体が認証済みかどうかまでは確認しません。プロバイダーCLIの認証確認は、本文で挙げた aws sts get-caller-identity などを別途実行する必要があります。

3プロバイダーの提供元選択の環境変数を同時に設定するとどうなりますか

想定していない優先順位で動作する可能性があるため避けてください。CLAUDE_CODE_USE_BEDROCK ・CLAUDE_CODE_USE_VERTEX ・CLAUDE_CODE_USE_FOUNDRY はいずれか一つだけをそのセッションのシェルに設定します。

設定ファイルのenvブロックに書いた変数を消したいときはどうしますか

設定ファイルでは変数の追加はできても削除はできません。シェルプロファイルなどで意図せずエクスポートされている変数を上書きしたい場合は、env ブロックでその変数を空文字列に設定します。Claude Codeは空文字列をプロバイダー選択上「未設定」として扱います。

AWS default-chain credential resolve timed outとCould not load credentials from any providersはどう違いますか

前者はチェーンの解決処理自体が60秒以内に終わらなかった場合、後者はチェーンを最後まで探した結果として資格情報が一つも見つからなかった場合に出ます。前者はタイムアウト値の延長、後者はそもそもの認証設定を疑います。