エラーの内容
WordPressがリクエストの途中でクラッシュし、次のエラーが表示されます:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wp-query.php on line 3492
この数値「134217728 bytes」はちょうど128 MBです。PHPが上限に達してプロセスを強制終了しました。プラグインを有効化した後、WooCommerceのチェックアウト実行時、10,000行のCSVのインポート中、または重いコードパスを追加したプラグインの大型アップデート直後によく発生します。
原因
PHPはプロセスごとにメモリの上限を強制します。WordPressはデフォルトで40 MBを要求します。多くの共有ホスティングではmemory_limitを64〜128 MBに設定しています。プラグインやテーマがその上限を超えた瞬間にクラッシュします。
よくある原因:
- 5つ以上の拡張機能を同時に読み込んだWooCommerce
- 複雑なレイアウトと多数のネストされたウィジェットをレンダリングするページビルダー(Elementor、Divi)
- 一括操作:投稿のインポート、サムネイルの再生成、スケジュールされたcronジョブの実行
- プラグインの最新アップデートで導入されたメモリリーク
修正方法
方法1:wp-config.php(最速、ほとんどのホストで有効)
wp-config.phpを開き、/* That's all, stop editing! */コメントの前に以下を追加します:
define( 'WP_MEMORY_LIMIT', '256M' );
wp-adminでもエラーが発生している場合は、管理者用のメモリ制限も追加します:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
重要な注意点:この設定はPHP自身のmemory_limitの範囲内でしか機能しません。PHPが128 MBに制限されている場合、ここにどんな値を設定してもWordPressはそれ以上使用できません。
方法2:php.ini
直接的なアプローチ — PHP自体の上限を変更します。
memory_limit = 256M
VPSや専用サーバーでは/etc/php/8.1/fpm/php.iniを編集します(パスのバージョン番号を適宜変更してください)。共有ホスティングの場合は、wp-config.phpと同じWordPressルートディレクトリにphp.iniファイルを配置します。ホストによってはpublic_htmlまたはホームディレクトリを参照する場合もあります。
保存後、該当するサービスを再起動します:
# PHP-FPM
sudo systemctl restart php8.1-fpm
# mod_phpを使うApache
sudo systemctl restart apache2
方法3:.htaccess(Apacheのみ)
WordPressの.htaccessに1行追加します:
php_value memory_limit 256M
Apache + mod_phpで有効です。NginxやPHP-FPMでは、このディレクティブは無視されます — その場合は代わりにphp.iniを使用してください。
方法4:WP-CLI(変更前に診断する)
実際に適用されている制限を確認します:
# WordPressが使用できると認識している値
wp eval 'echo WP_MEMORY_LIMIT;'
# PHPが実際に許可している値
wp eval 'echo ini_get("memory_limit");'
この2つの数値が異なる場合 — たとえばWordPressが256Mを期待しているのにPHPが128Mと報告する場合 — PHPの上限を引き上げるために方法2が必要です。wp-config.phpの編集だけでは不十分です。
方法5:cPanel / Plesk GUI
マネージドホスティングでは、ファイル編集をまったく行わずに設定できます:
- cPanel:MultiPHP INI Editor → PHPバージョンを選択 →
memory_limitを設定 - Plesk:ドメイン → PHP設定 →
memory_limit - Kinsta / WP Engine / Flywheel:サポートに連絡してください。インフラレベルでPHPを管理しており、制限を引き上げてもらえます。
推奨値は?
- 256M:ほとんどのWordPressサイトに適した標準値
- 512M:10以上の拡張機能を同時実行するWooCommerceストア
- 1024M:一括インポートやサムネイル再生成時のみ — 一時的に引き上げて、完了後は元に戻す
本番環境で-1(無制限)に設定したい衝動を抑えてください。メモリリークのあるプラグインが1つあるだけで、サーバーのRAMがすべて消費されてしまいます。
確認方法
wp-content/check-memory.phpに一時ファイルを作成します:
<?php
echo 'PHPのmemory_limit: ' . ini_get('memory_limit') . "\n";
echo 'WP_MEMORY_LIMIT: ' . WP_MEMORY_LIMIT . "\n";
ブラウザで読み込み、設定した値と一致することを確認したら、すぐに削除してください。デバッグファイルを公開ディレクトリに残すことは、深刻なセキュリティリスクになります。
WP-CLIを使う場合は、1つのコマンドで同じことができます:
wp eval 'echo "PHP: " . ini_get("memory_limit") . " | WP: " . WP_MEMORY_LIMIT;'
次に、元のエラーを引き起こした操作を実行します — プラグインを有効化し、インポートを実行し、問題のあるページをリロードします。致命的なエラーが出なければ完了です。
メモリを増やしても解決しない場合
512Mにしてもクラッシュが続く場合は、上限の問題ではなくメモリリークを抱えています。
- すべてのプラグインを無効化します。エラーが再発するまで1つずつ有効化していきます — それが問題のプラグインです。
- エラーメッセージのファイルパスをよく読んでください。多くの場合、問題のあるプラグインのコードを直接指しています。
- 最後のアップデート以降の既知のメモリ問題について、プラグインのバグトラッカーや変更履歴を確認します。
WP_DEBUG_LOGが有効になっている場合はwp-content/debug.logも確認してください。同じファイルパスが何十回も繰り返されていますか?それがリークです。
予防策
- すべての新しいWordPressインストールで
WP_MEMORY_LIMITを256Mに設定する — クラッシュを待たないこと - Query Monitorをインストールし、各プラグインアップデート後のメモリ使用量を監視する
- サイトごとにページビルダーは1つに絞る。同じインストールにElementorとDiviの両方を使うのはトラブルを招きます。
- VPS/専用サーバーでは、サイトごとにPHP-FPMプール制限を設定する — 重いサイトが他のサイトのリソースを奪わないようにする

