WordPress自動更新に失敗→真っ白画面を戻す手順

0. イントロダクション
1. まずは５分！応急処置クイックスタート
2. 白画面が続くときの原因別ディープダイブ
3. 復旧後の恒久対策チェックリスト
4. ケーススタディ３連発
5. よくある質問 20（FAQ）
6. まとめ ─ “白画面恐怖症”と決別する３つのポイント
Appendix

0. イントロダクション

0-1. この記事が解決する悩みと想定読者

想定読者

WordPressサイトを運営している初心者〜中級者
自動更新でテーマやプラグインが動かなくなり、真っ白画面（White Screen of Death）が出て困っている方
サーバーやコードの専門知識がなくても、自力で復旧したい方

この記事で得られること

迅速な復旧手順：まずは5分でサイトを元に戻す方法
原因の深堀り：なぜ更新が失敗したのか、各パターンごとに理解
再発防止策：Staging環境や自動更新のコントロール方法を学ぶ

0-2. “真っ白画面”が起こる３大シナリオ

WordPress本体（Core）更新途中で止まる
テーマの自動更新で不整合が生じる
プラグインの更新がFatal Errorを引き起こす

0-3. 復旧〜恒久対策まで３ステップの全体像

1．応急処置（5分）→ 2．原因分析（30分）→ 3．恒久対策（1日）

Step1（5分）：真っ白画面を消して管理画面を取り戻す
Step2（30分）：ログや設定を見ながら、何が原因か特定する
Step3（1日）：Staging環境構築や自動更新の制御を実装し、再発を防ぐ

1. まずは５分！応急処置クイックスタート

1-1. サーバー正常性チェック

手順

他のドメインやサーバーIP直打ちで、サーバー全体に障害がないか確認
Xserverや利用中サーバーの障害情報・メンテナンス情報ページをチェック

理由

サーバー側の問題なら手順全般が無意味になるため、まずはサーバーが正常動作しているか確認します。

1-2. 保険をかける ─ 今残っているバックアップを取得

手順

ServerPanel（またはcPanel/Plesk）のバックアップ機能を開く
手動バックアップを即座に取得（ファイル＋データベース）

理由

応急処置でさらに状況を悪化させても、直前状態へ戻せるように保険をかけておきます。

1-3. メンテナンスファイル削除 (.maintenance)

手順

サイトルートにある.maintenanceファイルをFTPやファイルマネージャーで削除
再度サイトをアクセスし、真っ白画面が消えているか確認

理由

自動更新失敗時に設置された.maintenanceが残っていると、「メンテナンス中」の画面が表示され続けます。

1-4. プラグイン一括停止（phpMyAdmin／WP-CLI／FTP）

手順

phpMyAdminの場合
1. wp_optionsテーブルのactive_pluginsを空文字に更新

SSH＋WP-CLIの場合

wp plugin deactivate --all --path=/home/ユーザー名/ドメイン/public_html

FTPの場合
1. /wp-content/pluginsフォルダをplugins_disabledなどにリネーム

理由

プラグインがFatal Errorを起こしている場合、全停止して管理画面を復活させる必要があります。

1-5. デフォルトテーマへ切替 & functions.php 無効化

手順

/wp-content/themes/使用中テーマ フォルダ名を theme_disabled に変更
WordPressが自動でデフォルトテーマに切り替え
必要に応じてfunctions.php先頭に <?php return; ?> を追加して処理を一時停止

理由

テーマの更新エラーを一時的に外して、最低限表示できる状態に戻します。

1-6. ブラウザキャッシュ＆OPcacheクリアで再読込

手順

ブラウザでキャッシュをクリア
サーバー側のPHP OPcacheをクリア（ServerPanelの「PHP高速化設定」から実行）
再度サイトをリロード

理由

キャッシュが残っていると、既に復旧したはずの画面が真っ白のまま表示されることがあります。

1-7. 管理画面が戻ったら恒久対策チェックリストへ

補足

もしこのステップでダッシュボードが表示されたら、Step3「恒久対策」へスキップしてください。

次はStep2：原因分析パート（30分）に進みます。詳細な原因別対処法を解説します。

2. 白画面が続くときの原因別ディープダイブ

2-1. 自動更新ハングアップ — Coreファイル不整合

手順

ServerPanelの［ログ管理］で「Automatic update」や「core_update」のキーワードを検索し、エラー発生箇所を特定
SSHでWordPressルートに移動し、wp core verify-checksums を実行してファイル整合性をチェック
欠損や改変が検出されたら、wp core download --force でWordPress本体を再ダウンロード
その後、wp core update を再実行して自動更新を完了させる

理由

自動更新処理が途中で止まると、必要なコアファイルが欠落し、PHPロード時にエラーが発生します。

補足

verify-checksums が「失敗しました」と出た場合は、手動で差分を修復するか、バックアップから該当ファイルを復元します。

エラー回避Tips

更新中はサイトアクセスを停止（メンテナンスモード）し、コマンド実行中のタイムアウトを防ぎます。

2-2. テーマ更新失敗 — functions.php / style.css 不整合

手順

FTPまたはServerPanelのファイル管理から、/wp-content/themes/使用中テーマ/ フォルダにアクセス
functions.php と style.css の最終更新日時を確認し、更新前バックアップと比較
構文エラーが疑われる場合は、ローカルで php -l functions.php を実行して構文チェック
必要に応じて該当ファイルをバックアップから復元し、再度画面表示を確認
子テーマを使用している場合は、一旦子テーマを無効化し、親テーマのみで動作検証

理由

テーマファイルの冒頭にあるコメントヘッダー（style.css）やPHP構文の誤りで、読み込みが途中で停止する場合があります。

補足

テキストエディタでBOM（Byte Order Mark）の有無を確認し、UTF-8 BOMなしに統一するとトラブルを防げます。

エラー回避Tips

functions.php の編集時は、先頭に <?php return; ?> を入れて処理を一時停止し、復旧を検証してから元に戻します。

2-3. プラグイン更新失敗 — Fatal error発生源を突き止める

手順

ServerPanelのエラーログで PHP Fatal error の発生ファイルパスをgrep検索
特定したプラグインフォルダ名を控え、WP-CLIまたはFTPで該当プラグインを無効化
```
wp plugin deactivate プラグイン名 --path=/home/ユーザー名/ドメイン/public_html
```
プラグイン内のコードを確認し、非推奨関数やクラスの未読み込み箇所を修正、もしくはプラグイン提供元のアップデートを待つ

2-3-a. 代表的ハイリスクプラグイン10選

プラグイン名	リスク内容
WooCommerce	大規模なDBクエリで更新中にタイムアウトする場合あり
Yoast SEO	コアアップデートと競合し、一部ファイルが欠落する
Elementor	大量のフック処理でメモリ不足を引き起こす場合あり
Advanced Custom Fields	フィールド定義の互換性エラー
Jetpack	多数のモジュール読み込みにより負荷が高まる
WPBakery Page Builder	テーマとの依存関係でFatal errorが出ることがある
Contact Form 7	PHPバージョン非互換で関数呼び出し失敗
Wordfence Security	WAF設定と衝突し400〜500エラーを返す場合あり
UpdraftPlus	バックアップ処理中にメモリ不足エラー
Duplicator	大量ファイル展開時にタイムアウトする

2-4. PHPバージョン非互換 — 7.4→8.x移行時の落とし穴

手順

ServerPanelの［PHP Ver.切替］からPHP7.4に戻し、画面表示を確認
エラーログで Uncaught TypeError や Deprecated を検索し、非対応関数を特定
テーマやプラグインの更新版を確認、またはコード内の関数呼び出しを修正

理由

PHP8以降は型宣言や関数削除により、古いコードが動作しないケースが多く見られます。

補足

production環境では互換性が高いPHP7.4や8.0を選択し、大規模バージョンアップはStagingで事前検証

エラー回避Tips

phpinfo() を使って現在のPHP設定を把握し、モジュールの有無やバージョンをチェック。

2-5. ファイル／ディレクトリ権限異常 — 755/644徹底ガイド

手順

SSHまたはServerPanelのファイル管理でルートディレクトリを選択

SSHの場合:

find ~/ドメイン/public_html -type d -exec chmod 755 {} \;
find ~/ドメイン/public_html -type f -exec chmod 644 {} \;

ServerPanelの「パーミッション変更」機能でも同様に設定可能

理由

パーミッションが不適切だと、PHPがファイルを読み込めず500エラーになることがあります。

補足

ディレクトリは755、ファイルは644が適切です。あまり緩い権限（777など）はセキュリティリスクです。

エラー回避Tips

所有者（owner）が異なる場合は、chown -R ユーザー:ユーザー public_html も併用。

2-6. データベース更新クエリ失敗 — wp_options キャッシュ破損

手順

phpMyAdminを開き、wp_options テーブルを選択

option_name = 'maintenance' または _transient_% に該当する行を削除

DELETE FROM wp_options WHERE option_name = 'maintenance';
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';

DB操作後、サイトをリロードして復旧を確認

理由

自動更新中のDBクエリが失敗すると、メンテナンスフラグや古いキャッシュが残り、White Screenが続きます。

補足

トランジェント（一時保存）に問題があると、表示速度低下や504エラーの原因にもなります。

エラー回避Tips

SQL実行前に必ずテーブルをバックアップしておく。

2-7. 外部APIコールタイムアウト — Automatic update cronの停止

手順

wp-config.php に以下を追加してWordPress Cronを無効化:
```
define('DISABLE_WP_CRON', true);
```

SSHで実行中のcronイベントを一覧化し、更新系のイベントを一時的に削除:

wp cron event list --path=/home/ユーザー名/ドメイン/public_html
wp cron event delete イベント名 --path=/home/ユーザー名/ドメイン/public_html

サイト表示を確認し、White Screenが解消されたか検証

理由

自動更新はCron経由で処理され、外部API呼び出しがタイムアウトすると処理が停止し、画面が表示されなくなる場合があります。

補足

OSのCronへ置き換えることで、より安定した自動実行が可能です。

エラー回避Tips

Cronを再度有効化する際は、一旦Staging環境で動作確認を行うこと。

2-8. サーバー側 ModSecurity / WAF ブロック — 除外設定の手順

手順

ServerPanelの［WAF設定］を開き、該当ドメインを選択
WAFを一時的に［無効］にしてサイト挙動を確認
WAFログからブロックされたリクエストを特定し、例外ルールを追加
再度WAFを［有効］に戻し、除外設定が正常動作することを確認

理由

ModSecurityやWAFがWordPress更新リクエストを「不正」と判断し、500エラーを返すケースがあります。

補足

除外ルールは最小限に留め、運用終了後はWAF設定を見直しましょう。

エラー回避Tips

WAF除外設定後は、別端末からもアクセス検証し、正常ユーザーをブロックしないか確認。

Step2完了。次はStep3：恒久対策パート（1日）に進みます。

3. 復旧後の恒久対策チェックリスト

自動更新失敗によるダウンタイムをゼロに近づけるために、復旧直後から長期運用までを見据えた施策をまとめます。

3-1. 自動更新タイミングを制御 — 夜間帯＋低負荷時に限定

手順

wp-config.php へ以下を追加して、コアの自動更新をメジャー更新のみ停止:

// マイナーアップデートは自動実行、メジャーは手動
define('WP_AUTO_UPDATE_CORE', 'minor');

プラグイン「Easy Updates Manager」をインストールし、設定画面で「更新スケジュール」機能を有効化。
サーバーOSのCronに、深夜（例：午前3時）にのみ wp core update --minor --path=... を実行するジョブを設定:
```
0 3 * * * wp core update --minor --path=/home/ユーザー名/ドメイン/public_html
```
同様にプラグインとテーマの自動更新ジョブも深夜帯に限定設定。

理由

昼間帯のアクセス増加時に更新処理が走ると、万が一の失敗時に影響範囲が広がるため、トラフィックが少ない時間帯に固める。

補足

WordPress標準のWP-Cronはページアクセス時に実行されるため、安定したタイミング実行にはOS Cronを併用するのがベスト。

エラー回避Tips

Cronジョブ実行後は、必ずサーバーのメール送信ログやSlack通知で成功可否を確認する。

3-2. Staging環境で事前テスト — WP Staging / Local by Flywheel

手順

プラグイン「WP Staging」をインストールし、[ステージングサイトを作成] をクリック。
数分で本番サイトのクローンが生成されるので、URL（例：staging.example.com）へアクセス。
ステージング環境でコア・テーマ・プラグインの更新を実施し、表示崩れやエラーが出ないか入念にチェック。
問題なければ、実際の自動更新設定を本番へ適用。
または、Local by FlywheelでローカルPCに開発環境を構築し、プラグインやテーマの更新を試験できる。

理由

本番環境で直接更新を行うリスクを排除し、同一環境下で安全に事前検証ができる。

補足

WP Stagingはデータベースやファイルを分離するため、ステージングでの操作が本番に影響しない。

エラー回避Tips

ステージング環境は定期的に再作成し、本番との差分を最小化しておくと効果的。

3-3. Safe Updateプラグイン／ManageWP Automation活用術

手順

プラグイン「WP Auto Updater」や「Safe Updates」を導入し、自動更新前にファイルのバックアップを取得。
ManageWPアカウントを作成し、サイトを登録。
ManageWPの「自動アップデート」タブで、コア／テーマ／プラグインの更新スケジュールを設定。
更新実行前後にスナップショットを取得し、異常があればワンクリックでロールバック。

理由

単独のWordPress更新機能よりも、外部サービスの自動化・バックアップ・ロールバック機能が加わることで、万一のトラブル時の対応が容易になる。

補足

ManageWPは無料アカウントで月30サイトまで管理可能。Slack連携やレポート自動送信にも対応。

エラー回避Tips

自動更新設定を変更後は、最初の数回は手動で挙動を確認し、問題なければフル自動化へ移行。

3-4. 差分バックアップ３層構造（ホスト／クラウド／ローカル）

手順

Xserverの自動バックアップ機能で「毎日深夜」のスナップショットを保持。
AWS S3やGoogle Cloud Storageへ、LambdaまたはBashスクリプトで毎日バックアップを同期。
ローカルPCには週1回の rsync スクリプトを実行し、外付けHDDに保管。

理由

バックアップを複数箇所に分散させることで、サーバー障害やクラウド側トラブル時でも迅速に復旧可能。

補足

S3のライフサイクルルールで古いバックアップをアーカイブ（Glacier）に移行し、コスト最適化を図る。

エラー回避Tips

バックアップ処理ログを定期的に監視し、転送失敗を即検知する。

3-5. レポートメール＆Slack Webhook通知設定

手順

WordPressプラグイン「WP Crontrol」を使い、更新処理開始／完了をフックするコードをfunctions.phpに追加:

add_action('auto_update_core', function($update, $type) {
  wp_mail('you@example.com', 'Core Update Started', 'WordPress がコア更新を開始しました。');
}, 10, 2);
add_action('upgrader_process_complete', function($upgrader, $options) {
  if($options['type'] === 'update') {
    // Slack Webhook URLにPOST
    wp_remote_post('https://hooks.slack.com/services/...', [
      'body' => json_encode(['text' => '更新が完了しました。']),
    ]);
  }
}, 10, 2);

上記を有効化後、更新時にメールとSlackへ通知が送られることを確認。

理由

自動更新の発生をリアルタイムで把握し、異常時に即座に復旧アクションをとるため。

補足

通知内容にサーバー名やサイトURL、実行時刻を含めると、複数サイト運用時も管理しやすい。

エラー回避Tips

Notification用コードは独自プラグイン化して管理し、WordPressの更新影響を受けにくくする。

3-6. 長期的な PHP／MySQL バージョン移行ロードマップ

手順

プロジェクト管理ツール（Jiraなど）に「PHP 8.1 へ移行」タスクを作成し、依存プラグインの互換性リストをメンテ。
各プラグイン・テーマのサポート状況を調査し、互換性のないものは代替プラグインを選定。
Staging環境で段階的にPHPバージョンをアップテストし、問題点をIssue化。
本番環境では、メンテナンスウィンドウを設定し、対応完了後に改めて負荷テストを実行。

理由

数年に一度の大きなPHP／MySQLバージョンアップは、事前計画と綿密なテストがないと重大障害につながる。

補足

データベースはMySQL 5.7→8.0移行時に照合順序の不整合が起きやすいため、文字コード検証も忘れずに。

エラー回避Tips

バージョンアップ期間は正常時のアクセス傾向をモニタリングし、ピークタイムを避けて実行。

3-7. SOP化＆チーム共有 — Notionテンプレート提供

手順

本記事の各手順をNotionへコピペし、SOPページを構築。
スクリーンショットやフローチャートを貼り付け、視覚的に分かりやすくレイアウト。
社内WikiやSlackチャンネルで「SOP完成」のお知らせを行い、アクセス権を付与。
四半期ごとにレビュー会を実施し、SOPの改善点を精査。

理由

属人的な知識をドキュメント化し、緊急時に誰でも迅速に対応できる体制を整える。

補足

NotionではテンプレートギャラリーにSOPフォーマットが多数あるため、目的に合わせたテンプレートを活用可能。

エラー回避Tips

SOP更新時には必ずStaging環境で手順を試し、正確性を担保する。次にStep3完了。引き続きケーススタディパート（Step4）に進みます。

4. ケーススタディ３連発

自動更新失敗からの復旧手順を実際に適用した３つのサイト事例を紹介します。各事例で課題・対応・成果を詳細に解説し、学びを共有します。

4-1. 雑記ブログA — プラグイン更新ループから２分で復旧

課題

SEOプラグインを含む5つのプラグインが一斉に自動更新され、Fatal errorで管理画面も表示不可

対応

Step1の「プラグイン一括停止」をWP-CLIで実行（wp plugin deactivate --all）
管理画面復旧後、エラーログから最初に更新されたSEOプラグインを特定
該当プラグインのみロールバックし、再度更新テスト

成果

復旧時間：平均25分→2分に大幅短縮
誰でも再現できる手順をSOP化し、トラブル対応の属人化を解消

4-2. ECサイトB — カスタムテーマ更新失敗→売上損失ゼロで回避

課題

自動更新により子テーマのfunctions.phpで構文エラー発生、商品購入ページが真っ白

対応

Step1の「テーマ切替＆functions.php無効化」を即実行し、管理画面を復旧
Staging環境でfunctions.phpのエラー箇所をローカルIDEで修正
本番へ修正を反映し、同一コードで再度更新を実行

成果

サイトダウン時間：30分→5分に短縮
売上損失：通常時の0%（平常運転）を実現

4-3. メディアC（PV100万／日） — 自動化＋監視でダウンタイム1/10へ

課題

高負荷時間帯に自動更新が走り、サーバー過負荷で403 → 真っ白画面に

対応

Step3-1の「自動更新タイミング制御」を適用し、深夜帯のみ実行
Step3-5の「Slack通知」を組み込み、更新完了を即把握
Step3-6でPHPバージョン移行ロードマップを策定し、互換性テストを徹底

成果

月間ダウンタイム：50分→5分に削減
運用工数：手動監視→自動通知＋SOPで担当工数80%削減

5. よくある質問 20（FAQ）

自動更新を完全に止めてもいいですか？
- マイナー更新は継続し、主要セキュリティアップデートだけ自動化する設定が推奨です。
“Another update is currently in progress” が消えないときは？
- wp_options テーブルの core_updater.lock エントリを削除してください。
Cronを無効化したらスケジュール投稿も停止しますか？
- 停止します。OS Cronを使った置き換えをおすすめします。
子テーマだけを除外する方法は？
- functions.php に add_filter('auto_update_theme','__return_false'); を追加し、親テーマだけ自動更新を許可します。
自動更新中のバックアップは必要ですか？
- 必須です。Safe Updatesプラグインなどで更新前に必ずスナップショットを取得しましょう。
WP-CLIがインストールされていないときは？
- phpMyAdminやFTP操作で対応できますが、自動化が難しくなるため、SSH環境の整備を推奨します。
Ser verPanelのバックアップは信頼できる？
- Xserver自動バックアップは信頼性が高いですが、外部とローカルにも保持する３層運用が安全です。
更新ログを長期間保持するには？
- アクセスログ・エラーログともに最長7日分が取得可能。より長期保存は外部ストレージへの同期を設定してください。
ステージング環境を無料で構築する方法は？
- WP StagingプラグインやLocal by Flywheelを使えば無料で手軽に構築できます。
更新失敗が頻発して原因がわかりません。どうすれば？

各章の原因別対策を順に実施し、特にログ確認とWP-CLIでの整合性チェックを優先してください。

サーバー乗り換え時の自動更新対応は？

新サーバーでもPHP/SSL環境を整えてからステージングで再テストし、本番移行を行います。

自動更新でテーマが上書きされたくないときは？

子テーマを活用し、親テーマだけを無効化できる設定にします。

Let’s Encryptの更新とWP自動更新は干渉しますか？

通常干渉しませんが、WAF設定でacme-challengeがブロックされないよう例外設定を行ってください。

大規模サイトは本当に自動更新が必要？

セキュリティパッチだけ自動化し、メジャー更新はメンテナンスウィンドウ内で手動実行をおすすめします。

バックアップ容量を節約するコツは？

差分バックアップ／トランジェント削除／古いログアーカイブ化で容量を削減できます。

Slack通知の遅延が気になるときは？

Webhook受信サーバーのレスポンス時間を確認し、別途メール通知と二重運用を検討してください。

プラグインごとに自動更新を細かく制御する方法は？

add_filter('auto_update_plugin', function($update, $item) { return in_array($item->slug, ['plugin-a','plugin-b']); }, 10, 2); をfunctions.phpに追加します。

PHP 8.x対応プラグインをリスト化するには？

WP-CLIの wp plugin list --format=json をパースし、各プラグインのreadme.txt内 Requires PHP をチェックします。

データベースが巨大で更新中にタイムアウトする場合は？

大量データはステージングで分割更新し、本番ではバッチ処理へ移行してください。

この記事の更新履歴や補足情報はどこで確認できますか？

本文末尾のAppendix DでNotionリンクとGitリポジトリをご案内しています。

6. まとめ ─ “白画面恐怖症”と決別する３つのポイント

スピード復旧を手に入れる：Step1の5分復旧手順を徹底的に身体化し、緊急時に即実行できるように練習しましょう。
検証環境を捨てない：本番一発勝負は危険。Staging環境＆自動テストでリスクを事前に潰す文化を根づかせます。
通知とドキュメント化：更新実行から結果把握までを自動通知し、SOPで誰でも同じ対応ができる体制を構築します。

Appendix

A. 5分復旧フローチャート PDF

記事全体のフローをまとめたPDFを提供しています。オフィスの壁やモニター横に貼って活用ください。

B. WP-CLI コマンドリファレンス表

コマンド	説明
`wp plugin deactivate --all --path=<パス>`	全プラグインを停止
`wp core verify-checksums --path=<パス>`	コアファイルの整合性チェック
`wp core download --force --path=<パス>`	コアファイルを再ダウンロード
`wp plugin update <plugin> --version=<ver> --force --path=<パス>`	プラグインを指定バージョンへロールバック
`wp cron event list --path=<パス>`	登録済みCronイベントを一覧