AGENT VENTURESTUDIO / 01
← CLAUDE-PENGIN-TOOLS
DOCUMENT · 7.0 KB

skills/wordpress-maintenance/references/ROLLBACK.md

Workspace snapshot · 09/04 13:33

戻し方（ROLLBACK）

更新する前にこのファイルを読み、どの手段で戻せるかを確定させる。 戻す手段が確保できていない対象は、更新しない。

前提: plugins-before.csv / themes-before.csv / core-version.txt / db-before-update.sql が ~/wp-maint/<日付>/ に保存されていること（SKILL.md Step 2・Step 4）。

目次

  1. プラグイン / 2. テーマ / 3. コア / 4. DB / 5. 復旧後 / 戻せないケース

判断: まず「何が壊れたか」で戻す範囲を決める

症状戻す範囲
特定の機能だけ壊れた（フォーム、カート、ビルダー）そのプラグイン1つだけ
更新直後から真っ白 / 500直前の束すべて。切り分けは戻してから
管理画面に入れないプラグイン全停止 → 1つずつ有効化
表示は無事だがデータが消えた（ウィジェット、設定）DBを戻す（プラグインを戻しても直らない）

DBを戻すと、更新後に投稿・注文・問い合わせが入っていた場合それも消える。 DBリストアの前に、必ず「更新後に新しいデータが入っていないか」を確認し、利用者へ影響を提示する。

1. プラグインを1つ前のバージョンへ戻す

plugins-before.csv から、そのプラグインの更新前バージョンを確認する。

grep '^<slug>,' ~/wp-maint/<日付>/plugins-before.csv

wordpress.org で配布されているもの

wp plugin install <slug> --version=<更新前のバージョン> --force
wp plugin activate <slug>

--force は既存を上書きするために必要。--version を省くと最新版が入り、戻したことにならない。

戻した直後に、そのプラグインが担う機能を実際に動かして確認する（フォームなら送信、カートならテスト注文）。

有料 / 独自配布のもの

wp plugin install --version= は使えない。次のどちらか。

  1. 更新前に退避したディレクトリを戻す（SKILL.md Step 4 で cp -a した場合） 
    wp plugin deactivate <slug>
mv wp-content/plugins/<slug> ~/wp-maint/<日付>/<slug>-failed-$(date +%H%M%S)
cp -a ~/wp-maint/<日付>/plugins-backup-<slug> wp-content/plugins/<slug>
wp plugin activate <slug>
  2. 配布元から旧バージョンのzipを取得して入れ直す 
    wp plugin install /path/to/<slug>-<旧バージョン>.zip --force
    配布元が旧バージョンを提供していない場合、この手段は存在しない。 だからSKILL.md Step 4で、更新前のディレクトリ退避を必須にしている。

WP-CLIが無い場合

  1. 管理画面 > プラグイン で対象を停止する。
  2. wordpress.org のプラグインページ > 「高度な表示」から旧バージョンのzipをダウンロードする。
  3. 管理画面 > プラグイン > 新規追加 > プラグインのアップロード でzipを入れ、置き換える。
  4. 有効化して、担当機能を実際に動かす。

FTP/ファイルマネージャが使える場合は、wp-content/plugins/<slug> を退避済みのものへ入れ替える。 入れ替え前に、現在のディレクトリも別名で残す（戻した結果さらに壊れたときのため）。

2. テーマを戻す

wp theme install <slug> --version=<更新前のバージョン> --force
wp theme activate <slug>

子テーマを使っている場合、親テーマを戻しても子テーマの改変は残る。 逆に、子テーマを使わず親テーマを直接改変していた場合、更新した時点で改変は消えている。 その場合はテーマファイルのバックアップからの復元が必要で、無ければ復旧できない。 更新前にこの点を確認する。

3. コアを戻す

wp core update --version=<更新前のバージョン> --force
wp core update-db

メジャーバージョンを戻すのはリスクが高い。 新しいコアで動作したDBスキーマを古いコアへ戻すため、 update-db で完全には戻らないことがある。 コア更新で壊れた場合は、コアだけでなくDBもセットで戻すほうが安全な場合が多い。

4. DBを戻す

最終手段。実行前に必ず影響を提示して同意を得る。

# 現状をまず退避（戻した結果が悪化したときのため）
wp db export ~/wp-maint/<日付>/db-before-rollback.sql

# 戻す
wp db import ~/wp-maint/<日付>/db-before-update.sql

実行前に必ず確認すること:

  • 更新後に新しい投稿・注文・問い合わせ・会員登録が入っていないか。入っていれば、それらは消える。
  • 消えるデータがある場合、先にその範囲を書き出して利用者へ提示する。 
    PREFIX=$(wp db prefix)
wp db query "SELECT post_type, COUNT(*) AS count FROM ${PREFIX}posts WHERE post_date_gmt > '2026-08-26 08:00:00' GROUP BY post_type;"
    日時は実際の更新開始時刻（UTC）へ置き換える。WooCommerceのHPOSなど、投稿テーブル以外へ保存される 業務データはこのSQLでは拾えないため、各サービスの管理画面・専用テーブルでも確認する。
  • WooCommerce等の受注データがある場合、DBリストアは原則行わない。 個別に直す。

WP-CLIが無い場合

phpMyAdmin のインポート、または事業者のバックアップ復元機能を使う。 インポート前に現在のDBをエクスポートして残す。 上書きは取り消せない。

5. 戻したあとに必ずやること

  1. 戻した対象と、戻した先のバージョンを記録へ書く。
  2. なぜ壊れたかを、戻したあとに調べる。 戻す前の調査でサイトを止め続けない。
  3. 同じ更新を再度当てる前に、ステージングで再現させる。 ステージングが無いなら、その更新は保留として利用者へ理由とともに伝える。
  4. 自動更新が有効だと、戻したものが再び自動で上がる。 該当プラグインの自動更新を止める。 
    wp plugin auto-updates disable <slug>
    これを忘れると、翌日同じ事故が再発する。

戻せないケース（先に知っておく）

  • 更新前のバージョン記録が無い → どのバージョンへ戻すか分からない。 Step 2を省略した結果。
  • 独自配布プラグインで、退避もzipも無い → 配布元へ問い合わせる以外の手段が無い。
  • 親テーマを直接改変していた → 改変内容のバックアップが無ければ復旧できない。
  • DBバックアップが壊れている / 空 → Step 4の確認を省略した結果。

このリストは、更新前に潰せるものばかりである。 だから順序を固定している。