WordPressのメジャーアップデートは、公開されたらすぐに適用したほうがよいのでしょうか。
急いで適用すると、かえってリスクが高くなる場合があります。
grandworkがWordPressの保守で行っている方法をもとに、アップデートを急がないほうがよい理由と、検証環境の作り方、wp-cliを使った自動アップデートの手順を説明します。
WordPressのバージョン表記とアップデート分類
WordPressのバージョンは、「7.1.3」のように3つの数字で表されます。
- 最初の数字（7）または2番目の数字（1）が変わる場合
→ メジャーアップデート（機能追加・仕様変更） - 最後の数字（3）が変わる場合
→ マイナーアップデート（セキュリティパッチ・バグ修正）
アップデートの進め方は、この2つを区別するところから始まります。
メジャーアップデートは必ず実施する。ただし急ぐ必要はない
公開直後に適用しない理由
- リリース直後は、不具合や互換性の問題が見つかることがある
- 急いで適用すると、サイトが表示されなくなったり、一部の機能が動かなくなったりするおそれがある
当社ではWelcartを使う機会が多いのですが、次のような不具合はどうしても起こります。バグのないシステムはそもそも存在しない、というのが当社の認識です。
[解決済]2.11.15アップデートによるクレジットカード決済不具合のご報告
そのため、当社では次の流れでアップデートしています。
- リリース後1〜4週間（プラグインやテーマの対応状況などにより変動 *）様子を見る
- 安全性が確認されてからアップデートする
実務のうえでも、この進め方がよいと考えています。
待つあいだに見るのは、日数よりも次の3つです。使っているプラグインやテーマの提供元が、新しいバージョンへの対応を案内しているか。最初のマイナーアップデート（7.1なら7.1.1）が出て、公開直後の不具合が直っているか。検証環境で更新して、問題が出ていないか。この3つがそろえば、4週間を待たずに更新してかまいません。
*脆弱性を修正するアップデートは、できるかぎりすぐに適用してください。
マイナーアップデートは自動適用がおすすめ
マイナーアップデートの中心は、次の2つです。
- セキュリティ修正
- 軽微な不具合の修正
そのため、互換性が失われるリスクは低いといえます。
define( 'WP_AUTO_UPDATE_CORE', 'minor' );管理画面の設定にかかわらず、マイナーアップデートだけを自動にしておきたい場合は、wp-config.phpに上の1行を書きます。この設定では、メジャーアップデートは自動で適用されません。マイナーアップデートを自動で受け取っておけば、WordPress本体のセキュリティリスクを最小限に抑えられます。
*ただし、WordPress本体のアップデートだけでは、セキュリティ対策として十分ではありません。
WordPress本体、プラグイン、テーマ、サーバ（PHPのバージョン）、WAFまで、ひととおり対応して初めて対策になります。
アップデートは、まず検証環境で確かめる
本番サイトをいきなりアップデートするのは危険です。
必ず検証環境（ステージング環境）を用意し、先にそちらで動作を確認してください。
検証環境の作成例
| 方法 | 特徴 |
|---|---|
| ローカル開発環境 | XAMPP（またはMAMP）やLocalWPなどを使い、PC上に構築する |
| 同サーバー別ディレクトリ | サブドメイン（staging.example.comなど）に複製する 本番と同じサーバー環境で検証するほうが、より正確に確認できます。 |
検証環境（ステージング環境）ではwp-cliによる自動アップデートが便利
当社では、検証環境のアップデートをwp-cliのスクリプトで自動実行しています。
自動実行にしておくと、次の利点があります。
- 毎回、手作業でアップデートしなくて済む
- 不具合が起きても、ログから「どのプラグインの更新が原因か」を特定しやすい
- 問題があれば、該当プラグインのみ停止して対応できる
手動確認を省力化したい方へ
検証環境では、wp-cliによる自動実行を当社はおすすめしています。
スクリプトを用意するのが難しい場合は、WordPress本体、プラグイン、テーマをすべて「自動更新」に設定するのも一つの方法です。
ただし、WordPress標準の自動更新には次の動きがあります。
- WordPress標準の自動更新（wp-cron経由）は、サイトにアクセスがあったときに実行される
- アップデートの処理が始まると、サイトは一時的にメンテナンスモードになる
これが、本番サイトでは、メジャーアップデートやプラグイン・テーマの自動更新を基本的に避けたほうがよい理由の一つです。マイナーアップデートは更新の範囲が小さいので、前に書いたとおり自動で適用してかまいません。
wp-cliによる自動アップデートスクリプト例（バックアップ込み）
WordPressのアップデートを安全に行うためには、事前にバックアップを取ったうえで実行することが基本です。
当社でも、検証環境をアップデートする前に次の2つを取っています。
- データベース（MySQL）のバックアップ
- WordPressファイル一式のバックアップ（丸ごとコピー）
そのうえで、アップデートを自動実行しています。
フルバックアップ込みのスクリプト例
#!/bin/bash
# 検証環境のWordPressを更新する例。どこかで失敗したら、その時点で止まる。
set -euo pipefail
# 日付と時刻を付ける（例：20261016-0300）
DATE=$(date +%Y%m%d-%H%M)
# ディレクトリ設定
WP_PATH="/path/to/your/staging/wordpress"
BACKUP_PATH="/path/to/your/backup/$DATE"
mkdir -p "$BACKUP_PATH"
cd "$WP_PATH"
# データベースのバックアップ（接続情報は wp-config.php から読まれる）
wp db export "$BACKUP_PATH/db_backup.sql"
# バックアップが空でないことを確かめる。空なら、ここで止まる
test -s "$BACKUP_PATH/db_backup.sql"
# WordPressファイル一式のバックアップ（丸ごとコピー）
rsync -a "$WP_PATH/" "$BACKUP_PATH/wp_files/"
# WordPress本体を更新し、続けてデータベースを更新する
wp core update
wp core update-db
# プラグインとテーマを更新する
wp plugin update --all
wp theme update --all
# 結果をログに残す
wp core version
wp plugin list --fields=name,status,versionこのスクリプトで気をつけている点は3つです。
- 1行目の
set -euo pipefailで、どこかの処理が失敗したらそこで止まるようにしています。バックアップに失敗したまま、更新へ進まないためです。 - データベースのバックアップには
wp db exportを使い、パスワードを命令の中に書きません。接続情報は wp-config.php から読まれます。MySQLの公式資料でも、パスワードを命令に直接書く方法は、ほかの利用者から見えるおそれがあるため安全ではないとされています。 - rootでは実行しません。WP-CLIは、rootで実行しようとすると警告を出して止まります。
--allow-rootを付ければ動きますが、WordPressのファイルを持っているユーザーで実行するほうが安全です。
バックアップ方法について補足
- DBバックアップはSQL形式
→ テキストファイルなのでリストア（復元）が容易です。 - ファイルのバックアップはrsyncでそのままコピー
→ zipにまとめなくても、速く確実にコピーできます。 - 取ったバックアップから実際に戻せるかを、検証環境で一度試しておく
→ 取れていることと、戻せることは別です。WordPressの公式資料も、バックアップが使える状態かを確かめるよう案内しています。
cron設定による自動実行例
0 3 * * 1 /bin/bash /path/to/update_wp_staging.sh >> /path/to/your/logs/wp_staging_update.log 2>&1- 毎週月曜3時に自動実行（WordPressのファイルを持っているユーザーのcrontabに登録する）
- ログはそのユーザーが書き込める場所に出力する（パスは環境に合わせて変更）
まとめ – やみくもに急ぐのではなく、慎重な判断と準備を
WordPressの保守で、アップデートは欠かせない作業です。
ただし、急いで適用すればよいわけではなく、適用する時期の判断と事前の準備が必要です。
本記事の振り返り
- WordPressのバージョン表記は、「メジャーアップデート」と「マイナーアップデート」に分かれる（最初または2番目の数字が変わればメジャー、最後の数字ならマイナー）
- メジャーアップデートは必ず実施する。リリース直後の適用は避け、プラグイン・テーマの対応、最初のマイナーアップデート、検証環境での結果を見てから更新する（目安は1〜4週間）
- マイナーアップデートはセキュリティ修正が中心で、標準で自動適用される。自動更新を止めていないかを確かめておく
- 本番環境で直接アップデートせず、必ず検証環境（ステージング）で事前確認することが安全運用の基本
- ステージング環境では、wp-cliによる自動アップデート＋ログ確認運用が効率的
- アップデート前には、データベースとWordPressファイルのバックアップを必ず取得する
- バックアップは、SQLダンプ＋rsyncによるファイルコピーがシンプルで速い
有償プラグイン（サブスクリプションのプランなど）を使う方法もある
それが、WordPressサイトを長く安定して運用することにつながります。
保守に関するご相談・お問い合わせ
- 「もっと具体的な運用方法を知りたい」
- 「自社サイトに最適なアップデート管理を提案してほしい」
- 「保守管理の一部だけ外注したい」
保守プランのご提案、お見積り、ご質問など、下記フォームより承っております。
お問い合わせ・ご相談
やりたいことを、まずはお気軽にお送りください。内容を確認して、改めて連絡させていただきます。
あわせてお読みいただきたい記事
WordPressの保守管理とは？ 自分で対応すべき内容と外注の考え方