サポート終了のPHPを使い続けるリスク｜バージョンアップとリプレイスの判断基準

2026年10月のPHP重大脆弱性「PHP2Shell」では、修正版が提供されたのはサポート中のPHP 8.2〜8.5だけでした。それより古いPHPで動くWebサイト・業務システムは「修正が来ない側」に取り残され、対応に追われた会社も多かったはずです。

この記事は、サポートが終了したPHP（またはまもなく終了するPHP）でシステムが動いていると分かった企業の担当者に向けて、放置のリスクと、「バージョンアップ」と「リプレイス（作り直し）」のどちらを選ぶかの判断基準を整理します。今回の騒動そのものへの対応はPHP2Shellの解説と確認手順の記事にまとめています。

結論：どちらを選ぶかは「土台が生きているか」で決まる

正解は一律ではありません。システムの土台（フレームワークと保守体制）が生きていればバージョンアップ、死んでいればリプレイスが基本線です。

• バージョンアップが基本線：LaravelなどのフレームワークやCMSで作られていて、保守・改修が続いており、業務にも合っているシステム

• リプレイスを検討：PHP 7系以前のまま何年も手が入っていない、作った会社と関係が切れている、フレームワークなしの独自実装、業務と機能がズレてきたシステム

• どちらでも先にやること：現状調査。バージョン・構成・改修履歴が分からないままでは、どちらの見積もりも正確に出せません

そして重要な前提がひとつ。「何もしない（延命）」は、もう選択肢に入りません。その理由を次の章から説明します。

まず現状確認：PHPのサポート期限一覧

PHP 8.1以前はすべてサポート終了。現役の8.2も2026年12月31日で終了します。「今どこにいて、期限まで何か月か」をまず把握してください。

出典はPHP公式のサポート期限一覧です。PHPは毎年末に古い系統のサポートが順に終わっていくため、このページは毎年見る価値があります。

ここから導かれる実務上のポイントが2つあります。

• いま8.2へ上げるのは悪手です。移行した2か月後にまたサポート切れになります。これから上げるなら、期限が2028年末の8.4、または2029年末の8.5が候補です。

• 自社のバージョンが分からない場合は、保守会社・サーバー会社への確認から始めてください。確認の依頼文は前回の記事のテンプレートがそのまま使えます。

「動いているから大丈夫」が通用しない理由

サポート終了は「壊れる」ことではなく「直してもらえなくなる」こと。問題は障害ではなく、脆弱性が見つかった日に表面化します。

サポートが終了してもシステムは昨日と同じように動き続けます。だから危機感を持ちにくいのですが、リスクの正体は故障ではありません。

1. 修正が来ない：新しい脆弱性が公表されても、修正版は提供されません。今回のPHP2Shellでは、8.1以前に対しては最小限の修正がソースコード形式で示されたのみで、通常の更新手段では適用できませんでした。

2. 攻撃側は期限を知っている：サポート終了後のソフトは「直されない的」として狙われやすくなります。公表済みの脆弱性は攻撃手順も出回るため、時間が経つほど危険が増します。

3. 周辺が先に限界を迎える：古いPHPはサーバーOSや各種ライブラリの対応からも外れていき、「サーバーを更新したら動かない」「対応できる技術者が見つからない」という形で保守コストが上がり続けます。

4. いざという時に選択肢がない：攻撃や障害が起きてから作り直すのは、計画的に移行するより何倍も高くつきます。業務停止と信用低下も伴います。

取引先からセキュリティチェックシートを求められる会社であれば、「サポート切れのソフトウェアを使用していないか」という設問に答えられなくなる、という現実的な問題もあります。

バージョンアップかリプレイスか：判断の分かれ道

「何年使ったか」ではなく、土台・保守・業務適合の3つで判断します。同じ築年数でも、手入れされた家とそうでない家では選択が変わるのと同じです。

注意したいのは、古いPHPからの改修費が高額になるケースでは、リプレイスとの費用差が思ったより小さくなることです。例えば7系から8.5への移行で互換性改修が大規模になるなら、「同じ費用をかけるなら業務の変化も反映して作り直す」ほうが投資として合理的な場合があります。逆に、昨年まで保守されていた8.1のLaravelアプリなら、バージョンアップ一択です。境目の判断は、現状調査の結果を見て開発会社と詰めるのが現実的です。

リプレイスに踏み込む場合の時期や進め方は業務システムのリプレイスを検討するタイミングと進め方で詳しく説明しています。

バージョンアップが「パッチ適用」では済まない理由と進め方

PHPのメジャーバージョンアップは、設定変更ではなく小さな開発案件です。「上げたら動かなくなった」を避けるために、調査→改修→テストの工程を踏みます。

「バージョンを上げるだけでしょう？」と思われがちですが、実際には次の作業が発生します。ここを省くと、本番で動かなくなります。

1. 現状調査：PHP・フレームワーク・ライブラリの現バージョンと、互換性のない記述（非推奨機能・削除された機能の使用箇所)を洗い出す

2. 連鎖する更新の計画：PHP本体だけでなく、フレームワーク（Laravel等）やライブラリも対応バージョンへ順に上げる必要があるため、経路を設計する

3. 改修とテスト：互換性のない箇所を改修し、テスト環境で業務の主要な流れを確認する。テストコードや検証環境がない場合は、その整備から始まることも多い

4. 本番切り替えと監視：切り戻し手段を用意した上で本番を更新し、一定期間監視する

期間や費用は、システムの規模・現在の世代・テスト資産の有無で大きく変わるため、一概には言えません。確かなのは、期限が迫ってから慌てて進めるほど高くつくことと、一度8.4/8.5まで上げて以後のEOL管理を保守に組み込めば、次回からの更新は今回よりずっと軽くなることです。

開発会社への相談・見積もりで確認すること

「対応します」の一言で任せず、移行先・調査の範囲・移行後の体制の3点を確認すると、会社の力量が見えます。

移行先はどのバージョンですか？その理由は？

サポート期限から逆算した提案（現時点なら8.4または8.5）が返ってくるかを見ます。「とりあえず8.2へ」のような、すぐ期限切れになる提案しか出ない場合は注意が必要です。

見積もりの前に現状調査はしますか？

コードを見ずに出てくる金額は、安全係数を大きく積んだ概算か、後から追加費用になる見切り発車のどちらかです。調査フェーズを区切って提案してくれる会社のほうが、結果的に総額は読みやすくなります。

移行後のサポート期限の管理はどうなりますか？

今回の騒動で分かったとおり、問題は「上げて終わり」ではなく維持です。保守契約の中でPHP・ライブラリの更新とEOL管理まで見てくれるかを確認してください。確認の観点は「納品して終わり」の開発会社を避けるための質問リストにまとめています。

よくある質問

サポート切れでも、社内からしか使わないシステムなら急がなくてよいですか？

外部公開システムより優先度は下がりますが、「安全」ではありません。社内ネットワークに入られた際の足がかりになるほか、サーバーOSの更新や周辺ツールの対応打ち切りで、いずれ動かす環境自体が維持できなくなります。期限を決めて計画に乗せてください。

レンタルサーバーの「PHPバージョン切替」で上げれば済みますか？

サーバー側のPHPを切り替えても、その上で動くプログラム側が新バージョンに対応していなければエラーになります。WordPressのような広く使われるCMSは本体・プラグインの更新で追従できることが多い一方、独自開発のシステムは改修が必要です。切り替え前に必ず検証環境で確認してください。

費用の相場を教えてください。

規模・現在の世代・テスト資産の有無で桁が変わるため、根拠のある金額は現状調査の後でないと出せません。言い換えると、調査なしで即答される金額には根拠がありません。まず調査だけ依頼し、その結果でバージョンアップとリプレイスを比較するのが、遠回りに見えて最短です。

まとめ：期限から逆算して動き出す

要点を整理します。

• PHP 8.1以前はサポート終了済み。8.2も2026年12月31日で終了するため、これから上げるなら8.4/8.5へ

• サポート終了のリスクは「壊れる」ではなく「直してもらえない」。脆弱性が出た日に表面化し、PHP2Shellでそれが現実になった

• 判断の分かれ道は土台・保守・業務適合の3つ。土台が生きていればバージョンアップ、死んでいればリプレイス

• どちらに進むにも、最初の一歩は現状調査。調査なしの見積もりに根拠はない

• 移行後は、サポート期限の管理（EOL管理）を保守契約に組み込み、「次の騒動」では当日に更新を終える側に回る

「自社のシステムがどのバージョンで動いているか分からない」という段階からで構いません。創新ラボでは、PHP・Laravelシステムの現状調査から、バージョンアップ・リプレイスの比較検討、移行後のEOL管理を含む保守まで対応しています。期限から逆算すると、動き出すのは早いほど選択肢が多く、安く済みます。