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