--- title: "PHPのサポート期限一覧：8.2は2026年末で終了、版ごとのEOLと移行手順【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18881/" published: 2026-10-25 updated: 2026-10-25 categories: ["PHP"] publisher: "株式会社一創" --- # 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](https://www.php.net/supported-versions.php)は、各系列のサポートを2段階で定めています。期限の表を読む前に、2段階のどちらで何が止まるのかを押さえておきます。 ### アクティブサポートとセキュリティサポートの違いと12月31日の期限 アクティブサポートは、初回の安定版から2年間です。この間はバグとセキュリティの問題がどちらも直り、定期的なパッチ版として出ます。その後の2年間がセキュリティサポートで、直るのは重大なセキュリティ問題だけです。リリースは必要に応じて出るため、何か月も出ないことも、短期間に何本も出ることもあります。 実務で「サポート期限」と呼ぶのは、後者の終了日です。この日を過ぎた系列は[php.netのサポート終了一覧](https://www.php.net/eol.php)に移り、どんな脆弱性が見つかっても修正版は出ません。アクティブサポートの終了は、通常のバグが直らなくなるという意味にとどまります。 ### 2024年のリリース周期RFCで延びたセキュリティ修正の1年 現在の4年周期は、2024年3月に承認された[リリース周期の見直しRFC](https://wiki.php.net/rfc/release%5Fcycle%5Fupdate)で決まりました。それまではセキュリティサポートが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の新機能と変更点](https://www.issoh.co.jp/tech/details/4525/)と[PHP 8.5の変更点と新機能まとめ](https://www.issoh.co.jp/tech/details/8179/)で確認できます。 ### 終了済みの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の影響範囲と修正版・更新できない場合の設定](https://www.issoh.co.jp/tech/details/18738/)にまとめています。 ### PHP 8.6の正式版予定日（2026年11月19日）と期限の見込み 次の8.6は、[PHP 8.6のリリース計画](https://wiki.php.net/todo/php86)で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のリリース一覧](https://www.php.net/releases/)には、`?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ライフサイクル](https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle)から取得しました。 | 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パッケージ情報](https://launchpad.net/ubuntu/noble/+source/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バージョンとサポート期限一覧](https://www.issoh.co.jp/tech/details/5637/)にあります。 逆に、Remiなどの外部リポジトリ、公式Dockerイメージ、自前ビルドで入れたPHPは、php.netの期限がそのまま期限です。OSがRHEL 9だから大丈夫、という判断は、OS標準のパッケージを使っている場合にしか成り立ちません。OSごと上げる場合の進め方は[インプレースアップグレードのリスクとRHELの対応経路](https://www.issoh.co.jp/tech/details/14688/)を参照してください。 ## 期限前の移行：Composer・PHPCompatibility・Rectorの版上げ手順 版上げの作業は、依存パッケージの確認、非互換の検出、コードの書き換え、検証環境での動作確認の順に進めます。順番を逆にすると、書き換えたあとで依存パッケージが対応していないと分かり、手戻りが出ます。 ### composer.jsonのplatform設定で依存パッケージの対応版を洗い出す 最初に、移行先のPHPで依存パッケージが解決できるかを確かめます。[Composerの設定リファレンス](https://getcomposer.org/doc/06-config.md)にある`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リファレンス](https://getcomposer.org/doc/03-cli.md)にある通り、`check-platform-reqs`は導入済みパッケージの要件と実環境のPHP・拡張を照合します。`platform`を固定したまま本番にデプロイすると、実際のPHPと食い違っていても依存解決が通る状態です。検証が終わったら設定を外すか、本番と同じ値にそろえます。 ### PHPCompatibilityで非互換箇所を静的に検出するコマンド 次に、自社コードの中で移行先の版で動かなくなる箇所を探します。[PHPCompatibility](https://github.com/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への移行ガイド](https://www.php.net/manual/ja/migration84.php)のような公式の移行ガイドで確認します。 ### Rectorで構文を書き換える設定とPHPStanでの確認の順序 検出した箇所のうち機械的に直せるものは、[Rectorのセット一覧](https://getrector.org/documentation/set-lists)にある版別のルールで書き換えます。プロジェクトの直下に`rector.php`を置きます。 ``` 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のレベル運用とベースライン](https://www.issoh.co.jp/tech/details/12338/)で確認し、最後に既存のテストを流します。Rectorは構文を直すだけで、挙動の変化までは保証しないためです。 ### 公式Dockerイメージのタグをパッチ版まで固定する検証環境の作成手順 動作確認に使うのは、移行先の版を固定した検証環境です。[公式Dockerイメージの定義リポジトリ](https://github.com/docker-library/php)には、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も[公式の動作要件](https://wordpress.org/about/requirements/)で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日に間に合わない原因になります。一創の[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)では、PHPで作られた既存システムの調査から版上げ、その後の運用の引き継ぎまでが支援の対象です。WordPressサイトの場合の運用体制は[WordPress保守運用の作業範囲と内製か外注かの判断基準](https://www.issoh.co.jp/column/details/15799/)で整理しています。 ## 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`で依存の状況を調べ、作業量を見積もるところから始めます。 ## 関連記事 - [PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版・更新できない場合の設定](https://www.issoh.co.jp/tech/details/18738/)：期限切れの系列が実際にどんな危険にさらされたかを確認できます。 - [PHP 8.5の変更点と新機能まとめ](https://www.issoh.co.jp/tech/details/8179/)：8.5を移行先にする場合の非推奨と移行の注意点をまとめています。 - [Laravelのバージョン確認｜artisanとcomposerの違いとサポート期限](https://www.issoh.co.jp/tech/details/17116/)：フレームワーク側の期限をコマンドで確かめる手順です。 - [PHP開発の始め方｜環境構築・フレームワーク選定・システム開発の進め方](https://www.issoh.co.jp/tech/details/1316/)：版上げを機に開発環境を見直す場合の出発点になります。 - [PHPStanとは？レベル0〜10の違いと導入・ベースライン運用](https://www.issoh.co.jp/tech/details/12338/)：版上げ後の型の不整合を検出する手順を解説しています。 --- 出典: [PHPのサポート期限一覧：8.2は2026年末で終了、版ごとのEOLと移行手順【2026年10月】]()（株式会社一創）