よこやま良平
WordPressの投稿を保存しようとして「更新に失敗しました」「返答が正しいJSONレスポンスではありません」と表示され、REST APIの通信を見ると401または403になっている場合、最初に再インストールや設定変更をしてはいけません。先に、どのリクエストが、どの認証段階で拒否されたのかを確認するのが正解です。
401は主に「認証情報を確認できない」、403は主に「要求は理解したが許可しない」という応答です。ただし、WordPress本体、WAF、セキュリティプラグイン、サーバー設定のどこが返したかによって意味が変わります。番号だけで原因を決めつけないことが重要です。
- REST APIの401と403の違いを、WordPressの投稿保存に沿って判断できる
- Cookie認証、Nonce、Application Password、ユーザー権限の確認順が分かる
- WAFやセキュリティプラグインを安全に切り分ける方法が分かる
- 原因を広げず、下書き保存まで確認する手順を実行できる
- 再発防止に必要なログ、権限、例外設定の考え方が分かる
この記事では、管理画面のブロックエディターから保存できないケースと、外部ツールや自作プログラムからREST APIへ接続できないケースを分けて解説します。まずエラーの証拠を残し、認証、権限、通信経路の順に範囲を狭めます。
作業前には、データベースとファイルのバックアップを取得し、直前に変更したプラグイン、WAF、Basic認証、CDN、サーバー設定をメモしてください。公開記事を直接更新せず、可能ならステージング環境か新規の下書きで確認します。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPress REST APIの401・403エラーを最初に整理する
最初の結論は、HTTP番号だけでなく、失敗したURL、操作、レスポンス本文、発生時刻の4点を一緒に保存することです。この記録があれば、WordPressが拒否したのか、手前のWAFやCDNが遮断したのかを判断しやすくなります。
401と403は認証と許可の段階が違う
401 Unauthorizedは、リクエストに有効な認証が付いていない、認証情報が期限切れ、または認証方式が受け付けられない時に返りやすい応答です。管理画面では、ログインCookieとREST Nonceの組み合わせが崩れた場合に発生します。
403 Forbiddenは、ログイン済みでも投稿を編集する権限がない場合や、WAF・セキュリティ機能がREST APIの通信を禁止した場合に返ります。WordPressの権限エラーとサーバー側の遮断は対処が異なるため、レスポンス本文の確認が欠かせません。
実際には、プラグインが401と403を独自に返すこともあります。レスポンスがJSONなら、code、message、data.statusを控えてください。HTMLのアクセス拒否画面なら、WordPressに到達する前に遮断されている可能性が高まります。
失敗したREST APIのURLと操作を特定する
ブロックエディターの保存では、投稿用エンドポイントだけでなく、自動保存、リビジョン、ユーザー情報、設定取得など複数の通信が動きます。画面に一つのエラーが出ても、原因になった通信は別のURLかもしれません。
ブラウザの開発者ツールで「ネットワーク」を開き、赤く失敗した通信を選びます。Request URL、Request Method、Status Code、Responseの内容を記録し、画面を閉じる前にスクリーンショットも残してください。
- 失敗した操作と再現手順
- リクエストURLとGET・POSTなどのメソッド
- HTTPステータス401または403
- JSONのcode・message、またはHTML拒否画面の特徴
- 発生時刻と直前に行った設定変更
再ログインだけで直るかを一度だけ確認する
管理画面からの保存だけが失敗し、長時間ログインしたままだった場合は、別タブの作業内容を保存してから一度ログアウトし、通常のログイン画面から入り直します。Nonceの期限切れなら、これだけで回復することがあります。
ただし、何度もログインを繰り返すとログイン試行制限にかかり、別の403や429を招く場合があります。一度で改善しない時は再試行を止め、以降の確認へ進んでください。
WordPress REST APIの401エラーを認証から切り分ける
401エラーでは、利用している認証方式を最初に一つへ絞ります。管理画面のCookie認証と、外部アプリのApplication Password認証を混同すると、直すべき場所が分からなくなります。
WordPress管理画面のREST APIは、ログインCookieだけでは十分ではありません。通常はリクエストにX-WP-Nonceヘッダーまたは_wpnonce値が付与され、WordPressが正当な画面操作であることを検証します。
Nonceが空、期限切れ、別ユーザーのもの、キャッシュされた古い値であれば、rest_cookie_invalid_nonceなどの401が返ることがあります。ブラウザのネットワーク詳細でX-WP-Nonceが送信されているかを確認し、ページ再読み込み後に値が更新されるかを見ます。
CDNやページキャッシュが管理画面、wp-json、admin-ajax.phpをキャッシュすると、古いNonceや別セッションの応答が混ざります。管理画面と認証関連URLはキャッシュ対象から除外し、キャッシュ削除後に新規下書きで再確認します。
- WordPress管理画面へ通常ログインできるか
- ブラウザがログインCookieを送っているか
- X-WP-Nonceまたは_wpnonceが付いているか
- 管理画面やwp-jsonがCDNキャッシュ対象になっていないか
- 再ログイン後の新しいNonceでも同じ401になるか
外部アプリではApplication Passwordを通常パスワードと分ける
外部ツールや自作プログラムからREST APIへ接続する場合は、WordPress 5.6以降のApplication Passwordを使う方法があります。これは管理画面の通常パスワードとは別に発行し、HTTPS通信でAuthorizationヘッダーとして送ります。
401になったら、ユーザー名の表記、Application Passwordの入力、対象ユーザーが無効化されていないか、サーバーがAuthorizationヘッダーをWordPressへ渡しているかを確認します。通常パスワードをコードへ直書きして試すのは避けてください。
ホスティング環境、リバースプロキシ、Basic認証の設定によっては、Authorizationヘッダーが途中で削除されます。この場合は正しいApplication PasswordでもWordPress側に認証情報が届かず、401になります。サーバーログとPHP側の受信状況を管理者に確認します。
curl -i https://example.com/wp-json/wp/v2/users/me
# 認証情報はコマンド履歴へ直接書かず、安全なクライアント側で設定します。上の例はエンドポイントの応答ヘッダーを見るための形です。実サイトで認証を試す場合は、パスワードをターミナル履歴や共有ログに残さない仕組みを使い、検証後は不要なApplication Passwordを失効させてください。
認証プラグインと独自コードのフックを確認する
JWT、OAuth、独自トークンなどの認証プラグインを使っている場合、WordPress標準のCookie認証とは確認箇所が異なります。プラグインの有効期限、署名鍵、時刻ずれ、対象ルート、ヘッダー形式を公式仕様と照合します。
テーマや独自プラグインのrest_authentication_errorsフィルターが、全REST APIを一律に拒否しているケースもあります。コードを削除するのではなく、いつ追加されたか、ログイン済み管理者や必要なルートまで拒否していないかをステージング環境で確認します。
WordPress REST APIの403エラーを権限と遮断から切り分ける
403エラーでは、WordPressが権限不足として返したのか、WAFなどが通信内容を危険と判定したのかを分けます。JSONとHTMLのどちらが返ったかを見ると、調査の入口を決めやすくなります。
WordPressのユーザー権限と投稿状態を確認する
JSONレスポンスにrest_cannot_edit、rest_forbidden、sorry, you are not allowedなどの意味が含まれる場合は、対象ユーザーの権限を確認します。投稿の編集者、作成者、カスタム投稿タイプ、公開済み・非公開などの状態で必要な権限が変わります。
管理者なら必ず保存できると決めつけるのも危険です。マルチサイト、会員機能、権限編集プラグイン、カスタムロールによって、edit_posts、edit_others_posts、publish_postsなどの権限が変更されている場合があります。
独自RESTルートではpermission_callbackの実装を確認します。current_user_canで必要以上に強い権限を要求していないか、未ログイン時だけでなく正しいユーザーでもfalseになっていないかを、テスト用ユーザーで検証します。
- 原因不明のまま全ユーザーを管理者へ昇格しない
- permission_callbackを常にtrueへ変更しない
- 公開投稿をテスト用に直接上書きしない
- データベースの権限値をバックアップなしで編集しない
WAF・CDN・セキュリティプラグインの拒否を確認する
レスポンスがサーバー会社やCDNのHTML拒否画面で、WordPress形式のJSONではない場合は、WAFやCDNを優先して確認します。特定の本文、HTMLタグ、URL、HTTPメソッド、短時間の連続通信が攻撃として検知されることがあります。
WAFの検知ログで、失敗時刻、接続元IP、対象URL、ルールIDを照合します。『たぶんWAF』という理由だけで全体を無効化せず、まずステージング環境または管理者IPに限定した一時除外で再現性を確認します。
セキュリティプラグインは、REST APIの無効化、ユーザー情報の非表示、XML-RPC遮断、ログイン保護など複数の機能を持ちます。REST API全体を止める設定では、ブロックエディターやプラグイン連携まで動かなくなるため、必要なルートを確認してから調整します。
.htaccess・Basic認証・サーバー設定を確認する
サイト移転やセキュリティ強化の直後なら、.htaccessのアクセス制限、Basic認証、IP制限、リバースプロキシ設定を確認します。wp-jsonだけでなく、OPTIONSやPOSTだけが拒否されていないかも重要です。
外部ドメインのアプリから呼び出す場合、ブラウザは本通信の前にOPTIONSのプリフライトを送ることがあります。OPTIONSが403なら、WordPressの投稿権限より前にWebサーバーやCORS設定で止まっている可能性があります。
curl -i -X OPTIONS https://example.com/wp-json/wp/v2/posts
curl -i https://example.com/wp-json/この確認では、最初の応答コード、ServerやViaなどのヘッダー、Content-Typeを見ます。HTMLの403、JSONの403、プロキシ独自のエラーでは調べる場所が違います。公開環境で設定を変える前に、現在の.htaccessとサーバー設定を保存してください。
WordPress REST APIで投稿保存に失敗した時の確認手順
投稿保存の復旧は、証拠保存、影響範囲の確認、認証、権限、遮断機能、下書きテストの順で行います。一度に複数の設定を変えなければ、どの操作で改善したかを説明でき、再発防止にもつながります。
手順1：編集内容を退避して通信記録を残す
保存エラーが出たら、本文をローカルの安全なファイルへコピーし、タイトル、スラッグ、カテゴリー、タグ、アイキャッチもメモします。画面を再読み込みする前に、失敗したネットワーク通信とレスポンスを保存してください。
次に、同じブラウザで新規の短い下書きを作成し、保存できるか確認します。特定の記事だけ失敗するなら本文の内容、ブロック、サイズ、メタデータが関係し、すべての投稿で失敗するなら認証や環境全体の問題が疑われます。
手順2：サイトヘルスとREST APIの基本応答を確認する
WordPressの「ツール」からサイトヘルスを開き、REST APIやループバックリクエストの重大な問題が出ていないか確認します。サイトヘルスが正常でも特定ルートだけ拒否されることはあるため、結果は証拠の一つとして扱います。
ブラウザで/wp-json/を開き、WordPress REST APIの案内JSONが返るかを確認します。トップの案内が表示されても、投稿ルートのPOST権限が正常とは限りません。GET、OPTIONS、POSTを分けて考えてください。
手順3：直前の変更を一つずつ戻して再テストする
エラー直前にWAF、キャッシュ、CDN、セキュリティプラグイン、権限、.htaccessを変更したなら、バックアップを用意した上で一つだけ元へ戻します。再テストは毎回同じ新規下書き、同じユーザー、同じ操作で行います。
プラグイン停止を試す場合も、いきなり全停止はしません。ステージング環境で候補を一つずつ無効化し、REST API通信が正常化した時点の差分を記録します。本番しかない場合は、利用者が少ない時間帯と復帰手順を決めてから行います。
- 編集内容と現在設定をバックアップする
- 失敗通信のURL・応答・時刻を記録する
- 別の新規下書きでも再現するか確認する
- ログイン・Nonce・ユーザー権限を確認する
- WAF・CDN・プラグイン・サーバーログを照合する
- 候補を一つだけ変更し、同じ条件で再テストする
手順4：下書き保存と読み戻しまで確認する
画面に「保存しました」と出るだけで完了にせず、投稿一覧で状態が下書きになっているか確認します。編集画面を開き直し、本文、画像、カテゴリー、タグ、抜粋が欠けずに読み戻せることまで確認してください。
REST APIを使う運用なら、作成後に同じ投稿IDをcontext=editで取得し、statusがdraft、titleとcontent.rawが送信した値と一致するかを照合します。公開や予約をテスト値に使う必要はありません。
原因がWAFの誤検知だった場合も、除外後に一回保存できただけでは不十分です。通常の本文、画像を含む本文、カテゴリー・タグ変更、自動保存を順に試し、必要最小限の通信だけ許可されているか確認します。
WordPress REST APIエラーを再発させない運用
再発防止では、認証方式、権限、WAF例外、ログ保存を文書化します。直った時の設定だけでなく、なぜその設定が必要か、誰が変更できるか、異常時にどこを見るかを残すことが大切です。
認証情報と権限を用途ごとに分ける
管理画面の操作はCookieとNonce、外部連携は用途別のApplication Passwordなど、認証方式を分けます。管理者アカウントをすべての連携で使わず、投稿作成だけなら必要な権限に限定した専用ユーザーを検討します。
Application Passwordには利用目的が分かる名前を付け、不要になったものは失効します。通常パスワード、トークン、Nonceをソースコード、共有資料、チャット、アクセスログへ残さない運用も決めてください。
WAF例外はURL・操作・接続元を最小化する
WAFの検知を回避するためにサイト全体を除外すると、攻撃も通しやすくなります。対象URL、HTTPメソッド、管理者IP、検知ルール、期限を限定し、例外追加後も検知ログを監視します。
REST APIを使わないから全停止する、という判断も慎重に行います。WordPress管理画面、ブロックエディター、サイトヘルス、各種プラグインが内部で利用するため、公開読み取りだけを制限するなど目的に合う方法を選びます。
更新前テストと監視項目を決める
WordPress本体、テーマ、プラグイン、PHP、WAF、CDNを更新する前に、ステージング環境で投稿の新規作成、更新、画像アップロード、自動保存、予約投稿を確認します。更新後も同じチェックを行い、差分を記録します。
監視では401・403の件数だけでなく、対象URL、ユーザー、接続元、User-Agent、WAFルールIDを確認します。ログには個人情報や認証情報が含まれる場合があるため、閲覧権限と保存期間も決めてください。
現場では、エラーを消すための全体無効化より、拒否した層を特定して最小限の修正を行う方が安全です。原因と確認手順を残せば、担当者やサーバー会社へ相談する時も、調査を早く進められます。
WordPress REST APIの401・403エラーでよくある質問
管理画面へ入れても、REST APIリクエストに有効なNonceが付いていなければ401になることがあります。ページキャッシュ、長時間開いた編集画面、JavaScriptエラーで古いNonceが使われていないか確認してください。
外部アプリの場合はCookie認証ではなくApplication Passwordなど別の認証方式が必要です。どの方式を使っているかを先に整理します。
本番サイトでWAF全体を無効にするのは避けてください。検知ログで時刻、URL、ルールIDを確認し、ステージング環境や管理者IP、特定ルートに限定した一時例外で原因を確かめます。
案内JSONが開くことは、読み取り入口が動いている証拠にすぎません。投稿保存には認証、Nonce、ユーザー権限、POST通信が必要なので、実際の下書き作成と読み戻しまで確認してください。
必ずしも同じ原因ではありません。ネットワーク切断、JavaScriptエラー、サーバーの500系エラー、WAF、権限不足でも似た表示になります。開発者ツールで失敗した通信とレスポンスを確認して判断します。
WordPress REST APIの401・403エラー解決まとめ
WordPress REST APIの401・403エラーは、番号だけで設定を変えず、失敗URL、操作、レスポンス本文、発生時刻を先に残してください。401は認証方式、Cookie、Nonce、Authorizationヘッダーを、403はユーザー権限、WAF、セキュリティプラグイン、サーバー制限を中心に確認します。
- 編集内容と設定のバックアップを取得した
- 401・403を返したURLとレスポンスを保存した
- 認証方式、Nonce、ユーザー権限を順番に確認した
- WAFやプラグインの検知ログを時刻で照合した
- 変更は一つずつ行い、下書きで再テストした
- 保存後に投稿状態と本文を読み戻して確認した
自分で確認する時も、公開記事を直接更新したり、WAFや権限を広く緩めたりせず、新規下書きと限定的な変更で進めます。原因を特定できない場合は、通信記録、ログ、直前の変更、再現手順をまとめて専門家やサーバー会社へ相談してください。
WordPressの投稿保存エラーが自分で直せない時は
ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
- WordPressが真っ白画面
- WordPressがログインできない
- ホームページのマルウェアや乗っ取り
- サイトの表示くずれ
- エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します！
いまなら期間限定で
・30日間動作保証で安心!
・初期費・調査料 0円で安心!