タグアーカイブ 400エラー

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エラーになる典型的な症状を示している。これは、投稿の保存パスと他の管理画面パスで異なるキャッシュルールが適用されている可能性を示唆する。

また、管理画面そのものへのキャッシュ適用や、サーバーレベル（cPanel）でのキャッシュ層、セキュリティプラグインによるREST APIアクセス制限も、同様の400エラーを引き起こす。原因は複合的なこともあるため、順を追って切り分ける必要がある。

REST APIエラーを解決する手順

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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている