「ディスク使用率が80%を超えました」というアラートに慌てていませんか？中小企業のWeb担当者向けに、原因の特定から即時対処、恒久対策まで実践的なフローを解説します。
こんな悩みはありませんか？
「監視ツールから突然アラートが届いた。ディスク使用率が82%——でも何をすればいいか分からない」
「ログが溜まっているらしいけど、どのファイルが問題なのか見当もつかない」
「とりあえず古いファイルを消したら、今度はサービスが落ちてしまった……」
こうした状況に陥ったことはないでしょうか。ディスク残量の問題は、放置するとサイト全体がダウンし、データベースへの書き込みも不能になる深刻な障害につながります。しかも最悪のケースでは、エラーログすら書き込めなくなるため原因調査も困難になります。
本記事では、神奈川拠点のWeb制作会社として20年以上、Laravel・WordPress・Next.jsの本番運用を支えてきた経験をもとに、ディスク使用率が80%を超えたときの対処フローを実践的にまとめました。エンジニアや社内Web担当者が、冷静かつ素早く動けるよう、ステップバイステップで解説します。
なぜディスクはいつの間にか埋まるのか
本番サーバーのディスクが逼迫する原因は、大きく次の4つに分類されます。
1. ログファイルの肥大化
Apache・Nginx・PHP・MySQLなどのログは、設定次第で際限なく積み上がります。特にアクセスログやエラーログは、アクセスが多いサイトでは1日で数百MBになることも珍しくありません。logrotateの設定漏れが原因であるケースが最も多いです。
2. セッションファイルの蓄積
PHPのデフォルト設定では、セッションデータは/tmp以下にファイルとして保存されます。セッションのGC（ガベージコレクション）が正常に動作していない環境では、数ヶ月分のセッションファイルが数十万件単位で溜まっているケースがあります。
3. アップロードファイル・バックアップの放置
WordPressのメディアライブラリや、Laravelのstorage/app配下にユーザーがアップロードしたファイルが蓄積されます。また、mysqldumpなどで生成したローカルバックアップを本番サーバー上に置いたまま忘れてしまうケースも頻繁に見られます。
4. デプロイ残骸・旧バージョンディレクトリ
CapistranoやEnvoyer等のデプロイツールを使っている場合、過去のリリースディレクトリが蓄積します。デフォルト設定では5世代分保持しますが、設定を変えないまま数年運用すると数十GBになることもあります。
対処フロー：段階別に動く
flowchart TD
A[🚨 ディスク使用率80%超アラート] --> B[Step1: 現状把握\ndfコマンドで容量確認]
B --> C[Step2: 原因特定\nduコマンドで犯人を探す]
C --> D{安全に削除できるか？}
D -->|Yes| E[Step3: 即時削除\nログ・セッション等をクリア]
D -->|No| F[バックアップ確認後に判断]
E --> G[Step4: 使用率60%以下を確認]
F --> G
G --> H[Step5: 恒久対策\nlogrotate・自動化設定]
H --> I[✅ 監視アラートのしきい値を見直す]Step 1：現状把握——どのパーティションが危ないか
まず全体像を把握します。
# ディスク使用量をパーティション別に確認
df -h
# 出力例
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 50G 41G 9G 82% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
/（ルートパーティション）が82%なのか、/varが別マウントで逼迫しているのかによって対処が変わります。まずここでどのマウントポイントが問題かを確認してください。
Step 2：原因特定——どのディレクトリが太っているか
# ルート直下のディレクトリ別使用量（大きい順）
du -sh /* 2>/dev/null | sort -rh | head -20
# /varが大きい場合、さらに掘り下げる
du -sh /var/* 2>/dev/null | sort -rh | head -10
# ログディレクトリの確認
du -sh /var/log/* 2>/dev/null | sort -rh | head -10
Step 3：即時削除——安全に容量を確保する
**削除前に必ずバックアップの状態を確認してください。**消したら戻せないものを誤って削除するケースが後を絶ちません。
# ✅ 安全に削除できるもの（例）
# 30日以上前のNginxアクセスログ（既にローテート済みの圧縮ファイル）
find /var/log/nginx -name "*.gz" -mtime +30 -delete
# Laravelのログを安全にクリア（ファイルごと消さずに中身を空に）
truncate -s 0 /var/www/your-app/storage/logs/laravel.log
# 古いセッションファイルを削除（7日以上前）
find /var/www/your-app/storage/framework/sessions/ -mtime +7 -delete
# 古いデプロイリリース（Capistrano: 直近5世代以外を削除）
# ※CapistranoはDeployfile内でkeep_releases設定を確認のこと
# ⚠️ 削除前に確認が必要なもの
# アップロードファイルはアプリのDBと紐づいている可能性があるため
# 単純削除は禁止。管理画面から削除するか、DB確認後に判断する
# MySQLのbinlogは削除前にレプリケーション設定を確認すること
ls -lh /var/lib/mysql/mysql-bin.*
Step 4：恒久対策——logrotateの設定を見直す
緊急対処後は、再発防止の設定を行います。特にlogrotateの設定は最優先です。
# /etc/logrotate.d/nginx の設定例（毎日ローテート・30日保持）
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
# Laravelログのローテートもlogrotateで管理する例
/var/www/your-app/storage/logs/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0664 www-data www-data
}
Logrotateの設定後は、テスト実行で動作確認を忘れずに。
# ドライラン（実際には削除しない）
logrotate -d /etc/logrotate.d/nginx
# 強制実行（設定が正しければこれで実行）
logrotate -f /etc/logrotate.d/nginx
よくある失敗パターンと対処法
実際の案件で見てきた「やりがちなミス」をまとめます。
失敗① rm -rf /var/log/nginx/* で稼働中ログを全削除してしまった
Nginxがファイルを開いたまま削除すると、プロセスはそのファイルディスクリプタを保持し続けるためディスクは解放されません。lsof | grep deletedで確認すると、削除済みのはずのファイルが依然としてディスクを占有しているのが分かります。正しくはtruncate -s 0でファイルを空にするか、logrotateのpostrotateでプロセスにシグナルを送ってください。
失敗② Laravelのphp artisan storage:link後にstorage配下を誤削除
あるEC系のクライアント案件で、storage/app/public以下の商品画像を「古いファイルだろう」と一括削除してしまい、全商品ページで画像が表示されなくなったケースがありました。アップロードファイルはアプリケーションのDBレコードと密接に紐づいているため、ファイルシステム上の操作だけで判断してはいけません。
失敗③ ディスクが100%になってからSSHすら繋がらなくなった
80%の段階でアラートが届いていたにもかかわらず、「まだ余裕がある」と放置した結果、2週間後に100%に到達。MySQLがクラッシュし、最終的にサーバーの再起動とデータリカバリが必要になったケースです。ディスクフルは「サービスが遅くなる」で済む話ではなく、データが壊れるリスクを伴います。80%をトリガーにした自動アラートの設定は必須です。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
ディスク使用率が80%を超えたときの対処は、**「現状把握 → 原因特定 → 安全な削除 → 恒久対策」**の4ステップが基本です。焦って手当たり次第にファイルを消すのが最も危険な行動であり、削除前の確認と恒久対策の設定がセットでなければ意味がありません。
弊社では過去に複数のクライアント様でこの問題に対応してきましたが、logrotateの設定と定期的なセッションクリーンアップを適切に設定したことで、その後2年以上ディスク起因の障害ゼロという結果が出ています。仕組みで予防することが何より重要です。
「自分で対応するのが不安」「そもそも監視の仕組みがない」という場合は、サーバー保守・監視設計のご相談もお気軽にどうぞ。
