Claude Code Windows対応ガイド｜Native/WSL2/WSL1の違いと選び方【2026年版】

「Claude Code Windows」で検索すると、WSL（Windows Subsystem for Linux）の導入を前提にした解説が目立つ。だが公式ドキュメント（code.claude.com/docs/en/setup）を確認すると、Windows上でClaude Codeを動かす方法はWSLだけではない。Native Windows・WSL 2・WSL 1という3つの選択肢が用意されており、WSLを一切使わずPowerShellやCMDだけで動かすことも可能だ。本記事は2026-08-11時点の公式ドキュメントに基づき、この3択の違い、インストール手順、Windows固有のつまずきどころを整理する。

読んでほしいのは主に次のような読者だ。普段Windowsをメイン環境として使っていて、Linux仮想環境の構築に手間をかけたくない開発者。すでにWSLを使ってClaude Codeを試したことがあり、Native Windowsとの違いを知りたい開発者。あるいは、チームにNative Windows派とWSL派が混在していて、それぞれの制約の違いを整理したいチームリードにも参考になるはずだ。

Claude Code全体の使い方・インストール・CLAUDE.md・Hooksまでを俯瞰したい場合は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き を参照してほしい。本記事はその中でも Windows 環境（Native Windows／WSL 2／WSL 1）に絞ったインストール手順とつまずきポイントを扱う。なお、GUIデスクトップアプリの「Claude Code Cowork」はCLIであるClaude Codeとは別製品で、本記事が扱うのはコマンドラインで動くClaude Codeの方なので混同しないようにしたい。

Native Windows対応が将来のバージョンで仕様変更される可能性はあるが、そこまでの変遷履歴は本記事では確認していない。断定できるのは「2026-08-11時点で公式ドキュメントがNative Windows・WSL2・WSL1の3択を明記している」という事実だけであり、本記事はこの時点の記述だけを根拠に選択肢を整理する。

Claude Code WindowsはWSL無しで動くのか？公式が示す3つの選択肢

結論から言うと、Claude Code WindowsはWSLが無くても動く。公式ドキュメントの「Set up on Windows」節は、Windows上でClaude Codeを使う方法として次の3つを並べて示している。

多くのUGC記事はWSL前提で書かれており、「Windowsで使うにはWSLが必要」という誤解を生みやすい。だが実際にはWindows システム要件（Windows 10 1809以降、またはWindows Server 2019以降。ハードウェアは4GB以上のRAM・x64/ARM64）さえ満たせば、Native Windowsとしてそのまま動かせる。Claude Code自体がどんなツールで何ができるのかを先に押さえたい場合は、Claude Codeとは？Anthropic公式AIコーディングツールの使い方・インストール・料金【2026年版】 を参照してほしい。

一方で、Native WindowsとWSL 2・WSL 1では対応できる機能に違いがある。特にSandboxingに対応するのはWSL 2のみという点は、上位のUGC記事では触れられていないことが多い差別化ポイントだ。サンドボックス実行を伴うワークフローを検討している場合は、この対応可否をあらかじめ押さえておく必要がある。

Sandboxing（サンドボックス実行）は、Claude Codeがコマンドを実行する際の隔離レベルに関わる仕組みで、対応可否は公式ドキュメントの比較表上で明示されている項目だ。「Windows インストール Claude Code」を検索している読者の多くはまずインストールを完了させたいだけのはずだが、後からサンドボックス実行が必要になった場合に選び直しが発生しないよう、最初の選択時点でこの対応表を確認しておく価値がある。

なお、Windows システム要件（Windows 10 1809以降、またはWindows Server 2019以降・4GB以上のRAM・x64/ARM64）は3つの選択肢に共通する前提条件であり、WSL2/WSL1を使う場合はこれに加えてWSL自体の有効化が必要になる。逆に言えば、Native Windowsを選ぶ場合はOSの標準要件を満たすだけで追加のセットアップ作業が発生しない。

比較表の「インストール元」の違いも実務上は重要だ。Native Windowsではインストーラーの実行そのものをPowerShellかCMDの中で完結できるのに対し、WSL2・WSL1はいったんWSL環境を有効化してから、そのWSLターミナルの中で改めてインストール操作を行うという2段構えになる。「とにかく早くclaudeコマンドを使いたい」だけなら、この段階の少なさもNative Windowsを選ぶ理由になり得る。

Claude Code Windowsのインストール手順｜ネイティブとWSLそれぞれのコマンド

Native Windows（PowerShell / CMD）

PowerShellの場合は次の1行を実行する。

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

CMDの場合はコマンドが異なる。PowerShell用のirm | iex構文はCMDでは動かないので、CMD専用のインストーラーを使う。

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

どちらの方法でも管理者権限は不要。インストール後は、バージョン確認と診断コマンドで正しく導入できたかを確認する。

claude --version
claude doctor

claude --versionはインストールされたバージョン番号を表示し、claude doctorは設定やPATHの状態を診断する。Windows インストール Claude Codeの手順としては、この3コマンドを実行すれば導入が完了する。

PowerShellとCMDでコマンドの書き方自体が違う理由は、インストーラーの配布形式がシェルごとに異なるためだ。irm ... | iexはPowerShell特有のパイプライン構文で、リモートスクリプトを取得してそのまま実行する。CMDにはこの構文が無いため、curlでスクリプトファイルを一旦ローカルに保存してから実行し、後片付けとしてdelで削除する、という3段階のコマンドになっている。どちらを使うかは、普段使っているターミナルアプリに合わせて選べばよい。

WSL 2 / WSL 1

WSLを選ぶ場合は、PowerShellやCMDからではなくWSLのターミナル内でLinux版のインストーラーを実行する。WSL自体の有効化（wsl --installなど）は別途必要で、WSL2かWSL1のどちらが有効化されているかによって、前述の比較表のとおりSandboxing対応可否が変わる。Claude Code WSLの導入という観点では、WSLターミナルを開いた後の手順はLinux環境向けのインストール方法と同じになる。

PowerShellやCMDのウィンドウでLinux版のコマンドを打っても動かない点には注意したい。WSLは「Windows上で動くLinux環境」であり、Claude CodeのインストーラーもWSL内では素直にLinux向けの手順で処理される。逆にNative Windows向けのインストールコマンド（irmやcurl -fsSL ... .cmd）をWSLターミナル内で実行する必要は無い。どちらの環境で作業しているかを意識し、対応するターミナルとコマンドの組み合わせを崩さないことが、Windows環境でのインストールをスムーズに終わらせるコツになる。

Windows固有のつまずき｜Git for Windowsの有無でシェルツールが変わる

Native WindowsでClaude Codeを使うときに最もつまずきやすいのが、Git for Windowsの有無によるシェルツールの挙動差だ。Git for WindowsはNative Windows利用時の任意インストールという扱いだが、入れているかどうかでClaude Codeの内部動作が変わる。

・Git for Windowsを入れていない場合：Claude CodeはBashツールでなく、PowerShellツールでシェルコマンドを実行する
・Git for Windowsを入れている場合：Git Bashを介してBashツールを使用する
・自動検出できない場合：settings.jsonのenv.CLAUDE_CODE_GIT_BASH_PATHにGit Bashの実行パスを明記する（例：C:\Program Files\Git\bin\bash.exe）

これはエラーとして表面化するわけではなく、「使えるツールの種類が静かに変わる」挙動であるため気づきにくい。Bashスクリプトを前提にしたワークフローがうまく動かない場合、まずGit for Windowsの導入状況とGit Bash Claude Codeの連携設定を疑うとよい。

この挙動を知らずにいると、「Claude Codeにシェルスクリプトを実行させたのに、想定していたBashの構文エラーになる」「ls -laのようなLinuxコマンドが期待通りに動かない」といった症状に遭遇したとき、原因の切り分けに時間がかかりやすい。まず疑うべきは、コード自体の不具合ではなく「今どちらのシェルツールが使われているか」という点だ。

Git Bashのパスが自動検出されない環境では、settings.jsonに次のようにパスを明記する。

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

このキーはあくまで「Git Bashの実行ファイルがどこにあるか」をClaude Codeに教えるためのものなので、Git for Windowsを標準的な場所にインストールしていれば通常は不要になる。インストール先をカスタマイズした場合や、複数バージョンのGitが共存している環境で自動検出が失敗する場合に効いてくる設定だ。

ネイティブWindowsとWSL、どちらを選ぶべきか

判断基準はシンプルで、Sandboxing（サンドボックス実行）が必要かどうかと、Linuxツールチェーンに依存しているかどうかの2点に集約される。

Windowsネイティブなプロジェクトやツールチェーンをそのまま使いたいだけなら、Native Windowsを選べば追加要件なしにすぐ始められる。逆に、Linux向けのビルドツールやパッケージマネージャーに依存する開発をしている、あるいはサンドボックス実行が前提のワークフローを組みたい場合は、Sandboxingに対応するWSL 2を選ぶのが公式ドキュメントの整理と一致する。WSL 1は「WSL2が使えない環境向け」という位置づけで、Sandboxing非対応という制約はNative Windowsと同じになる。

ネイティブ Windows Claude Codeという選び方は、既存のWindowsプロジェクトにAIコーディングエージェントを組み込みたい開発者に向いている。一方でDockerやLinux専用ツールを併用する開発フローでは、WSL 2側に寄せておいた方がトラブルが少ない。導入後の運用Tipsやワークツリー活用まで踏み込みたい場合は、Claude Codeベストプラクティス2026｜Boris直伝25 Tips・並列ワークツリー・–bare最適化 も合わせて参照してほしい。

判断に迷う場合は、次の観点で自分の開発環境を棚卸しするとよい。

・普段使っているツールチェーンは何か：Visual StudioやWindows専用のビルドツールが中心ならNative Windows、makeやLinux向けパッケージマネージャーが中心ならWSL 2が自然な選択になる
・サンドボックス実行を使う予定があるか：将来的にでも使う可能性があるなら、対応するWSL 2を最初から選んでおいた方が環境を作り直す手間を避けられる
・チームメンバーの環境と揃えたいか：チーム開発でmacOS/Linuxユーザーが多い場合、WSL 2に寄せておくと手順やトラブルシューティングの情報を共有しやすい
・すぐに試したいだけか：とにかく早く動かして試したいだけなら、追加要件のないNative Windowsが最短経路になる
・既存のシェルスクリプト資産があるか：Bash前提のスクリプトやCI設定をそのまま流用したいなら、WSL側かGit Bash併用のNative Windowsを選ぶと移植の手間が減る

これらはいずれも公式ドキュメントが示す対応表（要件・Sandboxing対応可否・向いている用途）から導ける判断基準であり、どれか1つに正解があるわけではない。自分の開発フローに合わせて選べばよい。

一度Native Windowsで始めた後に、必要になってからWSL 2へ移行する、という順序も選べる。3つの選択肢はどれか1つに固定しなければならないものではなく、プロジェクトやマシンごとに使い分けても構わない。たとえば普段使いのメインマシンではNative Windowsで軽量に動かしつつ、サンドボックス実行が必要な検証だけWSL 2環境で行う、といった併用も公式ドキュメントの整理上は矛盾しない構成になる。

まとめ｜Claude Code Windows対応の要点

この仕様は2026-08-11時点で公式ドキュメントに明記されている内容であり、将来のバージョンで変更される可能性がある点は留意しておきたい。WSL側のより詳細な機能制限（統合ターミナルや一部の連携機能がWSLセッションでは使えない、といった情報）は本記事執筆時点で一次ソース上での確認が取れておらず、あえて断定を避けている。気になる場合は公式ドキュメントの該当ページを直接確認してほしい。インストール後、プロジェクトルートに置くCLAUDE.mdの書き方まで整えたい場合は、CLAUDE.mdの書き方とは？セクション設計とauto memory・.claude/rules/の使い分け が参考になる。

最後に、記事冒頭でも触れた「Claude Code Cowork」との違いを改めて整理しておく。本記事が扱うClaude Codeはターミナル上で動くCLIツールで、PowerShell・CMD・WSLのいずれかからclaudeコマンドとして呼び出す。一方のClaude Code Coworkは、GUIのデスクトップアプリケーションとして提供される別製品であり、インストール方法もコマンドライン操作も本記事の内容とは一致しない。「claude code windows」で検索してGUIアプリを探していた場合は、CLIではなくCoworkの解説記事を確認したほうが早い。

参照ソース

・Advanced setup（公式ドキュメント） — システム要件・Windows対応表（Native Windows/WSL2/WSL1）・インストールコマンドを取得
・Claude Code公式インストールスクリプト（PowerShell向け） — Native Windowsインストーラーの実体を確認