WordPressのPHP互換性を確認する方法｜本体・テーマ・プラグインの検証票

WordPressのPHP互換性は、本体の対応表だけでは判断できません。使っている本体・テーマ・プラグイン・独自コード・サーバー条件をそろえ、更新先の候補で必要な機能が動くか確認します。提供元の対応情報と、自分のサイトの動作記録を別の根拠として残してください。

この記事は、PHPの切り替え前に何を調べ、どの機能を検証すればよいか迷う企業担当者と制作会社向けです。サーバー画面の操作や本番切り替えの手順は、PHP更新と戻し方を整理した既存ガイドへつなぎます。ここでは、切り替えの判断に必要な互換性の検証票を作ることに集中します。

1. 現在の構成と候補の環境をそろえる

まず、実際にWordPressを動かしているPHPの版を記録します。WordPressのサイトヘルス情報、契約サーバーの管理画面、管理担当者の資料を確認してください。操作権限や表示される項目は環境で異なるため、場所が分からない場合はホストへ確認します。版を調べるために、先に設定を切り替える必要はありません。

WordPress本体、利用中のテーマと子テーマ、プラグイン、独自機能の名称と版も一覧にします。停止中のプラグインについても、使っていないから削除してよいと即断しません。保存データ、連携、再利用する予定を確認し、今回の動作確認の対象と管理上の残課題を分けます。

候補環境は、PHPの版だけでなくサーバー条件も記録します。拡張機能、メモリ制限、メールの送信経路、実行時間などが異なる環境では、同じ操作でも結果が変わる場合があります。すべての値を公開する必要はありませんが、比較した環境が何かを管理記録で追えるようにしてください。

調査した日と資料の確認者も残します。サーバー側の強制変更予定や提供元の対応版が変われば、以前の検証結果だけでは判断できません。記事の「最新」という表現より、自分の環境と確認日の一致を重視してください。

2. PHPのサポートと製品の互換性を分ける

PHPのサポート期限はPHP公式のSupported Versionsで確認します。2026年10月1日の表では8.2、8.3、8.4、8.5が掲載され、8.2のセキュリティサポート終了は2026年12月31日です。以前の記事にある「8.1は終了予定」「8.4が最新」という説明をそのまま使わないでください。終了日と、現在提供される候補を作業日に見直します。

WordPress本体には、本体とPHPの互換性表があります。ここで対象のWordPress行とPHP列を確認します。たとえば、確認日の表で6.8と8.5の組合せは対応が示されず、6.9と8.5の組合せは対応が示されています。「WordPressを使っているから、提供されるPHPならすべて同じ」とは判断できません。

この表は本体についての資料です。テーマ、プラグイン、独自コード、外部連携の動作をまとめて保証するものではありません。本体の対応が確認できても、追加機能の確認を省かないでください。サーバーが候補のPHPを提供していることも、サイト全体が正常に動く証明とは別です。

候補は、PHPのサポート、WordPress本体、追加機能、ホストの条件を照合して選びます。最も新しい番号へすぐ切り替えるか、古い版へ戻せばよいかを記事だけで一律に決めないでください。戻せる候補や期限は、ホストの現在の提供条件に左右されます。

性能を目的にする場合も、一定割合の高速化を約束できません。PHPの実行時間とページ全体の表示には異なる要因が関係します。同じページ、操作、計測条件で比較し、互換性の合否と性能の結果を別に記録します。

3. Tested up toとRequires PHPの意味を読み分ける

プラグインの掲載ページには、版や要件に関する項目があります。「Tested up to」はWordPress本体のテスト対象版であり、PHPの試験済み版を示す項目ではありません。「Requires PHP」はPHPの最低要件です。最低要件を満たしていることだけで、それより新しいPHPのすべてに対応すると判断しないでください。

WordPress公式のプラグインreadmeの説明では、これらの項目の意味が区別されています。実際の掲載情報と提供元の変更履歴を確認し、現在使っているプラグインの版についてどこまで情報があるかを記録します。別の版の対応発表を、現在の版の根拠にしないでください。

テーマや有料プラグインでは、配布元の対応表、リリースノート、問い合わせ回答も確認対象になります。契約を終了して更新できない製品、配布元が分からない独自製品は、その事情も記録します。資料がない場合に「たぶん動く」と埋めず、未確認と扱います。

自動のコード検査ツールを使う場合も、対象、検知できる問題、見ていないコードを確認します。検査でエラーがないことと、実際のフォーム、予約、保存、定期処理が動くことは別です。使ったツールの結果は補助資料として残し、動作確認の代用にしないでください。

4. 独自コードと外部連携も検証対象にする

サイトの機能は、配布されている製品だけで構成されているとは限りません。子テーマ、独自プラグイン、テーマ内の追加コード、管理画面の設定から読み込む処理など、独自変更があるか確認します。制作会社が交代している場合は、納品物や変更履歴、元の担当者が残した資料を照合してください。

独自コードでは、PHPの移行ガイドなどを参照し、候補の版で変わる仕様と使っている処理を照合します。記事の短い説明だけで、すべての互換性の問題を判断することはできません。ログの警告やエラーは、対象ファイル、操作、環境をそろえて開発担当へ共有します。

外部連携は、API、メール、認証、決済、予約、データ同期など、業務上の役割から一覧にします。トップページが表示されても、送信や定期処理が止まっている場合があります。WordPress内の操作だけでなく、外部側で受け付けた記録をどのように確認するかも決めます。

検証に本物の顧客情報や決済を使う場合は、必要性と許可を先に確認してください。複製した環境が、本番の外部サービスへ実データを送信しないよう、接続先やテスト用の条件を整理します。一般的な「ステージングを作れば安全」という説明だけで済ませないことが大切です。

担当者が分からない機能は、勝手に外して試す対象にしません。何に使われているか、保存データ、止めたときの影響、代替や戻し方を調べます。情報が不足した箇所を残課題として返すことで、不要な削除や復元できない変更を避けられます。

5. 試験項目はサイトの業務から決める

試験は、画面を見ることだけで終えず、サイトを使う人の操作から決めます。経営者やWeb担当は、止まると困る機能を整理してください。制作会社は、それを実装と保存・送信・外部連携の確認項目へ落とします。すべてのサイトへ同じ長い検証表を適用する必要はありません。

基本の確認には、公開ページ、記事や固定ページの表示、管理画面のログイン、編集と保存、画像の扱いがあります。フォームがあるなら、入力、確認、送信処理、合意したテスト送信先の実受信まで分けます。送信完了画面が出ることと、必要な担当者へ情報が届くことは異なる結果です。

予約・会員・決済などがある場合は、受付、状態変更、通知、管理側での確認を機能ごとに分けます。テストできない操作には、未確認の理由と確認を担う人を書きます。実際に試していないのに、一覧のチェックだけで合格にしないでください。

定期処理や管理画面でしか使わない機能も、使っているなら対象に含めます。毎日実行される処理を確認していないまま、公開直後の画面だけで完了にしないでください。必要な確認期間がある場合は、切り替え予定へ反映します。

6. 別環境で同じ操作を試し、結果を読み戻す

別環境を用意するときは、本番とPHPを独立して変更できるか確認します。複製したWordPressがあっても、PHPの設定が本番と同じ範囲へ適用されるなら、独立した試験とは言えません。契約ホストや管理担当へ、設定の対象、接続先、公開状態を確認してください。

試験前に、元の版と操作結果を保存します。候補へ変更した後も同じページと同じ操作で確認し、差があれば記録します。同時にテーマや複数プラグインを変更すると、問題の原因を切り分けにくくなります。必要な更新を伴う場合は、変更順と対象の版を残します。

ログを見る場合、検証前からあった警告と、今回の操作で新しく発生した警告を分けます。警告がないことだけで全機能の合格にはしません。一方で、表示が動いているからといって、ログに出た問題を無視する必要もありません。内容と影響を開発担当へ確認し、合否と残課題を判断します。

不具合を再現できる記録には、操作したURLや画面、手順、使用環境、起きた時刻、期待した結果、実際の結果を含めます。ログの認証情報や顧客情報は共有前に除き、公開記事や通常の問い合わせ欄へ貼らないでください。

修正した後は、不具合の操作だけでなく、影響する関連機能も確認します。検証票の判定を更新し、試験環境だけで合格なのか、本番でも確認済みなのかを明記してください。候補環境の結果を、そのまま公開後の証拠として使わないことが重要です。

7. 切り替え判断へ渡す資料をまとめる

互換性の確認ができたら、構成票、提供元の資料、検証結果、未確認事項、必要な修正を一つの引き継ぎにまとめます。「問題ありません」という一文だけでは、何を確認したか後から追えません。確認日の違う資料や、別の版を試した結果を混ぜないでください。

本番へ進む判断には、互換性に加えて、対象、予定日時、権限、更新直前のバックアップ、戻し方、承認者が必要です。動的に増えるデータをどこまで戻せるか、ホストが元のPHPをまだ提供するかも確認します。候補環境での合格だけで、本番変更を始めないようにします。

画面が白くなるなどの症状が出た場合、症状だけで原因の製品を決めません。変更内容とログ、サーバーの状態を見て切り分けます。テーマやプラグインのフォルダ名を無条件に変える操作は、他機能や保存データへ影響する場合があります。管理画面へ入れない場合も、個別環境の復旧手順と権限を確認して担当者へ引き継いでください。

検証票に未確認が残る場合は、そのリスクと確認担当を明示します。業務上重要な操作が未確認なら、先に追加の検証や調査を行う判断があります。確認不能な状態を「たぶん問題ない」と置き換えて公開しないでください。

実際の切り替えと公開後の確認は、PHP更新の計画・切替・復旧ガイドも参照してください。ここで作った票を使うことで、更新手順の記事を読み直すだけでは残る、製品ごとの根拠不足を見つけられます。

8. 自社とAcquaの調査・検証の役割を決める

企業側は、止められない業務、使っている機能、管理契約、希望時期、確認担当を共有します。Acquaへの相談では、構成の調査、提供元情報の照合、検証票の作成、別環境での確認、不具合の一次調査など、必要な工程を環境に応じて整理します。すべてのPHP切り替えや独自機能の改修を一律に受け付ける保証ではありません。

企業向けWeb制作・保守の案内で、現在のサイトの確認と対応範囲を相談できます。提供元の資料と自社の試験で判断できる場合は、自力で整理して完了です。管理担当が不在、独自実装の担当が不明、別環境を用意できない場合は、どこから調査するかを相談してください。

制作会社の方は、Acquaへの実装・保守の受託案内に沿って、支給資料、独自変更、顧客の承認、テスト送信先、検収条件を共有します。調査、改修、検証、本番切替の担当を分け、未確定な作業は別の見積や判断として残します。顧客への直接連絡や本番の権限も事前に合意してください。

相談前にサイトURL、現在の版、ホストからの通知、止まると困る機能、希望する時期を用意します。分からない項目は不明のままで構いません。お問い合わせへ認証情報や顧客データを貼らず、必要な権限の渡し方を先に確認してください。

支援後の解決状態は、対象構成と根拠、必要機能の検証結果、未確認事項、切り替えと戻し方の担当がそろっていることです。更新した番号や速度の変化だけでなく、業務が継続できるかを確認します。調査・修正・検証・連絡の工数と費用も残し、今後の保守に無理がないかを見直してください。

本体の互換性表で対応なら、サイト全体も動きますか？

テーマ、プラグイン、独自コード、外部連携は別に確認します。本体の表だけではサイト全体の動作を保証できません。

Requires PHPより新しい版なら何でもよいですか？

最低要件と新しい版への対応は別です。提供元の資料と候補環境の試験を照合します。

自動検査が合格なら、動作確認を省けますか？

省けません。検査の対象外や実行時の条件があるため、業務上必要な表示・保存・送信・定期処理を確認します。

PHP更新でサイトは必ず速くなりますか？

一定の改善率は約束できません。同じ条件で性能を測り、互換性や業務の確認とは別の結果として扱います。

参照した公式資料（2026年10月1日確認）：PHPのサポート表、PHP 8.5移行ガイド、WordPress本体とPHPの互換性、プラグインのreadme項目。検証票は作業を整理するための編集案です。個別環境の対応や復旧条件は作業時点で確認してください。