【2026年】WSL2 Windows統合活用ガイド 2026｜GUI・GPU・ファイル共有の実践

WSL2 統合開発環境の現状と 2026 年の展望

2026 年 4 月時点において、Windows 上で Linux 環境を構築する「Windows Subsystem for Linux（WSL）」は、もはや単なる開発用ツールの一つを超え、エンジニアの標準的なワークフローに不可欠なインフラストラクチャとなっています。特に WSL2 の登場以降、仮想化技術とネイティブファイルシステムの融合が進み、ハイパフォーマンスな Linux カーネルを Windows 上で直接実行することが可能になりました。これにより、クラウドネイティブな開発から AI/ML 分野への GPU アクセラレーションまで、一つの OS で完結する環境が実現しています。2026 年において重要なのは、単に WSL をインストールすることではなく、Windows と Linux の境界をいかにシームレスに統合し、リソース効率を最大化するかという点にあります。

現在の主流である Windows 11 25H2 では、Hyper-V ベースの仮想化技術が大幅に最適化されており、WSL2 が使用する仮想マシン（VM）の起動速度は数秒未満に短縮されています。また、Linux カーネル 6.x シリーズのサポートも強化され、システムコールの互換性が向上しています。開発者にとっては、Windows のファイルエクスプローラーと Linux のコマンドラインを自由に行き来できる環境が重要であり、そのために WSLg（WSL GUI）やファイル共有機能の最適化が進んでいます。本ガイドでは、2026 年の最新スペックを持つ PC を前提に、WSL2 と Windows を深く統合するための実践的な設定方法を解説します。

WSL の導入は、単なるツールの追加ではなく、開発環境の設計思想そのものに関わります。例えば、GPU を使用する AI モデル学習を行う場合、CUDA ツールキットのバージョン管理やドライバとの相性が極めて重要になります。また、メモリ使用量の最適化やネットワーク設定における「mirrored mode」のような高度な機能を活用することで、従来の Docker 環境では得られなかったパフォーマンスを発揮できます。本記事では、Ubuntu 26.04 LTS や Debian 13 といった最新ディストリビューションの選定から、GPU アクセラレーションの実装、さらにはバックアップ戦略に至るまで、包括的な知識を提供します。

2026 年版おすすめディストリビューション比較と選定基準

WSL 環境を構築する際、最初に直面するのが「どの Linux ディストリビューションを採用するか」という選択です。2026 年現在、Microsoft Store から直接インストール可能な主要なディストリビューションは数多く存在しますが、開発の目的や個人のアレンジ性に合わせて最適な選択を行う必要があります。特に重要なのは、パッケージマネージャーの効率性、コミュニティの規模、そして WSL 特化のサポート状況です。ここでは、2026 年 4 月時点で推奨される主要なディストリビューションを比較し、それぞれの特性に合わせた選定基準を解説します。

まず、最もポピュラーで汎用性が高いのは Ubuntu です。Ubuntu 24.04 LTS の次の長期サポート版である「Ubuntu 26.04 LTS」は、2025 年 4 月にリリースされ、2030 年までセキュリティアップデートが提供されます。このバージョンでは、WSLg の動作安定性が向上し、X11 アプリケーションの描画遅延がさらに低減されています。また、Ubuntu 26.04 はビルドツール（GCC, G++, CMake）のサポートが非常に早く、開発のスタートアップ時間を短縮するのに適しています。一方で、サーバー環境との互換性を重視する場合は Debian が推奨されます。Debian 13（コードネーム：Trixie または Stable）は、その堅牢さからクラウドインフラの構築に広く採用されています。

Arch Linux も WSL で利用可能な選択肢の一つです。「Arch Linux for Windows」は公式にサポートされており、最新のパッケージを即座に入手したい開発者に好まれます。rolling release モデルにより、2026 年時点でも最新のライブラリや言語ランタイムを利用できますが、設定の手間と維持コストが高いという特徴があります。Fedora は Red Hat Enterprise Linux（RHEL）の upstream として機能しており、最新技術の実験に適しています。「Fedora WSL」は、Systemd のサポートが強く、コンテナ開発との親和性も高いです。各ディストリビューションの特徴を整理すると以下のようになります。

Ubuntu 26.04 LTS は、パッケージ管理システムが成熟しており、依存関係の解決に失敗するケースが比較的少ないため、初心者から中級者まで幅広く対応できます。Microsoft Store からインストールする場合、コマンド wsl --install -d Ubuntu-26.04 を実行することで迅速に環境を構築可能です。また、WSLg のサポート状況も 2025 年以降で大きく改善されており、GUI アプリケーションの動作がスムーズです。一方、Arch Linux はパッケージ更新頻度が高いため、WSL 仮想ディスクの容量管理には注意が必要です。

Debian 13 を選ぶ場合、その最小限のインストールサイズは WSL の軽量な起動を支援します。ただし、 proprietary デバイスドライバー（NVIDIA GPU など）の導入には追加の手順が必要になる場合があります。Fedora は Systemd の機能をフル活用できるため、バックグラウンドサービスの管理に優れています。各ディストリビューションの選択は、単なる好みの問題ではなく、プロジェクトの保守性やパフォーマンス要件にも直結します。2026 年において最もバランスが良いのは Ubuntu 26.04 LTS ですが、特定のニーズに応じて他の選択肢を組み合わせることも有効です。

GPU アクセラレーションの実装 NVIDIA CUDA と AMD ROCm の最適化

WSL2 環境における GPU アクセラレーションは、AI/ML 開発やグラフィカルな計算処理を行うエンジニアにとって最も重要な機能の一つです。2026 年時点では、NVIDIA の CUDA テクノロジーと AMD の ROCm プラットフォームの両方が WSL2 でネイティブにサポートされており、Windows 上の Windows Driver Model (WDDM) ドライバを介して Linux カーネルから直接 GPU にアクセスできるようになっています。この機能により、仮想マシンのオーバーヘッドを最小限に抑えつつ、GPU の性能をフル活用することが可能になります。

NVIDIA CUDA の利用には、最新の NVIDIA 驅動プログラムが必須となります。2026 年 4 月現在では「GeForce RTX 5090」や「RTX 5080」のような最新世代の GPU も一般的に使用されていますが、WSL2 で動作させるためには「NVIDIA CUDA Toolkit 13.x」シリーズと、対応する Windows ドライバ（バージョン 570.26 以降推奨）のインストールが必要です。設定手順としては、まず Windows 上で NVIDIA ダライバを最新化し、その後 WSL2 インスタンス内で nvidia-smi コマンドを実行して認識を確認します。もし GPU が認識されない場合は、WSL のバージョンが最新のビルドであるか確認し、Windows Update で Hyper-V コンポーネントを最新化することが重要です。

# Windows PowerShell での確認コマンド
wsl --list --verbose
nvidia-smi

AMD の ROCm（Radeon Open Compute）プラットフォームも同様に WSL2 でサポートされています。これは主に AMD Radeon RX 7000 シリーズや、2026 年時点で主流となる「RX 8900 XTX」などの GPU で利用されます。ROCm の設定は CUDA に比べて複雑で、環境変数の追加やカーネルモジュールのビルドが必要な場合がありますが、オープンソース志向の開発者には有利な選択肢です。特に Docker コンテナ内で ROCm を使用する際、ホスト OS と WSL2 の間のメモリ共有設定がパフォーマンスに大きく影響します。

GPU アクセラレーションの設定において注意すべきは、メモリの割り当てです。WSL2 が GPU にアクセスする際、VRAM（Video RAM）の他にシステムメモリとの通信帯域が必要です。例えば、大規模なモデル学習を行う場合、16GB 以上のシステムメモリを WSL に割り当てる .wslconfig の設定が推奨されます。また、温度管理も重要で、GPU の稼働時に 85°C を超える場合はスロットリングが発生し、性能が低下します。WSL2 のプロセス管理ツールの一部として、GPU 使用率を監視するスクリプトを実行することも有効です。

CUDA と ROCm の両方を利用するハイブリッド環境も構築可能です。この場合、各ライブラリのパスを適切に設定し、競合を防ぐ必要があります。具体的には、LD_LIBRARY_PATH や PATH 変数でライブラリ検索順を制御します。また、コンテナ環境（Docker Desktop）内でも GPU を利用したい場合は、Container Runtime の設定が別途必要になります。2026 年現在では、NVIDIA Container Toolkit が標準的にサポートされており、WSL2 上の Docker コンテナ内で CUDA アプリを実行する際のコマンドはシンプルになっています。

WSLg を活用した GUI アプリケーションの実行とディスプレイ設定

Windows と Linux の統合において大きな進化を遂げたのが「WSLg（Windows Subsystem for Linux for Graphics）」です。2026 年時点では、この機能により Linux 上の GUI アプリケーションが、まるで Windows ネイティブアプリケーションのように動作可能になっています。つまり、ターミナル画面内にウィンドウが表示されるのではなく、Windows のタスクバーやデスクトップ上で独立したウィンドウとして扱われるため、マウス操作やクリップボードの共有もシームレスに行えます。

WSLg を有効にするには、基本的な設定変更は不要ですが、Windows 11 25H2 以降のビルドが必須です。古いバージョンでは X11 サーバー（XServer）を別途インストールする必要がありましたが、現在は Linux カーネルに組み込まれた Wayland サーバーが標準で動作しています。Wayland は X11 に比べて描画遅延が低く、タッチ操作やマルチタッチにも対応しているため、WSLg での GUI アプリ体験は格段に向上しました。例えば、VS Code の拡張機能や GIMP、Blender などの重厚なグラフィックツールも、WSLg を介して快適に動作します。

GUI アプリを起動する際のコマンドは単純ですが、ディスプレイ設定にはいくつかの注意点があります。echo $DISPLAY コマンドで表示される値（通常は localhost:0）を確認し、その値が正しいか確認することが重要です。また、マルチモニター環境では、WSL のウィンドウがメインモニターのみに表示される場合があります。これを回避するためには、export DISPLAY=:0 などの環境変数を調整するか、WSLg の設定ファイルを変更してディスプレイ拡張を有効にします。

# WSL 内の確認コマンド
echo $DISPLAY
xhost +local:root # ローカルアクセス許可の確認

クリップボードの共有機能も WSLg の重要な要素です。Windows でコピーしたテキストは Linux で貼り付け可能になり、逆もまた同様です。この機能は wl-clipboard や xclip パッケージを利用することで強化されます。例えば、Web ブラウザで見つけたコードを即座に WSL 内のエディタに貼り付ける際、手動での再入力不要となるため作業効率が劇的に向上します。ただし、特殊な文字列や UTF-8 のエンコーディングが混在する場合は、一時ファイル経由で転送する方が安全な場合もあります。

WSLg は Windows 側のリソースを消費しますが、2026 年時点の OS はこの負荷を最小化するように最適化されています。GPU アクセラレーションとの併用時でも、描画パイプラインが効率的に処理されるため、フレームレート低下はほぼ発生しません。ただし、非常に重いグラフィカルなアプリケーション（例：高解像度の CAD ソフトや動画編集）を WSLg で動作させる場合は、Windows 側の GPU ドライバ設定や WSL の仮想ビデオメモリ割当を見直す必要があります。

ファイルシステム性能の最大化 /mnt/c 対策と 9P プロトコル

WSL2 と Windows 間のファイル共有は、開発効率に直結する重要な要素です。しかし、長年の課題として知られるのが「/mnt/c の遅さ」です。これは、Windows の NTFS ファイルシステムを Linux カーネルが WSL2 のファインダー（9P プロトコル）経由でアクセスするため、コンテキストスイッチやプロトコル変換のオーバーヘッドが発生することが原因です。特に、大量の小ファイルの読み書きや、バージョン管理システム（Git）の動作時にこの遅延は顕著になります。

2026 年時点では、この問題に対する対策がいくつか確立されています。まず推奨されるのが「Linux ファイルシステム内での開発」です。WSL の仮想ディスク（ext4）内にプロジェクトを配置し、Windows 側からは読み取り専用としてアクセスする形です。これにより、ファイル操作の速度は Linux ネイティブの速度に近づきます。具体的には、/home/user/project のようなパスで作業を行い、Git コマンドを実行します。

# WSL 内での推奨パス構成
cd /mnt/wsl/home/user/dev-project
git pull origin main
code . # VS Code が WSL 内で起動

もう一つの対策は「9P プロトコルの最適化」です。Windows のファイル共有を Linux から利用する際、\\wsl$ というパスを経由する方法があります。これは Windows エクスプローラーから直接 WSL ファイルシステムにアクセスできる機能であり、双方向のアクセスが高速化されています。例えば、Windows 上のエディタで WSL 内のファイルを編集するのではなく、WSLg で起動した GUI アプリや Windows のターミナル上で \\wsl$\Ubuntu\home\user というパスを指定して操作することで、ファイルシステムのオーバーヘッドを軽減できます。

また、クロスプラットフォームなファイル共有を行う場合、「SMB プロトコル」の利用も検討対象となります。Windows 上のフォルダーを WSL2 の SMB マウントポイントとしてマウントする場合、mount.cifs コマンドや mount -t cifs を使用します。ただし、この方法も NTFS との互換性により速度が低下する可能性があるため、開発用としては推奨されません。代わりに、WSL 内の ext4 ファイルシステムをバックアップや共有目的で Windows にエクスポートする場合は、.tar.gz アーカイブ形式での書き出しが最も効率的です。

2026 年現在、ファイル共有の最適化において「9P プロトコル」のパフォーマンスが向上したため、従来の問題点は軽減されています。しかし、それでも大規模なコンパイルやデータベースの構築を行う際は、WSL 内部でのファイル操作を基本方針とすべきです。また、WSL ファイルシステム内のファイルを Windows 側でバックアップする際、tar コマンドを使用して圧縮アーカイブを作成し、それを \\wsl$\Ubuntu\mnt\backup 経由で保存すると効率的です。

広告

リソース管理と systemd サポートによる常駐サービス構築

WSL2 は仮想マシンであるため、Windows 側のリソース（CPU、メモリ）を制限なしに使用しようとする傾向があります。これにより、ホスト OS のパフォーマンスが低下したり、他のアプリケーションの実行が阻害されたりするリスクがあります。そのため、.wslconfig ファイルによるリソース管理は必須のステップです。2026 年現在では、この設定ファイルの形式も標準化されており、より細粒度な制御が可能になっています。

.wslconfig ファイルは Windows ユーザーディレクトリ（%USERPROFILE%\.wslconfig）に配置されます。主なパラメータとして memory（割り当てるメモリ量）、processors（使用 CPU コア数）、swap（スワップファイルサイズ）が設定可能です。例えば、8GB のメモリの PC で WSL2 を使用する場合、memory=4GB として制限をかけることで Windows 側での動作を安定させます。また、autoSwap=true/false でスワップの使用を制御できます。

# .wslconfig 設定例
[wsl2]
memory=16GB
processors=8
swap=4GB
pageReporting=true
hyperVMemoryUsageLimit=90%

2025 年以降、WSL2 は「systemd」をネイティブにサポートするようになりました。これにより、Linux の標準的なサービス管理コマンド（systemctl start, stop, enable）が WSL 環境でも動作可能になります。以前は init システムの追加インストールが必要でしたが、現在はデフォルトで有効化されています。例えば、Nginx や MySQL を WSL2 内で常駐させる場合、システムダサービスとして登録することで、WSL の起動時に自動的に起動するようになります。

# systemd サービスの有効化例
sudo systemctl enable nginx
sudo systemctl start nginx
systemctl status nginx # ステータス確認

メモリ管理においては、「動的メモリ」のサポートも強化されています。Hyper-V 上の WSL2 は、ホスト OS の負荷に応じてメモリを動的に解放・取得する機能が実装されました。しかし、常に一定の性能を確保したい場合（例えばサーバーとしての利用）、固定値での割り当てが推奨されます。また、CPU のコア割り当てにおいて、論理プロセッサではなく物理コアに基づいた優先度を設定することも可能です。

ネットワーク構成の高度化 mirrored mode と DNS トンネリング

WSL2 のネットワーク機能は、従来の NAT（Network Address Translation）ベースから、「mirrored mode」や「DNS トンネリング」といった高度なモードへと進化しています。これは、開発者がコンテナ環境やクラウドインフラとの接続をよりシームレスに行うために必要な機能です。特に Docker コマンドや K8s 管理ツールの実行において、ホスト OS と WSL2 の IP アドレスの整合性が重要になります。

従来の WSL2 では、仮想 NIC が追加され、固有の IP アドレスが割り当てられていましたが、Windows からは直接アクセスできない問題がありました。しかし、「mirrored mode」では、WSL2 のネットワークトラフィックをホスト OS と共有するように設定でき、ポート転送やファイアウォールのルール適用が容易になります。このモードを使用するには、WSL のプロファイルで networkingMode=mirrored を指定します。

# PowerShell で mirrored mode に変更
wsl --set-default-version 2
wsl --update
# WSL2 の設定ファイル編集
Set-Content -Path $env:USERPROFILE\.wslconfig -Value "
[wsl2]
networkingMode=mirrored"

DNS トンネリングは、Windows の DNS サーバー設定を WSL2 に反映させる機能です。これにより、内部ドメインや社内ネットワークへのアクセスがスムーズに行われます。例えば、社内の GitLab インスタンスに WSL 内から接続する際、DNS 解決の遅延や失敗を防ぐために有効です。また、IPv6 のサポートも強化され、現代のネットワーク環境に対応しています。

ポート転送の設定は、WSL2 から外部へのアクセスが必要な場合に使用されます。例えば、WSD2 内で動作している Web サーバーを Windows ブラウザからアクセスさせる際、netsh interface portproxy add v4tov4 ... コマンドを使用します。しかし、mirrored mode を使用すれば、この設定は不要になる場合が多いです。

2026 年現在では、ネットワークモードの変更は WSL のバージョンアップに伴い簡単に行えます。ただし、セキュリティ上の理由からデフォルトは NAT モードのままです。開発者がコンテナ環境を構築する際や、ローカルサーバーとして WSL を使用する場合は、mirrored mode に切り替えることで設定の簡略化とパフォーマンス向上が期待できます。

仮想コンテナ環境 Docker Desktop vs Rancher Desktop vs Podman

WSL2 上でコンテナ環境を構築する際、どのランチャーを使用するかは重要な判断です。Docker Desktop は最も一般的ですが、Rancher Desktop や Podman もそれぞれ独自のメリットを持っています。2026 年時点では、これら各ツールの WSL2 統合度がさらに高まっており、選択の基準は明確化されています。

Docker Desktop は、WSL2 ベースバックエンドを標準で採用しています。これは、WSL ファイルシステム上で Docker Engine を実行し、コンテナを管理する仕組みです。ただし、Windows 上の Docker Desktop プロセス自体がリソースを消費するため、軽量な環境では Podman の方が適している場合があります。Docker Desktop の利点は、GUI ツールや拡張機能の充実です。

Rancher Desktop は、Docker と Kubernetes を統合して管理するオープンソースプロジェクトです。WSL2 上で動作し、Docker Desktop よりもリソース消費が抑えられている傾向があります。また、Open Source License に基づくため、企業利用でのライセンス料の問題がありません。Kubernetes クラスターのローカルテストに特化しているため、K8s 開発者には強く推奨されます。

Podman は、Docker と互換性がありながら、rootless（非ルート権限）で動作する設計になっています。WSL2 上で Docker コマンドをそのまま使用可能ですが、バックエンドは Podman Engine です。これにより、セキュリティリスクが低減され、コンテナの起動速度も Docker よりも高速です。

広告

2026 年現在、Kubernetes の開発フローでは Rancher Desktop がデファクトスタンダードになりつつあります。Docker Desktop は GUI ツールが必要なユーザー向けです。Podman はセキュリティ重視の環境や、軽量なスクリプト実行に適しています。各ツールのインストールは、WSL2 のターミナルから直接コマンドで可能です。

VS Code Remote WSL の設定と開発体験の向上

[Visual Studio Code（VS Code）の「Remote - WSL」拡張機能は、Windows と Linux 間の開発体験を劇的に変えるツールです。2026 年時点では、この拡張機能により、エディタの UI は Windows で表示されながら、実際のファイル処理やビルドプロセスが WSL2 内で実行されます。これにより、遅延のない編集と高速なコンパイルを両立します。

設定は非常にシンプルで、WSL2 インスタンス内のフォルダーを開く際に code . コマンドを実行するだけで OK です。ただし、拡張機能のインストールや、VS Code の設定ファイル（settings.json）での WSL 連携の有効化が重要です。具体的には、terminal.integrated.profiles.windows を WSL に設定し、エディタのコンソールで Git コマンドを即座に実行できるようにします。

// settings.json の例
{
    "terminal.integrated.defaultProfile.linux": "Ubuntu-26.04",
    "remote.WSL.showOutputWindowOnExtensionActivation": true,
}

開発体験の向上には、拡張機能の活用も重要です。「Python」や「C++」などの言語サポート拡張は、WSL 環境にネイティブインストールされているライブラリと連携します。例えば、pip コマンドが WSL2 内の Python 環境を指すよう設定することで、仮想環境（venv, conda）の管理がスムーズになります。

バックアップとリストア wsl --export/--import の運用戦略

WSL2 のデータを安全に保全するための標準的な手段は、wsl --export と wsl --import コマンドです。これにより、仮想ディスク全体をアーカイブとして保存し、別の PC や環境へ転送することが可能になります。2026 年時点では、この機能の信頼性が向上しており、大規模なデータセットでも正常に動作します。

エクスポート手順は、wsl --export <DistributionName> <ArchivePath.tar> を実行するだけです。例えば、Ubuntu 環境を ubuntu_backup.tar に保存する場合：

wsl --export Ubuntu-26.04 C:\backups\ubuntu_backup.tar.gz

リストア時は、新しい WSL インスタンスを作成し、wsl --import <DistributionName> <InstallLocation> <ArchivePath> を実行します。

バックアップの頻度は、プロジェクトの重要性によりますが、週に一度程度の実行が推奨されます。また、.wslconfig ファイルや環境変数の設定も別途ファイルとしてバックアップしておくと、復旧時に手間が減ります。

まとめ

本ガイドでは、2026 年時点での WSL2 と Windows の統合活用について包括的に解説しました。

• WSL2 最新機能: systemd、GUI アプリ（WSLg）、GPU アクセラレーション（CUDA/ROCm）の活用法を詳述。
• リソース管理: .wslconfig を使用したメモリ・CPU の最適化設定と動的メモリの活用。
• ファイル共有: /mnt/c 遅延対策および \\wsl$、9P プロトコルによる高速アクセスの実践。
• ネットワーク: mirrored mode と DNS トンネリングによるホスト OS 統合の高度設定。
• コンテナ: Docker Desktop, Rancher Desktop, Podman の比較と用途に応じた選択基準。
• バックアップ: wsl --export/--import を活用した環境の完全な保全戦略。

これらを設定することで、WSL2 は単なる Linux エミュレーターを超え、Windows 上で最強の開発環境へと進化します。各設定は開発者のニーズに合わせて調整し、効率的なワークフローを確立してください。

よくある質問（FAQ）

1. WSL2 のメモリ使用量が Windows を圧迫しないか？ .wslconfig ファイルで memory 値を制限することで回避できます。デフォルトは動的ですが、固定値を指定すると Windows のリソースが確保されます。

2. NVIDIA GPU が WSL2 で認識されない場合どうすれば？ まず Windows 側の NVIDIA ドライバが最新か確認し、WSL2 を再起動 (wsl --shutdown) してください。[CUDA Toolkit のバージョンとドライバの互換性も重要です。

3. U[bun](/glossary/bun-runtime)tu 26.04 LTS はいつリリースされる？ 2025 年 4 月に予定されており、2030 年までサポートされます。WSL にインストールする際は Microsoft Store から入手可能です。

4. WSLg で GUI アプリが起動しない原因は？ Windows 11 のバージョンが古くないか確認してください。また、Wayland サーバーの起動設定（export DISPLAY=:0）を確認します。

5. Docker Desktop と Rancher Desktop の違いは？ Docker Desktop は GUI ツールに強く、Rancher Desktop は K8s 環境構築や軽量さに優れています。K8s を多用するなら Rancher が推奨されます。

6. WSL2 のバックアップ方法について教えてください。 wsl --export コマンドでアーカイブを作成し、外部ストレージに保存します。リストア時は wsl --import を使用します。

7. /mnt/c でのファイル操作が遅い時の対策は？ プロジェクトファイルを WSL ファイルシステム内（例：/home/user/dev）へ移動して作業してください。Windows 側からの読み取りも可能ですが、書き込みは避けてください。

8. Mirrored Mode を有効にするには？ .wslconfig に networkingMode=mirrored を追加し、WSL を再起動します。これでホスト OS と IP が共有されます。

9. Systemd のサポートはどうすれば有効化できるか？ WSL2 標準でサポートされています。Windows Update でカーネルを最新に保てば自動的に有効になります。

10. WSL2 のネットワークポート転送は必要か？ Mirrored Mode に設定していれば不要です。NAT モードの場合は netsh コマンドによる手動設定が必要です。