Claude Codeで認証方式を解決できないエラーの原因と対処法

エラーの正体は「ワーカーに資格情報が届いていない」

Could not resolve authentication method は、セッションがAPIクライアントまで到達したのに、使える資格情報が一つも見つからなかったときに出ます。

Could not resolve authentication method. Expected one of apiKey, authToken, credentials, config, or profile to be set. Or for one of the "X-Api-Key" or "Authorization" headers to be explicitly omitted

この文字列が画面に出るのは、バックグラウンドセッションとクラウドセッションです。ワーカーが資格情報を持たないまま起動したときに表示されます。

通常の対話セッション、-p による非対話実行、Agent SDKの実行は同じ状態を Not logged in として報告します。この長い文字列はデバッグログにだけ書かれます。つまり、SDKやCIの画面にこの文言が直接出ていると思い込むと、見るべき場所を外します。デバッグログで見つけた場合は、Not logged in の対処に従います。

症状から切り分ける

どの経路で出たかによって、最初に疑う場所が変わります。ローカルの対話セッションで普通にログインできているのに、バックグラウンドのジョブだけが落ちるなら、原因はワーカーの側にあります。

バックグラウンドセッションの資格情報はスーパーバイザーが持つ

バックグラウンドセッションは、スーパーバイザーという別のプロセスの下で動いています。スーパーバイザーは、バックグラウンドセッションを動かし続けるためのバックグラウンドサービスです。/bg や claude agents を初めて使ったときに自動で起動し、保存済みの資格情報を使って各セッションを認証します。

ここが鍵になります。ローカルの対話セッションが正常にログインできていても、スーパーバイザーが資格情報を持たない状態で起動していれば、そこから派生するワーカーはすべて同じ状況になります。agent viewのトラブルシューティングにも、対話セッションは認証できているのにバックグラウンドのディスパッチだけが失敗する場合の手順があります。

対処は、/login の実行か ANTHROPIC_API_KEY の設定で資格情報を用意したうえで、スーパーバイザーを止めることです。

claude daemon stop --any --keep-workers

--any は一時的に起動したスーパーバイザーも止めるオプション、--keep-workers は動作中のバックグラウンドセッションを残すオプションです。次に claude agents か claude --bg を実行すると、新しいスーパーバイザーが起動して保存済みの資格情報を読み直します。

/login ではなく環境変数で認証している場合は、その次のコマンドを、変数を設定したシェルから実行します。変数は新しいスーパーバイザーを起動したシェルのものが使われるためです。

v2.1.287で claude daemon --help を確認すると、停止まわりのサブコマンドは次のように表示されました。

  status            Show daemon pid, version, uptime
  logs              Tail the daemon log (Ctrl-C to stop)
  ...
  stop              Shut down the supervisor and terminate background sessions
                      --any           also stop a transient (non-service) daemon
                      --keep-workers  leave detached sessions running

status で現在のスーパーバイザーのバージョンと稼働時間を見られるので、「作り直したはずなのに古いスーパーバイザーが残っている」という状況も切り分けられます。

バージョンによる既知の不具合

資格情報の設定漏れとは別に、Claude Code側の不具合が原因だったケースが2つあります。changelogでは、どちらも同じ日(2026年6月12日)のリリースで直っています。

現行のバージョンでは、このエラーは「ワーカーに資格情報が無かった」ことを意味します。したがって、新しいバージョンで出ているなら、不具合ではなく環境側を疑います。環境変数を何度見直しても解決しないときは、先に claude --version を確認すると、設定ミスと不具合を切り分けられます。

資格情報の期限切れとは症状が違う

資格情報はあるのに有効期限が切れた場合は、別の経過をたどります。agent viewの説明では、期限切れのログインは「あなたしか解消できないエラー」として扱われ、該当セッションは blocked 状態になります。ログインを使い続けるバックグラウンドセッションやRemote Controlのセッションは、期限が切れると進捗が止まり、再ログインするまで回復しません。

つまり、Could not resolve authentication method で起動直後に落ちる場合は「最初から資格情報が無い」、blocked で止まる場合は「途中で期限が切れた」と読み分けられます。後者の対処は、agent viewを開いて /login からサインインし直すことです。

もう一点、スーパーバイザーは、完了済みか返信待ちの状態で約1時間だれも接続していないセッションのプロセスを止めます。次に接続や返信をすると会話は保存済みの状態から再開されるので、アイドル後に再開した直後に資格情報のエラーが出る場合も、上の切り分けがそのまま使えます。Ctrl+T でピン留めしたセッションは、アイドル中もプロセスが維持されます。

メッセージの5つの候補と、実際の設定先

エラーメッセージは apiKey, authToken, credentials, config, or profile のどれかが設定されているはずだと述べています。この5語がClaude Codeのどの設定に当たるかは、エラーの説明に書かれていません。語の意味からの推定は次のとおりです。

確認の手がかりにするなら、語の対応よりも、Claude Codeが資格情報を選ぶ順番を押さえるほうが確実です。上にあるものが優先されます。

1. CLAUDE_CODE_USE_BEDROCK・CLAUDE_CODE_USE_VERTEX・CLAUDE_CODE_USE_FOUNDRY によるクラウドプロバイダーの資格情報
2. ANTHROPIC_AUTH_TOKEN
3. ANTHROPIC_API_KEY
4. apiKeyHelper スクリプトの出力
5. CLAUDE_CODE_OAUTH_TOKEN(claude setup-token で作る長期トークン)
6. Anthropicプロファイルとフェデレーションの資格情報
7. /login のサブスクリプションOAuth資格情報

この表の外にも例外があります。Claude appsゲートウェイにサインインしたセッションは、クラウドプロバイダーの設定よりも優先されます。また、Claude Desktopとクラウドセッションは apiKeyHelper を呼ばず、ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN も読みません。OAuthで認証するためです。Desktopでサードパーティの推論設定を使う場合は、その設定の資格情報を使います。クラウドセッションでこのエラーが出たときに、ANTHROPIC_API_KEY を設定し直しても効かない理由はここにあります。

各変数の用途はClaude Code環境変数リファレンス、Claude Code全体の認証まわりはログイン方法3種の使い分けで確認できます。

Not logged in との違い

同じ「資格情報が無い」状態でも、出る場所によってメッセージが変わります。

対処の中心も違います。Not logged in は /login か、ANTHROPIC_API_KEY をexportしたシェルで起動し直すことで直ります。このエラーは、起動元(スーパーバイザーやワーカーを立ち上げた環境)に資格情報が無いのが原因なので、/login を対話セッションで実行しただけでは足りない場合があります。

環境変数が届かない典型パターン

資格情報を環境変数で渡している場合、「対話シェルにはあるのに、別プロセスには無い」ことがこのエラーの典型的な原因です。

.zshrc や .bash_profile に書いた export ANTHROPIC_API_KEY=... は、そのファイルを読む対話シェルから起動したときだけ有効です。cron・systemdサービス・コンテナのエントリーポイントのようにプロファイルを経由しない起動では、変数を明示的に渡す設定が別途必要です。

バックグラウンドセッションでは、プロジェクトの設定ファイルの env ブロックも読まれます。シェルのexportに頼らず、起動方法に左右されない形にしたいなら、こちらに書く選択肢があります。ただしAPIキーを設定ファイルへ書くとリポジトリに混ざる危険があるので、コミットしない設定ファイルに置く前提です。

CIやスクリプトでブラウザーログインが使えない場合は、claude setup-token で1年有効のOAuthトークンを作り、CLAUDE_CODE_OAUTH_TOKEN に設定する方法があります。注意点が1つあります。--bare 付きで起動すると、このトークンは読まれません。bareモードはOAuthとキーチェーンを読まず、認証は ANTHROPIC_API_KEY か、--settings で渡す apiKeyHelper に限られます。v2.1.287の claude --help にも次のように出ています。

  --bare   Minimal mode: skip hooks ... Anthropic auth is
           strictly ANTHROPIC_API_KEY or apiKeyHelper via --settings
           (OAuth and keychain are never read).

setup-token で作ったトークンを --bare のスクリプトに渡して認証が通らないなら、このエラー(多くはデバッグログ上の文字列)の原因になりえます。

デバッグログで解決経路を追う

環境変数を目視で確認しても原因が分からないときは、デバッグログを出します。--debug-file <path> を付けると、ログを指定のファイルに書き出せます。--debug や /debug を使う場合の出力先は、既定で ~/.claude/debug/<session-id>.txt です。CLAUDE_CODE_DEBUG_LOGS_DIR で変更できます。

claude --debug-file ./auth.log
grep -n "Could not resolve" ./auth.log

対話・-p・Agent SDKの実行では、このエラー文字列がデバッグログに書かれます。見つかったら、Not logged in の対処(/login・環境変数の確認・apiKeyHelper)に進みます。バックグラウンドセッションについては、claude logs <id> で直近の端末出力を表示できます。<id> は claude --bg が表示する短いIDです。Agent SDK経由の場合は、SDKを呼び出すプロセスに資格情報が渡っているかを確認します。

v2.1.287で claude --debug-file ./auth.log auth status を試したところ、出力は19行で、設定ファイルの読み込み(存在しない .claude/settings.json の通知など)が中心でした。認証の失敗は含まれません。失敗の記録を得るには、失敗する実行そのものにフラグを付ける必要があります。

よくある質問

apiKeyHelper を設定していても起きますか

起きる経路があります。apiKeyHelper は、クラウドセッションとClaude Desktopでは呼ばれません。ローカル(CLI)でスクリプトが失敗した場合は、Your apiKeyHelper script is failing という別のエラーになります。対処は、スクリプトの終了コードや出力の空を見る手順です。このエラーが出ているなら、apiKeyHelper の失敗ではなく、ワーカーに資格情報が届いていない側を先に疑います。

/status では何が確認できますか

/status は、いまのセッションで有効な資格情報を表示します。確認できるのは、そのシェルとそのプロセスの環境だけです。バックグラウンドジョブやCIが別の環境変数で動いているなら、対話セッションの /status が正常でも、失敗側が正しいとは限りません。失敗する側と同じ環境で /status を実行して比べます。

まとめ

このエラーは、バックグラウンドセッション・クラウドセッションのワーカーが資格情報を持たずに起動したことを示します。バージョンがv2.1.176以上なら、疑う先はスーパーバイザーとその起動環境です。SDKやCIで見つけた場合は、デバッグログ上の文字列なので Not logged in として追い、失敗している環境そのもので確認します。