Laravel・PHP開発をわかりやすく解説

しかも、アプリケーションは古い組み合わせのままでも、しばらくは普通に動いてしまう。画面が表示され、ログインもでき、定期処理も実行される。そのため、サポート終了や依存関係のズレは、障害ではなく「見えない管理課題」として残りやすい。

個人開発では、専任の運用担当者を置けない。だからこそ、Laravelのメジャーリリース、PHP要件、サポート期間、CLIコマンド、Composerのロックファイルを一つの流れで理解しておく必要がある。

LaravelのメジャーリリースとPHP要件の変遷

Laravelのメジャーバージョンが変わると、必要なPHPの最低バージョンも変わる。アプリケーション側のコードだけを確認しても、実行環境のPHPが要件を満たしていなければ、Composerの依存関係を解決できない。

ただし、ここで注意したいのは「最低PHP要件」と「対応するPHPのすべての範囲」を混同しないことだ。たとえばLaravel 11の最低要件がPHP 8.2だからといって、PHP 8.2だけに対応しているわけではない。Composerの制約が^8.2であれば、意味するのはPHP 8.2以上、かつPHP 9.0未満という範囲である。

2026年3月時点で、各Laravelの公式パッケージが宣言しているPHP制約は、次のように整理できる。

この表は、各Laravel本体がComposerで宣言している実行要件を示したものだ。Laravel 10がPHP 8.1だけ、Laravel 11がPHP 8.2だけという意味ではない。したがって、Laravel 10に対してPHP 8.2や8.3を一律に非対応としたり、Laravel 11に対してPHP 8.3や8.4を一律に非対応としたりするのは適切ではない。

一方で、Composerの制約を満たしていれば、どのアプリケーションでも問題なく動くと断定できるわけではない。Laravel本体の条件とは別に、次のような要素が実際の対応可否を左右する。

• 利用している認証、管理画面、画像処理、決済などのパッケージ
• PHP拡張機能の有無とバージョン
• PHPの非推奨機能を使っている古いコード
• Dockerイメージや本番サーバーのビルド条件
• データベースドライバーや外部サービスの接続ライブラリ
• テスト環境と本番環境の構成差分

つまり、Laravelの表にあるPHPバージョンは「Laravel本体の要件」であり、プロジェクト全体の動作保証を示すものではない。特定のPHP 8.xで本当に動くかを判断するには、composer.json、依存パッケージ、実行環境、テスト結果を組み合わせて見る必要がある。

LaravelのPHP要件と公式サポート期間は別に見る

PHPの実行要件と、Laravelの公式サポート期間は別の情報である。あるLaravelがPHP 8.3で起動できるとしても、そのLaravel自体のセキュリティ修正が終了していれば、長期運用の前提としては弱い。

逆に、サポート期間内のLaravelであっても、利用中のパッケージがPHP 8.3に対応していなければ、アプリケーションはその環境へ移行できない。

この二つを一つの表に「対応・非対応」として詰め込むと、最低要件だけが対応範囲のように見えたり、フレームワークのサポート終了とPHPの実行可否が混同されたりする。確認するときは、まずLaravel本体のPHP制約を見て、その後に公式サポート日程を別の表で確認するほうが安全だ。

composer.jsonのPHP制約を読む

最初に確認する場所は、プロジェクトのcomposer.jsonにあるrequireセクションだ。ここには、プロジェクトが動作に必要とするPHPやパッケージの条件が記述されている。

たとえば、次のような指定があるとする。

"php": "^8.2"

"laravel/framework": "^12.0"

この場合、^8.2はPHP 8.2以上、かつ次のメジャーバージョンである9.0未満を意味する。^12.0はLaravel 12.0以上、かつLaravel 13.0未満という範囲になる。

この記法は、現在インストールされているバージョンを直接指定しているわけではない。あくまで「この範囲なら受け入れられる」という宣言だ。実際にどのバージョンが入っているかは、composer.lockとインストール済みパッケージを確認しなければ分からない。

ここを混同すると、composer.jsonを書き換えただけでアップグレードが終わったように見えてしまう。しかし、制約を書き換えただけでは、アプリケーションのコードも、ロックファイルも、実行環境も変わっていない。

確認する順番は次のようにすると分かりやすい。

1. composer.jsonで、プロジェクトが許容しているPHPとLaravelの範囲を見る。

2. php -vで、現在のコマンドライン環境のPHPを確認する。

3. composer show laravel/frameworkで、実際にインストールされたLaravelのバージョンを見る。

4. composer.lockが更新されているかを確認する。

5. テストと主要画面で、実際のアプリケーションの互換性を確認する。

この五つを分けて見ることが重要だ。宣言、実行環境、インストール済みの依存関係、固定された解決結果、アプリケーションの動作は、それぞれ別の情報だからである。

サポート期間のルールとEOL管理の重要性

Laravelの公式サポートは、メジャーリリースごとに期間が決まっている。バグ修正は18か月、セキュリティ修正は24か月というルールだ。

バグ修正の期間が終わると、通常の不具合修正や改善を期待できる期間ではなくなる。その後もしばらくセキュリティ修正が提供されるが、そこも終了すれば、公式からの安全性に関する修正は受けられない。

Laravelのバージョン管理は、数字を追いかける作業ではない。バグ修正とセキュリティ修正の期限を、開発計画に組み込む作業である。

2026年3月時点のサポートスケジュールは、次のように整理できる。

Laravel 11は、2026年3月時点でセキュリティサポートの終了を迎えている。Laravel 10はすでに完全なEOLに達している。現在も動作していることと、公式サポートの対象であることは別の話だ。

ここで注意したいのは、EOLになった瞬間にアプリケーションが停止するわけではないという点である。サポート終了は、フレームワークが技術的に起動しなくなる日付ではない。そのため、個人開発では「動いているから後回しでよい」と判断しやすい。

しかし、EOL後に問題になるのは、普段の画面表示ではない。新たに公開された脆弱性への対応、PHPや外部サービスの更新、周辺パッケージとの互換性、障害発生時の切り分けが難しくなることだ。

EOLを予定表に置く

サポート終了日は、リリース情報として読むだけでは足りない。自分の予定表に置き換える必要がある。

たとえばLaravel 12を使っている場合、セキュリティ修正終了日は2027年2月24日だ。この日付を覚えているだけではなく、次のような作業日程へ分解する。

• 移行対象のパッケージを洗い出す
• PHPの更新が必要か確認する
• Dockerイメージや本番環境の更新方法を決める
• テスト不足の機能を把握する
• ステージング環境で移行する
• 本番反映後の戻し方を準備する

アップグレード作業の負担は、プロジェクトによって大きく違う。Laravelの標準機能だけで構成された小さなアプリケーションなら、比較的短時間で確認できる。一方で、認証、決済、画像処理、外部API、管理画面、独自のキュー処理などが絡むと、フレームワークの更新以外にも検証が必要になる。

だから、EOL直前に作業を始めるのは危険だ。実際に修正が必要な箇所を見つけたとき、すぐに対応できるとは限らない。個人開発では、本業や別の案件によって作業が止まることもある。サポート終了日までの残り期間は、そのまま開発に使える時間ではない。

また、Laravel本体のサポートが切れていなくても、PHPや主要パッケージのサポート状況が先に問題になることがある。EOL管理では、Laravelの終了日だけを予定表に置くのではなく、PHP、データベース、Dockerのベースイメージ、外部サービスの変更時期も並べておきたい。

CLIコマンドで把握する現在の開発環境

バージョンを確認するときは、ドキュメントや記憶よりも、実際にアプリケーションを動かしている環境を読むべきだ。

ローカルではPHP 8.3を使っているのに、Dockerの中ではPHP 8.2を使っている。あるいは、ターミナルでは新しいComposerを使っているのに、デプロイ先には別のComposerが入っている。このようなズレは、個人開発でも珍しくない。

最低限、次のコマンドを使い分ける。

• php -v

現在のシェルで呼び出されるPHPのバージョンを確認する。

• php artisan --version

アプリケーションから読み込まれているLaravelのバージョンを確認する。

• composer show laravel/framework

Composerが管理するLaravelパッケージのインストール済みバージョンを確認する。

• composer show

プロジェクトにインストールされているパッケージ全体を一覧表示する。

• composer outdated

更新可能なパッケージを確認する。ただし、表示された最新版へ無条件に更新してよいという意味ではない。

• composer check-platform-reqs

現在のPHPや拡張機能が、インストール済みパッケージの実行要件を満たしているか確認する。

composer outdatedは便利だが、これだけでサポート状況を完全に判定できるわけではない。最新版が表示されても、それが現在のメジャーバージョンと互換性があるとは限らない。更新可能な範囲、メジャー番号の変化、PHP要件、変更履歴を合わせて見る必要がある。

LaravelのバージョンとPHPのバージョンを別々に確認する

php -vとphp artisan --versionは、似たようなバージョン確認に見えるが、見ている対象は違う。

php -vはPHPランタイムの情報だ。php artisan --versionは、そのPHPプロセスでLaravelアプリケーションを起動した結果として、読み込まれたLaravelの情報を表示する。

通常、同じディレクトリで同じPHPコマンドを使っていれば、両者に矛盾は生じない。ただし、次のような環境では差が出る。

• ローカルのPHPとDocker内のPHPを混同している
• 複数のPHP実行ファイルがインストールされている
• シェルの設定によって、想定と異なるPHPが呼び出されている
• 本番と開発で、異なるコンテナイメージを利用している
• Composerだけを別のコンテナや別のホストで実行している

Dockerを使う場合、ホスト側でphp -vを実行した結果より、アプリケーションコンテナ内で実行した結果を優先する。たとえば、docker compose exec app php -vで確認し、同じコンテナ内でdocker compose exec app php artisan --versionを実行する。

DockerfileのFROMに書かれたPHPのタグは、ビルド時の宣言である。実際に稼働しているコンテナがそのイメージから作られているか、コンテナを再作成したかまでは、タグを見ただけでは分からない。設定ファイルを変更した後に古いコンテナが残っていれば、ファイル上はPHP 8.3でも、実際のプロセスは以前のPHPを使っている可能性がある。

PHPのバージョンを変更したときは、コンテナを再作成したかだけでなく、PHP拡張機能も確認する。LaravelやComposerの依存パッケージが必要とする拡張機能が入っていなければ、PHP本体のバージョンが条件を満たしていてもアプリケーションは動かない。

WordPressと同じサーバーで運用する場合

LaravelのアプリケーションとWordPressを同じサーバーや同じDocker環境で運用している場合は、PHPの更新範囲に注意が必要だ。

Laravel側が新しいPHPを必要としていても、WordPress本体、テーマ、プラグインの一部が同じ環境で動いているとは限らない。PHPを更新したことでLaravelは起動したが、WordPressのプラグインが警告を出す、管理画面の一部が動かない、といった問題が起こることもある。

この構成では、アプリケーションごとに次の点を切り分ける。

• LaravelとWordPressが同じPHPコンテナを共有しているか
• ウェブサーバーとCLIで異なるPHPを使っていないか
• WordPressのプラグインが特定のPHPバージョンに依存していないか
• PHP拡張機能を片方のアプリケーションだけが必要としていないか
• 更新時に、どのサービスを停止する必要があるか

可能なら、LaravelとWordPressで実行環境を分離したほうが、更新の影響範囲を限定しやすい。分離できない場合でも、PHPの更新をLaravelだけの作業だと考えないことが大切だ。

Composer依存関係とバージョン整合性のチェック

Composerは、PHPプロジェクトのパッケージを取得するだけの道具ではない。各パッケージのバージョン制約を読み取り、互いに成立する組み合わせを解決する仕組みである。

プロジェクトの状態を理解するには、composer.jsonとcomposer.lockの役割を分けて考える。

composer.jsonは、プロジェクトが必要とするパッケージと、許容するバージョン範囲を宣言する。composer.lockは、その宣言をもとに解決された具体的なパッケージのバージョンを固定する。

composer installは、基本的にロックファイルに記録された組み合わせを再現する。開発環境、継続的インテグレーション、本番環境で同じロックファイルを使えば、依存関係の差分を小さくできる。

一方、composer updateは依存関係を再解決し、条件の範囲内で新しいバージョンを取得する。つまり、composer updateは「ロックファイルの内容をそのまま再現する」コマンドではない。実行方法によっては、複数のパッケージが同時に更新される。

^や~を曖昧に扱わない

バージョン制約は、更新の範囲を決める。よく使う記法でも、意味を曖昧にしたままではいけない。

• ^12.0は、Laravel 12系を基本とし、13.0未満の範囲を許容する
• ~12.0は、12系の中で、指定された範囲に沿って更新する
• 12.3.4のような固定指定は、更新範囲を狭くする
• dev-mainなどの開発ブランチ指定は、再現性と安定性の扱いが難しくなる

ただし、実際の解決結果は一つの制約だけで決まらない。Laravelが依存するSymfonyのコンポーネント、Carbon、ロガー、データベース関連のパッケージなど、複数の条件が同時に評価される。

Laravelのメジャーアップグレードでは、composer.jsonのLaravel指定を変更してから、Composerのエラーを一つずつ解消していく方法が取られる。しかし、依存パッケージの制約を確認せずに進めると、無関係に見えるパッケージが更新を妨げる。

依存の理由を逆引きする

依存関係の調査では、パッケージを一覧で見るだけでは足りない。なぜそのパッケージが入っているのかを確認する。

次のようなコマンドが役立つ。

• composer show laravel/frameworkでLaravel本体のバージョンと要件を確認する
• composer depends laravel/frameworkでLaravelを必要としているパッケージを調べる
• composer why symfony/http-foundationで、特定のパッケージが入っている理由を逆引きする
• composer prohibits laravel/framework ^13.0で、Laravel 13への更新を妨げる条件を探す
• composer validateで、composer.jsonとロックファイルの状態を確認する

特にcomposer prohibitsは、メジャーアップグレード前の調査で有効だ。Laravel本体を更新できない理由が、直接の指定ではなく、古い認証パッケージや管理画面パッケージにあることが分かる場合がある。

依存関係の問題を見つけたとき、すぐにパッケージを削除するのは避けたい。そのパッケージが、画面のどの機能や定期処理で使われているかを確認する。使っていないように見えて、サービスプロバイダーや設定ファイルから読み込まれていることもある。

Composerのエラーは、更新を拒否しているのではない。現在の依存関係では成立しない組み合わせを、先に知らせている。

部分更新には範囲を決める

たとえば、composer update laravel/frameworkだけを実行すると、Laravel本体を更新するために関連パッケージの再解決が必要になることがある。そこで、変更内容を確認せずに部分更新を繰り返すと、ロックファイルの差分が膨らみ、どの変更が原因でテストが失敗したのか分からなくなる。

更新前には、次の情報を残しておくとよい。

• 更新前のcomposer.json
• 更新前のcomposer.lock
• composer showの結果
• PHPのバージョン
• Laravelのバージョン
• 主要なテストの実行結果
• 本番とステージングの構成差分

Gitで管理しているなら、アップグレード専用のブランチを作る。更新を小さなコミットに分ければ、Laravel本体、PHP要件、周辺パッケージ、アプリケーション修正の関係を追いやすくなる。

ロックファイルの差分も、単に更新されたかどうかだけを見るのでは不十分だ。Laravel本体の更新にともなって、どのSymfonyコンポーネントが変わったのか、間接依存のパッケージがどこまで動いたのかを確認する。差分が大きい場合は、アプリケーションコードの修正と依存関係の更新を別のコミットに分けると、原因の追跡が楽になる。

個人開発におけるアップグレード戦略とリスク回避

個人開発では、常に最新のLaravelへ移行する必要はない。新機能を使う予定がなく、現在のバージョンがセキュリティサポート内で、依存関係も安定しているなら、すぐにメジャーアップグレードしない判断にも合理性はある。

ただし、保留には期限をつけるべきだ。「時間ができたら更新する」は、実質的に更新しない計画になりやすい。

更新を始める判断材料

次のような状態になったら、具体的な移行計画を作る。

• Laravelのセキュリティ修正終了日が近づいている
• 利用中のPHPが、次のLaravelで要求される最低バージョンを満たさない
• Composerで複数の依存パッケージが更新不能になっている
• PHPの非推奨機能に関する警告が増えている
• Dockerイメージや本番環境の更新が止まっている
• WordPressや外部サービス側の更新に、現在のPHPが追いつかなくなっている
• 新しい機能を追加するために、古いLaravelが制約になっている

セキュリティサポートの残りが少ない場合は、機能開発より先に移行作業を予定へ入れる。サポート終了まで半年を切った時点で計画を始めるという考え方は、個人開発でも現実的な目安になる。

ただし、残り期間を厳密な安全保証として扱ってはいけない。脆弱性の内容、アプリケーションの公開範囲、利用者が扱うデータ、更新に必要な作業量によって、許容できるリスクは変わる。外部公開している管理画面や個人情報を扱うサービスなら、期限ぎりぎりまで待つ理由は少ない。

LaravelとPHPを同時に上げるか、分けるか

Laravel 13へ移行するためにPHP 8.3が必要だとしても、LaravelとPHPを同じ変更で更新するか、別々に更新するかはプロジェクトによって変わる。

同時に更新するメリットは、作業期間を短くしやすいことだ。PHP 8.3へ上げた直後にLaravel 13へ移行するなら、環境を何度も作り直す必要がない。

一方で、問題が起きたときの原因は分かりにくくなる。PHPの更新で発生した問題なのか、Laravelの破壊的変更なのか、周辺パッケージの互換性なのかを切り分ける必要があるからだ。

変更を分ける場合は、まずPHPだけを更新し、既存のLaravelと主要機能が動くことを確認する。その後にLaravelを更新する。作業は増えるが、原因を特定しやすい。

判断の目安は、テストの量と本番構成の複雑さである。

どの方法を選んでも、変更前の状態へ戻せることが前提になる。Dockerを使っているなら、イメージのタグや依存ファイルの変更を記録し、以前のイメージを再ビルドできる状態にしておく。データベースのマイグレーションを伴う場合は、アプリケーションのロールバックだけでなく、データ構造をどう戻すかも考える必要がある。

PHPの更新を先に行う場合も、Laravel本体が公式に対応しているかだけでなく、プロジェクトの依存パッケージがそのPHPを許容しているかを確認する。Laravelの表でPHP 8.3が範囲に含まれていても、古い決済ライブラリや画像処理パッケージが別の制約を持っていれば、Composerの解決や実行時に問題が出る可能性がある。

アップグレードの実作業を分解する

個人開発で無理なく進めるなら、一度にすべてを変更しない。次のように段階を分けると、失敗箇所を把握しやすい。

1. 現状を記録する

php -v、php artisan --version、composer show、Dockerのイメージ情報を保存する。現在の状態が分からなければ、移行後に何が変わったか判断できない。

2. 依存パッケージを調査する

Laravel本体だけでなく、認証、管理画面、キュー、画像、決済、外部APIなどのパッケージを一覧にする。直接指定しているものと、間接的に入っているものを分けて見る。

3. PHPの互換性を確認する

本番、開発、継続的インテグレーション、定期処理で使うPHPが同じ条件か確認する。ウェブサーバーのPHPとCLIのPHPが異なる構成では、両方を調べる。

4. Laravelの移行ガイドを読む

非推奨になった機能、削除された設定、例外処理、認証、ルーティング、キューなど、プロジェクトで使っている箇所を拾う。移行ガイドを最後に読むのではなく、変更前の調査資料として使う。

5. 依存関係を更新する

composer.jsonを変更し、必要な範囲でComposerを実行する。ロックファイルの差分を確認し、意図していないメジャー更新が含まれていないかを見る。

6. 自動テストと手動確認を行う

テストが通るだけでは不十分な場合がある。ログイン、ファイルアップロード、メール送信、キュー、バッチ、管理画面など、利用頻度が高く障害の影響が大きい機能を確認する。

7. ステージングから本番へ進める

開発環境で動いたことを、本番反映の根拠にしない。環境変数、PHP拡張、権限、データ量、外部サービスの接続条件が異なるためだ。

この手順で大切なのは、最後に確認することではなく、各段階で止まれるようにすることだ。Composerの解決に失敗したらそこで止める。テストで認証が壊れたら、キャッシュを消して先へ進むのではなく、原因を確認する。問題を積み重ねたまま本番へ近づくと、切り戻しの判断が難しくなる。

バージョン整合性を日常の運用に組み込む

アップグレードは、数年に一度の大作業として扱うより、普段から小さく確認したほうが負担が少ない。

毎回すべてのパッケージを更新する必要はないが、少なくとも次の状態は定期的に確認したい。

• Laravelの現在のメジャーバージョン
• Laravelのセキュリティ修正終了日
• PHPの現在のバージョン
• composer.jsonとcomposer.lockの差分
• Dockerイメージの更新状況
• 主要パッケージの更新可能範囲
• 自動テストの実行結果
• 本番環境と開発環境のPHP差分

composer outdatedで更新可能なパッケージが見つかったとしても、すぐに本番へ反映する必要はない。まず変更履歴を確認し、現在の制約内で適用できる更新なのか、メジャーアップグレードを含むのかを分ける。

依存パッケージを長期間放置すると、後からまとめて更新することになる。そのときには、Laravel、PHP、Composer、周辺パッケージを同時に変えなければならない状態になりやすい。小さな更新を定期的に適用しておけば、変更の単位を小さく保てる。

ただし、無計画な自動更新も避けるべきだ。更新を自動化する場合は、まず継続的インテグレーション上でテストを実行し、失敗した更新を本番へ進めない仕組みにする。自動化の目的は、確認を省くことではなく、確認が必要な変更を早く見つけることにある。

定期的に確認したいのは、単独のバージョン番号ではない。たとえばcomposer.jsonがPHP 8.2を許容していても、本番のコンテナがPHP 8.1のままなら、宣言と実行環境が一致していない。逆に、本番がPHP 8.3へ更新されていても、古いパッケージがその環境で動くとは限らない。

「宣言されている条件」「実際にインストールされたもの」「現在動いている環境」の三つを定期的に突き合わせる。これだけでも、アップグレード直前に初めて環境の差分に気づく事態を減らせる。

バージョンの問題は、最終的には日付の問題になる

Laravel、PHP、Composer、Dockerのどれか一つだけを見ていると、環境全体のズレを見落とす。composer.jsonが要求するPHP、実際に起動しているPHP、composer.lockに固定された依存関係、サーバー上のコンテナが、同じ前提を共有しているかを確認する必要がある。

Laravel 12を使い続けるのか、Laravel 13へ移行するのかという判断も、単純な新旧比較ではない。PHPの更新が必要か、周辺パッケージが対応しているか、テストがどこまで用意されているか、本番から戻せるかを含めて決める。

「動いている」は、現在の動作を示すだけで、将来も安全に保守できることまでは示さない。

個人開発で必要なのは、常に最新を追いかけることではない。自分のプロジェクトがどのサポート期間にあり、どの条件で次のバージョンへ移行できるのかを把握しておくことだ。

まずは実行環境でphp -vを確認する。次にphp artisan --versionとcomposer show laravel/frameworkでLaravelの実体を見る。そのうえでcomposer.json、composer.lock、Dockerの設定を突き合わせる。ここまで行えば、少なくとも「何を更新しなければならないのか分からない」という状態からは抜け出せる。

サポート終了日は、突然やってくる障害ではない。前もって分かっている予定である。だから、EOLの日付を起点にして、調査、テスト、環境更新、本番反映の日程を逆算する。LaravelとPHPのバージョン整合性を管理するとは、その計画を普段の開発に組み込むことにほかならない。

Related reading: Laravel 11のミドルウェア登録で判明した新設計と移行の注意点 and Laravelの本番環境向けDockerfile：マルチステージビルドによるイメージ軽量化の是非.