Claude Media
Claude DesktopでAuthentication failedが繰り返される原因 — 社内プロキシ越し
Claude CodeClaudeTips

Claude DesktopでAuthentication failedが繰り返される原因 — 社内プロキシ越し

社内のTLS検査プロキシ越しでClaude Desktopが「Authentication failed」を繰り返すとき、証明書・URLカテゴリのブロック・NTLM認証のどこを疑うかを切り分けます。

読了目安 約12分

社内ネットワークでClaude Desktopを開くと、セッション画面に「Authentication failed — Sign in again to continue」が数分おきに出る。同じ端末のターミナルではclaudeが普通に動く。こうなると、まず疑うのは証明書です。

ところが、GitHubに報告された事例では原因は証明書ではありませんでした。TLS検査(プロキシが通信を復号して独自の認証局で署名し直す仕組み)の環境で、Desktopが失敗する原因は少なくとも3層に分かれます。ここでは症状ごとにどの層を疑うかを整理し、情報システム部門に頼む内容までまとめます。

症状から原因の層を絞る

同じ「社内プロキシ越しで動かない」でも、画面に出る文言で疑う先が変わります。

画面や記録に出るもの疑う層最初に確かめること
「Authentication failed — Sign in again to continue」が約5分おきに出る疑う層認証用URLの遮断最初に確かめることプロキシのURLカテゴリ規則とアクセスログ
「Unable to connect to Claude」、ログにBootstrap API returned 407疑う層プロキシの認証最初に確かめることプロキシがNTLM・Kerberosを要求していないか
SSL certificate verification failed疑う層認証局の信頼最初に確かめること検査用の認証局がOSの信頼ストアにあるか
白紙のページが表示される疑う層CDNホストの遮断最初に確かめることassets-proxy.anthropic.comなどの許可

上の3行目は、Claude Codeを実行したときのエラー文言です。Desktopのチャット画面で同じ文言が出るとは限りません。画面の文言が合わないときは、4行の「確かめること」を上から順に試します。

証明書ではなく、URLカテゴリで止められていた事例

GitHubのIssue #97853は、macOSのDesktopアプリで「Authentication failed」が約5分おきにセッション画面へ出ると報告しています。環境はZscalerによるTLS検査で、claude.ai・api.anthropic.com・console.anthropic.comの証明書がZscalerの認証局で再署名されます。そのルート証明書はmacOSのシステムキーチェーンで信頼済みでした。

報告者は最初、こう推測しました。

  • curlとopenssl s_clientは、Zscaler発行の証明書でも検証に成功する
  • 同じネットワークのターミナルCLIでは症状が出ない
  • Desktopの認証更新だけが、OSの信頼ストアより厳しい証明書固定(ピンニング)を使っているのではないか

約5分後、報告者は自分でこの推測を取り下げました。原因は証明書固定ではなく、プロキシが社内ポリシーで「AI」のURLカテゴリを遮断していたことでした。遮断は、OAuthのコールバックURL(https://claude.com/cai/oauth/authorize?...)に直接当たっていました。報告者の結論は「クライアントの修正ではなく、セキュリティ部門への許可リスト例外の依頼が解決策」です。

ここから読み取れる点が1つあります。証明書の検証が通っていても、認証に使うURLが遮断されれば更新は失敗します。しかもcurlでclaude.aiに届くことは、claude.comのこのパスが通ることの証明にはなりません。以上は報告者自身の診断で、あなたの環境で同じ原因かは確かめる必要があります。

手元でできる切り分け

情報システム部門に依頼する前に、端末側で3点を見ておくと依頼が具体的になります。

手順

依頼の前に端末で確かめる3点

  1. 1

    TLS検査の認証局を特定する

    接続先の証明書を出している発行者を確認します。社内の認証局名(Zscalerなど)が出れば、TLS検査を受けています。

  2. 2

    許可対象のホストへ届くかを見る

    ホストごとにHTTPステータスを取り、遮断されたものを洗い出します。プロキシの遮断ページが返るときは、200や302以外の応答になります。

  3. 3

    CLIで同じ症状が再現するか見る

    CLIが動くなら、少なくともapi.anthropic.comと認証局の信頼は成立しています。Desktopだけが失敗する場合は、Desktop固有のホストやURLを疑います。

# 1. 証明書の発行者を見る(社内CA名が出ればTLS検査あり)
openssl s_client -connect claude.ai:443 -servername claude.ai \
  </dev/null 2>/dev/null | openssl x509 -noout -issuer
 
# 2. 認証に関わるホストへ届くか(ステータスだけ表示)
for h in claude.ai claude.com platform.claude.com api.anthropic.com; do
  printf '%s ' "$h"
  curl -s -o /dev/null -w '%{http_code}\n' "https://$h/"
done

Windowsでは、PowerShellのcurlは別物のエイリアスです。curl.exeと明示して実行します。ステータスが返らずに接続が切れるホストがあれば、それがプロキシ側で遮断されている候補です。

許可してもらうホストの一覧

Desktopアプリはアプリのコードやユーザーコンテンツを複数のAnthropic CDNホストから読み込みます。claude.aiだけ許可してCDN側を遮断すると、エラーではなく白紙のページになります。ワイルドカードを減らしたいときは、次のホストを個別に許可する形が公式に案内されています。

anthropic.com
api.anthropic.com
a-api.anthropic.com
a-cdn.anthropic.com
s-cdn.anthropic.com
assets-proxy.anthropic.com
claude.ai
a.claude.ai
assets.claude.ai
downloads.claude.ai
*.livepreview.claude.ai
claude.com
platform.claude.com
*.livepreview.claude.app
*.claudeusercontent.com
*.claudemcpcontent.com

通信はHTTPSの443番ポートです。*.claudeusercontent.comと*.claudemcpcontent.comは、動的に作られるサブドメインがあるためワイルドカードのまま許可します。*.claudemcpcontent.comを遮断しても本体は動きますが、コネクタが返す対話ウィジェットが表示されなくなります。

この表と#97853の事例を合わせると、依頼で伝えるべき点が見えてきます。ホスト名の一覧だけでなく、claude.comとplatform.claude.comの認証パスまで含めること。そして、URLカテゴリ規則(AIカテゴリの一括遮断など)がホスト許可より先に評価される製品では、カテゴリ側の例外も必要になることです。

NTLMやKerberosのプロキシでは対話認証が出ない

Issue #98631は、WindowsのMSIX版Desktopで別の失敗を報告しています。常時接続のVPNがすべての通信をNTLM認証付きのプロキシに通す環境で、アプリには「Unable to connect to Claude」と出て、回復の手段がありません。

報告者がメインログで確認した行は3つです。

  • proxy for https://claude.ai resolved (proxied): プロキシは検出できている
  • Bootstrap API returned 407: 認証の要求に応答できていない
  • net::ERR_TUNNEL_CONNECTION_FAILED: トンネルが張れない

Chrome・Edgeは、プロキシが407を返すとWindowsの資格情報ダイアログを出します。報告者によれば、Desktopにはその仕組みがありません。そのためNTLMプロキシの背後では、資格情報を入力する画面が出ないまま接続が止まります。

報告者が試した回避策は、いずれも効かなかったとされています。settings.jsonやclaude_desktop_config.jsonでのプロキシ設定、Windows環境変数の設定、CNTLMやPxのようなローカル中継プロキシの併用です。報告者の見立てでは、MSIXのサンドボックスにより環境変数が描画プロセスに届きません。

これは機能要望のIssueで、まだ開いたままです。MSIX版の導入手順自体はClaude DesktopをWindowsで一括導入する手順(MSIX)にあります。そこに載る管理設定で、この問題は解消しません。

同じIssueのコメントには、部分的な回避策が1件あります。VPNに接続する前にDesktopを起動し、api.anthropic.com向けのホスト経路をVPNの外に出す方法です。ただし報告者自身が、VPN接続中の新規セッションはリモート管理設定の取得に失敗すると書いています。社内ルールとの兼ね合いもあるので、手順の紹介にとどめます。

公式がNTLMについて言っていること

Claude Codeのネットワーク設定ページは、NTLMやKerberosのような高度な認証が必要なプロキシには、その認証方式に対応したLLMゲートウェイの利用を検討するよう案内しています。SOCKSプロキシは非対応です。この記述はClaude Code(CLI)についてのもので、Desktop本体のチャット画面のプロキシ対応を説明するものではありません。

CLIは動くのにDesktopだけ失敗するとき

Claude Codeは、既定でMozillaの同梱証明書とOSの証明書ストアの両方を信頼します。TLS検査プロキシは、ルート証明書がOSの信頼ストアにあり、実行環境が読める状態なら追加設定なしで動きます。これが、#97853でCLIだけ無事だった理由と整合します。

手元で確かめるなら、デバッグログ付きでCLIを起動します。

claude --debug

証明書エラーが出る場合、ネットワーク設定ページが案内するのは次の対処です。

  • 検査用の認証局のPEMファイルをNODE_EXTRA_CA_CERTSに指定する
  • 認証局をOSのシステムの信頼ストアへ追加する
  • 情報システム部門に*.anthropic.comの許可を頼む

Desktopのコードタブやコワークのように、アプリが接続を管理するセッションには注意が要ります。ここでClaude Codeがプロキシ変数と証明書関連の変数を読むのは、管理設定と~/.claude/settings.jsonからだけです。リポジトリ内の設定ファイルは無視されます。シェルでexportした変数に頼っていると、Desktop経由のセッションには届きません。

{
  "env": {
    "HTTPS_PROXY": "http://proxy.example.corp:8080",
    "NODE_EXTRA_CA_CERTS": "/etc/ssl/corporate-ca.pem"
  }
}

これは~/.claude/settings.jsonへの書き方の一例です。Desktop本体(チャット画面)の証明書設定を説明するページは、network-configにもdesktopにも載っていません。本体側の挙動は、検証した結果をもとに情報システム部門か管理者向けの問い合わせ窓口に確かめます。CLI側の設定を網羅した手順はClaude Codeのプロキシ設定にあります。

情報システム部門へ渡す依頼文の骨子

切り分けの結果を、次の3点にまとめて渡します。

  1. 症状と頻度(例: セッション画面に約5分おきに「Authentication failed」)
  2. 開けない可能性のあるホスト(上の一覧と、claude.com・platform.claude.comの認証パス)
  3. 求める変更(AIカテゴリの例外、CDNホストの許可、NTLMの場合は対応する中継やゲートウェイの検討)

Claude Scienceは社内ネットワーク向けの設定項目を独自に持つため、同じ症状でも対処が異なります。そちらはClaude Scienceを社内ネットワークで使うで扱っています。

まとめ

「Authentication failed」の繰り返しは、証明書の検証失敗とは限りません。URLカテゴリ規則による認証パスの遮断、NTLM認証の407、CDNホストの遮断で、それぞれ画面の出方が違います。端末で発行者とホストごとのステータスを取り、結果を添えて許可を依頼するのが近道です。

NTLM必須のMSIX版Desktopは、機能要望が開いたままです。VPN越しの運用が必須なら、ブラウザ版のclaude.aiを併用する案も報告者は挙げています。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →