WordPressのバージョンアップ方法完全手順失敗しない順番と理由バックアップからPHPまで現場で使える安全運転ガイド

WordPressのバージョンアップ。やること自体はシンプルに見えます。

ボタンを押す。更新する。終わり。のはずが、現場ではたまに怪談になります。「画面が真っ白になりました」「管理画面に入れません」「なぜかお問い合わせが届きません」。背筋が冷えるタイプの更新祭り。

そこで今日は、更新作業を安全運転にするための手順を、ちゃんと順番ごとに解説します。しかも、よく言われるこの順番。

1. バックアップ
2. プラグインのバージョンアップ
3. 本体のバージョンアップ
4. PHPのバージョンアップ

なぜこの順番なのか。どこで止めるべきか。何を確認してから進むのか。実務で「失敗できない状況」を何度もくぐってきた人向けの目線で書きます。

フロントエンド担当でも、更新作業を任されることはあります。小規模サイトほどそう。だからこそ、作業者が判断できるように、余計な精神論は抜きでいきます。

更新前に止めるべきことまず手癖を止める
更新手順の全体像 4つの工程は別物
事前準備更新作業を始める前にやっておくこと
ステップ1 バックアップここが雑だと全部が危ない
ステップ2 プラグインのバージョンアップ先に外堀を固める
ステップ3 WordPress本体のバージョンアップ主役の更新は丁寧に
ステップ4 PHPのバージョンアップ最後にやる理由が一番深い
この順番でやる理由を一気に整理する
更新後の確認実務で本当に見るところ
更新でやりがちな失敗と回避策
フロントエンド担当が知っておくと強い視点
メリットとデメリット更新作業をする意味を現実に寄せる
おまけ実務で役立つチェックリストそのまま使える
関連して知っておくと得する話更新を安定させる小技

更新前に止めるべきことまず手癖を止める

止めたいのは、更新ボタンを勢いで押すことです。更新作業は、勢いが一番の敵。

WordPressはプラグインとテーマで出来上がっています。そこにPHPのバージョンが絡む。さらにキャッシュやCDN、WAF、メール送信設定、決済やフォームの外部連携まで混ざると、問題が出た時の原因追跡が一気に難しくなる。

だから、更新前に止めるべき行動が3つあります。

更新ボタンを連打して全部一気に上げる行為

まとめて更新は、原因究明を不可能にします。壊れた時に「どれが犯人か」分からない。犯人探しが長引くと、復旧が遅れます。

本番でいきなり試す行為

ステージング環境があるなら、先にそこで更新します。ない場合でも、最低限のバックアップと戻し手段がない状態で本番更新は避けたい。

確認事項を頭の中だけで処理する行為

忙しいほど、人は忘れます。だからチェックリスト化が最強。紙でもメモでもいい。人間の脳は、更新作業中にだいたい優雅に逃亡します。

更新手順の全体像 4つの工程は別物

バックアップ、プラグイン更新、本体更新、PHP更新。これらは似ているようでリスクの種類が違います。

バックアップは保険。失敗しても戻れる状態を作る。
プラグイン更新は機能単位の差し替え。影響範囲は広いが切り戻しがしやすい。
本体更新はWordPressの中核更新。互換性の基準が変わることがある。
PHP更新は実行環境の更新。動くか動かないかが一気に変わる場合がある。

この性質の違いを踏まえると、あの順番が合理的になります。順番の理由は後半で深掘りします。

事前準備更新作業を始める前にやっておくこと

作業開始の前に、これだけは揃えておくと楽になります。更新作業は、準備の段階で半分終わっている。

1 更新対象の棚卸しをする

管理画面で、WordPress本体のバージョン、テーマ名とバージョン、プラグイン一覧とバージョンを控えます。スクリーンショットでもよい。後で比較する材料になります。

2 重要機能のリストを作る

更新後に必ず確認する項目を決めます。全部は無理なので、事故ったら困るものだけ。

トップページの表示
下層ページ数ページの表示
お問い合わせフォームの送信
検索機能
ログインと管理画面の操作
予約や決済がある場合はその導線

ここを決めずに更新すると、更新後に何を確認すればよいか迷い、迷っているうちに時間が溶けます。

3 メンテナンス表示を用意する

更新中にアクセスが来ると、更新途中のファイルに触れて不具合が起きることがあります。軽いサイトならそこまで気にしなくてよい場合もありますが、アクセスがある程度あるならメンテナンス表示を検討します。

あなたのサイトが更新中に訪問者を受け入れるべきか。ここ、意外と判断が分かれます。あなたならどちらにしますか。

4 作業時間帯を選ぶ

アクセスが少ない時間帯、問い合わせが来にくい時間帯に実施します。夜中にやりたい気持ちは分かりますが、復旧の相談相手も寝ている可能性がある。ほどほどに。

ステップ1 バックアップここが雑だと全部が危ない

最初にバックアップ。これは儀式ではありません。戻すための現実的な手段です。

バックアップの対象は2つファイルとデータベース

WordPressは主に、

ファイル一式(WordPress本体、wp-content、テーマ、プラグイン、アップロード画像)
データベース(記事、固定ページ、設定、ユーザー、フォームデータなど)

この2つで成り立ちます。片方だけだと復旧できないケースが多い。

バックアップ方法の選択肢

方法はいくつかあります。環境によって最適解が違うので、代表例を押さえます。

サーバー側の自動バックアップ機能を使う
プラグインでバックアップを取る
FTPまたはSSHでファイルを取得し、DBはエクスポートする
All-in-One WP Migrationなどの移行系ツールで丸ごとエクスポートする

個人的には「サーバー側のバックアップが一番信用できる」と感じる場面が多いです。プラグインバックアップは便利ですが、バックアップ用プラグイン自体が動かない状況になることもあります。

バックアップのメリット

何かあっても元に戻せる
更新作業の心理的負担が減る
原因調査より復旧を優先できる

バックアップのデメリット

時間がかかる(サイト規模が大きいほど)
保存先の容量が必要
手順が雑だと、壊れたバックアップが出来上がる

バックアップは「取ったつもり」が一番怖い。できればリストア手順も想定しておきます。復旧の現場で人は焦ります。焦るとクリックが雑になる。雑になると被害が増える。更新作業の悪循環です。

ステップ2 プラグインのバージョンアップ先に外堀を固める

次はプラグイン更新。ここでの目的は、本体更新に備えて互換性の地雷を減らすことです。

なぜプラグインを先に更新するのか

WordPress本体が新しくなると、古いプラグインが動かないことがあります。逆に、最新プラグインは最新本体を前提に修正されていることが多い。

つまり、プラグイン更新を先に進めると、本体更新後の不具合確率を下げられます。

ただし、何でもかんでも更新すれば良いわけではありません。ここが現場の難しさ。

更新前に確認したいポイント

プラグインの最終更新日
動作確認済みのWordPressバージョン
PHPバージョン要件
利用者が多いか、開発が継続しているか

最終更新が何年も前のプラグインは、更新自体が止まっている可能性があります。その場合は、更新より先に置き換えを検討した方が安全なこともある。

更新のやり方安全な進め方

おすすめは、小分け更新です。

更新対象を2から5個程度に絞る
更新する
サイト表示と主要機能を簡易チェックする
問題なければ次の塊を更新する

面倒に見えますが、壊れた時に原因が絞れるので結果的に速いです。まとめて更新して壊れると、原因が分からず、調査で数時間溶けます。調査が趣味なら別ですが、たいてい違います。

プラグイン更新のメリット

脆弱性対策になる
本体更新後の互換性問題が減る
機能改善や不具合修正が取り込める

プラグイン更新のデメリット

機能やUIが変わることがある
他プラグインやテーマとの相性問題が出る
設定が初期化されるケースも稀にある

特にフォーム系、SEO系、キャッシュ系は影響が大きい。更新の塊を分けるなら、このあたりは単独更新が安心です。

ステップ3 WordPress本体のバージョンアップ主役の更新は丁寧に

プラグインを整えたら、本体更新に入ります。

本体更新で起きやすいこと

エディタ周りの挙動が変わる
テーマやプラグインの非推奨機能が影響する
管理画面のUIが微妙に変わる
セキュリティ関連の仕様が変わる

地味に困るのが、管理者の操作感が変わること。更新後に「いつもの場所がない」問題が発生します。これはバグではなく仕様である場合が多い。仕様は反論すると強い。

本体更新のやり方

基本は管理画面の更新機能を使います。大規模サイトや厳格な運用では、手動更新やCLI更新を選ぶ場合もあります。

管理画面から更新
WP-CLIで更新
手動でファイルを差し替える

実務で多いのは、まずステージングで検証し、問題がなければ本番も同様に更新する形です。

更新後の最低限チェック

ここで大事なのは、気持ちよく終わらせないこと。更新直後は気が緩みます。だから短いチェックを固定化します。

トップページが表示される
管理画面にログインできる
固定ページが数ページ表示される
お問い合わせフォームが送れる
コンソールエラーが増えていない

本体更新のメリット

脆弱性対策になる
機能改善が取り込める
運用者の操作性が上がる場合がある

本体更新のデメリット

テーマやプラグインが追従できていない場合に不具合が出る
管理画面の仕様変更で運用が混乱することがある
更新直後はキャッシュや最適化系が影響して表示が不安定になる場合がある

ステップ4 PHPのバージョンアップ最後にやる理由が一番深い

最後にPHP更新。ここが最大級のリスクポイントです。だから最後。

なぜPHP更新を最後に回すのか

PHPは、WordPress本体とプラグインとテーマを動かすエンジンです。エンジンを新しくすると、古い部品が動かないことがある。

先にPHPを上げると、古いプラグインやテーマが致命的に壊れる可能性が上がります。表示が真っ白、管理画面に入れない、致命的エラーで止まる。これは割と現実的に起きる。

だから、先にプラグインと本体を更新して、PHPの新しい環境でも動きやすい状態に近づけてからPHPを上げます。

PHP更新で見るべきポイント

サーバーが提供しているPHPバージョン
WordPressが推奨するPHPバージョン
利用中プラグインとテーマのPHP要件
切り戻し可能か(戻せるかどうか)

ホスティングによっては、PHPの切り替えが簡単です。逆に、戻せない運用もあります。戻せない場合は、ステージング検証の価値が跳ね上がる。

PHP更新のやり方

一般的にはサーバーの管理画面で切り替えます。VPSや専用サーバーではOSパッケージ更新やコンテナ更新になることもあります。

ステージングで同じPHPバージョンに切り替え、動作確認する
本番で切り替える前にバックアップ状態を再確認する
本番でPHPを切り替える
主要機能チェックを実施する
エラーログを確認する

PHP更新のメリット

セキュリティ面の改善
速度改善が期待できる
新しい言語機能に対応しやすい

PHP更新のデメリット

古いテーマやプラグインが動かなくなる可能性
エラーが出た時に原因が分かりにくい
一部の独自実装が非互換になる場合がある

PHP更新後にエラーが出た場合、まず疑うのは独自コードと古いプラグインです。functions.phpやmu-plugins、独自プラグインなど。地味にここが刺さることが多い。

この順番でやる理由を一気に整理する

ここまで読んで、順番の意味が見えてきたと思います。整理します。

1 バックアップが先理由は単純で最強

失敗しても戻れる状態を最初に作る。戻れない更新は、更新ではなく賭けです。賭けは楽しいけれど、仕事の賭けは胃に悪い。

2 プラグイン更新が次互換性の地雷を減らす

本体更新を迎え撃つために、周辺部品を新しくする。古い部品を抱えたまま本体を上げると、事故率が上がります。

3 本体更新はその次中核を最新に寄せる

プラグインを整えた状態で本体を上げると、互換性問題が減りやすい。更新後のトラブルが起きても原因が絞りやすい。

4 PHP更新は最後実行環境の変更は影響が最大

PHPは土台です。土台を動かす前に、上に載っているものをなるべく最新に寄せる。これが安全。

逆順でやると、まずPHP更新で壊れ、次に本体更新で追い討ちをかけ、ログインできず、バックアップも取れていない。ホラー完成。

あなたの更新作業がホラー映画になりそうな時、どの工程が一番怖いと感じますか。私はPHPです。だって土台だもの。

更新後の確認実務で本当に見るところ

更新後チェックは、全部やろうとして倒れるより、事故が起きたら困るところに絞る方が続きます。

表示確認のコツ

シークレットウィンドウで確認する(キャッシュ影響を避ける)
スマホ幅でも見る(メニューやレイアウト崩れが出やすい)
トップだけでなく下層も数ページ開く

機能確認のコツ

フォーム送信は必ずテストする
自動返信と管理者通知が届くか確認する
ログインと投稿編集を一度試す

ログ確認のコツ

可能ならサーバーのエラーログを確認します。更新後に大量の警告が出ている場合、今は問題が見えていなくても後で爆発します。静かに爆発するタイプの問題は、爆発した時に派手です。

更新でやりがちな失敗と回避策

失敗1 キャッシュ系のプラグインを更新したら表示が壊れた

キャッシュ系は、更新後にキャッシュ削除が必要なことがあります。サーバーキャッシュ、CDNキャッシュ、ブラウザキャッシュ。三段構えの時もある。

失敗2 フォームが送れなくなった

メール送信の仕組みは、PHP更新やプラグイン更新の影響を受けやすいです。SMTPプラグインを使っている場合は設定も確認。送信テストはケチらない。

失敗3 管理画面に入れない真っ白

原因がプラグインの場合、FTPやファイルマネージャーでプラグインフォルダ名を変えて無効化する方法が使えます。テーマが原因ならテーマ切り替えが必要になることもある。こういう時のために、バックアップが効きます。

フロントエンド担当が知っておくと強い視点

更新作業はサーバーやバックエンドの領域に見えますが、フロントエンドにも直撃します。

ブロックエディタ周りの影響

WordPress本体更新で、エディタのHTML出力やクラス名、ブロックのラッパー構造が変わることがあります。テーマ側でCSSをガチガチに当てていると崩れます。

jQueryやJS依存の影響

テーマやプラグインが古いjQueryや古い書き方に依存している場合、本体更新や関連ライブラリの更新で挙動が変わることがあります。コンソールエラー確認は、フロント担当の武器です。

Core Web Vitalsと更新

更新で速度が改善するケースもあります。逆に、更新でスクリプトが増え遅くなることもある。更新前後でPageSpeed InsightsやLighthouseで軽く比較すると、改善ポイントが見えます。

メリットとデメリット更新作業をする意味を現実に寄せる

WordPressとプラグインを更新するメリット

脆弱性対策になる
不具合が減る可能性
新機能や改善が使える
保守のしやすさが上がる

WordPressとプラグインを更新するデメリット

互換性問題が出る可能性
運用者が操作に迷う可能性
更新手順を誤ると復旧に時間がかかる

PHPを更新するメリット

セキュリティ面の改善
速度面の改善が期待できる
新しいライブラリや機能に追従しやすい

PHPを更新するデメリット

古いコードが動かなくなる可能性
トラブル時の原因追跡が難しい
切り戻し不可の環境だと心理的負担が増える

おまけ実務で役立つチェックリストそのまま使える

最後に、作業時に使えるチェックリストを置いておきます。コピペしてメモ帳に貼るだけでも効果があります。

作業前

更新対象の現状バージョンを控えた
重要機能の確認項目を決めた
作業時間帯と担当範囲を決めた
メンテナンス表示の有無を決めた

バックアップ

ファイルとDBの両方をバックアップした
バックアップの保存先を確認した
必要なら復旧手順を想定した

プラグイン更新

小分けで更新した
フォーム系とキャッシュ系は慎重に扱った
更新後に最低限の表示と機能を確認した

本体更新

更新後にログインできるか確認した
主要ページが表示されるか確認した
フォーム送信テストをした

PHP更新

ステージングで事前検証した
切り戻し可能か確認した
更新後にエラーログを確認した

更新前に止めるべきこと まず手癖を止める