WordPress の保守自動化ツールは、海外を中心に長く運用されているマーケットがあります。ManageWP・MainWP・WP Umbrella・InfiniteWP — それぞれ 10 年以上の歴史を持つ製品群です。
LP の比較ページを作る過程で各社の機能を体系的に並べてみたとき、興味深いパターンが浮かび上がりました。4 社とも提供していない機能が、3 つあったのです。
それぞれ業界の中で長年「できないもの」として扱われている領域で、構造的に難しい理由もあります。今回はその 3 つの未解決領域と、なぜそうなるのかを整理しておきます。
業界課題 1 — プラグインを 1 件ずつ HTTP チェック付きで更新する粒度
WordPress プラグインの更新は、多くの保守ツールで 「一括更新（bulk update）」が基本です。更新後にサイト全体のスクリーンショット差分や HTTP ステータスをチェックして、何か起きていれば「Safe Updates」「Atomic Updates」のような機能でまとめてロールバックする設計が主流になっています。
なぜ「1 件ずつ HTTP チェック付き」が業界標準にならないのか。最大の理由は API 設計の制約です。WordPress 標準の wp_ajax_update-plugin や Worker プラグイン経由の API は、複数プラグインをバッチで処理する前提で設計されています。1 件更新するたびに別ホストから HTTP ステータスを取りに行くようなステップ実行は、API 越しのオーバーヘッドが大きくなるため、業界全体が「一括 → 一括検査」の粒度に落ち着いた、という構造的事情があります。
副作用として、どのプラグインが原因で壊れたかの特定は、運用者の手作業に委ねられる場面が多くなります。
業界課題 2 — 失敗した 1 件だけのピンポイントロールバック
業界共通の「Safe Updates」機能は、基本的に 「全部ロールバックする」設計です。プラグイン 20 件をバッチで更新して 1 件が壊した場合でも、20 件すべての更新が巻き戻る。安全側に倒した自然な設計ですが、運用上は「安全に終わった 19 件まで失われる」という副作用があります。
なぜピンポイントロールバックが業界標準にならないのか。これは 状態管理の難しさが根本にあります。ピンポイントで巻き戻すには「更新前の各プラグインのファイル一式」を保管しておく必要があり、ストレージ・転送コスト・依存関係の整合性チェックが Worker プラグイン経由の API では現実的に重い。結果として「全体スナップショット 1 つで巻き戻す」ほうが実装も運用も単純で、業界はそちらに収斂しています。
代替策として WP-CLI ベースのアプローチが取れる場合は事情が変わりますが、後述するように WP-CLI 接続自体が業界の主流ではないため、選択肢として広がりにくい構造になっています。
業界課題 3 — クライアントサイトに追加プラグインをインストールしない接続
これが最も構造的な課題です。4 社とも、クライアントサイトに 自社の Worker / Child プラグインをインストールする運用が前提になっています。ManageWP Worker、MainWP Child、Umbrella、InfiniteWP Client — 名前は違えど、保守ツールから操作を受けるための「窓口プラグイン」を各サイトに置く必要があります。
なぜ業界がこれを採用しているのか。理由は 接続性と互換性の保証です。レンタルサーバーは無数にあり、それぞれ SSH の許可状況・WP-CLI の有無・ファイアウォール構成が違う。WordPress 内部から動く窓口プラグインを一つ置けば、HTTP API 越しに均一なインタフェースで全サイトに到達できる。これは業界の現実的な解です。
ただし副作用として：
- クライアントサイトには「保守会社の管理用プラグイン」が常駐する
- そのプラグイン自体に脆弱性が出れば全クライアントが影響を受ける
- クライアントから「これは何のプラグイン？」と聞かれたら説明が要る
- プラグイン削除（解約時等）でツールの管理対象から外れる
これらを「許容するか、別の接続方式を選ぶか」が、保守ツール選定で意外と効いてくる軸になります。
まとめ — 業界の前提を疑うかどうか
3 つの未解決領域に共通するのは、業界が「ここはこれで十分」と長年合意してきた領域だということです。bulk update + 全体ロールバック + Worker プラグイン経由、という組合せは、技術的にも商業的にも安定しており、4 社が同じ構造で 10 年以上運用してきた事実がその完成度を物語っています。
一方で、これらの「業界共通の前提」を疑うアプローチが存在するのも事実です。SSH + WP-CLI 接続を採用すれば、API 越しのオーバーヘッドを回避できて 1 件ずつのステップ実行とピンポイントロールバックが現実的になり、Worker プラグインも不要になる。トレードオフとして、SSH が許可されたレンタルサーバーに対象が限定される、運用者に SSH の基礎知識が要求される、という制約は出てきます。
どちらが「正しい」という話ではなく、運用スタイルと制約条件の組合せでフィットする選択肢が違う、というだけです。業界の主流である「Worker + bulk + 全体ロールバック」型を選ぶか、それを外したアプローチを選ぶか。比較検討のフレームとして、この 3 つの未解決領域を意識しておくと、自社の保守運用にとって何が本当に重要かが見えやすくなります。