この記事の要約
PHP 8.2サポート終了の期限は2026年12月31日で、以降は新たな脆弱性が見つかっても公式の修正版が提供されません。本記事では、サポート終了の意味と放置した場合の5つのリスク、本番以外も含めたPHP環境の棚卸し方法を整理します。そのうえで「バージョンアップ」「延命」「モダナイゼーション」の3つの対応パターンを判断フロー付きで比較し、業務システム向けの移行6ステップを解説します。期限に間に合わない場合の暫定策と、経営層・監査への説明ポイントもあわせて紹介します。
PHP 8.2サポート終了は2026年12月31日です。 この日を過ぎると、PHPの公式プロジェクトからセキュリティ修正が提供されなくなり、新しい脆弱性が見つかっても自社で対処するしかありません。
PHP 8.2で稼働する業務システムは、次の3つのいずれかを選ぶ必要があります。
- PHP 8.4以降へのバージョンアップ
- 延長サポートや隔離による一時的な延命
- フレームワークやアーキテクチャを含めたモダナイゼーション
どれが適切かは、システムの規模、フレームワークのバージョン、技術的負債の大きさによって変わります。本記事では、2026年10月の重大脆弱性「PHP2Shell」への対応を終えた企業が「次に何をすべきか」を、実務の流れに沿って解説します。
1. PHP 8.2サポート終了とは？いつまで使えるのか
まずは「サポート終了」が具体的に何を意味するのかを確認しましょう。PHPのサポートには2つの段階があり、PHP 8.2はすでに最終段階に入っています。
1-1. アクティブサポートとセキュリティサポートの違い
PHPの各バージョンは、リリース後に次の2段階のサポートを受けます。2024年3月にリリースサイクルが見直され、現在は合計4年間です。
- アクティブサポート（2年間）：バグとセキュリティ問題の両方が修正され、定期的に修正版がリリースされます。
- セキュリティサポート（2年間）：重大なセキュリティ問題のみ、必要に応じて修正されます。
両方の期間が終わると「End of Life（EOL）」です。PHP公式のサポートバージョン一覧でも、EOLのバージョンを使い続けると修正されない脆弱性にさらされる可能性があるため、できるだけ早くアップグレードすべきと明記されています。
1-2. PHPバージョン別サポート期限一覧（7.4〜8.6）
では、各バージョンのサポート期限を一覧で確認しましょう。2026年11月時点の状況は次のとおりです。
| バージョン | リリース日 | アクティブサポート終了 | セキュリティサポート終了 | 状態 |
|---|---|---|---|---|
| PHP 7.4 | 2019年11月28日 | 2021年11月28日 | 2022年11月28日 | 終了 |
| PHP 8.0 | 2020年11月26日 | 2022年11月26日 | 2023年11月26日 | 終了 |
| PHP 8.1 | 2021年11月25日 | 2023年11月25日 | 2025年12月31日 | 終了 |
| PHP 8.2 | 2022年12月8日 | 2024年12月31日 | 2026年12月31日 | まもなく終了 |
| PHP 8.3 | 2023年11月23日 | 2025年12月31日 | 2027年12月31日 | セキュリティ修正のみ |
| PHP 8.4 | 2024年11月21日 | 2026年12月31日 | 2028年12月31日 | サポート中 |
| PHP 8.5 | 2025年11月20日 | 2027年12月31日 | 2029年12月31日 | サポート中 |
| PHP 8.6 | 2026年11月19日（予定） | 2028年12月31日（見込み） | 2030年12月31日（見込み） | リリース予定 |
出典：php.net「Supported Versions」。PHP 8.6の期限は、現行のリリースサイクル（2年＋2年）から算出した見込みです。
1-3. 2027年1月以降に起こること・起こらないこと
上の表のとおり、PHP 8.2はすでにバグ修正が止まり、セキュリティ修正だけを受けている状態です。2027年1月以降は、そのセキュリティ修正も提供されなくなります。
ただし、サポートが終わってもPHP 8.2が突然動かなくなるわけではありません。 問題は、動き続けるシステムの中で「修正されない脆弱性」が少しずつ積み上がっていくことです。
なお、PHP2Shellでは一部の旧バージョン向けにも例外的な修正が行われました。しかし、次の重大脆弱性でも同じ対応がある保証はありません。 PHP 8.2サポート終了後は「公式の修正は来ない」前提で計画を立てる必要があります。
2. PHP 8.2サポート終了を放置する5つのリスク
「今は問題なく動いているから」と様子を見る企業も少なくありません。しかし、PHP 8.2サポート終了を放置すると、次の5つのリスクが時間とともに大きくなります。
2-1. 新たな脆弱性に公式パッチが提供されない
2026年10月に公開された重大脆弱性「PHP2Shell」は、ログイン不要で遠隔から悪用でき、実際の攻撃も確認されました。このときPHP 8.2はサポート期間内だったため、修正版の8.2.35が提供されています。
同じような脆弱性がPHP 8.2サポート終了後に見つかれば、原則として修正版は提供されません。 取れる手段は、自前のバックポート、隔離、移行に限られます。
2-2. フレームワーク・ライブラリのサポート切れが連鎖する
影響はPHP本体だけにとどまりません。業務システムの多くはフレームワークや外部ライブラリの上に成り立っており、それらも順次PHP 8.2を対象外にしていきます。
たとえばLaravelの公式サポートポリシーは次のとおりです。
| Laravel | 対応PHP | セキュリティ修正の期限 |
|---|---|---|
| Laravel 10 | 8.1〜8.3 | 2025年2月4日（終了） |
| Laravel 11 | 8.2〜8.4 | 2026年3月12日（終了） |
| Laravel 12 | 8.2〜8.5 | 2027年2月24日 |
| Laravel 13 | 8.3〜8.5（8.2は非対応） | 2028年3月17日 |
CakePHPも、2系は2021年6月にセキュリティサポートが終了しています。PHP本体を更新したくても、フレームワークが古いために更新できない、というケースは珍しくありません。
2-3. OS・ホスティング側で強制的に切り替わる
レンタルサーバーやPaaSでは、サポートが終わったPHPバージョンの提供を順次終了するのが一般的です。事業者のスケジュールでPHPが強制的に切り替わり、互換性のないアプリが突然エラーになるリスクがあります。
一方、RHELやUbuntuなどのLinuxディストリビューションに同梱されたPHPは、ベンダーが独自にセキュリティ修正をバックポートしている場合があります。その場合の期限はphp.netではなく、各ベンダーのサポート方針に従います。
2-4. セキュリティ監査や取引先のチェックで指摘される
ISMS（ISO/IEC 27001）の審査や、取引先から届くセキュリティチェックシートでは、サポート切れソフトウェアの利用有無を問われることが一般的です。
また、2022年4月施行の改正個人情報保護法により、一定の個人データ漏えいが起きた場合は個人情報保護委員会への報告と本人への通知が義務となっています。サポート切れのPHPが原因で漏えいが起きれば、管理体制そのものが問われます。
2-5. 先送りするほど移行コストと属人化リスクが膨らむ
PHPのバージョンを一度に複数飛ばすと、仕様変更や非推奨機能の影響が重なり、修正範囲が大きくなります。
さらに、時間が経つほど当時の開発者が退職・異動し、システムのブラックボックス化が進みます。「いつかやる」は、最も高くつく選択肢になりがちです。
【無料・1分】PHPシステムの移行リスクをAIで診断
PHP 8.2サポート終了に向けて、自社システムの依存関係や移行の難易度を把握したい方へ。HBLABのAI Assessmentで、移行リスクをすばやく可視化できます。
3. 自社のPHP 8.2利用状況を棚卸しする方法
リスクを把握したら、次は自社の現状確認です。PHP 8.2サポート終了の影響範囲は、本番サーバーだけを見ても正確にはわかりません。次の4つの観点で棚卸しを進めましょう。
3-1. 本番以外も含めて稼働環境を洗い出す
まずは、PHPが動いているすべての環境をリストアップします。
- 本番環境：Webサーバー、APIサーバー
- ステージング・検証環境：本番と同じバージョンか
- バッチサーバー・社内ツール：見落としやすい代表例
- コンテナ・CI環境：Dockerfileのベースイメージ、CIのPHPバージョン
- 委託先が管理する環境：保守会社やホスティング事業者の管理下にあるサーバー
本番だけ更新して、バッチサーバーやコンテナが古いまま、というケースは珍しくありません。
3-2. PHPのバージョンと拡張モジュールを確認する
環境を洗い出したら、それぞれのPHPバージョンを確認します。サーバー上では php -v でバージョン、php -m で読み込まれている拡張モジュールを確認できます。
注意したいのは、CLIとWebサーバー（PHP-FPMなど）でPHPのバージョンが異なるケースです。Web側のバージョンも必ず確認しましょう。コンテナの場合は、Dockerfileの FROM php:8.2-... などのベースイメージを確認します。
3-3. フレームワークと依存ライブラリの対応状況を確認する
次に、アプリケーション側の対応状況を確認します。composer.json の "require": {"php": ...} の指定と、利用しているフレームワークのバージョンを確認してください。
Composerの次のコマンドも役立ちます。
composer why-not php 8.4：PHP 8.4への更新を妨げているパッケージを一覧表示composer check-platform-reqs：現在の環境が依存パッケージの要件を満たしているかを確認
依存関係の調べ方は「現行システムの依存関係調査｜DB・バッチ・APIの調べ方5ステップ」で詳しく解説しています。
3-4. 棚卸しシートのテンプレート
確認した内容は、次のような一覧にまとめておくと便利です。対応の優先順位付けや、経営層への報告にもそのまま使えます。
| 項目 | 記入例 |
|---|---|
| システム名 | 受発注管理システム |
| 公開範囲 | インターネット公開／社内のみ |
| PHPバージョン（CLI／Web） | 8.2.29 ／ 8.2.29 |
| PHPの入手元 | php.net公式／OS同梱／ホスティング提供 |
| フレームワークとバージョン | Laravel 10 |
| 管理者・委託先 | 情報システム部／保守会社A |
| 対応方針と期限 | バージョンアップ／2027年3月 |
4. 更新・延命・刷新：PHP 8.2サポート終了への3つの対応パターン
棚卸しの結果をもとに、対応方針を決めます。PHP 8.2サポート終了への対応は、大きく次の3パターンに分けられます。
| 比較項目 | A. バージョンアップ | B. 延命 | C. モダナイゼーション |
|---|---|---|---|
| 内容 | PHP 8.4以降へ更新 | 延長サポート・隔離で時間を確保 | フレームワークや構成ごと刷新 |
| 向いているケース | フレームワークがサポート期間内、構成を把握できている | 近く廃止・リプレース予定、期限までの更新が困難 | 古いフレームワーク、ブラックボックス化、今後も改修が続く |
| メリット | 比較的短期間・低コストで対応しやすい | 当面の業務影響を抑えられる | 技術的負債を解消し、長期的な保守コストを下げられる |
| 注意点 | 互換性の確認とテストが必要 | 根本解決にならず、費用が継続する | 投資と期間が大きく、計画が重要 |
4-1. パターンA：PHP 8.4以降へのバージョンアップ
最も一般的な選択肢です。フレームワークがサポート期間内で、システムの構成や依存関係を把握できている場合に向いています。
移行先のバージョンは、次の考え方で選ぶとよいでしょう。
- PHP 8.3：セキュリティサポートは2027年12月31日まで。1年後に再び同じ対応が必要になるため、おすすめしません。
- PHP 8.4：リリースから約2年が経ち、主要なフレームワークやライブラリの対応が進んでいます。安定性を重視するなら第一候補です。
- PHP 8.5：2029年12月31日までサポートされます。ライブラリが対応していれば、より長く使える有力な候補です。
- PHP 8.6：2026年11月19日にリリース予定の最新版です。依存ライブラリの対応状況を確認してから検討しましょう。
4-2. パターンB：延長サポートや隔離による一時的な延命
次に、すぐにバージョンアップできない場合の選択肢です。延命には、主に次の3つの方法があります。
- OSベンダーのバックポートを利用する：ディストリビューションのサポート方針に従い、修正を受け続けます。
- 商用の延長サポートを利用する：サポート終了後のPHP向けに修正を提供する有償サービスです。
- システムを隔離する：社内ネットワークに限定するなど、攻撃を受ける範囲を絞ります。
ただし、延命はあくまで「移行までの時間稼ぎ」です。費用が継続的に発生するうえ、根本的な解決にはなりません。延命を選ぶ場合は、いつまで延命し、いつまでに移行するのかを必ず決めておきましょう。
4-3. パターンC：モダナイゼーション（アーキテクチャ刷新）
最後に、PHPのバージョンだけでなくシステム全体を見直す選択肢です。次のような兆候がある場合は、バージョンアップだけでは問題が解決しません。
- サポートの終わったフレームワーク（Laravel 5系、CakePHP 2系など）を使っている
- 独自フレームワークで、仕組みを理解している人が限られる
- 自動テストがなく、変更の影響を確認できない
- 設計書や仕様書が残っていない
- 今後も機能追加や改修を続ける予定がある
- クラウド移行やシステム連携の強化を予定している
このような場合は、PHP 8.2サポート終了をきっかけに、システム全体のモダナイゼーションを検討するほうが長期的には合理的です。考え方は「システムのモダナイゼーションとは」や「レガシーシステム刷新の進め方」で詳しく紹介しています。
4-4. 判断フロー：自社に合うパターンの選び方
ここまでの内容を、判断フローにまとめると次のようになります。
- 1年以内に廃止・リプレースする予定がある → YES：B. 延命（廃止日までの期限付き）
- NOの場合、フレームワークがサポート期間内で、構成や依存関係を把握できている → YES：A. バージョンアップ
- NOの場合、今後も機能追加や改修を続ける予定がある → YES：C. モダナイゼーション ／ NO：Aで最低限の更新を行い、Cを計画
いずれのパターンでも、2026年末までに作業が終わらない場合は、セクション6の暫定策を並行して実施してください。
PHPシステムの「更新か刷新か」をご相談ください
HBLABは、AIを活用したアセスメントで現行システムを可視化し、バージョンアップ・延命・モダナイゼーションのどれが最適かを判断するところからご支援します。
5. PHPバージョンアップの進め方6ステップ
ここからは、パターンAまたはCを選んだ場合の進め方です。PHP 8.2サポート終了に伴う移行も、基本的には次の6ステップで進めます。移行プロジェクト全体の流れは「マイグレーションの進め方｜アセスメント・AI移行・テストの3段階」もあわせてご覧ください。
Step 1. アセスメントで影響範囲を可視化する
まずは、ソースコードと依存関係を分析し、修正が必要な箇所を洗い出します。PHP_CodeSnifferのPHPCompatibilityルールやPHPStanなどの静的解析ツールを使うと、互換性の問題を効率よく検出できます。
評価すべき項目は「マイグレーション前のソースコード解析｜評価すべき8項目と進め方」が参考になります。
Step 2. 移行先・範囲・優先順位を決める
アセスメントの結果をもとに、移行先のPHPバージョンと、フレームワークの更新を同時に行うかを決めます。複数のシステムがある場合は、インターネットに公開されているシステムや業務への影響が大きいシステムから優先しましょう。
優先順位の付け方は「モダナイゼーションの優先順位と範囲｜着手順を決める3ステップ」で解説しています。
Step 3. 検証環境を用意する
次に、本番と同じ構成の検証環境を用意します。コンテナを使う場合は、公式Dockerイメージのタグを php:8.4.x-fpm のようにパッチバージョンまで固定すると、検証結果の再現性を保てます。
OSのバージョン、拡張モジュール、php.ini の設定も本番とそろえておきましょう。設定の違いによる不具合は、本番リリース後に見つかると原因の特定に時間がかかります。
Step 4. コードと依存ライブラリを修正する
検証環境ができたら、非推奨機能や仕様変更に対応します。PHP 8.2から更新する場合は、たとえば次の点に注意が必要です。
| 移行先 | 主な非推奨・変更点（抜粋） |
|---|---|
| PHP 8.3 | 引数なしの get_class()／get_parent_class() が非推奨／空文字列などへの ++・-- が非推奨／assert_options() が非推奨 |
| PHP 8.4 | 暗黙的なnullable型（function f(T $x = null)）が非推奨／E_STRICT 定数が非推奨／mysqli_ping() などが非推奨／fputcsv() などで escape 引数の既定値への依存が非推奨 |
| PHP 8.5 | バッククォート演算子（shell_exec() の別名）が非推奨／(integer)・(boolean) などの非標準キャストが非推奨／配列のキーに null を使う書き方が非推奨 |
出典：php.net 移行ガイド「Deprecated Features」（8.3／8.4／8.5）。全項目はPHP 8.4の非推奨機能一覧など公式マニュアルで確認してください。
Rectorなどの自動リファクタリングツールを使うと、定型的な修正を効率化できます。あわせて、Composerの依存ライブラリも移行先のPHPに対応したバージョンへ更新します。
Step 5. リグレッションテストで挙動を確認する
修正が終わったら、更新前と同じ動作をするかをテストで確認します。特に、次のポイントは差分が出やすいため重点的に確認しましょう。
- 日付・時刻の処理
- 文字列・文字コードの処理
- 外部APIやデータベースとの連携
- バッチ処理と帳票出力
- レスポンス速度やメモリ使用量などの性能
テストの進め方は「移行のリグレッションテスト｜新旧で挙動が一致するか確かめる方法」をご覧ください。
Step 6. 段階的にリリースし、切り戻し基準を決める
最後に、本番へリリースします。リリース前には、次のGo/No-Goチェックリストで準備状況を確認しましょう。
- ☐ 検証環境で、すべてのテストが合格している
- ☐ 性能が、事前に決めた基準の範囲内に収まっている
- ☐ Deprecated警告がゼロ、または許容する項目を一覧化している
- ☐ 本番データとソースコードのバックアップを取得している
- ☐ 切り戻し手順を、事前にリハーサルしている
- ☐ 切り戻しを判断する条件と責任者を決めている
- ☐ 関係部署と利用者に、作業日時を周知している
リリース後は、エラーログやDeprecated警告を一定期間監視します。リリース後も、PHPは毎年新しいバージョンが出ます。 次の更新に備えた保守体制づくりは「PHP保守とは？脆弱性リスクを最小化する7つの実践」で解説しています。
6. 期限に間に合わない場合の暫定策とロードマップ
PHP 8.2サポート終了まで、残された時間はわずかです。期限までに移行が終わらない場合でも、暫定策と計画の両方を進めることで、リスクを管理できる状態にできます。
6-1. 年内に実施したい5つの暫定策
まずは、年内に次の5つを実施しましょう。
- PHP 8.2の最新パッチを適用する：サポート期間中に出る最後の修正版まで適用します（執筆時点の最新は8.2.35）。
- 公開範囲を絞る：IP制限やVPN経由のアクセスに限定し、攻撃を受ける面を減らします。
- WAF・仮想パッチを導入する：既知の攻撃パターンを入口で遮断します。
- 監視とログを強化する：不審なアクセスやファイル改ざんを早期に検知できるようにします。
- 侵害の有無を確認する：PHP2Shellの公開以降に不審な痕跡がないかを調査します。
暫定策と侵害調査の具体的な手順は「PHP2Shellとは？影響の確認方法と今すぐ取るべき対策・侵害調査手順」で解説しています。
6-2. 2027年前半までの移行ロードマップ例
暫定策と並行して、移行のロードマップを作成します。業務システムを想定した一例は次のとおりです。
| 時期 | 実施内容 |
|---|---|
| 今週中 | 棚卸しの開始、インターネット公開システムの特定、最新パッチの適用状況の確認 |
| 2026年12月31日まで | 暫定策の実施、侵害調査、対応方針の決定、予算と体制の確保 |
| 2027年1月〜3月 | アセスメントの完了、公開システムなど優先度の高いシステムの移行 |
| 2027年4月〜6月 | 残りのシステムの移行、延命策の終了、継続的な保守体制の整備 |
システムの規模や数によって期間は変わります。目安としてご活用ください。
6-3. 経営層・監査に説明するときの4つのポイント
PHP 8.2サポート終了後も一時的に使い続ける場合は、その判断を説明できる状態にしておくことが重要です。社内稟議や監査対応では、次の4点を整理しておきましょう。
- 現状とリスク：どのシステムが、どの範囲に公開され、どんなリスクがあるか
- 暫定策：リスクを下げるために、何をいつ実施したか
- 完了時期：いつまでに、どの方法で移行するか
- 予算と責任者：必要な費用と、対応の責任者は誰か
「知らなかった」ではなく「把握したうえで計画的に対応している」状態をつくることが、監査や取引先への説明で最も大切です。
7. PHPバージョンアップの工数・費用を左右する6つの要因
移行を進めるうえで気になるのが、工数と費用です。PHPのバージョンアップは、システムの状態によって必要な工数が大きく変わります。主な要因は次の6つです。
| 要因 | 工数が増えやすいケース |
|---|---|
| コードの規模 | 行数や画面数が多く、共通処理が散らばっている |
| フレームワークのバージョン | フレームワーク自体も複数バージョン更新が必要 |
| 自動テストの有無 | テストがなく、手動での確認が中心になる |
| 依存ライブラリの数 | 更新が止まったライブラリや、独自改修したライブラリがある |
| 環境の数 | 本番・検証・バッチ・コンテナなど、更新対象の環境が多い |
| ドキュメントの有無 | 設計書がなく、仕様の調査から始める必要がある |
見積もりを依頼する前に、セクション3の棚卸しシートと、ソースコードへのアクセス方法、現在の不具合や改修予定を整理しておくと、精度の高い見積もりを得やすくなります。
なお、HBLABではAIを活用することで、移行に関わる手作業の工数を30〜50%削減し、アセスメントとドキュメント作成の期間を40%短縮した実績があります。
8. HBLABのPHPモダナイゼーション支援
ここまで見てきたように、PHP 8.2サポート終了への対応では、現状把握と方針決定が成否を分けます。HBLABは、アセスメントから移行、移行後の保守運用まで一貫してご支援します。
- AIを活用したアセスメント：独自のAIプラットフォーム「Migurei」で、ソースコード・DB・バッチの依存関係とリスクを分析し、設計書の復元からコード変換、テスト生成までを支援します。
- PHP2Shell影響調査からの継続支援：PHP2Shellアセスメントサービスで影響範囲を確認し、そのまま移行計画へつなげられます。
- 移行後の保守運用まで対応：マネージドサービスで、24時間365日の監視と継続的な脆弱性対応を提供します。
- 品質とセキュリティの体制：CMMI Level 3、ISO/IEC 27001:2022を取得しています。
PHP 8.2サポート終了の対応方針、まずは無料でご相談ください
「バージョンアップで足りるのか、刷新すべきか判断できない」「期限までに間に合うか不安」という段階からご相談いただけます。
9. PHP 8.2サポート終了に関するよくある質問
PHP 8.3へのバージョンアップでも問題ありませんか？
動作上は問題ありませんが、PHP 8.3のセキュリティサポートは2027年12月31日に終了します。1年後に再び対応が必要になるため、PHP 8.4以降への移行をおすすめします。
2026年11月リリース予定のPHP 8.6を選ぶべきですか？
最も長くサポートを受けられる一方、リリース直後は依存ライブラリやフレームワークの対応が追いついていないことがあります。業務システムでは、まずPHP 8.4または8.5を検討し、8.6はライブラリの対応状況を確認してから選ぶのが現実的です。
8.2.35に更新すれば、年明け以降も使い続けられますか？
8.2.35はPHP2Shellなど既知の脆弱性を修正した版ですが、2027年以降に見つかる脆弱性は修正されません。最新パッチの適用は暫定策であり、移行の代わりにはなりません。
WordPressサイトもPHP 8.2サポート終了の影響を受けますか？
はい。WordPressはPHP上で動作するため、サーバーのPHPが8.2であれば対象です。更新前に、テーマやプラグインが移行先のPHPに対応しているかを確認してください。
開発会社と連絡が取れない場合はどうすればよいですか？
開発会社が不在でも、ソースコードとサーバーにアクセスできれば移行は可能です。HBLABでは、他社が開発したPHPシステムでも、ソースコード解析から現状を把握し、移行や保守を引き継ぐことができます。
まとめ
PHP 8.2のセキュリティサポートは2026年12月31日に終了し、以降は新たな脆弱性に公式の修正版が提供されません。まずは本番以外の環境も含めてPHPのバージョンと依存関係を棚卸しし、バージョンアップ・延命・モダナイゼーションの中から自社に合う方針を選びましょう。期限に間に合わない場合は、暫定策でリスクを下げつつ、経営層に説明できる移行計画を立てることが大切です。PHP 8.2サポート終了を、システム全体を見直すきっかけとして活用しましょう。
