WordPress運営を自動化したいと考えると、最初に目につくのはAIによる本文生成です。ただ、複数サイトを運営すると負担になるのは文章作成だけではありません。投稿の状態、slug、カテゴリ、画像、ALT、内部リンク、SEO meta、公開可否、更新履歴などを揃える作業が増え、サイトごとの差分も管理しにくくなります。
僕は複数のWordPressサイトを運営し、投稿一覧の取得、下書き作成、既存投稿の更新、公開までをREST API経由で扱う仕組みを作ってきました。その経験から、AI自動化で先に減らす価値が高いのは「考えなくても確認できる作業」です。禁止文字列、画像ALTの欠損、meta未設定、リンク切れ候補の検出などを機械化すると、人は検索意図や一次情報、公開判断へ時間を使えます。
WordPressのAI自動化は5つの層に分けると設計しやすい
| 層 | 役割 | 代表例 | 人が残す判断 |
|---|---|---|---|
| 観測 | WordPressや計測データを読む | REST API、Search Consoleの確認 | 数字の意味・改善優先度 |
| 生成・分析 | 候補を作る | 構成案、meta案、リンク候補、差分要約 | 事実性・独自価値 |
| オーケストレーション | 処理順をつなぐ | n8n、独自ジョブ、キュー | 停止条件・再実行条件 |
| WordPress操作 | 投稿やメディアを変更する | REST API、Abilities API | 変更可能な範囲 |
| 承認・監査 | 公開前後を確認する | QA、ログ、rollback | 公開・削除・重要な表現 |
この5層を分ける理由は、AIの誤りとWordPressへの書き込みを直結させないためです。たとえば「検索順位が落ちた」という入力からAIが本文を修正し、そのまま本番記事へ上書きする設計では、原因の誤認がそのまま公開物へ反映されます。AIは修正案を作るところまで、WordPressへの更新は差分・対象ID・許可フィールドを確認してから、という境界を置くと事故を局所化できます。
自動化する工程の選び方
自動化しやすいのは「正解条件を機械で判定できる作業」
最初の候補は、成功条件をYes/Noで判定しやすい作業です。投稿一覧の取得、更新日の抽出、noindexの検出、featured imageの有無、ALTの空欄、meta descriptionの空欄、特定文字列の残存、予定した内部リンクの有無などは、人の好みよりルールで判定しやすくなります。
- 公開済み記事・下書き・予約投稿を一覧化する
- slugと投稿IDを台帳と照合する
- 画像サイズ・形式・ALTの欠損を検出する
- title/metaの未設定や極端な重複を検出する
- 外部リンク切れや内部リンク不足の候補を出す
- 更新対象だけを差分として提示する
逆に、検索意図の最終判断、商品のおすすめ理由、実体験の評価、法的・契約的な表現、削除、URL変更は、単純なルールでは品質を担保しにくい領域です。「自動化できるか」ではなく、「誤ったときに機械だけで気づけるか」で線を引くと判断しやすくなります。
記事制作を自動化するなら「生成」より公開前ゲートを先に作る
AIで本文を速く作れても、公開後に重複投稿、壊れた表、古い料金、未設定のmeta、誤ったASPリンクが残れば運営は楽になりません。僕なら先に、下書き固定→機械QA→人間確認→公開というゲートを作ります。本文生成を高度化するのは、その経路が安定してからです。
特に既存記事の更新では、slugとpost IDを同時に照合し、対象が一致しない場合は停止する方が安全です。タイトルだけで対象を探すと、似た記事名や旧記事を誤更新する可能性があります。更新前本文とtaxonomy、SEO meta、featured imageをsnapshotとして残せば、公開後の表示崩れや誤更新も戻しやすくなります。
2026年のWordPressはREST APIだけでなくAbilities・MCP・AI Clientも見る
WordPress 6.9以降はAbilities API、7.0ではAI Client、7.1ではAbilitiesの外部公開・検証・実行ライフサイクルが強化されました。さらにMCP Adapterを使うと、AbilityをAIエージェント側へ公開できます。これらは同じ機能の競合ではなく、役割が違います。
| 仕組み | 一言でいうと | 向く用途 |
|---|---|---|
| REST API | 投稿・メディア等へHTTPでアクセスする既存の操作経路 | 投稿取得、下書き、更新、外部システム連携 |
| Application Password | 外部連携用の失効可能な認証情報 | REST API等の外部認証 |
| Abilities API | WordPressが「何をできるか」を標準化して登録する層 | 機能の発見、入力/出力schema、権限制御 |
| MCP Adapter | AbilitiesをAIエージェントへ橋渡しする層 | AIからツール/リソースとして利用 |
| AI Client | WordPress内部からAIモデルを統一的に呼ぶ層 | プラグイン内AI機能、生成・分析 |
既存の投稿操作だけならREST APIで十分なケースも多く、MCPを入れれば自動的に良くなるわけではありません。逆に、複数のAIクライアントから同じWordPress機能を発見・利用させたいならAbilities/MCPの価値が出ます。目的から逆算して必要な層だけ採用するのが、保守コストを抑える近道です。
複数サイトでは「共通化するルール」と「サイト固有の判断」を分ける
複数WordPressを扱うと、共通化したくなる範囲が増えます。ただし、画像サイズ、禁止文字列、rollback、ログ形式のような運用ルールは共通化しやすい一方、検索意図、カテゴリ、収益導線、公開基準まで共通にするとサイトごとの目的が薄れます。
僕の運用では、サイトごとに記事テーマや収益導線が違うため、同じ「記事制作」でも最終判断は別です。AIに渡す共通プロンプトを大きくするより、共通のQAエンジンとサイト別ポリシーを分ける方が、変更理由を追いやすくなります。複数サイト管理そのものは128で詳しく整理しています。
SEOは「順位を自動で上げる」のではなく、改善候補を漏らさないために使う
Search Consoleの表示回数やクエリ、インデックス状態を取得しても、それだけで本文を書き換えるべきではありません。表示回数が増えてクリック率が低いならtitle/metaの改善候補、別クエリで表示されているなら検索意図のズレ候補、といった形で「診断材料」に変えるのが安全です。
Googleは、検索順位を目的に大量自動生成するのではなく、読者が目的を達成できるpeople-first contentを推奨しています。自動化の価値は記事数を増やすことではなく、一次情報確認・重複防止・内部リンク・鮮度管理など、人間が見落としやすい作業を安定させることにあります。
僕ならこの順番でWordPress自動化を広げる
- 読み取り専用で投稿・メディア・SEO設定の状態を取得する
- 欠損・重複・更新候補をレポート化する
- AIには構成・差分・metaなど「候補」だけ作らせる
- WordPressへ書く場合も最初はdraftだけに限定する
- 対象ID・変更前snapshot・ログ・rollbackを揃える
- 限定フィールドの更新を承認付きで許可する
- 十分な実績ができてから低リスク処理だけ自動実行する
自動化の成果は4つの運用指標で確認する
自動化後は、処理件数ではなく「人が確認に使った時間」「誤更新または却下された候補の割合」「rollbackが必要になった件数」「更新漏れの検出件数」を月ごとに残します。候補生成が速くても人の確認時間が増えたなら、その工程はまだ自動化に向いていません。逆にread-onlyの監視だけでも、毎日の巡回時間と見落としが減るなら十分な成果です。
指標を残しておくと、AI modelやworkflowを変更したときにも品質を比較できます。モデルの体感的な賢さではなく、公開前の却下率や復旧件数が改善したかで判断すれば、ツール変更に振り回されにくくなります。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://developer.wordpress.org/rest-api/
- https://developer.wordpress.org/news/2026/07/build-your-first-ai-powered-wordpress-plugin/
- https://developers.google.com/search/docs/fundamentals/creating-helpful-content
コメント