Claude Media
「Could not load credentials」の直し方 — Claude Code認証エラー
Claude Codeチュートリアル

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

Claude CodeをBedrock・Google CloudのAgent Platform・Microsoft Foundry経由で使うときに出る資格情報エラーを、プロバイダー別のCLI認証コマンドとIDE拡張特有の原因で切り分けます。

読了目安 約13分

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

画面に出る文言から、どのプロバイダーの問題か判別する

表示される文言は、実行しているプロバイダーごとに決まっています。

文言

資格情報エラーの3つの文言

  • Amazon Bedrock

    Could not load credentials from any providers。AWSの資格情報チェーンが空です。

  • Google CloudのAgent Platform

    Could not load the default credentials。Application Default Credentialsが未設定か失効しています。

  • Microsoft Foundry

    ChainedTokenCredential authentication failed。Azureの資格情報チェーンが全て失敗しています。公式の症状表には CredentialUnavailableError も同じ行に載っています。

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

v2.1.267以降はメッセージの前半が変わっている

AWSとGoogle Cloudについては、公式のエラー一覧が次の2行を実例として挙げています。

API Error: Could not load AWS credentials · Could not load credentials from any providers. Check or refresh your AWS credentials and try again.
API Error: Could not load Google Cloud credentials · invalid_grant. Check or refresh your Google Cloud credentials and try again.

· の後ろが原因を示す詳細です。期限切れのSSOセッション、ADCの未設定(Could not load the default credentials)、取り消されたサインイン(invalid_grant)などが入ります。検索で拾うべき文言は前半ではなく、この後半側です。-p の非対話モードとAgent SDKでは、構造化エラーコードが cloud_credential_error になります。v2.1.267より前は API Error: に続く詳細文だけが表示され、コードも server_error か unknown でした。古いバージョンの画面キャプチャーと文言が違って見えるのはこのためです。

最初に押さえる3手の切り分け

手順

資格情報エラーの切り分け順

  1. 1

    プロバイダーを特定する

    上の文言か、後述する claude auth status の apiProvider で、どのプロバイダーで動いているかを確定させます。

  2. 2

    プロバイダーCLI単体で認証を確かめる

    aws sts get-caller-identity などをClaude Codeを起動したのと同じシェルで実行します。ここで失敗するなら、Claude Code側の設定を見る必要はありません。

  3. 3

    CLIが通るのに失敗するなら環境変数の届き方を疑う

    提供元選択の変数がClaude Codeの起動元プロセスに届いているか、IDE拡張の場合はIDEが変数を引き継いでいるかを見ます。

claude auth status は資格情報の有効性まで見てくれない

切り分けの第1手に claude auth status を使いたくなりますが、確認できる範囲は限られます。確認環境はv2.1.285です。CLAUDE_CONFIG_DIR に空の一時ディレクトリを指定し、AWS・Google Cloud・Azureの資格情報は何も用意せず、提供元選択の変数だけを付けて実行しました。

claude auth status
CLAUDE_CODE_USE_BEDROCK=1 claude auth status

1行目(変数なし)は "loggedIn": false と "authMethod": "none"、"apiProvider": "firstParty" を返しました。2行目は次の出力です(パスは省略)。

{
  "loggedIn": true,
  "authMethod": "third_party",
  "apiProvider": "bedrock",
  "analyticsDisabled": true
}

CLAUDE_CODE_USE_VERTEX=1 では "apiProvider": "vertex" になりました。CLAUDE_CODE_USE_FOUNDRY=1 では "foundry" です。どちらも loggedIn は true でした。つまり、この出力が示しているのは「提供元がどれとして解釈されたか」までです。クラウド側に有効な資格情報があるかどうかは、loggedIn: true でも保証されません。資格情報エラーの原因究明に使えるのは、apiProvider が意図したプロバイダーになっているかの確認までと考えてください。

同じ環境で CLAUDE_CODE_USE_BEDROCK=1 と CLAUDE_CODE_USE_VERTEX=1 を同時に付けると、apiProvider は bedrock になりました。CLAUDE_CODE_USE_BEDROCK を空文字にすると firstParty に戻ります。確認したのはこの組み合わせだけです。3変数すべての優先順位は確かめていないので、複数を同時に設定しない運用のほうが安全です。

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 ブロックに書いた場合は、そのファイルが読み込まれるプロセスで起動しているかも合わせて見ます。

v2.1.207以降のClaude Codeは、資格情報チェーンの解決を毎リクエストではなく1回だけ行い、有効期限の5分前まで、または有効期限を持たない資格情報なら1時間、結果をメモリー上に保持します。解決処理自体が60秒でタイムアウトする点も覚えておく価値があります。aws-vault のようなラッパー経由でブラウザーベースのSSO・MFAを使っていて解決が長引く場合は、CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS でタイムアウト値をミリ秒単位で延長できます。タイムアウトすると AWS default-chain credential resolve timed out という別のエラーになります。前者は「チェーンが途中で止まった」、Could not load credentials from any providers は「最後まで探して何も無かった」ので、直す先が違います。

一度ログインできていたセッションが後から突然401を返すようになった場合は、初回のロードに失敗しているこの記事の状態とは別物です。ストリーミング応答自体のエラーも別種の不具合です。Bedrock content-typeエラーの原因と対処にまとめています。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

ブラウザーでのログインが使えない環境では、公式のトラブルシューティングにもう一つ選択肢があります。サービスアカウントのキーファイルのパスを GOOGLE_APPLICATION_CREDENTIALS に設定する方法です。

GCPの資格情報が期限切れまたは見つからないと判定すると、Claude Codeはキャッシュ済みの資格情報を破棄して最大2回まで自動的に再試行します(AWSの読み込み失敗も同じ扱いです)。gcpAuthRefresh を設定していれば、そのコマンドを実行してから再試行し、それでも解決しなければエラーとして報告します。GCPだけの差は旧バージョンにあり、v2.1.228より前は、失敗し続けるGoogle Cloudの資格情報を通常のリトライ予算いっぱいまで試してからエラーを出していたため、エラーが表示されるまでの待ち時間が今より長くなっていました。

gcpAuthRefresh にはブラウザー認証を使うコマンドを指定できます。コマンドの出力は画面に表示されますが、対話入力は送れず、認証が終わらないと3分でタイムアウトします。再試行が行うのは、キャッシュのクリアと設定済みコマンドの実行だけです。ADCが失効していて gcpAuthRefresh も未設定なら、手動で gcloud auth application-default login を実行し直します。

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

Azureの認証情報チェーンがどの方法でも資格情報を解決できなかったことを示します。Foundryの認証は、優先順位の高いほうから次の3つです。

優先度認証手段未設定のときの動き
1認証手段ANTHROPIC_FOUNDRY_AUTH_TOKEN未設定のときの動き次へ
2認証手段ANTHROPIC_FOUNDRY_API_KEY未設定のときの動き次へ
3認証手段Azure SDKの既定の資格情報チェーン(az login など)未設定のときの動き全て失敗すると本エラー

ANTHROPIC_FOUNDRY_AUTH_TOKEN(v2.1.203以降)は ANTHROPIC_FOUNDRY_API_KEY と既定チェーンの両方より優先されます。APIキーも認証トークンも設定していない場合に、Azure CLIでサインインして既定の資格情報チェーンがアカウントを見つけられるようにします。

az login

az login の完了後、同じシェルでClaude Codeを起動し直します。想定と違う方式が使われていると感じたら、優先度の高いほうの変数を一時的に unset して切り分けると原因が絞りやすくなります。FoundryにはBedrockやGoogle Cloudのような対話型のセットアップウィザードが無く、環境変数から読み込まれて最初のプロンプトの時点で接続されるため、変数が届いていないとこのエラーで初めて気づくことになります。

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

ターミナルでは aws sts get-caller-identity や gcloud auth application-default login が成功するのに、VS CodeやJetBrainsの拡張機能内でClaude Codeを実行したときだけ資格情報エラーが出ることがあります。公式のトラブルシューティングは、IDEのプロセスがシェルの環境を引き継いでいないことを疑うよう案内しています。

くらべる

IDEに環境変数を渡す2つの経路

IDEごとに1回

IDE自体の設定に書く

プロバイダーの環境変数をIDEの設定に明示します。起動のしかたに左右されず、GUIから開いても届きます。

起動のたびに必要

ターミナルからIDEを起動する

環境変数がエクスポート済みのターミナルから code . のように起動します。GUIから直接開き直すと、変数を引き継がないことがあります。

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

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

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

プロバイダー提供元選択の環境変数認証確認コマンド再認証コマンド
Amazon Bedrock提供元選択の環境変数CLAUDE_CODE_USE_BEDROCK認証確認コマンドaws sts get-caller-identity再認証コマンドaws sso login --profile <name> または aws configure
Google CloudのAgent Platform提供元選択の環境変数CLAUDE_CODE_USE_VERTEX認証確認コマンドgcloud auth application-default print-access-token再認証コマンドgcloud auth application-default login
Microsoft Foundry提供元選択の環境変数CLAUDE_CODE_USE_FOUNDRY認証確認コマンドaz account show再認証コマンドaz login

この表で公式docsに載っているコマンドは、aws sts get-caller-identity・aws sso login・gcloud auth application-default login・az login です。gcloud auth application-default print-access-token と az account show は各クラウド標準のCLIコマンドです。Claude Codeの公式docsには記載がありません。

まとめ

「Could not load credentials」系のエラーは、Claude Codeではなくクラウドプロバイダー側のCLI認証がそのシェルで通っていないことを示します。claude auth status が loggedIn: true を返しても、資格情報の有効性は確認できません。Bedrockなら aws sts get-caller-identity、Foundryなら az account show のように、プロバイダーCLI単体で確かめるのが確実です。Bedrockの料金体系やモデル選択の背景はAWS BedrockのClaude料金は直接APIとどう違うかにまとめています。

よくある質問

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

Bedrockの公式ドキュメントでは、/status は解決されたリージョンや、Mantleが有効かどうかといった提供元の設定を確認する手段として登場します。Foundryのドキュメントでも、提供元の表示(Microsoft Foundry)を設定確認に使う手段として /status が挙がっています。プロバイダーCLIが認証済みかどうかを調べる用途としては書かれていないので、本文の認証確認コマンドを別途実行してください。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →