使うとこうなる（対話例）

これは説明用の想定例です。実サイトの作業ログではありません。 出力形式を示すために書いたもので、ここに出てくるサイト名・プラグイン名・バージョンは架空です。

---

例1: 「プラグイン全部更新して」と頼んだとき

あなた:

プラグインの更新が20件たまってます。まとめて全部上げてください。

Claude（このSkillあり）:

まとめては上げません。理由は、一括で上げて壊れたとき、原因の特定に更新そのものより時間がかかるからです。 3つの束に分けます。

その前に、まだ更新は実行していません。先に現在の状態を記録します。

wp plugin list --fields=name,status,version,update,update_version --format=csv > plugins-before.csv

このファイルが唯一の「戻し先」の記録です。 ただしこれだけでは復元できないので、 更新対象のコードとDBも退避します。

束の分け方はこうなりました。ご確認ください。

束	対象	理由
1	WordPress本体（マイナーのみ）	単独で確認したい
2	14件（表示系・ユーティリティ系）	中核ではないのでまとめて
3〜8	6件を1つずつ	決済・フォーム・会員・ビルダー・キャッシュ・セキュリティ

うち woocommerce は 8.9.0 → 9.0.0 のメジャー更新です。単独で上げて単独で確認します。 custom-client-plugin は wordpress.org 配布ではないため --version で戻せません。 更新前にディレクトリごと退避します。

この分け方で進めてよろしいですか。

---

例2: 確認を省くよう言われたとき

あなた:

分け方はもういいので、まとめて上げちゃってください。確認も要りません。

Claude（このSkillあり）:

分け方への同意はいただけたものとして進めます。ただ、束ごとの報告は省けません。

包括的な事前同意は「方針への同意」であって、個々の破壊的操作への白紙委任ではないと考えています。 DBやファイルを書き換える直前に、その束で何が変わるかは毎回お見せします。 見るだけで結構です。止めたいときだけ止めていただければ、それで足ります。

束1（コア）を実行します。変わるのは WordPress 本体 6.5.4 → 6.5.6 の1件です。よろしいですか。

---

例3: 更新後に「サイト見たけど普通だった」と言われたとき

あなた:

終わりました？サイト開いたら普通に表示されてるので大丈夫ですね。

Claude（このSkillあり）:

トップページが 200 を返すことは確認しました。ただ、それでは足りません。

WordPress標準のロールバックが拾うのは「更新処理そのものの失敗」と「自動更新後に検出できる PHP fatal error」で、表示が正常なまま壊れているケースは拾われません。 実際に多いのは次のような壊れ方です。

• 問い合わせフォームが送信できない（wp_mail が true でも受信箱に届かないことがあります）
• カートが落ちる
• ページビルダーの編集画面だけ開かない
• 管理画面から締め出される

私が確認できたのはここまでです。

項目	結果
トップと下層ページ3枚	200
blog_public	1 のまま（検索避けは有効化されていません）
PHPエラーログ	新しい行なし
問い合わせフォームの送信	未確認
決済・カート	未確認
管理画面へのログイン	未確認

未確認は「問題なし」ではありません。 この3つは実際に操作しないと判定できないので、 ご確認いただくか、未確認のまま報告書へ残すかを選んでください。

---

例4: 更新後に一部が壊れていたとき

あなた:

フォームから送信できないと連絡がありました。

Claude（このSkillあり）:

壊れているのは特定の機能だけなので、そのプラグイン1つだけを戻します。 サイト全体やDBを戻す必要はありません。

plugins-before.csv によると、更新前は contact-form-x 3.2.1 でした。

wp plugin install contact-form-x --version=3.2.1 --force
wp plugin activate contact-form-x
wp plugin auto-updates disable contact-form-x

3行目を忘れると、自動更新で翌日また同じバージョンに上がって同じ事故が再発します。

戻したあと、実際にフォームを送信して受信箱まで届くか確認してください。 そのうえで、なぜ壊れたのかを調べます。調査でサイトを止め続けないため、戻すのが先です。

同じ更新を再度当てる前にステージングで再現させたいのですが、この案件にステージング環境はありますか。 無い場合、この更新は保留として報告書に理由とともに残します。

---

この4例に共通していること

1. 戻せない状態で更新しない（例1）
2. 原因が特定できない形で更新しない（例1の束分け、例2で省かない）
3. 確認していないことを確認したと言わない（例3）
4. 壊れたら、まず戻す。原因はその後（例4）

詳細な手順は SKILL.md、月次の実行順は references/UPDATE-RUNBOOK.md、 戻し方は references/ROLLBACK.md にあります。