ManageWP・MainWP・WP Umbrella・InfiniteWP の比較ページを LP 上で 1 本ずつ書く過程で、4 社の「サイトへの接続方式」を 1 列で並べようとして詰まったことがあります。同じ ManageWP に対して「Hosted SaaS 型」「Worker プラグイン型」「セルフホスト型」と呼び方が複数存在する。
よく見ると、これらは異なる 2 つの軸が 1 列に混在しているのだと気づきました。整理し直すと、4 社は 2 軸 6 マスのマトリクスに綺麗に収まります。今回はそのマトリクスを起こして、各マスがどんな運用上の特徴を持つのかを整理しておきます。
軸 1 — サイト側に何を置くか
「保守ツールが管理対象サイトに何をインストールするか」を問う軸です。
- A. Worker / Child プラグイン経由: 各サイトに保守ツール専用のプラグインを置く。ManageWP Worker・MainWP Child・WP Umbrella・InfiniteWP Client — 名前は違えど同じ役割の「窓口プラグイン」で、ダッシュボードはその REST/HTTP エンドポイント経由でサイトと通信する。
- B. SSH + WP-CLI で直接接続: サイトには何もインストールしない。SSH でサーバーに入って WP-CLI を呼び出す。
違いは クライアントサイトへの侵襲度として現れます。プラグイン経由は「窓口プラグイン自身に脆弱性が出ると全管理対象が連鎖する」「クライアントへの説明責任が発生する」。SSH 直接は「SSH を許可していないサーバーには到達できない」「運用者に SSH の基礎知識が要る」という制約を持ちます。
軸 2 — ダッシュボードの居場所
「ダッシュボード本体がどこに存在するか」を問う軸で、3 通りに分かれます。
- ① Hosted SaaS: ツールベンダーが運営するクラウドにダッシュボードがある。認証情報もクラウドに保存される信頼モデル。
- ② セルフホスト: 自前で WordPress サイトやサーバーを用意し、そこにダッシュボードを設置する。データは自分の管理下だが、ダッシュボード基盤自身の保守責任も自分で負う。
- ③ デスクトップアプリ: ダッシュボードが PC 内で動く。データもローカル保存・クラウド要素なし。
軸 2 は データの所在と責任分界点を決めます。事故時に誰が責任を負うのか、認証情報を誰が保管するのか — このマス選択で組織として引き受けるリスク構造が変わります。
2 軸を重ねた 6 マスのマトリクス
| ダッシュボード ↓ ／ 接続経路 → | Worker/Child プラグイン経由 | SSH + WP-CLI 直接 |
|---|---|---|
| ① Hosted SaaS | ManageWP・WP Umbrella | （業界に空白） |
| ② セルフホスト | MainWP・InfiniteWP | （業界に空白） |
| ③ デスクトップ | （業界に空白） | WP Maintenance Manager |
主要 4 社は「Worker 経由」列の上 2 マスに集中していて、SSH 直接列はほとんど空白です。占有されている 3 マスをそれぞれ見ていきます。
マス 1 — Hosted SaaS × Worker（ManageWP・WP Umbrella）
業界で最も古典的な構成です。ブラウザでどこからでもアクセスできる・ベンダーがインフラ更新と冗長化を引き受けてくれる・常時稼働監視と相性が良い。WP Umbrella の EU 拠点ホスティングのように、データレジデンシーをセールスポイントにできるのもこの構成ならではです。
トレードオフは クライアント認証情報をサードパーティクラウドに預ける信頼モデルであること。ベンダーのサーバーが侵害されれば全管理対象に波及するリスクがあり、ベンダーの事業継続性そのものに依存します。料金は月額に加えて「サイト × アドオン」が積み上がる構造になりがちです。
マス 2 — セルフホスト × Worker（MainWP・InfiniteWP）
クラウドに認証情報を預けたくないが Worker 経由の互換性は欲しい、というニーズの受け皿。データの完全所有と買い切り・年間ライセンスとの親和性がメリットです。
トレードオフは ダッシュボード基盤の保守責任が自分に降りてくること。MainWP は「ダッシュボード用 WordPress サイト」自身を更新・セキュリティ管理し続ける必要があり、InfiniteWP も自前パネルサーバーの面倒を見る必要がある。保守ツールの保守を保守するメタな再帰が起きるマスです。侵害時には、ダッシュボード基盤が落ちると接続している全クライアントサイトの認証情報が露出するリスクも抱えます。
マス 3 — デスクトップ × SSH（WP Maintenance Manager）
ダッシュボードを PC 上のアプリとして動かし、サイトへは SSH で直接接続する構成。データがローカル PC 内のみ・インフラ運用ゼロ・クライアントサイトに何も置かないの 3 点が特徴で、Worker プラグインの脆弱性連鎖を構造的に回避できます。
トレードオフは 常時稼働監視には向かないこと。PC がスリープしている時間帯は監視ループが動かない。また SSH を許可していないレンタルサーバーは対象外になるため、業界の対応サーバー網は他マスより狭くなります。
空白の 3 マスはなぜ空白なのか
残り 3 マスに該当製品がほぼ存在しないのは、構造的に説明がつきます。
- Hosted SaaS × SSH は、SSH 秘密鍵をクラウド事業者に預ける信頼モデルが市場で受け入れられにくい。Worker 経由なら認証情報はサイト側に閉じて済むため、SSH 鍵をクラウド側で保管・利用するモデルは監査上のハードルが高い。
- セルフホスト × SSH は技術的には可能だが、「自前のダッシュボード基盤を持つコスト」と「SSH 接続の制約」が二重に乗るため選好されにくい。
- デスクトップ × Worker は、Worker プラグインの一部が前提とする「ダッシュボードへの常時 push 通信」と、デスクトップアプリの「PC が起動している時間だけ動く」性質が噛み合わない。
まとめ — マスを選ぶ判断軸
どのマスを選ぶかは「許容コスト」と「責任分界点」のトレードオフです。比較検討時に効く判断軸は次の 3 つに集約できます。
- クラウドに認証情報を預けるか・自分の手元で持つか（軸 2 の上下）
- クライアントサイトに保守用プラグインを常駐させるか・避けるか（軸 1 の左右）
- インフラ運用の責任を負うか・負わないか（軸 2 のセルフホストだけ責任が増える）
業界の主流が「Hosted SaaS × Worker」と「セルフホスト × Worker」に二極化しているのは、SSH 経路の制約（対応サーバーの限定・運用者の SSH 知識要件）が業界全体での採用を難しくしてきた歴史的経緯によるものです。一方で SSH 列を選べば、Worker プラグインに伴うサイト側の侵襲度と窓口プラグイン脆弱性の連鎖リスクを構造的に避けられる選択肢が生まれます。
「正しい接続アーキテクチャ」は存在せず、運用スタイル・クライアントとの契約・データ取り扱い要件で最適マスは変わります。比較検討のフレームとして、この 6 マスを意識しておくと、自社の保守運用にとって何が本当に重要かが見えやすくなります。