🐳 Docker・開発環境

WSL2の使い方|Web制作環境の始め方とトラブル対策

WindowsでWeb制作をしていると、「Linux用のコマンドを使いたい」「Dockerを動かしたい」「本番サーバーに近い環境で確認したい」と感じることがあります。WSL2を使えば、Windowsを使いながらUbuntuなどのLinux環境を利用できます。この記事では、WSL2の導入からファイル配置、localhost、Docker、よくあるトラブルまで初心者向けに解説します。

WSL2とは何か

WSLは「Windows Subsystem for Linux」の略で、Windows上でLinuxディストリビューション、Linuxのファイルシステム、Bashなどのコマンドを利用するための仕組みです。従来の仮想マシンやデュアルブートを自分で細かく構築しなくても、WindowsとLinuxを行き来しながら開発できます。

WSL2はLinuxカーネルを使い、WSL1より完全なシステムコール互換性とファイルシステム性能を備えています。WordPress、PHP、Node.js、Git、Dockerなどを使うWeb制作では、通常はWSL2が扱いやすい選択です。

WSL2がWeb制作に向いている理由

  • 本番でよく使われるLinuxコマンドをローカルでも利用できる
  • WindowsのブラウザからLinux側の開発サーバーを確認できる
  • Git、Node.js、PHP、Dockerなどの開発ツールをまとめやすい
  • VS CodeなどのWindowsアプリとLinux環境を連携できる
  • プロジェクトごとの環境をDocker Composeで再現しやすい

WSL2はWindowsと別のLinux環境です。Windows側とLinux側には、それぞれユーザー、ホームディレクトリ、ファイル権限、インストール済みソフトがあります。この違いを理解すると、パスや権限のトラブルを減らせます。

WSL2とUbuntuをインストールする手順

Microsoft公式では、対応するWindows 10またはWindows 11で、管理者として開いたPowerShellから次のコマンドを実行する方法を案内しています。

wsl --install

標準ではUbuntuがインストールされます。処理が終わったらWindowsを再起動し、Ubuntuを起動してLinux用のユーザー名とパスワードを設定します。ここで作るパスワードはWindowsのPINとは別で、sudoを使うときに必要です。入力中は画面に文字や記号が表示されませんが、そのまま入力してEnterを押します。

インストール状態を確認する

PowerShellまたはコマンドプロンプトで次を実行します。

wsl --status
wsl --version
wsl --list --verbose

利用するUbuntuのVERSIONが「2」になっていることを確認します。WSLを更新する場合は次のコマンドを使います。

wsl --update

WSLがすでに入っていて別のLinuxを追加したい場合は、利用可能な一覧を確認してディストリビューションを指定します。

wsl --list --online
wsl --install -d Ubuntu

Web制作ファイルはどこへ置くべきか

WSLからはWindowsのCドライブを/mnt/cとして開けます。しかし、Linux用ツールやDockerコンテナから頻繁に読み書きするプロジェクトは、Ubuntu側のホームディレクトリへ置くのがおすすめです。

cd ~
mkdir -p projects
cd projects

たとえば/home/user/projects/sample-siteのように配置します。Docker公式も、LinuxコンテナへバインドマウントするソースコードはLinuxファイルシステムへ保存することで、ファイル性能と変更検知を改善できると案内しています。

Windowsのエクスプローラーから開く

Ubuntuのターミナルで次を実行すると、現在のLinuxフォルダーをWindowsのエクスプローラーで開けます。

explorer.exe .

エクスプローラーのアドレス欄では、通常\wsl$Ubuntuhomeユーザー名からもアクセスできます。Linuxの設定ファイルやプロジェクトをWindowsアプリで扱えますが、Linux側のシステムファイルをWindowsから不用意に編集しないようにします。

Dockerとlocalhostを使う方法

Docker Desktopを使用する場合は、設定でWSL 2ベースのエンジンと対象Ubuntuの連携を有効にします。Docker本体とComposeが使えるか、Ubuntu側で次を確認します。

docker version
docker compose version

プロジェクトにcompose.ymlまたはdocker-compose.ymlがある場合は、そのディレクトリで起動します。

docker compose up -d
docker compose ps

たとえばコンテナの80番ポートをWindowsの8083番へ公開している場合、Windowsのブラウザからhttp://localhost:8083を開けます。Microsoft公式でも、WSL内で動くWebサーバーへWindows側から通常はlocalhostで接続できると説明されています。

localhostで開けないとき

  1. docker compose psでコンテナが起動しているか確認する
  2. ポートが0.0.0.0:8083->80のように公開されているか確認する
  3. 別のアプリが同じポートを使っていないか確認する
  4. URLのHTTP・HTTPSとポート番号を確認する
  5. WindowsファイアウォールやVPNの影響を確認する

WSL2の標準NAT構成では、WindowsからWSL側のサービスへlocalhostで接続できます。反対に、WSLからWindows上のサービスへ接続する場合は、構成によってWindowsホストのIPアドレスが必要です。Windows 11のミラーネットワークを有効にした環境では、双方向にlocalhostを使える場合があります。

よくあるトラブルと直し方

WSLやUbuntuが反応しない

PowerShellで状態を確認し、WSL全体を一度終了して再起動します。

wsl --status
wsl --shutdown

wsl --shutdownは実行中のすべてのディストリビューションとWSL2仮想マシンを終了します。未保存の作業や実行中コンテナがないことを確認してから使います。その後、Ubuntuを起動し直します。

Permission deniedが表示される

現在のユーザーと対象ファイルの所有者・権限を確認します。

whoami
pwd
ls -la

原因を確認せずchmod -R 777を実行すると、秘密鍵や設定ファイルまで誰でも書き換えられる状態になります。プロジェクトの所有者がrootになっている場合は、なぜrootで作成されたかを確認し、必要な範囲だけ所有者を戻します。

Dockerへ接続できない

Docker Desktopが起動しているか、WSL Integrationで対象Ubuntuが有効かを確認します。次にdocker context lsdocker versionを実行し、クライアントだけでなくServer情報も返るか確認します。「permission denied while trying to connect to the Docker daemon socket」は、Dockerの起動状態、連携設定、ソケット権限を分けて調べます。

ディスク容量が増え続ける

Dockerイメージ、停止コンテナ、ビルドキャッシュ、データベースボリュームは容量を使用します。まず内訳を確認します。

df -h
docker system df

削除コマンドはデータを失う可能性があるため、表示内容とバックアップを確認してから実行します。特にdocker compose down -v-vは、WordPressのデータベースなどを保存したボリュームも削除するため、初期化するとき以外は付けません。

WSL2でよくあるトラブル事例

ここからは、このサイト固有の作業結果ではなく、WSL2でWeb制作を始めたときによく起きる一般的な事例です。実際の原因は環境によって異なるため、症状だけで決めつけず、確認結果を一つずつ記録してください。

実例1:Ubuntuを閉じたらサイトも止まったように見える

ターミナルを閉じた後にlocalhostが開けなくなり、「WordPressが消えた」と思うことがあります。実際には、WSLやDocker Desktopが停止した、またはコンテナが終了しただけで、ボリューム内のデータは残っている場合があります。最初にUbuntuを起動し、docker compose psで状態を確認します。停止していればプロジェクトのディレクトリでdocker compose up -dを実行します。

実例2:localhostへ接続できない

コンテナは起動しているのにブラウザでサイトが開けない場合、ポート番号の間違いがよくあります。たとえばComposeで8083:80と設定したサイトは、ブラウザでhttp://localhost:8083を開きます。別サイトも8083を使うと競合するため、片方を8084などへ変更し、コンテナを作り直してから確認します。

実例3:ファイルを編集しても反映が遅い

プロジェクトを/mnt/c以下へ置き、Linuxコンテナへバインドマウントすると、環境によって読み書きや変更検知が遅くなることがあります。ソースコードをUbuntu側の/home/ユーザー名/projectsなどへ移し、VS CodeのWSL連携から開くと改善する場合があります。移動前にはGitやバックアップで変更を保存します。

実例4:ファイルを保存できずPermission deniedになる

sudoでファイル生成やパッケージ操作を繰り返すと、プロジェクト内の一部がroot所有になり、通常ユーザーで編集できなくなることがあります。ls -laで所有者を確認し、必要なファイルだけを正しいユーザーへ戻します。エラーを消す目的でプロジェクト全体を777にするのは避けます。

実例5:dockerコマンドはあるのに接続できない

docker --versionは表示されても、docker versionでServer情報が返らない場合があります。これはDockerクライアントは存在するものの、Docker Desktopが停止している、対象UbuntuとのWSL連携が無効、またはソケットへ接続できない状態が考えられます。Docker Desktopの起動、WSL Integration、docker context lsの順に確認します。

まとめ

WSL2を使うと、Windowsの使いやすさを残しながらLinuxのWeb制作環境を利用できます。プロジェクトはLinux側へ置き、状態確認、ファイル権限、ポート、Docker接続を順番に切り分けることが大切です。困ったときはデータを削除する前に、wsl --statusdocker compose psで現在の状態を記録しましょう。

参考にした公式情報

※本記事は2026年7月25日時点の公式情報と、当サイトのWSL2環境での確認結果をもとに作成しています。

実例

実際の作業で確認したこと

今回の検証環境

  • Windows上のUbuntuを使うWSL2
  • Linuxカーネル:microsoft-standard-WSL2
  • Docker ComposeでWordPressとMariaDBを起動
  • 公開ポート:8083

実際に行った作業

WordPressのプロジェクトを/mnt/cではなくUbuntu側の/home以下へ配置し、Docker ComposeでWordPressとMariaDBを起動しました。Windowsのブラウザからhttp://localhost:8083へアクセスし、トップページと記事ページがHTTP 200で表示されることを確認しました。

実際に起きたこと

Dockerコンテナが「Up」と表示されていても、MariaDBの準備が完了する前にWP-CLIを実行すると「Error establishing a database connection」になりました。数秒後にMariaDBが接続を受け付ける状態になってから同じ処理を実行すると成功しました。

作業から分かったこと

WSL、Docker、WordPressをまとめて疑うのではなく、「WSLが動くか」「Docker Serverへ接続できるか」「コンテナが起動しているか」「データベースが接続を受け付けるか」「Webページが応答するか」の順に確認すると、原因を切り分けやすくなります。 Docker側の詳しい確認方法は「Docker ComposeでWordPressが起動しないときの対処法」も参考にしてください。

掲載内容は最終確認日時点の情報です。バージョンや環境によって表示・手順が異なる場合があります。重要な変更の前にはバックアップを取得してください。