「不正ログインがなかったか調べようとjournalctlを開いたら、思っていたより古いログが残っていない」——そんな経験はないでしょうか。systemd-journaldは既定のRateLimit（間引き）機能で同じようなログを黙って捨て、容量の上限に達すると古い記録を静かに消していきます。2026年9月18日には米CISAが実際に悪用が確認されたLinuxカーネルの脆弱性3件をKEVカタログに追加し、連邦機関に9月21日までの対応を求めるという動きもありました。侵入の兆候をどこまで遡って調べられるかは、結局ログの保存期間次第です。この記事ではUbuntu 24.04を基準に、journalctl --disk-usageと/etc/systemd/journald.confを使って、自分の環境でログがどれだけ・どこまで残るのかを点検する手順をまとめます。
journalctl --disk-usageで保有ログの容量を確認する
まず、今どれだけの量のログが残っているのかを見ます。sudoは不要です（読み取りだけなので設定変更のリスクもありません）。
$ journalctl --disk-usageこれは/var/log/journal（または後述する一時領域）に溜まっているログファイルの合計サイズを見ているコマンドです。出力例は次のようになります。
Archived and active journals take up 104.0M in the file system.どこを見て判断するか
- サーバーの稼働期間に対して数MB程度しかない場合：ログが想定より早く消えている可能性があります。半年運用しているサーバーで数MBしかないなら、容量ベースの上限（後述のSystemMaxUse）にすぐ達して古いログが消えている状態です。
- ディスク容量に対してかなり大きい場合：
df -h /var/logで空き容量も確認してください。空き容量がゼロに近いと、journaldがログを書き込めなくなり、それ以降の記録（＝侵入の証拠になり得るログ）が欠落します。
異常が疑われたら、次の章の「保存期間の上限」を先に確認します。数値だけでは「何日分残っているか」が分からないためです。
/var/log/journalの有無で「再起動で消える」ログを見分ける
点検の中でもっとも見落とされやすいのがこれです。journaldのログ保存先には「永続化される場所（ディスク）」と「再起動で消える場所（メモリ上の一時領域）」の2種類があり、設定によってはログが最初からディスクに残っていません。
$ test -d /var/log/journal && echo "永続化: 有効" || echo "永続化: 無効(再起動で消える)"このコマンドは、ログの永続化用ディレクトリが存在するかどうかだけを見ています。出力は次の2パターンです。
永続化: 有効永続化: 無効(再起動で消える)「無効」だった場合の次の行動
クラウドの最小構成イメージやDocker上のUbuntuでは、ディスクI/Oを節約する目的で最初からこの状態になっていることがあります。この場合ログは/run/log/journal（メモリ上のtmpfs）にしか置かれず、再起動した瞬間に不正ログインの記録も含めて全部消えます。侵入調査中にサーバーを再起動してしまい、証拠が消えたという事故を避けるため、永続化したい場合は次を実行します（sudoが必要な設定変更です）。
$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
$ sudo systemctl restart systemd-journald元に戻す（＝再起動で消える状態に戻す）には、このディレクトリを削除してから同じくjournaldを再起動します。rm -rf /var/log/journalは蓄積したログを完全に削除するコマンドなので、実行前に本当に不要か確認してください。
RateLimitで攻撃時のFailed passwordが間引かれていないか確認する
ログが永続化されていても、記録自体が最初から間引かれているケースがあります。journaldには同じサービスから短時間に大量のログが来たとき、ログの洪水でディスクとCPUを使い切らないよう自動的に間引くRateLimitという機能があり、Ubuntu 24.04にパッケージされているsystemdでは既定で「30秒間に10,000件」を超えると間引きが働きます（RateLimitIntervalSec=30s / RateLimitBurst=10000）。SSHへの総当たり攻撃（ブルートフォース）は短時間に同じようなFailed passwordログを大量発生させるため、まさにこの間引きの対象になり得ます。
$ journalctl -u systemd-journald --since "7 days ago" | grep -i suppressjournald自身が「間引きました」と記録した行を探しています。出力例です。
Sep 20 03:14:02 myserver systemd-journald[512]: Suppressed 842 messages from /system.slice/ssh.serviceどこを見て判断するか
この行が出ていたら、その時間帯に842件のログが記録されずに捨てられたということです。実際のsshdの記録は次のように残りますが、件数だけを見て「この程度の攻撃だった」と判断すると、間引かれた分だけ実態より少なく見積もってしまいます。
Sep 20 03:14:01 myserver sshd[9931]: Failed password for invalid user admin from 203.0.113.45 port 51244 ssh2次の行動
間引きの閾値を上げたい場合、本体の/etc/systemd/journald.confを直接書き換えるより、上書き用の設定ファイル（ドロップイン）を追加する方が安全です。元に戻すときはファイルを消すだけで済むためです。
$ sudo mkdir -p /etc/systemd/journald.conf.d
$ sudo nano /etc/systemd/journald.conf.d/10-ratelimit.conf[Journal]
RateLimitIntervalSec=30s
RateLimitBurst=50000$ sudo systemctl restart systemd-journald元に戻すにはsudo rm /etc/systemd/journald.conf.d/10-ratelimit.confのあと同じ再起動コマンドを実行します。あわせて、Ubuntu 24.04ではサーバー用途でもrsyslogが入っていないことがあり、/var/log/auth.log自体が存在しない場合があります。次のコマンドで確認できます。
$ dpkg -l | grep rsyslog何も出力されなければ未インストールです。RHEL系（CentOS・Fedora・Rocky Linuxなど）では同じ役割のファイルが/var/log/secureという別名になる点も、他環境を触るときは覚えておいてください。journaldのコマンド自体はどのディストリでも共通です。
SystemMaxUseとMaxRetentionSecで保存期間の上限を確認・設定する
容量が十分あり間引きも起きていないのに古いログがない場合、容量ベースの自動ローテーションが働いています。既定では保存先のファイルシステムの空き容量に応じて上限が自動計算される仕組みで、明示的な保存日数の指定（MaxRetentionSec）は設定されていません。
設定項目 | 意味 | Ubuntu 24.04の既定 |
|---|---|---|
SystemMaxUse | ログ全体が使える最大容量 | 未設定時はファイルシステム容量の約10%（上限あり） |
MaxRetentionSec | 保存する最大期間 | 未設定（容量の上限に達するまで残る） |
RateLimitIntervalSec / RateLimitBurst | 間引きの間隔と件数 | 30秒間に10,000件 |
Storage | 保存先（auto/persistent/volatile） | auto（/var/log/journalの有無で決まる） |
実際にどこまで遡れるかは、次のコマンドで確かめます。
$ journalctl --list-boots再起動ごとの記録が残っている範囲を一覧表示します。出力例です。
-3 8a1c2e... Mon 2026-08-24 09:12:03 JST—Wed 2026-09-10 07:03:41 JST
-2 4f9b7d... Wed 2026-09-10 07:05:12 JST—Fri 2026-09-19 21:44:09 JST
0 c7e610... Fri 2026-09-19 21:46:55 JST—Sun 2026-09-27 10:02:17 JSTどこを見て判断するか
一番上（最も古い行）の開始日時が「サーバーを動かし始めた日」より大幅に新しければ、それより前のログは容量の上限で既に消えています。たとえば3ヶ月前から稼働しているのに一覧の最古が2週間前からしかない場合、それより前に何が起きても今は調べられません。
次の行動：保存期間を明示的に確保する
調査に必要な期間（たとえば90日）を確保したい場合、先ほどと同じくドロップインで指定します。
$ sudo nano /etc/systemd/journald.conf.d/20-retention.conf[Journal]
MaxRetentionSec=90day
SystemMaxUse=2G$ sudo systemctl restart systemd-journald注意：ここで指定したSystemMaxUseが現在の使用量より小さい場合、再起動と同時に古いログがその場で削除されて容量が縮められます。設定前に必ずjournalctl --disk-usageで現状の使用量を確認し、それより小さい値を入れないようにしてください。元に戻すにはsudo rm /etc/systemd/journald.conf.d/20-retention.confのあと同じ再起動コマンドを実行します（この場合は既定値に戻るだけで、既に残っているログが消えることはありません）。
関連する選択肢
手元のPCを開いている間しか動かない、という問題を避けるなら、常時起動しているサーバーを借りてそこに置く方法があります。料金はプランによって変わります。
SSDプランが月々698円から使える！さくらのVPS
※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。
変更後の確認とログ改ざんチェックまでのつなぎ
設定を変えたら、必ずもう一度journalctl --disk-usageとjournalctl --list-bootsを実行し、意図した容量・期間になっているかを確認します。数値がすぐには反映されないこともあるので、翌日以降にもう一度見ておくと確実です。
ここまでは「ログが残っているか」の点検です。残っていることが分かったら、次は「そのログが後から書き換えられていないか」も別問題として確認する必要があります。この点はjournalctl --verifyでログ改ざん検知2026で扱っているので、あわせて見ておくと点検が一段深くなります。
月に一度、次の4つを流すだけでも「気づいたら証拠が残っていなかった」という事態は避けられます。
journalctl --disk-usageで使用量を見るtest -d /var/log/journalで永続化を確認するjournalctl -u systemd-journald | grep -i suppressで間引きの有無を見るjournalctl --list-bootsで実際に遡れる期間を確認する