「npm install -g @anthropic-ai/claude-code を走らせたのに、claude --version を打つと先週と同じ番号が返ってくる」— この症状で 30 分以上溶かした方も多いのではないでしょうか。私自身、新機能のリリースノートを見て試そうとしたのに、ローカルが旧バージョンのままで動かず、何度も入れ直した経験があります。
Claude Code の自動アップデートが効かないように見える時、原因はだいたい 3 つに集約されます。PATH の衝突、別バイナリのキャッシュ、そしてシェル環境のバージョン切替です。ここでは闇雲に再インストールを繰り返す前に、原因を 5 分で切り分けるための診断フローと、ケース別の確実な対処法をまとめました。
まず最初に確認すべき 3 行
時間がない方は、ターミナルでこの 3 つだけ走らせてみてください。多くの場合、ここで原因の見当がつきます。
# 実際に呼ばれているバイナリのパス
which claude
# npm がグローバルパッケージを置いている場所
npm root -g
# Claude Code 自身の自己診断
claude doctorwhich claude で返ってきたパスと、npm root -g の親ディレクトリ（bin/ を含む側）が一致していなければ、npm install -g で更新したバイナリと、シェルが実際に呼んでいるバイナリが別物だということです。これが「アップデートしたのに反映されない」の最も多いパターンです。
なぜ起きるのか — よくある 3 つの構図
1. Homebrew 経由と npm 経由が共存している（macOS で頻発）
Homebrew で brew install claude-code（あるいは類似のフォーミュラ）を入れた後に npm でも入れ直した、あるいはその逆をやった場合、/opt/homebrew/bin/claude と ~/.npm-global/bin/claude の両方が PATH に存在することになります。echo $PATH で前に来ている方が優先されますので、npm 側を更新しても Homebrew 側が呼ばれ続けるわけです。
2. nvm を使っていて、別の Node バージョン配下にインストールされている
nvm（Node Version Manager）を使っている方は要注意です。Node を切り替えるたびに、グローバルパッケージの保存場所も ~/.nvm/versions/node/v20.x.x/bin/ のように切り替わります。nvm use 20 の状態で npm install -g し、その後 nvm use 22 に変えたまま claude を呼ぶと、v22 配下にはインストールされていない（あるいは古い）バイナリが使われます。
3. ~/.claude/local に古い自己更新キャッシュが残っている
Claude Code はバージョンによって、~/.claude/local/ 配下に自身の最新版をキャッシュし、そこから起動するスタイルを採ることがあります。このキャッシュが壊れていたり、ネットワーク問題で書き換えに失敗したまま残ると、CLI ラッパーは新しい npm パッケージを見ても、ローカルキャッシュの方を優先してしまいます。
段階的な診断フロー
ここからは、上の 3 行で原因が絞れなかった場合の追加診断です。順番に実行していけば、ほぼすべてのケースで問題箇所が特定できます。
ステップ 1: バイナリの実体を全部洗い出す
# PATH 上にある claude 実行ファイルを全部列挙
type -a claude
# 例: 出力
# claude is /opt/homebrew/bin/claude
# claude is /Users/you/.npm-global/bin/claudetype -a claude は、which と違って PATH 上のすべての候補を列挙してくれます。2 つ以上出てきたら、それが「アップデートが効いていないように見える」直接の原因である可能性が高いです。
ステップ 2: 実際に起動しているバイナリのバージョンを個別に確認
/opt/homebrew/bin/claude --version
/Users/you/.npm-global/bin/claude --versionそれぞれを絶対パスで呼んで、どちらが新しいかを比べます。ここで「新しい方は確かに更新できている、古い方は放置されている」という構図がはっきり見えます。
ステップ 3: シェル設定ファイルで PATH の順序を確認
grep -nE "PATH" ~/.zshrc ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null意図したディレクトリが先に来ているか、設定ファイルを横断的にチェックします。~/.zshrc で追加した後に ~/.zprofile で別の PATH を上書きしている、というのも実によくある事故です。
ステップ 4: claude doctor で公式の自己診断
claude doctorclaude doctor は CLI が依存している Node のバージョン、設定ファイルの整合性、認証トークンの有効性などを一括で確認してくれます。少し前のバージョンから「Auto-update path conflict」のような警告が出るようになり、どのパスが衝突しているのかを直接教えてくれることもあります。
ケース別の対処法
Case A: Homebrew と npm の二重インストール
私はこの 1 年で何度かやらかしました。結論としては、インストール経路を 1 つに絞るのが一番楽です。npm 側を残すのが Anthropic 公式のおすすめなので、Homebrew 側を抜く例を書きます。
# Homebrew 側を削除（インストール経路を統一）
brew uninstall claude-code 2>/dev/null
# 念のため残骸を削除
sudo rm -f /opt/homebrew/bin/claude /usr/local/bin/claude
# npm で最新版を入れ直す
npm install -g @anthropic-ai/claude-code@latest
# 確認
which claude
claude --version判断のポイント: Homebrew 経由を残したい方もいると思います。ただ、Claude Code は Anthropic 側のリリースサイクルが速く、Homebrew のフォーミュラ更新がワンテンポ遅れることがあります。最新機能をすぐ試したい開発者は、npm に寄せる方が体験は安定します。
Case B: nvm を使っているケース
nvm 環境では、グローバルパッケージは Node のバージョンごとに分離されています。特定のバージョンに固定して運用するのが現実的です。
# 普段使う Node のバージョンに固定
nvm alias default 22
nvm use 22
# その上で再インストール
npm install -g @anthropic-ai/claude-code@latest
# 確認: バイナリのパスに v22.x.x が入っていれば OK
which claude複数バージョンを併用したい場合は、起動シェルで nvm use を必ず通す運用にしておくと、「ターミナルを開き直したら旧バージョンに戻った」という事故を防げます。
Case C: ~/.claude/local キャッシュの破損
自己更新キャッシュが壊れていると思われる時は、思い切ってキャッシュを消すと早いです。設定ファイル（~/.claude/settings.json や認証情報）はキャッシュとは別のディレクトリにあるので、local/ 配下だけ消せば認証はやり直しになりません。
# 自己更新キャッシュだけクリア（settings.json は触らない）
rm -rf ~/.claude/local
# 起動して再ダウンロードさせる
claude --versionただし、起動時に「local キャッシュをダウンロード中…」のメッセージが長時間止まる場合は、次の Case D（プロキシ問題）の可能性が高いです。
Case D: 企業プロキシ・SSL 自己署名証明書による更新失敗
社内ネットワーク配下で動かしている場合、自動更新が黙って失敗していることがあります。npm の取得自体は通るのに、CLI が直接アクセスする更新エンドポイントがプロキシでブロックされる、というパターンです。
# まず npm 側のプロキシ設定を確認
npm config get proxy
npm config get https-proxy
# CA 証明書のパスを通す（社内 CA が必要な場合）
export NODE_EXTRA_CA_CERTS=/path/to/corp-ca-bundle.pem
# 自動更新だけ一旦止めて、手動更新運用に切り替える
# settings.json: "autoUpdates": falseautoUpdates: false にしておくと、勝手に更新を試みなくなりますので、npm install -g @anthropic-ai/claude-code@latest を意図的に走らせた時だけバージョンが上がる、という分かりやすい運用になります。詳しい設定キーは、Claude Code の settings.json 完全ガイド を併せて参照ください。
Case E: それでも直らない時の最後の手段
ここまで試しても古いバージョンが返ってくる場合、構成が複雑になりすぎている可能性があります。次のように、関連ファイルを一度全部きれいにしてから入れ直すと、ほぼ確実にリセットできます。
# すべての残骸を削除（認証情報も消えるので注意）
npm uninstall -g @anthropic-ai/claude-code
sudo rm -f $(which -a claude)
rm -rf ~/.claude/local
# 認証だけは保存しておきたい場合は事前にバックアップ
cp ~/.claude/auth.json ~/claude-auth.backup.json 2>/dev/null
# クリーンインストール
npm install -g @anthropic-ai/claude-code@latest
claude --version~/.claude/auth.json をバックアップしておけば、再認証が必要になっても 30 秒で元の状態に戻せます。ここまでやって直らない場合は、Node のバージョン自体が古すぎる（Node 18 未満）可能性もあるので、node --version も合わせて確認してみてください。
自動アップデートを意図的に止めたい場合
CI/CD 環境や本番運用しているスクリプト内では、勝手にバージョンが上がられると困ることがあります。その場合は明示的に無効化しておきましょう。
~/.claude/settings.json（あるいはプロジェクト直下の .claude/settings.json）に次を追加します。
{
"autoUpdates": false
}これでセッション起動時の更新チェックが走らなくなります。バージョンを上げたい時は、npm install -g @anthropic-ai/claude-code@<version> で明示的に指定する運用にすると、再現性が一段上がります。CI でロックダウンしたい場合は、@anthropic-ai/claude-code@2.1.4 のようにマイナー固定するのが私の好みです。
なお、長期にわたって CI を運用する場合は、Claude Code 出力フォーマット JSON × CI/CD 連携 で紹介されているバージョン pin の考え方も参考になります。
似た症状で別原因のケースに注意
「アップデートが効かない」と思っていたら、実は別の問題だった、という落とし穴もあります。代表的なものを 2 つだけ挙げておきます。
- 新機能が
--allowedToolsなどのフラグでブロックされている: 新しいツールが追加されたのに、settings.jsonのallowedToolsホワイトリストに加わっていないと、機能自体が無効になっています。CLI のバージョンは新しいのに動作が古いままに見える典型例です。 - ターミナル側のシェルキャッシュが効いている: zsh/bash は実行ファイルのパスを内部にキャッシュします。
hash -r（bash）やrehash（zsh）を打つと、PATH の再評価が走って解決することがあります。
これらは Claude Code Hooks が発火しない時のトラブルシューティング と同じく、「設定が新しいのに挙動が古い」系の問題として一緒に頭に入れておくと、次にハマる時間が短くなります。
全体を振り返って — まず手元で 1 つだけやるなら
長くなりましたが、もし今すぐ何か 1 つだけやるとしたら、type -a claude を打って結果が 2 行以上ないか確認してください。これだけで、本記事の原因のうち最も多い「Homebrew × npm 二重インストール問題」と「nvm のバージョン切替問題」のどちらに該当するかが、ほぼ即座に切り分けられます。
複雑な再インストールに進む前に、まずは「実際に呼ばれている claude がどれか」を 30 秒で確かめる癖をつけておくと、次に同じ症状が出た時のリカバリ時間が劇的に短くなります。