2026.10.25 PHP

PHPのサポート期限一覧：8.2は2026年末で終了、版ごとのEOLと移行手順【2026年10月】

PHP 8.2のセキュリティサポートは2026年12月31日で終わります。残りは約2か月です。PHPのサポート期限は系列（8.2・8.3などの2桁の版）ごとに決まっており、公開から4年で修正が止まります。本記事では、php.netの一次情報をもとに8.2〜8.5と終了済みの7.4〜8.1の期限を一覧にし、自社サーバーの版を期限と照合するコマンド、RHELやUbuntuに同梱されたPHPの期限の読み方、ComposerとRectorを使った版上げの手順、移行先の選び方までを2026年10月25日時点の情報で整理します。

まとめ：PHP 8.2は2026年12月31日で終了、移行先は8.4か8.5

いま8.2以前で動いているPHPは、年内に移行先を決める段階にあります。8.2は12月31日を過ぎると、PHP開発チームからセキュリティ修正が出なくなります。8.1以前はすでに終了しており、2026年10月21日に公表されたPHP2Shellの修正版も本家からは出ていません。

移行先は8.4か8.5を勧めます。8.3は2027年末で終わるため、今から上げても次の版上げまでの期間は1年余りです。例外はRHELやUbuntuのパッケージでPHPを入れている場合で、OSベンダーがphp.netとは別の期限で修正を出し続けます。ただし対象はOSが提供する系列に限られ、アプリが依存するフレームワークの対応版は別に確かめる必要があります。

PHPのサポート期限の仕組み：2年のバグ修正と2年のセキュリティ修正

php.netのSupported Versionsは、各系列のサポートを2段階で定めています。期限の表を読む前に、2段階のどちらで何が止まるのかを押さえておきます。

アクティブサポートとセキュリティサポートの違いと12月31日の期限

アクティブサポートは、初回の安定版から2年間です。この間はバグとセキュリティの問題がどちらも直り、定期的なパッチ版として出ます。その後の2年間がセキュリティサポートで、直るのは重大なセキュリティ問題だけです。リリースは必要に応じて出るため、何か月も出ないことも、短期間に何本も出ることもあります。

実務で「サポート期限」と呼ぶのは、後者の終了日です。この日を過ぎた系列はphp.netのサポート終了一覧に移り、どんな脆弱性が見つかっても修正版は出ません。アクティブサポートの終了は、通常のバグが直らなくなるという意味にとどまります。

2024年のリリース周期RFCで延びたセキュリティ修正の1年

現在の4年周期は、2024年3月に承認されたリリース周期の見直しRFCで決まりました。それまではセキュリティサポートが1年で、合計3年でした。このRFCはセキュリティサポートを1年延ばし、終了日をすべて12月31日に揃えています。

効果は終了日に表れています。8.0は旧来の周期で2023年11月26日に終わりましたが、8.1は2025年12月31日まで延びました。期限が年末に揃ったので、予算と作業計画は「どの年の年末までに上げるか」で立てられます。

PHPのバージョン別サポート期限一覧：8.2〜8.5と終了済みの7.4〜8.1

ここからは系列ごとの具体的な日付です。値はすべてphp.netの公式ページから2026年10月25日に取得しました。

サポート中の4系列の期限表と残り期間（2026年10月時点）

系列	初回リリース	アクティブサポート終了	セキュリティサポート終了	2026年10月21日時点の最新版
8.5	2025年11月20日	2027年12月31日	2029年12月31日	8.5.12
8.4	2024年11月21日	2026年12月31日	2028年12月31日	8.4.27
8.3	2023年11月23日	2025年12月31日（終了）	2027年12月31日	8.3.36
8.2	2022年12月8日	2024年12月31日（終了）	2026年12月31日	8.2.35

8.2と8.3はすでにセキュリティ修正だけの段階です。8.4も2026年末でアクティブサポートを抜けます。通常のバグ修正まで受け続けたいなら、2027年以降の時点でその条件を満たすのは8.5と、11月に出る予定の8.6だけです。版ごとの変更点はPHP 8.4の新機能と変更点とPHP 8.5の変更点と新機能まとめで確認できます。

終了済みの8.1・8.0・7.4の最終版と期限切れ後に起きたこと

系列	サポート終了日	最終版
8.1	2025年12月31日	8.1.34
8.0	2023年11月26日	8.0.30
7.4	2022年11月28日	7.4.33
7.3	2021年12月6日	7.3.33

7.4.33や8.1.34のような最終版は、終了後も長く使われがちです。ただ、最終版は「最後に直った版」であって、以後の脆弱性には無防備です。

その影響がはっきり出たのが、2026年10月21日に公表されたPHP2Shellでした。PHP 5.4以降のほぼ全版が影響を受けるのに、本家の修正版は8.2.35以降の4系列にしか出ていません。7.4・8.0・8.1向けにはソースの差分がGitHubに置かれただけで、自前でビルドしない限り塞げない状態です。詳細はPHP2Shellの影響範囲と修正版・更新できない場合の設定にまとめています。

PHP 8.6の正式版予定日（2026年11月19日）と期限の見込み

次の8.6は、PHP 8.6のリリース計画で2026年11月19日の正式版が予定されています。10月21日にRC4が出ており、11月5日のRC5を経て正式版に進む日程です。日程は開発の状況で前後すると明記されています。

4年周期と年末揃えの規則に当てはめると、8.6はアクティブサポートが2028年末、セキュリティサポートが2030年末までになる見込みです。ただし、php.netの表に載るのは正式版の公開後です。業務システムの移行先にするのは、主要なフレームワークとライブラリが対応を表明してからにします。

サポート期限をコマンドで確かめる手順：php.netのAPIと稼働中の版

サーバーが数台を超えると、目視の照合では漏れが出ます。php.netはリリース情報をJSONで返すAPIを持っているため、稼働中の版と突き合わせる処理をスクリプトにできます。

php.netのリリースAPIで系列ごとの最新版とサポート状況を取得する

php.netのリリース一覧には、?jsonを付けるとJSONを返す口があります。versionに系列を渡すと、その系列の最新版、公開日、現在サポート中の系列一覧が返ります。

# 8.2系列の最新版と公開日、サポート中の系列一覧を取得する
curl -s "https://www.php.net/releases/index.php?json&version=8.2" \
  | jq '{version, date, supported_versions}'

# 2026年10月25日の実行結果
# {
#   "version": "8.2.35",
#   "date": "21 Oct 2026",
#   "supported_versions": ["8.2", "8.3", "8.4", "8.5"]
# }

終了済みの系列を渡すと、最終版の情報にmuseumというキーが付いて返ります。8.1なら8.1.34（2025年12月18日）です。supported_versionsに自分の系列が含まれていなければ、期限切れと判定できます。

稼働中サーバーのPHP版と最新パッチの差を判定するシェルの書き方

稼働中のPHPの系列と版を取り、APIの値と比べる例です。cronや監視の定期ジョブに入れると、期限切れとパッチの遅れを両方拾えます。Web側とCLIでPHPが異なる構成では、FPMのバイナリ（例：php-fpm8.3）で同じ値を取ります。

#!/bin/sh
# 稼働中のPHPの系列（例：8.3）と版（例：8.3.36）を取得する
BRANCH=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
CURRENT=$(php -r 'echo PHP_VERSION;')

# php.netから同じ系列の最新版とサポート状況を取得する
curl -s "https://www.php.net/releases/index.php?json&version=${BRANCH}" \
  | jq -r --arg br "$BRANCH" --arg cur "$CURRENT" '
      "系列: \($br)  稼働中: \($cur)  最新: \(.version)（\(.date)）  " +
      (if (.supported_versions | any(. == $br)) then "サポート中" else "サポート終了" end)'

このスクリプトが「稼働中」と「最新」の差を示しても、OSのパッケージで入れたPHPでは未修正とは限りません。次の章で説明するとおり、ディストリビューションは上流の版番号を据え置いて修正だけを取り込むためです。自前ビルドや公式Dockerイメージなら、差がそのままパッチの遅れを意味します。

OS同梱PHPの期限はphp.netと別：RHELとUbuntuのサポート期間の読み方

RHELやUbuntuの標準リポジトリから入れたPHPは、php.netの期限とは別にOSベンダーが修正を出します。php.netで期限切れの系列でも、OS側ではまだ修正が続いている場合があるためです。逆もあり、この食い違いを知らないと判断を誤ります。

RHEL 8・9・10のApplication Streams別のPHP提供終了時期

RHELはPHPを「Application Streams」として配り、系列ごとに提供終了日を定めています。値はRed HatのApplication Streamsライフサイクルから取得しました。

OS	PHP系列	提供開始	提供終了	php.netの期限
RHEL 10	8.3（初期搭載）	2025年5月	RHEL 10本体に準ずる	2027年12月31日
RHEL 10	8.4	2026年5月	2029年5月	2028年12月31日
RHEL 9	8.0（初期搭載）	2022年5月	RHEL 9本体に準ずる	2023年11月26日（終了）
RHEL 9	8.2・8.3	2024年5月・2025年5月	2029年5月	2026年末・2027年末
RHEL 8	7.4（初期搭載）	2020年11月	RHEL 8本体に準ずる	2022年11月28日（終了）
RHEL 8	8.2	2024年5月	2029年5月	2026年12月31日

RHEL 9の初期搭載PHP 8.0は、php.netでは2023年に終わっていますが、Red HatはRHEL 9本体の期間にわたって扱います。RHEL 9で追加された8.1は、php.netより半年以上早い2025年5月に提供を終えました。追加のストリームは本体より短く区切られるので、表の「提供終了」を必ず見ます。

Ubuntu 24.04のphp8.3が8.3.6表記のまま修正を取り込む仕組み

Ubuntu 24.04 LTSの標準PHPはphp8.3です。Launchpadのphp8.3パッケージ情報を見ると、リリース時の版は8.3.6-0maysync1、セキュリティ更新は8.3.6-0ubuntu0.24.04.13です。上流の版番号は8.3.6のまま変わらず、末尾の番号だけが増えています。

このため、Ubuntuでphp -vが8.3.6を示しても、php.netの8.3.36相当の修正が入っている可能性があります。判断の材料は版番号ではなく、apt changelog php8.3に対象のCVE番号が載っているかどうかです。前章のスクリプトをUbuntuで使う場合は、この理由で「最新」との差を無視し、系列のサポート状況だけを見ます。

OSのサポートに頼ってよい条件とphp.netの期限で動く条件

OSのサポートに頼ってよいのは、次の3つをすべて満たす場合です。OS標準のPHPパッケージをそのまま使っている、OSのサポート契約や更新が生きている、アプリが依存するフレームワークがその系列を引き続きサポートしている。3つ目は見落とされがちです。たとえばLaravelは系列ごとに必要なPHP版を上げていくため、OSがPHPを直しても、フレームワーク側の修正が古いPHPには届かなくなります。Laravelの対応表はLaravelの対応PHPバージョンとサポート期限一覧にあります。

逆に、Remiなどの外部リポジトリ、公式Dockerイメージ、自前ビルドで入れたPHPは、php.netの期限がそのまま期限です。OSがRHEL 9だから大丈夫、という判断は、OS標準のパッケージを使っている場合にしか成り立ちません。OSごと上げる場合の進め方はインプレースアップグレードのリスクとRHELの対応経路を参照してください。

期限前の移行：Composer・PHPCompatibility・Rectorの版上げ手順

版上げの作業は、依存パッケージの確認、非互換の検出、コードの書き換え、検証環境での動作確認の順に進めます。順番を逆にすると、書き換えたあとで依存パッケージが対応していないと分かり、手戻りが出ます。

composer.jsonのplatform設定で依存パッケージの対応版を洗い出す

最初に、移行先のPHPで依存パッケージが解決できるかを確かめます。Composerの設定リファレンスにあるplatformを使うと、手元のPHPを入れ替えずに、移行先の版で依存を解決させられます。

# 移行先（ここでは8.4）への版上げを妨げているパッケージを表示する
composer why-not php 8.4

# 依存解決の前提を8.4に固定し、更新できるかを試す（composer.lockは別ブランチで）
composer config platform.php 8.4.27
composer update --dry-run

# 本番サーバーの実際のPHPと拡張が要件を満たすかを確認する
composer check-platform-reqs

why-notで名前が挙がったパッケージは、対応版への更新か、代替への置き換えが必要です。ComposerのCLIリファレンスにある通り、check-platform-reqsは導入済みパッケージの要件と実環境のPHP・拡張を照合します。platformを固定したまま本番にデプロイすると、実際のPHPと食い違っていても依存解決が通る状態です。検証が終わったら設定を外すか、本番と同じ値にそろえます。

PHPCompatibilityで非互換箇所を静的に検出するコマンド

次に、自社コードの中で移行先の版で動かなくなる箇所を探します。PHPCompatibilityはPHP_CodeSnifferのルール集で、削除・非推奨になった関数や構文を版を指定して検出します。

# 導入（10.0系はComposer経由の導入のみサポート）
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev"

# 8.4以降で問題になる箇所を検出し、結果をファイルに出す
vendor/bin/phpcs -p src/ --standard=PHPCompatibility \
  --runtime-set testVersion 8.4- --report-full=phpcompat.txt

testVersion 8.4-のように末尾をハイフンにすると、8.4以降すべてを対象にできます。10.0系はPHP 7.2未満の実行環境とPHP_CodeSniffer 4.0.2未満の対応を外しているため、7.1以前で動くプロジェクトで実行に使うのは、移行先のPHPを入れた環境です。検出結果は「動かない」箇所の一覧で、直し方はPHP 8.3.xから8.4.xへの移行ガイドのような公式の移行ガイドで確認します。

Rectorで構文を書き換える設定とPHPStanでの確認の順序

検出した箇所のうち機械的に直せるものは、Rectorのセット一覧にある版別のルールで書き換えます。プロジェクトの直下にrector.phpを置きます。

<?php
// rector.php：8.4までの構文の書き換えを適用する設定
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true);

# 変更内容を差分で確認してから適用する
vendor/bin/rector process --dry-run
vendor/bin/rector process

引数なしのwithPhpSets()は、composer.jsonに書いたPHPの要件を読んで対象を決めます。7.4以前からの移行で差分が大きすぎる場合は、公式が勧めるwithPhpLevel()で1段ずつ上げる方法が選択肢です。書き換えの後は、型の不整合をPHPStanのレベル運用とベースラインで確認し、最後に既存のテストを流します。Rectorは構文を直すだけで、挙動の変化までは保証しないためです。

公式Dockerイメージのタグをパッチ版まで固定する検証環境の作成手順

動作確認に使うのは、移行先の版を固定した検証環境です。公式Dockerイメージの定義リポジトリには、2026年10月時点で8.2・8.3・8.4・8.5と8.6-rcの定義があります。タグはphp:8.4.27-fpmのようにパッチ版まで書くと、検証と本番で同じ版を再現できます。

一方で、パッチ版まで固定したタグは自動では更新されません。PHP2Shellのような修正版が出たら、タグを書き換えてイメージを作り直す運用を決めておきます。php:8.4-fpmのような系列タグにする場合も、イメージの再取得と再ビルドをしない限り修正は届きません。

移行先の選び方と外注の判断：8.4と8.5のどちらに上げるか

最後に、どの版へ上げ、どこまで自社でやるかを決めます。ここでは条件を示したうえで結論を書きます。

8.2からの移行先を8.4か8.5に絞る判断基準と8.3を選ばない理由

8.2からの移行先は、原則として8.4にします。セキュリティサポートが2028年末まであり、主要なフレームワークとライブラリの対応も出そろっているためです。WordPressも公式の動作要件でPHP 8.3以上を推奨しており、8.4はこの条件を満たします。新規開発や、依存パッケージが少なく追従しやすいシステムなら8.5を選び、期限を2029年末まで延ばします。

8.3は選びません。2027年12月31日で終わるため、移行の検証費用をかけても1年余りで同じ作業が来ます。8.6も、正式版の直後に本番の移行先にするのは見送ります。拡張モジュールやライブラリの対応が追いつくまでの数か月を待ち、8.6.1以降で判断するのが安全です。

7.4以前から上げる場合は、8.0の段階で非互換が集中します。一度に8.4まで上げるか段階を踏むかを決める判断基準は、テストの有無です。テストが無いシステムで一気に上げるのは失敗パターンで、壊れた箇所を特定できなくなります。その場合は、先に主要な画面の動作確認を自動化してから版上げに入ります。

PHP移行を外部に任せる規模と自社で済む規模の依存管理・テストによる線引き

自社で済むのは、Composerで依存を管理しており、テストがあり、why-notで挙がるパッケージが数個に収まる場合です。前章の手順をそのまま進めれば、移行先の版で動くところまで持っていけます。

外部に任せた方が早いのは、7.4以前で止まっている、依存がComposerで管理されていない、開発した担当者がもういない、のいずれかに当たる場合です。どれもコードの読み解きに時間がかかり、期限の12月31日に間に合わない原因になります。一創の保守運用・内製化支援では、PHPで作られた既存システムの調査から版上げ、その後の運用の引き継ぎまでが支援の対象です。WordPressサイトの場合の運用体制はWordPress保守運用の作業範囲と内製か外注かの判断基準で整理しています。

PHPのサポート期限に関するよくある質問：共用サーバーとWordPress

PHPの期限と版上げについて、運用担当者から寄せられやすい質問に答えます。

PHP 8.2のサポート期限が切れたら、サイトは動かなくなりますか？

動き続けます。期限はPHP開発チームが修正版を出すのをやめる日で、PHPが止まる日ではありません。問題は、期限後に見つかった脆弱性が直らないことです。PHP2Shellのように未認証で外から攻撃できる欠陥が出た場合、修正版が無い系列は攻撃を受け続けます。共用サーバーでは、事業者が期限切れの系列を選択肢から外し、自動で新しい系列へ切り替えることもあります。

PHP 7.4.33は最終版なので安全に使い続けられますか？

使い続けられません。7.4.33は2022年11月28日のサポート終了時点で直っていた最終版で、それ以降に見つかった脆弱性は含みません。RHEL 8の標準パッケージのように、OSベンダーが7.4へ修正を当て続けている場合は例外です。その場合もアプリのフレームワークが7.4を切っていれば、フレームワーク側の修正が入らなくなります。

レンタルサーバーで使っているPHPの期限はどこで確認できますか？

系列の期限はphp.netの表で決まり、事業者が変えることはできません。確認するのは、管理画面で選んでいる系列と、事業者がその系列にバックポートを当てているかの2点です。系列はWordPressなら管理画面の「サイトヘルス」、それ以外はphpversion()を出力する一時ファイルで分かります。確認用のファイルは調べ終わったら必ず削除します。

WordPressはPHPのどの版で使うのがよいですか？

WordPressの公式要件はPHP 8.3以上を推奨しています。期限まで考えると8.4が現実的な選択です。テーマやプラグインが8.4に対応していない場合は、更新が止まったプラグインを置き換える作業が先になります。8.2のまま年を越すと、テーマやプラグインに問題が無くても、PHP本体の修正が受けられなくなります。

PHPの版上げはどのくらいの期間を見ておけばよいですか？

8.2から8.4へ、Composerとテストがそろったシステムなら、依存の更新と検証で数週間が目安です。7.4以前からの移行や、依存がComposerで管理されていないシステムでは、調査だけで同程度かかることがあります。8.2の期限まで約2か月なので、12月に入ってからの着手では、期限に間に合わない可能性が高い状況です。まずcomposer why-notで依存の状況を調べ、作業量を見積もるところから始めます。