PHP 8.2から8.3・8.4への更新の進め方と、壊れやすいところ：つづきの技術室

PHP 8.2で動いている業務システムの担当の方から、「年内に上げないといけないらしいけれど、何から始めればいいのか」と聞かれることが増えてきました。8.2は2022年12月に出たバージョンで、セキュリティ修正が出るのは2026年12月31日までです（PHP: Supported Versions）。

サポートが切れると何が起きるのかは、サポート切れのPHPを放置すると何が起きるかに書きました。この記事はその続きで、実際に8.2から上げるときにどのバージョンを選び、どこを確かめ、どう切り替えるかを書きます。前半は発注担当や情シスの方向け、後半の変更点の部分は、保守会社や社内のエンジニアと話すときの材料として読んでいただければと思います。

8.3と8.4、どちらに上げるか

まず、各バージョンの期限を並べておきます。いずれもPHPの公式サイトに載っている日付です。

バージョン	最初のリリース	通常のサポート	セキュリティ修正
8.2	2022年12月8日	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日まで

出典：PHP: Supported Versions（2026年10月に確認）

8.3に上げると、次の期限は2027年末です。今回の作業が終わってから1年少しで、また同じ検討をすることになります。8.4なら2028年末まで、8.5なら2029年末までです。

私たちの考えとしては、使っているフレームワークやライブラリが対応していれば、8.4以上を目指すのがよいと思います。8.3を選ぶのは、システムが頼っている部品がまだ8.4に対応していない場合や、OSの都合で8.3しか選べない場合くらいです。8.2から8.4へ一気に上げても構いませんが、そのときは8.3で入った変更と8.4で入った変更の両方を確かめることになります。間を飛ばしても、確かめる量は減りません。

OSに同梱されたPHPを使っている場合

ここで一つ、先に確かめておきたいことがあります。そのPHPを、どこから入れているかです。

PHPの公式サイトにある期限は、PHPの開発元が修正を出す期限です。Red Hat Enterprise Linux（RHEL）のようなOSに同梱されたPHPは、OSの提供元が別の期限を決めて修正を出しています。Red Hatの公開しているApplication Streamsのライフサイクルでは、RHEL 8とRHEL 9のPHP 8.2は2029年5月まで、RHEL 9のPHP 8.3も2029年5月まで、RHEL 10のPHP 8.4は2029年5月までのサポートになっています。RHEL 10のPHP 8.3と、RHEL 8のPHP 7.4、RHEL 9のPHP 8.0は、そのRHELのバージョン自体が終わるまでの扱いです（Red Hat Enterprise Linux Application Streams Life Cycle）。

実際、2026年10月21日にPHP本体の重大な脆弱性が公表されたときも、Red HatはPHPの開発元がサポートを終えた7.4について、RHEL 8向けの修正を出しました（RHSA-2026:87080）。

一方で、同じページには、期限を過ぎたストリームのパッケージには更新もエラータ（修正の告知）も出ないと書かれています。RHEL 9のPHP 8.1は2025年5月で終わっているので、今回のような脆弱性が見つかっても、Red Hatからの修正は期待できません。

つまり、OS同梱のPHP 8.2を使っているなら、年末を過ぎてもすぐに修正が止まるわけではありません。逆に、OSとは別にPHPの公式版を入れていたり、ソースから自分でビルドしていたりするなら、2026年12月31日がそのまま期限です。Rocky LinuxやAlmaLinuxのようなRHEL互換のOSも含めて、まずは「このPHPは誰が修正を出しているのか」を保守会社に確かめてください。年内に急ぐべきかどうかは、そこで決まります。

ただ、OSの期限が延びているからといって、更新を先送りしてよいとは考えていません。フレームワークやライブラリは、OSとは関係なく新しいPHPに合わせて古い版の対応をやめていきます。PHP本体は直っても、その上の部品が古いまま固まる、ということが起こります。

8.3で変わること

ここからは、PHPの公式マニュアルにある移行ガイドのうち、業務システムで引っかかりやすいと私たちが考えるものを抜き出します。全体はPHP 8.2.x から PHP 8.3.x への移行にまとまっています。

8.3は、8.4に比べると変更が少ないバージョンです。それでも、次のあたりは確かめておきたいところです。

日付を扱う処理では、DateTime拡張が、これまで警告や汎用の例外で知らせていた問題を、DateErrorやDateExceptionという専用のエラーや例外で投げるようになりました（下位互換性のない変更点）。日付の入力チェックを警告頼みで書いていた古いコードでは、エラーの拾い方を見直すことになります。

range() の動きも細かく変わっています。たとえば range('9', 'A') は、8.3より前は数字の9から0までの配列を返していましたが、8.3からは文字の「9」から「A」までの並びを返します。number_format() に負の小数点以下桁数を渡したときの扱いも変わりました。どちらも、帳票や集計の画面で数字の並びや丸め方に効いてくる可能性があります。

非推奨（今は動くが、将来なくなる予定のもの）としては、空の文字列や数字でない文字列に ++ や -- を使うこと、引数なしの get_class() や get_parent_class()、assert_options() などが挙がっています（PHP 8.3.x で推奨されなくなる機能）。

8.4で変わること

8.4は、古いコードにとって影響の大きい変更が多いバージョンです。全体はPHP 8.3.x から PHP 8.4.x への移行にあります。

一番先に確かめてほしいのは、PHPに標準で入っていた拡張機能のうち、IMAP、OCI8、PDO_OCI、PSpellの4つが本体から外れたことです（削除された拡張モジュール）。IMAPはメールサーバーにつないでメールを読む機能、OCI8とPDO_OCIはOracle Databaseにつなぐための機能です。「問い合わせメールを自動で取り込む」「基幹システムのOracleからデータを読む」といった処理を持つシステムでは、別途PECLという仕組みから入れるか、作りを変える必要があります。公式の説明では、外れた拡張の新しいリリースは要望に応じて出すとされていて、これまでのように本体と一緒に更新される前提ではなくなります。

次に、件数の面で目立ちそうなのが、引数の型の書き方に関する非推奨です。function foo(T1 $a = null) のように、型を指定した引数の初期値に null を置く書き方が非推奨になり、?T1 $a = null のように書き直すよう案内されています（PHP 8.4.x で推奨されなくなる機能）。動作は変わりませんが、古いコードではこの書き方がよく使われるので、非推奨の通知が大量に出ることがあります。

CSVを扱う処理も見ておきたいところです。fputcsv()、fgetcsv()、str_getcsv() で escape 引数を省略することが非推奨になりました。CSVの出力や取り込みを持たない業務システムのほうが珍しいので、該当する書き方がないか、コードを検索しておくとよいと思います。

そのほか、業務システムで見かけそうなものを挙げておきます。

mysqli_ping() などの関数が非推奨になった
session.sid_length などのセッション設定を変えることが非推奨になった
exit() に想定外の型の値を渡すとTypeErrorになるようになった
E_STRICT というエラーの種類がなくなり、その定数も非推奨になった
正規表現のライブラリが更新され、{,3} のような書き方の意味が変わった
password_hash() でbcryptを使うときの既定の計算コストが10から12に上がった

最後のものは不具合ではありませんが、ログイン処理でパスワードを保存するときの計算が重くなります。利用者の多いシステムでは、念のため負荷を見ておくと安心です（その他の変更）。

非推奨は、今は動いても放置しない

移行ガイドを読むと、「非推奨」の項目の多さに驚かれると思います。非推奨は、今のバージョンでは動くけれど、将来のバージョンで削除する予定があるという意味です。だから更新の直後に画面が止まるわけではありません。

それでも、私たちは非推奨の通知を放置しないほうがよいと考えています。理由は二つあります。一つは、次に上げるときの作業がその分だけ重くなること。もう一つは、ログが非推奨の通知で埋まって、本当に見るべきエラーが見つけにくくなることです。少なくとも、何件どこで出ているかは把握しておき、計画的に減らしていくのがおすすめです。

更新の進め方

具体的な進め方は、システムの規模や保守の体制で変わりますが、大まかには次の順番になります。

今のPHPのバージョンと入手元（OS同梱か、別に入れたものか）、有効になっている拡張機能を一覧にする
使っているフレームワークやライブラリが、上げたいバージョンに対応しているかを調べる
検証用の環境に新しいPHPを入れ、非推奨の通知も含めてエラーをすべてログに出した状態で動かす
普段の画面だけでなく、月末の締め処理、CSVの取り込みと出力、メール送信、帳票の出力、外部サービスとの連携など、たまにしか動かない処理も試す
本番の切り替えは、問題があればすぐ元のPHPに戻せる形で行う

4番目は、時間をかけてでもやってほしいところです。トップページやログインは誰でも試しますが、月に一度しか動かない処理は、検証から漏れがちです。

5番目は、たとえばPHP-FPMを使っている環境なら、新旧のPHPを並べて動かしておき、Webサーバーの設定でどちらに渡すかを切り替える、といったやり方があります。こうしておくと、切り替えた後に問題が見つかっても、設定を戻すだけで済みます。

年内に間に合わないとき

検証してみたら、思ったより手直しが多かった。こういうことはよくあります。その場合でも、慌てて作り直しを決める必要はありません。

まずは前の章で書いたとおり、今使っているPHPに誰が修正を出しているのかを確かめます。OS同梱のPHPであれば、OSの提供元の期限まで修正が届くので、その間に計画的に進められます。PHPの公式版を使っている場合は、年明けからは修正が出なくなる前提で、外部に公開している画面を減らすなど、リスクを下げる手を保守会社と相談しながら、なるべく早く更新を終えるのが現実的です。

どちらの場合も、「いつまでに、どのバージョンへ」を一度決めて、関係者で共有しておくことをおすすめします。期限のない更新計画は、たいてい次のトラブルまで動きません。

8.2で動くシステムをお持ちの方へ

ディレクターズ・リベロでは、OSやミドルウェアの更新を含むサーバー運用保守と、他社が開発したシステムの引き継ぎを行っています。更新の影響範囲を調べるところからのご相談も歓迎です。詳しくはサーバー運用保守サポートとシステム引き継ぎ・レガシーシステム保守のページをご覧いただくか、info@directorz-libero.co.jp までご連絡ください。