WordPressの更新ボタンを押しても上がらないとき｜バージョンを固定している設定と、更新が途中で止まる原因

WordPressの管理画面で「今すぐ更新」を押したのに、バージョンが上がらない。もう一度押しても同じ。エラーらしいエラーも出ない——この症状は、やみくもに何度も更新ボタンを押しても解決しません。原因は大きく3系統に分かれ、確認する順番が決まっています。

先に結論を書くと、確認の順番は次のとおりです。

1. バージョンを固定する仕組みが入っていないか（ダウングレード系プラグイン・設定ファイルの固定記述）
2. 更新を実行するツール側が古くないか（サーバー付属のWP-CLIやPHPのバージョン非互換）
3. 環境要因で途中で止まっていないか（ディスク容量・権限・タイムアウト）

この記事では、実際に医療系クリニックのサイトでWordPress 6.6.1から7.0.2への更新を行ったときの実測値を交えながら、それぞれの見分け方と対処を整理します。対象は、自社サイトの管理を任されているWEB担当者や、制作会社からサイトを引き継いだ店舗経営者の方です。

原因1｜「何度更新しても同じバージョンに戻る」ならバージョン固定を疑う

最初に確認すべきは、バージョンを意図的に固定する仕組みが入っていないかです。

WordPressには「WP Downgrade」のように、コアのバージョンを特定の版に固定するプラグインがあります。過去の制作会社が「テーマが新バージョンに対応していないから」といった理由で入れたまま、引き継ぎ資料に書かれず残っているケースが実際にあります。

このプラグインが有効な間は、管理画面から何度更新しても、指定されたバージョンに戻り続けます。更新処理自体は動くので、エラーも出ません。「更新したはずなのにバージョン表示が変わらない」という症状になり、原因に気づきにくいのが厄介な点です。

確認する場所

• 管理画面の「プラグイン」一覧で、Downgrade・バージョン固定系の名前を探す
• データベースの wp_options テーブルに wpdg_specific_version_name のような固定バージョンを保持するオプションが残っていないか確認する

対処の手順

固定しているプラグインを見つけたら、いきなり消すのではなく、次の順で進めます。

1. なぜ固定されているのかを先に調べる。テーマやプラグインの互換性問題を避けるための固定なら、外した後に表示が壊れる可能性がある
2. バックアップを取る（後述）
3. プラグインを無効化・削除する
4. オプションの残骸まで消す。プラグインを削除しても設定値がデータベースに残ることがあり、残骸が0件になったことを確認して完了とする

実際の作業では、この固定プラグインを削除して初めて更新が通るようになりました。固定が残っている限り、他のどんな対処をしても永久に上がりません。

原因2｜サーバー付属のWP-CLIやPHPが古くて更新処理が失敗する

バージョン固定がないのに更新が失敗する場合、次に疑うのは更新を実行するツール側の非互換です。

レンタルサーバーには、コマンドラインからWordPressを操作するWP-CLIというツールがあらかじめ入っていることが多いのですが、このサーバー付属版が古いままになっていることがあります。実際の作業では、サーバー標準のWP-CLI 2.4.0でWordPress 7.0系への更新を実行したところ、内部処理（更新パッケージのダウンロード処理）の非互換で致命的エラーになりました。

ここで重要なのは、このエラーで止まってもWordPress本体は無傷で残るという点です。更新パッケージの取得段階で失敗しているため、サイトが壊れたわけではありません。エラー画面を見ると焦りますが、落ち着いてツール側を差し替えれば解決します。対処は、最新版のWP-CLI（作業時点で2.12.0)を自分のホームディレクトリに配置し、そちらで更新を実行するだけです。

もうひとつ、似た系統の詰まり方としてサーバーのデフォルトPHPが極端に古いケースがあります。別のサーバーでは、SSH接続時のデフォルトPHPが5.4系のままで、WP-CLI自体が起動しませんでした。この場合は、サーバーに入っている新しいPHP（例: 8.2系)のフルパスを明示してWP-CLIを実行します。サイトの表示に使われるPHPと、コマンドラインのPHPは別に設定されているサーバーが多く、「サイトは動いているのにコマンドが動かない」という混乱の原因になります。

原因3｜容量・権限・タイムアウトで途中で止まる

更新が「失敗しました」で止まる場合の残りの系統が環境要因です。

• ディスク容量不足: 更新は一時的に新旧両方のファイルを持つため、普段の倍近い空きが要る。サーバーパネルで使用率を確認する
• ファイル権限: サーバー移転やファイル転送の後に起きやすい。転送ツールの設定によっては、手元の環境の権限がそのまま本番に運ばれ、WordPressが自分のファイルを書き換えられなくなる
• タイムアウト: 共用サーバーの処理時間制限に引っかかると、更新途中でメンテナンスモードのまま止まる。docroot直下の .maintenance ファイルを削除すると復帰する

更新前に「戻せる状態」を作る｜実測値つきの手順

原因の切り分けと同じくらい大事なのが、更新前の準備です。実際の更新作業では、次の状態を作ってから実行しました。

• データベースのバックアップ(実測33MB)とファイル一式のバックアップ（実測448MB）を取得
• バックアップはサーバー上とローカルの2か所に保管
• 2か所のファイルがハッシュ値（sha256）で完全一致することを確認

「バックアップを取った」で終わらせず、ハッシュ照合まで行うのは、転送中の欠損に気づかないまま「戻せるつもり」になる事態を防ぐためです。戻せないバックアップは、無いのと同じです。

更新後の検証も数える

更新が通った後は、体感で「動いてそう」ではなく数で検証します。実際の検証項目は次のとおりでした。

• 記事数の完全一致: 投稿28・固定ページ17・お知らせ43・施術メニュー57件が更新前後で1件も変わらないこと
• REST APIが200を返すこと（外部連携やヘッドレス構成では特に必須）
• PHPの致命的エラーログが0件であること

この3点が揃って初めて「更新完了」と言えます。

自動更新の設定は「全部ON」でも「全部OFF」でもない

更新まわりでもうひとつ設計しておきたいのが、プラグインの自動更新です。

全プラグインの自動更新をONにしておくと、セキュリティ面では安心ですが、ページビルダーのような表示に直結する大型プラグインのメジャー更新まで予告なく走ります。実際の現場でも、19個のプラグインすべてが自動更新ONで、ページビルダーの4.1系から4.2系へのメジャー更新がいつ走ってもおかしくない状態でした。

かといって全部OFFにすると、今度はセキュリティ更新が止まり、脆弱性を抱えたまま放置される危険のほうが大きくなります。

実務的な落とし所は次の線引きです。

• 表示崩れリスクのある大型プラグイン（ページビルダー等）だけ自動更新OFFにして、手動でバックアップとセットで更新する
• それ以外はONを維持して、セキュリティ更新を止めない

「上がらないから放置」が一番危ない

最後に強調しておきたいのは、更新が上がらない原因を放置しないことです。

「更新ボタンを押しても上がらないから、そのまま使っている」という状態は、バージョン固定プラグインの例のように古いバージョンに留まり続ける仕組みが動いている可能性があります。WordPressの古いコアやプラグインは脆弱性の入口になり、改ざんやスパム踏み台のリスクが時間とともに積み上がります。

更新が上がらないのは、ほとんどの場合この記事の3系統のどれかです。順番に確認すれば原因は特定できますし、切り分けた上でなら、更新作業そのものは怖いものではありません。

まとめ｜切り分けの順番

1. 何度更新しても同じバージョンに戻る → バージョン固定プラグインと、データベースに残った固定設定を探す
2. コマンドやツールでエラーが出る → サーバー付属のWP-CLI・PHPのバージョンを確認し、新しい版を明示して実行する
3. 途中で失敗して止まる → 容量・権限・タイムアウトの環境要因を確認する
4. 着手前に2か所バックアップ＋ハッシュ照合で「戻せる状態」を作る
5. 更新後は記事数・REST・エラーログを数えて検証する

自社での切り分けが難しい場合や、引き継いだサイトの中身がブラックボックスになっている場合は、更新作業の代行や引き継ぎ調査から対応できます。「更新していいのか判断がつかない」段階のご相談でも大丈夫です。