
この記事について
当ブログでは普段、ホームページ制作や運用をご検討中の方に向けた記事を掲載していますが、今回は少し趣向を変えて、WordPressを管理している方やWeb制作者向けの技術的な内容です。
Xserver上のWordPressで実際に発生したエラーについて、原因を調べた過程とXserverサポートからの回答をまとめました。同じ現象で困っている方のお役に立てればと思います。
WordPressの「外観」からウィジェットを編集し、「更新」を押したところ、次のエラーが表示されました。
エラーが発生しました。返答が正しいJSONレスポンスではありません。
このエラーは投稿や固定ページの保存時にも表示されることがあり、WAF、セキュリティプラグイン、REST API、Cookie、ユーザー権限、.htaccess、PHPエラーなど、さまざまな原因が考えられます。
今回も、XserverのWAFやREST APIアクセス制限を無効にし、関係しそうなプラグインを停止しましたが、ウィジェットを更新できませんでした。
そこで、Chromeの開発者ツールとcurlコマンドを使って通信内容を確認し、最終的にXserverへ問い合わせました。
結論からいうと、今回の原因は、2026年7月19日にXserverが実施したWordPressの重大な脆弱性に対する緊急対策でした。
Xserverが「/wp-json/batch/v1」への通信を遮断していた
今回の環境では、WordPressのブロック型ウィジェット編集画面を開くと、次のREST APIエンドポイントへの通信が行われていました。
/wp-json/batch/v1
しかし、この通信に対してWordPressのJSONではなく、Xserverの「403 Forbidden」ページが返されていました。
WordPress側はJSON形式の返答を期待しているため、HTML形式の403エラーページが返されると、次のメッセージを表示します。
エラーが発生しました。返答が正しいJSONレスポンスではありません。
つまり、今回のエラーはJSONファイルそのものが壊れていたのではありません。
WordPressが期待していたJSONとは異なるHTML形式のエラーページが、Xserverから返されていたことが原因です。
Xserverサポートから届いた回答
開発者ツールとcurlによる調査結果をまとめてXserverへ問い合わせたところ、サポートから次の趣旨の回答が届きました。
報告された事象は、2026年7月19日に公表したWordPressの重大な脆弱性に対する緊急対策の内容に関連していると見受けられる。
利用者からの反響を受け、希望する利用者には個別解除を実施している。
対象ドメインについて、担当部署が制限解除の要否を確認したうえで対応する。
この回答によって、今回のウィジェット更新エラーは、WordPressの設定ミスではなく、Xserverが実施したサーバー側の緊急対策に関連する現象であることが確認できました。
Xserverの公式発表にも、2026年7月19日午前6時30分ごろから、対象サーバーにおいて次のエンドポイントへの通信を遮断したことが記載されています。
/wp-json/batch/v1
また、batch v1を利用するプラグイン、テーマ、外部サービス連携、独自開発機能に影響が出ている場合は、対象ドメインを添えてサポートへ問い合わせれば、個別に制限解除を検討すると案内されています。
Xserver「WordPressの脆弱性に関する注意喚起とサーバー側対策のお知らせ」
REST APIとは
REST APIとは、WordPressのデータを取得したり、更新したりするための通信窓口です。
「API」という言葉は外部サービスとの連携を想像しやすいのですが、WordPressの管理画面内部でも日常的に利用されています。
たとえば、今回のブロック型ウィジェット編集画面では、おおむね次のような流れで処理が行われます。
- 管理画面でウィジェットを編集する
- ブラウザ内のJavaScriptがREST APIへ通信する
- WordPressが編集内容を保存する
- 処理結果をJSON形式で返す
投稿や固定ページのブロックエディター、ウィジェット、サイトエディターなども、REST APIを利用してデータを取得・更新しています。
そのため、REST APIを全面的に停止すると、外部サービスとの連携だけでなく、WordPress管理画面の一部機能も正常に動かなくなることがあります。
JSONとは
JSONは、プログラム同士がデータを受け渡すための形式です。
たとえば、正常なREST APIの返答は、次のような形式になります。
{
"id": "block-2",
"sidebar": "footer-widget-area",
"status": "updated"
}
一方、今回Xserverから返されたのは、次のようなHTML形式の403エラーページでした。
<!DOCTYPE html>
<html lang="ja">
<head>
<title>403 Forbidden</title>
</head>
JSONとHTMLはまったく異なる形式です。
WordPressはJSONが返されるものとして処理しているため、HTML形式のエラーページを受け取ると、「返答が正しいJSONレスポンスではありません」と判断します。
最初に確認したこと
今回の調査では、一般的なJSONエラーの原因を一つずつ確認しました。
Xserverのセキュリティ設定を確認
Xserverのサーバーパネルで、次の設定を一時的にOFFにしました。
- WAF設定
- IPアドレス制限
- 国外IPのダッシュボードアクセス制限
- REST APIアクセス制限
- ログイン試行回数制限
XML-RPC APIアクセス制限やwlwmanifest.xmlアクセス制限は、今回のウィジェット更新とは直接関係しません。
関係しそうなプラグインを停止
セキュリティ、キャッシュ、REST API制限などに関係しそうなプラグインも停止しましたが、改善しませんでした。
Cookieを削除して再ログイン
対象ドメインのCookieを削除し、WordPressからログアウトしたうえで再ログインしましたが、結果は変わりませんでした。
.htaccessを確認
WordPressをインストールしているディレクトリの.htaccessは、次のような標準的な内容でした。
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /sample/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /sample/index.php [L]
</IfModule>
# END WordPress
REST APIへのアクセスを許可する次の記述も試しました。
SetEnvIf Request_URI ".*" AllowRestApi
しかし、/wp-json/batch/v1への通信は引き続き403 Forbiddenになりました。
今回の遮断は、利用者がサーバーパネルや.htaccessから変更できる通常のREST API制限とは別に、Xserver側で実施されていたためです。
Chromeの開発者ツールで403エラーを確認
Chromeの開発者ツールを使って、ウィジェット更新時の通信を確認しました。
- WordPressの「外観」から「ウィジェット」を開く
F12キーを押す- 「ネットワーク」タブを開く
- 「Fetch/XHR」を選択する
- ウィジェットの「更新」を押す
- 赤色で表示された通信を確認する
失敗していた通信は、次のような内容でした。
リクエストURL:
https://example.com/wp-json/batch/v1?_locale=user
リクエストメソッド:
OPTIONS
ステータスコード:
403 Forbidden
「レスポンス」タブを確認すると、WordPressのJSONエラーではなく、Xserverが生成したHTML形式の403 Forbiddenページが表示されました。
この時点で、WordPressのユーザー権限、Cookie、nonceなどの認証問題ではなく、WordPressの処理へ到達する前にサーバー側で拒否されていることが分かります。
OPTIONSリクエストとは
今回403 Forbiddenになっていたリクエストメソッドは、更新内容を送信するPOSTではなく、OPTIONSでした。
OPTIONSは、そのREST APIエンドポイントがどのような処理に対応しているか、どのHTTPメソッドを利用できるかなどを確認するために使われます。
今回のウィジェット編集画面では、/wp-json/batch/v1に対してOPTIONSリクエストが送信されていました。
しかし、その確認通信がXserver側で403となったため、ウィジェット編集画面は正常なREST API情報を取得できませんでした。
curlコマンドでも確認
ブラウザ固有の問題ではないことを確認するため、Windowsのコマンドプロンプトからcurlコマンドを実行しました。
curl.exe -i -X OPTIONS "https://example.com/wp-json/batch/v1"
結果は次のとおりです。
HTTP/1.1 403 Forbidden
Server: nginx
Content-Type: text/html
REST APIの別形式でも確認しました。
curl.exe -i -X OPTIONS "https://example.com/?rest_route=/batch/v1"
curl.exe -i -X OPTIONS "https://example.com/index.php?rest_route=/batch/v1"
いずれもXserverの403 Forbiddenページが返されました。
一方、通常のテキストファイルに対するOPTIONSリクエストは200 OKでした。
curl.exe -i -X OPTIONS "https://example.com/license.txt"
HTTP/1.1 200 OK
Allow: OPTIONS,HEAD,GET,POST
WordPressのindex.phpに対するOPTIONSリクエストも200 OKでした。
curl.exe -i -X OPTIONS "https://example.com/index.php"
この結果から、次のことが分かりました。
- OPTIONSメソッド全体が禁止されているわけではない
- PHPファイル全体が拒否されているわけでもない
/wp-json/batch/v1だけが選択的に403になっている
この挙動は、Xserverが公式発表しているREST APIのバッチエンドポイントへの通信遮断と一致します。
Xserverへ問い合わせた内容
ここまでの検証結果をまとめ、Xserverへ次のように問い合わせました。
WordPressのブロック型ウィジェット編集画面で更新できません。
以下のOPTIONSリクエストが、WordPressのJSONではなく、
Xserverの403 Forbiddenページを返します。
OPTIONS
https://example.com/wp-json/batch/v1
以下の設定はすべてOFFにしています。
・WAF
・IPアドレス制限
・国外IPのダッシュボードアクセス制限
・REST APIアクセス制限
.htaccessには以下も記載しています。
SetEnvIf Request_URI ".*" AllowRestApi
curlでも、/wp-json/batch/v1へのOPTIONSリクエストが
Server: nginxの403 Forbiddenになります。
OPTIONSメソッドがサーバー側で拒否されていないか、
設定状況をご確認ください。
これに対してXserverサポートから、今回の現象は2026年7月19日に公表したWordPressの重大な脆弱性に対する緊急対策に関連しているとの回答が届きました。
また、利用者からの希望に応じて個別解除を行っており、対象ドメインについて担当部署が解除の要否を確認したうえで対応するとのことでした。
なぜXserverはbatch v1を遮断したのか
2026年7月、WordPressのコア機能において、認証を必要とせず、第三者による任意のコード実行につながるおそれのある重大な脆弱性が公表されました。
Xserverは被害を防ぐための暫定措置として、攻撃経路となるREST APIのバッチエンドポイントへの通信をサーバー側で遮断しました。
/wp-json/batch/v1
これはセキュリティ対策として実施されたものですが、同じエンドポイントを正常に利用しているプラグイン、テーマ、外部サービス、独自機能などにも影響が出る可能性があります。
今回確認したサイトは、すでに修正版のWordPressへ更新していましたが、Xserver側の遮断は継続していたため、ブロック型ウィジェットを更新できませんでした。
対処法1:緊急対策によるbatch v1の制限か確認する
まず、今回のエラーが、2026年7月19日にXserverが実施した緊急対策によるものか確認します。
WordPressで「エラーが発生しました。返答が正しいJSONレスポンスではありません。」と表示されても、すべてが今回のXserverの制限によるものとは限りません。
WAF、セキュリティプラグイン、Cookie、.htaccess、PHPエラーなどでも、同じメッセージが表示されることがあります。
Chromeの開発者ツールでウィジェット更新時の通信を確認し、次のような状態になっているか調べます。
リクエストURL:
https://example.com/wp-json/batch/v1?_locale=user
リクエストメソッド:
OPTIONS
ステータスコード:
403 Forbidden
さらに「レスポンス」タブを開き、WordPressのJSONではなく、次のようなXserverのHTML形式の403エラーページが返されているか確認します。
<!DOCTYPE html>
<html lang="ja">
<head>
<title>403 Forbidden</title>
Windowsのコマンドプロンプトから、次のcurlコマンドでも確認できます。
curl.exe -i -X OPTIONS "https://example.com/wp-json/batch/v1"
次のような結果になれば、/wp-json/batch/v1への通信がXserver側で拒否されています。
HTTP/1.1 403 Forbidden
Server: nginx
Content-Type: text/html
この状態で、ブロック型ウィジェットなどのbatch v1を利用する機能が動作しなくなっている場合は、2026年7月19日に実施されたXserverの緊急対策による影響である可能性が高いと判断できます。
Xserverの公式案内では、batch v1のREST APIを利用するプラグイン、テーマ、外部サービス連携、独自開発機能に影響が生じている場合、希望する利用者について個別に制限解除を検討すると説明されています。
Xserver「WordPressの脆弱性に関する注意喚起とサーバー側対策のお知らせ」
Xserverへbatch v1の制限解除を依頼する
開発者ツールやcurlで確認した結果、/wp-json/batch/v1への通信がXserverの403 Forbiddenになっており、実際にウィジェットなどの機能へ影響が出ている場合は、Xserverサポートへ個別解除を依頼します。
公式案内では、解除を希望するドメイン名を添えて問い合わせるよう案内されています。
問い合わせ文は、次のような内容でよいでしょう。
WordPressのブロック型ウィジェットを更新すると、
「エラーが発生しました。
返答が正しいJSONレスポンスではありません。」
と表示され、更新できません。
開発者ツールおよびcurlで確認したところ、
OPTIONS
https://example.com/wp-json/batch/v1
への通信が、Xserverの403 Forbiddenになっています。
2026年7月19日に実施された緊急対策による
batch v1の通信制限の影響と考えられるため、
対象ドメインの制限解除をお願いいたします。
解除を希望するドメイン名:
example.com
必要に応じて、開発者ツールの画面やcurlの実行結果を添えると、状況をより具体的に伝えられます。
ただし、問い合わせの目的は原因調査を最初から依頼することではなく、今回の緊急対策によるbatch v1の制限であることを確認したうえで、影響が出ている対象ドメインの個別解除を依頼することです。
今回、実際にXserverへこの内容で問い合わせたところ、2026年7月19日に公表された緊急対策に関連する事象と見受けられるため、担当部署で対象ドメインの解除要否を確認するとの回答が届きました。
対処法2:従来型のウィジェット編集画面へ戻す
Xserverの対応を待たずにウィジェットを編集する必要がある場合は、ブロック型ウィジェット編集画面を従来型へ戻す方法があります。
使用中の子テーマのfunctions.phpなどへ、次のコードを追加します。
/* ブロック型ウィジェットエディターを無効化 */
add_filter( 'use_widgets_block_editor', '__return_false' );
追加後に「外観」から「ウィジェット」を開き直すと、従来型のウィジェット編集画面になります。
これはbatch/v1への制限を解除する方法ではありませんが、ブロック型ウィジェット画面を回避する応急処置になります。
WordPress本体も修正版へ更新する
WordPress本体の更新は、今回のウィジェット更新エラーを直接解除する操作ではありません。
Xserver側で/wp-json/batch/v1への通信が遮断されている限り、WordPress本体を更新しただけでは403 Forbiddenは解消しません。
ただし、Xserverが通信を遮断した理由は、WordPressの重大な脆弱性が公表されたためです。
そのため、Xserverへ制限解除を依頼するかどうかにかかわらず、使用しているWordPressの系列に応じて、次の修正版以降へ更新する必要があります。
- WordPress 6.8.xを利用している場合:6.8.6以降
- WordPress 6.9.xを利用している場合:6.9.5以降
- WordPress 7.0.xを利用している場合:7.0.2以降
Xserver「WordPressの脆弱性に関する注意喚起とサーバー側対策のお知らせ」
整理すると、WordPress本体の更新とXserver側の制限解除は、それぞれ目的が異なります。
- WordPress本体の更新:脆弱性を修正するための対策
- Xserver側の個別解除:batch v1を利用する機能を再び動かすための対応
「rest_cannot_manage_widgets」の401は別の問題
調査中、ブラウザで次のURLを直接開くと、401エラーが表示されることがありました。
https://example.com/wp-json/wp/v2/widgets
{
"code": "rest_cannot_manage_widgets",
"message": "このサイトのウィジェットを管理する権限がありません。",
"data": {
"status": 401
}
}
この表示だけで、WordPressの管理者権限が壊れているとは判断できません。
WordPress管理画面からREST APIへ通信する場合は、ログインCookieのほかに認証用のnonceなどが利用されます。
URLをアドレスバーへ直接入力した場合は、ウィジェット編集画面から送られる通信と同じ認証条件にならないため、401が返ることがあります。
重要なのは、URLを直接開いた結果ではなく、ウィジェットの「更新」を押した瞬間に失敗した通信のレスポンスです。
今回の場合は、WordPressのJSONではなく、XserverのHTML形式の403 Forbiddenページが返されていたことが原因特定の決め手になりました。
同じJSONエラーでも原因は一つではない
「エラーが発生しました。返答が正しいJSONレスポンスではありません。」というメッセージは、今回のXserverの制限だけで発生するものではありません。
一般的には、次のような原因でも表示されます。
- WAFによる遮断
- セキュリティプラグインの誤検知
- REST APIアクセス制限
- WordPressアドレスとサイトアドレスの不一致
- HTTPとHTTPSの不一致
- Cookieやnonceの認証エラー
.htaccessやパーマリンクの問題- PHPの致命的エラー
- サーバーからHTML形式のエラーページが返されている
そのため、エラーメッセージだけで原因を決めつけず、開発者ツールの「ネットワーク」と「レスポンス」を確認することが重要です。
まとめ
WordPressのウィジェットを更新した際に、次のエラーが表示されました。
エラーが発生しました。返答が正しいJSONレスポンスではありません。
開発者ツールとcurlコマンドで確認したところ、次の通信が403 Forbiddenになっていました。
OPTIONS /wp-json/batch/v1
返された内容はWordPressのJSONではなく、Xserverが生成したHTML形式の403エラーページでした。
さらにXserverサポートから、今回の事象は、2026年7月19日に実施したWordPressの重大な脆弱性に対する緊急対策に関連しているとの回答が届きました。
今回の重要なポイントは次のとおりです。
- Xserverが対象サーバーの
/wp-json/batch/v1への通信を遮断していた - WordPressがJSONではなくHTMLの403ページを受け取ったため、JSONレスポンスエラーが表示された
- WAFや通常のREST APIアクセス制限をOFFにしても改善しなかった
.htaccessへAllowRestApiを追加しても解除されなかった- Xserverへ対象ドメインの個別解除を依頼する必要がある
- 解除まで急ぐ場合は従来型のウィジェット画面で回避できる
- WordPress本体の更新は、今回のエラー解除とは別にセキュリティ対策として必要
Cookieの削除、プラグインの停止、WAFの無効化、.htaccessの変更を試しても改善しない場合は、Chromeの開発者ツールで失敗している通信を確認してください。
/wp-json/batch/v1へのOPTIONSリクエストが403となり、レスポンスにXserverのHTMLページが返されている場合は、今回と同じ緊急対策の影響を受けている可能性が高いと判断できます。
追記:CloudSecure WP Securityからbatch v1関連のエラー通知が届いた例
今回のXserver上のウィジェット更新エラーとは別に、ほかのWordPressサイトでCloudSecure WP Securityから、次のサーバーエラー通知が届いたことがありました。
Uncaught Error:
Call to undefined method WP_Error::get_method()
wp-includes/rest-api/class-wp-rest-server.php
スタックトレースには、REST APIのバッチ処理に関係する次の処理が含まれていました。
WP_REST_Server->match_request_to_handler()
WP_REST_Server->serve_batch_request_v1()
この通知は、WordPressがbatch/v1へのリクエストを処理している途中で、PHPの致命的エラーが発生したことを示しています。
ただし、この通知だけでCloudSecure WP Securityがエラーを発生させたとは判断できません。
CloudSecure WP Securityは、WordPress内部で発生したE_ERRORを検知し、管理者へメールで通知しただけの可能性があります。
また、この通知だけでは、次のような被害が発生したとは断定できません。
- サイトへ不正ログインされた
- サイトが改ざんされた
- マルウェアを設置された
- サイトへの侵入に成功された
異常な形式のREST APIリクエストや、脆弱性を調べる自動スキャンによってエラーが発生した可能性もありますが、接続元IPアドレス、User-Agent、アクセス先URLなどをアクセスログで確認しなければ原因は確定できません。
CloudSecure WP Security側でもbatch v1が遮断される場合がある
CloudSecure WP Securityでは、今回問題となったWordPressの脆弱性への対策として、REST APIのバッチエンドポイントへの通信を遮断する機能が追加されています。
そのため、Xserver以外のサーバーであっても、CloudSecure WP Securityを利用しているサイトで/wp-json/batch/v1が403 Forbiddenになる場合は、プラグイン側のセキュリティ対策によって遮断されていないか確認する必要があります。
ただし、今回この記事で紹介したXserver上のサイトでは、関係しそうなプラグインを停止しても403が続き、Xserverサポートからも緊急対策に関連する現象との回答が届いています。
したがって、今回のウィジェット更新エラーの直接的な原因は、CloudSecure WP Securityではなく、Xserver側のbatch/v1通信制限です。