2026年10月12日

WordPressのダッシュボードで「メモリ不足」エラーが繰り返し出る原因と対処法

エラー・白い画面

管理画面（ダッシュボード）だけでメモリ不足のエラーが何度も出る場合、多くは「管理画面用のメモリ上限」が低いか、管理画面で重い処理を繰り返すプラグインがあることが原因です。上限を上げるだけで収まることもありますが、繰り返し出るなら、どのリクエストが何にメモリを使っているかを突き止めないと再発します。この記事では、エラーの読み方、管理画面とフロントでメモリ上限が別に決まる仕組み、原因を可能性の高い順に確かめて直す手順を説明します。

まずエラーの正体を確認する

「メモリが不足しています」という日本語の表示は、WordPress本体の文言ではなく、ホスティングの管理画面やプラグインが出している場合があります。原因を調べるには、PHPが出している元のメッセージを見ます。典型的なのは次のような1行です。

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2345

読み方のポイントは3つあります。

268435456 bytes は、そのリクエストに許されていた上限（この例では256MB）です。上限を上げたつもりでもこの数字が変わっていなければ、設定が効いていません。
tried to allocate は「最後にあと少し確保しようとして失敗した量」で、原因の大きさではありません。
in …ファイル名 は、メモリが尽きた瞬間に動いていた場所です。データベース処理のファイルが出ていても、wpdb が悪いわけではなく、大量のデータを読み込ませた呼び出し元が別にいることがほとんどです。

画面に何も出ない場合は、wp-config.php でログを有効にして wp-content/debug.log を確認します。WordPress 5.2以降は致命的エラーが起きると「重大なエラーが発生しました」といった案内（文言はバージョンで異なります）が表示され、管理者にリカバリーモードのメールが届くことがあります。このメールにもエラーの場所が書かれています。

// wp-config.php の「編集が必要なのはここまでです」より上に追記
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

原因が分かったら WP_DEBUG は false に戻してください。debug.log は外部から読まれないよう、調査後に削除するか、Webサーバーの設定でアクセスを拒否しておきます。

管理画面とフロントでメモリ上限が違う理由

WordPressには、メモリ上限に関わる定数が2つあります。

WP_MEMORY_LIMIT：通常のページ表示で使う上限。既定はシングルサイトで40M、マルチサイトで64Mです。
WP_MAX_MEMORY_LIMIT：管理画面で使う上限。既定は256Mです。

管理画面を開くと、WordPressは wp_raise_memory_limit( 'admin' ) を呼び、PHPの memory_limit を WP_MAX_MEMORY_LIMIT まで引き上げようとします（この値は admin_memory_limit フィルターでも変えられます）。ただし、引き上げは「現在の値より大きいとき」で、かつサーバーが ini_set による変更を許している場合に限られます。ホスティングによっては php.ini やコントロールパネル側で上限が固定されていて、wp-config.php で何を書いても効きません。

今の実際の値は、管理画面の「ツール」→「サイトヘルス」→「情報」タブで確認できます。「サーバー」の項目にPHPのメモリ上限、「WordPress 定数」の項目に WP_MEMORY_LIMIT と WP_MAX_MEMORY_LIMIT が並んでいます（項目名はバージョンで多少変わります）。

原因1：管理画面用の上限が低い、または効いていない

最初に確かめるのは、エラーメッセージの上限値と、サイトヘルスに出ている値が一致しているかです。たとえばエラーが 134217728 bytes（128MB）で止まっているなら、管理画面でも128MBまでしか使えていません。

確認と対処は次の順で進めます。

wp-config.php に WP_MAX_MEMORY_LIMIT が小さい値で書かれていないか確認します。古い高速化記事を参考に低い値を入れたままになっていることがあります。
必要なら値を上げます。むやみに大きくせず、まずは256M〜512Mの範囲で試します。
書き換えてもエラーの上限値が変わらない場合は、サーバー側で固定されています。ホスティングのコントロールパネルにPHP設定の画面があればそこで変更し、無ければサポートに上限を確認します。

// wp-config.php（「編集が必要なのはここまでです」より上）
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

上限を上げてエラーが消えても、それで終わりにしないでください。管理画面で512MBを使い切るような処理は、どこかに無駄があるサインです。以下の原因も確認しておくと再発を防げます。

原因2：特定のプラグインが管理画面で重い処理をしている

ダッシュボードを開くたびに出る場合、ダッシュボードウィジェットが疑わしい候補です。アクセス解析、SEO、セキュリティ系のプラグインは、集計結果をウィジェットに表示するために大量のデータを読み込むことがあります。

切り分けには Query Monitor プラグインが便利です。管理バーに、そのページのピークメモリ使用量、実行されたクエリ、どのプラグインが時間を使ったかが表示されます。エラーで画面が開けない場合は、上限を一時的に上げて画面を出してから計測します。

プラグインを順に無効化して比べる方法も確実性が高いです。本番で試すとサイトの機能が止まるため、ステージング環境（本番の複製）で行います。管理画面に入れないときは、FTPやファイルマネージャーで wp-content/plugins 内の該当フォルダ名を変えると、そのプラグインだけ無効になります。

原因のウィジェットが分かり、プラグイン自体は使い続けたい場合は、ウィジェットだけを外す方法があります。ウィジェットのIDは、ブラウザの開発者ツールでウィジェットの要素を調べると id 属性で分かります。

// 子テーマの functions.php または mu-plugin に追加
add_action( 'wp_dashboard_setup', function () {
	// 'example_stats_widget' は実際のウィジェットIDに置き換える
	remove_meta_box( 'example_stats_widget', 'dashboard', 'normal' );
} );

あわせて、プラグインを最新版に更新し、作者のサポートフォーラムで同じ報告が無いか確認します。

原因3：数十秒おきの通信で繰り返し発生している

エラーが「画面を開いた時」ではなく、開いたまま放置していても一定間隔でログに出る場合は、Heartbeat API による定期通信（admin-ajax.php へのリクエスト）が関係している可能性があります。Heartbeat は投稿のロックや自動保存、ログイン状態の確認に使われ、プラグインもこの通信に処理を追加できます。追加された処理が重いと、通信のたびにメモリ不足になります。

debug.log や Query Monitor で admin-ajax.php のリクエストに注目し、該当するプラグインを特定するのが本来の対処です。応急処置として間隔を延ばすこともできます。

// 子テーマの functions.php または mu-plugin に追加
add_filter( 'heartbeat_settings', function ( $settings ) {
	$settings['interval'] = 60; // 秒。15〜120の範囲で指定する
	return $settings;
} );

Heartbeat をすべて止める設定は、投稿の同時編集の警告や自動保存に影響するため、おすすめしません。

原因4：自動読み込みのオプションが肥大化している

WordPressは、ページを開くたびに wp_options テーブルのうち自動読み込み（autoload）の指定があるデータをまとめてメモリに読み込みます。削除済みプラグインの設定やキャッシュ用のデータがここに溜まると、管理画面に限らず毎回メモリを圧迫します。WordPress 6.6以降のサイトヘルスには、自動読み込みのデータが大きすぎる場合に知らせる項目があります。

WP-CLIが使える環境では、合計サイズを確認できます。

# 自動読み込みオプションの合計サイズ（バイト）
wp option list --autoload=on --format=total_bytes

WordPress 6.6で autoload 列の値の種類が増えたため、WP-CLIのバージョンによっては集計に含まれない値があります。気になる場合はWP-CLIを更新するか、データベースで option_value の長さが大きいものから確認します。不要な行を消す前には、データベースのバックアップを取ってください。どのプラグインのデータか分からないものは削除せず、オプション名でプラグインを特定してから判断します。

原因5：一覧画面の表示件数や処理対象が多すぎる

投稿一覧、コメント一覧、WooCommerceの注文一覧などで「表示件数」を数百件に設定していると、その画面を開くたびに大量のデータを読み込みます。画面右上の「表示オプション」で件数を戻すと収まることがあります。インポート、一括編集、画像の再生成など、大量のデータを一度に扱う操作も同様です。こうした作業は、可能ならWP-CLIなどブラウザを介さない方法で、分割して実行します。

サーバー全体のメモリ不足と区別する

ここまでの話は「PHPの1リクエストあたりの上限」の問題です。これとは別に、サーバー自体のメモリが足りずにPHPのプロセスが強制終了される場合があります。その場合は Allowed memory size のメッセージは出ず、502や503のエラー、あるいは何も表示されない状態になります。VPSでは、OSのログにメモリ不足でプロセスを止めた記録が残ります。PHPの上限を上げすぎると、同時アクセス時にこちらの問題を招くため、上限の引き上げとサーバーの搭載メモリは合わせて考えます。

なお、各画面の項目名やサイトヘルスの表示内容は、WordPressのバージョンによって変わることがあります（2026年10月現在）。

まとめ

まずPHPの元のエラーを読み、上限値（bytes）が想定どおりかを確認します。エラーに出たファイルは「尽きた場所」で、原因とは限りません。
管理画面は WP_MAX_MEMORY_LIMIT、フロントは WP_MEMORY_LIMIT で上限が決まります。サーバー側で固定されていると wp-config.php の設定は効きません。
繰り返し出る場合は、ダッシュボードウィジェット、Heartbeat の通信、自動読み込みオプションの肥大化を疑い、Query Monitor やステージングでの切り分けで原因を特定します。
設定変更やデータ削除の前にはバックアップを取り、コードは子テーマか mu-plugin に入れます。