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