GASでWordPressを4記事連続公開｜1記事失敗しても残りを止めない設計

【PR】この記事には広告リンクが含まれています。

Google Apps Script（GAS）からWordPressへ複数記事を送るとき、単にループでPOSTするだけでは安全な週次運用になりません。途中の1記事で例外が起きた場合、残りの記事まで処理されない、再実行で公開済みの記事を二重作成する、ログは成功でも公開ページが存在しない、といった事故が起こり得るためです。

筆者のブログでは、週次処理の上限を4本に設定し、1記事ずつ独立したtry/catchで処理しています。2026年8月15日には品質ゲートの誤検知で一部記事が止まりましたが、原因を修正して対象を再実行し、ART-008〜011の4本を公開しました。この経験から、重要なのは「4回POSTするコード」ではなく、「失敗を閉じ込め、公開済みを再利用し、各記事を公開後に再確認する仕組み」だと分かりました。

結論：4記事を4つの独立した処理単位として扱う

複数記事の安全な公開では、全体ループと記事単位処理を分けます。全体ループは対象記事を順に渡すだけにし、本文検査、既存投稿検索、画像登録、投稿更新、公開後確認、管理表更新は記事単位の関数へ閉じ込めます。1記事の例外はその記事の結果として記録し、次の記事へ進みます。

この構造にすると、最初の1本が失敗しても残り3本を処理できます。一方、エラーを無視してよいわけではありません。失敗記事はブロック状態にし、原因を直した後、その記事IDだけを限定再実行します。公開済み記事まで同じループで再作成しないことが重要です。

• 週次対象を最大4本へ絞る
• 記事IDを全シート共通キーにする
• 1記事ごとに検査・公開・再取得を完結させる
• 失敗は記事単位で記録し、残りを継続する
• 再実行前にslugと既存投稿IDを検索する

【実体験】一括成功表示では公開完了を判断できなかった

筆者の運用では、処理対象が0件でも関数自体は例外を出さずに終了できます。しかし、それを週4本公開の成功と扱うと、記事が1本も増えていないのに完了したように見えてしまいます。そこで、処理関数の終了と週次目標の達成を別の判定にしました。

また、ART-008〜011を扱った回では、本文中の注意書きに含まれる語句を未解決マーカーと誤認し、一部記事が品質ゲートで停止しました。停止自体は公開事故を防ぐ働きでしたが、正常な文章まで止めたため判定条件を狭め、停止記事だけを再処理しました。結果として、1記事の失敗で他の記事を止めない構造と、失敗記事を安全に戻す経路の両方が必要だと確認できました。

全体ループと記事処理関数を分離する

全体関数では、公開キューから条件を満たす記事を上限まで取得し、記事IDを一つずつ処理関数へ渡します。処理関数の戻り値は、成功なら投稿ID・URL・slug・公開状態、失敗なら記事ID・工程・エラーメッセージを含むオブジェクトにします。最後に全件の結果を集計すれば、4本中何本が公開され、何本がどこで止まったかを把握できます。

try/catchをループ全体の外側だけに置くと、最初の例外でループが終了します。記事単位のtry/catchは、エラーを隠すためではなく影響範囲を限定するためのものです。catch内では失敗状態を許可済みの値で記録し、詳細は別の列や実行ログへ残します。

function publishWeekly(items) {
  const results = [];
  items.slice(0, 4).forEach(item => {
    try {
      results.push(publishOneArticle(item));
    } catch (error) {
      recordBlocked(item.articleId, error.message);
      results.push({ articleId: item.articleId, ok: false });
    }
  });
  return results;
}

処理開始前にロックと冪等性を入れる

時間主導トリガーと手動実行が重なると、同じ記事を同時に処理する危険があります。Apps ScriptのLockServiceは、同じスクリプトやユーザー、ドキュメント内で処理を排他するための仕組みです。開始時にロックを取得し、終了時はfinallyで必ず解放します。

排他制御だけでは再実行時の二重作成を防げません。記事IDとslugを基に、管理表の投稿ID、WordPressの既存投稿、公開URLの順で検索し、既存投稿があれば新規作成ではなく更新します。同じ入力で何度実行しても同じ投稿へ収束する冪等性を持たせると、通信切断後の再実行が安全になります。

品質ゲートはWordPressへ送る前に完了させる

WordPressへ送信した後に重大な不備へ気づくと、公開停止、修正、更新、再確認の工程が増えます。本文長、H1重複、slug重複、PR表記、広告属性、内部リンク、画像、alt、SEO項目、一次情報マニフェストの照合は、POST前に終わらせます。

特に一人称と具体的な数字は、実体験DBの使用可レコードへ紐付けます。根拠がない数値は公開前に非数値表現へ直し、公式仕様は出典を分けます。品質ゲートは文字列の有無だけではなく、文脈とマニフェストの対応を検査する必要があります。

WordPress REST APIへの送信結果を保存する

WordPress公式のPosts APIでは、投稿作成と更新でtitle、content、slug、status、featured_media、categories、tagsなどを扱えます。GAS側ではUrlFetchApp.fetchでHTTPリクエストを送り、レスポンスコードとJSON本文を確認します。muteHttpExceptionsを利用する場合は、例外が出ない代わりに4xxや5xxを自分で判定しなければなりません。

送信直後のレスポンスから、投稿ID、status、slug、link、featured_mediaを取得して一時結果へ保存します。成功コードだけを見て完了にせず、返却JSONに必要項目があるか、意図したslugになっているかを確認します。HTMLやWAFのエラーページが返った場合にJSON解析を続けない分岐も必要です。

画像は記事本文とは別工程として失敗点を切り分ける

アイキャッチは、画像ファイルの取得、メディアAPIへのアップロード、alt設定、投稿のfeatured_media更新という複数工程があります。本文投稿が成功しても画像登録だけ失敗することがあるため、どの工程で止まったかを記録します。

筆者の運用では、画像のDrive ID、ファイル名、alt、用途を記事IDへ紐付けてから公開キューへ入れます。アップロード後に得たメディアIDを投稿へ設定し、投稿再取得時のfeatured_mediaが0ではないことを確認します。画像の見た目はAPI値だけでは判断できないため、公開ページの表示確認も残します。

公開後は同じ投稿をGETして照合する

POSTの成功と公開の成功は同じではありません。投稿IDを使ってGETし、statusがpublish、slugが予定値、linkが自ドメイン、content.renderedに本文が含まれ、featured_mediaが設定されているかを照合します。タイトル、カテゴリ、タグ、SEO・OGの反映も管理値と比べます。

さらに公開URLへアクセスし、HTTP 200と本文表示を確認します。リダイレクトで別slugへ移動していないか、404テンプレートが200を返していないかも注意します。API再取得と公開ページ確認を組み合わせることで、管理画面上の状態と読者が見る結果の両方を確認できます。

再試行は失敗記事だけに限定する

再試行対象は、公開済みの4本全体ではなく失敗した記事IDだけです。5xxや通信タイムアウトは少し間隔を置いて再試行し、400系は入力や認証を直してから実行します。原因が不明なまま同じリクエストを繰り返すと、二重投稿やサーバー負荷につながります。

筆者の現行運用では、軽微な不備を修正した後の限定再実行を最大2回としています。それでも失敗する場合は、認証、権限、サイト障害、事実関係の未確定を切り分け、記事をブロック状態にします。成功記事の投稿IDとURLは保持し、再処理しません。

Apps Scriptの実行時間とクォータを前提にする

Apps Scriptには実行時間や各サービスのクォータがあります。Google公式のクォータは変更される可能性があるため、固定値を記事やコードへ決め打ちせず、運用時点の公式ページを確認します。記事数を無制限に増やすのではなく、1回の上限を設け、画像処理や外部通信が長引いた場合に途中結果を失わない設計が現実的です。

各記事の開始・終了時刻、工程、HTTPコード、投稿IDを記録すると、時間超過が起きてもどこまで進んだか分かります。次回は未完了記事から再開し、公開済み投稿を更新またはスキップできます。ログは認証情報を含めず、運用判断に必要な最小限へ絞ります。

4記事公開の実務チェックリスト

コードが動くかだけでなく、キュー、原稿、画像、広告、公開後確認が同じ記事IDでつながっているかを確認します。順番を固定すると、担当者が変わっても確認漏れを減らせます。

• 公開済みと同じslugがない
• 使用可のEXP IDが1件以上ある
• 本文8,000字以上、重大エラー0
• PR表記と広告属性、計測ピクセルがある
• 内部リンクは公開済みページだけ
• 画像ファイル、alt、Drive IDがそろっている
• 投稿後GETでstatus・slug・本文・画像を照合した
• 公開URLがHTTP 200で表示される

本番前のドライランを用意する

本番公開と同じ入力を使いながら、WordPressへ書き込まず、対象記事、予定slug、本文長、画像ID、広告、内部リンク、既存投稿検索結果だけを出すドライランがあると安全です。公開予定4本が意図した順序で選ばれ、既公開記事が含まれないことを確認してから本番処理へ進めます。

ドライランの合格を本番成功とは扱いません。本番では認証、メディア登録、投稿更新、公開後GETが加わります。ドライラン結果と本番結果を同じ実行IDで結び、選定段階と公開段階のどちらで差が出たかを追えるようにします。

運用担当が確認する画面を減らす

自動化の価値はコード行数ではなく、公開後に必要な確認が短く明確になることです。各記事のタイトル、URL、使用EXP ID、案件、公開状態、画像、注意点を一つのサマリーへまとめ、詳細ログは異常時だけ開きます。

ただしサマリーは元データの代わりではありません。WordPress再取得とHTTP確認が合格した値から作り、処理開始前の予定値を成功結果として表示しないようにします。

コード変更と本番データ変更を分ける

公開トラブルへ対応するとき、コード修正と記事データ修正を同時に大量実施すると、どちらが効果を持ったのか分からなくなります。まず失敗工程を特定し、判定ロジックの誤検知ならコードとテストを直し、本文の実際の欠陥なら該当記事データだけを直します。変更点を一つの実行単位へ絞ります。

本番へ反映する前に、通過させたい正常例と停止させたい異常例でテストします。反映後の再実行は失敗記事IDだけにし、成功記事の投稿を再送しません。これにより、復旧作業自体が新しい重複や上書きを生むリスクを下げられます。

スプレッドシートの入力規則をコードと合わせる

記事状態や承認状態にドロップダウンの入力規則がある場合、コードが書く値もその選択肢へ合わせます。存在しないエラー状態を書こうとすると、公開エラーを記録する処理まで失敗し、原因が二重になります。許可値は設定として一元管理し、コード内へ同じ意味の別表現を増やしません。

詳細なエラー内容は状態列へ詰め込まず、次の処理やエラー詳細の列へ記録します。状態は集計しやすい短い値、詳細は人が原因を読める文に分けると、キュー抽出とトラブル調査の両方が安定します。

公開前スナップショットを残す

公開直前のタイトル、slug、本文、カテゴリ、タグ、画像ID、広告URL、内部リンク、SEO値を記事IDへ紐付けて保存します。投稿後の値が違ったとき、何と比較すべきかが明確になります。スナップショットには認証情報を含めません。

本文全体が大きい場合でも、保存先を一つに決め、他の表には記事IDと更新日時、文字数、ハッシュ、検査結果を残します。複数のタブへ異なる本文コピーを置くなら、どれを正本とするかを定め、公開時に古い原稿を拾わないようにします。

対象記事を選ぶ前の準備

公開関数の中で記事候補を無条件に先頭から4件取ると、未完成の原稿や既公開記事が混ざる可能性があります。候補抽出では、記事マスターが公開前の状態であること、WordPress下書きに本文があること、最終確認が合格であること、処理キューが実行可能であることを記事IDで照合します。4表のどれかが欠ける記事は対象から外し、理由を記録します。

並び順は優先度だけでなく、公開予定日、実体験の強さ、収益導線、内部リンクの受け皿を含めて決めます。同順位なら記事IDなど安定したキーで並べ、実行ごとに対象が変わらないようにします。抽出結果は処理開始前に確定し、途中でシートへ追加された候補を同じ回へ混ぜません。

記事単位の状態遷移を決める

記事は「候補」「原稿作成中」「品質確認済み」「公開キュー」「処理中」「公開済み」「ブロック」のように状態を進めます。許可されていない値をエラー記録で書くと、本来の失敗に加えて入力規則エラーが起きます。筆者の運用でも、エラー時に管理列へ許可外の値を書こうとする問題を見つけ、既存の許可値へ統一しました。

処理中のまま長時間残った記事は、前回実行の中断か、現在も別プロセスが動いているかを判定します。ロックの有無、最終更新時刻、WordPressの既存投稿を確認し、安易に新規作成へ進みません。状態遷移をコードと入力規則で一致させると、再開判断が安定します。

HTTPコードを工程別に扱う

WordPressへの通信では、2xx、4xx、5xxを同じ再試行ルールにしません。認証や権限の401・403、入力不備の400、存在しないIDの404は、同じ内容を繰り返しても改善しないことが多いため原因を直します。429や5xx、タイムアウトは一時的な可能性があり、待機後に失敗記事だけ再試行します。

レスポンス本文にはWordPressのエラーコードとメッセージが含まれる場合があります。ログへは機密情報を除いたHTTPコード、API工程、WordPress側コード、記事IDを残します。HTMLのWAF画面が返った場合はJSONエラーと区別し、サーバー設定やREST API制限を確認します。

4本を順次処理する利点

同時送信は短時間で終わる可能性がありますが、画像登録、投稿更新、再取得の依存関係や、記事ごとのログ順序が複雑になります。週4本という規模では、順次処理でも運用上の見通しを持ちやすく、失敗した記事の位置と原因を追いやすい利点があります。

順次処理でも、公式リンクの事前確認や画像ファイルの存在確認など、WordPressを書き換えない読み取り処理は公開前にまとめられます。ただし、記事作成そのものは記事IDごとの結果を確定してから次へ進み、投稿IDとURLの対応を取り違えないようにします。

再実行で新規作成か更新かを決める

失敗が投稿作成前なら新規作成、投稿ID発行後なら更新という単純な分岐だけでは不十分です。レスポンスを受け取る前に通信が切れた場合、WordPress側では作成済みかもしれません。再実行では、管理表の投稿IDが空でもslug検索を行い、同じslugの投稿があればそのIDを採用します。

公開済み投稿が見つかった場合は、予定本文や画像と一致するかを確認し、不足項目だけ更新します。内容が別記事なら自動で上書きせずブロックします。既存投稿の状態がdraftなら、記事IDやタイトルを照合した上で更新対象にします。この慎重な分岐が二重公開を防ぎます。

内部リンクは公開順を考えて確定する

同じ週の4記事を相互リンクすると、最初の記事を公開する時点でリンク先がまだ存在しないことがあります。公開前検査では、既に公開済みのURLだけを本文へ入れます。同週記事の相互リンクは4本すべての公開後に追加するか、公開順と存在確認を組み込んだ別工程にします。

本記事からは、基本的な実装を扱うGASとWordPress自動投稿の実運用、完了判定の失敗を扱う処理成功なのに公開されない問題、全体方針を扱うAIと自動化の品質運用へつなぎます。

成功件数と週次達成を別に集計する

実行結果は、対象件数、成功件数、失敗件数、スキップ件数を分けます。対象0件・成功0件は、エラーがなかったとしても週4本目標の達成ではありません。既に同じ週で4本公開済みなら「追加処理不要」、未達なら「不足」と判定します。

公開日はWordPressのdateと公開URLを基準に週を判定し、シートの予定日だけで公開済みと数えません。翌日に復旧した記事は実公開日を記録しつつ、どの未完了週の補充だったかを管理メモへ残すと、重複補充を防げます。

運用を止めないための最小ログ

詳細ログを増やしすぎると確認が難しくなります。最低限、実行ID、記事ID、開始時刻、終了時刻、工程、結果、HTTPコード、投稿ID、URL、再試行回数、エラー要約を残します。本文全文や認証ヘッダーは記録しません。

記事単位のログがあれば、成功3件と失敗1件を切り分け、失敗記事だけを復旧できます。週次サマリーは記事単位ログから集計し、サマリーだけを根拠に公開完了としません。最終判断はWordPressの再取得値と公開ページです。

よくある質問

Q. 4記事をfetchAllで同時送信すれば速くなりますか？
UrlFetchAppにはfetchAllがありますが、依存関係、レート制御、記事ごとの再試行、重複防止を考えると、速さだけで方式を決められません。筆者の実運用は記事単位の順次処理です。

Q. try/catchで囲めば安全ですか？
例外の影響範囲は限定できますが、二重投稿防止、入力検査、送信結果確認、公開後GET、ログ記録がなければ十分ではありません。

Q. HTTP 200なら公開完了ですか？
APIの対象投稿でstatus、slug、本文、featured_mediaを再取得し、公開URLの表示も確認します。200だけでは別ページやエラーテンプレートの可能性を除けません。

Q. 1本失敗したら週全体をやり直しますか？
いいえ。成功記事を保持し、原因を直した失敗記事IDだけを限定再実行します。

確認した公式情報

制度や仕様は変更される可能性があるため、2026年9月19日に以下の現行ページを確認しました。

• Google Apps Script公式：UrlFetchApp
• Google Apps Script公式：LockService
• Google Apps Script公式：サービスの割り当て
• WordPress公式：Posts REST API

まとめ

GASでWordPressへ4記事を連続公開するなら、ループより先に失敗単位を設計します。記事ごとのtry/catch、ロック、slugによる冪等性、公開前品質ゲート、投稿後GET、HTTP 200確認、限定再実行を一つの流れにします。

筆者の運用でも、品質ゲートの誤検知と再実行を経験したことで、処理の終了と公開完了を分ける必要性が明確になりました。4本を一つの大きな処理として扱わず、4つの独立した記事として最後まで照合することが、安全な週次自動公開の要点です。