WEBサイトPHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）
PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）
目次
01 何が起きたか — PHP 8.2のセキュリティサポートが、2026年12月31日で終わる
公式の表の日付
PHPの公式サイトの「Supported Versions」（訳: サポートされている版）のページを、2026年10月9日に開いて確かめた。ページに更新日は載っていないため、次の日付は、2026年10月9日に確認した値である。8.2の行には、セキュリティサポートの終了日として、2026年12月31日が書かれている。この日まで、2026年10月9日から数えて83日である（この記事の計算）。
| 枝 | 最初の公開 | 積極的サポートの終了 | セキュリティサポートの終了 | 最新の点の版 |
|---|---|---|---|---|
| 8.2 | 2022年12月8日 | 2024年12月31日 | 2026年12月31日 | 8.2.34 |
| 8.3 | 2023年11月23日 | 2025年12月31日 | 2027年12月31日 | 8.3.35 |
| 8.4 | 2024年11月21日 | 2026年12月31日 | 2028年12月31日 | 8.4.26 |
| 8.5 | 2025年11月20日 | 2027年12月31日 | 2029年12月31日 | 8.5.11 |
右端の「最新の点の版」は、公式の配布のデータ（JSON）で確かめた。4つとも、公開日は2026年9月24日で、種類の印は「security」（訳: セキュリティ）だった。
8.4の「積極的サポート」も、同じ日に終わる
表を横に読むと、2026年12月31日に終わるのは、8.2のセキュリティサポートだけではない。8.4の積極的サポートも、同じ日に終わる。8.4に上がっても、2027年からは、バグの修正が止まり、セキュリティの修正だけの段階に入る。8.3は、積極的サポートがすでに2025年12月31日に終わっている。
8.6は、まだ試験の段階
公式サイトのトップには、「PHP 8.6.0 RC3 available for testing」（訳: PHP 8.6.0 RC3が試験用に公開された）という告知が出ていた。続きには、「The next release will be RC4, planned for 22 October 2026.」（訳: 次の版はRC4で、2026年10月22日を予定している）と書かれている。取得したページに、8.6の正式の公開日は載っていなかった。この記事は、日付を推測で書かない。RCは本番で使う版ではないため、移行先の候補には入れない。
02 なぜ・背景 — 公式は「2年＋2年」で版を終わらせる
2年は積極的に、次の2年はセキュリティだけ
公式のページは、サポートの仕組みを、次のように書いている。
"Each release branch of PHP is fully supported for two years from its initial stable release."
（訳: PHPの各枝は、最初の安定版の公開から2年間、全面的にサポートされる。）
"After this two year period of active support, each branch is then supported for two additional years for critical security issues only."
（訳: この2年間の積極的サポートのあと、各枝は、さらに2年間、重大なセキュリティの問題に限って、サポートされる。）
8.2は、2022年12月に出て、2024年12月31日までが積極的、2026年12月31日までがセキュリティだけである。いまの8.2は、すでにセキュリティだけの段階にある。
セキュリティだけの段階では、修正が出ないこともある
公式のページは、この段階の修正の出方も書いている。
"Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports."
（訳: この期間のリリースは、必要に応じて出される。報告の数によって、点の版が複数出ることも、1つも出ないこともある。）
つまり、サポート終了日の前でも、修正が定期的に届く保証はない。終了日は、「その日まで安心」ではなく、「その日で修正が止まる」日である。
終わったあとは、修正が届かない
公式のページの凡例は、終了した版を、次のように書いている。
"A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities."
（訳: もうサポートされない版。この版の利用者は、修正されていないセキュリティの弱点にさらされるおそれがあるため、できるだけ早く上げるべきである。）
終了した枝の一覧のページ（2026年10月9日に確認）では、8.1が2025年12月31日、8.0が2023年11月26日、7.4が2022年11月28日に終わっている。8.1以前の版を使っているサイトは、すでに終了の日を過ぎている。
WordPressは、8.3以上を勧めている
WordPressの公式の要件のページは、勧める版を「PHP version 8.3 or greater.」（訳: PHPの版は8.3以上）と書いている。PHPの更新を促すページも、「現在は8.3以上」と書いている。要件のページは、古い版でも動くことを認めつつ、動くことと、安全なことは別だと書いている。
"However, these versions have reached their official End Of Life and may expose your site to security vulnerabilities."
（訳: しかし、これらの版は公式のサポートが終わっており、サイトをセキュリティの弱点にさらすおそれがある。）
03 用語 — 読み違えやすい言葉を先にそろえる
積極的サポートとセキュリティサポート
用語
積極的サポート（Active support）：報告されたバグとセキュリティの問題が直され、定期的に点の版が出る段階である。セキュリティサポート（Security support）：重大なセキュリティの問題に限って、必要なときだけ点の版が出る段階である。公式の凡例は、後者を「Security fixes only」（訳: セキュリティの修正だけ）と呼んでいる。
枝・点の版・EOL
用語
枝（branch）：8.2や8.3のように、2つ目までの数字で区切った、版の系列である。点の版：8.2.34のように、枝の中で出る、修正の版である。EOL（End of life）：枝のサポートが終わり、修正が出なくなることである。PHP 8.2.34のような点の版を最新に保つことと、8.2から8.3に枝を上げることは、別の作業である。
非推奨（Deprecated）
用語
非推奨：いまは動くが、将来の版で使えなくなる予定の書き方である。実行すると、警告が出る。公式の移行の手引きは、版ごとに「Deprecated Features」（訳: 非推奨の機能）の一覧を載せている。
04 型別 — 版の確かめ方を、3つの立場に分ける
🅰 適用範囲 — PHPで動いているサイトが対象
この記事が対象にするのは、PHPで動いているサイトである。WordPressをはじめ、PHPで作られたCMSや、自作のPHPのサイトが含まれる。PHPを使っていない静的なサイトには、この表は関係しない。
🅱 公式が書いていないことと、この記事が確かめていないこと
php.netの表には、レンタルサーバー会社や、パッケージの配布元が、独自に修正を当てるかどうかが載っていない。その扱いは、この記事では確かめていない。サーバー会社に、8.2のサポートを、いつまで続けるかを、文書で聞く。表には「in 2 months」のような、開いた日で変わる相対の表示も出る。書き写すのは、日付そのものである。
🅲 手順1-A — サーバーに入れる人は、コマンドで読む
コマンドラインでは、php -vが、版を表示する。公式の説明は、この指定を「Using -v to get the SAPI name and the version of PHP and Zend」（訳: -vで、SAPIの名前と、PHPとZendの版を得る）と書いている。表示の先頭には、版の数字のあとに、cliのようなSAPIの名前が出る。コマンドラインで出る版は、サイトを動かしている版と同じとは限らない。サイトを動かしている側の版は、別に確かめる。
サイトの側から確かめる関数もある。公式の説明は、phpversion()を、「Returns a string containing the version of the currently running PHP parser or extension.」（訳: いま動いているPHPの処理系か拡張の版を、文字列で返す）と書いている。確認用に1枚のファイルを置く場合は、読み終えたら、そのファイルをすぐ消す。版を外から読める状態を、残さないためである。
🅲 手順1-B — 管理画面だけの人は、サイトヘルスを見る
WordPressの場合、公式のページは、確かめ方を、次のように書いている。
"To check what version of PHP your WordPress site is using, from the WordPress Dashboard, select Tools > Site Health from the sidebar menu, and then select the Info tab. Expand the Server section and scroll down until you see PHP version."
（訳: WordPressのサイトが使っているPHPの版を確かめるには、ダッシュボードの左のメニューから「ツール」の「サイトヘルス」を選び、「情報」のタブを選ぶ。「サーバー」の欄を開き、「PHPバージョン」が出るまで下へ進む。）
サイトヘルスの公式の説明は、版が古い場合の警告の文言を、「Your site is running an outdated version of PHP, which requires an update」（訳: サイトは古い版のPHPで動いており、更新が必要である）と載せている。WordPress以外のCMSや、レンタルサーバーの管理画面の場合は、PHPの版を選ぶ欄の名前が、会社ごとに違う。この記事は、会社ごとの画面を確かめていない。欄が見つからなければ、次の手順1-Cに回る。
🅲 手順1-C — 任せている人は、5つの質問を送る
制作会社やサーバー会社に任せている場合は、聞く質問を決める。次の5つを、1通にまとめて送る。
- どのサイトが、いま、どのPHPの版で動いているか。
- その版のサポートは、いつ終わるか。
- 2026年12月31日より前に、移行する予定日はいつか。
- 移行の前に、試験の環境で確かめる予定はあるか。
- 問題が出たときに、元の版に戻す手順と、担当は誰か。
返事に版の数字が無ければ、数字を書いて返してもらうよう、もう1回聞く。
| 立場 | 開く場所 | 見るもの |
|---|---|---|
| サーバーに入れる | コマンドラインと、サイトの側の確認 | 版の数字と、SAPIの名前 |
| 管理画面だけ | サイトヘルスの「情報」の「サーバー」 | PHPバージョンの数字 |
| 任せている | 制作会社やサーバー会社への質問 | 版・終了日・移行の予定日の3つ |
🅲 手順2 — 読んだ版を、終了日と突き合わせる
版が分かったら、表の「セキュリティサポートの終了」と突き合わせて、サイトごとに終了日と、今日からの日数を書く。8.2なら2026年12月31日までの日数、8.1以前なら「すでに終了」と書く。終了済みのサイトは、公式のページの言葉どおり、「strongly urged to upgrade」（訳: 強く上げることを勧める）対象である。
🅲 手順3 — 移行先の枝を、日付と対応状況で選ぶ
移行先の候補は、8.3・8.4・8.5である。表のとおり、セキュリティサポートの終了は、8.3が2027年12月31日、8.4が2028年12月31日、8.5が2029年12月31日である。2026年10月9日から数えて、8.3の終了日まで448日（この記事の計算）である。新しい枝ほど、サポートは長い。一方、WordPressの公式のページは、新しい版でテーマやプラグインが動くかは、分からないとしている。
"WordPress itself works with PHP as far back as version 7.4, but we don’t know if your themes or plugins will work on newer versions."
（訳: WordPress本体は、PHP 7.4まで遡って動くが、テーマやプラグインが新しい版で動くかどうかは、分からない。）
そのため、選ぶ基準は2つに絞る。使っている部品がすべて対応を書いている、最も新しい枝にする。対応が書かれていない部品があれば、その部品の更新か、代わりの部品を、先に決める。
🅲 手順4 — 移行の前に、変わる点を公式の手引きで確かめる
公式の8.2から8.3への移行の手引きは、冒頭に、次のように書いている。
"This new minor version brings with it a number of new features and a few incompatibilities that should be tested for before switching PHP versions in production environments."
（訳: この新しい小さな版には、多くの新機能と、少数の非互換が含まれる。本番の環境で版を切り替える前に、試験しておくべきである。）
手引きの具体例は、たとえば、8.3で「The opcache.consistency_checks INI directive was removed.」（訳: opcache.consistency_checksのINIの設定が削除された）とある。8.4の手引きの「Deprecated Features」には、次の項目がある。
"A parameter's type is implicitly widened to accept null if the default value for it is null."
（訳: 引数の型は、既定値がnullなら、nullも受け付けるように、暗黙のうちに広げられる。）
この項目は、型を書き、既定値をnullにした引数を持つコードの書き方が、非推奨になったことを示している。自作のコードや、古いプラグインに、この形が無いかは、試験の環境で実行して初めて分かる。確かめ方は、手順5に書いた。
🅲 手順5 — 試験の環境で、画面を1つずつ開く
WordPressの公式のページは、更新の前の準備として、バックアップを、次のように書いている。
"Make a backup of your website: a backup will let you revert your site to how it is right now in the event anything goes wrong."
（訳: サイトのバックアップを取る。何か問題が起きたときに、サイトをいまの状態に戻せるようになる。）
同じページは、部品の確認に、PHP Compatibility Checkerというプラグインを挙げ、「This plugin isn’t perfect and may miss items or flag false positives, but it does work in most cases.」（訳: このプラグインは完全ではなく、見落としや誤検出もありうるが、ほとんどの場合に働く）と注意している。Composerを使っているサイトでは、公式の説明のcheck-platform-reqsが、「checks that your PHP and extensions versions match the platform requirements of the installed packages」（訳: PHPと拡張の版が、導入した部品の要件に合っているかを調べる）とある。
試験の環境では、移行先の版で、画面を1つずつ開く。トップページ、問い合わせ、ログイン、購入や予約の画面（ある場合）を、「表示できた」か「エラー」かで書く。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1・2が洗い出し、項目3〜5が手順1、項目6〜8が手順2、項目9〜11が手順3・4、項目12・13が手順5に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- PHPで動いている自社のサイトを、すべて書き出し、サイトの数をメモに書く
- サイトごとに、版を確かめる人（自分・制作会社・サーバー会社）を、1行ずつ書く
- WordPressのサイトは、ツールのサイトヘルスの「情報」の「サーバー」を開き、PHPバージョンの数字を、そのまま書く
- WordPress以外のサイトは、サーバーの管理画面でPHPの版を選ぶ欄を開き、表示されている数字を書く（欄が無ければ「なし」と書く）
- 画面で確かめられないサイトは、制作会社かサーバー会社に、版を数字で教えてもらうよう質問を送り、送った日付を書く
- 書いた版を、公式の表の「Security Support Until」の日付と突き合わせ、サイトごとに終了日を、「2026年12月31日」の形で書く
- 8.2のサイトについて、今日から2026年12月31日までの日数を数え、数字で書く
- 8.1以前のサイトがあれば、「すでに終了」と書き、一覧の先頭に移して、印を付ける
- 使っているプラグインとテーマを一覧にし、PHPの対応する版が公式のページで確かめられない部品の数を数えて、書く
- Composerを使っているサイトは、試験の環境で
composer check-platform-reqsを実行し、結果を「通った」か「通らなかった」かで書く - 移行先の枝を、8.3・8.4・8.5から1つ選び、理由を、終了日と部品の対応状況の2点で、1行で書く
- 試験の環境で、移行先の版を使い、トップページ・問い合わせ・ログインの3画面を開いて、「表示できた」か「エラー」かを、画面ごとに書く
- 本番の切り替え日と、元の版に戻す担当者と、バックアップを取る日を、2026年12月31日より前の日付で決め、カレンダーに登録して、登録した日を書く
時間が限られているときは、項目1・3・6・7の4つだけでも、「どのサイトが」「どの版で」「いつ終わるか」「あと何日か」は分かる。
06 代替・他の選択肢 — 今すぐ上げられないときと、上げたあとのこと
年内に移行できない事情があるとき
部品の対応が間に合わないときは、上げられない理由と、いつまでに解消するかを、日付つきで書き出す。8.2のまま年を越す場合は、2027年1月1日から修正が届かない版で動くことになる。公式の終了済みの版のページも、上げることを「strongly urged」としている。その間の、通信の制限などの代わりの対策が効くかは、この記事では確かめていない。
8.3に上げる場合と、8.4・8.5に上げる場合
8.3は、WordPressが勧める版の下限で、2027年12月31日までセキュリティの修正が出る。ただし、積極的サポートは、すでに終わっている。8.4・8.5は、サポートが長い。どちらを選んでも、移行は1回で終わらず、数年ごとに繰り返す。年の終わりに、版とサポートの終了日を確かめる日を、毎年のカレンダーに入れておく。
確認の手がかりになる、当サイトの無料ツール
移行の試験のあと、サイト内のリンクを一通り開くには、当サイトの無料ツール🔧 WEBサイト内のリンク漏れ・チェックツールが使える。移行の前後の状況を比べるには、ログインして使う🔧 WEBサイトの状況チェック・比較ツールが手がかりになる。どちらも、PHPの版やサポートの終了日を判定するツールではない。
注意
版を確かめるための確認用のファイルは、読み終えたらすぐ消す。また、本番の切り替えは、年末年始の連休の直前に置かない。戻す担当者が、連絡のつく日にする。
サーバーのソフトの版を確かめる、同じ型の記事として、当サイトの記事「Apache HTTP Server 2.4.69が10月1日に出た。セキュリティの修正は20件で、重大度は「中」5件・「低」15件 ── 自社のサーバーの版と、使っている機能が当たるかを確かめる14項目（2026年10月時点）」と「WordPress 7.1.3の7件の修正は、それぞれ別の機能に当たる ── 自社のWordPressで使っている機能と突き合わせて確かめる13項目（2026年10月時点）」がある。この記事は、その内容を繰り返さない。
07 当サイトで確かめたこと
公式の表と、配布のデータを開いた
2026年10月9日に、PHPの公式サイトの、サポートされている版の表、終了した枝の一覧、各枝の配布のデータ（JSON）を開いた。表の日付は、この記事の表のとおりである。配布のデータでは、最新の点の版が、8.2.34・8.3.35・8.4.26・8.5.11で、4つとも2026年9月24日付だった。公式のトップでは、8.6.0がRC3の段階で、次のRC4は2026年10月22日の予定だった。
言えるのは、2026年10月9日の時点の、公式の日付と、最新の版である。言えないのは、サーバー会社や配布元が、独自の修正を当てているかどうかである。
当サイトでも、同じ確認をした
当サイトも、この記事の手順1と手順2で、自分たちの環境を確かめた。
公式の表を開いたときに、表示が相対の言い方（「in 2 months」）と日付の両方で出ることに気づいた。この記事の日付は、日付そのものを書き写した。この確認の型は、当サイトの記事「記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった」で書いた、公開した日にチェック項目を自分のサイトに当てる進め方と同じである。
08 このテーマの、これまで
終了した枝と、これから終わる枝
| 日付 | 枝 | できごと |
|---|---|---|
| 2022年11月28日 | 7.4 | サポートが終了した（最後の点の版は7.4.33） |
| 2023年11月26日 | 8.0 | サポートが終了した（最後の点の版は8.0.30） |
| 2025年12月31日 | 8.1 | サポートが終了した（最後の点の版は8.1.34） |
| 2026年12月31日 | 8.2・8.4 | 8.2のセキュリティサポートと、8.4の積極的サポートが終わる |
| 2027年12月31日 | 8.3・8.5 | 8.3のセキュリティサポートと、8.5の積極的サポートが終わる |
表の上3行は、公式の終了した枝の一覧による。下2行は、公式の表の日付をそのまま並べたものである。
当サイトの、関連する過去の記事
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 確認項目を、自分のサイトに当てた話。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面の読み違いの話。
- Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日 — 通知を溜めていた話。
- 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — 測定の約束を、測り直す話。
- 警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった — 大量の警告の中の本物の話。
現在の貴方のIPアドレス
このサイトで書いている人
