2026.10.30

【2026年版】PHP 8.2のサポートは12月31日で終了｜8.4・8.5へのバージョンアップ手順とつまずきやすい変更

soflan ・読了 6分

はじめに

PHP 8.2 のセキュリティサポートは、2026 年 12 月 31 日で終わります。2027 年からは、脆弱性が見つかっても 8.2 には修正版が出ません。10 月にも PHP で深刻度「緊急」の脆弱性が見つかっており、サポートの切れた版を使い続ける危険は小さくありません（脆弱性の内容はPHP 7 系から 8 系への記事の冒頭にまとめています）。

この記事では、PHP 8.2（と 8.3）から 8.4・8.5 へ上げる手順と、8.3〜8.5 で変わったところのうち、つまずきやすいものをまとめました。PHP 7 系以前からの場合はPHP 7 系から 8 系へ・PHP 5 系から 8 系への記事をどうぞ。

PHP のサポート期間

バージョン	公開	通常のサポート	セキュリティの修正
8.2	2022 年 12 月	終了	2026 年 12 月 31 日まで
8.3	2023 年 11 月	終了	2027 年 12 月 31 日まで
8.4	2024 年 11 月	2026 年 12 月 31 日まで	2028 年 12 月 31 日まで
8.5	2025 年 11 月	2027 年 12 月 31 日まで	2029 年 12 月 31 日まで
8.6	2026 年 11 月 19 日に正式版の予定（10 月末時点は RC）

PHP は、公開から 2 年は通常のサポート（バグとセキュリティの修正）、そのあと 2 年はセキュリティの修正だけ、というしくみです。期限はその年の 12 月 31 日にそろえられています。

上げる先は 8.4 か 8.5

8.4（2028 年末まで）：フレームワークやライブラリの対応が進んでいて、無難な選択
8.5（2029 年末まで）：使っているものが 8.5 に対応していれば、次の更新までの期間を長くとれる
8.3 は 2027 年末までなので、今から上げる先としては短すぎます
8.6 は 11 月に正式版の予定です。出てすぐはライブラリが追いついていないことが多いので、8.6 を待つより、まず 8.4・8.5 に上げておきましょう

上げる前に確かめること

bash

# 今の PHP のバージョン
php -v

# Composer の依存が、新しい PHP の条件を満たすか（新しい PHP で実行する）
composer check-platform-reqs

# 使っている拡張の一覧（8.4 で本体から外れたものがないか見る）
php -m

フレームワーク・CMS（Laravel・Symfony・WordPress・EC-CUBE など）が、上げる先の PHP に対応しているか。古い版のままなら、先にそちらを上げます
レンタルサーバーなら、管理画面で選べる PHP のバージョンと、切り替えの方法（サイトごとか、全体か）
拡張：8.4 で IMAP・OCI8・PDO_OCI・pspell が本体から外れました（PECL から入れる）

問題の箇所をツールで見つける

PHPCompatibility

コードを静的に調べて、上げる先の PHP で問題になる箇所を一覧にします。使い方はPHPCompatibility の使い方にまとめています。

bash

# 8.4 以降で問題になる箇所を一覧にする
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4- --ignore=vendor/

Rector

機械的に直せる書き換え（暗黙の null 許容に ? を付ける、など）は、Rector で一気に直せます。

rector.php

<?php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    // composer.json の "php" の条件を見て、そのバージョン向けの書き換えをする
    ->withPhpSets();

bash

# まず差分だけ見る
vendor/bin/rector process --dry-run

テストを非推奨の警告ありで回す

新しい PHP の検証環境で、error_reporting = E_ALL にしてテストや画面を一通り動かし、ログに出る Deprecated を拾います。非推奨は今すぐ止まりませんが、次のメジャーバージョン（PHP 9）で削除される予定です。

bash

# Docker で PHP 8.5 の環境を作って、テストを動かす
docker run --rm -v "$PWD":/app -w /app php:8.5-cli \
  php -d error_reporting=E_ALL -d display_errors=1 vendor/bin/phpunit

8.3 でつまずきやすいところ

数字でない文字列の ++・-- が非推奨

PHP

$s = '';
$s++;            // 8.3 から非推奨（空の文字列・数字でない文字列の ++）

$id = 'A9';
$id = str_increment($id); // 'B0'。文字列を進めたいときは str_increment() を使う

そのほか

get_class()・get_parent_class() を引数なしで呼ぶのが非推奨 → self::class・static::class などに
assert_options() と assert.* の設定が非推奨

8.4 でつまずきやすいところ

引数の「暗黙の null 許容」が非推奨

PHP

function find(User $user = null) {}  // 8.4 から非推奨
function find(?User $user = null) {} // ? を付ける（Rector で一括で直せる）

古いライブラリに大量に残っていることが多い書き方です。自分のコードだけでなく、vendor の中から警告が出ることもあるので、ライブラリも新しくしましょう。

E_STRICT がなくなった

エラーのレベル E_STRICT が削除され、定数の E_STRICT は非推奨になりました。error_reporting(E_ALL & ~E_STRICT) のような書き方が古い設定やフレームワークに残っていると、非推奨の警告が出ます。E_ALL だけにします。

そのほか

trigger_error() に E_USER_ERROR を渡すのが非推奨 → 例外を投げるか exit() に
fputcsv()・fgetcsv()・str_getcsv() の escape の引数を省略すると非推奨 → 明示的に渡す（escape: '' など）
round() に正しくない mode を渡すと ValueError になった（前は四捨五入として扱われた）
exit() に正しくない型を渡すと TypeError になった
mysqli_ping() が非推奨。セッションの session.sid_length などの設定の変更も非推奨
OPcache の JIT の既定が変わった。JIT を使っていた人は opcache.jit の設定を確かめる

8.5 でつまずきやすいところ

コマンドをバッククォートで囲んで実行する書き方が非推奨 → shell_exec() に
(integer)・(boolean)・(double)・(binary) の型キャストが非推奨 → (int)・(bool)・(float)・(string) に
PDO の MySQL 用の定数（PDO::MYSQL_ATTR_INIT_COMMAND など）が非推奨 → Pdo\Mysql::ATTR_INIT_COMMAND に

進める順番

フレームワーク・CMS・ライブラリを、上げる先の PHP に対応した版にする（composer update）
検証環境を新しい PHP にして、PHPCompatibility・Rectorで問題の箇所を直す
E_ALL でテストと画面の確認をして、ログの Deprecated と Warning を片付ける
本番を切り替え、しばらくエラーログを毎日見る
12 月 31 日までに終える。間に合わないときは、少なくとも外から使われる部分を優先する

まとめ

PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日で終わる
上げる先は 8.4（2028 年末まで）か 8.5（2029 年末まで）。8.6 の正式版（11 月予定）を待つより先に上げる
ツールは PHPCompatibility・Rector。テストは E_ALL で回して Deprecated を拾う
つまずきやすいのは、暗黙の null 許容、E_STRICT、数字でない文字列の ++、CSV の escape、バッククォート