WordPress のブロックエディタで記事を更新しようとしたときに、「更新に失敗しました。返答が正しい JSON レスポンスではありません。」と表示されることがあります。
このエラーは、ブロックエディタの保存処理が WordPress REST API を使っており、その応答が JSON として成立しなかった場合に発生します。原因は WordPress 本体だけとは限らず、WAF、リバースプロキシ、PHP エラー、パーマリンク、HTTPS 混在、キャッシュなど、公開経路全体にあります。
当時の私の環境では、WAF である ModSecurity を無効化すると解消しました。ただし、WAF を丸ごと無効化すると防御層を失うため、最終的には対象の通信とルールを切り分け、必要な範囲だけ調整する必要があります。
書籍
ModSecurity Handbook, Second Edition
ModSecurity と Web Application Firewall の設定、ログ、ルール、チューニングを確認したい場合の参考書籍です。英語書籍であり、価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
書籍
WordPress 仕事の現場でサッと使える！デザイン教科書 [WordPress 6.x対応版] 改訂第3版
WordPress のサイト構築、テーマ、カスタマイズ、運用項目を確認したい場合の参考書籍です。価格や在庫、WordPress の最新仕様との差分はリンク先や公式ドキュメントで確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
前提となる関連記事
WordPress の構築、Kubernetes 上の運用、WAF、パーマリンク、サイトマップの問題は相互に関係します。REST API のエラーは単発の画面エラーではなく、公開経路と WordPress 設定の不整合として見る方が切り分けやすいです。
- Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
- WordPress を Kubernetes で運用する構成
- ModSecurity WordPress のバージョンアップで偽陽性判定
- WordPress 影響を最小限に抑えたパーマリンクの変更
- WordPress サイトマップとパーマリンクの問題
このエラーの意味
ブロックエディタで保存すると、ブラウザは WordPress の REST API に対して投稿内容を送信します。通常であれば、WordPress は JSON を返します。
しかし、途中で WAF がブロックしたり、PHP エラーが混ざったり、リバースプロキシが HTML のエラーページを返したりすると、ブラウザ側は JSON として解釈できません。その結果、「返答が正しい JSON レスポンスではありません」という表示になります。
| 原因候補 | 起きること |
|---|---|
| WAF / ModSecurity | REST API の POST が不正扱いされ、403 や HTML エラーが返る。 |
| PHP エラー | JSON の前後に warning や fatal error が混ざる。 |
| リバースプロキシ | 上流エラーや制限により、JSON ではなくエラーページが返る。 |
| パーマリンク / rewrite | REST API の URL 解決が崩れる。 |
| HTTPS 混在 | 管理画面と REST API の URL が http / https でずれる。 |
| キャッシュ | 管理画面や REST API にキャッシュが介入して古い応答を返す。 |
まず REST API が生きているか確認する
最初に、WordPress の REST API が通常の GET で応答するかを確認します。ブラウザで確認してもよいですが、サーバー側から curl で見ると HTTP ステータスと応答本文を分けて確認できます。
curl -i https://www.example.com/wp-json/
curl -i https://www.example.com/wp-json/wp/v2/posts?per_page=1ここで HTML のエラーページ、リダイレクトのループ、403、500 が返る場合、ブロックエディタ以前に REST API の経路が壊れています。
ブラウザの開発者ツールで失敗したリクエストを見る
ブロックエディタの保存失敗は、管理画面上のメッセージだけでは原因が分かりません。ブラウザの開発者ツールで Network を開き、保存時に失敗している wp-json へのリクエストを確認します。
- HTTP ステータスが 403 なのか、500 なのか、200 だが JSON ではないのかを見る。
- Response が JSON ではなく HTML になっていないか確認する。
- Request URL が意図したドメイン、スキーム、パスになっているか確認する。
- WAF やリバースプロキシのエラーページが返っていないか確認する。
ここで 403 が返っている場合は WAF や認可の問題を疑います。500 の場合は PHP、プラグイン、テーマ、サーバー側エラーを疑います。200 なのに JSON でない場合は、PHP の warning 混入やキャッシュ、プロキシの差し替えを疑います。
WAF / ModSecurity を確認する
私の環境では、ModSecurity を無効化するとブロックエディタの保存が通りました。これは WordPress が悪いというより、REST API の投稿内容が WAF のルールに引っかかり、JSON ではなくブロック応答が返っていた状態です。
WAF を確認する場合は、まず一時的な切り分けとして対象経路でブロックが発生しているかを確認します。その後、audit log の rule id、リクエスト URI、パラメータ、検知内容を見て、必要最小限の例外にします。
sudo tail -n 200 /var/log/modsec_audit.log
sudo grep -n "wp-json" /var/log/modsec_audit.log
sudo grep -n "id " /var/log/modsec_audit.log重要なのは、WAF を丸ごと無効化して終わりにしないことです。ブロックエディタの保存に必要な REST API と、実際に検知したルールを確認して、範囲を絞って調整します。
PHP エラーが JSON に混ざっていないか確認する
PHP の warning や notice が出力されると、REST API の応答本文に余計な文字列が混ざり、JSON として壊れることがあります。管理画面では見えなくても、REST API の応答としては壊れます。
sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/php*-fpm.log
curl -s https://www.example.com/wp-json/wp/v2/posts?per_page=1 | head本番環境では、PHP エラーを画面へ直接表示しない方が安全です。デバッグ時はログへ出力し、REST API の応答に混ざらないようにします。
パーマリンクと rewrite を確認する
REST API は /wp-json/ を使うため、パーマリンクや rewrite の設定が崩れていると API の到達性に影響します。特に Apache では mod_rewrite と AllowOverride の設定を確認します。
sudo apache2ctl -M | grep rewrite
sudo apache2ctl configtest
curl -i https://www.example.com/wp-json/WordPress 管理画面では、パーマリンク設定を保存し直すことで rewrite ルールが再生成される場合があります。ただし、既存サイトでパーマリンク構造を変える場合は、URL 変更とリダイレクト設計を別途考える必要があります。
HTTPS とサイト URL の不整合を確認する
管理画面が HTTPS で開いているのに WordPress の siteurl や home が HTTP のままだと、REST API の URL 生成や Cookie、ブラウザの混在コンテンツ制御で問題が出ることがあります。
wp option get siteurl
wp option get home
curl -I https://www.example.com/wp-json/WP-CLI が使える環境なら、siteurl と home を確認できます。REST API の URL が正しいスキームとドメインになっているかも合わせて見ます。
リバースプロキシとキャッシュを確認する
WordPress の前段に nginx、Apache リバースプロキシ、CDN、キャッシュプラグインがある場合、REST API や管理画面の POST をキャッシュ対象にしないことが重要です。
- /wp-admin/ をキャッシュしない。
- /wp-json/ をキャッシュしない、または慎重に扱う。
- POST リクエストをキャッシュしない。
- リクエストボディサイズ制限に引っかかっていないか確認する。
- WAF、プロキシ、WordPress のどこで 403 / 413 / 500 が出ているかを分ける。
対処方針
このエラーに対して、いきなりプラグインを大量に無効化したり、WAF を恒久的に無効化したりすると、原因が見えなくなります。まず失敗している REST API のリクエストと応答を確認し、どの層が JSON を壊しているかを切り分けます。
| 確認結果 | 対処 |
|---|---|
| 403 + WAF ログあり | 対象ルール、URI、パラメータを確認し、必要最小限の WAF 例外を作る。 |
| 500 + PHP ログあり | 原因のプラグイン、テーマ、PHP 設定を修正する。 |
| HTML エラーページが返る | リバースプロキシ、WAF、上流エラーのどこで差し替わったか確認する。 |
| REST API が 404 | パーマリンク、rewrite、AllowOverride を確認する。 |
| HTTP / HTTPS が混在 | siteurl、home、プロキシヘッダー、TLS 終端を揃える。 |
まとめ
ブロックエディタの「返答が正しい JSON レスポンスではありません」というエラーは、WordPress の画面上では抽象的ですが、実際には REST API の応答が JSON として成立していないという具体的な問題です。
私の環境では ModSecurity が原因でしたが、重要なのは WAF を無効化することではありません。失敗した REST API リクエスト、HTTP ステータス、レスポンス本文、WAF ログ、PHP ログ、プロキシログを突き合わせ、どの層が JSON 応答を壊しているのかを確認することです。
WordPress の管理画面トラブルは、WordPress 本体だけで完結しないことがあります。特にブロックエディタは REST API を前提に動くため、WAF、リバースプロキシ、TLS、パーマリンク、PHP エラーまで含めて 1 つの公開経路として見る必要があります。
Related posts:
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
WordPress が wordpress.org に接続できない原因と切り分け方
WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する
WordPress の外部連携プラグインが重い原因 – 投稿時の同期処理を見直す
Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
WordPress のショートコード運用を見直す – 経過日数表示を例に本文と機能を分離する
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
WordPress で Google Analytics 4 を導入する理由 – アクセス解析を運用改善に使う
WordPress ブロックエディタを使う理由 – 記事構造と再利用性を高める
WordPress のスパムコメント対策 – コメント欄を開くリスクと運用設計
WordPress のパーマリンクを変更する手順 – 旧 URL を守るリダイレクト設計
WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針