タグアーカイブ トラブル解決

  1. ホーム   /  タグ付きの投稿: "トラブル解決" ( 固定ページ8 )
WordPress更新後にサイトが完全にダウンした時の復旧手順
2026年7月2日 0

WordPress更新後にサイトが完全にダウンした時の復旧手順

プラグインやテーマの更新後にサイト全体がダウンし「このサイトで重大なエラーが発生しました」と表示される場合、多くの原因は .htaccess に書き込まれた不適切な指示がサーバー設定と衝突していることにある。FTP / SFTP でサーバーに接続し .htaccess から問題の行を削除するかファイルを一旦削除したあと、WordPress 管理画面でパーマリンク設定を再保存すれば復旧できる。

更新後にサイトが完全にダウンする仕組み

更新後にサイトが完全にダウンする仕組み

一部のプラグインやテーマは、更新時にパフォーマンス向上や URL の取り回しを目的として .htaccess に独自のルールを自動挿入する。これがサーバーの許容範囲を超えると、Apache が起動時に設定ファイルを解釈できず「500 Internal Server Error」を返し、フロントエンドも管理画面もアクセス不能になる。

典型的なのが Option MultiViews のような指示を勝手に追記するケースだ。この機能は Apache のコンテントネゴシエーション（ファイル名の拡張子を自動補完してリクエストを解決する仕組み）を有効にするが、レンタルサーバーや共用ホスティングではセキュリティとルーティングの競合を防ぐために AllowOverride で無効化されていることが多い。許可されていない場所に書かれた Option MultiViews は「ここでは許可されていません」というサーバーエラーを引き起こし、サイト全体を落とす。

WordPress 本体の更新ではこのような追記はほぼ発生しない。問題が起きるのは、更新と同時に .htaccess を操作する一部のキャッシュ系プラグイン、セキュリティ系プラグイン、多言語プラグインだ。プラグイン開発者のテスト環境と本番サーバーの設定が異なるために発生する「動作確認済み」とされる更新でも、自分の環境では致命的になることがある。

.htaccess のエラーでアクセス不能になった時の復旧手順

.htaccess のエラーでアクセス不能になった時の復旧手順
STEP 1 FTP クライアントやサーバーのファイルマネージャでサイトに接続する
↓
STEP 2 WordPress インストールディレクトリ直下の .htaccess をダウンロードしてバックアップする
↓
STEP 3 問題の行（例 Option MultiViews）を削除するか .htaccess を一旦削除する
↓
STEP 4 WordPress 管理画面にログインし「設定」→「パーマリンク」を開いて「変更を保存」をクリックする

FTP 接続と .htaccess の場所を確認する

まずは FTP クライアント（FileZilla など）や契約中のサーバーが提供するファイルマネージャでサーバーに接続する。WordPress をインストールしたディレクトリ（多くの場合は public_html か httpdocs）を開き、直下に .htaccess というファイルがあるかを確認する。ドットで始まるファイルはデフォルトで非表示になっている場合があるので、FTP クライアントの設定で隠しファイルを表示するように切り替える必要がある。

エラーログを確認して原因行を特定する（可能な場合）

サーバーのエラーログを見られれば原因の特定は早い。cPanel やコントロールパネルに「エラーログ」または「Error Log」という項目があるので、直近のエントリを確認する。今回のようなケースでは .htaccess: Option MultiViews not allowed here というエラーメッセージが記録されている。この行がログに残っていれば .htaccess 内の Option MultiViews を含む行やブロックを削除するだけで復旧する可能性が高い。

Before（問題のある .htaccess）
# BEGIN WordPress
…
Option MultiViews
…
# END WordPress
↓
After（該当行を削除）
# BEGIN WordPress
…
…
# END WordPress
■ エラーを引き起こす行　■ 削除後

.htaccess を削除して WordPress に再生成させる方法

エラーログを確認できない場合や問題の行を特定できない場合は .htaccess を一旦削除してしまうのが手っ取り早い。削除する前に必ずファイルをダウンロードして手元にバックアップを取っておく。削除後、サイトが表示されるようになったら WordPress 管理画面の「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」ボタンを押す。これで WordPress が必要最小限の .htaccess を自動生成する。

パーマリンク設定を保存して再生成された .htaccess には WordPress の標準ルールだけが書かれているため、問題を引き起こしていた余計な指示は含まれない。この状態でサイトが正常動作していれば復旧成功だ。

原因となったプラグインの特定と対処

.htaccess を修正しても、問題のプラグインをそのままにしておくと再度更新が走ったときや設定変更時に同じことが起きる。更新直前にどのプラグインやテーマを更新したかを確認し、該当するものを一時的に無効化しておく。

管理画面に入れるなら「プラグイン」画面から該当プラグインを停止する。管理画面にも入れない場合は、FTP で /wp-content/plugins/ ディレクトリにアクセスし、該当プラグインのフォルダごと名前を変更する（例: plugin-name を plugin-name-disabled にする）。これでプラグインが強制的に無効化され、管理画面にアクセスできるようになる。

.htaccess を修正しても直らない場合の追加対応

.htaccess を修正しても直らない場合の追加対応

ブラウザキャッシュとサーバーキャッシュをすべて削除する

.htaccess を修正してもまだエラー画面が表示される場合、キャッシュが古いエラー状態を保持している可能性がある。ブラウザのキャッシュを削除し、サーバー側で Varnish や OPcache などのキャッシュ機構が動いている場合はそれらもクリアする。コントロールパネルにキャッシュ管理機能があればそこから削除し、WordPress 用のキャッシュプラグインを導入しているなら FTP で /wp-content/cache/ ディレクトリの中身を手動で削除する。

全プラグインを強制無効化して標準テーマに切り替える

.htaccess の問題ではなく、更新されたプラグインやテーマのコードそのものが PHP の致命的エラーを起こしている可能性もある。FTP で /wp-content/plugins/ フォルダ全体を plugins-temp などにリネームし、使用中のテーマ（/wp-content/themes/テーマ名）もリネームする。WordPress はプラグインがなくても動作し、有効なテーマがない場合は標準テーマ（Twenty Twenty-Five など）に自動でフォールバックする。これで管理画面に入れれば、あとは問題のプラグインやテーマを一つずつ戻して原因を絞り込む。

サーバー会社に AllowOverride 設定を確認する

Option MultiViews のような指示がサーバー側でどう扱われるかは Apache の AllowOverride 設定で決まる。自前で httpd.conf やバーチャルホスト設定を編集できない共用サーバーでは、サーバー会社に「.htaccess に Option MultiViews を記述したところサイト全体が停止した。この指示を許可する設定に変更できるか」と問い合わせる手段もある。ただしセキュリティ上の理由で許可されないケースが大半なので、その場合はプラグインの設定を見直すか、代替プラグインを検討する必要がある。

更新による .htaccess 破損を防ぐための対策

更新による .htaccess 破損を防ぐための対策
更新前 必ずサイト全体と .htaccess をバックアップする
更新時 可能ならステージング環境で先にテストする
更新後 即座にサイト全体が表示されるか確認し、問題があれば即座にロールバックする

更新前にかならずバックアップを取る習慣をつける

WordPress 本体、プラグイン、テーマのいずれを更新する場合でも、更新前にサイト全体とデータベースのバックアップを取ることは最も基本的で強力な防御策だ。.htaccess も設定ファイルの一つとしてバックアップ対象に含めておく。バックアップがあれば、今回のようにサイトが完全にダウンしても数分で元の状態に戻せる。

ステージング環境で事前に検証する

本番環境に直接更新を適用する前に、ステージング環境（本番と同一のサーバー設定を持つテストサイト）で動作確認を行うことで、.htaccess の競合や PHP エラーを事前に検出できる。多くの国内レンタルサーバーはコントロールパネルから簡単にステージングサイトを作成できる機能を提供している。少なくとも重要なプラグインのメジャーアップデートでは、このステップを踏むことで大規模なダウンを回避できる。

プラグインの変更履歴を確認し .htaccess 操作の有無を把握する

更新前にプラグインの変更履歴（Changelog）を確認する習慣も有効だ。特に「Improved .htaccess rules」「Added server-level optimizations」などの記述がある場合は要注意で、更新後に .htaccess が書き換わる可能性が高い。こうした更新は必ずバックアップを取ったうえで適用し、適用直後に .htaccess の内容を確認して想定外の追記がされていないかチェックする。

よくある質問

更新後に管理画面だけでなくフロントエンドも真っ白になるのはなぜか

.htaccess のエラーは PHP の処理に入る手前のサーバーレベルで発生するため、WordPress のエラーハンドリング機構が一切働かない。結果としてフロントエンドも管理画面も同じ「500 Internal Server Error」や真っ白な画面になり、WordPress のデバッグモードでもエラーメッセージが表示されないことが多い。

.htaccess を削除しても問題ないのか

WordPress のパーマリンク設定を保存すれば必要なルールは自動で再生成されるので、.htaccess の削除自体は安全だ。ただし独自に追加したリダイレクトルールや BASIC 認証設定などがある場合はバックアップから手動で戻す必要がある。

FTP でサーバーに接続できない場合はどうすればよいか

サーバー会社が提供するコントロールパネル（cPanel など）のファイルマネージャが使えるかを確認する。多くの場合ブラウザから直接ファイルを編集できる。それも使えない状況であればサーバー会社のサポートに連絡し「.htaccess の特定の行を削除してほしい」と依頼するのが最も早い復旧手段になる。

今回のエラーはプラグインの不具合なのか

厳密にはプラグインのコードに問題があるというより、プラグインが想定するサーバー環境と実際のサーバー設定の不一致によって発生する。プラグイン開発者が Option MultiViews が許可されている環境で開発し、許可されていない共用サーバーでエラーが出るケースが典型だ。したがって「不具合」というより環境依存の問題と呼ぶ方が実態に近い。

同じ問題を起こさないために .htaccess をロックできるか

ファイルのパーミッションを 444（読み取り専用）に設定すれば外部からの書き込みは防げるが、WordPress 本体やプラグインが正当な理由で .htaccess を更新する必要がある場合にエラーの原因となる。現実的な対策は、書き換えが発生する更新の前にバックアップを取り、更新後に diff を取って差分を確認する運用だ。

この記事のポイント

  • .htaccess への不適切な追記が更新後のサイトダウンの直接原因になりやすい
  • FTP で問題の行を削除するか .htaccess を一旦削除すれば即座に復旧できる
  • 削除後は管理画面のパーマリンク設定で必要最小限の .htaccess を再生成する
  • 原因プラグインを特定し無効化しないと再発するため忘れずに対処する
  • 更新前のバックアップとステージング検証が最も確実な予防策になる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WooCommerceの税金レポートが表示されない時の原因と直し方
2026年7月2日 0

WooCommerceの税金レポートが表示されない時の原因と直し方

WooCommerce の分析「税金」レポートが突然「表示するデータがありません」になった場合、履歴データの再インポートと分析キャッシュのクリアでほぼ解決する。この症状は注文データや収益レポートが正常でも、税金レポートだけが空白になるのが特徴だ。

なぜ税金レポートだけが空白になるのか

なぜ税金レポートだけが空白になるのか

WooCommerce の分析画面は、注文が発生するたびにバックグラウンドで集計テーブルを更新している。しかし、プラグインの更新やサーバーの一時的な負荷、データベースの不整合が重なると、この集計処理が途中で止まることがある。すると注文や収益といった主要レポートは残余データで表示される一方、国別の税金内訳のような細かい集計を必要とするレポートだけが「表示するデータがありません」と出る。

とくに手動で税率を設定している店舗では、税率コードと注文データの突合作業が必要になるため、集計の中断に対して脆弱だ。一時的な不具合であり、データそのものが消失したわけではない。

Before（エラー状態）
税金レポートに「表示するデータがありません」
注文・収益は正常に表示される
履歴データのインポートが「0件中2件」で止まっている
↓
After（正常状態）
国別の税額が一覧表示される
VAT 申告データをそのまま抽出できる
履歴データのインポートが全件完了している
■ エラー状態　■ 正常状態

履歴データを再インポートして集計を再開する

履歴データを再インポートして集計を再開する

最も確実な解決策は、分析用の履歴データを手動で再インポートすることだ。この操作は既存の注文や顧客データを消さず、集計テーブルだけを再構築する。

STEP 1 管理画面の「分析」→「設定」を開く
↓
STEP 2 ページ下部の「履歴データをインポート」セクションまでスクロール
↓
STEP 3 期間を「すべて」に設定し、「開始」ボタンを押す
↓
STEP 4 インポート完了後、税金レポートを再確認する

「スキップ」チェックボックスに注意する

履歴データのインポート画面には「以前にインポートした顧客と注文をスキップ」というチェックボックスがある。通常はチェックを入れたままでも問題ないが、インポートが途中で止まっている場合は、このチェックを外して全件を再処理するほうが確実だ。件数が多いと時間はかかるが、税金レポートの不整合を解消する近道になる。

インポートが「準備完了」で止まっている場合

履歴データのインポートが「準備完了」と表示され、クリックしても動かない場合は、WooCommerce のスケジュールアクションが滞留している可能性が高い。「WooCommerce」→「ステータス」→「スケジュールされたアクション」を開き、「保留中」のタスクがないか確認する。もし大量に溜まっているなら、WP Crontrol などのプラグインで手動実行するか、サーバーの WP-Cron が正しく動作しているかを調べる必要がある。

分析キャッシュをクリアして表示をリセットする

分析キャッシュをクリアして表示をリセットする

履歴データの再インポートだけで改善しない場合、分析画面が参照しているキャッシュが破損している。WooCommerce には専用のキャッシュクリア機能が用意されている。

  • 管理画面で「WooCommerce」→「ステータス」→「ツール」を開く
  • 「分析キャッシュをクリア」という項目を探す
  • 「実行」ボタンを押す
  • 画面を更新して税金レポートを再表示する

この操作は注文データや設定を一切変更しない。キャッシュを消すだけなので、安全に何度でも実行できる。実行後すぐに改善しない場合は、ブラウザのキャッシュも個別にクリアしてから再確認する。

ブラウザキャッシュとサーバーキャッシュも疑う

分析キャッシュをクリアしても改善しない場合、ブラウザが古い管理画面を表示し続けている可能性がある。シークレットウィンドウで管理画面を開き、同じ症状が出るかを試す。また、サーバー側で Redis や Memcached などのオブジェクトキャッシュを導入している場合は、そちらのキャッシュもクリアする。

データベースツールで直接修復する最終手段

データベースツールで直接修復する最終手段

ここまでの手順で直らない場合、WooCommerce の分析テーブルそのものに不整合が生じている。管理画面の「WooCommerce」→「ステータス」→「ツール」には、分析データベースの検証や修復を行うツールも含まれている。

  • 「分析データベースのテーブルを作成」を実行する（既存テーブルがある場合は何もしない）
  • 「分析データベースのテーブルを検証」を実行し、エラーがあれば修復を試みる

もしこれでも解決しない場合は、ステージング環境（本番とは別のテスト用サイト）に本番のデータを複製し、WooCommerce と WordPress を最新版に更新してから同じ手順を試す。更新によって分析テーブルの構造が修正され、問題が解消することがある。

よくある質問

注文データは消えていないか

消えていない。税金レポートが表示されないのは集計テーブルの不整合であり、実際の注文データは「WooCommerce」→「注文」から確認できる。VAT 申告に必要な情報も、個別の注文画面で確認可能だ。

WooCommerce を更新するのが怖いが、どうすればよいか

WP Staging などのプラグインでステージング環境を作り、そこで先に更新をテストするのが安全だ。問題なければ本番にも反映すればよい。更新を完全に避けるより、検証した上で適用するほうが長期的なリスクは小さい。

手動税率と自動税率のどちらが税金レポートに強いか

WooCommerce Tax 拡張（自動税率）を使うと、税率の管理と集計が一本化されるため、レポートの安定性は上がる。ただし手動税率でも正しく設定されていれば問題なく動作する。今回のように不具合が出たときは、手動税率のほうが原因特定に手間がかかることがある。

分析キャッシュをクリアすると他のレポートに影響するか

影響しない。キャッシュをクリアしても、次回アクセス時に再集計が走るだけだ。むしろ他のレポートでも古いキャッシュによる誤表示が起きていた場合、一括で改善する。

インポートがいつまでも終わらない時の対処法は

注文件数が数万件を超える大規模店舗の場合、インポートに時間がかかることがある。サーバーの PHP 実行時間制限（max_execution_time）が短すぎると途中で停止するため、サーバー管理者に延長を依頼するか、WP CLI を使ってコマンドラインから実行するのが確実だ。

この記事のポイント

  • 税金レポートだけが空白になるのは、集計テーブルの不整合が主な原因
  • 履歴データの再インポートと分析キャッシュのクリアが最も効果的な解決策
  • 「スキップ」チェックを外して全件インポートするとより確実
  • スケジュールアクションの滞留やサーバーキャッシュも併せて確認する
  • どうしても直らない場合はステージング環境で更新をテストする
佐々木 太陽
, , , ,
お悩み・トラブル解決
Advanced Ads 2.0.23 アップデート後の致命的エラーの直し方
2026年7月1日 0

Advanced Ads 2.0.23 アップデート後の致命的エラーの直し方

Advanced Ads 2.0.23 にアップデートした途端に「このサイトで重大なエラーが発生しました」と表示される問題は、Pro版のキャッシュバスティング機能が原因だ。管理画面にアクセスできなければ、FTP またはファイルマネージャーでプラグインを手動で一時無効化し、バージョンを 2.0.22 に戻せば即座に復旧する。

なぜ Advanced Ads 2.0.23 で致命的エラーが起こるのか

なぜ Advanced Ads 2.0.23 で致命的エラーが起こるのか

エラーの直接の原因は、Advanced Ads のコアプラグイン側にある abstract-group.php の 170 行目で、Pro版のキャッシュバスティングモジュールから渡された配列データの型を正しく取り扱えず、TypeError が発生している点だ。PHP 8.4 系の厳格な型チェックによって、以前のバージョンでは警告で済んでいた箇所が致命的エラーに変わった。

内部的には、get_ad_weights メソッドが想定するデータ構造と、キャッシュバスティングが上書きしたグループ情報との間で不整合が起きている。とくに広告グループの重み付け配列に対して isset や empty でアクセスしようとした際に、オフセットとして配列そのものを渡してしまう形になり、PHP が型エラーを投げている。

Before（エラー状態）
Advanced Ads 2.0.23 + Pro キャッシュバスティング有効
→ 「このサイトで重大なエラーが発生しました」
↓
After（解決後）
Advanced Ads 2.0.22 にロールバック
→ サイトが正常表示される
■ エラー状態　■ 修正後

上記のデモは、キャッシュバスティング機能が有効な状態でのエラー発生と、プラグインのダウングレードによる復旧の流れを表している。

管理画面にアクセスできない場合の緊急復旧手順

致命的エラーによって WordPress 管理画面にもログインできない状態では、ブラウザ上の操作だけで問題を解消できない。FTP クライアントか、レンタルサーバーのファイルマネージャーを使ってサーバー上のファイルを直接操作する。

FTP またはファイルマネージャーでプラグインを一時無効化する

サーバーに接続したら、/wp-content/plugins/ ディレクトリへ移動する。ここで advanced-ads フォルダと advanced-ads-pro フォルダの名前を変更する。フォルダ名の末尾に -disabled を付与すれば、WordPress はそのプラグインを認識しなくなり、エラーが止まる。

フォルダ名の変更例は次のとおりだ。
advanced-ads → advanced-ads-disabled
advanced-ads-pro → advanced-ads-pro-disabled

この状態でサイトのフロントエンドにアクセスすると、致命的エラーは出なくなる。ただし広告が一切表示されない点に注意する。次に管理画面へ入れるようになるので、続けてプラグインのバージョンロールバックを行う。

Advanced Ads をバージョン 2.0.22 に戻す

まず FTP でリネームした advanced-ads-disabled フォルダを元の advanced-ads に戻す。Pro版の advanced-ads-pro-disabled は、まだ無効化されたままにしておく。この操作で Advanced Ads の基本プラグインだけが有効化された状態になる。

管理画面にログインし、「Advanced Ads」→「ツール」→「バージョン管理」へ進む。ここでバージョン 2.0.22 を選択し、ロールバックを実行する。ロールバック完了後、Pro版のフォルダ名を元に戻して有効化すれば、2.0.22 の組み合わせで通常運用に復旧できる。

STEP 1 FTP で advanced-ads フォルダと advanced-ads-pro フォルダをリネーム（末尾に -disabled）
↓
STEP 2 advanced-ads フォルダのみ元の名前に戻す（Pro版は無効のまま）
↓
STEP 3 管理画面「ツール」→「バージョン管理」で 2.0.22 にロールバック
↓
STEP 4 Pro版のフォルダ名も元に戻し、有効化して復旧完了

この一連の手順で、管理画面に入れない状態からでも確実にサイトを復旧できる。

キャッシュバスティングを無効化して一時しのぎする方法

キャッシュバスティングを無効化して一時しのぎする方法

管理画面にアクセスできる状態であれば、Pro版のキャッシュバスティング機能をオフにするだけで致命的エラーを回避できる。Advanced Ads Pro の設定画面を開き、「キャッシュバスティング」セクションのトグルを無効化する。これにより cache-busting.class.php の処理が走らなくなり、エラーの発生箇所が呼び出されない。

無効化後にサイトのフロントエンドを再読み込みして、エラーが消えたことを確認する。この方法はあくまで応急処置であり、根本的な修正が公式から提供されるまではキャッシュバスティング機能を使えない点に留意する。広告のインプレッション計測や表示の最適化に影響が出るため、修正版のリリースを待つか、前述のロールバックを適用するほうが望ましい。

PHP 8.4 環境で注意すべきエラーの傾向

PHP 8.4 では、配列オフセットに対する型の取り扱いがさらに厳格化された。今回のエラーも、Cannot access offset of type array in isset or empty というメッセージにあるとおり、配列を別の配列のキーとして使おうとしたコードがエラーになっている。PHP 7.x 系では E_WARNING で済んでいたコードが、8.x 系では TypeError の致命的エラーに格上げされるケースが増えている。

TagDiv Newspaper のような複合的なテーマとビルダー系プラグインを併用している環境では、テーマが内部的にウィジェットブロックを動的サイドバーとしてレンダリングし、その中で Advanced Ads の広告配置が呼び出される。この呼び出し階層が深いほど、わずかな型の不整合がスタックトレース全体を巻き込む致命的エラーに発展しやすい。エラーログのスタックトレースを読むときは、一番上の発生行だけでなく、そのひとつ下の呼び出し元との関係に着目すると原因特定が早まる。

よくある質問

2.0.23 にアップデートしたあとサイト全体が真っ白になるのは同じ原因か

同じ可能性が高い。とくに Pro版のキャッシュバスティングを有効にしている場合、このエラーが発生する。画面が真っ白になるのは PHP の致命的エラーによって WordPress の表示処理が途中で停止しているためだ。サーバーのエラーログを確認すると、今回と同じ TypeError が記録されているはずだ。

ロールバック機能が管理画面から使えないときはどうすればよいか

FTP でプラグインフォルダをリネームして一時無効化し、コアプラグインだけを有効にして管理画面にアクセスできる状態を作る。そのうえで「バージョン管理」からロールバックを実行する。どうしても管理画面に入れない場合は、WordPress 公式プラグインディレクトリから 2.0.22 の ZIP を手動でダウンロードし、FTP で上書きアップロードする方法でもダウングレードできる。

Pro版のキャッシュバスティングを無効にすると広告収益にどの程度影響があるか

キャッシュバスティングは広告の表示を毎回動的に変えることでキャッシュによる同一広告の連続表示を防ぐ仕組みだ。無効化すると、ページキャッシュが効いた状態では同じ広告が繰り返し表示される可能性が高まり、インプレッションの多様性が下がる。短期的な暫定対処としては許容できるが、修正版リリース後は必ず再有効化するほうがよい。

今回のエラーは Advanced Ads 無料版だけでも発生するのか

エラーの起点はコアプラグインの abstract-group.php だが、実際に問題を引き起こしているのは Pro版のキャッシュバスティングモジュールだ。無料版のみの利用では通常発生しない。ただし同じ PHP 8.4 環境で他のアドオンを使っている場合は、類似の型エラーに注意が必要だ。

この記事のポイント

  • Advanced Ads 2.0.23 + Pro キャッシュバスティングの組み合わせで発生する
  • 管理画面にアクセスできないときは FTP でプラグインフォルダをリネームして無効化する
  • コアプラグインを 2.0.22 にロールバックすれば復旧できる
  • キャッシュバスティングの無効化は暫定対処であり根本解決にはならない
  • PHP 8.4 の厳格な型チェックがエラーの引き金になっている
佐々木 太陽
, , , ,
お悩み・トラブル解決
ブロックエディタが点滅してクラッシュする時の原因と直し方
2026年7月1日 0

ブロックエディタが点滅してクラッシュする時の原因と直し方

ブロックエディタの画面が激しく点滅し、操作不能になったりエラーでクラッシュする場合、原因の大半はブラウザ拡張機能やキャッシュ、プラグイン競合による JavaScript の競合だ。セーフモードでの編集とブラウザのトラブルシューティングを順に行えば、大半のケースはすぐに編集を再開できる。

なぜブロックエディタが点滅してクラッシュするのか

なぜブロックエディタが点滅してクラッシュするのか

今回の事象の中心にあるのは getComputedStyle@[native code] から始まる JavaScript エラーだ。ブロックエディタは React ベースの画面であり、DOM 要素のスタイルを動的に計算する処理を多用している。この getComputedStyle 呼び出しが失敗すると、React の内部状態が破綻し、画面全体の再描画が無限ループに陥って「点滅」が発生する。

エラーが起きるトリガーは主に以下の3つだ。

  • AdBlock や Grammarly、翻訳ツールなど、ページの DOM 構造を書き換えるブラウザ拡張機能がエディタの動作と衝突している
  • プラグインやテーマが独自に読み込む古い JavaScript ライブラリが、WordPress 本体のバンドル済み React と二重読み込みになっている
  • ブラウザやサーバーに残ったキャッシュが、更新後のスクリプトと旧バージョンのスクリプトを混在させている

点滅はエディタが「レンダリング → クラッシュ → 再マウント → レンダリング」を一瞬で繰り返すために起こる。ユーザーからは、画面全体がチカチカしてボタンやブロックをクリックできない、またはクリックした瞬間に「このブロックでエラーが発生しました」と表示されて操作不能になる状態として見える。

Before（点滅発生中）

エディタ画面全体が高速で明滅し、ブロックを選択できない。クリックすると「このサイトで重大なエラーが発生しました」と表示される。

↓
After（正常動作）

エディタが安定し、ブロックの選択・編集・移動が問題なく行える。画面のちらつきは完全に消えている。

■ エラー状態　■ 修正後

ビジュアルエディタの点滅を止めて編集を再開する手順

ビジュアルエディタの点滅を止めて編集を再開する手順

原因を一つずつ潰していくのが確実だ。以下の手順は、影響範囲が小さくすぐ試せるものから並べている。手順1〜3で解決しなければ、手順4以降の WordPress 内部の切り分けに進む。

STEP 1 ブラウザ拡張機能をすべて無効にする
↓
STEP 2 シークレットウィンドウで動作確認する
↓
STEP 3 ブラウザキャッシュとサーバーキャッシュを削除する
↓
STEP 4 プラグインの競合を切り分ける（セーフモード）
↓
STEP 5 テーマを標準テーマに切り替える

ブラウザ拡張機能をすべて無効にして試す

最も短時間で試せて、かつ最も解決率が高い対処だ。ブロックエディタは高度な JavaScript で動作しており、広告ブロッカーや文法チェッカーなどの拡張機能が DOM に手を加えると、React の仮想 DOM と実際の DOM の整合性が崩れて getComputedStyle エラーが発生する。特に AdBlock 系、Grammarly、翻訳アドオン、ユーザースクリプト（Tampermonkey 等）が競合しやすい。

Chrome の場合、アドレスバー右の拡張機能アイコンから「拡張機能を管理」を開き、すべての拡張機能を一度オフにする。その状態でエディタを開き直し、点滅が収まるかを確認する。収まった場合は、拡張機能をひとつずつオンにして犯人を特定する。

シークレットウィンドウかゲストモードで動作を確認する

拡張機能を一括で無効化できるもっと手軽な方法が、シークレットウィンドウ（Chrome は Ctrl+Shift+N、Firefox は Ctrl+Shift+P）だ。シークレットモードでは拡張機能がデフォルトで無効になるため、ここで問題が再現しなければ、原因はほぼ確実に拡張機能かブラウザのキャッシュにある。

別のブラウザ（普段 Chrome を使っているなら Firefox や Edge）をインストールし、拡張機能を何も入れていない状態でエディタにアクセスするのも有効な切り分けになる。複数ブラウザで同じエラーが出る場合は、拡張機能ではなく WordPress 側の問題の可能性が高い。

ブラウザキャッシュとサーバーキャッシュを削除する

WordPress のバージョンアップやプラグイン更新の直後に点滅が始まった場合、ブラウザに古い JavaScript ファイルがキャッシュされている可能性が高い。キャッシュされた古いスクリプトと、サーバー上の新しいスクリプトが混ざると、関数の呼び出し不一致で React がクラッシュする。

  • ブラウザのキャッシュと Cookie を全期間で削除する（Chrome 設定→プライバシーとセキュリティ→閲覧履歴データの削除→「キャッシュされた画像とファイル」にチェック→全期間）
  • サーバー側で W3 Total Cache や WP Super Cache などのキャッシュプラグインを使っている場合は、管理画面から「全キャッシュを削除」する
  • Cloudflare などの CDN を利用している場合は、ダッシュボードでキャッシュをパージする
  • 一部のレンタルサーバーで提供される独自キャッシュ機能もオフにする

セーフモードでプラグインの競合を切り分ける

ここまでの手順で解決しない場合、WordPress 内部で JavaScript の競合が起きている。特定のプラグインやテーマが、WordPress 本体がバンドルしている React とは別バージョンの React を読み込んでいたり、jQuery の古いバージョンや別の JavaScript ライブラリを強制的に読み込んでいるケースが多い。

全プラグインを一度に無効化すると管理画面まで影響が出る操作もあるため、WordPress のトラブルシューティングモード（Health Check & Troubleshooting プラグイン）を使うのが安全だ。このプラグインをインストールして有効化すると、管理画面のツールバーに「トラブルシューティングモード」ボタンが現れる。これを押すと、自分だけに影響するセッションで、すべてのプラグインが無効化され標準テーマに切り替わった状態でエディタをテストできる。他の訪問者には通常通りのサイトが表示される。

トラブルシューティングモードでエディタが正常に動けば、原因はプラグインかテーマにある。次にプラグインをひとつずつ有効化していき、どのプラグインを有効にした瞬間に点滅が再発するかを特定する。Health Check プラグインが使えない環境では、本番に近いテスト環境（ステージング）を作って同じ手順を行う。

テーマを標準テーマに切り替える

有料テーマやカスタマイズの多いテーマは、独自のページビルダーやアニメーションライブラリを読み込んでいることがある。プラグインをすべて無効化しても直らない場合、テーマが原因の可能性が高い。一時的に Twenty Twenty-Five などの標準テーマに切り替え、エディタの点滅が止まるか確認する。

テーマを切り替えるとウィジェットやメニュー構成が変わる可能性があるため、先にサイトのバックアップを取ることを推奨する。点滅がテーマに起因していた場合は、テーマの開発元に getComputedStyle エラーの情報を添えて問い合わせるか、子テーマで競合するスクリプトの読み込みを停止させる。

点滅エラーの詳細を開発者ツールで特定する方法

点滅エラーの詳細を開発者ツールで特定する方法

どうしても原因がわからない場合や、特定のプラグインをどうしても無効化できない事情がある場合は、ブラウザの開発者ツールで詳細なエラー情報を収集する。

  • Chrome で F12 キー（開発者ツール）を開き、「Console」タブを確認する
  • 赤いエラーメッセージの右に表示される「ソース」のリンクをクリックすると、エラーが発生している JavaScript ファイルと行番号が表示される
  • ファイルパスに /wp-content/plugins/プラグイン名/ や /wp-content/themes/テーマ名/ が含まれていれば、そのプラグインまたはテーマがエラーの発生源だ
  • 「Network」タブで、404 エラー（Not Found）になっている .js ファイルがないかも確認する。ファイルの読み込みに失敗していると、依存する React の処理が途中で止まりクラッシュする

これらの情報を、原因と思われるプラグインやテーマのサポートフォーラムに提出すれば、開発者側での修正も期待できる。エラーメッセージを丸ごとコピーして伝えるとスムーズだ。

それでも直らない時の一時的な回避策

それでも直らない時の一時的な回避策

納期が迫っていてどうしても編集を進めなければならない場合、以下の回避策で作業を継続できる。

コードエディタで直接編集する

ビジュアルエディタが使えなくても、ブロックエディタの右上の三点メニューから「コードエディタ」に切り替えれば、HTML ベースでブロックの内容を編集できる。ビジュアルのプレビューは見られないが、少なくとも点滅に悩まされずにテキストの修正やブロック構造の調整は可能だ。

クラシックエディタプラグインを一時的に有効化する

Classic Editor プラグインをインストールして有効化すると、旧来のクラシックエディタで記事を編集できる。点滅の原因がブロックエディタ固有の React 処理にある場合、クラシックエディタでは問題が発生しないことが多い。作業が完了したらプラグインを無効化して元のブロックエディタに戻し、根本原因の調査を続ける。

よくある質問

同じブラウザで他の WordPress サイトは正常に動く。自サイトだけ点滅するのはなぜか

自サイトのプラグインまたはテーマが読み込んでいる JavaScript が原因だ。他の WordPress サイトが正常なのは、そのサイトでは問題のスクリプトが読み込まれていないからだ。「セーフモードでプラグインの競合を切り分ける」手順で原因のプラグインやテーマを特定する。

getComputedStyle エラーは WordPress のバージョンを戻せば直るか

バージョンを戻すことで一時的に直るケースはあるが、セキュリティ更新が適用されなくなるため推奨しない。WordPress 本体には問題がなく、特定のプラグインやテーマが新しい WordPress のバンドル済み React に対応していないことがほとんどだ。プラグインやテーマの更新を待つか、開発元に報告して対応を依頼する方が安全だ。

ブラウザのハードウェアアクセラレーションは関係あるか

ごくまれに、GPU レンダリングの不具合が画面の点滅を引き起こすことがある。Chrome の設定→システム→「ハードウェア アクセラレーションが使用可能な場合は使用する」をオフにして再起動すると直るケースも報告されている。ただし、getComputedStyle エラーを伴う場合は JavaScript の競合が原因の可能性が高い。

全プラグイン無効化と標準テーマでも直らない場合はどうするか

ここまで試しても直らない場合は、WordPress 本体のファイル破損やサーバー側の特異な設定（mod_security など）が影響している可能性がある。WordPress の再インストール（「ダッシュボード→更新」から「再インストール」を実行）を試す。それでもダメならサーバーのエラーログを確認し、PHP のメモリ制限や実行時間制限が不足していないかも調べる。

エラーのスタックトレースにプラグイン名が出ていない時はどう調べるか

エラーが react-dom.min.js や components.min.js で発生している場合、直接の原因箇所がミニファイされた WordPress 本体のファイルになっている。この場合は「Network」タブで、読み込まれているすべての .js ファイルを確認する。プラグインが読み込むスクリプトの数が多い順に疑い、ひとつずつ無効化して切り分ける。

この記事のポイント

  • ブロックエディタの点滅と getComputedStyle エラーの主因はブラウザ拡張機能と JavaScript 競合
  • シークレットウィンドウと拡張機能無効化で素早く原因を絞り込める
  • Health Check プラグインのトラブルシューティングモードで安全にプラグインを切り分ける
  • どうしても急ぐ場合はコードエディタや Classic Editor プラグインで一時的に編集を続行できる
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Bricks Builderのカスタムコードで同意管理プラグインが効かない時の直し方
2026年7月1日 0

Bricks Builderのカスタムコードで同意管理プラグインが効かない時の直し方

Kanslieri Cookie ConsentでGoogle AnalyticsやMicrosoft Clarityを自動ブロックする設定にしているのに、シークレットウィンドウで計測タグが動いてしまう原因は、Bricks Builderのカスタムコード欄に直書きしたスクリプトを、同意管理プラグインが認識できない仕組みにある。スクリプトを手動ブロック用の属性に書き換えるか、WordPress標準のエンキュー方式に差し替えれば、同意前の計測を確実に止められる。

なぜBricksカスタムコードの計測タグがブロックされないのか

なぜBricksカスタムコードの計測タグがブロックされないのか

Kanslieri Cookie Consentをはじめ、多くのCookie同意管理プラグインは、WordPressの標準機能であるwp_enqueue_scriptで読み込まれたスクリプトをフックして制御する設計になっている。スクリプトのハンドル名を解析し、同意が得られるまで実行を自動的に保留する仕組みだ。

一方、Bricks Builderの「Settings → Custom Code → Header Scripts」に貼り付けたコードは、テーマがwp_headアクションを通じてページのソースにそのまま埋め込む。プラグイン側からは「PHPで読み込まれたスクリプト」として認識されず、単なるインラインHTML扱いになる。その結果、管理画面のScript Blockingページに「Google Analyticsは自動ブロック対象」と表示されていても、実際にはブロックが効かない。

Google Analyticsの_gaや_gidといったCookieがシークレットウィンドウで生成され、/g/collectへのリクエストが送信され、page_viewやscrollイベントが記録されるのはこのためだ。Microsoft Clarityも同様に、カスタムコード欄経由では自動ブロックの対象外になる。

同意前のトラッキングを防ぐ具体的な修正手順

同意前のトラッキングを防ぐ具体的な修正手順

Kanslieri Cookie Consentの自動ブロックが効かない場合でも、手動ブロックの仕組みを利用すれば計測を止められる。修正方法は大きく2つある。すでにカスタムコードを使っているなら、スクリプトタグに手動ブロック用の属性を追加するのが最も手早い。

手動ブロック用のtype属性に書き換える方法

Kanslieri Cookie Consentは、スクリプトタグのtype属性をtext/plainに書き換えることで、同意があるまでスクリプトの実行を止める仕組みを持っている。同意が得られた時点で、プラグインがtypeをtext/javascriptに戻して実行する。Bricksのカスタムコード欄に貼ってあるGoogle AnalyticsとMicrosoft Clarityのコードを、次のように修正する。

修正前
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>
↓
修正後
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" type="text/plain" data-cookiecategory="analytics"></script>
<script type="text/plain" data-cookiecategory="analytics">
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>
■ 修正前（自動ブロック非対応）　■ 修正後（手動ブロック対応）

ポイントは各<script>タグにtype="text/plain"とdata-cookiecategory="analytics"を追加することだ。data-cookiecategoryの値は、Kanslieri Cookie Consentの設定で該当スクリプトを割り当てたいカテゴリ名と一致させる。Google Analyticsならanalytics、Microsoft Clarityも同じ分析カテゴリで構わない。複数カテゴリにまたがる場合はdata-cookiecategory="analytics, marketing"のようにカンマ区切りで指定できる。

WordPressのエンキュー方式に切り替える方法

より根本的な解決策として、カスタムコード欄ではなく子テーマのfunctions.phpからwp_enqueue_scriptでスクリプトを読み込む方法もある。この方法なら、Kanslieri Cookie Consentの自動ブロック機能が確実に働く。

function my_google_analytics_script() {
    wp_enqueue_script(
        'google-analytics',
        'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX',
        array(),
        null,
        false
    );
    wp_add_inline_script(
        'google-analytics',
        "window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());
        gtag('config', 'G-XXXXXXXXXX');"
    );
}
add_action('wp_enqueue_scripts', 'my_google_analytics_script');

このコードを子テーマのfunctions.phpに追加したら、Bricksのカスタムコード欄から該当のコードを削除する。Kanslieri Cookie ConsentのScript BlockingページでGoogle Analyticsが認識されるようになり、同意前のトラッキングが自動的にブロックされる。

手動ブロックが正しく動くか確認する手順

手動ブロックが正しく動くか確認する手順
STEP 1 ブラウザのシークレットウィンドウを開く（Cookieが初期化された状態）
↓
STEP 2 サイトにアクセスし、Cookie同意バナーが表示されたら同意せずに待つ
↓
STEP 3 Chrome DevToolsの「Application → Cookies」で_gaや_gidが生成されていないことを確認
↓
STEP 4 「Network」タブでgoogle-analytics.comやclarity.msへのリクエストが発生していないことを確認

DevToolsのNetworkタブでは、フィルタにcollectやclarityと入力すると該当リクエストを素早く見つけられる。同意前にこれらのリクエストが記録されていなければ、ブロックは正しく機能している。その状態でCookieバナーの「同意する」をクリックし、直後にリクエストが走り始めれば、同意後の計測も正常に動作していることになる。

Bricks Builderのキャッシュが有効になっている場合は、修正後にかならずキャッシュをクリアする。Bricksの管理画面から「Bricks → Settings → Performance」でキャッシュを削除したうえで、サーバー側のキャッシュやCDNがある場合も同時にパージする。キャッシュが残っていると修正前のスクリプトが配信され続けてしまうため、確認作業の前に忘れずに行う必要がある。

よくある質問

他のページビルダー（ElementorやDivi）でも同じ問題は起きるのか

起きる可能性が高い。Elementorのカスタムコード機能やDiviの統合設定から追加したスクリプトも、テーマ側で直接HTMLに出力されるため、同意管理プラグインの自動ブロック対象外になりやすい。同じ手動ブロックの手法が適用できる。ただし、Elementorの場合はwp_enqueue_script方式に切り替える方が推奨される場面が多い。カスタムコード欄にスクリプトを置く運用は、同意管理の観点からは避けるのが無難だ。

Kanslieri Cookie Consentの自動ブロックが効かないスクリプトを見分ける方法はあるか

管理画面の「Script Blocking」ページに一覧表示されるスクリプトは、プラグインが自動検出できたものだけだ。ここに表示されていないGoogle AnalyticsやClarityのスクリプトは自動ブロック対象外と判断してよい。また、シークレットウィンドウで実際にCookieが生成されるか、DevToolsでネットワークリクエストが発生するかを確認すれば、ブロックの可否を実動作で検証できる。

手動ブロックに書き換えたスクリプトが、同意後も動かない場合はどうするのか

Kanslieri Cookie Consentの設定で、data-cookiecategoryに指定したカテゴリが有効になっているか確認する。「Cookie Settings」画面で該当カテゴリのトグルがオンになっていること、同意バナーでユーザーがそのカテゴリを許可できる選択肢が表示されていることをチェックする。カテゴリ名にタイプミスがあると、プラグインがスクリプトをどのカテゴリに紐づけてよいか判断できず、同意後も実行されない。

Bricksのカスタムコードは使わず、Google Site KitプラグインでGA4を入れるとどうなるか

Site Kitはwp_enqueue_scriptを使ってGoogle Analyticsタグを読み込むため、Kanslieri Cookie Consentの自動ブロック機能が正常に働く。手動ブロックの書き換えは不要になる。すでにカスタムコードでGA4を入れている場合は、そのコードを削除してSite Kitに移行するだけで、同意管理の課題が解決する。Clarityも公式プラグインを使えば同様だ。

この記事のポイント

  • Bricks Builderのカスタムコード欄は同意管理プラグインの自動ブロック対象外になる
  • スクリプトタグにtype="text/plain"とdata-cookiecategoryを追加して手動ブロックに対応させる
  • wp_enqueue_scriptで読み込めば自動ブロックが有効になり修正不要
  • 修正後はシークレットウィンドウとDevToolsでCookieとリクエストを検証する
  • キャッシュクリアを忘れると修正が反映されない
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WooCommerce HPOSが48時間で100万件以上のアクションスケジューラ完了ジョブを生成した原因と対処法
2026年6月30日 0

WooCommerce HPOSが48時間で100万件以上のアクションスケジューラ完了ジョブを生成した原因と対処法

WooCommerceサイトでデータベースサイズが突然急増し、wp_actionscheduler_actionsテーブルに数百万件もの完了済みジョブが蓄積している場合、HPOSデータ同期バッチプロセスが無限ループを起こしている可能性が極めて高い。ここでは症状の見分け方から原因の特定、停止、クリーンアップまで、具体的な手順をまとめる。

HPOS関連のデータベース肥大化が疑われる症状

HPOS関連のデータベース肥大化が疑われる症状

以下のような兆候が複数同時に現れたら、Action Schedulerの暴走を疑ってよい。

  • データベース容量が短時間で急激に増加する（数GB単位）
  • PHPエラーログのファイルサイズが異常に大きくなる
  • データベースのロックエラーやデッドロックが頻発する
  • 管理画面やフロントエンドで「INSERT command denied」などのエラーが出る
  • サーバーのバックグラウンドプロセスがほぼ常時稼働し続ける
  • 注文件数が数百件なのにAction Schedulerテーブルだけが肥大化している

これらの症状は、単体では他の原因もあり得るが、データベース内の完了ジョブが異常に増えている点が最大の特徴だ。

正常時（Before）
wp_actionscheduler_actions テーブルに数百件程度のジョブが存在する
↓
暴走時（After）
100万件以上の完了ジョブが蓄積し、データベース全体が膨張する
■ 正常時　 ■ 暴走時

Action Schedulerが暴走していないか確認する方法

Action Schedulerが暴走していないか確認する方法

まずはデータベースを直接調べ、どのジョブが何件蓄積しているかを確かめる。WP-CLIが使えるならコマンドラインから、そうでなければphpMyAdminやAdminerで以下のクエリを実行する。

STEP 1 Action Schedulerテーブルの完了ジョブ数を集計する
↓
STEP 2 フック名「wc_run_batch_process」でフィルタし、引数を確認する
↓
STEP 3 注文件数とジョブ件数を比較し、異常な乖離を確認する
↓
STEP 4 実行中のジョブが1件完了するたびに次が即座にスケジュールされるループを特定する

完了ジョブの数とフック名を調べる

データベースに直接問い合わせる場合、以下のSQLで完了状態のジョブをフック名別に集計できる。

SELECT hook, COUNT(*) AS cnt
FROM wp_actionscheduler_actions
WHERE status = 'complete'
GROUP BY hook
ORDER BY cnt DESC
LIMIT 10;

ここで wc_run_batch_process の件数が数十万〜数百万件と突出していれば、疑いは濃厚だ。

引数（args）から発行元を特定する

次に、そのフックの引数を見る。例えば以下のクエリで先頭の数件を取得する。

SELECT action_id, args, scheduled_date_gmt
FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process'
AND status = 'complete'
ORDER BY action_id DESC
LIMIT 5;

引数フィールドにはシリアライズされたデータが入っている。その中に Automattic\WooCommerce\Internal\DataStores\Orders\DataSynchronizer という文字列が含まれていれば、HPOSのデータ同期機構がバッチを発行している証拠だ。

注文件数との比較で異常を確信する

管理画面のWooCommerce → 注文で表示される注文の総数は、データベースの wp_posts（またはHPOS有効時は wp_wc_orders）で確認できる。注文が600件しかないのに、同期バッチの完了ジョブが100万件もあるなら、明らかにループが発生している。

動作中のループをリアルタイムで観察する

WP-CLIが利用可能なら、以下のコマンドでペンディング状態のジョブを監視する。

wp action-scheduler list --hook=wc_run_batch_process --status=pending

定期的に実行すると、常に1件だけ存在し、それが完了するとすぐに新たなペンディングが生まれるパターンが観測できるはずだ。これはキューが滞留しているのではなく、バッチ自身が次をスケジュールし続ける無限ループであることを示す。

なぜHPOS DataSynchronizerが無限ループを起こすのか

なぜHPOS DataSynchronizerが無限ループを起こすのか

HPOS（High-Performance Order Storage）を有効にすると、WooCommerceは注文データを従来の wp_posts テーブルから専用テーブルへ移行する。この移行やデータの同期を担うのが DataSynchronizer であり、バックグラウンドでバッチ処理を走らせる。

通常は同期が完了すればバッチは停止するが、何らかの設定不整合やエラーにより「同期が完了したと見なされず、次のバッチが即座に予約される」状態に陥ることがある。具体的には、各バッチが「保留中 → 完了 → 次バッチ予約」というサイクルを際限なく繰り返す。注文数が少なくても、このループによってAction Schedulerのテーブルだけが急激に肥大化し、データベース全体を圧迫する。

保留中（Pending）
↓
完了（Complete）
↓
次バッチ予約（Schedule Next）
↓
再び 保留中（Pending）へ
↑ 無限にループする

このループが起きているかどうかは、データベースを直接見るまで気づきにくい。キャッシュやRedis、WP Rocketなどを最初に疑いがちだが、真因はAction Schedulerの中にある。

データベースの安静化とクリーンアップの手順

データベースの安静化とクリーンアップの手順

原因がHPOSの同期バッチループと判明したら、ループを止め、完了ジョブを削除し、再発を防ぐ。以下の手順を順に実行する。

STEP 1 WP-CLIで同期状態を確認し、必要に応じて同期をリセットする
↓
STEP 2 Action Schedulerの完了ジョブを安全に一括削除する
↓
STEP 3 データベーステーブルを最適化し、容量を解放する
↓
STEP 4 再発防止のためにHPOS設定を見直す

同期状態のリセット

まず、現在のHPOS同期状況を確認する。WP-CLIで次のコマンドを実行する。

wp wc hpos sync status

ここで「status: in-progress」や「pending」が表示される場合、同期が完了しておらず、バッチが動き続けている可能性がある。強制的にリセットし、不要な同期を停止するには以下を実行する。

wp wc hpos sync reset

リセット後、再度ステータスを確認し「idle」や「complete」になっていれば、新たなバッチはスケジュールされなくなる。

完了ジョブの一括削除

100万件単位の完了ジョブを削除するには、Action Schedulerが提供するWP-CLIコマンドを使うのが安全で高速だ。以下のコマンドで、完了状態のジョブをすべて削除できる。

wp action-scheduler clean --status=complete

特定のフックのみを削除したい場合は、プレーンなSQLで一度に削除してもよいが、必ず事前にデータベース全体のバックアップを取ること。

DELETE FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process' AND status = 'complete';

さらに、関連するログテーブル（wp_actionscheduler_logs）の不要レコードも合わせて削除すると、ディスク容量を大きく回復できる。ただし、こちらは慎重に扱う必要があるため、まずは完了ジョブの削除だけでも効果は大きい。

テーブル最適化で容量を解放

大量のレコードを削除した後は、データベースが断片化し、実際の容量が解放されないことがある。phpMyAdminなどから該当テーブルに対して「最適化（OPTIMIZE TABLE）」を実行するか、以下のSQLを流す。

OPTIMIZE TABLE wp_actionscheduler_actions;
OPTIMIZE TABLE wp_actionscheduler_logs;

これにより、削除した領域がOSに返却され、データベース全体のサイズが縮小する。

再発防止とHPOS設定の見直し

ループが再発しないように、WooCommerceのHPOS設定を確認する。管理画面の WooCommerce → 設定 → 詳細設定 → 機能 から「High-performance order storage（高性能注文ストレージ）」が有効になっているか、そして「互換モードを有効にする」や「データ同期を有効にする」オプションがどのようになっているかをチェックする。

既に全注文がHPOSテーブルに完全移行済みで、互換モードが不要なら、これらの同期オプションを無効化することで、バックグラウンドのバッチ処理そのものを止められる。ただし、テーマやプラグインが古い注文データ参照方法を使っている場合は注意が必要だ。

また、WP-CLIのcronを定期的に監視し、Action Schedulerのジョブ数が異常増加していないかをチェックする仕組みをサーバー監視に組み込むと早期発見につながる。

よくある質問

HPOSが有効かどうかはどこで確認できるか

管理画面の「WooCommerce → 設定 → 詳細設定 → 機能」に移動し、「注文データストレージ」の項目で「High-performance order storage」が選択されていれば有効だ。WP-CLIでは wp wc hpos status で確認できる。

完了ジョブを削除してもサイト動作に影響はないか

Action Schedulerの完了ジョブは過去の処理履歴であり、削除しても現在予約されているジョブや進行中の処理には影響しない。ただし、監査やデバッグ目的で残したい場合は、削除前にバックアップを取ることを強く推奨する。

WP-CLIが使えないレンタルサーバーではどうすればよいか

phpMyAdminなどのデータベース管理ツールから直接SQLで削除できる。プラグイン「WP Crontrol」などを利用すれば、Action Schedulerの一覧を管理画面で確認し、フックごとに手動で削除することも可能だが、件数が多い場合はSQLのほうが現実的だ。

同期をリセットしてもループが再発するのはなぜか

根本原因が解消されていないと再発する。たとえば、同期オプションが有効なまま残っていたり、カスタムコードがバッチをトリガーし続けているケースがある。同期の完全停止を試み、プラグインの干渉も疑いながら一つずつ切り分ける必要がある。

この記事のポイント

  • データベースの急激な肥大化とAction Schedulerの完了ジョブ数に注目する
  • フック名「wc_run_batch_process」と引数からHPOSの同期バッチループを特定する
  • WP-CLIで同期状態をリセットし、完了ジョブを一括削除してテーブルを最適化する
  • HPOSの同期設定を見直し、不要なバッチ処理を完全に止めて再発を防ぐ
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WordPressで重大なエラーが発生した時の原因と復旧手順
2026年6月29日 0

WordPressで重大なエラーが発生した時の原因と復旧手順

WordPressで「このサイトで重大なエラーが発生しました」と表示され管理画面にもログインできない場合、まず試すべきはサーバーのエラーログ確認と、FTPを使った原因プラグインの強制停止だ。管理用メールが届かなくても、手動の切り分け作業でサイトを復旧できる。

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

あのメッセージが表示されるとき、WordPress内部ではPHPの「致命的エラー（Fatal Error）」が起きている。プログラムの処理がそこで停止してしまい、画面表示が途中で終わる。テーマやプラグインの更新失敗、PHPバージョンの非互換、サーバーのメモリ上限超過、あるいはコアファイルの破損など原因は多岐にわたる。

WordPress 5.2以降、致命的エラーが起きると管理画面へのログインも止められる設計になった。これは「壊れかけのサイトを操作し続けて被害を拡大させない」ための安全措置だ。通常なら「サイトに技術的な問題が発生しました。復旧手順のリンクを管理者メールアドレスに送信しました」という案内とともに「回復モード」用のリンクがメールで届く仕組みになっている。

ただ、このメールが届かないケースは実際には非常に多い。メールサーバーの設定不備や、そもそも通知を受け取る管理者アドレスが存在しないサイトもある。つまり「メールが届かない＝打つ手がない」わけではない。手動での復旧手順を覚えておけば、すぐに対処できる。

管理用メールが届かなくてもエラーの原因を特定する手順

管理用メールが届かなくてもエラーの原因を特定する手順

原因を特定できないまま闇雲に操作すると、状況をさらに悪化させかねない。まずは「一体どのファイルの何行目で止まっているのか」という技術情報を掴む必要がある。

サーバーのエラーログを最優先で確認する

「重大なエラー」の原因は、ほとんどの場合サーバー上の「エラーログ」に明瞭に記録されている。エックスサーバー、ConoHa WING、さくらのレンタルサーバなど国内の主要レンタルサーバーなら、コントロールパネル内の「エラーログ」や「アクセスログ」といったメニューから確認可能だ。cPanel系であれば「Errors」アイコンから辿れる。

  • ログには「PHP Fatal error」という文言と、問題が起きたファイルのパス（/home/…/plugins/xxxx/xxxx.php on line 123 など）が刻まれている
  • ここでプラグイン名が明記されていれば原因はほぼ特定できたも同然だ
  • もしログの見方が分からない場合は、「エラーログをダウンロードして全文をテキストエディタで開き、Fatal で検索する」とよい

wp-config.php で WP_DEBUG を有効にしてエラーを画面表示させる

エラーログがすぐに見つからない・もしくはより直感的に原因を掴みたい場合は、WordPressのデバッグモードを有効にする。FTPソフト（FileZillaなど）か、サーバーのファイルマネージャーで WordPress インストールディレクトリ直下の wp-config.php ファイルに以下の行を追加する。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

この設定でエラー情報は /wp-content/debug.log に書き出される。ブラウザ上でサイトを再読込し、その後このログファイルを開けば、先ほどと同じように原因ファイルを特定できる。WP_DEBUG_DISPLAY を true にすると画面に直接エラーが表示されるが、一般の訪問者にも見えてしまうので本番環境での使用は推奨しない。問題を解決したあとは false に戻すか、行ごと削除すること。

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

原因が特定のプラグインやテーマだと判明したら、管理画面に戻らなくても手動で無効化できる。管理画面を経由せず、ファイル名の変更で読み込ませないようにする手法だ。これでサイトの表示や管理画面へのアクセスが復活する。

STEP 1 サーバーのエラーログを確認する
↓
STEP 2 wp-config.php に WP_DEBUG 設定を追記する
↓
STEP 3 エラーメッセージから原因プラグインを特定する
↓
STEP 4 該当プラグインをリネームして無効化する

原因プラグインのフォルダをリネームする

FTPソフトまたはレンタルサーバーのファイルマネージャーで、WordPress のインストール先に移動し、/wp-content/plugins/ ディレクトリを開く。エラーログに書かれていたプラグイン名と一致するフォルダを見つけて、名前を変更する。末尾に「_deactivated」や「_bk」などを付け足せばよい。

  • 変更前: problem-plugin
  • 変更後: problem-plugin_deactivated

WordPress はフォルダ名が一致しないプラグインを読み込まなくなる。結果、致命的エラーの原因が取り除かれ、サイトは無事に表示されるようになる。管理画面にも再びログイン可能になる。

すべてのプラグインを一括で疑う場合の方法

エラーログ上でプラグイン名が特定できないが、何らかのプラグインが原因であることは間違いない場合、/wp-content/plugins/ フォルダそのものをリネームしてしまう手もある。たとえば plugins を plugins_stop に変更すれば、すべてのプラグインが一括で無効化される。その状態で管理画面にログインできれば、原因はやはりプラグインなので、フォルダ名を元に戻し、管理画面から一つずつ有効化していく。テーマが原因と疑われる場合は、/wp-content/themes/ 以下の現在のテーマフォルダをリネームする。WordPress はテーマが存在しないとデフォルトテーマ（Twenty Twenty-Five など）に自動で切り替わる。

復旧後に必ずやっておくべき再発防止策

復旧後に必ずやっておくべき再発防止策

サイトが無事に表示され管理画面にも入れたら、そのまま運用を再開するのではなく、必ず以下の3つをチェックする。これで同じエラーが二度と起きにくくなる。

WordPress本体、テーマ、プラグインをすべて最新にする

致命的エラーは「古いソフトウェア」と「最新のPHPバージョン」の組み合わせで起きやすい。更新が止まっている長期放置プラグインが混ざっているなら、代替のメンテナンスされているプラグインへの移行を検討する。

PHPバージョンをサーバー管理画面で上げる

WordPress の推奨する PHP バージョンは常に上がっている。サーバーのコントロールパネルで PHP 8.1 以上に設定変更できるか確認する。変更後はサイト全体の動作確認を必ず行う。

WP_DEBUG の設定を本番環境で必ず解除する

wp-config.php にデバッグ設定を追加していた場合、必ず define( 'WP_DEBUG', false ); に戻すか、該当行を削除する。ログ出力を有効にしたまま運用すると、サーバーのディスク容量を圧迫し、別のトラブルを引き起こす。

よくある質問

管理画面の「回復モード」リンクがメールで届かない理由は

主な原因はサイトのメール送信機能そのものが正常に動いていないことだ。特に共用サーバーでは PHP の mail() 関数が制限されているか、WordPress の送信メールが迷惑メールフォルダに分類されている。SMTPプラグインなどで送信経路を信頼性の高いものに変えれば、次回以降の通知は確実に届くようになる。

WordPressログイン画面自体が表示されない場合の対処法は

管理画面へのアクセスすら致命的エラーで遮断されているという状態だ。まず前述の FTP を使ったプラグイン一括停止を試す。それでも改善しないなら、.htaccess ファイルの破損も疑って、ファイル名を .htaccess_bk に変更し、WordPress 管理画面の「設定」→「パーマリンク」で再生成させる。

FTPパスワードがわからないが復旧できるか

レンタルサーバーのコントロールパネルにログインできれば、多くの場合ブラウザ上で操作できる「ファイルマネージャー」が利用可能だ。FTPアカウントの情報が不明でも、ファイルマネージャーさえ使えれば全く同じ手順でプラグインフォルダのリネームができる。

すべてのプラグインを停止してもエラーが消えない

テーマが原因の可能性が高い。FTPで /wp-content/themes/ 以下の現在のテーマフォルダをリネームする。また、WordPress のコアファイルが破損していることもある。「ダッシュボード」→「更新」から WordPress の「再インストール」を実行すれば、コアファイルが上書き修復される。

WP_DEBUG を設定したが debug.log に何も記録されない

サーバー側で PHP エラーログの出力先が別に固定されているケースだ。その場合、レンタルサーバーのコントロールパネルに用意されている「エラーログ」機能に、より詳細な情報が出ている。そこを確認すれば解決の糸口がつかみやすい。また、wp-config.php の記述場所が /* That's all, stop editing! */ より上にあるかも確認する。

この記事のポイント

  • 「重大なエラー」はPHPの致命的エラーが原因で起こる
  • メールが届かなくてもサーバーのエラーログで原因を特定できる
  • FTPやファイルマネージャーでプラグインフォルダをリネームして停止する
  • 復旧後はPHPバージョンの確認とWP_DEBUGの解除が必須
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
Events Manager 7.3.7更新後に致命的エラーで画面が真っ白になった時の直し方
2026年6月29日 0

Events Manager 7.3.7更新後に致命的エラーで画面が真っ白になった時の直し方

Events Manager 7.3.7 へ更新した直後にサイトが真っ白になり、WP_HTML_Tag_Processor::apply_attributes_updates() の致命的エラーが発生する現象は、別のプラグインやテーマが開始した出力バッファリングとの競合が原因だ。復旧には、プラグインを 7.3.6 以前に差し戻す。根本解決には、競合相手を特定して対処する必要がある。

なぜ 7.3.7 で WP_HTML_Tag_Processor の致命的エラーが起きるのか

なぜ 7.3.7 で WP_HTML_Tag_Processor の致命的エラーが起きるのか

表示されるエラーメッセージは「PHP Fatal error: WP_HTML_Tag_Processor::apply_attributes_updates(): Cannot use output buffering in output buffering display handlers」だ。これは、すでに出力バッファリング（ob_start）が始まっているのに、さらに別の出力バッファリングを入れ子で開始しようとしたときに PHP が送出する。

Events Manager 7.3.7 では、HTML 出力の整形やサニタイズに WordPress の WP_HTML_Tag_Processor を利用している。このクラスは内部的に ob_start() を使うことがあり、タイミングによっては二重バッファリングの禁止に抵触する。単体では問題にならなくても、先に出力バッファリングを開始する別のプラグイン（キャッシュプラグインやページビルダー、一部の翻訳プラグインなど）やテーマが組み合わさると、この競合が表面化する。

Before（エラー状態）
プラグイン A が先に出力バッファリングを開始。その後 Events Manager 7.3.7 が WP_HTML_Tag_Processor 経由で 2 重目のバッファを開始しようとして 致命的エラー で停止、画面が真っ白になる。
↓
After（競合解消後）
競合相手を無効化するか、Events Manager を 7.3.6 に戻すと出力バッファリングの入れ子が発生せず、サイトが正常に表示される。
■ エラー発生時　■ 復旧後

まずはサイトを復旧させる 以前のバージョンに戻す手順

まずはサイトを復旧させる 以前のバージョンに戻す手順

管理画面にアクセスできず真っ白な状態でも、FTP またはサーバーのファイルマネージャーでプラグインを差し戻せば、数分で復旧できる。データベース上のイベント情報や設定は保持される。

STEP 1 FTP でサーバーに接続し、/wp-content/plugins/events-manager/ フォルダを events-manager-old にリネームする
↓
STEP 2 管理画面が表示されるようになったら、「プラグイン」→「インストール済みプラグイン」で自動的に無効化された Events Manager を完全に削除する（イベントデータはデータベースに残る）
↓
STEP 3 公式リポジトリの「開発」タブやバージョン管理から 7.3.6 の ZIP を入手し、「プラグイン」→「新規追加」→「プラグインのアップロード」でインストールして有効化する

FTP が使えない場合の代替手段

レンタルサーバーの管理画面にファイルマネージャー機能があるなら、同じ操作ができる。phpMyAdmin から wp_options テーブルの active_plugins 行を直接編集してプラグインの無効化を試みる方法もあるが、操作ミスが起きやすいため、ファイルマネージャーでフォルダ名を変更するほうが安全だ。

競合するプラグインやテーマを特定する手順

競合するプラグインやテーマを特定する手順

7.3.7 へ戻したい場合や、今後のアップデートでも同様の競合を防ぎたい場合は、次の手順で原因の相手を突き止める。

Health Check & Troubleshooting プラグインを使う

「サイトヘルスチェック＆トラブルシューティング」プラグインは、管理者だけが特定のプラグインやテーマを有効化した状態をテストできる公式推奨ツールだ。有効化して「トラブルシューティングモード」を開始すると、サイトの外観を変えずに、Events Manager 7.3.7 だけを有効化した状態でエラーの再現を確認したり、1 つずつ他のプラグインと組み合わせて競合を絞り込める。

手動でプラグインを 1 つずつ検証する

  • 管理画面の「プラグイン」→「インストール済みプラグイン」で、Events Manager 以外の全プラグインを無効化する
  • テーマを標準テーマ（Twenty Twenty-Five など）に切り替える
  • Events Manager 7.3.7 を有効化してエラーが出ないことを確認する
  • 1 つずつ他のプラグインを有効化し、エラーが再現した時点で競合相手を特定する
  • テーマも元に戻して再現するか確認する

エラーログの取得と開発者への報告

エラーログの取得と開発者への報告

競合相手が特定できたら、Events Manager の開発元に情報を提供することで修正が期待できる。wp-config.php で WP_DEBUG を true にし、WP_DEBUG_LOG も true に設定すると、/wp-content/debug.log にエラーの詳細が記録される。

7.3.7 を有効化し競合プラグインも有効化した状態でエラーを発生させ、そのログを添えて公式フォーラムやサポートに報告する。同時に、競合相手のプラグイン開発者にも情報を伝えると、双方の調整が進みやすくなる。

よくある質問

7.3.7 に更新しなければ、この問題は起こらないのか

その通りだ。Events Manager 7.3.6 では WP_HTML_Tag_Processor を利用していないため、出力バッファリングの競合は発生しない。セキュリティ上や機能上の理由でアップデートしたい場合は、競合相手を特定してから更新するか、修正版のリリースを待つことを推奨する。

プラグインを削除してもイベントのデータは消えないか

Events Manager の予約データやイベント情報、設定はデータベースに保存されている。管理画面からプラグインを削除しても、これらのデータは保持される。ただし、完全に削除した場合、プラグイン側のアンインストール処理で消える可能性もあるため、事前にバックアップを取っておくとより安全だ。

他のプラグインでも同じようなエラーは出る可能性があるのか

WP_HTML_Tag_Processor は WordPress 本体の機能であり、他のプラグインでも利用される可能性がある。出力バッファリングを多用するプラグイン（キャッシュ系、出力圧縮系、外部出力を加工する系）と組み合わさると、同種の致命的エラーが起こりうる。発生時は同様の切り分け手順で原因を突き止められる。

管理画面にすら入れない場合、他に試せることはあるか

FTP でプラグインフォルダをリネームするのが最も確実な復旧手段だ。サーバー管理パネルのファイルマネージャーでも同様に操作できる。どうしてもファイルに触れない場合は、サーバー会社のサポートに依頼してリネームや無効化を依頼する方法もある。WP-CLI が使える環境なら wp plugin deactivate events-manager --skip-plugins=events-manager で無効化できる。

この記事のポイント

  • Events Manager 7.3.7 の致命的エラーは、他のプラグインやテーマとの出力バッファリング競合で発生する
  • 復旧には FTP でプラグインフォルダをリネームし、7.3.6 以前のバージョンに差し替える
  • 競合相手は「サイトヘルスチェック＆トラブルシューティング」プラグインで安全に特定できる
  • エラーログを添えて開発者に報告すれば、今後の修正を促せる
  • プラグイン削除ではイベントデータは原則消えず、データベースに残る
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerce PayPal決済が断続的に失敗する原因と直し方
2026年6月28日 0

WooCommerce PayPal決済が断続的に失敗する原因と直し方

WooCommerce PayPal Payments プラグインで決済が断続的に失敗し OrderProcessor.php のエラーが発生する場合、注文 ID のセッション保存が決済リダイレクトと競合しているか、PayPal ウェブフックの署名検証に失敗している可能性が高い。原因をログから特定し、設定と更新状況を見直せば、決済の取りこぼしを止められる。

なぜ PayPal 決済やカード決済が断続的に失敗するのか

なぜ PayPal 決済やカード決済が断続的に失敗するのか

断続的に発生する決済失敗は、一定の条件が重なった時だけ起こる「競合状態」が原因になっていることが多い。WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal にリダイレクトされる直前に注文 ID をセッションへ保存する処理と、PayPal 側の承認完了後の戻り処理がうまく噛み合わず、注文 ID を見失うケースが報告されている。

また PayPal から届く CHECKOUT.ORDER.APPROVED ウェブフックの署名検証に失敗すると、ブラウザ経由の戻りが完了しなかった注文を復旧できず、売上が失われる。キャッシュや最適化を完全に停止しても再発するケースは、プラグイン内部のタイミング問題である可能性が極めて高い。

エラーログから失敗のパターンを特定する

エラーログから失敗のパターンを特定する

WooCommerce PayPal Payments の詳細ログを有効にする

管理画面の「WooCommerce」から「設定」へ進み「決済」タブを開く。PayPal の項目にある「接続を管理」画面の下部に「ログ」というチェックボックスがあるので、これを有効にして保存する。有効化後は決済のたびにログが蓄積され始めるので、エラーが出たタイミングを正確に追える。

ログに記録されるエラーメッセージを読み解く

失敗時のログには「Payment failed: There was an error processing your order. OrderProcessor.php:109」と出力される。ただしこのメッセージだけでは表面的な情報に過ぎない。同じ時刻付近に PayPal API への注文作成リクエストや capture 呼び出しが記録されているかを確認することが重要だ。

もしログに PayPal 側の注文作成すら残っていないなら、プラグインが PayPal へ処理を引き継ぐ前の段階でコケている。逆に注文作成は成功しているのに capture 呼び出しが見つからないなら、戻り処理かウェブフックの不具合を疑う。

STEP 1 WooCommerce 設定で PayPal の詳細ログを有効にする
↓
STEP 2 失敗時刻の前後で PayPal API 呼び出しの有無を調べる
↓
STEP 3 注文作成ログがない場合はセッションと注文 ID の欠落を疑う

上の手順で失敗パターンを大まかに分類できる。注文作成ログが欠けているパターンは後述の注文 ID 消失問題と合致する。

ウェブフック検証失敗の原因と直し方

ウェブフック検証失敗の原因と直し方

ウェブフックが届いているのに検証に失敗する仕組み

PayPal から WordPress サイトの REST エンドポイント（/wp-json/paypal/v1/incoming）に届いたウェブフックは、プラグインが PayPal の公開鍵を使って署名を検証する。この検証が通らないと、たとえ CHECKOUT.ORDER.APPROVED イベントを受け取っていても支払いを完了できず、注文は保留のままになる。

署名検証が失敗する典型的な原因

まず疑うのはサーバー時刻のずれだ。署名にはタイムスタンプが含まれており、サーバーの時刻が大きく狂っていると検証に失敗する。次に考えられるのがプラグイン内部で保持している PayPal 公開鍵のキャッシュ不整合だ。接続情報を更新した直後や、マルチサイト構成でドメインが一致していない場合にも起こりうる。

ウェブフック検証を復旧させる具体的な対処

最初に PayPal との接続を一度解除し、再度接続し直す。これで公開鍵のキャッシュが強制的に再取得される。それでも直らない場合は WooCommerce の「ステータス」画面から「ツール」タブを開き、「WooCommerce のトランジェントをクリア」と「期限切れのトランジェントをクリア」を順に実行する。最後に PayPal のデベロッパーダッシュボードでウェブフック URL が本番環境の正しいドメインを指しているか確認する。

Before（検証失敗時）
ウェブフック受信 → 署名照合エラー → 注文が未完了のまま放置
↓
After（再接続後）
ウェブフック受信 → 署名照合成功 → 注文が正常に完了
■ 検証失敗　■ 再接続で復旧

上の流れで復旧しない場合はプラグインバージョン固有の不具合が根底にある可能性が高い。

注文 ID がセッションから消える問題に対処する

注文 ID がセッションから消える問題に対処する

リダイレクト前に注文 ID が保存されない既知の不具合

GitHub の issue #4458 でも報告されているが、WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal へリダイレクトされる直前に注文 ID を正しくセッションへ格納できないケースがある。これが発生すると、PayPal 上で決済が承認されても、戻ってきた WooCommerce 側でどの注文に紐づければよいかわからず、OrderProcessor がエラーを起こす。

修正パッチやバージョンアップで解決できるか

バージョン 4.1.0 ではこのタイミング問題に対する修正が含まれていると開発者からアナウンスされている。まずはプラグインを 4.1.0 以降へ更新することが最も確実な対処となる。どうしても本番環境で即時の更新が難しい場合は、プラグインの公式サポートチャネルを通じて修正パッチの提供を依頼する手もある。

更新前に検証するべき設定

更新前に WooCommerce の「システムステータス」レポートを取得し、PHP のバージョンが 8.0 以上であること、WordPress 本体と WooCommerce が最新の安定版であることを確認する。多言語プラグイン（WPML 等）を併用している場合は、プラグイン同士の互換性もあわせてチェックしておく。

それでも直らない場合に踏むべき最終手順

それでも直らない場合に踏むべき最終手順

キャッシュとセキュリティ系プラグインの完全な切り離し

速度最適化プラグインやサーバー側の動的キャッシュはすでに無効化していても、WAF（ウェブアプリケーションファイアウォール）やセキュリティプラグインが PayPal からのコールバック通信をブロックしている場合がある。一時的にすべてのセキュリティ系プラグインを停止し、サーバーのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストが 200 ステータスを返しているか確認する。

注文メタデータとセッションデータの直接確認

失敗した注文の詳細画面を開き、カスタムフィールドに _ppcp_paypal_order_id というメタキーが存在するか調べる。これが空になっている注文は、まさに注文 ID の引き継ぎに失敗した注文だ。WooCommerce が生成した注文番号は存在するのに PayPal 側の注文 ID だけ欠落している場合は、前述の競合が再現したと断定してよい。

確認項目
注文メタデータ → _ppcp_paypal_order_id の有無を確認
アクセスログ → /wp-json/paypal/v1/incoming への POST が 200 を返しているか
プラグインバージョン → 4.1.0 以上へ更新済みか
■ データ・技術系の確認ポイント

この三点を確認すれば、問題がインフラ寄りなのかアプリケーション寄りなのか切り分けられる。

よくある質問

PayPal のウェブフック検証失敗は何が原因か

サーバー時刻のずれや PayPal 公開鍵のキャッシュ不整合が最も多い原因だ。接続を一度解除して再接続し、WooCommerce のトランジェントをクリアすることで解決することが多い。まれにホスティング環境のファイアウォールが PayPal の検証用リクエストを遮断しているケースもある。

決済が断続的に失敗する場合、キャッシュが原因か

キャッシュが直接の原因でないケースも多い。キャッシュを完全に停止し、カートやチェックアウトの除外設定を施しても再発するなら、プラグイン内部の競合状態や注文 ID の引き継ぎ不良を疑うべきだ。

WooCommerce PayPal Payments の最新バージョンで問題は修正されたか

バージョン 4.1.0 では、注文 ID のセッション保存タイミングに関する修正が含まれている。4.0.4 以前で OrderProcessor エラーが断続的に出ている場合は、まず 4.1.0 以降へ更新することが推奨される。

注文 ID が保存されない問題はどうやって確認するか

失敗した WooCommerce 注文のカスタムフィールドを確認し、_ppcp_paypal_order_id というメタキーが空かどうかを調べる。空であれば注文 ID の引き継ぎに失敗している。プラグインの詳細ログにも PayPal 側の注文作成リクエストが記録されない。

ウェブフックのエンドポイントにアクセスできるか確認する方法は

サイトのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストを探し、HTTP ステータスが 200 であることを確かめる。PayPal のデベロッパーダッシュボード上でウェブフック URL が本番ドメインを指しているかも同時に検証する。

この記事のポイント

  • ログを有効にして OrderProcessor エラーの前後に PayPal API 呼び出しが存在するか確認する
  • ウェブフック検証失敗は接続の再設定とトランジェントクリアで復旧する可能性が高い
  • 注文 ID のセッション消失は 4.1.0 以上のプラグイン更新で根本対処できる
  • キャッシュ停止だけでは直らない競合はプラグイン内部のタイミング問題を疑う
  • 注文メタデータとアクセスログの二面から原因の切り分けを進める
佐々木 太陽
, , , , ,
お悩み・トラブル解決
W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方
2026年6月27日 0

W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方

W3 Total Cache 2.10.0 へのアップデート後、動的コンテンツが表示されず「W3TC dynamic mfunc tag refused： missing call：slug + hmac envelope.」と表示される場合、根本原因はバージョン 2.10.0 で導入された HMAC 署名検証の仕様変更である。プラグインを 2.9.x 系に戻すか、動的ブロックの呼び出しコードに正しい slug 属性と HMAC 署名を付与すれば直る。

どんな症状が発生しているのか

どんな症状が発生しているのか

W3 Total Cache（以下 W3TC）のページキャッシュを有効にしたサイトを更新したあと、AdRotate Pro など mfunc タグを使って動的コンテンツを部分キャッシュしていた箇所が、エラーメッセージに置き換わる。日本語環境では英文のまま「W3TC dynamic mfunc tag refused： missing call：slug + hmac envelope.」という文言が表示されるケースが多い。この文言は「mfunc 呼び出しが拒否された。slug と HMAC エンベロープが不足している」という意味だ。

対象になるのは、W3TC のページキャッシュ機能と「後期キャッシング（Late Caching）」や「動的 mfunc ブロック」を組み合わせて使っていたサイトである。具体的には、固定ページ全体をキャッシュしつつ、広告ブロックやログイン状態表示などの一部だけを非キャッシュで差し込んでいた構成だ。更新前は問題なく動いていたのに、2.10.0 にした途端に該当箇所だけエラー文言に化ける。

なぜ W3TC 2.10.0 でエラーが起きるのか

なぜ W3TC 2.10.0 でエラーが起きるのか

W3TC 2.10.0 では、動的 mfunc タグのセキュリティ強化として HMAC（ハッシュベースのメッセージ認証コード）による署名検証が必須になった。これは不正な動的コードの注入を防ぐための仕組みだが、従来の呼び出しコードには slug 属性と HMAC 署名が含まれていなかったため、検証に失敗し、一律で拒否されるようになった。

W3TC の動的 mfunc ブロックは、PHP 関数をページキャッシュ内に埋め込んでおき、キャッシュから配信される直前に実行する仕組みだ。これまでは単純なコールバック名だけで動作していたが、2.10.0 からは「どのスラッグから呼び出されたか」と「正当な呼び出し元であることを証明する HMAC 署名」のセットがなければ mfunc タグが無効化される。

この仕様変更は W3TC 本体のセキュリティアップデートであるため、AdRotate Pro など W3TC 互換モードを持つ他プラグインの側が新しい署名形式に対応していないと、もれなくエラーになる。結果的に、更新後は互換モードで動的コンテンツを提供しているほとんどすべてのサイトで同じ問題が発生している。

W3TC 2.10.0 の動的 mfunc 呼び出し変化
Before
<！– mfunc callback_name –>
slug・HMAC なし → 拒否される
↓
After
<！– mfunc callback_slug –><！– mfunc hmac_signature –><！– /mfunc –>
slug・HMAC 付き → 正常動作
■ エラー状態（旧形式）　■ 2.10.0 の要求仕様

すぐにサイトを元に戻す応急処置

すぐにサイトを元に戻す応急処置

W3 Total Cache を 2.9.x 系にダウングレードする

最も短時間で確実に直す方法は、W3TC を 2.10.0 より前のバージョンに戻すことだ。ダウングレード手順は以下のとおり。

  1. 管理画面の「プラグイン」から W3 Total Cache を停止する
  2. 「プラグイン」→「プラグインの追加」→「プラグインのアップロード」を使うか、FTP で古いバージョンの ZIP を展開して上書きする
  3. プラグインを再有効化し、すべてのキャッシュを削除する

古いバージョンの ZIP ファイルは WordPress.org のプラグインページにある「以前のバージョン」セクションから入手できる。バージョン 2.9.8 や 2.9.9 であれば HMAC 署名検証が存在しないため、従来どおり動的 mfunc タグが動作する。

ダウングレードしたあとは、W3TC の自動更新を一時的に停止することを推奨する。管理画面の「プラグイン」で個別に自動更新をオフにするか、wp-config.php に define（ 'AUTOMATIC_UPDATER_DISABLED', true ）; を追加してサイト全体の自動更新を止めておけば、意図しない再アップデートを防げる。

他プラグインの W3TC 互換モードを一時的に無効化する

もし AdRotate Pro など、W3TC 互換モードを個別にオン・オフできるプラグインを使っているなら、当該プラグインの設定で互換モードをオフにする手もある。ただしこの場合、ページキャッシュの影響で広告がローテーションしなくなったり、動的コンテンツが静的になってしまったりする副作用がある。あくまで「エラー表示を消す」ための一時的な回避策と位置づけるのが安全だ。

2.10.0 を使い続ける場合の恒久対応

2.10.0 を使い続ける場合の恒久対応

W3TC 2.10.0 のセキュリティ修正を活かしたまま動的コンテンツを動作させるには、呼び出しコードに正しい slug と HMAC 署名を付与する必要がある。この修正は、動的 mfunc タグを生成している側（多くの場合は広告管理プラグインや自作のテーマ関数）に手を入れることになる。

W3TC の HMAC 署名の仕組みを理解する

mfunc タグはページキャッシュの HTML 内に PHP コード片を残し、キャッシュ配信時に W3TC がそれを検出して実行する。2.10.0 ではこのとき、呼び出しパラメータとして「call：slug」と「hmac」の両方がエンベロープに含まれていなければならない。slug は処理を一意に識別する任意の文字列、hmac は W3TC 内部で生成される署名ハッシュだ。

生成ルールは公開されているが、実際には W3TC が提供する API 関数を使って動的ブロックを登録するのが現実的だ。自作テーマであれば w3tc_fragmentcache_register フィルターを使い、コールバックと slug を W3TC に登録すれば、あとは W3TC 側が自動で HMAC 署名を計算してくれる。

AdRotate Pro での対応状況を確認する

AdRotate Pro は W3TC 互換モードを有効にしている場合、内部的に mfunc タグを生成している。今回のエラーは、AdRotate Pro が生成する mfunc タグが 2.10.0 の新形式に対応していないために発生している。AdRotate Pro の開発元がこの問題に対応したアップデートをリリースするまでは、互換モードの使用が難しい。

AdRotate Pro の管理画面にある「W3 Total Caching compatibility」設定をオフにし、代わりに JavaScript による非同期広告読み込み（AdRotate のダイナミックモード）を使うか、広告ブロックを iframe で埋め込む形に切り替えると、ページキャッシュ機構に依存せず動的広告を配信できる。

自作テーマで動的ブロックを登録し直す

テーマの functions.php などで自作の動的コンテンツを mfunc タグで埋め込んでいた場合は、W3TC のフラグメントキャッシュ API を使った正式な登録に切り替える。基本的な流れは次のとおりだ。

  1. w3tc_fragmentcache_register フィルターで、slug とコールバック関数のペアを W3TC に登録する
  2. テンプレート内では w3tc_fragmentcache_output 関数を使い、slug を指定して動的出力を行う
  3. W3TC が自動で HMAC 署名を計算し、mfunc タグとしてページキャッシュに埋め込む

この方法なら、W3TC のバージョンが上がっても署名方式の変更に W3TC 本体側が追随するため、サイト側のコードを再度修正する必要がなくなる。フラグメントキャッシュ API の具体的な記述例は W3TC の公式ドキュメントに掲載されている。

Late Caching 設定の確認と調整

W3TC の pgcache.late_caching 設定（後期キャッシング）が有効かどうかも、動作に影響を与える要素のひとつだ。この設定が true の場合、ページ生成の最終段階で mfunc タグを処理するため、プラグイン間の競合が減る傾向がある。すでに true でもエラーが出ている場合は今回の本質的な原因ではないが、念のため設定値を確認しておく。

wp-content 内の w3tc-config/master.php を直接確認するか、管理画面の「パフォーマンス」→「一般設定」からエクスポートした設定ファイルで pgcache.late_caching の値を確認できる。false であれば true に変更し、キャッシュを全削除してから表示を再確認する。

再発を防ぐための注意点

再発を防ぐための注意点

W3TC のような深くサイト機構に組み込まれるプラグインをメジャーバージョンアップする前には、必ずステージング環境で検証する習慣をつける。とくに mfunc やフラグメントキャッシュといった、通常のキャッシュとは異なる高度な機能を使っている場合は、本番適用前に動的コンテンツの全パターンをテストする必要がある。

また、W3TC の設定をエクスポートしてバックアップしておけば、問題が起きたときに設定ごと以前のバージョンに戻せる。管理画面「パフォーマンス」→「一般設定」の下部にある「設定のダウンロード」ボタンで、JSON 形式の設定ファイルを定期的に保存しておくとよい。

更新前の準備と検証フロー
STEP 1 W3TC 設定を JSON でダウンロードしてバックアップ
↓
STEP 2 ステージング環境で W3TC を更新し動作確認
↓
STEP 3 動的コンテンツ全種をテストし問題なければ本番に適用
↓
STEP 4 本番反映後すぐにキャッシュ全削除して再チェック

よくある質問

「W3TC dynamic mfunc tag refused」はサイト全体が真っ白になるのか

サイト全体が真っ白になるわけではない。ページの大部分は正常にキャッシュ配信されるが、mfunc タグで差し込まれていた動的コンテンツの部分だけがエラー文言に置き換わる。レイアウトが崩れることはあるが、PHP 致命的エラーによる白画面とは異なる。

キャッシュを削除しても直らないのはなぜか

キャッシュ削除はあくまで「現在保存されているキャッシュファイルを消す」行為であり、mfunc タグの生成コード自体を修正するものではない。新しいキャッシュが生成されるときに、同じく新形式に対応していない mfunc タグが再度埋め込まれるため、キャッシュ削除だけでは根本解決にならない。

W3TC 無料版でも同じ問題は起きるのか

起きる。HMAC 署名検証は W3TC のコア機能の一部として Pro 版・無料版の両方に実装されている。フラグメントキャッシュや mfunc タグを使っているサイトは、Pro 版かどうかに関係なく影響を受ける。

このエラーを放置してもサイトには大きな問題はないか

動的コンテンツが表示されないという機能面の問題に加え、エラー文言が来訪者にそのまま見える状態はサイトの信頼性を損なう。また広告が表示されなければ収益にも直結するため、実質的には早期解決が必要な重大トラブルに分類される。

他に W3TC 2.10.0 で影響を受けるプラグインはあるか

AdRotate Pro 以外にも、W3TC 互換モードで動的コンテンツを埋め込む仕組みを持つプラグイン全般が影響を受ける可能性がある。具体的には、動的ウィジェットやパーソナライズ表示を行うキャッシュ対応プラグインが該当する。該当プラグインの更新情報を注視し、開発元が W3TC 2.10.0 対応を表明するまではアップデートを保留するのが安全だ。

この記事のポイント

  • W3TC 2.10.0 の HMAC 署名検証強化で mfunc タグが拒否される
  • ダウングレードで即時解決するがセキュリティ面は旧版に戻る
  • 互換プラグイン側の対応アップデートを待つか公式 API で再実装する
  • キャッシュ削除だけでは再発するため mfunc コード自体の修正が必要
  • メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.