「うちの業務システム、PHPの古いバージョンで動いていると言われた」
「サーバー会社から更新の案内が来たが、何をどこに頼めばいいか分からない」
2026年10月、PHP本体に「緊急」レベルの脆弱性が2件公表されました。
修正版が出たのはPHP 8.2以降だけで、7系や8.1で動くシステムには通常の修正が届いていません。
この出来事をきっかけに、古いPHPで動く業務システムの扱いを見直す企業が増えています。
この記事では、PHPのバージョンアップとは何か、放置するとどうなるかを整理します。
古いPHPのシステムの選択肢は「直す・一部を作り直す・全部作り直す」の3つです。
判断の軸は「PHPとフレームワークの差」「資料とテストの有無」「あと何年使うか」の3つです。
費用の目安と進め方、当社が古いシステムを引き継いで作り直した事例もあわせてご紹介します。
2026年10月のPHP脆弱性で何が起きたか
まず、今回の出来事を事実だけ整理します。
PHPの開発チームは2026年10月21日（日本時間23時）に、重大な脆弱性2件を修正した版を公開しました。
識別番号はCVE-2026-109618とCVE-2026-109619で、深刻度は2件ともCVSS v4.0で9.2（10点満点）です。
認証なしで外部からプログラムを実行される恐れがあり、Webの通信を受けるPHPすべてが対象とされました。
| PHPのバージョン | 今回の扱い |
|---|---|
| 8.5 / 8.4 / 8.3 / 8.2 | 修正版あり（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35） |
| 8.1 / 8.0 / 7.4 | 通常の修正なし。例外として最小限の修正がソースコードの形で提供 |
| 7.3以前 | 提供なし |
国内では、修正版の公開に合わせて多くの企業が予防的にサービスを一時停止しました。
当社でも、開発・保守を担当しているPHPのシステムについてサービス一時停止の可能性をお知らせし、修正版の公開後に順次更新しています。
ポイントは、古いバージョンには修正そのものが届かないという点です。
サーバー会社が直してくれるのは、サポート中のバージョンだけです。
7系や8.1で動くシステムは、設定による緩和策で時間を稼ぎながら、バージョンアップか作り直しを進める必要があります。
PHPのバージョンアップとは？サポート期限の仕組み
PHPのバージョンアップとは、システムを動かしているPHP本体を、サポート中の新しい版に切り替えることです。
PHPには1つの版につき、おおむね次の期限があります。
- アクティブサポート：公開から2年間。不具合も脆弱性も直される
- セキュリティサポート：その後の2年間。脆弱性だけが直される
- サポート終了（EOL）：以降は脆弱性が見つかっても直されない
| バージョン | セキュリティサポート終了 | 2026年10月時点の状態 |
|---|---|---|
| PHP 7.4 | 2022年11月 | 終了済み |
| PHP 8.0 | 2023年11月 | 終了済み |
| PHP 8.1 | 2025年12月 | 終了済み |
| PHP 8.2 | 2026年12月 | あと2か月で終了 |
| PHP 8.3 | 2027年12月 | セキュリティサポート中 |
| PHP 8.4 | 2028年12月 | アクティブサポート中 |
| PHP 8.5 | 2029年12月 | アクティブサポート中 |
注意したいのは、今回ぎりぎり修正版が出たPHP 8.2も、2026年12月で期限を迎えることです。
「8.2に上げたから安心」ではなく、次は8.3以降への更新が必要になります。
PHPは毎年11月ごろに新しい版が出るため、「期限が来たら上げる」仕組みを持つことが前提になります。
自社のシステムが古いPHPで動いているか確かめる方法
経営者や総務の方が最初にやるべきことは、「誰に何を聞くか」をはっきりさせることです。
PHPを更新する担当は、システムの置き場所によって変わります。
| システムの置き場所 | PHP本体を更新する人 | 確認先 |
|---|---|---|
| レンタルサーバー（共用） | サーバー会社 | サーバー会社の管理画面・お知らせ |
| VPS・クラウド・自社サーバー | 自社の情シス、または保守会社 | 保守契約の相手先 |
| 開発会社が用意したサーバー | 開発会社 | 開発会社の担当者 |
| パッケージ製品・業務用機器の内部 | 製品のメーカー | メーカーのセキュリティ情報 |
確認するときは、次の3点を聞いてください。
- Webで使われているPHPのバージョンはいくつか（コマンドで見える版と、Webで動く版が違うことがある）
- そのバージョンは、今回の修正版（8.2.35以降など）に更新済みか
- 更新できないなら、理由は「サーバー側の都合」か「システムが新しいPHPで動かない」か
3つ目の答えが「システムが動かないから上げられない」なら、それはシステム本体の改修か作り直しの問題です。
この記事の以降は、その状態にある方に向けて書いています。
古いPHPのシステムを放置する4つのリスク
「今は動いているから」と先送りすると、次の4つのリスクが積み上がります。
1. 脆弱性が直されず、攻撃の入口になる
今回のように、PHP本体に穴が見つかっても修正が届きません。
顧客情報を扱うシステムなら、漏えい時の損害は改修費を大きく上回ります。
PHPの脆弱性を狙う攻撃は2024年にもIPAが注意喚起しており、今回が最後ではありません。
2. サーバー会社の都合で、ある日突然止まる
レンタルサーバー各社は、サポートが終わったPHPの提供を順次打ち切ります。
「来月から7.4は選べません」という案内が来てから改修先を探すと、割高な緊急対応になります。
3. 機能追加や不具合修正を頼める会社がなくなる
古いPHPと古いフレームワークの組み合わせは、対応できる技術者が年々減ります。
開発会社に「まずバージョンアップしないと手が出せない」と言われ、小さな改修すら止まることがあります。
保守そのものを放置した場合の損害は、システム保守を放置する5つのリスクでも解説しています。
4. 後になるほど、上げる幅が大きくなり費用が増える
PHP 7.4から8.3に上げる作業は、8.1から8.3に上げる作業より手間が数倍かかります。
版の差が開くほど、動かなくなる箇所が増え、調べる範囲も広がるためです。
バージョンアップは、差が小さいうちに小刻みにやるほうが総額は安くなります。
PHPをバージョンアップすると動かなくなるのはなぜか
「PHPを上げるだけなら、サーバーの設定を変えれば終わりでは？」と思われがちです。
実際には、版を上げるとプログラムの一部が動かなくなることがあり、ここに改修費がかかります。
主な原因は次の3つです。
PHP本体の仕様変更
PHPは版が上がるごとに、古い書き方を廃止したり、あいまいな動きを厳密にしたりしています。
| 変わった時期 | 影響の例 | よく起きる症状 |
|---|---|---|
| PHP 7.0 | 古いデータベース接続関数（mysql_系）の廃止 | DBにつながらず画面が真っ白になる |
| PHP 8.0 | 文字列と数値の比較ルールの変更、エラーの扱いの厳密化 | 検索結果や判定が変わる。警告だったものがエラーで止まる |
| PHP 8.1〜8.2 | 引数へのnull渡しや、宣言していないプロパティの使用が非推奨に | ログに警告が大量に出る。次の版で止まる前兆 |
| PHP 8.4以降 | 非推奨だった書き方の一部が廃止 | 古い書き方のまま上げると止まる箇所が出る |
フレームワークやライブラリの期限切れ
業務システムの多くは、PHP本体の上にLaravelやCakePHPなどの「フレームワーク」を載せて作られています。
フレームワークにも期限があり、古い版は新しいPHPで動きません。
CakePHPの2系・3系で作られたシステムは、PHP 8系で動かすこと自体が難しく、作り直しに近い作業になります。
PHPのバージョンアップの見積もりは、実質「フレームワークを何世代上げるか」で決まります。
PHPだけ上げてフレームワークを放置すると、同じ問題がすぐにもう一度起きます。
確かめる手段がない
一番の問題は、上げた後に「どこが壊れたか」を見つける手段がないことです。
本番とは別の動作確認用の環境（テスト環境）も自動テストもなければ、全画面を人の手で確認するしかありません。
画面が50あれば、確認だけで数人日かかります。
作った会社と連絡が取れず仕様書もなければ、「何が正しい動きか」を調べる作業から始まります。
古いPHPのシステムをどうするか｜3つの選択肢と費用の目安
選択肢は3つです。
どれが正解かはシステムの状態で変わるため、費用と期間を並べて比べます。
| 選択肢 | 内容 | 向いているケース | 費用の目安 | 期間の目安 |
|---|---|---|---|---|
| A. バージョンアップ（延命） | PHPとフレームワークをサポート中の版へ上げ、動かない箇所を直す | フレームワークの差が1〜2世代。ソースと仕様書がある | 数十万円〜数百万円 | 1〜3か月 |
| B. 一部を作り直す | 外部に公開している部分など、リスクの大きい部分だけ新しく作る | 基幹部分は安定している。業務を止められない | 数百万円〜 | 3〜6か月 |
| C. 全部作り直す | 業務を整理し、新しいPHPとフレームワークで作り直す | フレームワークの差が3世代以上。ソースや仕様書がない | 数百万円〜数千万円 | 6か月〜1年 |
Aの費用は、機能追加などの改修と同じく「調査＋修正＋テスト」の積み上げで決まります。
詳しくはシステム改修の費用の決まり方と目安をご覧ください。
Cの費用は新規開発と同じ考え方で、規模別の相場はシステム開発の費用相場にまとめています。
判断のコツは、Aの費用に「3〜5年後にまたかかる費用」を足して、Cと比べることです。
延命は1回で終わりません。
2〜3年で業務が変わる、または別のシステムに統合する予定があるなら、Aで十分です。
あと10年使うつもりなら、Cのほうが総額は下がることが多いです。
直すか作り直すか｜5つの判断基準
当社がご相談を受けたときに確認している判断基準は、次の5つです。
「作り直し寄り」が3つ以上なら、Cを軸に見積もりを取ることをおすすめします。
| 判断基準 | 延命（A）寄り | 作り直し（C）寄り |
|---|---|---|
| PHPとフレームワークの差 | どちらも1〜2世代の差 | PHP 7系以前、またはフレームワークが3世代以上前 |
| ソースコードと仕様書 | 最新のソースがあり、仕様書も残っている | ソースが手元にない。中身が分かる人もいない |
| テストの手段 | テスト環境や自動テストがある | 本番しかなく、確認は全部手作業 |
| 業務との合い方 | 今の業務に合っていて、Excelでの補完が少ない | システムの外で手作業やExcel管理が増えている |
| 今後の利用年数 | 2〜3年で統合や乗り換えの予定がある | 5年以上は使い続ける |
ソースコードが手元にない場合は、Aの選択肢そのものがなくなります。
開発した会社と連絡が取れないときの対処は、開発会社が無くなったときの対処法で事例つきで解説しています。
PHPバージョンアップ・作り直しの進め方6ステップ
方針が決まる前でも、今日から動けることがあります。
おすすめの順番は次の6ステップです。
- 棚卸し
PHPで動くシステムを全部書き出し、PHPとフレームワークの版、置き場所、保守先を一覧にする。 - 当面の守り
更新できないシステムは、IP制限などで公開範囲を絞り、WAFや開発元が示す緩和策で攻撃経路を減らす。これは時間稼ぎで、安全になる対策ではない。 - 影響調査
開発会社がソースを読み、新しいPHPで動かない箇所の数とフレームワークの世代差を調べる。ここで費用の精度が上がる。 - 方針決定
A・B・Cの費用と期間を並べ、今後の利用年数と合わせて決める。 - 段階的に実施
テスト環境を先に用意し、機能や画面の単位で区切って切り替える。業務を止めずに移行できる。 - 期限管理の仕組み化
PHP・フレームワーク・OS・データベースの期限を一覧にし、保守契約に「期限の半年前に更新計画を出す」ことを盛り込む。
発注側で一番効くのは、棚卸しと影響調査に協力することです。
ソースコード、サーバーの権限、残っている仕様書がそろっているほど、調査の工数と費用が減ります。
用意するものは、システム開発の引き継ぎの進め方にまとめています。
当社の事例｜古いシステムを引き継いで作り直した例
当社はPHP（Laravel）での業務システム開発を主力にしており、他社が作った古いシステムを引き継ぐご相談を多くいただいています。
進め方の参考として、3つの事例をご紹介します。
サポート切れの提案書作成システムをWeb化
サポートが切れた環境で動いていた提案書作成システムを、Webシステムとして作り直した事例です。
過去に作った提案書を当時のまま再出力できるよう、古いデータを読み解いて移行しました。
「C. 全部作り直す」を選びつつ、データは捨てなかった例です。
この事例の詳細は、以下のページでご覧いただけます。
基幹システムを残し、現場で使う部分だけ新しく作る
古い基幹システムは安定していたため残し、現場で使う見積発行の部分だけをWebで新しく作った事例です。
「B. 一部を作り直す」の典型で、基幹側を止めずに必要な部分から更新しました。
詳しくはレガシー基幹システムを残してWeb化した開発事例をご覧ください。
機能を止めずに不動産サイトを作り直す
老朽化した不動産サイトを、基幹連携や帳票の機能を止めずに新しい基盤へ移した事例です。
段階的に切り替えることで、業務を止めずに移行しています。
進め方は不動産サイトのリプレースを「機能を止めず」に成功させる方法にまとめています。
システム側の詳細は老朽化した不動産管理システムのリプレイス開発事例をご覧ください。
PHPのバージョンアップに関するよくある質問
Q. レンタルサーバーのシステムでも、自社で何かする必要がありますか？
PHP本体の更新はサーバー会社が行います。
ただし、管理画面で古いPHPの版を選んだままだと、更新の対象外になることがあります。
選択中の版が8.2以降か確認し、古ければ切り替えたうえで、表示やフォーム送信の動作を確かめてください。
Q. PHP 7.4のシステムに「最小限の修正」を当てれば使い続けられますか？
おすすめしません。
今回提供された7.4・8.0・8.1向けの修正は、ソースコードから自分でPHPを組み立てる人向けの例外的な措置です。
今回の2件以外の脆弱性は直されないため、根本の対策はサポート中の版へ移ることです。
Q. 他社が作ったPHPのシステムでもバージョンアップを頼めますか？
ソースコードとサーバーの権限があれば、多くの場合は対応できます。
まず影響調査を行い、A・B・Cのどれが合うかを費用と期間つきでご提案します。
延命が割に合わない場合は、その理由も含めて正直にお伝えします。
Q. バージョンアップの作業中、システムは止まりますか？
作業の大半は、本番とは別のテスト環境で行います。
切り替えの瞬間だけ数十分〜数時間の停止が必要になることがあります。
夜間や休日に切り替え、問題があれば元に戻せる手順を用意して進めます。
Q. 作り直すなら、PHP以外の言語にしたほうがよいですか？
言語を変えるだけでは、期限の問題は解決しません。
どの言語にも期限があり、大事なのは「期限が来たら上げられる体制」です。
PHPは技術者が多く業務システムの実績も豊富なため、作り直し先として今も現実的な選択肢です。
開発サービスのご案内更新できない古いシステムを作り直すシステムリプレイスPHPを上げられない、作った会社と連絡がつかない。そんなシステムを、今の機能とデータを読み解いたうえで作り直します。他社製のシステムもご相談いただけます。リプレイスの進め方・事例を見る →まとめ
古いPHPで動くシステムについて、リスク・選択肢・判断基準・進め方を整理しました。
- 2026年10月の脆弱性で修正版が出たのはPHP 8.2以降。7系・8.1には通常の修正が届かない
- PHP 8.2も2026年12月で期限。「期限が来たら上げる」仕組みが前提になる
- 上げられない理由がシステム側にあるなら、改修か作り直しの問題
- 選択肢は「延命・一部を作り直す・全部作り直す」の3つ
- 判断の軸は「版の差」「資料とテストの有無」「あと何年使うか」
- 棚卸しと当面の守りは今日から始められる
「自社のシステムがどのPHPで動いているか分からない」という段階のご相談でも大丈夫です。
他社が作ったシステムの引き継ぎ、影響調査、作り直しの見積もりまで、株式会社みんなシステムズがまとめて承ります。
お気軽にご相談ください。
