※本記事にはアフィリエイト広告が含まれます。
PHP 8.2のセキュリティサポートは、2026年12月31日で終わります。この記事を書いている2026年9月29日の時点で、残りは約3か月です。
移行先の候補は8.3・8.4・8.5の3つです。ただ、EOLの一覧を見ても「どれを選べばいいか」は決まりません。決め手になるのは、各バージョンで何が変わるか（非互換の変更と非推奨）と、使っているフレームワークがどのPHPに対応しているかです。
この記事では、php.netの移行ガイドとLaravelの公式ドキュメントをもとに、8.2から上げるときに当たる変更と、Laravelとの組み合わせごとの期限を整理します。記事中の日付・対応表は、すべて2026年9月29日時点の公式情報です。
結論：多くの場合は8.4、Laravel 13まで上げるなら8.4か8.5
先に結論をまとめます。確認日時点のセキュリティサポートの期限は、8.3が2027年12月31日、8.4が2028年12月31日、8.5が2029年12月31日です。
- 8.3：変更は小さいが、期限まで約1年3か月しかない。年末に間に合わせるための「つなぎ」なら選択肢になる
- 8.4：期限まで約2年3か月。Laravel 11〜13のどれでも対応していて、8.3より期限が1年長い。多くのシステムの第一候補になる
- 8.5：期限はいちばん長いが、非推奨がまとまって増える。Laravel 12か13で、依存ライブラリも8.5に対応している場合に向く
判断の軸は「サポート期限」「非互換の変更の量」「フレームワーク・ライブラリの対応」の3つです。以下、この順に公式情報を見ていきます。
PHPのサポート期限とポリシー（公式の表）
php.netのサポートポリシーでは、各ブランチは最初の安定版リリースから2年間「アクティブサポート」（バグとセキュリティ問題の修正）を受け、その後の2年間は重大なセキュリティ問題の修正だけを受けます。合計4年で終了です。
| バージョン | 初回リリース | アクティブサポート終了 | セキュリティサポート終了 |
|---|---|---|---|
| 8.2 | 2022-12-08 | 2024-12-31 | 2026-12-31 |
| 8.3 | 2023-11-23 | 2025-12-31 | 2027-12-31 |
| 8.4 | 2024-11-21 | 2026-12-31 | 2028-12-31 |
| 8.5 | 2025-11-20 | 2027-12-31 | 2029-12-31 |
8.2はすでに2024年末でアクティブサポートを終えていて、今はセキュリティ修正だけの期間です。その期間も2026年12月31日で終わります。なお、8.3もアクティブサポートは2025年末に終わっていて、8.4のアクティブサポートも8.2と同じ2026年12月31日に終わります。「バグ修正まで受けられる期間」を重視するなら、2027年以降もアクティブサポートが続くのは8.5だけです。
比較表：8.3/8.4/8.5で変わること（非互換の変更と非推奨）
8.2から8.5へ一気に上げる場合は、8.3・8.4・8.5の移行ガイドをすべて読む必要があります。業務コードで当たりやすいものを、バージョン順に抜き出しました。全項目は各移行ガイドを確認してください。
| バージョン | 種類 | 主な変更 |
|---|---|---|
| 8.3 | 非互換 | range()の引数チェックが厳しくなった（オブジェクト・リソース・配列を境界に渡すとTypeError、増加する範囲に負のstepでValueError など） |
| 8.3 | 非互換 | 空の配列に負のインデックス$nを代入すると、次のインデックスが0ではなく$n+1になる |
| 8.3 | 非互換 | number_format()の負のdecimalsが無視されず、小数点より上の桁で丸めるようになった |
| 8.3 | 非互換 | Date拡張が警告や汎用の例外ではなく、DateError・DateException系の専用例外を投げる |
| 8.4 | 非互換 | exit()/die()が関数に近い動きになり、不正な型を渡すとTypeError |
| 8.4 | 非互換 | E_STRICTのエラーレベルを削除（定数は非推奨） |
| 8.4 | 非互換 | JITのデフォルトがopcache.jit=disable・opcache.jit_buffer_size=64Mに変わった |
| 8.4 | 非推奨 | デフォルト値nullの引数で型を暗黙にnullableにする書き方 |
| 8.4 | 非推奨 | mysqli_ping()・mysqli_kill()・mysqli_refresh()、trigger_error()へのE_USER_ERROR |
| 8.5 | 非推奨 | (integer)・(boolean)・(double)・(binary)のキャスト名 |
| 8.5 | 非推奨 | shell_exec()の別名としてのバッククォート演算子 |
| 8.5 | 非推奨 | PDOクラスのドライバ固有の定数・メソッド（PDO::MYSQL_ATTR_*など。Pdo\Mysql等へ移行） |
| 8.5 | ソフト非推奨 | __sleep()・__wakeup()（__serialize()・__unserialize()へ） |
8.3：細かい関数の挙動の変更が中心
8.3の非互換の変更は、range()・number_format()・負の配列インデックスなど、特定の関数や書き方に限られます。日付処理でwarningを前提にしたエラー処理を書いている場合は、Date拡張の専用例外（DateError・DateException系）に変わった点を確認しておきます。
8.4：古いコードで当たりやすいのは「暗黙のnullable」
8.4で既存コードに広く当たりやすいのは、引数の暗黙のnullable型の非推奨です。移行ガイドには次の例が載っています（コメントは筆者が補足）。
// 8.4で非推奨
function foo(T1 $a = null) {}
// 明示的にnullableにする
function foo(T1|null $a = null) {}
// または
function foo(?T1 $a = null) {}もう1つ、JITの設定にも注意が必要です。8.4ではJITのデフォルトがopcache.jit=disable・opcache.jit_buffer_size=64Mに変わりました。デフォルトでJITが無効なことは変わりませんが、無効にしている設定がopcache.jit_buffer_sizeからopcache.jitに移っています。これまでopcache.jit_buffer_sizeだけでJITを有効にしていた環境は、opcache.jitの値も見直す必要があります。また、JITを有効にしていて初期化に失敗した場合、PHPは起動時に致命的エラーで終了するようになりました。
8.5：非推奨がまとまって増える
8.5では、非推奨の追加が目立ちます。キャスト名の(integer)や(boolean)、バッククォート演算子は、古いコードに残っていることがある書き方です。ほかにも、配列のオフセットにnullを使うこと、case文をセミコロンで終えること、$http_response_header変数（http_get_last_response_headers()へ）なども非推奨になりました。
非互換の変更としては、配列以外の値（null以外）を[]やlist()で分割代入すると警告が出るようになったこと、intで表せないfloatをintにキャストすると警告が出るようになったこと、disable_classesのINI設定が削除されたことなどがあります。
DBまわりで見落としやすいのが、PDOのドライバ固有の定数です。たとえばPDO::MYSQL_ATTR_USE_BUFFERED_QUERYはPdo\Mysql::ATTR_USE_BUFFERED_QUERYへの置き換えが案内されています。
Laravelを使っている場合の組み合わせ
Laravelの公式サポートポリシーでは、各リリースはバグ修正を18か月、セキュリティ修正を2年受けます。対応するPHPは次のとおりです。
| Laravel | 対応PHP | リリース | バグ修正終了 | セキュリティ修正終了 |
|---|---|---|---|---|
| 11 | 8.2〜8.4 | 2024-03-12 | 2025-09-03 | 2026-03-12 |
| 12 | 8.2〜8.5 | 2025-02-24 | 2026-08-13 | 2027-02-24 |
| 13 | 8.3〜8.5 | 2026-03-17 | 2027年第3四半期 | 2028-03-17 |
確認日時点で、Laravel 11はセキュリティ修正も終了し、Laravel 12はバグ修正が終わってセキュリティ修正だけの期間に入っています。Laravel 13は最低でもPHP 8.3が必要です。
組み合わせ別の期限
上の2つの表を重ねて、「PHPとLaravelのどちらかのセキュリティサポートが先に切れる日」を組み合わせごとに出しました。日付はphp.netとLaravelの公式の表の値で、どちらが早いかを比べたものです。
| 組み合わせ | 先に切れる日 | 先に切れる側 |
|---|---|---|
| Laravel 11 ＋ 8.3/8.4 | 2026-03-12（終了済み） | Laravel |
| Laravel 12 ＋ 8.3/8.4/8.5 | 2027-02-24 | Laravel |
| Laravel 13 ＋ 8.3 | 2027-12-31 | PHP |
| Laravel 13 ＋ 8.4 | 2028-03-17 | Laravel |
| Laravel 13 ＋ 8.5 | 2028-03-17 | Laravel |
Laravel 12を使い続ける限り、PHPをどれにしても期限は2027年2月24日で揃います。PHPの選択で期限に差が出るのは、Laravel 13に上げた場合です。
Laravel 13のドキュメントにある8.5向けの分岐
前の章で触れたPDO定数の非推奨は、Laravelの設定にも関係します。Laravel 13のデータベースのドキュメントにあるMySQL接続の設定例では、SSLのCA証明書を指定するoptionsが、PHP_VERSION_IDで分岐しています。
'options' => extension_loaded('pdo_mysql') ? array_filter([
(PHP_VERSION_ID >= 80500 ? \Pdo\Mysql::ATTR_SSL_CA : \PDO::MYSQL_ATTR_SSL_CA) => env('MYSQL_ATTR_SSL_CA'),
]) : [],PHP 8.5以上ではPdo\Mysql::ATTR_SSL_CAを、それ未満では従来のPDO::MYSQL_ATTR_SSL_CAを使う書き方です。古いバージョンのLaravelで作ったプロジェクトは、config/database.phpが作成時のまま残っていることがあります。8.5に上げる場合は、自分のプロジェクトのconfig/database.phpや、PDO::MYSQL_ATTR_*を直接書いている箇所を検索しておくと、非推奨の通知を事前に潰せます。
用途別のおすすめ
Laravel 11以前のまま動かしているシステム
Laravel 11はセキュリティ修正が2026年3月12日に終わっています。PHPだけ上げてもフレームワーク側の修正は受けられないので、まずLaravelのバージョンアップを計画に入れる必要があります。年内にLaravelまで上げきれない場合でも、Laravel 11が対応する8.4まではPHPを上げられます。
Laravel 12を当面続けるシステム
8.4がおすすめです。Laravel 12のセキュリティ修正が2027年2月24日に終わるため、PHPを8.5にしても期限は延びません。非推奨の対応が少ない8.4で年末を越え、Laravel 13への移行を2027年2月までに進める、という段取りが現実的です。8.4はLaravel 13でも使えるので、Laravel 13に上げるときにPHPを変えずに済みます。
Laravel 13へ上げるシステム
8.4か8.5です。Laravel 13との組み合わせでは、どちらも期限はLaravel 13のセキュリティ修正終了（2028年3月17日）で揃います。8.3はPHP側が2027年末に切れるので、あえて選ぶ理由は小さいです。8.5を選ぶなら、Composerで入れている依存ライブラリが8.5に対応しているか、8.5の非推奨にどれだけ当たるかを先に確認します。
SES案件に参画するときも、参画先のPHPとフレームワークのバージョンは事前に聞いておきたい項目です。案件選びの基準全般は、PHPエンジニアが失敗しないSES案件の選び方にまとめています。
よくある誤解
「非推奨＝すぐ動かなくなる」ではない
非推奨（deprecated）と削除は別物です。php.netの説明では、E_DEPRECATEDは「将来のバージョンで動かなくなるコード」についての実行時の通知です。つまり非推奨になった時点では動きますが、将来のバージョンで削除される可能性がある、という扱いです。一方で、8.4のE_STRICTのように「エラーレベル自体が削除された」ものは、そのバージョンから挙動が変わります。移行ガイドでは、非推奨（deprecated）と非互換の変更（incompatible）が別のページに分かれているので、両方を読みます。
とはいえ、本番のログにE_DEPRECATEDが大量に出る状態は、次の移行を重くします。上げたバージョンで出た非推奨の通知は、その都度潰しておくのが安全です。
OSのパッケージのPHPは期限が違う場合がある
この記事の期限は、php.netが公開しているPHP本体のサポート期限です。Linuxディストリビューションのパッケージとして入れたPHPは、ディストリビューション側が独自にサポート期間を決めている場合があります。サーバーのOSのパッケージを使っているなら、そのディストリビューションの公式情報も確認してください。
まとめ
移行先の決め方を3行でまとめます。
- PHP 8.2のセキュリティサポートは2026年12月31日で終わる。移行先の期限は8.3が2027年末、8.4が2028年末、8.5が2029年末
- Laravelを使っているなら、Laravel側のサポート期限と重ねて考える。Laravel 12なら8.4、Laravel 13なら8.4か8.5
- 8.2から上げるときは、8.3・8.4・8.5の移行ガイド（非互換の変更と非推奨）を順に読み、暗黙のnullable・JITの設定・PDO定数などを検索しておく
移行ガイドは英語で項目も多いので、言語仕様やLaravelの仕組みを体系的に押さえておくと読み進めやすくなります。手元に1冊、PHPやLaravelの解説書を置いておくのも一つの方法です。
普段Amazonを使っている方は、こちらからも探せます。書籍を選ぶときは、対象のPHP・Laravelのバージョンを確認してください。
PHPに加えてAWSのスキルを持つとフリーランスの単価がどう変わるかは、PHPエンジニアがAWSも取ったらフリーランス単価はどう変わるかにまとめています。
