💻 6月3日の MS Build で開催される VS Code Live に参加しましょう。

WSL での開発

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

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

WSL Architecture

これにより、コードのホスト場所に関係なく、フル IntelliSense（補完）、コード ナビゲーション、デバッグ機能を含む、ローカルと同等の開発エクスペリエンスを VS Code が提供できるようになります。

はじめに

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

インストール

開始するには、以下が必要です:

  1. Windows Subsystem for Linux を、希望する Linux ディストリビューションとともにインストールする。

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

  2. Windows 側に（WSL 内ではなく）Visual Studio Code をインストールする。

    注: インストール中に [追加タスクの選択] を求められたら、[PATH に追加する] オプションを必ずチェックしてください。これにより、code コマンドを使って WSL 内のフォルダーを簡単に開けるようになります。

  3. WSL 拡張機能をインストールする。VS Code で他のリモート拡張機能を使用する予定がある場合は、Remote Development 拡張機能パックのインストールを選択できます。

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

WSL ターミナルから

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

  1. WSL ターミナルウィンドウを開きます（スタートメニューの項目を使用するか、コマンドプロンプト / PowerShell から wsl と入力します）。

  2. VS Code で開きたいフォルダーへ移動します（/mnt/c のような Windows ファイルシステムのマウント先を含みます）。

  3. ターミナルで code . と入力します。初めて実行する場合、VS Code が WSL 内で実行するために必要なコンポーネントを取得します。これには短時間しかかからず、初回のみ必要です。

    注: このコマンドが機能しない場合は、ターミナルを再起動するか、インストール時に VS Code がパスに追加されていない可能性があります。

  4. しばらくすると、新しい VS Code ウィンドウが開き、VS Code が WSL でフォルダーを開いているという通知が表示されます。

    WSL Starting notification

    VS Code は WSL 内で自身の構成を継続し、進行状況を常に通知します。

  5. 完了すると、左下隅に WSL インジケーターが表示され、通常通り VS Code を使用できるようになります！

    WSL Status Bar Item

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

VS Code から

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

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

すでにフォルダーを開いている場合は、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 は拡張機能をローカル（UI/クライアント側）または WSL 内のいずれかの場所で実行します。テーマやスニペットのように VS Code の UI に影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能は WSL 内に配置されます。

拡張機能ビューから拡張機能をインストールすると、正しい場所に自動的にインストールされます。インストール後、カテゴリーグループ化によってインストール先を確認できます。Local - Installed カテゴリーと、WSL 用のカテゴリーが表示されます。

Workspace Extension Category

Local Extension Category

注: 拡張機能の作成者で、拡張機能が正しく動作しない場合やインストール場所が間違っている場合は、Supporting Remote Development を参照してください。

リモートで実行する必要があるにもかかわらずローカルにインストールされた拡張機能は、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 で開くすべてのターミナルウィンドウ（[ターミナル] > [新しいターミナル]）は、ローカルではなく自動的に 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 内に保存されたソースコードを操作できます！以下の手順に従ってください。

  1. まだ行っていない場合は、Docker Desktop の WSL 2 サポートをインストールおよびセットアップしてください。

    ヒント: [設定] > [リソース] > [WSL 統合] に移動し、使用する WSL ディストリビューションとの Docker 統合を有効にしてください。

  2. まだ行っていない場合は、WSL 拡張機能と一緒に Dev Containers 拡張機能をインストールしてください。

  3. 次に、通常通りソースコードフォルダーを WSL で開きます。

  4. WSL でフォルダーが開いたら、コマンドパレット（F1）から Dev Containers: Reopen in Container を選択します。

  5. フォルダー内に .devcontainer/devcontainer.json ファイルがない場合、フィルター可能なリストから開始点を選ぶか、既存の Dockerfile または Docker Compose ファイル（存在する場合）を選択するよう求められます。

    Select a node dev container definition

  6. VS Code ウィンドウ（インスタンス）がリロードされ、開発コンテナーの構築が開始されます。進行状況通知でステータスの更新を確認できます。

    Dev Container Progress Notification

  7. 構築が完了すると、VS Code は自動的にコンテナーに接続します。これで、コンテナー内からソースコードを操作できます。

詳細については、Dev Containers のドキュメントを参照してください。

既知の制限事項

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

WSL 関連の有効な問題のリストについては、こちらを参照してください。

WSL 1 で開いているワークスペース内のフォルダー名を変更しようとすると EACCES: permission denied エラーが発生する

これは、VSCode によってアクティブになっているファイル監視機能が原因で発生する、WSL ファイルシステム実装の既知の問題です（Microsoft/WSL#3395, Microsoft/WSL#1956）。この問題は WSL 2 でのみ修正されます。

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

大規模なワークスペースでは、ポーリング間隔 remote.WSL.fileWatcher.pollingInterval を増やし、監視対象のフォルダーを制御したい場合があるでしょう: files.watcherExclude Open in VS Code Open in VS Code Insiders .

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
WSL 上でのみ Firebase via node が非常に低速になる Microsoft/WSL#2657

Git の制限事項

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

Container Tools 拡張機能の制限事項

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

拡張機能の制限事項

多くの拡張機能は修正なしで WSL で動作します。ただし、場合によっては特定の機能に変更が必要になることがあります。拡張機能で問題が発生した場合は、共通の問題と解決策のまとめを参照してください。問題を報告する際、拡張機能の作成者にこの情報を伝えることができます。

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

よくある質問

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

WSL: Connect to WSL using Distro を使用し、Windows 10 May 2019 Update (バージョン 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 側のいずれかでプロキシ設定が不足している可能性があります。

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

WSL ターミナルからリモート VS Code が開始されると、ダウンロードは WSL ディストリビューション内の wget を使用して行われます。プロキシ設定は以下で構成できます。

サーバーが稼働すると、Remote タブのプロキシ設定が使用されます。

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

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

たとえば、次の設定は、Container Tools 拡張機能をローカルで実行するように、および Remote - SSH: Editing Configuration Files 拡張機能をデフォルトとは逆にリモートで実行するように強制します。

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

"workspace" の代わりに "ui" という値を指定すると、拡張機能はローカルの UI/クライアント側で強制的に実行されます。通常、拡張機能が破損する可能性があるため、拡張機能のドキュメントに特記がない限り、これはテスト目的でのみ使用されるべきです。詳細は Supporting Remote Development を参照してください。

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

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

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

5/28/2026
© . This site is unofficial and not affiliated with Microsoft.