WordPress REST APIの400エラーを解決する原因と対処法
WordPressの管理画面でウィジェットの更新や新規ページの公開ができず、REST APIの400エラーが発生する場合、まずW3 Total Cacheの設定とプラグイン同士の干渉を疑う。W3 Total CacheがREST APIのリクエストに干渉してエラーを引き起こすケースが多いため、オブジェクトキャッシュとデータベースキャッシュを一時停止して症状が改善するかを確認するのが最も早い切り分けになる。
REST APIの400エラーが起きる原因は何か
WordPress 4.7以降、管理画面の多くの操作はREST APIを通じて行われる。ウィジェットの更新、固定ページの保存、ブロックエディターのオートセーブなどだ。このAPIのエンドポイントにリクエストを送った際、サーバーが「400 Bad Request」を返すということは、送信されたデータの形式やヘッダー情報に不備があるとサーバーが判断したことを意味する。
ただ、実際には送信データそのものに問題がなくても、プラグインがリクエストの内容を改変したり、キャッシュ機構がAPIのレスポンスを破損させたりして400エラーが発生することが多々ある。特に、W3 Total Cacheのような全ページキャッシュ・オブジェクトキャッシュ・データベースキャッシュを一括して扱うプラグインでは、キャッシュの設定ミスや競合が原因で管理画面の動作に支障をきたしやすい。
ウィジェット更新 → 400 Bad Request
固定ページ公開 → 400 Bad Request
投稿保存 → 200 OK
ウィジェット更新 → 200 OK
固定ページ公開 → 200 OK
上記の図は、投稿だけが正常に動作し、固定ページとウィジェットだけが400エラーになる典型的な症状を示している。これは、投稿の保存パスと他の管理画面パスで異なるキャッシュルールが適用されている可能性を示唆する。
また、管理画面そのものへのキャッシュ適用や、サーバーレベル（cPanel）でのキャッシュ層、セキュリティプラグインによるREST APIアクセス制限も、同様の400エラーを引き起こす。原因は複合的なこともあるため、順を追って切り分ける必要がある。
REST APIエラーを解決する手順
W3 Total Cacheのキャッシュを段階的に無効化する
第一に、W3 Total Cacheの管理画面（「パフォーマンス」→「一般設定」）から、各キャッシュモジュールを一つずつ無効化して症状が改善するか確認する。すべて一気にではなく段階的に止めることで、どのキャッシュ機能がエラーの原因になっているかを特定できる。
W3 Total Cacheの「一般設定」で「オブジェクトキャッシュ」のチェックを外して保存
同様に「データベースキャッシュ」のチェックを外す
ページキャッシュ、ミニファイも停止し、症状が改善するかテストする
各ステップで設定を変更したあとは、W3 Total Cacheの「すべてのキャッシュをクリア」を実行してから、問題の操作（固定ページの公開やウィジェットの更新）を試す。もしオブジェクトキャッシュまたはデータベースキャッシュを停止した段階で問題が解消するなら、それらのキャッシュ方式が使用しているバックエンド（MemcachedやRedis）との通信に問題があるか、cPanel環境で利用できるリソースに制限がかかっている可能性が高い。
管理画面ページをキャッシュ対象から除外する
W3 Total Cacheのページキャッシュ設定には、キャッシュ対象から外すURLパターンを指定する項目がある。管理画面のパス（/wp-admin/）がキャッシュされてしまうと、ノンス（セキュリティトークン）の不整合が起こり400エラーを引き起こす。
「パフォーマンス」→「ページキャッシュ」→「高度な設定」→「キャッシュしないページ」に以下のパターンを追加する。
/wp-admin/
/wp-login.php
/wp-json/それでも改善しない場合は、W3 Total Cacheの設定ファイル（通常は/wp-content/w3tc-config/以下）に直接手を入れる方法もあるが、管理画面からの設定で解決することがほとんどだ。cPanelの「ファイルマネージャー」からFTPアカウントを使ってアクセスできる。
テーマとプラグインの干渉を調べる
Catch Boxのような無料テーマでも、プラグインとの特定の組み合わせでREST APIのリクエストに余計なデータを付加してしまうケースがある。W3 Total Cacheの設定変更だけで解決しない場合は、プラグインの一括無効化による切り分けを行う。
すべてのプラグインを無効化し、デフォルトテーマ（Twenty Twenty-Fiveなど）に切り替えた状態で問題が再現するか確認する。これでエラーが消えるなら、一つずつプラグインを有効化していき、どのプラグインがトリガーになっているかを特定する。特定後は、そのプラグインのREST API関連の設定を見直すか、代替プラグインを検討する。
ブラウザの開発者ツールでエラーの詳細を確認する
ChromeやFirefoxの開発者ツール（F12キー）を開き、「ネットワーク」タブでウィジェット保存時や固定ページ公開時のリクエストを観察する。400エラーが返ってきたリクエストをクリックすると、サーバーから返されたレスポンスボディに具体的なエラーメッセージが含まれていることがある。
例えば、「無効なパラメーター」「cookie nonce is invalid」などのメッセージが確認できる。これにより、キャッシュによるノンス不整合なのか、リクエストパラメーターの欠落なのかをより正確に判断できる。また、ブラウザのコンソールタブにJavaScriptエラーが出ている場合も、それらを併せて確認する。
再発を防ぐための恒久的な設定
原因となったキャッシュ機能を一時停止して問題が解決した場合、そのまま無効にし続けるとサイト表示速度に影響が出る。恒久的な対策としては、W3 Total Cacheのオブジェクトキャッシュやデータベースキャッシュを再び有効化した上で、管理画面のURLパターンをキャッシュ対象から明示的に除外する設定を施す。
また、cPanelからPHPのバージョンやメモリ制限も確認しておく。多くのレンタルサーバーでは、PHPのメモリ制限が256MBに設定されているが、W3 Total Cacheの一部機能はそれ以上のメモリを消費することがある。PHPの設定でmemory_limitを512MB程度に引き上げられるなら引き上げておくと、予期せぬキャッシュ破損やプロセス停止を避けやすくなる。
よくある質問
REST APIエラーはサイトのフロントエンドにも影響するか
通常、REST APIの400エラーは管理画面の操作に限られることが多い。ただし、フロントエンドでWordPressのREST APIを利用した動的な機能（リアルタイム検索や読み込みボタンなど）を使っている場合は、来訪者が同様のエラーに遭遇する可能性がある。
キャッシュプラグインをすべて停止しても直らない場合はどうするか
サーバーレベル（cPanel）のキャッシュ（Varnishなど）が動作している可能性がある。cPanelに「キャッシュマネージャー」や「サイトパフォーマンス」がある場合は、そちらも一時的に無効化して検証する。また、mod_securityなどのセキュリティモジュールがREST APIのリクエストをブロックしているケースもあるため、ホスティング会社のサポートに確認する必要がある。
同じ症状でプラグインがW3 Total Cache以外の場合はどう切り分けるか
WP Super CacheやLiteSpeed Cacheなど、他のキャッシュプラグインでも同様の干渉が起きることがある。切り分け手順は共通で、いったん全プラグインを無効化してから、キャッシュプラグインだけを先に有効化して問題が再現するかを見る。再現すればそのプラグインの設定を調整する。
ブラウザのコンソールに「nonce」関連のエラーが出ている
ノンスエラーは、キャッシュによって管理画面の古いHTML（古いセキュリティトークンを含む）が表示されてしまう場合に起きる。ページキャッシュの除外設定で/wp-admin/ディレクトリ全体をキャッシュ対象から外し、W3 Total Cacheの「クエリ文字列をキャッシュする」設定を無効化すると解消しやすい。
この記事のポイント
- REST APIの400エラーはW3 Total Cacheの設定が主な原因になりやすい
- オブジェクトキャッシュとデータベースキャッシュから段階的に停止して切り分ける
- 管理画面のURLをキャッシュ対象から除外してノンス不整合を防ぐ
- テーマや他プラグインとの干渉がないか全無効化で確認する
- cPanelのPHPメモリ制限やサーバーレベルキャッシュも併せて点検する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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 では、動的 mfunc タグのセキュリティ強化として HMAC（ハッシュベースのメッセージ認証コード）による署名検証が必須になった。これは不正な動的コードの注入を防ぐための仕組みだが、従来の呼び出しコードには slug 属性と HMAC 署名が含まれていなかったため、検証に失敗し、一律で拒否されるようになった。
W3TC の動的 mfunc ブロックは、PHP 関数をページキャッシュ内に埋め込んでおき、キャッシュから配信される直前に実行する仕組みだ。これまでは単純なコールバック名だけで動作していたが、2.10.0 からは「どのスラッグから呼び出されたか」と「正当な呼び出し元であることを証明する HMAC 署名」のセットがなければ mfunc タグが無効化される。
この仕様変更は W3TC 本体のセキュリティアップデートであるため、AdRotate Pro など W3TC 互換モードを持つ他プラグインの側が新しい署名形式に対応していないと、もれなくエラーになる。結果的に、更新後は互換モードで動的コンテンツを提供しているほとんどすべてのサイトで同じ問題が発生している。
すぐにサイトを元に戻す応急処置
W3 Total Cache を 2.9.x 系にダウングレードする
最も短時間で確実に直す方法は、W3TC を 2.10.0 より前のバージョンに戻すことだ。ダウングレード手順は以下のとおり。
- 管理画面の「プラグイン」から W3 Total Cache を停止する
- 「プラグイン」→「プラグインの追加」→「プラグインのアップロード」を使うか、FTP で古いバージョンの ZIP を展開して上書きする
- プラグインを再有効化し、すべてのキャッシュを削除する
古いバージョンの 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 を使い続ける場合の恒久対応
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 を使った正式な登録に切り替える。基本的な流れは次のとおりだ。
w3tc_fragmentcache_registerフィルターで、slug とコールバック関数のペアを W3TC に登録する- テンプレート内では
w3tc_fragmentcache_output関数を使い、slug を指定して動的出力を行う - 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 形式の設定ファイルを定期的に保存しておくとよい。
よくある質問
「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 コード自体の修正が必要
- メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている