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