Windows 11で既存Laravel環境を構築する方法

2026/8/6

はじめに

今回は、MacのDocker環境で動作していたLaravelプロジェクトをGitHubからWindows 11へクローンし、Docker DesktopとLaravel Sailを使って起動するまでの手順を紹介します。

GitHubからLaravelプロジェクトをクローンした直後に、次のコマンドを実行したところ、Composerが見つからないエラーが発生しました。

composer install

表示されたエラーは次のとおりです。

Command 'composer' not found

DockerでLaravel環境を構築する場合、WindowsやWSLへComposerを直接インストールしなくても、Composerが入った一時的なDockerコンテナを使って依存パッケージをインストールできます。

この記事では、次の流れを初心者向けに解説します。

  • WSL2の確認
  • Docker Desktopのインストール
  • Docker DesktopのWSL2設定
  • GitHubからLaravelプロジェクトをクローン
  • Dockerを使ったcomposer install
  • .envの作成
  • Laravel Sailの起動
  • マイグレーションとSeederの実行
  • Windows側のフォルダで発生した権限エラーへの対処

今回の環境

今回使用した環境は次のとおりです。

OS：Windows 11 Home 
Linux環境：WSL2 Ubuntu 
コンテナ環境：Docker Desktop 
PHP：8.3 
フレームワーク：Laravel 
開発環境：Laravel Sail 
ソースコード管理：GitHub

対象のLaravelプロジェクトは、MacのDocker環境ですでに動作確認済みです。

GitHubへ登録していたLaravelプロジェクトをWindows側へクローンし、Windowsでも同じ環境を立ち上げます。

Windows11でWSL２を確認する

Laravel SailをWindowsで利用する場合は、WSL2を使用します。

PowerShellを開いて、次のコマンドを実行します。

wsl --status

インストールされているLinuxディストリビューションとWSLのバージョンは、次のコマンドで確認できます。

wsl -l -v

正常な例は次のとおりです。

NAME   STATE   VERSION 
Ubuntu Running 2

VERSIONが2であれば、WSL2として動作しています。

WSLがインストールされていない場合は、管理者権限でPowerShellを開いて次を実行します。

wsl --install

WSLを更新する場合は、次を実行します。

wsl --update

Docker Desktopの公式ドキュメントでは、WindowsでWSL2バックエンドを利用する場合、WSLのバージョンを確認し、必要に応じてwsl --installまたはwsl --updateを実行する方法が案内されています。

Docker Desktopをインストールする

Docker Desktopの公式サイトから、Windows版Docker Desktopをダウンロードしてインストールします。

インストール中に、コンテナの実行方法を選択する画面が表示されることがあります。

Choose how to run Docker containers

LaravelではLinuxコンテナを使用するため、WSL2を利用する設定を選択します。

Docker Desktopの新しいバージョンでは、以前表示されていた次の設定項目が見当たらない場合があります。

Use the WSL 2 based engine

WSL2に対応した環境では、この設定が初期状態で有効になっており、設定項目自体が表示されないことがあります。Docker公式ドキュメントにも、WSL2を利用できる環境では、WSL2エンジンがデフォルトで有効になり、設定が表示されない場合があると記載されています。

Docker Desktopを起動したら、必要に応じて次の設定を確認します。

Settings → Resources → WSL Integration

Ubuntuが表示されている場合は、Ubuntuとの連携を有効にします。

WSLからDockerが利用できるか確認する

WSLのUbuntuターミナルを開いて、次のコマンドを実行します。

docker --version

続いて、テスト用コンテナを実行します。

docker run hello-world

次のメッセージが表示されれば、WSLからDocker Desktopを利用できています。

Hello from Docker!

LaravelプロジェクトをGitHubからクローンする

今回は、Mac環境ですでに動作確認済みのLaravelプロジェクトをGitHubから取得します。

WSLのUbuntuターミナルで、作業用フォルダを作成します。

mkdir -p ~/workspace
cd ~/workspace

GitHubからLaravelプロジェクトをクローンします。

git clone git@github.com:ユーザー名/リポジトリ名.git

今回の例では、次のようなプロジェクト名です。

cd VehicleSearchSystem

ファイルを確認します。

ls

Laravelプロジェクトであれば、次のようなファイルが表示されます。

app
artisan
bootstrap
composer.json
composer.lock
compose.yaml
config
database
package.json
public
resources
routes
storage
tests
vite.config.js

composer installでエラーが発生

クローンしたプロジェクトで、次のコマンドを実行しました。

composer install

しかし、次のエラーが表示されました。

Command 'composer' not found, did you mean:
  command 'compose' from deb mailcap

これは、WSLのUbuntuにComposerがインストールされていないためです。

ただし、LaravelをDockerで動かす場合、WSLへComposerを直接インストールする必要はありません。

Composerが入ったDockerイメージを一時的に起動し、そのコンテナ内でcomposer installを実行できます。

プロジェクトが要求するPHPバージョンを確認する

使用するComposer用Dockerイメージを決めるため、composer.jsonに記載されたPHPバージョンを確認します。

次のコマンドを実行します。

grep -n '"php"' composer.json

今回のプロジェクトでは、次の結果になりました。

9: "php": "^8.3",

したがって、PHP 8.3に対応したComposer用Dockerイメージを使用します。

Docker経由でcomposer installを実行する

プロジェクトのルートディレクトリで、次のコマンドを実行します。

docker run --rm \
  -u "$(id -u):$(id -g)" \
  -v "$(pwd):/var/www/html" \
  -w /var/www/html \
  laravelsail/php83-composer:latest \
  composer install --ignore-platform-reqs

このコマンドでは、Composerが入った一時的なDockerコンテナを起動しています。

各オプションの意味は次のとおりです。

--rm 
処理終了後に一時コンテナを削除する 

-u "$(id -u):$(id -g)" 
現在のWSLユーザーと同じユーザーID・グループIDで実行する 

-v "$(pwd):/var/www/html" 
現在のLaravelプロジェクトをコンテナへマウントする 

-w /var/www/html 
コンテナ内の作業ディレクトリを指定する 

laravelsail/php83-composer:latest 
PHP 8.3とComposerが入ったDockerイメージを使用する 

composer install 
composer.lockに基づいて依存パッケージをインストールする

composer.lockが存在するプロジェクトでcomposer installを実行すると、Composerはcomposer.lockに記録されたバージョンを使用して依存パッケージを復元します。そのため、Mac環境とWindows環境で依存パッケージのバージョンをそろえやすくなります。

Laravel Sailがインストールされたか確認する

Composerの処理が完了したら、次のコマンドを実行します。

ls vendor/bin/sail

次のファイルが表示されれば、Laravel Sailを実行する準備ができています。

vendor/bin/sail

また、Composerのオートローダーも確認できます。

test -f vendor/autoload.php && echo "Composer install completed"

正常であれば、次のように表示されます。

Composer install completed

.envファイルを作成する

GitHubには通常、パスワードやAPIキーを含む.envファイルを登録しません。

.envが存在するか確認します。

ls -la | grep .env

.envがない場合は、.env.exampleをコピーします。

cp .env.example .env

データベース設定を確認する

Laravel SailでMySQLを使用する場合は、.envのデータベース設定を確認します。

例として、次のように設定します。

DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=laravel_db_test
DB_USERNAME=root_user_name
DB_PASSWORD=root_password

重要なのは、DB_HOSTです。

DB_HOST=mysql

LaravelコンテナからMySQLコンテナへ接続するため、通常はlocalhostではなく、compose.yamlに定義されたMySQLのサービス名を指定します。

例えば、compose.yamlが次のようになっている場合、

services: 
    mysql: 
      image: mysql:8.0

.envでは次のように設定します。

DB_HOST=mysql

Laravel Sailを起動する

Docker Desktopが起動していることを確認して、次のコマンドを実行します。

./vendor/bin/sail up -d

-dを付けると、コンテナをバックグラウンドで起動できます。

コンテナの状態を確認します。

./vendor/bin/sail ps

または、次のコマンドでも確認できます。

docker compose ps

LaravelやMySQLなどのコンテナがrunningまたはUpになっていれば起動しています。

Laravelのアプリケーションキーを生成する

新しく.envを作成した場合は、Laravelのアプリケーションキーを生成します。

./vendor/bin/sail artisan key:generate

.envを確認すると、APP_KEYに値が設定されます。

grep APP_KEY .env

正常な例は次のとおりです。

APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxx

マイグレーションを実行する

データベースへテーブルを作成します。

./vendor/bin/sail artisan migrate

Seederも同時に実行する場合は、次のコマンドを使用します。

./vendor/bin/sail artisan migrate --seed

すでにマイグレーション済みで、Seederだけを実行する場合は次のとおりです。

./vendor/bin/sail artisan db:seed

管理ユーザー用の環境変数を設定する

今回のプロジェクトでは、DatabaseSeeder内で管理ユーザーを作成していました。

処理の一部は次のようになっています。

class DatabaseSeeder extends Seeder
{
    use WithoutModelEvents;

    public function run(): void
    {
        $this->call(ManufacturerSeeder::class);

        $adminEmail = (string) config('admin.email');
        $adminPassword = (string) config('admin.password');

        if ($adminEmail === '' || $adminPassword === '') {
            return;
        }

        // 管理ユーザー作成処理
    }
}

このSeederでは、次の設定値を取得しています。

config('admin.email');
config('admin.password');

メールアドレスまたはパスワードが空の場合、次の処理によって管理ユーザー作成処理が終了します。

if ($adminEmail === '' || $adminPassword === '') { 
return; 
}

そのため、.envに管理ユーザー情報を設定する必要があります。

ADMIN_EMAIL=admin@example.com
ADMIN_PASSWORD=任意のパスワード

さらに、config/admin.phpを次のように設定します。

<?php 
   return [ 'email' => env('ADMIN_EMAIL', ''),
   'password' => env('ADMIN_PASSWORD', ''), 
];

.envを変更した後はキャッシュを削除する

.envを変更しただけでは、Laravelが以前の設定キャッシュを使用していることがあります。

次のコマンドでキャッシュをまとめて削除します。

./vendor/bin/sail artisan optimize:clear

または、設定キャッシュだけを削除します。

./vendor/bin/sail artisan config:clear

その後、Seederを再実行します。

./vendor/bin/sail artisan db:seed

configの値をTinkerで確認する

管理ユーザーが作成されない場合は、Laravelが.envの設定を読み込めているか確認します。

Tinkerを起動します。

./vendor/bin/sail artisan tinker

次のコマンドを実行します。

config('admin.email');

続けて、パスワードを確認します。

config('admin.password');

メールアドレスが正しく表示されれば、設定を取得できています。

"admin@example.com"

nullや空文字が表示される場合は、次の点を確認します。

  • .envにADMIN_EMAILがあるか
  • .envにADMIN_PASSWORDがあるか
  • config/admin.phpが存在するか
  • .envとconfig/admin.phpの変数名が一致しているか
  • optimize:clearを実行したか
  • 別のプロジェクトの.envを編集していないか

確認が終わったら、Tinkerを終了します。

exit

フロントエンドのパッケージをインストールする

React、Inertia.js、Viteなどを使用している場合は、Node.jsの依存パッケージもインストールします。

./vendor/bin/sail npm install

開発用のViteサーバーを起動します。

./vendor/bin/sail npm run dev

このコマンドは、開発中は実行したままにします。

静的ファイルをビルドする場合は、次を実行します。

./vendor/bin/sail npm run build

ブラウザからLaravelへアクセスする

通常は、ブラウザから次のURLへアクセスします。

http://localhost

.envでポートを変更している場合は、指定したポートを使用します。

例えば、次の設定の場合、

APP_PORT=8080

アクセス先は次のとおりです。

http://localhost:8080

Laravelの画面が表示されれば、Windows 11上のDocker環境構築は完了です。

Operation not permittedが大量に表示された場合

最初は、LaravelプロジェクトをWindows側の次のようなフォルダへクローンしていました。

/mnt/c/Users/alpth/workspace/Vehicle/VehicleSearchSystem

この状態でDocker経由のcomposer installを実行したところ、次のような警告が大量に表示されました。

fchmod (file attributes) error: Operation not permitted
warning: cannot set modif./access times

実際のログでは、Laravelの依存ファイルを展開するときに、ファイル属性や更新日時を設定できない警告が繰り返し発生していました。

これは、Windows側のファイルシステムへマウントしたフォルダに対して、LinuxコンテナがLinux形式のファイル権限を設定しようとしたことが原因です。

WSL側へプロジェクトを置き直す

対策として、プロジェクトをWindows側の/mnt/c配下ではなく、WSLのLinuxファイルシステム内へ置き直しました。

mkdir -p ~/workspace 
cd ~/workspace

GitHubから改めてクローンします。

git clone git@github.com:ユーザー名/VehicleSearchSystem.git
cd VehicleSearchSystem

その後、もう一度Composerを実行します。

docker run --rm \
  -u "$(id -u):$(id -g)" \
  -v "$(pwd):/var/www/html" \
  -w /var/www/html \
  laravelsail/php83-composer:latest \
  composer install --ignore-platform-reqs

Docker公式も、WSL2で開発するときはLinux側のファイルシステムを利用する方法を案内しており、ファイルシステムのパフォーマンスに関するベストプラクティスを公開しています。

WSL側へプロジェクトを置くことで、次の問題を避けやすくなります。

  • Composerの権限エラー
  • npmインストール時の権限問題
  • Viteの変更検知が遅い
  • Dockerのファイルアクセスが遅い
  • storageやbootstrap/cacheの書き込みエラー

WSL内のファイルをWindows側で編集する

WSL内に置いたプロジェクトも、Windows側のエディターから開けます。

Windowsのエクスプローラーでは、次のようなパスからアクセスできます。

\\wsl$\Ubuntu\home\alpth\workspace\VehicleSearchSystem

Visual Studio Codeを使用している場合は、プロジェクトフォルダで次を実行できます。

code .

PhpStormの場合も、\\wsl$\Ubuntu\...のパスを指定してプロジェクトを開けます。

ただし、エディターによってはWSL連携機能を利用したほうが、ファイル監視やターミナル連携が安定します。

よく使うLaravel Sailコマンド

Docker環境の起動は次のコマンドです。

./vendor/bin/sail up -d

コンテナを停止する場合は次のとおりです。

./vendor/bin/sail down

コンテナの状態を確認します。

./vendor/bin/sail ps

Artisanコマンドを実行します。

./vendor/bin/sail artisan コマンド名

Composerを実行します。

./vendor/bin/sail composer install

Composerパッケージを追加します。

./vendor/bin/sail composer require パッケージ名

npmパッケージをインストールします。

./vendor/bin/sail npm install

Viteを起動します。

./vendor/bin/sail npm run dev

マイグレーションを実行します。

./vendor/bin/sail artisan migrate

Seederを実行します。

./vendor/bin/sail artisan db:seed

キャッシュをまとめて削除します。

./vendor/bin/sail artisan optimize:clear

今回の構築手順まとめ

今回実行した主なコマンドをまとめると、次のようになります。

mkdir -p ~/workspace
cd ~/workspace
git clone git@github.com:ユーザー名/VehicleSearchSystem.git
cd VehicleSearchSystem
grep -n '"php"' composer.json
docker run --rm \
 -u "$(id -u):$(id -g)" \ 
-v "$(pwd):/var/www/html" \ 
-w /var/www/html \ 
laravelsail/php83-composer:latest \ 
composer install --ignore-platform-reqs
cp .env.example .env

.envを編集した後、Laravel Sailを起動します。

./vendor/bin/sail up -d
./vendor/bin/sail artisan optimize:clear
./vendor/bin/sail artisan migrate --seed
./vendor/bin/sail npm install
./vendor/bin/sail npm run dev

最後にブラウザで次へアクセスします。

http://localhost

まとめ

Windows 11で既存のLaravelプロジェクトをDocker Desktop上に構築する場合、WSLへComposerを直接インストールしなくても作業できます。

GitHubからクローンした直後はvendorフォルダが存在しないため、Laravel Sailをまだ実行できません。

そのため、最初の1回だけComposer入りのDockerイメージを使用して、次の処理を実行します。

docker run --rm \
  -u "$(id -u):$(id -g)" \
  -v "$(pwd):/var/www/html" \
  -w /var/www/html \
  laravelsail/php83-composer:latest \
  composer install --ignore-platform-reqs

vendor/bin/sailが作成された後は、Composer、Artisan、npmなどのコマンドをLaravel Sail経由で実行できます。

また、LaravelプロジェクトをWindows側の/mnt/c配下に置くと、Composerによる権限設定でOperation not permittedが発生することがあります。

Docker DesktopとWSL2を使ってLaravelを開発する場合は、プロジェクトを次のようなWSL側のファイルシステムへ置くと、権限やファイルアクセスの問題を避けやすくなります。

/home/ユーザー名/workspace/プロジェクト名

さらに、Seederで.envの値を使用している場合は、環境変数を設定した後に次のコマンドを実行することも重要です。

./vendor/bin/sail artisan optimize:clear

今回の構築では、Docker Desktop、WSL2、Laravel Sailの役割を理解することで、WindowsへPHPやComposerを個別にインストールせずにLaravel環境を構築できました。