「容量が残りわずかです」というメールが、サーバー会社から届いた。サイトの引っ越しやバックアップに使っているAll-in-One WP Migrationも、書き出しが途中で進まなくなった。記事や画像はそれほど増やしていないのに、どうしてこうなるのでしょうか。
当社がPHPやWordPressの最新化を担当したサイトでも、作業に取りかかってから同じような問題がいくつも見つかりました。お客様はどなたも気づいていませんでした。実際に確認した5つの原因をもとに、この記事では確かめ方から片付け方まで紹介します。
WordPressの容量が増える原因は「サイト本体以外」
WordPressの容量が急に増える、あるいは書き出しが止まる。その原因は、多くの場合、記事や画像以外にあります。当社で見つかったのは、エラーを記録し続けるdebug.log、サーバー内に溜め込まれたバックアップ、大量に溜まったコメント、アクセス解析プラグインの記録、置きっぱなしの書き出しファイルという5つの原因でした。どれも管理画面では見えにくいうえ、このうち2つは外部から読める状態でした。

| 原因 | 実際の事例 | 外から読めたか |
|---|---|---|
| debug.log | 35GBまで膨らみ、書き出しが止まる原因になっていた | 読めた |
| サーバー内のバックアップ | 書き出し7.9GBのうち7.2GBがUpdraftPlusのバックアップ | - |
| 大量のコメント | コメント590万件で、データベースが4.98GB(上限3GB) | - |
| アクセス解析の記録 | 記録が443万行・1.66GBになり、書き出しが止まる原因になっていた | - |
| 書き出しファイルの放置 | サーバー内に13個が残っていた | 読めた |
原因1:debug.logが35GBまで増えていた
WordPressには、エラーの内容をファイルへ記録する機能が備わっています。開発や不具合調査の際に有効にする機能で、通常の書き込み先は wp-content/debug.log です。調査を終えたら無効に戻すのが基本ですが、あるサイトでは有効にしたまま何年も放置されていました。
そのサイトでは、debug.logが35GBにまで膨らんでいました。All-in-One WP Migrationの書き出しが途中で止まるため調べたところ、原因はこのログでした。警告やエラーが発生するたびに記録が追加されるので、そのままにしておくとログは増え続けます。
しかも、このファイルはブラウザで開ける状態でした。debug.logには、サーバー内のフォルダの場所やプラグインの名前などが記録されています。攻撃者に手がかりを与えるおそれがあり、外部から見える状態にしてはいけません。別のお客様のサイトでも、公開されたままのdebug.logが見つかりました。
そこで、まずwp-config.phpで記録を停止しました。そのうえで、ログと古い圧縮ログ(.gz)を公開フォルダの外へ移し、削除しています。
原因2:バックアップの中にバックアップが入っていた
UpdraftPlusなどのバックアッププラグインでは、初期設定のまま使うと、保存先がサイトと同じサーバーの中になります。この状態でAll-in-One WP Migrationの書き出しを行うと、保存してあるバックアップもまとめて含まれてしまいます。
| サイト | 書き出しの大きさ | 除外したもの | 除外後 |
|---|---|---|---|
| A | 7.9GB(うちUpdraftPlusが7.2GB) | UpdraftPlusのバックアップ、セキュリティプラグインのログ | 305MB |
| B(Aと同じお客様) | 5.5GB | UpdraftPlusのバックアップ、古い書き出しのフォルダ、セキュリティプラグインのログなど | 382MB |
サイト本体の大きさは300MB台でした。つまり、書き出しの9割以上をバックアップとログが占めていたことになります。別のお客様のサイトでも、書き出す際にはUpdraftPlusとBackWPupのバックアップを除外しています。会員制の別のサイトでは、3.2GBの書き出しのうち2.57GBがUpdraftPlusのバックアップでした。
バックアップを同じサーバー内に置くと、サーバーが壊れた際に一緒に失われます。より安全なのは、外部に保存するか、サーバー会社の自動バックアップを利用する方法です。エックスサーバーなら、WordPressのバックアップ方法で紹介しているように、標準のバックアップ機能でも十分です。
原因3:コメントが590万件溜まっていた
コメント欄を開けたままにしていると、スパムコメントが溜まり続けます。あるサイトで確認したコメント数は、590万件(うち承認済み380万件)でした。データベースの大きさも4.98GBに達し、サーバーの上限である3GBを超えていました。
このサイトはコメントの表を空にしたことで、データベースが2.34GBになり、書き出しは64MBになりました。ただし、正規のコメントが残っているサイトでは、すべて削除せずにスパムだけを消してください。
コメント数が数十万件程度でも、書き出しには時間がかかります。ほかのサイトでは、承認待ちの数十万件のスパムコメントが溜まり、それが書き出しを遅くする原因になっていました。All-in-One WP Migrationでは、データベースを表ごとに書き出します。そのため、コメントのような大きな表を処理している間は「%」の表示が進まないまま、件数だけが増えていきます。画面が止まったように見えても、件数が増えているなら処理は続いています。
原因4:アクセス解析プラグインの記録が443万行
サイトの訪問者を記録するアクセス解析プラグインの中には、記録をデータベースに残し続けるものがあります。同じお客様の2つのサイトでは、WassUpというプラグインの記録が443万行・1.66GBと343万行・1.3GBに達していました。どちらもAll-in-One WP Migrationの書き出しが止まり、原因を調べるとこの記録でした。
記録を除いて書き出すと、1つ目のサイトは2.2GBから197MBに、2つ目は2.0GBから627MBになりました。1つ目のサイトでは、2018年に作られたUpdraftPlusのバックアップも残っていました。アクセス解析をGoogleアナリティクスなどの外部サービスで行っているなら、サイトの中に記録を溜めるプラグインは止められないか確認してください。
原因5:書き出しファイルがサーバーに残っていた
All-in-One WP Migrationの書き出しファイルは、ダウンロードを済ませてもサーバーに残ります。当社が最新化の作業でサーバー内を確認すると、こうしたファイルを残したままのサイトがかなり多く見つかります。あるサーバーでは13個が残っており、すべて外部から読める状態でした。
このプラグインは、保存フォルダの一覧を表示させないようにしています。ただ、それで隠れるのは一覧だけです。ファイルの場所さえ分かれば、直接ダウンロードできてしまいます(バージョン7.111のコードで確認)。書き出しファイルにはデータベースの中身がすべて収められているため、会員情報やお問い合わせの記録があれば、それらも含まれます。
当社では、この13個のファイルを公開フォルダの外へ移動しました。書き出しファイルをダウンロードしたあとは、サーバーから削除してください。
ここまでのまとめ:容量の問題は、安全の問題でもある
容量の増加や書き出しの停止には、単にファイルが場所を取っているというだけでは済まない背景があります。エラーの放置、バックアップの不適切な置き場所、コメント欄の管理不足といった、運用上の問題です。外部から読めるファイルも実際に見つかりました。容量の警告が届いたら、サイトの状態を見直すきっかけとして受け止めてください。
自分で確かめる方法
容量を使っている場所を把握するには、次の順番で確認します。
- サーバーのファイルマネージャーやFTPソフトを使い、wp-content の中にあるフォルダごとの大きさを調べる
- wp-content の直下に debug.log があるかを調べ、見つかったら何GBあるかを確認する
- updraft、backwpup、ai1wm-backups などのバックアップや書き出しのフォルダが、どれほどの大きさかを確認する
- サーバーの管理画面やphpMyAdminで、データベース全体の大きさと、表ごとの大きさを調べる(コメントの表 wp_comments や、プラグインが作った表が極端に大きくないか)
- 管理画面の「コメント」を開き、承認待ちとスパムがそれぞれ何件あるかを確認する
debug.logが見つかった場合は、ブラウザで https://(ご自身のドメイン)/wp-content/debug.log を開いてください。内容が表示されるなら、外部からも読める状態になっています。
片付け方と再発防止
| 原因 | 片付け方 | 再発防止 |
|---|---|---|
| debug.log | 記録を停止してから削除する | 調査を終えたら、wp-config.phpの設定を必ず元に戻す |
| サーバー内のバックアップ | 古くて不要なバックアップを削除する | 外部を保存先にするか、サーバー会社のバックアップ機能を利用する |
| 大量のコメント | スパムと承認待ちを削除する | コメント欄を使わないなら閉じる。使う場合はスパム対策を入れる |
| アクセス解析の記録 | 不要な記録を削除するか、プラグインを止める | 使っていないアクセス解析プラグインは停止・削除する |
| 書き出しファイル | ダウンロードが済んだものを削除する | 書き出した日のうちに、サーバーから消す |
debug.logへの記録を停止するには、wp-config.phpにある次の行を確認してください。true になっている場合は false に戻します。
|
1 2 3 |
define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); |
記録が有効なままでは、先にファイルを削除してもログが再び増えていきます。作業は「止めてから消す」という順番で進めてください。また、何百万件ものコメントを管理画面から削除するのは現実的ではなく、phpMyAdminでの作業になります。データベースを直接操作するため、必ずバックアップを取ってから作業してください。
よくある質問
Q. debug.logは消しても大丈夫ですか?
はい。debug.logは記録のためのファイルなので、削除してもサイトの動作に影響はありません。不具合を調査している途中なら、必要な部分を手元に保存したうえで削除してください。
Q. 書き出しが何十分も同じ%のままです。止まっていますか?
%の横に表示される件数が増えている場合は、大きな表を書き出している最中です。件数にも変化がなければ、上で紹介した方法で、ログやバックアップのファイルが大きくなりすぎていないかを確かめてください。
Q. UpdraftPlusは使わないほうがいいですか?
いいえ。外部(クラウドストレージなど)を保存先に設定すれば、便利に使えるプラグインです。問題になるのは、サーバーの中に溜め込む設定のまま使い続けることです。安全面については、UpdraftPlusの接続キー流出の記事でも紹介していますので、あわせてご覧ください。
見えない場所の点検まで、お任せください
今回取り上げた5つの問題は、いずれも管理画面を見ているだけでは気づけません。当社では、PHPやWordPressの最新化、保守の作業にあわせて、サーバーの中まで確認しています。容量を圧迫するファイルや外部から読めるファイルがあれば、片付けまで対応します。
当社の保守サポートでは、WordPressとプラグインの更新、毎日のバックアップ、24時間の監視に月額3,800円から対応しています。容量の警告が来た、書き出しが終わらないなどのご相談も承ります。
書き出したデータを手元で復元する際の注意点は、All-in-One WP Migration等の復元で起きるメール誤送信を防ぐで紹介しています。
更新履歴
- 2026年11月8日:作成(当社が担当したPHP・WordPress最新化の作業中に見つかった事例)