Contents
現行 Laravel メジャーリリースと最低 PHP バージョン
Laravel 10 が LTS（Long‑Term Support）として公式にリリースされている現在、各メジャーリリースは PHP の新機能を活かすために最低バージョン要件を段階的に引き上げています。このセクションでは、2024 年 3 月時点で公式ドキュメントが明示している要件のみを掲載し、将来のリリースについては「予定」や「検討中」といった表現に留めます。
注：Laravel の次期メジャー（11 以降）の正式な PHP 要件は、リリースノートが公開されるまで確定情報として扱えません。最新情報は Laravel 公式ブログや GitHub リポジトリの
CHANGELOG.mdを随時確認してください。
| Laravel バージョン | 最小 PHP バージョン* | LTS 判定** | サポート終了予定日† |
|---|---|---|---|
| 10 (2023‑02) | >= 8.0 | ○（LTS） | 2028‑02 |
| 11 (2024‑02) | >= 8.1 ※未確定 | ×（非 LTS） | 2029‑02 |
| 12 (2025‑02) | >= 8.2 ※未確定 | ×（非 LTS） | 2030‑02 |
* 最小 PHP バージョンは Laravel の公式インストール要件ページを参照。[^1]
** LTS 判定は Laravel が正式に「LTS」と表記したバージョンのみ対象。[^2]
† サポート終了日は Laravel のリリースサイクル（5 年間のバグフィックス＋2 年間のセキュリティパッチ）を基に算出。[^3]
現行バージョンの要件が意味すること
- PHP 8.0 未満では Composer が依存解決に失敗し、インストールが中断されます。
- LTS バージョンは長期運用を前提としているため、安定環境を維持したいプロジェクトは Laravel 10 の採用が推奨されます。
LTS 判定とサポートスケジュール（公式情報）
Laravel の LTS は「リリースから 5 年間のバグフィックス + 2 年間のセキュリティパッチ」提供という明確な方針があります。この節では、現在公式に発表されている Laravel 10 のサポート期間と、過去 LTS バージョンの実績を比較しながら解説します。
| バージョン | LTS 判定 | バグフィックス期間 | セキュリティパッチ期間 |
|---|---|---|---|
| Laravel 10 | ○（LTS） | 2023‑02 → 2028‑02 | 2028‑02 → 2030‑02 |
| Laravel 9 | ×（非 LTS） | 2022‑02 → 2025‑02 | 2025‑02 → 2027‑02 |
ポイント：LTS が付与されたバージョンは、長期的な保守コストが低減するため、エンタープライズ向けプロジェクトのデフォルト選択肢となります。[^4]
PHP の主要リリースと Laravel への影響（確定情報のみ）
PHP は毎年 11 月に新メジャーをリリースし、型システムや JIT エンジンが徐々に拡充されています。本節では 公式にリリース済みの PHP バージョン（8.0〜8.3）について、Laravel コアおよび主要パッケージが受ける影響をまとめます。将来の 8.4・8.5 の機能は「開発中」や「提案段階」の情報であるため、本稿では記載しません。
| PHP バージョン | Laravel コアへの主な影響 |
|---|---|
| 8.0 | Union Types、属性（Attributes）導入に伴い、ミドルウェアやバリデーションルールの型宣言が可能になった。 |
| 8.1 | readonly プロパティと enum が利用でき、Eloquent モデルで不変プロパティを安全に定義できるようになった。 |
| 8.2 | true/false 型が正式サポートされ、Form Request のバリデーションで真偽値限定のシグネチャが記述可能。 |
| 8.3 | dynamic properties が非推奨化されたことで、Laravel のマジックプロパティ使用時に IDE 補完が向上した。 |
出典：PHP 各バージョンのリリースノート（php.net）と Laravel 公式アップグレードガイド[^5][^6]
PHP バージョン選定の実務的視点
- 開発環境は常に最新安定版を使用し、CI で複数バージョン（8.1〜8.3）をマトリクステストすることで互換性問題を早期に検出できます。
- サードパーティーパッケージの対応状況は
composer outdatedで定期的に確認し、PHP バージョンアップ時の破壊的変更に備えます。
移行作業の実践チェックリスト
このセクションでは、Laravel と PHP のバージョン更新を安全かつ効率的に進めるための 具体的な手順 を示します。各項目は独立したタスクとして CI に組み込むことが可能です。
1. 互換性チェックツールの導入
| ツール名 | 特徴 | 推奨利用シーン |
|---|---|---|
| laravel‑shift（有料） | Laravel のメジャーアップグレード用スクリプトを自動生成。 | 大規模コードベースの一括変換に最適。 |
| rector/laravel（オープンソース） | PHPStan と連携し、細粒度なリファクタリングが可能。 | CI で段階的に変更を検証したい場合。 |
実装例（Rector の設定）
|
1 2 3 4 |
# rector.yaml services: Rector\Laravel\Set\LaravelSetList::LARAVEL_10_TO_11: null |
注：ツールは必ず
--dry-runオプションで変更内容を確認し、コードレビュー後に本番適用してください。[^7]
2. CI/CD パイプラインへの組み込み
以下は GitHub Actions のサンプルです。PHP バージョン 8.1〜8.3 をマトリクスでテストし、Rector と PHPUnit を同時に実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
name: Laravel Compatibility CI on: push: branches: [ main ] pull_request: jobs: test: runs-on: ubuntu-latest strategy: matrix: php-version: ['8.1', '8.2', '8.3'] steps: - uses: actions/checkout@v3 - name: Set up PHP ${{ matrix.php-version }} uses: shivammathur/setup-php@v2 with: php-version: ${{ matrix.php-version }} extensions: mbstring, intl, xml - run: composer install --prefer-dist --no-progress - name: Run Rector (dry‑run) run: vendor/bin/rector process src --set laravel-10-to-11 --dry-run || true - name: Execute Tests run: vendor/bin/phpunit |
この構成により、PHP の全サポートバージョンでテストが成功すれば本番環境へのリスクは大幅に低減します。
3. 非推奨機能の置換と Lint ツール活用
| 非推奨対象 | 削除予定（Laravel） | 推奨代替実装 |
|---|---|---|
Route::match(['GET','POST'], ...) の文字列配列 |
Laravel 12（検討中） | Route::match(['get', 'post'], …) （小文字表記） |
Facade の暗黙的取得 (Facade::getFacadeRoot()) |
Laravel 13（検討中） | サービスコンテナから直接取得 app(ExampleService::class) |
$request->input('flag', false) のデフォルトが null に統一 |
Laravel 11（実装済み） | 型宣言付き Form Request クラスでプロパティに初期値を設定 |
ベストプラクティス：
phpstan+larastanを CI に追加し、非推奨コードの検出と自動レポート化を行うことで、技術的負債の蓄積を防げます。[^8]
4. データベースマイグレーションとキャッシュクリア
- マイグレーション前チェック
php artisan migrate:statusで未実行マイグレーションを一覧化。-
本番環境では
--lock=1オプションで排他制御し、同時実行による競合を防止（Laravel 10 以降）。 -
キャッシュリフレッシュ
- デプロイ後は必ず
php artisan config:cache && php artisan route:cache && php artisan view:clearを実行。 - CI のデプロイスクリプトに組み込むことで、人為的ミスを排除できます。
安全なデプロイ戦略と次のアクション
バージョンアップは機能追加だけでなく、既存ロジックへの影響も伴うため 段階的ロールアウト が推奨されます。ここではステージング環境での検証フローと、Blue/Green デプロイの実装ポイントを解説します。
ステージングでの総合テスト
- 本番と同一構成（PHP バージョン、データベース、キャッシュ）を用意し、CI の結果に加えて 手動シナリオテスト（認証・ジョブキュー）も実施。
- テストケースは「主要機能」「外部サービス連携」の2カテゴリに分け、失敗時のロールバック手順を事前にドキュメント化しておく。
Blue/Green デプロイの具体的手順（Docker/Kubernetes 前提）
- Blue 環境：現在稼働中の Laravel アプリ。
- Green 環境：新バージョンをデプロイした検証用コンテナ。
- Green で
php artisan migrate --forceとキャッシュリフレッシュを実行し、すべての自動テストが成功したらロードバランサーのトラフィック比率を 0%→100% に切り替える。 - 問題発生時は即座に Blue 環境へロールバックし、
helm rollbackまたはkubectl rollout undoコマンドで復元。
メリット：障害が起きてもトラフィックを切り替えるだけで復旧できるため、ダウンタイムを数秒に抑えられます。[^9]
今すぐ取るべき 3 つのアクション
- 公式ドキュメントと互換性チェッカー を用いて、対象 Laravel バージョンと PHP バージョンの組み合わせをステージング環境でテスト。
- CI に
laravel‑shift／rectorとphpstan+larastanを導入し、プルリクエストごとに自動的に非推奨コードや型ミスマッチを検出。 - Blue/Green デプロイパイプライン（Docker Compose も可）を構築し、本番切り替え前に全テストが通過したことを確認。
これらの手順を体系化すれば、Laravel と PHP のバージョン互換性リスクを最小限に抑えつつ、安全・迅速なアップグレードが実現できます。
参考文献・出典
[^1]: Laravel 公式インストール要件 – https://laravel.com/docs/10.x/installation#server-requirements
[^2]: Laravel LTS の定義 – https://laravel.com/docs/10.x/releases#long-term-support-lts
[^3]: Laravel バージョンごとのサポートスケジュール（2024 年 3 月時点） – https://github.com/laravel/framework/blob/10.x/CHANGELOG.md
[^4]: 「Laravel LTS が提供する長期保守」 – Laravel News, 2023年5月掲載記事。
[^5]: PHP 8.0 Release Notes – https://www.php.net/releases/8_0_0.php
[^6]: PHP 8.1–8.3 の新機能解説 – https://www.php.net/manual/en/migration81.php, https://www.php.net/manual/en/migration82.php, https://www.php.net/manual/en/migration83.php
[^7]: Laravel Shift ドキュメント – https://laravelshift.com/
[^8]: PHPStan + Larastan 公式ガイド – https://github.com/larastan/larastan
[^9]: 「Blue‑Green Deployments with Kubernetes」 – Google Cloud Blog, 2022年10月掲載。