1. はじめに：WSL 2を入れたのに、なぜDockerは遅いのか

個人でPythonの開発をしていると、「環境の汚染」が気になってきます。

プロジェクト用にインストールしたライブラリが別のプロジェクトに影響を与えてしまったり、本番サーバーとローカルの環境がいつの間にかズレていたり。

最近であればよくAIを使った開発を行ったり、遊びでAIにWEB検索の結果を読み取らせたりといったことを行っています。
しかし、そこで心配になってくるのがプロンプトインジェクションや悪意あるコード実行になってきます。
AIだけではただ結果を読んで返答するだけですが、AIから受け取った内容を実行したり、出力するときに気を付けないと、おかしなコードを実行してしまう、ということは十分にあり得ます。

またライブラリに脆弱性のあるものが紛れてしまう危険性もあります。開発PCに入り込まれ、ほかのプロジェクトに設定していたAPIやenvファイルが盗み見られてしまう、ということも起こるかもしれません。

隔離した開発環境を作りたい。そこで自然とDockerに行き着くわけです。

そして多くの方が、最初のステップとしてWSL 2（Windows Subsystem for Linux）を有効化します。
「WSL 2を入れればDockerも速くなるはず」——そう思って環境を整えたのに、ファイルの読み書きが体感できるレベルで遅い、という壁にぶつかることがあります。

読み書きを繰り返す処理で明らかに遅くなったり、ライブラリのインストールに異常な時間がかかったりします。
ライブラリをインストールするときや、頻繁にデータのやり取りをするシステムだと、あまりにも速度が気になってしまい「これならDockerではなくてあきらめて仮想環境でいいのでは？」と思ってしまうほど。

私自身も最初はこの落とし穴にはまっていました（最初からちゃんと調べておくべきでした...）。
「Dockerとはこういうものか」と思って諦めかけていたのですが、調べていくうちに原因がわかりました。この記事は、同じところで悩んでいる方の参考になればと思い書いています。

原因は「Windowsのファイルシステム（Cドライブ）とLinuxコンテナの間でのデータのやり取りが遅い」という、Windows特有の構造的な問題でした。そして重要な事実があります——WSL 2を有効化するだけでは不十分なのです。

解決策は、ソースコードを置く場所を変えること——具体的には、WSL 2の内部領域（Ubuntuのホームディレクトリ）にコードを置くことでした。さらに、VS Codeの「Dev Containers」拡張機能を活用することで、コンテナ内を直接操作できる快適な開発環境が完成します。

この記事では、私が実際に行った環境構築を全6ステップで紹介します。

2. この記事で目指すゴール

この記事では、以下の環境を構築することを目標とします。

Windows 10 / 11 上で、WSL 2（Ubuntu）を「プロジェクトの保管場所」として正しく活用する
VS Code（Visual Studio Code）の拡張機能「Dev Containers」を使い、コンテナの中を直接いじれる状態にする
コードを保存したその瞬間に変更がコンテナに反映される、ストレスのない開発環境を実現する
コンテナを作り直しても、Gitの認証情報などが消えない仕組みを整える

構築後の開発体験は、Cドライブで作業していた頃と比べると明らかに別物でした。
特にファイルの同期速度については、「あの遅さは何だったのか」と感じるくらいです。

3. 前提条件：始める前に確認するもの

以下がインストール・設定済みであることを確認してください。

Windows 10 または Windows 11
WSL 2 が有効化済みであること
Docker Desktop（インストール済みであること）
Visual Studio Code
VS Codeの拡張機能「WSL」および「Dev Containers」

WSL 2の有効化や Docker Desktop のインストールがまだの方は、先にそちらを済ませてから本記事に進んでください。
この記事では「WSL 2が使える状態にあるWindows PC」を出発点として進めます。

4. 核心：「正しいファイル配置」こそが爆速化の鍵

本題に入る前に、この問題の原因をしっかり理解しておきましょう。
ここを理解することが、「WSL 2を入れただけで満足」という落とし穴を避けることに直結します。

WindowsとWSL 2（Linux）は、それぞれ別のファイルシステムを持っています。
Windowsが使うのは「NTFS」、LinuxはLinux独自の仕組みです。

❌ NGパターン：CドライブにコードをそのままDockerで動かす

Cドライブにコードを置いてDockerコンテナで動かすと、コンテナがファイルを読み書きするたびに、この「異なるシステム間の翻訳（マウント処理）」が発生します。
WSL 2を入れていても、コードの置き場所がCドライブ（Windowsの領域）のままでは、この翻訳コストは発生し続けます。これが速度低下の正体です。

✅ 正解パターン：WSL 2の内部領域にコードを置く

WSL 2の内部領域（Ubuntuのホームディレクトリ）にコードを置けば、コンテナはLinux同士でファイルのやり取りをするため、翻訳コストが大幅に軽減されます。

（Microsoft公式DevBlogでも、WSL 2 ファイルシステムの高速性については言及されています。完全なネイティブ Linux と同等ではありませんが、クロスファイルシステムのオーバーヘッドは実用上ほぼ無視できるレベルです。）
https://devblogs.microsoft.com/commandline/announcing-wsl-2/

WSL 2 は、最新かつ最高の仮想化技術を使用して、軽量ユーティリティ仮想マシン (VM) 内で Linux カーネルを実行します。ただし、WSL 2 は従来の VM 体験とは異なります。VM と聞くと、起動が遅く、非常に隔離された環境で動作し、多くのコンピュータリソースを消費し、管理に時間を要するものを思い浮かべるかもしれません。WSL 2 にはこれらの特性はありません。WSL 1 の優れた利点はそのままに、Windows と Linux の高度な統合、非常に高速な起動時間、小さなリソースフットプリント、そして何よりも VM の設定や管理が不要です。

これが「爆速」の理由です。

まとめると：

コードの置き場所	WSL 2の有無	速度
Cドライブ（NTFS）	あり	🐌 遅い（翻訳コスト発生）
Cドライブ（NTFS）	なし	🐌 遅い
WSL 2の内部（ext4）	あり	🚀 爆速

WSL 2を入れただけでなく、コードをWSL 2の内部に置くことが必須です。

🚀 検証：Windowsドライブ vs WSLネイティブの圧倒的な速度差

「本当に速くなるの？」と思う方のために、実際に計測した結果をお見せします。

Dev Containersを利用する際、プロジェクトファイルを「Windows側のドライブ（Cドライブや外付けSSD）」に置くか、「WSLの領域内」に置くかで、パフォーマンスにどれほどの差が出るかを検証しました。

検証用コード (`test_io.py`)

1,000個の微小なファイルを連続して「作成」および「削除」し、その処理時間を計測するシンプルなPythonスクリプトです。

import time
import os

# 1,000個のファイル操作テスト
FILE_COUNT = 1000
FILENAME_PREFIX = "test_file_"

def run_test():
    print(f"--- {FILE_COUNT}個のファイル操作テストを開始 ---")
    start_time = time.time()

    # 1. ファイル作成
    for i in range(FILE_COUNT):
        with open(f"{FILENAME_PREFIX}{i}.txt", "w") as f:
            f.write(f"test {i}")

    write_time = time.time() - start_time
    print(f"作成完了: {write_time:.2f} 秒")

    # 2. ファイル削除
    for i in range(FILE_COUNT):
        os.remove(f"{FILENAME_PREFIX}{i}.txt")

    delete_time = time.time() - (start_time + write_time)
    print(f"削除完了: {delete_time:.2f} 秒")
    print(f"合計時間: {write_time + delete_time:.2f} 秒")

if __name__ == "__main__":
    run_test()

検証結果

以下は筆者の計測環境における結果です。倍率は環境によって異なりますが、WSL領域が大幅に速いという方向性は共通しています。

計測環境：

項目	内容
CPU	AMD Ryzen 7 9700X
WSL	Ubuntu（VERSION 2）
Docker	28.5.1 (build e180ab8)

保存場所	合計処理時間	備考
Windowsドライブ (F: SSD)	2.60 秒	OSの境界を越える通信が発生
WSL領域 (Native)	0.02 秒	Linuxネイティブな高速処理

WSL領域に配置した場合、Windowsドライブに比べて約130倍もの高速化が確認できました（筆者環境での計測値）。

なぜこれほどの差が出るのか？

この圧倒的な速度差は、ディスク自体の性能ではなく「OS間の通信オーバーヘッド」に起因します。

Windowsドライブの場合: Dockerコンテナ（Linux）がWindows側のファイルにアクセスする際、「9P」と呼ばれるファイルアクセスをネットワーク越しにやり取りするための古いプロトコルを介して「翻訳」作業が発生します。1,000個のファイルを操作すると、この翻訳と通信が1,000回繰り返されるため、大きな遅延となります。
WSL領域の場合: WSL内のファイルシステム（ext4）に直接アクセスするため、翻訳の必要がありません。Linuxカーネルが本来の性能をフルに発揮できるため、一瞬で処理が完了します。

結論

数千〜数万のファイルを扱うモダンな開発（npm install、pip install、ビルド処理など）において、この差は数分から数十分の待ち時間の差となって現れます。

ストレスのない開発環境を構築するためには、プロジェクトフォルダを必ずWSL側のディレクトリ（\\wsl$\...）に配置することが良いでしょう。

5. 全体の構成〜6ステップの流れ

これから行う作業の全体像を整理しておきます。

Windowsという「母屋」の隣に、開発専用の「離れ（Ubuntu）」を建て、そこに「魔法の隔離環境（サンドボックスとしてのDockerコンテナ）」を設置するイメージです。

ステップ	作業内容
ステップ1	開発専用の「離れ」を建てる（Ubuntuのインストール）
ステップ2	DockerとUbuntuを連携させる（パイプをつなぐ）
ステップ3	プロジェクト用のフォルダをWSL側に作る（正しい配置）
ステップ4	VS CodeからUbuntuの部屋に入る
ステップ5	Dev Containersの設定ファイルを配置する
ステップ6	コンテナを起動する（魔法の隔離環境の完成）

それでは、1ステップずつ進めていきましょう。

6. ステップ1：開発専用の「離れ」を建てる（Ubuntuのインストール）

まず、Windows用の公式アプリストア「Microsoft Store」から、Linux環境のひとつである「Ubuntu」をインストールします。

Microsoft StoreからUbuntuを入手する

Windowsのスタートボタンをクリックし、検索窓に「store」と入力して、「Microsoft Store」を開く
ストア内の検索バーに「Ubuntu」と入力して検索する
検索結果にオレンジ色のロゴの「Ubuntu」が表示されるので、「入手」または「インストール」をクリックする

インストール完了後、「開く」ボタンをクリックすると黒い画面（ターミナル）が立ち上がり、セットアップが自動で始まります。

ユーザー名とパスワードを設定する

しばらく待つと、画面に Enter new UNIX username: と表示されます。
ここで、Ubuntu専用のユーザー名（半角英小文字）を入力してEnterを押します。

続いてパスワードを求められますが、ここには注意点があります。
パスワードを入力しても、画面には「*」などの文字が一切表示されません。
これはキーボードの不具合ではなく、Linuxのセキュリティ仕様です。
背後からパスワードを盗み見られないための仕組みのため、見えなくても入力はされています。そのまま入力してEnterを押してください。

確認用の再入力が求められるので、もう一度同じパスワードを入力します。

インストール完了の確認

画面に ユーザー名@パソコン名:~$ のような文字が表示されたら完了です。
黒い画面は右上の「×」で閉じて大丈夫です。

念のため、PowerShellを開いて以下のコマンドを実行してみてください。

【入力】

wsl -l -v

【結果】

  NAME              STATE           VERSION
* Ubuntu            Running         2
  docker-desktop    Running         2

一覧の中に「Ubuntu」が表示されていれば成功です。

7. ステップ2：DockerとUbuntuを連携させる（パイプをつなぐ）

次は、Windows側にある「Docker Desktop」の設定を変更して、先ほど作ったUbuntuからもDockerを使えるようにします。
この作業を省くと、Ubuntu上でDockerコマンドを実行できません。

Docker DesktopのWSL連携設定をONにする

注意： Docker Desktop はバージョンアップに伴いUIのメニュー構成が変わることがあります。
本手順は執筆時点（Docker Desktop v4.x系）の画面に基づいています。
お使いのバージョンで表記が異なる場合は、「WSL Integration」などのキーワードで設定画面を検索してください。

タスクトレイ（デスクトップ右下の時計周辺）にある Docker のロゴ（コンテナを運ぶクジラをモチーフにしたアイコン）をクリックして、Docker Desktopを開く

画面右上の歯車アイコン（Settings）をクリックして設定画面を開く
左側のメニューから「Resources（リソース）」＞「WSL Integration（WSL連携）」の順にクリックする

「Enable integration with my default WSL distro」にチェックが入っていることを確認する
その下にある「Ubuntu」というトグルスイッチをON（青色）にする
右下の青いボタン「Apply & restart（適用して再起動）」をクリックする

数秒から数十秒でDockerが再起動して、設定が反映されます。

連携が成功したか確認する

Ubuntuのターミナルを開き（スタートメニューから「Ubuntu」を検索）、以下のコマンドを入力してください。

docker version

クライアントとサーバー（Dockerデーモン）の両方のバージョン情報が表示されれば、連携成功です。

補足： docker -v でもバージョン番号は確認できますが、これはクライアント側の情報のみを返します。
WSLとの連携（Dockerデーモンへの接続）を確認するには、docker version を使う方が確実です。
docker version でサーバー情報が表示されない場合は、Docker Desktopの設定を見直してください。

8. ステップ3：プロジェクト用のフォルダを「WSL側」に作る（正しいファイル配置）

ここがこの記事のメインテーマです。

Ubuntuの中にソースコードを置くためのフォルダ（プロジェクトディレクトリ）を作ります。
速度の恩恵を受けるのは、このフォルダがUbuntu（WSL 2の内部）にあるからです。

重要： WindowsのCドライブに作ったフォルダをDockerコンテナにマウントしてはいけません。WSL 2を入れていても、コードの置き場所がCドライブのままでは「4. 核心」で説明した翻訳コストが発生し、速度の恩恵を受けられません。

エクスプローラーでUbuntuの中に入る

Windowsのエクスプローラー（黄色いフォルダアイコン）を開き、上部のアドレスバーに以下を入力してEnterを押します。

\\wsl.localhost\Ubuntu

（\\wsl.localhost は Windows 11 以降で推奨されます）

ホームディレクトリにプロジェクトフォルダを作る

Ubuntuの中に入ったら、以下の順番でフォルダを移動します。

home フォルダを開く
その中にある、ステップ1で設定した「あなたのユーザー名」のフォルダを開く

このフォルダが、あなた専用の作業スペース（ホームディレクトリ）です。

このフォルダ内の何もない白い部分を右クリックし、「新規作成」＞「フォルダー」を選択して、新しいフォルダを作ります。
名前は今回 my_project とします（スペースを含まない半角英数字が望ましいです）。

重要なのは、作ったのが「Cドライブ」の中ではなく、「Ubuntuの中」であるという点です。
この違いが、後の動作速度に直結します。

9. ステップ4：VS CodeからUbuntuの部屋に入る

ここが今回の環境構築における最大のポイントです。
VS Codeの画面はWindowsに表示されたままですが、裏側で操作しているのはUbuntuのファイルシステムになります。

VS CodeをWSLに接続する

VS Codeを起動する
画面左下に表示されている「><」という形の小さなアイコン（リモートインジケーターと呼ばれます）をクリックする

画面上部に表示されるメニューから「Connect to WSL」（日本語表示の場合は「WSL に接続」）をクリックする

もし「Connect to WSL」が表示されない場合は、VS Codeの拡張機能「WSL」がインストールされていない可能性があります。
左側のブロックマーク（拡張機能アイコン）から「WSL」と検索してインストールしてください。

Ubuntuへの接続を確認する

接続が完了すると、VS Codeの画面左下のアイコン横に「WSL: Ubuntu」という文字が表示されます。
この表示が出れば、VS CodeがUbuntuの部屋に入室できた合図です。

プロジェクトフォルダを開く

VS CodeがWSLに接続された状態で、「ファイル」＞「フォルダーを開く...」をクリックします。
パス入力欄に以下のように入力して「OK」をクリックしてください。

/home/あなたのユーザー名/my_project

「このフォルダーの作成者を信頼しますか？」という警告が表示されたら、「はい、作成者を信頼します」を選んでください。
自分で作ったフォルダなので問題ありません。

VS Codeの左側のファイルエクスプローラーに「MY_PROJECT」と表示されれば、このVS Codeは「Ubuntuの世界」のファイルを直接操作しています。

10. ステップ5：Dev Containersの設定ファイルを配置する

次は、「どんな開発環境を作るか」をDockerに指示するための設定ファイルを配置します。

Dev Containersは、VS Codeの拡張機能の中でも特に強力な機能です。コンテナの中を直接VS Codeで操作でき、拡張機能の自動インストールや初期セットアップコマンドの自動実行なども設定できます。

2種類の「設計図」ファイルを用意します。

フォルダの構成

最終的に、以下のようなファイル構成になることを目標にします。

my_project/
 ├── .devcontainer/
 │   ├── devcontainer.json
 │   └── Dockerfile
 └── requirements.txt

`.devcontainer` フォルダを作成する

VS Codeの左側のファイルエクスプローラーで、「MY_PROJECT」の文字にマウスを乗せると「新しいフォルダー」のアイコンが表示されます。
そのアイコンをクリックして、以下の名前を入力してください。

.devcontainer

先頭の「.（ドット）」を忘れないよう注意してください。
これが Dev Containers の目印になります。

設計図その1：`devcontainer.json` を作成する

.devcontainer フォルダを選択した状態で、「新しいファイル」をクリックし、devcontainer.json という名前で作成します。
ファイルを開いたら、以下の内容を貼り付けて保存（Ctrl + S）してください。

このファイルは、VS Codeに対して「この開発環境にはどの拡張機能を最初から入れてほしいか」「コンテナ作成後に自動で実行するコマンドは何か」などを指示する設定ファイルです。

{
  "name": "My Dev Environment",
  "build": {
    "dockerfile": "Dockerfile",
    "context": ".."
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "github.copilot"
      ]
    }
  },
  "remoteUser": "vscode",
  "postCreateCommand": "python -m pip install --upgrade pip"
}

各設定の意味は以下の通りです。

"name" ... コンテナの表示名です。VS Codeの左下に表示されます。
"build" ... どのDockerfileを使ってコンテナを作るかを指定します。"context": ".." は、1つ上の階層（my_project 直下）にある requirements.txt をDockerが参照できるようにするための設定です。
"extensions" ... コンテナ起動時に自動でインストールされるVS Code拡張機能の一覧です。
"postCreateCommand" ... コンテナが初めて作られた直後に、自動で実行されるコマンドです。ここではpipを最新版に更新しています。

設計図その2：`Dockerfile` を作成する

次に、同じく .devcontainer フォルダの中に Dockerfile という名前のファイルを作成します。
拡張子（.txt など）は不要で、「D」だけ大文字です。

このファイルは、Dockerに対して「どのOSを土台にして、何をインストールしてほしいか」を指示する設計図です。

FROM mcr.microsoft.com/devcontainers/python:3.12

# requirements.txtが存在する場合のみコピーしてインストールする最小構成
COPY requirements.txt* /tmp/

RUN if [ -f "/tmp/requirements.txt" ]; then pip install -r /tmp/requirements.txt; fi

バージョンについて： 上記では執筆時点（2026年4月）の安定版である Python 3.12 を使用しています。
本記事の例をそのまま使う場合は問題ありませんが、使用するPythonのバージョンは適宜読み替えてください。
最新の安定サポートバージョンは Python 公式サイトで確認できます。

1行目の FROM は、コンテナの土台となるイメージを指定しています。
mcr.microsoft.com/devcontainers/python:3.12 はMicrosoft公式が提供している、Dev Containers向けに最適化されたPython 3.12環境です。

2行目・3行目は、requirements.txt（後で作成します）の中身を読み取り、書かれているPythonライブラリをインストールする処理です。
if [ -f ... ] は「ファイルが存在する場合のみ実行する」という条件分岐です。requirements.txt をうっかり置き忘れた場合でも COPY に失敗してビルドが止まることを防ぐフォールバックとして機能します（空ファイルの場合は pip install -r がエラーなく完了します）。

then: もし存在（真）であれば、次の処理へ進みます。
fi: if 文の終わり（end）を意味します。

`requirements.txt` を作成する

最後に、.devcontainer の中ではなく、my_project フォルダの直下（.devcontainer と同じ階層）に requirements.txt を作成します。

ここには、コンテナ内で使いたいPythonライブラリを1行ずつ記述します。
今は試しに以下のように書いておきましょう。

requests

何も使わない場合は、ファイルを空白のままにしても構いません。

11. ステップ6：コンテナを起動する（Dev Containers活用術の仕上げ）

設計図が揃いました。いよいよコンテナを起動します。

コンテナで再度開く

VS Codeの画面左下にある「><」のアイコン（現在「WSL: Ubuntu」と表示されているはずです）をクリックします。
表示されたメニューから以下の項目を選んでください。

Reopen in Container
（日本語表示の場合：コンテナーで再度開く）

もし過去にビルドに失敗したことがある場合は、代わりに「Rebuild and Reopen in Container（コンテナーを再構築して再度開く）」を選んで、最初からクリーンにビルドし直してください。

ビルドが始まる

VS Codeのウィンドウが読み込まれ直し、右下に「Dev Containerを開始しています...」という通知が出ます。

裏側ではDockerが以下の処理を実行しています。

Python 3.12の土台イメージをダウンロードする
requirements.txt の中のライブラリをインストールする
コンテナを起動してVS Codeを接続する

初回は数分〜10分ほどかかりますが、2回目以降はキャッシュが効くため数秒で立ち上がります。

VS Codeのターミナルが開かれ、以下のようなビルドログが流れます。

起動完了の確認

VS Codeの画面左下に表示されていたアイコンの文字が、「Dev Container: My Dev Environment」に変わったら完成です。

以下の3点を確認して、環境が正しく動いているか確認しましょう。

ファイルの爆速同期を体感する
VS Code上で適当なファイルを新規作成して保存してみてください。
Cドライブに置いていた頃の「もっさり感」がなく、瞬時に保存されます。
自分だけのサンドボックスが正しく動いているか確認する
ターミナルを開いて以下のコマンドを実行します。
```
python --version
```
Windows本体にPythonを入れていなくても、Python 3.12.x と表示されれば成功です。
Git認証情報の引き継ぎを確認する（Git Credential Manager 使用時のみ）
ターミナルで git fetch などを実行したとき、パスワードを求められずに通信できれば、ホストOSの認証情報が正しくコンテナに引き継がれています。

注意： この確認は、Windows側で Git Credential Manager（GCM） が設定されている場合のみ有効です。SSH認証を使用している環境ではこの項目はスキップしてください（「13. よくある質問」の「コンテナ内でのGitプッシュ時にパスワードを求められる」を参照）。

12. 運用で困らないための補足知識

ライブラリはコンテナ内に閉じ込める

コンテナを作り直したときに手動インストールしたライブラリが消えた、という経験はないでしょうか。
これはDockerの仕様通りの動作で、コンテナは破棄すると初期状態に戻ります。

この問題を防ぐには、使いたいライブラリを requirements.txt または Dockerfile に記載しておくことです。
そうすれば、コンテナが再作成されるたびに自動でインストールされます。

また、ライブラリをWindowsのCドライブ内に置いてコンテナからマウントして使う、という方法はお勧めできません。
理由は2つあります。

特定のPCの特定のフォルダに依存する形になり、他の環境で再現できなくなること
WindowsとLinuxではOSのアーキテクチャが異なるため、Windows上でコンパイルされたライブラリのファイルをLinuxコンテナで読み込もうとするとエラーが多発すること

ライブラリは必ずコンテナ内にインストールする運用を徹底してください。

Dockerの不要データについて（定期メンテナンス）

コンテナの破棄と作成を繰り返すと、使われなくなった古いイメージ（<none> タグのもの）やビルドキャッシュが蓄積し、気づいたら数十GBのストレージを占有していることがあります。

定期的なメンテナンスとして docker system prune コマンドを使う方法がありますが、オプションによっては開発中の重要なデータ（データベースの中身など）が削除される危険があるので注意してください。

WSLの仮想ディスクが膨らんだときについて

WSL 2はWindowsの内部に「VHDX（仮想ハードディスクファイル）」を作り、その中にLinux側のデータを保存しています。
このVHDXファイルは「自動で膨らむが、自動では縮まない」という仕様があります。

つまり、Dockerの不要データを削除してもWSLの中の空洞が増えるだけで、Windows（Cドライブ）から見たVHDXファイル自体のサイズは変わりません。
Cドライブの空き容量を実際に回復させるには、VHDXを圧縮する操作が必要ですが、この操作は管理者権限が必要で、手順を誤るとWSL環境が壊れるリスクもあります。

13. よくある質問

Q. コンテナの起動やファイルの保存が極端に遅い

原因はほぼ確実に、ソースコードがWindowsのCドライブ側に置かれたままになっていることです。
WSL 2側のディレクトリ（\\wsl.localhost\Ubuntu\home\...）にコードを移動し、そこをVS Codeで開き直してください。

Q. コンテナ内でのGitプッシュ時にパスワードを求められる

この方法は、Windows側で Git Credential Manager（GCM） が設定されている場合に有効です。
GCMを使用していない環境（SSH認証のみ使用している場合など）では、以下の手順では解決しない場合があります。

GCMを使用している場合の手順：
Windowsのコマンドプロンプトやターミナルで、対象のリポジトリに対して git fetch などを一度実行してログインを完了させてから、コンテナを起動し直してください。

SSH認証を使用している場合：
WSL側の ~/.ssh/ にSSHキーを配置し、Ubuntuの ssh-agent に登録する方法が一般的です。

Q. ディスク容量が不足しているエラーが出る

古いコンテナイメージやビルドキャッシュが積み重なっている状態です。

Q. WSL 2の保存容量に上限はありますか

WSL 2は内部のVHDXファイルが自動で拡張します。

注意： 上限容量の値はWindowsのバージョン・WSLのバージョン・Dockerの管理方式によって異なる可能性があります。
本記事執筆時点の情報であるため、最新の仕様は Microsoft公式ドキュメントを参照してください。

14. まとめ

この記事では、「WSL 2を入れただけでは爆速にならない」という落とし穴を出発点として、本当の意味でDockerを高速化するための正しいファイル配置と、Dev Containersを活用した快適な開発環境の構築方法を紹介しました。

正しいファイル配置：ソースコードをWSL 2（Ubuntu）の内部に置く
Docker連携：Docker DesktopのWSL Integration設定でUbuntuと連携する
Dev Containers活用：VS Codeの「Dev Containers」拡張機能でコンテナに直接接続する

Cドライブでコードを管理していた頃と比べて、ファイルの保存・反映速度が体感で別物になります。
実際の計測でも、WSL領域はWindowsドライブの約130倍という速度差が確認できました。

加えて、コンテナという「隔離された箱」の中で開発するため、ライブラリの混入や環境汚染のリスクが大幅に下がります。

ひとつだけ守りたいルールを挙げるとすれば、「ソースコードはWSL 2側に置く」ことです（少なくとも2026年4月時点では、これがパフォーマンスへの影響が最も大きい選択です）。
これさえ守れば、この記事で作った環境は長期間快適に使い続けられます。

環境を作る段階でつまずくことが多かった経験から、できるだけ省略せずに書きました。
参考になれば幸いです。