PHPのバージョンを上げる前の確認表

1. 更新理由と対応条件を揃える

サポート終了への対応、ソフト側の動作条件、新しい環境への移行など、今回の更新理由を整理します。サーバーで選べる最新の番号だからという理由だけで、動作条件を確認せず切り替えないでください。

PHPには通常の修正が提供される期間と、セキュリティ対応中心の期間があります。対象バージョンの現在の状況はPHP公式のサポート表で確認し、変更内容は公式マニュアルの移行ガイドから対象の版を調べます。確認日: 2026年9月10日。

WordPressなら本体だけでなく、テーマと利用中のプラグインも対象です。独自PHPなら使っているライブラリや外部接続も確認します。この記事は更新前の確認表であり、特定の組み合わせについて動作保証や実機試験済みとするものではありません。

2. Webとコマンド実行の環境を分けて記録する

ブラウザから動くPHPと、コマンドや定期処理で呼び出すPHPは別の設定になっている場合があります。片方の番号を確認しただけで、すべて切り替わったと判断しないようにします。設定画面や管理担当から、実際の実行経路を確認してください。

スマホでは表を横にスクロールできます。

3. 検証環境で代表的な操作を試す

トップページが見えることだけでは十分ではありません。記事表示、検索、ログイン、管理画面、画像処理、フォーム、定期処理など、利用している機能から試験対象を選びます。顧客へ通知したり本番の決済を発生させたりしないよう、検証先を分離してから試します。

テスト票の記入例は「記事検索／既存の検証語で検索／変更前と同じ候補が出ること」のように、操作と合格条件を並べます。これは試験計画の例で、実行結果ではありません。利用していない機能を形式だけで並べるより、日々使っている重要な操作を漏らさないことが大切です。

構文チェックで見つからない実行時の問題もあります。ログのエラーや警告を確認し、原因が分からないまま警告表示を消して合格扱いにしないでください。診断用の詳細情報を公開ページへ残さず、管理できる場所で確認します。

4. 本番反映は変更範囲を絞る

1. 検証結果と未解決項目を担当者で確認する。
2. 作業直前のバックアップと復旧手順を確認する。
3. 受付や定期処理への影響が少ない作業時刻を決める。
4. 対象の設定だけを変更し、別の改修を混ぜない。
5. Webと定期処理それぞれの代表操作を再確認する。

サーバーによって設定変更の単位や反映方法は違います。同じ契約の別ドメインにも影響するかを確認し、関係する運営者へ知らせます。大きな更新を一度に重ねると、問題がPHPなのかプラグインなのか切り分けにくくなります。

5. 戻す操作だけでデータまで戻るとは考えない

実行するPHPを旧版へ戻しても、更新中に書き換わったデータベースやファイルが自動で元に戻るわけではありません。ほかのソフト更新も行った場合は、必要なデータと設定を対応する状態へ戻す手順を確認します。

一方で、古いバックアップを本番へ戻すと、その後の問い合わせや投稿を失うことがあります。何を失う可能性があるかを確認せず、焦って全体を上書きしないでください。復旧の判断者、保存しておくログ、停止条件を事前に決めることが役立ちます。

作業後は実行版・確認結果・残る課題・次の確認期限を記録します。旧版へ一時的に戻した場合も、そのまま放置せず問題を解決する計画を残します。準備は検証環境の確認表とバックアップの基本を合わせて確認できます。

更新の前に控えておく情報

表は横にスクロールできます。

よくある症状と、最初に見る場所

表は横にスクロールできます。

原因が分からないまま設定を何度も変えると、どれが効いたのか分からなくなります。まず元のバージョンに戻してサイトを動く状態にし、テスト環境で原因を探すのが安全です。

サーバー会社から切り替えの案内が来たとき

古いPHPのバージョンは、サーバー会社の案内で提供が終わることがあります。案内が来たら、切り替えの期限と、期限を過ぎたときに自動で切り替わるかを確認します。期限の直前に慌てないよう、案内を受け取った時点でテスト環境での確認を始め、余裕を持って本番を切り替えます。作業の流れはテスト環境で確認する手順も参考にしてください。

PHPの更新を任せたい方へ

サーバーの切り替えや、プラグインの対応確認を自分で進めるのが不安な場合は、当サイトのWordPressの安全対策で、PHPの更新を税込5,000円で承ります。作業前にサイト全体のバックアップを取り、切り替え後にトップ・記事・お問い合わせフォームの表示を確認します。新しいPHPで動かない部分があれば、元の状態に戻したうえで対応をご相談します。