2026年10月21日、PHP の開発チームは、外部から不正なプログラムを実行されるおそれのある2件の重大な脆弱性を公表し、修正版を公開しました。脆弱性とは、攻撃に悪用される可能性のある、ソフトウェアの弱点のことです。今回の問題は WordPress のプラグインではなく、その土台である PHP 側の問題で、PHP 公式は速やかな更新を呼びかけています。
この発表や、レンタルサーバーからの案内をきっかけに、PHP の更新を考えた方もいるのではないでしょうか。まずはサーバー会社や保守担当者に、今回の修正が自分の利用環境へ適用されているかを確認してください。その後の追加案内も含め、必要な対応を確認しておきましょう。
今回の問題への修正適用と、PHP 5.6 系や 7.4 系などからサポート対象の新しい系列へ移る作業は、分けて考える必要があります。新しい系列への移行準備に時間がかかる場合も、今回の脆弱性への対応まで先送りせず、当面の対応と移行計画を担当者に相談しましょう。
一方で、「更新したらサイトが動かなくならないか」「動作確認と言われても、どこを見ればよいのか」と迷うこともありますよね。
この記事では、WordPress サイトの PHP を更新するときに、サイトの持ち主や更新担当者が確認したい内容を紹介します。PHP 5.6系や7.4系など、古い環境からの更新で気をつけたいことも取り上げます。
まず押さえたいのは、ページが表示されることに加えて、問い合わせや更新作業が最後までできるかを確かめるという考え方です。
コードを読めなくても、普段の操作を試すことで確認できる部分はあります。その準備と、専門家に任せたい部分を順番に整理していきましょう。
PHP を更新すると、なぜ確認が必要なのか
PHP は、サーバー上で WordPress を動かしているプログラミング言語です。ページを作って表示したり、入力された情報を処理したりするために使われています。
WordPress 本体だけでなく、デザインや表示を担う「テーマ」、機能を追加する「プラグイン」も PHP を使います。PHP の変更によって、古い書き方のプログラムが動かなくなったり、以前と違う結果になったりする場合があります。
WordPress の公式案内でも、PHP 更新前のバックアップ、WordPress・テーマ・プラグインの更新、互換性の確認を挙げています。互換性とは、組み合わせて問題なく使えるかどうか、ということです。
たとえば、トップページが表示されても、お問い合わせフォームの送信時だけ問題が出る可能性はあります。そこで、「見る」「操作する」「結果を確かめる」を1組にしてテストすると、確認の抜けを減らせます。
以降の項目は、この考え方をサイトの機能ごとに当てはめた確認案です。すべてのサイトに同じ機能があるわけではないので、自分のサイトで使っているものを選んでください。
テストを始める前に準備すること
現在の PHP と、変更先のバージョンを確認する
WordPress の管理画面で「ツール」→「サイトヘルス」→「情報」を開き、「サーバー」内の PHP バージョンを確認します。表示される数字は、省略せず控えておきましょう。古い WordPress でこの画面がない場合は、サーバーの管理画面や保守担当者に確認します。
変更先は、サーバーで選べるものの中から、PHP の公式サポート期間と、使っている WordPress・テーマ・プラグインの対応状況を合わせて決めます。
2026年10月26日時点で、WordPress の公式推奨は PHP 8.3以上です。ただし、それだけで個別のテーマやプラグインまで動作が保証されるわけではありません。変更先の系列に用意された修正版の適用状況も、サーバー会社に確認してください。
バックアップと「戻す方法」を確認する
WordPress のバックアップには、画像やテーマなどの「ファイル」と、記事・設定などを保存する「データベース」の両方が必要です。
バックアップを取ったら、次のことも確認しておきます。
- 保存先と取得日時が分かるか。
- 復元する方法と、作業を頼める人が決まっているか。
- PHP を元のバージョンへ戻せるか。戻せる場合、どこで操作するのか。
バックアップの復元と、PHP の設定を戻す操作は別です。 サーバー会社の仕様によっては、以前の PHP を選べなくなっている場合もあるため、更新前に確認しておきたいところです。
可能であれば、検証用の場所へバックアップを復元し、実際にサイトを開けるかも担当者に確認してもらいましょう。
できれば、本番とは別の場所で試す
実際にお客さまが使っているサイトを「本番環境」、本番を複製して試す場所を「検証環境」や「ステージング環境」と呼びます。
検証環境で PHP を変更して確認し、問題を直してから本番へ進めると、営業中のサイトへの影響を抑えながら準備できます。複製を作っただけで本番と同じ条件になるとは限らないので、PHP の設定や外部サービスとの接続の違いは担当者と確認してください。
また、複製したサイトから本物のお客さまへメールが届いたり、注文が外部へ送られたりしないように、通知先・決済・外部連携を確認します。検証環境へのアクセスも制限し、個人情報が不用意に公開されない状態にします。
検証環境の作り方や通知を止める方法が分からない場合は、先にサーバー会社や保守担当者へ相談しましょう。
更新前と更新後で、同じ操作を試す
更新後に初めてフォームを試すと、問題が見つかっても「以前から届かなかったのか、今回の変更が原因なのか」が分かりません。
そこで、更新前にも一度、同じ操作で正常に動いているか確認しておきます。 確認するページ、入力内容、期待する結果をメモし、必要な画面を画像で残しておくと比較できます。
記録は、次の程度で十分です。
| 確認項目 | 操作と期待する結果 | 更新前 | 更新後 |
|---|---|---|---|
| 問い合わせ | テスト送信し、担当者と入力者の両方にメールが届く | 確認済み | 未確認 |
| 記事編集 | テスト用の下書きを保存し、開き直しても内容が残る | 確認済み | 未確認 |
| サイト内検索 | 記事名で検索し、該当する記事が表示される | 確認済み | 未確認 |
上の表は記入例です。自動返信がないフォームなど、元から用意されていない動きは確認対象から外します。「未確認」と「問題なし」は分けて記録しましょう。
1. 主要なページを、パソコンとスマートフォンで開く
最初は、訪問者がよく見るページを確認します。
- トップページ。
- サービス・料金・会社案内などの主要ページ。
- 記事の一覧と、個別の記事。
- お問い合わせや申し込みにつながるページ。
文字や画像が欠けていないか、メニューやボタンが動くか、エラーの文章が表示されていないかを見ます。サイト内検索や条件による絞り込みを使っている場合は、結果も表示させてみてください。
管理画面にログインしている状態だけでなく、ログアウトした状態でも確認します。パソコンとスマートフォンの両方で、主要な操作ができるところまで試しましょう。
表示を速くするため、以前作ったページを保存して再利用する「キャッシュ」という仕組みもあります。担当者にキャッシュの扱いを確認し、以前保存された画面を見ただけで確認を終えないようにします。
2. フォームは、メールの受信まで確認する
問い合わせフォームでは、次の順番で確認します。
- テストと分かる名前や件名、自分が受信できるメールアドレスを入力する。
- 確認画面がある場合は、入力内容が正しく表示されるかを見る。
- 送信し、完了画面や完了メッセージを確認する。
- サイト担当者に通知メールが届いたかを確認する。
- 自動返信がある場合は、入力したアドレスにも届いたかを確認する。
- 問い合わせ内容を管理画面に保存する機能がある場合は、その記録を確認する。
「送信しました」と表示されたことと、メールが届いたことは分けて確認します。 届かない場合は、迷惑メールのフォルダーも含めて調べ、送信時刻と宛先を控えておきましょう。
必須項目を空にした場合に入力案内が出るか、添付ファイルを受け付ける場合は添付も届くかを確認します。添付には、個人情報を含まないテスト用ファイルを使います。
フォームが複数ある場合は、採用応募、資料請求なども忘れずに。通知先が別の担当者なら、受信確認もそれぞれに依頼します。
3. 管理画面で、保存と画像の追加を試す
普段サイトを更新している人は、次の操作も確認してください。
- 普段使うアカウントで、ログインとログアウトができるか。
- 投稿や固定ページの編集画面を開けるか。
- テスト用の下書きに文字を入力し、保存できるか。
- 保存後に開き直しても、変更内容が残っているか。
- テスト用の画像を追加し、ページ内に挿入できるか。
- プレビューで文字や画像が表示されるか。
公開済みの記事をテストのために変更する必要はありません。検証環境か、テスト用の下書きを使いましょう。
独自の入力欄を使っているサイトでは、その欄の保存も確認します。管理者だけでなく、実際に担当者が使っている権限のアカウントで試すと、普段の更新作業に近い確認ができます。
4. 購入・予約・会員機能は、記録されるところまで試す
商品販売、予約受付、会員向けページがあるサイトでは、その機能が確認の中心になります。
| 機能 | 試す操作 | 最後に確認する結果 |
|---|---|---|
| 商品購入 | 商品選択、カート追加、住所・配送方法の入力、テスト決済 | 金額が正しく、注文と決済結果が記録され、通知が届く |
| 予約 | 日時選択、必要事項の入力、予約確定 | 予約一覧に反映され、枠数と通知が正しい |
| 会員機能 | テスト会員でログインし、会員向けページを開く | 対象の内容を見られ、ログアウト後は閲覧が制限される |
キャンセルやパスワードの再設定など、運営に欠かせない操作も対象にします。商品販売なら、普段使う決済方法や送料・割引の条件を選んで試してください。
決済テストは、決済会社やプラグインの公式手順に沿って、検証環境とテスト用の設定で行います。テスト注文でもメールや外部連携が動くことがあるため、通知、出荷、在庫連携の扱いも先に確認します。
本番へ切り替えた後に行う確認は、担当者と方法を決めてください。実際の請求・出荷が発生する操作や、営業中のサイト全体をテスト決済へ変更する操作を、自己判断で行わないようにしましょう。
5. 予約投稿やバックアップなどの自動処理を確認する
画面上の操作ができても、時間になったら実行される処理まで動いているとは限りません。
予約投稿、自動バックアップ、外部サービスへの情報送信など、使っている自動処理を挙げて、次の実行後に結果や履歴を確認するようにします。たとえば、バックアップなら「予約が登録されている」だけでなく、新しいバックアップが実際に作成されたかを見ます。
WordPress の予約処理に使われる WP-Cron は、通常、ページへのアクセスをきっかけに動きます。そのため、アクセスが少ない検証環境で予約投稿が遅れた場合、PHP 更新だけが原因とは限りません。サーバー側で別の実行方法を設定していることもあるので、担当者に確認しましょう。
自動処理ごとに動く間隔は違います。「翌日になったから完了」と一律に決めず、対象の処理が動くタイミングまで確認予定に含めておくとよいでしょう。
6. エラーの記録は、担当者にも確認してもらう
画面から分かることに加えて、サーバーや WordPress のエラーログも確認対象です。ログは、問題が起きた時刻や内容を残す記録です。
WordPress には、不具合を調べるために、エラーや警告を記録する「デバッグ」機能があります。ただし、公式資料は、こうした機能を本番サイトで使用することを推奨していません。設定ファイルの編集に慣れていない方は、検証環境での記録と確認を担当者へ依頼してください。
依頼するときは、「フォームを送信した時刻」など、テストの時間も伝えると調べやすくなります。
警告が出たからといって、すべて即座にサイトが止まるわけではありません。一方、画面上で問題が見えなくても、修正が必要な場合はあります。内容と影響を確認し、修正するもの、経過を見るものを担当者と整理します。
PHP 5.6系・7.4系から更新するときの注意点
PHP 5.6 系は 2018 年 12 月 31 日、7.4 系は 2022 年 11 月 28 日に公式サポートを終了しています。サーバー会社が独自に延長対応している場合も、PHP 公式の通常サポートとは分けて考え、対応範囲を確認してください。
古い PHP からの移行でも、確認する基本項目は同じです。ただ、テストで見つかった問題を直すために、テーマやプラグインの改修・交換が必要になる可能性を見込んでおくと、計画を立てやすくなります。
PHP 5.6系は、古いプログラムが残っていないか調べる
PHP 5.6系から現在のサポート対象へ進む場合は、複数世代の変更をまたぎます。PHP 7への移行でも、以前の機能の削除やエラー処理の変更がありました。
長く使っているオリジナルテーマ、更新が止まったプラグイン、独自に追加した処理があれば、担当者に伝えてください。使っている WordPress 自体が古い場合も、PHP を変更する前の調査が必要です。
検証環境で、現在の PHP で動かせる WordPress・テーマ・プラグインの更新を進め、それぞれの動作を確認します。その先の版が新しい PHP を必要とする場合は、組み合わせが成り立つ順番を担当者に決めてもらいます。
「すべて最新版にしてから PHP を変える」という順番を、そのまま古い環境へ当てはめることはできません。何をどの順番で更新したかを記録しながら、段階を分けて進めましょう。
PHP 7.4系でも、8系での動作は別に確認する
PHP 7.4系で正常に動いていても、8系で同じように動くとは限りません。PHP 8.0では、数値と文字列を比べる方法や、プログラムの処理に想定外の値を渡したときの扱いなどが変更されています。
用語や変更内容をすべて覚える必要はありません。テーマ・プラグインの提供元に移行先への対応状況を確認し、独自の計算、絞り込み、入力チェックなどがある場合は、その結果まで試すことが大切です。
移行資料を読む際は、8.0だけでなく、最終的に使う系列までの変更も確認します。これは、公開サイトを7.4、8.0、8.1と順番に切り替えて運用しなければならない、という意味ではありません。最終的に使う PHP とサイトの組み合わせを、検証環境で確かめることが目的です。
本番へ切り替えたら、重要な操作をもう一度
検証環境で問題がなければ、本番のバックアップと戻す方法を再確認し、担当者が対応できる時間帯に切り替えます。注文や予約を受け付けるサイトでは、受付を一時的に止める必要があるかも事前に決めておきます。
本番へ検証環境の内容を反映する場合は、その間に増えた注文・予約・問い合わせを上書きしないように、反映する範囲を担当者と確認してください。
切り替え後は、本番の PHP が予定したバージョンになっているかを確認し、主要ページ、問い合わせ、管理画面での保存などをもう一度試します。購入や予約は、事前に決めた方法で確認します。
問い合わせが届かない、注文を完了できない、管理画面に入れないといった問題が出た場合は、そのまま作業完了にせず、担当者へ連絡します。影響と原因に応じて、更新前の状態へ戻す「切り戻し」が必要か判断します。戻す場合は、事前に決めた手順に従います。
ここで注意したいのは、バックアップへ戻すと、取得後に増えた注文や投稿などが失われる可能性があることです。PHP の設定だけを戻せるのか、サイトの復元も必要なのかを切り分け、営業中のデータを確認してから対応してください。
古い PHP へ一時的に戻して復旧した場合も、その状態を最終形にはせず、問題を直して再更新する予定を決めておきます。
完了の目安は、事前に選んだ重要な操作について、本番で期待する結果を確認できていることです。自動処理など未確認の項目が残る場合は、誰がいつ確認するかを記録し、保留中の項目として引き継ぎます。
自分で確認できることと、相談したいこと
普段のページ閲覧、フォームの受信確認、下書きの保存、画像の追加などは、操作に慣れたサイト担当者が確認できる範囲です。事業者へ作業を依頼する場合も、「自分のサイトで大事な操作」を伝える役割があります。
一方、次の状態では、設定変更を進める前にサーバー会社や制作・保守担当者へ相談するとよいでしょう。
- PHP 5.6系・7.4系からの更新で、テーマやプラグインの対応状況が分からない。
- バックアップの復元方法や、PHP を戻せるかどうかが分からない。
- 更新が止まったテーマ・プラグインや、内容が分からない独自機能がある。
- 決済・予約・外部連携のテスト方法を決められない。
- 更新後に送信・保存・購入が失敗する、画面にエラーが出る。
相談前には、サイトの URL、サーバー会社、現在と変更予定の PHP、WordPress・テーマ・プラグインのバージョン、バックアップの状況を整理しておくと話が進めやすくなります。不具合がある場合は、起きた時刻、ページ、操作の順番、画面の画像も添えましょう。パスワードやお客さまの個人情報を、そのまま問い合わせに書く必要はありません。
PHP の更新では、サーバーの設定を変える作業と、サイト側の動作を確かめて直す作業が関わります。サーバー会社には設定や提供環境を、制作・保守担当者にはテーマやプラグイン、独自機能を相談すると、役割を整理しやすくなります。
オレインデザインへも、既存の WordPress サイトについて、調査や改修の相談をお寄せいただけます。「何をテストすればよいか決められない」「古いテーマを使っていて更新の進め方が分からない」といった場合は、現在の状況をお問い合わせフォームからお知らせください。サイトの構成や契約環境に応じて、必要な確認と対応範囲を整理します。
確認内容を最初からすべて理解する必要はありません。まずは、サイトを使う人と更新する人が普段何をしているかを書き出してみてください。その操作を、更新前と更新後で同じように試すための参考になれば嬉しいです。
