Laravel 12サポート期限とバージョン移行ガイド｜EOLスケジュール・PHP要件とアップグレード手順

「運用中のWebシステムで使っているLaravel 12のサポート期限（EOL）はいつまで？」「Laravel 11からLaravel 12へのバージョン移行はどのような手順で進めるべき？」「推奨されるPHPバージョンやアップグレード前の注意点は？」と疑問をお持ちではありませんか？

PHPフレームワークのデファクトスタンダードとして世界中で採用されているLaravelですが、バージョンごとの公式サポート期間を正確に把握して計画的にメンテナンスを行わないと、セキュリティパッチの提供停止や外部ライブラリの非互換による重大なシステム障害を引き起こすリスクがあります。

結論からお伝えすると、Laravel 12は「リリース後18ヶ月間のバグ修正」と「リリース後2年間のセキュリティ修正」が提供されるライフサイクルで運用されています。また、Laravel 11で大幅に刷新されたスリムなアプリケーション構造を安定して継承しているため、Laravel 11からLaravel 12へのアップグレードは破壊的変更が極めて少なく、非常にスムーズに実施可能です。

本ガイドでは、実務で開発・保守を担うエンジニアやテックリードの方々に向けて、Laravel 12のサポートライフサイクルの全貌から、安全なバージョン移行手順、旧バージョン放置によるセキュリティリスクまで徹底解説します。

【早見表】Laravel各バージョンのサポート期限（EOL）とPHP対応マトリクス

まずはじめに、現在多くの企業システムで稼働しているLaravel 9〜12のリリース日、バグ修正終了日、セキュリティ修正終了日（EOL）、および対応PHPバージョンを一覧できるファーストビュー早見表を掲載します。

過去の全バージョンを含む包括的なEOL情報については、当サイトの別記事「Laravel EOLバージョン一覧とサポート終了まとめ」でも体系的に整理しています。あわせてご参照ください。

Laravel 9, 10, 11, 12 のバグ修正期限・セキュリティ修正期限・リリース日一覧表

Laravelのサポート期限を見る際には、「バグ修正期間」と「セキュリティ修正期間」の違いを明確に意識することが極めて重要です。

表から読み取れる通り、Laravel 11はすでに2026年3月12日をもってセキュリティ修正を含めた全サポートが終了（EOL）しています。現在Laravel 11で本番稼働しているWebサービスは、コアフレームワークに新たなゼロデイ脆弱性やバグが発覚しても公式からパッチが提供されない状態にあります。

一方、Laravel 12は2027年2月24日までセキュリティパッチが継続提供されます。重大な脆弱性に対して安全に保護されているため、これから新年度に向けてシステムのバージョン維持運用を計画する現場にとって、最も現実的かつ安定した移行ターゲットとなります。

対応PHPバージョン（PHP 8.2 / 8.3 / 8.4）の互換性マトリクス

Laravelのアップグレード計画を策定する際、決して見落としてはならないのが「実行基盤となるPHP自体のサポート期限」との兼ね合いです。

ここで特に注意すべき点は、Laravel 12はPHP 8.2でも動作可能であるものの、PHP 8.2本体の公式セキュリティサポートが2026年12月31日をもって終了するという事実です。

もしサーバーのPHPランタイムをPHP 8.2のまま運用し続けた場合、Laravel 12自体のサポート期間（2027年2月まで）が残っていたとしても、基盤となるPHPエンジンの脆弱性が放置される状態に陥ってしまいます。したがって、Laravel 12への移行を機に、インフラ環境のPHPバージョンをPHP 8.3または最新のPHP 8.4へ同時に引き上げることがエンタープライズ運用におけるベストプラクティスです。

Linuxサーバー環境におけるPHPやLaravelのセットアップ手順については、「LinuxでLaravelを簡単にインストールする手順ガイド」で実践的な導入フローを詳しく解説しています。

1. Laravelのリリースサイクルとサポートポリシーの仕組み

Laravelのサポート期限やEOLを正しく理解するためには、公式開発チームが定めているリリースサイクル（Release Cycle）とサポートポリシー（Support Policy）の基本原則を把握しておく必要があります。

フレームワークの更新方針を把握しておくことで、「いつバージョンアップの検証に着手すべきか」「保守開発の予算や工数をどの時期に確保すべきか」を体系的に計画できるようになります。

年次リリースサイクル（毎年Q1リリース）とLTS（長期サポート）の廃止方針

現在、Laravelは「毎年第1四半期（Q1：1月〜3月頃）に1つのメジャーバージョンをリリースする」という年次リリースサイクルを完全に定着させています。

現場のエンジニアやプロジェクトマネージャーの間で今なお見受けられる誤解が、「LTS版を選んでおけば、3〜5年間はバージョンアップを行わずに放置できるのではないか」という思い込みです。

結論として、現在のLaravelには「LTS版」は存在しません。Laravel 6を最後にLTS制度は廃止されており、Laravel 9、10、11、12を含むすべてのメジャーバージョンは一律で「2年間のサポート期間」に統一されています。

LTSが廃止された理由は、「数年間放置されたレガシーシステムを一気に引き上げるよりも、破壊的変更を最小限に抑えた年次アップデートを毎年定期的に適用する方が、結果として開発現場の移行負荷とリスクを劇的に低減できる」という設計思想に基づいています。

バグ修正18ヶ月・セキュリティ修正24ヶ月の基本ルール

Laravelの公式サポート期間は、リリース日を起点とした「2段階のフェーズ」に分かれています。

【Laravelのサポートタイムライン（全24ヶ月）】

リリース日
  │
  ├─ 【第1フェーズ：アクティブサポート】（0ヶ月 〜 18ヶ月間）
  │    ・バグ修正（Bug Fixes）の提供
  │    ・セキュリティ修正（Security Fixes）の提供
  │    ・新機能・マイナー改善パッチの継続提供
  │
  ├─ 【第2フェーズ：セキュリティメンテナンス】（18ヶ月 〜 24ヶ月間）
  │    ・セキュリティ修正（Security Fixes）のみ提供
  │    ・一般的な機能不具合やバグ修正は終了
  │
24ヶ月後（満2年）
  │
  └─ 【サポート終了（EOL: End of Life）】
       ・公式パッチ提供の完全終了
       ・ゼロデイ脆弱性に対する修正も提供されない状態へ

具体的には以下の2つの期間で構成されます。

1. バグ修正期間（Bug Fixes：18ヶ月間）
   フレームワーク内部の不具合修正、パフォーマンスの最適化、PHPマイナーバージョンアップへの追随パッチ、およびセキュリティ脆弱性の修正がすべて精力的に行われるフルサポート期間です。
2. セキュリティ修正期間（Security Fixes：24ヶ月間、後半6ヶ月）
   重大なセキュリティ脆弱性（CVE）が報告された場合の緊急パッチのみが提供されるフェーズです。通常の機能バグや非互換の修正は原則として行われなくなります。

また、Laravel本体だけでなく、周辺の公式ファーストパーティパッケージ（Sanctum、Breeze、Telescope、Horizon、Cashierなど）のサポート方針にも注意が必要です。これらの公式パッケージは、原則として「現行最新のメジャーバージョン」を対象に新機能の追加や最適化が行われるため、Laravel本体のバージョンを維持し続けることがエコシステム全体の健全性を保つ唯一の手段となります。

2. Laravel 12のサポート期限詳細とシステム選定基準

ここからは、本記事の主役であるLaravel 12のサポート終了スケジュール詳細と、なぜいま企業の開発現場でLaravel 12を選定すべきなのかという意思決定基準を掘り下げます。

Laravel 12のサポート終了スケジュール（バグ修正期限とセキュリティ期限）

Laravel 12の具体的なライフサイクル日程は以下の通りです。

現在のステータスとして、Laravel 12はバグ修正期間を経てセキュリティサポート期間（後半フェーズ）へ移行していますが、2027年2月24日まではセキュリティ修正が保証されています。

多くの企業や開発チームでは、第4四半期（10月〜12月）から新年度の第1四半期（1月〜3月）にかけて年間のシステム保守予算やバージョンアップ計画を策定します。すでにEOLを迎えてしまっているLaravel 11以前のシステムを運用している現場にとって、秋から冬にかけてLaravel 12への移行プロジェクトを立ち上げ、年度内に安全にカットオーバーさせることは、セキュリティリスクを排除するための最も合理的かつ優先度の高い施策となります。

企業の新規開発・システムリプレイスでLaravel 12を採用すべき理由

企業の新規Webサービス開発や、既存レガシーシステムのモダンリプレイスにおいて、なぜLaravel 12を採用すべきなのでしょうか。その理由は単なるサポート期限の長さだけではありません。現場目線での決定的なメリットが4点存在します。

① Laravel 11のスリム構造が完全に成熟・安定化している

Laravel 11では、長年親しまれてきた app/Http/Kernel.php や app/Console/Kernel.php が廃止され、bootstrap/app.php への設定集約、不要な設定ファイルの自動オンデマンド読み込みなど、フレームワークの骨格（Skeleton）が大幅に軽量化されました。

Laravel 12はこの洗練されたスリム構造をそのまま継承しており、初期リリース直後の混乱や周辺ライブラリの非互換が完全に解消された「最も洗練され、安定したディレクトリ構造」で開発を進めることができます。

② 破壊的変更（Breaking Changes）が極めて少なく、アップグレードコストが極小

Laravel 11からLaravel 12への移行に伴う破壊的変更は、後述するCarbon 3への移行やSVGバリデーションの仕様変更など数点に限られており、一般的なビジネスロジックコードへの影響はほぼ皆無です。多くのプロジェクトにおいて、半日〜1日程度の検証作業で安全にアップデートを完了できます。

③ 公式AIエコシステム（Laravel AI SDK & Laravel Boost）との親和性

Laravel 12では、OpenAIやAnthropic（Claude）、Google（Gemini）などの大規模言語モデルを直感的なPHPコードで操作できる公式AI SDK（laravel/ai）や、AIコーディングアシスタントと安全にプロジェクトコンテキストを共有するMCPサーバー「Laravel Boost」など、次世代のAIネイティブな開発スタイルを支える基盤が整っています。

Laravel 12の機能全容については、当サイトの「Laravel 12の新機能・変更点総まとめ」でも詳しく解説していますので、機能選定の参考にしてください。

④ エンタープライズ開発に耐えうる本番実績とサードパーティパッケージの対応完了

リリースから一定期間が経過したことで、主要なサードパーティ製パッケージ（決済SDK、認証プロバイダ、監視ツール、SaaS連携クライアント等）のLaravel 12対応がすべて完了しています。新規導入時に「依存関係が解決できずプロジェクトが進まない」というリスクがありません。

3. Laravel 11からLaravel 12へのアップグレード完全チェックリスト

ここからは、実際に稼働中のLaravel 11アプリケーションをLaravel 12へ安全に移行するための実践的なアップグレード手順を完全チェックリスト形式で解説します。

事前の準備から依存パッケージの更新、破壊的変更への対応、自動テストの検証まで、ステップに沿って着実に進めることで、本番環境でのトラブルを未然に防ぐことができます。

アップグレード前の準備（バックアップ、PHPバージョン確認、テストカバレッジ）

アップグレード作業に着手する前に、必ず以下の3つの事前準備を完了させてください。

現在のLaravelバージョンおよびPHPバージョンの詳細情報は、ターミナルで以下のコマンドを実行することで一括確認できます。

# Laravel環境情報の一括表示
php artisan about

環境別の詳しいバージョン確認手順や、本番環境・PHPプログラムコード内からの判定方法については、「Laravelのバージョン確認方法まとめ」で詳しく解説しています。

composer.json の依存パッケージ更新手順（laravel/framework: ^12.0）

事前準備が整ったら、プロジェクトルートにある composer.json をエディタで開き、Laravelフレームワーク本体および開発用ツールのバージョン制約を更新します。

{
    "require": {
        "php": "^8.2",
        "laravel/framework": "^12.0",
        "laravel/tinker": "^2.10.1"
    },
    "require-dev": {
        "fakerphp/faker": "^1.23",
        "laravel/pail": "^1.2.2",
        "laravel/pint": "^1.21",
        "laravel/sail": "^1.41",
        "mockery/mockery": "^1.6",
        "nunomaduro/collision": "^8.6",
        "pestphp/pest": "^3.7",
        "pestphp/pest-plugin-laravel": "^3.1",
        "phpunit/phpunit": "^11.5.3"
    }
}

ファイルを保存したら、ターミナルで依存関係の更新を実行します。サードパーティ製ライブラリの依存関係も含めて一括解決するために、--with-all-dependencies オプションを付与して実行することを推奨します。

# 依存パッケージの一括更新
composer update --with-all-dependencies

もしComposerの依存解決エラー（Your requirements could not be resolved to an installable set of packages.）が発生した場合は、後述するCarbon 2/3の競合や、未更新のサードパーティ製パッケージが原因であることが大半です。composer outdated コマンドを実行して、各ライブラリの最新バージョン状況を確認してください。

公式Laravel Upgrade Guideで確認すべき破壊的変更（Breaking Changes）の要点

Laravel 11からLaravel 12へのアップグレードでは、影響度の高い破壊的変更（Breaking Changes）はごく少数に抑えられています。実務で特に押さえておくべきポイントは以下の3点です。

① Carbon 3.x への完全移行（Carbon 2のサポート廃止）

Laravel 12では日付操作ライブラリである Carbon 3.x の使用が必須 となりました。Laravel 11まではCarbon 2と3の両方がサポートされていましたが、Laravel 12ではCarbon 2のサポートが完全に終了しています。

通常のアプリケーションコード（Carbon::now() や $user->created_at->format('Y-m-d') など）は後方互換性が保たれており修正不要ですが、サードパーティ製パッケージが "nesbot/carbon": "^2.0" に固定されている場合に依存解決エラーが発生します。該当パッケージを最新版に更新するか、代替ライブラリへ差し替えてください。

② SVG画像のバリデーション仕様変更（セキュリティ向上）

セキュリティ強化（SVGファイル内に埋め込まれた不正スクリプトによるStored XSS攻撃の防止）のため、標準の image バリデーションルールにおいて SVG ファイルがデフォルトで除外 されるようになりました。

// 【Laravel 11以前】SVGも画像として通過していた
$request->validate([
    'logo' => 'required|image',
]);

// 【Laravel 12】SVGはバリデーションエラーとなる
// SVGのアップロードを明示的に許可したい場合は以下のように記述変更する
$request->validate([
    'logo' => 'required|file|mimes:jpeg,png,jpg,gif,svg,webp',
]);

③ データベース Blueprint クラスの内部引数変更

マイグレーションのテーブル定義を司る低レベル内部クラス Illuminate\Database\Schema\Blueprint のコンストラクタにおいて、Illuminate\Database\Connection インスタンスの受け渡しが必須となりました。一般的な Schema::create(...) を利用したマイグレーション定義には影響ありませんが、スキーマ操作を独自拡張しているカスタムパッケージやマクロを定義している場合は動作検証が必要です。

【公式リファレンス活用】公式ドキュメントと日本語翻訳（ReadDouble）を活用したバージョン差分検索法

アップグレードを安全かつ短時間で完遂させるための実務テクニックとして、公式リファレンスと有志日本語翻訳ドキュメント（ReadDouble）を賢く組み合わせるハイブリッド活用フローを推奨します。

日本語ドキュメントで大枠の設計思想を理解したうえで、英語公式とGitHubの一次情報で細部の変更差分を検証する二段構えをとることで、仕様の見落としによる本番不具合をゼロに抑えることができます。

Pest / PHPUnit による自動テスト実行と動作検証

コードの修正が完了したら、キャッシュをクリアした上で自動テストを実行し、すべての機能が正常に動作していることを検証します。

# 1. 各種キャッシュ（設定・ルート・ビュー）の一括クリア
php artisan optimize:clear

# 2. 自動テストスイートの実行（Pest または PHPUnit）
php artisan test

すべてのテストケースがグリーンになったら、ローカル環境およびステージング環境においてブラウザやAPIクライアントを用いた手動スモークテスト（認証、主要CRUD、決済、メール送信、ジョブキューの処理等）を実施し、ログ（storage/logs/laravel.log）に例外や警告が出力されていないことを確認します。

4. サポート終了（EOL）を迎えた旧バージョンを放置するセキュリティリスク

「システムが問題なく稼働しているから、わざわざコストをかけてまでバージョンアップする必要はないのではないか」という声を現場で耳にすることがあります。しかし、サポート終了（EOL）を迎えたLaravelを本番環境で放置し続けることには、企業の事業継続を脅かす極めて深刻なリスクが存在します。

脆弱性放置による不正アクセス・データ漏洩リスク

EOLを迎えたバージョンに対しては、Laravel公式セキュリティチームからいかなる修正パッチも提供されなくなります。

Webアプリケーションのフレームワークには、SQLインジェクション、クロスサイトスクリプティング（XSS）、セッションハイジャック、リモートコード実行（RCE）など、日々新たな攻撃手法や脆弱性（CVE）が報告されます。サポート期間中であれば composer update だけで即座に修正パッチを適用できますが、EOL後は「既知の脆弱性が野放しになっている危険なシステム」としてインターネット上に晒され続けることになります。

万が一情報漏洩事故が発生した場合、個人情報保護法に基づく監督官庁への報告義務や損害賠償責任が発生するだけでなく、企業の社会的信用が失墜します。特にPCI DSSやISMS（ISO 27001）などの情報セキュリティ基準では、「サポートが継続しているOSおよびミドルウェアの利用」が明確に義務付けられているため、コンプライアンス監査において重大な指摘事項となります。

PHP自体のEOL（PHP 8.1以前）との複合リスク

旧バージョンのLaravelを運用している環境では、「基盤となるPHPランタイム自体のEOL」も同時に進行しているという複合リスクを抱えています。

例えば、Laravel 10以前のシステムで利用されているPHP 8.1やPHP 8.0はすでにセキュリティサポートが終了しています。また、Laravel 11で利用されているPHP 8.2も2026年12月末でEOLを迎えます。PHP本体のセキュリティパッチが提供されない環境では、Webサーバーそのものの乗っ取りリスクが高まります。

さらに、StripeやAWS、SendGridなどの外部SaaSや決済サービスの公式SDKは、古いPHPバージョンや古いLaravelのサポートを順次打ち切っていきます。ある日突然「外部APIの仕様変更に対応できず、決済処理やメール送信が停止する」といった実業務への致命的な障害に直結します。

過去バージョンの詳しいサポート履歴やアップグレード判断基準については、「Laravel EOLバージョン一覧とサポート終了まとめ」もあわせてご覧ください。

まとめ：安全なLaravelバージョン維持運用のロードマップ

本記事では、Laravel 12のサポート期限（EOLスケジュール）から、PHP要件、Laravel 11からの移行チェックリスト、そして旧バージョン放置のリスクまで体系的に解説しました。

要点を振り返ると以下の通りです。

Laravel 12への移行は破壊的変更が少なく、自動テストと公式ガイドを組み合わせることでスムーズに完遂できます。ぜひ本ガイドを参考に、安全で堅牢なLaravel運用環境を整えてください。

---

あわせて読みたいLaravel実践ガイド（関連記事）

Laravelの運用・保守から最新機能の活用まで、あわせて確認しておきたいおすすめの技術ガイドです。