PHP更新後にHTTP 500・白画面になったら？修正版を維持して復旧する手順

2026年10月23日

2026年10月23日確認。PHPの重大な脆弱性を受けて修正版へ切り替えた直後、WordPressが「HTTP 500」「このサイトで重大なエラーが発生しました」「真っ白な画面」になったときは、旧PHPへ無条件に戻す前に、障害の発生箇所と修正適用状態を分けて確認してください。切替直後のエラーは、PHP本体の脆弱性が直っていないことの証拠でも、必ずプラグインだけが原因という証拠でもありません。サーバー設定、拡張モジュール、WordPress本体、プラグイン、テーマ、独自コードのいずれでも起こり得ます。

この記事は、2026年10月21日に公表されたPHP公式の緊急修正案内とWordPress公式の注意喚起を踏まえ、修正版への切替後に表示障害が起きたサイトを安全に復旧することに絞ります。今回の欠陥と影響範囲の全体像はPHP2ShellとWordPressの対応策をご覧ください。ホストの対応状況は変わるため、作業当日に公式告知と管理画面を必ず見直してください。

最初の目標は「どの層のエラーかを特定し、サイトの主要機能を再開すること」です。次の目標は「修正済みPHPのまま安定運用できること」です。表示が戻っただけで終わらず、更新版・ログ・管理画面・フォーム・決済などの確認結果を記録しましょう。

PHP切替直後のHTTP 500は何を意味する？最初に切り分ける

HTTP 500は、サーバーが処理中の内部エラーを返したという大きな分類です。ブラウザーに「500」と表示されるだけでは、PHPの互換性、Webサーバー設定、権限、タイムアウト、メモリ、データベース接続のどれが原因か分かりません。WordPressの「重大なエラー」画面も、致命的なPHPエラーをWordPress側が捕まえた結果であり、原因ファイルを画面だけで特定できるとは限りません。白画面も同様です。まず切替時刻・影響URL・HTTP応答・サーバーログを一つの記録にまとめます。

切替作業の直前に動いていたページが直後に壊れたなら、PHP版変更は有力な手掛かりです。ただし、同時刻にプラグインやテーマが自動更新されていた、サーバーが再起動した、キャッシュ設定が変わった可能性もあります。因果関係を早合点すると、実際はデータベース障害なのにプラグインをすべて停止するなど、余計な停止を招きます。まず一つの原因仮説に固定せず、変更履歴とログで確かめます。

5分で作る障害メモ

サイト運営者は「誰が、いつ、どの契約で、何のPHP版から何へ変更したか」を書きます。表示障害が全ページか一部だけか、管理画面にも出るか、ログイン済みと未ログインで違うかも記録します。たとえばトップは表示されるが問い合わせ送信だけ失敗するなら、全体の起動失敗よりフォームプラグインやメール処理を優先します。トップも管理画面も500なら、PHP起動・拡張・初期化時のエラーが候補です。

確認にはブラウザーだけでなく、ホストのアクセスログとエラーログを使います。ログ閲覧権限のない担当者は、ホストへ「対象URL、発生時刻とタイムゾーン、切替前後のPHP系統、HTTP 500を確認した時刻」を送れば調査が早くなります。パスワードやログ全文をメールに貼らず、機密情報を除いた抜粋を安全な窓口で共有してください。フォーム入力や顧客情報がログに含まれる場合があります。

先に安全を確保する判断

今回のPHP公式発表は、CVE-2026-109618とCVE-2026-109619について、修正版への更新だけが完全な対策だと説明しています。PHP 8.5.12、8.4.27、8.3.36、8.2.35が公式の修正版です。OSやホストが修正をバックポートする場合は、表示番号だけでなく、当該CVEが修正済みか提供元に照会します。旧版に戻すと障害が消えても、脆弱性への対応が後退し得るため、本番を安易に戻して放置しないでください。

売上や申込みに直結する機能が停止し、短時間で復旧できない場合、運用責任者・保守担当・ホストと相談し、公開範囲の一時制限、メンテナンス案内、影響機能の停止、修正済みの別系統への切替などを検討します。これは可用性と安全性の両立を図る判断で、単独担当者が「旧版なら表示される」と判断して恒久的に戻す場面ではありません。脆弱な版での公開を続けるより、一時的に公開を絞るほうが安全な場合があります。

最初の観測	優先する確認	次の担当
全URLと管理画面が500	PHP・Webサーバー・拡張のエラーログ	ホスト／インフラ担当
特定ページだけ500	該当機能のプラグイン・テーマ・独自コード	WordPress保守担当
フォーム送信時だけ失敗	送信処理、外部API、PHP拡張、ログ	機能担当とホスト
画面は出るが管理画面だけ停止	管理画面限定のプラグインと権限	WordPress保守担当
断続的な500	PHPワーカー・メモリ・時間帯・負荷	ホスト／インフラ担当

ログとサイトヘルスで原因の層を確定する

障害の修正はログから始めます。WordPressの画面だけで「PHP 8に非対応」と決めるのは危険です。PHP切替後の500であっても、ログに出るメッセージが拡張モジュールの読み込み失敗、プラグインの関数未定義、テーマの構文エラー、データベース接続失敗では、直す場所が異なります。サーバーのエラーログ、PHPログ、WordPressのデバッグログを時刻順に見て、最初の致命的エラーを探してください。後続の警告だけを修正しても停止は消えません。

ログが読める環境なら、公開画面にエラーを出さず記録する

WordPress公式のデバッグ手順では、検証用環境でWP_DEBUGとWP_DEBUG_LOGを有効にし、WP_DEBUG_DISPLAYを無効にする方法を示しています。ただし本番サイトでの常用は推奨されません。原因調査のために一時的に使うなら、作業時間を限定し、ログの保存先が公開領域に露出しないことを確認し、調査後は設定を戻します。wp-content/debug.logにはパスや入力情報が記録され得ます。バックアップとアクセス制限を先に確認してください。

すでにサーバーが独自のエラーログを提供していれば、まずそれを見ます。WordPressが起動する前の致命的エラーやPHP拡張のロード失敗は、WordPressのログへ届かない場合があるためです。ホストの管理画面で「PHPエラーログ」「Webサーバーのエラーログ」の名称を探し、切替直後の時刻で絞ります。アクセスログで500のURLと時刻を確認し、その前後をエラーログと照合します。ログがないことを「エラーがない」と解釈せず、記録先や保存期間も確認します。

エラーメッセージは「種類」と「最初の発生元」で読む

Uncaught ErrorやFatal errorは処理停止を示し、ファイルパスと行番号が発生源の手掛かりです。Call to undefined functionなら、プラグインが呼ぶ関数の提供元、必要なPHP拡張、読み込み順序などを確かめます。Class not foundなら、オートロードや依存プラグイン、更新途中のファイル欠落を調べます。Parse errorなら構文が対象PHPで解釈できない可能性があります。Allowed memory size exhaustedはメモリ不足の兆候ですが、上限を無制限に上げる前に、無限ループや異常なプラグイン処理を切り分けます。

一方、DeprecatedやWarningは直すべき互換性の兆候でも、必ずしも500の直接原因ではありません。最初の致命的エラーより後に大量の警告が出ることもあります。画面に警告が見えるからといって、致命的エラーと混同しないでください。発生時刻、対象URL、スタックトレース、直前の変更、再現条件を一緒に見ます。ログの断片を検索する場合は顧客情報や秘密鍵を公開の検索サービスへ貼らないでください。

サイトヘルスが開くなら、実行中のPHP版を控える

WordPressの公式案内は、管理画面の「ツール → サイトヘルス → 情報 → サーバー」で実行中のPHP版を確認できるとしています。ホストの管理画面の選択値とサイトヘルスの表示が異なる場合は、設定の反映待ち、ドメインごとの設定差、キャッシュ、別サーバー、PHPワーカーの再起動などをホストへ確認します。サイトヘルスが開かなければ、版の確認を無理に続けずホストの設定・ログに進みます。確認用のphpinfo()ファイルを公開ディレクトリに置きっぱなしにしないでください。

複数サイトを同じ契約に置く場合は、「別サイトは動く」という事実も手掛かりになります。同じPHP版と同じサーバーで別サイトだけ壊れるなら、サイト固有のコードやプラグインが疑わしくなります。ただしサイトごとにPHP設定や拡張が異なることもあり、同居サイトの成功だけでサーバー全体の安全を保証できません。比較条件を記録してください。

ログの情報をチームで共有するときは、原因の「確定」と「推測」を分けます。たとえば「15時02分に決済プラグインのファイルでFatal error」は観測事実、「PHP 8.4との互換性が原因」はその段階では仮説です。エラーが出た場所は、呼び出し元や依存するライブラリの影響を受けます。仮説のまま顧客向けに原因を断定すると、後で訂正が必要になります。一次対応の報告は「影響」「分かっている事実」「未確認」「次の確認時刻」の四つに分けると、不要な憶測を減らせます。

サーバーの時刻と担当者の端末の時刻が異なることにも注意してください。ログがUTC、管理画面が日本時間という組み合わせでは、同じ障害を九時間ずれて追ってしまいます。チケットには必ずタイムゾーンを添え、PHP切替操作、最初の500、ホストの再起動、修正適用の各時刻を並べます。複数担当者が同時に本番を触っているなら、その間は変更を止め、作業の所有者を一人決めてください。

プラグイン・テーマ・PHP拡張を安全に切り分ける

ログが特定プラグインのファイルを示す場合、最初にそのプラグインの公式更新情報と利用中の版を確認します。「プラグインを全停止すれば復旧する」は事実として役立ちますが、決済・会員管理・セキュリティ設定をまとめて止めると別の障害や露出を作り得ます。原因候補を一つずつ、影響を見ながら切り分けることが原則です。作業前にファイルとDBの復元可能なバックアップ、変更時刻、担当者、元の有効状態を残してください。

管理画面が開ける場合

管理画面で対象プラグインの更新を確認し、公開前に同じ条件のステージングで試します。エラーが特定操作だけで出るなら、対象機能の設定や依存サービスも確かめます。停止が許されるプラグインなら、一時無効化して同じURLと操作を再現し、500が消えるかを見ます。消えた場合も即削除せず、提供元の互換性情報・修正版・代替策を確認します。消えなければ元の状態へ戻し、次の候補へ進みます。各操作を一回ずつ行い、同時に複数の設定を変えないことが原因特定を早めます。

サイトのキャッシュやCDNが古いエラーページを返していることもあります。プラグインを止めたのに表示が変わらないときは、レスポンスヘッダーとキャッシュの有無を確認します。ただしキャッシュを一括削除する前に、トラフィック増や重要ページへの影響を考えます。検証URLは同じものを使い、シークレットウィンドウだけに頼らず、応答コードとログ時刻も照合します。

管理画面に入れない場合とリカバリーモード

WordPressには致命的エラー時のリカバリーモードがあり、管理者メールに案内が届く場合があります。公式の一般的なエラーの説明とホストの手順を参照し、正規の通知か送信元を確認して利用します。通知が届かない場合も、迷惑メールや登録アドレスを確認し、ログとホストのファイル管理・SFTPを使う道を探します。メール内のリンクやサイト情報を第三者へ転送しないでください。

SFTPやファイルマネージャーで特定プラグインを一時的に無効化する方法はありますが、本番のファイルを触る前に元の名前と権限を記録します。ディレクトリ名を変えるだけで関連ファイルや設定が自動削除されるとは限らず、複数のプラグインが依存している場合は別のエラーが出ます。元へ戻す方法と実施時刻を決め、作業者を一人に絞ります。やみくもに全プラグインフォルダーを変更せず、ログの示す候補から始めます。

テーマと独自コードを疑う条件

エラーのファイルパスが有効テーマや子テーマを指すなら、PHP版変更で顕在化した独自コードを確認します。特に長年修正していないfunctions.phpやテーマ内の古いライブラリ、独自ショートコードは候補です。ただしテーマを標準テーマへ切り替えるとレイアウトや機能が大きく変わるため、原則としてステージングで先に再現します。本番で切替が必要なら営業時間外など影響の少ない時間帯を選び、元へ戻す手順と表示検査項目を準備します。

テーマのファイルを直接編集する際は、画面上のエディターで試行錯誤せず、版管理された修正を用意します。エラーを「非表示」にするだけでは解決しません。実行できない構文、関数の引数、型の扱い、依存ライブラリを修正し、同じPHP版でテストします。独自コードの担当者が不明なら、提供元または保守会社へ切替前後の版・ログを渡し、修正可能か見積もります。

PHP拡張・設定由来のエラーはホストと確認

プラグイン名がログに出ても、そのプラグインが必要とするPHP拡張が新しい実行環境に入っていないだけの場合があります。画像処理、文字コード、データベース接続など、サイトの機能に必要な拡張の有無をホストの管理画面またはサポートへ確認します。独自VPSでは旧PHPのモジュールだけが残り、新しいPHP-FPMへ切り替わっていない可能性もあります。サーバー設定を利用者が変えられない共用ホストでは、憶測で設定ファイルを書き換えるより、エラーと必要機能を示して相談します。

本番のエラーログにpermission deniedやファイル不存在があれば、PHP版変更と同時に実行ユーザーやソケットパスが変わっていないかを確認します。これらはテーマの互換性だけでは説明できません。データベース接続エラーであれば、接続先、ネットワーク、認証、拡張を分けて見る必要があります。ログの先頭にある発生元と、実際に直す担当が同じとは限らないことを意識してください。

修正版PHPのまま復旧する実務フロー

安全な復旧は「停止を隠すこと」ではなく、「修正済みPHP上で主要機能が安定すること」です。作業責任者は、バックアップの復元可能性、ステージングの準備、切替時刻、影響機能、承認者をそろえます。障害が発生してから初めてバックアップを取る場合でも、今の壊れた状態を別名で保存します。後から原因調査に必要になることがあるためです。ただし機密データの保管先とアクセス権を管理してください。

0〜15分：利用者への影響と安全状態を固定する

運用担当は監視画面、ブラウザー、アクセスログで実際の影響範囲を確認します。フォームだけ停止ならフォームの受付を一時停止して代替連絡先を案内する、全体停止ならメンテナンス表示を用意するなど、利用者への影響を先に軽減します。同時にPHP版とホストの修正適用状況を記録します。メンテナンス表示がWordPress自体に依存すると、PHP障害で出せない場合があるので、ホストの機能やWebサーバー側の方法を確認します。

15〜45分：ログで原因候補を一つに絞る

保守担当はPHP・Webサーバー・WordPressのログを切替時刻から追い、最初の致命的エラーを抽出します。エラーが同じURLと同じ操作で再現するかを安全なテスト環境で調べます。ホストの管理画面から得られるログが不足するなら、サポートへ調査依頼を出します。「サイトが落ちた」だけでなく、障害発生時刻、契約名、対象ドメイン、変更したPHP系統、応答コード、エラー抜粋を渡します。契約情報やログの個人情報は公開コメントに書きません。

45〜90分：最小変更で修正または限定的に停止する

対象プラグインの互換更新、PHP拡張の追加、設定の修正、独自コードの修正など、ログに根拠がある変更を選びます。更新版が提供されていない重要プラグインなら、一時停止の可否だけでなく、代替サービスや旧機能の停止による事業影響を判断します。複数候補がある場合は一つ変えて再現確認、戻して次を試す順序にします。WordPress本体やプラグインの「全部更新」を障害中に同時実施すると、変更点が増えて原因を追いにくくなります。

90分以降：主要導線を検証してから復旧宣言する

トップページ、検索流入が多いページ、管理画面、ログイン、問い合わせ、会員登録、予約・決済、通知メール、外部連携をサイトの実態に合わせて確認します。閲覧できたことと送信・購入が完了したことは別です。テストデータを使い、実際の顧客へ重複通知や決済を発生させないようにします。エラーログの新規発生も再確認し、数分間の成功だけで終えず、通常トラフィックでの監視を継続します。

段階	担当と入力	完了条件	失敗時の戻し方
事実固定	運用担当／時刻・URL・版・ログ	影響範囲と担当を記録	公開範囲を制限しホストへ連絡
原因特定	保守担当／最初の致命的エラー	再現条件と原因候補が一致	設定を元へ戻し別候補を調査
最小修正	開発担当／修正版・互換情報	修正済みPHPで対象操作が成功	変更単位を戻し代替手段へ
公開確認	運用責任者／主要導線の結果	HTTP応答・機能・ログが正常	メンテナンスへ戻し再調査

この時間配分は目安です。大規模ECや会員サイトでは承認と検証に長く掛かります。復旧を急ぐために権限のない担当者が本番サーバーを直接編集するより、変更の責任者を決めて安全な手順を守るほうが結果的に早いことがあります。

復旧時のチェック項目は、サイトの収益や利用者の行動で優先順位を付けます。情報サイトなら記事本文、検索、関連記事、問い合わせ、サイトマップを確認します。ECなら商品閲覧だけでなく、カート、送料計算、決済完了、メール通知、注文管理画面まで一連の流れを試します。予約サイトなら空き状況の表示、仮押さえ、確認メール、キャンセルを試します。外部API連携は画面上の成功表示だけでなく、相手側へ正しいデータが届いたか確認します。利用者の実データを使わないテスト手順を事前に決めてください。

障害直後はキャッシュが古いページを返し、担当者だけ正常に見えることがあります。公開ページのHTTP応答、別のネットワークからの閲覧、ログインしていない状態の表示を確認します。一方で、短時間に何度も大量の確認リクエストを投げると、復旧中のサーバーへ負荷を掛けます。検証対象を代表的なURLへ絞り、ホストの監視を見ながら実施してください。記録は「URL・操作・期待結果・実結果・確認者・確認時刻」で残すと、後から再検証しやすくなります。

旧PHPへ戻す前に考えることと再発防止

切替直後に白画面が出ると、管理画面の選択肢を一つ前に戻したくなります。しかし、今回の緊急更新はPHP公式が認証前のリモートコード実行につながり得るとする二つの欠陥に対するものです。「古いPHPへ戻せば表示が直る」は互換性問題を示す材料であって、安全を保証する結論ではありません。特に公開Webサーバーを旧版のまま長時間運用する判断は、事業上の障害と侵害リスクを同時に評価する必要があります。

緊急ロールバックが必要なら条件を明文化する

たとえば決済が完全停止し、修正済みの別系統も使えず、ホストが緊急対応中の場合に、運用責任者が短時間のロールバックを検討することはあります。ただしその場合も、公開遮断やアクセス制限、重要機能の停止、ホストの暫定防御、監視強化、再更新期限を組み合わせ、残るリスクを記録します。PHP公式は暫定策を完全な解決とは認めていません。ホストのWAF適用だけで「修正完了」と表示しないでください。

「一時的」の定義が曖昧だと旧版に戻したまま数週間が過ぎます。承認者、判断理由、戻した時刻、残した公開範囲、次に試す修正版、期限、再検証担当を障害チケットに書きます。期限に間に合わない場合は再承認し、公開継続の可否を判断します。運用を続けるか一時停止するかは、サイトのデータの重要度、攻撃面、代替手段によって変わります。

復旧後に残す検証証跡

復旧後は「どのエラーを、何を変えて解消したか」を書きます。修正済みPHPの版とホストの告知、WordPress・プラグイン・テーマの版、確認したURLと操作、テスト結果、ログの再発有無を記録します。旧版に戻していないこと、戻したなら再更新の計画を明確にします。別環境があるなら同じ設定を再現し、将来の更新リハーサルに使います。単に「画面表示OK」とだけ書いた記録では、次回の更新時に判断を繰り返すことになります。

また、今回の500が偶然の互換エラーだったとしても、同じサイトで古いプラグインや独自コードが多ければ、次のPHP更新でも停止しやすくなります。定期的な棚卸し、提供元の更新履歴確認、テスト環境でのPHP系統更新、監視、復元訓練を運用計画へ入れてください。具体的な事前チェックはPHP更新前後のプラグイン・テーマ互換性確認で整理します。

よくある質問：白画面、リカバリーモード、PHP版の判断

Q. 白画面なら、今回のPHP脆弱性に攻撃された証拠ですか？

いいえ。白画面はPHPの致命的エラー、出力設定、テーマ・プラグインの不具合などでも起こります。今回の脆弱性による侵害の有無は、表示症状だけでは判定できません。ログの保存と専門家による調査が必要です。不審な管理者アカウント、未知のファイル、改ざん、外部通信などがある場合は、通常の互換性エラーとして片づけず、ホストとインシデント対応担当へ連絡してください。

Q. WordPress本体を更新すれば500もPHPの欠陥も直りますか？

WordPress本体の更新が互換性改善に役立つ場合はありますが、今回のPHP本体の欠陥は直せません。WordPress公式はWordPress固有の欠陥ではなく、WordPressの更新は不要・予定もないと説明しています。500の原因もログで特定する必要があります。WordPress更新、PHP更新、プラグイン修正は別の作業として管理してください。

Q. プラグインを全部停止しても500なら何を見ますか？

テーマ、独自コード、PHP拡張、サーバーの設定、権限、データベース、PHPワーカーの起動状況を確認します。すべてを無効化する前にログで原因を絞るほうが安全です。全停止を既に実施したなら、どのプラグインが有効だったかを控え、決済・認証・防御機能が止まっていないか確認します。停止しても変化がなければ、元の状態へ戻してホストのエラーログを調べます。

Q. `WP_DEBUG`を有効にしたら訪問者にもエラーが見えますか？

設定次第です。WP_DEBUG_DISPLAYが有効だと表示され得ます。WordPress公式は本番での常用を推奨していません。必要な短時間だけ適切にログへ記録し、公開画面には出さず、調査後は設定とログを整理します。ログにはファイルパスや個人情報が含まれる場合があるため、公開URLから読めない状態を確認してください。

Q. どの時点で「復旧済み」と言えますか？

修正済みPHPでサイトの主要導線が正常に動き、HTTP応答が期待どおりで、新規の致命的エラーが増えていないことを確認した時点です。トップだけが表示されても、フォームや注文が止まっていれば復旧とは言えません。運用責任者と検証項目を決め、障害チケットへ結果を残してください。検索エンジン向けの重要ページも再確認します。

まとめ：PHP更新直後のHTTP 500は「PHPを戻す」前に、ログから最初のエラーを確認し、サーバー側かサイト側かを分け、最小変更で修正します。復旧の完了条件は、修正済みPHPの維持と主要機能の正常動作の両方です。本記事の情報確認日は2026年10月23日です。作業時はPHP、WordPress、ホストの最新の公式案内を確認してください。

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

サイト運用では、障害ログの整理、更新対象の棚卸し、検証項目の作成など、判断を支える作業が増えています。AIは調査メモの整理やチェックリスト作成を助けますが、脆弱性の修正適用や復旧判断を自動で保証するものではありません。WithAIでAIの使い方を学び、情報の真偽と安全性を自分で確認できる力を身につけませんか。詳しくは下のバナーからご確認ください。