保守の実務

WordPressのアップデート代行と、更新に失敗したときの一次対応｜バックアップ→ステージング→本番の手順、切り戻し、お客様への連絡文

公開日：

お客様から「WordPressの更新をお願いできますか」と頼まれた。更新ボタンを押すだけなら簡単だが、表示が崩れたり、サイトが止まったりしたらどうするかが決まっていない。

この記事は、WordPressのアップデート代行を受ける個人・フリーランスに向けて、引き受ける前に決めること、バックアップ→ステージング→本番の手順、更新に失敗したときの一次対応と切り戻し、お客様への連絡文をまとめたものです。毎月の作業全体は「WordPress保守で毎月やること一覧」で扱っています。

公式ドキュメントが勧めていること

  • 常に最新版に更新する。作業の前にサイトをバックアップする（Updating WordPress）
  • バックアップはデータベースとファイルの2つ。データベースは定期的に、更新の前には必ず取る（WordPress Backups）
  • 作ったバックアップが存在し、使えることを確かめる（Upgrading WordPress）
  • 本体の小さな更新と安全性の更新は、多くのサイトで自動で適用される。プラグインとテーマの自動更新は、WordPress 5.5から1つずつ有効にできる
  • 更新後に問題が起きたら、バックアップを戻し、以前のバージョンのファイルに置き換えることができる

引き受ける前に決めること

  • 対象：本体・プラグイン・テーマ・翻訳のどこまでか。有料プラグインのライセンス更新やPHPのバージョン変更を含むか
  • 権限：管理画面に加えて、サーバーのファイルとデータベースに入れるか。切り戻しには、管理画面だけでは足りないことがある
  • 時間帯：更新する曜日と時間。問い合わせや予約の多い時間は避ける
  • 確認するページ：トップ、お問い合わせ、よく見られるページなど
  • 不具合が起きたときの費用：自分の作業が原因の場合、プラグイン側の不具合の場合、お客様の変更が原因の場合で分ける（契約書の書き方は「WordPress保守契約書に入れる条項チェックリスト」）

手順：バックアップ → ステージング → 本番

1. バックアップ

データベースとファイルの両方を取り、ファイルが空でないか、中身がそろっているかを確かめます。公式ドキュメントは、複数の世代を、サーバーとは別の場所にも置くよう勧めています。

2. ステージングで試す

本番の複製（サーバーのステージング機能や、サブドメインに作った複製）で、同じ更新を先に試します。公式ドキュメントは、WP_DEBUGなどのデバッグ機能を本番ではなく、ローカルやステージングで使うよう勧めています。エラーの記録を取りながら試せるのが、ステージングの利点です。

ステージングは一般に公開せず、パスワードで保護します。お問い合わせフォームから、本物のお客様あてにメールが届かないようにも注意します。

ステージングを用意できない小さなサイトでは、プラグインを1つずつ更新し、アクセスの少ない時間に作業して、お客様に事前に伝えておきます。

3. 本番

ステージングで問題がなかった更新を、決めた時間に本番で行います。終わったらキャッシュを消して（公式ドキュメントも、キャッシュが残ると古い表示が出続けると案内しています）、決めたページをパソコンとスマホで確かめ、フォームは実際に送ってみます。

更新に失敗したときの一次対応

最初の5つ

  1. 触る前に記録する：いつ、何を更新したか、出ている画面とエラーの文
  2. 影響の範囲を見る：サイト全体か、一部のページか、フォームだけか
  3. お客様に一次連絡する。原因が分からなくても、把握して対応中であることを先に伝える
  4. 切り戻すか、原因を直すかを決める
  5. 復旧したら、原因と再発防止を報告する

症状ごとの手がかり

症状 手がかり
「このサイトで重大なエラーが発生しました」と表示される リカバリーモード（WordPress 5.2以降）。管理者のメールアドレスに、原因のプラグインやテーマとログイン用のリンクが届く。ログインすると原因が管理者のセッションだけ一時停止され、無効化できる
リカバリーモードのメールが届かない 公式ドキュメントは、FTPなどで該当プラグインのフォルダ名を変えて一時的に無効にする方法を案内している
「更新に失敗」の通知が残る WordPressのフォルダにある .maintenance ファイルを削除する（公式ドキュメント）
表示が崩れた キャッシュを消して確かめる。直らなければ、プラグインを無効にし、1つずつ有効に戻して原因を探す（公式ドキュメントの手順）
フォームが動かない 実際に送って再現させる。直るまでは、電話など別の連絡手段をサイトに案内するようお客様に提案する

切り戻しの選び方

方法 向いている場面 注意
原因のプラグインだけ前のバージョンに戻す 原因が1つに絞れている WordPress.org配布のものは、WP-CLIの wp plugin install <スラッグ> --version=<バージョン> --force で入れ直せる。有料プラグインは配布元で旧版を確認する
サイト全体をバックアップから戻す 原因が分からず、サイトが止まっている バックアップを取った後の投稿や設定の変更が失われる
本体を前のバージョンに戻す ― 公式ドキュメントは通常勧めておらず、完全なバックアップがなければ成功はほぼ不可能としている

どの方法でも、何をどこまで戻すかを記録してから作業します。原因の調べ直しは、ステージングで行います。

お客様への連絡文

更新の事前連絡

【相手の名前】様

【日付】の【時間帯】に、WordPressとプラグインの更新を行います。
作業の前にバックアップを取り、テスト用の環境で確認した更新のみを行います。
作業中に表示がおかしい場合は、このメールにご返信ください。

不具合の一次連絡（原因が分かる前に送る）

【相手の名前】様

本日【時刻】に行った更新のあと、【症状：例）お問い合わせフォームが送信できない状態】を確認しました。
ご迷惑をおかけし申し訳ありません。いま、更新前の状態に戻す作業を進めています。
【時刻】ごろまでに、改めて状況をご連絡します。

復旧の報告

【相手の名前】様

【時刻】に、【症状】が解消したことを確認しました。
原因は【原因：分かっている範囲で】でした。
今後は【対策：例）このプラグインの更新は、テスト用の環境で確認してから行います】。
今回は【費用の扱い：例）作業による不具合のため、費用はいただきません】。

自分の作業が原因なら、そのことをはっきり書きます。トラブルがあった月の月次報告の書き方は、「保守の月次報告書の書き方」で紹介しています。

出典（確認日：2026年10月29日）

  • WordPress.org「Updating WordPress」 https://wordpress.org/documentation/article/updating-wordpress/
  • WordPress.org「Plugin and themes auto-updates」 https://wordpress.org/documentation/article/plugins-themes-auto-updates/
  • WordPress.org「Recovery Mode」 https://wordpress.org/documentation/article/recovery-mode/
  • WordPress Developer Resources「WordPress Backups」 https://developer.wordpress.org/advanced-administration/security/backup/
  • WordPress Developer Resources「Upgrading WordPress」 https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
  • WordPress Developer Resources「Debugging in WordPress」 https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
  • WordPress Developer Resources「wp plugin install」 https://developer.wordpress.org/cli/commands/plugin/install/

更新の前後の確認を含めた3段の保守メニューと、月次報告の雛形は、記事の下で紹介している保守契約スターターキットにまとめています。独立の前後の手続きも確認したい方は、無料の独立準備チェックリストを使ってください。

関連記事