GASからWordPressに投稿する方法|自動化の基本構成
GASからWordPressへ自動投稿するなら、基本構成はシンプルです。GASで本文データを作り、UrlFetchApp で WordPress REST API の /wp-json/wp/v2/posts に POST する。認証は、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_URLWP_USERNAMEWP_APP_PASSWORD
この3つを Script Properties に入れておくと、コードを公開・共有するときの事故を減らせます。
3. 投稿データをJSONで組み立てる
WordPressの投稿エンドポイントには、たとえば次のような内容を送ります。
titlecontentstatuscategoriestags
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: 更新や削除に使う投稿IDstatus:draftになっているかlink: 公開後に使うURLslug: 自動生成または指定したスラッグ
最初は 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 になる
contentやtitleの形式が崩れている- カテゴリやタグの指定がサイト側の値と合っていない
payloadをJSON文字列にせず送っている
投稿はできたが表示が崩れる
- Markdownをそのまま送っている
- 改行やHTMLタグの扱いがテーマやエディタの想定とずれている
- 手動投稿した記事のHTML構造と自動投稿した本文の構造が違いすぎる
二重投稿が起きる
- トリガーの再実行対策がない
- 投稿成功後のID保存がない
- シート側に「処理済み」列を作っていない
自動化を一段進める方法
Apps Script の installable trigger を使えば、定時実行も組めます。毎朝の決まった時刻に投稿下書きを作るなら、最初の一歩として十分です。
次に足すなら、このあたりが現実的です。
- 投稿IDを保存して、更新は
POST /wp/v2/posts/<id>に切り替える - カテゴリやタグを事前取得して、スラッグからIDへ変換する
- 画像アップロードを追加する
- 公開は人が最終確認してからにする
最初に作るべきなのは、完璧な自動投稿ではなく、壊れたときに止めやすい下書き自動化です。 そこまで作れれば、あとは入力元と整形処理を足していくだけで実運用に近づきます。
