WordPressでAIエージェントに何を任せる？自動化できる仕事と承認すべき操作

AIエージェントは、通常の生成AIより「外部toolを使いながら複数stepを進める」点が特徴です。WordPressでは、記事一覧を読む、対象記事を取得する、差分を作る、画像を確認する、draftを更新するといったtoolを組み合わせられます。

一方で、WordPress運営は正解が1つではありません。SEO、収益、ブランド、法的表現、一次情報が絡むため、Agentが長く自律実行するほど、最初の判断ミスが後工程へ伝播します。そこで「Agentに何ができるか」より「どこで必ず止めるか」を先に決めます。

WordPress業務を3段階に分ける

この3区分は固定ではありません。同じ「内部リンク追加」でも、候補抽出は自律、本文への挿入は承認付き、と細分化できます。tool単位でrisk levelを持つと、Agent全体をON/OFFするより柔軟に運用できます。

仕事別：AIエージェントへ任せる範囲

任せやすい仕事1：観測と棚卸し

Agentが最も安全に価値を出しやすいのはread-onlyです。公開記事数、更新日、meta欠損、featured image、リンクstatus、Search Consoleの変化などを複数sourceから集め、「今日見るべき3件」を作るところまで任せられます。

この用途では、AIの文章精度よりtoolの取得結果が重要です。Agentが数字を記憶から推測しないよう、必ずsource toolから値を取得し、取得できなければ「不明」と返すルールにします。

任せやすい仕事2：変更候補と差分を作る

既存記事のtitle/meta改善案、古い公式情報の差分要約、内部リンク候補、見出しの整理などは、Agentが候補を作る用途と相性があります。人はゼロから調査するのではなく、差分とsourceを見て採用/却下できます。

重要なのは、Agentに「最適化して」とだけ指示せず、変更対象と禁止事項をtool側で制限することです。slug変更禁止、ASP URL変更禁止、本人一次情報の新規生成禁止など、守るべき条件をWordPressへのwrite関数が拒否できる形にします。

承認付きにする仕事：draft・meta・限定更新

Agentが必要なsourceを調べ、変更案を作り、WordPressへdraftとして保存するところまでは自動化できます。ただし公開記事の上書きでは、before/afterを見せて承認を取る方が安全です。

承認画面には全文ではなく、「title変更」「H2追加」「公式仕様の数値更新」「内部リンク2本追加」のような差分要約と、実際のdiffの両方を出します。要約だけではAgentが重要な変更を省く可能性があるため、原文diffへ戻れる設計が必要です。

承認画面には「何を・なぜ・どの権限で変えるか」を出す

承認ボタンだけを置くと、人は内容を読まずに通しやすくなります。実務では、対象site/post、呼び出すtool、変更field、変更理由、参照source、before/after、想定risk、rollback方法を1画面で確認できる方が安全です。特に外部情報を根拠にする更新では、Agentの要約だけでなく参照URLと取得日時を残します。

承認は長期的な「このAgentなら何でも許可」ではなく、その操作にだけ使える短い許可として扱います。例えばpost 123のmeta更新を承認しても、別postのpublish権限まで引き継がせません。承認対象をtool call単位またはtransaction単位に限定すると、会話の流れで権限が膨らむのを防げます。

任せない仕事：不可逆・高影響・根拠が人にしかない判断

• URL/slugの変更や301設計
• 記事・mediaの完全削除
• 大量記事の一括公開
• アフィリエイトの推奨順位や未確認の実使用評価
• 契約・料金・保証を伴う断定
• credential・ユーザー権限・plugin/themeの本番変更

これらも技術的にはAgentから実行できますが、「できる」と「任せるべき」は別です。特に実体験はtoolで取得できないため、Agentに「それらしい体験談」を補完させるとE-E-A-Tでは逆効果になります。本人が確認した事実だけをdataとして渡します。

Agentを壊れにくくする運用設計

Agentの賢さよりtool境界が重要

同じmodelでも、toolが「update_post(id, html)」の1個だけなら広い権限を持ちます。逆に「update_meta_description(id, value)」「create_draft(title, content)」のように副作用を限定すれば、Agentが誤判断しても影響範囲を狭められます。

WordPress Abilities APIは、機能ごとにinput/output schema、permission、annotationを持たせられるため、このtool境界を作る基盤として使えます。MCPはAgentからそれらを発見・呼び出す接続層です。

状態を持たせるなら「記憶」と「正本データ」を分ける

Agentが前回の作業を覚えていると便利ですが、投稿statusや価格、公開URLのような事実を会話memoryだけへ置くのは危険です。正本はWordPress/DB/manifestに置き、Agentは毎回必要な状態を読み直します。

「前回はこのpost IDだった」という記憶と、現在のWordPressが一致しなければ現在値を優先し、差分を人へ報告します。長期Agentほど、古い状態を自信を持って使うことへの対策が必要です。

複数Agentを作る前に1本のworkflowを安定させる

SEO Agent、画像Agent、WordPress Agentを分ける設計は魅力的ですが、Agent間の引継ぎが増えると「誰が最終状態を決めたか」が追いにくくなります。最初は1本のworkflowで、入力→source→候補→QA→承認→writeを安定させます。

分割するなら責務を明確にします。調査AgentはWeb情報とsourceを返すだけ、編集Agentはdraftだけ、公開は固定ロジック、というように副作用が重ならない分け方が扱いやすいです。

評価指標は「自動実行回数」ではない

Agent導入で毎日100操作できても、確認や復旧に時間がかかれば効率化とは言えません。少ないtoolでも、人がやっていた確認を確実に減らし、エラー時に原因を追える方が実運用では価値があります。

WordPress Agentを始めるならこのtrust ladder

1. Level 0：回答だけ。WordPressへ接続しない
2. Level 1：read-onlyで状態取得
3. Level 2：候補・レポートを生成
4. Level 3：draft/限定fieldへwrite、必ず承認
5. Level 4：低リスクの定型writeだけ自動実行
6. Level 5：複数toolを自律選択。ただし高リスク操作は承認必須

最終Levelへ行くことが目的ではありません。サイト規模が小さく、更新頻度も低いならLevel 2〜3が最も費用対効果が高いこともあります。自律性ではなく、運営上の結果で止めるLevelを決めます。

公式情報・参考資料

仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。

• https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/
• https://developer.wordpress.org/news/2026/07/build-your-first-ai-powered-wordpress-plugin/
• https://make.wordpress.org/core/2026/08/04/a-unified-public-exposure-flag-for-abilities-in-wordpress-7-1/

あわせて読みたい

• WordPress×MCPで何ができる？
• Abilities APIのtool設計
• AI自動化のセキュリティ
• AIエージェントの基礎