Claude Codeが社内プロキシ・SSL証明書エラーで動かない時の設定完全ガイド 2026
Claude Codeが企業プロキシ・SSLインスペクション環境で繋がらない原因と対処法を公式ドキュメントベースで整理。NODE_EXTRA_CA_CERTSが不要なケース、mTLS認証、MCPサーバーやバックグラウンドエージェントで設定が反映されない問題まで実例付きで解説する。
エンジニアのゆとです。
以前、常駐案件で客先の貸与PCにClaude Codeを入れようとしたら、インストール自体は通ったのにログインで止まった。エラーはunable to verify the first certificate。自宅のMacでは何の問題もなく使えていたのに、会社のネットワークに繋いだ瞬間にこれだ。原因はSSLインスペクションを行う社内プロキシが、通信の途中で証明書を独自のものに差し替えていたことだった。
Claude Codeに限らず、企業ネットワークの多くはこの手のプロキシを挟んでいる。セキュリティ上は正しい仕組みなんだけど、CLIツール側からすると「知らない証明書が割り込んできた」ようにしか見えないので、素直にエラーで止まる。日本語で検索すると同じ症状を報告しているQiitaやZennの記事がいくつも出てくる時点で、これがかなり普遍的な詰まりポイントだと分かる。
この記事では、Claude Code公式の「Enterprise network configuration」ドキュメントを一次情報として、プロキシ設定・SSL証明書エラー・MCPサーバーやバックグラウンドエージェントでの落とし穴までを整理する。既存の解説記事の多くはWindows + PowerShellの手順が中心で、2026年時点で追加されたCLAUDE_CODE_CERT_STORE（OS証明書ストアの自動信頼）やmTLS認証まで触れているものは見当たらなかったので、そのあたりも含めて一次情報ベースで書いた。
結論 — 症状別の対処表
まず自分がどのパターンに当てはまるか確認してほしい。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| そもそも接続がタイムアウトする・繋がらない | プロキシ環境変数が未設定、または誤った値 | HTTPS_PROXYを正しい形式で設定（後述） |
unable to verify the first certificateエラー | SSLインスペクションプロキシの証明書がOSに信頼されていない | 社内CA証明書をOSの証明書ストアにインストール、それでもダメならNODE_EXTRA_CA_CERTS |
| プロキシに繋がるが401/407で弾かれる | プロキシ認証（Basic認証）の情報未設定 | HTTPS_PROXYのURLにuser:password@を含める |
| NTLM/Kerberos認証プロキシで詰まる | Claude CodeはNTLM/Kerberosを直接サポートしていない | LLM Gatewayを経由する構成に切り替える |
| ターミナルでは動くのにMCPサーバーだけ外部に繋がらない | プロキシ環境変数がMCPの子プロセスに伝わっていない | .mcp.jsonのサーバーエントリに直接envでプロキシ変数を書く |
claude agentsやバックグラウンドセッションだけ挙動が違う | supervisorプロセスがシェルの環境変数を引き継いでいない | ~/.claude/settings.jsonのenvブロックに設定する |
| 会社のクライアント証明書認証（mTLS）が必要な環境 | プロキシ側でクライアント証明書を要求している | CLAUDE_CODE_CLIENT_CERT/CLAUDE_CODE_CLIENT_KEYを設定 |
なぜ社内プロキシでClaude Codeが動かないのか
企業ネットワークの多くは、外部との通信を一度プロキシサーバーに集約している。単に通信を中継するだけでなく、HTTPSの中身を検査する「SSLインスペクション」を行っている場合、プロキシがAnthropicのサーバー証明書をいったん自分の証明書に差し替えてクライアントに渡す。ブラウザは会社が配布した独自ルート証明書（社内CA）を信頼するよう設定済みなので気づかないが、Claude CodeのようなCLIツールはNode.jsのランタイムが持つ証明書ストアを見て通信の安全性を判断するため、社内CAが登録されていないと「知らない証明書だ」と判断してエラーで止まる。
つまり問題は大きく2つに分かれる。
- そもそもプロキシサーバーの場所を知らない — 環境変数でプロキシのアドレスを教えてやる必要がある
- プロキシが差し替えた証明書を信頼していない — 社内CA証明書を信頼させる必要がある
この2つを混同して、証明書の問題なのにプロキシ設定だけいじって直らない、逆にプロキシ設定が漏れているのに証明書だけ足して直らない、というケースをよく見かける。まず切り分けてから対処したほうが早い。
まず診断する — claude --debugと/status
設定を変える前に、今何が読み込まれているかを確認する癖をつけたほうがいい。Claude Codeはほとんどの設定ミスを起動時にはチェックせず、実際に通信するタイミングで初めてエラーとして表面化する仕様になっている。唯一起動時に検証されるのはプロキシURLの形式で、http://のようなスキームが欠けている値を渡すと、その場でどの変数が壊れているか名指しで起動が止まる。
claude --debugデバッグログはターミナルには出ず、~/.claude/debug/<session-id>.txt（または--debug-fileで指定したパス）に書き出される。ログの中で以下のような行が出ていれば、その設定はきちんと読み込まれている。
CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERT
mTLS: Loaded client key from CLAUDE_CODE_CLIENT_KEY読み込みに失敗している場合はFailed to readやFailed to loadという行が理由付きで出てくるので、パスの誤りやパーミッションの問題はここで一発で分かる。
対話セッション中なら/statusでも確認できる。
- Proxy: 現在有効なプロキシURL。パースできない値は「invalid and ignored」と表示される
- mTLS client cert / mTLS client key: 読み込みに成功した場合のみ行が表示される。行がなければ読み込み失敗
- Additional CA cert(s):
NODE_EXTRA_CA_CERTSのパスが表示される（ファイルの中身までは検証していないので、実際に読み込めたかはデバッグログ側で確認する）
プロキシ環境変数を設定する
Claude Codeは標準的なプロキシ環境変数をそのまま尊重する。
# HTTPSプロキシ（推奨）
export HTTPS_PROXY=https://proxy.example.com:8080
# HTTPプロキシ（HTTPSが使えない場合）
export HTTP_PROXY=http://proxy.example.com:8080
# 特定の宛先をプロキシから除外（スペース区切り）
export NO_PROXY="localhost 192.168.1.1 example.com .example.com"
# カンマ区切りでも可
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"
# すべての通信でプロキシを迂回
export NO_PROXY="*"小文字のhttps_proxy等も同様に効く。複数指定されている場合、Claude Codeはhttps_proxy → HTTPS_PROXY → http_proxy → HTTP_PROXYの順に見て、最初に値が入っているものを採用する。どれが実際に使われているか迷ったら、この優先順位を思い出すと切り分けが早い。
なおClaude CodeはSOCKSプロキシに対応していない。社内プロキシがSOCKS5しか提供していない場合は、HTTP/HTTPSに変換するローカルプロキシを挟むか、後述のLLM Gateway経由の構成を検討することになる。
一度きりのシェルでexportしても、閉じれば消える。毎回設定し直すのが面倒なら、シェルの起動ファイル（.zshrcや.bashrc）に書くか、Claude Code側の~/.claude/settings.jsonにまとめて書いてしまうほうが確実だ。
{
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NO_PROXY": "localhost,127.0.0.1,.internal.example.com"
}
}このページで紹介する環境変数は、すべてsettings.jsonのenvブロックでも同じように設定できる。後述するMCPサーバーやバックグラウンドエージェントの話にも関わってくるので、シェルのexportよりsettings.json側に寄せておくことをおすすめする。
Windowsの場合、PowerShellで一時的に設定するならこう。
$env:HTTPS_PROXY = "https://proxy.example.com:8080"永続化したいなら、システム環境変数として設定するか、上記と同じくsettings.jsonのenvブロックに書く方法のほうがシェルをまたいでも確実に効く。
プロキシ認証（Basic認証）が必要な場合
プロキシ側でユーザー名・パスワードを要求してくる構成なら、URLに埋め込む。
export HTTPS_PROXY=http://username:password@proxy.example.com:8080パスワードをスクリプトやdotfileに平文で書きっぱなしにするのは避けたい。1Passwordなどのシークレット管理ツールから都度注入する運用のほうが安全で、Claude Code CLI向けの具体的なやり方は別記事にまとめてある。
NTLMやKerberosといった、より高度な認証方式のプロキシには対応していない。これは公式ドキュメントでも明言されている制約で、該当する環境ではプロキシの手前にNTLM/Kerberosを吸収してくれるLLM Gatewayサービスを置く構成が推奨されている。素のURL埋め込みではどうにもならない領域なので、ここで詰まったら設定を疑うより先に環境自体を見直したほうがいい。
SSL証明書エラーの直し方 — 2026年時点でまず確認すべきこと
unable to verify the first certificateのようなエラーに遭遇すると、多くの解説記事は即座に「NODE_EXTRA_CA_CERTSで社内CA証明書を指定しろ」と案内する。それ自体は間違いではないんだけど、2026年時点のClaude Codeでは、その手順が不要なケースが増えている。
Claude Codeはデフォルトで、自前で同梱しているMozillaのCA証明書セットに加えて、OSの証明書ストアも自動的に信頼する挙動になっている。つまり、会社のIT部門がすでに社内CA証明書をOSの証明書ストア（macOSのキーチェーン、Windowsの証明書ストア）に配布済みなら、Claude Code側で追加の設定をしなくてもそのまま繋がる可能性が高い。CrowdStrike FalconやZscalerのようなエンタープライズ向けTLSインスペクションプロキシも、ルート証明書がOSの信頼ストアに入ってさえいれば追加設定なしで動くと公式に案内されている。
ただし条件がある。OS証明書ストアを読むには、ランタイムがtls.getCACertificatesという機能を持っている必要がある。ネイティブインストーラー版のClaude Codeは常にこの機能を持っているが、npm経由でインストールした場合はNode.js 22.15以降が必要になる。それより古いNode.jsで動かしている場合は、同梱のMozilla証明書セットしか信頼されず、NODE_EXTRA_CA_CERTSでの追加指定が必須になる。
node --versionまずここを確認して、22.15未満なら先にNode.jsを上げるだけで直るケースがある。ネイティブインストーラーへの移行も選択肢としてはあり、Windows環境でのインストール方法の違いは別記事で比較している。
証明書ストアの信頼元はCLAUDE_CODE_CERT_STOREという環境変数でコントロールできる。カンマ区切りでbundled（同梱のMozilla証明書セット）とsystem（OS証明書ストア）を指定する仕組みで、デフォルトはbundled,systemの両方だ。
# 同梱のMozilla証明書セットのみ信頼する
export CLAUDE_CODE_CERT_STORE=bundled
# OSの証明書ストアのみ信頼する
export CLAUDE_CODE_CERT_STORE=systemこの変数にはsettings.json専用のスキーマキーは用意されていないので、envブロックに直接書く形になる。
それでも直らない場合 — NODE_EXTRA_CA_CERTSで手動指定する
OS証明書ストアに社内CAが登録されていない、あるいはNode.jsのバージョンが古くてsystemソースが効かない場合は、証明書ファイルを直接指定する。
export NODE_EXTRA_CA_CERTS=/path/to/ca-cert.pem問題は「社内CA証明書のファイルをどう手に入れるか」で、ここを詳しく書いている記事が少なかったので手順を残しておく。一番早いのは、社内のIT部門やヘルプデスクに「Claude Codeで使うので、社内プロキシのルートCA証明書をPEM形式かCRT形式でもらえますか」と直接聞くこと。SSLインスペクションを導入している会社なら、大抵は配布用のファイルが既に用意されている。
自分でOSから取り出す場合、macOSはキーチェーンアクセス.appから対象の証明書を探し、右クリックして「書き出す」でPEM形式（.cer）として保存する。Windowsはcertmgr.mscを開いて該当のCA証明書を右クリック→「すべてのタスク」→「エクスポート」→「Base-64 encoded X.509 (.CER)」を選ぶ。どちらもBase64エンコードされたテキスト形式で、拡張子を.pemに変えるだけでそのまま使える。
# 取得した証明書を指定する（Mac/Linux）
export NODE_EXTRA_CA_CERTS=~/certs/corp-ca.pem# Windows PowerShellで永続化する場合
[Environment]::SetEnvironmentVariable("NODE_EXTRA_CA_CERTS", "C:\certs\corp-ca.pem", "User")設定できたかどうかは、前述のclaude --debugのログにAppended extra certificates from NODE_EXTRA_CA_CERTSの行が出ているかで確認する。パスの指定ミスはFailed to readで分かる。
mTLS（クライアント証明書）認証が必要な環境
金融機関や大企業のセキュリティポリシーが厳しい環境だと、サーバー証明書の検証だけでなく、クライアント側も証明書を提示して自分の身元を証明する「相互TLS（mTLS）」を要求されることがある。この構成は他の解説記事ではほぼ触れられていないが、Claude Codeは公式に対応している。
# クライアント証明書
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を再起動すること。有効期限が切れる前に新しい証明書に差し替えておかないと、古いペアを読み込んだまま接続エラーになる。
MCPサーバー・バックグラウンドエージェントで設定が反映されない問題
ここが実務でかなりハマりやすいポイントだと思う。ターミナルでclaudeを起動して通常のチャットは問題なくプロキシ経由で動くのに、MCPサーバーだけ外部に繋がらない、あるいはclaude agentsのバックグラウンドセッションだけ挙動が違う、というケースがある。
原因は環境変数の伝播範囲にある。シェルでexportしたプロキシ変数は、そのシェルから起動したプロセスにしか伝わらない。MCPサーバーは.mcp.jsonで定義された別プロセスとして起動するので、シェルの環境変数をそのまま引き継ぐとは限らない。プロキシ経由の通信が必要なMCPサーバーには、サーバーのエントリに直接envで書く必要がある。
{
"mcpServers": {
"some-server": {
"command": "npx",
"args": ["-y", "@example/mcp-server"],
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NODE_EXTRA_CA_CERTS": "/path/to/corp-ca.pem"
}
}
}
}MCPサーバーの接続トラブル全般（Failed to connectや承認待ちで止まる問題など）はさらに幅が広いので、症状別の切り分けを別記事にまとめてある。プロキシ以外の原因を疑うならこちらも合わせて見ておくと早い。
さらに厄介なのが、claude agentsや--bg、/backgroundで動くバックグラウンドセッションだ。これらはターミナルの中では動いておらず、ユーザーごとに1つ立ち上がる「supervisor」という常駐プロセスが実体になっている。このsupervisorは最初にどのシェルから起動されたかによって環境変数を引き継ぐかどうかが変わり、OSのサービスとしてインストールされたsupervisorに至ってはシェルの環境変数を一切受け取らない。
つまり「あるシェルではプロキシ変数をexportしてからバックグラウンドセッションを起動したので動いた」「別のシェルから起動したら同じ設定のはずなのに繋がらなかった」という再現性のない不具合が起きうる。これを避ける方法はひとつで、プロキシ・証明書・mTLS関連の環境変数はすべてシェルのexportではなく、~/.claude/settings.json（または管理者が配布するmanaged settings）のenvブロックに書くこと。すべてのマシン・すべてのバックグラウンドセッションに確実に届く設定方法はこれしかない、と公式ドキュメントでも明言されている。
社内で全員に同じランチャースクリプトを経由させる強めのポリシーを敷いている場合はprocessWrapperという設定キー（またはCLAUDE_CODE_PROCESS_WRAPPER環境変数）でラッパーコマンドを指定する仕組みもある。ここまでくると個人の設定というより組織のIT管理者側のタスクになるので、興味があれば公式の企業ランチャー向けドキュメントを参照してほしい。
Docker・VPS上のClaude Codeでプロキシを使う場合
コンテナやVPS上でClaude Codeを動かしている場合も考え方は同じで、コンテナ内のシェルまたは実行ユーザーのsettings.jsonにプロキシ・証明書関連の環境変数を渡してやればいい。Dockerであればdocker runの-eオプションやdocker-compose.ymlのenvironmentセクションでコンテナに環境変数を渡す形になる。VPS上に直接インストールしている場合は、そのVPSが社内ネットワーク経由でしか外に出られない構成なのかどうかを先に確認しておくと、無駄なプロキシ設定を追加せずに済む。
Docker Compose環境でのClaude Codeの実践的な組み方は別記事にまとめてあるので、コンテナ側の設計から見直したい場合はそちらを参照してほしい。
記事が見つかりません:
社内ネットワークで許可すべきURL一覧
プロキシやファイアウォールの許可リストを整備する担当者向けに、Claude Codeが通信する主なホストをまとめておく。特に閉域network・コンテナ環境では、これを先にIT部門へ渡しておくと後々の手戻りが減る。
| ホスト | 用途 |
|---|---|
api.anthropic.com | Claude APIへのリクエスト全般、WebFetchの安全性チェック |
claude.ai / platform.claude.com | アカウント認証（claude.ai / Anthropic Console） |
mcp-proxy.anthropic.com | claude.ai経由のMCPコネクタ通信 |
downloads.claude.ai | プラグイン・ネイティブインストーラーのダウンロードと自動更新 |
registry.npmjs.org | npm/bunでのインストール、プラグインの依存パッケージ、npx起動のMCPサーバー |
raw.githubusercontent.com | changelogフィード（/release-notes） |
storage.googleapis.com | プラグインのメタデータ、アーティファクトのアップロード |
formulae.brew.sh | Homebrewインストール時のバージョンチェック |
code.claude.com | ドキュメント参照エージェント・WebFetchのドキュメント検索 |
npm/bun経由でインストールした場合はregistry.npmjs.org、ネイティブインストーラーの場合はdownloads.claude.aiが必須になるという違いがあるので、自社の導入方法に合わせて確認するといい。最新かつ完全な一覧は公式ドキュメントの表で随時更新されているので、許可リストを作る前に一度目を通しておくのが確実だ。
VS Code拡張機能でのプロキシ設定
VS Code上でClaude Code拡張を使っている場合、拡張機能自体はVS Code本体のプロキシ設定（http.proxy）を参照する。CLI側の環境変数を設定しただけではVS Code拡張には反映されないことがあるので、settings.json（VS Codeの設定ファイル、Claude Codeのものとは別）で以下も合わせて確認しておくといい。
{
"http.proxy": "https://proxy.example.com:8080",
"http.proxyStrictSSL": true
}proxyStrictSSLをfalseにすると証明書検証自体をスキップできるが、これはあくまで切り分け用の一時対応で、本番の運用としては推奨しない。まずは社内CA証明書を正しく信頼させる方向で解決し、それでもダメな場合の最終手段くらいに考えておいたほうがいい。
それでも繋がらない時のチェックリスト
ここまでの設定をひと通り試しても直らない場合、次の順番で切り分けるとよい。
claude --debugでデバッグログを開き、プロキシ・CA証明書・mTLS関連の行がどう出ているか確認する/statusでProxyとAdditional CA cert(s)の行を確認し、値が「invalid」扱いになっていないか見るcurl単体でプロキシ経由の疎通を確認する（curl -v -x $HTTPS_PROXY https://api.anthropic.com）。ここで失敗するならClaude Code以前にネットワーク側の問題node --versionでNode.jsのバージョンを確認し、22.15未満ならOS証明書ストアの自動信頼が効かない前提でNODE_EXTRA_CA_CERTSを必ず設定する- ターミナルでは動くのにMCP・バックグラウンドだけダメな場合は、環境変数をシェルの
exportではなくsettings.jsonのenvブロックに移す - 途中で会話が急に切れる・接続が切られる症状が別途あるなら、社内プロキシ経由でよく報告されているタイムアウト誤発火のバグを踏んでいる可能性もある
FAQ
会社のPCでClaude Codeを使うこと自体は許可されていないと動かない？
技術的な設定とは別に、会社の情報セキュリティポリシー上の利用可否は必ず確認しておくこと。この記事はあくまで「プロキシ環境下で技術的に接続を通す方法」を扱っていて、利用許可そのものを与えるものではない。
NODE_EXTRA_CA_CERTSとCLAUDE_CODE_CERT_STOREはどちらを使うべき？
まずCLAUDE_CODE_CERT_STOREのデフォルト挙動（bundled,system）でOS証明書ストア経由の自動信頼を試す。Node.jsのバージョンが古い、あるいはOS証明書ストアに社内CAがまだ登録されていない場合にのみNODE_EXTRA_CA_CERTSで個別指定する、という優先順位で考えるとシンプルになる。
自宅では普通に使えるのに、会社のPCだけ毎回設定し直すのが面倒
settings.jsonはスコープが分かれていて、ユーザー全体の設定（~/.claude/settings.json）に会社用のプロキシ設定を書いてしまうと自宅でも常に有効になってしまう。プロジェクトごとに切り替えたいなら、プロジェクト直下の.claude/settings.local.json（gitignore対象にできる個人用ファイル）に会社用の設定だけ書き分けるほうが運用しやすい。
まとめ
Claude Codeが社内プロキシで動かない問題は、突き詰めると「プロキシの場所を教えているか」と「プロキシが差し替えた証明書を信頼しているか」の2点に集約される。2026年時点では、OS証明書ストアの自動信頼のおかげでNODE_EXTRA_CA_CERTSを手動で設定しなくても繋がるケースが増えているので、まずはNode.jsのバージョンとCLAUDE_CODE_CERT_STOREのデフォルト挙動を疑ったほうが手戻りが少ない。
MCPサーバーやバックグラウンドエージェントは別プロセス・別プロセス群として動いている関係で、シェルのexportだけでは設定が届かないことがある。プロキシ・証明書関連の環境変数はできるだけsettings.jsonのenvブロックに寄せておくのが、結局いちばん再現性のある解決策だと思う。
