【PR】この記事には広告リンクが含まれています。
WordPress REST APIへの投稿でサーバー側エラーが返ると、もう一度送れば直るように見えます。しかし、応答を受け取れなかっただけでWordPress側には投稿が残っている可能性があり、同じ新規作成を繰り返すと二重投稿の原因になります。
大切なのは、途中の成功表示を公開完了とみなさず、更新前後を同じ記事IDで照合することです。この記事では、5xxの限定再試行を既存のApps ScriptとWordPress REST APIの運用へ組み込む考え方を整理します。
運営者は、品質ゲートの誤検知を修正した後に複数記事を公開し、処理成功と実公開を分けて確認する運用へ変更しました。週次処理は記事ごとに例外を分離し、一つの記事が失敗しても正常な記事は継続する設計です。
最初に確認したい結論
- 5xxの限定再試行の対象と完了条件を先に固定する
- 管理表の記事IDを共通キーにする
- WordPressの現在状態を送信前後に取得する
- 失敗記事だけを再実行する
- 認証情報と個人情報を本文・ログへ出さない
- status・slug・URL・本文・featured_mediaを個別確認する
5xxが示す範囲を理解する
5xxが示す範囲を理解するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
再試行してよい条件を狭くする
再試行してよい条件を狭くするでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
Retry-Afterを確認する
Retry-Afterを確認するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
新規作成と更新を分ける
新規作成と更新を分けるでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
HTTPResponseから応答を観測する
HTTPResponseから応答を観測するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
待機時間と試行上限を決める
待機時間と試行上限を決めるでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
再送前に同じslugを検索する
再送前に同じslugを検索するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
成功応答後も同じ投稿を再取得する
成功応答後も同じ投稿を再取得するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
記事単位で失敗を分離する
記事単位で失敗を分離するでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
更新前の本文をバックアップする
更新前の本文をバックアップするでは、5xxの限定再試行の目的と確認対象を分けます。処理全体が動いたという表示だけで合格にせず、記事ID、WordPress投稿ID、slug、現在の状態、確認時刻を同じ記録へ結び付けます。対象を特定できないまま自動処理を続けません。
実行前は、スプレッドシートに保存された期待値とWordPressから取得した現在値を並べます。タイトルの見た目だけで同一と判断せず、変わりにくいIDと保存済みの対応関係を優先します。予定値や推測値は実績の列へ入れません。
実行後は同じ取得経路でもう一度読み、送信した値が保存されたかを確認します。リクエスト送信、WordPress保存、公開ページ表示を別工程にすると、途中で止まった場所を判定しやすくなります。
差異があれば、該当記事だけを安全に戻します。一時通信失敗は上限を決めて再試行し、認証、権限、入力不足、事実関係を確定できない問題では公開中の記事を変更しません。正常な記事はそのまま維持します。
5xxの限定再試行の実行チェックリスト
1. 応答コードと本文を記録する
この確認は「応答コードと本文を記録する」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
2. 投稿IDとslugで保存有無を調べる
この確認は「投稿IDとslugで保存有無を調べる」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
3. 一時障害と恒常エラーを分ける
この確認は「一時障害と恒常エラーを分ける」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
4. 待機時間と上限を適用する
この確認は「待機時間と上限を適用する」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
5. 再送後に同じ投稿を取得する
この確認は「再送後に同じ投稿を取得する」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
6. 失敗記事だけをキューへ戻す
この確認は「失敗記事だけをキューへ戻す」の証拠を残すために行います。前段が合格していても、この結果がなければ5xxの限定再試行の完了にはしません。記事IDと対象投稿を明示し、別の記事の結果を流用しません。
作業前には入力元、実行条件、想定出力を確認します。状態が想定外なら、その場で新規作成や上書きを選ばず、取得できた事実と停止理由を記録します。
作業後には応答コードだけでなく、WordPressが保持している値を再取得します。管理表と取得結果が一致してから次の工程へ進め、反映されていなければ対象工程だけをやり直します。
再実行時は、直前の試行回数、最終エラー、WordPress側の保存有無を確認します。同じ入力を無制限に送らず、上限へ達した場合はブロックとして原因確認へ切り替えます。
管理表へ残す項目
最低限、記事ID、処理種別、入力元、出力先、状態、WordPress投稿ID、slug、試行回数、最終エラー、次の処理、更新日時を分けて持ちます。自由記述だけにせず、機械が判定する状態は許可された値へそろえます。
観測値と判断値も分けます。HTTP応答、WordPressのstatus、本文長は観測値であり、公開可能、再試行対象、停止という結論は判断値です。根拠をたどれる形にすると、後から安全に再判定できます。
認証情報を守る
WordPressのアプリケーションパスワードや認証ヘッダーは、記事本文、スプレッドシート、通常ログへ記録しません。ログに必要なのは記事ID、投稿ID、処理名、短い原因、次の動作です。
外部サービスの応答全文を保存する場合も、資格情報、個人名、住所、内部パスが含まれないかを確認します。読者向け記事には実際の秘密値や管理画面の個人情報を掲載しません。
関連記事
複数記事の失敗分離、公開状態の再取得、重複slugの防止もあわせて確認してください。同じ検索意図の記事を複製せず、公開前品質、送信、再取得、復旧という役割に分けています。
WordPress運用の土台を確認する
自動投稿の安全策を整えても、公開先のWordPressが安定して動かなければ運用は続きません。運営者が利用しているエックスサーバーについて、現在のプランと仕様は申込み前に公式ページで確認してください。
確認した公式情報
画面や仕様は変更される可能性があるため、2026年10月17日に次の一次情報を確認しました。
まとめ
WordPress REST APIの5xxを限定再試行｜一時障害で二重投稿しない方法で重要なのは、送信できたことと公開状態が確定したことを分け、同じ記事IDで更新前後を照合することです。
5xxの限定再試行は単独の機能ではなく、入力検査、WordPress送信、再取得、管理表反映、限定再実行をつなぐ運用として設計します。未確認の体験や数字を足さず、公開後の取得結果を完了条件にしてください。
運用補足：応答コードと本文を記録する
応答コードと本文を記録するを定期処理へ組み込むときは、入力値を読む段階、外部へ書き込む段階、結果を再取得する段階を一つの関数へ隠さず、ログ上で区別します。途中で例外が起きても、どこまで完了したかが記事IDから追える状態を作ります。
正常系だけでなく、対象が見つからない場合、すでに完了している場合、別の実行が処理中の場合、取得結果が管理表と異なる場合を先に定義します。何もしない安全な終了も、理由を持つ正式な結果として扱います。
翌週の処理では前回の状態を読み、完了行を再選定しません。公開前の予定件数と公開後に確認できた件数を分け、処理対象がなかった実行を成功件数として加算しないようにします。
