WordPressのPHPバージョンアップで失敗しないために｜移行先の選び方と確認手順
公開日： ／ 執筆：株式会社Create Reality
WordPressのPHPバージョンアップは、移行先のサポート状況とサイト全体の互換性を確認し、テスト環境で主要機能を検証してから本番へ反映するのが基本です。サーバーの選択欄で新しい番号を選ぶ前に、変更対象と戻す手順を決めておきましょう。
この記事では、企業のWeb担当者がサーバー会社や制作会社と確認するための判断材料をまとめます。WordPress本体の更新準備全般は、WordPressアップデート前のチェックリストをご覧ください。
PHP更新とWordPress更新は別の作業
PHPはWordPressを動かすサーバー側の実行環境です。WordPress本体を更新しても、サーバーのPHPが同時に更新されるとは限りません。また、PHPだけを変更しても、古いプラグインや独自開発部分の問題がすべて解消するわけではありません。
| 対象 | 確認する内容 | 主な確認先 |
|---|---|---|
| PHP | 利用中のバージョン、選択可能な移行先、適用範囲 | サーバー管理画面・サーバー会社 |
| WordPress本体 | 現在のバージョンと移行先PHPへの対応 | 管理画面・公式情報 |
| テーマ・プラグイン | 提供元の対応情報と更新状況 | 開発元の案内 |
| 独自コード | 非互換な処理、利用する拡張機能 | 制作会社・開発担当者 |
移行先は「推奨要件・サポート期限・互換性」で決める
2026年11月13日時点のWordPress公式の推奨環境では、PHP 8.3以上が挙げられています。ただし、この数字だけで、使用中のすべてのテーマやプラグインが動くと判断することはできません。
PHP公式のサポート表では、通常の修正が行われる期間と、重要なセキュリティ問題への対応期間が区別されています。確認日時点でPHP 8.2のセキュリティサポート期限は2026年12月31日です。動作しているかだけでなく、移行先をどのくらい保守できるかも判断材料にしてください。
まずサーバーで提供される候補を確認し、WordPress・利用機能・独自コードの対応状況と照合します。最新候補に未対応の機能がある場合は、代替機能やコード改修も含めて計画します。古いPHPを使い続ける前提で先送りするのではなく、移行を妨げている機能と解消期限を記録しましょう。
手順1：変更するサイトと現在の構成を記録する
担当者への引き継ぎにも使えるよう、次の情報を一枚にまとめます。
- 対象ドメインとサイトの用途
- 現在と移行先のPHPバージョン
- WordPress、テーマ、主要プラグインのバージョン
- フォーム・予約・決済など、止められない機能
- 独自開発した処理と保守担当者
- バックアップの取得日時と復元担当者
共有サーバーでは、PHP設定がどの単位で適用されるかを確認します。同じアカウント内に複数のサイトがある場合、対象サイトだけの変更か、別のシステムにも影響する設定かを、サーバー会社の説明で確かめてください。ターミナルで表示されるPHPとWebサイトで使われるPHPが異なる構成にも注意が必要です。
WordPress側のバージョン確認方法は、公式PHP更新ガイドにある「ツール → サイトヘルス → 情報 → サーバー」が参考になります。同ガイドでは、バックアップ、テーマやプラグインの互換性確認、ステージング環境での試験も案内されています。
手順2：本番に近いテスト環境で確認する
テスト環境は、本番サイトを複製して変更を試すための環境です。可能な範囲でPHPの設定や必要な拡張機能もそろえます。コピー直後は本番用の通知先や外部連携が残る場合があるため、試験メール・決済・予約が実際の顧客や業務に影響しない設定を先に確認してください。外部からの閲覧制限も設けます。
PHPを切り替える前に現在の環境で確認し、切り替え後に同じ操作を繰り返すと、変更による差分を調べやすくなります。テーマなどの更新が必要な場合も、変更内容と試験結果を段階ごとに残すと原因を切り分けやすくなります。
| 確認する機能 | 完了の判断例 |
|---|---|
| 公開ページ | 主要ページ・記事・検索結果が表示される |
| 管理画面 | ログイン、編集、保存、画像アップロードができる |
| 問い合わせ | 入力エラー表示から送信、試験用宛先への受信まで確認できる |
| 予約・購入 | 検証用の設定で受付・確認・取消の流れを確かめられる |
| 定期処理 | 予約投稿やデータ連携などの実行結果を確認できる |
| エラーログ | 変更前後のエラーや警告を担当者が確認している |
トップページが表示されるだけでは十分ではありません。利用者の操作と、管理者が日常的に行う操作を両方確認します。画面に出ないエラーもあるため、ログの確認を開発担当者に依頼するときは、発生時刻と再現手順を添えてください。
手順3：互換性の問題を解消してから本番へ切り替える
独自コードを利用している場合は、移行先だけでなく、飛び越える各バージョンの変更点も調べます。たとえばPHP 8.3から8.4への公式移行ガイドには、後方互換性のない変更や非推奨機能の項目が用意されています。プラグインの「最低PHP要件」を満たすことと、新しいPHPでの動作が検証されていることも別です。
問題のある機能は、更新・改修・代替などの対応を決めて再試験します。警告を画面に表示しない設定にすることと、原因を修正することを混同しないでください。本番利用者に詳細なエラー情報を見せるのではなく、担当者が適切にログを確認する体制を用意します。
手順4：本番切り替えと復旧判断を一組で準備する
実施前に、作業時間、担当者、完了条件、不具合時の連絡先を決めます。バックアップはファイルとデータベースを含め、復元方法を確認してください。サーバー側で以前のPHPへ戻せるかも事前確認が必要です。
切り替え後はテスト環境と同じ項目を本番で確認します。フォーム試験は許可した宛先を使い、実際の注文や決済が発生しない方法を担当者と決めてください。
重大な不具合が起きたら、原因の推測で次々に設定を変える前に、決めた手順で停止・切り戻しを判断します。データベースを古いバックアップに戻すと、その後の問い合わせや注文情報を失う可能性があります。PHPだけの切り戻しとデータ復元を分け、復元範囲を確認してください。旧環境に戻せても、それを恒久対応にせず、問題を修正して再移行する計画を立てます。
自社対応と外部依頼を分ける目安
担当者が構成を把握しており、テスト環境・復元手順・必要な権限がそろっているなら、サーバー会社の手順をもとに対応を計画できます。一方、制作当時の担当者が不明、独自テーマがある、予約や決済が止められない場合は、事前調査を含めた依頼を検討しましょう。
依頼時は「PHPを上げたい」だけでなく、対象URL、利用中のPHP、残したい機能、作業できる時間帯を伝えると範囲を整理しやすくなります。Create Realityでは、WordPressアップデート対応として本体・プラグイン・PHPの更新をご相談いただけます。継続的な点検はWebサイト運用保守でも承ります。
本記事は2026年11月13日に確認した公式情報を参考にしています。推奨要件やサポート期限は変更されるため、実施時点の公式情報とサーバー会社の案内を確認してください。
