AIエージェント

Claude CodeをWSLで使う手順とは？Windowsでの導入方法と注意点を解説

Windows環境でClaude Codeを使おうとしたとき、多くの解説記事がWSL（Windows Subsystem for Linux）の導入から説明しているため、Linuxの知識が必要なのではないかと感じた方も多いはずです。実際、以前のClaude CodeはWindowsで動かすためにWSLを経由する必要がありました。

現在は状況が変わり、Claude CodeはWindows上で直接動作します。公式のシステム要件でもWindows 10 バージョン1809以降が対象に含まれ、WSLは必須条件ではなくなりました。それでもWSLを選ぶ理由は残っており、どちらを使うかは開発対象と必要な機能によって決まります。

この記事では、WSLとネイティブ環境の違いと選び方から、WSLの準備手順、Claude Codeのインストールと認証、環境設定、つまずきやすいエラーの対処、社内で運用する際の考え方までを順に整理します。実行するコマンドと確認方法もあわせて記載します。

確認したいポイント	結論	詳細
Claude CodeにWSLは必須？	必須ではなくネイティブでも動く	Windows 10 バージョン1809以降で直接動作します。WSLは選択肢の一つという位置づけに変わりました。
WSLとネイティブどちらを選ぶ？	Linux前提の開発ならWSL2	ビルドや依存関係がLinuxを前提とする場合や、サンドボックスを使いたい場合はWSL2が適しています。
Claude Codeの入れ方は？	WSL内で公式インストーラを実行	WSLのターミナルからインストール用コマンドを実行し、claude –versionで動作を確認します。
よくあるエラーの原因は？	PATHの設定とWSL1の利用が中心	コマンドが見つからない、実行できないといった不具合は、原因ごとに確認手順が決まっています。

この記事でわかること
✓ Claude CodeとWSLの関係がどう変わり、現在の要件はどうなっているか
✓ ネイティブWindows・WSL2・WSL1の違いと、自社に合う選び方
✓ WSLの有効化からClaude Codeのインストール、認証までの具体的な手順
✓ 作業ディレクトリやエディタ連携など、WSLで使うときの環境設定
✓ 起動できない、ログインできないといった不具合の原因と対処法

AI開発環境の整備を検討中の方へ｜サービス資料を差し上げます
開発体制へのAI活用の組み込み方、支援の進め方、費用の考え方をまとめた資料をご用意しています。社内での検討資料としてご活用ください。
▶ 資料請求フォーム からお申し込みいただけます。

Claude CodeはWSLなしでも動作する｜まず前提を確認する

解説記事の情報が古いまま残っているため、WSLが必須だと誤解されやすい状況があります。最初に現在の位置づけと動作要件を確認しておくと、この後の判断がしやすくなります。

WSLが必須だった時期と現在の違い

Claude Codeは当初、macOSとLinux向けのコマンドライン用ツールとして提供されていました。そのためWindowsで動かすには、Windows上にLinux環境を用意するWSLを経由する必要があったという経緯があります。

その後、Windowsへの対応が進み、現在はPowerShellやコマンドプロンプトから直接インストールして実行できます。WSLは選択肢の一つに位置づけが変わり、公式の案内でも用途に応じて選ぶ形になっています。

検索で見つかる手順の多くはこの変更以前に書かれたものです。記事の公開日を確認せずに進めると、必要のない環境構築に時間を使うことになります。

現在のシステム要件

公式ドキュメントに記載されている動作環境は、Windows 10 バージョン1809以降またはWindows Server 2019以降、メモリ4GB以上、x64またはARM64のプロセッサです。macOSは13.0以降、LinuxはUbuntu 20.04以降やDebian 10以降が対象になります。

利用には通信環境も必要です。認証と処理のためにインターネット接続が前提となるため、社内ネットワークで通信制限がある場合は、事前に許可設定の確認が必要になります。

シェルはBash、Zsh、PowerShell、CMDに対応しています。WSLで使う場合はWSL側のBashがそのまま利用でき、Windows向けのGitを別途入れる必要はありません。

【出典】Claude Code公式ドキュメント「Advanced setup」

それでもWSLを選ぶ理由がある

ネイティブで動くようになった今も、WSLを選ぶ理由は残っています。代表的なのは、開発対象がLinuxを前提としている場合です。本番環境がLinuxであれば、同じ環境で動かしたほうが挙動の違いに悩まされません。

もう一つは、コマンド実行を隔離するサンドボックスを使いたい場合です。この機能に対応しているのはWSL 2のみで、ネイティブWindowsとWSL 1では利用できません。

逆に、Windows向けのアプリケーションやツールを扱う開発であれば、ネイティブのほうが設定は簡単です。どちらが優れているかではなく、扱う対象で決まります。

ネイティブWindowsとWSLの違いと選び方

選択肢はネイティブWindows、WSL 2、WSL 1の三つです。それぞれ必要な準備と使える機能が異なるため、判断の材料を整理します。

三つの選択肢を比較する

ネイティブWindowsは追加の準備が不要で、インストール後すぐに使い始められる点が利点です。Windows向けのGitを入れておくとBashによるコマンド実行が使えますが、必須ではありません。入れていない場合はPowerShell側の仕組みでコマンドが実行されます。

WSL 2はLinuxカーネルを軽量な仮想環境で動かす仕組みです。準備の手間は増えますが、Linux向けのツールがそのまま動き、サンドボックスにも対応します。

WSL 1は仕組みが異なり、Linuxのバイナリを直接実行できない場合があります。サンドボックスにも対応していないため、WSL 2が使える環境であればWSL 2を選ぶのが基本です。

WSL 2が向いているケース

ビルド手順や依存パッケージがLinuxを前提としている場合は、WSL 2が向いています。本番環境と同じ構成で動作を確認できるため、環境差による不具合を減らせます。

コマンド実行の範囲を制限したい場合も同様です。エージェントが自動でコマンドを実行する使い方をするほど、実行環境を分けておく意味は大きくなります。

また、Linuxのコマンドやパッケージ管理に慣れている場合は、WSLのほうが作業が速く進みます。既存の手順をそのまま持ち込めるためです。

ネイティブWindowsが向いているケース

Windows向けのアプリケーションや、Windows上のツールと連携する開発では、ネイティブが適しています。ファイルの読み書きが速く、パスの扱いで迷う場面も少なくなります。

環境構築にかけられる時間が限られている場合も、まずはネイティブで始めるほうが現実的です。WSLは後から追加でき、両方を同じPCに共存させることもできます。

判断がつかない場合は、ネイティブで試して不都合が出た時点でWSLを検討する順序が無難です。最初から複雑な構成を組む必要はありません。

自社に合う環境構成を相談したい方へ｜無料相談を受け付けています
現在の開発環境と扱う案件の内容をうかがい、ネイティブとWSLのどちらが適しているか、運用ルールをどう決めるかを一緒に整理します。
▶ 無料相談フォーム からお申し込みいただけます。

WSLを準備する手順

WSLを使うと決めた場合の準備手順です。Windows側での有効化から、Linux側の初期設定、バージョンの確認までを順に進めます。

事前に確認しておくこと

まず、Windowsのバージョンを確認します。wsl –install という一つのコマンドで導入できるのは、Windows 10 バージョン2004（ビルド19041）以降またはWindows 11です。それより古い環境では手動での導入手順が必要になります。

また、仮想化に関する機能が有効になっている必要があります。企業から貸与されたPCでは管理者によって制限されている場合があるため、事前に情報システム部門へ確認しておくと手戻りを防げます。

ディスクの空き容量も見ておきます。Linuxの環境と開発用のパッケージを入れるため、数GB以上の余裕を確保しておくと安心です。

WSLとUbuntuを導入する

PowerShellを右クリックして管理者として実行し、wsl –install を入力してからPCを再起動します。このコマンドで、WSLの実行に必要な機能の有効化と、既定のディストリビューションであるUbuntuの導入がまとめて行われます。

再起動後にUbuntuが起動し、Linux側のユーザー名とパスワードの設定を求められます。ユーザー名は小文字で空白を含まない形にします。パスワードはWindowsのログインと同じである必要はありませんが、管理者権限のコマンドで使うため控えておきます。

初期設定が終わったら、パッケージの一覧と更新を適用しておきます。最初の実行では数分かかる場合があります。

【出典】Microsoft Learn「WSL のインストール」

WSL 2になっているか確認する

導入後は、PowerShellで wsl -l -v を実行してバージョン欄を確認します。ここが2になっていればWSL 2で動作しています。1と表示された場合は、この後のインストールで問題が起きる可能性があります。

1だった場合は、wsl –set-version の後にディストリビューション名と2を指定することで変換できます。変換には時間がかかるため、作業時間に余裕があるときに実施します。

この確認を先に済ませておくと、後述するエラーの多くを事前に回避できます。手順として省かないことをおすすめします。

WSL内にClaude Codeをインストールする手順

WSLの準備ができたら、Linux側にClaude Codeを導入します。ここで重要なのは、WindowsのPowerShellではなくWSLのターミナルから作業することです。

公式のインストーラで導入する

WSLのターミナルを開き、公式が案内しているインストール用のコマンドを実行します。curl でインストールスクリプトを取得して実行する形式で、macOSやLinuxと同じ手順が使えます。

この方法で導入される実行ファイルはNode.jsを必要としません。以前はnpmでの導入が中心でしたが、現在は専用のインストーラが推奨されており、権限まわりの問題も起きにくくなっています。

インストール後は自動更新が有効になり、起動時と実行中に更新の確認が行われます。更新の受け取り方は設定で変更でき、安定版を選ぶことも可能です。

動作を確認する

導入が終わったら、claude –version を実行してバージョン番号が表示されるか確認します。表示されれば実行ファイルは正しく配置されています。

より詳しく確認したい場合は claude doctor を使います。導入状態と設定ファイルの検証結果、警告と対処の案内が読み取り専用で表示されるため、原因の切り分けに役立ちます。

この二つのコマンドは、後から不具合が起きたときにも最初に実行する確認手段になります。覚えておくと調査が速くなります。

npmで導入する場合の注意点

npmでの導入も引き続き可能ですが、条件があります。バージョン2.1.198以降のパッケージはNode.js 22以降が前提で、それより古い環境では警告が表示されます。

またWSLでは、Windows側にインストールしたNode.jsを参照してしまう場合があります。この状態では導入や実行が正しく行われないため、後述する確認方法で参照先を見ておく必要があります。

権限エラーを避けるため、管理者権限を付けた形でのグローバル導入は行わないよう公式でも案内されています。エラーが出た場合は、権限を強制するのではなく導入方法を切り替えます。

ログインと利用に必要なプラン

インストールが終わってもログインでつまずくケースがあります。原因の多くは契約プランの条件を満たしていないことです。

対象となる契約の種類

Claude Codeを利用するには、Pro、Max、Team、Enterpriseのいずれかのプラン、またはConsoleのアカウントが必要です。無料のプランには含まれていないため、無料の状態でログインを繰り返しても解決しません。

Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryといった外部の提供基盤を経由して利用する方法もあります。社内の契約状況に応じて選択できます。

導入前に契約の種類を確認しておくと、環境構築とログインのどちらに問題があるのかで迷わずに済みます。

ログインの流れ

インストール後、claude と入力して起動するとブラウザでの認証に進みます。WSLの環境ではブラウザが自動で開かない場合があるため、表示されたURLをWindows側のブラウザに貼り付けて進める方法も使えます。

環境変数にAPIキーが設定されている場合は、ブラウザを開かずにそのキーを使うかどうかの確認が表示されます。会社の環境では、この設定が意図せず残っていることもあるため注意します。

認証が完了すると資格情報が保存され、次回以降はそのまま利用できます。

通信要件を確認しておく

認証と実行のために外部への通信が発生します。社内ネットワークで制限がかかっている場合、インストールは成功してもログインや実行の段階で止まります。

許可が必要な接続先は公式ドキュメントに記載されています。情報システム部門へ依頼する際は、この一覧を添えると確認が早く進みます。

プロキシを経由する環境では、WSL側にも設定を反映する必要があります。Windows側の設定はWSLに引き継がれないため、それぞれで指定します。

WSLで使うときの環境設定

動作するようになった後、快適に使えるかどうかは環境の作り方で変わります。特に作業場所の選び方は、体感速度に直結します。

作業ディレクトリはLinux側に置く

WSLからはWindows側のドライブを参照できますが、この経路を通したファイルの読み書きは明確に遅くなります。プロジェクトはLinux側のホームディレクトリ配下に置き、そこで作業するのが基本です。

速度だけでなく、権限の扱いでも違いが出ます。Windows側のフォルダでは、ツールによって書き込みが期待どおりに行われない場合があります。

既存のプロジェクトをWindows側に置いている場合は、WSL側に移すか、Windows側で作業するならネイティブでの利用に切り替える判断が必要です。

エディタとの連携

VS Codeを使う場合は、WSL接続用の拡張機能を入れてWSL側のフォルダを開きます。ターミナルの既定のプロファイルをWSLに設定しておくと、毎回切り替える手間がなくなります。

CursorのようにVS Codeを基にしたエディタでも、同じ拡張機能の仕組みが使えます。エディタ側のターミナルからそのままClaude Codeを起動する使い方が定着しやすい形です。

接続先を間違えたまま作業すると、エディタはWindows側、Claude CodeはWSL側という状態になり、変更が反映されていないように見えることがあります。

環境変数の扱い

Windows側で設定した環境変数はWSLには引き継がれません。逆も同様です。APIキーやプロキシの設定は、使う側の環境で個別に設定する必要があります。

WSLでは、シェルの設定ファイルに記述しておくと起動のたびに適用されます。設定した後は、新しいターミナルを開いて反映を確認します。

設定ファイルに機密情報を直接書く場合は、共有リポジトリに含めないよう管理方法を決めておきます。

よくあるつまずきと対処法

導入時に発生する不具合は、原因のパターンがある程度決まっています。エラーの表示ごとに確認すべき箇所を整理します。

コマンドが見つからない

インストールは完了したのに claude が実行できない場合、実行ファイルの場所がPATHに含まれていないか、導入した環境と実行している環境が違うのいずれかが原因です。

WSL内で導入したものをPowerShellから実行しようとしても動きません。その逆も同じです。ターミナルの表示がLinuxのユーザー名になっているかを確認します。

PATHの設定が原因の場合は、シェルの設定ファイルに実行ファイルの配置先を追加し、ターミナルを開き直します。

実行できないというエラーが出る

起動時に実行形式に関するエラーが表示される場合、WSL 1を使っていることが原因である可能性が高いです。特定のバージョン以降で、WSL 1の読み込み処理と実行ファイルの形式が合わない事象が報告されています。

対処は、ディストリビューションをWSL 2へ変換することです。PowerShellから変換コマンドを実行し、完了後に再度起動を確認します。

WSL 2に移行できない事情がある場合は、ネイティブWindowsでの利用に切り替える方法もあります。

Node.jsが見つからない

npmで導入した際に発生しやすいのがこの問題です。WSL内で which node や which npm を実行し、結果がWindows側のドライブを指している場合、Windowsのnode.jsを参照しています。

対処としては、Linux側のパッケージ管理やバージョン管理ツールでNode.jsを導入し、WSL内で完結する状態にします。導入時に対象のOSを明示的に指定する方法もあります。

そもそもnpmを使わない導入方法であればこの問題は起きません。特別な理由がなければ公式のインストーラを使うのが簡単です。

ログインが完了しない

認証画面まで進むのにログイン状態にならない場合、契約プラン、保存された資格情報、通信制限のいずれかが原因です。まず契約が対象に含まれているかを確認します。

資格情報が壊れている場合は、いったんログアウトしてから終了し、起動し直して再度ログインすると解消することがあります。

ブラウザが自動で開かない、あるいは認証待ちのまま進まない場合は、表示されたURLを手動でブラウザに貼り付けて進めます。

関連記事：MCPサーバーとは？仕組み・設定方法・セキュリティ対策

WSLで運用するときの安全面の考え方

個人での利用と業務での利用では、確認すべき点が変わります。特にコマンドを自動で実行させる使い方では、実行範囲の設計が重要になります。

サンドボックスが使えるのはWSL 2のみ

コマンドの実行を隔離する機能に対応しているのはWSL 2だけで、ネイティブWindowsとWSL 1では利用できません。自動実行を積極的に使う方針であれば、この点はWSL 2を選ぶ理由になります。

隔離されているとはいえ、WSLからはWindows側のファイルを参照できる設定が既定になっています。分離の度合いを高めたい場合は、参照範囲を制限する設定を検討します。

何をどこまで自動で実行させるかは、事前に決めておくべき事項です。導入後に個別判断で運用すると、範囲が広がっていきます。

権限とアクセス範囲を決める

業務で使う場合は、アクセスしてよいディレクトリと、実行を許可するコマンドの範囲を明文化しておきます。設定ファイルで制御できるため、チームで同じ内容を共有できます。

顧客の情報を含むリポジトリを扱う場合は、契約上の制約も確認が必要です。取り扱いの条件が定まっていない状態で使い始めるのは避けます。

利用状況を後から確認できるようにしておくと、問題が起きたときの調査が容易になります。

社内展開のルールを整える

複数人で使う場合、環境の差が問い合わせの原因になります。ネイティブとWSLのどちらを標準にするかを決めておくだけでも、対応の手間は大きく減ります。

導入手順、確認方法、問い合わせ先をまとめておくと、担当者ごとの試行錯誤を避けられます。手順書は実際の環境で一度検証してから配布します。

更新が頻繁なツールのため、手順書も定期的に見直す前提で用意します。

まとめ

Claude CodeはWindows上で直接動作するようになり、WSLは必須の条件ではなくなりました。それでもLinuxを前提とした開発や、コマンド実行を隔離したい場合には、WSL 2を選ぶ意味があります。

WSLで使う場合は、管理者権限のPowerShellからWSLを有効化し、Linux側のユーザー設定を済ませたうえで、WSLのターミナルからClaude Codeを導入します。導入後は claude –version と claude doctor で状態を確認します。

つまずきやすいのは、PATHの設定、WSL 1の利用、Windows側のNode.jsを参照している状態、契約プランの条件です。原因ごとに確認手順が決まっているため、順に切り分ければ解決できます。

業務で使う場合は、実行を許可する範囲と社内での標準構成を先に決めておくことが、後の運用負担を左右します。開発体制への組み込み方から検討したい場合は、現状の環境と対象業務の整理から始めてみてください。