WordPressのメモリ上限（memory_limit）とは？不足エラーの原因・確認・増やし方

WordPressでプラグイン更新、画像変換、バックアップ、インポートをした時だけ500エラーになる場合、PHPメモリ不足が候補になります。ただし「memory_limitを256MBにすれば解決」と決め打ちすると、メモリリークや異常なクエリを見逃します。

WordPressのメモリ上限は3層で考える

WordPress公式ドキュメントでは、WP_MEMORY_LIMITとWP_MAX_MEMORY_LIMITを使えます。ただしホスティング事業者がPHP上限を固定している場合、WordPress側だけ書き換えても超えられません。

WordPressの標準メモリ値を先に知る

WordPressはPHP側の上限を無視して無限にメモリを増やせるわけではありません。WP_MEMORY_LIMITを512Mにしても、ホスト側がそれより低い値へ固定していれば反映されない場合があります。まず「WordPressが要求する値」と「PHPが許可する値」を分けます。

memory_limitを確認する場所

レンタルサーバーではPHP設定画面、phpinfo、サイトヘルス、エラーログなどから現在値を確認できます。WordPress側でWP_MEMORY_LIMITを書いていても、PHP側のmemory_limitがそれより小さければ実際に使える上限はそこで止まります。逆にPHP側が大きくても、WordPress通常処理には独自の上限が使われます。

数値だけを比較しない

256MBと512MBを比べて「512MBの方が高性能」とは限りません。1リクエストが何MB使うか、同時に何リクエスト走るか、PHP-FPMや共有サーバーの制御がどうなっているかで全体の余力は変わります。WordPress管理画面に表示される1つの数字は、サーバー全体のRAM容量そのものではありません。

メモリ不足の典型症状

• プラグイン更新時だけ500エラー
• 高解像度画像のアップロードや変換で停止
• バックアップZIP作成が途中で落ちる
• 大量記事インポート・エクスポートで失敗
• 管理画面の特定ページだけ白画面

最初にやる診断

1. エラーメッセージのバイト数を読む

Allowed memory size of ... bytes exhaustedが出ているなら、メモリ不足の根拠があります。単に500だけの場合はPHP fatal error、WAF、タイムアウトなど別原因もあるため、サーバーのPHPエラーログを確認します。

2. 直前の変更を確認する

メモリ不足は「常に容量が少ない」だけでなく、新しいプラグイン、バックアップ設定、画像サイズ、大量処理が引き金になります。発生日時と直前変更を紐づけると原因を絞りやすくなります。

3. 一時的に上限を上げても再発を見る

上限変更で直った場合も、それが恒久対策とは限りません。同じ操作を数回繰り返し、ピークメモリと処理時間が増え続けていないかを見ます。

症状別の切り分け例

画像アップロードだけ失敗

スマホ写真や高解像度PNGでだけ落ちる場合、画像デコード・リサイズで一時的に大きなメモリを使います。アップロード前に画像寸法を縮小し、それで安定するなら恒久的にmemory_limitを上げる前に運用側で解決できる可能性があります。

バックアップだけ失敗

巨大ZIP作成、DBダンプ、暗号化などが重い場合があります。バックアップを分割する、ファイルとDBを分ける、サーバー標準バックアップへ役割を移す方法も検討します。バックアップのために本番の通常処理まで高いmemory_limitへ固定する必要はありません。

管理画面の一括処理で失敗

画像最適化、SEO再計算、記事一括更新などは大量データを一度に読み込みやすい処理です。バッチサイズを小さくする設定があるなら先に使います。メモリ不足が「データ量×一括件数」で再現するなら、処理分割が本命です。

メモリ不足を再現して原因を切り分ける

エラーが毎回出ない場合は、再現条件をメモします。何枚の画像をアップしたか、どのプラグイン更新時か、バックアップ容量はいくつか、同時にCronが動いていなかったかまで残します。同じ操作でだけ再現するなら、WordPress全体の上限不足よりその処理固有の負荷を疑えます。

メモリ不足とタイムアウトを混同しない

画面が途中で止まるとすべてメモリ不足に見えますが、max_execution_time、外部API timeout、DB lock、WAF、Cronの重複でも似た症状が出ます。エラーログにmemory exhaustedがないなら、推測で上限を変えず実際のエラー種別を確認します。

wp-config.phpで設定する時の考え方

WordPress公式にはWP_MEMORY_LIMITとWP_MAX_MEMORY_LIMITの指定例があります。実際の値はサイト規模、プラグイン、ホスト側制限で変わるため、TameshiTechでは特定の数値を万能な正解として固定しません。

変更する場合は、バックアップを取得し、設定ファイルの記述位置を守り、変更前の値を記録します。設定後はサイトヘルスやphpinfo相当の管理画面で、実際に反映された上限を確認してください。

設定するならコードは最小限にする

必要性を確認した上でwp-config.phpへ指定する場合は、既存定義を重複させず、wp-settings.phpが読み込まれる前に置きます。

define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

上の数値は「全サイトの推奨値」ではなく記述例です。実際にはホスティング側の上限、サイト規模、画像処理、プラグイン構成を見て決めます。設定後は実際に反映された値をサイトヘルスやホスト側画面で確認します。

本番サイトで設定ファイルを触る前の安全策

1. 現在のwp-config.phpを保存
2. 文字コードと改行を変えない
3. 定数を重複定義しない
4. 編集後すぐトップと管理画面を確認
5. 500になったら変更を元へ戻す

設定変更は1行でもサイト全体へ影響します。管理画面から編集できるサーバー機能があるなら、FTPで直接触る前にそちらを使う方が戻しやすい場合があります。

上限を増やすより別の対策が必要なケース

判断基準｜設定変更で済むか、サーバー見直しが必要か

単発の画像処理だけで不足するなら運用やバッチ分割で解決できる可能性があります。通常の投稿保存でも頻繁に不足し、ホスト上限が低く変更できない場合は、サーバー仕様がボトルネックです。149の性能チェックでPHP・DB・同時実行まで合わせて確認してください。

メモリ変更後のQA

1. トップと主要記事を表示
2. 管理画面で投稿保存
3. 画像アップロード
4. フォーム送信
5. バックアップ・Cronなど高負荷処理
6. PHPログに新しいwarning/fatalがないか確認

上限を上げた後も記録しておくもの

変更前後のmemory_limit、WordPress側の定数、変更日時、理由、エラー全文を運用台帳へ残します。数か月後に別担当が見ても「なぜ256Mなのか」「誰が何のために変えたか」が分かる状態にすると、無意味な上限増加を防げます。

複数サイトでは全部同じ値にそろえる必要はありません。画像処理が多いサイト、EC、バックアップ対象が大きいサイトでは必要量が異なります。共通化するのは値そのものではなく、診断手順と記録形式です。

最後に見るべきこと

上限を増やしてエラーが消えても、CPU使用率や処理時間が悪化していないか確認します。メモリだけ解決して別の資源を圧迫していれば、根本原因は残っています。

公式情報・参考資料

• WordPress: wp-config.php の編集
• WordPress Hosting Handbook

まとめ

WordPressのメモリ上限は、エラーを消すための数字ではなく、処理設計とサーバー資源の境界です。ログ→直前変更→実上限→原因処理の順で見て、必要なら上限を調整します。頻発するなら143のCron、144のDB、145のObject Cache、149のサーバー性能まで含めて土台から点検した方が安全です。PHP世代自体の判断は141へ分離しています。