WordPress更新の手順｜バックアップ・動作確認・復旧判断

1. 変更前の状態と戻し方をそろえる

本体・PHP・テーマ・プラグインのバージョン、作業時刻、更新予定を記録します。ファイルとデータベースの保存対象がそろい、管理画面が開かなくても復元できる経路があるかを確かめます。サーバーの自動保存だけに頼る場合も、保存時刻・保持期間・復元対象を確認します。

保存先の考え方はバックアップの保存先と復元確認へ。WordPress公式の更新手順も更新前のバックアップを案内しています。

2. 更新の組み合わせを検証環境で確かめる

変更履歴と対応するWordPress・PHPの条件を読みます。すべてのサイトに共通する「本体を必ず最初に更新」という順番ではなく、依存するテーマやプラグインの要件に合わせて順序を決めます。有料製品は更新を受け取る契約やライセンスの状態も確認します。

予約・決済・会員機能があるなら、ステージング環境で代表操作を試します。検証環境が実際の顧客へ通知したり、課金したりしないように設定します。PHPの変更も必要ならPHP更新前の確認を別の変更項目として記録してください。

3. 本番更新は結果を追える単位で行う

1. 受注が少ない時間帯と作業担当を決め、検証済みの変更内容を共有します。
2. 直前のバックアップと復旧手順を確認します。更新中も注文等が増える環境では、停止範囲や新しいデータの保全方法を決めます。
3. 必要な依存関係を満たす単位で更新し、結果をその都度残します。処理中に別の更新やファイル変更を重ねないようにします。
4. 更新直後に管理画面と主要URLを確認し、異常が出た地点で次の更新を止めます。

セキュリティ修正は定期点検日まで無条件に待つものではありません。告知内容と影響を確認し、速やかに対応できる担当を用意します。自動更新を利用する場合にも、失敗通知と表示異常に気づく仕組みが必要です。

4. 更新前後で同じ操作を照合する

スマホでは表を横にスクロールできます。

HTTP 200で開くだけでは、ページ途中のエラーやフォーム障害は見逃します。自分がログインしている画面だけでなく、利用者の見え方でも確認します。未検証の機能は「確認済み」にせず残してください。

5. 異常時は新しいデータを守って復旧する

エラーのURL・発生時刻・直前の変更・表示されたメッセージを控えます。ログに個人情報が含まれる場合は共有範囲を限定します。キャッシュの問題か、更新した機能の問題かを切り分け、原因を追えないまま全機能を停止しないでください。

データベースを古い保存へ戻すと、更新後に受け付けた注文・投稿・問い合わせも失う可能性があります。ファイルだけで戻せるか、データ構造が変わっているか、新規データをどう保全するかを確認してから復元します。解決後は実施した変更と未確認事項を残し、再度更新を適用する条件を決めます。

6. 10時のバックアップに、10時15分の注文は入っていない

以下は復旧判断を練習するために作成した練習用のケースです。特定製品の障害報告や、当サイトで発生した注文・復旧の実績ではありません。注文をデータベースに保存するサイトで、更新作業中も注文受付を続けた場面を考えます。

スマホでは表を横にスクロールできます。

この場面で、すぐにデータベース全体を戻さない

10:00の状態でデータベースを上書きすると、10:15の注文がサイト上から失われる可能性があります。外部の決済処理が済んでいる場合、画面だけ以前へ戻しても決済まで取り消されるわけではありません。注文番号を控えるだけでは、明細・在庫・会員との対応をすべて復元できないことがあります。

1. 次の変更を止める：別のプラグイン更新を重ねず、発生時刻・対象URL・更新対象を記録する。
2. 受付への影響を判断する：注文や決済も正常か確認できないなら、担当者が停止範囲と利用者への案内を決める。表示だけの問題なら、必要以上に全機能を止めない。
3. 現在の状態を保全する：障害がある状態も含めて、戻す前のファイル・データベースを別の保存として確保する。注文や決済の記録を公開の共有フォルダへ置かない。
4. 戻せる組み合わせを調べる：更新時にデータ構造が変わっていないか、旧ファイルが現在のデータで動くか、製品の案内と検証環境で確認する。
5. 復旧方法を決める：修正版の適用、設定の修正、対象ファイルの復旧、データを含む復旧のどれが必要かを判断する。新旧データの統合が必要で手順が確かでない場合は、開発元や保守担当へ引き継ぐ。

「ファイルだけなら安全」とも決められません。旧版が新しいデータ構造に対応しない場合や、戻した版に既知の問題がある場合があります。復旧後は表示だけでなく、対象となる注文の件数・状態・外部決済との対応を、権限を持つ担当者が確認します。

ファイルとデータベースの両方が保存対象になる点はWordPress公式のバックアップ資料で確認できます。このケースの時刻と判断順は、保存時刻のずれを理解するために当サイトが作成した説明例です。

7. 次へ進む・止める・引き継ぐ条件を決めておく

更新ボタンを押せても、それだけで更新を完了扱いにはできません。担当者ごとの判断が変わらないように、作業前に次の区切りを決めます。

スマホでは表を横にスクロールできます。

作業後の報告は「更新しました」だけで終えず、「変更したもの／確認できた操作／未確認の範囲／残っている対応」を分けます。未確認の機能を一覧に残すことで、次の担当者が再確認する範囲を選べます。

WordPress変更判断・引継ぎシートを保存する（TXT）。対象と期待結果を作業前に記入し、実際の結果は作業後に追記してください。