サーバー容量が足りないときの対処法｜削除前の確認と増設判断

1. 何の容量が不足しているかを確認する

最初に通知の文面、対象契約、確認日時、上限と使用量を控えます。Webファイル、メールボックス、データベース、ファイル数など、制限の対象が違えば対処も変わります。容量の空きがあるのに保存できない場合は、権限や別の制限も調べる必要があります。

契約画面にある総容量と、個別メールアカウントの上限も同じではありません。例えばエックスサーバー公式のメール仕様では、メールボックスの使用量がディスク容量に含まれると説明されています（確認日2026年9月30日）。これは同社の仕様であり、他社の内訳は利用中のサービスで確認してください。

調査中にバックアップを同じ満杯の領域へ追加すると、さらに空きが減ります。空きが極端に少なく更新や受信が止まっている場合は、大きな圧縮処理を始めず、外部への退避方法や一時的な容量確保を管理者と決めます。ここで紹介するのは削除の判断手順であり、本番へ貼り付ける一括削除コマンドではありません。

空きがあるのに足りない例：メールボックスの上限

以下は設定例です。契約全体が100GB、使用量が60GBでも、あるメールボックスに2GBの上限を設定し、そのボックスが2GBに達しているなら、全体の残り40GBだけでは受信できると判断できません。

1. 通知が契約全体と個別メールボックスのどちらを指すか確認する。
2. 管理画面で対象ボックスの上限・使用量・更新時刻を控える。
3. 個別上限を変更できる契約か確認する。整理する場合は、利用者と保存対象・同期の影響を合わせ、退避後に実施する。

この状況でWeb画像を消しても、個別ボックスの制限は変わりません。逆に契約全体が満杯なら、個別上限を増やすだけでは足りません。DBやファイル数の制限も、同じように該当する枠を確認してください。

2. 名前や更新日だけで削除可否を決めない

以下は削除候補を調べるための当サイト独自の整理表です。「古い」「backupという名前」「キャッシュらしい」という見た目だけでは、安全に消せる証拠になりません。スマホでは横にスクロールできます。

用途が分からないデータベースのテーブルや設定ファイルは、容量順で消さず保留します。キャッシュも提供機能から消す方法を先に確認します。削除してすぐ同じ容量へ戻るなら、原因は保持数や生成処理にある可能性があるため、削除を繰り返すだけでは解決しません。

3. WordPressの「未添付」を「未使用」と決めつけない

WordPress公式のメディアライブラリ説明では、未添付は投稿や固定ページとの添付関係に基づく分類です（確認日2026年9月14日）。その表示だけで、サイトのどこからも使われていないことを保証するものではありません。

削除候補の画像なら、URLを控えて記事本文、アイキャッチ、ロゴ、テーマの設定、CSS、再利用するコンテンツなどを照合します。PDFはサイト内だけでなく、案内メールや外部サイトから直接URLが使われている可能性もあります。参照先をすべて追えないものは、すぐに消さず保留欄へ入れましょう。

WordPressは同じ画像から複数サイズのファイルを作ることがあります。似た名前のファイルでも画面幅によって使われる場合があるため、FTP等でサムネイルだけをまとめて消す進め方は避けます。画像の容量が主因なら、今後アップロードする原稿のサイズや圧縮方法も見直すと、増加を抑えやすくなります。

4. 退避・取り出し確認・少量の整理の順に進める

1. 作業前を記録：対象フォルダや機能、容量、担当者、保留事項をメモする。
2. 必要分を別の保存先へ退避：公開URLから取得できる場所へバックアップを置かない。容量を空ける目的なら、同じディスク内の移動だけでは足りない。
3. 取り出せることを確認：ファイル数や容量を照合し、代表ファイルを開く。WordPress全体の復旧が必要なら、別環境での復元確認まで計画する。
4. 確認済みの一種類だけ整理：管理画面や提供元が案内する操作を使い、対象と結果を残す。
5. 表示と容量を再確認：主要ページ、画像、必要な業務機能を点検し、使用量表示の更新時刻も確認する。

WordPress公式のバックアップ案内は、ファイルとデータベースの両方を保存対象としています（確認日2026年9月14日）。記事データだけ保存して画像を削除した場合、画像は戻せないおそれがあります。保存対象の違いはバックアップの保存先を分ける判断表でも整理しています。

メールの削除は利用者と実施範囲を合わせてください。同期方式によってはサーバー側の削除が端末にも反映されます。また、バックアップを開けても、運用中の環境へ正しく戻せるかは改めて確かめる必要があります。整理後に不具合が出た場合は追加削除を止め、記録した対象から復旧します。

写真や動画が多いサイトの容量を見積もる

写真を多く載せるサイトでも、最初から最大容量のプランが必要とは限りません。撮影時の原本、掲載用に書き出した画像、納品用ファイルは役割が違うため、Webサイトを原本の唯一の保管先にせず、公開に必要な画像だけをアップロードします。顧客のデータを公開ディレクトリへ置く方法も避けてください。

WordPressのレスポンシブ画像の説明では、アップロードした画像から複数のサイズが生成され、テーマによって追加されるサイズも変わると説明されています（2026年9月23日確認）。元画像の合計だけでは使用量を見積もれないため、10枚程度を試しに登録して使用量の差を測り、その値を月の増加量の見積もりに使います。

動画は、ディスクに保存する量と閲覧時の転送量を分けて見積もります。30MBの動画を100人がそれぞれ全量取得すると、単純計算では3,000MBの転送です。再生方式やキャッシュで実際の通信量は変わるため目安として扱い、動画配信サービスへの埋め込みや別の保存先も含めて、権利・表示方法・費用に合う置き場所を選びます。

5. 片付けで足りるか、半年先の容量を計算する

次は例です。契約上限200GB、同じ集計範囲での現在使用量170GBを想定します。内訳はWeb関連50GB、メール40GB、バックアップ80GB。復旧に必要な分を確保したうえで、古いバックアップ50GBを外部へ退避して削除できたなら、整理後は120GBです。

必要容量の目安＝整理後の使用量＋今後増える量＋作業時に必要な空きとして見積もります。直近の実測をもとに月8GB増えると仮定し、半年分48GBと作業用20GBを加えると、120＋48＋20＝188GBになります。

この例は200GB以内ですが、見積もりとの差に使える残りは12GBです。月12GB増える場合なら120＋72＋20＝212GBとなり、上限を超えます。増加量が変わりやすいサイトでは、強気の見積もりだけで契約を決めないことが大切です。20GBも一律の推奨値ではありません。更新や復元が一時的に必要とする領域から決めます。

GBとGiBなど単位が違う画面の数値は、そのまま足さず集計条件をそろえます。移行先へコピーを置く、圧縮ファイルを展開する、検証環境を作るといった作業でも一時的に容量を使います。定期バックアップの保持数が再び増える設定なら、その分を将来の増加量へ含めてください。

6. 整理メモを残し、必要なら契約を比較する

容量を確保したら、原因となった保持数や定期処理も見直し、次に点検する日を決めます。確認時刻と使用量を同じ条件で記録すれば、増え方が変わったときにも気付きやすくなります。

整理後も不足が見込まれるなら、現契約のプラン変更と他社への移転を比較します。総容量だけでなく、メール・DBの制限、バックアップの保存領域、復元方法、更新料金、移行作業の範囲をそろえてレンタルサーバーの比較記事をご確認ください。比較記事には広告リンクを含みます。必要な容量が確保できている場合は、買い替えを急ぐ必要はありません。

移転も候補になる場合はドメイン移管とサーバー移転の作業分担表へ。現在の構成から相談したい場合は公開・設定サポートの対応範囲と料金目安をご覧ください。

写真を増やす予定がある場合の容量計画

不要データを整理した後も画像が増えるなら、次の更新分まで含めて容量を見積もります。表示の速さと、サーバーに保存する量は別々に確認してください。