2026年8月12日

Allowed memory size exhausted の直し方｜memory_limit・php_admin_value・WP_MEMORY_LIMIT のどれを変えるか

エラー・白い画面

「Fatal error: Allowed memory size of ... bytes exhausted」は、PHPの1リクエストあたりのメモリ上限（memory_limit）を超えたときに出るエラーです。直すには上限を引き上げるか、メモリを使いすぎている処理を特定して止めるかのどちらかですが、**WordPressの WP_MEMORY_LIMIT は現在のPHPの上限より大きいときにだけ引き上げる値で、サーバー側で固定された上限は越えられない**という関係を理解していないと、設定しても効かない状態にはまります。この記事では、3つの設定の関係を整理したうえで、確認方法、引き上げ手順、原因の特定方法を説明します。

エラーメッセージの数字を読む

エラーは次のような形で出ます。

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-content/plugins/example/inc/import.php on line 210

最初の数字が、エラーが起きた時点で有効だった memory_limit です。134217728バイトは128M、268435456バイトは256Mにあたります。「tried to allocate」の数字は最後に確保しようとした分だけで、必要な総量ではありません。上限を少し上げれば足りる、という意味ではない点に注意してください。

ファイルパスは「上限に達した瞬間に実行していた場所」です。そこが原因であることは多いものの、別の処理が大量にメモリを使った後で、たまたまそのファイルが最後の確保をしただけ、ということもあります。

似たメッセージに「Out of memory (allocated ...)」があります。こちらはPHPの上限ではなく、サーバー自体のメモリが足りずに確保できなかった状態なので、上限を上げると悪化します。サーバーのメモリ不足やOOM Killerの対策が必要です。

3つの設定の関係を整理する

memory_limit（PHPの設定）

PHPが1リクエストで使えるメモリの上限です。php.ini、PHP-FPMのプール設定、.user.ini、.htaccess（mod_phpの場合のみ）などで設定し、プログラムからは ini_set() で変更できます。ただし、PHP-FPMのプール設定で php_admin_value[memory_limit] を使って指定された値は、ini_set() で変更できません。最終的にPHPを止めるのはこの値です。

WP_MEMORY_LIMIT（WordPressの通常時の目標値）

WordPressが起動時に memory_limit をこの値まで引き上げようとする定数です。wp-config.php で定義しない場合の既定値は、シングルサイトで40M、マルチサイトで64Mです。

重要なのは、WordPressは**現在の memory_limit よりこの値が大きいときだけ** ini_set() で引き上げ、小さい場合は何もしないという点です。php.iniが512Mなら、WP_MEMORY_LIMIT を256Mにしても512Mのままで、下がりません。既定値の40Mが「WordPressは40Mしか使えない」という意味ではないのもこのためです。また、memory_limit が変更不可に固定されている環境では、WordPressは引き上げを行わず、WP_MEMORY_LIMIT にはその時点の値が入ります。

WP_MAX_MEMORY_LIMIT（重い処理のときの目標値）

管理画面や画像処理など、メモリを多く使う場面で wp_raise_memory_limit() が引き上げる上限です。既定値は256Mで、memory_limit がすでに256Mより大きい（または無制限の -1）場合はその値が使われます。

引き上げが行われる主な場面は次のとおりです。

管理画面（wp-admin）を、manage_options 権限を持つユーザー（通常は管理者）が開いたとき
画像の編集やサムネイル生成などの画像処理

管理画面であっても、編集者や投稿者が開いた場合はこの引き上げは行われず、WP_MEMORY_LIMIT までの値で動きます。「管理者では問題ないのに編集者だとエラーになる」という症状は、この違いで説明できることがあります。

まとめると、実際に効く上限は「サーバー側の memory_limit」と「WordPressが引き上げようとする値」の大きいほうで、ただしサーバー側で固定されていれば引き上げは効きません。

現在の値を確認する

いちばん確実なのは、Webサーバー経由で動くPHPの値を見ることです。管理画面の「ツール」→「サイトヘルス」→「情報」タブを開くと、「サーバー」の項目にPHPのメモリ上限が、「WordPress定数」の項目に WP_MEMORY_LIMIT と WP_MAX_MEMORY_LIMIT が表示されます。サイトヘルスは管理画面で動くため、管理者が見るとすでに引き上げ後の値になっていることがある点に注意してください。

WP-CLIでも確認できますが、WP-CLIはコマンドライン用のPHP（php-cli）で動き、Webとは別のphp.iniを読みます。CLIでは無制限（-1）になっていることも多く、Webの値とは一致しないことがあります。

# WordPressの定数（CLI上の値）
wp eval 'echo WP_MEMORY_LIMIT, " / ", WP_MAX_MEMORY_LIMIT, PHP_EOL;'

# PHP-FPM側の設定ファイルを確認（パスは環境で異なる）
grep -rn "memory_limit" /etc/php/8.3/fpm/

上のパスはUbuntuでPHP 8.3を使う場合の例です（2026年10月現在）。

上限を引き上げる

wp-config.phpで設定する

memory_limit が変更可能な環境では、wp-config.php の /* 編集が必要なのはここまでです */ より上に書きます。wp-settings.php の読み込みより後に書くと効きません。

define( 'WP_MEMORY_LIMIT', '256M' );      // フロントを含む通常のリクエスト
define( 'WP_MAX_MEMORY_LIMIT', '512M' );  // 管理者の管理画面・画像処理

設定後にエラーが出た操作をもう一度行い、解消するかを確認します。効かない場合は、サーバー側で上限が固定されているか、サーバー側の値より小さい値を書いている可能性があります。

php.iniやPHP-FPMの設定で引き上げる

VPSや専用サーバーなら、PHP-FPMが読むphp.ini、またはプール設定（例: /etc/php/8.3/fpm/pool.d/www.conf）を変更します。php-cli用とPHP-FPM用でphp.iniは別ファイルなので、編集するファイルを取り違えないようにしてください。

; php.ini の場合
memory_limit = 256M

; プール設定の場合（ini_set で変更できなくなる）
php_admin_value[memory_limit] = 256M

変更後は sudo systemctl reload php8.3-fpm などでPHP-FPMを再読み込みします。設定ファイルの変更前には元のファイルを控えておきます。

レンタルサーバーの場合

多くのレンタルサーバーでは、コントロールパネルのPHP設定画面で memory_limit を変更できます。PHPをCGI/FastCGIで動かしているサーバーでは、ドキュメントルートに置く .user.ini も使えます（反映まで数分かかることがあります）。.htaccess の php_value memory_limit はApacheのモジュール版PHPでしか使えず、それ以外の環境では500エラーの原因になるので、使う前にサーバーのマニュアルで対応を確認してください。

上げすぎない：上限はワーカーごとにかかる

memory_limit は1リクエスト（PHPのプロセス1つ）ごとの上限です。PHP-FPMの同時実行数（pm.max_children）が20で上限が512Mなら、最悪の場合は約10GBを使う計算になります。サーバーのメモリを超えるとスワップやOOM Killerによる強制終了が起き、サイト全体が不安定になります。

-1（無制限）にするのは、原因の調査中に一時的に使う場合に限ってください。通常は256M程度で足り、それでも足りない処理は、上限を上げるより処理の書き方を見直すほうが効果的です。

メモリを使いすぎている原因を特定する

上限を上げてもエラーが消えない、または512Mでも足りない場合は、無限ループや大量データの一括読み込みを疑います。

エラーメッセージのファイルパスで、プラグインやテーマの見当をつける
wp-config.php に WP_DEBUG と WP_DEBUG_LOG を設定し、wp-content/debug.log に記録されたエラーの発生場所と頻度を見る
Query Monitorプラグインで、ページごとのピークメモリ使用量を確認する
怪しいプラグインを1つずつ無効化し、エラーが消えるかを見る

よくある原因は次のとおりです。

save_post などのフックの中で wp_update_post() を呼び、フックが再帰的に呼ばれ続ける
posts_per_page を -1 にして全件を取得する処理。IDだけが必要なら 'fields' => 'ids' を指定し、件数が多ければページ分けして処理する
大きな画像のアップロード。WordPressは長辺が2560pxを超える画像を縮小して扱いますが、元画像の読み込みにはメモリが必要です
インポートやバックアップのプラグインで、大量データを一度に処理している

大量データの処理は、ブラウザから実行するよりWP-CLIで行うと、Webのタイムアウトや上限の影響を受けにくくなります。

管理画面に入れなくなった場合

WordPress 5.2以降では、致命的なエラーが起きると「このサイトで重大なエラーが発生しました」と表示され、サイト管理者のメールアドレスにリカバリーモードのリンクが届きます。リンクからログインすると、原因のプラグインを一時停止した状態で管理画面を操作できます。メールが届かない場合は、FTPやファイルマネージャーで該当プラグインのフォルダ名を変更すると、そのプラグインが読み込まれなくなります。

まとめ

エラーの最初の数字は、その時点で有効な memory_limit。tried to allocate の数字は必要量ではない
WP_MEMORY_LIMIT はPHPの上限より大きいときだけ引き上げる値で、下げる働きはない。既定値はシングルサイトで40M
WP_MAX_MEMORY_LIMIT は管理者の管理画面と画像処理で使われ、既定値は256M
サーバー側で php_admin_value などにより固定されていると、wp-config.php の設定は効かない
上限はPHPのプロセスごとにかかるため、上げすぎずに原因の処理を特定する