WordPressの記事保存、バックアップ、外部ストレージ同期、デプロイ、REST APIで「423 Locked」が返ることがあります。保存を押しても進まない、特定ファイルだけ更新できない、別の処理が使用中と表示される症状です。
423は、対象資源がロックされているため処理できない状態です。ロックは変更を壊さないための保護であり、原因を見ずにファイルやロック情報を削除すると、進行中の更新や他者の編集を壊すおそれがあります。
ロックファイル、データベースのロック情報、外部サービスのトークンを推測で削除しないでください。まず処理中の担当、ロック範囲、正規の解除方法、有効期限を確認します。
先に結論：423エラーは8段階で確認する
- 編集中の本文、アップロード内容、同期対象を安全な場所へ退避する
- 保存・同期・削除の連打と自動再試行を止める
- URL、HTTPメソッド、時刻、対象ID、423、応答本文を記録する
- WordPress画面の投稿ロックか、HTTP 423かを分ける
- WebDAV、外部ストレージ、バックアップ、独自APIの発行元を特定する
- ロック所有者、対象範囲、トークン、有効期限、進行中処理を確認する
- 正規の終了・更新・解除手順を一つだけ実施する
- 保存結果、競合、重複、再ロックの有無まで確認する
更新内容同士の一般的な競合ならWordPressの409 Conflictを直す確認順、古いETag等の条件失敗ならWordPressの412 Precondition Failedを直す確認順が適切です。
423 Lockedとは？
RFC 4918の423 Lockedは、要求の送信元または宛先となる資源がロックされている状態です。応答本文の事前条件コードによって、必要なロックトークンが送られていない、競合するロックがある、といった理由を示せます。
423はWebDAVで定義されたステータスです。WordPress本体の投稿編集画面には別の「投稿ロック」機能がありますが、画面に他のユーザーが編集中と出ることと、HTTP応答が423になることは同じではありません。
WordPressは423というステータス名を認識できますが、標準の投稿保存が常に423を返すわけではありません。外部ストレージ、WebDAV対応プラグイン、バックアップ先、デプロイ基盤、独自REST APIが発行する場合があります。
ロックには所有者、対象URL、深さ、共有・排他、トークン、有効期限があります。見た目が同じ423でも、正規トークンの不足、他処理のロック、期限切れ、対象範囲の誤認で対処が変わります。
409・412・423・424の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 409 Conflict | 要求が対象の現在状態と競合する | 同時更新、重複、状態遷移 |
| 412 Precondition Failed | 要求ヘッダーの条件が成立しない | If-Match、ETag、更新日時 |
| 423 Locked | 対象または宛先の資源がロック中 | 所有者、範囲、ロックトークン |
| 424 Failed Dependency | 依存する別の処理が失敗した | 先に失敗した操作と対象 |
423が出たときは、「他の誰かがWordPress記事を編集中」と決めつけません。HTTP要求のURLと応答本文を見て、WordPress投稿、外部ファイル、コレクション、バックアップ、同期ジョブのどれがロックされたかを確認します。
WordPressで423が出る主な原因
1．WebDAVや外部ストレージの資源が別処理でロックされている
画像、バックアップ、書類、公開ファイルをWebDAVや外部ストレージへ保存する構成では、別の端末や同期処理が同じ資源をロックしている場合があります。ファイルだけでなく、親コレクションのロックが子資源へ及ぶこともあります。
同期アプリを複数端末で開いている、バックアップと復元が重なった、デプロイ中に管理画面から同じファイルを変更した場合は、進行中処理を先に確認します。
2．必要なロックトークンを送っていない
WebDAVでロックを取得したクライアントは、保護された資源を変更するとき、仕様に従ってロックを識別する必要があります。取得したトークンを保存していない、別URLのトークンを送る、引用符や形式を手編集すると423になります。
トークンを推測で作らず、ロックを取得した正規クライアントとAPI応答から再確認します。認証トークンやCookieと混同せず、公開チャットへ値を貼らないでください。
3．期限切れまたは更新に失敗したロック情報を再利用している
クライアント側に古いロック情報が残り、サーバー側では期限切れや再発行済みになっていると、見かけ上は所有者が同じでも更新できません。長時間のオフライン、アプリ強制終了、通信切断後に起きやすい状態です。
古いキューをそのまま再送せず、現在のロック状態と資源内容を取得し直します。編集内容は退避し、最新状態との違いを確認してから再適用します。
4．バックアップ・更新・デプロイ処理が終了していない
バックアップ作成、展開、復元、テーマ更新、デプロイが、対象ディレクトリやアーカイブを保護している場合があります。管理画面の表示が止まっていても、サーバー側では処理が継続している可能性があります。
ジョブログ、開始時刻、対象、進捗、完了・失敗状態を確認します。処理中にロックを削除したり、同じ復元を重ねて起動したりしません。
5．独自REST APIが業務ロックを423で表現している
予約枠、商品、注文、会員情報、編集ワークフローなどをプラグインが一時的にロックし、独自APIで423を返すことがあります。この場合、WebDAVのロックトークンではなく、業務上の所有者や状態遷移が応答本文に示される場合があります。
API仕様、エラーコード、リクエストIDを確認し、WebDAVの解除手順を流用しません。番号だけで解除方法を決めないことが重要です。
6．WordPress投稿ロックをHTTP 423と混同している
WordPress公式のwp_check_post_lock()資料では、別ユーザーが投稿を編集中か判定する仕組みが説明されています。これは編集競合を減らすWordPress機能であり、HTTP 423の発生を直接意味しません。
画面の「別のユーザーが編集中」とNetwork欄の423を別々に確認します。投稿ロックを無効化しても、外部ストレージやAPIが返す423は解決しません。
最初の10分で行う安全な初動
1．変更内容を退避し、再試行を止める
本文、ファイル、同期対象、設定変更を安全な場所へ退避します。自動同期、保存連打、再アップロード、再デプロイを一度止めます。同じ対象へ複数処理を重ねると、ロック更新や重複処理が増えます。
注文、決済、通知、公開処理を伴う場合は、423が出ても前回処理の一部が完了していないか確認します。画面表示だけで失敗と断定しません。
2．HTTP要求と画面メッセージを分けて記録する
Network欄で、423になったURL、メソッド、Request Headers、Response、リクエストIDを確認します。画面の文言、対象ファイル・投稿ID、発生時刻、利用端末、ログインユーザーも記録します。
ロックトークン、Authorization、Cookieには秘密値が含まれ得ます。相談時はヘッダー名の有無だけを示し、値は安全な提出方法が指定された場合だけ共有します。
3．進行中処理と別利用者を確認する
他の編集者、別端末、バックアップ、同期、デプロイ、外部アプリが同じ対象を使用していないか確認します。担当者が分かるなら、強制解除する前に処理状況と保存内容を確認します。
変更前にはWordPress更新前のバックアップ手順で戻せる状態を用意します。ただし、保存先自体がロック中なら、同じ場所への新規バックアップを重ねません。
どの層が423を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| WordPress編集画面 | 投稿ロック、更新者、リビジョン | HTTP 423ではなく画面上の競合か |
| テーマ・プラグイン | REST名前空間、独自ロック、ジョブログ | どの機能が423を生成したか |
| WebDAV・外部保存 | LOCK状態、範囲、所有者、トークン、有効期限 | 正規クライアントのロックか |
| バックアップ・デプロイ | 処理ID、対象パス、開始・終了状態 | 処理中または異常終了か |
| CDN・APIゲートウェイ | 応答ヘッダー、リクエストID、転送先 | WordPress到達前に返したか |
WordPress REST APIのRoutes and Endpointsでは、ルートとHTTPメソッドの組み合わせで処理先が決まります。まず失敗したルートの名前空間から、WordPress本体、プラグイン、外部サービスの担当を分けます。
URLが外部ドメインなら、WordPress本体のファイルを触る前にそのサービスのロック仕様を確認します。同じ423でも、独自APIがWebDAVとは異なる意味で使用している場合があります。
原因別の安全な直し方
1．正規の処理が完了するまで待ち、結果を確認する
バックアップ、復元、同期、デプロイが正常進行中なら、まず完了を待ちます。完了後に対象の現在内容、処理ログ、ロック状態を確認し、必要なら最新内容を取得してから操作を再開します。
待ち時間はサービス仕様と処理規模で異なります。推測の時間で強制終了せず、公式の進捗表示、ジョブログ、提供元サポートを使います。
2．ロックを取得したクライアントから正規に解除する
WebDAVクライアントや外部アプリがロックを取得した場合は、そのクライアントの終了・保存・解除機能を使います。別端末から同じトークンを推測して解除せず、所有者と対象範囲を確認します。
解除前に未保存の変更がないか確認します。ロックが親コレクションへ設定されている場合は、子ファイル一つだけを解除しようとしても解決しないことがあります。
3．期限切れ情報は最新状態から再取得する
サーバー側のロックが失効し、クライアントだけ古い情報を持つ場合は、編集内容を退避してから現在の資源とロック状態を取得し直します。新しいセッションで正規にロックを取り直し、差分だけを反映します。
キャッシュ全削除を先に行うのではなく、どのクライアントが何を保持していたかを記録します。再発防止にはロック更新と異常終了時の回復設計が必要です。
4．独自APIは応答本文の解除条件に従う
プラグインや業務APIが423を返す場合は、所有者、状態、再試行可能時刻、解除権限、管理画面の手順を公式資料で確認します。WebDAV用のLOCK・UNLOCK要求を勝手に送らないでください。
開発者は、423だけでなく、秘密値を含めずに原因コード、対象ID、現在の所有者、正規の再取得・解除方法を返すと、誤った強制解除を減らせます。
5．壊れたロックの強制解除は最後に限定する
所有者が存在せず、処理も終了し、公式手順で異常な残存ロックと確認できた場合だけ、管理者がバックアップ後に対象限定で解除します。データベース行やロックファイルを直接削除する前に、提供元の手順を確認します。
本番で試す前に、WordPressのテスト環境を作る手順に沿って、解除後の保存、同期、競合、再ロックを検証してください。
やってはいけない対処
- 進行中処理を確認せずロックファイルを削除する
- データベースのロック情報を直接消す
- ロックトークンを推測・改変・公開する
- 保存・同期・復元を何度も連打する
- 別ユーザーの未保存編集を確認せず強制解除する
- WordPress投稿ロックを無効化すれば423も直ると決めつける
- WebDAVと独自APIの解除方法を混同する
- 複数プラグイン、外部サービス、サーバー設定を同時に変える
復旧後の確認チェックリスト
- 対象の最新内容に必要な変更が残っている
- 他者や別端末の変更を上書きしていない
- バックアップ・同期・デプロイ処理が一つだけ完了している
- 同じ対象に不要なロックが残っていない
- 正規クライアントで取得・更新・解除ができる
- 親コレクションと子資源のロック範囲が正しい
- 古いトークンや送信キューを再利用していない
- 投稿ロックとHTTP 423を別々に確認した
- 注文・通知・公開処理に重複がない
- 通常操作で再ロックと解除が正しく働く
自力で直せないときに伝える情報
- 発生日時とタイムゾーン
- 対象URL、HTTPメソッド、対象ID・パス
- 画面メッセージと実際のHTTP 423
- 秘密値を伏せた応答本文、事前条件コード、リクエストID
- WebDAV・外部ストレージ・プラグインの名称と版
- ロック所有者、範囲、有効期限の確認結果
- 進行中のバックアップ、同期、デプロイ
- 別端末・別ユーザーでの利用状況
- すでに試した一変更と結果
WordPress投稿ロックならサイト管理者、プラグインの独自APIなら開発元、WebDAV・外部保存ならサービス提供元へ相談します。秘密のトークンや認証値は公開しないでください。
よくある質問
423は誰かがWordPress記事を編集中という意味ですか？
必ずではありません。WordPressの投稿ロックは別の仕組みです。423はWebDAVや独自API、外部保存先が資源ロックを示している場合があります。実際の要求URLと発行元を確認してください。
時間を置けば直りますか？
有効期限のある正常なロックなら直ることがありますが、処理が停止した残存ロックや、必要なトークン不足は待つだけでは直りません。進行状況と現在のロック状態を確認します。
ロックファイルを削除してよいですか？
対象と所有者を確認できない状態では削除しないでください。進行中処理や他者の編集を壊す可能性があります。提供元の公式解除手順とバックアップを優先します。
まとめ
423 Lockedは、対象または宛先の資源がロックされ、要求を処理できない状態です。WordPressでは投稿ロック、WebDAV、外部ストレージ、バックアップ、独自APIを分けます。
- 変更を退避し、再試行を止める
- HTTP 423とWordPress画面の投稿ロックを分ける
- 発行元、所有者、範囲、トークン、有効期限を確認する
- 正規クライアントまたは公式手順で終了・解除する
- 強制解除は異常な残存ロックと確認できた場合だけにする
423を邪魔なエラーとして壊すのではなく、誰のどの処理を守っているロックかを特定することが、変更を失わない復旧につながります。