WordPressバックアップは本当に戻せる？AIと行う復元リハーサル入門

「更新前にバックアップを取りました」と聞くと安心します。しかし、保存ファイルがあることと、必要なときにサイトを戻せることは同じではありません。

バックアップが途中で壊れている、データベースしか入っていない、復元先のPHPが合わない、手順や権限が分からない――。事故が起きてから初めて気づくと、宿泊予約や問い合わせが動いている本番サイトで試行錯誤することになります。

そこで必要なのが、本番とは別の検証環境へバックアップを戻し、実際に使えるか確かめる復元リハーサルです。この記事では、CodexやClaude Codeに確認と記録を手伝わせながら、宿主さんが安全に合否を判断する方法を説明します。

結論：バックアップの合格条件は「保存できた」ではなく「別環境で開けた」
WordPressのバックアップには二つの中身が必要
「整合性確認」と「復元確認」は別の試験
復元リハーサルを始める前の安全条件
AIに任せられる作業
宿主さんが確認する項目
復元時点をどう選ぶか
コピペで使えるAIへの依頼文
合格・保留・不合格の基準
どのくらいの頻度で試すか
宿主さん向けチェックリスト
参考にした公式情報
まとめ

結論：バックアップの合格条件は「保存できた」ではなく「別環境で開けた」

復元リハーサルの基本は次の流れです。

バックアップの作成結果を確認
  ↓
ファイルとデータベースが揃っているか確認
  ↓
本番から隔離した検証環境を用意
  ↓
保守担当者が復元
  ↓
AIが機械的な確認を補助
  ↓
宿主が予約・料金・問い合わせを確認
  ↓
手順、時間、問題点を記録

本番サイトへ上書きして試してはいけません。リハーサルは、本番のデータと処理を壊さない隔離環境で行います。

WordPressのバックアップには二つの中身が必要

WordPress公式資料では、データベースとファイルを分けて説明しています。どちらか一方だけでは、元のサイト全体を再現できません。

対象	主に含まれるもの	欠けた場合の例
データベース	記事、固定ページ、設定、ユーザー、コメント等	記事や設定が戻らない
ファイル	テーマ、プラグイン、アップロード画像、設定ファイル等	写真や独自デザインが戻らない

さらに、復元には次の情報も必要です。

いつ取得したバックアップか
どのサイト・環境のものか
WordPress、PHP、データベースのおおよその構成
復元を担当する人と連絡先
保存場所と閲覧権限
復元手順または契約サービスの公式案内
暗号化している場合の安全な鍵の管理方法

秘密鍵やパスワードをバックアップと同じ場所へ平文で置くと、盗まれたときに一緒に利用されます。AIとの会話にも貼り付けません。

「整合性確認」と「復元確認」は別の試験

バックアップには段階的な確認があります。

1. 作成処理が成功したか

バックアップ機能やスクリプトが成功として終了し、途中で通信切断や容量不足が起きていないか確認します。

2. 保存ファイルが壊れていないか

ファイルサイズ、圧縮ファイルの検査、チェックサムなどを使って、保存後に変化・破損していないか確認します。チェックサムはファイルの「指紋」のような値で、保存時と後日の値が一致するかを調べられます。

3. 必要な構成が揃っているか

データベース、画像、テーマ、プラグイン、必要な設定が対象に含まれているかを、内容そのものや秘密情報を不用意に表示せず確認します。

4. 別環境へ復元して動くか

最後に、隔離された検証環境へ戻し、ページが開き、管理画面へ入れ、画像や機能が動くか確かめます。ここまで通って初めて「復元に使える可能性が高い」と判断できます。

整合性検査が成功しても、環境差や手順不足で起動しないことがあります。反対に、ページが一枚開いただけでは、予約やメールまで正常とは限りません。

復元リハーサルを始める前の安全条件

次の条件を確認してから始めます。

本番とは別のサーバー、検証領域、またはローカル環境である
検証環境が検索エンジンへ公開されない
Basic認証等で第三者が閲覧できない
本番の予約システムや決済へ接続しない
本番宛てのメールを送信しない
Analyticsや広告計測へ検証アクセスを送らない
複製された個人情報を必要最小限にし、利用後に安全に処分できる
本番データベースへの接続先が設定されていない
復元によって本番を上書きしないと担当者が確認している

宿のサイトには氏名、メールアドレス、問い合わせ、予約情報が保存されている場合があります。検証目的であっても、個人情報を複製する範囲と保管期間を決めます。可能なら匿名化したデータで確認します。

AIに任せられる作業

CodexやClaude Codeは、次のような機械的な確認を支援できます。

バックアップ日時、サイズ、世代数の一覧化
圧縮形式やチェックサムの検査計画
データベースとファイルが揃っているかの確認項目作成
検証環境と本番環境の接続先の相違確認
復元後の重要URLのHTTP応答確認
画像、CSS、JavaScriptの読み込み失敗の整理
WordPress、テーマ、プラグインの版の比較
復元にかかった時間とエラーの記録
リハーサル報告書と次回手順の更新

ただし、AIへ「最新バックアップを本番へ戻して」と一文で頼んではいけません。復元は既存データを上書きし得る作業です。対象、復元先、バックアップ日時、停止が必要な機能、戻し方を人が承認します。

宿主さんが確認する項目

技術的にエラーがなくても、宿として正しいかは自動判定できません。

表示

トップページが開く
客室・料金・食事・アクセスが表示される
写真が欠けたり古くなったりしていない
パソコンとスマートフォンで大きな崩れがない

予約・連絡

予約ボタンが意図した予約先へ進む
料金・プラン・空室案内が正しい
問い合わせフォームを安全な宛先でテストできる
電話番号、メール、休館案内が正しい

WordPress管理

管理画面へ正規の管理者が入れる
最近の記事と固定ページが存在する
メディア画像が開く
テーマと必要なプラグインが認識される
管理者権限や利用者が想定どおりである

本番の決済を実行したり、実在する宿泊枠を取ったりしないよう、予約・決済テストの方法は利用サービスへ確認します。

復元時点をどう選ぶか

「最新」が必ず最善とは限りません。不具合や改ざん後に取得したバックアップには、問題も含まれている可能性があります。

複数世代を保管し、次を記録します。

記録	判断に使う理由
取得日時	問題が起きる前か判断する
WordPress・テーマ・プラグイン版	復元先との互換性を見る
主な更新内容	どの記事・設定まで戻るか確認する
自動検査結果	作成・破損検査が通ったか見る
復元試験日	実際に戻せた世代か分かる

宿泊予約や問い合わせをWordPress内で管理している場合、古いバックアップへ戻すと、取得後に入ったデータを失う可能性があります。「サイト表示だけを戻す」のか「データベース全体を戻す」のかは、復元前に分けて判断します。

コピペで使えるAIへの依頼文

バックアップを変更せず監査する

WordPressのバックアップが復元に使える状態か確認したいです。
この依頼では復元、展開、削除、本番変更をしないでください。

バックアップについて、秘密情報や内容を表示せずに、
取得日時、サイズ、ファイル形式、チェックサム、世代数、
データベースとWordPressファイルの有無を確認する計画を作ってください。

不足項目、確認できない項目、保守担当者へ聞く質問を分けてください。

復元リハーサルの計画を作る

WordPressバックアップを隔離された検証環境へ復元する
リハーサル計画を作ってください。まだ実行しないでください。

本番を変更しないこと、検索非公開、外部メール停止、
予約・決済・Analyticsとの分離、個人情報の最小化を条件にします。

準備、復元、技術確認、宿主による確認、片付けの順に整理し、
各工程へ担当者、合格条件、中止条件、元へ戻す方法を付けてください。
私が対象と復元先を承認するまでコマンドを実行しないでください。

リハーサル結果を記録する

復元リハーサルの結果を運用記録にまとめてください。

実施日、使用したバックアップ日時、復元先、所要時間、
成功した確認、失敗した確認、未確認事項、次回までの改善を整理してください。
パスワード、鍵、内部接続情報、顧客・予約情報は記録に含めないでください。
「復元可能」と断定せず、今回確認できた範囲を明記してください。