更新前に確かめるのは、バックアップの「設定」ではなく、問題が起きたときに元へ戻せる状態です。同じ時点のサイトファイルとデータベースが一組で保存され、保存先へアクセスできるかを確認します。自動バックアップの設定表示だけで終えず、最終成功日時と保存先を実際の画面で読み戻すこと、復元担当と連絡先を決めること、復元後に確認する画面を決めることまで済ませてから更新へ進みます。
「自動バックアップは有効です」と聞いていても、保存対象や取得時刻を説明できなければ、どの状態へ戻るのかは分かりません。この記事では、WordPressの企業サイトを制作会社・保守会社と運用する担当者が、更新実行、追加確認、延期のどれを選ぶか判断できるよう、確認の順番を整理します。
更新前に確かめるのは、保存の有無ではなく戻せる状態か
バックアップが「ある」ことと、更新前の状態へ「戻せる」ことは同じではありません。自動取得のスケジュールが登録されていても、直近の処理が失敗している、保存先へ入れる人がいない、復元操作の担当範囲が契約上決まっていない、といった状態では、障害時にすぐ使えないためです。
更新前は、制作・保守担当に次の三つを一続きで確認します。
- どの日時の、何を保存したバックアップなのか
- 問題が起きたら、誰が、どの保存先から、どの手順で復元するのか
- 復元後に、誰が、どの画面を見て完了と判断するのか
三つのうち一つでも曖昧なら、「バックアップ済み」という言葉だけで更新を承認しないほうが安全です。確認したいのは手段の名称ではなく、更新前のどの時点へ戻すかという基準（復元点）から、業務に使える表示まで戻す経路です。
更新内容も一件に絞って記録します。「WordPressを更新する」だけでは範囲が広すぎます。WordPress本体、テーマ、プラグイン、サーバー上の設定、独自プログラムなど、今回どこへ変更を加えるのかを制作・保守担当に示してもらえば、保存対象との対応を確認しやすくなるでしょう。
WordPressの管理画面から取得したエクスポートファイルも、サイト全体のバックアップと同一視できません。そのファイルが何を含むかを確認し、後述するサイトファイルとデータベースの一組がそろっていることを別途確かめます。WordPress Developer Resources
バックアップ対象をファイルとデータベースに分ける
WordPressの一般的なサイトは、大きく「サイトファイル」と「データベース」の二つで構成されます。サイトファイルは表示や機能を形づくる材料、データベースは文章などの内容や運用中に蓄積される情報を置く場所、と考えると分かりやすいでしょう。WordPress Developer Resources
データベースは通常、Webサーバー上のWordPressフォルダとは別の仕組みで管理されます。そのため、サーバーからファイル一式をダウンロードしただけでは、データベースまで取得できたとは限りません。反対に、データベースだけを保存しても、テーマ、プラグイン、画像などのファイルは戻せません。WordPress Developer Resources
WordPress公式資料は、一般的なWordPressサイトを完全に復元するにはファイルとデータベースの両方が必要であり、同じ頃に作成した一つの「バックアップセット」として扱う考え方を示しています。出典。 WordPress Developer Resources
| 確認対象 | 主に含まれるもの | 更新前の確認 |
|---|---|---|
| サイトファイル | WordPress本体、テーマ、プラグイン、画像、設定・コード類 | 今回の更新対象を含む範囲が保存されているか |
| データベース | 投稿などの内容、サイト上で蓄積・生成されるデータ | 復元担当が読み込める状態で取得されているか |
| 同じ復元点 | ファイルとデータベースの組み合わせ | 更新前の同じ状態を示す日時として束ねられているか |
片方が欠けている、または取得時刻の関係を説明できない場合は、更新前に制作・保守担当へ確認します。この表は「何かが保存されているか」ではなく、「同じ状態へ戻す材料がそろっているか」を判断するためのものです。
なぜ同じ時点の一組にするのか
更新によって変わる場所は、作業内容ごとに異なります。ファイル側だけが変わるとは限らず、データベース側にも変更が加わるケースがあります。古いファイルと新しいデータベース、またはその逆の組み合わせでは、更新前と同じ状態を再現できないおそれがあるためです。WordPress Developer Resources
取得時刻が秒単位で完全に一致するかを見るのではなく、両方がどの作業前の状態を指しているのかを確認してください。「更新開始前のファイル一式」と「その直前に取得したデータベース」のように、復元時に組み合わせる二つが明示されていれば判断できます。
制作・保守担当には、「ファイル側の保存範囲」「データベース側の取得方法」「二つを結び付ける日時またはバックアップ名」を尋ねてください。回答がサービス名だけで終わる場合は、そのサービス上で二つが同時に保護されていると分かる画面や記録が判断材料になります。
取得時刻、保存先、保持世代を読み戻す
自動バックアップの設定画面に「毎日」や「更新前」と表示されていても、それは予定を示しているだけかもしれません。更新を始める前に直近の処理結果を開き、最終成功日時が更新開始より前で、残したい最新内容を含む時点であることを読み戻してください。
たとえば、前日にページを修正したのに、最後に成功したバックアップが三日前なら、復元後はその修正より前へ戻る可能性があります。復元点が古くても更新自体ができないとは限りませんが、失う変更を把握したうえで承認すべきか検討します。
確認に使うのは、バックアップ一覧、実行履歴、完了通知、保存されたファイルの日時などです。IPAの中小企業向けガイドライン第4.0版は、バックアップ運用について、対象、取得方法、取得日時・間隔、保管場所、世代管理、保管期間を検討し、復旧計画と正しく復旧できることの確認まで行うよう示しています。出典。 情報処理推進機構+1
保存先は「場所」と「入れる人」をセットで確認する
「サーバーに保存」「クラウドに保存」という回答だけでは、復元時に誰が取り出せるのか分かりません。保存先の名称に加えて、管理画面へ入れる担当者、必要な権限、制作・保守会社へ連絡する方法を確認します。パスワードを確認表へ直接書くのではなく、権限を持つ人と安全な受け渡し方法を決めておくとよいでしょう。
サーバー会社の自動バックアップを使う場合も、対象範囲、取得頻度、保管期間、復元の申請方法、復元に要する手続を確認対象に含めます。「契約に含まれる」と「更新担当がすぐ復元できる」は別の条件です。制作会社が操作するのか、サイト所有者がサーバー会社へ申請するのかまで分けます。WordPress Developer Resources
保持世代は更新前の復元点が消えないかを見る
保持世代とは、何回分のバックアップを残すかという考え方です。最新版だけを上書きする仕組みでは、不具合に気付く前に正常な復元点が消えることがあります。少なくとも、今回の更新前に取得した一組が、更新後の確認を終えるまで残る設定かを確認してください。
WordPress公式資料は一般的な目安として、直近のバックアップを3〜5世代保ち、異なる場所にもコピーを置くことを勧めています。ただし、企業サイトで何世代を何日残すかは、更新頻度、保存容量、復元に戻したい期間に合わせて決めます。出典。 WordPress Developer Resources
復元担当と復元後の確認画面を先に決める
不具合が起きてから担当者を探すと、復元判断までに時間がかかります。更新前に「連絡を受ける人」「復元を実行する人」「復元後を確認する人」を定めてください。同じ人が複数を兼ねても構いませんが、役割と連絡先を書き分けると、抜けを見つけやすくなります。
復元までの流れは、次の順番で合意しておきましょう。
- 更新担当が異常を確認し、追加作業を止める
- 事業担当者と復元担当へ、決めた連絡手段で知らせる
- どの状態なら復元へ切り替えるかを、判断担当が決める
- 復元担当が、指定したバックアップセットを使って戻す
- 技術担当と事業担当が、決めた画面を確認して完了を記録する
ここで分けたいのは、「復元を実行する人」と「復元を決める人」です。制作・保守会社が技術操作を担当しても、更新前の状態へ戻すことで失われる入力や公開内容がある場合、事業側の承認が必要になることがあります。着手条件を事前に決めておけば、連絡待ちの間に変更が増えるのを避けられます。
IPAのガイドラインは、中小企業や小規模事業者を対象に、経営者が担当者を任命し、必要な範囲を関係者と連携して組織的に実施する考え方を示しています。また、実施状況を記録や設定画面などの証拠で点検する方法も挙げています。更新前の復元責任を口頭だけでなく、一枚の確認表に残すのは、この運用観点をWebサイト更新へ置き換えたものです。出典。 情報処理推進機構+2情報処理推進機構+2
復元後に見る画面を絞る
「サイトが表示された」だけでは、更新前の状態へ戻ったか判断できません。復元後の確認画面は、サイト全体を網羅しようとせず、今回の更新と事業上の影響に合わせて絞っておきましょう。
- トップページなど、公開サイトが開くことを確かめる画面
- 今回更新した対象ページまたは対象機能
- 問い合わせフォームなど、止まると業務へ影響する導線
- WordPress管理画面など、更新後も運用を続けるための画面
フォーム送信を確認する場合は、テスト方法と処理後の扱いも決めます。事業担当者は文章、画像、リンク先、受付先などを確認し、技術担当は復元処理と対象機能の動作を見る、という分担が適しています。
更新前の復元確認表を一枚作る
確認内容はメールやチャットに散らさず、一件の更新につき一枚へまとめます。予定している更新を一件だけ書き、その下の五欄を制作・保守担当と埋めてください。
予定している更新（1件）：
更新対象と作業内容を具体的に記入する
- バックアップ対象：サイトファイルとデータベースの両方が含まれ、同じ復元点の一組になっている
- 取得日時：最終成功日時を画面または記録で確認し、更新開始前の状態である
- 保存先：保存場所、アクセスできる担当者、取り出す経路、保持期限が分かる
- 復元担当：実行者、復元判断者、連絡先、対応可能な時間帯が決まっている
- 復元後の確認画面：確認する画面・機能と、技術側・事業側それぞれの確認者が決まっている
五欄が埋まったら、次の基準で更新可否を決めます。
- 更新実行：二つの保存対象、取得日時、保存先、復元担当、確認画面を説明でき、問題発生時に決めた手順で復元へ移れる
- 追加確認：バックアップは確認できたが、保持期限や担当範囲など一部の記録が不足しており、更新前に解消できる
- 延期：ファイルかデータベースが欠ける、保存先へ入れない、復元担当と連絡がつかない、復元後の確認者が決まっていない
チェック数だけで機械的に決めるのではなく、欠けている欄が復元そのものを止めるかを見ます。特に、バックアップセット、保存先へのアクセス、復元担当の三つが確定しない場合は、更新日を守ることより、戻せる状態を作ることを優先してください。
まとめ：更新作業と復元手順を同じ依頼に含める
更新前のバックアップ確認では、サイトファイルとデータベースを同じ時点の一組として扱い、最終成功日時、保存先、保持期限を実際の画面や記録で読み戻します。そのうえで、復元を実行する人、判断する人、復元後に見る画面を決めれば、「バックアップ済み」という説明を更新可否の判断材料へ変えられます。
次に予定している更新を一件書き、バックアップ対象、取得日時、保存先、復元担当、復元後の確認画面の五欄を、制作・保守担当と埋めてください。どこまでが現在の保守範囲か分からない場合は、更新代行だけでなく、権限、連絡経路、復元責任を一緒に整理すると、次回以降も同じ基準で判断できます。
Backups — Advanced Administration Handbook／WordPress.org・WordPress Developer Resources／2023年3月28日初版公開、2026年6月4日最終更新／出典。 WordPress Developer Resources
中小企業の情報セキュリティ対策ガイドライン 第4.0版／独立行政法人情報処理推進機構（IPA）セキュリティセンター／2026年3月27日第4.0版公開、案内ページは2026年7月3日最終更新／出典。 情報処理推進機構+1
