WordPressメンテナンスツールのマッピング
WordPressメンテナンスツールの比較は困難です。ある情報源ではツールを「SaaS」と呼び、別の情報源では「セルフホスト型」と呼んでいます。ほとんどの人が、2つの異なる概念を1つのラベルに混同しています。
選択肢を理解するには、2つの異なる軸を見る必要があります。
軸1：ツールがサイトにどのように接続するか • Worker Plugin（ワーカープラグイン）：管理しているすべてのサイトに小さなプラグインをインストールします。これにより、ダッシュボードがサイトと通信するためのゲートウェイが作成されます。 • Direct SSH（直接SSH）：サイトには何もインストールしません。ツールがSSH経由でログインし、WP-CLIを使用します。
プラグイン方式は簡単ですが、すべてのサイトに脆弱性を追加することになります。SSH方式はクリーンですが、ホスト側でSSHアクセスを許可している必要があります。
軸2：ダッシュボードがどこで動作するか • Hosted SaaS：ベンダーがダッシュボードを運用します。ベンダーのクラウドにサイトの認証情報が保存されます。 • Self-hosted：自身のサーバーでダッシュボードを運用します。データは自身で所有しますが、ソフトウェアの管理も行う必要があります。 • Desktop App：ダッシュボードがローカルコンピュータ上で動作します。データは自身のマシン内に留まります。
これら2つの軸によってグリッドが作成されます。ほとんどの製品は、そのうちの2つのセルにのみ位置しています。
Hosted SaaS + Worker Plugin (ManageWP, WP Umbrella) どのブラウザからでも簡単にアクセスできます。ベンダーが稼働時間を管理します。トレードオフは、クライアントの認証情報を第三者に預けることになる点です。
Self-hosted + Worker Plugin (MainWP, InfiniteWP) データを自身で保持できます。ベンダーに依存する必要もありません。トレードオフは、ダッシュボード自体をメンテナンスしなければならない点です。「ツールを管理するためのツール」を、自ら管理することになります。
Desktop App + Direct SSH (WP Maintenance Manager) 最もプライバシーが守られる方法です。クライアントのサイトには何もインストールされず、データは自身のPC内に留まります。トレードオフは、コンピュータがスリープするとモニタリングが停止することです。
その他の組み合わせの多くには、主要な製品が存在しません。例えば、クラウドベンダーにSSHキーを渡すことは滅多にありません。そのため、「Hosted SaaS + SSH」は非常に販売が難しい構成となります。
ツールを選ぶ際は、次の3つの質問を自分に投げかけてみてください：
- 認証情報をサードパーティのクラウドに置きたいか、それともローカルに保持したいか？
- すべてのクライアントサイトにプラグインを入れたいか、それとも一切入れたくないか？
- 自身のインフラを運用する準備ができているか？
完璧な選択肢はありません。どの選択肢にも、リスク、コントロール、使いやすさの間のトレードオフが存在します。