GitHub ActionsとWordPress REST APIを組み合わせると、記事ファイルをGitHubへ追加したことをきっかけに、WordPressへの投稿まで自動化できます。ただし「APIで投稿できた」だけでは、運用としては不十分です。
本当に必要なのは、認証情報をコードへ埋め込まないこと、誤った記事をそのまま公開しないこと、既存記事を意図せず上書きしないこと、公開後にURL・canonical・indexability・本文を確認すること、失敗時に戻せることです。
この記事では、AIで本文を書く部分よりも、GitHub Actions → 品質チェック → WordPress REST API → 公開後QA → 状態記録という、安全に繰り返せる運用構成を中心に説明します。
全体構成：自動投稿は「生成」より「検証」を厚くする
おすすめの流れは次の通りです。
- 記事をHTMLやMarkdownなどの管理ファイルとしてGitHubへ追加する
- GitHub Actionsが変更された記事だけを検出する
- 公開前に必須メタデータ、本文量、リンク、出典などを検証する
- WordPress REST APIで投稿する
- 公開URLへアクセスして本番表示を検証する
- 成功した変更を記録し、失敗なら公開済みと扱わない
この順番の利点は、AIや人が作った本文がそのまま本番へ直結しないことです。コンテンツ生成は変動しやすい一方、公開条件はコードで固定できます。自動化の品質は「何記事作れるか」ではなく、不完全なものをどこで止められるかで大きく変わります。
WordPress REST APIの認証はApplication Passwordを使う
WordPressには外部アプリケーション向けのApplication Password機能があります。通常の管理画面ログイン用パスワードを自動化スクリプトへそのまま持ち込むより、用途を分離しやすい方法です。
GitHub Actionsからは、WordPressのURL、ユーザー名、Application PasswordをSecretsとして参照し、HTTPリクエスト時に認証します。ここで重要なのは、値そのものをリポジトリ内のPython、YAML、記事ファイルへ書かないことです。
env:
WP_URL: ${{ secrets.WP_URL }}
WP_USERNAME: ${{ secrets.WP_USERNAME }}
WP_APP_PASSWORD: ${{ secrets.WP_APP_PASSWORD }}ワークフロー内でも、Secretsをデバッグ目的で出力しないようにします。URLやユーザー名にも運用上公開したくない情報が含まれる場合があるため、ログは必要最小限にします。
GitHub Secretsに入れるもの、入れないもの
GitHub ActionsのSecretsは、ワークフローが必要な認証情報をリポジトリの通常ファイルと分離するために使います。WordPress自動投稿なら、少なくともApplication Passwordのような認証情報はSecret側に置きます。
一方、記事タイトル、slug、公開状態、カテゴリ、出典URLなど、公開判断に必要な非秘密情報は記事ファイル側に持たせるとレビューしやすくなります。
例えば次のように、記事本文の先頭へ機械判定用の情報を置く設計があります。
<!-- TITLE: ... -->
<!-- SLUG: ... -->
<!-- STATUS: publish -->
<!-- SOURCES_VERIFIED: yes -->
<!-- ORIGINAL_VALUE: ... -->
<!-- EVIDENCE_MODE: original_analysis -->こうすると、ワークフローは「公開してよいファイルか」をWordPressへ送る前に検査できます。Secretsとコンテンツ管理情報を混ぜないことがポイントです。
posts endpointで記事を作る基本
WordPress REST APIでは、投稿の作成・更新にposts endpointを利用できます。タイトル、本文、slug、statusなどをJSONとして送れます。
ただし、本番運用ではいきなりPOSTする前に、同じslugが既に存在しないか確認する方が安全です。新規記事を作るつもりなのに既存slugを更新すると、検索順位を持つ記事を意図せず書き換える可能性があります。
おすすめは次のルールです。
- 新規公開では既存slugが見つかったら停止する
- 更新を許す場合だけ明示的なフラグを要求する
- カテゴリやタグは既存taxonomyから解決し、曖昧なら停止する
- 公開前に本文量や見出し数を検査する
自動化では「とりあえず投稿して後から直す」より、異常時に止まる方が運用コストを下げやすくなります。
AI記事ならORIGINAL_VALUEを機械的に要求する
AIで記事作成を自動化すると、出典を要約しただけの文章でも一定の長さを簡単に作れます。文字数だけを品質条件にすると、検索結果や公式文書を言い換えただけの記事が量産されやすくなります。
そこで、記事ごとに「このページが何を新しく整理するのか」を明示する欄を持たせます。たとえば、複数仕様を用途別に比較する、制度情報を意思決定の順番へ組み直す、運用手順を失敗時の復旧まで含めて体系化する、といった具体的な価値です。
同時に、実体験を装う表現も止める必要があります。「使ってみた」「検証した」と書くなら、その根拠が本当に存在する場合だけ許可します。自動化の目的は人間らしい文章を大量に作ることではなく、根拠のない権威付けを本番へ出さないことです。
公開後QAは必須：WordPress APIの成功＝本番成功ではない
REST APIが200系を返しても、公開ページが期待通りとは限りません。テーマ、SEOプラグイン、キャッシュ、リダイレクト、taxonomyなどの影響は、公開URLを見ないと確認できないことがあります。
公開後は最低限、次を確認します。
- 公開URLがHTTP 200で取得できる
- 想定したタイトルと主要本文が表示される
- canonicalが自分自身または意図したURLを指す
- 意図しないnoindexが付いていない
- 内部リンクが正しいページへ向く
- アイキャッチや主要画像が壊れていない
- 広告・PR表示が必要な記事では表示される
商品比較サイトなら商品リンクや市場の取り違え、YMYLサイトなら出典・表現、プロダクトサイトならダウンロード導線など、サイト別のQAも追加します。全サイトで同じ「合格条件」にしないことも重要です。
失敗時にrollbackできる設計にする
自動投稿で怖いのは、途中まで成功した状態です。たとえばアイキャッチ画像だけアップロードされ、記事公開に失敗すると、使われないメディアが残ります。既存記事の更新で公開後QAが落ちた場合は、変更前本文へ戻せる方が安全です。
そのため、更新前データを退避し、失敗した段階に応じて次のような復旧を考えます。
- 新規記事のQA失敗：下書きへ戻す
- 既存記事のQA失敗：変更前本文へ戻す
- 新規メディアだけ作成済み：未使用なら削除する
- 復旧にも失敗：成功扱いにせず、手動確認用backlogへ残す
「Actionsが最後まで緑だったか」だけではなく、WordPress本番状態まで確認して成功判定する必要があります。
変更履歴とcooldownを持つとSEO自動化が安定する
SEO改善を毎日実行できるようになると、逆に同じ記事を短期間で何度も変えてしまう問題が起きます。昨日タイトルを変更し、今日本文を書き換え、明日また内部リンクを変えると、どの変更が効いたのか判断しにくくなります。
対策として、material changeごとに次の情報を残します。
- 変更したURL
- 変更日時
- 変更理由
- 変更前のSearch Console指標があればその値
- 期待する結果
- 次に大きく触らない期間
- 本番QA結果
緊急の誤情報やリンク切れはすぐ直しつつ、通常のSEO実験は一定期間観測します。この仕組みがあると、自動化が「毎日何かを変える機械」ではなく「仮説を実行して測るシステム」に近づきます。
AIBlogBase Liteと自動化記事をどうつなぐか
AIBlogBaseでは、WordPressブログを安全に始めるための無料テーマとして AIBlogBase Lite を公開しています。この自動化記事は、Liteそのものを無理に販売するための記事ではありません。
役割は、ブログ運営を「文章作成」だけでなく、テーマ・公開フロー・品質管理まで含めて考える読者へ、AIBlogBaseがどのような設計を重視しているか示すことです。無料テーマを使うかどうかにかかわらず、Secretを漏らさない、誤公開を止める、公開後QAを行うという原則は再利用できます。
Liteを導入する場合も、最初から記事自動化まで一気に進める必要はありません。まず通常のWordPress運用を安定させ、その後にGitHub Actionsを一つずつ追加する方がトラブル箇所を切り分けやすくなります。
最小構成から始める手順
- WordPressでApplication Passwordを発行し、権限を必要最小限にする
- GitHub Secretsへ認証情報を登録する
- まず下書き作成だけをActionsから試す
- 記事メタデータの必須チェックを追加する
- 既存slug保護を追加する
- 公開後のHTTP・本文確認を追加する
- canonical・indexability・画像などのQAを追加する
- 失敗時rollbackと変更履歴を追加する
最初から複雑なAI生成や大量投稿を組み込むより、投稿1件を確実に作成・確認・復旧できるところから拡張する方が安全です。
まとめ：自動投稿の価値は「無人化」より「再現可能な品質管理」
GitHub ActionsとWordPress REST APIを使えば投稿処理は自動化できます。しかし、運用の完成度を決めるのは投稿APIそのものではありません。
Secretsで認証情報を分離し、公開前ゲートで低品質記事を止め、既存slugを守り、公開後に本番ページを検査し、失敗時はrollbackし、変更履歴を残す。この一連の設計があることで、自動化を継続的なブログ運営へ使いやすくなります。
AIBlogBaseでは、今後も単にAIで文章を増やす方法ではなく、WordPressを壊さず、根拠を保ち、成果を測れる運用へつなげる実践的な仕組みを中心に整理していきます。
