WordPress本体のバージョンアップ前に確認するリスクと実施判断

WordPress本体の更新通知が届いたとき、すぐ更新してよいのか、見送るべきなのかで迷うことがあります。更新しないまま待つリスクと、更新で表示や機能に影響が出るリスクは、別々に考える必要があります。結論から言えば、更新そのものは必要で、見送る場合も、担当者と次に判断する時点を決めた、期限のある判断にします。この記事では、更新の前の段階に絞り、今回の更新の対象、構成への影響、戻せる準備、実施の時期の順に判断材料をそろえます。更新の操作、更新後の不具合への対処、プラグインの停止や削除、代わりの製品探しは扱いません。公的な情報は2026年10月30日に確認しました。

本体更新には、実施することのリスクと、見送っている間のリスクがあります。片方だけを見ると判断が偏るため、分けて整理します。

IPA（情報処理推進機構）の「安全なウェブサイトの運用管理に向けての20ヶ条」（2019年3月6日更新）は、OSやサーバーソフトウェアなどのバージョンアップで、今まで動作していたウェブアプリケーションが正常に動作しなくなる場合があるため、事前の検証が必要だと述べています。同じ文書の別の項目は、CMSを含む構成ソフトウェアに脆弱

性が見つかれば、適宜バージョンアップするよう求めています。更新は必要で、その前に確かめることも必要です。

確かめる対象は三つです。テーマやプラグインとの組み合わせ、本体のファイルに加えた独自の変更、PHP（WordPressが動く土台）やデータベースの環境です。独自の変更は、WordPress.orgの更新手順が、更新で失われると警告しています。何がどの程度起きるかは構成で変わるため、一般論では示せず、自分のサイトで確かめるまで分かりません。

見送っている間は、修正が適用されていない状態が続きます。WordPress.orgのセキュリティ方針は、正式にサポートされるのは最新版のみで、古いバージョンへの修正の移植は厚意だと説明しています。古いバージョンのまま待つと、修正が届くかは約束されません。

どれだけ急ぐかは、告知から読み取ります。たとえば、2026年9月22日公開の7.1.2の告知は、重大度「critical」の脆弱性を修正するセキュリティ更新として、直ちに更新するよう勧めています。その後も、10月6日に7.1.3、10月28日に7.1.4が公開され、それぞれの告知（7.1.3、7.1.4）はどちらもセキュリティ更新だと説明しています。ここで挙げた版番号は確認日時点のもので、版はその後も進むため、今の最新版はリリース一覧で確かめます。告知の読み方と影響の判断は、今回の修正が自サイトに及ぼす影響の読み方で詳しく取り上げています。

判断の前に、何が更新されるのかを特定します。

最初に控えるのは、現在の本体のバージョンと、更新通知が示す更新先のバージョンです。管理画面に入れる場合は、「更新」の画面に現在のバージョンが表示されます。本体、テーマ、プラグイン、PHPは別のソフトウェアで、通知も別々に出ます。とくに取り違えやすいのがPHPです。PHPのバージョンはサーバー側で決まり、その変更は本体の更新とは別の作業です。同じ「バージョン」でも数字は別なので、控えるときは名前を添えます。

管理画面に入れない場合は、サイトを管理している相手（制作会社、保守会社、社内の管理者など）に、次を尋ねます。

次に、公式の告知で、今回の更新が何を変えるのかを読みます。2026年8月19日公開の7.1の告知は、サイトエディタでの画面幅ごとのスタイル指定やメディアの編集など、機能の追加を中心に紹介しています。前の章で見た9月22日の更新は、セキュリティ修正でした。公式の自動更新の説明は、保守やセキュリティの更新を含む「マイナー」と、機能の追加を含む大きな更新である「メジャー」を区別しますが、この呼び方だけで安全性や緊急性は決まりません。

公式の説明では、5.6以降に新しく導入したサイトは大きな更新（メジャー）も初めから自動更新の対象ですが、それより前から使っているサイトは、設定を変えない限り小さな更新（マイナー）だけが対象です。いずれの場合も、設定で変更も停止もできます。自動更新の仕組みは、今回の修正が自サイトに及ぼす影響の読み方でも取り上げています。

この記事で確かめるのは、自分のサイトの実際の設定です。サーバー会社の管理ツールなど、WordPressの外側で設定されている場合もあります。管理している相手に、次を確認します。

自動で更新されるかはサイトごとに違うため、思い込みで判断しないことが大切です。

対象を並べるだけでは判断は進みません。今回の更新の内容と構成を照らして範囲を絞り、確かめられなかった範囲は未確認として記録します。

最初に、利用中のテーマと有効なプラグインを一覧にし、独自の変更があれば加えます。配布元には、対応状況の手がかりが載ることがあります。WordPress.orgのプラグインの配布ページに載る説明の「Tested up to」は、テストしたWordPressのバージョンを示し、マイナーバージョンは無視されます。「Requires PHP」は、必要な最低限のPHPのバージョンです（公式の説明）。

これは配布元の記載で、自分のサイトの構成で確かめた結果ではありません。「Tested up to」が更新先と合っていてもずれていても、それだけで自分のサイトでの動作は決まりません。表示がない場合も、非対応と決めつけず、未確認として次に進めます。商用や自社制作のテーマ、独自の変更が入った部分は、一般的な基準で対応の可否を決められないため、制作した側や配布元に確認するか、後で触れる試験で確かめます。本体のファイルへの変更は更新で失われるので、誰がどのファイルを変えたか分からなければ、未確認として記録します。

PHPとデータベースは、本体とは別の確認対象です。データベースの種類とバージョンは、サーバー会社の管理画面や契約の案内で分かることが多いものの、表示は会社ごとに違い、分からなければ管理している相手に尋ねます。

WordPress.orgの要件のページは、推奨する環境を示します。同じページは、より古いPHPやMySQLでも動く場合があると書く一方、そうした環境は公式のサポートが終了しており、脆弱性にさらされるおそれがあると注意します。この二つは別の説明として読みます。

このページの内容が、今回の更新先の最低条件と同じとは限りません。更新先のバージョンごとの要件はここからは確定できないため、告知や、サーバー会社、制作会社への確認で補い、確かめられなければ未確認として次の判断へ持ち込みます。

PHPのバージョンを変える作業は、本体の更新とは別です。同じ日に重ねるか分けるかは、それぞれを戻せるかと確認の手間で変わるため、一律には決められません。公式の案内では、本体・テーマ・プラグインを先に更新し、新しいPHPで動くかを確かめてからPHPを切り替えます。ただし、今のPHPのままでは先に更新できないものがある場合は、試験用の環境で確かめたうえで、サーバーの管理者や保守の担当者と順序を決めます。PHPの切り替えの準備は、本体更新と区別して行うPHP切替の準備にまとめています。

すべてを同じ深さで確かめると、時間が足りません。先に試す箇所は、二つの観点で決めます。

一つ目は、今回の変更との接点です。たとえば前の章の7.1の告知は、画面幅ごとのスタイル指定、メディアの編集と画像の処理、新しいブロックなどを挙げています。自分のサイトがそうした機能を使っていれば接点があり、使っていなければ優先度は下がります。セキュリティ修正の影響範囲は、説明から自分で推測せず、読み取れなければ接点が不明なものとして扱います。

二つ目は、事業への影響の大きさです。問い合わせフォームや予約など、止まると事業に直結する機能と、サイトの入口のページが候補です。独自の変更も、結果が読みにくいため候補に入ります。

この表は確かめる順番を決めるためのもので、重大なセキュリティ更新を延ばす理由にはしません。本番と同じ構成の試験用のサイトなど、別の環境を用意できればそこで試し、用意できなければ、確かめられなかった範囲を記録します。環境の有無や項目の数が、そのまま安全の条件になるわけではありません。結果は、確かめた範囲と未確認の範囲に分けて記録し、実施の判断材料にします。

公式の更新手順は、問題が起きたときに復元できるよう、更新の前のバックアップを案内しています。更新前に今あるバックアップで復元を試す確認と、定期取得・保存と復元試験の運用記録は、別の記事で詳しく取り上げます。この記事が扱うのは、その結果を実施条件に含める部分で、三つに分けます。

確認済みなら、条件の一つを満たします。一部未確認なら、確認する時間と手段を確保できるかを見て、確保できなければ未確認のまま実施時期の判断に持ち込みます。確認できなければ、実施の判断を保留して確認先を決めます。

もう一つの条件は、時間と担当者です。実施後に表示と動作を確かめ、必要なら戻す作業ができる時間と担当者を、その日に確保できるかを確かめます。確保できなければ、バックアップが確認済みでも、その日の実施は条件を満たしません。バックアップがあれば必ず戻せる、という保証もありません。

判断に使うのは、告知（セキュリティ修正を含むか、公式がどう更新を勧めているか）、影響の確認、戻せる準備、実施後に対応できる時間と担当者の四つです。これに業務上の制約（繁忙日、キャンペーン期間、担当者の不在日など）を重ね、実施を避ける日を決めます。

公開から何日待つか、夜間に行うか、更新の区分がマイナーかどうかといった一つの基準だけでは決めません。構成や準備を見ないままでは、どれも安全を保証しないからです。一方、未確認を理由にいつまでも延期することも勧めません。正式にサポートされるのは最新版のみなので、見送りは、解消する担当者と次に判断する時点を決めた、期限のある判断にします。試験が済んでいても、更新後に何も起きない保証にはなりません。

確認しきれなかった項目は、消さずに記録します。項目ごとに、未確認の内容（例: プラグインの対応、データベースのバージョン、復元できるか）、その理由（例: 配布元に情報がない、管理画面に入れない）、確認先（例: 配布元、サーバー会社、制作会社、社内の管理者）、次に判断する時点（日付、または返事が届いた時点）の四つを書きます。

確認先が必ず対応してくれるとは限らず、返事が得られないことも記録します。相談するときは、現在の本体のバージョン、今回の更新の対象、テーマやプラグインなどの構成、ここまでの確認の結果、未確認の理由、実施したい時期を添えます。

確認先が社内に見つからない、公式の情報を今後も追う人が決まらない場合は、今回の更新だけの話ではなくなります。その考え方は、更新情報と判断を自社で追い続けられるかの基準で整理しています。

更新の前に確かめることは、更新の対象、構成への影響、戻せる準備の結果、確認しきれなかった項目の扱いの四つです。これらを合わせて実施の時期を決め、見送りも期限のある判断にします。すでに更新が途中で止まった、更新の後に画面が表示されなくなった場合は、この記事の範囲を超え、起きた状況の整理から始めることになります。確認の担当者や時間がそろわず、判断を自社だけで進められない場合は、本体更新を含むWordPress保守の相談をご覧ください。

本記事は、ビークリエイトのWordPress保守チームの知見をもとに構成しています。詳しくは会社概要をご覧ください。