編集

WSLでの開発

Name: Visual Studio Code
Author: Microsoft

Visual Studio Code WSL拡張機能を使用すると、VS Codeから直接Windows Subsystem for Linux (WSL)をフルタイムの開発環境として使用できます。Windowsの快適な環境から、Linuxベースの環境で開発し、Linux固有のツールチェーンとユーティリティを使用し、Linuxベースのアプリケーションを実行およびデバッグできます。

この拡張機能は、コマンドやその他の拡張機能をWSLで直接実行するため、パスの問題、バイナリの互換性、その他のクロスOSの問題を心配することなく、WSLまたはマウントされたWindowsファイルシステム (例: /mnt/c) にあるファイルを編集できます。この拡張機能は、VS Code ServerをWSL内にインストールします。サーバーは、WSL内の既存のVS Codeインストールとは独立しています。

WSL Architecture

これにより、VS Codeは、コードがどこでホストされているかに関係なく、完全なIntelliSense (補完)、コードナビゲーション、デバッグを含む**ローカル品質の開発エクスペリエンス**を提供します。

はじめに

注: このトピックを確認した後、入門WSLチュートリアルから始めることができます。

インストール

始めるには、以下が必要です。

お好みのLinuxディストリビューションとともにWindows Subsystem for Linuxをインストールします。

注: WSL 1には、特定の種類の開発に関して既知の制限があります。また、Alpine Linuxにインストールされた拡張機能は、拡張機能内のネイティブソースコードにおけるglibcの依存関係により動作しない場合があります。詳細については、Remote DevelopmentとLinuxの記事を参照してください。
Windows側 (WSL内ではない) にVisual Studio Codeをインストールします。

注: インストール中に**追加タスクを選択**するよう求められたら、codeコマンドを使用してWSLでフォルダーを簡単に開くことができるように、**PATHに追加**オプションを必ずチェックしてください。
WSL拡張機能をインストールします。VS Codeで他のリモート拡張機能を使用する予定がある場合は、Remote Development拡張機能パックをインストールすることを選択できます。

リモートフォルダーまたはワークスペースを開く

WSLターミナルから

VS CodeでWindows Subsystem for Linux内のフォルダーを開くのは、コマンドプロンプトまたはPowerShellからWindowsフォルダーを開くのと非常によく似ています。

WSLターミナルウィンドウを開きます (スタートメニュー項目を使用するか、コマンドプロンプト/PowerShellからwslと入力します)。
VS Codeで開きたいフォルダーに移動します (/mnt/cなどのWindowsファイルシステムマウントを含むが、これに限定されません)。
ターミナルにcode .と入力します。初めてこれを行う場合は、VS CodeがWSLで実行するために必要なコンポーネントをフェッチしているのが表示されます。これは短時間しかかからず、1回だけ必要です。

注: このコマンドが機能しない場合は、ターミナルを再起動する必要があるか、VS CodeがインストールされたときにVS Codeをパスに追加しなかった可能性があります。
しばらくすると、新しいVS Codeウィンドウが表示され、VS CodeがWSLでフォルダーを開いているという通知が表示されます。

VS CodeはWSLで自身を構成し続け、進捗状況を常に最新の状態に保ちます。
完了すると、左下隅にWSLインジケーターが表示され、通常どおりVS Codeを使用できるようになります。

これで完了です！このウィンドウで実行するVS Codeの操作はすべてWSL環境で実行されます。編集やファイル操作から、デバッグ、ターミナルの使用など、すべてです。

VS Codeから

または、VS Codeから直接WSLウィンドウを開くこともできます。

VS Codeを起動します。
F1キーを押し、デフォルトのディストリビューションの場合は**WSL: Connect to WSL**を、特定のディストリビューションの場合は**WSL: Connect to WSL using Distro**を選択します。
ファイルメニューを使用してフォルダーを開きます。

すでにフォルダーを開いている場合は、**WSL: Reopen Folder in WSL**コマンドを使用することもできます。使用するディストリビューションを選択するよう求められます。

WSLウィンドウにいて、現在の入力をローカルウィンドウで開きたい場合は、**WSL: Reopen in Windows**を使用します。

Windowsコマンドプロンプトから

Windowsプロンプトから直接WSLウィンドウを開くには、--remoteコマンドラインパラメーターを使用します。

code --remote wsl+<ディストリビューション名> <WSL内のパス>

例: code --remote wsl+Ubuntu /home/jim/projects/c

入力パスがファイルかフォルダーかを推測する必要があります。ファイル拡張子がある場合は、ファイルと見なされます。

フォルダーを開くように強制するには、パスにスラッシュを追加するか、以下を使用します。

code --folder-uri vscode-remote://wsl+Ubuntu/home/ubuntu/folder.with.dot

ファイルを強制的に開くには、--gotoを追加するか、以下を使用します。

code --file-uri vscode-remote://wsl+Ubuntu/home/ubuntu/fileWithoutExtension

Gitを使用する

WSLとWindowsで同じリポジトリを使用している場合は、改行コードを一貫して設定するようにしてください。詳細については、ヒントとコツを参照してください。

WSLがWindows Git資格情報マネージャーを使用するように構成することで、パスワードを回避することもできます。詳細については、ヒントとコツを参照してください。

拡張機能の管理

VS Codeは、拡張機能を2つの場所のいずれかで実行します。ローカルのUI/クライアント側、またはWSL内です。テーマやスニペットなど、VS Code UIに影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能はWSL内に配置されます。

拡張機能ビューから拡張機能をインストールすると、自動的に正しい場所にインストールされます。インストールされると、カテゴリグループに基づいて拡張機能がどこにインストールされているかを判断できます。**Local - Installed**カテゴリとWSL用のカテゴリがあります。

Workspace Extension Category

Local Extension Category

注: 拡張機能の作成者で、拡張機能が正しく動作しない、または間違った場所にインストールされる場合は、詳細についてリモート開発のサポートを参照してください。

実際にリモートで実行する必要があるローカル拡張機能は、**Local - Installed**カテゴリで薄く表示され、無効になります。リモートホストに拡張機能をインストールするには、**Install**を選択します。

Disabled Extensions w/Install Button

拡張機能ビューに移動し、**Local - Installed**のタイトルバーの右にあるクラウドボタンを使用して**Install Local Extensions in WSL: {Name}**を選択することで、WSL内にローカルにインストールされているすべての拡張機能をインストールすることもできます。これにより、WSLインスタンスにインストールするローカルにインストールされている拡張機能を選択できるドロップダウンが表示されます。

Install all extensions

WSLでターミナルを開く

VS CodeからWSLでターミナルを開くのは簡単です。フォルダーがWSLで開かれると、VS Codeで開く**ターミナルウィンドウ** (Terminal > New Terminal) は、ローカルではなく自動的にWSLで実行されます。

同じターミナルウィンドウからcodeコマンドラインを使用して、WSLで新しいファイルやフォルダーを開くなど、多くの操作を実行することもできます。コマンドラインで使用できるオプションを確認するには、code --helpと入力してください。

Using the code CLI

WSLでのデバッグ

WSLでフォルダーを開くと、アプリケーションをローカルで実行する場合と同じようにVS Codeのデバッガーを使用できます。たとえば、launch.jsonで起動構成を選択し、デバッグを開始する (F5) と、アプリケーションはリモートホストで起動し、デバッガーがそれにアタッチされます。

.vscode/launch.jsonでのVS Codeのデバッグ機能の設定に関する詳細については、デバッグのドキュメントを参照してください。

WSL固有の設定

WSLでフォルダーを開いた場合でも、VS Codeのローカルユーザー設定は再利用されます。これにより、ユーザーエクスペリエンスは一貫していますが、ローカルマシンとWSLの間でこれらの設定の一部を変更したい場合があります。幸いなことに、WSLに接続すると、コマンドパレット (F1) から**Preferences: Open Remote Settings**コマンドを実行するか、設定エディターの**Remote**タブを選択することで、WSL固有の設定を設定することもできます。これらの設定は、WSLでフォルダーを開くたびに、既存のローカル設定を上書きします。

高度: 環境設定スクリプト

WSLでVS Code Remoteが起動されると、シェル起動スクリプトは実行されません。これは、シェル用に調整された起動スクリプトでの問題を回避するために行われました。追加のコマンドを実行したり、環境を変更したりする場合は、セットアップスクリプト~/.vscode-server/server-env-setup (Insiders: ~/.vscode-server-insiders/server-env-setup) で行うことができます。存在する場合、スクリプトはサーバーが起動する前に処理されます。

スクリプトは有効なBourneシェルスクリプトである必要があります。無効なスクリプトはサーバーの起動を妨げる可能性があることに注意してください。サーバーの起動を妨げるスクリプトになってしまった場合は、通常のWSLシェルを使用してセットアップスクリプトを削除または名前変更する必要があります。

出力とエラーについては、WSLログ (**WSL: Show Log**) を確認してください。

高度な設定: コンテナー内のWSL 2フォルダーを開く

WSL 2とDocker DesktopのWSL 2バックエンドを使用している場合、Dev Containers拡張機能を使用して、WSL内に保存されているソースコードを操作できます。次の手順に従ってください。

まだ行っていない場合は、Docker DesktopのWSL 2サポートをインストールしてセットアップします。

ヒント: **設定 > リソース > WSL統合**に移動し、使用するWSLディストリビューションとDocker統合を有効にします。
まだインストールしていない場合は、WSL拡張機能とともにDev Containers拡張機能をインストールします。
次に、通常どおりWSLでソースコードフォルダーを開きます。
WSLでフォルダーが開いたら、コマンドパレット (F1) から**Dev Containers: Reopen in Container**を選択します。
フォルダーに.devcontainer/devcontainer.jsonファイルがない場合は、フィルター可能なリストから開始点を選択するか、既存のDockerfileまたはDocker Composeファイル (存在する場合) を選択するよう求められます。
VS Codeウィンドウ (インスタンス) が再ロードされ、開発コンテナーのビルドが開始されます。進捗通知によってステータス更新が提供されます。
ビルドが完了すると、VS Codeは自動的にコンテナーに接続します。これで、コンテナー内からソースコードを操作できます。

詳細については、開発コンテナーのドキュメントを参照してください。

既知の制限事項

このセクションには、WSLの既知の一般的な問題のリストが含まれています。これは、問題の完全なリストを提供するのではなく、WSLでよく見られるいくつかの一般的な問題を強調することを目的としています。

WSLに関連するアクティブな問題のリストはこちらを参照してください。

WSL 1で開いているワークスペース内のフォルダーの名前を変更しようとすると、EACCES: 権限拒否エラーが表示されます。

これは、VSCodeによってアクティブになっているファイルウォッチャーが原因で発生する、WSLファイルシステム実装の既知の問題 (Microsoft/WSL#3395、Microsoft/WSL#1956) です。この問題はWSL 2でのみ修正されます。

この問題を回避するには、remote.WSL.fileWatcher.pollingをtrueに設定します。ただし、ポーリングベースのファイル監視は、大きなワークスペースではパフォーマンスに影響を与えます。

大きなワークスペースの場合は、ポーリング間隔を長くしたい場合があるでしょう: remote.WSL.fileWatcher.pollingIntervalと監視するフォルダーを制御します: files.watcherExclude。

WSL 2にはこのファイルウォッチャーの問題はなく、新しい設定の影響も受けません。

WSL 1でのGolang

問題	既存の問題
DelveデバッガーがWSLで動作しない	go-delve/delve#810、Microsoft/vscode-go#926

WSL 1でのNode.js

問題	既存の問題
NodeJSエラー: spawn EACCES (このエラーの異なるバリアント)	Microsoft/WSL#3886
Webpack HMRが機能しない	Microsoft/WSL#2709
Nodeを介したFirebaseがWSLでのみ使用できないほど遅い	Microsoft/WSL#2657

Gitの制限

SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズがある場合、VS Codeのプルおよび同期機能がリモートで実行中にハングする可能性があります。パスフレーズのないSSHキーを使用するか、HTTPSを使用してクローンするか、コマンドラインからgit pushを実行して問題を回避してください。

Container Tools拡張機能の制限事項

コンテナーツール拡張機能はリモートとローカルの両方で実行できますが、すでにローカルにインストールされている場合、最初にローカルでアンインストールしない限り、リモートSSHホストにインストールすることはできません。この問題は、今後のVS Codeリリースで対処します。

拡張機能の制限事項

多くの拡張機能はWSLで変更なしで動作します。ただし、場合によっては、特定の機能に変更が必要になることがあります。拡張機能の問題に遭遇した場合は、問題報告時に拡張機能の作成者に伝えることができる一般的な問題と解決策の概要を参照してください。

さらに、Alpine Linuxベースのディストリビューションを使用している場合、WSLにインストールされた一部の拡張機能は、拡張機能内のネイティブコードのglibc依存関係により動作しない場合があります。詳細については、Linuxでのリモート開発の記事を参照してください。

よくある質問

デフォルトのディストリビューションを変更するよう求められるのはなぜですか?

**WSL: Connect to WSL using Distro**を使用し、Windows 10の2019年5月更新 (バージョン1903) より古いWSLで実行している場合、WSLコマンドはまだ-dオプションをサポートしていないため、デフォルトのディストリビューションでのみ動作できるため、**デフォルトのディストリビューション**を切り替えるよう求められます。

wslconfig.exeを使用して、デフォルトのディストリビューションを手動で切り替えることはいつでも可能です。

例

wslconfig /setdefault Ubuntu

インストールされているディストリビューションは、以下を使用して確認できます。

wslconfig /l

ライブラリまたは依存関係の欠落に関するエラーが表示されています。

一部の拡張機能は、特定のWSL Linuxディストリビューションのバニラインストールでは見つからないライブラリに依存しています。パッケージマネージャーを使用して、追加のライブラリをLinuxディストリビューションに追加できます。UbuntuおよびDebianベースのディストリビューションの場合、sudo apt-get install <package>を実行して必要なライブラリをインストールします。追加のインストール詳細については、拡張機能または言及されているランタイムのドキュメントを確認してください。

WSL拡張機能の接続要件は何ですか？

WSL拡張機能とVS Code Serverには、以下へのアウトバウンドHTTPS (ポート443) 接続が必要です。

update.code.visualstudio.com
vscode.download.prss.microsoft.com
marketplace.visualstudio.com
*.gallerycdn.vsassets.io (Azure CDN)

一部の拡張機能 (C#など) は、download.microsoft.comまたはdownload.visualstudio.microsoft.comからセカンダリ依存関係をダウンロードします。その他の拡張機能 (Visual Studio Live Shareなど) には、追加の接続要件がある場合があります。問題が発生した場合は、詳細について拡張機能のドキュメントを参照してください。

サーバーとVS Codeクライアント間のその他すべての通信は、ランダムなローカルTCPポートを介して行われます。VS Code自体がアクセスする必要がある場所のリストは、ネットワーク接続の記事で確認できます。

プロキシの背後にあり、接続の問題があります。

プロキシ設定がWindows側またはWSL側のいずれかで不足している可能性があります。

リモートウィンドウがVSCodeから開かれると、WSL拡張機能はWindows側でVSCodeサーバーをダウンロードしようとします。したがって、Windows側のプロキシ構成を使用します。

OS設定から継承
Visual Studio Codeでのネットワーク接続で説明されているとおり

リモートVSCodeがWSLターミナルから起動されると、ダウンロードはWSLディストリビューションでwgetを使用して行われます。プロキシ設定は次のように構成できます。

wgetプロキシ設定: https://stackoverflow.com/questions/11211705/how-to-set-proxy-for-wget
サーバーセットアップスクリプトで手動で

サーバーが起動して実行されると、リモートタブのプロキシ設定が使用されます。

拡張機能をローカル/リモートで強制的に実行できますか？

拡張機能は通常、ローカルまたはリモートのどちらかで実行されるように設計およびテストされており、両方ではありません。ただし、拡張機能がそれをサポートしている場合、settings.jsonファイルで特定の場所で強制的に実行できます。

たとえば、以下の設定では、コンテナーツール拡張機能をローカルで強制的に実行し、リモート - SSH: 設定ファイルの編集拡張機能をデフォルトではなくリモートで実行するように強制します。

"remote.extensionKind": {
    "ms-azuretools.vscode-containers": [ "ui" ],
    "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

"workspace"の代わりに"ui"の値を指定すると、拡張機能はローカルUI/クライアント側で強制的に実行されます。これは**拡張機能を壊す可能性**があるため、拡張機能のドキュメントで特に明記されていない限り、通常はテストにのみ使用する必要があります。詳細については、リモート開発のサポートに関する記事を参照してください。

拡張機能の作成者として、何をすべきですか？

VS Code拡張機能APIはローカル/リモートの詳細を抽象化するため、ほとんどの拡張機能は変更なしで動作します。ただし、拡張機能は任意のnodeモジュールまたはランタイムを使用できるため、調整が必要な状況があります。更新が必要ないことを確認するために、拡張機能をテストすることをお勧めします。詳細については、リモート開発のサポートを参照してください。

質問またはフィードバック

ヒントとコツまたはFAQを参照してください。
Stack Overflowで検索します。
機能リクエストを追加するか、問題を報告してください。
弊社のドキュメントまたはVS Code自体に貢献します。
詳細については、CONTRIBUTINGガイドを参照してください。

08/07/2025