結論：まず2.1.266以降か、Gatewayを選ぶ設定があるかを確認する
「Not signed in to the Cloud gateway」と表示された時は、いきなり再ログインせず、claude --version、CLAUDE_CODE_USE_GATEWAY、ANTHROPIC_BASE_URL、認証ヘルパーと管理設定の順で切り分けます。
公式changelogでは、2.1.265でGateway用環境変数の回帰が入り、APIキー、apiKeyHelper、カスタム認証ヘッダーを使う環境でもCloud gatewayへのサインイン要求が出る場合がありました。2.1.266で、CLAUDE_CODE_USE_GATEWAY単独では強制しない挙動へ戻っています。versionと認証経路を固定して一つずつ再現するのが安全です。
一次情報はClaude Code公式changelogと公式Authenticationです。前者は2.1.265と2.1.266の回帰・修正、後者はClaude.ai、Console、クラウドプロバイダー、self-hosted Claude apps gatewayの認証方式を説明しています。機密値そのものをログへ貼らず、変数名と設定の所在だけを記録してください。
APIキーとCloud gatewayは別の認証経路
| 経路 | 利用条件 | 最初に見る場所 |
|---|---|---|
| Claude.ai / Teams / Enterprise | ブラウザまたは組織ログイン | /login、組織招待、管理ポリシー |
| Claude Console / API | APIキーまたはヘルパー | キーの有無、endpoint、helperの終了状態 |
| Cloud provider | Bedrock等の環境変数・設定 | provider選択とregion・権限 |
| Claude apps gateway | 組織SSOとGateway発行token | 管理設定のGateway URLとログイン方式 |
認証文書上、APIキーが設定されていれば初回ログインをスキップしてキーの承認へ進みます。一方、self-hosted Cloud gatewayは企業SSOでログインし、Gateway発行tokenがsessionの認証情報です。両者を同じ経路として扱うと、APIキーを直したつもりでGatewayへ送られる、または組織の経路を回避する事故につながります。
7手順：Gateway認証エラーを再現可能な状態にする
claude --versionの結果、端末、実行時刻を記録し、2.1.265のままなら更新可否を確認します。- shell、CI、IDE、managed settingsのそれぞれで、Gateway関連の環境変数名だけを一覧化します。値やtokenは記録しません。
CLAUDE_CODE_USE_GATEWAY、ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、apiKeyHelperの設定元を分けます。- 一つのテスト用sessionで、APIキー経路かGateway経路かを明示し、同時に複数の認証設定を試しません。
- Gateway利用ならSSO、Gateway URL、管理者が指定したscopeを確認し、APIキー利用ならendpointとhelperの終了状態を確認します。
- 修正後は同じproject、同じversion、同じ操作を一度だけ再実行し、エラー文と経路の変化を比較します。
- 解消した設定、承認者、適用scope、rollback方法を台帳に残し、全端末へ一括配布する前に限定ユーザーで確認します。
認証失敗を「パスワードの問題」と決めつけないことが重要です。2.1.265のように変数の解釈がversionで変わることがあります。管理設定は個人のshellより優先される場合があるため、ローカルで値を消しても組織設定から再注入される可能性があります。設定の優先順位は組織ポリシーの確認方法と更新channelの選び方も参照してください。
企業運用で決める3つの境界
第一は、誰が認証経路を選ぶかです。個人の実験ではAPIキーを使えても、組織業務ではSSOやGatewayに統一する判断があります。第二は、どのscopeへ設定を置くかです。managed settings、project、user、sessionを区別し、秘密情報を共有projectへ置かない運用にします。第三は、障害時のfallbackです。Gateway障害時にAPIキーへ勝手に切り替えると、請求先、監査主体、データ経路が変わります。fallbackは管理者が承認した手順として定義してください。
料金について、今回の公式changelogと認証文書からGateway専用の追加料金を断定できません。モデル料金、API契約、Teams・Enterprise契約、クラウド利用料はそれぞれの公式料金表で確認し、エラー解消と料金判断を混ぜないことが重要です。
再現テストは、作業中のrepositoryや本番相当のGatewayで行わないでください。認証経路を変える操作は、sessionの利用主体だけでなく、送信先と請求の記録も変えます。テスト用project、最小権限のアカウント、ダミーのread-only操作を用意し、成功した場合も元の設定へ戻せることを確認します。
障害報告には、version、OS、実行surface、設定scope、認証経路、発生時刻、エラーの前後を含めます。秘密値を伏せても、URLのqueryやhelperの標準出力にtokenが含まれることがあるため、共有前に全文を点検します。
チェックリスト：再ログインする前に
□ Claude Codeのversionを記録した □表示されたエラー全文を保存した □GatewayとAPIキーのどちらを選ぶか決めた □環境変数名だけを棚卸しした □endpointの有無を確認した □apiKeyHelperのscopeと終了状態を見た □managed settingsの上書きを確認した □同じ条件で再現した □秘密値をログやチケットに貼っていない □rollbackと承認者を決めた
よくある質問
2.1.266へ更新すれば必ず直りますか？
今回の回帰に一致する場合は修正対象ですが、Gateway URL、管理設定、helper、権限が別原因なら残ります。version更新後も同じ条件で再現してください。
APIキーとGatewayを同時に設定してよいですか？
意図した優先順位を説明できる場合を除き、検証時は一つに絞ります。組織運用では認証主体と請求・監査の境界が変わるため、fallbackも承認対象です。
設定値をサポートへ共有してよいですか？
tokenや秘密値は共有せず、version、変数名、設定scope、endpointのホスト名をマスクした形、再現手順、エラー文を伝えます。
公式情報と無料診断
仕様は公式changelogと公式Authenticationを公開直前に確認しています。Miraigentの無料診断では、Claude Codeの認証経路、組織設定、障害時fallback、監査記録を業務単位で整理できます。