KMMR Note

システムエンジニアの備忘録

  1. HOME
  2. 未分類
  3. WSL 3.0で何が変わった？WSL containers正式提供と更新方法

WSL 3.0で何が変わった？WSL containers正式提供と更新方法

  • 公開：2026.10.01
  • 更新：2026.10.01
  • 未分類

「WSL 3.0が出た」と聞くと、いま使っているUbuntuを移行する必要があるのか、Dockerを使う開発環境まで変わるのかが気になるところです。今回の大きな動きは、WindowsからLinuxコンテナーを扱えるWSL containersの正式提供です。

Microsoftは2026年9月29日にWSL containersの一般提供を発表し、WSL 3.0.1のリリースノートにも正式提供を記載しました。この記事では、WSL 2との番号の違い、更新方法、Nginxを動かす短い手順、Docker Desktopとの使い分けにつながるCompose対応の現状を紹介します。

目次

WSL 3.0と「WSL 2」は何が違う？

WSLには、ソフトウェア本体のバージョンと、Linuxディストリビューションを動かす方式の番号があります。今回の3.0.1はWSL本体のリリース番号です。一方、Ubuntuなどの一覧で表示される「WSL 2」は、Linuxカーネルを仮想マシンで動かす実行方式を指します。

確認するコマンド 表示される情報
wsl --version WSL本体やカーネルなど、各コンポーネントのバージョン
wsl --list --verbose 登録済みディストリビューションの名前・状態・実行方式（1または2）

つまり、WSL本体を3.0系へ更新した後も、ディストリビューションの一覧に「VERSION 2」と表示されることは矛盾しません。WSL containersもWSL 2のLinuxカーネルを使います。今回の更新を理由に、Ubuntuを「WSL 3」へ変換する操作は必要ありません。

出典：WSLの基本コマンド、WSL 3.0.1リリースノート。

WSL containersでできること

これまでWindowsでコンテナーを使っていた人にとって、最も分かりやすい変化はWSLに同梱されたwslc.exeからLinuxコンテナーを起動できることです。PowerShellからイメージを取得して実行したり、WebサーバーのポートをWindows側へ公開したりできます。

コンテナーは、アプリとその実行に必要な環境をまとめて扱う仕組みです。普段の作業用Ubuntuとは別に、Nginxのようなサービスを短時間試したいときにも使えます。操作用のCLIに加え、Windowsアプリからコンテナーを制御するAPIも用意されています。

正式提供の発表では、再起動、ヘルスチェック、ファイルのマウントなど、日常のコンテナー操作に関わる機能が紹介されています。細かな操作を調べるときは、wslc --helpや各サブコマンドのヘルプが入口になります。

出典：WSL containersの一般提供の発表。

WSLを更新してバージョンを確認する

WSLが導入済みのWindowsで、PowerShellまたはWindows TerminalのPowerShellタブを開き、次のコマンドを実行してください。

wsl --update
wsl --version
wslc version

最初のコマンドがWSL本体の更新、2つ目が更新後のコンポーネント確認、3つ目がコンテナー用CLIの確認です。正式提供版を利用する手順は通常のwsl --updateで案内されており、プレリリース版を入れるための--pre-releaseは不要です。3.0系の正式リリースとして公開されたのは3.0.1なので、更新後は実際の表示を確かめると迷いません。

WSLを初めて導入する場合は、MicrosoftのWSLインストール手順に沿って、必要な機能の有効化と再起動を済ませてから進めてください。

wslcが見つからない場合は、まずwsl --versionで更新結果を確認し、ターミナルを開き直して再度試してください。会社の管理端末では、WSL containersの利用や取得可能なコンテナーイメージが組織のポリシーで制限されている場合もあります。

出典：Microsoft Learn：WSL containersの入門手順、WSLの更新コマンド。

Nginxを起動してWindowsからアクセスする

コンテナーを使える状態になったら、WebサーバーのNginxを動かすと、起動からWindows側への接続までを一通り試せます。以下はMicrosoftの入門手順に沿った例で、コマンドはPowerShellで実行します。

コンテナーを起動する

wslc run -d --rm -p 8080:80 --name web nginx

webは、この例で付けるコンテナー名です。-dでバックグラウンド起動し、-p 8080:80でWindows側の8080番ポートをコンテナー内の80番ポートへつなぎます。初回はイメージを取得するため、ネットワーク接続とダウンロード用の空き容量が必要です。

Windows側の8080番を別のアプリが使っている場合は、-p 8081:80など空いている番号に変え、その後のアクセス先も同じ番号に合わせてください。ポート公開はWindowsのネットワーク設定やファイアウォールにも関わるため、社内・共有ネットワークでは既存の利用ルールに沿って試してください。

ブラウザーでアクセスする

Windowsのブラウザーでhttp://localhost:8080/を開いてください。Nginxのページが表示されれば、コンテナー内のWebサーバーへWindowsから接続できています。

ページが開かないときは、次のコマンドでコンテナーの状態とログを見て、起動に失敗しているのか、接続先やポートが合っていないのかを絞り込めます。

wslc container list
wslc container logs web

コンテナーを停止する

wslc container stop web

起動時の--rmにより、このコンテナーは停止すると削除されます。試用には便利ですが、コンテナー内だけに保存した変更を残したい用途では、ボリュームなどの永続化を用意してから使う必要があります。

出典：Microsoft Learn：コンテナーの起動・接続・停止。

Docker Desktopから移行できる？Compose対応が判断のポイント

Nginxを1つ起動する例を見ると、普段のDocker環境もそのまま置き換えられそうに感じるかもしれません。ただ、Webアプリとデータベースをcompose.yamlでまとめて起動しているなら、先にComposeへの対応状況を見る必要があります。

今回の一般提供の発表では、WSLcのCompose対応は今後の開発項目として説明されています。既存のcompose.yamlを変更せずに利用できることを目標にしていますが、正式提供された機能として紹介されたわけではありません。

そのため、既存のCompose構成が日々の開発に欠かせない場合は、現在のDocker環境を使いながら、WSL containersを単体コンテナーで試す進め方が取りやすいでしょう。起動コマンドの見た目が似ていても、実際の移行判断では、使っているオプション、データの保存先、開発ツールからの接続も確かめる必要があります。

Microsoftの発表ではVS CodeのDev Containersなどとの連携も紹介されています。エディターからの利用を中心に考える場合は、使っている拡張機能のWSLc対応と設定方法も合わせて確認してください。

出典：一般提供の発表：連携機能とComposeの計画。

ファイル共有とネットワークにも新しい仕組み

WSL containersでは、Windows側のフォルダーをコンテナーへ共有する際にvirtiofsを使います。Microsoftのアーキテクチャ解説では、従来のPlan9との比較でファイル共有の性能向上が説明されています。プロジェクトをWindows側に置く人にとって気になる変更ですが、ビルド全体が一律に速くなると考えるより、実際のファイル構成と処理で違いを見るのがよさそうです。

ネットワークにはConsomméというモデルが導入されています。WSLcセッションを所有するユーザーのWindowsプロセスとして通信を扱う設計で、VPNやファイアウォールとの互換性を高める狙いがあります。これらはWSL containersの仕組みとして紹介されている変更です。普段使っているUbuntuのマウントやネットワーク設定まで、同じ動作へ変わったと読み替えないようにしたいところです。

出典：WSLcのアーキテクチャ解説。

まずは小さなコンテナーから試す

WSL 3.0系の注目点は、WindowsからLinuxコンテナーを使うための入口がWSL本体に加わり、正式提供されたことです。まずは本体とwslcのバージョンを確かめ、Nginxのような単体コンテナーで起動・接続・停止を試すと、使い勝手をつかみやすくなります。

既存の開発環境を移すかどうかは、その後にCompose、データの永続化、エディター連携を見て判断できます。日常のUbuntu環境やDocker環境を使いつつ、新しい選択肢として試していくのが自然でしょう。

関連記事