WordPressで「別の更新が現在進行中です」と出る時の安全な直し方

WordPress本体を更新しようとして「別の更新が現在進行中です」と表示された時は、すぐにデータベースを編集してはいけません。
先に実行中の更新が本当に残っていないか確認し、通常は15分以上待つのが安全な初動です。

このメッセージは故障そのものではなく、複数の本体更新が同時に走ってファイルを壊さないための保護機能です。
ただし、通信切断やPHP停止のあとに更新ロックだけが残ると、処理が終わっているのに次の更新を始められません。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。更新エラーは、ロックを消す操作より「まだ動いていないと証明する確認」が重要です。

この記事では、WordPress本体の更新で使われる core_updater.lock を中心に、待機、証拠保存、切り分け、解除、再実行の順で解説します。
プラグインやテーマの更新失敗、メンテナンス表示が残る問題とは、途中まで原因が共通していても確認対象が異なります。

公開サイトが正常に見えていても、別の管理者、自動更新、サーバー側の定期処理が動いている場合があります。
「画面が止まったから更新も止まった」と決めつけず、時刻とログを確かめてから操作してください。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPress「別の更新が現在進行中です」の意味を確認する

結論から言うと、この表示はWordPress本体の同時更新を防ぐためのロックが存在する合図です。
まずエラーを消そうとせず、保護機能が正常に働いている可能性を前提に状況を確認します。

WordPress本体の同時更新を防ぐロック

WordPressは本体更新を開始する前に、データベースへ更新中を示す値を保存します。
別の画面や処理が同時に本体ファイルを書き換えようとした場合、その値を見て後から来た更新を停止します。

本体更新では多数のPHPファイルを一時的に展開し、古いファイルと入れ替えます。同時処理が走ると、片方が削除したファイルをもう片方が参照するなど、更新前より深刻な状態になり得ます。

そのため「別の更新が現在進行中です」は、異常を知らせるだけの文ではありません。
ファイルの競合を避けるために次の処理を止めた、安全装置のメッセージでもあります。

core_updater.lockは時刻を持つデータ

WordPress本体の更新ロックは、通常 core_updater.lock というオプション名で保存されます。値にはロックを作成した時刻が入り、一定時間を過ぎた古いロックは再利用されない設計です。

WordPressコアでは、本体更新のロック時間として15分が使われます。
更新開始から数分しか経っていないなら、管理画面を閉じたりデータベースを触ったりせず、処理の完了を待つ判断が基本です。

15分以内なら解除より待機を優先する

管理画面で更新ボタンを押した直後、別タブを開いてもう一度更新した場合は、最初の処理が続いている可能性が高いです。
この段階でロックを削除すると、意図的に設けられた排他制御を外すことになります。

画面が白い、ブラウザが応答しない、通信が切れたという理由だけでは、サーバー側のPHP処理が終了したとは判断できません。
ブラウザとの接続が切れても、サーバーではダウンロードや展開が続く場合があります。

WordPressの自動更新は有効にする？本体・テーマ・プラグイン別の判断基準

WordPress更新ロックを消す前に証拠とバックアップを残す

更新ロックを解除する前には、発生時刻、直前の操作、現在の表示、サーバーログを残し、ファイルとデータベースを保全します。
ロック削除自体は小さな変更でも、その後に本体更新を再実行するため、戻せる状態が必要です。

エラー時刻と直前の更新操作を記録する

まず「別の更新が現在進行中です」と表示された時刻と、最初に更新を開始した時刻を記録します。
管理者が複数いる場合は、同じ時間帯に本体・テーマ・プラグイン更新をした人がいないか確認してください。

自動更新の通知メール、ホスティング会社の自動アップデート履歴、保守サービスの作業履歴も確認対象です。
人が操作していなくても、バックグラウンド更新が先にロックを取得していることがあります。

公開画面と管理画面の状態を分けて保存する

公開トップ、代表的な投稿、ログイン画面、管理画面、更新画面を別々に確認します。
公開画面が200で表示されても、管理画面だけが停止している場合や、メンテナンス表示が一部キャッシュに残る場合があります。

サーバーのエラーログには、更新開始時刻の前後を絞って、Fatal error、タイムアウト、メモリ不足、ディスク容量不足がないか確認します。
全ログを無計画に削除したり、確認前にログローテーションを実行したりしないことが大切です。

バージョンアップで壊れたWordPress不具合を直す！アップデート前後のトラブル対策まとめ

ファイルとデータベースを同じ時点で保全する

バックアップはWordPressファイルだけでなく、データベースも同じ時点で保存します。
本体更新ではファイルが中心に変わりますが、更新後にデータベース更新画面が表示される版もあるため、片方だけでは十分ではありません。

ホスティング会社の自動バックアップがある場合も、取得時刻、保存対象、保持期限、復元方法を確認します。更新失敗後に作られたバックアップだけでは、更新前へ戻せないことがあります。

WordPress更新が本当に止まっているか切り分ける

15分以上経過しても表示が変わらない時は、更新ロックだけが残ったと決めつけず、実行中プロセスと失敗原因を切り分けます。
解除後に同じ障害を繰り返さないため、止まった理由まで確認するのが正解です。

別タブ・別管理者・自動更新を確認する

自分のブラウザで更新タブを閉じていても、別タブや別端末で更新画面が開いたままになっていないか確認します。
複数の管理者がいるサイトでは、連絡せずにロックを消すと、他の人の正常な更新へ二重処理を重ねる危険があります。

WordPressの更新通知メール、管理画面の「更新」、ホスティング管理画面の履歴を時系列に並べます。自動更新が始まった直後なら、サーバー負荷や配布元通信によって通常より時間がかかっている可能性があります。

サーバーのPHP処理と更新ログを確認する

VPSや専用サーバーでプロセスを確認できる場合は、更新開始時刻から継続しているPHP、WP-CLI、cronの処理がないか調べます。
共有サーバーでは、無理にコマンドを追加せず、プロセス一覧やアクセスログなど提供されている機能を使います。

更新中のアクセスが続いているなら、ロックを削除せず完了を待ちます。逆に、15分以上前から更新関連のアクセスがなく、PHPエラーで処理が終了しているなら、取り残されたロックの可能性が高まります。

容量・権限・通信失敗を先に直す

更新ロックが残った原因として、ディスク容量不足、PHPの実行時間超過、メモリ不足、ファイル権限、配布元への通信失敗があります。
ロックだけを消しても原因が残っていれば、再実行時に同じ場所で停止します。

サーバー容量は合計だけでなく、WordPressの設置先、一時ディレクトリ、バックアップ保存先を分けて確認します。inode上限に達している場合は、空き容量が表示されていても新しいファイルを作れません。

権限を確認する時は、サイト全体を一律777へ変更しないでください。所有者とWebサーバー実行ユーザーの関係を確認し、ホスティング会社が推奨する値へ戻すことが必要です。

WordPressのステージング環境とは？本番更新前に使うべきケースと注意点

WordPress「別の更新が進行中」を安全に解除する

更新処理が終了しており、15分以上経過し、バックアップも確保できた場合だけ、古い core_updater.lock を確認して解除します。
方法はWP-CLIを優先し、利用できない場合にデータベース管理画面を使います。

WP-CLIでロックの値を確認する

SSHとWP-CLIを安全に利用できる環境では、最初にWordPressの設置先へ移動し、URLと本体バージョンを確認します。
対象サイトが正しいことを確認してから、ロックの値を読み取ります。

wp option get siteurl
wp core version
wp option get core_updater.lock

値が表示された場合は、その時刻と更新開始時刻を照合します。
「Error: Could not get ‘core_updater.lock’ option.」のように値が存在しない場合は、すでにロックが失効または削除されているため、削除コマンドを重ねる必要はありません。

停止を確認してからWP-CLIで削除する

実行中の更新がなく、15分以上前の古いロックだと確認できたら、対象サイトで次のコマンドを1回だけ実行します。
成功後は同じ値を再取得し、存在しないことを確認します。

wp option delete core_updater.lock
wp option get core_updater.lock

wp transient delete --all や wp cache flush を同時に実行する必要はありません。変更を一つに絞れば、解除後に問題が起きても原因を追いやすくなります。

データベースでは対象行だけを扱う

WP-CLIを使えない場合は、phpMyAdminなどでWordPressデータベースを開きます。
最初に wp-config.php のデータベース名とテーブル接頭辞を確認し、別サイトのデータベースを触らないようにします。

SELECT option_name, option_value
FROM wp_options
WHERE option_name = 'core_updater.lock';

wp_options の wp_ は初期値です。接頭辞を変更しているサイトでは、実際のテーブル名へ読み替えます。
検索結果が1行だけで、値と時刻が古いことを確認してから、その行だけを削除します。

DELETE FROM wp_options
WHERE option_name = 'core_updater.lock';

SQLを実行する前に、対象行のエクスポートまたはデータベース全体のバックアップを残します。
option_idを見ずに広い条件で削除したり、更新関連らしい名前をまとめて消したりしないでください。

WordPress更新ロック解除後に再実行する

ロック解除後は、すぐに複数の更新をまとめて実行せず、WordPress本体だけを一度再実行します。
更新前の原因を直し、監視できる状態で小さく試すことが安全です。

同じ失敗原因を直してから再更新する

エラーログにメモリ不足やタイムアウトがあれば、ホスティング会社の推奨範囲で設定を見直します。容量不足なら、不要な古いバックアップやログを内容確認後に退避し、一時展開に必要な余裕を確保します。

配布元との通信失敗がある場合は、WordPress.orgへのHTTPS通信、DNS、プロキシ、WAF、外向き通信制限を確認します。
証明書検証を無効化して通す方法は、更新パッケージの安全性を損なうため避けてください。

ファイル所有者や権限に問題がある場合は、サーバー仕様に合わせて修正します。すべてのファイルを一括で書き込み可能にする対処は、更新後の侵入リスクを高めます。

ステージングまたは保守時間帯で本体だけ更新する

本番と同じ構成のステージングを用意できるなら、先に同じ更新を試します。
本体、PHP、テーマ、プラグインの互換性を確認し、更新後の管理画面と主要機能まで動くことを確かめます。

本番で再実行する場合は、問い合わせや購入が少ない時間帯を選び、他の管理者へ更新開始を共有します。自動更新やバックアップと時間が重ならないよう、スケジュールも確認してください。

更新画面は一つだけ開き、完了表示が出るまで別タブで更新操作をしません。
進捗が止まったように見えても、決めた待機時間とログ確認を優先し、ボタン連打を避けます。

WordPressデータベースアップデートに失敗した時の原因と解決方法【完全ガイド】

表示・管理画面・ログを確認して完了する

更新完了後は、公開トップ、代表記事、ログイン、管理画面、投稿編集、メディア画面を確認します。
外見だけでなく、問い合わせフォーム、検索、会員、決済など、サイト固有の重要機能も試してください。

「データベースの更新が必要です」と表示された場合は、URLとWordPressバージョンを確認し、バックアップがある状態で一度だけ実行します。画面を何度も再読み込みしたり、別の版のファイルへ戻したりしないことが重要です。

サーバーログに新しいFatal errorがなく、core_updater.lock が残っておらず、管理画面のWordPressバージョンが予定どおりなら更新完了です。確認結果と時刻を作業記録へ残します。

WordPress更新ロックの再発を防ぐ

再発防止では、更新担当と時間帯を決め、同時操作を起こさない運用を作ることが最も効果的です。
サーバー性能だけを上げても、手動更新と自動更新が重なればロックは正常に作られます。

更新担当・対象・時間帯を一つにする

複数管理者がいるサイトでは、更新前にチャットや作業表へ開始時刻、対象、担当者を書きます。
本体更新中はテーマやプラグイン更新を始めず、完了確認後に次の作業へ進むルールが必要です。

自動更新を有効にする範囲も決めます。本体のマイナー更新、メジャー更新、テーマ、プラグインを同じ考え方で一括設定せず、復元可能性と影響度に応じて分けてください。

更新前点検を定型化する

更新前には、バックアップ成功、空き容量、PHP互換性、ステージング結果、外部サービス障害を確認します。
毎回同じチェックリストを使えば、担当者が変わっても判断基準を保てます。

更新対象が多い場合は、一括選択より小分けにします。どの更新で停止したか分かりやすく、問題が起きた時の切り戻し範囲も小さくできます。

長期間更新していないサイトは、本番で一気に最新版へ上げないでください。中間版、PHP要件、データベース更新、古いテーマやプラグインの互換性を調べ、ステージングで順序を決めます。

更新後の監視と記録を残す

更新完了時刻、変更前後のバージョン、担当者、確認URL、ログ結果を記録します。
次回同じメッセージが出た時に、正常な所要時間と比較できるため、待つべきか調査へ進むべきか判断しやすくなります。

ワードプレスレスキューとは？復旧依頼前の確認点

WordPress更新中エラーのよくある質問

WordPress更新ロックは待機・確認・限定解除の順で直す

「別の更新が現在進行中です」と表示された時は、ロックをすぐ削除するのではなく、まず15分以上待ちます。
次に別管理者、自動更新、PHP処理、ログ、容量、権限を確認し、本当に更新が止まったと判断できた場合だけ古いロックを解除します。

解除方法は、対象サイトを確認しやすいWP-CLIを優先します。データベースを直接扱う場合は、接頭辞と対象行を確かめ、バックアップ後に core_updater.lock だけを削除してください。

更新ロックは、WordPressを守るための仕組みです。消すことを目的にせず、なぜ残ったのかを確認し、戻せる状態で一つずつ作業すれば、更新事故の拡大を防げます。

WordPress更新トラブルが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で