古いPHPを上げるのがこわい人へ｜リスクの洗い出しと安全な上げ方
「PHPのサポートが切れてます」——保守を引き継いだ人やレンタルサーバーの通知で、そう言われたことはありませんか。上げたほうがいいのは分かっている。でも、上げた瞬間に画面が真っ白になって、動いていたサイトが止まるのが想像できてしまう。だから、7.4のまま、あるいはもっと前のまま止まっている。
これは、あなたが後回しにする性格だからでも、慎重すぎるからでもありません。「上げたらどこが壊れるのか」が見えていないだけです。見えないものは、こわい。逆に言えば、壊れそうな場所を先に書き出して、本番に触れる前に試せる場所さえあれば、バージョン上げはぐっと落ち着いて進められます。今日は、いきなり上げるのではなく「リスクを洗い出す」ところから始めましょう。
結論：①いま何が動いているか（PHPのバージョンと、そのうえで動くアプリ・ライブラリ）を確認し、②公式の移行ガイドと照らして壊れそうな箇所を洗い出し、③検証環境で新バージョンを立てて試し、④問題を1つずつ潰してから本番を切り替え、⑤切り替え後もしばらく様子を見る。この順で、「見えないこわさ」を「見える作業」に変えていきます。
環境（レンタルサーバー／VPS／コンテナ、フレームワークの有無、検証環境が用意できるか）で最適な進め方は変わります。本文を自分の環境に読み替えつつ、細部は検証環境と公式情報で確認してください。
なぜ「古いPHP」を上げたほうがいいのか
まず、後回しにしてきたこと自体を責める必要はありません。動いているものを触るのは、それだけでリスクだからです。そのうえで、上げておく理由を落ち着いて確認しておきます。
- サポートが切れたバージョンは、脆弱性が見つかっても修正されない（セキュリティの問題が残り続ける）
- 新しいライブラリやプラグインが、古いPHPに対応しなくなっていく（いずれ更新できなくなる）
- レンタルサーバー側が古いバージョンの提供を終了し、ある日強制的に上げられることがある
いま動いているPHPがサポート対象かどうかは、PHP公式のSupported Versionsで確認できます。「まだ大丈夫か」「もう切れているか」を、まずここで一次情報として押さえておくと、社内や取引先への説明もしやすくなります。
まず「いま何が動いているか」を確認する
上げる前に、いまの足元を確認します。ここが分からないまま上げると、何が原因で壊れたのか切り分けられなくなります。
- 現在のPHPバージョン（
php -v、または管理画面の情報ページ、<?php phpinfo();で確認） - そのPHPで動いているアプリ（自作のプログラム／WordPressなどのCMS／Laravelなどのフレームワーク）とそのバージョン
- 使っているライブラリ・拡張モジュール（
composer.jsonがあれば依存関係、なければ読み込んでいるモジュール一覧） - どのバージョンまで上げるのか（いきなり最新でなく、まず1つ上のサポート内バージョンでも可）
ここで大事なのは「一気に何段も上げない」ことです。7.4から一足飛びに最新へ、ではなく、まずサポート内の手前のバージョンへ、と刻むほうが、壊れた原因を追いやすくなります。
壊れそうな箇所を「先に」洗い出す
いきなり動かすのではなく、公式の移行ガイドと照らして「今回のバージョンで変わる点」を先に洗い出します。PHPはバージョンが上がるときに、古い書き方を使えなくする（非推奨→廃止）ことがあります。ここが、既存コードで一番引っかかる場所です。
例えば7.4から8.0への移行ガイドには、廃止された関数や、エラーの扱いが厳しくなった点がまとまっています。全部を暗記する必要はありません。「自分のコードで使っていそうな箇所」に当たりをつけるために使います。
洗い出しの現実的なやり方は、次のどれかです。
- 検証環境で実際に新バージョンで動かし、出たエラー・警告のログを見る（一番確実）
- 移行チェック用のツール（PHP_CodeSnifferの互換性チェックなど）でコードを静的に確認する
- 自作コードなら、
error_reportingを厳しめにしてログを取り、非推奨の警告を拾う
ここで見つかった項目は、あとで「潰すことリスト」になります。数を数えて記録しておくと、進み具合が見えて気持ちが少し楽になります。
検証環境で試してから、本番を切り替える
洗い出しができたら、本番とは別の場所で新バージョンを立てて試します。ここが「戻せる状態」の中心です。
- 検証環境を用意する（同じ構成のサーバー／ローカル／コンテナ。本番のデータのコピーがあるとより確実）
- 新しいPHPバージョンでアプリを動かし、主要な画面・機能を一通り触る（トップ・ログイン・購入や登録など「お金や個人情報が動く動線」は特に丁寧に）
- 出たエラーを1つずつ潰す（洗い出しリストと照らして、直した箇所を消し込む）
- 本番切り替え前に、必ずバックアップ（DB＋ファイル）と、元のバージョンに戻す手順を用意しておく
- 切り替えは、できればアクセスの少ない時間帯に。切り替えたら主要画面をすぐ確認し、しばらくエラーログを見張る
レンタルサーバーで検証環境が作りにくい場合は、サブドメインやステージング機能、ローカルのDocker環境などで「本番に近い場所」を作れないか探してみてください。それも難しいときは、切り替えを平日の日中に人がいる状態で行い、問題が出たらすぐ元のバージョンに戻せるようにしておく——この「すぐ戻せる」を先に用意することが、最大の保険になります。
明日やること（小さく1つ）
全部を今日やる必要はありません。まずは次のどれか1つで十分です。
php -vで今のバージョンを確認し、Supported Versionsでサポート状況を見る- 動いているアプリ・フレームワーク・主なライブラリの名前とバージョンを1枚に書き出す
- 「どこまで上げるか」を、いきなり最新ではなく「まず1つ手前のサポート内バージョン」と仮に決める
チェックリスト：PHPバージョンアップ前後の確認
- 現在のPHPバージョンとサポート状況を確認したか
- 動いているアプリ・フレームワーク・ライブラリのバージョンを把握したか
- どのバージョンまで上げるか（刻んで上げるか）を決めたか
- 公式の移行ガイドで、今回変わる点をざっと確認したか
- 検証環境で新バージョンを動かし、エラー・警告を洗い出したか
- 洗い出した項目を1つずつ潰して記録したか
- 本番切り替え前にバックアップ（DB＋ファイル）を取ったか
- 元のバージョンに戻す手順を用意したか
- 切り替え後、主要画面の確認とエラーログの見張りをしたか
サポート切れのバージョンを前にすると、つい「大ごと」に感じてしまいます。でも実際にやることは、現状を確認して、壊れそうな場所を書き出して、別の場所で試す——地味な作業の積み重ねです。こわさの正体は「見えないこと」なので、見えるようにするほど、静かに小さくなっていきます。
一気に最新まで、と気負わなくて大丈夫です。今日は今のバージョンを確認するところまで。それだけでも、止まっていたものが一歩前に進みます。
よければ、こちらも
- サポート切れのOS・ミドルウェアを棚卸しする手順は EOLの棚卸し手順 にまとめています。
- テストがないコードに手を入れる前の安全策は テストがないコードを安全に改修する をどうぞ。
- 改修の影響範囲を見落とさない調べ方は 改修の影響範囲を調べる順番 が参考になります。