Allowed memory size exhaustedは、PHPの処理でメモリ制限に達したときのエラーです。まずエラー全文・発生操作・時刻を保存し、設定を増やす前に、画像処理やバックアップなど何をしたときに出たかを分けます。PHP変更直後ならPHP変更後の復旧、真っ白画面なら真っ白画面の確認へ進みます。
134217728 bytesは何を表す？エラー文の読み方
次は説明用の例です。実際の障害を再現したログではありません。
Allowed memory size of 134217728 bytes exhausted (tried to allocate 1024 bytes)134217728 bytes：この例で表示された制限値。1024で2回割ると128MiBです。tried to allocate 1024 bytes：失敗時に追加で確保しようとした量です。処理全体の必要メモリ量や推奨設定値ではありません。in ... on line ...：エラーが報告されたファイル・行です。そのファイルだけが原因だとは断定できません。
ディスクの空き容量やアップロード容量の上限とは別の制限です。エラー文に128MiBが出たことだけを理由に、全サイトへ同じ増量を勧めることはできません。
設定変更の前に： WordPressバックアップと復元を確認し、直前の更新が関係する場合は更新前後の確認項目も見直します。似たエラーはトラブル解決一覧から確認できます。
確認する順番
- エラーが出た操作と時刻を記録
- 直前の変更を確認
- 画像処理・バックアップ等の重い処理を確認
- PHP情報を確認
- 必要ならホスティング推奨範囲で設定を確認
| 発生した操作 | 最初に見る候補 |
|---|---|
| 画像アップロード・画像生成 | 画像サイズ、画像処理系プラグイン、同時処理 |
| バックアップ・移行 | バックアップ対象、圧縮処理、直前の設定変更 |
| 投稿保存・管理画面 | エディター、プラグイン、直前に追加した処理 |
| サイト全体・常時 | PHPエラーログ、テーマ・プラグイン、PHP環境 |
メモリ不足は「上限が低い」ことだけが原因とは限りません。まず発生操作・時刻・エラーログに出るファイル名・直前変更を記録し、同じ操作で再現するかを確認します。上限変更は原因候補を絞った後に検討します。
メモリ上限を変更する前に、現在値と契約先の制限を確認
上限変更は契約サーバーの仕様と推奨値を確認して行います。WordPress側の設定値だけを大きくしても、PHPやホスティング側の上限が低ければ反映されない場合があります。また、原因となる処理が異常に重い場合は、上限を増やしても再発します。
| 対応 | 安全性 | 先に確認すること |
|---|---|---|
| 発生操作とログを記録 | 高い | 時刻・URL・ファイル名 |
| 直前の変更を戻す | 比較的高い | バックアップ・変更履歴 |
| プラグインを1つずつ切り分け | 中 | 影響範囲・復旧手順 |
| メモリ上限を変更 | 中 | サーバー仕様・現在値・推奨範囲 |
| 複数設定を同時変更 | 低い | 避ける |
PHPバージョン変更直後から発生した場合は、PHPバージョン変更後にWordPressが動かないときの確認手順もあわせて確認します。
関連記事
原因を絞るための記録項目
| 記録するもの | 見るポイント |
|---|---|
| 発生操作 | 画像アップロード、投稿保存、バックアップなど |
| 発生時刻 | 同じ時間帯に繰り返すか |
| エラーログ | 同じプラグイン・テーマのファイル名が出ているか |
| PHP情報 | 現在のメモリ上限とサーバー側の上限 |
| 直前変更 | プラグイン更新、テーマ変更、PHP変更の有無 |
同じ操作で毎回再現するなら、その処理を優先して切り分けます。逆に操作と無関係に常時発生する場合は、プラグイン・テーマ・PHP全体の状態を確認します。
WordPress側の WP_MEMORY_LIMIT と管理系処理の WP_MAX_MEMORY_LIMIT、PHPの memory_limit は確認する場所が異なります。管理画面と公開画面で値が違う場合もあるため、発生した処理で使われる値を担当者へ確認します。WordPress公式のメモリ設定説明でも、上限増加が根本原因を隠す場合や、ホスト側で変更を認めない場合を説明しています。
容量不足と混同しないよう、必要に応じてサーバー容量不足の確認もあわせて確認してください。
やらない方がよいこと
- 根拠なくメモリ上限を大幅増加
- ログを見ずにプラグイン削除
- 本番でデバッグ情報を公開
最後に確認すること
変更は1つずつ行い、変更前後で同じ操作を再確認します。原因が特定できない場合は、URL・発生時刻・変更内容を整理して契約先や担当者へ相談してください。
補足：メモリ上限・エラーログ・画像アップロードに関するよくある質問は、後半のFAQへまとめています。
特定プラグインや処理後に発生した場合は、その処理を止めて再現性を確認します。画面全体が落ちる場合は重大なエラー、500へ変わる場合は500エラーへ切り分けます。
メモリ不足を相談するときの記入メモ
不明な項目は「不明」のまま相談できます。全部埋まっても原因確定・復旧済みとは判断しません。入力は送信・自動保存されません。ログの絶対パス・顧客情報・認証情報は、公開の場へ貼らないでください。
復旧は、最初に失敗した操作を確認して判断します。ログやバックアップを保全し、本番で詳細なエラーを公開しないようにします。
大きな画像の変換・圧縮・サムネイル生成で発生する場合は、先に画像をアップロードできない原因の切り分けを確認します。ファイルサイズ上限のエラーならupload_max_filesizeの確認へ進みます。
よくある質問
wp-config.phpへ数値を追加すれば直りますか？
環境によってはWordPress側設定よりサーバー側上限が優先されます。契約サーバーの仕様と現在値を確認します。
プラグインを全部停止した方が早いですか？
一度に全部変えると原因を追いにくくなります。直前更新やログで候補を絞り、必要なら1つずつ確認します。
画像アップロード時だけ出ます
画像サイズ、変換・圧縮処理、画像系プラグインなどとの関係を確認します。大きな画像をそのまま処理していないかも見ます。
