昨日まで動いていたClaude Codeが突然起動しなくなった話

朝、いつものようにPowerShellを開いてclaudeと打ち込んだら、こんなエラーが出ました。

claude: The term 'claude' is not recognized as a name of a cmdlet,
function, script file, or executable program.

昨日まで問題なく使えていたのに、です。

こういうとき、エンジニアは「何も変えてないのに…」と思いがちですが、正直に言うと何かが変わっているんですよね。問題は、自分が変えたのか、ツール側が変わったのか、それとも環境が変わったのか。

最初は「Windows Updateでも走ったのかな」と思いましたが、直感的に「それは違う気がする」と感じました。

問題の切り分け：まずは再インストールしてみる

エラーメッセージを読むと、claudeというコマンドが「存在しない」と言われています。つまり、Windowsがこのコマンドをどこにも見つけられない状態です。

とりあえず公式のインストールコマンドを実行してみました。

irm https://claude.ai/install.ps1 | iex

すると、インストール自体は成功するのですが、最後にこんな警告が出ました：

✅ Installation complete!

‼ Setup notes:
  • Native installation exists but C:\Users\[username]\.local\bin
    is not in your PATH. Add it by opening: System Properties →
    Environment Variables → Edit User PATH → New → Add the path above.
    Then restart your terminal.

「PATHが通っていない」

ここで少し引っかかりました。というのも、以前インストールしたときはこんなメッセージは出なかったからです。

PATHとは何か（意外とここが肝です）

念のため説明しておくと、PATHは「Windowsがコマンドを探す場所のリスト」です。

たとえば、あなたがclaudeとだけ入力したとき、Windowsは以下のような順番で探します：

もしPATHに登録されていないフォルダに実行ファイルがあっても、Windowsは「そんなコマンド知らない」と返すわけです。

つまり、claude.exeは存在するけど、Windowsがそれを見つけられない状態だったということです。

応急処置：とりあえず動かす

作業を再開したかったので、まずはPowerShellで環境変数を設定しました。

[Environment]::SetEnvironmentVariable(
  "Path",
  $env:Path + ";C:\Users\[username]\.local\bin",
  "User"
)

PowerShellを再起動すると、無事にclaudeコマンドが動きました。

でも、ここで終わりにはしたくありませんでした。

なぜ、昨日まで動いていたのに、今日はPATHを通す必要があったのか？

根本原因を探る：公式ドキュメントを読む

正直、ここで少し詰まりました。検索しても同じ問題に遭遇している人の記事がすぐには見つからなかったからです。

それで、公式ドキュメントを丁寧に読み直してみたところ、こんな一文を見つけました。

"Some users may be automatically migrated to an improved installation method."

これだ、と思いました。

つまり、一部のユーザーが自動的に改善されたインストール方法に移行されるということです。

ここでパズルのピースがはまりました。

昨日までの状態

今日の状態

つまり、Claude Codeの自動アップデートによって、インストール方法自体が変わったわけです。

なぜnpmからネイティブインストールに？

ここで疑問が湧きました。なぜわざわざ移行する必要があったのか？

npm経由のインストールには、実はいくつかの問題があります：

一方、ネイティブインストールは：

技術的には、ネイティブインストールの方が理にかなっています。

でも、移行のタイミングが予告なしだったので、朝からちょっと焦りました。いつもの道が突然通行止めになったような感覚です。

同じ問題に遭遇したら

もし同じ問題に遭遇した場合、以下の手順で解決できます。

1. すぐに使いたい場合（一時的）

フルパスで実行：

C:\Users\[username]\.local\bin\claude.exe

または、現在のセッションだけPATHを通す：

$env:Path += ";C:\Users\[username]\.local\bin"
claude

2. 恒久的に解決したい場合（推奨）

PowerShellで環境変数を設定：

[Environment]::SetEnvironmentVariable(
  "Path",
  $env:Path + ";C:\Users\[username]\.local\bin",
  "User"
)

実行後、必ずPowerShellを再起動してください。

GUIで設定したい場合は：

ツールの進化と利用者体験のバランス

今回の件で改めて考えたのは、ツールの進化は必ずしもスムーズではないということです。

開発者側としては、より良いアーキテクチャに移行したい。依存関係を減らし、メンテナンス性を上げたい。それは正しい判断です。

でも、利用者側からすると、「昨日まで動いていたものが突然動かなくなる」というのは、朝の作業開始時には結構なストレスです。

正直に言うと、移行の事前通知があったかどうかも分かりません。

リリースノートに書いてあったかもしれないし、メールが来ていたかもしれない。でも、日常的に使っているツールのリリースノートを、いちいち細かくウォッチしているかと言われれば、していません。

これは私が悪いのか？と言われれば、そうかもしれません。でも、それが現実的なツールの使い方だとも思います。

毎日使うツールが10個、20個とあったとして、そのすべてのリリースノートを追いかけるのは現実的ではありません。GitHubのReleasesをウォッチして、Discordのアナウンスチャンネルをチェックして、公式ブログを定期的に読んで…なんてやっていたら、本来の作業が進みません。

結局のところ、ツールを使う側としては「何か問題が起きたら調べる」というスタンスにならざるを得ないんだと思います。

これは開発側からすれば不本意かもしれません。せっかく丁寧にリリースノートを書いても、読まれない。移行ガイドを用意しても、問題が起きてから初めて参照される。

でも、それがツールとユーザーの関係性なんだろうなと、今回改めて感じました。

次に備えて

とはいえ、今回の経験から、いくつか習慣を見直そうと思いました：

「定期的にリリースノートを確認しよう」と書こうと思いましたが、正直それは習慣化できる自信がありません。現実的に続けられることだけを挙げました。

もし同じ問題に遭遇した方がいたら、この記事が参考になれば幸いです。

関連書籍

Claude Codeをより深く理解したい方には、以下の書籍がおすすめです。