Claude Code「Could not load credentials from any providers」の意味と対処法｜Bedrock の AWS 認証

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

このメッセージは、Claude Code を Amazon Bedrock・Claude Platform on AWS・Mantle エンドポイント経由で使う設定（CLAUDE_CODE_USE_BEDROCK=1 など）になっているのに、手元のマシンで使える AWS の認証情報が1つも見つからなかったという意味です。リクエストは AWS まで届いておらず、失敗しているのは手元での認証情報の読み込みです。多くの場合、同じシェルで aws sso login --profile <プロファイル名> を実行し、AWS_PROFILE を設定してから Claude Code を起動し直せば解消します。

Claude Code v2.1.267 より前は、· より前の部分がなく API Error: Could not load credentials from any providers とだけ表示されていました（Error reference）。どちらの表示でも中身は同じです。この記事は、2026年9月25日時点（Claude Code v2.1.282）の公式ドキュメントと、手元で実際に再現した出力をもとにしています。実機で確認した内容とドキュメント記載の内容は書き分けています。

このエラーが出る条件

このメッセージが出るのは、Claude Code の接続先が AWS 経由（Amazon Bedrock、Claude Platform on AWS、Mantle エンドポイント）になっているときだけです。claude.ai のサブスクリプション（Pro・Max・Team・Enterprise）や Claude Console の API キーでログインしている場合、このエラーは出ません。ログインしていないときに出るのは別のメッセージです（Not logged in の対処法）。

公式ドキュメントによると、Claude Code は Amazon Bedrock への接続に AWS SDK の既定の資格情報チェーン（default credential provider chain） を使います（Claude Code on Amazon Bedrock）。Claude Platform on AWS や Mantle エンドポイント経由の場合も同じ AWS 認証情報の解決に失敗するとこのメッセージになります。このチェーンのどこからも認証情報を取り出せなかったときに、このエラーになります。

Error reference に書かれている挙動は次のとおりです。

• リクエストはクラウド側に届いていない（手元での読み込みの失敗）
• Claude Code はキャッシュした認証情報を消して最大2回再試行してから、このメッセージを出す
• · の後ろの詳細文が具体的な原因を示す（SSO セッションの期限切れなど）
• claude -p の非対話実行と Agent SDK では、構造化エラーコードが cloud_credential_error になる（v2.1.267 以降。以前は server_error か unknown）

同じ見出しの中に Google Cloud の Could not load Google Cloud credentials も含まれていますが、この記事では AWS の場合だけを扱います。

AWS SDK が認証情報を探す順番

AWS の公式ガイド（Setting credentials in Node.js）によると、JavaScript 用 AWS SDK v3 の既定チェーンは、次の順に認証情報を探し、最初に見つかったものを使います。

2〜5 は、AWS_PROFILE（未設定なら default）で選ばれたプロファイルの中身を見ます。「どこにも見つからなかった」がこのエラーの正体なので、直し方は「どれか1つを確実に用意する」ことになります。

原因の早見表

· の後ろの詳細文で、原因のあたりがつきます。

2つ目の汎用メッセージは、プロファイルが存在しない場合も、credential_process のコマンドが失敗した場合も、まったく同じ文面でした（後述の実機検証）。文面だけでは区別できないので、次の手順で Claude Code の外から確かめるのが近道です。

対処法

1. Claude Code の外で認証情報を確かめる

まず、Claude Code を起動するのと同じシェルで次を実行します（Troubleshoot installation and login）。

aws sts get-caller-identity

• アカウント ID と ARN が返る → シェルの認証情報は有効。原因は「Claude Code のプロセスに届いていない」側（3 へ）
• エラーになる → AWS 側の設定の問題。2 へ
• 返ってこない（固まる） → 5 へ

2. サインインして AWS_PROFILE を設定する

SSO（IAM Identity Center）を使っている場合は、サインインしてからプロファイルを指定します。公式ドキュメントの手順（Option C）は次のとおりで、aws sso login と AWS_PROFILE の設定に続けて claude の起動コマンドを追加します。

aws sso login --profile=myprofile
export AWS_PROFILE=myprofile
claude

Windows の PowerShell では、環境変数を $env:AWS_PROFILE = "myprofile" のように設定します。

ほかの方法として、公式ドキュメントには次が挙がっています。

• aws configure でアクセスキーを設定する（Option A）
• AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY・AWS_SESSION_TOKEN を環境変数で渡す（Option B）
• aws login でマネジメントコンソールの認証情報を使う（Option D）
• Amazon Bedrock の API キーを AWS_BEARER_TOKEN_BEDROCK に設定する（Option E）。この方法は資格情報チェーンを使いません

リージョンは AWS_REGION、AWS_DEFAULT_REGION、プロファイルの region、us-east-1 の順で決まります。使われているリージョンは、セッション内の /status で確認できます。

3. VS Code・JetBrains では IDE に環境変数を渡す

ターミナルの claude では動くのに、VS Code や JetBrains の拡張機能でだけこのエラーが出る場合、IDE のプロセスがシェルの環境変数を引き継いでいない可能性が高いと公式ドキュメントは説明しています。対処は次のどちらかです。

• IDE 自身の設定で、CLAUDE_CODE_USE_BEDROCK や AWS_PROFILE などの環境変数を設定する
• 環境変数を export 済みのターミナルから IDE を起動する（例：code .）

claude の設定ファイル（~/.claude/settings.json）の env ブロックに書く方法もあります。公式の /setup-bedrock ウィザードも、選んだ認証方法やリージョンをこの env ブロックに保存します（Sign in with Bedrock）。GitHub には、Codespaces 上の VS Code 拡張でこの症状が出たという報告もあります（anthropics/claude-code #51108、コミュニティ報告）。この報告では環境変数自体は正しく設定・確認できていたのに、VS Code 拡張から実行したときだけ失敗していました（プレーンな CLI では再現していません）。issue はこの記事の作成時点で修正されたわけではなく、動きがないまま stale としてクローズされています。

4. credential_process を単体で動かす

プロファイルで credential_process を使っている場合、そのコマンドが失敗しても、表示は汎用の Could not load credentials from any providers になります。プロファイルに書かれたコマンドをターミナルで直接実行し、認証情報の JSON が出力されるか確認してください。

5. 固まる・タイムアウトする場合

詳細文が AWS default-chain credential resolve timed out のときは、チェーンが「失敗した」のではなく「止まった」状態です。Claude Code は1回の解決を60秒で打ち切ります（AWS default-chain credential resolve timed out）。公式ドキュメントが挙げる原因と対処は次のとおりです。

• 入力を待つ credential_process → aws sts get-caller-identity も固まるなら、プロファイル側を直す
• 応答しない IMDS（コンテナや VM） → 環境側を直す
• MFA 付き SSO など、正当に60秒以上かかる → aws sso login を先に済ませるか、CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS をミリ秒で引き上げる

EC2 以外のマシン（手元の Mac など）では、AWS SDK の設定 AWS_EC2_METADATA_DISABLED=true で IMDS への問い合わせを止められます（AWS SDKs and Tools Reference Guide）。後述のとおり、手元の検証ではこれがあるかないかでエラー表示までの時間が大きく変わりました。EC2 のインスタンスロールで認証している環境では設定しないでください。

6. 古いバージョンなら更新する

ドキュメントには、バージョン固有の問題が2つ記載されています。

• v2.1.207：Bedrock のリージョンが SSO プロファイルの sso_region を上書きしていたため、IAM Identity Center が別リージョンにあると Session token not found or invalid で失敗した
• v2.1.207 より前：チェーンが止まると、エラーにならずに待ち続けた

claude --version で確認し、古ければ更新してください。

実機での再現結果（v2.1.282）

2026年9月25日、macOS 上の Claude Code v2.1.282 で、本物の認証情報を一切使わずに再現しました。共通の条件は CLAUDE_CODE_USE_BEDROCK=1・AWS_REGION=us-east-1、AWS のキーの環境変数はすべて未設定、AWS_CONFIG_FILE と AWS_SHARED_CREDENTIALS_FILE は存在しないパス、~/.aws のない空のホームディレクトリです。実行したのは claude -p hi です。

いずれも終了コードは1でした。

再試行の挙動と表示までの時間は、AWS_EC2_METADATA_DISABLED の設定有無で大きく変わりました。このマシンで計測した2つのケースを分けて示します。

• AWS_EC2_METADATA_DISABLED=true を設定した場合（実機で確認）：--output-format stream-json --verbose で実行すると、"error":"cloud_credential_error" の再試行イベントが1回記録されました（max_retries の設定値は 2）。メッセージが表示されるまでは約1.6秒でした。
• AWS_EC2_METADATA_DISABLED を設定せず、IMDS への問い合わせを止めていない場合（実機で確認、再実行で内訳を記録）：起動から約60秒後に最初の再試行イベントが記録され、そこから約60秒間隔で "error":"unknown" の再試行が6回（max_retries の設定値は 10）発生し、最後に "error":"cloud_credential_error" に切り替わってメッセージが表示されました。合計で約490秒（約8分）かかっています。EC2 ではない Mac で IMDS への問い合わせ待ちに時間がかかっていたためと考えられます。

この時間はネットワーク環境によって変わるはずなので、このマシンで計測した目安として扱ってください。

インタラクティブ画面、VS Code 拡張、実際の AWS アカウントを使った確認はしていません。

似ているが別のエラー

AWS まわりには、原因も対処も異なるメッセージがいくつかあります。見分けるポイントは「AWS まで届いたかどうか」です。

出典はいずれも Error reference と Claude Code on Amazon Bedrock です。AWS authentication failed が出た場合は、aws sts get-caller-identity で「どの ID でリクエストしているか」を確認するよう公式ドキュメントは勧めています。古い AWS_PROFILE や default プロファイルのまま、権限のない ID で接続しているケースがよくあるためです。

Claude Code のエラー全般はClaude Code トラブルシューティング完全ガイドにまとめています。

チームで Bedrock を使う場合（管理者向け）

社内で Bedrock 経由の Claude Code を配る場合、公式ドキュメントでは次の設定が用意されています。

• awsAuthRefresh：認証情報の期限切れを検知したときに、aws sso login --profile myprofile のようなコマンドを自動で実行します。実行前に STS の GetCallerIdentity で本当に期限切れかを確かめ、まだ有効なら実行しません
• awsCredentialExport：セッション開始時などに、認証情報を JSON で返すコマンドを実行します。.aws を変更できない環境や、既定チェーンとは別アカウントの認証情報が必要な場合に使います

{
  "awsAuthRefresh": "aws sso login --profile myprofile",
  "env": {
    "AWS_PROFILE": "myprofile"
  }
}

注意点として、企業の VPN や TLS 検査プロキシが SSO のブラウザ処理を妨げる環境では、awsAuthRefresh がブラウザのタブを開き続けるループになることがあります。その場合は awsAuthRefresh を外し、起動前に手動で aws sso login を実行する運用にするよう、公式ドキュメントに記載されています。

IAM 権限の設計やモデルのアクセス許可を含む導入全体は、Claude Code の企業導入ガイドとセキュリティ設計ガイドで解説しています。

よくある質問

まとめ

• このエラーは、Bedrock・Claude Platform on AWS・Mantle エンドポイント利用時に AWS の認証情報が手元で1つも見つからなかったという意味。AWS まで届いていない
• まず同じシェルで aws sts get-caller-identity を実行し、シェル側の問題か、Claude Code に届いていない問題かを切り分ける
• SSO なら aws sso login と AWS_PROFILE。IDE でだけ出るなら、IDE に環境変数を渡す
• 詳細文が resolve timed out なら、止まっている箇所（credential_process・IMDS）を直す
• AWS authentication failed は AWS まで届いた後のエラーで、権限やモデルのアクセス許可も疑う