SECTION 01
結論：WindowsならまずWSL2が無難、ただし一択ではない
WindowsでClaude Codeを使いたいなら、まずWSL2を入れるのが無難な選択肢です。ただし、2026年4月現在、これが唯一の方法というわけではありません。
Anthropicの公式ドキュメントでは、Claude CodeはWindowsでGit for Windowsか WSLが必要とされており、PowerShell・CMD・Git Bashのいずれからでも起動可能です。さらに公式トラブルシューティングでは、ケースによってはWSLよりネイティブWindowsのほうがファイルシステム性能がよいと案内されています。
自分はもともとCursorをWindowsで使っていたとき、PowerShellがコマンドを叩くたびにエラーを吐く問題に本当に悩まされました。ターミナル上でAIがコマンドを実行するたびに止まるので、開発どころではありません。
ところがWSL2を入れた瞬間、それまでの苦労が嘘のように消えました。Windowsの中にLinux環境が立ち上がるので、Claude Codeに限らずほとんどの開発ツールがMacと同じ感覚で動くようになります。
WindowsでClaude Codeを動かす選択肢は、大きく分けて以下の3つです。
- WSL2（Windows Subsystem for Linux） — Windows内にLinux環境を構築。Linux前提のツールチェーンと最も相性がよく、情報も多い
- Git Bash（Git for Windows） — 公式対応。WSLなしでも始められる手軽さが魅力
- PowerShell / コマンドプロンプト — 公式対応だが、Linux系コマンドとの相性問題が起きやすい
どれを選んでも動かすこと自体は可能です。Linux系ツールチェーンに慣れている方やトラブルを最小限にしたい方にはWSL2が安心ですが、軽く試したいだけならGit Bashから始めるのも合理的な選択です。
SECTION 02
PowerShellで起きること：著者が体験した現実
PowerShellを選びたくなる気持ちはわかります。Windowsに最初から入っているし、追加インストールなしで始められるのは魅力的に見えます。
現在のClaude Codeは公式にPowerShellからの起動をサポートしています。ただし、Claude Codeが内部で生成・実行するコマンドがLinuxシェルを前提にしている場面が多く、そこで摩擦が生じます。
CursorでPowerShellを使っていたとき、AIがコマンドを実行するたびに失敗するという体験をしました。パスの書き方が違う、コマンドが見つからない、権限が足りない。毎回手動で修正するのは現実的ではありません。
Claude Codeでも同様の構造的な問題が起きえます。たとえば以下のようなケースです。
rm -rfやchmodなどLinux系コマンドがそのまま通らない- パス区切りが
/ではなく\になり、スクリプトが破綻する - シェルスクリプト（
.sh）がPowerShellでは実行できない
これらは「設定を変えれば直る」レベルの問題ではなく、ツールの前提となるOS文化の違いから来ています。Claude Codeが生成するコマンドはLinuxシェルを想定していることが多いので、PowerShellで受け取ると翻訳コストが毎回発生します。
この翻訳コストを避ける手段としてWSL2やGit Bashがあります。PowerShellを完全に捨てるのではなく、開発用のターミナルだけをWSLやGit Bashに切り替えるという考え方で進めるのがポイントです。
SECTION 03
インストール方法：ネイティブインストーラーが基本
2026年現在、Claude Codeのインストールはネイティブインストーラーが推奨されています。以前はnpmでのグローバルインストールが主流でしたが、npm経由のインストールは現在deprecated（非推奨）となっています。
方法1：WSL2経由で使う場合
まずWindows側でWSL2を入れるところから始めます。
- Windows Terminalをインストール —
winget install Microsoft.WindowsTerminal - gsudo をインストール — 管理者権限の操作を楽にするツール。
winget install gerardog.gsudo - WSL2をインストール —
wsl --installだけで入る。再起動が必要な場合あり
WSL2のインストールが完了すると、Ubuntuが既定のディストリビューションとして入ります。Windows Terminalを開くとタブにUbuntuが表示されるので、そこからLinux環境に入れます。
WSL側でのClaude Codeインストールは、ネイティブインストーラーを使います。
curl -fsSL https://claude.ai/install.sh | bashこれだけで完了です。Node.jsの事前インストールも不要です。
方法2：ネイティブWindows（WSLなし）で使う場合
WSLを使わずにWindows上で直接始めたい場合は、まずGit for Windowsをインストールしてください。その後、PowerShellで以下を実行します。
irm https://claude.ai/install.ps1 | iexまたはwingetを使う方法もあります。
winget install Anthropic.ClaudeCodeインストール後は、PowerShell・CMD・Git Bashのいずれからでも claude コマンドで起動できます。
npm経由のインストール（互換用）
以前の npm install -g @anthropic-ai/claude-code も動作しますが、公式では非推奨です。npm経由で入れる場合はNode.js 18以上が必要になります。
特別な理由がない限り、ネイティブインストーラーを使うのが安全です。
SECTION 04
Windowsで詰まる失敗パターンと対処法
環境構築の手順通りに進めても、Windows固有の落とし穴にはまることがあります。ここでは実際に起きやすい失敗パターンと、その対処法をまとめます。
最も多いのが「コマンドが認識されない」というエラーです。claude と打っても command not found や 認識されていません になる場合、インストール先にPATHが通っていません。ネイティブインストーラーを使えばPATHは自動設定されますが、反映にはターミナルの再起動が必要な場合があります。
次に多いのが権限まわりのエラーです。以下のパターンに分かれます。
- npm互換ルートで権限エラーが出る → sudoで押し切るのではなく、ネイティブインストーラーに切り替えるのが安全です。公式でも
sudo npm install -gは推奨されていません - Windows側の実行ポリシーが
Restrictedのままでスクリプトが動かない - ファイルの書き込み権限がなく、Claude Codeがコード修正を反映できない
APIキーが読み込まれない問題も定番です。PowerShellで設定した環境変数はWSL側には引き継がれません。逆もまた同じです。WSLで使うなら ~/.bashrc に、PowerShellで使うなら $PROFILE にそれぞれ書く必要があります。
地味に痛いのが、iPhoneからAPIキーや認証コードを転記するときのもたつきです。MacならAirDropやユニバーサルクリップボードで一瞬ですが、Windowsだと手打ちになります。対策としては、クラウド上のパスワードマネージャーを経由するか、メールで自分に送って貼り付けるのが現実的です。
SECTION 05
VS Codeとの連携：ターミナルをWSLに切り替える
Claude CodeはCLIツールなので、VS Codeの統合ターミナルから直接使うのが最も自然な運用スタイルです。WSLを使う場合は、VS Codeの既定ターミナルがPowerShellになっているため、設定変更が必要です。
VS Codeの設定で terminal.integrated.defaultProfile.windows を検索し、既定のプロファイルを「Ubuntu (WSL)」に変更します。これだけで、VS Codeのターミナルタブを開いたときに自動でWSL環境に入ります。
ネイティブWindows環境で使う場合は、Git Bashをデフォルトプロファイルに設定するのも有効です。
CLIとエディタの作業分担を意識することも重要です。おすすめの使い方は以下の通りです。
- Claude Code（CLI）に任せる — コード修正、テスト生成、Git操作、ファイル作成
- VS Code（エディタ）で見る — 差分の確認、複数ファイルの俯瞰、デバッグ実行
- 判断が必要な場面 — Claude Codeの提案を見てからエディタで微調整
CursorやGitHub Copilotとの使い分けも気になるところでしょう。判断軸はシンプルで、エディタの中で補完を受けたいならCopilotやCursor、プロジェクト全体を横断して作業を任せたいならClaude Codeです。
CursorはGUIで操作する分だけ直感的ですが、Claude Codeはプロンプト一つで複数ファイルの修正からコミットまで一気に走るのが強みです。併用する場合は、日常の小さな補完はCopilot、まとまった作業はClaude Codeという棲み分けが実務では多くなります。
SECTION 06
導入後に最初にやる実務タスクとプロンプト例
環境構築が終わったら、実際のプロジェクトフォルダで試すのが一番の近道です。ターミナルで作業ディレクトリに移動し、claude コマンドで起動します。
最初に打つべきは、プロジェクトの全体像を把握させるプロンプトです。たとえば「このプロジェクトの構成を説明して」と聞くと、ディレクトリ構造やpackage.jsonの中身を読み取って概要を返してくれます。
次に、実務に近い連続タスクのフローを試してみます。以下のような流れがおすすめです。
- 「このファイルのバグを修正して」 — コード修正の基本動作を確認
- 「修正内容のテストコードを書いて」 — テスト生成の品質を確認
- 「変更をgit commitして」 — Git操作の一連の流れを確認
プロンプトは日本語で問題ありません。Claude Codeは日本語のプロンプトを自然に理解し、コード部分は英語、説明部分は日本語で返してくれます。ただし、エラーメッセージやログは英語で出力されるため、その部分だけ読み慣れておく必要があります。
ファイルの新規作成を依頼するときは、「○○というファイルを作って」ではなく、目的と仕様をセットで伝えるのがコツです。「ユーザー認証のAPIエンドポイントを作って。Express.jsで、JWTを使って、エラーハンドリングも入れて」のように書くと、より実用的なコードが返ってきます。
SECTION 07
WSLとWindowsのファイル共有で知っておくこと
WSLを使う場合、WSLとWindows間のファイル共有は可能ですが、落とし穴があります。WSLからWindowsのファイルにアクセスするには /mnt/c/Users/... というパスを使いますが、この経路はI/Oが遅いため開発には不向きです。
推奨されるのは、プロジェクトファイルをWSL側のファイルシステムに置くことです。~/projects/ のようなWSL内のディレクトリで作業し、VS Codeの「Remote - WSL」拡張を使ってエディタからアクセスします。
逆に、WindowsのデスクトップやダウンロードフォルダにあるファイルをWSLで使いたいときは、コピーしてWSL側に持ってくるのが安全です。以下のように使い分けます。
- 日常の開発 — WSL内のディレクトリで完結させる
- ファイルの受け渡し —
/mnt/c/経由でコピー、常用はしない - VS Codeからの編集 — Remote WSL拡張でWSL内を直接開く
なお、ネイティブWindows環境で使う場合はこのファイルシステム問題は発生しません。公式ドキュメントでも、ファイルシステム性能を重視するならネイティブWindowsのほうが有利なケースがあると案内されています。
Claude Codeがファイルパスを出力するとき、WSL内のパスとWindowsのパスが混在することがあります。/home/user/project/ と C:\Users\user\ が混ざると混乱しますが、WSL内で作業している限りはLinuxパスだけを見ればよいので、意識して切り分けてください。
Git操作もWSL側で完結させるのが鉄則です。Windows側のGitとWSL側のGitは別のインストールなので、設定（ユーザー名やメールアドレス）もそれぞれ個別に行う必要があります。
SECTION 08
それでも動かないときの切り分け手順
手順通りに進めても動かないケースは存在します。切り分けの基本は「どこで止まっているか」を特定することです。闇雲にコマンドを打ち直すより、原因の層を絞り込むほうが結果的に早く解決します。
まず確認すべきはインストールが正常に完了しているかです。claude --version を実行して、バージョンが表示されることを確かめます。npm互換ルートを使っている場合は node -v でNode.jsがv18以上であることも確認してください。
次に切り分けるのはネットワークの問題です。以下のチェックポイントを順に確認します。
claude起動後に認証が通らない → ブラウザのポップアップブロッカーを確認- APIキー設定済みなのに認証エラー →
echo $ANTHROPIC_API_KEY（WSL/Git Bash）または$env:ANTHROPIC_API_KEY（PowerShell）で変数が正しく展開されるか確認 - ネイティブインストーラーのダウンロードが止まる → プロキシ設定やファイアウォールを確認
WSLを使っていて不安定な場合は、WSLの再起動を試します。PowerShellから wsl --shutdown を実行し、再度WSLを開きます。WSL内部でメモリリークが起きていたりディスクが圧迫されていると、予期しないエラーが出ることがあります。
最終手段として、WSLのディストリビューションを初期化する方法もあります。ただし中のデータは消えるので、重要なファイルはバックアップしてからにしてください。wsl --unregister Ubuntu で削除し、Microsoft Storeから再インストールできます。
SECTION 09
それでもMacか？Windowsを選ぶ合理的な理由
正直に言うと、ソロで開発するならMacのほうが楽です。Unix系なのでターミナルのコマンド問題が最初から発生しませんし、iPhoneとの連携もシームレスです。これまでの経験から、Web開発を始めるならまずMacを勧めるのが自分の基本スタンスです。
しかし、Windowsを選ぶ合理的な理由も確かにあります。ハイスペックなWindowsマシンはMacと同等以上の性能をより安く手に入れられますし、GPUを活かしたローカルLLMの実行やゲームといった用途も一台でカバーできます。
試行錯誤の中で実感したのは、WSLを使いこなせれば、WindowsでもMacとほぼ同じ開発体験が手に入るということです。Claude Codeも、WSL上で動かす限りはMacとの差をほとんど感じません。さらに今はネイティブWindows対応も進んでいるので、WSLなしでも始められる敷居の低さがあります。
判断軸をまとめると以下のようになります。
- Macが向いている人 — Web開発メイン、Apple製品を普段使い、セットアップの手間を最小限にしたい
- Windowsが向いている人 — 高性能GPUが必要、ゲームもしたい、コスパ重視、WSLの学習コストを受け入れられる
- どちらでも問題ない人 — WSLを入れる前提で、好きなほうを選ぶ
大事なのは、「Windowsだから開発できない」という時代はとっくに終わっているということです。WSL2の登場以降、Windows上の開発環境は劇的に改善しました。Claude Codeのようなモダンなツールも、正しい環境を選べば快適に動きます。
SECTION 10
Windows＋Claude Code導入チェックリスト
最後に、この記事の内容をチェックリスト形式でまとめます。環境構築時に開いておくと、抜け漏れなく進められます。
パターンA：WSL2を使う場合
Windows側の準備は以下の通りです。
- Windows Terminalをインストール — wingetで一行
- gsudoをインストール — 管理者権限の操作を楽にする
- WSL2をインストール —
wsl --installで完了、再起動を忘れずに
WSL側の準備はこの順番で進めます。
- apt updateとupgrade — パッケージを最新にする
- Claude Codeをネイティブインストーラーで導入 —
curl -fsSL https://claude.ai/install.sh | bash - Gitをインストール — ユーザー名とメールの設定も忘れずに
パターンB：ネイティブWindowsで使う場合
- Git for Windowsをインストール — Claude Codeの動作に必要
- Claude Codeをインストール — PowerShellで
irm https://claude.ai/install.ps1 | iex、またはwinget install Anthropic.ClaudeCode
共通：認証と設定の確認
claudeコマンドで起動確認 — 初回はブラウザ認証- APIキーの設定（APIキー利用の場合） — WSLなら
~/.bashrc、PowerShellなら$PROFILEにそれぞれ設定 - 環境変数の展開を確認 —
echo $ANTHROPIC_API_KEY（WSL/Git Bash）または$env:ANTHROPIC_API_KEY（PowerShell）
共通：VS Codeの設定
- 既定ターミナルを変更 — WSLなら「Ubuntu (WSL)」、ネイティブなら「Git Bash」を
terminal.integrated.defaultProfile.windowsで設定 - Remote WSL拡張をインストール（WSL利用時） — WSL内のファイルをエディタで直接編集するため
- プロジェクトはWSL内のディレクトリに置く（WSL利用時） — I/O速度のため
/mnt/c/は避ける
ここまで完了すれば、WindowsでもClaude Codeを使った開発がストレスなく回り始めます。WSLルートでもネイティブルートでも、自分の開発スタイルに合ったほうを選んでください。
