「Elementor で脆弱性が公開された。管理しているサイトのうち、いくつかに Elementor が入っている。今日中に Elementor だけを横断で更新したい」
WordPress 保守を多サイトで請けていると、こういうシナリオは月に何度か発生します。コア更新や他のプラグイン更新は通常のメンテナンス枠で順次やればいいけれど、特定プラグインだけは緊急で当てたい。
ところが業界の主流ツールには、この「対象を絞った安全な一括更新」をやる UI がほとんどありません。今回はそれをどう設計するか、という話です。
業界主流の「Update All」の限界
多くの WordPress 保守ツールは、各サイトのダッシュボードで「Update All」ボタンを押すスタイルです。
- 押すと全プラグイン更新が一気に走る
- どれか 1 つでも壊れると、業界標準の “Safe Updates” / “Atomic Updates” 機能で全件ロールバック
- 「Elementor だけを上げる」「複数サイトの中で一部だけ対象」のような粒度を持つ操作系がない
業界全体がこの構造に収斂している背景は 4 社調査の 3 つの未解決領域 にまとめたとおりで、Worker プラグイン経由の HTTP API という制約上、粒度を上げにくいという技術的事情があります。
結果として、エージェンシーの「Elementor だけを複数サイトに対して」のような典型タスクが、1 サイトずつ手作業でログインして個別更新になりがちです。
必要だったのは「サイト × プラグイン」の 2 軸粒度
WP メンテナンスマネージャの v1.6.2 では、この問題を 2 軸の粒度で解きました。
- サイト軸: どのサイトのどのプラグインが更新待ちかを一覧で把握できる
- プラグイン軸: 「サイト × プラグイン」の組合せをチェックボックスで選び、その組合せだけを更新する
「Update All」ボタンの代わりに、「選んだ組合せだけを更新するボタン」がある形です。
横断ダッシュボードの設計
ツールバーから「プラグイン更新」を開くと、全サイトを SSH 並列でスキャンして「要更新プラグイン」を一覧化します。
プラグイン名でグループ化されて表示されるので：
Elementor — 複数サイトで要更新（4.0.0 → 4.0.8）
☐ siteA.com
☐ siteB.com
☐ siteC.com
Yoast SEO — 複数サイトで要更新（22.0 → 22.1）
☐ ...
のように、どのプラグインがどのサイトで古いままかが一目でわかります。サイト一覧を横並びで見ていて「Elementor は全部更新したい、Yoast は別タイミングで」のような判断ができる。
取得結果はブラウザにキャッシュされ、アプリ再起動後でも即時表示されます。SSH の並列スキャンは多くのサイトを抱えていても短時間で終わるので、定期的にチラ見しやすい設計です。
選択更新の動きは通常メンテと完全に同じ
ここが核心です。「選択プラグインを更新」ボタンで実行される処理は、通常のメンテナンスとまったく同じ安全機構が動く：
- DB バックアップ（更新前に必ず取る）
- 1 件ずつ HTTP チェック付きで更新 + 問題発生時の自動ピンポイントロールバック（実装の詳細は別記事）
- ビジュアル確認・サマリーメール
通常のメンテナンスとの違いは、Core / テーマ / 翻訳の更新だけがスキップされること。プラグイン更新の中でも、選んだ組合せだけが動く。
ログ履歴とレポートには「選択更新」タグが付与され、対象プラグイン名も記録されます。後から「先月 Elementor を横断で更新したのはいつ・どのサイトに対して」を追跡できる証跡が残る。
まとめ — 粒度を上げると運用が変わる
「Update All」の単純さは便利な一方、サイトをまたいで特定プラグインだけを動かしたいという現実的なニーズには応えにくい構造です。
横断ダッシュボード + 選択更新 + 安全機構維持、という 3 点セットで初めて「対象を絞った安全な一括更新」が成立します。1 件のプラグイン脆弱性公表に対して、影響を受けるサイトだけを 1 アクションで安全に更新できる粒度。
「全部更新するか、何もしないか」の二択だった作業が、狙い撃ちで動かしながら安全機構を全部維持できる形になると、緊急対応と通常メンテの境界線が変わります。