Claude Code WSLインストールで出るエラー20種の直し方

Q: sudoでnpm installしてもいいですか？

避けてください。公式は sudo npm install -g を権限の問題とセキュリティ上のリスクにつながる操作として明確に非推奨としています。権限エラーが出るなら、npmのグローバル先を変更するよりネイティブインストーラーへ切り替えるほうが確実です。

Q: 「Exec format error」はどうすれば直りますか？

WSL1の既知の問題なので、PowerShellから wsl --set-version <DistroName> 2 でWSL2へ変換するのが確実です。WSL1に留まる必要があるなら、動的リンカ経由で起動する関数を ~/.bashrc に追加する回避策が公式に載っています。ただしWSL1ではサンドボックス実行が使えません。

Q: アンインストールして入れ直すにはどうしますか？

ネイティブ版なら rm -f ~/.local/bin/claude と rm -rf ~/.local/share/claude で本体を消せます。npm版は npm uninstall -g @anthropic-ai/claude-code です。設定まで消す場合は ~/.claude と ~/.claude.json も削除しますが、MCPサーバーの設定やセッション履歴が失われる点に注意してください。

WSLのターミナルでClaude Codeのインストールコマンドを流したのに claude が動かない、あるいはインストール自体が途中で落ちる。この症状は「WSLがWindows側のNode.jsやnpmを拾ってしまう環境の混在」「WSL1がネイティブバイナリを実行できない」「ダウンロードやメモリで止まる」の3系統に分かれ、どれに当たっているかはターミナルに出たエラー文言で判別できます。編集部はAnthropicの公式ドキュメントとMicrosoftのWSLドキュメントを突き合わせ、WSLで報告されているエラー20種を「症状→原因→打ち手」で整理しました。うち15種はインストールと起動の診断表に、残る5種はWindowsとWSLでコマンドを取り違えた時の一覧にまとめています。エラー文言をそのまま探して、一手ずつ当ててください。

この記事の要点

まず which node と which npm を実行します。パスが /mnt/c/ で始まっていればWindows側のバイナリを見ており、npm経由のエラーはほぼここが原因です。
公式の推奨はnpmではなくネイティブインストーラー（curl -fsSL https://claude.ai/install.sh | bash）で、WSLのターミナル内から実行します。PowerShellから流すコマンドではありません。
cannot execute binary file: Exec format error はWSL1の既知の問題です。wsl --set-version <DistroName> 2 でWSL2へ変換するのが確実な直し方になります。
インストールには約512MBの空きメモリが必要です。足りないと Killed（exit code 137）で落ちます。

01WSLでインストールできないのはなぜ？まず切り分ける

WSLでの失敗は、ほとんどが3つの系統に分かれます。ひとつはWSLがWindows側のNode.jsやnpmを拾ってしまう環境の混在、ふたつめがWSL1のローダーがネイティブバイナリを実行できない問題、みっつめがダウンロード・メモリ・PATHといったインストーラー側の事情です。設定を足す前にどの系統かを見分けると、当てる手が一気に絞れます。

切り分けは3つのコマンドで足ります

WSLのターミナルで次の3行を順に実行してください。どこで止まったかが、そのまま系統の判別になります。

# 1. どちら側のNode/npmを見ているか
which node
which npm

# 2. claudeが入っているか、どこに入っているか
which -a claude

# 3. インストールの健全性と設定の検証結果
claude doctor

which node が /mnt/c/ を返したら環境の混在です

WSLは既定でWindowsのPATHを引き継ぐ設計です。そのためLinux側にNode.jsを入れていても、先にWindowsのNodeやnpmが見つかればそちらが優先されます。公式ドキュメントも、/mnt/c/ で始まるパスはWindowsのバイナリ、/usr/ で始まるパスはLinux側のものだと明記しています。混在が見えた時点で、章03の対処に進んでください。

claude doctor は起動せずに診断だけを出します

claude doctor はセッションを開かずに読み取り専用の診断を表示し、インストールの健全性、設定ファイルの検証エラー、直近の自動更新の結果までまとめて確認できます。ネイティブ版のインストール先は ~/.local/bin/claude で、実体は ~/.local/share/claude/versions/ 配下へのシンボリックリンクです。which -a claude が複数のパスを返す場合は、二重インストールを疑う場面になります。

FIG.1 WSLで詰まった時の切り分け

STEP 1
which node / npm
/mnt/c/で始まる
→ 環境の混在（章03）

→

STEP 2
wsl -l -v
VERSIONが1
→ Exec format error（章05）

→

STEP 3
claude doctor
そもそも入っていない
→ インストーラー側（章06）

02WSLで報告されているエラー15種【診断表】

公式のトラブルシューティングに掲載されているもののうち、WSLで遭遇しうる症状を15行にまとめました。ターミナルに出た文言をそのまま探し、右端の打ち手から当ててください。文言が環境ごとに変わるものは、頭に【症状】と付けています。詳しい手順は章03以降で追います。

出るエラー・症状	起きていること	打ち手
`exec: node: not found`	WindowsのNode.jsを参照している	Linux側にNode.jsを入れ、`which node`が`/usr/`か`~/.nvm/`を指すか確認する
【症状】npmがプラットフォーム不一致を報告する	WindowsのnpmをWSLが拾っている	`npm config set os linux`のあと`--force`付きで再インストールする
【症状】nvmで切り替えてもNodeのバージョンが変わらない	Windows側のnvmがPATHで優先されている	`~/.bashrc`にnvmローダーを追記し、Linux側のパスを先頭へ足す
`cannot execute binary file: Exec format error`	WSL1のローダーがバイナリを扱えない	`wsl --set-version <DistroName> 2`でWSL2へ変換する
`bash: claude: command not found`	`~/.local/bin`がPATHに入っていない	シェル設定にPATHを追記し、ターミナルを開き直す
`Error: claude native binary not installed`	optional依存かpostinstallがスキップされた	`--omit=optional`や`--ignore-scripts`を外して入れ直す
`npm error code ENOTEMPTY`	旧パッケージのディレクトリが残っている	`npm root -g`配下の該当ディレクトリを消して再インストールする
`Killed`／exit code 137	インストール中にメモリが尽きた	swapを作るか空きメモリを確保する（約512MBが必要）
`Raw mode is not supported`	組織の管理設定に承認が必要な変更があり、パイプ実行では承認ダイアログを出せない	インストーラーをもう一度実行する
`syntax error near unexpected token '<'`	スクリプトではなくHTMLが返っている	ネットワークとプロキシを確認し、別の入手経路へ切り替える
`curl: (22) ... returned error: 403`	プロキシや地域制限で弾かれている	対応国かを確認し、社内プロキシの設定を見直す
`curl: (56) Failure writing output to destination`	ダウンロードが途中で切れた	回線の安定を確かめてから再実行する
`Error loading shared library libstdc++.so.6`	musl版とglibc版を取り違えている	`ldd --version`でlibcを確かめ、正しい版を入れ直す
`Illegal instruction`	CPUがAVXに未対応、またはアーキテクチャの不一致	`uname -m`とAVXの有無を確認する（回避策は未提供）
【症状】ログイン後にブラウザからターミナルへ戻らない	別ホストで開いたブラウザからコールバックが届かない	画面に出たログインコードをターミナルへ貼り付ける

15行のうち、上の4行がWSL固有の詰まりどころです。5行目はPATHの通し忘れ、6行目と7行目はnpm経由で入れた時に起きます。8行目以降はLinux全般で起きるもので、WSLでは割り当てメモリの小ささやプロキシ設定が引き金になりやすい点だけ違います。

03Node.jsとnpmの混在で出るエラーを直す

WSLで最も多い詰まり方が、Windows側のNode.jsとnpmを拾ってしまうパターンです。Anthropicの公式ドキュメントも、この3つを「npm install errors in WSL」として並べて掲載しています。ネイティブインストーラーを使っていれば、この章はまるごと読み飛ばして構いません。

「exec: node: not found」はWindows側のNodeを見ている

claude を実行して exec: node: not found と出るなら、WSLがWindowsのNode.jsを参照しています。which npm と which node の返すパスを見て、/mnt/c/ で始まっていれば確定です。

同じ混在が原因で、Error: Claude Code is not supported on Windows. Claude Code requires macOS or Linux to run properly. が出ることもあります。WSL内でWindows側のNode.jsが優先されると、インストール前のチェックが実行環境を win32 と判定するためです。Murasan Labが、VS CodeのRemote-SSH経由でWSLに接続した環境で報告しています。この文言は現在の公式トラブルシューティングのエラー一覧には無く、対処は本節と同じでLinux側にNode.jsを入れ直すことになります。

Linux側にNode.jsを入れ直す手順

Ubuntuなら sudo apt install nodejs npm でも導入できますが、バージョンを切り替えられる nvm 経由のほうが後々扱いやすくなります。入れ終えたら、もう一度 which node でパスが /usr/ か ~/.nvm/ 配下に変わったことを確かめてから claude を起動してください。

# nvmを入れてLTS版のNode.jsを使う（WSLのターミナル内で実行）
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
source ~/.bashrc
nvm install --lts
which node   # /home/<user>/.nvm/... と返れば成功

プラットフォーム不一致は npm config set os linux で直す

npmでのインストール中にプラットフォームの不一致を報告される場合も、原因はWindowsのnpmです。OSをlinuxと明示してから、強制フラグ付きで入れ直します。

# OSをlinuxと明示してから再インストール（sudoは付けない）
npm config set os linux
npm install -g @anthropic-ai/claude-code --force

sudo を付けないことが要点です。公式は sudo npm install -g を権限の問題とセキュリティ上のリスクにつながる操作として避けるよう明記しています。なお、npm版が必要とするNode.jsのバージョンは、v2.1.198以降で22以上です。古いNode.jsでは EBADENGINE の警告が出るだけでインストール自体は完了し、パッケージが取得するネイティブバイナリは実行時にNode.jsを使わないため claude は動きます。

nvmで切り替えても反映されない時

WSLとWindowsの両方にnvmを入れていると、WSL側でNodeのバージョンを変えても反映されないことがあります。WSLがWindowsのPATHを取り込み、Windows側のnvmが優先されるためです。公式が挙げる最も多い原因は、現在のシェルにnvmが読み込まれていないことなので、まずローダーを設定ファイルへ追記します。

# ~/.bashrc または ~/.zshrc の末尾に追記する
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

読み込んでもWindows側が勝つ場合は、Linux側のNodeのパスを明示的に先頭へ足します。そのセッションではLinuxのNodeが優先されます。

export PATH="$HOME/.nvm/versions/node/$(node -v)/bin:$PATH"

appendWindowsPath = false で切ってはいけない理由

PATHの混在を根元から断とうとして appendWindowsPath = false を設定する案内を見かけますが、公式は避けるよう警告しています。WSLからWindowsの実行ファイルを呼べなくなり、explorer.exe . やWindows側のブラウザ起動といった連携が全て止まるためです。Windows開発でNode.jsを使っているなら、Windows側のNode.jsもアンインストールせずに残します。

FIG.2 WSLがnodeを見つける順番

PATHの先頭　~/.nvm/versions/node/<ver>/bin　← ここが空だと下へ落ちる

↓

Linuxの標準　/usr/bin/node（apt等で入れた場合）

↓

Windowsから継承　/mnt/c/Program Files/nodejs/node.exe　← ここに落ちると not found

04npmインストール特有のエラーを直す

npmパッケージは、プラットフォームごとのoptional依存としてネイティブバイナリを取得し、postinstallでリンクを張る構成です。どちらかが欠けると、実体のないプレースホルダのまま残ります。この仕組みを知っていると、次の2つのエラーは読んだだけで原因が分かります。

「claude native binary not installed」が出る時

claude を実行して Error: claude native binary not installed と表示されたら、ネイティブバイナリが配置されていません。公式は原因を4つ挙げています。

optional依存を無効化している（--omit=optional、pnpmの--no-optional、yarnの--ignore-optional、.npmrcのoptional=false）
インストールスクリプトを無効化している（--ignore-scripts）
対応外のプラットフォームで実行している
社内のnpmミラーがプラットフォーム別パッケージを持っていない

# postinstallだけを手で走らせる（フラグを外した再インストールが本筋）
node node_modules/@anthropic-ai/claude-code/install.cjs

ただし、バイナリ自体がダウンロードされていない場合は install.cjs を実行しても配置できません。フラグを外して入れ直すのが先です。対応プラットフォームは linux-x64、linux-arm64、linux-x64-musl、linux-arm64-muslほか計8種で、WSLのUbuntuはlinux-x64に当たります。

「npm error code ENOTEMPTY」で再インストールが止まる時

既存のインストールに上書きすると、npmが旧ディレクトリを退避できずに ENOTEMPTY で止まることがあります。エラー出力の npm error path 行が、動かせなかったディレクトリを名指ししています。

# 残骸を消してから入れ直す
rm -rf "$(npm root -g)/@anthropic-ai/claude-code"
rm -rf "$(npm root -g)/@anthropic-ai/.claude-code-"*
npm install -g @anthropic-ai/claude-code
claude --version

nvmでNodeのバージョンを切り替えていると、npm root -g が返す場所と npm error path が指す場所がずれます。その場合はエラーが名指ししたディレクトリのほうを消してください。

権限エラーが出たらsudoではなくネイティブへ切り替える

npm由来の権限エラーで詰まったら、グローバルの書き込み先をいじる前にネイティブインストーラーへ移るほうが早く片付きます。npmのグローバルディレクトリに書き込めないと自動更新も止まり、起動時に一度だけ通知が出て claude doctor に対処法が並ぶ状態になります。

# WSLのターミナル内で実行（PowerShellではない）
curl -fsSL https://claude.ai/install.sh | bash

05「Exec format error」はWSL1の問題

claude を実行して cannot execute binary file: Exec format error と出る場合は、WSL1でネイティブバイナリの既知の問題に当たっています。バイナリのプログラムヘッダの変更を、WSL1のローダーが扱えないことが原因で、AnthropicのリポジトリではIssue #38788として追跡されています。自分がWSL1かどうかは、PowerShellで wsl -l -v を実行してVERSION列を見れば分かります。

# PowerShellで実行（DistroNameは自分の名前に置き換える）
wsl -l -v
wsl --set-version <DistroName> 2

Microsoftのドキュメントによると、wsl --install で新しく入れたディストリビューションは既定でWSL2になります。wsl --install 自体はWindows 10 バージョン2004（ビルド19041）以降、またはWindows 11が前提です。それより古いWindowsでは手動インストールの手順が案内されています。

WSL1のまま使いたい場合はどうする？

事情があってWSL1に留まるなら、動的リンカ経由でバイナリを呼ぶ回避策が公式に載っています。~/.bashrc に次の関数を追記し、source ~/.bashrc で反映してから claude を実行してください。ホームディレクトリが異なる場合はパスを読み替えます。

claude() {
  /lib64/ld-linux-x86-64.so.2 "$(readlink -f "$HOME/.local/bin/claude")" "$@"
}

ただしWSL1では、Claude Codeのサンドボックス実行がサポート対象外です。コマンドを隔離して走らせたい制作作業や自動化を考えているなら、回避策で凌ぐよりWSL2へ変換したほうが後で困りません。

FIG.3 WSL1とWSL2で変わること

WSL 1

ネイティブバイナリでExec format error

サンドボックス実行：非対応

回避策：動的リンカ経由の関数

WSL 2

ネイティブバイナリがそのまま動く

サンドボックス実行：対応

変換：wsl --set-version <Distro> 2

06インストーラー自体が失敗する時の対処

インストールコマンドそのものが完走せず、claude が置かれるところまで到達しないケースもあります。WSLでは、割り当てメモリの小ささと社内プロキシが引き金になりやすい傾向です。

「syntax error near unexpected token ‘<‘」はHTMLが返っている

インストールコマンドを実行して bash: line 1: syntax error near unexpected token `<' や bash: line 1: `<!DOCTYPE html>' と出る場合、スクリプトの代わりにHTMLページが返ってきています。同じ原因で curl: (22) The requested URL returned error: 403 になることもあります。返ってきたページに「App unavailable in region」と書かれていれば、その国では提供されていません。対応国で403が続くなら、社内プロキシやフィルタが downloads.claude.ai を塞いでいる可能性が高くなります。

# ダウンロード元に到達できるかを確かめる
curl -sI https://downloads.claude.ai/claude-code-releases/latest

# 社内プロキシ配下ならプロキシを通してから実行する
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
curl -fsSL https://claude.ai/install.sh | bash

レスポンスの1行目でネットワークを判別する

1行目に HTTP/2 200 が出れば、サーバーには届いています。403ならプロキシかネットワークフィルタ、5xxなら一時的な障害なので数分待って再実行します。何も返らない、Could not resolve host、タイムアウトのいずれかなら、ネットワークが接続を遮断している状態です。

「Killed」とexit code 137はメモリ不足

インストール中に Killed と表示され、Installation was killed before it could finish (exit code 137) で終わる場合は、LinuxのOOM killerがインストール処理を止めています。公式はインストールにおよそ512MBの空きメモリが必要と明記しており、システム要件としては4GB以上のRAMを求めています。WSLは .wslconfig でメモリ上限を絞れるため、以前に上限を設定していたなら見直す価値があります。

# 2GBのswapを作って再実行する
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
curl -fsSL https://claude.ai/install.sh | bash

「Raw mode is not supported」はインストーラーを実行し直す

インストール中に Raw mode is not supported を含むエラーで落ちるのは、組織のサーバー管理設定に承認が必要な変更が含まれていた場合です。承認ダイアログは端末を必要としますが、curl ... | bash はパイプ経由なので標準入力が端末になりません。v2.1.246以降はインストール中にダイアログを出さない仕様に変わっており、それ以前でもインストーラーを実行し直せば最新版の install が走って通過します。ただし、組織の起動設定が設定の取得完了を待つ構成になっている場合は、v2.1.246以降でもダイアログが出るため、パイプ経由のインストールは失敗したままです。その場合はスクリプトを一度ファイルに保存し、パイプを使わずに実行してください。

「curl: (56)」はダウンロードが途中で切れています

curl: (56) Failure writing output to destination と、関連する curl: (23) は、スクリプトがBashに最後まで渡らなかったことを示します。終了コード56はダウンロードの中断、23はBashが先に終了したことでcurlが書き込めなかった状態です。回線の安定を確かめて再実行するのが基本の対処になります。

07入ったのにclaudeが起動しない時の切り分け

インストールが完走したのに claude が反応しない場合、原因はPATH・共有ライブラリ・二重インストールの3つに絞られます。順番に潰していくと確実です。

command not found はPATHに入っていないだけ

bash: claude: command not found は、インストール先がシェルの検索パスに入っていない状態を指します。ネイティブ版は ~/.local/bin/claude に入るため、そのディレクトリがPATHにあるかを確かめます。

# ~/.local/bin がPATHに入っているか
echo $PATH | tr ':' '\n' | grep -Fx "$HOME/.local/bin"

# 出力が無ければ追記して読み直す
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
claude --version

VS Codeの拡張機能だけを入れている場合、~/.local/bin/claude は作られません。拡張機能はCLIの専用コピーを拡張ディレクトリ内に抱えており、PATHには追加しない設計だからです。ターミナルから claude を叩きたいなら、単体のインストールを別途行う必要があります。

共有ライブラリと命令セットのエラー

Error loading shared library libstdc++.so.6: No such file or directory は、musl版とglibc版のバイナリを取り違えたサインです。glibcのシステムにmuslのクロスコンパイル用パッケージが入っていると、インストーラーがmuslと誤認することがあります。ldd --version の出力に GNU libc や GLIBC が含まれていればglibc、musl と出ればmuslです。

Illegal instruction は別の話で、CPUが必要な命令セットに対応していないか、アーキテクチャが一致していないことを示します。おおむね2013年より前のIntel・AMDのCPUや、AVXをゲストに渡していない仮想環境で起こります。grep -m1 -ow avx /proc/cpuinfo の結果が空なら、ゲストからAVXが見えていません。公式はネイティブバイナリでの回避策は無いとしており、Issue #50384で状況が追跡されています。

二重インストールを疑う

which -a claude が複数返る、あるいは更新したはずのバージョンが古いままなら、インストールが二重になっています。確認する場所は3つで、ネイティブ版の ~/.local/bin/claude、古いバージョンが作った ~/.claude/local/、そしてnpmのグローバルです。

which -a claude
ls -la ~/.local/bin/claude
ls -la ~/.claude/local/
npm -g ls @anthropic-ai/claude-code 2>/dev/null

# 余分なものを消す（残すのはネイティブ版）
npm uninstall -g @anthropic-ai/claude-code
rm -rf ~/.claude/local

08WSL2でブラウザ認証が終わらない時はどうする？

ブラウザに表示されたログインコードを、ターミナルの入力欄に貼り付ければ完了します。WSL2ではブラウザが別ホストで開くため、サインイン後のリダイレクトがClaude Code側のローカルコールバックへ戻れず、代わりにコードが表示される仕様です。

ブラウザ自体が開かない時はBROWSERを指定する

WSL2からブラウザが起動しない場合、BROWSER 環境変数にWindows側のブラウザのパスを設定します。パスはインストール先に合わせて読み替えてください。

export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
claude

対話プロンプトで c を押すと認証URLがクリップボードにコピーされるので、手元のブラウザへ貼って開く方法も使えます。URLが折り返してクリックできない狭い端末でも、この手が使えます。

コードを貼り付けても反応しない時

ターミナルのペースト操作が入力欄まで届いていない可能性があります。Windows Terminalでは右クリックやShift+Insertが代替のペースト操作に割り当てられていることが多く、そちらを試す価値があります。それでも通らなければ、標準入力からコードを読む claude auth login を使ってください。

claude auth login

認証が通ったのに API Error: 403 で弾かれるなら、サブスクリプションの状態を確認します。Claude Codeの利用にはPro・Max・Team・Enterpriseのいずれか、またはConsole（API）アカウントが必要で、無料のClaude.aiプランは対象外です。Console利用なら「Claude Code」または「Developer」のロールが割り当たっているかも見てください。上限に当たって止まる場合の扱いはClaude Code usage limit reachedの対処法と再開手順にまとめています。

09WSL用とWindows用でコマンドを取り違えた時

WSLの記事を見ながらPowerShellで作業してしまう、あるいはその逆をやると、原因が分かりにくいエラーが返ります。文言でどちらを取り違えたかが判別できるので、表にまとめました。プロンプトが PS C:\ ならPowerShell、PS の無い C:\ ならCMD、$ で終わっていればWSLの中です。

出るエラー	いま居る場所	正しいコマンド
`'bash' is not recognized as the name of a cmdlet`	PowerShell（Linux用を実行した）	`irm https://claude.ai/install.ps1 \| iex`
`A parameter cannot be found that matches parameter name 'fsSL'`	PowerShell（`curl`が別コマンドの別名）	`irm https://claude.ai/install.ps1 \| iex`
`The token '&&' is not a valid statement separator`	PowerShell（CMD用を実行した）	`irm https://claude.ai/install.ps1 \| iex`
`'irm' is not recognized`	CMD（PowerShell用を実行した）	PowerShellを開くか、CMD用の`install.cmd`を使う
スクリプトの中身が表示されるだけで何も入らない	ダウンロード部分しか実行していない	`\| iex`まで含めた1行をそのまま実行する

Windows側で出る「Git for Windows または PowerShell が必要」

WSLではなくWindowsネイティブに入れた場合、Claude Code on Windows requires either Git for Windows (for bash) or PowerShell というエラーに当たることがあります。Git for Windows自体は任意で、Git Bashが無ければPowerShellツールが使われる設計なので、この文言は「どちらも見つからなかった」ことを意味します。PowerShellがPATHに無いなら C:\Windows\System32\WindowsPowerShell\v1.0\ を追加します。Gitが入っているのに認識されないときは、設定ファイルで bash.exe のパスを直接指定してください。

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

指定できるのは bash.exe、sh.exe、bash、sh のいずれかの名前を持つファイルだけです。Git for Windowsの git-bash.exe を指定しても無視され、自動検出に戻ります。なおWSL環境ではGit for Windowsは不要で、Linux側のgitがそのまま使えます。

10WSLが遅い・ファイルが見つからない時の置き場所

インストールが通ってからのつまずきで多いのが、動作の重さとファイルの見失いです。どちらもプロジェクトの置き場所が原因になっている場合があります。Microsoftのドキュメントは、使うツールと同じOS側にファイルを置くよう案内しています。

Linuxのコマンドラインで作業するなら、ファイルはWSLのファイルシステムに置くのが最速です。具体的には \\wsl$\<DistroName>\home\<UserName>\Project のようなLinux側のルート配下を使い、C:\Users\<UserName>\Project（WSLからは /mnt/c/Users/...）は避けます。OSをまたいだアクセス自体は可能ですが、性能が大きく落ちるとMicrosoftも明記しています。Claude Codeはファイルの読み書きと検索を繰り返すため、この差がそのまま体感速度に出ます。

VS CodeはWSLのターミナルから `code .` で開く

WindowsのVS CodeからWSL内のファイルをそのまま開いても、Linux側の環境とは噛み合いません。WSL拡張機能を入れたうえで、WSLのターミナルから code . を実行してリモートサーバー経由で開くのが正しい手順です。

# WSLのプロジェクトディレクトリで実行する
cd ~/projects/my-site
code .
claude

FIG.4 プロジェクトの置き場所

Linux側に置く（推奨）

~/projects/my-site

Linuxツールでの読み書きが速い

Windows側に置く

/mnt/c/Users/<user>/Project

OSをまたぐぶん性能が落ちる

11WSLとネイティブWindows、どちらに入れるべき？

サンドボックスでコマンドを走らせたい、あるいはLinuxのツールチェーンを使うならWSL2です。Windowsネイティブのプロジェクトが中心なら、ネイティブWindowsに入れて構いません。公式が示す選択肢と要件を並べます。

選択肢	必要なもの	サンドボックス実行	向いている場面
ネイティブWindows	なし（Git for Windowsは任意）	非対応	Windowsネイティブのプロジェクトとツール
WSL 2	WSL 2 が有効	対応	Linuxツールチェーン、コマンドの隔離実行
WSL 1	WSL 1 が有効	非対応	WSL 2 が使えない場合の代替

インストール方法もあわせて選びます。ネイティブインストーラーはバックグラウンドで自動更新されるのに対し、Homebrew・WinGet・apt・dnf・apkは既定では自動更新されません。npmも同じネイティブバイナリを取得する構成なので、環境が混在しやすいWSLではネイティブインストーラーのほうが素直な選択です。

動作環境の要件も確認しておきます。対応OSはmacOS 13.0以降、Windows 10 1809以降またはWindows Server 2019以降、Ubuntu 20.04以降、Debian 10以降、Alpine Linux 3.19以降です。ハードウェアは4GB以上のRAMと、x64かARM64のプロセッサが必要になります。

12WSLのClaude Codeを安定させる初期設定

WSLは環境が混ざりやすいぶん、最初に足回りを固めておくと後の手戻りが減ります。公式ドキュメントが挙げている項目のうち、入れた直後に済ませておくものを並べます。

入れたらまずclaude doctorを通す

コーディングを始める前に claude doctor を一度走らせると、インストールの健全性、設定ファイルの検証エラー、直近の更新結果が一度に読み取れます。claude --version が 2.1.211 (Claude Code) のようなバージョン番号を返せば、実行環境としては通っている状態です。この段階でPATHや二重インストールを潰しておくと、あとから原因の切り分けに戻る回数が減ります。日本語で返らない場合の設定はClaude Codeが英語で返るときの日本語固定の設定にまとめました。

自動実行では認証とPATHを先に固める

定期実行の自動化では、対話プロンプトの出ない -p 付きの実行でログインコードを貼り付けられず、認証で止まることがあります。初回は対話セッションでログインを済ませてから自動実行に回すと安定します。PATHについても、スクリプトの冒頭でLinux側のパスを明示しておくと、cron経由の実行で見失う事故を防げます。cronのPATHは対話シェルより短く、nvmも読み込まれません。$(node -v) のようにnodeの解決を前提にした書き方は使えないため、~/.local/bin を直接足すか nvm.sh を読み込みます。

#!/usr/bin/env bash
# 定期実行スクリプトの先頭でLinux側のパスを明示する
export PATH="$HOME/.local/bin:$PATH"
# nvmのNodeも使うなら、バージョンを直接書くか nvm.sh を読み込む
# export NVM_DIR="$HOME/.nvm"; [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
claude --version

なお ANTHROPIC_API_KEY がシェルの設定ファイルに残っていると、サブスクリプションではなくそのキーが使われます。-p 付きの非対話実行では、キーがあれば常にそちらが優先される仕様です。身に覚えのない課金や This organization has been disabled が出たら、~/.bashrc の export ANTHROPIC_API_KEY=... を疑ってください。定期実行の組み方はClaude Codeの定期実行をcronで自動化する方法、権限まわりの詰まりはClaude Codeの権限バイパスと承認を減らす設定で扱っています。日本語のファイル名やパスで表示が崩れる場合はターミナルが文字化けする原因と直し方もあわせて確認すると早いです。

よくある質問

WSLとネイティブWindows、どちらに入れるべきですか？

Linuxのツールチェーンを使う開発や、コマンドをサンドボックスで隔離して実行したい場合はWSL2が向きます。Windowsネイティブのプロジェクト中心なら、ネイティブWindowsに入れる選択で問題ありません。サンドボックス実行はWSL2のみ対応で、ネイティブWindowsとWSL1では使えません。

WSLでNode.jsは必ず必要ですか？

ネイティブインストーラーを使うなら不要です。npmパッケージも同じネイティブバイナリを取得する構成で、インストールされた claude は実行時にNode.jsを呼びません。npm経由で入れる場合、v2.1.198以降のパッケージはNode.js 22以降を求めますが、古いバージョンでは EBADENGINE の警告が出るだけでインストールは完了します。

sudoでnpm installしてもいいですか？

避けてください。公式は sudo npm install -g を権限の問題とセキュリティ上のリスクにつながる操作として明確に非推奨としています。権限エラーが出るなら、npmのグローバル先を変更するよりネイティブインストーラーへ切り替えるほうが確実です。

「Exec format error」はどうすれば直りますか？

WSL1の既知の問題なので、PowerShellから wsl --set-version <DistroName> 2 でWSL2へ変換するのが確実です。WSL1に留まる必要があるなら、動的リンカ経由で起動する関数を ~/.bashrc に追加する回避策が公式に載っています。ただしWSL1ではサンドボックス実行が使えません。

無料プランでもClaude Codeは使えますか？

使えません。Pro・Max・Team・EnterpriseのいずれかまたはConsole（API）アカウントが必要で、無料のClaude.aiプランは対象外です。インストール自体は完走しても認証で止まるため、症状としては「入ったのにログインできない」形で現れます。

WSLでClaude Codeが遅いのですが、設定で改善できますか？

まずプロジェクトの置き場所を確認してください。Microsoftは、Linuxのコマンドラインで作業するファイルはWSLのファイルシステムに置くよう案内しており、/mnt/c/ 配下に置くとOSをまたぐぶん性能が落ちると明記しています。~/projects/ のようなLinux側へ移すだけで、読み書きの待ち時間が変わります。

アンインストールして入れ直すにはどうしますか？

ネイティブ版なら rm -f ~/.local/bin/claude と rm -rf ~/.local/share/claude で本体を消せます。npm版は npm uninstall -g @anthropic-ai/claude-code です。設定まで消す場合は ~/.claude と ~/.claude.json も削除しますが、MCPサーバーの設定やセッション履歴が失われる点に注意してください。

13まとめ：エラー文言をそのまま引く

WSLでClaude Codeが入らない・動かないときは、設定を足す前にターミナルの文言を診断表に当てるのが最短です。/mnt/c/ が見えたらNode.jsとnpmの混在、Exec format error ならWSL1、Killed ならメモリ、command not found ならPATH、と原因ごとに打ち手が決まっています。判断に迷ったら、npmをやめてネイティブインストーラーで入れ直し、claude doctor を通してから作業に戻ってください。入れたあとの使い方は非エンジニアが使うClaude Codeスラッシュコマンド12選、権限の扱いはClaude Codeの権限モードと制限モードの違いで続きを扱っています。

14出典

Anthropic 公式ドキュメント「Troubleshoot installation and login」（Claude Code Docs, code.claude.com/docs/en/troubleshoot-install）
Anthropic 公式ドキュメント「Advanced setup」（Claude Code Docs, code.claude.com/docs/en/setup）
anthropics/claude-code Issue #38788「[BUG] Claude code 2.1.83 and above broken on WSL1」（GitHub）
anthropics/claude-code Issue #50384「[BUG] Illegal instruction crash on CPUs without AVX after 2.1.112 (native binary regression)」（GitHub）
Microsoft Learn「Install WSL」（learn.microsoft.com/en-us/windows/wsl/install）
Microsoft Learn「Set up a WSL development environment」（learn.microsoft.com/en-us/windows/wsl/setup/environment）
Murasan Lab「WSL環境下のClaude Codeインストール手順とトラブルシューティング」（murasan-net.com、WSL内でWindowsのNode.jsを拾った際のエラー報告）