PHP 8.2のサポート終了にどう備える？8.4への移行手順・所要期間と、年内に間に合わない場合の選択肢【2026年版】
PHP 8.2のセキュリティサポートは、2026年12月31日に終わります。 10月21日には、深刻な脆弱性2件を修正した8.2.35が出ました。年が明けてから同じような脆弱性が見つかっても、8.2向けの修正は開発元から出ません。
7.4や8.1のサポート終了に合わせて8.2へ上げた会社では、まだ先の話だと思っていたかもしれません。ただし、Amazon Linux 2023なら開発元と同じ12月31日に終わり、RHELなら2029年まで修正が続くなど、いつまで使えるかは環境によって変わります。
本記事では、PHP 8.2の期限と環境ごとの違い、移行先を8.4にする理由、8.2から8.4で変わる点と移行手順、12月31日に間に合わない場合の選択肢を、情シス担当者向けに整理します。
想定読者
本記事は、次のような方を想定しています。
- PHP 8.2で動く業務システムやWebサービスを運用している情シス担当者
- AWS（Amazon Linux 2023・Elastic Beanstalk）でPHP 8.2を使っている方
- 10月の脆弱性で8.2.35に上げたが、次にどこまで上げればよいか迷っている方
- PHPのバージョンアップを保守会社に頼みたいが、作業の中身と期間の見当をつけたい方
PHP 8.2のサポートは2026年12月31日に終わる
バージョン別のサポート期限
PHPの各系統は、最初のリリースから2年間のアクティブサポート（不具合とセキュリティの修正）と、その後2年間のセキュリティサポート（重大なセキュリティ問題だけの修正）を受けます。8.2はすでにセキュリティサポートの期間に入っていて、それが12月31日に終わります。
| 系統 | 初回リリース | アクティブサポート | セキュリティサポート |
|---|---|---|---|
| PHP 8.2 | 2022年12月 | 2024年12月31日で終了 | 2026年12月31日 |
| PHP 8.3 | 2023年11月 | 2025年12月31日で終了 | 2027年12月31日 |
| PHP 8.4 | 2024年11月 | 2026年12月31日 | 2028年12月31日 |
| PHP 8.5 | 2025年11月 | 2027年12月31日 | 2029年12月31日 |
1月1日に止まるわけではない
サポートが終わっても、PHP 8.2で動くシステムが1月1日に止まることはありません。止まるのは開発元からの修正です。10月のような脆弱性が来年見つかれば、8.2には修正版が出ず、攻撃を防ぐ手段がなくなります。
10月の脆弱性では、サポートが終わっていた7.4・8.0・8.1にも、例外として最小限の修正がソースコードで公開されました。ただし、開発元はこれを深刻度が高いための特別な措置と説明しています。次も同じ対応があるとは限りません。
使っている環境によって、8.2の期限は変わる
OSのパッケージやクラウドのサービスでPHPを使っている場合は、開発元ではなく、そのOSやサービスの提供元が修正を出します。期限はそれぞれ違います。
| 環境 | PHP 8.2の修正が続く期限 | 備考 |
|---|---|---|
| Amazon Linux 2023（php8.2） | 2026年12月31日 | 開発元と同じ日。php8.4は2028年12月31日まで |
| AWS Elastic Beanstalk（PHP 8.2 AL2023） | 2027年3月31日にプラットフォーム引退 | PHP本体の更新の扱いはAWSの告知で確認 |
| Google App Engine（php82） | 2026年12月31日にサポート終了 | 2027年12月31日に非推奨 |
| Azure App Service | 開発元の期限に従う方針 | 8.2の個別の日付は未公表 |
| RHEL 8・RHEL 9（php 8.2） | 2029年5月 | Red Hatが修正を続ける。RHEL 10には8.2がない |
| Debian 12（php8.2） | 2028年6月30日（LTS） | 通常のセキュリティサポートは2026年6月に終了済み |
| Ubuntu LTS | 該当なし | 22.04は8.1、24.04は8.3を収録 |
AWSのEC2で標準的に使われるAmazon Linux 2023には、延長がありません。EC2上で8.2を使っているなら、12月31日を期限として動く必要があります。
期限が延びる環境でも、周りの部品は先に止まる
RHELやDebianでは、PHP本体の修正は2028〜2029年まで続きます。ただし、修正が続くのはPHP本体だけです。LaravelやSymfonyなどのフレームワーク、Composerで入れているライブラリは、開発元のサポート期限に合わせて8.2への対応を打ち切っていきます。
たとえばLaravel 12は8.2〜8.5で動きますが、次のLaravel 13は8.3以上が必要です。WordPressも、推奨するPHPを8.3以上としています。OSの期限が延びても、アプリの部品を新しくできない状態が続くと、そちらから脆弱性が残ります。
移行先は8.4を基本にする
8.2からの移行先は、8.3・8.4・8.5の3つです。c3indexでは、次の理由から8.4を基本と考えています。
- 8.3はすぐに次の期限が来る：セキュリティサポートは2027年12月31日まで。上げてから約1年で、また移行を考えることになる
- 8.4は期限と安定のバランスがよい：2028年12月31日まで使え、公開から約2年たっているので、主要なフレームワークやライブラリの対応が進んでいる
- 8.5は依存関係の確認が先：期限は最も長い（2029年12月31日）が、使っているライブラリがすべて対応しているかを先に確かめる。Amazon Linux 2023のphp8.5はOSの期限に合わせて2029年6月30日まで
使っているフレームワークとライブラリが8.5に対応していれば、8.5まで上げるのも選択肢です。
8.2から8.4で変わる主な点
8.2から8.4への移行は、7系から8系への移行ほど大きな変化はありません。それでも、開発元の移行ガイドには次のような変更が載っています。
- 日付処理の例外（8.3）：Date拡張の一部が、警告ではなく専用の例外やエラーを出すようになった
- 関数の引数チェック（8.3〜8.4）：
range()に配列などを渡すと TypeError、round()に不正なモードを渡すと ValueError になる - E_STRICTの削除（8.4）：エラーレベル E_STRICT が削除され、定数も非推奨になった
- resourceからオブジェクトへの移行（8.4）：DBA・ODBC・SOAPなどで、
is_resource()による戻り値の確認が使えなくなった - MySQLの接続タイムアウトのエラーコード（8.4）：2006から4031に変わった。エラーコードで再接続を判断している処理は要確認
8.4で非推奨になった書き方
非推奨の書き方は、8.4でも動きますが、警告が出ます。次の版で削除されることもあるので、移行のついでに直しておきます。業務システムで特に多いのは次のものです。
- 暗黙のnullable型：
function foo(T $a = null)のような書き方は非推奨になり、?T $a = nullと書く必要がある。古いコードやライブラリに広く残っている mysqli_ping()の非推奨trigger_error()に E_USER_ERROR を渡す書き方の非推奨- セッション関連の一部の設定（
session.sid_lengthなど）の変更の非推奨
PHP 8.2から8.4への移行手順
ステップ1：対象システムを棚卸しする
まず、社内のどのサーバーでPHP 8.2が動いているかを一覧にします。サーバーごとに、PHPのバージョン、動かし方（PHP-FPMやmod_phpなど）、フレームワークとその版、外部に公開しているかどうかを書き出します。保守会社に任せているサーバーも含めてください。
ステップ2：依存パッケージの対応状況を確認する
Composerを使っている場合は、composer.json と composer.lock を見て、各ライブラリが8.4に対応しているかを調べます。次のコマンドで、8.4への更新を妨げているパッケージを洗い出せます。
composer why-not php 8.4対応していないライブラリは、新しい版へ更新するか、代わりのライブラリを探します。フレームワークの版を上げる必要がある場合は、その作業も計画に入れます。
ステップ3：テスト環境で8.4を動かす
本番と同じ構成のテスト環境を用意し、PHPだけを8.4に替えて動かします。エラー表示をすべて出す設定（E_ALL）にして、ログに出る非推奨の警告とエラーを集めます。AWSなら、本番のサーバーをもとに検証用の環境を作れるので、本番に影響を出さずに確かめられます。
ステップ4：コードを直して、業務の流れを確かめる
集めたエラーと警告をもとに、コードを直します。PHP_CodeSnifferのPHPCompatibilityやRectorといったツールを使うと、互換性の問題の洗い出しや機械的な書き換えを効率化できます。直したら、画面の操作、帳票の出力、外部システムとの連携、夜間のバッチ処理など、業務の流れに沿って動きを確かめます。
ステップ5：本番を切り替える
切り替えは、利用の少ない時間帯に行います。新しい環境を横に作って切り替える方式にすれば、問題が出たときにすぐ元に戻せます。切り替え後しばらくは、エラーログと処理時間を注意して見ます。
移行にかかる期間の目安
期間は、システムの規模とテストのしくみで変わります。c3indexの見立てでは、次のくらいを目安にしてください。
| システムの状態 | 期間の目安 |
|---|---|
| 小規模（画面が少ない）、フレームワークの版はそのまま | 2〜4週間 |
| 中規模の業務システム、ライブラリの更新が必要 | 1〜3か月 |
| 自動テストがない、仕様がわかる人がいない、フレームワークの版も上げる | 3か月以上 |
今が10月下旬なので、12月31日までは約2か月です。中規模以上のシステムでは、年内にすべてを終えるのは難しいかもしれません。その場合は、次の章の選択肢を組み合わせます。
12月31日に間に合わない場合の選択肢
外部に公開しているシステムから移行する
すべてのシステムを年内に移すのが難しければ、優先順位をつけます。最初に移すのは、インターネットに公開しているシステムです。10月の脆弱性は、ログインなしで外部から攻撃できるものでした。社内だけで使うシステムは、その次にします。
修正が続く環境を一時的に使う
RHELやDebianのように、PHP 8.2の修正を続けるOSもあります。また、サポートの終わったPHPに有償で修正を提供するベンダーもあります。ただし、OSの乗り換え自体に手間がかかり、フレームワークやライブラリの問題も残ります。8.4へ移るまでのつなぎとして考えてください。
移行が終わるまで、リスクを下げる運用で補う
移行までの間は、次の対策を重ねます。
- 社内向けのシステムは、インターネットから直接アクセスできないようにする（VPNの内側に置く、接続元のIPアドレスを制限する）
- WAF（Webアプリケーションへの攻撃を手前で止めるしくみ）を入れる
- 開発元やOSの提供元のセキュリティ情報を定期的に確認し、深刻な脆弱性が出たら公開を止める判断の手順を決めておく
- 脆弱性診断で、外からどう見えているかを確かめる
7系や古いフレームワークが残っているなら、作り直しも比べる
棚卸しの途中で、PHP 7系やCakePHP 2.x・3.xなど、さらに古いシステムが見つかることがあります。こうしたシステムは、8.4へ上げる作業が作り直しに近い規模になります。延命と作り直しの費用と期間を並べて、方針を決めてください。
よくある質問
Q. 12月31日を過ぎると、PHP 8.2で作ったシステムは動かなくなりますか？
動き続けます。止まるのは開発元からのセキュリティ修正です。ただし、年明け以降に見つかった脆弱性は修正されないため、外部に公開しているシステムほどリスクが高くなります。
Q. 8.3に上げれば十分ですか？
8.3のセキュリティサポートは2027年12月31日までなので、約1年で次の移行が必要になります。手間を考えると、8.4まで上げるほうが次の移行までの期間を長く取れます。
Q. Amazon Linux 2023のEC2で8.2を使っています。何をすればよいですか？
Amazon Linux 2023では、php8.2パッケージの更新は12月31日で止まります。同じOSの上で php8.4 のパッケージを使えるので、テスト環境で8.4に替えて動作を確かめ、本番を切り替えます。OSそのものの期限（2029年6月）は別に管理してください。
Q. RHEL 9なので、PHP 8.2は2029年まで使えますか？
PHP本体の修正は、Red Hatが2029年5月まで続けます。ただし、フレームワークやComposerのライブラリは、開発元の期限に合わせて8.2への対応を終えていきます。アプリ側の部品を新しくできるうちに、8.4へ移る計画を立ててください。
Q. 保守会社に頼む場合、何を用意すればよいですか？
ソースコードの最新版、サーバーへのアクセス手段、使っているフレームワークとライブラリの一覧（composer.json）、画面や帳票の一覧があると、見積もりと作業が早く進みます。仕様書がなくても、ソースコードとサーバーがあれば調査はできます。
まとめ
本記事のポイントをまとめます。
- PHP 8.2のセキュリティサポートは2026年12月31日に終わる。システムは動き続けるが、年明け以降の脆弱性には開発元の修正が出ない
- 期限は環境で変わる。Amazon Linux 2023とGoogle App Engineは同じ12月31日、Elastic Beanstalkは2027年3月にプラットフォーム引退、RHEL 8・9は2029年5月、Debian 12はLTSで2028年6月まで
- OSの期限が延びても、フレームワークやライブラリは先に8.2への対応を終える
- 移行先は8.4が基本。8.3は約1年で期限が来る。8.5は依存関係の対応を確かめてから
- 移行は、棚卸し、依存パッケージの確認、テスト環境での検証、修正と業務の確認、本番切り替えの順に進める
- 年内に間に合わなければ、公開しているシステムから移し、それまでは公開範囲の制限やWAFで守る
12月31日まで約2か月です。まずは社内でPHP 8.2が動いているサーバーを一覧にし、どれから移すかを決めてください。
PHPのバージョンアップ・システム保守のご相談はc3indexへ
c3index は、製造業・中堅企業の情シスを支援するシステム会社です。PHPやフレームワークのバージョンアップ、他社が作ったシステムの調査と引き継ぎ、AWS上での検証環境の用意と本番の切り替え、移行後の保守まで、一貫して支援しています。「どのシステムから、どこまで上げるべきか」の整理からお手伝いします。名古屋・東京・福岡の3拠点体制で対応しています。まずはお気軽にご相談ください。
