WordPress REST APIエラーの直し方｜JSONと401

2026.10.30

WordPressのREST APIエラーは、応答の中身を見るのが近道です。

エディターの「返答が正しい JSON レスポンスではありません。」は、応答にJSON以外が混ざると出ます。

正しいアプリケーションパスワードで401になるなら、疑うべきは認証のヘッダーがPHPまで届いているかどうかです。

エディターで保存できない方や、外部ツールからつなげない方向けの記事です。

画面と応答は、当方の検証用WordPress（WordPress 7.1.4、PHP 8.3、2026年10月30日）で再現しました。

仕組みの解説はWordPress REST APIとはに任せ、本記事は直し方に絞ります。

WordPress REST APIのエラーと原因の一覧

出ているメッセージやコードから、原因と最初に確かめることを引けるようにしました。

出ている症状・コード	主な原因	最初に確かめること
「返答が正しい JSON レスポンスではありません。」	応答にPHPの警告やHTMLが混ざっている	開発者ツールで応答の中身を見る
401 rest_not_logged_in（アプリケーションパスワードを使用）	認証のヘッダーがPHPに届いていない	.htaccessのHTTP_AUTHORIZATIONの1行
401 rest_cannot_create	ログインしていない、または権限が足りない	認証の方法とユーザーの権限グループ
403 rest_cookie_invalid_nonce	nonce（使い捨ての合言葉）が古いか違う	画面を読み込み直す、キャッシュの対象から外す
403（HTMLのエラーページ）	サーバーやセキュリティ機能が止めている	サーバーの設定とセキュリティプラグイン
404 rest_no_route	URLか送り方（GET・POST）が違う、ルートを作るプラグインが停止中	/wp-json/ のルートの一覧
404 rest_post_invalid_id	存在しないIDを指定している	投稿のID
400 rest_invalid_param	パラメーターの値や型が違う	応答のparamsに書かれた項目

コードとメッセージは当方の検証用WordPressで実際に返ったもの（HTMLの403ページを除く）

コードの頭の数字で大まかに分かれる

400は送った値の誤り、401は認証されていない、403は認証や確認で断られた、404は行き先が無いという意味です。

応答の本文が「code」「message」「data」を持つJSONなら、WordPressまで届いたうえで断られています。

本文がHTMLのページなら、止まった場所はWordPressより前のサーバーの段階か、壊れたWordPressの応答です。

日本語のメッセージは環境で変わる

メッセージの文は、サイトの言語設定によって英語と日本語が切り替わります。

検索するときは、メッセージの文よりも「rest_not_logged_in」のようなコードのほうが確実です。

まず応答の中身を見る

エラーの表示だけでは原因がわからないので、最初に応答そのものを見ます。

ブラウザーの開発者ツールで見る

エディターの画面でF12キーを押し、開発者ツールを開く
「ネットワーク」（Network）タブを開いた状態で、もう一度「保存」を押す
赤く表示された通信や、URLに wp-json を含む通信を選ぶ
「レスポンス」（Response）タブで、返ってきた本文の先頭を見る

本文の先頭が「{」で始まらず、HTMLのタグや英語の警告文で始まっていれば、JSONが壊れている状態です。

コマンドで確かめる

外部のツールからつなぐ場合は、curlで同じ要求を送ると、状態コードと本文をまとめて見られます。

curl -i https://example.com/wp-json/wp/v2/users/me
curl -i -u 'ユーザー名:アプリケーションパスワード' https://example.com/wp-json/wp/v2/users/me

1行目はログインしない状態、2行目はアプリケーションパスワードを付けた状態です。

example.comは自分のサイトのURLに置き換えます。

「返答が正しい JSON レスポンスではありません」の直し方

このメッセージは、エディターが受け取った応答をJSONとして読めなかったときに出ます。

当方の検証：PHPの警告が応答の先頭に混ざった

REST APIの処理中にPHPの警告（Undefined array key）を出すプラグインを作り、画面へのエラー表示（display_errors）を有効にした状態で試しました。

ブロックエディターで「保存」を押すと、画面の上に「更新に失敗しました。返答が正しい JSON レスポンスではありません。」と表示されました。

ブロックエディターの上部に「更新に失敗しました。返答が正しいJSONレスポンスではありません。」と出た画面 — PHPの警告が応答に混ざったときのブロックエディター（2026年10月30日、当方の検証用WordPressで撮影）

このときの応答は、JSONの前に警告文のHTMLが付いた形でした。

<br />
<b>Warning</b>:  Undefined array key "missing_key" in （ファイルのパス・省略） on line （省略）<br />
{ …ここから本来のJSON… }

先頭の数行が余計なだけでも、エディターは応答全体を読めなくなります。

プラグインを停止すると、同じ操作で保存できるようになりました。

サイトヘルスにも「REST API で予期しない結果」と出る

同じ状態で「ツール」→「サイトヘルス」を開くと、おすすめの改善に「REST API で予期しない結果が発生しました」が出ていました。

サイトヘルスのおすすめの改善に「REST APIで予期しない結果が発生しました」と表示された一覧 — サイトヘルスのおすすめの改善（2026年10月30日、当方の検証用WordPressで撮影）

エディターで保存を試す前に、サイトヘルスで気づけることもあります。

→ 関連：サイトヘルスの状態を改善する方法

WordPressは通常、JSONの要求では警告を表示しない

WordPress本体は、要求がJSONを求めているとき（AcceptやContent-Typeのヘッダーがapplication/jsonのとき）は、画面へのエラー表示を止める作りになっています（wp-includes/load.phpのwp_debug_mode）。

ブラウザーで /wp-json/ のURLを直接開いたときのように、JSONを求めない要求では、この仕組みは働きません。

このため当方の検証では、プラグインの中で表示を有効に戻して、警告が応答に出る状態を作りました。

本体の仕組みの外で文字が出力されると、同じようにJSONが壊れます。

プラグインやテーマが、処理の途中でエラー表示を有効に戻している
プラグインやテーマが、echoなどで余計な文字を出力している
セキュリティ機能やサーバーが、JSONの代わりにHTMLのエラーページを返している

上の2つは当方の検証と同じ「余計な出力」の仲間で、3つ目は後の「403」の節で扱います。

直し方は原因のプラグインを止めて、エラーはログに回す

手がかりは、応答に出ている警告文の中のファイルの場所です。

ファイルの場所がwp-content/plugins/の下なら、そのプラグインを停止するか更新して、保存できるかを確かめます。

原因がすぐに絞れない場合は、プラグインの競合を調べる手順で1つずつ切り分けます。

→ 関連：WordPressのプラグイン競合の調べ方

エラーを画面に出さずファイルに残す設定（WP_DEBUG_DISPLAYをfalseにする書き方）は、エラーログの場所と出力方法で説明しています。

401エラーの直し方（アプリケーションパスワード・未ログイン）

401は、WordPressが要求を送った人を確認できなかったときに返ります。

正しいアプリケーションパスワードでも401になった

当方の検証用WordPressは.htaccessを手で書いていたため、WordPressが書き出す1行が入っていませんでした。

その状態では、正しいアプリケーションパスワードを付けても、ログインしていないときと同じ401が返りました。

# .htaccessに1行が無いとき（正しいアプリケーションパスワード）
HTTP 401  {"code": "rest_not_logged_in", "message": "現在ログインしていません。", "data": {"status": 401}}

# 1行を足した後（同じパスワード）
HTTP 200

原因は、ブラウザーやツールが送ったAuthorizationヘッダーが、サーバーの段階で落とされてPHPまで届いていなかったことです。

.htaccessにHTTP_AUTHORIZATIONの1行を戻す

WordPress本体が書き出す.htaccessには、Authorizationヘッダーを受け渡す行が入っています（wp-includes/class-wp-rewrite.php）。

公式ドキュメントに載っている標準の.htaccessは次のとおりで、RewriteEngine Onの次の行がそれです。

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

出典：WordPress Developer Resources「Apache HTTPD / .htaccess」（2026年10月30日確認）

古い時期に作った.htaccess、手で書き直した.htaccess、プラグインが上書きした.htaccessでは、この行が抜けていることがあります。

書き換える前に、今の.htaccessを別名で保存しておくと安心です。

Nginxのサーバーや、別の書き方を使う場合の設定は、REST APIの公式FAQの「Why is Authentication not working?」に載っています。

出典：REST API Handbook「Frequently Asked Questions」（2026年10月30日確認）

パスワード違いとの見分け方

わざと間違えたパスワードを送ると、1行がある状態でも無い状態でも、同じ401 rest_not_logged_inが返りました（WordPress 7.1.4）。

つまり、応答のコードだけでは、パスワード違いとヘッダーが届いていない状態を見分けられません。

本体のコードにはincorrect_passwordというエラーもありますが、検証ではREST APIの応答には出てきませんでした。

アプリケーションパスワードを発行し直しても401が続くなら、ヘッダーが届いているかを疑います。

ログインせずに書き込もうとした場合の401

認証を付けずに投稿を作ろうとすると、別のコードの401が返りました。

POST /wp-json/wp/v2/posts（認証なし）
HTTP 401  {"code": "rest_cannot_create", "message": "このユーザーとして投稿を編集する権限がありません。", "data": {"status": 401}}

この場合は認証の付け忘れか、使っているユーザーに投稿の権限が無いことを確かめます。

SWELLの閲覧数の計測（swell-ct-pv）で出る401については、SWELLのREST API 401エラーの原因と解決方法をご覧ください。

403エラーの直し方（nonce・セキュリティ）

403は、要求は届いたものの、確認の段階で断られたことを示します。

「Cookie チェック失敗」はnonceが合っていない

ログインしたブラウザーから、誤ったX-WP-Nonceを付けて送ると、次の403が返りました。

HTTP 403  {"code": "rest_cookie_invalid_nonce", "message": "Cookie チェック失敗", "data": {"status": 403}}

ログインのCookieで認証する場合、WordPressはnonceという使い捨ての合言葉も一緒に確かめます。

公式ドキュメントによると、nonceを付けずに送った場合は、ログインしていても未ログインの要求として扱われます。

出典：REST API Handbook「Authentication」（2026年10月30日確認）

長く開いたままの画面や、ページキャッシュに古いnonceが残った画面から送ると、合言葉が合わなくなります。

画面を読み込み直しても続く場合は、そのページをキャッシュの対象から外せるかを確かめてください。

HTMLの403ページが返る場合

応答がJSONではなく、サーバー会社やセキュリティプラグインの403ページなら、WordPressより前の段階で止められています。

確かめる場所は、サーバーのWAF（攻撃を防ぐ仕組み）や、REST APIを制限するセキュリティプラグインの設定です。

当方の検証用WordPressでは、WAFによる403は再現できなかったため、ここは一般的な見方として書いています。

なお、WordPressの公式FAQによると、REST APIそのものを止めると管理画面の機能が使えなくなるため、止めるべきではありません。

404・400エラーの直し方

404と400は、送った先や値が間違っているときに返ります。

rest_no_routeはURLか送り方の誤り

存在しないルートに送ると、次の404が返りました。

GET /wp-json/wp/v2/nothing-here
HTTP 404  {"code": "rest_no_route", "message": "URL とリクエストメソッドに一致するルートが見つかりませんでした。", "data": {"status": 404}}

URLの綴りのほか、GETとPOSTの取り違えでも同じコードになります。

プラグインが追加したルートなら、そのプラグインが停止していないかも確かめてください。

/wp-json/ 自体が404になる場合

/wp-json/ を開いてもHTMLの404ページになる場合は、パーマリンクの設定かサーバーの書き換えの設定を疑います。

公式ドキュメントが案内しているのは、この場合に ?rest_route=/ の形でURLを指定する方法です。

https://example.com/?rest_route=/

こちらで応答が返るなら、REST API自体は動いていて、URLの書き換えだけが止まっています。

出典：REST API Handbook「Key Concepts」（2026年10月30日確認）

IDやパラメーターの誤り

存在しない投稿IDや、型の違うパラメーターを送ると、次のように返りました。

GET /wp-json/wp/v2/posts/999999
HTTP 404  {"code": "rest_post_invalid_id", "message": "無効な投稿 ID です。", "data": {"status": 404}}

GET /wp-json/wp/v2/posts?per_page=abc
HTTP 400  {"code": "rest_invalid_param", "message": "無効なパラメータ: per_page", …}

400の応答には、どの項目がどう違うかが「params」に書かれているので、その項目を直します。