ACQUA JOURNAL

WordPressのREST APIで保存・連携が失敗するとき｜要求・応答・権限・再送の確認表

公開日 2026年10月3日ホームページ育成・制作

WordPressで「更新に失敗しました」「返答が正しいJSONレスポンスではありません」と表示されたら、先に原稿を控え、失敗した操作と通信の応答を確認してください。エラー表示だけで原因を決めたり、同じ登録を何度も送ったりすると、保存済みのデータや重複が分かりにくくなります。

この記事は、更新担当者が整理する初動と、制作会社がREST APIの要求・認証・権限・保存結果を調べる仕事を分ける手順です。ブロックエディターと外部システムの連携では、使う認証や要求の経路が同じとは限りません。

1. 原稿を残し、失敗した操作を限定する

入力中の文章を控え、対象サイト、投稿や機能、操作、発生時刻、表示されたメッセージを記録します。下書き保存、公開、画像追加、外部からの登録など、どの操作で失敗したかを分けてください。

入力原稿、操作、対象と時刻を先に残す図 — 図1：原因を調べる前に、入力と起きた状態を記録します。

公開ページが見えることと、編集の保存に成功したことは別です。別端末・別権限では操作できるかなど、既に確認した条件を記録します。認証情報、Cookie、トークンを通常の問い合わせ文章へ貼り付けないでください。

原稿の回復と調査を同時に行う場合は、同じ投稿を別の担当が変更していないか確認します。原因が未確定の間に、テーマ切替・一括停止・URL設定変更を重ねません。

2. どの要求が、どこへ送られたかを見る

制作担当はブラウザーの開発者ツールでNetworkを開き、記録を開始して対象の操作を再現します。対象の要求についてURL、HTTPメソッド、送信した項目、開始時刻、応答を確認します。確認に使うデータと環境は、実業務へ影響しない条件を合意してください。

操作から要求先、送信項目、応答を追う通信の図 — 図2：画面のエラーと、実際の要求を対応づけます。

WordPress REST API公式ガイドでルートと対象を確認します。REST APIの入口はサイトの設置・配信構成により確認方法が異なります。別のサイトや試験環境へ要求していないか、転送された後の行先も照合してください。

外部連携の場合は、連携元の記録とWordPress側を同じ時刻で対応づけます。失敗のたびに認証や接続先を変える前に、現在の要求がどの工程まで届いたかを確認します。

3. HTTP状態と応答本文を一緒に読む

通信の状態コード、Content-Type、応答本文を確認します。JSONを期待する通信でHTMLのログイン画面、保護機能の案内、PHPの警告が返っている場合、JSONの表示エラーだけを見て投稿本文が不正と決めません。

状態コード、内容の種類、応答本文を別々に確認する図 — 図3：番号だけでなく、返った内容と行先を読みます。

確認する項目	記録する内容
要求	対象URL、メソッド、操作時刻、送った項目
応答	状態コード、Content-Type、行先、必要な本文
認証・権限	方式、対象ユーザー、必要な操作権限
保存の実体	対象ID、保存値、重複の有無
公開・業務	公開ページと連携先の結果、未確認

成功の状態コードでも、期待した項目が保存されたかは別に確認します。一方、通信が途中で途切れた場合は、サーバー側で処理が済んでいる可能性も含めて確認し、未保存と断定しません。状態コードの意味はMDNのHTTP応答コードも参照できます。

4. ログイン、認証、操作権限を分ける

WordPress公式の認証説明では、管理画面内のCookie認証、nonce、外部から使うアプリケーションパスワードなどが案内されています。管理画面へ入れたことだけで、すべてのAPI操作を実行できるとは判断しません。

ログイン状態、要求の認証、操作する権限を分ける図 — 図4：認証方式と、操作してよい範囲を照合します。

管理画面内の要求では、Cookieとnonceの扱い、期限や現在の画面の状態を確認します。外部連携では、HTTPS、対象アカウント、認証情報の受け渡しと保管、利用する方式を確認します。内部のnonceを外部システムへ固定して貼る方法に置き換えません。

操作権限は対象ユーザーと機能で判断します。原因が不明なまま全ユーザーを管理者へ昇格させたり、認証を無効にしたりしません。必要な操作と最小限の権限、終了時の解除方法を担当と確認してください。

5. 経路と独自実装を、変更履歴から調べる

保護機能、プロキシ、キャッシュ、サーバー、追加機能、独自のルートや保存処理などを、現在の構成と直前の変更から照合します。403なら必ずWAF、404なら必ずパーマリンク、という一つの原因に固定しません。

要求の経路と、保護・サーバー・独自処理の確認先を示す図 — 図5：直前の変更と応答を手掛かりに、調査対象を絞ります。

独自の投稿や入力項目を実装しているなら、公開するルート、受け付ける項目、権限確認、保存後の返答を確認します。更新画面の仕様票と合わせて、入力が空、既存データがない、権限が違う場合も試験項目へ加えます。

切り分けに設定変更が必要なら、対象と差分、試験、復元、承認を一組で準備します。試験環境ではデータ・メール・外部連携の隔離を確認し、本番の注文や通知を誤って送らないようにします。

6. 再送する前に、保存済みかを確認する

対象の投稿IDや連携の識別子、最新の編集値、処理記録を読み戻します。新規作成と既存更新を分け、既に作成されているものをもう一度新規登録しないよう確認してください。

保存値と処理記録を確認してから、再送の要否を判断する図 — 図6：応答が不明なときは、同じ作成を重ねる前に確認します。

外部システムでは、再試行をどう識別し、どこで二重登録を防ぐかを仕様として決めます。WordPressのすべてのエンドポイントが、同じ要求を再送すれば必ず一回だけ処理するとは考えません。

保存値を読み戻せない、結果が矛盾する場合は「状態不明」と残します。追加の書き込みを止め、識別子と要求・応答を調査担当へ渡してください。エラー表示だけを理由に、記事の作り直しや重複投稿をしません。

7. 修正後は編集・公開・連携の結果を別々に検収する

合意した修正を試し、同じ操作で保存値を確認します。正しい項目が保存され、既存データが保たれ、権限外の操作ができないことを、必要な条件で試験してください。

編集保存、公開表示、連携先の結果を別々に検収する図 — 図7：通信の成功だけで、仕事の完了を判断しません。

一般の閲覧者が開くページ、画像、一覧、サービス案内も確認します。通知や注文の連携では、受信・取り込み・担当の対応まで、合意した試験経路で確かめます。試験データの処理と権限の終了も記録してください。

制作会社の検収はWordPress実装を外注するときの確認表と合わせて、原本、差分、戻し方、試験結果、残る課題を引き継ぎます。

8. 更新担当の初動と、実装調査を分担する

更新担当は原稿、対象、操作と時刻、画面のメッセージを整理します。制作担当は要求と応答、認証と権限、経路、保存処理、重複と検収を調べます。すべての担当に通信やサーバーの設定変更を求める必要はありません。

原稿と現象の記録、通信と実装の調査、業務の検収を分担する図 — 図8：記録をそろえ、必要な調査と実装だけを依頼します。

AcquaにはWordPress実装、既存保存処理や表示の調査・修正、合意範囲の公開確認を相談できます。企業向けWeb制作・運用と制作会社向けWordPress実装・既存修正の現在の案内を確認してください。

相談窓口には対象URL、操作、発生時刻、直前の変更、保存済みかの確認結果をお知らせください。機密を含む記録は必要部分を選び、安全な共有経路を別に決めます。支援後は、一度の操作で必要なデータが正しく保存され、公開・連携結果と再試行の扱い、残る課題が分かる状態を目指します。

JSONエラーは本文の書き方が原因ですか？

画面の表示だけでは決まりません。対象の応答が何を返したか、行先や経路を確認します。

管理画面に入れるのにAPIが失敗するのはなぜですか？

ログイン、要求の認証、操作権限は別の確認です。使う方式と対象ユーザーを照合してください。

保存に失敗したら、もう一度押してよいですか？

まず保存値と処理記録を確認します。結果が不明な新規作成を繰り返さず、重複と状態を調べます。

WAFを止めれば解決しますか？

原因と影響を確認します。保護を一律に停止せず、必要な限定試験と復元を担当と合意します。