コンテンツへスキップ
WordPress保守

壊れた 1 件だけを戻す — WP-CLI で per-plugin rollback を実装する

プラグイン 20 件をまとめて更新して、そのうちの 1 件がサイトを壊した。多くの WordPress 保守ツールでは、こういうとき安全側に倒して 20 件すべてを元に戻す設計（”Safe Updates” / “Atomic Updates” などと呼ばれる）が一般的です。

ただ運用していると、「壊れた 1 件だけを戻して、残り 19 件は更新を維持したい」場面が増えてきます。今回はその設計を WP-CLI ベースでどう組み立てるか、実装側の話をまとめておきます。

起点になるコマンド — wp plugin install --version=X --force

WP-CLI には、プラグインを「特定のバージョンで上書きインストール」する強力なコマンドがあります。

wp plugin install <plugin-slug> --version=1.2.3 --force --skip-plugins --skip-themes

オプションの意味は：

  • --version=1.2.3 — 上書きする旧バージョンを指定（WP.org の公開バージョンならどれでも）
  • --force — 既に同名プラグインが存在しても上書きする
  • --skip-plugins --skip-themes — WP-CLI 起動時のプラグイン/テーマロードをスキップ（壊れたプラグインがある状態でも WP-CLI 自身が落ちない。詳細は別記事）

このコマンド 1 行で「プラグインを旧版にピンポイントで巻き戻す」が実現できます。あとはこれを 更新フローのどこで・どんな条件で叩くかの設計次第です。

HTTP チェックと組み合わせる

ステップごとに HTTP ステータスを取り、変化を検知する：

プラグイン更新前: GET / → 200
↓
wp plugin update <plugin-slug> --skip-plugins --skip-themes
↓
プラグイン更新後: GET / → 500 ← 壊れた！
↓
wp plugin install <plugin-slug> --version=<旧版> --force --skip-plugins --skip-themes
↓
ロールバック後: GET / → 200 ← 復旧
↓
次のプラグインへ進む

更新の単位を「全部まとめて」ではなく「1 件ずつ + HTTP チェック」にすることで、どのプラグインで壊れたかが明確になります。

ロールバック対象の特定

「直前に更新したプラグイン」がそのまま犯人候補です。これは bulk update では成立しません（複数同時更新だと、HTTP が 500 を返したときどのプラグインが原因か絞り込めない）。

1 件ずつ更新する設計の利点は、HTTP が変化した瞬間のプラグインが、即座に巻き戻し対象として確定することです。誤って関係ないプラグインまで戻すリスクがない。

旧バージョンの値は「更新前」のスナップショットから取れます：

# 更新前に控えておく
wp plugin list --format=json --skip-plugins --skip-themes > /tmp/plugins_before.json

# ロールバック対象のスラグから旧版を引く
prev_version=$(jq -r '.[] | select(.name=="<slug>") | .version' /tmp/plugins_before.json)

これでスナップショットから旧版を引いて巻き戻し、検証して問題なければ次のプラグインへ進む、というループが成立します。

復旧確認 — 戻したら必ず HTTP を再チェック

ロールバック後にもう一度 HTTP を取り、200 に戻っているかを確認します：

  • ✅ 200 に戻った → そのプラグインだけ更新を諦め、次のプラグインへ
  • ❌ まだ 500 → ロールバックでは復旧できない（壊れた状態が PHAR バイナリ自体ではなく、DB スキーマや別ファイルに残っている等）→ より重い処理（DB 全体ロールバック・キャッシュフラッシュ・テーマ自動切替など）へエスカレーション

この段で「巻き戻したら確実に直る」と思い込まず、戻した直後にもう一度確認するのがポイント。--force での上書きインストールはファイル置換しか行わないため、DB 側の不整合は別途検出が必要です。

まとめ — 「全体を戻す」と「1 件だけ戻す」の選択

業界主流の「全部まとめて戻す」設計は実装が単純で安全側に倒れる利点があり、選ばれる理由はちゃんとあります。一方で「壊れた 1 件だけを戻す」設計は、運用視点では：

  • 壊した犯人がログに直接残る
  • 安全に終わったプラグインの更新は維持される
  • 次回の保守タスクで巻き戻し分だけ再試行できる

という利点があります。実装側の手間と引き換えに、運用の透明性と継続性が上がる、というトレードオフ。

WP-CLI の --version=X --force という小さなコマンドが、この設計を支えています。SSH と WP-CLI が使えるレンタルサーバーでの保守自動化を考えている方には、ぜひ覚えておいてほしいフラグの組合せです。

業界全体がこの per-plugin rollback を採用していない構造的背景は、業界 4 社調査の 3 つの未解決領域 も併せてどうぞ。