Docker Desktop が使えない会社PCで、WSL2 + Docker Engine を通すまでに踏んだ5つのエラー

Docker Desktopは一定規模以上の企業では有償ライセンスの対象となるため、企業によっては会社PCへの導入が難しいケースがあります。私たちも、そうした制約のある環境でWSL2上にDocker Engineを直接導入する必要があり、実際に構築を進めたところ、5つのエラーに順番に遭遇しました。今回はその一つひとつと対処内容を記録します。

①Linuxカーネル更新プログラムが未実行

まず、WSL2のLinuxカーネル更新プログラムが実行されていない状態でエラーが発生しました。これはPCの再起動で解決しています。

②Microsoft StoreからUbuntuを導入できない

次に、Microsoft StoreからUbuntuを導入しようとしたところ、導入できない事象に遭遇しました。この事象は、UbuntuのAppxBundleを手動でインストールすることで解決しました。

③apt updateでコネクションエラー

WSL2内でapt updateを実行したところ、コネクションエラーが発生しました。これは社内プロキシ環境が原因で、/etc/environmentにプロキシ設定を追記することで解決しました。

④docker run hello-worldが失敗

Dockerの動作確認としてdocker run hello-worldを実行したところ失敗しました。こちらはiptablesの設定をiptables-legacyに変更した上で、service docker startを実行することで解決しています。

⑤docker daemonがタイムアウト

最後に、docker daemonの起動時にタイムアウトが発生しました。これは/etc/default/dockerにプロキシ設定を追記することで解決しています。

教訓：プロキシ問題は2箇所で別々に起きる

今回の一連の作業を振り返って印象的だったのは、プロキシに起因するトラブルがaptというOSレベルの仕組みと、docker daemonというアプリケーションレベルの仕組みの2箇所で、それぞれ独立に発生したことです。片方のプロキシ設定を直しただけでは解決せず、OS側とアプリ側の両方に同様の設定を入れて初めて一通り動くようになりました。

プロキシ環境下でのミドルウェア導入は、「1つ設定を直せば終わり」ではなく、レイヤーごとに同じ確認を繰り返す前提で臨む必要があります。

まとめ

Docker Desktopを使えない社内PC環境でWSL2 + Docker Engineを導入する過程では、カーネル更新、Ubuntu導入、apt通信、コンテナ起動、daemon起動という各段階でそれぞれ別のエラーに遭遇しました。特にプロキシ関連の設定はOSレベルとアプリレベルの両方に必要になる点は、同様の構成を検討する際に押さえておくとよいポイントです。

※ 本記事の検証は2026年7月時点のものです。