「AWS default-chain credential resolve timed out」の対処

API Error: AWS default-chain credential resolve timed out — Amazon BedrockやClaude Platform on AWS経由でClaude Codeを使っていると、この文言で止まることがあります。結論から言うと、これは認証情報が間違っているという意味ではありません。AWSのデフォルト認証情報プロバイダーチェーンが60秒以内に何も返さず、Claude Codeが解決自体を諦めたという意味です。リクエストはまだAWS側にすら届いていません。

似た見た目の「認証エラー」と混同しやすいので、まず切り分けの軸を1つだけ押さえます。相手から拒否されたのか、相手にすら辿り着けていないのか。このエラーは後者です。

何が起きているか — 認証情報が60秒間、1つも返ってこない

AWSのデフォルト認証情報プロバイダーチェーンは、環境変数・共有設定ファイル・credential_process・IAMロール・インスタンスメタデータサービス(IMDS)の順に認証情報を探す、AWS SDK共通の仕組みです。Claude Codeはこのチェーンを呼び出しますが、どのステップからも60秒以内に応答がなければ、そこで解決を打ち切ります。

打ち切られた時点でリクエストはまだ送信されていません。Amazon Bedrockにも、Claude Platform on AWSにも、Mantleエンドポイントにも到達していない、ローカルな解決の失敗です。この3つの経路はいずれも同じデフォルトチェーンで署名するため、どれを使っていてもエラーの中身は同じになります。

体感の待ち時間が60秒ぴったりに見えないことも珍しくありません。Claude Codeは認証情報キャッシュをクリアしてから再試行したうえでこのエラーを出すため、画面にメッセージが出るまでに複数回の失敗した試行が積み重なっています。

よくある原因は2つ

原因はほぼ2つに絞られます。どちらもAWS側の設定に起因し、Claude Code自体の不具合ではありません。

• credential_processが入力待ちで固まっている: AWSプロファイルに設定した外部コマンドが、対話的な入力(パスワード・確認プロンプト等)を待っているのに、Claude Codeからはそれを受け取れません。コマンドは永遠に応答を返さず、チェーンはそこで止まります
• コンテナやVMのIMDSが応答しない: インスタンスメタデータサービスへの問い合わせに対して、応答が返ってこない環境です。ネットワークポリシーでIMDSへの経路が塞がれている、あるいはそもそもIAMロールが割り当てられていないコンテナで起きやすい原因です

credential_processが固まるとはどういうことか

credential_processは、AWSの~/.aws/configに書ける設定項目で、認証情報を標準出力に返す外部コマンドを指定できます。たとえばcredential_process = aws-vault exec myprofile --jsonのような形です。この仕組み自体はAWS SDK共通のもので、Claude Code固有ではありません。

問題は、指定したコマンドが対話を前提にしていることがある点です。OSのキーチェーンをロック解除するパスワード入力や、ブラウザでのSSO確認を待つコマンドは、ターミナルの向こうにいる人間を想定しています。Claude Codeからそのコマンドを呼び出しても、待っている入力は届きません。コマンドは応答を返さないまま止まり、チェーンもそこで止まります。

リモート開発環境ではこれがとくに起きやすくなります。SSH先やdevcontainer、CI環境ではブラウザを開けないため、SSOのサインインフローを含むcredential_processはそのまま固まります。対処は、ブラウザを開ける手元の端末で先にaws sso loginを済ませ、リモート側はキャッシュされた認証情報を読むだけの状態にしておくことです。

似た名前の設定と混同しない

このタイムアウトは、認証情報を解決できるまでの上限です。認証情報が解決したあと、実際のリクエストへの応答をどれだけ待つかは別の設定で決まります。API_TIMEOUT_MSがその役割で、既定値は600000ミリ秒(10分)です。CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MSを延ばしても、認証情報が解決したあとの応答待ちには影響しません。逆に、認証情報の解決自体が固まっているときにAPI_TIMEOUT_MSをいくら延ばしても効果はなく、直す対象を取り違えると時間だけが過ぎます。

切り分け手順

まず、Claude Codeを起動したのと同じシェル・同じAWS_PROFILEで、AWS CLI自体が同じように固まるかを確認します。

aws sts get-caller-identity --profile myprofile

これも固まるなら、原因はClaude Codeではなくプロファイルの設定にあります。対話的なサインインを要求するcredential_processコマンドが典型例です。

固まらずに応答するなら、次はサインインのタイミングを疑います。ブラウザ認証を伴うSSOは、Claude Codeを起動する前に済ませておくのが確実です。

aws sso login --profile myprofile

事前にサインインを済ませておけば、チェーンはブラウザフローを待たずにローカルのSSOキャッシュから解決できます。Claude Code起動後にブラウザでの認証を挟む構成は、60秒という制限とそもそも相性がよくありません。

タイムアウトそのものを延ばす

MFA付きのSSOをaws-vaultのようなラッパー経由で使っていると、対話的なサインインに60秒以上かかることが正当にあります。この場合は原因を取り除くのではなく、上限時間側を引き上げます。

CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MSがその設定です。既定値は60000(60秒)で、ミリ秒単位で指定します。Amazon Bedrock・Claude Platform on AWS・Mantleエンドポイントのいずれでも、デフォルトチェーンで署名する経路すべてに効きます。この変数はv2.1.207以降でのみ有効です。

export CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS=180000

延ばす前に、まず切り分け手順で「そもそも解決できるチェーンか」を確認しておきます。credential_processが恒久的に固まっている場合は、時間を延ばしても解決しません。

3つのAWS認証エラーの違い

Claude Codeのエラー一覧には、AWS関連のエラーがほかに2つあります。名前が近く、対処法も混同しやすいので表にまとめます。

違いは条件の有無に出ます。default-chainのタイムアウトはawsAuthRefreshを設定していなくても無条件に発生しますが、残り2つはv2.1.198で入ったawsAuthRefreshの自動更新機能が有効になっているときだけ、専用のメッセージとして表示されます。設定していない環境では、同じ401・403でも汎用的なPlease run /loginに落ち着きます。

AWS経由ではなくAnthropic APIを直接使っていて接続自体に失敗する場合は、原因の切り分け方がまったく別になります。「Unable to connect to API」の原因と対処で扱っています。

よくある質問

このエラーは認証情報が間違っているという意味ですか

いいえ。認証情報の中身が正しいか誤っているかは、この時点ではまだ判定されていません。チェーンが60秒以内に何かを返すことすらできなかった、という解決段階の失敗です。中身が間違っている場合は、AWS側から401や403が返る「AWS credentials expired or invalid」「AWS authentication failed」という別のエラーになります。

awsAuthRefreshを設定していないと出ませんか

出ます。default-chainのタイムアウトはawsAuthRefreshの設定と無関係に、条件なしで発生します。設定が必要なのは「AWS credentials expired or invalid」と「AWS authentication failed」の2つだけです。

CI環境のDockerコンテナで急に出るようになりました

コンテナにIAMロールが割り当てられていない、またはネットワークポリシーでインスタンスメタデータサービスへの経路が塞がれていると、IMDSへの問い合わせが応答なしのまま60秒を迎えます。IAMロールの割り当てと、コンテナからIMDSへの到達性を確認します。

v2.1.207より前のバージョンでは何が起きていましたか

このエラーメッセージ自体が存在しませんでした。チェーンが止まっても失敗として報告されず、操作画面がそのまま固まって見えるだけでした。60秒での打ち切りとこの文言は、v2.1.207で同時に入っています。

API_TIMEOUT_MSを延ばせば直りますか

直りません。API_TIMEOUT_MSは認証情報が解決したあとのリクエスト応答を待つ設定で、認証情報の解決自体が終わらない今回の症状には効きません。延ばすべきはCLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS側です。ただし、credential_processが恒久的に入力待ちで固まっているだけなら、どちらの設定を延ばしても解決しません。

まとめ

「AWS default-chain credential resolve timed out」は、AWSに拒否されたのではなく、認証情報の解決自体が60秒間終わらなかったときに出ます。まずaws sts get-caller-identityを同じプロファイルで実行し、そこでも固まるならプロファイル側のcredential_processを疑います。ブラウザ認証を伴うSSOは起動前に済ませておくと安定し、MFA込みで正当に時間がかかる構成ではCLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MSで上限を引き上げられます。