WordPressの記事保存、商品更新、会員登録、外部同期で「409 Conflict」が返ることがあります。要求の書き方が読めないのではなく、送った操作が対象データの現在状態とぶつかっている状態です。
典型例は、別の担当者が先に記事を更新した、同じ識別子のデータがすでにある、古い版を基に上書きしようとした、許可されない順序で状態を変えようとした場合です。最新状態を取得し、差分を確認してから統合または再実行します。
409が出た直後に「もう一度保存」を連打したり、最新データを強制上書きしたりしないでください。相手の変更を消すだけでなく、注文、在庫、通知などを重複させるおそれがあります。まず自分の内容を退避し、前回の処理結果と現在版を確認します。
先に結論：409エラーは8段階で確認する
- 編集中の本文や入力値を、別の安全な場所へ退避する
- 保存・送信の連打と自動再試行を止める
- 操作、日時、URL、HTTPメソッド、対象ID、409を記録する
- 前回の要求が一部または全部成功していないか確認する
- サーバーから対象データの最新状態と版情報を取得する
- 自分の送信版と現在版の差分、重複、状態遷移を確認する
- 残す変更を統合し、原因候補を一か所だけ修正する
- テスト送信後、関連データと重複処理の有無まで確認する
JSONやURL自体が不正ならWordPressの400 Bad Requestを直す確認順、許可されていないGET・POST・PUT等を送ったならWordPressの405 Method Not Allowedを直す確認順へ切り替えます。
409 Conflictとは？
RFC 9110の409 Conflictは、要求が対象リソースの現在状態と競合するため完了できない状態です。利用者が競合を解消して再送できるよう、サーバーは原因を判断するのに十分な情報を返すべきだと説明されています。
RFCは、PUTで以前の版を基に更新しようとしたところ、その間に第三者の変更が入ったケースを例にしています。この場合は、どちらかを無条件に消すのではなく、履歴と差分を確認して内容を統合してから再送します。
WordPressには投稿ロック、自動保存、リビジョンなど、同時編集による損失を防ぐ仕組みがあります。ただし、WordPress本体の同時編集表示が必ずHTTP 409として現れるわけではありません。409はプラグインの独自REST APIや外部サービスが返すこともあるため、実際の要求先と応答本文を確認してください。
400・409・412・422の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文や内容を処理できない | JSON、URL、ヘッダー、一般的な入力不備 |
| 409 Conflict | 要求が対象の現在状態と競合する | 同時更新、重複、状態遷移、同期 |
| 412 Precondition Failed | If-Match等で指定した前提条件を満たさない | ETag、更新版、条件付き要求 |
| 422 Unprocessable Content | 形式は理解できるが指示内容を処理できない | 必須、型、範囲、項目間の整合 |
古い版を上書きしないためにIf-Matchを送り、ETagが変わっていた場合は412になるのがHTTPの条件付き要求としての整理です。一方、アプリケーションが独自に現在状態との競合を検出して409を返すこともあります。番号だけでなく、レスポンスの競合理由とAPI仕様を優先します。
要求の形式は正しいものの、入力値自体が条件を満たしていない場合は、WordPressの422 Unprocessable Contentを直す確認順を参照してください。
WordPressで409が出る主な原因
1．別の担当者やタブが先に更新した
同じ投稿を複数人、複数タブ、複数端末で開き、古い画面から保存すると、先に保存された変更とぶつかります。画面を開いてから長時間たった場合や、公開直前に校正と画像設定を並行した場合に起こりやすくなります。
「自分しか触っていない」と思っていても、自動保存、予約処理、外部編集アプリ、同期プラグインが更新している場合があります。対象投稿の更新日時、投稿者、リビジョン、REST要求を確認します。
2．同じスラッグ・メールアドレス・一意キーがすでにある
新規作成の要求でも、スラッグ、会員メールアドレス、商品コード、注文番号、外部IDなど、重複を許さない値が既存データと衝突すると409になる実装があります。削除済み・ゴミ箱・下書きのデータが同じ値を保持していることもあります。
値の末尾へ無意味な連番を足す前に、既存データが本当に別物か、前回の作成要求が成功済みではないかを確認します。同じ対象なら新規作成ではなく更新、別物なら運用ルールに沿った一意の値を決めます。
3．許可されない順序で状態を変えようとしている
注文を「未払い」から直接「発送済み」へ変える、期限切れの予約を承認する、すでに公開済みの処理を再度確定するなど、現在状態から許可されない遷移は競合として扱われることがあります。
送信したい最終状態だけでなく、現在状態と通るべき中間処理を確認します。管理画面で手動変更できるからといって、APIから同じ順序を省略できるとは限りません。
4．同じ要求・Webhook・一意キーを再送した
通信が遅いときにボタンを押し直す、タイムアウト後に自動再試行する、Webhookが重複配信されると、すでに処理済みの一意キーやイベントIDと衝突する場合があります。二重決済や二重登録を防ぐための正常な拒否である可能性もあります。
新しいキーで再送して回避する前に、元の要求が完了したかを確認します。注文、決済、メール、在庫、外部連携では、応答を受け取れなかっただけで処理は成功しているケースがあります。
5．双方向同期で双方が同じ項目を変更した
WordPressとCRM、EC、予約、表計算、翻訳サービスを双方向同期していると、両側で同じ項目を更新し、どちらを正とするか決められなくなることがあります。一方の更新がもう一方を呼び戻す循環もあります。
項目ごとの正本、更新時刻、同期方向、競合時の優先ルールを決めます。単純に「新しい時刻を優先」すると、時計ずれや遅延配信で誤判定するため、版番号やイベントIDも使って判断します。
6．復元・移行後に古い版情報を使っている
バックアップ復元、ステージングから本番への反映、キャッシュされた編集画面、オフライン編集の再接続により、クライアントが持つ版とサーバーの現在版がずれることがあります。対象IDは同じでも、更新日時やETag、内部の版番号が異なります。
復元直後に古いタブから保存せず、ログインし直して現在版を取得します。移行や更新の前には、WordPress更新前のバックアップ手順で、戻せる状態を用意してください。
最初の10分で行う安全な初動
1．自分の変更を退避し、保存の連打を止める
記事本文、商品説明、フォーム入力などを、ブラウザ外の安全な場所へコピーします。個人情報や秘密情報を含む場合は、共有範囲を限定した保存先を使います。退避できたら、同じボタンの連打と自動再試行を止めます。
操作時刻、対象URL、HTTPメソッド、投稿・商品・注文等のID、409、エラー本文、リクエストIDを記録します。複数タブを開いていたか、誰が同じ対象を編集していたか、直前に同期や復元を行ったかも残します。
2．前回処理が成功していないか確認する
一覧画面を別タブで開き直すか、取得用APIで対象を読み、更新日時と内容を確認します。新規作成なら、同じメールアドレス、スラッグ、注文番号、外部IDのデータがすでに存在しないか検索します。
決済や注文では、WordPress側だけでなく決済サービス側の取引IDを確認します。「画面がエラーだから失敗」と決めつけて再送すると、外部側だけ二重になる危険があります。
3．現在版・送信版・直前版の3つを比較する
現在サーバーにある内容、自分が送ろうとした内容、可能なら競合前の直前版を並べます。タイトル、本文、公開状態、カテゴリー、カスタムフィールド、更新日時、版番号を比較し、「誰の何を残すか」を決めます。
WordPressのリビジョンでは、保存された版を比較し、以前の状態を復元できます。自動保存もユーザーごとに保存され、公開済み内容を直接上書きしません。まず履歴を保全し、差分が理解できるまで復元や削除を急がないでください。
どの層が409を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・編集画面 | 開いていたタブ、自動保存、画面の警告 | 古い編集内容を送ったか |
| WordPress本体 | 投稿ロック、リビジョン、更新者、更新日時 | 別ユーザーの編集と重なったか |
| テーマ・プラグイン | 独自RESTルート、ログ、重複判定 | 一意値や業務状態が競合したか |
| 外部サービス | 外部ドメイン、取引ID、イベントID、API版 | 処理済み要求や外部状態と衝突したか |
| CDN・WAF | 応答ヘッダー、イベント、キャッシュ | 独自機能が返しているか。一般には優先度は低い |
ブラウザのNetwork欄で、409になった要求のURL、メソッド、Responseを確認します。/wp-json/以下でも、WordPress本体ではなくプラグインが登録したルートの場合があります。外部ドメインなら、そのサービスの状態と公式API資料を確認します。
WordPressのwp_check_post_lock()公式資料では、別ユーザーが投稿を編集中か確認する仕組みが説明されています。また、WordPressのRevisions公式資料では、保存済みリビジョンの比較と復元、自動保存の扱いを確認できます。
REST応答がHTMLへ変わる、保存時に「返答が正しいJSONレスポンスではありません」が併発する場合は、WordPressのJSONレスポンスエラーを直す手順も併用し、409の応答をWordPressまで正しく受け取れているか確認します。
原因別の安全な直し方
1．最新状態を読み直し、差分を統合する
最新の投稿やデータを取得し、自分の退避内容と比較します。相手の変更を残したまま、自分の必要な変更だけを適用した新しい版を作ります。本文だけでなく、タイトル、抜粋、カテゴリー、公開日時、カスタムフィールドも確認してください。
複数人で編集する場合は、担当箇所と保存順を決め、同じ投稿を同時に開きっぱなしにしない運用へ変えます。長時間編集では、保存前に最新状態を確認できる仕組みを使います。
2．重複データが同一対象か別対象かを判定する
同じスラッグや外部IDが見つかったら、作成済みの同一対象なのか、本当に別の対象なのかを確認します。同一なら既存IDへの更新へ切り替え、別物なら意味のある一意値を発行します。
ゴミ箱や非公開データも検索範囲に含めます。重複を解消するために既存データを削除する場合は、参照関係、URL、注文履歴、復元方法を確認し、バックアップなしで実行しないでください。
3．現在状態から許可された順序で遷移する
状態遷移の競合では、現在状態を取得し、次に実行できる操作をAPIまたはプラグインの仕様で確認します。承認、確定、発送、取消など、各段階で必要な権限と前提条件を満たしてから進めます。
管理画面の表示名とAPI値が違う場合があります。見た目で推測せず、現在値、遷移先、必要な中間処理をログへ残し、一段階ずつ確認します。
4．再送は冪等性と前回結果を確認して行う
作成・決済・通知などの再送では、同じ要求を複数回受けても結果が増殖しない「冪等性」の設計が重要です。APIが冪等性キーを提供しているなら公式仕様どおりに使い、応答を失っても同じキーで結果を照会できるようにします。
409を避けるために毎回新しいキーを作ると、別の処理として受け付けられ、重複する危険があります。元のキー、取引ID、イベントIDで処理結果を確認し、本当に未処理のときだけ再実行します。
5．同期の正本と競合ルールを決める
WordPressと外部サービスのどちらが各項目の正本かを決めます。たとえば本文はWordPress、在庫はEC、会員状態はCRMというように、所有元を分けると双方向の上書きを減らせます。
同期イベントには対象ID、版番号、更新元、発生時刻、イベントIDを持たせ、同じイベントを二度処理しないようにします。競合時に自動で片方を捨てず、人が差分を判断する保留状態も用意します。
6．条件付き更新を使い、意図しない上書きを防ぐ
APIがETagや版番号による条件付き更新に対応しているなら、取得した版を条件として更新します。サーバー側の版が変わっていれば拒否されるため、気づかず最新変更を消す事故を防げます。
RFC 9110のIf-Matchは、複数の利用者が同じリソースを保存する際の「更新消失」を防ぐ用途を説明しています。対応状況はAPIごとに異なるため、独自判断でヘッダーを足さず、公式仕様に従います。
やってはいけない対処
- 退避せずに画面を再読み込みし、自分の変更を失う
- 最新状態を見ずに強制上書きする
- 投稿ロックや競合検知を本番で無効化する
- リビジョンや自動保存を確認前に削除する
- 409を避けるため、一意キーを毎回変えて再送する
- 決済、注文、通知のボタンを連打する
- 重複データを参照関係の確認なしに削除する
- 同期元と同期先を同時に手作業で修正する
- 複数のプラグインとAPI設定を一度に変更する
409は、データを守るために処理を止めている場合があります。エラーを消すことだけを目的に競合検知を外すと、静かに変更が失われるため危険です。競合理由を解消し、安全機構を残したまま成功させます。
復旧後の確認チェックリスト
- 現在版に必要な変更がすべて統合されている
- 別担当者の変更が消えていない
- 投稿、商品、会員、注文が重複していない
- スラッグ、メール、外部ID等の一意性が保たれている
- 状態が許可された順序で変化している
- 決済、在庫、通知、Webhookが二重実行されていない
- WordPressと外部サービスの状態が一致する
- 投稿ロック、リビジョン、条件付き更新が正常に働く
- 同期の循環や再試行ループが止まっている
- 別ユーザー、別タブ、通常の操作でも409が再発しない
公開ページのURL自体が409を返し続ける場合は、編集時だけの問題として放置しないでください。Googleは、429を除く4xxを返すURLの内容を検索処理に使わず、継続すれば既存のインデックスから除外され得ると説明しています。公開ページ、主要導線、サイトマップ掲載URLが200を返すことまで確認します。
自力で直せないときに伝える情報
- 409が出た日時とタイムゾーン
- 操作画面、対象URL、RESTルート、HTTPメソッド
- 投稿・商品・注文・ユーザー等の対象ID
- 秘密値を伏せた応答コード、メッセージ、リクエストID
- 送信版と現在版の更新日時、版番号、ETag
- 重複している可能性があるスラッグや外部ID
- 同時編集した担当者、タブ、同期サービス
- 直前の更新、復元、移行、プラグイン変更
- 前回処理の成功有無と、すでに試した対処
決済や外部同期では、問い合わせ前に秘密値を伏せ、取引IDやイベントIDだけを安全な窓口へ伝えます。応答を返したのがプラグインなら開発元、外部ドメインならサービス提供元、投稿編集の競合ならサイト管理者へ相談します。
よくある質問
409は待てば自然に直りますか？
短時間のロックなら解除後に進めることもありますが、古い版、重複、一意キー、状態遷移の競合は待つだけでは直りません。自分の内容を退避し、最新状態とエラー理由を確認してください。
投稿ロックを解除してもよいですか？
編集者が本当に作業中でないことを確認できた場合に限り、管理された手順で対応します。ロック表示だけを邪魔な機能として無効化すると、同時編集による上書き事故が増えます。
リビジョンを復元すれば解決しますか？
失った内容を戻す助けにはなりますが、競合の原因そのものが消えるとは限りません。復元前に現在版との違いを比較し、残すべき変更を統合してから、新しい一つの版として保存します。
キャッシュ削除は有効ですか？
古い編集画面やJavaScriptが残っている場合は役立つことがありますが、サーバー上の重複や版競合はキャッシュ削除だけでは解決しません。先に現在版を取得し、発生元を特定します。
まとめ
409 Conflictは、要求が対象データの現在状態と競合し、そのままでは完了できない状態です。WordPressでは同時編集、重複作成、状態遷移、再送、外部同期などを確認します。
- 自分の変更を退避し、再送を止める
- 前回結果と対象の最新状態を確認する
- 現在版、送信版、直前版の差分を比較する
- 重複、一意キー、状態遷移、同期元を確認する
- 必要な変更を統合し、安全機構を残して再実行する
409を「保存できないエラー」とだけ見ず、変更を失わないための競合通知として扱うことが、安全な復旧への最短ルートです。