WordPress保守をAIで自動化するのは本当に可能なのか

WordPress保守をAIで自動化できるのか。結論から言うと、かなりの部分はできます。

ただし、それは「AIに本番サイトを自由に触らせる」という意味ではありません。AIに向いているのは、更新候補の整理、エラーの一次確認、バックアップ状況の確認、修正案の下書き、ステージング環境での検証、レポート作成などです。反対に、本番更新、削除、権限変更、データベース一括置換、テーマ切替のような作業は、人が止めるポイントを残さないと危険です。

この記事では、WordPress保守をAIで自動化する場合の現実的な範囲を、MCP、REST API、WP-CLI、ステージング検証の観点から整理します。あわせて、Shopify運用コマンド自動化との違い、事故を減らすための運用ルールも実務目線でまとめます。

WordPress保守のAI自動化はどこまで現実的か

まず前提として、WordPress保守のAI自動化は可能です。ただし、最初から「完全自動」を目指すよりも、「AIが調べる、人が承認する、機械が実行する」という3段階に分けたほうが安全です。

WordPressにはREST APIがあり、投稿の作成、更新、メディア操作などを外部から扱えます。さらにWordPress公式では、Abilities APIをMCPのtools、resources、promptsへ変換し、Claude DesktopやVS CodeなどのMCPクライアントからWordPressの機能を呼び出す構成が示されています。

出典: WordPress.org News「From Abilities to AI Agents: Introducing the WordPress MCP Adapter」（英語）

一方で、WordPressはサイトごとの差分が大きいCMSです。テーマがSWELLなのか、独自テーマなのか。カスタム投稿タイプがあるのか。会員機能や予約機能が入っているのか。キャッシュプラグインやセキュリティプラグインが何をしているのか。これらが違うだけで、同じ「プラグイン更新」でも影響範囲が変わります。

つまり、WordPress保守のAI自動化は「保守担当者を不要にする仕組み」ではありません。むしろ、保守担当者が見落としやすい確認作業を速くし、判断に必要な材料をそろえる仕組みです。

AIに任せやすい保守作業

保守作業は、情報を集める作業、判断を補助する作業、実際に本番を変更する作業に分けて考えると安全です。AIに任せやすいのは、前半の2つです。

たとえば、次のような作業はAI自動化と相性が良いです。

• WordPress本体、テーマ、プラグインの更新候補を一覧化する
• エラーログ、PHPバージョン、サーバー環境の情報を整理する
• バックアップの取得日時、保存先、復元可否を確認する
• 問い合わせフォーム、予約フォーム、決済導線などのチェック項目を作る
• 更新前後の表示差分をブラウザ検証で確認する
• 保守レポートの下書きを作る

これらは、AIが「状況を読む」「表にする」「手順化する」ことで価値を出しやすい領域です。人が毎回ゼロから確認するより、AIに一次チェックを任せたほうが速く、抜け漏れも減らしやすくなります。

たとえばホームページの保守費用を考えるときも、単に月額いくらかではなく、何をどこまで見ているかが重要です。保守範囲の考え方は、ホームページ保守費用の考え方を整理した記事でも解説しています。AIを入れる場合も、まず保守範囲を分解し、AIが担当する作業と人が責任を持つ作業を分ける必要があります。

保守タスク	AIとの相性	人の確認
更新候補の棚卸し	高い	更新順と影響範囲を確認
バックアップ確認	高い	復元テストは人が確認
表示崩れチェック	高い	重要ページは目視確認
エラー原因の一次調査	中程度	仮説の妥当性を確認
本番更新の実行	低い	承認者が必須
削除・権限変更	低い	原則として人が実行

AI任せにしてはいけない作業

逆に、AIへそのまま任せると事故になりやすい作業もあります。判断基準はシンプルで、「失敗したときにすぐ戻せない作業」「売上や問い合わせに直結する作業」「権限が広がる作業」は、人が止めるべきです。

特にリダイレクトは、1行の設定ミスで検索流入やCV導線に影響します。301と302の違いを理解せずにAIへ修正させるのは危険です。リダイレクトの基礎は、301リダイレクトと302リダイレクトの違いも参考にしてください。

また、ドメインやサーバー契約の管理もAI任せにしないほうがよい領域です。AIは期限の一覧化や通知文の作成には向きますが、契約更新、DNS変更、支払い情報の変更は人が確認すべきです。ドメイン期限の見落としはサイト停止につながるため、ドメイン有効期限管理の記事で触れているように、管理表と通知の二重化が必要です。

AI自動化では、メールや通知の扱いにも注意が必要です。たとえばサーバーや管理画面を装った認証メールをAIが本物と誤認し、担当者にそのまま転送すると、フィッシング被害の入口になります。エックスサーバーを装う認証スパムのような例は、エックスサーバー認証スパムの注意点も確認しておくと安全です。

最小構成でWordPress AI保守を始める手順

最小構成は、WordPress MCP Adapter、REST API、Application Passwords、WP-CLI、ステージング環境、監査ログの6点です。ここをそろえると、AIに調査と検証を任せつつ、本番反映を人が止められる形にできます。

1. まずステージング環境を用意する

最初に必要なのは、AI用の実験場です。本番サイトでいきなりAIに更新を試させるのではなく、ステージング環境を用意します。プラグイン更新、テーマ更新、PHPバージョン変更、フォーム送信テストなどは、ステージングで先に試します。

2. 読み取り中心の権限から始める

次に、AIが触れる権限を絞ります。WordPress公式のApplication Passwordsは、ユーザー画面で生成、確認、取り消しができます。AI接続用に専用ユーザーを作り、最初は読み取り中心にして、不要になったら取り消せるようにしておきます。

MCPを使う場合も同じです。WordPress公式のMCP Adapterリポジトリでは、HTTPやSTDIOといった接続方式、検証（validation）、権限制御（permission control）などの構成が説明されています。便利さより先に、どのAbilityを公開するか、どのユーザーで実行するか、ログをどう残すかを決めます。

出典: WordPress/mcp-adapter（GitHub）（英語）

3. WP-CLIは実行役ではなく手順化に使う

WP-CLIは、WordPress保守の自動化で非常に強い道具です。たとえば「wp plugin update」「wp theme update」「wp core update」などのコマンドで、更新作業を手順として扱えます。

出典: WP-CLI Commands「wp plugin update」（英語）

ただし、AIにいきなり本番実行させる必要はありません。AIには、更新対象の一覧、実行順、事前バックアップ、確認ページ、ロールバック手順をまとめさせます。その上で、人が承認し、必要に応じて担当者がコマンドを実行する形で十分です。

4. ログと差分を残す

AI自動化を入れるときほど、「誰が、いつ、何を、なぜ変更したか」を残す必要があります。AIの出力だけでは証跡として弱いので、実行コマンド、対象ファイル、更新前後のスクリーンショット、エラーログ、承認者を残します。

WordPress公式のHardeningドキュメントでも、バックアップ、未使用プラグインの削除、管理画面からのファイル編集無効化などが推奨されています。AI自動化は、基本対策の代わりではなく、基本対策を確認し続けるための補助と考えるべきです。

Shopify運用コマンド自動化との違い

Shopify運用コマンド自動化と比べると、WordPress保守はサイトごとの個別差分が大きい点が違います。Shopifyは商品、カート、注文、顧客アカウントなどのコマースデータを中心に設計されており、Shopify公式のStorefront MCPでも、商品探索やカート管理などが主な用途として説明されています。

出典: Shopify.dev「Storefront MCP server」（英語）

一方、WordPressはCMSです。同じWordPressでも、企業サイト、採用サイト、病院サイト、EC連携サイト、会員サイトで構成が大きく変わります。テーマ、プラグイン、独自ブロック、カスタム投稿タイプ、フォーム、キャッシュ、サーバー設定が絡むため、AIのコマンドをそのまま横展開しにくいのです。

Shopifyを選ぶべきか、WordPressで組むべきかという判断は、そもそもの運用思想にも関係します。ECでShopifyを検討している場合は、Shopify比較の記事も参考になります。EC運用の定型化を重視するならShopify、コンテンツや独自ページ運用の自由度を重視するならWordPressという考え方です。

比較軸	WordPress保守	Shopify運用
対象	テーマ、プラグイン、投稿、フォーム、サーバー	商品、在庫、注文、カート、顧客
個別差分	大きい	比較的定型化しやすい
AIに任せやすい作業	確認、検証、修正案作成	商品情報整理、FAQ、運用コマンド
注意点	本番変更の影響が読みにくい	注文や顧客情報の権限管理が重要

事故を減らす運用ルール

AI自動化で一番避けたいのは、便利になった結果、誰も中身を見なくなることです。そこで、次のルールを先に決めます。

AI生成コードについては、「動くかどうか」だけで見ないほうが安全です。条件分岐が増えすぎていないか、関数が長くなりすぎていないか、既存テーマやプラグインの責務を壊していないか、戻す手順があるかを確認します。サイクロマティック複雑度のような指標を参考にする考え方もありますが、特定の閾値を機械的に当てはめるより、保守しやすさとテストしやすさを現場ごとに判断したほうが実用的です。

また、MCPやローカルエージェントを使う場合は、AIが実行できるコマンドにも注意します。MCPのSecurity Best Practicesでは、トークンの扱い、SSRF、ローカルMCPサーバーの権限などがリスクとして挙げられています。WordPress保守でも、削除系コマンド、sudoを伴う操作、秘密情報を読む操作は、AIから直接実行できないようにしておくべきです。

明日から試すチェックリスト

最後に、AI自動化を入れる前に確認したいチェックリストを置いておきます。全部を一気にやる必要はありません。まずは読み取り、次にステージング検証、最後に人手承認付きの本番反映という順番で進めます。

1. 保守対象のWordPress本体、テーマ、プラグイン、PHP、サーバー情報を一覧化する
2. バックアップの保存先、取得頻度、復元方法を確認する
3. ステージング環境を用意する
4. AI接続用の専用ユーザーを作り、権限を限定する
5. MCP、REST API、WP-CLIのうち、まずは読み取り中心で使う範囲を決める
6. 更新候補一覧、影響範囲、確認ページ、戻し方をAIに整理させる
7. ステージングで更新し、表示、フォーム、ログイン、検索導線を確認する
8. 本番反映前に担当者が承認する
9. 反映後にログ、問い合わせ、エラーログ、主要ページを確認する

この順番で始めれば、AIを使いながらも、事故が起きたときに戻せる余地を残せます。WordPress保守のAI自動化は、万能スイッチではありません。ですが、保守作業を分解し、権限を絞り、ステージングで検証するなら、十分に実務で使える段階に来ています。

まとめ

WordPress保守をAIで自動化することは可能です。特に、更新候補の整理、脆弱性情報の確認、バックアップ状況の確認、ステージング検証、差分レポート、保守報告書の下書きは、AIと相性が良い領域です。

一方で、本番変更、削除、権限変更、データベース一括置換、テーマ切替はAI任せにしないほうが安全です。MCPやREST API、WP-CLIは強い道具ですが、強い道具ほど権限設計と承認フローが重要になります。

最初の一歩は、AIに「実行」ではなく「確認」と「整理」を任せることです。そこからステージング検証、人手承認、本番反映後の監視へ進めれば、WordPress保守はかなり現実的に自動化できます。

FAQ