【PHP 8.2 サポート終了】2026年12月末までに社内SEがやること

はじめに

PHP 8.2のセキュリティサポートが2026年12月31日に終了します。

2026年は他にもMySQL 8.0（4月）、Amazon Linux 2（6月）、Office 2021（10月）などEOLが集中する年です。PHP 8.2も年末に控えているため、計画的な対応が必要です。

この記事では、PHP 8.2から8.3/8.4への移行について、社内SE向けに解説します。

PHP 8.2 サポート終了の概要

サポート期限

サポート種別	終了日	状況
アクティブサポート	2024年12月31日	終了済み
セキュリティサポート	2026年12月31日	約1年後

PHP 8.2は2022年12月にリリースされ、4年間のサポート期間を経て2026年末にEOLを迎えます。現在はセキュリティサポート期間中で、重大なセキュリティ問題のみ修正が行われています。

PHP 8.2の主な特徴（振り返り）

PHP 8.2で導入された主な機能です。移行時の参考にしてください。

• readonlyクラス：クラス全体をreadonlyに設定可能
• DNF型（Disjunctive Normal Form Types）：複合型の組み合わせが可能に
• true/false/nullを独立した型として使用可能
• 動的プロパティの非推奨化（Deprecation警告が出る）
• utf8_encode()/utf8_decode()の非推奨化

移行先の選択肢

PHP 8.2からの移行先は主に2つです。

バージョン	リリース日	EOL	推奨度
PHP 8.3	2023年11月	2027年12月31日	○ 安定性重視
PHP 8.4	2024年11月	2028年12月31日	◎ 長期運用向け
PHP 8.5	2025年11月（予定）	2029年12月31日	△ 新しすぎる可能性

推奨：PHP 8.4への移行がおすすめです。2028年末までサポートされるため、次回の移行まで2年の余裕があります。PHP 8.3は1年後にまたEOLを迎えるため、移行コストを考えると8.4が効率的です。

PHP 8.3/8.4への移行で注意すべき変更点

PHP 8.3での変更点

削除された機能

• utf8_encode() / utf8_decode()の削除

追加された機能

• json_validate()関数
• クラス定数の型付け
• #[\Override]アトリビュート
• Randomizerクラスの拡張

PHP 8.4での変更点

新機能

• プロパティフック：getter/setterをプロパティに直接定義
• 非対称可視性：読み取りと書き込みで異なるアクセス修飾子
• newを括弧なしでメソッドチェーン可能
• 新しい配列関数（array_find()など）

非推奨になった機能

• mysqli_ping() / mysqli::ping()
• 暗黙的なnullable型（function foo(Type $param = null)形式）
• _を型名として使用

移行時に対応が必要なコード

1. utf8_encode() / utf8_decode() の置き換え

PHP 8.2で非推奨、PHP 8.3で削除された関数です。

// 変更前（PHP 8.3でエラー）
$utf8 = utf8_encode($latin1_string);
$latin1 = utf8_decode($utf8_string);

// 変更後
$utf8 = mb_convert_encoding($latin1_string, 'UTF-8', 'ISO-8859-1');
$latin1 = mb_convert_encoding($utf8_string, 'ISO-8859-1', 'UTF-8');

2. 動的プロパティへの対応

PHP 8.2で非推奨化された動的プロパティは、将来のバージョンでエラーになる予定です。

// 変更前（PHP 8.2で警告）
class User {
    public $name;
}
$user = new User();
$user->email = 'test@example.com'; // 未定義のプロパティ

// 変更後（方法1：プロパティを定義）
class User {
    public $name;
    public $email; // 明示的に定義
}

// 変更後（方法2：#[AllowDynamicProperties]を使用）
#[AllowDynamicProperties]
class User {
    public $name;
}

3. mysqli_ping() の置き換え（PHP 8.4対応）

// 変更前（PHP 8.4で非推奨）
if ($mysqli->ping()) {
    echo "接続OK";
}

// 変更後（クエリで確認）
try {
    $mysqli->query("SELECT 1");
    echo "接続OK";
} catch (mysqli_sql_exception $e) {
    // 再接続処理
}

4. 暗黙的なnullable型の修正（PHP 8.4対応）

// 変更前（PHP 8.4で非推奨）
function greet(string $name = null) {
    // ...
}

// 変更後（明示的にnullableを宣言）
function greet(?string $name = null) {
    // ...
}

互換性確認の手順

1. PHP 8.2利用環境の棚卸し

まずはPHP 8.2を使用している環境を洗い出します。

• 本番Webサーバー
• ステージング・開発環境
• レンタルサーバー・VPS
• Docker / コンテナ環境
• CI/CDパイプライン

2. 静的解析ツールでのチェック

PHPStanやPsalmなどの静的解析ツールを使って、非推奨機能の使用箇所を検出できます。

# PHPStanの実行例
./vendor/bin/phpstan analyse src --level=5

3. テスト環境での動作確認

1. テスト環境にPHP 8.3または8.4をインストール
2. アプリケーションをデプロイ
3. エラーログを確認（Deprecation警告も含めて）
4. 主要機能の動作テスト
5. パフォーマンステスト

4. WordPressサイトの場合

WordPress本体は最新版であればPHP 8.3/8.4に対応しています。問題になりやすいのはプラグインとテーマです。

• WordPress本体を最新版にアップデート
• プラグイン・テーマを最新版にアップデート
• 1年以上更新されていないプラグインは代替を検討
• PHP Compatibility Checkerプラグインで互換性チェック

移行スケジュール例

2026年12月のEOLに向けた推奨スケジュールです。年末の移行は避けましょう。

時期	作業内容
2026年Q2（4-6月）	環境棚卸し、影響調査、静的解析
2026年Q3（7-9月）	テスト環境構築、互換性確認、コード修正
2026年Q4（10-11月）	本番移行（11月までに完了）
2026年12月	予備期間（新規移行作業は避ける）

2026年は他のEOL対応も多いため、PHP 8.2の移行は下半期に集中させるのが現実的です。上半期はMySQL 8.0やAmazon Linux 2の対応を優先しましょう。

2026年 他のEOLとの関係

PHP 8.2のEOL対応は、2026年の他のEOL対応と合わせて計画する必要があります。

時期	EOL対象	優先度
4月	MySQL 8.0	高（DB移行は影響大）
6月	Amazon Linux 2	高（OS移行は基盤）
10月	Office 2021	中（全社員に影響）
11月	PostgreSQL 14	中
12月	PHP 8.2	高（年末前に完了）

よくある質問

Q. PHP 8.1から8.2を経由せずに8.4へ移行できる？

はい、可能です。むしろ推奨します。PHP 8.2を経由すると、2026年末に再度移行が必要になります。PHP 8.1から直接8.3または8.4に移行する方が効率的です。

Q. PHP 8.4と8.3、どちらを選ぶべき？

長期運用を考えるならPHP 8.4がおすすめです。サポート期間が1年長く、新機能（プロパティフックなど）も利用できます。ただし、互換性の問題が心配な場合はPHP 8.3を選び、その後8.4に移行する方法もあります。

Q. EOL後も使い続けることはできる？

技術的には可能ですが、セキュリティパッチが提供されなくなるため推奨しません。一部のホスティングサービスでは提供を継続しますが、セキュリティリスクは自己責任となります。

まとめ

項目	内容
EOL日	2026年12月31日
推奨移行先	PHP 8.4（または8.3）
主な注意点	utf8_encode削除済み、mysqli_ping非推奨
移行期限	2026年11月までに完了推奨
他のEOL	MySQL 8.0（4月）、AL2（6月）なども対応必要

PHP 8.2のEOLは2026年末です。年末の移行は避け、11月までに完了させるスケジュールを立てましょう。2026年は他のEOLも多いため、年間計画を立てて計画的に対応することが重要です。