CLAUDE_CODE_CERT_STORE（クロードコード・サートストア）

会社支給のパソコンや社内ネットワークでClaude Codeを使おうとして、SSL・証明書エラーで止まった人向け

会社支給のパソコンでClaude Codeを初めて起動したら、いきなりSSL証明書エラーで止まった。そんな経験をした人向けの設定値が CLAUDE_CODE_CERT_STORE です。会社の社内ネットワークには、社員のインターネット通信を一度受け止めて中身を検査する「TLSプロキシ」という中継サーバーが置かれていることが多く、ここが原因でClaude Codeの通信が弾かれていました。

v2.1.101 のアップデートで、Claude Code は起動したパソコン自体が持っている証明書の信頼リストをそのまま信じるようになりました。これで会社の中継サーバーがあっても、追加設定なしで通信が通ります。CLAUDE_CODE_CERT_STORE は、その自動の信頼をあえて止めたいときだけ触る設定です。

噛み砕くと

新しい職場に初日に行くと、受付で「この人は社員です」と保証してくれる人がいないと中に入れてもらえません。会社の中継サーバーは、いわばこの「保証してくれる人」を会社独自のものに差し替えています。

パソコンのOSは、誰を信用していいかを書いた名簿を最初から持っています。会社のパソコンには、IT部門がそこに「うちの中継サーバーは信用していい」と書き足してあるのが普通です。

v2.1.101 からのClaude Codeは、この名簿をそのまま読むようになりました。だから会社の中継サーバーも自動で信用できる。CLAUDE_CODE_CERT_STORE に bundled を入れると、この名簿を見るのをやめて、Claude Codeが自分で持ってきた小さな名簿だけを見るようになります。

つまり普段はいじらない設定です。

大事な前提：この設定は「普段いじらない」のが正解

ここで先に言っておきたいのは、ほとんどの人はこの設定を触る必要がないという点です。v2.1.101以降のClaude Codeは、何も指定しなければOSの名簿を自動で信用します。社内の中継サーバー越しでもそのまま通る。

触るのは逆方向、つまり「自動の信用をあえて止めたい」という限られた場面だけです。だから設定エラーで困っている人がまず確認すべきは、この設定値ではなく、使っているバージョンの方です。

「会社支給PCで社内プロキシ越しに使う」を例に、実際の手順を見る

会社から渡されたパソコンで、社内ネットワーク越しにClaude Codeを初めて動かす場面を順に追います。多くの人がSSL証明書エラーで最初につまずく場面です。

ステップ1: 初回起動でエラーが出る

インストール直後、ログインしようとすると通信が止まり、証明書まわりのエラーメッセージが出ます。会社の中継サーバーが間に入っていて、Claude Codeがその証明書を信用できていない状態です。

$ claude
Error: unable to verify the first certificate / self-signed certificate in certificate chain

ステップ2: まずバージョンを確認する

ここで設定をいじる前に、使っているバージョンを見ます。これが古いと、そもそもOSの名簿を読む機能が入っていません。

$ claude --version

返ってきた番号が 2.1.101 より前なら、原因はバージョンの古さです。ここで初心者がやりがちな勘違いがあります。エラー文に「certificate」と出ているからといって、いきなり CLAUDE_CODE_CERT_STORE を設定しにいくと、後で書くとおり逆効果になります。

ステップ3: 古ければアップデートする

バージョンが古かったら、まず新しくします。インストール方法によって更新のやり方は変わりますが、目的は v2.1.101 以降にすることです。

$ claude update

ステップ4: もう一度起動する

新しいバージョンになったら、再度起動します。v2.1.101以降なら、OSの名簿に会社の中継サーバーの証明書が登録されている限り、追加設定なしで通信が通ります。会社支給機ならIT部門がその登録を済ませているのが普通です。

$ claude

これで通ればゴール。多くの会社環境はここで解決します。

ステップ5: 今の設定状態を確認する

自分のパソコンでこの設定値がどうなっているかは、次の1行で見られます。

$ echo $CLAUDE_CODE_CERT_STORE

何も返ってこなければ未設定、つまりデフォルトの「OSの名簿を信用する」状態です。社内の中継サーバー環境では、この空っぽの状態が正解です。

ステップ6: bundled を入れるとどうなるか（社内環境では入れない）

仮にここで bundled を入れると、Claude Codeは会社の名簿を見るのをやめ、自分が持ってきた小さな名簿だけを見ます。会社独自の証明書はそこに入っていないので、社内の中継サーバー環境では再びエラーになります。

$ export CLAUDE_CODE_CERT_STORE=bundled

社内プロキシ環境では、これは入れてはいけない設定です。入れるのは別の動機があるときだけで、それは後半で書きます。

つまり CLAUDE_CODE_CERT_STORE は何をしてくれるのか

• やってくれる: bundled を入れたとき、Claude Codeに同梱された証明書だけを信用する状態に切り替える。OSの名簿を見にいかなくなる
• やってくれない: 証明書エラーそのものを直してはくれない。社内環境でエラーが出ているとき、この設定を bundled にしても解決しない（むしろ悪化する）
• 意味が薄い場面: 個人のパソコンで普通に使う人。デフォルトのまま何もしなくていい。触る必要がそもそもない

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 会社支給のノートPCで初めて起動したらSSL証明書エラーが出たとき

社内ネットワーク越しに起動して証明書エラーが出た。このときの正解は、この設定を触ることではなく、claude --version でバージョンを見ることです。2.1.101より前なら更新して再起動。多くの場合これだけで通ります。会社のIT部門がOSの名簿に中継サーバーの証明書を登録済みだからです。

シナリオ2: セキュリティが厳しい部署で、OSの名簿を信用したくないとき

金融や医療など、パソコンのOSの名簿に勝手に足された証明書まで丸ごと信用するのを避けたい部署があります。この場合だけ export CLAUDE_CODE_CERT_STORE=bundled を入れて、Claude Code同梱の名簿だけに絞る判断があります。ただし社内の中継サーバーを通している環境なら通信が止まるので、中継サーバーがない直接接続の環境が前提です。

シナリオ3: 自宅の個人PCで趣味の開発に使うとき

自宅のWi-Fiで自分のMacからClaude Codeを使う、というよくある場面では、この設定の出番はありません。echo $CLAUDE_CODE_CERT_STORE が空っぽのまま、つまりデフォルトで問題なく動きます。むしろここで bundled を入れると、将来何かのツールを足したときに余計なエラーの種になります。触らないのが一番です。

初心者が踏みやすい落とし穴

• 「証明書エラーが出たら bundled にすれば直る」は完全に逆。bundled は会社独自の証明書を無視するので、社内の中継サーバー環境ではむしろ弾かれます。社内環境では未設定が正解です
• 設定を触る前にバージョンを見ていない。v2.1.100以前はOSの名簿を自動で信用する機能がなく、社内プロキシで証明書エラーが起きやすかった。claude --version で確認し、古ければ更新が先です
• これを「証明書の検証を無効にしてエラーを握りつぶす設定」だと思い込む。検証を飛ばす危険な裏技とは別物で、bundled にしてもセキュリティは下がりません。信用する名簿を切り替えるだけです
• 個人のパソコンなのに念のため bundled を入れてしまう。一般の利用者にこの設定は不要です。デフォルトのまま何もしないのが正しい
• エラー文の「certificate」という単語だけ見て焦る。原因はたいてい中継サーバーかバージョンの古さで、この設定値そのものではありません
• 会社のIT部門に確認せず自己判断で値をいじる。会社支給機の名簿はIT部門が管理しているので、エラーが続くならまず相談したほうが早い場合があります

書き方

export CLAUDE_CODE_CERT_STORE=bundled

やってみるとこうなる

入力

echo $CLAUDE_CODE_CERT_STORE

出力例

何も表示されない（＝未設定。OSの名簿を信用するデフォルト動作。社内の中継サーバー環境ではこの状態が正解）

関連項目

• Sandboxing（サンドボックス）
• settings.json（セッティングス・ジェイソン）
• /login（ログイン）
• /claude-code-subprocess-env-scrub（準備中）

公式ドキュメント

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md