先に要点
サーバー保守では、OS や SSL 証明書より後回しにされがちなのが PHP のバージョン更新です。
表示が崩れていないと まだ動いているから大丈夫 と思いやすいのですが、実務ではここを後回しにしたことで、あとから更新作業が一気に重くなることがかなり多いです。
特に、WordPress サイトや Laravel アプリでは、PHP 本体が古いままだと、プラグインやフレームワークの更新、サーバー移転、脆弱性対応の足を引っ張りやすくなります。
その結果、平常時は静かでも、何か起きたときだけ急に高くつく保守項目になります。
この記事では、PHP のバージョン更新がなぜ必要なのかを、サポート終了、セキュリティ、性能、周辺ソフトの対応、保守で後回しにしない判断基準、実際の確認手順から整理します。
小規模サイトの監視全体から見たい場合は、小規模サイトの監視は何から始める？死活監視・SSL・ディスク容量の見方 もつながりやすいです。
この記事では、2026年4月22日時点で PHP.net の supported versions、WordPress.org の requirements と PHP optimization、Laravel の releases を確認しながら整理しています。ここでは運用判断の材料としてまとめており、個別環境の互換性は実機確認を優先してください。
結論：PHP更新は「不具合対応」ではなく「古くなる前の保守」
先に結論を言うと、PHP の更新は 壊れたから直す作業 ではなく、古くなって身動きが取れなくなる前に進める保守 です。
PHP.net の公式情報では、各 PHP ブランチは通常 2年の通常サポート + 2年のセキュリティサポート の形で扱われます。
2026年4月22日時点では、たとえば次の状態です。
- PHP 8.2: セキュリティサポートは 2026年12月31日まで
- PHP 8.3: セキュリティサポートは 2027年12月31日まで
- PHP 8.4: セキュリティサポートは 2028年12月31日まで
- PHP 8.5: セキュリティサポートは 2029年12月31日まで
この差を早めに見ておかないと、ある日突然というより、半年から1年かけて更新しづらい環境になっていきます。
PHPのバージョン更新が必要な理由
2026年10月21日に、認証なしでコードを実行されるおそれのある PHP 本体の脆弱性（PHP2Shell）の修正版が出ました。修正版が出たのはサポート中の 8.2〜8.5 だけで、8.1 以前はソースの修正が公開されただけでした。古い版のままだと、こうしたときに「すぐ上げる」ができません。確認方法と対策は PHP2Shellとは？影響を受けるPHPの版・確認方法・今すぐやる対策 にまとめています。
1. サポートが切れると未修正の脆弱性を抱えやすい
一番大きい理由はここです。
PHP 本体のサポートが終わると、その後に見つかった脆弱性や不具合に対して、公式の修正が入らなくなります。
特に公開サイトでは、「今すぐ攻撃されるか」より「問題が起きても公式に直らない状態」で運用すること自体がリスクです。WordPress.org でも、古い PHP はサポート終了済みであり、セキュリティ上の問題を招く可能性があると案内されています。
2. フレームワークやCMSの更新に追いつけなくなる
PHP が古いと、その上に乗っているソフトも更新しづらくなります。
たとえば Laravel の公式リリース情報では、2026年4月22日時点で次の対応範囲が示されています。
このため、古い PHP のままでは、新しい Laravel へ上げたいときに先にサーバー更新が必要になります。
WordPress でも、requirements ページでは PHP 8.3 以上が推奨されています。
3. プラグインやライブラリの互換性確認が難しくなる
古い PHP は、一見すると 古いから安定している ように見えます。
でも実際には、周辺の作者がそのバージョンでの検証をやめていくため、トラブル時に判断材料が減ります。
この状態になると、次のような問題が増えます。
更新
相性が読みにくい
プラグイン更新をかけると相性が読みにくい。
機能
新しい拡張が使えない
新しい拡張機能が使えない。
移転
移転先の候補が減る
ホスティング会社の切り替え候補で対応外になる。
障害
まず PHP 更新から
障害時に「まず PHP を上げてください」から始まりやすい。
4. 性能改善を取り逃しやすい
PHP の新しいバージョンには、セキュリティだけでなく性能改善やバグ修正も含まれます。
WordPress の公式ドキュメントでも、新しい PHP にはセキュリティと性能の改善がありつつ、後方互換に注意してアップグレードするべきだと案内されています。
もちろん、性能改善だけを理由に急いで更新するとは限りません。ただ、同じアプリでも PHP を更新するだけで応答が軽くなることは普通にあります。
どんなときに後回しにしない方がいいか
次のどれかに当てはまるなら、保守の優先度は上げた方がよいです。
1. サポート
終了済み・終了間近
使っている PHP が公式サポート終了済み、または終了が近い。
2. 要件
PHP 要件が上がっている
WordPress 本体、テーマ、プラグインの更新時に PHP 要件が上がっている。
3. 更新予定
フレームワークを上げる
Laravel や周辺パッケージの更新を予定している。
4. 移転予定
移転・リプレースがある
サーバー移転、VPS移行、リプレースの予定がある。
5. 環境差
本番と検証の差が大きい
開発・検証環境と本番環境の PHP バージョン差が大きい。
古い PHP のまま移転や大規模更新をすると、アプリ更新とサーバー更新が同時にぶつかって切り分けが難しくなります。
逆に、すぐ上げる前に慎重に見るべきケース
更新は必要ですが、雑に上げるのも危険です。
たとえば次のような環境は、先に検証計画を作る方が安全です。
古いサイト
長年触っていない
長年触っていない古い WordPress サイト。
改修
独自改修が多い
独自改修したテーマやプラグインが多い。
依存
古い部品に依存
古いライブラリや拡張モジュールに依存している。
環境
本番しかない
本番しかなく、ステージング がない。
固定
バージョン固定
ベンダー提供パッケージが特定 PHP に固定されている。
この場合でも「だから更新しない」ではなく、「だから先に棚卸しする」が正しい進め方です。
実務での判断基準
保守の現場では、次の順で見ると判断しやすいです。
- 1
公式サポート
いまのPHPは公式にサポートされているか
- 2
アプリ側の要件
アプリ側の推奨・対応範囲はどうか
- 3
検証環境
ステージングで検証できるか
- 4
戻し方
失敗時に戻せるか
1. いまのPHPは公式にサポートされているか
まず PHP.net の supported versions を見ます。
ここで EOL に入っている、またはセキュリティサポート終了が近いなら、優先度は高いです。
2. アプリ側の推奨・対応範囲はどうか
次に、使っているソフトの公式要件を見ます。
- WordPress なら requirements と compatibility
- Laravel なら releases の supported PHP versions
- 主要プラグインや主要パッケージの対応表
3. ステージングで検証できるか
WordPress の公式ドキュメントでも、PHP 更新前に非本番環境で試すことが勧められています。
そのため、ステージング があるかどうかで、進めやすさがかなり変わります。
4. 失敗時に戻せるか
バックアップ はあるか。切り戻し手順はあるか。PHP バージョンをホスティング側で戻せるか。エラーログを見られるか。
更新前に確認しておきたい手順
実務では、次の流れにすると比較的安全です。
PHP更新の進め方
- 1現在の PHP バージョンを確認する
いま動いているバージョンを把握する。
- 2
- 3対応 PHP バージョンを確認する
それぞれの対応 PHP バージョンを公式情報で確認する。
- 4
- 5
- 6本番反映後に確認する
エラーログ、フォーム、管理画面、バッチ、メール送信を確認する。
フォーム送信、管理画面ログイン、予約、決済、定期バッチは最低限見たいです。
よくある失敗
失敗1
いきなり本番で上げる
一番よくある失敗です。更新自体より、「どこが壊れたか分からない」状態の方がつらくなります。
失敗2
WordPress本体だけ見て安心する
本体が動いても、テーマやプラグイン、独自コードでエラーが出ることがあります。特に古いコードでは、PHP の非推奨機能や厳格化で表面化する問題があります。
失敗3
切り戻し方法を決めていない
障害時に「戻せると思っていた」が一番危ないです。パネル操作でバージョンを戻せるのか、CLI なのか、ホスティング依頼なのかを先に確認した方が安全です。
どうしても今すぐ上げられないとき
事情があってすぐ更新できないことはあります。
その場合でも、完全放置にはしない方がよいです。
すぐ上げられないときにやること
- 1期限を決める
いつまでに上げるか期限を決める。
- 2理由を一覧化する
更新できない理由を一覧化する。
- 3洗い出す
非対応プラグインや独自改修を洗い出す。
- 4
- 5
つまり、今は無理 でも いつかやる を言語化しておくことが大事です。
PHPバージョン更新のよくある質問
Q. PHP のサポート期間はどれくらいですか？
A. 現行ポリシーでは アクティブサポート2年 + セキュリティサポート2年 = 計4年です。セキュリティサポート終了は PHP 8.1 が2025年末、8.2 が2026年末、8.3 が2027年末、8.4 が2028年末です。
Q. PHP 7 系はまだ使えますか？
A. 公式サポートは 2022年で終了済みです。ホスティング会社が独自延長している場合もありますが、セキュリティ脆弱性が出ても自社で対応する必要があり、業務利用には推奨できません。
Q. PHP 更新でハマる典型は？
A. 非互換な構文(deprecated → removed)、関数仕様変更、型厳格化(8系)、プラグインや CMS の対応、composer 依存関係の更新 などです。事前検証なしで本番更新は危険です。
Q. 検証環境はどう用意しますか？
A. Docker で別 PHP バージョンの環境を立てる、ホスティング会社のステージング環境を使う、ローカルに Laravel Valet / Herd で別バージョン切り替え、などが定番です。
Q. WordPress と PHP の組み合わせは？
A. WordPress 公式は現在 PHP 8.3 以上 を推奨しています(7.4/8.0 は EOL のため非推奨)。WordPress 本体は古い PHP でも動作しますが、セキュリティ上アップグレードが強く推奨されます。テーマやプラグインが古いと新しい PHP 系で警告が出るので、個別確認が必要です。
Q. PHP 更新後の確認ポイントは？
A. エラーログに警告/エラー、管理画面の動作、フォーム送信、画像アップロード、メール送信、バッチ処理、外部 API 連携、を網羅的に確認します。
Q. PHP 7 から 8 への大きな変更は？
A. JIT コンパイラ追加(性能向上)、Named Arguments、Match expression、Nullsafe operator、Constructor Property Promotion、型システム強化、です。性能向上が大きいので、可能なら 8 系への更新は積極的に検討します。
まとめ
PHP のバージョン更新が必要なのは、単なる新機能のためではありません。
サポート終了、セキュリティ修正停止、フレームワークやプラグインの対応終了、移転や障害対応の難化を避けるためです。
保守で大事なのは、壊れてから慌てて上げることではなく、まだ動いているうちに上げる判断材料をそろえること です。
特に WordPress や Laravel を使っているなら、PHP 本体の更新は周辺更新の土台として見ておく方が安全です。
参考リンク
- PHP.net: Supported Versions
- WordPress.org: Requirements
- Developer.WordPress.org: PHP Optimization
- Laravel: Release Notes / Support Policy