Claude Code Windowsインストール — ネイティブとWSL、どちらを選ぶか
Claude CodeはWindowsネイティブとWSL2の2通りで動きます。Sandboxモードの対応可否や導入手順、企業環境特有のつまずきまで、Windows導入の判断材料をまとめます。
Windowsでの動かし方は2通りある
Claude CodeはWindows上で、ネイティブのWindows環境かWSL2のどちらかで動きます。どちらもインストール自体は数分で終わりますが、あとから使える機能に差が出ます。とくにSandboxモード(コマンド実行を隔離する機能)はネイティブWindowsでは使えず、WSL2でしか有効になりません。
先に判断基準を出しておくと、プロジェクトがWindows側のツールチェーンに依存しているならネイティブ、Linuxのビルドツールを使うかコマンド実行を隔離したいならWSL2を選びます。両方インストールして使い分けることもできます。
ネイティブとWSL、どちらを選ぶべきか
Windows・WSL2・WSL1の3択を、追加要件とSandbox対応で比較します。WSL1は動作こそしますが公式にSandboxモード非対応で、既知の不具合も残るため積極的には選びません。
| 選択肢 | 追加要件 | Sandboxモード | 向いているケース |
|---|---|---|---|
| ネイティブWindows | 追加要件なし(Git for Windowsは任意) | Sandboxモード非対応 | 向いているケースWindowsネイティブのプロジェクト・ツール |
| WSL2 | 追加要件WSL2の有効化 | Sandboxモード対応 | 向いているケースLinuxツールチェーン、コマンド実行の隔離 |
| WSL1 | 追加要件WSL1の有効化 | Sandboxモード非対応 | 向いているケースWSL2が使えない環境の代替 |
Sandboxモードは、ファイル書き込みとネットワークアクセスをコマンドごとに制限する機能です。macOSではOS内蔵のSeatbeltを、LinuxとWSL2ではbubblewrapとsocatを使って隔離します。ネイティブWindowsはいずれの仕組みも使えないため、Sandboxが必要ならWSL2上でClaude Codeを動かします。コンテナで丸ごと隔離する別のやり方はClaude CodeをDevContainerで安全に動かす完全実装にまとめています。
ネイティブWindowsにインストールする手順
PowerShellを開いて次のコマンドを実行します。管理者権限は不要です。
irm https://claude.ai/install.ps1 | iexCMDから入れる場合はコマンドが異なります。
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmdirmが認識されないと出たらCMDでPowerShell用コマンドを実行しています。逆に&&が無効と出たらPowerShellでCMD用コマンドを実行しています。プロンプトの行頭がPS C:\ならPowerShell、C:\だけならCMDです。
Git for Windowsの導入は任意です。入れるとClaude CodeがGit BashをBashツールとして使えるようになり、入れなければPowerShellツールで代替します。両方使える環境では、settings.jsonでCLAUDE_CODE_USE_POWERSHELL_TOOLを1にするとPowerShellツールを、0にするとBashツールを優先させられます。
Git for Windowsを入れたのにClaude CodeがGit Bashを見つけられない場合、CLAUDE_CODE_GIT_BASH_PATHで明示します。
{
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}v2.1.219以降、このパスはbash.exe・sh.exe・bash・shという名前のファイルしか受け付けません。Git for Windowsのランチャーgit-bash.exeをそのまま指定すると無視され、自動検出にフォールバックします。--debugオプションを付けて起動すると、この不一致が警告として表示されます。
WSL2にインストールする手順
WSLのディストリビューション(Ubuntuなど)のターミナルを開き、ネイティブWindowsと同じLinux用インストールコマンドを実行します。
curl -fsSL https://claude.ai/install.sh | bashPowerShellやCMDからではなく、必ずWSLのターミナル内でインストールと起動を行います。Git for Windowsも不要です。パスの扱い・Node.jsの取り違え・sandbox有効化・ログイン時のブラウザー問題まで踏み込んだ手順は、Claude CodeをWSL2で使うにまとめています。
Claude Code DesktopのWSLセッション機能
CLIを使わずグラフィカルに操作したい場合、Claude Code DesktopアプリのCodeタブには、WSL2のディストリビューションの中でそのままセッションを開始する機能があります。プロジェクトがWSL側のファイルシステムに置かれているなら、この機能でWindows側からネットワークファイルシステム経由でアクセスする遅さやファイル監視の不具合を避けられます。
利用にはWindows 10または11、WSL2、ディストリビューション内へのgitインストールが必要です(WSL1は非対応)。セッション開始時に環境ピッカーから対象ディストリビューションを選び、フォルダはディストリビューション内のLinuxパス(/home/you/projectなど)で指定します。ワークスペースの信頼はディストリビューションとフォルダの組み合わせごとに個別で、Windows側の同じパスを信頼していても引き継がれません。
ただし統合ターミナル・コネクタとプラグイン・セッションのフォーク・ファイルブラウザーペイン・@によるファイル候補は、WSLセッションではまだ使えません。これらが必要な作業は、WSLターミナルから直接CLIを起動する方法に切り替えます。組織管理下のデバイスでは、管理者の設定によってWSLセッション自体が無効化されている場合もあります。
Windows特有のインストールエラーと対処
Windowsのインストールでは、コマンドの取り違え以外にも次のパターンが頻出します。
32ビットPowerShellを開いている
スタートメニューにはWindows PowerShellとWindows PowerShell (x86)の2つがあり、後者は64ビット機でも32ビットプロセスとして動くためインストールが失敗します。[Environment]::Is64BitOperatingSystemを実行してTrueが返れば、x86でない方のPowerShellを開き直します。
TLS検証エラーで止まる
CRYPT_E_NO_REVOCATION_CHECKやCRYPT_E_REVOCATION_OFFLINEは、証明書失効の確認先に到達できないことが原因で、企業ファイアウォール配下でよく起きます。CMDでインストールしている場合はcurl --ssl-revoke-best-effortを付けて再実行するか、.NET経由でダウンロードしTLS検証の扱いが異なるPowerShellインストーラーに切り替えます。
Claude Desktopがclaudeコマンドを奪う
古いバージョンのClaude Desktopアプリを入れていると、WindowsApps配下に登録されたClaude.exeがPATH上でClaude Code CLIより優先され、claudeと打ってもDesktopアプリが起動します。Claude Desktopを最新版に更新すると解消します。
npm経由でPowerShellの実行ポリシーに阻まれる
running scripts is disabled on this systemというエラーは、npmが作る.ps1ランチャーをPowerShellの実行ポリシーがブロックしている状態です。Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserで自ユーザー分だけ許可するか、.ps1ではなく.cmdランチャーを呼ぶか、そもそもnpmではなくネイティブインストーラーに切り替えます。
ダウンロードファイルをアンチウイルスが掴んで離さない
The process cannot access the fileは、直前のインストール試行が残っているか、ウイルス対策ソフトがダウンロード中のバイナリをスキャン中であることが原因です。%USERPROFILE%\.claude\downloadsを削除してから再実行します。
企業のWindows環境で気をつけること
管理対象デバイスでは、一般的なつまずきとは別の壁に当たることがあります。AppLockerやEDR(エンドポイント検知・対応)エージェントがclaude.exeや、それが呼び出すcmd.exe・bash.exeをブロックしていると、Git for Windowsを正しく設定していてもGit Bashを見つけられません。この場合はIT部門にこれらのプロセスの許可リスト登録を依頼します。
TLS検査を行う社内プロキシの配下では、PowerShellインストーラーは.NET経由でWindowsの証明書ストアを参照するため、社内CA証明書をWindowsストアに追加してもらう必要があります。インストール後のClaude Code本体には、NODE_EXTRA_CA_CERTS環境変数で同じ証明書を指定します。
組織で許可する最低バージョンを固定したい場合、Managed SettingsのminimumVersionを使うとユーザー側の設定で上書きできない下限を強制できます。バックグラウンド更新とclaude updateの両方がこの下限より古いバージョンへは戻りません。権限まわりの設計は個人・チーム・企業のレイヤー別にClaude Codeセキュリティ・権限ガイドで整理しています。
よくある質問
Windows 11とWindows 10のどちらでも使えますか
使えます。システム要件はWindows 10バージョン1809以降、またはWindows Server 2019以降です。これより古いWindows 10や、32ビット版のWindowsは対象外です。
管理者権限がないと入れられませんか
不要です。ネイティブインストーラーはユーザーのホームディレクトリ配下(%USERPROFILE%\.local\binなど)にインストールするため、管理者権限なしで動きます。
WinGetでも入れられますか
入れられます。winget install Anthropic.ClaudeCodeの1行で導入できますが、既定では自動更新されません。settings.jsonでCLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATEを1にすると、新しいバージョンが出たときにClaude Code自身がwinget upgrade相当の更新をバックグラウンドで実行します。macOS側でパッケージマネージャー経由にするか迷う場合はClaude Code Homebrew・npm・ネイティブ導入の比較で更新の挙動の違いを比較しています。
ARM64版のWindowsでも動きますか
動きます。システム要件はx64またはARM64プロセッサで、npm経由のインストールもwin32-arm64向けのバイナリが用意されています。
Windows版とWSL2版でセッションやMCP設定は共有されますか
共有されません。ネイティブWindowsとWSL2は別々のファイルシステム上で動くため、~/.claude配下の設定・許可済みツール・MCPサーバー構成もそれぞれ独立しています。両方を使う場合は、必要な設定を両方の環境にそれぞれ用意します。
まとめ
Windowsのインストールは、ネイティブならirm https://claude.ai/install.ps1 | iex、WSL2ならWSLターミナル内でcurl -fsSL https://claude.ai/install.sh | bashの1行で完了します。選択の分かれ目はSandboxモードの要否とプロジェクトの置き場所で、迷ったらネイティブから始め、コマンド実行の隔離が必要になったタイミングでWSL2を検討する進め方が無理なく進みます。インストール全般の基本や他OSとの比較はClaude Code install完全ガイド、個別のエラーメッセージからの切り分けはClaude Codeインストールエラーの切り分けチェックリストを参照してください。