PHP 8.2 のサポート終了（2026年12月31日）までにやること：移る版の選び方、バージョンアップの手順と確かめ方

PHP 8.2 のセキュリティの修正は、2026年12月31日で終わります（PHP のサポート期間）。この記事を公開した11月11日から数えると、残りは約7週間です。

10月には、PHP に重大な脆弱性が2件見つかり、国内の多くのサービスが予定外のメンテナンスに入りました。このとき、PHP からは 8.5・8.4・8.3・8.2 の修正版が出ましたが、すでにサポートが終わっていた 8.1 以前には出ていません（くわしくは「PHPの重大な脆弱性はその後どうなったか」）。年が明けると、8.2 もこの「直してもらえない側」に入ります。

この記事は、PHP 8.2 で動くサイトや業務システムを持つ会社の、システムの担当者や情報システムの担当者に向けて書いています。次のことを順にまとめます。

• サポートが終わると、何が起きて、何が起きないか
• 最初の1週間でやること：どこで 8.2 が動いているかを洗い出す
• 移る版の選び方：8.3・8.4・8.5、そして 11月に出る 8.6
• 使っている製品の対応：WordPress・Laravel・EC-CUBE
• 12月31日から逆算した進め方
• バージョンアップの手順と、手順ごとの確かめ方
• 期限に間に合わないときの考え方

事実は、PHP の公式サイトと、各製品・各 OS の公式の資料で確かめ、本文にリンクしています。期限や対応の版は変わることがあるため、2026年11月11日時点の内容です。

サポートが終わると、何が起きて、何が起きないか

起きないこと：サイトは止まらない

最初に誤解を解いておきます。12月31日を過ぎても、PHP 8.2 で動くサイトやシステムは、そのまま動き続けます。PHP の開発チームが遠くからプログラムを止めるわけではありませんし、見た目も変わりません。だからこそ、後回しにされやすい作業です。

起きること：新しく見つかった脆弱性が、直らなくなる

PHP の公式サイトは、サポートの状態を3つに分けています。不具合とセキュリティの両方を直す「アクティブサポート」、重大なセキュリティの問題だけを直す「セキュリティサポート」、何も直さない「サポート終了（End of life）」です。サポートが終わった版について、公式サイトは「できるだけ早く上げるべきで、直っていない脆弱性にさらされるおそれがある」と書いています（PHP のサポート期間）。

10月の脆弱性は、まさにこの差が出た例でした。修正版が出た版を使っていた会社は、更新すれば終わりました。8.1 以前を使っていた会社は、米国の CISA から「更新できるまで、PHP で動くシステムをオフラインにする」よう求められる立場に置かれました（CISA）。

2026年11月11日時点の、各版の期限

PHP は、2024年に決めたルールで、新しい版を出してから2年間は不具合も直し、そのあと2年間はセキュリティだけを直します。期限はどちらも、その年の12月31日にそろえます（PHP の RFC：Release cycle update）。

出典：PHP のサポート期間、PHP 8.6 の日程

見落としやすいのが 8.4 です。8.4 は、不具合の修正が 8.2 と同じ12月31日で終わります。年明けからは、セキュリティの修正だけが続きます。8.4 に移っても危なくはありませんが、「最新の不具合の修正まで受けたい」なら 8.5 の方が長く安心できます。

最初の1週間でやること：どこで 8.2 が動いているかを洗い出す

バージョンアップの相談を受けたとき、作業が遅れる原因の多くは、コードの直しよりも前の「どこで動いているかが分からない」です。最初の1週間は、ここに使います。

PHP が動いている場所を、全部書き出す

本番のサーバーだけを見て終わりにしないことが大切です。次の場所を一つずつ確かめ、表にします。

• 本番の Web サーバー（台数が複数あれば全部）
• テスト用・検証用のサーバー
• 夜間の集計やメール送信など、画面のない処理を動かすサーバー
• コンテナを使っている場合は、その元になるイメージに書いてある PHP の版
• 自動テストやデプロイの仕組みの中で使っている PHP の版
• 開発者のパソコンの中の開発環境
• レンタルサーバーなら、ドメインごとの PHP の設定

同じサーバーの中でも、画面を出す PHP と、コマンドで動かす PHP の版が違うことがあります。コマンドの php -v だけで判断せず、画面側は管理画面や phpinfo() の表示（確かめたら必ず消す）でも確かめます。

PHP を「どこから入れたか」も書く

表には、版の番号だけでなく、PHP の入れ方も書きます。これで、期限が本当に12月31日なのかが変わるからです。

• OS の標準のパッケージ：OS の会社が、PHP の公式の期限を過ぎても修正を出し続けることがあります（くわしくは後の「間に合わないとき」の節）。
• それ以外：公式のソースから自分で作ったもの、OS とは別の配布元のパッケージ、コンテナの公式イメージなど。PHP の公式の期限で修正が止まる前提で計画するのが安全です。
• レンタルサーバー：サーバー会社が用意した PHP を使います。8.2 をいつまで選べるか、修正をどう当てるかは、サーバー会社の案内で確かめます。10月の脆弱性では、多くのサーバー会社が版の番号を変えずに修正を当てていました。

洗い出しの表の例

この例では、バッチ用のサーバーだけ修正が当たっていない古い 8.2 のまま、という状態も見つかります。洗い出しは、期限の対応だけでなく、10月の脆弱性の修正が漏れていないかの確認にもなります。PHP に限らず、動いているソフトと版の一覧を作っておく意味は、「PHPの重大な脆弱性はその後どうなったか」の「平時に決めておく5つのこと」にも書いています。

移る版の選び方：8.3・8.4・8.5、そして 8.6

基本は「使っている製品が対応している中で、一番新しい版」

PHP の版を上げる作業は、PHP だけでは決まりません。WordPress やフレームワーク、使っているライブラリが、移る先の版に対応している必要があります。そのため、選び方の基本は次のとおりです。

1. 使っている CMS・フレームワーク・主なライブラリが、公式に対応している版を調べる
2. その中で、一番新しい版を選ぶ
3. 一番新しい版に上げられない理由があれば、それを書き残し、次に上げる時期を決める

8.3 は「1年しのぐ」選択になる

8.3 のセキュリティの修正は2027年12月31日までです。8.2 から 8.3 は変更が比較的小さいため、作業は軽めですが、1年後にまた同じ作業が要ります。製品の都合で 8.3 までしか上げられない場合の選択と考えます。

8.4 と 8.5 の違い

8.4 はセキュリティの修正が2028年末まで、8.5 は2029年末までです。8.2 から上げるなら、どちらも 8.3 と 8.4 の変更をまたぐことになり、確かめる量は大きくは変わりません。製品が 8.5 に対応しているなら、8.5 を選ぶと、次の作業までの時間を1年長く取れます。

11月19日に出る 8.6 は、年内の移行先には向かない

PHP 8.6.0 は、11月19日に公開される予定です（PHP 8.6 の日程）。先のルールどおりなら、もっとも長く使える版になります。ただし、出たばかりの版は、ライブラリや CMS の対応が追いつくまで時間がかかります。12月末の期限に間に合わせる移行先にすると、対応待ちで止まる危険が大きくなります。年内は 8.4 か 8.5 に移り、8.6 は来年、対応がそろってから検討するのが現実的です。

どれくらい変わるのか：公式の「後方互換性のない変更」

各版で何が変わったかは、PHP の公式マニュアルの移行ガイドに「後方互換性のない変更」としてまとまっています（8.3、8.4、8.5）。業務システムで影響が出やすいのは、たとえば次の点です。

• 8.3：日付を扱う機能で、問題があったときに警告ではなく専用の例外が出るようになった。日付の処理でエラーの扱いを確かめる必要がある。
• 8.4：IMAP、OCI8、PDO_OCI、PSpell の4つの拡張機能が、PHP の本体から外れた（8.4 で外れた拡張機能）。メールの受信を IMAP で処理している仕組みや、Oracle のデータベースにつないでいる仕組みは、別に入れる手配が要る。
• 8.4：引数の初期値を null にして、型に null を書かない書き方が「非推奨」になった（8.4 の非推奨）。すぐに動かなくなるわけではないが、ログに警告が大量に出ることがある。
• 8.4：エラーの種類の一つ E_STRICT が廃止され、この定数も非推奨になった。古いフレームワークや、エラーの表示の設定で E_STRICT を使っているコードは、警告が出るようになる。
• 8.5：比べられないオブジェクトと真偽値を比べたときの動きがそろえられた、など細かな変更。

コードの直し方の細かい話は、別の記事で扱います。ここで押さえたいのは、「何が変わるか」は公式に一覧があり、道具で機械的に探せる部分も多いということです。

使っている製品の対応：WordPress・Laravel・EC-CUBE

WordPress：本体は 8.5 まで対応。テーマとプラグインは別に確かめる

WordPress の公式の対応表では、WordPress 6.9・7.0・7.1 は、PHP 8.5 まで対応しています（WordPress と PHP の対応表）。WordPress は、PHP 8.3 以上のサーバーを推奨しています（WordPress の動作環境）。

注意したいのは、この表は本体だけの話だという点です。WordPress の開発チーム自身が、WordPress は本体だけで使われることはまずなく、テーマやプラグインと組み合わせて使われると書いています。古いプラグインや、作った会社が更新をやめたテーマは、新しい PHP で動かないことがあります。WordPress のサイトを今後どう持つかを考えるなら、「WordPressのサイトを EmDash に移すべきか」も参考になります。

Laravel：11 を使っているなら、Laravel ごと上げる

Laravel は、版ごとに対応する PHP と、修正の期限を公開しています（Laravel のサポート方針）。

Laravel 11 で動いているシステムは、PHP を上げる前から、フレームワークの修正がすでに止まっています。PHP だけ 8.4 に上げても、Laravel 側の問題は残ります。PHP と Laravel を一緒に上げる計画にした方が、作業を2回に分けるより結果として軽く済むことが多いです。

EC-CUBE：4.3 は公式の対応が 8.3 まで

国内のネットショップで多く使われている EC-CUBE は、4.3 のシステム要件で、PHP 8.1〜8.3 を対応としています（EC-CUBE 4 のシステム要件）。PHP 8.2〜8.5 に対応する 4.4 は、2026年9月25日にアルファ版が出た段階です（EC-CUBE のリリース）。

EC-CUBE 4.3 のサイトは、年内は 8.3 に上げるのが公式の範囲に収まる選び方です。8.3 の期限は2027年末なので、4.4 の正式版が出たあとの移行を、来年の予定と予算に入れておきます。

依存しているライブラリは、Composer で調べられる

Composer でライブラリを管理しているなら、composer prohibits php 8.4（why-not も同じ）で、PHP 8.4 に上げるのを妨げているライブラリを一覧にできます（Composer のドキュメント）。上げる前の見積もりの材料として、最初に流しておくと便利です。

あわせて、Composer の設定ファイルも確かめます。設定の platform に PHP の版が書いてあると、Composer は実際のサーバーの版ではなく、そこに書いた版を前提にライブラリを選びます（Composer の設定）。本番とそろえるための便利な設定ですが、PHP を上げたあとに書き換え忘れると、古い版を前提にしたライブラリが入り続けます。アプリ側が求める PHP の版（require の php）とあわせて、移る先の版に書き換える作業を、手順の中に入れておきます。

社内の決裁で説明する材料

バージョンアップには費用がかかります。見た目が何も変わらない作業に予算を通すには、「やらないと何が起きるか」を具体的に説明する必要があります。決裁の資料には、次の3つを書くと伝わりやすくなります。

1. 期限は外の都合で決まっていて、動かせない。12月31日は PHP の開発チームが決めた日付で、自社や保守会社の都合では延ばせません。
2. 期限を過ぎたあとの危険は、実際に起きた。2026年10月の重大な脆弱性では、サポートが終わった版に修正版が出ず、CISA は更新できるまでシステムをオフラインにするよう求めました。同じことが来年 8.2 で起きたとき、取れる手が「止める」しかなくなります。
3. 今回の作業は、次の期限でも使える。洗い出しの表と確かめる項目の表は、次に版を上げるときにそのまま使えます。1回目に作っておけば、2回目からの費用は下げられます。

費用の大きさは、システムの数、フレームワークの古さ、自動のテストの有無で大きく変わります。洗い出しと composer prohibits の結果があれば、保守会社も見積もりを出しやすくなります。

12月31日から逆算した進め方

11月11日から12月31日までは約7週間です。ただし、12月の終わりは年末の休みや、取引先の締めの作業と重なります。切り替えたあとに問題が出たとき、すぐに直せる人がそろっている時期に本番を切り替えたいので、本番の切り替えは12月の中旬までに終える計画をおすすめします。

システムが複数あるなら、インターネットから見えるもの（会社のサイト、会員サイト、問い合わせのフォームなど）を先にします。社内からしか使えない仕組みは、外からの攻撃を受けにくいぶん、優先度を下げられます。

バージョンアップの手順と、手順ごとの確かめ方

1. 検証用の環境を、本番とそろえて作る

本番と同じ OS、同じ拡張機能、同じ設定で、新しい版の PHP の環境を作ります。拡張機能の一覧は、今の本番で php -m を実行すると出せます。8.4 以降に上げる場合は、先に書いた IMAP などの4つが一覧にないかを、ここで確かめます。

2. 道具で、直す場所を探す

人の目でコードを全部読むのは現実的ではありません。次のような道具で、直す候補を機械的に出します。

• PHPCompatibility：コードを読んで、指定した版で使えなくなる書き方や、非推奨の書き方を見つけます。testVersion に移る先の版を指定して使います（PHPCompatibility）。
• Rector：古い書き方を、新しい版の書き方に自動で書き換える道具です。PHP 5.3 から 8.5 までの書き換えに対応しています（Rector）。

道具が見つけるのは「書き方の問題」です。動いたときの結果が変わる問題は、次の確かめ方で見つけます。

3. 非推奨の警告を、ログに出して読む

検証用の環境では、非推奨の警告（Deprecated）もログに出す設定にします。本番では出していないことが多い警告ですが、次の版で動かなくなる場所の目印になります。画面を一通り操作し、夜間の処理も動かしてから、ログに出た警告を種類ごとに数えます。

4. 業務の流れを、通しで確かめる

自動のテストがあれば、まず全部を流します。そのうえで、テストがない部分を人が確かめます。業務システムでよく漏れるのは、次のような「ふだん目にしない処理」です。

• ログイン、ログアウト、パスワードの再設定
• 問い合わせや申込のフォームの送信と、届くメール
• CSV や PDF の出力と、取り込み
• 決済、外部のサービスとの連携
• 夜間の集計、定期的に送るメール
• 管理画面の検索と、一覧の並び替え

確かめる項目は表にして、誰がいつ確かめたかを書き込みます。この表は、次に版を上げるときにもそのまま使えます。

5. 本番を切り替える前に、元に戻す手順を確かめる

切り替える前に、データベースとファイルのバックアップを取り、元の版に戻す手順を実際に試しておきます。レンタルサーバーなら管理画面で版を戻せるか、自社のサーバーなら古い版をすぐに起動できる状態で残しておけるか、を確かめます。切り替えは、アクセスの少ない時間を選び、担当者がそろっている平日に行います。

6. 切り替えたあと、1週間はログを見る

切り替えた直後に問題がなくても、月に一度の処理や、特定の操作をしたときにだけ出る問題があります。1週間はエラーのログを毎日見て、問題がなければ、洗い出しの表の版を書き換えます。表には「次の期限」の列も足し、新しい版の期限の半年前に、予定表へ入れておきます。

期限に間に合わないときの考え方

まず、本当の期限を確かめる

洗い出しで「OS の標準のパッケージ」だった場合、OS の会社が修正を出し続けることがあります。

• Red Hat Enterprise Linux：Red Hat は、RHEL 9 と RHEL 8 の PHP 8.2 を、2029年5月まで扱うとしています（Red Hat：Application Streams のライフサイクル）。
• Debian 12：標準の PHP は 8.2 です。Debian 12 の通常のサポートは2026年7月11日に終わり、2028年6月30日までは LTS（長期サポート）が続きます（Debian 12 の案内）。11月11日時点で、Debian 12 の php8.2 には10月の脆弱性の修正（8.2.35）が配られています（Debian のセキュリティ追跡）。LTS で個々のパッケージがいつまで直されるかは、Debian の案内で確かめてください。

この場合、期限は12月31日ではなくなります。ただし、OS の会社が直すのはセキュリティの問題で、新しい CMS やライブラリが 8.2 に対応し続けるわけではありません。時間に余裕ができたと考え、移行の計画は続けます。

間に合わない場合は、日付と理由と守り方を書面に残す

どうしても年内に終わらない場合は、黙って年を越さず、次の3つを書面に残します。

1. いつまでに移るか：新しい期限の日付と、担当者。
2. なぜ間に合わないか：製品の対応待ち、予算の承認待ち、など。
3. それまでの守り方：管理画面にアクセスできる場所を社内やVPNに限る、使っていない画面や機能を止める、WAF（Web アプリケーションの攻撃を防ぐ仕組み）を入れる、など。

これらは、攻撃を受ける入口を減らす手当てで、修正版の代わりにはなりません。10月の脆弱性のときに PHP の公式も、暫定の設定は「インストールを安全にするものではない」と書いていました。守り方は「移るまでのつなぎ」と位置づけます。

古すぎて上げられないなら、作り直しも比べる

フレームワークの版が古く、PHP だけでなく、フレームワークもライブラリもまとめて上げないと動かない、という場合があります。このときは、版を上げる費用と、作り直す費用を並べて比べる段階です。判断の目安は「古いシステムは直すか、作り直すか」にまとめています。

保守会社に任せている場合に、確かめること

保守会社にシステムを任せている場合も、期限を守る責任は、システムを持つ会社の側にあります。次の5つを聞き、答えを書面で残しておくと安心です。

1. どのサーバーで 8.2 が動いているか（洗い出しの表を出してもらう）
2. 移る先の版と、その版を選んだ理由
3. 作業の日程と、サービスが止まる時間
4. 問題が出たときに、元に戻す手順
5. 費用が、月々の保守の範囲か、別の見積もりか

PHP の版を上げる作業は、月々の保守の範囲に入っていないことがよくあります。年末に見積もりを受け取って、社内の承認が年明けになる、という流れは避けたいところです。11月のうちに相談を始めてください。保守の契約で決めておきたい項目は、「システムの保守を引き継いだら、最初にやること」にもまとめています。

おわりに

PHP 8.2 のサポート終了は、10月の脆弱性のような突然の出来事ではなく、3年前から日付が決まっていた予定です。それでも、期限の直前に慌てる会社が多いのは、どこで動いているか、誰が上げるのか、費用は誰が持つのかが、ふだん決まっていないからです。

残りの7週間でやることは、洗い出し、移る版の決定、検証、切り替えの4つです。最初の1週間で洗い出しの表を作れば、残りの作業の大きさが見えます。今回作った表と、確かめる項目の表は、2027年末の 8.3、2028年末の 8.4 の期限でも、そのまま使えます。