WordPressのフォーム送信、ブロック保存、会員登録、決済連携、REST APIで「422 Unprocessable Content」が返ることがあります。JSONの括弧や通信自体は成立しているのに、入力内容を処理してもらえない状態です。
422では、通信を何度もやり直すより、エラー応答に示された項目とAPIの入力条件を照合するほうが近道です。必須項目、値の型、文字数、許可値、項目同士の整合、参照先の存在を順に確認します。
検証を無効化したり、空欄を一律に0へ置き換えたりしないでください。表面上送信できても、誤った注文、壊れた会員情報、公開状態の不整合を後に残します。まず入力内容を安全に退避し、秘密情報を伏せたうえで、失敗した一項目を特定します。
先に結論：422エラーは8段階で確認する
- フォーム本文や編集中の内容を別の安全な場所へ退避する
- 同じ送信の連打を止め、操作、時刻、URL、HTTPメソッド、422を記録する
- 応答本文を開き、エラーコード、メッセージ、対象項目を確認する
- 422を返したのがWordPress、プラグイン、外部APIのどこかを特定する
- 現行仕様で必須項目、型、形式、範囲、許可値を照合する
- 開始日と終了日など、項目間の矛盾や参照先の状態を確認する
- 原因候補を一か所だけ直し、テストデータで再送する
- 保存結果、関連画面、ログ、通知、重複登録の有無まで確認する
応答本文がなく、要求のJSON自体が壊れている疑いがある場合は、先にWordPressの400 Bad Requestを直す確認順を使います。送信形式やContent-Typeが対応外なら、WordPressの415 Unsupported Media Typeを直す確認順が適切です。
422 Unprocessable Contentとは？
RFC 9110の422 Unprocessable Contentは、サーバーが要求本文の種類を理解でき、構文も正しいものの、含まれる指示を処理できない状態です。外箱の形式は読めても、中身が業務ルールに合わない、と考えると分かりやすくなります。
たとえばJSONとしては正しくても、必須のメールアドレスが空、数量へ文字列が入っている、許可されていないステータスを指定した、終了日が開始日より前、といった内容なら処理条件に合いません。
ただし、WordPress本体が入力検証の失敗を必ず422で返すわけではありません。WordPress REST APIの公式例では、無効な引数が400として返るケースも示されています。422は、プラグインの独自エンドポイント、外部サービス、APIゲートウェイなどが採用していることも多いため、番号だけで発生元を決めつけないことが大切です。
400・409・415・422の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文や内容を処理できない | 壊れたJSON、URL、ヘッダー、一般的な入力不備 |
| 409 Conflict | 要求が対象の現在状態と競合する | 同時更新、古い版、重複、状態遷移 |
| 415 Unsupported Media Type | 要求本文の形式が非対応 | Content-Type、ファイル形式、エンコード |
| 422 Unprocessable Content | 形式は理解できるが指示内容を処理できない | 必須、型、範囲、許可値、項目間の整合 |
ステータス番号は原因の分類に役立ちますが、実装によって使い分けは異なります。実際の応答本文、エラーコード、失敗した項目、公式仕様をセットで確認してください。古いデータを上書きしようとしているなら、WordPressの409 Conflictを直す確認順へ進みます。
WordPressで422が出る主な原因
1．必須項目がない、空文字、nullになっている
画面では任意に見えても、API側では必須の項目があります。JavaScriptで非表示にした入力、条件分岐で消えた住所、空の配列、空文字とnullの違いが原因になることもあります。項目名が正しくても、値が「存在するだけ」では条件を満たさない場合があります。
ブラウザの入力欄だけでなく、実際に送信されたRequest PayloadまたはForm Dataを確認します。個人情報、パスワード、認証トークン、決済情報は画面共有や公開ログへ出さず、値を伏せて項目の有無だけを記録してください。
2．型・形式・範囲・許可値が合っていない
数値を求める項目へ"10"という文字列を送った、日付が指定形式と違う、メールアドレス形式を満たさない、最大文字数を超えた、列挙された候補以外を指定した、といった不一致です。画面上で同じ「10」に見えても、JSONでは数値と文字列が区別されます。
WordPress REST APIはJSON Schemaを使って、type、format、最小値・最大値、列挙値などを表現できます。推測で値を変えず、対象エンドポイントのスキーマまたはプラグインの現行資料を確認します。
3．項目同士の関係が矛盾している
個々の項目が正しくても、組み合わせで失敗します。開始日より終了日が前、セール価格が通常価格より高い、公開指定なのに公開日時がない、「配送不要」と「配送先必須」が同時に指定されている、といった状態です。
この種の条件は、単独項目のスキーマだけでは分からず、プラグインや外部サービスの業務ルールに実装されていることがあります。エラーメッセージに複数の項目名が出たら、項目ごとではなく関係性を確認します。
4．参照先の投稿・ユーザー・商品・状態が使えない
存在しない投稿ID、削除済みの商品、権限のないユーザー、無効化されたカテゴリー、すでに終了した注文などを指定すると、値の形は正しくても処理できません。入力画面を長時間開いたままにした後や、別担当が対象を変更した直後に起こりやすい原因です。
参照IDを推測で別の値へ置き換えず、管理画面または取得用APIで現在の存在と状態を確認します。対象が更新されて競合している場合は422ではなく409として返る実装もあります。
5．読み取り専用・自動生成の項目を送っている
ID、作成日時、計算済み合計、システム状態など、応答には含まれるものの更新要求では受け付けない項目があります。取得したJSONを丸ごと複製し、そのまま作成・更新へ送り返す処理で起こりがちです。
取得用の応答スキーマと更新用の入力スキーマは同じとは限りません。更新可能と明記された項目だけで小さな要求を作り、サーバーが生成する値を除外します。
6．プラグインや外部APIの更新で入力条件が変わった
昨日まで動いていた連携が更新後に422になった場合、必須項目の追加、許可値の変更、古いAPI版の終了、検証強化が考えられます。WordPress、プラグイン、テーマ、外部サービスを同時に更新していると、原因の境界が分かりにくくなります。
更新履歴、APIバージョン、対象エンドポイント、要求例を確認し、テスト環境で一変更ずつ比較します。安全な検証環境の作り方は、WordPressのテスト環境を作る手順も参考にしてください。
最初の10分で行う安全な初動
1．入力内容とエラー情報を別々に保存する
記事本文やフォーム入力は、ブラウザが閉じても失わない安全な場所へコピーします。次に、発生時刻、操作画面、URL、HTTPメソッド、422、応答のリクエストID、プラグイン名と版を記録します。保存できなかった内容と調査記録を混ぜないことが重要です。
応答本文にJSONがあれば、code、message、data、paramsなどを確認します。名称は実装ごとに異なりますが、「どの項目が、どの条件に違反したか」が書かれていれば、最優先の手がかりです。
2．再送前に前回処理の結果を確認する
422は通常、指示内容を処理できなかった応答ですが、外部決済、メール配信、在庫、Webhookが絡む処理では、周辺処理の一部だけが完了している可能性を捨てないでください。管理画面、注文番号、送信履歴、外部サービス側の記録を確認してから再送します。
ボタン連打や自動再試行は、入力条件が変わらない限り同じ失敗を繰り返します。さらに、実装の不備があると重複登録の原因になります。再現テストは、影響のないテストデータで一回ずつ行います。
3．成功した要求との差分を小さく比較する
同じエンドポイントで直近に成功した要求があるなら、秘密値を伏せて項目名、型、空欄、配列の形、日付形式、API版を比較します。大量の違いを一度に直すのではなく、エラーで指定された項目から見ます。
成功例をそのまま本番へ再送するのは危険です。ユーザーID、注文ID、nonce、トークン、日時などは使い回せません。比較に使うのは構造と条件であり、秘密値や一意の値ではありません。
どの層が422を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・アプリ | Request Payload、Form Data、画面検証 | 送信前に値が消えた、型が変わったか |
| CDN・WAF | 応答ヘッダー、イベント、リクエストID | WordPress到達前に独自ルールで拒否したか |
| WordPress REST API | ルート、引数スキーマ、応答コード | 標準の引数検証で失敗したか |
| テーマ・プラグイン | 独自エンドポイント、ログ、更新履歴 | 業務ルールや独自検証が422を返したか |
| 外部API | 外部側のリクエストID、API版、公式資料 | 決済、CRM、配信等の条件に違反したか |
WordPressのRESTルートは通常/wp-json/以下です。ブラウザのNetwork欄で要求URLと応答ヘッダーを確認し、WordPressのURLなのか、別ドメインの外部APIなのかを分けます。REST APIの応答表示自体が崩れている場合は、WordPressの「返答が正しいJSONレスポンスではありません」を直す手順も確認してください。
WordPress REST APIの独自エンドポイント資料では、引数ごとに必須指定、検証用validate_callback、整形用sanitize_callbackを設定できます。検証は「受け入れてよい値か」、整形は「安全な形へそろえる処理」であり、役割を混同しないことが大切です。
WordPress REST APIのSchema資料では、OPTIONS要求でエンドポイントのスキーマを調べられる場合があると説明されています。ただし、認証や権限が必要なルートへ無断で試行せず、運営者または開発者として許可された環境だけで確認してください。
原因別の安全な直し方
1．必須・空欄・nullを仕様どおりにそろえる
必須項目を追加し、任意項目は「省略」「空文字」「null」のどれを受け付けるか仕様で確認します。空欄だから0、false、現在日時を自動投入する、といった一律変換は意味を変えるため避けます。
条件付き必須項目では、画面の表示条件とAPIの検証条件を合わせます。たとえば「配送あり」を選んだときだけ住所を表示するなら、非表示時に古い住所を送らないこと、表示時には必須値が揃うことを両方確認します。
2．型・日付・文字数・許可値を修正する
要求本文を見て、整数、数値、真偽値、文字列、配列、オブジェクトが仕様と一致するようにします。日付はタイムゾーンを含むか、金額の小数桁、電話番号の記号、文字コードなども公式例と照合します。
許可値が列挙されている項目は、画面表示名ではなくAPIが求める値を送ります。たとえば日本語の「公開済み」ではなくpublishを求める実装があります。古い値を互換性の確認なしに新しい値へ自動変換しないでください。
3．項目間の条件と参照先を現在状態に合わせる
開始・終了、最小・最大、親・子、商品・在庫、投稿・カテゴリーなどを一組で見ます。参照先IDが存在し、必要な権限があり、受付可能な状態であることを確認します。現在状態を再取得してから入力画面を作り直すと、古い候補を送り続ける問題を避けられます。
別担当の更新で状態が変わった場合は、最新内容を確認して差分を統合します。現在版を無視して上書きするのではなく、競合なら409の手順に切り替えます。
4．送信項目を更新可能な最小構成にする
取得した応答全体を送り返している場合は、API資料で更新可能な項目だけを選びます。ID、リンク、作成日時、計算結果、埋め込み情報などの読み取り専用項目を除外し、目的に必要な値だけを送ります。
最小構成で成功したら、任意項目を一つずつ追加して境界を確かめます。本番データへ直接試すのではなく、バックアップと復元方法を用意したテスト環境で検証してください。
5．独自エンドポイントは検証結果を具体的に返す
開発者が独自REST APIを直す場合は、「入力が不正」だけで終わらせず、対象項目と満たすべき条件を、秘密情報を含めない形で返します。サーバーログにはリクエストIDを残し、利用者の画面と管理者のログを対応づけられるようにします。
rest_validate_value_from_schema()の公式資料を利用すると、WordPressのスキーマに沿った検証ができます。独自検証を追加するときも、認証・認可を先に行い、エラーへ機密値や内部構造を出しすぎない設計が必要です。
やってはいけない対処
- エラー本文を見ず、同じ内容を何度も再送する
- 入力検証や必須チェックを本番で無効化する
- 空欄、null、不明な値を一律に0や空文字へ変える
- 原因と無関係にContent-TypeやHTTPメソッドを変更する
- 成功例のトークン、nonce、注文IDをコピーして使い回す
- パスワード、個人情報、決済情報をログや相談文へ貼る
- 複数のプラグイン、コード、CDN設定を同時に変更する
- データベースを直接編集して検証だけを回避する
特に、GET・POST・PUT・PATCHを当てずっぽうに変えると、別の処理を実行したり405へ変わったりします。メソッドが疑わしいときは、WordPressの405 Method Not Allowedを直す確認順で、対象ルートの仕様を確認してください。
復旧後の確認チェックリスト
- 問題の操作が意図した成功応答になる
- 保存・登録された値が入力内容と一致する
- 必須、型、形式、範囲、許可値が現行仕様に合う
- 開始・終了など項目間の整合が取れている
- 参照先の投稿、ユーザー、商品が正しい
- 重複登録、重複メール、二重決済が起きていない
- 関連する管理画面と外部サービスの状態が一致する
- 検証や認可を弱める暫定設定が残っていない
- 秘密値を含む一時ログやスクリーンショットを適切に削除した
- 別ユーザー、別ブラウザ、通常の入力でも再発しない
公開ページのURL自体が422を返している場合は、フォームの失敗だけとして放置できません。Googleは、429を除く4xxを返すURLの内容を検索処理に使わず、継続すれば既存のインデックスから除外され得ると説明しています。通常の公開ページ、サイトマップ掲載URL、主要導線が200を返すことも確認します。
自力で直せないときに伝える情報
- 422が出た日時とタイムゾーン
- 操作した画面と対象URLまたはRESTルート
- HTTPメソッド、Content-Type、APIバージョン
- 秘密値を伏せた要求の項目名・型・構造
- 秘密値を伏せた応答コード、メッセージ、対象項目
- リクエストID、対象の投稿・商品・注文ID
- 直前に更新したWordPress、テーマ、プラグイン
- 成功する入力と失敗する入力の最小差分
- すでに試した対処と、その結果
相談先は、応答を返した層に合わせます。外部ドメインのAPIならそのサービス、プラグイン独自ルートなら開発元、WordPress到達前ならサーバー会社やCDNです。「WordPressで422が出る」だけでなく、上の情報を整理すると調査が進みやすくなります。
よくある質問
422はWordPress本体の故障ですか？
必ずしも故障ではありません。要求の形式は読めたものの、入力値が処理条件を満たさないときの応答です。WordPress本体、テーマ、プラグイン、外部APIのどこが返したかを先に特定します。
400と422はどう見分けますか？
一般には、要求を正しく解釈できない広い不備が400、形式を理解した後の内容上の不備が422です。ただし実装によって400へまとめることもあります。番号だけでなく、応答本文とAPI仕様を優先してください。
キャッシュ削除で直りますか？
古いJavaScriptや入力候補が残っている場合は改善することがありますが、必須項目や業務ルールの不一致はキャッシュ削除だけでは直りません。先に失敗項目を特定し、キャッシュは更新前後の差が疑われるときに対象を限定して消します。
プラグインを全部停止してよいですか？
本番で一括停止すると、フォーム、決済、会員、セキュリティに別の影響が出ます。バックアップと復元手段を用意し、テスト環境で発生元の候補を一つずつ確認してください。
まとめ
422 Unprocessable Contentは、要求本文の種類と構文は理解できても、含まれる指示を処理できない状態です。WordPressでは必ず422になるとは限らないため、応答本文と発生元の確認が欠かせません。
- 入力内容を退避して再送を止める
- エラーの対象項目と発生元を特定する
- 必須、型、形式、範囲、許可値を現行仕様と照合する
- 項目間の矛盾、参照先、読み取り専用項目を確認する
- 一か所ずつ直し、保存結果と重複処理まで検証する
「形式は合っているはず」で止まらず、サーバーが処理できる内容になっているかを一項目ずつ確かめることが、安全で早い復旧につながります。