WordPress自動投稿で「処理成功なのに公開されない」を防ぐ確認手順【GAS実例】

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

Google Apps ScriptからWordPressへ投稿したとき、実行ログに「成功」と出ても、読者が記事を読める状態とは限りません。API呼び出しが成功した、投稿データが作成された、WordPressでstatusがpublishになった、公開URLを第三者が開けた、アイキャッチや広告リンクまで正しく表示された。これらは別々の完了条件です。

筆者は週4本の自動公開を運用する中で、処理成功と実公開が同じではないことを経験しました。品質ゲートの誤検知で初回処理が止まり、実体験IDの紐付けなどを直したあと、ART-008〜011の4本を公開しています。以後は、4本すべてのURL、公開状態、公開時刻、サムネイルを記事ごとに確認し、1本でも未公開なら「4本公開完了」と報告しない運用へ変更しました。

この記事では、WordPress自動投稿が公開されないときに、GASの終了表示から先で何を確認するかを整理します。コード例は考え方を示すものであり、認証情報は含めません。WordPressやプラグイン、サーバーの構成によって返却項目が異なる場合があるため、公式REST API仕様と自分の環境を確認してください。

「処理成功」と「公開完了」を分ける

自動投稿の成功判定を一つにすると、途中まで進んだ状態を公開完了と誤認します。少なくとも次の5段階に分けます。

1. 送信成功：GASからHTTPリクエストを送れた
2. API成功：WordPressがエラーではない応答を返した
3. 投稿保存：投稿ID、slug、本文などが保存された
4. 公開状態：再取得したstatusがpublishである
5. 公開品質：URL、本文、画像、内部リンク、広告、SEO項目が期待どおりである

WordPress REST APIの投稿スキーマには、id、link、slug、status、title、content、excerpt、featured_media、categories、tagsなどがあります。POSTの応答だけでなく、返却された投稿IDを使ってGETし直せば、WordPress側に保存された状態を確認できます。

「例外が出なかった」は送信処理が最後まで走ったことしか示しません。対象記事が0件だった、下書きで作られた、slugが変更された、画像アップロードだけ失敗した、といった状態でも、コードの作り方によっては全体が成功扱いになり得ます。

【実体験】品質ゲート停止から4本公開まで

筆者の週4本公開では、品質ゲートが本文内の注意書きに含まれる特定語を未解決マーカーと誤認し、記事を止める問題が起きました。本文に問題が残っていたのではなく、「その言葉を残さない」と説明する正常な文章まで検知していたのが原因です。

初回停止後、検知条件と実体験IDの紐付けなどを修正し、再実行しました。その結果、ART-008〜011の4本を公開できました。ただし、実行ログの件数だけでは完了にせず、各記事のURL、公開状態、時刻、サムネイルを個別に確認しました。

この経験から、品質ゲートは厳しければよいのではなく、「本当に止めるべき状態」を検知する必要があると分かりました。一般的な単語が本文にあるだけで止めるのではなく、HTMLコメント内の保留表示、明確なプレースホルダー、空の必須項目など、文脈を含めて判定します。

最初に確認する7つの原因

1. 対象記事が選ばれていない：処理キューの状態、日付、最大件数、公開済み除外条件を確認します。
2. 品質ゲートで止まった：実体験ID、PR表記、内部リンク、未解決項目、本文長などのエラー内容を見ます。
3. 認証に失敗した：401・403などのHTTPコードとWordPressのエラーコードを記録します。
4. statusがdraftのまま：送信ペイロードと再取得結果のstatusを確認します。
5. 既存slugと衝突した：WordPressがslugを変えていないか、既存投稿を更新すべきでないかを確認します。
6. 画像だけ失敗した：media投稿の結果とfeatured_mediaのIDを確認します。
7. 公開ページがキャッシュ・制限で見えない：ログアウト状態や別ブラウザからURLを開きます。

原因を一度に推測せず、入力、送信、保存、公開、表示の順に確認します。エラー発生時に本文や認証情報を丸ごとログへ出すと情報漏えいにつながるため、記事ID、処理段階、HTTPコード、WordPressエラーコード、次の処理だけを記録します。

GAS側でHTTP応答を検査する

Apps ScriptのUrlFetchAppでWordPress REST APIを呼ぶ場合、例外処理だけに頼らず、HTTPステータスとレスポンス本文を確認します。概念的には次の順です。

const response = UrlFetchApp.fetch(endpoint, options);
const code = response.getResponseCode();
const data = JSON.parse(response.getContentText());

if (code < 200 || code >= 300) {
  throw new Error('WordPress API error: ' + code);
}
if (!data.id || !data.slug) {
  throw new Error('post identity missing');
}

実運用では、muteHttpExceptionsの設定によって例外の出方が変わります。HTTPコードが2xxでも、必要な投稿ID、slug、linkが返っていなければ次へ進めません。JSON解析に失敗した場合も、HTMLのエラーページやセキュリティ機能の応答を受け取っている可能性があります。

応答本文をログへ残すときは、認証情報、Cookie、個人情報、下書き全文を含めないようにします。調査に必要なフィールドだけを抽出します。

投稿後に必ずGETで再取得する

投稿作成・更新の応答だけで完了にせず、返却された投稿IDへGETを行います。再取得結果で次を照合します。

• status === "publish"
• slugが送信予定と一致する
• linkが期待するドメイン配下である
• タイトルと本文が対象記事のものになっている
• featured_mediaが0ではなく、期待する画像に対応する
• カテゴリとタグが設定されている
• 本文内の内部リンクと広告リンクが残っている

WordPress公式では、特定投稿の取得は GET /wp/v2/posts/<id>、作成は POST /wp/v2/posts、更新は POST /wp/v2/posts/<id> と案内されています。statusにはpublish、future、draft、pending、privateなどがあります。

slugだけで既存投稿を検索する場合は、公開済みだけでなく編集権限のある状態も含めて検索条件を確認します。同じslugの下書きがあるのに新規作成すると、WordPress側で末尾へ数字が付くことがあります。

公開URLをログアウト状態で開く

管理者としてログインしているブラウザでは、下書きや限定状態の投稿を見られる場合があります。そのため、公開確認はシークレットウィンドウ、ログアウト状態、または認証情報を持たないHTTP取得で行います。

確認するのは200応答だけではありません。ページタイトル、公開日、本文冒頭、アイキャッチ、カテゴリ、主要CTAを見ます。リダイレクトされた場合は、最終URLが期待するslugか確認します。404、410、パスワード入力、プレビュー用URLであれば公開完了にしません。

4本処理では、1本目から順にURLを記録します。最後に合計件数だけを見ると、同じURLを二重に数えたり、1本が下書きのままでも気づきにくくなります。

アイキャッチ画像を別の成功条件にする

記事本文が公開されても、アイキャッチが未設定、古い画像、文字被り、トリミング崩れなら公開品質は未完了です。筆者の運用では、公開後に各記事のサムネイルを個別に確認します。

画像処理は、生成、サイズ調整、メディアアップロード、代替テキスト設定、featured_media紐付け、OG画像反映の段階に分かれます。どこまで成功したかを記録し、記事投稿の成功に埋もれさせません。

一覧カードと記事ページでは切り抜き方が異なる場合があります。16:9の1600×900を基準にしても、文字を端へ置くとテーマ側のトリミングで切れます。公開ページ、トップページ、SNS向けOG表示の3か所を確認すると安全です。

1記事ずつtry/catchして残りを続ける

複数記事を一つのtry/catchで囲むと、最初の失敗で残りが実行されません。記事単位で処理を分け、成功と失敗を別々に記録します。

for (const article of selectedArticles) {
  try {
    const result = publishOne(article);
    verifyPublished(result, article);
    recordSuccess(article.id, result.id, result.link);
  } catch (error) {
    recordBlocked(article.id, safeMessage(error));
  }
}

この構造なら、1本が画像エラーでも残り3本は処理できます。ただし最終報告は「処理対象4本、公開3本、失敗1本」とし、4本成功とは言いません。失敗記事は入力規則に存在する状態へ移し、詳細は次の処理欄や実行ログへ保存します。

再実行時は公開済み3本を除外し、失敗した1本だけを更新します。毎回新規投稿すると重複記事が増えるため、記事ID、slug、WordPress投稿IDの対応を管理します。

品質ゲートの誤検知を減らす

品質ゲートは、根拠のない体験談、未提携広告、未公開内部リンク、空の画像、重複slugを止めるために必要です。一方、単語の部分一致だけで止めると、正常な注意書きまでエラーになります。

未解決項目を検知するなら、HTMLコメント、行頭の明確な保留記号、角括弧で囲んだプレースホルダー、空のURL属性など、実際の未完成状態に絞ります。検知した文字列だけでなく、記事ID、位置、前後の文脈をエラーへ含めると修正しやすくなります。

体験表現は一次情報マニフェストへ照合します。「筆者が使った」「経験した」「判断した」と書く文には、EXP ID、出所、使ってよい数字・判断を割り当てます。該当EXPがなければ、一人称を削除して公式情報として書くか、そのテーマを差し替えます。

AIと自動化を使いながら品質を保つ設計は「AIとApps Scriptでブログを自動化しても品質を落とさない運用ルール」で詳しく説明しています。

実行ログに残す項目

項目	目的	注意
実行日時	どのトリガーか特定	サイトのタイムゾーンを明示
記事ID	管理表とWordPressを接続	タイトルだけにしない
処理段階	送信・画像・再取得を区別	「失敗」だけにしない
HTTPコード	API応答を切り分け	認証情報を残さない
投稿ID・URL	再取得と確認に使用	成功時のみ確定値を記録
安全なエラー要約	次の修正を決める	本文全文・秘密情報を除外
最終状態	公開済み・ブロックを区別	入力規則の許可値を使う

公開されないときの復旧順序

1. 同じ実行ボタンをすぐに押さず、ログとWordPressを確認する
2. 対象記事数と各記事IDを特定する
3. WordPress投稿IDやslugで既存投稿を検索する
4. 作成済みなら新規作成せず更新する
5. 品質ゲート、認証、画像、本文のどこで止まったか切り分ける
6. 失敗記事だけを修正して再実行する
7. GET再取得と公開URL確認を行う
8. 管理表の状態をWordPressと同期する

WordPress REST API自動投稿の基本実装は「Google Apps ScriptでWordPressを自動投稿する方法」を参考にしてください。403の場合はサーバー側のセキュリティやアクセス制御を先に切り分けます。

安定したWordPress運用の土台

自動投稿は、WordPress本体、テーマ、プラグイン、サーバー、REST API、画像処理の組み合わせで動きます。サーバーが不安定なら、コードの成功判定を厳密にしても公開品質は安定しません。バックアップ、SSL、アクセス制御、PHP環境、WAF設定、障害情報の確認先を決めておきます。

筆者はエックスサーバー上のWordPressでREST API連携を運用しています。これからWordPressブログを作り、自動化できる土台を整えたい方は、契約条件と現在の仕様を公式ページで確認してください。

エックスサーバーの公式情報を確認する

よくある質問

HTTP 200なら公開成功ですか？

十分ではありません。再取得したstatus、slug、link、本文、featured_mediaなどを確認し、ログアウト状態で公開URLを開きます。

statusがpublishなのに見つかりません

返却されたlinkとslug、サイトURL、リダイレクト、キャッシュ、可視性を確認します。管理画面の一覧とREST API再取得も照合してください。

同じslugの下書きがあったらどうしますか？

新規作成せず、その投稿IDを更新します。事前にslugと記事IDの対応を管理表で確認します。

4本中1本が失敗したら全体を失敗にしますか？

処理は残りを続けられますが、結果は公開3本・失敗1本と報告します。1本の失敗を隠して「4本完了」とはしません。

認証情報をログに出してもよいですか？

出しません。ユーザー名、アプリケーションパスワード、Authorizationヘッダー、Cookieなどを保存せず、安全なエラー要約だけを記録します。

まとめ：完了判定はWordPress側の再取得で行う

WordPress自動投稿で「処理成功なのに公開されない」を防ぐには、GASの終了表示を完了条件にしないことです。HTTP応答を検査し、投稿IDで再取得し、status、slug、link、本文、画像、カテゴリ、タグ、広告、内部リンクを確認します。

筆者の週4本運用では、初回停止を修正したあと4本を公開し、各URL・公開状態・時刻・サムネイルを個別確認しました。現在の原則は、1本でも未公開なら4本完了と報告しないことです。

自動化の目的は成功表示を増やすことではなく、読者が正しい記事を読める状態を再現することです。入力、送信、保存、公開、表示の5段階へ分け、失敗記事だけを安全にやり直せるようにしてください。

参考にした公式情報

• WordPress Developer Resources：Posts REST API
• Google Apps Script：UrlFetchApp
• エックスサーバー：WordPress REST APIに関する設定

公式情報の確認日：2026年9月5日

自動公開を状態遷移として設計する

記事の状態を「未公開／公開済み」の二つだけにすると、どこまで進んだか分かりません。候補、本文完成、品質合格、送信準備、送信中、WordPress保存、公開検証中、公開済み、ブロックのように分けます。

各状態へ進む条件を明文化します。たとえば「公開済み」は、WordPressのstatusがpublishであるだけでなく、slug、本文、featured_media、内部リンク、広告リンク、カテゴリ、タグ、SEO項目の再取得確認が終わった状態とします。

状態名は管理シートの入力規則と合わせます。コードが許可されていない値を書こうとすると、元の公開エラーに加えて管理表更新まで失敗します。詳細なエラーは別列へ保存し、状態列には既存の許可値を使います。

再実行しても重複しない設計

自動処理は、通信切断や時間制限で途中終了する可能性があります。同じ処理を再実行しても新しい投稿を増やさず、既存の投稿を正しく更新できることが重要です。

1. 記事IDで管理表を検索する
2. WordPress投稿IDがあればその投稿を取得する
3. 投稿IDがなければslugで既存投稿を検索する
4. 既存下書きがあれば更新する
5. どちらもなければ新規作成する
6. 成功後に投稿IDとURLを管理表へ保存する

新規作成の直後に管理表更新が失敗した場合も考え、再実行時はWordPress側のslugを必ず検索します。投稿IDを保存できなかったからといって、新規作成へ直行しません。

リトライできるエラーと止めるエラー

一時的なタイムアウトや5xx応答は、待ち時間と回数を制限して再試行できる場合があります。一方、401・403、必須データ不足、重複slug、広告リンク不備、実体験根拠不足は、同じ入力で繰り返しても直らないため止めます。

種類	例	基本対応
一時障害	タイムアウト、5xx	回数制限付きで待って再試行
認証・権限	401、403	停止して設定確認
品質	実体験なし、PR漏れ	記事をブロック
競合	重複slug、既存下書き	既存投稿を更新
部分成功	本文成功・画像失敗	記事単位で未完了を記録

再試行する場合は、同じ記事を同時に二重処理しないようロックや実行中状態を使います。最大回数を超えたら、次回トリガーへ無限に持ち越さず、原因と再開条件を記録します。

公開後検証をコードと目視に分ける

コードでは、status、slug、本文の一部、featured_media、リンク、カテゴリ、タグなどを比較します。目視では、タイトルの折返し、表の崩れ、アイキャッチ文字、CTAの見え方、スマートフォン表示を確認します。

本文全文を完全一致で比較すると、WordPressの整形やブロック変換で差が出る場合があります。必須セクション、主要な数値、広告パラメータ、内部リンクURL、見出し数など、意味が変わる要素を選んで比較します。

検証結果は記事単位で記録し、総件数は最後に集計します。4本中3本が合格し1本がブロックなら、公開3本・未完了1本です。集計を先に作らないことで、成功件数の過大報告を防ぎます。

障害発生時の安全な報告テンプレート

• 対象記事IDとタイトル
• 停止した処理段階
• WordPress投稿IDが発行済みか
• 現在のstatusとURL
• 安全に要約したエラー
• 再実行前に必要な修正
• 残りの記事が継続処理されたか

「公開に失敗しました」だけでは次の作業が分かりません。反対に、レスポンス全文を貼ると秘密情報や下書き本文が混ざる可能性があります。必要な事実だけを残します。

公開できない環境では、完成原稿を非公開下書きまたは処理キューへ保存し、公開済みと報告しません。認証済みの経路が戻った時点で、既存slugを検索してから再開します。

定期実行の前に行うドライラン

本番公開前には、実際の公開を伴わずに対象記事、slug、画像、内部リンク、広告リンク、カテゴリ、タグを一覧化するドライランを用意すると安全です。対象0件や5件以上、重複slug、画像ファイル不足を本番前に見つけられます。

ドライランの合格は公開成功ではありません。入力データが処理可能であることを示すだけです。本番後には必ずWordPress側の再取得と公開URL確認を行います。

定期トリガーでは、同じ時間帯に別実行が残っていないか、前回のブロック記事が自動で再投入されないかも確認します。実行ロック、処理中フラグ、最終実行IDを使い、重複処理を防ぎます。

成功率より検証可能性を優先する

自動化では、エラーを出さないことより、どこで失敗したか分かることが重要です。例外をすべて握りつぶすと見かけの成功率は上がりますが、未公開記事を見つけにくくなります。

記事単位の結果、WordPress投稿ID、URL、再取得結果、画像IDを残せば、次回は失敗箇所から再開できます。成功3本と失敗1本を正確に記録する運用のほうが、曖昧な4本成功より信頼できます。

筆者が4本の公開後に個別確認を残した理由もここにあります。自動化が増えるほど、最後の確認条件を具体的にし、報告と実際の公開状態を一致させます。

REST APIが403で止まる場合の切り分けは「エックスサーバーでWordPress REST APIが403になる原因と直し方」も参照してください。