Google Apps ScriptでWordPressを自動投稿する方法｜実運用で詰まった点と安全な設計【2026年版】

2026年8月15日2026年8月20日

Google Apps ScriptからWordPressへ記事を自動投稿する流れを表したアイキャッチ画像

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

Google Apps ScriptからWordPressへ記事を自動投稿できれば、スプレッドシートで管理した原稿を、決めた曜日にまとめて公開できます。ただし、単にREST APIへ本文を送るだけでは安全な運用になりません。認証情報の保管、重複slugの防止、アイキャッチやカテゴリの設定、公開後の再取得、記事ごとの失敗分離まで設計して初めて、毎週使える仕組みになります。

この記事では、エックスサーバー上のWordPressとGoogle Apps Scriptを接続し、実際に自動公開まで通した記録をもとに、構成と注意点を整理します。先に結論を言うと、最小構成は「管理表」「品質ゲート」「投稿処理」「公開後検証」の四層です。認証情報はシートへ置かず、Application Passwordsを使い、最初は非公開下書きで接続を確かめます。

Google Apps ScriptでWordPressを自動投稿する全体像

流れは、スプレッドシートから公開候補を読み、条件を満たした記事だけをWordPress REST APIへ送る形です。Apps ScriptのUrlFetchAppはHTTP・HTTPSリクエストを送信できるため、WordPressの投稿エンドポイントと組み合わせられます。

記事マスターから候補を取得する
本文、slug、カテゴリ、タグ、広告リンクを検査する
同じslugの投稿がないかWordPress側で検索する
画像をメディアへ登録してfeatured_mediaを取得する
投稿を作成または更新する
同じ投稿を再取得し、statusと必須項目を照合する
成功した記事だけ管理表を更新する

WordPress公式のPosts APIでは、title、content、excerpt、slug、status、featured_mediaなどを投稿データとして扱えます。公開処理ではstatusをpublishにしますが、接続確認段階ではdraftにして表示を確かめるのが安全です。

【実体験】最初に止まったのはWordPressではなくサーバー側だった

筆者の環境では、ユーザー名とApplication Passwordsを確認してもREST APIが403になりました。原因はエックスサーバーの国外アクセス制限に含まれるREST APIアクセス制限でした。

対応では、REST APIアクセス制限だけをOFFにし、ダッシュボードアクセス制限はONのまま残しました。設定後は認証済みの接続が通り、非公開下書きの作成から公開処理まで進められました。設定をまとめて解除せず、必要な経路だけを切り分けた点が重要です。

403の詳しい確認順は「エックスサーバーでWordPress REST APIが403になる原因と直し方」で画面単位に整理しています。

認証にはApplication Passwordsを使う

外部スクリプトへWordPressの通常ログインパスワードを渡す必要はありません。WordPress公式のApplication Passwordsは、連携ごとに発行し、個別に失効できる認証情報です。HTTPS上でBasic認証として利用します。

保存先はApps Scriptのスクリプトプロパティに限定し、シート、本文、実行ログ、ソースの共有部分へ書かないようにします。ログにはAuthorizationヘッダーや生のエラー本文をそのまま出さず、秘密情報を伏せた短いエラーだけを残します。

記事マスターに最低限必要な列

運用しやすい管理表には、記事ID、タイトル、slug、抜粋、本文HTML、品質判定、状態、WordPress投稿ID、URL、更新日時を用意します。さらに、使用した実体験ID、一次情報ID、広告案件ID、内部リンク先を別タブで紐付けると、本文の根拠を追跡できます。

記事IDを共通キーにすると、タイトルを修正しても管理表同士の対応が崩れません。投稿後にWordPress IDを保存しておけば、次回は新規投稿ではなく既存投稿の更新に切り替えられます。

重複投稿を防ぐにはWordPress側のslugを先に検索する

シート上で重複がなくても、WordPressに同じslugの下書きが残っていることがあります。投稿前にpostsエンドポイントをslugで検索し、既存下書きがあればそのIDを更新します。公開済み投稿が同じslugを使っている場合は、自動で別記事を作らず停止させます。

この確認を入れないと、試行のたびに同じ内容の下書きが増えます。タイトルではなくslugと投稿IDで判断するのが安定します。

本文を送る前の品質ゲート

自動投稿で最も怖いのは、処理エラーより、誤った記事が正常に公開されることです。送信前に次を検査します。

本文にH1が残っていない
slugが英数字とハイフンだけで構成されている
未完了メモ、暫定リンク、保留表示が残っていない
公開済み内部リンクが入っている
広告記事の冒頭にPR表記がある
A8リンクにsponsored nofollowがある
A8計測ピクセルが保持されている
一次情報マニフェストと体験表現が一致している

体験談は「文章が自然か」だけでは判定できません。使用可能なEXP IDを記事ごとに固定し、一人称の事実や数値をマニフェストへ照合します。根拠がなければ公開対象から外します。

アイキャッチ、カテゴリ、タグも投稿前に確定する

本文だけを投稿し、画像や分類をあとで手作業にすると、結局は公開後の修正が増えます。自動処理では、カテゴリ名とタグ名をIDへ変換し、アイキャッチをメディアへ登録したあと、featured_mediaへそのIDを設定します。

画像のaltは記事タイトルをそのまま詰め込まず、何を図解した画像かが分かる短い説明にします。SEOタイトル、メタディスクリプション、OG画像も同じ投稿IDへ保存し、投稿後の監査APIで一致を確認します。

複数記事は一括送信せず個別に失敗を分離する

週に複数本を処理する場合、最初の記事でエラーが出たため残りも止まる設計は避けます。候補を配列で取り出し、一記事ずつtry/catchで処理します。失敗した記事はエラー状態へ変更し、残りの記事は続行します。

公開結果は「要求件数」「対象件数」「成功件数」「失敗件数」「各記事のURL」を残します。これにより、四本のうち三本だけ成功した場合も、成功した記事を公開済みとして正しく扱えます。

公開成功はPOSTレスポンスだけで判断しない

WordPressからIDが返っても、カテゴリやSEO設定まで一致したとは限りません。投稿直後に同じIDをcontext=editで再取得し、status、slug、本文、featured_mediaを照合します。さらに補助APIや管理画面データから、カテゴリ、タグ、画像alt、SEOタイトル、説明、OG画像を確認します。

この再取得が通ったときだけ管理表を公開済みに変更します。通信が途中で切れた場合も、次回はslugとIDで既存投稿を見つけられるため、重複を避けられます。