つづきの技術室サポート切れのPHPを放置すると何が起きるか
年末が近づくと、サーバー会社から「旧バージョンのPHPの提供を終了します」というお知らせが届くことがあります。読んでもよくわからないまま、とりあえず保存して終わり。私たちのところに相談が来るのは、だいたいその数か月後、管理画面が真っ白になってからです。
2026年は、ちょうどその時期にあたります。PHPの公式サイトによると、PHP 8.2のセキュリティサポートは2026年12月31日で終わります（PHP: Supported Versions）。この記事では、サポートが切れたPHPを使い続けると何が起きるのかと、社内で何を確かめればいいのかを、エンジニアではない方向けに書きます。
PHPそのものが終わったわけではありません
「PHPのサポートが切れる」と聞いて、PHPという言語がなくなるのかと心配される方もいます。そうではありません。サポートが終わるのは8.2や7.4といったバージョンごとで、PHP自体は毎年新しい版が出ています。2026年10月時点で最新の8.5は、2029年12月31日までセキュリティ修正が出る予定です（PHP: Supported Versions）。
困るのは、サポートの終わった古いバージョンのまま動いているシステムです。「PHPが終わった」のではなく「うちのシステムが使っているPHPのバージョンが終わった、またはもうすぐ終わる」と読み替えると、何を確かめればいいかが見えてきます。
「サポート終了」は、何が終わるのか
PHPは、各バージョンに決まった寿命があります。最初のリリースから2年間は不具合とセキュリティの修正が出る通常のサポート、その後の2年間は重大なセキュリティ問題だけを直す期間で、合わせて4年たつとサポートが終わります。公式サイトは、サポートが終わったバージョンについて、修正されない脆弱性にさらされる可能性があるので、できるだけ早く更新するよう呼びかけています（PHP: Supported Versions、PHP: Unsupported Branches）。
つまり、サポート終了の翌日にシステムが止まるわけではありません。止まらないから厄介なのです。それ以降に見つかった問題は、PHP側では直してもらえなくなります。
2026年10月時点で、公式にサポートされているのは8.2、8.3、8.4、8.5の4つです。セキュリティ修正が出る期限は、8.2が2026年12月31日、8.3が2027年12月31日、8.4が2028年12月31日、8.5が2029年12月31日です（PHP: Supported Versions）。それより前のバージョンはすべてサポートが終わっています。たとえば7.4は2022年11月28日、8.0は2023年11月26日、8.1は2025年12月31日に終了しました（PHP: Unsupported Branches）。業務システムでいまもよく見かける5.x系は、さらに前にサポートを終えています。
Perlも事情は似ています。Perlの公式ドキュメントでは、直近の2つの安定版を重大な問題の修正対象とし、セキュリティ修正については5.x.0のリリースから3年以内のバージョンに提供するとしています。現時点では5.44と5.42が通常のサポート、5.40がセキュリティ修正のみで、それより古い版はサポートが終わっています（perlpolicy）。ただしPerlは、OSに同梱されたものを使っていることが多く、実際にどこまで修正が届くかはOSの提供元にもよります。ここは個別に確認が必要です。
放置したときに起きること
私たちが見てきた範囲で言うと、困りごとはセキュリティ事故より先に、別の形でやってくることが多いです。
ある日、サーバー側の都合で動かなくなる
レンタルサーバーやクラウドの事業者は、古いPHPの提供をいずれ終えます。OSのサポートが終わって入れ替えが必要になったときも、新しいOSでは古いPHPが動かないことがあります。こちらが何も変えていなくても、土台が変わることでシステムが動かなくなる。冒頭の「管理画面が真っ白」はこのパターンです。
更新しようとしたら、作り直しに近い規模になる
古いPHPほど、新しい版との差が大きくなります。わかりやすい例が、データベースにつなぐ部分です。PHP 7.0では、それまで広く使われていた mysql 拡張が削除されました（PHP: Removed Extensions and SAPIs）。PHP 5の時代に書かれたシステムの多くはこれを使っていて、そのままではPHP 7以降で動きません。
一度に何段階も飛ばして上げようとすると、こうした変更が積み重なります。毎年少しずつ上げていれば数日で済んだ作業が、数年放っておいたせいで数か月の案件になる。私たちが一番もったいないと感じるのはここです。
周りの部品も一緒に止まる
PHPの上では、フレームワークやライブラリが動いています。これらも新しいPHPに合わせて開発が進むので、古いPHPのままだと、部品の更新もできなくなります。PHP本体だけでなく、システム全体が古いまま固まってしまいます。
見つかった脆弱性がそのまま残る
最後に、セキュリティの問題です。サポートが終わった後に見つかった脆弱性には、公式の修正が出ません。外部に公開しているシステムであれば、残った穴はそのまま攻撃の入口になりえます。
この記事を公開した数日後に、ちょうどその例が出ました。2026年10月21日、PHPは認証なしで外部からプログラムを実行されるおそれのある重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）を修正した8.5.12、8.4.27、8.3.36、8.2.35を公開しました。このときの告知には、8.1以前にはPHPプロジェクトから更新は出ないとはっきり書かれています。重大さを考えて7.4、8.0、8.1向けに最小限のソース用パッチも用意されましたが、これはソースから自分でビルドする人に向けたもので、サポート中の版と同じ修正が届くわけではありません（PHP: News Archive - 2026）。OSに同梱されたPHPなら、OSの提供元が独自に修正を出すこともあります。どこから入れたPHPなのかで、取れる手が変わるということです。
社内でまず確かめたいこと
いきなり見積もりを取る前に、次のことを確かめておくと話が早く進みます。
一つ目は、PHPやPerlのバージョンです。サーバー会社の管理画面に表示されていることも多いですし、保守会社がいれば聞けばすぐにわかります。わからない場合は、それ自体が「誰も把握していない」というサインです。
二つ目は、サーバーとOSの契約状況です。サーバー会社から古いPHPの提供終了について案内が来ていないか、メールを探してみてください。期限が書かれていれば、それが実質的な締め切りになります。
三つ目は、そのシステムが止まったときの影響です。受注、請求、顧客管理など、止まると業務が回らないものから優先順位をつけます。全部を一度に上げる必要はありません。
更新の進め方について、私たちの考え
PHPの更新には、大きく分けて「今のシステムを少しずつ直して新しいPHPに対応させる」方法と、「作り直す」方法があります。どちらが正しいかはシステムによりますが、最初から作り直しを前提にする必要はないと考えています。
古いシステムでも、業務の流れに合わせて何年も手を入れてきた分、画面や処理には現場のノウハウが詰まっています。それを捨てるのはもったいない。まず今のコードを調べ、どこが新しいPHPで動かないかを洗い出してから決めても、遅くはありません。
もうひとつお伝えしたいのは、一度上げて終わりにしないことです。PHPは毎年新しい版が出て、4年でサポートが切れます。更新を「数年に一度の大工事」ではなく「毎年の点検」にしておけば、今回のような慌て方はしなくて済みます。
8.2から8.3や8.4へ上げるときの具体的な進め方と、公式の移行ガイドに載っている変更のうち引っかかりやすいところは、PHP 8.2から8.3・8.4への更新の進め方と、壊れやすいところにまとめました。
おわりに
PHP 8.2のセキュリティサポート終了まで、残りは2か月ほどです。8.2を使っているシステムはもちろん、もっと古いPHPやPerlで動いているシステムがあれば、この機会に一度状況を確かめてみてください。
ディレクターズ・リベロでは、他社が開発したシステムの調査と引き継ぎ、PHPやOSの更新を含むサーバー保守を行っています。「バージョンもよくわからない」という段階からのご相談も歓迎です。詳しくはシステム引き継ぎ・保守とサーバー保守のページをご覧いただくか、info@directorz-libero.co.jp までご連絡ください。