WordPressのPHP更新手順｜バージョン選び・互換性確認・復旧判断まで

WordPressの管理画面やサーバー会社から、PHPの更新を勧める通知が届いた。更新したいけれど、問い合わせフォームや管理画面が動かなくなるのは困る。このような場面では、管理画面の切り替えボタンを探す前に、現在の構成、更新先の条件、問題が起きたときの戻し方をそろえることが大切です。

この記事では、企業サイトの担当者が制作会社やサーバー会社と更新を進めるために、バージョンの選び方、互換性の調査、検証、本番反映、復旧判断を整理します。PHPとWordPressの公式資料を根拠に、実際に変更された仕様の例も紹介します。途中の会社サイトや確認メモは説明用の架空例で、Acquaの顧客成果ではありません。

PHPの更新で最初に押さえたい三つのこと

WordPress本体の更新とPHPの更新は別の作業

PHPは、サーバー上でWordPressなどのプログラムを動かすための言語・実行環境です。WordPress本体、テーマ、プラグインを更新する操作と、PHPのバージョンを変更する操作は同じではありません。本体が新しくてもPHPが古い場合があり、PHPだけ新しくしても古いテーマのコードが対応するわけではありません。

まずは、サーバー管理画面でPHPの設定を変更する権限が誰にあるかを確認します。WordPressへログインできても、サーバー契約を管理できるとは限りません。制作会社が管理しているなら、通知の内容、対象ドメイン、現在のバージョンを共有し、どこまでが保守契約に含まれるかを聞きます。通知メールに書かれた期限も、作業予定を決める材料になります。

動いていることと、サポートされていることを分ける

PHP公式のサポート期間の一覧では、通常の不具合修正を含む期間と、重要なセキュリティ修正に限定した期間を区別しています。期間が終了した系列には、公式から修正が提供されなくなります。今の画面が正常に表示されることだけでは、今後も維持できるかを判断できません。

一方で、古いという情報だけから、そのサイトが既に侵害されていると決めることもできません。現在の構成とサポート状況を把握し、移行までの対応と移行日を決めます。ホスティング会社独自の延長サポートがある場合は、PHP公式の期間と区別し、対象範囲や終了条件を契約先へ確認してください。名称が似ていても、提供主体と対応内容は同じとは限りません。

目的は、業務を維持しながら更新できる状態を作ること

更新の目的を「数字を新しくする」だけにすると、フォームの受付や社内の編集作業が保たれたかを見落とします。会社案内の表示、見積もり相談の受付、お知らせ更新、予約通知など、そのサイトで止められないものを先に書き出します。担当者が説明できる完了条件を作ってから、技術的な作業範囲へ落とし込みましょう。

PHPの更新により性能が変わる可能性はありますが、サイト全体の速度が一定割合で改善するとは限りません。画像、キャッシュ、外部サービス、データベースなども表示に関係します。「更新すれば必ず速くなる」「検索順位が上がる」という約束ではなく、サポートのある構成へ移行し、必要な機能を維持できたかを基本の評価にします。

更新先はサポート期限と互換性の両方から選ぶ

2026年9月時点の公式サポート期間を確認する

次の表は、PHP公式の一覧を2026年9月9日に確認したものです。末尾の細かな修正版ではなく、8.3などの系列ごとの期限を示しています。作業日が後になる場合は、上の公式ページを開き直し、利用できる修正版と契約サーバーの提供状況も確認してください。

この時点では、8.2と8.3はセキュリティ修正の期間に入っています。8.4と8.5は通常のサポート期間内です。この表は移行計画の期限を考える資料であり、上の行や下の行を選べばすべてのサイトで動くという互換性の表ではありません。残り期間だけで決めず、次に説明するWordPress側の条件と照合します。

WordPressの推奨条件を、サイト全体の保証と混同しない

WordPress公式の要件は、確認日時点でPHP 8.3以上を推奨しています。また、開発チームのPHP互換性の一覧では、WordPress本体のバージョンごとに対応関係が示されています。「WordPressなら同じ条件」とまとめず、使っている本体のバージョンを確認して読みます。

この一覧で本体が対応していても、追加したテーマ、プラグイン、独自コードがすべて確認されたことにはなりません。候補のPHPに対して、使用中の製品の案内と実際の検証結果をそろえます。「8.3以上」という推奨を「8.3だけが最も安全」と読み替えたり、公開年が新しい製品だから対応済みと推測したりしないことが重要です。

候補を決めた理由と、次の見直し時期を残す

候補は、サーバーが提供していること、本体・製品の対応情報があること、必要な機能を別環境で検証できることから絞ります。最新系列へ進める条件がそろう場合もあれば、特定機能の対応を待つために別の系列を選ぶ場合もあります。どちらの場合も「なんとなく安定していそう」ではなく、確認した材料を理由として残しましょう。

暫定的な選択なら、そのまま無期限に使い続けないよう、何が解消すれば次へ進めるかを決めます。例えば「予約機能の対応版を確認したら再検証」「契約サーバーの提供開始後に候補へ加える」と記録します。サポート終了直前になって初めて調査することを避けるため、社内の予算や繁忙期も考えて見直し日を置きます。

公式の変更例から、互換性確認が必要な理由を知る

PHP 8.0では、以前使えた関数が削除された

PHPの8.0移行ガイドには、create_function()やeach()の削除が記録されています。古い独自コードがこれらを呼び出していたら、新しい環境でそのまま使えるとは限りません。これは公式に公開された仕様変更の実例で、特定のWordPressサイトで障害が起きたという顧客事例ではありません。

実務上は、サイトを作った年だけで影響を判断せず、現在動いているコードを調べます。テーマを更新していても、子テーマや独自プラグインに以前の処理が残る場合があります。確認担当には、製品の一覧だけでなく、過去に独自追加した機能や修正箇所も共有します。コードを修正する場合は、元の処理の目的を理解した担当者が変更し、該当機能を再確認します。

警告だった処理が、実行を止めるエラーになる場合がある

同じPHP 8.0の公式ガイドには、数を数えるcount()へ数えられない型を渡すと、TypeErrorになる変更も説明されています。「以前は結果が表示されていた」という観察だけでは、入力値や処理の前提が適切だったとまでは分かりません。更新によって、以前からあったコードの問題が表面化する場合を考える必要があります。

例えば、説明用の架空サイトで、記事に関連項目がある場合は動き、関連項目が空のときだけ失敗するとします。この場合、代表ページを一枚見るだけでは確認が足りません。データがある・ない、入力が正しい・不足している、ログインしている・していないなど、機能の条件を変えて確認します。すべての組み合わせを無制限に試すのではなく、使う機能と過去の不具合から重要な条件を選びます。

非推奨の通知と、現在の機能停止を分けて扱う

PHP 8.2の非推奨機能の公式案内では、例外となるケースを除き、動的プロパティの作成が非推奨になったことが示されています。非推奨の通知は、将来に向けてコードの見直しが必要な手がかりです。一方で、その語が記録されたことだけを、サイト全体が停止した原因と断定することはできません。

ログを読む際は、通知の種類、発生した処理、時刻、実際の症状を対応させます。画面が表示できるから通知をすべて無視することも、通知があるからすべての更新を中断することも、適切な判断とは限りません。現在の業務への影響、修正の必要性、製品開発元の対応状況を確認し、更新の可否と残る改善事項を分けて決めます。

準備では、構成の調査と復元方法を具体化する

現在の構成と、変更する順序を一覧にする

現在のPHP、WordPress本体、テーマ、主要プラグイン、独自コード、外部連携を書き出します。PHP側の拡張機能や設定が関係する機能も、保守担当へ確認します。画面表示だけでなく、画像処理、メール、予約、データ出力などの担当製品を対応させると、検証範囲を決めやすくなります。

「PHPを上げる前に全部を最新にする」という一律の順序では、現在のPHPで新しい製品が動かない場合に行き詰まります。古い構成から移る場合は、本体・製品・PHPの条件を照合し、途中で必要になる更新や置き換えを計画します。順序は別環境で確かめ、変更履歴に残します。不要プラグインの判断は、プラグイン整理の確認手順も参照してください。

バックアップは、取得だけでなく復元まで確認する

WordPressの公式バックアップガイドでは、一般的なサイト全体の復元にファイルとデータベースの両方が必要と説明しています。取得日時、保存先、対象範囲、復元担当を記録し、別環境で戻せることを確認します。バックアップ一覧に成功と表示されたことだけで、本番を復旧できると結論づけないようにします。

PHPの切り替えと同時に製品更新やデータ移行を行う場合は、PHPを戻すだけで以前の状態へ戻るとは限りません。どの段階で何が変わるかを整理し、必要なファイルとデータの組み合わせを復元手順へ含めます。バックアップからの復元で、その後に届いた問い合わせや注文を失わないよう、追加データの保全と更新を止める範囲も決めておきます。

サーバー側の切り替え条件と、作業できる人を確認する

サーバー会社によって、PHPを変更する画面、反映までの時間、対象ドメインの範囲、旧バージョンへ戻せる条件は異なります。契約中のサービスの公式案内を確認し、分からない点は窓口へ聞きます。特に複数のサイトを管理する契約では、一つの変更がどこへ影響するかを明確にしてください。

確認メモには、操作する担当、判断する担当、連絡先、作業時間、異常時の連絡方法を書きます。担当者が外出している時間に切り替え、別の人が状況を把握できない、といった運用上の空白を避けるためです。認証情報の共有は、必要な対象と方法を決めてから行います。記事の一般手順からサーバー画面の項目名や反映時間を推測して操作しないようにしましょう。

別環境で、訪問者と更新担当の両方の動作を確認する

検証環境と本番環境の違いを書き出す

検証環境は、本番と同じPHPの系列を選ぶだけでは十分でないことがあります。テーマやプラグインの版、データ、拡張機能、キャッシュ、外部接続など、違いがある箇所を記録します。本番と完全に同じにできない場合も、何を確認でき、何が確認できないかを把握しておけば、本番で必要な確認を具体化できます。

サイトを複製すると、通知先や決済連携も引き継がれる場合があります。検証用のメール、決済のテスト機能、外部接続の制御などを準備し、通常の顧客や社内業務へ誤って動作させない条件を作ります。実データを使う必要があるかも判断します。検証用のサイトを置いたことと、その環境で安全に入力・送信を試せることは別です。

操作と期待する結果をセットで確認する

確認表には「フォーム確認」とだけ書かず、「必須項目を空欄で送ると該当欄へ案内が出る」「正しく入力すると完了画面になり、許可したテスト先へ通知される」のように期待する結果を書きます。実際に受信を確認できない環境なら、その項目を未確認として残し、本番で許可された方法を使って確かめます。

入力データはテストと分かる内容を使い、確認後にどう扱うかを決めます。注文や予約があるサイトなら、受付だけでなく変更・キャンセル・担当者の確認まで、業務に必要な経路を追加します。会社案内とECサイトを同じ表の項目数だけで判定せず、そのサイトの利用に合わせて完成させてください。

自動チェックと目視・実操作の役割を分ける

コードの互換性を調べるツールやテストは、問題の候補を探す助けになります。ただし、対応するPHPの範囲や解析対象を確認し、検出されなかったことを、全機能が正しく動く証明にしないでください。ツール名を選ぶより先に、何を確認したいかを決め、その確認に使えるかを判断します。

自動処理で一覧できる警告と、担当者が実際に見て判断する内容を分けると、作業報告も読みやすくなります。例えば「解析対象のコードで候補なし」「予約完了まで実操作済み」「月次通知は未実行」という状態は別です。PHP更新の完了条件を満たすために、どの未確認をいつ埋めるかまで決めておきます。

本番の切り替えは、確認と戻す判断を一組にする

実行前に、検証後の変更と受付状況を確かめる

検証から本番反映までに、プラグインの追加やフォームの変更があれば、検証した構成と本番が変わっています。作業前に差分を確認し、影響する部分を再検証します。確認済みという記録に日付とバージョンを付けるのは、過去の結果を別の構成へそのまま当てはめないためです。

切り替え直前には、必要なバックアップ、担当者の待機、通知と連携の状態、作業後の確認表をそろえます。アクセスが少ない時間でも、重要な予約や自動処理が動いていることがあります。事業の受付周期と社内担当の対応時間から実施時間を決め、必要な案内があるなら事前に準備します。

切り替え後は、設定値と実際の動作を確認する

契約サーバーの公式手順に従って対象を変更したら、管理画面の選択値に加え、サイト側で使われているPHPと動作を確認します。反映待ちやキャッシュなど、環境固有の条件も案内に従います。ブラウザーで一度トップを開いたことだけで完了にせず、先に決めた閲覧・入力・編集の経路を確認します。

定期処理は、その場で通常の周期が来ないこともあります。許可されたテストで確認するか、次の実行結果を確認する担当と時刻を記録します。公開直後の確認が終わった範囲と、運用を続けながら確認する範囲を分けておくと、引き継いだ担当者も状況を把握できます。

戻せる条件と、戻した後の確認を決めておく

戻す判断には、主要ページが表示できない、必要な受付が完了しない、編集作業に重大な支障があるなど、業務への影響を使います。旧PHPへ変更できるか、製品更新の取り消しやデータ復元も必要かは、準備段階の手順で判断します。「数クリックで戻せる」という操作の容易さと、サイトが復旧することは同じではありません。

戻した後も、表示と受付を再確認し、影響した時間と残る問題を記録します。緊急回避として古い構成へ戻す場合は、更新計画を終了せず、原因の調査と次の検証日を決めます。サポートが終わった構成へ戻ったことを、保守上の課題が解決した状態とは扱いません。

トラブルが出たら、症状と変更履歴から切り分ける

白い画面や管理画面の停止は、原因を一つに決めない

画面が表示できないときは、対象URL、発生時刻、表示されたメッセージ、直前の変更、影響範囲を記録します。原因はテーマやプラグインに限らず、PHPの設定や必要な拡張機能、サーバー側の条件なども調査対象です。症状だけを見て「必ずこのプラグイン」と断定せず、作業担当が変更記録とログを照合します。

管理画面に入れない場合でも、すべてのプラグインのフォルダ名を次々に変更するような作業を、状況を整理せずに進めないでください。必要な連携や設定に別の影響を加える可能性があります。受付に影響するなら、調査と業務復旧の優先順位を判断し、合意した復元方法と連絡体制に従います。

ログは公開画面に出さず、必要な情報を保管する

WordPressの公式デバッグガイドは、エラーの記録と画面表示を制御する設定を説明しています。単にデバッグを有効にする操作だけを本番へ加えるのではなく、保守担当が保存先、閲覧できる人、公開への露出を確認して使います。必要な期間だけ記録し、内容に認証情報や個人情報が含まれていないかにも配慮します。

開発元へ問い合わせる場合は、製品とPHPのバージョン、再現操作、期待する結果、実際の結果、関係するログを必要な範囲でまとめます。ログ全体やバックアップを公開フォーラムへ貼り付けるのは避け、案内された適切な共有方法を使います。情報が整理されていれば、同じ症状の確認や担当間の引き継ぎを進めやすくなります。

対応版がない機能は、事業上の必要性から見直す

古い独自機能や更新の止まった製品が移行を妨げる場合は、対応版を待つ、修正を依頼する、代替へ移す、役割を終えた機能を終了するという選択肢を比較します。名前が似た製品へ置き換えるだけでは、保存データ、通知、URL、編集方法が引き継がれるとは限りません。利用部署に必要な動作を確認してから範囲を決めます。

例えば、架空の企業サイトで古い資料一覧の機能が更新できないなら、公開資料のURL、分類、検索、担当者の追加操作を必要条件として整理します。代替案のデザインだけで判断せず、過去の資料へ到達できるかまで確認します。PHP更新をきっかけに機能を見直す場合も、移行作業として費用と日程を分けて把握すると、依頼内容が明確になります。

制作会社へ依頼するときの確認項目と、更新後の運用

見積もりは切り替え操作だけで比較しない

WordPress公式のPHP更新の案内も、バックアップや互換性の準備、問題がある場合の支援を説明しています。依頼時には、現状調査、更新順序の検討、検証環境、修正、バックアップ、本番反映、反映後の確認がどこまで含まれるかを聞きます。管理画面の操作料金だけでは、作業全体を比較できません。

調査しないと修正の規模が分からない場合は、調査と実施を段階に分ける方法があります。見積もりには、調査で分かること、実施前に再確認する金額、対応できない製品が見つかった場合の扱いを記載してもらいます。何をもって完了とするか、公開後の問題にどの期間・範囲で対応するかも、契約前に確認しましょう。

社内から渡す相談メモを用意する

最初の相談では、サイトURL、届いた通知、現在分かるバージョン、契約サーバー、保守担当、困っている症状、止められない機能を共有します。分からない項目は未確認と書けば構いません。管理画面の認証情報を先に広く配るより、調査対象と必要な権限を決めるところから進めます。

説明用の相談メモなら、「会社案内と見積もり受付に使用。月末は更新が多い。サーバーから期限の通知あり。独自の資料検索があり、仕様書の所在は未確認。まず更新先と必要な修正範囲を調べたい」と書けます。制作会社を変える場合は、ホームページ引き継ぎの確認表も使い、契約・権限・データを合わせて整理してください。

更新記録を、次の担当が使える形で残す

完了時には、変更前後のバージョン、実施日、修正した製品、検証項目、結果、未確認事項、バックアップと復元方法の所在を記録します。次回の担当者が、何を確認した構成なのかを理解できることが大切です。サポート期限の確認日と次の見直し日も加え、通知が届いてから慌てて準備する運用を減らします。

AcquaへWordPress保守・更新を相談する際は、「更新してよいか分からない」「独自機能が残っている」「復元方法を把握していない」といった状況から共有してください。まず調査が必要な範囲と、維持したい業務を整理します。PHP更新を一回の切り替えで終えず、必要な機能を確認して維持できる運用へつなげましょう。

一次資料の確認日：2026年9月9日。サポート期限・推奨条件・製品の対応状況は、実際の作業時に公式情報を再確認してください。