InfraAcademy Blog

PHP 8.2で動いているサーバー、年内に上げられますか？12月31日のセキュリティサポート終了と8.4への移行準備

公開日: 2026-10-16 更新日: 2026-10-16 著者: ryu | #Linux #wordpress #php

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

担当しているサーバーで、PHPが動いていませんか？

WordPressのサイト、社内の申請システム、昔からある管理画面など、PHPは今でもいろいろな場所で使われています。

そのPHPのバージョンが8.2なら、残りは2か月半ほどです。PHPの公式サイトでは、PHP 8.2のセキュリティサポートは2026年12月31日までとされています。

この記事では、PHPのサポートの仕組み、サーバーに入っているPHPのバージョンの調べ方、8.4へ上げる前に確かめておきたいことを順番にまとめます。

コードの修正は開発チームの担当になることが多いですが、どのサーバーでどのPHPが動いているかを把握するのはインフラエンジニアの仕事です。まずはそこから見ていきましょう。

PHP 8.2のサポートはいつまで？¶

最初に、PHPの公式サイトに載っている各バージョンのサポート期限を表にまとめます。

バージョン	通常のサポート	セキュリティサポート
PHP 8.2	2024年12月31日で終了	2026年12月31日まで
PHP 8.3	2025年12月31日で終了	2027年12月31日まで
PHP 8.4	2026年12月31日まで	2028年12月31日まで
PHP 8.5	2027年12月31日まで	2029年12月31日まで

PHP 8.2は、すでに通常のサポートが終わっていて、いまはセキュリティの修正だけが出ている状態です。

公式のリリース告知でも、2024年12月に出た 8.2.27 が8.2系の最後のバグ修正リリースで、その後はセキュリティ修正だけになると案内されていました。

PHPのサポート期間の決まり方¶

PHPのサポート期間は、バージョンごとにばらばらに決まっているわけではありません。

PHPの各バージョンは、最初の安定版が出てから2年間は通常のサポート、そのあと2年間は重大なセキュリティの問題だけを直すサポートを受けます。

つまり、どのバージョンも寿命はおおよそ4年です。毎年11月ごろに新しいバージョンが出て、年末に古いバージョンが1つずつ終わっていく流れになっています。

最新の8.5は2025年11月20日に出ました。来年の年末には8.3が終わるので、8.2から8.3に上げても、1年後にまた同じ作業が必要になります。

12月31日を過ぎると何が起きるのか¶

サポートが終わっても、PHPが急に動かなくなるわけではありません。サイトは1月1日以降もそのまま表示されます。

困るのは、そのあとに8.2に影響する脆弱性が見つかったときです。PHPのプロジェクトは、サポートが終わったバージョンには修正版を出しません。

WordPressの公式サイトでも、サポートが終わったPHPでも動きはするものの、セキュリティ上の問題にさらされる可能性があると注意書きがあります。WordPressが推奨しているPHPのバージョンは、8.3以上です。

また、レンタルサーバーやマネージドサービスでは、PHPのプロジェクトより早く8.2の提供をやめるところもあります。たとえばAcquiaは、PHP 8.2のサポートを2026年10月1日で終えると案内していました。自社で使っているサービスの告知も、あわせて確認しておきましょう。

サーバーに入っているPHPのバージョンを調べる¶

では、実際にサーバーでPHPのバージョンを調べてみます。

いちばん手軽なのは、php -v を実行する方法です。

$ php -v
PHP 8.2.29 (cli) (built: ...)
Copyright (c) The PHP Group
Zend Engine v4.2.29, Copyright (c) Zend Technologies

ただし、ここで安心してはいけません。表示の (cli) に注目してください。

CLIとWebのPHPは、別のものとして動いている¶

php -v で分かるのは、コマンドラインで使うPHP（CLI）のバージョンです。

Webサイトを動かしているのは、多くの場合PHP-FPMか、Apacheに組み込まれたモジュール（mod_php）です。1台のサーバーに複数のバージョンが入っていると、CLIは8.3なのにWebは8.2のまま、ということが普通に起こります。

PHP-FPMやApacheのモジュールは、次のように確認できます。

# 動いているPHP-FPMのサービスを確認する（Debian / Ubuntu系の例）
$ systemctl list-units --type=service 'php*'
php8.2-fpm.service  loaded active running  The PHP 8.2 FastCGI Process Manager

# 実際に動いているプロセスも見ておく
$ ps -ef | grep [p]hp-fpm

# Apacheに組み込まれたPHPモジュールを確認する
$ apache2ctl -M | grep -i php

Debian系のOSでは、/etc/php/ の下にバージョンごとのディレクトリができるので、入っているバージョンの一覧としても使えます。

$ ls /etc/php/
8.2  8.3

# どのPHPがCLIの既定になっているか
$ update-alternatives --list php

RHEL系のOSでは、パッケージの一覧から確認するのが確実です。

$ rpm -qa | grep -i '^php'
$ php-fpm -v

Webから見たバージョンを確かめたいときは、phpinfo() を出力するファイルを一時的に置く方法もあります。ただし、設定の中身がすべて見えてしまうので、確認が終わったらすぐに消してください。

どこから入れたPHPかも記録しておく¶

バージョンと一緒に、そのPHPをどこから入れたかも確認しておきます。入れ方によって、修正が届く経路が変わるからです。

入れ方	例	修正の届き方
OSの標準パッケージ	Debian 12の `php8.2`、Ubuntu 24.04の `php8.3`	OSのセキュリティ更新で届く
外部のリポジトリ	PPAやサードパーティのリポジトリ	配布元が修正を出すかどうかによる
コンテナイメージ	`php:8.2-fpm` などの公式イメージ	イメージを作り直さないと反映されない
ソースからビルド	`/usr/local/bin/php` など	自分でビルドし直す必要がある

Debian 12（bookworm）の標準のPHPは8.2です。Ubuntu 24.04の標準は8.3なので、Ubuntu 24.04で8.2が動いている場合は、外部のリポジトリから入れている可能性が高いです。

OSの標準パッケージは、ディストリビューションが独自に修正を続ける場合があります。ただ、どこまで面倒を見るかはOSごとに違うので、PHPの公式のサポート期限とは別に、OSのセキュリティ情報で確認しておきましょう。

コンテナで動かしている場合は、Dockerfile の FROM の行を見ればバージョンが分かります。Dockerで作ったPHPの環境については『Dockerを使ってphpの環境を構築する方法』も参考にしてください。

8.4へ上げる前に確認しておきたいこと¶

バージョンが分かったら、次は移行先を決めます。

8.3に上げると、セキュリティサポートは2027年末までです。8.4なら2028年末まで、8.5なら2029年末まで使えます。来年も同じ作業をしないで済むように、8.4以上を候補にするのがおすすめです。

非推奨の警告をログに出して、事前に洗い出す¶

PHPは、新しいバージョンで使えなくなる予定の書き方に対して、非推奨（Deprecated）の警告を出します。

8.4で非推奨になったものの中で、古いコードでよく見かけるのは次の書き方です。

// 8.4から非推奨（型の後ろに = null と書いて、暗黙にnullを許している）
function find(User $user = null) { ... }

// 明示的にnullを許す書き方に直す
function find(?User $user = null) { ... }

ほかにも、E_STRICT という定数が8.4で非推奨になりました。8.2の時点で非推奨になっていた、宣言していないプロパティを動的に作る書き方や、utf8_encode() も残っていないか確認しておきましょう。

非推奨の警告は、すぐにエラーになるわけではありません。ただ、公式の説明では将来のPHP 9で削除される予定とされているので、移行のタイミングでまとめて直しておくのが楽です。

検証環境では、警告がすべてログに残るように設定しておきます。

; 検証環境の php.ini の例（本番では display_errors を Off のままにする）
error_reporting = E_ALL
log_errors = On
error_log = /var/log/php/error.log
display_errors = Off

PHP-FPMを使っている場合は、php.ini を変えたあとに systemctl restart php8.4-fpm のように再起動しないと反映されません。

拡張モジュールとComposerの指定も見ておく¶

アプリのコードと同じくらい見落としやすいのが、拡張モジュールです。

# いまのPHPに入っている拡張モジュールの一覧
$ php -m > modules-8.2.txt

# 新しいPHPを入れたあとに比べる
$ php8.4 -m > modules-8.4.txt
$ diff modules-8.2.txt modules-8.4.txt

Debian系では、php8.2-mbstring のように拡張モジュールがバージョンごとに別のパッケージになっています。PHP本体だけを入れて、拡張モジュールを入れ忘れると、画面が真っ白になる原因になります。

Composerを使っているアプリなら、composer.json の require に書かれたPHPのバージョンの範囲も確認します。composer check-platform-reqs を実行すると、いまの環境が依存パッケージの条件を満たしているかを確かめられます。

php.iniとPHP-FPMの設定は引き継がれない¶

Debian系のOSで新しいバージョンのPHPを入れると、設定ファイルも新しいディレクトリに一から作られます。8.2で調整していた設定は、自動では引き継がれません。

設定ファイル	8.2のときの場所	8.4での場所
Web用のphp.ini	`/etc/php/8.2/fpm/php.ini`	`/etc/php/8.4/fpm/php.ini`
CLI用のphp.ini	`/etc/php/8.2/cli/php.ini`	`/etc/php/8.4/cli/php.ini`
PHP-FPMのプール設定	`/etc/php/8.2/fpm/pool.d/www.conf`	`/etc/php/8.4/fpm/pool.d/www.conf`

たとえば、upload_max_filesize や memory_limit を大きくしていた場合、新しい環境では既定値に戻っています。ファイルのアップロードが急に失敗するようになった、という問い合わせはここが原因のことが多いです。

PHP-FPMのプール設定にある pm.max_children などのプロセス数の設定も同じです。古いファイルと新しいファイルを diff で比べて、意図して変えていた値を書き写しておきましょう。

もう1つ、PHP-FPMの待ち受けのソケットのパスも変わります。Debian系の標準の設定では、/run/php/php8.2-fpm.sock が /run/php/php8.4-fpm.sock のようにバージョン入りの名前になるので、Webサーバー側の設定もあわせて直す必要があります。

切り替えと切り戻しの手順を決めておく¶

最後に、本番の切り替え方を決めておきます。

Debian系のように複数のPHPを並べて入れられる環境なら、新しいPHP-FPMを先に起動しておき、WebサーバーのFastCGIの接続先を切り替える方法が使えます。問題があれば接続先を元に戻すだけで切り戻せるので、作業時間を短くできます。

ApacheとPHPの組み合わせ方は『Apacheでphpを動作させる環境の構築方法』でも解説しています。仕組みを理解しておくと、切り替えの手順も組み立てやすくなります。

年内に終わらせるための進め方¶

12月は、どの会社も年末の作業や休みで動きにくい時期です。残りの期間を、おおまかに3つに分けて進めると現実的です。

時期	やること
10月中	PHPが動いているサーバーとバージョン、入れ方を一覧にする
11月中	検証環境で8.4に上げ、非推奨の警告と拡張モジュールの差分をつぶす
12月前半	本番を切り替え、切り戻しの手順も確認しておく

一覧を作るときは、サーバー名、OS、CLIとWebそれぞれのPHPのバージョン、入れ方、担当チームを列にしておくと、あとで抜け漏れを見つけやすくなります。

最近は、OpenSSL 3.0やPython 3.10、MySQL 8.0など、サーバーで使われるソフトウェアのサポート終了が続いています。『OpenSSL 3.0のサポート終了』や『Python 3.10のサポート終了』も、同じサーバーで関係していることが多いので、一覧を作るついでに確認しておくと効率的です。