環境のリセット方法 & トラブルシューティング

環境が不安定になった場合、または新しい開発環境を作成する必要がある場合は、コンテナー環境と WSL をリセットできます。

1. まず状態を確認する

リセットの前に、現在の状態を確認してください。GA で追加された診断コマンドが役立ちます。

  • コンテナー環境の状態を一目で確認します。

    wslc system info

  • 実行中・停止中のコンテナーを一覧表示します。

    wslc container list
    操作画面イメージ

  • コンテナーのアクティビティをリアルタイムに監視します。問題の発生タイミングを特定する際に有効です。

    wslc events

  • 特定のコンテナーのログを確認します。

    wslc container logs <コンテナー名>

2. コンテナー単位の対処

環境全体をリセットする前に、問題のあるコンテナーだけを対処できないか検討してください。

  • コンテナーを再起動する (GA で追加)

    wslc container restart <コンテナー名>

  • コンテナーを停止する

    wslc container stop <コンテナー名>

  • 停止に時間がかかる場合のタイムアウトを指定する (GA で追加)

    wslc run や wslc create の際に --stop-timeout を指定できます。-1 を指定すると無制限に待機します。

  • コンテナーからファイルを救出する (GA で追加)

    コンテナーを削除する前に、必要なファイルを取り出せます。

    wslc container cp <コンテナー名>:/path/to/file C:\path\to\destination

    注意: Windows からコンテナーへコピーする場合、コピー先 (コンテナー側) のディレクトリが存在しないと ERROR_PATH_NOT_FOUND エラーになります。/tmp/ など、存在するディレクトリを指定してください。

3. コンテナー環境のリセット

注意: 以下の操作はコンテナーとイメージを削除します。必要なデータは事前に wslc container cp で退避するか、ボリュームに保存されていることを確認してください。

  1. 実行中のコンテナーを停止する

    対象のコンテナーを個別に停止します。

    wslc container stop <コンテナー名>

  2. コンテナーを削除する

    wslc container rm <コンテナー名>

  3. イメージを確認して削除する

    wslc image list

    wslc image rm <イメージ名>

  4. ボリュームを確認して削除する

    モデル ファイルなどを保存したボリュームも削除する場合に実行します。

    wslc volume list

    wslc volume rm <ボリューム名>

INFO: ボリュームを残しておけば、コンテナーを作り直してもデータは保持されます。ローカル AI のモデルのように再取得に時間がかかるデータは、ボリュームを残すことをお勧めします。

4. WSL のリセット

コンテナー環境ではなく、WSL ディストリビューション自体をリセットする場合の手順です。

  1. WSL を停止する

    wsl --shutdown

  2. ディストリビューションの名前を確認する

    wsl --list

  3. ディストリビューションを削除する

    警告: --unregister はディストリビューション内のすべてのデータを削除します。Linux ファイル システム上のソース コードや設定も失われます。必要なデータは事前に Windows 側へ退避してください。

    wsl --unregister <DistroName>

  4. 再インストールする

    wsl --install -d Ubuntu-26.04

5. トラブルシューティング

wslc コマンドが見つからない

wslc は WSL の更新によって提供されます。以下を実行して WSL を最新化してください。

wsl --update

それでも解決しない場合は、microsoft/WSL のリリース ページから最新リリースを直接ダウンロードしてください。

なお、wslc.exe には組み込みの別名として container.exe が用意されています。こちらでも同じコマンドを実行できます。

ネットワークに接続できない / VPN 環境で通信できない

wslc は Consommé ネットワーク モデルを採用しており、トラフィックはセッションを所有するユーザーの権限で送信されます。通常の Windows プロセスと同様に扱われるため、VPN やファイアウォールとの互換性は高くなっています。

それでも問題が発生する場合は、WSL 側の設定を確認してください。

  • DNS の問題: dnsTunneling=true を設定すると、ネットワーク パケットではなく仮想化機能を使用して DNS 情報を取得します。VPN や高度なファイアウォール設定を使用している場合に有効です。
  • プロキシ環境: autoProxy=true を設定すると、Windows の HTTP プロキシ情報が WSL に自動的に適用されます。

注意: これらは %UserProfile%\.wslconfig の [wsl2] セクションに書く WSL ディストリビューション向けの設定です。wslc コンテナーのネットワークにも効果があるかは、公式ドキュメントでは明記されていません。

コンテナーから Windows 上のサービスに接続できない

コンテナー内の localhost はコンテナー自身を指します。Windows 上のサービスに接続するには、ホスト名 host.wslc.internal を使用してください。具体例は「ローカル AI タスク」のステップを参照してください。

イメージを取得できない (組織の環境)

組織で管理されている PC でイメージを取得できない場合は、エンタープライズ運用の章を参照し、IT 管理者に確認してください。

ディスク容量が不足する

各 wslc セッションは独自のストレージ VHD を持ち、既定では %LOCALAPPDATA%\wslc\sessions に配置されます。システム ドライブの空き容量が不足する場合、GA で追加された設定により既定セッションのストレージ パスを別のドライブに変更できます。変更方法は、ステップ 1「WSL と wslc のセットアップ」 の「6. ストレージの配置を変更する」を参照してください。

ファイル アクセスが遅い

WSL 上の Linux ツール (Docker Engine ルートなど) で開発する場合は、ソース コードを Linux ファイル システム側 (/home/<ユーザー名>/) に配置してください。Windows ファイル システム (/mnt/c/...) 上のファイルを Linux ツールから操作すると遅くなります。

なお、wslc ドライバーで Dev Containers を使う場合は、ソース コードを Windows 側のフォルダーに置きます (「Demo - VS Code を使用したリモート コンテナーでの開発」のステップを参照)。

wslc では Linux 環境から Windows ファイルにアクセスする際の性能が最大 2 倍高速化されていますが、それでも Linux 側に置くのが最善です。

compose を使いたい

現時点の wslc には compose サブコマンドがありません。 公式ブログによれば、これは最も要望の多い機能であり、次のイテレーションの重点項目とされています。公式は、既存の compose.yaml を変更せずに使えるようにすることを目標として表明しています (提供時期は未定)。

それまでの間は、コンテナー ランタイムの準備の補足で説明した Docker Engine ルートを併用してください。

その他

WSL の一般的なトラブルシューティングについては、公式トラブルシューティング ガイドを参照してください。

便利なツール

コマンド ラインでの管理に加えて、以下のコミュニティ ツールが利用できます。

ツール 形態 用途
Lazywslc TUI ダッシュボード ターミナル上で WSL コンテナーを管理
VS Code container extension VS Code 拡張 VS Code 上でコンテナーを管理 (wslc 対応)