MENU

GASからWordPressに投稿する方法|自動化の基本構成

GASからWordPressに投稿する方法|自動化の基本構成

GASからWordPressへ自動投稿するなら、基本構成はシンプルです。GASで本文データを作り、UrlFetchApp で WordPress REST API の /wp-json/wp/v2/postsPOST する。認証は、WordPress 5.6以降で使える Application Passwords を使うのが実務では扱いやすい形です。

手作業でコピペしていた定型記事、社内レポート、フォーム送信内容の下書き化を減らしたい場面では、この構成だけでかなり進みます。最初から複雑な連携にせず、まずは「下書きを1本作れる」状態まで持っていくのが近道です。

  • できること: GASからWordPressへ下書きや公開記事を自動作成できる
  • 向いている場面: スプレッドシートの行データを記事化したい、定期投稿を自動化したい、社内入力フォームの内容を下書き化したい
  • 基本部品: UrlFetchApp、Script Properties、WordPress REST API、Application Passwords
  • 最初の目標: まずは draft で1本投稿し、成功後にタグやカテゴリ、定期実行を足す
目次

前提環境

2026年4月確認時点の前提です。

  • GASは Google Apps Script の現行エディタ環境を使う
  • WordPress側は REST API が使えること
  • 外部アプリ認証は Application Passwords が使える WordPress 5.6以降 を前提にする
  • 認証情報を送るため、接続先は HTTPS を前提にする

GAS側では UrlFetchApp で外部の HTTP/HTTPS へリクエストを送れます。設定値の保存には PropertiesService を使うと、URLやユーザー名、アプリケーションパスワードをコードに直書きせずに済みます。

基本構成

まずは全体像を押さえると、迷いにくくなります。

ここがポイント: GASからWordPress投稿を自動化する最小構成は、「認証情報を安全に持つ」「REST APIにJSONを送る」「最初は下書きで作る」の3点です。

1. WordPress側で認証を用意する

  • WordPressのユーザープロフィールで Application Passwords を発行する
  • 投稿権限のあるユーザーを使う
  • 送信先エンドポイントは https://あなたのドメイン/wp-json/wp/v2/posts

2. GAS側で設定値を持つ

  • WP_SITE_URL
  • WP_USERNAME
  • WP_APP_PASSWORD

この3つを Script Properties に入れておくと、コードを公開・共有するときの事故を減らせます。

3. 投稿データをJSONで組み立てる

WordPressの投稿エンドポイントには、たとえば次のような内容を送ります。

  • title
  • content
  • status
  • categories
  • tags

4. まずは draft で送る

publish をいきなり使うより、最初は draft で動作確認したほうが安全です。タイトル、本文、文字化け、改行、カテゴリ設定を目で確認できます。

WordPress側の準備

コードを書く前に、WordPress管理画面で2つだけ済ませます。

Application Passwords を発行する

WordPress公式ドキュメントでは、外部アプリからの認証方法として Application Passwords が案内されています。通常のログインパスワードを直接使うより、この方式のほうが管理しやすく、不要になればその接続だけ止められます。

やることは次のとおりです。

  • 管理画面で対象ユーザーのプロフィールを開く
  • Application Passwords から新しいパスワードを発行する
  • 発行直後に表示された値を控える
  • GASの Script Properties に保存する

カテゴリ・タグのIDを確認する

投稿時にカテゴリやタグを付けるなら、WordPress REST APIでは IDベースで扱う のが基本です。

たとえば、既存カテゴリを確認したいなら次のようなURLで確認できます。

GET https://あなたのドメイン/wp-json/wp/v2/categories?slug=news
GET https://あなたのドメイン/wp-json/wp/v2/tags?slug=automation

名前で考えていても、送信時には数値IDを使う場面が多いので、ここは先に押さえておくと後で詰まりません。

GAS側の実装

ここでは、最初に動かしやすい最小例を載せます。まずは1本の下書きを作るコードです。

function createWordPressPost() {
  const props = PropertiesService.getScriptProperties();
  const siteUrl = props.getProperty('WP_SITE_URL');
  const username = props.getProperty('WP_USERNAME');
  const appPassword = props.getProperty('WP_APP_PASSWORD');

  if (!siteUrl || !username || !appPassword) {
    throw new Error('Script Properties に WP_SITE_URL / WP_USERNAME / WP_APP_PASSWORD を設定してください。');
  }

  const endpoint = siteUrl.replace(/\/$/, '') + '/wp-json/wp/v2/posts';
  const auth = Utilities.base64Encode(username + ':' + appPassword.replace(/\s+/g, ''));

  const payload = {
    title: 'GASからの自動投稿テスト',
    content: '<p>これは Google Apps Script から作成した下書きです。</p><p>まずは draft で動作確認します。</p>',
    status: 'draft',
    categories: [3],
    tags: [12]
  };

  const options = {
    method: 'post',
    contentType: 'application/json',
    headers: {
      Authorization: 'Basic ' + auth
    },
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(endpoint, options);
  const statusCode = response.getResponseCode();
  const bodyText = response.getContentText();

  Logger.log(bodyText);

  if (statusCode < 200 || statusCode >= 300) {
    throw new Error('WordPress API error: ' + statusCode + ' ' + bodyText);
  }

  return JSON.parse(bodyText);
}

この例で押さえる点は3つです。

  • 認証情報は PropertiesService.getScriptProperties() から読む
  • 認証ヘッダーは Basic 認証の形で送る
  • muteHttpExceptions: true を付けて、失敗時のレスポンス本文を確認しやすくする

Script Properties に入れる値

Apps Script エディタのプロジェクト設定から、次のキーを登録しておくと管理しやすくなります。

WP_SITE_URL=https://example.com
WP_USERNAME=your_user_name
WP_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx

表示上の空白が入っている Application Passwords は、コード側で空白除去してから使うと扱いやすいです。

入力例と返り値の見方

送るJSONは最小ならこれだけでも十分です。

{
  "title": "週次レポート 2026-04-22",
  "content": "<p>売上サマリーを自動投稿します。</p>",
  "status": "draft"
}

成功すると、WordPress REST API から投稿オブジェクトが返ります。実務でまず見ればよいのは次の項目です。

  • id: 更新や削除に使う投稿ID
  • status: draft になっているか
  • link: 公開後に使うURL
  • slug: 自動生成または指定したスラッグ

最初は Logger.log() でレスポンス全体を確認し、必要な項目だけ後で取り出す形にすると作業が早いです。

Markdown原稿を送るときの考え方

ここは初心者がつまずきやすい点です。

WordPressの投稿エンドポイントに送る content は、そのまま投稿本文として保存される値です。Markdown原稿を持っていても、サイト側の構成によってはそのまま期待どおりに表示されません。

実務では次のどちらかに寄せると安定します。

  • HTMLに変換してから送る: もっとも無難。段落、見出し、リンクを自分で制御しやすい
  • Markdown対応プラグインや運用ルールに合わせる: 既存サイトにMarkdown運用がある場合だけ選ぶ

GASで自動投稿を始める段階では、本文はまずHTML文字列で送るほうがトラブルが少なめです。

実務で使いやすい応用例

最小構成が動いたら、次の広げ方が実務向きです。

スプレッドシートの行を記事化する

  • 1行を1記事として扱う
  • title 列、content 列、status 列を用意する
  • 投稿済みフラグを書き戻して二重投稿を防ぐ

フォーム入力を下書き化する

  • Googleフォームの回答をトリガーにする
  • 問い合わせ内容や申請内容を WordPress 下書きへ送る
  • 管理者は WordPress で整えて公開する

定時バッチでまとめ記事を作る

  • 日次・週次の集計結果をGASで整形する
  • 時間主導トリガーで下書きを作る
  • 人が確認してから公開する

この順で広げると、投稿APIの接続確認、データ成形、運用フローの順で段階的に固められます。

よくある失敗と対処

動かない原因は、だいたい同じところに集まります。

401 / 403 になる

  • Application Passwords ではなく通常パスワードを使っている
  • ユーザーに投稿権限がない
  • URLが wp-json/wp/v2/posts になっていない
  • HTTPS前提の認証条件を満たしていない

400 になる

  • contenttitle の形式が崩れている
  • カテゴリやタグの指定がサイト側の値と合っていない
  • payload をJSON文字列にせず送っている

投稿はできたが表示が崩れる

  • Markdownをそのまま送っている
  • 改行やHTMLタグの扱いがテーマやエディタの想定とずれている
  • 手動投稿した記事のHTML構造と自動投稿した本文の構造が違いすぎる

二重投稿が起きる

  • トリガーの再実行対策がない
  • 投稿成功後のID保存がない
  • シート側に「処理済み」列を作っていない

自動化を一段進める方法

Apps Script の installable trigger を使えば、定時実行も組めます。毎朝の決まった時刻に投稿下書きを作るなら、最初の一歩として十分です。

次に足すなら、このあたりが現実的です。

  • 投稿IDを保存して、更新は POST /wp/v2/posts/<id> に切り替える
  • カテゴリやタグを事前取得して、スラッグからIDへ変換する
  • 画像アップロードを追加する
  • 公開は人が最終確認してからにする

最初に作るべきなのは、完璧な自動投稿ではなく、壊れたときに止めやすい下書き自動化です。 そこまで作れれば、あとは入力元と整形処理を足していくだけで実運用に近づきます。

参照リンク

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次