WordPressのバージョンアップ手順：更新の順番・WP-CLIでの実行・失敗時の戻し方【7.1系対応】

WordPressのバージョンアップは、更新ボタンを押す前の洗い出しと、失敗したときの戻し方を先に決めておくかどうかで事故の大きさが変わります。2026年10月27日時点の最新版は7.1.3で、公式が保守対象とするのは7.1系の最新版だけです。本記事では、メジャーとマイナーの扱いの違い、更新対象の洗い出し、本体・データベース・プラグイン・テーマの更新順、WP-CLIで同じ手順を繰り返すスクリプト例、自動更新の範囲の決め方、失敗時にプラグイン単位・本体・サイト全体で戻す手順までを、公式ドキュメントを根拠に解説します。

まとめ：WordPressのバージョンアップはマイナーを自動・メジャーを検証後に手動で

運用の型は、次の1つに絞る方針です。セキュリティ修正を含むマイナー更新（7.1.2→7.1.3など）は自動更新に任せ、機能が変わるメジャー更新（7.0→7.1など）は検証環境で先に当ててから本番で手動実行します。プラグインとテーマは、業務に関わるものだけ自動更新から外して手動の枠に入れます。

手動で更新するときの順番は、更新前の記録とバックアップ、本体、データベース、プラグイン、テーマ、翻訳、配布物との照合です。WP-CLIでこの順番をスクリプトにしておくと、検証環境と本番で同じ作業を再現できます。

戻し方は3段階で考えます。問題のプラグインだけ旧版に戻す、本体を旧版に戻す、サイト全体をバックアップから復元する、の順です。本体を戻す場合はデータベースも更新前の状態に戻す必要があり、更新前のバックアップが無ければ戻せません。

WordPressのバージョンの種類と公式サポート：最新の7.1系だけを保守する仕組み

バージョンアップの判断は、どの更新が何を変えるかを知るところから始まります。WordPressの版番号は「7.1.3」のように3つの数字で表され、先頭2つがメジャー、3つ目がマイナーです。

メジャーとマイナーの違いと7.0から7.1.3までのリリース間隔の実測値

メジャーは機能追加や管理画面の変更を含む更新で、マイナーは不具合とセキュリティの修正です。公式のリリース一覧では、7.0が2026年5月20日、7.1が8月19日に出ています。7.1系のマイナーは9月17日の7.1.1、9月22日の7.1.2、10月6日の7.1.3と、7週間で3本出ました。

マイナーの間隔は数日のこともあるため、手作業で追いかける運用は破綻しやすくなります。マイナーを自動に任せる理由はここにあります。

旧ブランチの修正はバックポートの好意で保証されないという公式方針

WordPress.orgのセキュリティ方針は、公式にサポートするのは最新版だけだと明記しています。旧版にも重大な修正をバックポートしていますが、それは自動更新で古いサイトを守るための好意（courtesy）という位置付けです。

実際に10月6日には、7.1.3と同じ日に7.0.7と6.7.10も出ています。ただし、旧ブランチに修正が届き続ける約束はありません。7.0系のまま止めているサイトは、次のメジャー更新を計画に入れておく必要があります。7.0固有の変更点はWordPress 7.0の新機能・変更点とアップデート手順で扱っています。

バージョンアップ前の確認作業：更新対象の洗い出しとバックアップ・検証環境の準備

更新の失敗は、作業中より準備の不足で起きます。何が更新されるかを一覧にし、戻れる状態を作ってから手を付けます。

WP-CLIで本体とプラグインの更新対象・版番号・種類を洗い出す

wp core check-updateは、本体の更新候補を版番号と更新の種類（major・minor）つきで返します。プラグインはwp plugin listの既定フィールドに、現在の版と更新後の版（update_version）、自動更新の有無（auto_update）が含まれます。

# 本体の更新候補を、キャッシュを使わずに確認する（--force-check は WP-CLI 2.10.0 以降）
wp core check-update --force-check

# 更新待ちのプラグインとテーマを、現在の版・更新後の版・自動更新の有無つきで書き出す
wp plugin list --update=available --fields=name,status,version,update_version,auto_update --format=csv > plugins-pending.csv
wp theme list --update=available --fields=name,status,version,update_version,auto_update --format=csv > themes-pending.csv

# 自動更新を有効にしているプラグインだけを名前で出す（WP-CLI 2.5.0 以降）
wp plugin auto-updates status --all --enabled-only --field=name

一覧ができたら、版の先頭の数字が変わるプラグイン（2.x→3.xなど）に印を付けます。仕様の変更が入りやすいのはこの更新で、検証環境で確かめる対象もここに絞れます。

2つを超えるメジャーをまたぐときに段階更新を選ぶ公式手順書の基準

公式の更新手順書は、最初の版から最新版まで一度に上げることも可能だとしたうえで、2つを超えるメジャーをまたぐ場合は段階的な更新を検討するよう勧めています。理由として、競合の回避とデータベース破損のリスクを挙げています。

たとえば6.7から7.1へ上げる場合、間にあるメジャーは6.8・6.9・7.0の3つです。この場合は6.9、7.1の順に区切り、各段階で表示とデータベース更新の結果を確かめます。wp core update --version=6.9のように版を指定すれば、途中の版で止められます。

本番と同じ版をそろえた検証環境で先にメジャー更新を当てる理由

メジャー更新は、本番のデータとプラグイン構成を写した検証環境で先に当てます。本体だけ新しい版にした空の環境では、業務で使う画面やフォームの不具合が出ないためです。複製の作り方とバックアップの取り方はWordPressのバックアップ設計と復元テストの手順にまとめています。

あわせてPHPの版も本番とそろえます。WordPress 7.1が動くPHPの範囲や、PHP側を上げる手順はWordPressのPHPバージョンアップ手順を参照してください。本体とPHPを同じ日に上げると、不具合の原因をどちらか一方に切り分けられなくなります。

WP-CLIでのバージョンアップ手順：本体・データベース・プラグイン・テーマの順番

手動で更新する場合も、管理画面のボタンではなくコマンドで実行すると、検証環境と本番で手順がずれません。

更新前の記録から配布物との照合までを順番に実行するスクリプトの例

公式の手順書は、本体を置き換えて更新プログラムを走らせた後に、プラグインとテーマを更新する順番を示しています。次のスクリプトはこの順番をWP-CLIに置き換えたものです。

#!/bin/bash
# WordPressのバージョンアップを、検証環境と本番で同じ手順で実行する
set -euo pipefail
cd /var/www/example   # WordPressの設置ディレクトリ
STAMP=$(date +%Y%m%d-%H%M)

# 1. 更新前の状態を記録する（戻すときの基準になる）
wp core version --extra > "before-core-${STAMP}.txt"
wp plugin list --fields=name,status,version --format=csv > "before-plugins-${STAMP}.csv"
wp theme list --fields=name,status,version --format=csv > "before-themes-${STAMP}.csv"

# 2. データベースを書き出す（ファイル一式の取得は別手順で先に済ませる）
wp db export "before-db-${STAMP}.sql"

# 3. 本体 → データベース → プラグイン → テーマ → 翻訳の順に更新する
wp core update
wp core update-db
wp plugin update --all
wp theme update --all
wp language core update

# 4. 本体とプラグインのファイルが配布物と一致するかを確かめる
wp core verify-checksums --locale=ja
wp plugin verify-checksums --all

wp plugin update –allは、更新の間だけメンテナンスモードを自動で入れて外します。wp core verify-checksumsは、ダッシュボードの更新画面に出る言語と版を指定しないと照合が合わない場合があると公式が案内しています。日本語版で入れたサイトに付ける指定は--locale=jaです。wp plugin verify-checksumsはWordPress.orgの配布物と照合するため、有料プラグインなど公式ディレクトリにないものは対象外として扱います。

–minorと–patchでプラグインの更新幅を絞り本番の変化を小さくする

wp plugin updateで更新の幅を絞るのは、次の2つのオプションです。--minorは1.3から1.4のような2桁目までの更新だけを、--patchは1.3から1.3.3のような3桁目の更新だけを実行します。テーマ側の同じオプションは、WP-CLI 2.10.0で追加されています。

# どのプラグインがどの版になるかを、実行せずに確かめる
wp plugin update --all --minor --dry-run

# 検証が終わっていない会員機能のプラグインを外して、残りを更新する
wp plugin update --all --minor --exclude=my-member-plugin

先頭の数字が変わる更新だけを検証環境に回し、本番では--minorで差を小さく保つと、検証の工数を版の大きな変更に集中できます。

ワンクリック更新が止まったときの.maintenanceと更新ロックの解除

管理画面の更新が途中で止まると、「定期メンテナンスのため、一時的に利用できません」という表示が残ることがあります。公式の日本語ドキュメントは、WordPressのディレクトリにある.maintenanceファイルを削除すれば表示が消えると案内しています。

WP-CLIで更新を再実行して「Error: Another update is currently in progress.」が出る場合は、ほかの更新が本当に動いていないことを確かめてからwp option delete core_updater.lockでロックを外します。この手順はwp core updateの公式ページに記載があります。

自動更新の範囲の決め方：本体のマイナーとプラグインを分けて設定する運用ルール

自動更新は、全部有効にするか全部止めるかの二択ではありません。本体・プラグイン・テーマで別々に決められます。

既存サイトと新規サイトで違う本体の自動更新の既定値と定数での固定

公式の手順書によると、WordPress 5.6以降に新しく入れたサイトは、メジャーとマイナーの両方が既定で自動更新されます。5.6より前から使っているサイトは、管理者が変えない限りマイナーだけが自動更新の対象です。同じ7.1.3でも、サイトを作った時期によって既定の動きが違うということです。

運用の型に合わせて固定するなら、wp-config.phpに次の1行を書きます。この定数は管理画面の自動更新の設定より優先されます。

// 本体はマイナー更新だけを自動にし、メジャーは検証後に手動で当てる
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

自動更新をすべて止める定数もありますが、公式は強く非推奨としています。フィルターで細かく制御する場合に案内されている記述先は、wp-config.phpではなくmu-pluginです。定数とフィルターの組み合わせ方はWordPressセキュリティ対策の自動更新の章で詳しく扱っています。

6.6のプラグイン自動ロールバックが拾える失敗と拾えない失敗の境目

プラグインの自動更新は、5.5からプラグイン単位で有効にできるようになりました。実行は1日2回で、成功と失敗の結果がメールで届きます。6.6のフィールドガイドによると、自動更新でPHPの致命的エラーを検知したときは旧版に戻す仕組みも入っています。

ただし、この機能の統合提案では、判定はトップページへのループバック要求で行うと説明されています。トップページが表示できれば、フォームの送信、決済、会員ページなど別の画面で起きる不具合は戻す対象になりません。致命的エラーではない表示崩れも同じです。業務で使う画面に関わるプラグインは自動更新から外し、検証環境を通す手動の枠で扱います。

バージョンアップに失敗したときの戻し方：プラグイン単位・本体・サイト全体の3段階

戻す範囲は小さい順に考えます。問題を起こしたものだけを戻せば、ほかの更新に含まれる脆弱性の修正を捨てずに済みます。

wp plugin updateの–versionで問題のプラグインを旧版へ戻す手順

原因のプラグインが分かっている場合は、更新前に記録した版を指定して戻します。wp plugin updateの--versionは、指定した版への更新を実行するオプションです。

# 更新前の記録から、問題のプラグインの版を確かめる
grep my-form-plugin before-plugins-20261027-0900.csv

# 記録した版へ戻し、そのプラグインの自動更新を止める
wp plugin update my-form-plugin --version=4.2.1
wp plugin auto-updates disable my-form-plugin

自動更新を止めないまま戻すと、次の自動更新でまた同じ版に上がります。戻した後は、修正版が出たかを確認する担当者と期限を決めておきます。

本体を戻すときにデータベースの復元が必要になる理由と–forceの使い方

本体を旧版に戻すこと自体は、wp core update --version=7.0.7 --forceで実行できます。ただし公式の手順書は、旧版へのロールバックを原則として勧めていません。新しい版にはセキュリティ修正が含まれること、版の間でデータベースの構造が変わることの2つが理由です。

メジャー更新ではwp core update-dbでデータベースの版も上がります。ファイルだけを旧版に戻した場合は、新しい構造のデータベースを古いコードが読む状態です。本体を戻すときは、更新前に書き出したデータベースもあわせて復元します。公式の説明では、更新前にサイト全体とデータベースのバックアップが無ければ、ロールバックの成功はほぼ不可能です。メジャー更新の前にバックアップを取り、それが使えることまで確かめる工程を省かないでください。

自社でバージョンアップを回せるサイトと保守会社に任せるサイトの判断基準

ここまでの手順を自社で回せるかは、サイトの構成でほぼ決まります。

自社で更新を回せるサイトと保守会社に任せるサイトの構成の違い

自社で回せるのは、公式ディレクトリのプラグインだけで組まれ、フォームの送信先や外部連携が少ないサイトです。マイナーを自動に任せ、メジャーが出るたびに検証環境で確かめれば足ります。

保守会社に任せた方がよいのは、独自開発のプラグインやテーマの改変があるサイト、会員機能や決済でトップページ以外に業務画面を持つサイト、検証環境を用意できないサイトです。この構成で業務を止めるのは、6.6の自動ロールバックが拾えない不具合です。弊社のWordPress保守・メンテナンスでは、検証環境での事前確認と戻し方の取り決めを含めて更新を引き受けています。保守の範囲や費用の目安はWordPress保守運用とはで整理しています。

更新を止めて据え置く判断をしてはいけない場面と期限付きの例外の扱い方

「不具合が怖いので更新を止める」という判断は採用しません。公式が保守するのは最新版だけで、旧ブランチへの修正は約束されていないからです。止めてよいのは、特定のプラグインの更新を、修正版が出るまで期限付きで保留する場合に限ります。

サーバーが古く、新しいPHPに上げられないためにWordPressも上げられない場合は、更新の問題ではなくサーバーの問題です。この場合はWordPressのサーバー移行の手順を先に検討します。

WordPressのバージョンアップでつまずきやすい点のよくある質問

WordPressのバージョンアップについて、検索で多く見られる質問に答えます。

WordPressの現在のバージョンはどこで確認できますか？

管理画面の「ダッシュボード」→「更新」に、現在の版と更新できる版が表示されます。サーバーにログインできる場合は、wp core version --extraで本体の版とデータベースの版を同時に確認できます。データベースの版は本体を戻すときの判断材料になるため、更新前に控えておくと安心です。最新版は公式のリリース一覧で確認でき、2026年10月27日時点では7.1.3です。

古いバージョンから一気に最新版へ上げても大丈夫ですか？

公式は、最初期の版から最新版まで一度に上げることも可能だとしています。そのうえで公式が勧めているのは、2つを超えるメジャーをまたぐ場合に段階的な更新を検討することです。6.7から7.1のように3つ以上のメジャーをまたぐなら、6.9で一度止めて表示とデータベース更新を確かめてから7.1へ進めます。どの段階でも、作業前のバックアップは必ず残してください。

WordPress本体とプラグインはどちらを先に更新すべきですか？

公式の手順書の順番は、本体を先に更新し、その後にプラグインとテーマを更新する流れです。新しいプラグインの版が新しい本体を前提にしている場合があるためです。ただし、本体のメジャー更新に対応していないことが分かっているプラグインは、本体を上げる前に検証環境で動作を確認しておきます。

バージョンアップの前にプラグインをすべて停止する必要はありますか？

ファイルを手で置き換える手動更新では、公式は全プラグインの停止を手順に含めています。管理画面のワンクリック更新やwp core updateの手順には、全停止は含まれていません。ただし手動更新に切り替えるのは、ワンクリック更新が失敗した場合が大半です。その場合は公式の手順どおり停止してから作業します。

バージョンアップ後にサイトが真っ白になったらどうすればよいですか？

まず更新直後に入れたプラグインを疑い、サーバー上でwp-content/plugins内の該当フォルダ名を変えて無効化します。表示が戻った場合に旧版へ戻す対象は、そのプラグインだけです。本体の更新で起きた場合は、ファイルとデータベースを更新前のバックアップから一緒に復元します。メンテナンス表示が消えない場合は.maintenanceファイルを削除してください。

関連記事

• WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準を解説：バージョンアップを含む保守を、誰がどの範囲で担うかを判断する材料になります。
• WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順【7.1系対応】：更新前の取得と、戻すときの復元の手順をまとめています。
• WordPressのPHPバージョンアップ手順：互換性確認・切り替え・戻し方【7.1系対応】：本体と分けて行うPHP側の版上げの手順です。
• WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】：7.1.2・7.1.3で修正された脆弱性と、自動更新の設定の詳細です。
• WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順：7.0へのメジャー更新で変わった点を確認できます。