claude インストール プロキシ設定|社内PCで通信失敗を直す手順
会社のPCではClaudeをブラウザで開けるのに、インストールコマンドや初回ログインだけが失敗することがあります。社内プロキシの影響を疑っても、Windowsの設定、ターミナルの環境変数、証明書のどこを見ればよいか迷いがちです。この記事ではClaude Codeを対象に、ダウンロードから起動後の通信までを分け、環境別の確認順序と管理者へ相談する情報を整理します。
Claude Codeは社内プロキシ経由で導入・利用できる。インストーラー側の接続設定と起動前のHTTPS_PROXY、社内CA、許可ドメインを別々に確認し、ダウンロード・認証・API通信の失敗箇所を分ければ、証明書検証を無効にせず必要な対処を判断できる。
Contents (7)
claudeのインストールはプロキシのどこで止まる?
検索で多いのは、ターミナルから使うClaude Codeの導入トラブルです。Claude Desktopのアプリ設定とは扱いが異なるため、まず実行したコマンドと利用環境を確認しましょう。
通信は大きく三つに分かれます。インストール用スクリプトと本体の取得、ブラウザを使う認証、起動したClaude CodeからのAPI通信です。ブラウザが社内の自動プロキシ設定を使えても、curlやターミナルのプログラムが同じ経路を使うとは限りません。
管理者にはプロキシのURL・ポート、認証方式、TLS検査の有無、配布されたCA証明書を確認します。PACファイルのURLとプロキシサーバーのURLは別物なので、HTTPS_PROXYに指定できる接続先を確認してください。
公式の設定仕様はエンタープライズネットワーク設定で確認できます。
起動前にHTTPS_PROXYを設定する
Claude CodeはHTTPS_PROXY、HTTP_PROXY、NO_PROXYに対応しています。URLのスキームは管理者から指定されたプロキシ方式に合わせます。HTTPS通信を中継する場合でも、接続先がHTTPプロキシなら値はhttp://から始まります。
WindowsのPowerShellでは、次のように現在のプロセスの環境変数を設定します。以下のホスト名・ポートは例であり、社内の値へ置き換えてください。
$env:HTTPS_PROXY = "http://proxy.example.com:8080"
$env:HTTP_PROXY = "http://proxy.example.com:8080"
macOS・Linux・WSLのシェルでは次の形です。
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
- 管理者に確認したプロキシURLを、Claude Codeを起動するターミナルで設定する。
- 小文字のhttps_proxyやhttp_proxyに古い値が残っていないか確認する。
- 起動中のClaude Codeを終了し、設定したターミナルから起動し直す。
小文字のhttps_proxyが大文字より優先されるため、大文字だけの変更では古い値が使われる場合があります。NO_PROXYは社内方針に合わせ、「*」による全通信の除外は避けます。SOCKSプロキシは対応対象外です。
インストーラーとClaude Codeの設定を分ける
公式推奨のネイティブインストールならNode.jsの別途導入は不要です。ただし、Claude Code用の環境変数だけで、取得ツールの通信まで通るとは限りません。
macOS・Linux・WSLでの公式コマンドは次のとおりです。
curl -fsSL https://claude.ai/install.sh | bash
Windows PowerShellでは次のコマンドが案内されています。
irm https://claude.ai/install.ps1 | iex
- OSとシェルに合うコマンドを公式セットアップで確認する。
- スクリプト取得に失敗したら、curlまたはPowerShellの取得処理で使うプロキシ・証明書設定を確認する。
- スクリプト取得後に本体のダウンロードが失敗したら、配布先への通信許可を確認する。
- 導入後は新しいターミナルを開き、プロキシ設定を引き継いでバージョンを確認する。
PowerShellの取得処理には、組織指定の接続方法やOSの信頼設定も確認します。取得ツールとClaude Code本体は別のプログラムなので、疎通は個別に確認してください。
証明書エラーは社内CAを信頼させる
TLS通信を社内で検査する場合、企業の認証局を端末側で信頼する必要があります。エラーが出たら、どのプログラムの証明書検証が失敗したかを確認しましょう。
現在の公式仕様では、Claude Codeは同梱のCAとOSの証明書ストアを利用します。OSストアの読み取りには対応ランタイムが必要で、ネイティブインストールでは対応済み、npm経由ではNode.js 22.15以降が必要とされています。
追加のCAを明示する場合は、管理者が配布したPEM形式のファイルを指定します。
$env:NODE_EXTRA_CA_CERTS = "C:\certs\company-ca.pem"
export NODE_EXTRA_CA_CERTS="/path/to/company-ca.pem"
- 管理者から正しいCA証明書と適用方法を受け取る。
- 起動環境から読める場所に保存し、ファイルパスを指定する。
- Claude Codeを起動し直し、証明書エラーが解消したか確認する。
NODE_EXTRA_CA_CERTSはcurlやPowerShellの信頼設定まで変更しません。取得時のエラーは取得ツール側で確認します。証明書検証の無効化に頼らず、信頼するCAを正しく追加してください。
認証方式と許可ドメインを管理者と確認する
プロキシ認証とClaudeのログインは別です。Basic認証ではURLに認証情報を含める方式がありますが、パスワードのスクリプトへの固定やリポジトリへの登録は避けます。
NTLM・Kerberosが必要な環境ではBasic認証の例をそのまま使えません。管理者と、対応する社内ゲートウェイなどの構成を確認します。クライアント証明書によるmTLSも別の仕組みです。
| 通信の段階 | 主な確認先 | 確認する内容 |
|---|---|---|
| 導入・更新 | claude.ai、downloads.claude.ai | スクリプトとネイティブ本体の取得 |
| アカウント認証 | claude.ai、claude.com、platform.claude.com | ブラウザのサインインとトークン交換 |
| API通信 | api.anthropic.com | 起動後のリクエスト |
| npm経由の導入 | registry.npmjs.org | パッケージ取得または社内ミラー |
表は直接Anthropicへ接続する際の主な宛先です。追加機能や別のクラウド基盤では通信先も変わるため、公式のネットワークアクセス要件を管理者へ共有してください。
WSL・VS Codeでは起動環境をそろえる
WSLはWindowsとは別のLinux環境です。Windows側に環境変数やCAを設定しても、WSL側へ同じ設定が適用されているとは限りません。CAファイルのパスも、Windows形式とLinux形式を混同しないようにします。
- WindowsネイティブかWSLか、Claude Codeを動かす環境を一つ決める。
- 選んだ環境内でプロキシとCAを設定し、ターミナルから疎通を確認する。
- VS Codeから使う場合は、拡張機能やターミナルがどちらの環境で動いているか確認する。
- 設定変更後は必要なアプリを起動し直し、同じ環境で再確認する。
継続利用する設定は~/.claude/settings.jsonのenvでも管理できます。既存設定を保持して必要なキーを追加し、JSON内のWindowsパスはバックスラッシュを二重に書きます。
ただし、このファイルはインストール前の取得ツールの設定には使えません。また、Desktopが接続を管理する一部のセッションでは読み取る設定スコープに制限があるため、CLIとDesktopの設定を同一視しないでください。
エラーを段階別に切り分けて接続を確認する
再インストールの前に、エラー全文と発生段階を確認します。同じ「接続できない」でも、設定ミスと認証失敗では相談先が変わります。
| 症状 | 最初に確認すること |
|---|---|
| 名前解決失敗・タイムアウト | プロキシURL、ポート、接続先の許可 |
| 407 Proxy Authentication Required | プロキシの認証方式と資格情報 |
| 証明書検証エラー | 社内CAの適用先、形式、読み取り権限 |
| claudeが見つからない | インストール結果とPATH |
| ログインだけ失敗 | 認証先への通信とアカウント設定 |
- claude --versionで本体が導入できたことを確認する。
- claude doctorでインストールと設定の診断を読む。
- claudeを起動して認証し、機密情報を含まない短い質問でAPI通信を確認する。
- 解決しなければclaude --debugでログを確認し、管理者へ発生段階とエラーを伝える。
バージョン表示だけではAPIへ接続できた証明になりません。ログを共有するときは認証情報などを除き、取得・認証・利用のどこが成功したかを添えると、必要なプロキシ設定や通信許可を特定しやすくなります。