前回の記事などを参考に「NginxやWordOpsのWebログローテーション（圧縮・世代管理）を設定して、これでディスク容量問題は完璧！」と一安心していませんか？
……実は、安心するのはまだ早いかもしれません。
「Webログの対策はバッチリなはずなのに、なぜかディスク容量が日に日に減っていく」
「df -h で確認すると、やっぱりストレージが圧迫されている……」
そんな謎の現象に悩まされている場合、犯人はWebサーバー（Nginx）ではなく、UbuntuというOS自体が裏でひそかに溜め込んでいる「隠れたシステムログ」である可能性が非常に高いです。
このOS内部のログ、デフォルト設定のままだと制限なしで数GB〜十数GB単位まで巨大化し続け、最終的にはサーバーのストレージを食いつぶしてしまうという罠があります。
「せっかくWebサイトのログを綺麗にしたのに、OSのログでサーバーが落ちたら元も子もない……」
ご安心ください！この記事では、見落としがちな「OS隠れログ」の正体を突き止め、すでに溜まってしまった古いログを安全に一括削滅する方法を分かりやすく解説します。
さらに、二度とログでディスクが溢れないよう「ログの最大サイズ（上限）を自動制限する設定」までセットで紹介します。
今回も、ただコマンドをコピペするだけでなく、「なぜそのコマンドを打つのか」「各パラメータがどんな意味を持つのか」という仕組みの解説をバッチリ盛り込みました。
大切なログを誤って消しすぎない安全な設定手順になっていますので、愛機（サーバー）を快適・安全に保つために、一緒にサクッと設定を済ませておきましょう！
1. Webログ消したのに…の原因！見落としがちな「OS隠れログ」の正体
NginxやApacheなどのWebサーバーログを定期的に圧縮・削除（ローテーション）するように設定しても、「なぜかディスク容量（ストレージ）が減らない…」という現象が起こることがあります。
その原因の多くは、UbuntuなどのLinux OSがシステム全体で記録している 「OS内部のログ」 にあります。
① なぜOSのログは肥大化するのか？（systemd-journaldの仕組み）
現代のUbuntu（16.04以降など）では、システム全体のサービス起動ログやエラーメッセージ、ログイン履歴などを systemd-journald という仕組みが一括管理しています。
この systemd-journald は非常に優秀で便利なツールなのですが、標準設定（デフォルト）のままだと、利用可能なディスク容量の「最大10%」まで制限なくログを溜め込み続けるという仕様になっています。
つまり、ストレージが100GBあるサーバーなら、最大10GB分ものOSログが自動で蓄積されてしまうということです。
② 放置するとどうなる？サーバーが直面するトラブル
OSログを制限せずに放置しておくと、以下のようなトラブルを引き起こします。
- ディスク容量100%によるサイト停止 Webログをせっかく数MB〜数万KBに抑えていても、OSログが数GB〜十数GBまで膨れ上がり、突然ストレージを圧迫してデータベースやサーバーを停止させます。
- ログ調査（トラブルシューティング）が重くなる 数か月〜数年分のシステムログが巨大な単一データとして残るため、サーバー障害が起きた時に原因を探すコマンド（
journalctlなど）の実行速度が極端に遅くなります。
2. まずは現状確認！隠れログがどれくらい容量を食っているか調べる方法
作業を始める前に、まずはあなたのサーバーで「OSの隠れログが実際にどれだけのディスク容量を消費しているか」を確認してみましょう。
ターミナルで以下のコマンドを実行します。
sudo journalctl --disk-usage実行結果の例
コマンドを実行すると、以下のように現在のログ使用量が表示されます。
Archived and active journals take up 4.2G in the file system.もしここで 「数GB（上記例では4.2GBなど）」 と表示された場合、正しくOSログがストレージを圧迫しています！
3. 【実践】肥大化したOSログを安全に手動で削減（クリーンアップ）する
現状が把握できたら、まずは溜まりに溜まった過去の不要なログを手動で一括削除して、すぐにディスク容量を確保しましょう。
安全に削除するための代表的な2つのコマンドを紹介します。環境や目的に合わせてどちらか（あるいは両方）を実行してください。
方法A：サイズ（容量）を指定して削除する（おすすめ）
「ログの総量を〇〇MB（またはGB）以下に抑えたい」という場合は、--vacuum-size オプションを使います。
例として、直近の「500MB分」だけを残して、それ以前の古いログをすべて削除したい場合は以下のコマンドを実行します。
sudo journalctl --vacuum-size=500M500M：残したいログの合計サイズを指定します（例：100M, 1G など）。指定したサイズを超えている過去ログが即座に削除されます。
方法B：期間（日数）を指定して削除する
「過去〇日分のログだけを残して、それより古いログをすべて削除したい」という場合は、--vacuum-time オプションを使います。
例として、直近「7日間」のログだけを残して削除したい場合は以下のコマンドを実行します。
sudo journalctl --vacuum-time=7d7d：残したい期間を指定します（d＝日、m＝月、y＝年）。例として 14d（14日間）や 2w（2週間）のように指定可能です。
削除後の確認
削除コマンドを実行したら、もう一度確認コマンドを打ってみましょう。
sudo journalctl --disk-usagetake up 500.0M や take up 200.0M などのように、指定したサイズ近くまで容量が削減されていれば手動クリーンアップ成功です！
4. 二度と溢れさせない！ログの最大サイズ（上限）を自動制限する永続設定
手動でログを消しても、デフォルト設定のまま放置すれば再びOSログは肥大化していきます。
ここでは、systemd-journald の設定ファイルを編集し、「OSログの最大上限サイズ」を恒久的に制限する手順を解説します。
設定ファイルの編集手順
ターミナルで設定ファイルを開きます。（ここでは nano エディタを使用します）
sudo nano /etc/systemd/journald.confコピペでOK！設定コードとパラメータ解説
ファイルが開いたら、[Journal] という行を探し、その下に以下の設定を追記（またはコメントアウト # を外して編集）します。
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month各パラメータの意味と役割
| パラメータ名 | 設定値の例 | 役割・意味 |
|---|---|---|
SystemMaxUse | 500M | OSログが使用する最大ディスク容量。これを超えると古いログから自動で削除されます。 |
SystemKeepFree | 1G | OSログ用に必ず残しておくべき空き容量。ディスク全体の空きが少なくなった際の安全弁です。 |
MaxRetentionSec | 1month | ログを保存する最大期間。サイズに関わらず指定期間（例: 1ヶ月）が経過したログは自動削除されます。 |
💡 おすすめの設定値
小〜中規模のVPSや個人サーバーであれば、SystemMaxUse=500M（または 1G）程度に設定しておけば、トラブルシューティング用のログを十分残しつつ、ディスク圧迫を完全に防ぐことができます。
キーボードの Ctrl + O ➔ Enter で保存し、Ctrl + X でエディタを閉じます。
5. 設定の反映と動作確認手順
設定ファイルを書き換えただけでは、まだシステムに反映されていません。最後にサービスを再起動して設定を適用しましょう。
サービスの再起動
以下のコマンドで systemd-journald を再起動します。
sudo systemctl restart systemd-journald動作確認
再起動後、改めて使用量確認コマンドを実行します。
sudo journalctl --disk-usage設定した SystemMaxUse（例：500M）の範囲内に自動調整されていれば、永続化設定は無事完了です！
6. まとめ
今回は、Webログ対策後も見落とされがちなUbuntuの「OS隠れログ」の仕組みと、手動削除＆自動上限設定の手順を解説しました。
本記事の重要ポイントを振り返りましょう！
- Webログ以外の落とし穴：
systemd-journaldは標準でディスク容量の最大10%までログを溜め込む。 - 手動で緊急避難：
journalctl --vacuum-size=500Mで溜まった過去ログを一発解消。 journald.confで恒久対策：SystemMaxUse=500Mを設定し、二度とログでストレージを溢れさせない仕組みを作る。
WebログとOSログの両方をしっかり制御できていれば、ログ肥大化による突然のサーバー停止リスクはほぼゼロになります。
設定後の動作確認（ヨシ！）までしっかり済ませて、快適で安全なサーバー運用を続けていきましょう！
コメント