沼 健一郎

WordPress障害対応

プラグイン更新でFatal error：一次資料で原因を確定させる手順

／動かなくなったWordPressの原因特定と復旧。ログの読み方と、層を分けた切り分けの手順。

WordPressのプラグインを更新したら白画面になった。あるいは管理画面だけ落ちた。

このとき最も多い対応は「更新したプラグインを止める」です。それで復旧はしますが、なぜ落ちたかが分からないままなので、次の更新でまた落ちます。

原因を確定させる手順を書きます。推測ではなく、一次資料で確定させます。

結論：この順で確定させる

  1. エラーログからファイル名・行番号・クラス名を取る
  2. その行の実際のコードを読む
  3. WordPress本体の変更履歴と突き合わせる
  4. 「更新後の互換性問題」なのか「元からある不具合」なのかを判定する

STEP 0: まず復旧させる

原因調査の前に、サイトを立ち上げます。落ちたままの調査は焦って判断を誤ります。

SSHかFTPで、該当プラグインのディレクトリ名を変更します。

cd wp-content/plugins
mv problem-plugin problem-plugin.disabled

WordPressは存在しないプラグインを自動的に無効化するので、これでサイトは復旧します。削除ではなくリネームにしてください。 コードを読む必要があります。

STEP 1: エラーログからファイルと行を取る

白画面のままでは何も分かりません。デバッグログを有効にします。

// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);  // 画面には出さない

wp-content/debug.log に記録されます。Fatal errorなら、こういう行が出ます。

PHP Fatal error:  Uncaught Error: Call to undefined method
WP_Query::get_something() in /path/to/plugins/xxx/includes/class-abc.php:142

取るべき情報は3つです。

  • エラーの種類（Call to undefined method / Cannot redeclare / Class not found など）
  • ファイルパスと行番号
  • 関わっているクラス名・メソッド名

サーバーによっては debug.log ではなくサーバーのエラーログに出ます。cPanelの「エラー」やSSHでログを確認してください。

STEP 2: その行を実際に読む

ここが最も飛ばされます。 エラーメッセージだけで判断せず、該当行のコードを開いてください。

sed -n '135,150p' wp-content/plugins/xxx/includes/class-abc.php

読むのは前後15行程度で足ります。見るべきは以下です。

  • 呼び出しているメソッド・関数は何か
  • それはWordPress本体のものか、プラグイン内のものか、他プラグインのものか
  • 引数はいくつ渡しているか

Call to undefined method なら、そのメソッドが本当に存在しないのかを確認します。

grep -rn "function get_something" wp-includes/

存在しなければ、WordPress本体から削除されたか、名前が変わったかです。

STEP 3: WordPress本体の変更と突き合わせる

WordPressのメジャーアップデートでは、関数やクラスが変更・廃止されます。プラグインがそれに追随していないと落ちます。

確認先は3つあります。

WordPress公式の開発者向け変更履歴

各バージョンのリリースノートに、廃止された関数の一覧があります。

関数リファレンス

その関数のページに「Deprecated since X.X」と書かれていれば、廃止済みです。代替関数も併記されています。

WordPress本体のソース

最も確実です。手元のWordPressで直接検索します。

# 関数が定義されているか
grep -rn "function wp_something" wp-includes/ wp-admin/

# 引数の数が変わっていないか
grep -rn -A3 "function wp_something" wp-includes/

引数の数の変更は見落としやすい原因です。関数は存在するのに、必須引数が増えていて ArgumentCountError になります。

STEP 4: 「更新で壊れた」のか「元から壊れていた」のか

ここを区別してください。対処が変わります。

更新で壊れた場合

  • プラグインの更新履歴を見る（readme.txt の Changelog）
  • WordPress本体を更新したなら、そのバージョンの変更点を見る
  • どちらを更新して落ちたかを特定する

対処は、プラグインの新版を待つか、該当箇所にパッチを当てるか、代替プラグインに移るかです。

元から壊れていた場合

特定の条件でだけ発動する不具合が、たまたま今日踏まれただけということがあります。

判定方法は、同じ操作を別の環境で再現できるかです。ステージング環境で同じ手順を踏んで再現しなければ、環境固有の要因（データ、他プラグイン、PHPバージョン）が関わっています。

再現しない場合、「再現せず」と記録に残してください。 原因不明のまま「直った」ことにすると、次に同じ現象が起きたときに一からやり直しになります。

よくある原因パターン

PHPバージョンの非互換

サーバーがPHPを自動更新して、古いプラグインが動かなくなるパターン。エラーは Syntax error や Deprecated から始まり、やがてFatalになります。

php -l wp-content/plugins/xxx/xxx.php   # 構文チェック

プラグイン同士の衝突

Cannot redeclare function は、2つのプラグインが同じ名前の関数を定義しています。片方を止めるしかありません。

メモリ不足

Allowed memory size exhausted はコードの問題ではなくリソースです。

define('WP_MEMORY_LIMIT', '256M');

テーマ側のカスタムコード

functions.php に書かれた独自コードが原因のことがあります。プラグインを疑う前に、テーマを標準テーマに切り替えて再現するか確認してください。

調査を記録に残す

原因が分かったら、以下を残してください。

  • 発生日時と症状
  • エラーログの該当行（ファイル・行番号・メッセージ）
  • 確定した原因と、その根拠（どのソースで確認したか）
  • 対処内容
  • 再現しなかった項目

「根拠」を書くのが重要です。「たぶんプラグインの互換性」ではなく「WordPress 6.8で wp_hash_password() の実装が変わり、旧ハッシュとの照合が失敗するため。wp-includes/pluggable.php:xxx で確認」と書けば、次の人が検証できます。

まとめ

Fatal errorの調査は、推測を挟まないことです。

エラーログにファイル名と行番号が書いてあるのだから、そこを読む。関数が存在するかは本体を検索すれば分かる。この2つをやるだけで、大半は30分で確定します。

「プラグインを止めたら直った」で終わらせると、同じことが繰り返されます。

サイトが落ちて困っている方へ

WordPressの障害復旧を承っています。更新後の白画面、Fatal error、管理画面に入れないなど。原因の特定から復旧、再発防止まで対応します。

販売実績58件・評価5.0・出品者ランク プラチナ（2026-09時点）

WordPress障害対応 の他の記事