WordPressのPHPメモリ不足を確認する方法｜500エラーと管理画面停止の対処

WordPressで500エラーが出たり、管理画面の保存や画像処理が途中で止まったりした時は、設定値を増やす前にPHPメモリ不足の証拠を確認してください。エラー画面だけでは、プラグインの不具合、CPU不足、データベース遅延などと見分けられません。

結論は、発生時刻と操作を記録し、エラーログの「Allowed memory size exhausted」、現在の実効上限、原因ファイルの3点を照合することです。この順番なら、不要な設定変更を避けながら復旧方法を選べます。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。PHPメモリ不足の対応では、上限値だけを増やさず、どの処理がどの時刻に使い切ったかを必ず確認しています。

PHPメモリ不足は、画像の一括生成、インポート、バックアップ、重い編集画面など、特定の操作でだけ起きることがあります。普段は表示できるサイトでも、処理の山が重なれば一時的に上限へ達します。

一方で、500エラーや管理画面停止のすべてがメモリ不足ではありません。この記事では「確認できた事実」と「推測」を分け、初心者でも戻せる変更だけを一つずつ行う手順を解説します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのPHPメモリ不足はエラーログで判断する

WordPressのPHPメモリ不足を判断する最も確実な手掛かりは、症状が出た時刻のPHPエラーログです。500という番号や画面の白さではなく、メモリを使い切ったことを示す文言まで確認してください。

ブラウザに詳しいエラーを表示する必要はありません。サーバー管理画面のエラーログ、または外部から見えないdebug.logを使えば、訪問者へサーバーパスを見せずに調査できます。

Allowed memory size exhaustedの1行を読む

典型的な記録には「許可されたメモリ量」「追加で確保しようとした量」「処理が止まったファイル」「行番号」が含まれます。次の例では、約128MBの上限へ達した後、さらにメモリを確保できず停止しています。

[10-Sep-2026 00:12:34 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes) in /path/to/wp-content/plugins/example/example.php on line 123

134217728バイトを1,048,576で割ると128MBです。ただし「tried to allocate」の数値だけを上限と誤解しないでください。そこは最後に追加しようとして失敗した量であり、先に書かれたAllowed memory sizeが上限です。

ファイルパスは重要な手掛かりですが、そのファイルが必ず根本原因とは限りません。別の処理が大量のメモリを保持した結果、最後に小さな追加確保をした正常なファイルで停止する場合もあります。

症状が出た時刻と直前の操作を記録する

ログは時刻と操作をセットで読みます。投稿保存、画像アップロード、バックアップ展開、商品CSVの取込など、直前の操作を一つに絞ると該当行を探しやすくなります。

管理画面を何度も再読み込みすると同じFatal errorが増え、最初の記録が埋もれます。時計がUTC表記ならJSTとの差も考慮し、サーバーのタイムゾーンを確認してから照合してください。

500エラーだけでメモリ不足と決めない

500 Internal Server Errorはサーバー内部で処理を完了できなかったという結果であり、原因名ではありません。.htaccessの記述ミス、PHP構文エラー、権限、プラグイン競合でも同じ500になります。

Allowed memory size exhaustedがなく、代わりにParse error、Call to undefined function、Permission deniedなどが記録されているなら、そのエラーを優先します。ログが空なら、参照しているログの種類と対象ドメイン、記録時刻が正しいかを確認してください。

WordPress 500エラーの原因と解決方法を完全網羅｜ケース別の直し方を徹底解説

WordPressのPHPメモリ上限を3か所で確認する

WordPressのPHPメモリ上限は、wp-config.phpの定数だけでは判断できません。WordPress用の希望値、PHPのmemory_limit、ホスティング側の制限を比較し、実際のリクエストで有効な値を確認する必要があります。

WP_MEMORY_LIMITへ大きな数値を書いても、PHP設定の変更が禁止されていたり、契約プランの上限が低かったりすれば反映されません。設定ファイルに書いてある値と、実効値を分けて考えてください。

サイトヘルスの情報で実効値の手掛かりを見る

管理画面へ入れる場合は「ツール」から「サイトヘルス」を開き、「情報」タブのサーバー項目を確認します。PHPバージョン、PHPメモリ上限、最大実行時間などを、調査時点の画面として保存してください。

表示値が期待と違う場合は、別のphp.iniを編集している、PHP-FPMの再読み込みが必要、サーバー側で上書きされているなどの可能性があります。サイトヘルスは問題を自動で直す画面ではなく、現在値を比較する入口として使います。

WordPressのサイトヘルスで「改善が必要」と出た時の見方と対処法

wp-config.phpの2つの定数を区別する

WP_MEMORY_LIMITは通常のWordPress処理で要求する値、WP_MAX_MEMORY_LIMITは管理画面など負荷の高い処理で要求する上限に使われます。どちらもPHPやサーバーが許可する範囲を超えて強制できる設定ではありません。

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

/* That's all, stop editing! Happy publishing. */

定数を追加するなら「That’s all, stop editing」のコメントより前へ置き、同じ定数が二重に定義されていないか確認します。引用符、括弧、セミコロンの欠落は新しい500エラーを作るため、変更前のwp-config.phpを必ず保存してください。

php.iniとホスティング側のmemory_limitを確認する

PHP全体の上限は、php.iniやサーバー管理画面のPHP設定にあるmemory_limitで指定されます。共有サーバーではプランごとの上限や変更可能範囲があり、WordPress側から自由に増やせないことがあります。

memory_limit = 256M

数値は例であり、256Mがすべてのサイトの正解という意味ではありません。現在値、処理内容、契約上限を確認し、必要最小限の一時変更として扱います。変更後はサイトヘルスや新しいログで実効値を再確認してください。

.htaccessのphp_valueは、PHP-FPMやCGI構成では使えず、それ自体が500エラーの原因になる場合があります。利用サーバーの公式手順で対応可と確認できない限り、推測で追加しない方が安全です。

WordPressの管理画面が止まる時の安全な確認手順

WordPressの管理画面が止まる時は、同じ操作を連打せず、再現条件を一つだけ作ってログと照合します。管理画面へ入れるかどうかで入口は変わりますが、バックアップと記録を先に取る原則は同じです。

管理画面へ入れる場合は操作を一つに絞る

投稿一覧は開くのに特定投稿の編集だけ止まる、通常画像は入るのに大画像だけ失敗する、バックアップ開始後だけ応答しないなど、正常な操作と失敗する操作を比べます。

サイトヘルス、サーバー資源、エラーログを開き、失敗操作を一度だけ実行して時刻を記録します。CPUやディスクが上限なのにPHPメモリだけを増やしても改善しないため、同じ時間軸で見てください。

WordPressの管理画面が急に重い原因とは？初心者でもできる切り分け手順

管理画面へ入れない場合はサーバー側から確認する

管理画面そのものが500エラーや真っ白画面なら、レンタルサーバーの管理画面、ファイルマネージャー、SFTPからエラーログとwp-config.phpを確認します。WordPressのリカバリーモード案内メールが届いている場合は、送信元と対象サイトを確認して利用します。

画面へエラーを直接表示するWP_DEBUG_DISPLAYは本番で有効にしないでください。サーバーパスやプラグイン名が訪問者へ見えるため、ログへ記録し、調査後に戻す方法を選びます。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

デバッグ設定は一時的な調査用です。必要な記録を保存したら元の値へ戻し、外部からdebug.logへアクセスできないことも確認します。既にサーバーのPHPエラーログへ記録されているなら、無理に追加する必要はありません。

WordPress画面真っ白の直し方｜プラグイン・テーマ・メモリ不足まで全対応

変更前後を同じ手順で比べる

原因候補が見つかったら、一度に一つだけ変更し、同じURL・同じ操作で再確認します。複数のプラグイン停止、PHP変更、キャッシュ削除を同時に行うと、直っても何が効いたのか分かりません。

1. 対象ファイルとデータベースのバックアップを取る
2. 失敗時刻・URL・操作・ログ行を保存する
3. サーバー資源とPHPの実効上限を記録する
4. 原因候補を一つだけ停止または調整する
5. 同じ操作を一度だけ再実行する
6. 改善の有無と新しいログを記録し、不要な変更を戻す

WordPressのPHPメモリ不足を一時的に復旧する方法

WordPressのPHPメモリ不足を一時的に復旧する時は、重い処理を止めることを先に行い、必要な場合だけ上限を小さく引き上げます。無制限に増やす対応は、異常な処理を長く動かしてサーバー全体を不安定にするため避けてください。

画像処理・取込・バックアップを停止または分割する

画像のサムネイル再生成、大量CSV取込、検索インデックス作成、バックアップ圧縮、マルウェアスキャンは、一時的に大きなメモリを使います。処理件数を小分けにし、同時刻に複数を走らせないだけで復旧できる場合があります。

途中で止まったジョブをすぐ再実行せず、ロックファイル、一時ファイル、処理済み件数を確認します。二重実行になると、メモリだけでなくCPU、ディスク、データベース接続も圧迫します。

確認できた範囲でメモリ上限を一時的に調整する

ログでメモリ不足を確認し、ホスティング側が変更を許可している場合に限り、WP_MEMORY_LIMITやPHP memory_limitを一段階だけ上げます。変更前後の値、時刻、対象処理を記録してください。

変更後に同じ操作が完了しても、原因解決とは限りません。消費量が上限ぎりぎりなら再発するため、原因プラグイン、画像サイズ、取込件数、同時実行数を見直します。

原因候補のプラグインやテーマだけを切り離す

ログのパスと直前の変更から特定のプラグインが疑われる場合は、バックアップと代替手段を確認してから、そのプラグインだけを停止します。管理画面へ入れない時は、プラグインフォルダ名を一時変更する方法があります。

ただし、決済、会員、予約、セキュリティ、キャッシュなどは停止の影響が大きいため、本番で一括無効化しないでください。ステージング環境があるなら同じデータ量と操作で再現し、更新版や設定変更を試します。

WordPressのPHPメモリ不足の原因を特定して再発を防ぐ

WordPressのPHPメモリ不足を再発させないためには、上限値ではなく消費量が増えた原因を特定します。メモリを増やして表示が戻っても、無限ループや重複処理が残れば次はCPUや実行時間の上限へ達します。

エラーのファイルパスと操作内容を対応させる

wp-content/plugins配下ならプラグイン、themes配下ならテーマが手掛かりです。画像関数やWordPressコアのファイルで止まっている場合は、大画像や呼び出し元プラグインが先にメモリを消費した可能性も確認します。

行番号だけを見てファイルを直接書き換えるのは危険です。更新で消える修正になりやすく、最後に停止した場所とメモリを増やした処理が別の場合もあるため、呼び出した操作と直前の更新履歴を組み合わせます。

変更前後のメモリ使用量と完了時間を比べる

原因候補を一つ変更するごとに、処理が完了したか、Fatal errorが消えたか、完了時間が変わったかを記録します。ホスティングの資源グラフや検証環境の計測ツールを使い、同じデータ量で比較してください。

数値が取れない場合でも、画像枚数、CSV行数、投稿ブロック数など入力規模をそろえると比較できます。小さいデータでは成功し、大きい時だけ失敗するなら、分割処理や画像縮小が有効な可能性があります。

重い定期処理を分散し不要な機能を整理する

バックアップ、画像最適化、セキュリティ確認、集計、外部同期を同時刻へ集中させないでください。役割が重複するプラグインを整理し、使っていない停止中プラグインも更新または削除の判断をします。

大きな画像はアップロード前に適切な寸法へ縮小し、インポートは分割します。更新前はステージングで確認し、正常時のPHP上限、主要操作の完了時間、資源グラフを基準として残すと異常に気づきやすくなります。

WordPress修正の依頼前チェックリスト｜原因を切り分ける方法

WordPressのPHPメモリ不足でよくある質問

WordPressのPHPメモリ不足を調査する時によくある疑問をまとめます。設定変更の前に、現在の実効値とログの証拠を確認することが共通の前提です。

WordPressのPHPメモリ不足は証拠確認から復旧する

WordPressのPHPメモリ不足では、500エラーや管理画面停止という症状だけで判断しないことが重要です。発生時刻と操作を記録し、Allowed memory size exhausted、実効上限、原因候補のファイルを照合してください。

復旧は、重い処理の停止または分割、必要最小限の一時的な上限調整、原因候補を一つずつ切り分ける順で進めます。変更前後を同じ操作で比べれば、直った理由を説明でき、再発防止にもつながります。

ログの読み方やサーバー設定に不安があり、管理画面と公開画面の両方が止まっている場合は、それ以上の再実行を止めてください。エラーログ、発生時刻、変更履歴、バックアップの有無を整理してから専門家へ引き継ぐのが安全です。

WordPressの500エラー・管理画面停止が自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で