サポート終了したPHPを使い続けるリスクと現実的な対策

PHPのサポート期間の仕組み

PHPの各ブランチ（8.3、8.4 など）には、公式に2段階のサポート期間が設けられています。

• アクティブサポート：バグ修正とセキュリティ修正の両方が提供される期間
• セキュリティサポート：重大なセキュリティ問題の修正のみが提供される期間

セキュリティサポートの期限を過ぎたブランチは「サポート終了（End of Life）」となり、以後は脆弱性が見つかっても公式の修正版はリリースされません。PHP公式サイトの表を見ると、各ブランチはリリースからおおむね4年後の12月31日にセキュリティサポートが終了しています。

現在サポートされているバージョン（2026年10月23日時点）

出典：PHP: Supported Versions（php.net）

一方、PHP 8.1 は2025年12月31日、PHP 8.0 は2023年11月26日、PHP 7.4 は2022年11月28日にそれぞれサポートが終了しています。PHP 7.3 以前や 5.x 系も、すでに数年前にサポートが終わっています（出典：PHP: Unsupported Branches（php.net））。

特に注意したいのが PHP 8.2 です。セキュリティサポートは2026年12月31日までで、本記事の公開時点から残り約2か月です。8.2で稼働しているシステムは、今のうちに 8.3 以降への移行計画を立てておくことをおすすめします。

サポート終了したPHPを使い続ける4つのリスク

1. 新たな脆弱性が修正されない

最大のリスクは、EOL版で新しい脆弱性が見つかっても公式の修正版が出ないことです。PHP本体の問題はアプリケーション側のコードを丁寧に書いても防げない場合があり、「自社のプログラムに問題がないから大丈夫」とは言い切れません。なお、Linuxディストリビューションの中には、自社で配布するPHPパッケージに独自にセキュリティ修正を提供しているものもあります。ご利用中のOSとパッケージがその対象かどうか、まず確認しておきましょう。

直近で報告されているPHPの脆弱性と対処方法については、PHP脆弱性対策の特設ページで最新情報をまとめています。

2. フレームワーク・ライブラリが追随できなくなる

Laravel や Symfony などのフレームワーク、Composer で導入している各種ライブラリは、新しいバージョンほど古いPHPへの対応を打ち切っていきます。その結果、ライブラリ側で脆弱性が修正されても、古いPHPのままでは修正版を導入できないという状況が起こります。PHP本体だけでなく、依存ライブラリ全体が「更新できない状態」に固まってしまうことが、EOL版の見落とされがちなリスクです。

3. サーバー・OS・クラウドの選択肢が狭まる

新しいOSやレンタルサーバー、マネージドサービスでは、古いPHPがそもそも提供されていないことがあります。サーバーの保守期限切れやハードウェア更新のタイミングで「移行先で動かない」ことが判明し、計画外の改修が必要になるケースは珍しくありません。

4. 取引先や監査への説明が難しくなる

セキュリティチェックシートや監査で、利用ソフトウェアのサポート状況を問われることが増えています。EOL版を使っている場合、その理由と代替となる対策を説明できる状態にしておくことが求められます。

まず確認すべき現状把握のポイント

対策を検討する前に、次の項目を洗い出しておくと、見積りや判断が格段に正確になります。

• 本番・検証・バッチ用など、すべてのサーバーのPHPバージョン（php -v で確認可能）
• 利用しているフレームワークとそのバージョン、composer.json / composer.lock の有無
• 独自に追加しているPHP拡張モジュールや、外部サービスとの連携部分
• cron などで定期実行されているスクリプト（画面からは見えないため漏れやすい部分です）
• 自動テストの有無と、手動で確認すべき主要な業務シナリオ
• システムの改修ができる担当者や開発会社が、今も対応可能かどうか

現実的な対策の選択肢

選択肢1：段階的なバージョンアップ

多くのケースで第一候補となるのが、サポート中のバージョンへのアップグレードです。ただし、PHP 7系から 8系への移行では、文字列と数値の比較ルールの変更や、これまで警告だった処理のエラー化など、動作に影響する変更が含まれます。公式の移行ガイド（PHP 7.4.x から PHP 8.0.x への移行）に後方互換性のない変更点が一覧化されているので、影響範囲の見積りに活用できます。

バージョンの差が大きい場合は、一度に最新版へ上げるよりも、フレームワークの対応バージョンを確認しながら段階的に上げるほうが、問題の切り分けがしやすく安全です。

選択肢2：移行完了までの暫定的な防御

改修に時間がかかる場合は、バージョンアップと並行してリスクを下げる手当てを行います。これは根本対策ではなく、あくまで移行完了までの「時間を稼ぐ」ための措置です。

• WAF（Web Application Firewall）の導入やルールの見直し
• 管理画面へのアクセスをIPアドレスやVPNで制限する
• 使われていない機能・ページ・アップロード機能を停止する
• phpinfo() を出力するファイルなど、不要な情報公開を削除する
• ログ監視とバックアップの取得状況を確認し、異常時に復旧できる体制を整える

選択肢3：作り直し・パッケージへの置き換え

独自のフレームワークで作られている、ソースコードの所在がはっきりしない、業務自体が変わっている――といった場合は、バージョンアップよりも作り直しやSaaSへの置き換えのほうが総コストを抑えられることがあります。判断の進め方はレガシーシステム移行の進め方の記事でも詳しく解説しています。

バージョンアップを安全に進める手順

1. 棚卸し：上記の現状把握の項目を一覧にし、対象範囲を確定します。
2. 静的解析で影響を洗い出す：PHP_CodeSniffer の PHPCompatibility ルールや PHPStan などのツールで、新バージョンで問題になる箇所を機械的に抽出します。Rector を使うと、一部の書き換えを自動化できます。
3. 検証環境の構築：本番と同じ構成で新バージョンのPHPを動かせる環境を用意します。コンテナを使うと、複数バージョンの比較も容易です。
4. 修正と回帰テスト：主要な業務シナリオを中心に、修正前後で同じ結果になるかを確認します。
5. 本番切り替えとロールバック計画：切り替え手順と、問題が出たときに元へ戻す手順を事前に決め、影響の少ない時間帯に実施します。

経営層へ説明するときのポイント

PHPのバージョンアップは、画面や機能が変わらないため投資効果が見えにくく、後回しにされがちです。説明の際は「何が起きる可能性があるか」と同時に、「いつまでに・いくらで・どこまでリスクを下げられるか」をセットで示すと判断を得やすくなります。公式のサポート期限という客観的な日付があるため、計画の根拠として使いやすいのもポイントです。

まとめ

• 2026年10月23日時点で公式にサポートされているのは PHP 8.2〜8.5。8.2 は2026年12月31日でセキュリティサポートが終了します。
• EOL版では脆弱性が修正されないだけでなく、ライブラリやサーバー環境の更新も難しくなります。
• 対策は「段階的バージョンアップ」を基本に、必要に応じて「暫定防御」や「置き換え」を組み合わせます。
• まずは全サーバーのバージョンと依存関係を棚卸しすることが、正確な計画への第一歩です。

コエラーン・テクノロジー（Koelearn Technology）では、古いPHPで稼働するシステムの診断から、暫定防御、段階的なバージョンアップ、その後の長期保守まで一貫してご支援しています。詳しくはPHP脆弱性対策サービスおよび長期運用保守をご覧ください。