WordPressの更新（バージョンアップ）を安全に行う手順

WordPressの更新は、管理画面で更新ボタンを押すだけでは完了しません。本体・プラグイン・テーマ・PHPの組み合わせによっては、表示崩れやフォーム停止、外部連携の不具合が起こる可能性があります。更新対象を把握し、戻せる状態を確認してから段階的に反映することが重要です。

この記事では、更新前の棚卸しからバックアップ、ステージング検証、本番反映、障害時の切り戻しまでを順に解説します。読後には、更新を安全な変更管理として進める判断基準を持ち、自社対応の可否や外部支援が必要な範囲を整理できるようになります。

WordPress更新は、対象の棚卸しから復元準備、検証、本番確認、記録までを一連の変更管理として進めます。

01Sectionまず整理する：更新対象と優先順位の決め方

最初に行うべきことは、「何を更新するか」と「更新によって何に影響するか」の棚卸しです。WordPressの更新画面ではコア、プラグイン、テーマなどの更新候補を確認できます。加えて、サイトヘルスでは、PHP、サーバー、データベース、テーマ、プラグインなどの構成情報を確認できます。

更新対象は4つ、影響確認は周辺構成まで広げる

中心となる更新対象は、WordPress本体、プラグイン、テーマ、PHPです。ただし、実際の影響はデータベース、サーバー設定、キャッシュ・CDN、外部連携、独自コードにも及びます。たとえばフォーム用プラグインの更新では、送信画面だけでなく通知メールやCRM・MA連携まで確認が必要になる場合があります。

テーマを更新する場合は、親テーマへの直接改修が更新で失われることがあります。子テーマや独自テンプレートの利用状況は、WordPress公式のトラブルシューティング情報も参照しながら確認してください。プラグインについても、管理画面で表示される情報だけで対応可否を判断できない場合があるため、独自実装や外部配布の拡張機能は提供元または実装担当へ確認します。

更新順序は固定せず、検証単位を決める

「本体を先に更新する」「プラグインを一括更新する」といった一律の順序は、安全な方法とは限りません。先に決めるべきなのは、更新後に成立させるPHP、WordPress、テーマ、プラグインの組み合わせです。

特に、独自テーマ、更新停止中のプラグイン、外部連携、問い合わせ・決済・会員機能、PHP要件の変更がある場合は、影響度の高い対象を小分けにして検証します。脆弱性対応など早期の評価が必要な更新でも、復元手段や重要導線の確認者がいないまま本番反映を急ぐと、障害時の影響を広げかねません。

更新台帳で互換性・復元・責任者を見える化する

更新台帳は、更新順を決める表ではなく、互換性と復元可能性を確認するための記録です。更新前後のバージョンだけでなく、重要導線、復元情報、確認担当を一つの記録にまとめます。

02Section更新前にそろえる復元・検証・体制

本番更新の可否は、「バックアップを取ったか」ではなく、「問題が起きたときに戻せるか」で判断します。一般的なWordPressサイトを復元するには、ファイルとデータベースの双方を扱う必要があります。WordPress公式のバックアップガイドを確認し、利用中の環境で必要となる範囲を明確にしてください。

ファイルとデータベースを1組のバックアップセットとして管理する

ファイルにはテーマ、プラグイン、アップロード済みメディア、設定ファイルなどが含まれます。データベースには投稿、固定ページ、設定、ユーザー関連情報などが含まれます。どちらか一方だけでは、更新前の状態へ適切に戻せないことがあります。

そのため、ファイルとデータベースは近い時点で取得した1組のバックアップセットとして扱います。取得日時、保存先、保持世代、取得者、バックアップIDを台帳に残してください。保存先へアクセスできる権限と、復元を実行する担当者も更新前に確認します。

復元権限と手順を確認し、可能ならステージングで試す

バックアップが存在していても、DBのインポート権限がない、保存先にアクセスできない、復元後の確認手順がない、といった状態では切り戻しに使えません。復元後に公開画面、管理画面、主要導線を誰が確認するかまで決めておくことが必要です。

本番に近い環境がある場合は、ステージングで復元できるかを確認します。バックアップの取得・保管・復元の考え方はWordPressバックアップの解説を、検証環境の準備と本番との差分管理はステージング環境の解説を参照してください。

本番との差分と作業責任を先に決める

ステージングで合格しても、本番とPHP、メール送信、外部連携、環境変数、キャッシュ・CDN、アクセス制御、定期実行処理が異なれば、同じ結果になるとは限りません。判明している差分は台帳に残し、本番後の確認項目へ反映します。

同時に、作業者、機能確認者、業務承認者、切り戻し判断者、代替担当、連絡先を決めます。本番反映の直後に確認する時間が確保できない場合は、技術的に更新可能でも実施を保留する判断が必要です。

03Sectionステージング検証から本番完了までの進め方

本番反映は、バックアップ・復元・検証・体制・確認時間の条件を確認してから判断します。

安全な更新は、変更を小さな単位で検証し、その結果を踏まえて本番へ進む流れです。WordPress公式の更新ガイドで作業時点の更新方法と注意事項を確認しつつ、サイト固有の検証項目を優先します。

ステージングでは変更を小分けにし、結果を記録する

たとえば重要なフォーム関連プラグインを1件更新したら、表示、フォーム送信、通知メール、連携先への反映、管理画面操作、エラーログを確認し、結果を残します。複数の変更を同時に実施すると、不具合が起きた際に原因と切り戻し対象を特定しにくくなります。

データベース更新の案内が表示された場合も、すぐに本番で実行しません。ステージングでバックアップセット、復帰方法、重要導線のテスト結果を確認できているかを見直します。確認できない場合は、本番では保留し、実装担当または利用中サーバーの公式手順を確認してください。

Go／No-Goと本番完了条件を承認プロセスにする

本番反映の判断は、作業者だけで完結させず、業務への影響を判断できる担当者と共有します。次の条件が一つでも満たせない場合は、更新そのものを放棄するのではなく、不足条件を解消するまで保留します。

本番の完了条件は、更新画面で成功表示を確認することではありません。主要ページ、フォーム、通知メール、外部連携、管理画面、重大なエラーログを確認し、結果・残課題・承認状況を台帳に記録して初めて完了とします。

04Section更新できない・崩れたときの初動と切り戻し

障害時は原因を急いで決めつけず、追加変更を止め、影響に応じて切り戻しまたは調査・連絡を判断します。

更新後に画面が崩れた、管理画面に入れない、フォームや通知メールが動かない場合、原因を急いで断定するより事業影響を抑えることを優先します。特に公開・管理画面の表示不能、重要導線の停止、決済・会員・個人情報への影響が疑われる場合は、追加作業を止めて判断します。

異常を確認したら、追加変更を止めて判断する

初動は次の流れで進めます。

1. 1異常を確認した：表示不能、致命的エラー、フォーム・通知・連携停止などを認知する。
2. 2追加変更を止める：更新、設定変更、キャッシュ操作などを重ねない。
3. 3証跡を残す：発生時刻、更新対象と前後バージョン、操作順、エラー、影響範囲、バックアップIDを記録する。
4. 4重要導線・個人情報への影響を確認する：公開、管理、フォーム、通知、連携、会員、決済への影響を確認する。
5. 5停止許容条件と照合する：事前に定めた停止許容条件を超える、または即時修正の確実性がない場合は切り戻しや外部連絡を優先する。
6. 6切り戻しまたは調査・外部連絡を選ぶ：復元済み手順で早く影響を下げられるなら切り戻しを優先し、復元不能やサーバー・PHP・独自コードが関係する場合は担当者へ連絡する。

切り戻しを優先する条件と復旧完了条件

公開・管理画面が表示できない、フォーム・通知メール・重要連携が停止した、決済・会員・個人情報への影響が懸念される場合は、調査を続けるより切り戻しを優先するかを判断します。切り戻しは、事前に確認した復元手順があり、修正を続けるより早く影響を下げられる場合に有効です。

外部へ連絡する際は、情報を絞って渡すと初動が進みやすくなります。少なくとも「発生時刻」「更新対象と更新前後のバージョン」「エラー内容や画面記録」「実施した操作の履歴」「影響範囲とバックアップID」を共有します。ログや画面記録には個人情報や認証情報が含まれる場合があるため、保存先と閲覧権限を限定してください。

復旧後も、公開・管理画面、重要導線、通知メール、外部連携、ログを再確認します。発生原因、実施した復旧、残課題、次回確認の担当を承認者へ共有して復旧完了とします。検知、報告、封じ込め、復旧、委託先との連携体制をあらかじめ整える考え方は、IPAのインシデント対応体制に関する解説も参考になります。

リカバリーモードとデバッグの位置付け

リカバリーモードは、致命的エラーが発生した際に問題となるテーマやプラグインへの対処を補助する機能です。ただし、すべての障害で利用できるわけではなく、復元の代替手段でもありません。

デバッグは原因調査のために使います。WordPress公式のデバッグガイドを確認し、ログの保存先と閲覧権限を管理してください。公開画面に詳細なエラーを表示すると情報が露出するおそれがあるため、本番環境での表示設定には注意が必要です。

05Section自動更新は対象別に自動・手動・保留を決める

自動更新の可否は更新対象だけでなく、復元・通知・確認・切り戻しの体制を含めて決めます。

自動更新は作業を減らす手段ですが、検証や復旧を不要にするものではありません。WordPressの自動更新はコア、プラグイン、テーマなどを対象とし、PHPの切替やサーバー設定の変更は対象外です。自動更新の設定や通知の扱いは、プラグイン・テーマの自動更新に関するWordPress公式情報で作業時点の仕様を確認してください。

自動化の前に、通知・監視・復旧の担当を決める

自動更新を検討する前提は、復元可能なバックアップ、更新通知を受ける担当、異常を確認する手段、切り戻しを実行できる担当、緊急連絡先があることです。通知メールだけでは、フォーム送信や外部連携が正常かどうかまで確認できません。

フォーム、認証、CRM・MA、決済、会員、個人情報処理、独自連携、独自テーマに関わる対象は、更新後の機能確認を行えるよう、手動検証を優先します。保留は放置ではなく、何が不足しているか、誰がいつ確認するかを台帳に残す運用です。

06SectionPHP更新は別の変更として計画する

PHPはWordPressを動かすサーバー側の実行環境です。WordPress本体やプラグインの自動更新とは別に、切替可能なPHP版、拡張モジュール、反映範囲、ロールバック可否を確認して計画します。サーバー管理画面での具体的な切替方法は契約や権限によって異なるため、利用中サーバーの公式手順を確認してください。

PHP公式のサポート状態とWordPress要件を確認する

まず、PHP公式のSupported Versionsで利用中PHPのサポート状態と終了日を確認します。サポート状態は変わるため、作業時点の公式情報を参照してください。続いて、WordPressの要件ページでPHP、データベース、HTTPSなどの現行要件を確認します。

WordPressの要件を満たしていても、テーマ、プラグイン、独自コード、外部連携まで問題なく動くことを保証するものではありません。各提供元または実装担当への個別確認が必要です。

ステージング切替から本番の復帰条件までを確認する

07Section自社対応・スポット支援・継続保守を選ぶ基準

更新作業を自社で行えるかは、管理画面を操作できるかではなく、復元・検証・障害対応まで継続して担えるかで判断します。更新対象が少なくても、問い合わせや資料請求などの重要導線が止まった場合に対応できないなら、作業範囲や体制の見直しが必要です。

比較見積もりでは、金額より前に作業条件をそろえる

費用や作業期間は、構成、独自改修、外部連携、検証範囲、緊急性、復旧支援の有無によって変わります。公開情報だけでは同じ条件で比較しにくいため、総額だけで比較せず、対象範囲と責任分界をそろえて個別に確認することが重要です。

継続的な更新通知、監視、障害連絡をどう設計するかは、WordPress保守の考え方も参考にしてください。自社で復元・検証・障害対応を担うことが難しい場合は、必要な支援範囲を整理したうえでサービス一覧から相談先を確認できます。

08Section更新を継続運用にするためのFAQ

WordPressの更新・保守体制を相談する

更新対象、独自改修、外部連携、バックアップ・復元の状況を整理したうえで、必要な保守・更新支援の相談先を探せます。

WordPress制作・保守2949社掲載

WordPress制作・保守の相談先を探す