Laravel 11の変更点とサポート期限｜EOL後も残る未修正の脆弱性と12・13への移行判断

Laravel 11は2024年3月12日にリリースされ、2026年3月12日でセキュリティ修正の提供も終了しました。それでも11.xブランチには2026年7月までタグが打たれ続けており、「まだ保守されているのか、もう危ないのか」が外から判断しにくい状態になっています。

この記事では、Laravel 11で実際に何が変わったのかを整理したうえで、EOL後の11.xで何が起きているかをGitHubの一次情報から確認し、12と13のどちらへ移すかの判断材料を示します。最新メジャーである13系そのものの内容はLaravel 13で正式安定版になったAI SDKの全体像と導入判断の前提知識、12系の要件と11からの具体的なアップグレード手順はLaravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点で扱っています。

まとめ：Laravel 11の現在地

• バグ修正は2025年9月3日、セキュリティ修正は2026年3月12日で提供終了。公式表の凡例でいう End of life に当たります。
• 2026年6月17日に公開された2件の脆弱性は、影響範囲が「12.60.0未満」「12.61.1未満」と記載され、Laravel 11系もこの範囲に入ります。修正版として案内されているのは12系と13系だけです。
• EOL後も11.xにはv11.55.0（2026年7月14日）までタグが打たれています。ただし中身はLaravel Cloudのマネージドキュー関連のバックポートで、v11.52.0以降はリリースノートも作成されていません。
• 11の中核はbootstrap/app.phpへの設定集約、Laravel Reverbの追加、/upヘルスルート、秒単位レート制限、暗号鍵の無停止ローテーション。既存アプリの構造変更は求められません。
• 対応PHPは8.2〜8.4。13系はPHP 8.3以上が必須のため、PHPの版が移行先の上限を決めます。
• 移行はメジャーを1つずつ。公式の想定所要時間は11→12が5分、12→13が10分です。

Laravel 11のサポート期限とEOL後に起きていること

バグ修正2025年9月3日・セキュリティ修正2026年3月12日で終了

Laravelのサポートポリシーは全リリース一律で、バグ修正が18か月、セキュリティ修正が2年と定められています。バージョンごとに期間の長短を設ける仕組みではないため、11だけが延長されることはありません。公式ドキュメントのサポート表に記載された各版の期限は次のとおりです。

表で見落とされがちなのは12系の位置づけです。12のバグ修正提供は2026年8月13日までで、それ以降はセキュリティ修正のみ（2027年2月24日まで）に移ります。11から12へ移してもバグ修正の窓はすでに閉じるため、移行先を12に決めるのは「セキュリティ修正が続く残り期間を買う」判断だと理解しておく必要があります。

EOL後も打たれ続ける11.xタグの正体

Packagistで11系のリリース履歴をたどると、セキュリティ修正期限の2026年3月12日を過ぎたあともv11.49.0とv11.50.0（2026年3月17日）、v11.51.0（3月26日）、v11.52.0（5月14日）と続き、最新はv11.55.0（2026年7月14日）です。タグだけを見れば保守が継続しているようにも読めます。

しかし中身は保守ではありません。GitHubのリリース一覧に登録されている11.x向けのリリースはv11.51.0が最後で、v11.52.0以降はタグが存在するのにリリースノートが作成されていません。v11.51.0からv11.55.0までの16コミットを確認すると、「Backport cloud queues」「Dedicated Cloud Queue」「Pop managed queue jobs from the cloud-agent instead of SQS」といった、Laravel Cloudのマネージドキューを11系でも動かすためのバックポートが大半を占めます。

タグが増えていることを、脆弱性が塞がれ続けている根拠として読んではいけません。これらはホスティング側の都合による機能移植であり、一般利用者向けのバグ修正・セキュリティ修正の窓は2026年3月12日で閉じたままです。

11系に修正版が出ていない2026年6月の脆弱性

EOLの実害は、すでに具体的な形で現れています。2026年6月17日、laravel/frameworkに対して2件のアドバイザリが公開されました。

影響範囲は「12.60.0未満」「12.61.1未満」と記載されており、11系の最終タグであるv11.55.0もこの範囲に含まれます。一方、修正版として案内されているのは12系と13系だけです。

記載レンジだけでなく、実コードでも裏が取れます。12系ではIlluminate/Validation/Concerns/ValidatesAttributes.phpのvalidateEmail()にpreg_match('/[\r\n]/', (string) $value)による改行文字のガードが追加されていますが、v11.55.0の同ファイルにこの記述はありません。前節で見たとおり、v11.52.0以降のコミットにも修正は入っていません。

フォームでemailバリデーションを使っているアプリケーションを、11系のまま運用する判断はもう取れません。もう1件のほうは適用範囲が狭く、公式の説明はローカルファイルシステムドライバの問題としています。config/filesystems.phpのlocalディスクで'serve' => trueを有効にし、Storage::disk('local')->temporaryUrl()で一時URLを発行している構成が該当します。期限切れのURLが有効なまま受け付けられたり、署名した対象と別のリソースに解決されたりする恐れがあります。

この2件はEOL後わずか3か月で出たものです。今後同種のものが出ても11系には修正が来ない、という前提で計画を立てる必要があります。

LTSという区分が現行ポリシーに無い点

「Laravel 10 LTS」「Laravel 11 LTS」といった検索が続いていますが、現行のサポートポリシーには長期サポート版の区分がありません。サポート表で(LTS)の表記が付いた最後のバージョンはLaravel 6（2019年9月3日リリース）で、当時のポリシーはLTSがバグ修正2年・セキュリティ修正3年、一般リリースがバグ修正6か月でした。Laravel 7以降は表からLTSの表記が消え、現在は全リリースが一律でバグ修正18か月・セキュリティ修正2年に統一されています。

つまり11も12も13もLTSではなく、Laravel 10も2025年2月4日でセキュリティ修正が終了済みです。「どれかがLTSだから当面は動かさなくてよい」という前提でバージョンを据え置いているなら、その前提自体が成り立ちません。

Laravel 11で実際に変わった点

bootstrap/app.phpへの集約とファイル削減

11の目玉は、新規アプリケーションの構成を薄くしたことです。従来5つあったサービスプロバイダはAppServiceProviderの1つだけになり、イベントの自動検出が既定で有効になりました。新規アプリに同梱されていた9つのミドルウェアはフレームワーク側へ移り、HTTPカーネルのクラスそのものが不要になっています。ルーティング・ミドルウェア・例外処理・サービスプロバイダの設定は、bootstrap/app.phpに集約されました。

<?php

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->validateCsrfTokens(except: ['stripe/*']);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        $exceptions->dontReport(MissedFlightException::class);
    })->create();

スケジュール定義もコンソールカーネルを介さず、routes/console.phpでScheduleファサードを使う形になりました。

<?php
// routes/console.php（Laravel 11以降はコンソールカーネルを置かない）
use Illuminate\Support\Facades\Schedule;

Schedule::command('emails:send')->daily();

またroutes/api.phpとroutes/channels.phpは既定で作られません。必要になった時点でphp artisan install:api、php artisan install:broadcastingを実行して追加します。

ここで誤解されやすいのは適用範囲です。この構成変更は新規作成するアプリケーションに対するもので、公式ドキュメントは既存アプリケーションに変更を求めていません。10から11へ上げただけでディレクトリ構成を作り直す必要はなく、旧構成のままでも動きます。

Laravel Reverbによる自前WebSocketサーバー

11では、ファーストパーティのWebSocketサーバーであるLaravel Reverbが追加されました。php artisan reverb:startで起動し、Laravel Echoをはじめとする既存のイベントブロードキャスト機構とそのまま組み合わせられます。Redisのパブリッシュ／サブスクライブ機能による水平スケールにも対応しており、リアルタイム通信のために外部のホスティングサービスへ依存しない選択肢が本体側に用意された点が、11の実務上の変化として大きい部分です。

新規アプリの既定データベースのSQLite化

11で新規作成したアプリケーションは、データベースの既定がSQLiteになりました。セッション・キャッシュ・キューの各ドライバも既定がdatabaseです。追加のミドルウェアやサーバーを用意しなくても、作成直後から開発を始められるようにするための変更でした。裏を返せば、11以降に作られたプロジェクトを引き継いだときは、.envのデータベース設定が明示されているかを最初に確認しないと、意図せずSQLiteのまま本番に出る事故が起こり得ます。

/upヘルスルートと秒単位レート制限

11の新規アプリには/upのヘルスチェック用エンドポイントが定義されています。上のコードのwithRouting()にある'/up'がその指定で、Kubernetesなどのオーケストレーターや外部の死活監視サービスから叩くことを想定したものです。このルートにHTTPリクエストが届くとDiagnosingHealthイベントが発行されるため、依存サービスへの疎通確認など独自のチェックも追加できます。

レート制限は、それまで分単位の粒度しか扱えませんでした。11ではHTTPリクエストとキュージョブの双方で秒単位の指定が可能になっています。

<?php
RateLimiter::for('invoices', function (Request $request) {
    return Limit::perSecond(1);
});

暗号鍵の無停止ローテーションとパスワード自動再ハッシュ

Laravelはセッションクッキーを含むすべてのクッキーを暗号化するため、暗号鍵を入れ替えると全ユーザーがログアウトし、旧鍵で暗号化したデータも復号できなくなっていました。11ではAPP_PREVIOUS_KEYS環境変数に過去の鍵をカンマ区切りで並べておけます。暗号化には常にAPP_KEYの現行鍵を使い、復号は現行鍵で失敗した場合に過去の鍵を順に試すため、鍵の入れ替えでユーザーを追い出さずに済みます。

パスワードのハッシュも同様です。bcryptのワークファクタをconfig/hashing.phpやBCRYPT_ROUNDSで引き上げると、以降はユーザーが認証するたびに古いハッシュが自動で再ハッシュされます。計算コストの見直しを、利用者への影響なしに反映できるようになりました。

casts()・キューテスト・Artisanコマンドの追加

Eloquentのキャストは、プロパティではなくcasts()メソッドで定義できるようになりました。引数付きのキャストを書くときに記述が素直になります。

<?php
class Product extends Model
{
    protected function casts(): array
    {
        return [
            'options' => AsCollection::using(OptionCollection::class),
            'released_at' => 'datetime',
        ];
    }
}

キューのテストも書きやすくなりました。ジョブが解放・削除・失敗したことの検証には従来カスタムのフェイクやスタブが必要でしたが、11ではwithFakeQueueInteractions()を挟むだけで済みます。

<?php
$job = (new ProcessPodcast)->withFakeQueueInteractions();

$job->handle();

$job->assertReleased(delay: 30);

クラス生成系のArtisanコマンドとしてmake:class、make:enum、make:interface、make:traitが追加されました。スキーマ検査ではSchema::getTables()やSchema::getColumns()など、テーブル・ビュー・カラム・インデックス・外部キーを取得するネイティブメソッドが揃っています。テスト面では、:memory:のSQLiteを使う際にPDOオブジェクトを接続間で使い回すようになり、公式ドキュメントはテスト実行時間が半減する場合があると説明しています。データベースでは、MySQLドライバの流用ではなくMariaDB専用ドライバが用意された点も変更のひとつです。

Laravel 11の動作要件（PHPとデータベース）

対応PHPは8.2から8.4

Laravel 11.xが要求するPHPの最低バージョンは8.2で、サポート表に併記された対応範囲は8.2〜8.4です。実際、11系の最終リリースであるv11.55.0のcomposer定義でも、PHPの要求は^8.2のままになっています。稼働中のアプリがどの版で動いているかは、次のコマンドで確認できます。

# 稼働中のアプリが実際にどの版で動いているかを確認する
composer show laravel/framework | grep '^versions'
php artisan --version
php -v

対応データベース5種と必要バージョン（MySQL 5.7以上）

公式が一次サポートを明示しているデータベースと必要バージョンは次のとおりです。

移行を検討するうえで押さえておきたいのは、この必要バージョンの一覧が11系と13系の公式ドキュメントで完全に一致している点です。PHPの下限は13で8.3へ引き上げられた一方、データベース側の下限は動いていません。11で動いていたデータベースは13でもそのまま条件を満たします。なお、MongoDBはフレームワーク本体ではなくMongoDB社が保守するmongodb/laravel-mongodbパッケージ経由での対応です。

Laravel 11から12・13へ移行する順序と所要時間

メジャー1つずつの段階移行

公式のアップグレードガイドはメジャー単位で用意されており、11から13へ直接移す手順は存在しません。11→12、12→13の順に段階を踏みます。ガイドに記載された想定所要時間は11→12が5分、12→13が10分です。13は破壊的変更を抑えることに重点を置いた版で、公式ドキュメントも「多くのアプリはコードをほとんど変えずに移行できる」と説明しています。

# 1段階目：Laravel 11 から 12 へ（composer.json の require を書き換える）
composer require laravel/framework:^12.0 --update-with-all-dependencies
composer require --dev phpunit/phpunit:^11.0 --update-with-all-dependencies

# 2段階目：Laravel 12 から 13 へ（PHP 8.3 以上が前提）
composer require laravel/framework:^13.0 laravel/tinker:^3.0 --update-with-all-dependencies
composer require --dev phpunit/phpunit:^12.0 --update-with-all-dependencies

# Laravel Boost を入れている場合は同時に上げる（/upgrade-laravel-v13 に必要）
composer require laravel/boost:^2.0 --update-with-all-dependencies

テスト関連の依存も同時に上がります。12ではphpunit/phpunitが^11.0、pestphp/pestが^3.0、13ではそれぞれ^12.0と^4.0が要求されます。13ではlaravel/tinkerの^3.0への更新も必要です。11→12で発生する破壊的変更を影響度ごとに確認したい場合は、Laravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点に一覧をまとめています。

移行先の上限を決めるPHPの版

13.xが要求するPHPの最低バージョンは8.3です。PHP 8.2で運用しているなら、Laravelだけを13へ上げることはできません。12.xはPHP 8.2〜8.5に対応しているため、PHPを動かせない事情がある環境の現実的な着地点は12になります。逆にPHP 8.3以上へ上げられるなら、セキュリティ修正が2028年3月17日まで続く13まで進めたほうが、次の移行作業を先送りできます。順序としては、Laravelのメジャーを上げる前にPHPの版を確定させると手戻りが出ません。

エラーにならないまま挙動が変わる箇所

移行で厄介なのは、例外も警告も出ないまま動作だけが変わる変更です。11から12へ上げるときは、HasUuidsが返すUUIDのバージョン7化（従来の順序付きUUIDv4を続けるならHasVersion4Uuidsへ差し替え）、imageバリデーションが既定でSVGを弾く点、localディスクを明示していない場合にルートがstorage/appからstorage/app/privateへ変わる点の3つを先に確認してください。影響度を含む全体像はLaravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点にあります。

<?php
// Laravel 12以降、HasUuids が返すのは UUIDv7。
// 従来の順序付き UUIDv4 を維持したい場合は差し替える。
use Illuminate\Database\Eloquent\Concerns\HasVersion4Uuids as HasUuids;

12から13へ上げる際に高影響として挙げられているのは、CSRFミドルウェアの扱いです。VerifyCsrfTokenがPreventRequestForgeryへ改称され、Sec-Fetch-Siteヘッダーによるオリジン検証が加わりました。VerifyCsrfTokenとValidateCsrfTokenは非推奨のエイリアスとして残るものの、テストやルート定義でミドルウェアを除外している箇所は新しいクラス名へ直す必要があります。

13へのアップグレードはAIアシスタントに任せる経路も用意されており、laravel/boost ^2.0を導入すると/upgrade-laravel-v13コマンドで手順を進められます。Boost自体の位置づけはLaravel Boost 2.0とは？概要とできること｜Laravel開発にAIを統合する新ツールの全貌で解説しました。認証まわりのスターターキットを使っている場合は、Laravel Breeze・Jetstreamはなぜ非推奨に？スターターキット（React/Vue/Livewire）への移行と代替案も併せて確認してください。

よくある質問

Laravel 11のサポート期限はいつまでですか？

バグ修正は2025年9月3日、セキュリティ修正は2026年3月12日で提供が終了しています。公式のサポートポリシーは全リリース一律でバグ修正18か月・セキュリティ修正2年と定められており、11だけが延長される仕組みはありません。11.xブランチには2026年7月14日のv11.55.0までタグが打たれていますが、内容はLaravel Cloud向けキュー機能のバックポートで、セキュリティ修正ではありません。

Laravel 11のPHPバージョンは？

最低要件がPHP 8.2で、公式サポート表に記載された対応範囲は8.2〜8.4です。移行先を13にする場合はPHP 8.3以上が必須になるため、PHP 8.2のままなら12（対応範囲8.2〜8.5）が上限になります。

Laravel 11の次はどのバージョンを選べばよいですか？

PHP 8.3以上へ上げられるなら、2026年3月17日リリースの13系が第一候補です。バグ修正が2027年第3四半期まで、セキュリティ修正が2028年3月17日まで提供されるため、次の移行までの間隔を最も長く取れます。PHPを動かせない場合は12系が上限です。13で加わったAI SDKなどの内容はLaravel 13で正式安定版になったAI SDKの全体像と導入判断の前提知識、12系の要件はLaravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点にまとめています。

Laravel 11から13へ一気に上げられますか？

公式のアップグレードガイドはメジャー単位で提供されているため、11→12→13の順に段階を踏みます。ガイド記載の想定所要時間は11→12が5分、12→13が10分です。13はPHP 8.3以上を要求するので、Laravelを上げる前にPHPの版を確定させてください。

Laravel 11に留まる場合、何をすればよいですか？

2026年6月17日公開の2件の脆弱性は影響範囲に11系が含まれ、修正版は12系・13系にしか提供されていません。既定のemailバリデーションを使っているか、localディスクを'serve' => trueで公開してtemporaryUrl()を発行しているかを洗い出し、該当する場合は自前で回避策を実装するか、外部から到達できないよう遮断する対応が要ります。恒久策にはならないため、移行時期を決めたうえでの暫定措置として扱ってください。

関連記事

• Laravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点
• Laravel 13で正式安定版になったAI SDKの全体像と導入判断の前提知識
• Laravel Boost 2.0とは？概要とできること｜Laravel開発にAIを統合する新ツールの全貌
• Laravel Breeze・Jetstreamはなぜ非推奨に？スターターキット（React/Vue/Livewire）への移行と代替案