止血（先に戻す）の手順

原因が分からなくても、サイトを戻すことはできる。 この2つを混ぜないのがこのSkillの中心。

いつこのファイルを使うか:

• サイトが落ちていて、原因調査に時間がかかりそうなとき
• ECや会員制で、止まっている時間そのものが損失のとき
• 切り分けの途中でさらに壊れたとき

---

判断: 戻すべきか、直すべきか

最後の行が重要。 「動いていた頃へ戻す」は、侵害の場合にバックドアも戻す。

---

戻す前に必ず確認する: 何が消えるか

DBを戻すと、バックアップ取得時刻より後に入ったデータは消える。

PREFIX=$(wp db prefix)
wp db query "SELECT post_type, COUNT(*) AS count FROM ${PREFIX}posts WHERE post_date_gmt > '<バックアップ時刻(UTC)>' GROUP BY post_type;"
wp db query "SELECT COUNT(*) FROM ${PREFIX}users WHERE user_registered > '<バックアップ時刻>';"

投稿テーブル以外に保存される業務データ（WooCommerceのHPOS、問い合わせプラグインの専用テーブル、 会員プラグイン）はこのSQLでは拾えない。各プラグインの管理画面でも確認する。

消えるデータがある場合、件数と種類をサイト所有者へ提示し、同意を得てから実行する。 受注データが動いているECでは、DBの全戻しは原則行わない。ファイル側だけ戻して切り分ける。

---

1. ファイルだけ戻す（DBを触らない）

多くの障害はコード側で起きる。DBを戻さずに済むならその方が安全。

# 現状を先に退避（戻した結果さらに悪化したときのため）
mkdir -p ~/wp-triage/rollback-$(date +%H%M%S)
cp -a wp-content/plugins  ~/wp-triage/rollback-$(date +%H%M%S)/plugins-broken
cp -a wp-content/themes   ~/wp-triage/rollback-$(date +%H%M%S)/themes-broken
cp -a wp-config.php       ~/wp-triage/rollback-$(date +%H%M%S)/wp-config.php.broken

そのうえで、バックアップアーカイブから該当ディレクトリだけを展開して置き換える。 全部を上書きしない。 障害と無関係な部分まで巻き戻すと、別の不整合が出る。

2. プラグイン1つを戻す

原因のプラグインが分かっている場合、これが最小の戻し方。

wp plugin install <slug> --version=<以前のバージョン> --force
wp plugin activate <slug>
wp plugin auto-updates disable <slug>     # 戻したものが翌日また上がるのを防ぐ

最後の行を忘れると同じ事故が再発する。 自動更新は「戻した」を尊重しない。

wordpress.org 以外の配布（有料・独自）はバージョン指定で取得できない。 退避ディレクトリか、配布元の旧版パッケージが必要になる。無ければ戻せない。

3. コアを戻す

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

メジャーを跨いで戻すのはリスクが高い。 新しいコアで更新されたDBスキーマは、 update-db だけでは完全に戻らないことがある。コア起因が確実な場合に限る。

4. DBを戻す（最終手段）

# 現状のDBを必ず先に退避
wp db export ~/wp-triage/db-broken-$(date +%Y%m%d-%H%M%S).sql
chmod 600 ~/wp-triage/db-broken-*.sql

wp db import <バックアップ>.sql

• 実行前に「何が消えるか」の提示と同意（上記）。
• 実行後、siteurl / home がその環境の値になっているか確認する。 別環境のダンプを戻すと、URLが別サイトを指す。

  wp option get siteurl ; wp option get home
  

• 退避したダンプは個人情報を含む。公開ディレクトリに置かず、保管期限を決める。

5. どうしても復旧できないとき

サイトを落としたままにするより、状況を伝える静的ページを出すほうが損失が小さい場合がある。

• 復旧作業中である旨と、連絡先を出す
• 復旧見込み時刻を、根拠なく書かない
• 元のサイトのファイルを消さない（そのまま別ディレクトリへ退避する）

これは復旧ではなく時間を買う手段。「直った」と報告しない。

---

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

1. SKILL.md Step 7 の4層確認（ブラウザ／WPキャッシュ／CDN／サーバー）を通す。
2. 200を返したまま壊れる箇所（フォーム、ログイン、決済、編集画面）を開く。
3. なぜ壊れたかを、戻したあとに調べる。 調査でサイトを止め続けない。
4. 同じ更新・作業を再度行う前に、ステージングで再現させる。 ステージングが無いなら、その作業は保留として理由とともに伝える。
5. 戻した内容・消えたデータ・未解明の点を記録する。 原因が分からなかったなら「分からなかった」と書く。