結論：再インストール前に認証の層を分ける
Claude Codeにログインできない時は、再インストールや認証情報の再発行を繰り返す前に、エラー、認証方式、対象組織、ブラウザー、ネットワーク、端末の順で切り分けます。同じ「ログインできない」でも、サインイン期限、APIキー、組織ポリシー、プロキシでは対処が違うためです。
画面を閉じる前に、エラー全文、発生時刻、最後に成功した時刻、Claude Codeの版、OS、利用アカウント、対象組織を記録してください。APIキーやOAuthトークンは記録・共有しません。この記事は、個人利用者が次の一手を判断し、管理者が再現条件を受け取るための手順です。
まず症状と公式サービス状態を固定する
最初に「誰が、いつ、どの環境で失敗したか」を一行にします。自分だけならアカウント・端末・ブラウザーを、複数人なら組織設定・ネットワーク・サービス状態を先に疑います。直前のSSO変更、組織切替、APIキー更新、端末交換、VPNやプロキシ変更も一つずつ記録します。
Anthropicの公式ステータスでClaude Code、Claude Console、claude.aiの状態を確認します。障害中なら試行を増やさず、発生時刻と公式表示を保存します。復旧後にログインできても、端末設定が原因だったと断定せず「公式障害と一致」と記録します。
認証方式を比較して正しい入口を選ぶ
公式Authenticationでは、Claude Codeの認証経路として、claude.aiのPro・Max・UltraやTeams・Enterprise、Claude Console、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryなどが案内されています。会社が指定した方式と違う入口を選ぶと、契約があっても対象組織へ入れません。
- claude.ai：個人契約または招待されたTeams・Enterpriseのアカウントでログインします。
- Claude Console：Consoleの認証情報を使い、管理者から招待されているか確認します。
- クラウド基盤：組織指定の環境変数や認証を先に設定し、ブラウザー認証が不要な方式かを確認します。
- APIキー：ANTHROPIC_API_KEYの参照先と発行元を管理者が照合し、キーの値は表示・共有しません。
利用者側で方式を勝手に切り替えて制限を回避するのではなく、契約、席、役割、組織ポリシーを管理者へ確認します。導入手順の全体はClaude Codeのインストール方法も参照してください。
現行の公式ログインフローで再確認する
初回起動ではブラウザー認証が基本ですが、ANTHROPIC_API_KEYを設定して利用を承認した場合や、先にclaude auth loginを実行した場合はログイン画面を省略できます。ブラウザーが開かない時は、画面の案内でログインURLをコピーし、認証後に表示されたコードを端末へ貼り付けます。
Claude Consoleでは、現行の案内に従うとv2.1.242以降で「Consoleアカウントでサインイン（推奨）」と「APIキーを作成（legacy）」を選べます。前者は更新されるOAuthログインをAnthropic profileとして保存し、後者は静的なAPIキーを保存するため、同じ「ログインできない」でも確認対象が異なります。また、v2.1.290未満では既に認証済みでもセットアップ中に画面が出る挙動があるため、版を記録してから更新を判断します。
ログイン障害を9手順で切り分ける
- エラー全文、発生時刻、最後の成功時刻をそのまま記録する。
- Claude Codeの版、OS、CLI・VS Code・Desktopなどの起動面を固定する。
- 利用する認証方式と、ログイン先の組織・アカウントを確認する。
- 管理者に、招待、席、役割、Claude Code利用権、認証ポリシーを確認してもらう。
- OAuth profileの期限切れ・失効、APIキーの無効・参照先違いをエラー別に確認する。
- ブラウザーの別プロファイル、古いCookie、callback遮断、会社アカウントの取り違えを確認する。
- DNS、プロキシ、VPN、TLS、ファイアウォール、許可ドメインを確認する。
- 端末時刻と証明書を確認し、正しい経路で一度だけ再認証する。
- 解決しなければ秘密値を除いた再現手順、ログ、試行履歴を管理者へ渡して止める。
公式Authenticationでは、初回起動時にブラウザーでログインし、ブラウザーが自動で開かない場合は画面の案内でログインURLをコピーし、コードが表示された場合は端末へ貼り付ける流れが説明されています。成功後に「Login successful」と表示されない、または別組織へ入る場合は、再試行回数を増やすより入口とアカウントを見直します。
エラー別に次の対応を決める
OAuth error・403 Forbidden：公式Troubleshoot installation and loginの認証項目と組織アクセスを確認します。契約や組織の許可がない時は個人アカウントへ移らず、管理者へ渡します。
Access has not been granted：Claude Codeを利用できる役割が付いているかを管理者が確認します。権限不足を広い権限のキーへ置き換えて解決しません。
API Error・401・Invalid API key：キーの値を表示せず、発行元、期限、環境変数名、実行シェル、対象組織だけを照合します。古いシェルに残った値と新しい値の混在も、一度に一項目ずつ確認します。
ブラウザーが戻らない・通信エラー：公式Troubleshootではプロキシ、ファイアウォール、TLS、地域制限、接続性を確認する案内があります。会社ネットワークだけで失敗するなら、許可ドメインとプロキシ設定をIT担当へ渡し、証明書検証を無効化する回避は行いません。
ログイン画面が繰り返し表示される時
公式Authenticationは、以前のサインインの期限切れ、管理者が指定した組織、管理者が要求した認証方式、古いClaude Codeの版を原因候補として挙げています。まず正しいアカウントで再認証し、それでも続くなら管理者のforceLoginOrgUUIDやforceLoginMethodなどの設定、アカウントの所属、利用版を確認します。
複数アカウントを使う場合は、公式案内に従い、アカウントごとに設定ディレクトリを分ける方法があります。ただし会社のmanaged settingsや認証ポリシーを利用者側で上書きする話ではありません。ログアウトしてやり直す時も、共有端末ではアカウントを取り違えないようにします。
復旧後のチェックリストと停止条件
- 正しい組織名、認証方式、契約・席・役割が表示されている。
- 新しいターミナルまたは指定の起動面でも、同じアカウントで再現する。
- 会社指定のネットワークとブラウザープロファイルでログインできる。
- APIキー、OAuthトークン、Cookie、Authorizationヘッダーを記録・共有していない。
- エラー、原因、修正担当、復旧時刻、再発時の連絡先を残している。
短時間に認証を繰り返して制限が強まった、管理者不在で組織ポリシーを確認できない、認証情報の漏えいが疑われる場合は止めます。漏えいの可能性がある場合は、復旧より先に社内手順に従って失効と影響範囲を確認します。権限の設計はClaude Codeの権限設定、企業の運用整理はClaude Code企業導入チェックリストにつなげて確認できます。
よくある質問
Claude Codeにログインできない時、最初に何を確認しますか？
エラー全文、発生時刻、最後に成功した時刻、Claude Codeの版、認証方式、対象組織を記録し、公式ステータスを確認します。再インストールはその後です。
ログイン画面が何度も表示される時はどうしますか？
以前のサインインの期限、管理者が指定した組織や認証方式、Claude Codeの版を確認し、必要なら正しいアカウントで再認証します。組織設定は管理者へ渡します。
ログイン障害でAPIキーを記事やチケットに貼ってもよいですか？
貼ってはいけません。APIキー、OAuthトークン、Cookie、Authorizationヘッダーを伏せ、秘密値を除いた再現手順だけを共有します。
公式情報を確認して無料診断へ
認証の入口とログイン手順はAnthropic公式Authentication、エラー別の導入・ログイン切り分けは公式Troubleshoot installation and login、サービス状態は公式ステータスで公開直前にも確認してください。仕様や画面は更新されるため、この記事の手順と公式一次情報が異なる場合は公式情報を優先します。
ログイン復旧後も同じ停止が起きるなら、Miraigentの無料診断でアカウント、組織、権限、ネットワーク、担当者の境界を整理できます。