以下の内容はhttps://error-daizenn.hatenablog.com/entry/2026/02/22/001547より取得しました。

DockerのWindowsコンテナ最新トラブル大全：透明ネットワーク、WSL、hcsshimエラーまで原因と対策を一気に整理

 

DockerのWindowsコンテナ最新トラブル大全：透明ネットワーク、WSL、hcsshimエラーまで原因と対策を一気に整理

DockerをWindowsで使っていると、Linux環境ではあまり見ない独特のつまずき方が起きます。代表例が「透明ネットワーク（Transparent Network）」の挙動不審、VM上でのネットワーク断、host.docker.internal が効かない、hcsshim::CreateScratchLayer failed のようなWindowsコンテナ特有のエラー、そしてDocker DesktopのWSL絡みの起動失敗です。
この記事では、Windowsコンテナ周りで最近よく話題になる問題を「原因の筋道」と「最短で効く対処」に寄せて整理します。単なる手順集ではなく、なぜそうなるのかを押さえたうえで再発を防ぐ構成にしています。

Windowsコンテナが詰まりやすい理由：まず全体像を掴む

WindowsでDockerを動かす場合、落とし穴はだいたい次の3層に分かれます。

  • Docker Desktop層：Desktop自体の設定・更新・バックエンド（WSL2 / Hyper-V）

  • Windowsネットワーク層：HNS（Host Network Service）や仮想スイッチ、Firewall、VMのNIC

  • Windowsコンテナ層：Windowsイメージの互換性、レイヤー管理（hcsshim）、サービス実行権限

ここを意識すると、症状から原因の層を切り分けやすくなり、闇雲に再インストールしなくて済みます。

透明ネットワーク（Transparent Network）が不安定：Hyper-VやVMware上で起きやすい

症状

  • WindowsコンテナにLANのIPを直で割り当てるつもりが、通信が途切れる

  • Hyper-V VM内で透明ネットワークを使うと外部へ出られない／外部から入れない

  • VMware上のWindows VMでTransparentが動かない、または不定期に死ぬ

原因の考え方

透明ネットワークは「コンテナをL2的にぶら下げる」発想なので、仮想化環境のvSwitch設定やMACアドレスの扱いに強く依存します。特にVMの中でさらに仮想スイッチを作る構造（入れ子）になると、以下が障害になりがちです。

  • MACスプーフィングが許可されていない（Hyper-Vで特に重要）

  • VMware側のセキュリティ設定で Promiscuous Mode / Forged Transmits / MAC Changes が制限

  • 物理NIC・vSwitch・HNSの組み合わせが崩れて、HNSのネットワークが破綻

まず効く対処（優先順）

  1. Hyper-V VMならMACスプーフィングを有効化
    VMのネットワークアダプター設定で「MACアドレス スプーフィングを有効」にする。

  2. VMwareなら仮想スイッチのセキュリティ設定を見直す
    上記3点（Promiscuous/MAC Changes/Forged Transmits）を許可寄りに。

  3. HNSネットワークの掃除（再生成）
    透明ネットワークが壊れていると、設定を直しても復帰しないことがあります。
    例：Docker停止 → HNSネットワークの再作成 → Docker起動、の流れで復旧しやすい。

  4. 透明ネットワークに固執しない選択肢も検討
    目的が「外部と疎通できること」なら、NAT型で要件を満たす設計（ポート公開）に寄せた方が安定するケースが多いです。特にVM上では顕著です。

host.docker.internal が繋がらない：WindowsコンテナとLinuxコンテナで前提が違う

症状

  • コンテナからホストの host.docker.internal:11434 に接続できない（GenAI系スタックやローカルAPIで頻発）

  • Linuxコンテナでは通るのにWindowsコンテナに切り替えたら死ぬ

原因の考え方

host.docker.internal は環境により「解決方法」が違い、Windowsコンテナでは名前解決や到達性が想定通りにならないことがあります。さらに、対象サービスがホスト側で localhost バインドだと、コンテナからは到達できません。

最短で効く対処

  • ホスト側サービスのListenアドレスを確認
    127.0.0.1 のみなら、0.0.0.0（または実IP）で待ち受けるよう変更。

  • Firewallでポートを許可
    Windows Defender Firewallがローカル向け以外を落としていることがあります。

  • 解決先IPを明示して検証
    host.docker.internal を捨てて、ホストの実IP（同一セグメント）に向けて疎通するか試す。
    これで通るなら、名前解決やDockerの特殊経路が原因側と切り分けできます。

hcsshim::CreateScratchLayer failed (0x3)：Windowsコンテナ特有の“レイヤー破損”系

症状

  • コンテナ起動時に「The system cannot find the path specified (0x3)」で落ちる

  • pull/build後に突然起動できなくなる

原因の考え方

Windowsコンテナのレイヤー管理は hcsshim が担います。ここで0x3系が出る場合は、ざっくり言うと

  • レイヤーの保存先パスが壊れている

  • ディスク容量やファイルシステム、ウイルス対策の干渉

  • Dockerのデータ領域とWindowsの整合性崩れ

のどれかです。

効きやすい対処

  • Dockerのクリーンアップ（未使用イメージ・コンテナ削除）

  • Docker Desktopのデータリセット（最終手段寄り）

  • 保存先ディスクの空きとファイルシステム健全性チェック

  • Windowsのリアルタイム保護／EDRがレイヤー生成を阻害していないか確認
    企業PCだとここが原因のこともあります。

再発するなら、特定のイメージや更新タイミングで発生していないか、Windowsのパッチ適用・Docker Desktop更新と相関を取るのが近道です。

WSLエラーでDocker Desktopが起動しない：再起動後に起きる定番パターン

症状

  • 再起動後にDocker Desktopが「Unexpected WSL error」などで立ち上がらない

  • WSLディストリやDockerのバックエンドが壊れたように見える

原因の考え方

Docker DesktopがWSL2バックエンドを使っている場合、**WSLの内部状態（仮想ディスク、サービス、統合機能）**が崩れると連鎖的に起動不能になります。Windows Update直後や、休止状態の復帰後に発生しがちです。

効く手当て（壊す前に順番を守る）

  1. WSLの再起動（サービス再起動相当）

  2. Docker Desktopの再起動

  3. WSLディストリ状態の確認（ディストリが壊れていないか）

  4. どうしてもダメならDocker側のデータ再生成
    ただしこれはイメージやボリュームを失う可能性があるため、重要データがボリュームにある場合は保全前提で。

Windows 11 / Proでのインストール失敗（0x80370109など）：仮想化まわりが“前提未達”

症状

  • Docker Desktopインストール中にエラーコードで止まる

  • WSL2や仮想化機能が有効なはずなのに進まない

原因の考え方

この手のエラーは多くが「仮想化の前提が揃っていない」か「機能はONでも実体が動いていない」です。

  • BIOS/UEFIで仮想化支援（Intel VT-x / AMD-V）が無効

  • Windowsの機能（Virtual Machine Platform / WSL / Hyper-V）が不足

  • セキュリティ機能や他社仮想化ソフトが競合

失敗を減らすコツ

  • まず WSL2を単体で正常動作させる（Docker前に土台を固める）

  • Hyper-V系を使うなら、競合しやすい仮想化ソフトの併用に注意

  • 企業端末はポリシーで機能が抑止されていることがあるため、管理側制約も視野に

Windows Server 2022コンテナ：サービス実行、別ユーザー起動、外部アカウントが難しい

症状

  • コンテナ内でWindowsサービスを起動したいがうまくいかない

  • 別ユーザーでプロセスを動かしたい

  • 外部アカウント（ドメインユーザー等）でサービス実行したい

原因の考え方

Windowsコンテナは、Linuxコンテナのように「何でもできる小さなVM」ではなく、ホストと密結合な制約があります。特に資格情報・ドメイン連携・サービス制御は、セキュリティ境界の都合で設計上難しいことが多いです。

現実的な落とし所

  • まずは「サービスとして動かす必然性」を見直し、フォアグラウンド実行＋監視に寄せる

  • 認証が必要なら、コンテナ外（ホストや別基盤）に寄せる、または gMSA などWindowsコンテナ向けの仕組みを検討

  • どうしても密なWindows機能が必要なら、コンテナではなくVMが適切な場合もある

Next.js SSR + Docker（Windows絡みで“バックエンドに繋がらない”）：本番だけ死ぬ典型

症状

  • 開発は動くのに、本番（SSR）でバックエンド到達不能

  • docker-compose では繋がる想定なのに、SSRだけ失敗

原因の考え方

SSRは「サーバー側で実行される」ため、ブラウザからのアクセスと経路が違います。ここにWindows特有のDNS・ネットワーク定義の差が重なると、次のような事故が起きます。

  • SSR側が localhost を見てしまい、コンテナ内を指してしまう

  • composeのネットワーク名解決が期待通りでない

  • Firewallやポート公開の設計ミスで、到達できるのは片方向だけ

まずやるべき確認

  • SSRが参照するバックエンドURLが コンテナ視点で正しいか
    localhost を使っていないか、サービス名解決になっているか。

  • composeで同一ネットワークにいるか、ポート公開が必要なのか（内向き通信なら不要な場合が多い）

  • Windowsコンテナ／Linuxコンテナの切り替えでネットワーク挙動が変わっていないか

まとめ：Windowsコンテナは「壊れ方の型」を知ると一気に楽になる

Windowsコンテナのトラブルは難解に見えますが、頻出の壊れ方はだいたい型が決まっています。

  • 透明ネットワークはVM上で不安定になりやすい。MACやvSwitchの制約を疑う

  • host.docker.internal は万能ではない。ListenアドレスとFirewall、実IP検証が近道

  • hcsshim 系はレイヤー破損・干渉・整合性崩れ。クリーンアップと環境要因の切り分け

  • WSLエラーは土台（WSL2）の健全性から順に戻す

  • サービス実行や別ユーザーは設計上の制約が強い。要件の再整理が効く

WindowsでDockerを安定運用するコツは、「症状の派手さに引っ張られず、層を切り分けて潰す」ことです。これだけで、再インストール地獄からかなり解放されます。



以上の内容はhttps://error-daizenn.hatenablog.com/entry/2026/02/22/001547より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14