全体概要

今回は、Docker Desktop for Windows を使わずに、Windows 上で Linux コンテナーの開発環境を構築します。

2026 年 9 月 29 日に WSL containers (wslc.exe) が一般提供 (GA) となり、Windows に標準搭載された CLI だけで Linux コンテナーをビルド・実行・配布できるようになりました。本ハンズオンでは、この wslc を主ルートとして環境を構築し、VS Code から開発・デバッグを行います。さらに ローカル AI ワークロード と エンタープライズ運用 まで扱います。

INFO: Windows に Docker の開発環境を構築する場合、従来は「Docker Desktop for Windows」を利用しますが、一定条件下では有償ライセンスが必要です。詳細は公式ページを参照してください。wslc は WSL に組み込まれた機能として提供されます。

WSL containers (wslc) とは

wslc.exe は、WSL に組み込まれた Linux コンテナー用の CLI です。wsl --update を実行するだけで入手でき、使い慣れたコンテナー コマンド体系をそのまま利用できます。組み込みの別名として container.exe も用意されています。

また WSL containers API が提供され、Windows ネイティブ アプリケーションからプログラム的に Linux コンテナーを実行できます。公式ブログでは、この API が解放するシナリオとして “running local AI workloads or using cloud-based containerized applications locally” (ローカル AI ワークロードの実行、クラウドのコンテナー化アプリのローカル実行) が挙げられています。

なぜ安全で、なぜ速いのか

wslc は WSL とは異なるアーキテクチャを採用しており、それが安全性と性能の根拠になっています。ここでは要点だけを押さえます。

1. セッション モデル — 権限を落とした分離

従来の WSL では、特権 Windows サービスである wslservice.exe が仮想マシンを保持していました。wslc ではこの設計が変わります。

  • wslc では、wslservice.exe は仮想マシンの所有権を保持しません。
  • 代わりに呼び出したユーザーの権限で動作する子プロセス wslcsession.exe を生成し、コンテナー作成・ディレクトリのマウント・ポートのバインドといったセッション操作はすべてこの子プロセスが代行します。

この結果、2 つの利点が生まれます。セッションごとに別プロセスで動くためセッション間が強く分離され、かつセッション操作が wslservice.exe より低い権限のプロセスで実行されるためセキュリティ境界が強化されます。

2. ストレージ — virtiofs による高速な共有

セッションの状態 (イメージ、コンテナー、ネットワーク、ボリューム) は、セッションごとの VHD に保存されます。wslc.exe を使う場合、この VHD は %LOCALAPPDATA%\wslc\sessions に置かれます。

Windows のパスをコンテナーと共有するボリュームは、Linux 仮想マシン内に virtiofs 共有としてマウントされ、コンテナーへバインド マウントされます。virtiofs はハイパーバイザーと仮想マシン間の相互運用のために設計された高性能ファイルシステムで、plan9 と比較して約 2 倍高速です。

ネイティブな Linux ファイルシステムが必要な場合や、ボリュームのサイズ上限を設けたい場合は、VHD を実体とする VHD ボリュームを使用できます。

3. ネットワーク — Consommé による高い互換性

wslc は Consommé という新しいネットワーク モデルを採用しています。Linux 仮想マシンのトラフィックはイーサネット フレームとして virtio キューへ送られ、ユーザーの権限で動作する Windows プロセスがこれを読み取って、DNS 応答・TCP/UDP ルーティング・ポート マッピングを提供します。

この方式の大きな利点は、仮想マシンから出るトラフィックが wslc セッションを所有するユーザーとして送信されることです。通常の Windows プロセスが発したトラフィックと同じように流れるため、VPN やファイアウォールとの互換性が高くなります。

INFO: アーキテクチャのさらに詳しい解説は、WSLC Architecture deep dive を参照してください。

ルートの選択 — wslc と Docker Engine

本ハンズオンでは wslc を主ルートとしますが、現時点の wslc には compose がありません。公式ブログでは “Our top feature request for WSLc is adding compose support, and this will be our focus for our next iterations.” とされ、次のイテレーションでの対応が予告されています。

そのため、以下の基準でルートを選択してください。

ルート 選ぶ基準 本ハンズオンでの扱い
wslc (主ルート) 単一コンテナーの開発、Dev Containers、ローカル AI を利用するアプリの実行。追加インストール不要で始めたい ステップ 2「コンテナー ランタイムの準備」 以降すべてこのルートで進みます
Docker Engine (代替) compose.yaml によるマルチサービス構成が必要 (DB + API + フロントなど) ステップ 2「コンテナー ランタイムの準備」 内の補足として手順を残しています

迷ったら wslc を選んでください。 マルチサービスが必要になった時点で、ステップ 2「コンテナー ランタイムの準備」 の Docker Engine 手順を追加実行すれば、両方を併用できます。

目次

  1. WSL と wslc のセットアップ
    • WSL を有効化し、wsl --update で wslc を入手します。最初のコンテナーを実行します。
  2. コンテナー ランタイムの準備
    • wslc ルートの確認と、compose が必要な場合の Docker Engine 代替手順を説明します。
  3. Git のインストール
    • GitHub 上のリポジトリをクローンするために Git をインストールします。
  4. Visual Studio Code のインストール
    • VS Code と拡張機能をインストールし、wslc を Dev Containers のドライバーとして設定します。
  5. Demo - リモート コンテナーでの開発
    • 既存のアプリ プロジェクトを Dev Container 化し、実行とデバッグを行います。
  6. ローカル AI タスク
    • Windows 上の Foundry Local でモデルをローカル実行し、その API を Windows 側と wslc コンテナーから呼び出します。
  7. エンタープライズ運用
    • Intune と Microsoft Defender for Endpoint による管理、ネットワーク制御、レジストリ許可リストを扱います。
  8. 環境のリセット & トラブルシューティング
    • 環境のリセット方法と、wslc の新しい診断コマンドを説明します。

ゴール

  • Windows 環境に wslc を使用して Linux コンテナーの開発環境を構築する
  • VS Code から Dev Container に接続し、コードの実行とデバッグを行う
  • ローカルで AI 推論ワークロードをコンテナー実行する
  • エンタープライズ環境で WSL コンテナーを統制するための選択肢を理解する

前提条件

  • ローカル環境の管理者権限が必要です。
  • BIOS でハードウェア仮想化を有効化してください。
  • WSL がサポートする Windows のバージョンであること。要件は公式のインストール手順を参照してください。
  • wslc を利用するには WSL バージョン 2.9.3 以降が必要です。wsl --update で WSL を最新化し、wsl --version でバージョンを確認してください。

注意: 本ハンズオンの手順は公式ドキュメントに準拠して作成していますが、お使いの Windows バージョンや組織のポリシーによって挙動が異なる場合があります。

参考資料