Claude Code の SSL 証明書エラー：確実に効く5つの対処法（2026年版）

自宅では動いていた Claude Code が、オフィスに来た途端に TLS のエラーの壁で止まる。SELF_SIGNED_CERT_IN_CHAIN、unable to get local issuer certificate、あるいは素っ気ない Self-signed certificate detected。インストールに問題はありません。会社のネットワークがすべての HTTPS 接続を開いて再署名しており、Claude Code がその新しい署名を認識できないのです。

解決策はまず証明書チェックを無効化することではありません。会社が追加した「その1枚の証明書」を Claude Code に信頼させることです。本ガイドでは、試すべき順序に沿ってその5つの方法、あわせて設定すべきプロキシまわりの項目、そして API キーをこっそり通信路上の誰にでも差し出してしまう例の「対処法」を取り上げます。

30秒でできる切り分け

まずはエラー文字列を読みます。どの層で失敗しているかがわかり、それぞれが下記の具体的な対処法に対応します。

原因は10秒のテストで決着します。検査のないネットワークで Claude Code を実行してください。スマホのテザリングで十分です。あるいは IT に api.anthropic.com のバイパスルールを依頼します。そこでは接続でき、社内ネットワークで失敗するなら、プロキシが通信を再署名しているということで、必要なのは再インストールではなく CA の対処です。

直すか回避するか：それぞれが妥当な場面

設定ファイルに手を付ける前に、自分が実際に抱えている問題を見極めましょう。以下の証明書系の対処法は、会社の CA を入手でき、環境変数を設定できることを前提にしています。それが常に成り立つとは限らず、無理に押し通すと午後がまるまる無駄になります。

CA を追加すべき場合（大半のケース）

• マシンを自分で管理でき、環境変数を設定するか ~/.claude/settings.json を編集できる。
• IT がルート CA ファイルを渡してくれる、またはすでに OS の信頼ストアにインストールされている。
• プロキシが単純なパススルーまたは基本認証を使っている。

代わりにゲートウェイ経由にすべき場合

• プロキシが NTLM または Kerberos 認証を要求する。Claude Code はどちらも話せず、CA のインポートでは解決しません。
• 会社の CA を入手できず、IT も Anthropic のドメインを許可リストに入れてくれない。
• チーム全体に対して、独自の TLS 終端を持つ単一の出口点が必要で、開発者ごとの CA のやりくりに割く価値がなくなっている。

打ち切りの判断

直接ネットワークでは Claude Code が接続でき、社内プロキシの背後でのみ壊れるなら、これは間違いなく信頼の問題です。再インストールも、Node バージョンをやみくもに切り替えるのも、「バイナリが壊れている」というサポートチケットを開くのもやめて、対処法1に進んでください。クリーンなネットワークでも失敗する場合、原因は別のもの（DNS、地域ブロック、期限切れのサブスクリプションなど）であり、ここの証明書系の対処法では解決しません。

Claude Code が証明書を拒否する理由

多くの社内ネットワークは TLS 検査プロキシを運用しています。Zscaler、Netskope、Cato、CrowdStrike Falcon、あるいは同じ役割を担うフルトンネル VPN です。この装置はデータ損失防止（DLP）とマルウェア検査のために送信 HTTPS を読むために存在します。暗号化されたストリームを読むには、中間に居座る必要があります。api.anthropic.com への接続を終端して復号し、自ら先へと接続を張り、会社の秘密の認証局でレスポンスを再署名するのです。

ブラウザがその再署名された証明書を信頼するのは、IT がノート PC のセットアップ時に会社のルート CA をブラウザと OS の信頼ストアへ配布したからです。Claude Code は独自の信頼観を持つ別のランタイムであり、そこに食い違いが生じます。

flowchart LR
    A[Claude Code] -->|HTTPS| B[TLS-inspection proxy]
    B -->|decrypts, re-signs<br/>with corporate CA| C[api.anthropic.com]
    C -->|real Anthropic cert| B
    B -->|re-signed cert| A
    A -->|corporate CA<br/>not in trust store| D[SELF_SIGNED_CERT_IN_CHAIN]

多くの解説が取り違えているのがここです。現行の Claude Code はすでに OS の信頼ストアを読みます。デフォルトでは、同梱の Mozilla CA セットと OS の証明書ストアの両方を信頼します。OS ストアの読み込みには tls.getCACertificates を公開するランタイムが必要です。ネイティブインストーラは常に備えており、npm インストールでは Node 22.15 以降が必要です。それより古い Node では、同梱セットと NODE_EXTRA_CA_CERTS のみが有効です。したがって IT が会社のルートを OS ストアにインストール済みで、現行ビルドを使っていれば、Zscaler や CrowdStrike Falcon のような検査プロキシでも追加設定なしに動きます。エラーが出るのは、その隙間です。古い npm ベースのインストール、OS ストアに入らなかった CA、あるいはそれをスキップする形で起動されたランタイム、といったケースです。

SSL エラーを読む：文字列と影響範囲

正確な文字列が原因を絞り込みます。これは Node と OpenSSL が使うのと同じ分類なので、Claude Code がネイティブバイナリで動いていても npm インストールでも同じように当てはまります。

この切り分けが重要です。すべての API 呼び出しで出る検証エラーは信頼ストアの問題で、CA を追加すれば一度で直ります。インストール時の失効エラーはファイアウォールが参照をブロックしているだけなので、信頼設定を変えるのではなく、そのインストールコマンド1回だけを回避します。

対処法（順番どおりに）

上から順に進めてください。先の対処法ほどクリーンで、後の対処法ほどリスクが高くなります。

対処法1：Claude Code に OS の信頼ストアを使わせる

IT がすでに会社の CA をシステムストアに入れている場合（ブラウザに必要なので、ほぼ確実に入っています）、いちばんクリーンな対処法は、それと戦わず Claude Code にそのストアを読ませることです。

ネイティブインストーラでは自動です。npm インストールでは、Node が 22.15 以降であることを確認します。

node --version

それより古ければ Node をアップグレードするか、信頼判定を Node バージョンに依存しないネイティブインストーラに切り替えてください。CLAUDE_CODE_CERT_STORE のデフォルトはすでに bundled,system なので、Claude Code は初期状態で OS ストアを読みます。この変数に触れるのは、誰かが bundled に強制して OS ストアを外してしまった場合だけです。その場合は system を戻します。

export CLAUDE_CODE_CERT_STORE=bundled,system

期待される結果：Claude Code が OS の信頼するもの（会社のルートを含む）を信頼します。system だけを強制しても、デフォルトが持っていない信頼が増えるわけではないので、OS ストアを読むには古すぎるランタイムを救うことはできません。OS ストア自体に CA がない場合は、対処法2の出番です。

対処法2：NODE_EXTRA_CA_CERTS を会社の CA に向ける

これが主力の対処法で、Anthropic のドキュメントが TLS 検査環境向けに名指ししているものです。既存のものを置き換えることなく、組み込みセットの上に会社のルートを追加します。

まず CA ファイルを PEM 形式で入手します。IT に依頼するか、自分でエクスポートします。macOS では Keychain Access を開いて会社のルートを .pem としてエクスポート、Windows では certmgr.msc を実行して「信頼されたルート証明機関」を開き Base-64 encoded X.509 でエクスポート、Linux では通常すでに /usr/local/share/ca-certificates か /etc/pki/ca-trust の下にファイルがあります。

そして Claude Code をそこへ向けます。

export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem
claude

期待される結果：Claude Code がプロキシの再署名した証明書を信頼するようになり、API 呼び出しが成功します。~/.zshrc や ~/.bashrc に export を追加して永続化してください。CA バンドルに複数の証明書（ルートと中間）が含まれる場合は、1つの PEM ファイルに連結します。NODE_EXTRA_CA_CERTS はそのすべてを読みます。

対処法3：インストール手順を別途直す

インストールとランタイムは別々のネットワーク呼び出しで、独立して失敗し得ます。Claude Code がまだインストールされる前に curl が詰まるなら、シェルのプロファイルではなくインストールコマンドにパッチを当てます。

インストーラの curl を同じ CA バンドルに向けます。

curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash

Windows で schannel の secure-channel エラーが出る場合は、まず TLS 1.2 を強制します。

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
irm https://claude.ai/install.ps1 | iex

Windows が CRYPT_E_NO_REVOCATION_CHECK または CRYPT_E_REVOCATION_OFFLINE を報告する場合、ネットワークが証明書の失効参照をブロックしています。これは社内ファイアウォールの背後でよくあることです。インストールに限ってベストエフォートの失効チェックを追加します。

curl --ssl-revoke-best-effort -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

期待される結果：バイナリがインストールされます。実行時の API 呼び出しは引き続き対処法1または対処法2に支配されるので、そちらも設定してください。

対処法4：プロキシそのものを設定する

証明書は問題ないのに、プロキシが使われていないこともあります。Claude Code は標準的なプロキシ変数を読みます。API 通信で重要なのは HTTPS_PROXY です。

export HTTPS_PROXY=https://proxy.example.com:8080
export HTTP_PROXY=http://proxy.example.com:8080
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

NO_PROXY はスペースまたはカンマ区切りのリストを取り、* はすべてをプロキシからバイパスします。プロキシが基本認証を必要とする場合は、URL に認証情報を含めます。

export HTTPS_PROXY=http://username:password@proxy.example.com:8080

時間を浪費する前に知っておくべき2つの制限があります。Claude Code は SOCKS プロキシに対応していません。また、NTLM や Kerberos のプロキシ認証も扱えません。まさに次のセクションで扱うケースです。

対処法5：mTLS とクライアント証明書環境

一部の企業は、信頼されたサーバー証明書だけでなく、クライアント証明書も要求します。Claude Code は3つの変数で相互 TLS に対応します。

export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="your-passphrase"

期待される結果：Claude Code がハンドシェイク時にクライアント証明書を提示し、ヘッダーではなく証明書で呼び出し元を認証するプロキシやゲートウェイを満たします。

逆をいく対処法：検証は絶対に無効化しない

フォーラムで NODE_TLS_REJECT_UNAUTHORIZED=0 を勧められることがあります。これはエラーを消してくれます。誰からのどんな証明書も受け入れるよう Node に指示するからです。それには、同じカフェのネットワークにいる攻撃者も含まれ、あなたが毎リクエストで送る API キーを平文で読めるようになります。これは絶対にコミットしてはならない1行です。CA を追加すれば検証を有効に保ったまま、選んだ証明書だけを信頼します。検証を無効化すればすべてを信頼します。両者はまったく別物です。

通しの手順例：macOS 上の Zscaler

抽象的な手順はしくじりやすいので、いちばん一般的な構成、Zscaler の背後にある Mac について、最初から最後まで通しで示します。所要時間はおよそ5分です。

まず、本当にプロキシが原因かを確認します。スマホにテザリングして claude を実行してください。そこで接続できれば、社内ネットワークが傍受しているということで、以下を続けます。

Keychain から Zscaler のルートをエクスポートします。Keychain Access を開き、会社のルート（多くは Zscaler Root CA という名前）を検索して選択し、File → Export Items でホームフォルダに zscaler-root.pem として保存します。.cer としてエクスポートされた場合は変換します。

openssl x509 -inform der -in zscaler-root.cer -out zscaler-root.pem

Claude Code をそこへ向け、永続化します。

echo 'export NODE_EXTRA_CA_CERTS="$HOME/zscaler-root.pem"' >> ~/.zshrc
source ~/.zshrc

export が読み込まれるよう新しいターミナルを開き、claude を起動します。SSL エラーは消えています。

対処が本当に効いたか検証する

「動いているように見える」を信じないでください。Claude Code とシェルが証明書について一致していることを確認します。次のワンライナーは同じ CA を通してリクエストを実行し、証明書チェーンと SSL certificate verify ok を出力するはずです。

curl --cacert "$NODE_EXTRA_CA_CERTS" -svo /dev/null https://api.anthropic.com 2>&1 | grep -E "issuer|verify"

そのバンドルで curl は検証できるのに claude はまだ失敗する場合、変数が Claude Code のプロセスに届いていません。これは次に扱うシェル対 settings.json の隙間であって、証明書の問題ではありません。

Docker、CI ランナー、リモート開発

コンテナは、解決したと思った後にこのエラーが再発する場所です。新しいコンテナはノート PC の OS 信頼ストアを継承しないからです。ホストは会社の CA を信頼していても、Docker 内の Ubuntu ベースイメージは信頼していません。

CA をイメージに焼き込み、OS ストアと Node 変数の両方に登録します。

COPY corporate-ca.pem /usr/local/share/ca-certificates/corporate-ca.crt
RUN update-ca-certificates
ENV NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt

同じ論理が CI ランナーとリモート開発マシンにも当てはまります。同じプロキシの背後にある GitHub Actions や GitLab のランナーには、ジョブ環境に CA が存在する必要があり、通常はジョブの冒頭で書き出すシークレットファイルとして用意し、いずれの claude ステップよりも前に NODE_EXTRA_CA_CERTS を export します。Devcontainer には Dockerfile 内に上記の ENV 行が必要です。シェルのプロファイルだけを直した場合、コンテナはそれを一度も見ません。

settings.json 対シェル

上記のすべての変数は ~/.claude/settings.json の env ブロックに置けます。一度設定するマシンにとってはこちらがきれいな選択肢です。

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/path/to/corporate-ca.pem",
    "HTTPS_PROXY": "https://proxy.example.com:8080"
  }
}

はっきり述べておくべき注意点があります。一部の初期バージョンは NODE_EXTRA_CA_CERTS が settings.json にだけ設定されていると無視し、デスクトップアプリが起動する CLI サブプロセスへ常に転送するとは限りませんでした。どちらも追跡中の GitHub Issue として表面化しています。settings.json の値が効かない場合、確実なフォールバックはプロファイルでのシェル export です。Node が Claude Code の起動前に読むため、どのビルドでも尊重されます。

よくある関連エラー（と対処法）

これらは証明書エラーの隣に現れ、それと取り違えられがちです。

最後の行が見落とされがちです。claude はターミナルでは動くのに VS Code や JetBrains のパネルが SSL エラーを出す場合、エディタは Dock から起動されて .zshrc を一度も見ていません。IDE 独自の環境に変数を設定するか、それらがすでに export されているシェルからエディタを起動してください。

プロキシが折れない時：ゲートウェイ経由にする

プロキシが NTLM や Kerberos を要求する、あるいはそもそも CA を入手できない場合、証明書の追加は行き止まりです。Anthropic 自身のネットワークガイダンスもそう述べています。高度な認証を要求するプロキシには、その方式を話せる LLM ゲートウェイを前段に置くのです。ゲートウェイは自前の TLS を終端し、面倒なプロキシ交渉を一度だけ処理します。こうすれば全開発者が1つのエンドポイントを指すだけで済み、各自が自分の信頼ストアと格闘する必要がなくなります。

それが ofox です。https://api.ofox.ai にある OpenAI・Anthropic 互換のゲートウェイです。Claude Code をカスタムエンドポイントに向けるのは1行の変更で、Claude Code のエンドポイント切り替えチュートリアルで扱ったのと同じ差し替えです。2つの変数を設定します。

export ANTHROPIC_BASE_URL=https://api.ofox.ai/anthropic
export ANTHROPIC_API_KEY=sk-ofox-...

これで何が解決し、何が解決しないかは正直に言っておきます。社内プロキシは引き続き api.ofox.ai への通信を再署名するので、ゲートウェイのホストのために会社の CA を信頼ストアに入れる必要は残るかもしれません。ゲートウェイが与えてくれるのは、チーム全体で1つの出口エンドポイント、Claude・GPT・Gemini をまたぐ単一の課金ビュー、そしてひとつの上流に到達できない時の組み込みフォールバックです。base-URL の差し替えとモデルルーティングの全体像はCursor・Claude Code・Cline のカスタム API 設定ガイドを、接続後のコスト管理はClaude Code のハイブリッドルーティングパターンをご覧ください。Claude Code から完全に乗り換えることも検討しているなら、同じ信頼のルールがClaude Code から Codex への移行ガイドにも当てはまります。

ゲートウェイは避難口であって、デフォルトではありません。CA を入手できるなら、対処法1か対処法2の方がシンプルで、直接経路にとどまれます。

FAQ

Claude Code の SELF_SIGNED_CERT_IN_CHAIN はどう直せばいい？ TLS 検査プロキシが信頼していない CA で接続を再署名したのです。その CA を OS の信頼ストアにインストールする（ネイティブインストーラと Node 22.15+ は自動で読みます）か、NODE_EXTRA_CA_CERTS を CA バンドルに向けます。検証は無効化しないでください。

NODE_EXTRA_CA_CERTS とは何で、どこに向ければいい？ 組み込みセットの上に信頼証明書を追加する Node の変数です。会社のルートを PEM 形式で指定します：export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem。シェルまたは settings.json で設定します。

Claude Code は Windows や macOS の証明書ストアを読む？ はい。デフォルトで同梱の Mozilla セットに加え OS ストアを信頼します。OS ストアの読み込みにはネイティブインストーラまたは Node 22.15+ が必要です。より古い Node は同梱セットと NODE_EXTRA_CA_CERTS のみを使います。

NODE_TLS_REJECT_UNAUTHORIZED=0 は安全？ いいえ。すべてのリクエストで証明書検証を無効にし、経路上の誰にでも API キーをさらします。代わりに CA を追加してください。

curl は通るのに Claude Code だけ SSL エラーになるのはなぜ？ 別々の信頼ストアを読むからです。システム curl は通常すでに会社の CA を信頼していますが、Claude Code のランタイムは信頼していないか、npm インストールが Node 22.15 より古い可能性があります。NODE_EXTRA_CA_CERTS を同じ CA に向けるか、ネイティブインストーラまたは Node 22.15+ に移行して OS ストアを読ませます。（CLAUDE_CODE_CERT_STORE のデフォルトは bundled,system なので、system を強制しても何も増えません。）

NODE_EXTRA_CA_CERTS を settings.json で設定できる？ はい、env ブロックで設定できます。一部の古いバージョンはシェルの export のみを尊重したので、settings.json が効かない場合はシェルのプロファイルで export してください。

Claude Code は SOCKS や NTLM プロキシに対応している？ SOCKS には非対応で、NTLM や Kerberos 認証も直接は扱えません。HTTP_PROXY、HTTPS_PROXY、NO_PROXY を読み、URL 内の user:password 形式の基本認証に対応します。NTLM や Kerberos にはゲートウェイを前段に置いてください。

会社の CA 証明書ファイルはどう入手すればいい？ IT にルート CA を PEM 形式で依頼するか、Keychain Access（macOS）、certmgr.msc（Windows、Base-64 X.509）、または /usr/local/share/ca-certificates（Linux）からエクスポートします。

今回の更新にあたり確認した情報源

• Claude Code: Troubleshoot installation and login（2026-07-03 確認）。TLS/SSL エラー文字列、--cacert によるインストール対処、Windows の TLS 1.2 と --ssl-revoke-best-effort、インストール時の HTTPS_PROXY 設定の出典。
• Claude Code: Enterprise network configuration（2026-07-03 確認）。NODE_EXTRA_CA_CERTS、CLAUDE_CODE_CERT_STORE、同梱+OS の信頼モデルと Node 22.15 のしきい値、HTTP_PROXY/HTTPS_PROXY/NO_PROXY、基本認証プロキシ URL、SOCKS 非対応の制限、mTLS 変数の出典。
• anthropics/claude-code issue #22512（2026-07-03 確認）。settings.json で設定した NODE_EXTRA_CA_CERTS が尊重されなかったケースを裏付け、シェル export のフォールバックの根拠。
• Node.js の TLS ドキュメント（NODE_EXTRA_CA_CERTS の挙動と PEM バンドルの扱いについて）（2026-07-03 確認）。