「Allowed memory size of ... bytes exhausted」は、1回のリクエストで使えるPHPメモリの上限に達したために処理が止まったことを示すエラーです。上限を引き上げれば一時的には消えますが、メモリを大量に使っている処理が残っていると、データが増えたときやプラグインを追加したときに再発します。この記事では、上限値の正しい確認方法と応急処置を押さえたうえで、メモリを食っている原因を突き止め、上限を上げ続けなくても済む状態にする手順を説明します。
エラーメッセージの読み方
エラーは次のような形で表示・記録されます。
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2345- 268435456 bytes：その時点のメモリ上限です。134217728 なら128MB、268435456 なら256MB、41943040 なら40MBです。
- tried to allocate 20480 bytes：最後に確保しようとした量です。ここが小さい数字なら、少しずつ積み上がった結果、最後の一押しで上限を超えたことを意味します。
- in ... on line：上限を超えた瞬間に実行していたファイルです。
注意したいのは、最後のファイルが原因とは限らない点です。上の例のように wp-includes 内のファイルが出ていても、WordPress本体が悪いわけではなく、それまでに別のプラグインが大量のメモリを使っていた可能性が高いです。メッセージは「どこで限界に達したか」を示すだけで、「誰が使ったか」は別に調べる必要があります。
上限値は2段階で決まっている
WordPressのメモリ上限は、サーバー側のPHP設定と、WordPress側の定数の2つで決まります。
- PHPの memory_limit：php.ini などで設定されるサーバー側の上限です。
- WP_MEMORY_LIMIT：WordPressがフロント表示で使おうとする上限です。指定しなければ、通常のサイトで40MB、マルチサイトで64MBが使われます。
- WP_MAX_MEMORY_LIMIT：管理画面や画像処理など、重い処理のときに引き上げる上限です。指定しなければ256MBです。
WordPressは、PHPの memory_limit が WP_MEMORY_LIMIT より小さいときだけ、値を引き上げようとします。サーバー側で引き上げが禁止されていると、wp-config.php に書いても反映されません。現在の値は、管理画面の「ツール」→「サイトヘルス」→「情報」タブで確認できます。「サーバー」の項目にPHPのメモリ上限が、「WordPress 定数」の項目に WP_MEMORY_LIMIT と WP_MAX_MEMORY_LIMIT が表示されます。
まずは応急処置で表示を戻す
サイトが止まっていて調査もできない場合は、先に上限を上げて動く状態に戻します。作業前に wp-config.php のコピーを取ってください。
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );/* That's all, stop editing! */ の行より上に追記します。反映されない場合は、サーバーのコントロールパネルのPHP設定、または php.ini や .user.ini の memory_limit を変更します。どの方法が使えるかはサーバーによって違うため、サーバーのマニュアルで確認してください。
memory_limit = -1（無制限）にするのは避けてください。暴走した処理がサーバー全体のメモリを使い切り、ほかのサイトやデータベースまで止まる原因になります。ここで上げた値は「調査のための時間稼ぎ」と考え、次の手順で原因を探します。
メモリを食っている原因を突き止める
1. どの操作で起きるかを特定する
エラーが出る場面を書き出します。特定のページだけか、管理画面の特定の操作（画像のアップロード、投稿の保存、エクスポート、ある設定画面を開く）か、時間帯に関係なく発生するか、です。WP-Cronで動く定期処理が原因の場合は、誰も操作していない時間帯にエラーログが増えます。
あわせて wp-config.php でエラーログを有効にし、発生時刻と直前の警告を記録します。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );ログは wp-content/debug.log に出力されます。調査が終わったら WP_DEBUG を false に戻してください。
2. Query Monitor でメモリ使用量を見る
Query Monitor プラグインを有効にすると、管理バーにそのページの生成時間、ピークメモリ使用量、データベースクエリ数が表示されます。エラーにならない程度の重いページで、どのプラグインが多くのクエリを発行しているか、極端に大きな結果を返すクエリがないかを確認できます。1ページで数百件以上のクエリや、数千行を返すクエリがある場合は、それが有力な原因です。
3. プラグインとテーマを切り分ける
Health Check & Troubleshooting プラグインのトラブルシューティングモードを使うと、自分のログインセッションだけでプラグインを止め、標準テーマに切り替えた状態を確認できます。全プラグインを止めて症状が消えたら、1つずつ有効にして再発する組み合わせを探します。管理画面に入れない場合は、FTPで wp-content/plugins 内の該当フォルダ名を一時的に変えると、そのプラグインを止められます。
4. 自動読み込みオプションの肥大化を確認する
wp_options テーブルのうち、自動読み込み（autoload）が有効な行は、すべてのページ表示で毎回メモリに読み込まれます。削除済みプラグインの設定や、大きなキャッシュデータがここに溜まっていると、どのページでもメモリを消費します。最近のWordPressでは、サイトヘルスの「ステータス」に自動読み込みオプションが大きすぎるという警告が出ることがあります。
WP-CLIでは、次のコマンドで自動読み込みされるオプションをサイズの大きい順に20件確認できます。テーブルの接頭辞は wp db prefix で取得しています。WordPress 6.6以降は自動読み込みの値が on や auto-on などに変わったため、従来の yes とあわせて指定しています。
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM $(wp db prefix)options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY bytes DESC LIMIT 20;"見覚えのない大きなオプションがあっても、すぐに削除しないでください。名前の接頭辞から、どのプラグインのものかを調べ、そのプラグインが現役なら設定画面や作者の案内に従って整理します。削除する場合は、事前にデータベース全体のバックアップを取ります。
原因別の根本対策
大量データを一度に読み込むコード
テーマやプラグインのコードで、posts_per_page に -1 を指定して全投稿を一度に取得していると、記事数の増加とともにメモリ使用量が増え続けます。必要なのが投稿IDだけなら 'fields' => 'ids' を指定し、件数の多い処理はページを分けて少しずつ処理します。
$paged = 1;
do {
$query = new WP_Query( array(
'post_type' => 'post',
'posts_per_page' => 200,
'paged' => $paged,
'fields' => 'ids',
'no_found_rows' => false,
) );
foreach ( $query->posts as $post_id ) {
// 1件ずつの処理
}
$paged++;
} while ( $paged <= $query->max_num_pages );巨大な画像のアップロード
スマートフォンやカメラの高解像度画像をそのままアップロードすると、サムネイル生成時に大量のメモリを使います。WordPressは大きな画像を自動で縮小する仕組みを持っていますが、その縮小処理自体にもメモリが必要です。アップロード前にパソコン側で長辺2,000〜3,000ピクセル程度に縮小しておくと、エラーを避けやすくなります。
古い、または相性の悪いプラグイン
特定のプラグインを止めると直る場合は、まず最新版に更新します。改善しなければ、同じ機能を持つ軽いプラグインへの入れ替えや、作者への報告を検討します。機能が重複しているプラグイン（SEO、キャッシュ、セキュリティ系の併用など）も整理対象です。
終わらない処理（無限ループ・再帰）
フィルターの中で、同じフィルターを呼ぶ関数を実行していると、処理が終わらずにメモリを使い切ります。たとえば save_post のフック内で wp_update_post() を呼ぶと、保存のたびに同じフックが再実行されます。この場合は、処理の前に remove_action() でフックを外し、処理後に付け直します。
PHPのバージョンが古い
PHP 7系などの古いバージョンは、処理性能の面で新しいバージョンに劣るうえ、セキュリティ更新も終了しています（2026年10月現在、公式のサポートが続いているのはPHP 8系の新しいバージョンです）。テーマとプラグインの対応を確認したうえで、PHPを更新するのも有効な対策です。ただし、PHPの更新だけでメモリ不足が解消するとは限らないため、ここまでの原因調査と組み合わせて行います。
対策後の確認
原因に対処したら、応急処置で上げた上限を、サイトの規模に見合った値（多くのサイトでは256MB程度）に戻し、エラーが出ていた操作をもう一度試します。Query Monitor でピークメモリが下がっていること、debug.log に同じエラーが出ていないことを確認できれば完了です。
まとめ
- エラーメッセージのファイル名は「限界に達した場所」で、メモリを使った原因とは限りません。
- 上限はPHPの memory_limit と WP_MEMORY_LIMIT・WP_MAX_MEMORY_LIMIT の2段階で決まり、サイトヘルスの「情報」タブで現在値を確認できます。
- 上限の引き上げは応急処置にとどめ、Query Monitor、トラブルシューティングモード、自動読み込みオプションの確認で原因を特定します。
- 全件取得のコード、巨大画像、相性の悪いプラグイン、無限ループ、古いPHPなど、原因ごとに対策します。データベースを触る前にはバックアップを取ります。