Claude CodeをWindowsで使う方法｜ネイティブ版とWSL2の選び方、Git for Windowsの要否【2026年10月】

Claude Codeは、WSL2を入れなくてもWindowsでそのまま動きます。 PowerShellで irm https://claude.ai/install.ps1 | iex を実行すれば、管理者権限なしでインストールでき、PowerShellやコマンドプロンプト（CMD）から claude を起動できます。

ところが、「claude code windows」で検索して上位に出てくる日本語の記事には、「WindowsではWSLの準備が必要」「Git Bashを入れてパスを設定しないと起動しない」と書かれたものがまだ多く残っています。Claude Codeが最初にWindowsネイティブに対応したのは2025年7月のv1.0.51で、このときはGit for Windowsが必須でした。その後、2026年4月のv2.1.120で、Git for Windowsがない場合はPowerShellでコマンドを実行するように変わっています（CHANGELOG・npmの公開日時）。どちらの書き方も書かれた時点では正しく、その後に前提が2回変わったというのが実情です。

本記事では、Windowsという環境がClaude Codeに持ち込む違いだけを扱います。ネイティブ版・WSL2・デスクトップアプリのどれを選ぶかを決めたうえで、それぞれのインストール手順、Git for Windowsが要る場面、WSL2でしか使えないサンドボックス、Windowsでよく起きるエラーの直し方までをまとめました。OSを問わない導入の流れ（ログイン、最初の操作、CLAUDE.mdの書き方）はClaude Codeの導入・インストール手順で解説しています。

本記事の情報について：2026年10月21日に確認したClaude Code公式ドキュメント（Advanced setup・Troubleshoot installation and login・Sandboxing・Tools reference・デスクトップアプリ）と、同日時点の最新版v2.1.305にもとづいています。Windowsまわりの挙動は更新のたびに変わることがあるため、導入前に公式の最新情報も確認してください。

状況別の読み分け早見表

まず結論：Windowsで動かす3つの方法と選び方

迷ったら、ネイティブ版をPowerShellから入れるのが最も手早い始め方です。 Linux向けのツールで開発している場合や、コマンドを隔離して動かすサンドボックスが必要な場合だけ、WSL2を選びます。

公式ドキュメントの「Set up on Windows」は、選び方を「プロジェクトがどこにあるか」と「どの機能が必要か」で決めるように案内しています（Advanced setup）。公式の比較表に、デスクトップアプリを加えて整理すると次のとおりです。

3つの方法の違いは、Claude Codeがどこで動き、Claudeが実行するコマンドをどのシェルが受け持ち、プロジェクトをどこに置くかに集約されます。ネイティブ版はすべてがWindows側、WSL2はすべてがLinux側にそろいます。デスクトップアプリは、セッションを始めるときに選んだ環境（ローカルかWSLか）に合わせて、どちらかの形になります。

判断の順番

上から順に当てはめてください。

1. リポジトリと、ビルドやテストに使うツールがすでにWSL2の中にある → WSL2。WSLの中のファイルをWindows側から操作するとネットワーク経由のファイルシステムを通るため遅く、ファイルの変更の検知も効かなくなります（Claude Code Desktop in WSL）。Claude CodeもWSLの中で動かします
2. Linuxでしか動かないツールでビルド・テストしている → WSL2
3. Claudeが実行するコマンドを、OSの仕組みで隔離して動かしたい → WSL2。ネイティブ版ではサンドボックスが使えません（後述）
4. .NETやWindows向けアプリなど、Windowsのツールで開発している → ネイティブ版
5. ターミナルに慣れていない、変更を画面で確認しながら進めたい → デスクトップアプリ
6. 上のどれにも当てはまらない → ネイティブ版

なぜ「WindowsならWSL2が必要」という情報が多いのか

検索上位の記事が間違っていたわけではありません。Claude Codeがネイティブで動かなかった時期、Git for Windowsが必須だった時期、どちらも必須でなくなった現在の3つの時期があり、記事によって書かれた時期が違うことが混乱の原因です。

時期の区切りは、Claude CodeのCHANGELOGの「Added support for native Windows (requires Git for Windows)」（v1.0.51）と「Git for Windows (Git Bash) is no longer required」（v2.1.120）の記載を、npmレジストリの公開日時（v1.0.51は2025年7月11日、v2.1.120は2026年4月24日、いずれも協定世界時）と照合して確認しました。古い記事の手順を試す前に、その記事がどの時期に書かれたものかに注意してください。

記事の新旧を見分けるには、Git for Windowsがないときに、PowerShellツール（Claudeがコマンドの実行にPowerShellを使う仕組み）が既定で使われると書かれているかを見るのが目安になります。PowerShellツール自体は2026年3月のv2.1.84から任意で試せるプレビューとして存在したため、触れていてもGit Bashを必須としている記事は、2026年4月より前の情報と考えてください。

導入前に確認するWindowsの要件

Claude CodeはWindows 10の1809以降、またはWindows Server 2019以降の64ビット版で動きます。 32ビット版のWindowsでは動きません。

公式ドキュメントが挙げる動作要件のうち、Windowsに関係する条件は次のとおりです（System requirements、2026年10月時点で確認）。

もう一つの前提が、使えるアカウントの種類です。Claude Codeを使うには、Pro・Max・Team・Enterpriseのいずれかのプランか、Claude Console（APIの従量課金）のアカウントが必要で、無料のClaude.aiプランには含まれていません（Authenticate）。どのプランを選ぶかはClaude Codeの料金プランを比較した記事で整理しています。

WSL2を使う場合は、Windows側の条件がもう一段上がります。Microsoftのドキュメントでは、wsl --install で一括導入するにはWindows 10のバージョン2004（ビルド19041）以降か、Windows 11が必要とされています（Microsoft Learn「Install WSL」）。

インストール前のチェックリスト

インストールを始める前に、次の項目を確かめておくと、途中で止まりにくくなります。

• Windowsのバージョン：Windows 10の1809以降、Windows 11、Windows Server 2019以降のいずれか。winver を実行すると表示されます
• 64ビット版か：PowerShellで [Environment]::Is64BitOperatingSystem を実行し、True と表示されればよい
• アカウント：Pro・Max・Team・Enterpriseのいずれかのプランか、Claude Consoleのアカウントがある
• 使うシェル：PowerShellとCMDのどちらでコマンドを貼るか（次の節で見分け方を説明します）
• Git for Windows：Bashを前提にしたスクリプトを使うなら入れておく
• WSL2：Linuxのツールで開発する、またはサンドボックスを使うなら用意する
• 会社のPC：プロキシやセキュリティソフトの決まりがあるなら、情報システム部門に先に確認する

ネイティブ版のインストール（PowerShell・CMD・WinGet）

ネイティブ版は、使っているシェルに合ったコマンドを1行実行するだけで入ります。 管理者として実行する必要はありません。

自分がPowerShellとCMDのどちらにいるかを確かめる

最初につまずきやすいのが、PowerShellとコマンドプロンプト（CMD）の取り違えです。公式ドキュメントは、プロンプトの表示で見分ける方法を案内しています。

• 行頭が PS C:\Users\あなたの名前> のように PS で始まる → PowerShell
• 行頭が C:\Users\あなたの名前> で PS が付かない → CMD

Windows TerminalやVS Codeのターミナルでは、タブごとにPowerShellとCMDを切り替えられるため、開いているタブがどちらかを見てからコマンドを貼り付けてください。

インストールコマンド

PowerShellの場合は次のコマンドです。

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

CMDの場合は次のコマンドです。

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

WinGet（Windowsのパッケージマネージャー）でも入れられます。

winget install Anthropic.ClaudeCode

インストール中は進み具合が表示されません。終わったら新しいターミナルを開き直してから claude --version を実行し、2.1.305 (Claude Code) のようにバージョン番号が出れば成功です。インストール前から開いていたウィンドウでは、PATH（コマンドを探す場所の一覧）の変更が反映されていないことがあります。

さらに詳しく状態を見たい場合は claude doctor を実行します。セッションを始めずに、インストールの状態・設定ファイルの書き間違い・自動更新の結果などを読み取り専用で表示します（Verify your installation）。

入れ方による更新のされ方の違い

インストール方法によって、その後の更新のされ方が変わります。Windowsでは選択肢が多いぶん、ここを知らずに選ぶと「古いバージョンのまま使っていた」ということが起こります。

WinGetで入れた場合も、環境変数 CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE を 1 にすると、Claude Codeが更新コマンドを代わりに実行してくれます。ただし公式ドキュメントによると、Claude Codeの実行中はWindowsが実行ファイルをロックするため、WinGetでの更新が失敗することがあり、その場合は手動のコマンドが表示されます（Update Claude Code）。WinGetを選ぶ場合はこの更新の手間に注意し、ときどき claude --version でバージョンを確認してください。

新しい機能をすぐ使うより安定を優先したい場合は、更新の配信チャネルを stable（おおむね1週間前の版で、大きな不具合が出た版を飛ばす）に切り替えられます。PowerShellなら次のコマンドで、最初から stable を入れられます。

& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) stable

npmで入れる場合の注意

npmでも入れられますが、WindowsではPowerShellの実行ポリシー（スクリプトの実行を制限する仕組み）に止められやすいのが難点です。npmが作る npm.ps1 や claude.ps1 が実行ポリシーで止められ、「running scripts is disabled on this system」と表示されます。

公式ドキュメントが挙げる対処は3つです（running scripts is disabled on this system）。

1. 自分のユーザーに限ってローカルのスクリプトを許可する：Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
2. .ps1 の代わりに npm.cmd や claude.cmd を使う（実行ポリシーの対象外）
3. npmをやめて、PowerShellのインストーラーで入れ直す

npm版を使う条件として、Node.jsは22以降が必要です（2026年10月時点の公式ドキュメントで確認）。なお、npm版も中身はインストーラー版と同じネイティブの実行ファイルで、claude の実行時にNode.jsは使われません（Install with npm）。特別な理由がなければ、PowerShellのインストーラーを選ぶのが確実です。

インストール後のログインや、最初のプロジェクトでの使い方は、OSによる違いがありません。続きはClaude Codeの導入・インストール手順を参照してください。

Git for Windowsは必要か（BashツールとPowerShellツール）

Git for Windowsは必須ではありません。入れておくと、ClaudeがBashのコマンドやBash向けのスクリプトを使えるようになります。 ない場合、ClaudeはPowerShellでコマンドを実行します。

Claude Codeは、ファイルの操作やテストの実行のために、シェルのコマンドを実行します。ネイティブ版では、このときに使うシェルがGit for Windowsの有無で変わります（Install on native Windows）。

PowerShellツールが有効なとき、ClaudeはPowerShellを主なシェルとして扱い、Git BashがあればPOSIX向けのスクリプトにはBashも使います。PowerShell 7（pwsh.exe）があればそれを、なければWindows PowerShell 5.1（powershell.exe）を使います（PowerShell tool）。

チームで開発するなら、Git for Windowsは入れておくほうが無難です。 リポジトリの中には、npm のスクリプトやビルド手順がBashを前提に書かれているものが少なくないからです。また、デスクトップアプリで変更ごとに別の作業用フォルダ（worktree）を切るセッションを使う場合も、Gitが必要になります。

Git Bashが見つからないときは CLAUDE_CODE_GIT_BASH_PATH を設定する

Git for Windowsを入れたのに使われない場合、Claude Codeがインストール先を見つけられていない可能性があります。CLAUDE_CODE_GIT_BASH_PATH が設定されていないとき、Claude Codeは次の順で bash.exe を探します（Troubleshoot installation）。

1. 既定のインストール先である C:\Program Files\Git と C:\Program Files (x86)\Git
2. PATH上にある git と同じインストールの bin\bash.exe

これ以外の場所にGitを入れている場合は、PowerShellで where.exe git を実行して場所を確かめ、その bin\bash.exe を設定ファイルに書きます。設定ファイルは、ユーザー全体なら %USERPROFILE%\.claude\settings.json です。

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

JSONの中では、パスの区切りの \ を \\ と2つ重ねて書く点に注意してください。

設定しても使われない場合は、ファイル名を見直します。 Claude Codeが受け付けるのは bash.exe・sh.exe・bash・sh という名前のファイルだけで、Git for Windowsの git-bash.exe（ターミナルを開くためのランチャー）を指定すると無視され、設定がないものとして自動検出に戻ります。存在しないパスを書いた場合も同じです。この挙動はv2.1.219以降のもので、それより前の版では、パスが存在しないと起動時に「Claude Code was unable to find CLAUDE_CODE_GIT_BASH_PATH path」で止まっていました。古い記事でこのエラーの対処が中心になっているのはそのためです。

ファイル名も正しいのに使われない場合、公式ドキュメントは、AppLockerやグループポリシーのソフトウェア制限、EDR（端末のセキュリティ監視ソフト）が邪魔をしている可能性を挙げています。その場合は情報システム部門に、claude.exe と、そこから起動される cmd.exe・bash.exe を許可してもらうよう依頼します。

実行ポリシーと許可ルールの落とし穴

PowerShellツールについて、Windowsならではの注意点が2つあります。

1つ目は実行ポリシーです。Claude CodeはPowerShellを起動するとき、そのプロセスに限って -ExecutionPolicy Bypass を付けます。そのため、PCの実行ポリシーが既定のままでも、Claudeは .ps1 のスクリプトを実行できます。ただし、グループポリシーで会社が設定した実行ポリシーは上書きしません。PCの実行ポリシーどおりに動かしたい場合は、CLAUDE_CODE_POWERSHELL_RESPECT_EXECUTION_POLICY=1 を設定します。

2つ目は許可ルールの書き方です。Git Bashがある環境で、Bash(git push *) のようにBashのコマンドを禁止するルールを書くと、そのセッションではPowerShellツールが警告なしにオフになります。Bashの禁止ルールではPowerShellのコマンドを止められず、PowerShell側から同じことができてしまうのを防ぐためです。PowerShellツールも使い続けたい場合の方法は2つあります。環境変数 CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を設定するか、PowerShell(git push *) のように、PowerShell向けの禁止ルールを別に書きます。なお、Bash だけを書いてBashツールを丸ごと禁止すると、そのセッションではClaudeが使えるシェルのツールがなくなります（Bash deny rules also turn off the PowerShell tool）。

許可・承認・禁止する操作をどう切り分けるかの考え方は、Claude Codeのセキュリティと社内導入時の注意点のパーミッションの設計で整理しています。

WSL2で使う場合の手順と注意点

WSL2で使う場合は、WSLのターミナルの中でLinux向けのインストーラーを実行し、claude もWSLの中で起動します。 PowerShellやCMDから入れるのではありません。

WSL2の準備とClaude Codeのインストール

WSL2がまだない場合は、管理者として開いたPowerShellで次を実行し、PCを再起動します。既定ではUbuntuが入ります（Microsoft Learn「Install WSL」）。

wsl --install

再起動後、Ubuntuのユーザー名とパスワードを設定したら、WSLのターミナルの中でLinux向けのインストーラーを実行します。

curl -fsSL https://claude.ai/install.sh | bash

公式ドキュメントにあるとおり、WSL環境ではGit for Windowsは要りません。Gitは、WSLの中にLinuxのものを入れて使います。

プロジェクトはLinux側に置く

WSL2で使うときに最も効いてくるのが、プロジェクトの置き場所です。WSLの中から /mnt/c/ 配下のWindowsのファイルを操作すると、ファイルシステムをまたぐ読み込みが遅くなります。

公式のトラブルシューティングは、この遅さのせいでファイル検索の結果が本来より少なくなることがあると書いています。しかも、このとき claude doctor の検索の項目は「OK」と表示されるため、気づきにくい問題です（Slow or incomplete search results on WSL）。WSL2では検索の結果が少ないと感じたら、まずプロジェクトの場所を確認するよう注意してください。対処として挙げられているのは次の3つです。

1. 検索する場所を絞って頼む（「auth-service パッケージの中でJWTの検証処理を探して」のように）
2. プロジェクトを /mnt/c/ ではなくLinux側の /home/ 配下に移す
3. WSLをやめて、ネイティブ版で動かす

WSL2を選んだのなら、2つ目の「Linux側に置く」が基本です。

ログインでブラウザが戻ってこないとき

WSL2では、ログインのときに開くブラウザがWindows側で動くため、ログイン後にClaude Codeへ自動で戻れないことがあります。その場合はブラウザに表示されるコードを、ターミナルの「Paste code here if prompted」に貼り付けます。ブラウザ自体が開かない場合は、環境変数 BROWSER にWindowsのブラウザのパスを指定します（OAuth login fails in WSL2）。

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

貼り付けても反応しない場合は、Windows Terminalの右クリックや Shift+Insert で貼り付けるか、claude auth login を使うと標準入力からコードを受け付けます。ログインまわりの詳しい対処は「Invalid code」で止まるときの対処も参照してください。

WSLの中でnpmを使っている場合

WSLの中でnpmを使ってClaude Codeを入れている場合、WSLがWindows側のNode.jsやnpmを拾ってしまうことがあります。WSLは既定でWindowsのPATHも取り込むためです。which npm と which node を実行して、/mnt/c/ で始まるパスが出たらWindowsのものです。Linuxのパッケージマネージャーかnvmで、WSLの中にNode.jsを入れ直してください（npm install errors in WSL）。そもそもWSLの中でもネイティブのインストーラー（install.sh）を使えば、この問題は起きません。

WSL1は避ける

WSL1でも動かすことはできますが、サンドボックスが使えません。さらに、WSL1で claude を実行すると「cannot execute binary file: Exec format error」が出る不具合が報告されています。いちばん確実な直し方は、PowerShellでディストリビューションをWSL2に変換することです。

wsl --set-version <ディストリビューション名> 2

ディストリビューション名とWSLのバージョンは、PowerShellで wsl -l -v を実行すると確認できます。

デスクトップアプリで使う場合

ターミナルを使いたくない場合は、Claudeのデスクトップアプリの「Code」タブからClaude Codeを使えます。 アプリにClaude Codeが含まれているので、Node.jsやCLIを別に入れる必要はありません。

インストールと始め方

Windows用のインストーラーは、x64版とARM64版が公式ドキュメントのページからダウンロードできます。インストールしてスタートメニューから起動し、Anthropicのアカウントでログインしたら、画面上部の「Code」タブを開きます。Codeタブを使うには、Pro・Max・Team・Enterpriseのいずれかのプランが必要です。

セッションを始めるときは、入力欄の下にある環境の選択から、次のどちらかを選びます。

• ローカル：Windows上で動く。ネイティブ版と同じ扱い
• WSL：インストール済みのWSL2のディストリビューションの中で動く。Claude Code・ツール・GitはLinux側で動く

WSLセッションの条件とできないこと

WSLセッションを使うには、WSL2（WSL1は不可）と、ディストリビューションが1つ以上入っていて、その中にGitが入っている必要があります。プロジェクトのフォルダはLinuxのパス（/home/you/project など）で選びます（Claude Code Desktop in WSL）。

公式ドキュメントによると、WSLセッションでは次の制限があります。

• プラグインが使えない
• ファイルの画面では閲覧だけで、編集はできない（Claudeに頼んで編集する）
• 統合ターミナルやコネクタが使えない場合がある（機能が順次提供されているため。Amazon Bedrockなど他社のサービス経由では使えない）
• 会社が管理するPCでは、管理者の設定でWSLセッション自体が使えないことがある

デスクトップアプリで気をつけたい点

環境変数の読み込み方が、ターミナルで使う場合と違います。WindowsのデスクトップアプリはユーザーとシステムのWindows環境変数を引き継ぎますが、PowerShellのプロファイル（$PROFILE）は読み込みません。PowerShellのプロファイルに書いた設定がアプリから効かないのはこのためで、必要な値はWindowsのユーザー環境変数に設定します。

もう一つ、古いデスクトップアプリが claude コマンドを横取りすることがあります。古い版のアプリが WindowsApps フォルダに Claude.exe を登録していると、ターミナルで claude を実行したときにCLIではなくアプリが開きます。アプリを最新版に更新すれば直ります。

複数のセッションを並べて進める使い方は、Claude Codeデスクトップアプリの並列作業ガイドで詳しく扱っています。

サンドボックスはWSL2でしか使えない

ネイティブ版のClaude Codeは、サンドボックスなしでコマンドを実行します。 公式ドキュメントは、サンドボックスが動くのはmacOS・Linux・WSL2で、Windowsで使いたい場合はWSL2の中でClaude Codeを動かすよう案内しています（Sandboxing、2026年10月時点で確認）。コマンドの隔離が必要かどうかは、ネイティブ版とWSL2を選ぶときの大きな判断材料になります。

サンドボックスとは、Claudeが実行するシェルのコマンドの周りに、OSが強制する境界を作る仕組みです。コマンドが読み書きできるファイルと、接続できるネットワークの宛先を決めておけば、その範囲内のコマンドは確認なしで実行させられます。対象はBash・PowerShell・Monitorのコマンドと、そこから起動されるプロセスです。

ネイティブ版で設定しても、黙ってサンドボックスなしで動く

注意したいのは、ネイティブ版でサンドボックスを有効にしても、既定ではエラーにならない点です。公式ドキュメントによると、依存するものが足りない、またはプラットフォームが対応していないためにサンドボックスを起動できないとき、Claude Codeは既定でサンドボックスなしでコマンドを実行します。

サンドボックスが使えない環境で起動そのものを止めたい場合は、sandbox.failIfUnavailable を true にします。会社で「サンドボックスなしでは使わせない」と決めている場合はこの設定を使いますが、ネイティブのWindowsでは起動できなくなるため、Windowsの利用者にはWSL2かコンテナで使ってもらう必要があります。

WSL2でサンドボックスを使う準備

WSL2では、bubblewrap（ファイルの隔離）と socat（通信の中継）の2つのパッケージが必要です。Ubuntuなら次のコマンドで入ります。

sudo apt-get install bubblewrap socat

入れたらClaude Codeを再起動し、/sandbox を実行します。足りないものがあると「Dependencies」タブに一覧が出ます。また、WSL1で /sandbox を使うと「Sandboxing requires WSL2」と表示されます。

ネイティブ版で安全に使うには

ネイティブ版を選ぶ場合は、サンドボックスの代わりに許可の設定で守ることになります。具体的には、ファイルの編集やコマンドの実行のたびに確認を求める既定のモードで使い、許可するコマンドを設定ファイルで絞り込みます。確認の手間を減らしたい場合は、Claudeの判断で安全な操作だけを自動で通すモードもあります。仕組みと、許可ルールの書き方はClaude Codeのautoモード完全ガイドで解説しています。

業務のPCで、機密情報を含むリポジトリを扱うなら、サンドボックスの有無は選択の大きな決め手になります。情報システム部門や法務と方針を決めるときの論点は、前述のセキュリティと社内導入時の注意点が参考になります。

なお、同じコーディングエージェントでも、OpenAIのCodexは公式ドキュメントで「既定ではネイティブのWindowsサンドボックスを使う」よう案内しており（OpenAI「Windows sandbox」）、この点はClaude Codeと異なります。両方を使い分けている場合は、CodexをWindowsで動かす方法とあわせて読むと違いがわかります。

Windowsでよく起きるエラーと直し方

Windowsで起きる問題の多くは、「別のシェル向けのコマンドを貼った」「PATHが反映されていない」「会社のネットワークやセキュリティソフトに止められた」の3つに分かれます。 表示されたメッセージから引けるように、公式ドキュメントに載っているものをまとめました（Troubleshoot installation and login）。

最後の行は公式ドキュメントのターミナル設定のページに載っているものです。Windowsでは、^H で届いたBackspaceをCtrl+Backspace（1単語削除）として扱うのが既定になっているために起きます。ただし、TERM_PROGRAM が mintty（Git Bashの標準のターミナル）か、TERM が cygwin のときは、この扱いになりません。

PATHが通っていないときの直し方

インストールは成功したのに claude が見つからない場合は、PowerShellで次の順に確かめます。まず、インストーラーが実行ファイルを置いたかを確認します。

Test-Path "$env:USERPROFILE\.local\bin\claude.exe"

True なら、実行ファイルはあります。続いて、その場所がPATHに入っているかを確認します。

$env:PATH -split ';' | Select-String '\.local\\bin'

何も表示されなければ、ユーザーのPATHに追加します。

$currentPath = [Environment]::GetEnvironmentVariable('PATH', 'User')
[Environment]::SetEnvironmentVariable('PATH', "$currentPath;$env:USERPROFILE\.local\bin", 'User')

追加したらターミナルを開き直し、claude --version を実行します。VS Codeなどのエディタの中のターミナルは、エディタが起動したときのPATHを引き継ぐため、エディタごと終了して開き直す必要があります。

インストーラーは、PATHに入っていないことを検出すると、出力の「Setup notes:」にNative installation exists but C:\Users\you\.local\bin is not in your PATH.と表示します。ただし、表示するだけでPATHは変更しません。インストール時の出力にこの行がないかも見てください。

会社のネットワークで止まるとき

社内のプロキシが通信を検査している環境では、インストールの段階で証明書のエラーが出ることがあります。PowerShellのインストーラーは.NETを通してダウンロードし、Windowsの証明書ストアで検証します。そのため、プロキシの証明書がWindowsに登録されていれば通ります。登録されていなければ、情報システム部門に依頼してください。

インストール後に起動してから出る証明書のエラーは「SSL certificate verification failed」の対処を、APIにつながらない場合は「Unable to connect to API」の対処を参照してください。ここに載っていないエラーは、Claude Codeのエラー対処法・トラブルシューティングの逆引き表から探せます。

日本語で使うときの改行・入力の注意

Windows Terminalなら、Shift+Enterで改行できます。 どのターミナルでも確実に使えるのは、Ctrl+J と、\ を入力してからEnterを押す方法です。

公式ドキュメントの対応表では、Windows TerminalはShift+Enterに設定なしで対応しています。VS Codeの統合ターミナルでは、/terminal-setup を1回実行するとShift+Enterが使えるようになります（Enter multiline prompts）。Windowsで改行のつもりが送信されてしまう場合の確かめ方は、Claude Codeで改行する方法にまとめています。

日本語の入力では、漢字の変換を確定するEnterと送信のEnterが重なり、書きかけの指示を送ってしまうことがあります。改行に Ctrl+J を使うか、長い指示はエディタで書いてから貼り付けると防げます。Shift_JISなど、UTF-8以外の文字コードのファイルを扱うときの注意も含めて、Claude Codeを日本語で使うときのベストプラクティスで解説しています。

よくある質問

まとめ

WindowsでClaude Codeを使うときの判断は、次の3点に集約されます。

1. まずはネイティブ版でよい。 WSL2は必須ではなく、PowerShellで irm https://claude.ai/install.ps1 | iex を実行すれば、管理者権限なしで入ります。自動で更新されるのもこの入れ方です
2. Git for Windowsは任意だが、チーム開発なら入れておく。 なければPowerShellで動き、あればBashのスクリプトも使えます。見つからないと言われたら CLAUDE_CODE_GIT_BASH_PATH に bash.exe のパスを書きます
3. サンドボックスが要るならWSL2。 ネイティブ版ではサンドボックスが使えず、有効にしても既定では黙ってサンドボックスなしで動きます。WSL2を選んだら、プロジェクトはLinux側に置きます

そして、ネットで見つけた手順がうまくいかないときは、その記事がいつ書かれたものかを最初に確かめてください。Windowsまわりの前提は、2025年7月と2026年4月の2回、大きく変わっています。

Windows端末が中心の会社では、ツールの使い方そのものより、端末の管理方針やセキュリティの決まりとどう両立させるかで導入が止まりがちです。衣株式会社では、Claude Codeを使った受託開発と、社内への導入・定着の支援を行っています。