WordPressのAI自動化｜20サイト超の運用で決めた任せ方と事故の対処

2026.10.30

WordPressのAI自動化で効果が大きいのは、記事を丸ごと書かせることではありません。

REST APIで「読む・測る・検査する」を回し、書き込みの前後を機械で確かめる使い方です。

当方は、WordPressテーマSWELLのサイトを中心に、20以上のWordPressをPythonとAIで運用しています。

この記事では、回している仕組みとAIと人の線引き、自動化で踏んだ事故と対処をまとめました。

WordPressを自分で運営していて、更新や点検をAIやスクリプトに任せたい方に向けた内容です。

書いてあるのは、2026年10月30日時点の当方の運用です。

WordPressのAI自動化の全体像

当方の自動化は、WordPressに触る部品をPythonにまとめ、AIはその部品を使う側に回す形をとっています。

自動化している作業

作業	使う仕組み	AIの役割
記事の本文・題名の読み書き	REST API＋アプリケーションパスワード	下書き・直す案・検査
メタタイトル・説明	SEO SIMPLE PACK のメタをRESTで	案を出す
PHPのスニペットを配る	Code Snippets のREST	コードの下書き
設定・プラグインの操作	WP-CLI（SSH）	コマンドを組み立てる
順位とアクセスの測定	Search Console・GA4 のAPI	変化を要約する
更新の通知	IndexNow	なし（機械的に送る）
記事の採点	独自の品質基準	採点と指摘

当方が自動化している作業（2026年10月30日時点）

部品をそろえてAIに使わせる

サイトごとに別々のスクリプトを書くと、直し忘れや食い違いが起きます。

当方は、投稿の取得・保存・検索などをPythonの部品にまとめ、全サイトで同じ部品を呼ぶ作りです。

AIに頼むのは、この部品を組み合わせたスクリプトを書くことと、結果を読んで要約することです。

部品の中で権限と検算をそろえておけば、AIが書いたスクリプトでも同じ安全装置を通ります。

MCPはまだ読み取りの段階

WordPress公式のMCP Adapterも検証用のサイトで試しましたが、本体だけで使える操作はサイト情報などの読み取り3つでした。

そのため、当方の運用での書き込みは、今もREST APIとWP-CLIで行っています。

→ 実測の記録：WordPress MCPの使い方｜MCP Adapterで実際にAIとつないだ結果

WordPressにつなぐ仕組み（REST API・Code Snippets・WP-CLI）

書き込みの入口は、REST API・Code Snippets・WP-CLIの3つです。

REST API＋アプリケーションパスワード

記事・固定ページ・メディア・カテゴリーの読み書きは、本体のREST APIで足ります。

認証には、WordPress 5.6から本体に入っているアプリケーションパスワードを使います。

発行するユーザーの権限がそのまま乗るので、ユーザーは用途ごとに分けるのが安全です。

→ 基本：WordPress REST APIとは／GASから使う例：WP REST APIとGASを使った投稿・更新方法

SEO SIMPLE PACKのメタもRESTで書く

SEO SIMPLE PACK のメタタイトルと説明は、投稿のカスタムフィールドとして保存されています。

RESTで読み書きできるように登録しておけば、投稿と一緒に送れます。

題名を変えてもメタタイトルを送り忘れると、検索結果に古い題名が残るため、両方を同時に送る作りです。

→ 手順：SEO SIMPLE PACK│メタ情報をREST APIから設定する方法

Code SnippetsのRESTでPHPを配る

functions.php を直接書き換えるかわりに、Code Snippets というプラグインにPHPのスニペットを登録しています。

Code Snippets にはREST APIがあるので、同じスニペットを全サイトに配ったり、まとめて止めたりできます。

スニペットなら管理画面から止められるので、コードに誤りがあっても戻しやすいのが利点です。

出典：Code Snippets（WordPress.org）

WP-CLIをSSHで使う

RESTで届かない設定やプラグインの更新、データベースの書き出しは、SSHで入ってWP-CLIで操作します。

置換のように取り返しがつきにくい操作は、試し実行のオプションで件数を見てから本番を流します。

出典：WP-CLI（公式）

毎週の測定と更新の通知

自動化の効果がいちばん出ているのは、書くことより測ることです。

Search ConsoleとGA4をAPIで測る

Search Console のAPIで検索の表示・クリック・順位を、GA4 のAPIでページごとの閲覧数を、毎週取っています。

見るのは平均ではなく、記事と検索語ごとの変化です。

AIには、前の週との差を要約させ、どの記事に手を入れるかの候補を出させます。

候補から実際に選ぶのは人です。

→ 似た仕組みをGASで作る例：Search Console│異常を毎週自動検知する／出典：Search Console API・Google Analytics Data API

IndexNowで更新を知らせる

記事を公開・更新したら、IndexNow という仕組みで対応する検索エンジンにURLを知らせています。

送るのは機械的な作業なので、AIの判断は挟みません。

出典：IndexNow（公式）

記事を機械で採点して入稿前に止める

記事は、当方で決めた品質基準で採点しています。

基準は、検索意図への回答・正確さと根拠・独自性・読みやすさ・読者の次の行動の5つの軸で、100点満点です。

入稿の道具には、機械で判定できる検査を組み込んでいます。

1文が1段落になっているか
題名32字・説明120字に収まっているか
煽る言葉が入っていないか
外部リンクが生きているか
ブロックの開きと閉じがそろっているか

どれか1つでも引っかかると、下書きにも保存しない作りです。

AIに任せること・人が決めること

線を引く基準は、「間違えたときに機械で見つけられるか」と「取り返しがつくか」の2つです。

作業	AIに任せる	人が決める
下書き・言い換え	任せる	事実と照らして直す
数値・版・画面の項目名	候補を出すだけ	公式資料と実機で確かめる
どの記事を直すか	データの要約	選ぶ
一括の書き換え	スクリプトを書く	控え・小さな試し・結果を見る
公開	検査と照合を通ったものだけ、スクリプトで公開する	公開してよい範囲と合格の基準を決める
認証情報	見せない	人が管理する

当方の線引き（2026年10月30日時点）

AIに任せていること

任せているのは、下書き・言い換えの案・スクリプトの作成・測定結果の要約・機械的な検査の5つ。

どれも、出てきたものを人や機械があとで確かめられます。

人が決めていること

何を書くか・どこまで任せるか・合格の基準は、人が決めます。

生成AIの下書きには、古い版のメニュー名や、試していないことを試したように書く文が混じるからです。

公開の前に、公式の資料と実機の画面で照らし合わせてから出しています。

認証情報はAIとの会話に貼らない

アプリケーションパスワードやAPIキーは、手元の設定ファイルに置き、スクリプトが読み込む形にしています。

AIとの会話に貼ると、記録に残って取り消しの手間が増えるので、貼らないと決めました。

自動化で踏んだ事故と対処

ここからは、当方が実際に踏んだ事故です。

どれも画面上ではエラーが出ず、あとから気づいたものでした。

正規表現でブロックを分けたら本文が32MBに膨らんだ

ブロックを正規表現の最短一致で切り出したところ、入れ子のリストを最初の閉じタグで切ってしまいました。

親のないリスト項目が残り、保存のたびに増えて、約5,000字の記事が32MBまで膨らんでいました。

読者の画面には、ブロックの目印が文字のまま出ていた状態です。

対処は、入れ子の深さを数えて分ける部品に置き換え、保存した後に文字数を取り直して桁の違いを検知することです。

IDの一括置換で内部リンクが壊れた

画像を差し替えるときに、本文全体の "id":数字 をまとめて置き換えました。

ところが、SWELLの記事リンクのブロックにも同じ形でIDが入っていて、リンク先の記事IDまで画像のIDに変わりました。

置換は対象のブロックの中だけに限り、書き込みの前後でIDの数を比べるように直しています。

キャッシュのフォルダーを移したらページキャッシュが黙って止まった

サーバーの容量を減らそうとして、WP Rocket のキャッシュの置き場をフォルダーごと移しました。

WP Rocket は置き場が無いとページキャッシュを止めますが、エラーは出さず、フォルダーも作り直しません。

ほかの機能は動き続けるので見た目では気づけず、約1日、表示に6〜21秒かかるページが出ていました。

キャッシュはプラグインの「キャッシュをクリア」で消し、置き場のフォルダーには触らないことにしています。

コマンドのハイフン2つがダッシュに化けた

WordPressの自動整形は、段落や表のセルにある --resume のようなハイフン2つを、1本のダッシュに置き換えます。

読者がコピーしても動かないコマンドになっていました。

コードブロックと <code> の中は変わらないので、コマンドとオプションはそのどちらかに入れ、公開後にダッシュが残っていないかを検査しています。

1文ずつ分ける処理が、かっこの中で文を割った

1文を1段落に分ける処理が、かぎかっこの中の「。」でも切っていました。

引用したエラー文が独立した段落になり、次の段落は閉じかっこから始まっていました。

その間、検索ではエラー文の専用記事ではなく、総合記事のほうが表示されていた時期があります。

今は、かっこの深さを数えて外側の「。」だけで切っています。

見た目が正常でも、元の記事のマークアップが壊れていた

リライトの道具が止まる記事を調べると、原因は道具ではなく元の記事にありました。

閉じていないリンクのタグがあり、後ろの本文までリンクになっていた
開いていないのに閉じるタグだけが残っていた
段落のブロックの中身が別の部品になっていた

全記事に流す前に、壊れたマークアップを洗い出して直す道具を先に通すようにしました。

一覧を100件で打ち切り、同じスニペットを3つ作った

Code Snippets の一覧をページ送りせずに取ったため、101個目以降が見えていませんでした。

同じ名前のスニペットが無いと判断して、毎回新しく作り、同じものが3つ並んでいました。

一覧の取得は、全ページを取る部品に一本化しています。

事故から決めた3つの決まり

決まり	中身
控え	書き込む前に、元の本文をファイルに残す
範囲	置換は対象のブロックの中だけに限る
検算	保存後に取り直し、文字数・IDの数・公開ページの見た目を比べる

当方が自動化の書き込みで守っている決まり