Claude Codeのログイン7手順｜できない時の直し方【2026年9月】

Claude Codeのログインを7手順で整理。/loginが効かない時の認証優先順位、ANTHROPIC_API_KEYの残留、期限切れの再ログイン、WSL2やCIでの認証、macOSのKeychain復旧を公式情報で確認。

2026年9月27日時点の結論。ログインの相談で一番多いのは「ログインできない」ではなく「ログインしたのに反映されない」だ。原因はほぼ決まっていて、環境変数の ANTHROPIC_API_KEY が残っているとそれがサブスクのログインより優先されるため、/login を何度やっても認証元が変わらない。だからまず /status で「いま何で認証しているか」を見る。ここを飛ばして /logout と /login を繰り返すのが一番遠回りになる。ブラウザが開かないなら c を押してURLをコピー、リダイレクトが戻ってこないなら表示されたコードを端末に貼る、CIならブラウザを使わず claude setup-token で発行したトークンを使う。macOSで毎回ログインを求められるならKeychainが書けていない。

公式ドキュメントは認証情報の優先順位を7段階で明記しており、クラウドプロバイダの設定が最優先、/login で保存したサブスクのログインが最下位だと書いている（Anthropic「Authentication」Authentication precedence（2026年9月確認））。つまり /login は「最も弱い認証情報」を書き換えるコマンドだ。この構造を知っているかどうかで切り分けの速さが変わる。

この記事の要点

最初にやること：/status を開いて、どの認証情報が有効かを見る。API key や Auth token の行が出ていれば、/login ではその状態は変わらない。
優先順位：クラウドプロバイダ → ANTHROPIC_AUTH_TOKEN → ANTHROPIC_API_KEY → apiKeyHelper → CLAUDE_CODE_OAUTH_TOKEN → プロファイル → /login のログイン、の7段。
初回ログイン：ブラウザが自動で開かないときは c でURLをコピーする。リダイレクトが戻らない環境では、ブラウザに出たコードを Paste code here if prompted に貼る。
期限切れ：期限の3日前に警告が出る。実際に切れると Login expired · Please run /login になり、モデルへのリクエストは送られずローカルで止まる。
保存先：macOSは暗号化されたKeychain、LinuxとWindowsは .credentials.json（Linuxはファイルモード 0600）。macOSでKeychainが書けないとLinuxと同じ平文ファイルに落ちる。
ブラウザが無い環境：claude setup-token で一年有効のトークンを発行し、CLAUDE_CODE_OAUTH_TOKEN に入れる。回転する資格情報なら apiKeyHelper。
対象読者：Claude CodeをCLIやIDE拡張で使っている開発者、チームの認証方式を決める開発リード、CIに組み込む担当者。
今日やること：/status を開いて認証元を1回確認する。API key の行が出ていたら、その場で env | grep ANTHROPIC を実行する。ここで原因が判明するケースが一番多い。

前提｜まず /status で認証元を確かめる

ログインの不調は「認証情報が無い」ケースと「別の認証情報が勝っている」ケースに分かれる。この2つは症状が似ているのに対処が正反対なので、最初に切り分ける。/status はバージョン、モデル、アカウント、接続状態を表示する画面で、Claudeが応答している最中でも開ける（Anthropic「Slash commands」/status（2026年9月確認））。

/statusに出る5つの行で認証元を判別する

/status で見る5つの行

認証まわりで見る行は次のとおり。どの行が出るかは、いま何で認証しているかで変わる。

/status の行	出る条件と読み方
`Login`	保存済みのclaude.aiまたはClaude Consoleのログインが有効な認証情報のとき。期限切れで更新できない状態では `Expired — log in again` と、保存していた組織とメールアドレスが出る
`API key`	`ANTHROPIC_API_KEY` を承認済みで、それが使われているとき。使われていない旨の印が付いていなければ、これが有効な認証情報
`Auth token`	`CLAUDE_CODE_OAUTH_TOKEN` で認証しているとき。行に変数名が出る
`apiKeyHelper`	`apiKeyHelper` 設定が有効な認証情報のとき。スクリプトが失敗していれば `Failing` と直近の失敗の詳細が出て、次に成功すると消える
`Profile`	Anthropicプロファイル（キーを作らないConsoleサインインや `ant auth login` が書いたもの）で認証しているとき

Login 行は2.1.210以降、apiKeyHelper 行の失敗表示は2.1.274以降で出る。古いバージョンでは期限切れの表示そのものが出ないため、ここで何も分からない場合はまずバージョンを確認する。2026年9月27日時点の最新は2.1.283だ（anthropics/claude-code「CHANGELOG.md」2.1.283（2026年9月27日確認））。

非対話で確認したいときは claude auth status を使う。認証状態をJSONで出し、--text で人間向けの表示になる。終了コードはログイン済みで0、未ログインで1なので、CIの事前チェックにそのまま使える（Anthropic「CLI reference」claude auth status（2026年9月確認））。2.1.268で claude auth status --json の出力に configDirectory が追加され、どの設定ディレクトリの認証情報を見ているかも分かるようになった。

手順1｜初回ログインを通す

インストール後に claude を実行すると、初回はブラウザが開いてログイン画面に進む。ANTHROPIC_API_KEY を設定済みの場合はログインのプロンプトを飛ばし、そのキーを承認するかどうかを聞かれる。ログインが完了すると端末に Login successful と出て、Enterで続行する（Anthropic「Authentication」（2026年9月確認））。

選べるアカウントの種類

ログイン画面で選ぶ選択肢は、契約形態によって意味が変わる。

選択肢	使う人
Claude account with subscription	Claude ProまたはMaxの契約者。claude.aiのアカウントでログインする
Anthropic Console account	Claude Consoleの利用者。管理者に招待されている必要がある。APIキーを作る経路と作らない経路がある
3rd-party platform	Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryを使う組織。BedrockとVertex AIは対話形式のセットアップウィザードが起動する
Cloud gateway	自社でClaude appsゲートウェイを運用している組織。社内SSOでサインインし、ゲートウェイが発行したトークンがそのセッションの唯一の認証情報になる

Consoleアカウントは、APIキーを作らずにサインインする経路が2.1.242以降で選べる。(recommended) と表示されるほうがOAuthトークンをAnthropicプロファイルとして保存する経路で、APIキーは作られない。(legacy) と表示されるほうはConsoleのAPIキーを作って他の認証情報と一緒に保存する。前者は自動で更新され、更新に失敗すると Anthropic profile login expired でリクエストが失敗する。キーを作らないサインインを使うときは、事前に ANTHROPIC_API_KEY を解除しておく。

ブラウザが開かない、リダイレクトが戻らない

ブラウザが自動で開かないときは c を押すとログインURLがクリップボードにコピーされるので、ブラウザに貼る。SSHの狭い端末でURLが折り返してクリックできない場合もこれで通る。

サインイン後にブラウザがログインコードを表示してリダイレクトが戻ってこない場合は、そのコードを端末の Paste code here if prompted に貼る。これはブラウザがClaude Codeのローカルのコールバックサーバーに到達できないときに起きる挙動で、WSL2、SSHセッション、コンテナでよく発生する。

OAuth error: Invalid code. Please make sure the full code was copied と出た場合は、コードの期限切れかコピペでの切り詰めだ。Enterでやり直し、ブラウザが開いてから手早く完了させる。リモートやSSHではブラウザが別のマシンで開いている可能性があるので、端末に表示されたURLを手元のブラウザで開く。

貼り付けても何も起きないときは、端末の貼り付けキーが入力欄に届いていない。Windows Terminalなら右クリックやShift+Insertといった代替の貼り付け操作を試す。それでも駄目なら claude auth login を使う。こちらは貼られたコードを標準入力から読むため、対話プロンプトへの貼り付けが効かない環境の回避策になる。

claude auth login

claude auth login には --email でメールアドレスを事前入力する、--sso でSSO認証を強制する、--console でサブスクではなくClaude Console（API利用課金）でサインインする、といったオプションがある。

手順2｜認証の優先順位を押さえる

ここが /login が効かないように見える原因の中心だ。複数の認証情報があるとき、Claude Codeは次の順で1つを選ぶ。上にあるものが勝つ。

クラウドプロバイダを最上段、/loginを最下段とする7段の階段で認証情報の優先順位を示した図 — 認証情報の優先順位は7段で、/loginが最下段

優先順位の7段

順位	認証情報	補足
1	クラウドプロバイダ	`CLAUDE_CODE_USE_BEDROCK`、`CLAUDE_CODE_USE_VERTEX`、`CLAUDE_CODE_USE_FOUNDRY` のいずれかが設定されているとき
2	`ANTHROPIC_AUTH_TOKEN`	`Authorization: Bearer` ヘッダで送られる。ベアラトークンで認証するLLMゲートウェイやプロキシ経由のとき
3	`ANTHROPIC_API_KEY`	`X-Api-Key` ヘッダで送られる。対話モードでは一度承認を聞かれ、その選択が記憶される。非対話モード（`-p`）では設定されていれば常に使われる
4	`apiKeyHelper`	スクリプトの出力。Vaultから取る短命トークンなど、回転する資格情報向け
5	`CLAUDE_CODE_OAUTH_TOKEN`	`claude setup-token` で発行した長期トークン。ブラウザログインができないCIやスクリプト向け
6	Anthropicプロファイルとフェデレーション資格情報	`ant` CLIやWorkload Identity Federationが使う認証情報
7	`/login` のサブスクOAuth認証情報	Pro、Max、Team、Enterpriseの既定

Claude appsゲートウェイにサインイン済みのセッションはこの一覧の外側にあり、BedrockやVertexと同じ「プロバイダの選択」として、それらより上に立つ。ゲートウェイのセッションがある間は、ベアラトークンやAPIキー、apiKeyHelper、プロファイルは使われない。

古いAPIキーが残っているとサブスクが無効になる

ANTHROPIC_API_KEY は /login のログインより優先される。前職や別プロジェクトのキーがシェルのプロファイルに残っていると、有効なProやMaxの契約があってもそのキーが使われる。無効化された組織のキーだった場合は API Error: 400 ... This organization has been disabled や Your ANTHROPIC_API_KEY belongs to a disabled organization が出る。ヒント文は保存済みのログインがあるかどうかで変わり、引き継げるログインがあれば「解除すればサブスクに切り替わる」旨、無ければ「更新するか解除しろ」という旨になる。

# macOS / Linux
unset ANTHROPIC_API_KEY
claude

# Windows PowerShell
Remove-Item Env:ANTHROPIC_API_KEY
claude

恒久的に消すには ~/.zshrc、~/.bashrc、~/.profile の export ANTHROPIC_API_KEY=... を削除する。Windowsでは $PROFILE のPowerShellプロファイルとユーザー環境変数を見る。

自分で設定した覚えがないのにキーが入っているケースもある。direnv、dotenv系のシェルプラグイン、IDEのターミナルが、プロジェクト内の .env から古いキーを読み込むことがあるためだ。疑うときは認証している当のシェルで次を実行する。

env | grep ANTHROPIC

Get-ChildItem Env:ANTHROPIC*

env や apiKeyHelper を設定ファイル側で入れている場合は、シェルを見ても出てこない。settings.json の env ブロックは全セッションに環境変数を効かせるので、そちらも確認する。置き場所の整理はClaude Code settings.json設定完全ガイド、キーそのものの管理はClaude Codeでの秘密情報・環境変数の管理にまとめてある。

apiKeyHelperがある間は /login が効かない

apiKeyHelper の出力は保存済みのログインより優先されるため、設定が残っている限り /login をしても状況は変わらない。スクリプトが失敗しているときは Your apiKeyHelper script is failing · This usually means you need to re-authenticate with your provider · Run /status to see the script's error output が出る。

Claude Codeは既定で5分ごとにこのスクリプトを再実行する。間隔は CLAUDE_CODE_API_KEY_HELPER_TTL_MS で変えられる。返すまでに10秒を超えると、経過時間つきの警告がプロンプトバーに出る。スクリプトがエラー終了する、タイムアウトする、何も出力しない、のいずれかだと、3回の試行のうちに上のメッセージが出る。スクリプトはキーだけを標準出力に出し、印字可能なASCIIの単一トークン（最大16,384文字）として、終了コード0で終わる必要がある。

手順3｜エラーメッセージから原因を引く

Claude Codeの認証エラーはメッセージが細かく分かれており、文面から原因がほぼ確定できる。すべて公式のエラーリファレンスに記載がある（Anthropic「Error reference」Authentication errors（2026年9月確認））。

メッセージと最初の一手の対応表

よく出るものを対応表にする。

メッセージ	状態	最初の一手
`Not logged in · Please run /login`	有効な認証情報が無い	`/login`。環境変数で認証させるつもりなら、`claude` を起動したシェルで変数がexportされているか確認
`Login expired · Please run /login`	保存済みログインの更新が拒否され、Claude Codeが認証情報を消した状態。リクエストはAPIに届く前にローカルで止まる	`/login`。再ログインしない限り毎回同じ表示になる
`OAuth token revoked · Please run /login`	APIが返した拒否。どこかで全ログアウトしたか、管理者が権限を外した	`/login`。同一セッション内で再発するなら `/logout` してから `/login`
`Invalid API key · Fix external API key`	`ANTHROPIC_API_KEY` か `apiKeyHelper` が返したキーをAPIが拒否した、または送信前にClaude Codeが止めた	Consoleでキーの失効を確認。または変数を解除して `/login`
`API Error: 401 Invalid authentication credentials`	資格情報の形式は通ったが、その裏のアカウントや組織が拒否された。失効直後、組織の無効化、アカウントの停止で出る	`/status` でどちらが有効かを見てから、キーの回転か再ログインを選ぶ
`Could not refresh your login because another Claude Code process is refreshing it`	同一マシンの別プロセスが共有の更新ロックを持っている、または更新途中で終了した	1分待って再試行。続くなら他のClaude Codeウィンドウを閉じる。それでも駄目なら `/login`
`Couldn't save your login. If your Mac's keychain is locked, unlock it and log in again.`	サインインはできたが認証情報を保存できず、ログインが完了しなかった	Keychainをロック解除して `/login`
`Your organization has disabled API key authentication`	組織の管理者がAPIキー認証を切った	メッセージが名指しした `ANTHROPIC_API_KEY` か `apiKeyHelper` を外してから `/login`
`Your organization has disabled Claude subscription access for Claude Code`	サーバ側の組織設定。ローカル設定や環境変数では上書きできない	ConsoleのAPIキーで認証する、または管理者に有効化を依頼
`Claude login not accepted · Run /login, then try again`	クラウドセッションの作成をサーバが401で拒否した	`/login` を完了してからセッションを開始

Login expired と OAuth token revoked は似ているが別物だ。前者はClaude Code自身が「更新に失敗したログイン」に対して出すのでリクエストを送らない。後者はAPIが返した拒否だ。更新が失敗した理由がアカウントの停止である場合は、代わりに Your account is on hold and can't use Claude Code. が出る。

なお2.1.206より前は、期限切れのログインでもリクエストをそのまま送っていたため、モデル側のエラーや401として現れていた。メッセージで原因を引く前提が成り立つのは2.1.206以降だ。

403 Forbiddenが出る場合

ログイン自体は通ったのに API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}} が出る場合は、認証ではなく権限や経路の問題だ。ProやMaxなら契約が有効かをclaude.aiの設定で確認する。Consoleの利用者なら、アカウントに「Claude Code」または「Developer」のロールが付いているかを管理者に確認する。プロキシの背後にいる場合は、社内プロキシがAPIリクエストに干渉している可能性がある。

サインインのページ側で Authorization failed と Claude Code access has not been granted for this account. Contact your administrator. が出る場合は、Claude Enterpriseの組織でロールがCustomになっており、所属グループに割り当てられたカスタムロールのどれもClaude Codeを許可していない状態だ。Claude Code側で何を変えても解決しないため、組織のOwnerにロールの変更を依頼する（Anthropic Support「Custom roles」（2026年9月確認））。

手順4｜期限切れと再ログイン

/login で作ったログインには期限がある。切れる前に警告が出るので、そこで更新しておくのが一番安い。

期限が近い状態からLogin expiredを経て/loginに至る流れと、OAuth token revokedも/loginに合流することを示した図 — 期限が近い状態から再ログインまでの流れ

期限が近いときの警告

期限まで3日以内になると、起動時に Your login expires in 3 days · run /login to renew という警告が出る。2.1.203以降の挙動で、2.1.217より前は5日前から出ていた。この警告は情報提供で、リクエストを止めることはない。実際に期限が切れるまで認証は動き続ける。警告が出るのはclaude.aiまたはClaude Consoleのログインが有効な認証情報のときだけで、クラウドプロバイダや環境変数、apiKeyHelper で認証している場合は出ない。

早めに更新する意味が大きいのは、人が見ていないセッションだ。エージェントビューのバックグラウンドセッションやRemote Controlのセッションは、ログインの期限を越えると進行が止まり、サインインし直すまで復帰できない（Claude Code Remote Control活用ガイド）。

何度もログインを求められるとき

セッションをまたいで繰り返しログインを要求される場合、確認する点が2つある。1つはシステムの時刻だ。トークンの検証は正しいタイムスタンプに依存するため、時計がずれていると失敗する。もう1つはmacOSの認証情報の保存先で、これは手順5で扱う。

同一マシンの並列セッションは保存済みのログインを共有し、更新を1プロセスだけが行うよう調整する。2.1.211より前は、スリープからの復帰で2つのセッションが同じトークンで更新してしまい、保存済みログインが失効して開いている全セッションが一斉に再ログインを求める事象があった。2.1.282では、別プロセスが更新途中で閉じられたり強制終了された後に、最大1分間リクエストが失敗する不具合も直っている。

CLAUDE_CODE_OAUTH_TOKENを使っている場合

CLAUDE_CODE_OAUTH_TOKEN で認証している場合、401でリクエストが失敗しても、Claude Codeは設定された値を送り続ける。保存済みログインのトークンに切り替わることはない。/status ではこの認証情報が Auth token 行として表示される。claude setup-token で新しいトークンを発行して入れ替えるか、変数を解除して /login する。

2.1.225より前は、セッションの途中でこの変数の値を保存済みログインの短命アクセストークンに置き換えてしまい、そのトークンが切れた時点で再び401が続く挙動だった。

手順5｜認証情報の保存先とKeychainの復旧

保存先を知らないと、macOSで毎回ログインを求められる現象の原因が見えない。

Keychainが書けない状態で平文の.credentials.jsonに落ちる左側と、Keychainへ戻した右側を対比し、claude doctorとsecurity unlock-keychainを添えた図 — 平文ファイルに落ちた認証情報をKeychainへ戻す

OSごとの保存先

OS	保存先
macOS	暗号化されたmacOS Keychain。Keychainが書き込みを拒否した場合はLinuxと同じ `~/.claude/.credentials.json`（ファイルモード `0600`）に保存される
Linux	`~/.claude/.credentials.json`（ファイルモード `0600`）
Windows	`%USERPROFILE%\.claude\.credentials.json`。ユーザープロファイルディレクトリのアクセス制御を継承し、既定では自分のユーザーアカウントに限定される

CLAUDE_CONFIG_DIR を設定している場合、.credentials.json はそのディレクトリ配下に置かれる。macOSのフォールバックが書くファイルも同じで、Keychainのエントリもそのディレクトリをキーにするため、CLAUDE_CONFIG_DIR が違うセッションは別のエントリを読む。認証情報が突然見つからなくなったときは、この変数が意図せず変わっていないかを確認する。.credentials.json は /login と /logout が管理するファイルなので、手で編集しない。APIのエンドポイントを変えたいだけなら ANTHROPIC_BASE_URL を使う。

Keychainが書けない状態を直す4手順

SSHセッションでKeychainがロックされている、Keychainのパスワードがアカウントのパスワードとずれている、といった場合にKeychainが書き込みを拒否する。このとき認証情報は平文の ~/.claude/.credentials.json に落ちる。APIキーを作るConsoleログインは、Keychainが書けるようになるまで失敗する。次の順で戻す。

claude doctor を実行してKeychainのアクセスを確認する。拒否されているときは macOS Keychain is not writable で始まる警告と推奨の対処が出る。警告が無ければKeychainは書けているので、4番へ飛ぶ。
Keychainのロックを解除する。

security unlock-keychain ~/Library/Keychains/login.keychain-db

パスワードを入力したら claude doctor を再実行し、警告が消えたかを見る。

解除しても直らない場合はパスワードを同期する。キーチェーンアクセスを開き、login キーチェーンを選んで「編集 > キーチェーン”login”のパスワードを変更」でアカウントのパスワードに合わせる。再度 claude doctor で警告が消えたことを確認する。
/logout してから /login する。Keychainが書ける状態になれば、次に認証情報を書く時点で自動的にKeychainへ戻るが、すぐに反映させたいときはこの操作を行う。

手順4の /logout は、保存済みの認証情報をすべて消す。平文ファイルの中身、保存済みのMCPサーバーのログイン、プラグインの機微な値も対象なので、後でMCPサーバーの再認可とプラグインの秘密情報の再入力が必要になる。/logout は初回起動時のセットアップ状態もリセットするため、次に claude を実行するとログインとセットアップを最初から通ることになる。

Keychainのロックに関連して、2.1.281では、ログインKeychainがロックされている状態（スリープ復帰直後など）でmacOSの認証情報を書いたときに、保存済みのMCP OAuthトークンが失われる、あるいはKeychainのエントリが削除される不具合が直っている。この症状に当たっていた環境は、更新するだけで解消する。更新の手順そのものはClaude Codeの課金判定と/statusの読み方で扱っている確認項目と合わせて回すと早い。

手順6｜WSL2・SSH・コンテナ・CIで認証する

ブラウザが同じマシンに無い環境では、初回ログインの前提が崩れる。3通りの逃げ道がある。

CIからブラウザが無いという分岐を経て、claude setup-tokenとapiKeyHelperの2経路に分かれ、前者がCLAUDE_CODE_OAUTH_TOKENにつながることを示した図 — ブラウザが無い環境での2つの認証経路

ブラウザが別マシンにある場合

WSL2、SSH越しのリモートマシン、コンテナでは、ブラウザが別のホストで開き、そのリダイレクトがClaude Codeのローカルのコールバックサーバーに届かない。サインイン後にブラウザがログインコードを表示するので、それを端末の Paste code here if prompted に貼る。

WSL2でブラウザがまったく開かない場合は、BROWSER 環境変数にWindows側のブラウザのパスを設定する。

export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
claude

あるいは対話ログイン画面で c を押してURLをコピーする、または claude auth login が表示するURLをコピーして手元のブラウザで開く。Windows側の環境構築全般はClaude Code Windows導入7手順にまとめてある。

CIやスクリプトで認証する

対話的なブラウザログインができない環境では、claude setup-token で一年有効のOAuthトークンを発行する。

claude setup-token

/login と同じブラウザ認可フローが開き、ブラウザでアクセスを承認するとトークンが端末に表示される。このコマンドはトークンをどこにも保存しないので、コピーして認証させたい場所の CLAUDE_CODE_OAUTH_TOKEN に設定する。

export CLAUDE_CODE_OAUTH_TOKEN=your-token

このトークンはサブスクで認証するため、Pro、Max、Team、Enterpriseのいずれかの契約が必要だ。モデルへのリクエストしかできないので、Remote Controlのセッションを確立したり、claude.aiのコネクタを取得したりはできない。ローカルに設定したMCPサーバーは引き続き動く。ベアモード（--bare）はこの変数を読まないため、--bare を使うスクリプトでは ANTHROPIC_API_KEY か apiKeyHelper で認証する。非対話実行の組み立て方はClaude Codeのヘッドレス自動化とSDK活用で扱っている。

claude setup-token と /install-github-app は forceLoginMethod だけを適用し、forceLoginOrgUUID を適用しない点に注意する。別の組織でトークンを発行できてしまうため、組織を固定したい場合はこの経路を管理対象に含める必要がある。

バックグラウンドセッションで認証情報が見つからない場合

Could not resolve authentication method. Expected one of apiKey, authToken, credentials, config, or profile to be set. は、セッションが認証情報なしでAPIクライアントに到達した状態だ。バックグラウンドセッションとクラウドセッションで、ワーカーが認証情報なしに起動したときに出る。対話実行や -p、Agent SDKでは同じ状態を Not logged in として報告し、この文字列はデバッグログにだけ書く。

まず確認するのは、変数が「対話シェル」ではなく「ワーカーを起動する環境」に設定されているかだ。加えて、2.1.174より前はアイドルの事前初期化ワーカーに割り当てられたバックグラウンドセッションが、正しい認証情報があってもこの形で失敗することがあった。2.1.176より前はクラウドセッションでも同様だった。該当するなら更新で解消する。

IDE拡張で認証が通らないのに端末では通る場合は、IDEのプロセスがシェルの環境を継承していないことが多い。IDE側の設定に変数を入れるか、変数をexportした端末からIDEを起動する。devcontainerでの取り回しはClaude Code devcontainerのチーム導入にまとめた。

手順7｜組織の設定で止められている場合

個人の設定をいくら直しても通らないケースがある。判断のために、組織側で効く設定を押さえておく。

forceLoginMethodとforceLoginOrgUUID

管理者は管理設定（managed settings）で forceLoginMethod と forceLoginOrgUUID を指定し、開発者のログイン方法と所属組織を固定できる。forceLoginOrgUUID に組織IDを入れると、別組織のclaude.aiログインではエラーになり、起動時に終了する。forceLoginOrgUUID をどこかの設定ファイルに入れると、キーを作らないConsoleサインインの提示が止まり、APIキーを作る経路になる。claude.aiのサインインに寄せたいなら forceLoginMethod を "claudeai" にする。

2.1.212以降は端末ログイン、VS Code拡張、Agent SDK、claude setup-token、/install-github-app、ゲートウェイサインインのすべての経路で forceLoginMethod が適用される。2.1.212より前は端末ログインだけだった。端末の対話ログイン画面では claudeai か console を事前選択するだけで強制はしないため、forceLoginMethod を "claudeai" にしていても開発者がConsoleログインを完了できる点は残る。

環境由来の認証情報は組織の所属を検証できないため、forceLoginOrgUUID が入っていると ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、apiKeyHelper のセッションは起動時にブロックされる。一方、Bedrockなどクラウドプロバイダのセッションはクラウド側で認証するためブロックされない。この線引きを知らずにCIを組むと、ローカルでは動いたのに配布先で起動しない構成になる。管理設定の配布そのものはClaude Codeの組織ガバナンスと管理設定を参照。

ゲートウェイサインインを要求されている場合

管理設定が forceLoginMethod を "gateway" にしている、または forceLoginGatewayUrl を設定している場合、Claude appsゲートウェイのサインインしか受け付けない。ゲートウェイのサインインが無いセッションでは Not signed in to the Cloud gateway — run /login. でモデルへのリクエストが失敗する。ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、apiKeyHelper を設定していて管理設定が forceLoginMethod を指定している場合は、起動時に「管理者のポリシーがゲートウェイサインインを要求しており、ここに設定されたAnthropic発行の認証情報は使われない」という趣旨のメッセージで終了する。

2.1.265では、管理者の要求が無いマシンでも、一部のLLMゲートウェイやプロキシ構成で前者のメッセージが出る回帰があった。2.1.266以降に更新すれば直り、構成の変更は要らない。ゲートウェイ経由の運用設計はClaude Codeのゲートウェイと支出上限の設計で扱っている。

想定の場面｜前職のキーが残ったまま新環境に入る

ここからは想定の場面だ。実在の組織や案件ではない。新しく参加した開発者が、以前の職場で使っていたdotfilesをそのまま持ち込み、~/.zshrc に export ANTHROPIC_API_KEY=... が残っているとする。会社のMaxプランでログインしても、/login は成功するのに毎回 This organization has been disabled でリクエストが落ちる。/status を開けば API key の行が出ているので、そこで原因が確定する。unset ANTHROPIC_API_KEY と .zshrc の該当行の削除で解決する。オンボーディングのチェックリストに「env | grep ANTHROPIC が空であること」を1行入れておくと、この種の相談は消える。

よくある失敗と対処

認証元の取り違え

/login を何度もやり直す：環境変数か apiKeyHelper が勝っている間は何度やっても変わらない。先に /status を見る。
シェルだけ確認して終わる：settings.json の env ブロックと .env ファイルからも変数が入る。両方見る。
非対話モードで挙動が変わる：-p では ANTHROPIC_API_KEY が設定されていれば常に使われる。対話で承認を断っていても関係ない。

保存とKeychainの失敗

毎回ログインを求められる：システム時刻のずれか、Keychainが書けていない。claude doctor で確認する。
.credentials.json を手で編集する：このファイルは /login と /logout が管理する。壊すと再ログインが必要になる。
CLAUDE_CONFIG_DIR が違うシェルで起動している：別のKeychainエントリと別のファイルを読むため、ログイン済みに見えない。

遠隔環境での失敗

ローカルのブラウザでURLを開いていない：SSHではリモート側でブラウザが開こうとする。c でコピーして手元で開く。
対話プロンプトへの貼り付けが効かない：claude auth login を使う。標準入力からコードを読む。
CIに --bare を使いつつ CLAUDE_CODE_OAUTH_TOKEN を渡している：ベアモードはこの変数を読まない。ANTHROPIC_API_KEY か apiKeyHelper にする。

よくある質問

いま何で認証しているか、確認する最短の方法は

/status を開く。Login、API key、Auth token、apiKeyHelper、Profile のどの行が出ているかで分かる。非対話なら claude auth status を使う。ログイン済みなら終了コード0、未ログインなら1で返る。

/login したのに認証が切り替わりません

ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、apiKeyHelper のいずれかが残っている。これらは保存済みログインより優先される。変数を解除し、apiKeyHelper は settings.json から設定を外してから /login する。

ブラウザが開かないときはどうしますか

c を押すとログインURLがクリップボードにコピーされる。ブラウザにログインコードが表示された場合は、それを Paste code here if prompted に貼る。貼り付けが効かない端末では claude auth login を使う。

Login expired と OAuth token revoked は何が違いますか

Login expired はClaude Codeが保存済みログインの更新に失敗して認証情報を消した状態で、リクエストはAPIに届かない。OAuth token revoked はAPIが返した拒否だ。どちらも /login で復帰するが、後者が同一セッション内で再発する場合は /logout してから /login する。

macOSで毎回ログインを求められます

システム時刻のずれか、ログインKeychainが書けていない可能性が高い。claude doctor で macOS Keychain is not writable の警告が出るかを見て、security unlock-keychain ~/Library/Keychains/login.keychain-db で解除する。直らなければキーチェーンアクセスでパスワードを同期する。

CIでブラウザログインができません

claude setup-token で一年有効のトークンを発行し、CLAUDE_CODE_OAUTH_TOKEN に設定する。回転する資格情報を使うなら apiKeyHelper でVaultから取得する形にする。--bare を使う場合はこの変数が読まれないため、ANTHROPIC_API_KEY か apiKeyHelper を使う。

管理者にログイン方法を固定されているか確認できますか

forceLoginMethod や forceLoginGatewayUrl が管理設定に入っている場合、ゲートウェイのサインイン画面しか出ない、あるいは起動時に「管理者のポリシーがゲートウェイサインインを要求している」という趣旨のメッセージで終了する。環境の認証情報を設定していると起動時にブロックされることもあるため、管理者に設定内容を確認する。

/logout すると何が消えますか

保存済みの認証情報がすべて消える。平文の .credentials.json の中身、保存済みのMCPサーバーのログイン、プラグインの機微な値も対象だ。初回起動時のセットアップ状態もリセットされるため、次に claude を実行するとログインとセットアップを最初から通ることになる。