WordPressのPHP更新手順｜バックアップから動作確認・復旧まで

2026年10月22日確認。PHP2Shellへの対策として、WordPressを動かすPHPの更新を求められたとき、いきなり本番サイトの版を切り替えると表示崩れや決済・フォーム停止を招くことがあります。先に現在の版、バックアップ、互換性、戻し方を確認し、切り替え後に主要機能をテストします。まだ自サイトが対象か分からない場合は、PHP2Shellの影響確認手順から始めてください。脆弱性の全体像はWordPress運営者向け緊急対策で整理しています。

切替画面の場所やバックアップの扱いは契約先ごとに違います。エックスサーバー・ConoHa WING・ロリポップ！・さくらの具体的な手順も合わせて確認してください。

切り替え前に「復旧できる状態」を作る

対象環境と変更担当者を決める

WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」で実行中のPHP版を記録します。公式の修正版は8.2.35、8.3.36、8.4.27、8.5.12です。ただしホストがバックポートしている場合は表示版だけで判定できません。契約中のホストに、対象サイトと今回の二つのCVEの修正状況を確認してください。PHPの提供元がサーバー会社なら、管理画面で顧客が切り替えるのか、ホストが自動で切り替えるのかも決めます。

本番更新の担当を「実行者」「検品者」「障害時の判断者」に分けます。ECサイトなら注文が少ない時間帯を選び、更新中にフォーム投稿や決済が進む可能性を考えて、運用担当へ時刻を知らせます。更新作業を始める前に、管理画面・SFTP・ホストのコントロールパネルへアクセスできることを実際に確かめます。WordPress管理画面だけに頼ると、エラーで管理画面に入れなくなった際に復旧できません。

ファイルとデータベースを両方保全する

バックアップはWordPressのファイルだけでは足りません。テーマ、プラグイン、アップロード済み画像などのファイルと、投稿・設定・ユーザー情報を含むデータベースの両方を保存します。ホストのスナップショットを使う場合も、復元先と復元に必要な権限を確認します。WordPress公式のバックアップ資料を参考に、取得時刻と保管先を記録してください。個人情報を含むバックアップは公開フォルダに置かず、アクセスを限定します。

可能ならステージング環境で先に同じPHP版へ切り替え、トップページ、重要な記事、問い合わせ、会員機能、決済、管理画面を通します。ステージングが本番と同じプラグイン版・テーマ版・PHP拡張・キャッシュ構成でなければ、成功しても本番の保証にはなりません。差分を記録し、本番でも必ず再検品します。

「どのPHPが動いているか」をサイト単位で棚卸しする

最初に更新対象の一覧を作ります。会社のホームページだけを見て終わりにせず、採用サイト、問い合わせ専用サイト、キャンペーン用サブドメイン、会員サイト、検証用の公開URLも含めます。同じサーバー契約でも、ドメインやディレクトリごとにPHPの設定が違うことがあります。管理画面の表示だけで一括更新を決めず、ホストが実際に変更する範囲を確認します。

台帳には「URL、契約アカウント、サーバー名、実行中のPHP版、ホストによる修正の有無、管理担当、重要機能、更新予定時刻」を記載します。Webリクエストで使うPHPと、定期処理・コマンドラインで使うPHPが別の構成もあります。ホストへ問い合わせる際は、今回修正された二つのCVEについてWeb側とバッチ側の適用範囲を分けて質問します。単に「PHP 8.4です」という回答では、パッチレベルやバックポートの有無が分かりません。

WordPress公式の注意喚起が示すとおり、今回の問題はWordPress本体固有の脆弱性ではありません。テーマやプラグインをすべて最新版にしても、サーバーのPHPが未修正ならPHP2Shell対策の代わりにはなりません。一方で、PHPの更新時にはテーマやプラグインの互換性が現実の障害要因になるため、両方を別の作業として管理します。WordPress公式の緊急告知とPHP公式リリースを出発点にしてください。

変更前に関係者と停止条件を合意する

「障害が出たら戻す」だけでは遅れます。何分以内に検知し、何を停止条件にするかを先に決めます。例えば、問い合わせフォームのテスト送信が失敗した場合は公開中の広告流入を止めて調査する、決済完了後の注文記録と通知メールが一致しない場合は購入導線を一時停止する、管理画面に入れない場合はホスト側からログを確認する、という具合です。閾値はサイトの業務に合わせて決め、根拠のない「30分で必ず直る」といった保証は置きません。

担当表には、実行者だけでなく、フォーム受信を確認できる人、決済管理画面でテスト注文を確認できる人、ホストへ緊急連絡できる契約者も含めます。外部制作会社が管理している場合、契約者しかPHPの切替権限を持たないことがあります。夜間作業を決めてから権限不足に気づくと復旧が長引きます。認証情報をメールやチャットへそのまま貼らず、既存の権限管理手段で必要最小限のアクセスを渡してください。

運用中の注文・予約・会員登録があるサイトでは、テストのために誰がどのデータを作るかも決めます。実在顧客のメールアドレスやカードを検証に使わず、決済事業者が用意するテスト環境・方法と、サイト側のテストアカウントを使います。本番で少額決済を行う必要がある場合でも、返金処理、手数料、売上集計への影響を経理担当と事前に確認します。

バックアップは「取得」ではなく「戻せる」で判定する

バックアップの完了メールが届いたことと、復元できることは別です。保存したファイルにテーマ・プラグイン・アップロード画像・設定ファイルが含まれるか、データベースのエクスポートが同じ時刻帯で取れているかを確認します。WordPress公式は、一般的なWordPressサイトの完全な復元にはファイルとデータベースの両方が必要だと説明しています。片方だけでは、見た目だけ戻って投稿が欠ける、投稿は戻っても添付画像がない、といった状態になり得ます。

検証用環境で一度復元するのが最も確実です。時間が足りない場合でも、バックアップファイルのサイズが極端に小さくないか、一覧に対象のDBとファイルがあるか、ホストの復旧窓口・受付時間・復元にかかる目安を確認します。確認できない項目は「未検証」と明記し、作業を強行するかどうかを責任者が判断します。バックアップファイルを公開ディレクトリへ放置しないことも重要です。WordPress公式のバックアップの説明とDBの保存手順を参照してください。

ECや予約サイトの復旧では、バックアップ時刻から復元時刻までに入った注文・予約・問い合わせが失われる可能性があります。復元前にその期間のデータを別に保全し、決済事業者、メール通知、受注管理システムと照合する段取りを決めてください。PHPのバージョン変更だけで回復する障害なら、DB全体を過去へ戻す必要はありません。復元対象は原因に応じて最小限にします。

ステージング環境を本番のコピーとして検証する

ステージングでは、本番と同じテーマ・プラグイン・独自コード、同じPHP拡張、同じキャッシュ方式に近づけます。単に記事が数件見えるだけのテストサイトでは、会員ログインや決済、CSV取込、定期処理の互換性は確かめられません。差分表を作り、「本番と一致」「テスト用に変更」「再現できない」の三つに分けます。再現できない項目は本番切替直後の検品対象に加えます。

個人情報を含むDBを複製する場合は、ステージングの公開制限、アクセス権、検索エンジンへの露出、メール誤送信を必ず確認します。運用に不要な実データは匿名化し、外部サービスのAPIキーや本番の送信先はテスト用へ置き換えます。ステージングの更新中に本番の決済やメール配信が発火する構成は危険です。ホストや開発担当と環境の境界を確認してからコピーしてください。

テストでは、トップページだけでなく、投稿詳細、カテゴリー、検索、404ページ、画像の表示、記事編集・公開、メディアアップロードも確認します。業務で使う機能は実際の操作を再現します。例えば「見積フォームを入力して送信し、管理者通知を受信し、返信先が正しいことを確認する」までを一つの試験とします。「送信ボタンが押せた」だけでは合格にしません。

互換性の調査では、名前ではなく実際の経路を見る

古いテーマやプラグインがある場合、開発元の公開する対応PHP版と更新履歴を調べます。最終更新日だけで対応可否を決めず、現在使っているプラグインの版と、実際に動作させるPHP系列でテストしてください。WordPress公式のPHP更新ガイドも、バックアップ、WordPress・テーマ・プラグイン更新、互換性確認を事前手順に挙げています。ただし当該ガイドの古い推奨PHP番号を、今回の安全版の根拠に流用しないでください。脆弱性修正の番号はPHPの最新のセキュリティ告知で確認します。

独自プラグインや子テーマを使う場合、依存するライブラリ、カスタムフィールド、ショートコード、外部API、PHP拡張も調査対象です。日常の閲覧画面では動かないCSV出力や夜間バッチだけでエラーになることがあります。重要度順に「売上・顧客へ直接影響」「管理業務へ影響」「表示だけの軽微な影響」と区分し、優先して試験します。互換性に疑いが残るなら、修正版の同一PHP系列へ上げる選択肢や、ホストのパッチ適用済み版の有無を確認します。安全性だけ、互換性だけの片方で結論を出しません。

準備項目	確認する証拠	不足した場合の扱い
修正状況	対象サイトの実行版、ホストの修正告知または回答	版名だけで安全と断定せずホストへ照会
復旧手段	同時点のファイル・DB、復元先、権限	復元方法を確認するまで本番切替を保留
機能試験	フォーム、ログイン、決済等の試験者と手順	検品できる時間帯へ変更
障害対応	停止条件、連絡先、ロールバック判断者	担当不在なら作業を延期・代替者指定

PHPの更新と動作確認を順番に行う

ホストの正式な手順に従って、対象ドメインまたは対象サーバーのPHPを修正版へ切り替えます。「PHP 8.4へ変更」とだけ書かれた選択肢なら、実際に8.4.27以上が提供されるか、ホストへ確認します。別のメジャー・マイナー系へ移る場合は、古いテーマやプラグインの互換性に注意が必要です。修正版と互換性の両方を満たす版を選びます。

順番	作業	完了条件
1	変更直前のバックアップ取得	ファイルとDBの保存先を確認
2	ホストの手順でPHPを変更	対象サイトのWeb用PHPに反映
3	サイトヘルスとホスト告知を照合	版またはバックポートの根拠を保存
4	主要機能を実操作で点検	表示・送信・ログイン等に異常なし
5	一定時間のログと問い合わせを監視	新しいエラーの増加なし

「表示された」だけで合格にしない

トップページが開いても、フォームや予約機能が止まっている可能性があります。サイトの実態に合わせて、投稿閲覧、検索、問い合わせ送信、会員ログイン、購入・予約のテストを行います。実際の顧客へメールが届く機能は、テスト送信先を使い誤送信を避けてください。管理画面ではプラグインのエラー通知を確認し、ホストのエラーログに更新後から新しいPHPの致命的エラーが出ていないかを見ます。キャッシュが古いページを返すことがあるため、ログインした状態と未ログイン状態の両方で確認します。

確認結果は「機能名、操作、期待した結果、実際の結果、時刻、担当者」で残します。変更前後のスクリーンショットだけでは、送信や決済の動作を証明できません。検証に使った会員や注文のテストデータは、本番の集計に影響しないよう事前に扱いを決めます。

ホストの切替画面で確認する五つのこと

管理画面の名称と操作手順はホストごとに違います。WordPressの管理画面からPHPそのものを更新するとは限りません。操作前に、変更対象がドメイン単位かサーバー全体か、反映にどれくらい時間がかかるか、対象となるPHP系列とパッチレベル、旧版への切替方法、切替中のアクセスへの影響を確認します。複数サイトが同じ設定を共有しているなら、一つのサイトだけを試すつもりで全サイトが変わる事故を防げます。

画面に「PHP 8.4」としか表示されず、8.4.27以上であることが分からない場合は、サポートの正式な回答またはパッチ告知を確認します。逆に表示番号が古くても、ホストが当該修正をバックポートしている可能性があります。この場合も、どのCVEに対して、どの環境へ、いつ適用したかを回答してもらいます。版の見た目だけで「安全」「危険」を断定しないためです。

ホストへ送る質問は、対象ドメインを明示して具体的にします。例えば「当該ドメインのWeb実行環境はCVE-2026-109618とCVE-2026-109619に対応済みか。対応済みなら、稼働するPHPの版またはバックポートの根拠、適用日時、顧客側で必要な切替操作を教えてください」とします。ホストの回答で「WAFを入れた」とだけ返った場合、PHP自体の修正予定を追加で尋ねます。WAFは暫定緩和であって修正版への置換ではありません。

切替当日の実行手順を時系列で残す

切替直前に、担当者はサイトの正常状態を記録します。トップページ、主要な投稿、問い合わせ、ログイン、購入画面の応答と、直近のエラーログ件数を基準値にします。WordPress、テーマ、プラグインの更新を同時に実施すると原因が混ざるため、可能な限り変更を分離します。互換性のため先行更新が必要なら、各変更の時刻と検品結果を分けて残してください。

次に、変更直前のバックアップを取得し、実行者がホストの手順で対象環境を切り替えます。反映後は管理画面の表示だけではなく、実際のWordPressサイトで「ツール」→「サイトヘルス」→「情報」→「サーバー」を確認します。ホストが管理画面へのアクセスを提供しない場合は、サポートから当該サイトの実行PHPについて根拠を得ます。新しい版が確認できなければ「変更完了」とは報告せず、キャッシュや反映待ちを含めてホストへ照会します。

切替直後は、編集担当が投稿を更新する前に閲覧系の基本動作を確認します。次に送信・ログインなど状態を変える機能を、最後に決済や在庫を動かす機能を検証します。テストの順序を決めておくと、異常が出た時点で影響を止めやすくなります。複数サイトにまたがる場合は、重要度の低いサイトで工程を確かめ、次のサイトへ進む前に一件ずつ記録を閉じます。ただし、緊急のパッチ適用を不必要に長く遅らせないよう、全体の日程も決めます。

フォームは「入力から受信まで」を一連で試す

問い合わせフォームでは、必須項目のエラー表示、確認画面、送信完了画面、管理者への通知、送信者への自動返信をそれぞれ確認します。送信ボタンの反応だけでは、PHPのメール処理が成功したか分かりません。テストでは架空の氏名と安全な検証用アドレスを使い、件名に試験日時を入れて本番問い合わせと区別します。通常のフォームに加え、添付ファイルや複数ステップの入力があれば対象にします。

送信成功の画面が出てもメールが届かない場合、フォームプラグインのログ、SMTP連携、ホストのメール送信ログ、迷惑メール振分けを順に見ます。更新前から起きていたメール到達問題をPHP切替のせいにしないよう、変更前の基準も記録します。外部CRMへ送るフォームなら、CRM側にレコードが入ったかまで確認します。個人情報を含む送信内容を、障害報告のスクリーンショットにそのまま載せないよう注意してください。

会員・予約・決済は画面の先を確かめる

会員サイトでは、ログイン、ログアウト、パスワード再設定、権限ごとの表示、マイページの更新を試します。管理者で表示できても一般会員ではエラーになることがあります。キャッシュ対象から除外すべき会員ページが正しく扱われているかも確認します。PHP更新後にセッションまわりが変わる構成では、ログイン直後だけでなく、一定時間後の再訪も試すと問題を見つけやすくなります。

予約サイトでは、空き枠表示から予約確定、通知、管理画面反映、キャンセルまでを追います。ECサイトでは、商品詳細からカート、送料計算、決済事業者への遷移、戻り、注文記録、確認メール、在庫反映を一つのトランザクションとして扱います。決済側で成功したのにWordPress側へ注文が残らない障害は重大です。利用中の決済事業者が提供するテストモードやテストカードの方法に従い、実顧客データを使わないでください。

外部連携は、見える画面だけでは検知できません。Webhook、CSV連携、在庫同期、配送ラベル発行、会計ソフト連携など、業務上の後工程まで確認します。サービスごとに「どのイベントで何が起きるか」を表にすると抜けを減らせます。たとえば購入完了を起点に、注文登録、決済確定、在庫減算、顧客メール、管理者通知を並べ、それぞれ確認できる管理画面やログを指定します。

管理画面と公開画面は別のテストにする

サイト訪問者から見える画面では、スマートフォン・PCの表示、記事内画像、メニュー、検索、ページネーション、404応答などを確認します。キャッシュが古いHTMLを返すと、PHPのエラーが隠れる場合があります。ログイン中とシークレットウィンドウで確認し、必要に応じてページキャッシュやCDNキャッシュを手順に従って更新します。キャッシュの削除自体がアクセスを増やすこともあるため、実施時刻を残します。

管理画面では、投稿の下書き保存、公開・更新、画像アップロード、プラグイン設定画面、ユーザー管理など実際に使う作業を試します。サイトの表側が正常でも管理画面だけが致命的エラーになると、次の運用が止まります。テスト投稿を本番公開する必要はありません。下書きやステージングで再現できる操作を選び、検証用データは後で整理します。承認ワークフローがある場合、編集者と管理者の双方で動作を確認します。

ログは「エラーがあるか」ではなく「増えたか」を見る

PHP更新前から警告が出ているサイトでは、ログに一行でもあれば失敗とは言えません。変更時刻を境界に、致命的エラーの新規発生、同じエラーの増加、発生URL、プラグインやテーマのファイルパスを確認します。タイムゾーンが異なるログを照合する際は、基準時刻も記録してください。訪問者の入力値や認証情報がログへ書き込まれていないかも注意が必要です。

WordPress公式のデバッグ資料は、変更前にステージングまたは適切なバックアップを用意すること、本番で常時デバッグモードを有効化しないことを示しています。検証時にWP_DEBUGを使う場合も、エラーを訪問者に表示しない設定、ログファイルの保管場所とアクセス制限、終了後に無効へ戻す手順を決めます。調査用ログが公開ディレクトリから読める状態にならないよう、ホスト側の設定も含めて確認します。

検品結果は合否と保留を分けて残す

作業者だけが「問題なさそう」と判断せず、業務担当が確認する項目を分けます。技術担当はPHP版、HTTP応答、エラーログ、管理画面を確認し、運用担当は問い合わせ受信、注文、予約、会員通知など日々の業務を確認します。すべての項目が合格なら公開継続、重要項目が失敗なら機能停止またはロールバック検討、未検証なら期限と担当を設定する、という判定にします。

試験票は「対象機能／試験操作／期待結果／実際の結果／合否／証拠の場所／担当／時刻／次の対応」を一行にします。例えばフォームなら、「検証用のメールアドレスで送信し、完了画面と管理者通知を確認した」が合格条件です。メールが遅れているだけなのか、記録自体がないのかを分けます。決済なら、顧客側の完了表示に加えて決済事業者とWordPress双方の記録が一致するまで保留とします。

検品は切替直後だけで終えません。夜間に動く予約通知や定期バッチは次の実行時刻に確認します。営業日にしか入力が来ないB2Bフォームは、翌営業日の受信状況も監視します。更新直後の異常は必ずしもPHP起因ではありませんが、時刻とログを残して比較できる状態にしておくことで、原因の切り分けが早くなります。

不具合が出たときの戻し方と判断

更新後に白い画面、500エラー、フォーム停止などが出たら、まず変更時刻と影響範囲を確認します。ホストのエラーログにある該当時刻のエラーと、プラグイン・テーマの更新履歴を照らします。原因が明らかで、安全に修正できる場合は修正後に再テストします。ただし脆弱なPHPへ戻して放置することは対策完了ではありません。

一時ロールバックの条件を先に決める

緊急で旧版へ戻す判断が必要なら、公開停止やアクセス制限、WAFの暫定ルール、ホストの修正済みバックポートなどを組み合わせ、誰がいつまでに再更新するかを記録します。個人情報や決済を扱うサイトで旧版のまま公開を続ける判断は、サイト運営者とホストがリスクを確認して行います。戻す前にホストへ「修正版の別系統」「当該プラグインの修正版」「互換性の問題の回避策」がないか問い合わせるのも有効です。

WordPressの画面に入れない場合も、コントロールパネルやSFTPで直前の状態へ戻せる手順を準備しておきます。データベースを丸ごと復元すると、バックアップ取得後の注文や投稿が消える可能性があります。復元範囲と失われるデータを確認し、障害対応者が承認してから実行します。単にPHP版だけを戻せば直るのか、DBやファイルまで復元が必要なのかを切り分けます。

更新完了の報告に必要な情報

関係者へは、対象URL、更新前後のPHP版またはパッチ根拠、変更時刻、バックアップの保管先、点検した機能、未解決の問題、次の監視日時を共有します。「PHP更新済み」の一言だけでは、今回のCVEが当該サイトで解消したか分かりません。複数環境があるなら、本番・ステージング・別ドメインを分けて報告します。なお、更新前に侵害が起きていた可能性がある場合、版更新だけでは調査は終わりません。侵害を疑う場合の初動手順も参照してください。

障害が出たら、まず影響範囲と変更点を固定する

障害を発見した直後に複数のプラグインを無作為に停止すると、原因が分からなくなります。まず発見時刻、影響URL、発生する操作、HTTP応答、影響する利用者の範囲を記録します。「全ページが500エラー」「ログイン者だけ白画面」「決済後の通知だけ届かない」では、優先すべき対応が違います。同じ画面を別のブラウザーや未ログイン状態でも開き、キャッシュの表示だけで判断しないようにします。

次に、PHPを切り替えた時刻と、直前・直後に行ったテーマ、プラグイン、設定の変更を時系列に並べます。更新と同時に別の保守作業が走っていたなら、その変更も記録します。ホストのPHPエラーログ、Webサーバーのエラーログ、WordPressのリカバリーメールを確認し、エラーの場所と発生時刻を照合します。管理画面へ入れる場合は「サイトヘルス」の情報も保存します。ログには個人情報や秘密が含まれる可能性があるため、外部へ共有する際は必要箇所だけを伏せて渡します。

障害が起きたことと侵害されたことは同義ではありません。PHP更新後の互換性エラーを攻撃被害と決めつけず、一方で不審な管理者アカウント、見覚えのないファイル、予期しない外部通信などがある場合は、通常の互換性障害として処理しないでください。疑わしい兆候は侵害を疑う場合の初動手順へ進み、証拠を保全して担当者・ホストへ連絡します。

白画面・500エラーの原因を順に絞る

白画面や500エラーでは、まずホストが提供するPHPエラーログから、変更直後の致命的エラーを確認します。特定のテーマやプラグインのファイルが示されていれば、その製品の更新履歴、対応PHP版、開発元の案内を調べます。エラー文の一部だけを検索して無関係なコードを貼り付ける対応は避けます。特に公開サイトでの直接編集は、復旧を難しくすることがあります。

WordPressのリカバリーモードが使える場合は、通知を受けた正規の管理者が対象を確認します。管理画面に入れない場合、ホストのファイル管理やSFTPでプラグインの一時停止を検討できますが、停止により決済や会員認証が止まる可能性があります。実行前に影響機能を確認し、停止したプラグイン名・時刻・戻し方を記録します。テーマの切替も外観やテンプレートを大きく変えるため、やみくもに行いません。

単純なPHP互換性問題であれば、該当製品を修正版へ更新する、開発元へ修正を依頼する、同等機能の保守されている製品へ移る、といった選択肢があります。ただし、脆弱性対応のためのPHP変更を戻さずに解決できる方法を先に検討します。WordPress公式の一般的なエラーの案内を参照しつつ、ホスト固有のログの場所や復旧操作はホストの正式手順に従ってください。

フォーム停止・メール不達は段階で切り分ける

フォームの障害では、送信画面、WordPress内の保存、メール生成、SMTPまたはホストの送信、宛先での受信を分けます。入力画面でエラーになるのか、完了表示は出るが管理画面に記録がないのか、記録はあるのにメールだけ届かないのかで原因の候補が変わります。送信失敗を繰り返すと同じ問い合わせが複数回登録されることもあるため、試験の回数と識別子を残します。

通知だけが届かない場合、フォームプラグインとメール送信プラグインの両方がPHP更新に対応しているか確認します。ホストのメール制限や外部サービスの障害もあり得るので、変更時刻と各サービスのログを照合します。受信者側の迷惑メール振分け、差出人ドメインの認証、配信サービスの管理画面も確認します。問題のある間は訪問者へ問い合わせが届くと誤認させず、代替連絡手段を明示して業務担当へ受信状況を共有します。

決済・予約の障害は二重処理を防いで対応する

「購入ボタンを押したが完了画面へ進まない」という報告があっても、決済が失敗したとは限りません。最初に決済事業者の取引記録とWordPressの注文記録を照合します。取引が成立しているのに再試行を促すと、二重請求が起こるおそれがあります。顧客への案内文は事実が確認できるまで慎重にし、返金・再処理を行う担当を決めます。

予約の場合も、画面の失敗表示と実際の枠確保が一致しないことがあります。予約システムと通知メール、担当者のカレンダーを照合してから再入力します。更新前後に作成されたデータを消さないため、安易なDB復元は避けます。業務を止める判断が必要なら、該当導線を一時停止し、既存注文の処理と新規受付を分けて運用します。技術復旧だけでなく、顧客への連絡・記録の突合まで終えて障害完了とします。

一時ロールバックは「安全性」と「事業継続」の両面で決める

更新で重要機能が止まり、修正版上で短時間に直せない場合、旧版へ戻す案が出ます。しかし未修正版へ戻すと、今回の脆弱性のリスクが再び残ります。戻す前に、同じ系列の修正版、ホストが提供するバックポート済み環境、互換性問題を起こしたプラグインの修正、機能の一時停止といった選択肢を順に確認します。更新できない場合の暫定策も、修正版への移行までの時間を短くするためのものです。

どうしても旧版へ戻す場合は、公開範囲を制限するか、影響の大きい機能を停止するか、ホストの暫定緩和が利用できるかを検討します。誰がリスクを承認し、いつ再更新し、途中で何を監視するかを文書化してください。WAFの導入だけで修正済みと記載しません。共有サーバーでは設定変更の権限がない場合もあるため、実現できない対策を手順書に書かず、ホストの回答を踏まえて判断します。

ロールバックの操作はホストによって異なります。PHPの設定だけを戻せるのか、サーバースナップショットで全体を戻すのかを先に確認します。後者なら、変更以降の投稿、注文、予約、会員登録も巻き戻される可能性があります。復旧ポイントの時刻を確認し、失われるデータの一覧と再投入方法を作ってから実行します。変更後の受注データを保全せず、バックアップを上書きしてしまう事故を防ぐためです。

三つの失敗例から復旧計画を考える

失敗例1：トップページだけで合格にした。更新直後の見た目は正常でしたが、問い合わせフォームの送信後にPHPエラーが出て、営業日の問い合わせを受け取れませんでした。防止策は、送信から管理者受信までの試験を切替当日の完了条件にすることです。発見後はフォーム記録とメールログを照合し、失われた問い合わせがないか確認します。受信不能の間は代替連絡先を案内します。

失敗例2：DBを丸ごと戻して注文が消えた。PHPの設定変更だけで直る可能性があったのに、前夜のスナップショットを復元し、当日の注文がWordPress側から消えました。防止策は、復元範囲と時刻を承認者が確認し、注文・決済データを別途保全することです。復元後は決済事業者と配送・会計データを突き合わせ、欠落を補います。この例は架空のケースですが、復元の影響範囲を考えるうえで重要です。

失敗例3：管理画面の表示版だけを見た。設定画面でPHP系列を選んだため対策完了と報告しましたが、対象ドメインへの反映がまだで、実際には旧環境が稼働していました。防止策はサイトヘルスとホストの回答で対象ドメインの実行環境を照合することです。バックポートの場合は、対象CVEと適用日時を確認します。どの方法で修正されたかの証拠を、作業報告に残してください。

切替後の監視期間を決める

完了直後に一回だけ正常でも、定期処理や低頻度のページで障害が出ることがあります。作業当日、翌営業日、次の定期処理後に確認する項目を分けます。例えば当日はトップページ、管理画面、フォーム、会員、決済を実操作で確認します。翌営業日は問い合わせの受信件数とログ、次の予約通知やCSV出力の実行後はその結果を確認します。監視期間は業務の周期に合わせて決め、すべての業務機能を確認する前に「完全終了」としないことが大切です。

検知指標には、HTTP 500系応答の増加、PHP致命的エラー、問い合わせの受信件数、決済の失敗率、顧客からの報告件数を使えます。数値の閾値は通常時の水準がないと決められません。更新前の同じ曜日・時間帯と比べ、原因不明の変化があれば確認します。アクセスが減ったとしても、PHP更新だけが原因と決めつけず、検索流入や広告出稿、サイト障害の有無を分けて見ます。

よくある質問：WordPress本体も同時に更新すべきか

今回のPHP2Shellの修正対象はPHPであり、WordPress本体の更新だけで問題が解決するわけではありません。WordPress公式も、今回の問題のためのWordPress更新は予定していないと説明しています。ただし、運用全体ではWordPress本体、テーマ、プラグインの更新も重要です。PHPの切替前に互換性を確保するための更新が必要なら、各作業を別々に記録し、変更ごとに検品します。複数の更新を同時に行うと、障害が出た際に原因を切り分けにくくなります。

よくある質問：PHP 8.2.35ならずっと安全か

2026年10月22日時点で、8.2.35は今回の二つの脆弱性についてPHPが示す修正版の一つです。しかし、それが将来の脆弱性まで永久に防ぐという意味ではありません。また8.2系列にはサポート期限があるため、次の更新計画も必要です。ホストが独自に修正をバックポートする場合は公式の番号と表示が一致しないこともあります。今回の対策完了の確認と、継続的な保守計画を別に管理してください。

よくある質問：WAFを入れていれば更新は不要か

不要にはなりません。WordPress公式はホストがWAFルールを導入している可能性に触れていますが、それでもホストからの案内を確認し、必要に応じてPHPを更新するよう求めています。WAFはリクエストの一部を遮断する暫定的な緩和策で、すべての条件や経路を必ず防ぐ保証はありません。PHP修正版への移行日、適用範囲、暫定対策の解除条件を決めてください。

よくある質問：同じサーバーの全サイトを同時に更新すべきか

契約と設定の構成によります。PHPの切替がサーバー全体に効くホストなら、事前に同居サイトの機能を棚卸しし、全サイトを検品します。ドメイン単位で切り替えられるなら、重要度と互換性に応じて順序を決めます。ただし緊急の修正を先送りするために試験を際限なく長くするべきではありません。ホストが適用範囲と反映時間を示せないときは、サポートに確認してから操作します。

よくある質問：自社でサーバーを管理していない場合は何をするか

契約者または保守会社が、ホストの正式な告知と対象環境の実行PHPを確認します。ホストが自動で修正を適用済みなら、サイトごとの適用日時とパッチ根拠を保存します。顧客側で切替が必要なら、バックアップ、検証、実行、検品を担当者へ依頼します。「制作会社に任せた」だけで完了とせず、対象URLと検品結果が分かる報告を受け取ります。権限不足なら、契約管理者がホストへ直接問い合わせます。

更新作業の最終チェックリスト

段階	確認すること	残す記録
対象確認	全URLと実行PHP、ホストの修正状況	サイト別台帳、回答日
事前準備	ファイル・DBのバックアップ、権限、復元方法	取得時刻、保管場所、復旧担当
互換性	テーマ・プラグイン・独自コード・外部連携	ステージングの試験票と差分
切替	対象ドメインのPHP修正反映	前後の版、ホスト告知、実行時刻
直後の検品	表示、フォーム、会員、予約、決済、管理画面	操作結果、ログ、担当者
継続監視	新規エラー、受信、注文、定期処理	翌営業日・次回実行後の確認結果
障害時	停止条件、復元範囲、失われるデータ	判断者、リスク、再更新の期限

この表で「保留」になった項目は、空欄にしないで担当者と期限を書きます。未検証の業務機能がある場合、PHPのパッチが適用済みでも業務上の完了報告は保留にできます。逆に業務機能が動いていても、対象サイトにPHP修正が反映されていないならセキュリティ対応は完了していません。技術面と業務面の二つの合格を分けて判断してください。

ケース別：小規模なコーポレートサイト

架空例です。会社案内とブログ、問い合わせフォームだけを運用し、共有ホストの管理画面でドメインごとにPHPを切り替えられるサイトを想定します。担当者はまずサイトヘルスで現在のPHP版を記録し、ホストの告知で修正版の提供状況を確認します。制作会社が保守を担当しているなら、切替を依頼する際に「対象ドメイン、希望する修正版、バックアップ、テスト送信の実施、失敗時の復旧方法」を一つの依頼にまとめます。

この規模では、切替前に重要な記事や商品ページのURLを数件選び、問い合わせのテスト送信先を用意すれば、当日の検品が具体化します。切替後は公開画面の表示だけでなく、フォームの管理者通知と自動返信、管理画面の投稿保存を確認します。障害が出た場合、問い合わせを止めて代替の連絡先を案内し、ホストのログとフォームプラグインを調べます。完了条件は、PHP修正の反映、フォーム受信、代表的な画面と編集機能の合格です。

ケース別：WooCommerceなどのECサイト

架空例です。商品ページ、会員、決済、配送、在庫管理が連動するサイトでは、切替時間の選定と検品がより重要です。担当者は直近の注文件数と営業時間を把握し、テスト環境で同じテーマ・プラグインとPHP系列を検証します。決済プラグインだけでなく、税・送料、領収書、配送ラベル、会計連携、定期購入の処理まで一覧にします。決済事業者のテストモードが使えるかを確認し、実顧客に請求しない方法を選びます。

切替後に最初に見るのは、サイトが開くかだけではありません。テスト注文が決済管理画面に一件、WordPress側に一件として記録され、在庫・通知・配送の後工程が一致するかを確認します。確認が終わるまで新しい広告キャンペーンを開始しない、という業務上の制御も考えられます。決済だけ成功し注文記録が失敗した場合は、顧客へ安易に再注文を促さず、二重請求を防ぎます。完了条件は、注文フローと日次の後処理まで正常なことです。

ケース別：複数拠点・複数サイトを管理する企業

架空例です。企業サイト、採用サイト、ブランド別サイトが同一契約にある場合、一つの切替で影響が全体に及ぶことがあります。担当者はサイト別の台帳を作り、PHPの設定単位をホストに確認します。各サイトに個別の制作会社が関わるなら、どの環境がいつ変わるかを全社へ共有します。サイトごとに使用プラグインが違うため、一サイトで成功した結果を他サイトの互換性証明に流用しません。

この構成では、試験担当者をサイト別に決め、共通の試験票で合否を集約します。採用サイトなら応募フォームと管理者通知、ブランドサイトならキャンペーン申込と計測、企業サイトなら問い合わせと記事更新など、重要機能を変えます。ホストがサーバー全体にパッチを適用した場合も、全サイトの実行環境と主要機能を確認します。検証で不具合が出たサイトのみを止められるか、サーバー全体のロールバックが必要かを事前に把握しておくと判断が速くなります。

定期処理とコマンドラインを見落とさない

公開ページのPHPが切り替わっても、cronやCLIで使うPHP実行ファイルが別のままの構成があります。WordPress標準の疑似cronだけでなく、ホストの定期実行、WP-CLI、独自スクリプト、外部サービスから呼び出される処理を一覧にします。今回の脆弱性についてはPHP公式がWebリクエストを処理する環境をリスクとして挙げていますが、運用上はCLIとWebの版差が互換性や保守に影響します。対象の修正状況と、バッチ処理の互換性は分けて確認してください。

定期処理は更新直後に実行されないことがあります。翌朝に配送データを作る、毎週月曜に請求書を発行する、月末に会員課金を行うなど、次の実行日時が異なります。作業票に次回実行時刻と確認担当を記載し、ジョブの成功ログだけではなく成果物を確認します。例えばCSVが生成されても文字化けや列欠けがあるなら業務上は不合格です。通知が飛ぶ処理では検証用の送信先を確保し、本番利用者への誤送信を避けます。

外部ベンダーに作業を依頼するときの質問表

ホストや保守会社へ「PHPを最新にしてください」とだけ伝えると、作業範囲が曖昧になります。まず、対象URL、現在の実行PHP、今回の二つのCVEに対する修正状況、ホストが提供する修正版の番号またはバックポート根拠を尋ねます。次に、顧客側で操作が必要か、反映対象はドメイン単位かサーバー全体か、ダウンタイムやキャッシュへの影響があるか、サポート可能な時間帯を確認します。

保守会社には、ファイルとDBのバックアップ、ステージングの再現範囲、検品する機能、障害時の連絡と復旧、作業報告の証拠について合意します。見積もりが必要なら、作業費に「切替だけ」「互換性修正」「ステージング構築」「決済テスト」「監視」が含まれるかを分けて尋ねてください。未確認の互換性修正を定額の成果に含めたと誤認すると、障害時に責任範囲が曖昧になります。

依頼文の例は、「対象URLは〇〇。PHP2Shellの二つのCVEについて当該サイトの修正状況を確認したい。必要なPHP切替、バックアップ、主要機能の試験、障害時の復旧案、実行後の証跡と未対応項目を提示してください」です。〇〇には対象URLを入れます。契約者本人が承認すべき有料作業や停止時間は、依頼前に確認します。秘密情報や管理者パスワードを通常のメール本文へ貼らず、既定の安全な共有方法を使ってください。

修正済みでも、元のサイトに侵害がないとは限らない

PHP更新は新しい攻撃の機会を減らすための対応です。もし更新前に侵害が起きていたなら、PHPだけを修正しても、不正な管理者アカウントや改変されたファイルは自動で消えません。不審な管理者の追加、予期しない投稿、外部サイトへのリダイレクト、改変警告、見覚えのないファイルがある場合は、通常の更新作業と別に調査します。証拠となるログやファイルを先に保全し、侵害を疑う範囲と期間を整理します。

侵害の有無を判断できないまま、管理画面のパスワード変更だけで完了としないでください。WordPressのハッキング時の公式FAQを参考にし、契約ホストや専門家へ調査を相談します。更新後の検品で発見したエラーが単なる互換性障害か、攻撃に関わる兆候かを混同しないことも重要です。調査の進め方は関連記事で別に整理しています。

次の保守日程まで決めて作業を閉じる

今回の修正版へ切り替えたら、その時点の作業は終えられます。しかしPHPの修正は一度きりではありません。サポート期限を迎える系列を使っているなら、次の系列への移行計画を作ります。PHP公式は、PHP 8.2系列が2026年12月31日にサポート終了となり、その後は同系列へのセキュリティ修正が出ないと告知しています。2026年10月時点で8.2.35へ上げた場合も、継続利用の方針を別に決めてください。

定期点検では、PHP版、ホストのセキュリティ告知、WordPress本体・テーマ・プラグインの更新、バックアップの復元可能性、ログの異常を確認します。毎月必ず特定の作業時間で十分とは限りませんが、担当者と確認周期を決めることはできます。今回の作業票を次回も使える形で保存し、障害時の連絡先を更新します。結果として、緊急時に「誰が切り替えるのか」「どこにバックアップがあるのか」から調べ直さずに済みます。

本記事は2026年10月22日時点のPHP2Shell対策を中心に、WordPressのPHP更新を安全に進めるための実務手順をまとめたものです。実際の操作名、提供版、権限、復旧方法は契約ホストによって異なります。公開サイトで作業する前にホストの最新案内と対象サイトの設定を確認し、確認できない場合は無理に操作せずサポートへ問い合わせてください。

作業前日・当日・翌営業日の実行計画

前日まで。対象サイトの棚卸しとホストの修正状況確認を終えます。ステージングで重要な機能を試し、失敗するものは開発元へ問い合わせます。バックアップの保存先と復元手順、作業者・検品者・判断者の連絡先を確定します。顧客からの問い合わせが増える可能性のあるサイトでは、社内の対応窓口へ作業予定を共有します。未検証の機能が残るなら、切替後に誰がいつ試すかを決めます。

当日、切替前。最新のバックアップを取得し、ファイルとDBが同じ時点に近いことを確認します。現在のPHP版、主要画面、フォーム、決済、エラーログを基準として保存します。保守中の他の更新を止め、変更履歴を一本化します。対象ドメインと切替後のPHP版を実行者と検品者で読み合わせます。入力フォームやECを一時停止するなら、停止開始と再開の条件を業務担当へ伝えます。

当日、切替後。ホストの反映を待ち、サイトヘルスとホストの告知を照合します。まず公開画面と管理画面、次にフォーム・会員・予約、最後に決済・外部連携を試します。重大な不具合があれば新規流入や購入を止め、影響を固定してログを確認します。修正版の別選択肢や製品側の修正で直せるかを検討し、それでも復旧できない場合にロールバックを判断します。各項目の結果は「合格・失敗・保留」に分けます。

翌営業日以降。営業時間の問い合わせ、注文、予約、メールの実績を確認します。夜間・週次処理が残っている場合は次の実行結果を追います。ホストの公式案内に追加情報が出ていないかを確認し、対象CVEへの対応状況を記録し直します。未解決項目には担当と期限を付け、運用担当へ引き継ぎます。全工程が終わってから、保守台帳へ次回のPHP更新予定を登録します。

作業報告のひな型

技術担当から責任者へ渡す報告には、最低限次の内容を含めます。「対象URLと契約ホスト」「変更前後のPHP版またはバックポートの根拠」「対象CVEに対するホストの回答」「変更日時」「ファイル・DBバックアップの保存先と復元担当」「ステージングとの差分」「公開画面・管理画面・主要機能の検品結果」「切替後のログ状況」「未検証の機能と次の確認日」「障害時の復旧判断」を一件ずつ記載します。サイトが複数あるなら、サイトごとに報告を分けます。

報告では「問題ありません」だけでなく、何を試し、何を試していないかを明記します。たとえば「問い合わせフォームはテスト送信と管理者受信を確認。決済は事業者テストモードで一件実施。週次請求処理は次回月曜に確認予定」という書き方なら、受け取る側が残るリスクを判断できます。ログやスクリーンショットを添付する場合、顧客情報、アクセストークン、サーバーの秘密を伏せます。報告の目的は作業者を評価することではなく、次に何が必要かを共有することです。

「更新できない」場合の期限付き判断

現在のテーマやプラグインが修正版PHPで動かず、すぐに切り替えられない場合は、単に保留とせず、代替案と期限を決めます。ホストにパッチをバックポートした版があるか、同一系列の修正版へ変更できるか、製品の修正版があるか、問題の機能だけを一時停止できるかを確認します。公衆向けの提供を続けるリスクが高い場合は、サイトや影響機能の公開停止も含めて判断します。PHP公式は「更新だけが完全な解決策」と明示しており、暫定緩和だけで安全だとは言えません。

期限は「いつか対応する」ではなく、ホストの回答期限、互換性修正の見込み、次の再試験日、公開継続を再判断する日を決めます。その間のログ監視やアクセス制限を誰が担当するかも記録します。更新できない理由が費用や社内承認なら、停止による損失と未修正で公開するリスクを両方示し、責任者の判断を仰ぎます。技術担当が独断で旧版運用を続けたり、WAFの設置だけで対応完了としたりしないための手順です。

検索流入や顧客導線への影響も点検する

PHP更新後に表示は正常でも、canonical、サイトマップ、記事の本文、構造化データが出力されているかを主要ページで確認します。テーマやSEOプラグインの互換性エラーにより、検索向けの出力だけが欠けることがあります。問い合わせ導線、資料請求ボタン、電話リンク、関連記事の内部リンクもクリックして確認します。作業直後の検索順位の上下だけで更新の効果や失敗を判断しないでください。まずHTTP応答、index可否、重要ページの内容、Search Consoleのクロールエラーを確かめます。

キャンペーン中のサイトでは、広告やメールマガジンから訪れるページを優先して試します。入口のページが正常でも、その次の申込画面が動かなければ機会損失になります。計測タグやコンバージョンイベントも、許可されたテスト環境・方法で確認します。SEOや広告の数字は更新以外の要因でも変動するため、技術的な障害の有無と集客データの変化を分けて報告します。

根拠（2026年10月22日確認）：PHP公式セキュリティ告知、WordPress公式注意喚起、WordPress公式PHP更新ガイド、WordPress公式バックアップ資料、WordPress公式デバッグ資料

AIスキルで、未来の自分をアップデート！

今なら完全無料でAIを学べる！

WithAIには、目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースがあります。動画や実践を通して、スマホ・PCから自分のペースで学べます。PHPの更新やWordPressの保守を代行するサービスではありません。今回の更新作業は契約ホストと保守担当へ確認したうえで、AIスキルも身につけたい方は、WithAIの無料学習案内をご覧ください。