Linuxサーバーの運用や障害調査で、「サービスが起動しない」「エラーの原因がわからない」という場面に直面したことはありませんか？systemdを採用しているモダンなLinux環境では、従来のテキストログに代わり、journalctl コマンドによる一元的なログ管理が標準となっています。
しかし、オプションが豊富すぎるあまり「どのオプションを組み合わせれば目的のログを瞬時に引けるのか」迷ってしまう方も少なくありません。そこで本記事では、実務の現場で即座にコピペして使える目的別の逆引き早見表を冒頭に配置し、出力ログの読み解き方、syslog や dmesg との違い、さらには systemctl と連携した障害切り分けフローまで徹底解説します。
オプションを視覚的に組み合わせてコマンドを生成したい方は、あわせて journalctl コマンド生成ツール もご活用ください。
【早見表】journalctlやりたいこと別・逆引きコマンド一覧
実務で頻繁に利用する journalctl コマンドの代表的な組み合わせをまとめました。作業現場で素早くログを調査したいときは、以下の表からコマンドをコピーしてご利用ください。
| 目的（やりたいこと） | 実行コマンド（即コピペ可能） | 主な用途・解説 |
|---|---|---|
| 全ログの確認 | journalctl |
システム全体のログをページャー（less）で先頭から閲覧 |
| 直近N行のみ表示 | journalctl -n 50 |
最新の50行のみをターミナルに表示（行数変更可） |
| 特定サービスのログ確認 | journalctl -u nginx |
nginxなどの特定ユニット（Unit）が出力したログに限定 |
| リアルタイム追跡（tail -f相当） | journalctl -f |
新着ログを常時監視（Ctrl+C で終了） |
| サービスログをリアルタイム追跡 | journalctl -u nginx -f |
Webサーバーや独自デーモンの動作をリアルタイム監視 |
| 直近1時間のログ抽出 | journalctl --since "1 hour ago" |
相対時刻で直近1時間以内のログを抽出 |
| 今日のログのみ表示 | journalctl --since today |
当日00:00以降に記録されたログを表示 |
| 特定の日時範囲で絞り込み | journalctl --since "2026-10-01 09:00" --until "2026-10-01 12:00" |
障害発生時間帯を絶対時刻でピンポイント指定 |
| 前回の起動セッションを確認 | journalctl -b -1 |
サーバー再起動前のログを調査（-b 0 は今回起動分） |
| 起動履歴の一覧表示 | journalctl --list-boots |
過去の再起動日時とブートID一覧を確認 |
| エラー以上の重要ログ抽出 | journalctl -p err |
緊急度err（Priority 3）以上の警告・重大ログのみ表示 |
| カーネルログのみ表示（dmesg同等） | journalctl -k |
ハードウェア認識、ネットワークドライバ、OOM Killerの確認 |
| カタログ付き詳細エラー確認 | journalctl -xeu nginx |
systemctl起動失敗時に詳細解説付きで末尾ジャンプ表示 |
| ログ本文の正規表現検索 | journalctl -g "Failed password" |
grepパイプ不要でMESSAGE本文を内部高速検索 |
| プロセス名（syslog識別子）で絞り込み | journalctl -t sshd |
ユニット定義を持たないプロセスやスクリプトログの特定 |
| タイムゾーン付きISO 8601表記 | journalctl -o short-iso |
別システムのアクセスログと時刻照合しやすい形式で出力 |
| JSON形式で出力 | journalctl -o json -n 10 |
jqコマンドやログ転送エージェントへの連携用出力 |
| ページャーを無効化してパイプ渡し | journalctl --no-pager -n 100 |
less起動を抑止し、grepやawkでのスクリプト処理に活用 |
| ログのディスク使用量を確認 | journalctl --disk-usage |
ジャーナルログが消費しているディスク容量を表示 |
| 容量上限で古いログを削除 | sudo journalctl --vacuum-size=1G |
ログ総容量が1GB以下になるよう古いログから安全に削除 |
| 保存期間で古いログを削除 | sudo journalctl --vacuum-time=7d |
7日以上前の古いジャーナルログを削除してディスク解放 |
journalctlとは？syslogやdmesgとの違い
journalctl は、systemdのログ収集デーモンである systemd-journald が管理するジャーナルログを照会するためのコマンドラインユーティリティです。従来のLinuxシステムでは、カーネルログは dmesg、デーモンやシステム全体のログは /var/log/messages や /var/log/syslog などのテキストファイルにバラバラに出力されていました。journalctl を使うことで、これらすべてのログを一元管理し、高速に検索・抽出できます。
従来のログ管理（syslog/dmesg）とjournalctlの比較表
「journalctlとdmesgやsyslogは何が違うのか？」という疑問を実務でよく耳にします。大きな違いは保存形式（バイナリ vs テキスト）と収集範囲の一元性にあります。
| 比較項目 | journalctl（systemd-journald） | 従来のsyslog（rsyslog / syslog-ng） | dmesg（カーネルリングバッファ） |
|---|---|---|---|
| 対象ログ範囲 | カーネル、デーモン、標準出力/標準エラー出力、監査ログを一元集約 | syslogプロトコル経由で送信されたメッセージが中心 | Linuxカーネルメッセージのみ |
| 保存形式 | 構造化バイナリ形式（インデックス付き） | プレーンテキスト形式 | メモリ上のリングバッファ（非永続） |
| 保存場所 | /run/log/journal/ または /var/log/journal/ |
/var/log/syslog, /var/log/messages 等 |
カーネルメモリ領域（RAM） |
| 検索・絞り込み | ユニット別（-u）、時刻（--since）、ログレベル（-p）で高速抽出 |
grep、awk、sedなどテキスト処理コマンドで走査 | grepとのパイプライン処理が中心 |
| リアルタイム追跡 | 可能（-f オプション） |
可能（tail -f コマンド併用） |
可能（dmesg -w オプション） |
| メタデータ保持 | PID、UID、GID、Unit名、SELinuxコンテキスト等を完全保持 | テキスト行に含まれるホスト名・プロセス名・日時のみ | カーネルタイムスタンプとメッセージのみ |
journalctl ではログがバイナリ形式でインデックス化されて保存されているため、数ギガバイトに及ぶ巨大なログファイルであっても、サービス名や日時による絞り込みがテキスト走査の grep と比較して圧倒的に高速です。
ログの保存場所と仕組み（/run/log/journal と /var/log/journal）
systemd-journald のログ保存場所には、設定と環境に応じて2つのパターンが存在します。この違いを理解していないと、「再起動したら過去のログが消えてしまった」というトラブルにつながります。
- /run/log/journal/ （揮発性・メモリ上）
tmpfs（RAM）上に保存されます。OSを再起動するとログはすべて消去されます。デフォルト設定のディストリビューション（一部の軽量コンテナや初期設定環境）では、ディスク容量を消費しないようにこのディレクトリが使われます。 - /var/log/journal/ （永続性・ディスク上）
ストレージ上に保存されます。サーバーを再起動してもログは保持され、過去の起動セッション（journalctl -b -1等）をさかのぼって調査できます。
ログをディスクに永続化させる具体的な設定手順については、後述の「ログを再起動後も残す設定（Storage=persistent）」にて詳しく解説します。
journalctlの出力結果の読み方（ログ行の構造解説）
journalctl を実行すると大量のログ行が表示されますが、1行ごとの構造を正確に分解して理解しておくことで、障害時のボトルネック特定が格段に早くなります。ここでは実務でよく見かける実際のログサンプルをもとに、各フィールドの意味とログレベルの分類を整理します。
まずは代表的なログ出力例を見てみましょう。
# SSH認証失敗のログ例
Oct 12 14:23:45 web-server-01 sshd[28491]: Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2
# Nginxのワーカープロセスエラーログ例
Oct 12 14:25:10 web-server-01 nginx[31042]: 2026/10/12 14:25:10 [error] 31042#31042: *1 connect() failed (111: Connection refused) while connecting to upstream
標準ログ出力のフォーマット対比表（日時・ホスト・プロセス・メッセージ）
標準的な journalctl 出力（デフォルトの short 形式）は、左から順に4つの主要フィールドで構成されています。
| フィールド項目 | サンプル該当箇所 | 意味と実務での着目ポイント |
|---|---|---|
| 1. タイムスタンプ（日時） | Oct 12 14:25:10 |
メッセージが記録された月日時分秒。デフォルトはサーバーのローカルタイムゾーン（JST等）。外部ログと突合する際は -o short-iso でタイムゾーン付き表記に切り替えると齟齬を防げます。 |
| 2. ホスト名（Hostname） | web-server-01 |
ログを生成したマシンのホスト名。複数台のサーバーログを集約している環境では、どのノードで事象が起きたかを瞬時に識別する基準になります。 |
| 3. プロセス / ユニット名 [PID] | nginx[31042] |
メッセージを出力したプロセス名（またはUnit名）と、OS上のプロセスID（PID）。PIDが頻繁に変わっている場合は、プロセスがクラッシュと再起動を繰り返している兆候（再起動ループ）です。 |
| 4. メッセージ本文（MESSAGE） | connect() failed (111: ...) |
デーモンやカーネルが出力した実際のイベント内容。エラーコード、アクセス元IP、失敗理由などの真因がここに記録されます。 |
ログレベル（Priority 0〜7）の色分けと深刻度一覧
systemd-journald に記録されるメッセージには、syslog規格に準拠した 0〜7 の8段階の優先度（Priority / ログレベル） が内部メタデータとして付与されています。ターミナル上で journalctl を実行した際、特定の行が赤色や太字でハイライトされるのは、このログレベルに基づいているためです。
| 数値 | レベル名（Priority） | ターミナル表示色 | 深刻度の目安と実務アクション |
|---|---|---|---|
| 0 | emerg（Emergency） |
赤色太字 / 反転 | システム全体が使用不能。カーネルパニック等、直ちに全停止する重大インシデント。 |
| 1 | alert（Alert） |
赤色太字 | 即時対応が必要。データベース破損や主要パーティションの破損など。 |
| 2 | crit（Critical） |
赤色 | 致命的な状態。重要ハードウェア障害やクリティカルなサービスの停止。 |
| 3 | err（Error） |
赤色 | 通常のエラー。サービスの起動失敗（Active: failed）や設定エラーなど、実務調査の中心。 |
| 4 | warning（Warning） |
太字（環境依存） | 警告。現時点で停止はしていないが、放置するとエラーになりうる状態（メモリ枯渇接近等）。 |
| 5 | notice（Notice） |
通常テキスト | 正常だが注意すべきイベント。サービスの開始・停止イベントなど。 |
| 6 | info（Informational） |
通常テキスト | 一般的な動作報告ログ。正常な接続受付や定期ジョブの完了など。 |
| 7 | debug（Debug） |
通常テキスト | 開発・トラブル解析用の詳細ログ。通常時は出力が抑制されることが多い。 |
日常の障害調査では、レベル3の err（Error）以上 を絞り込む journalctl -p err が最も多用されます。情報過多で原因ログが埋もれてしまっているときは、まずこのオプションで絞り込みましょう。
基本操作：まず覚える4つのログ確認コマンド
journalctl を使いこなす第一歩として、現場で毎日のように実行する「4つの基本コマンド」をマスターしましょう。この4つを身につけるだけで、日常的なログ確認作業の8割以上をカバーできます。
1. 直近ログだけを確認する（-n / -e）
引数なしで journalctl を実行すると、保存されている最古のログから順に表示されるため、最新のログにたどり着くまで時間がかかります。直近のログを確認したいときは -n または -e を指定します。
# 最新のログを50行だけ表示する
journalctl -n 50
# 行数を省略した場合は直近10行が表示される
journalctl -n
# ページャーのカーソルを最新ログ（末尾）に配置して開く
journalctl -e
-n 50 は「直近50件のログを出力して終了」します。一方、-e（--pager-end）は less ページャーを起動した状態で最下部にジャンプするため、末尾から上に向かって Shift + G や b キーで遡りながら調査したい場合に適しています。
2. サービス（Unit）単位で絞り込む（-u）
Webサーバーやデータベースなど、特定の常駐プログラムのログだけを調査したい場合は -u（--unit）オプションでユニット名を指定します。
# Nginx のログだけを抽出
journalctl -u nginx
# SSH サーバーのログを抽出（拡張子 .service は省略可能）
journalctl -u ssh.service
【落とし穴】大文字・小文字の誤りに注意：
systemdのユニット名は大文字と小文字を厳密に区別します。たとえば journalctl -u Nginx と先頭を大文字にして実行すると、一致するユニットが存在しないため -- No entries -- と表示されてログが1行も出力されません。ユニット名が不明な場合は、事前に systemctl list-units --type=service で正確な名前を確認してください。
3. リアルタイムで追跡する（-f）
新しいログが追記される様子をリアルタイムで監視したい場合は -f（--follow）を指定します。これは従来の tail -f とまったく同じ感覚で使えます。
# システム全体のログをリアルタイム追跡
journalctl -f
# 特定サービスのログだけをリアルタイム追跡（最も実務で使う組み合わせ）
journalctl -u nginx -f
設定変更後の動作検証や、APIへのリクエスト受信確認を行う際に重宝します。追跡を終了するときはキーボードの Ctrl + C を押します。
4. 期間・日時を指定して絞り込む（–since / –until）
「昨日の15時頃に発生した障害のログを見たい」「直近30分間のエラーを追いたい」といった時間帯の絞り込みには、--since（開始日時）と --until（終了日時）を使用します。
# 直近1時間のログを表示（相対指定）
journalctl --since "1 hour ago"
# 今日のログのみを表示
journalctl --since today
# 昨日のログのみを表示（昨日の00:00から今日の00:00まで）
journalctl --since yesterday --until today
# 特定の日時範囲を秒単位でピンポイント指定（絶対指定）
journalctl --since "2026-10-12 14:00:00" --until "2026-10-12 14:30:00"
【必須ルール】空白を含む場合は必ずダブルクォートで囲む：
シェル上で journalctl --since 2026-10-12 14:00:00 のようにクォートなしで実行すると、日付と時刻の間の空白で引数が分割され、構文エラー（Failed to parse timestamp）が発生します。空白を含む引数は必ずダブルクォート "..." で囲んで実行してください。
主要オプション一覧と実務活用テクニック
基本操作を押さえたら、障害調査の現場でプロが多用する応用オプションを身につけましょう。インデックスを活用した高速検索や、他ツール・スクリプトとの連携に欠かせないテクニックを解説します。
起動セッション別で絞り込む（-b / –list-boots）
サーバーが意図せず再起動してしまった際、「再起動の直前に何が起きていたのか」を調査するには -b（--boot）オプションが威力を発揮します。
# 現在の起動セッション（今回の起動後）のログのみ表示
journalctl -b
# 1回前の起動セッション（前回の再起動前）のログを表示
journalctl -b -1
# 2回前の起動セッションのログを表示
journalctl -b -2
# 記録されている起動履歴の一覧を確認
journalctl --list-boots
journalctl --list-boots を実行すると、以下のように過去の起動履歴とブートID、起動日時、シャットダウン日時が一覧表示されます。
# 出力例
-2 a1b2c3d4... Sun 2026-10-11 09:00:15 JST—Sun 2026-10-11 23:45:10 JST
-1 e5f6a7b8... Mon 2026-10-12 00:00:22 JST—Mon 2026-10-12 10:15:30 JST
0 9c8d7e6f... Mon 2026-10-12 10:16:01 JST—Mon 2026-10-12 15:00:00 JST
この一覧から目的のインデックス番号（-1 など）または32桁のブートIDを指定することで、再起動前のログだけを正確に切り出して調査できます。
優先度・エラーレベルで絞り込む（-p）
日常の運用で最も遭遇する「エラーログだけを抜き出したい」という要望には、-p（--priority）を指定します。指定したレベルおよび、それ以上に深刻なレベルのログがすべて抽出されます。
# エラー（err）以上の深刻なメッセージのみ表示
journalctl -p err
# 警告（warning）以上のメッセージを表示
journalctl -p warning
# 前回の起動セッションで発生したエラーのみを抽出
journalctl -b -1 -p err
# 特定サービス（例: PostgreSQL）のエラーのみを直近1時間から抽出
journalctl -u postgresql -p err --since "1 hour ago"
このように -u や --since、-b と組み合わせることで、ノイズとなる正常ログを一掃し、調査対象のエラーだけに焦点を絞り込めます。
カーネルログのみ表示する（-k）
-k（--dmesg）オプションを指定すると、Linuxカーネルが出力したメッセージのみを抽出できます。従来の dmesg コマンドと同等の情報を得ることができます。
# カーネルメッセージのみ表示
journalctl -k
# カーネルメッセージをリアルタイム監視（dmesg -w 相当）
journalctl -k -f
# 前回の起動時のカーネルエラー（ハードウェア障害やOOM Killer）を確認
journalctl -k -b -1 -p err
物理サーバーのディスクI/Oエラー、NICリンクダウン、メモリ枯渇によるOOM Killer（Out of Memory Killer）の発動など、OS基盤レイヤーの異常調査に必須のオプションです。
メッセージ本文を正規表現検索する（-g）
ログの本文（MESSAGEフィールド）に含まれる文字列を検索したい場合は、-g（--grep）オプションを使用します。
# "Failed password" を含むログを正規表現で高速検索
journalctl -g "Failed password"
# Nginxのログから 500番台エラー（500/502/503/504）の行を検索
journalctl -u nginx -g "HTTP/1\.[01]\" 50[0-9]"
【grepパイプとの違いと圧倒的メリット】：
通常、エンジニアは journalctl | grep "Failed" とパイプで繋ぎがちです。しかし、パイプ処理では journalctl が保持する全テキストをデコードして標準出力に流し込み、それを grep が1行ずつ再スキャンするため非常に重くなります。一方、-g オプションは journald のバイナリインデックス内部で直接パターンマッチングを行うため、検索処理が格段に高速で、CPUやI/O負荷を大幅に軽減できます。パターンに大文字が含まれていなければ、自動的に大文字・小文字を区別せず検索（ignore-case）してくれます。
出力形式を変更する（-o json / short-iso）
-o（--output）オプションを使うと、ログの出力フォーマットを自由に変更できます。実務で特に役立つのが short-iso と json です。
# タイムスタンプを ISO 8601 形式（タイムゾーン付き）で表示
journalctl -o short-iso -n 5
# JSON 形式で1行ずつ出力
journalctl -o json -n 5
# jq と組み合わせて特定フィールド（PIDとメッセージ）のみ抽出
journalctl -u nginx -o json -n 10 | jq -r '[.__REALTIME_TIMESTAMP, ._PID, .MESSAGE] | @tsv'
short-iso は 2026-10-12T14:30:15+09:00 のように正確な年・日時とタイムゾーンが出力されるため、クラウド上のログ収集基盤（CloudWatchやDatadog）と時刻を突き合わせる際に重宝します。また json 出力は Fluentd や Logstash などのログフォワーダーに受け渡す際の標準的な中間形式として最適です。
スクリプト・grep連携でパイプに流す（–no-pager）
journalctl はターミナル上で対話的に実行された場合、自動的に less などのページャーを起動します。しかし、シェルスクリプト内で結果を変数に代入したり、他のコマンドにパイプで渡したりする際には、このページャーが邪魔になります。
# ページャーを無効化して直接標準出力に出力する
journalctl --no-pager -u nginx -n 100
# 外部コマンドへ安全にパイプライン処理
journalctl --no-pager -u nginx -p err | mail -s "Nginx Error Report" admin@example.com
シェルスクリプトで journalctl を呼び出す際は、ターミナルのハングアップを防ぐためにも必ず --no-pager を付与するのが鉄則です。
障害調査・サービス起動失敗時の切り分け手順（Pattern #19連携フロー）
「WebサーバーやAPIを起動しようとしたが失敗した」という障害現場において、初心者が最も陥りがちなのが「やみくもに再起動コマンドを連打してしまう」ことです。systemd環境における障害対応の王道は、「systemctl で状態を確認」→「journalctl で詳細原因を特定」→「設定修正後にリアルタイム監視で復旧確認」 という3段階の論理的フローを踏むことです。
ステップ1：systemctl status で異常状態を検知
サービスが立ち上がらないときは、まず systemctl status でプロセスの現在の終了ステータスと直近の終了コード（Exit Code）を確認します。サービスの基本操作やステータス値の詳細な読み方については、systemctlコマンドの使い方と主要オプション早見表｜サービス起動・停止・自動起動設定完全ガイド で詳しく解説しています。
# サービスの状態を確認
systemctl status nginx
実行結果に以下のように Active: failed (Result: exit-code) と表示されている場合、異常終了が発生しています。
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2026-10-12 14:10:00 JST; 15s ago
Process: 32014 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
Oct 12 14:10:00 web-server-01 systemd[1]: Starting A high performance web server...
Oct 12 14:10:00 web-server-01 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 12 14:10:00 web-server-01 systemd[1]: nginx.service: Failed with result 'exit-code'.
Oct 12 14:10:00 web-server-01 systemd[1]: Failed to start A high performance web server.
末尾に「See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.」と出力されている通り、status 単体では概要しか分かりません。ここで次のステップへ進みます。
ステップ2：journalctl -xeu <service> で直近の詳細エラーを特定
直前の起動失敗で何が起きていたのか、その真因を突き止めるために最強の組み合わせとなるのが journalctl -xeu <service> です。
# 説明文付きで最新のサービスエラーログを最下部ジャンプ表示
journalctl -xeu nginx.service
-x（--catalog）：エラーコードに関する詳細な解説カタログや、ドキュメント参照URLを補足付与します。-e（--pager-end）：ログの最下部（最新行）へジャンプして開くため、スクロールの手間なく直前の失敗行を視界に捉えられます。-u（--unit）：調査対象のサービスログだけに絞り込み、他プロセスのノイズを完全排除します。
このコマンドを実行すると、以下のように設定ファイルの構文エラー箇所や、ポート80番の競合（Address already in use）、権限不足（Permission denied）といった障害の直接的原因となった具体的な行が明確に特定できます。
# 詳細ログの出力例：設定ファイルのセミコロン忘れを特定
Oct 12 14:10:00 web-server-01 nginx[32014]: nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/default:23
Oct 12 14:10:00 web-server-01 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: A start job for unit nginx.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit nginx.service has finished with a failure.
ステップ3：設定・権限修正後に再起動し journalctl -u -f で復旧確認
エラー原因（上記例では設定ファイルの構文エラー）を修正したら、サービスを再起動し、同時にログをリアルタイムで追跡して正常稼働を担保します。
# 1. 設定の構文チェック
sudo nginx -t
# 2. サービスの再起動
sudo systemctl restart nginx
# 3. リアルタイムログで正常起動と最初のリクエスト疎通を確認
journalctl -u nginx -f
もし自作スクリプトやデーモンが起動直後にクラッシュを繰り返している場合は、ユニット定義側の設計（再起動リトライ回数や待機時間）も見直す必要があります。安定運用のためのユニット設計については、systemd ユニットの基本と再起動戦略 もあわせてご参照ください。
OSレベルの異常（OOM Killer、メモリ枯渇）を検知する
「サービスが急に強制終了したのに、サービス自体のログには何もエラーが残っていない」というケースがあります。これはLinuxカーネルの OOM Killer（Out of Memory Killer） によって、メモリ枯渇時にプロセスが強制終了（SIGKILL）された典型的なパターンです。
この現象を特定するには、カーネルログからエラーやメモリ関連のメッセージを抽出します。
# カーネルログからエラーレベル以上を抽出
journalctl -k -p err
# ログ本文から "Out of memory" または "Killed process" を検索
journalctl -g "Out of memory|killed process" --since "2 hours ago"
出力結果に Out of memory: Killed process 12345 (mysqld) といった行が記録されていれば、OS全体のメモリ不足が原因です。スワップ領域の追加やプロセスのメモリ上限見直しを行いましょう。
ログ容量の管理と永続化設定
systemd-journald はシステムの稼働ログをすべて収集するため、運用を放置するとジャーナルファイルがディスク容量を圧迫してしまうことがあります。ここではディスク枯渇を防ぐための容量確認・削除手順と、安全な自動上限設定を解説します。
ログ使用量の確認（–disk-usage）と安全な削除（–vacuum-size / –vacuum-time）
まず、現在ジャーナルログがどの程度のディスク容量を消費しているかを確認します。
# 現在のジャーナルログ使用容量を確認
journalctl --disk-usage
出力例：
Archived and active journals take up 2.4G in the file system.
サーバー全体のディスク容量が逼迫しているかどうかを根本から調査したい場合は、du コマンドの使い方｜ディレクトリ別容量調査と大容量ファイル特定 を使って全体の使用率を把握しておくと安心です。
ジャーナルログが数ギガバイトに膨らんでディスクを圧迫している場合は、--vacuum-size や --vacuum-time を使用して古いログを安全にパージ（間引き削除）します。
# 合計サイズが1GB以下になるよう古いログから削除（sudo必須）
sudo journalctl --vacuum-size=1G
# 7日以上経過した古いログを削除（sudo必須）
sudo journalctl --vacuum-time=7d
# 保持するアーカイブログファイルの世代数を指定して削除
sudo journalctl --vacuum-files=5
【重要】直接ファイルを rm コマンドで消さないこと：/var/log/journal/ 配下のファイルを rm コマンドで直接削除すると、journaldの内部インデックスとの不整合やファイルハンドルの開放漏れが生じる恐れがあります。ジャーナルログのクリーンアップは必ず journalctl --vacuum-* コマンドを使用してください。
また、年末年始や長期休暇の前にログ肥大化によるサーバー停止事故を防ぐための総合的な対策手順は、長期休暇前のサーバー停止を防ぐ！logrotate総点検とディスク監視自動化スクリプト にて詳細を公開しています。
ログを再起動後も残す設定（Storage=persistent）
一部のLinux環境（Debian系や軽量OSの初期設定など）では、ジャーナルログが /run/log/journal/（RAM上）に一時保存される設定になっており、サーバーを再起動すると過去の障害ログがすべて消滅してしまうという危険な状態になっている場合があります。
再起動後もログを永続的にディスク上に残すには、以下の設定を行います。
# 1. 永続化用ディレクトリが存在するか確認し、なければ作成
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
# 2. 設定ファイル /etc/systemd/journald.conf を編集
sudo nano /etc/systemd/journald.conf
設定ファイル内で [Journal] セクションの Storage パラメータを persistent に変更します。
[Journal]
Storage=persistent
編集後、systemd-journald に設定を反映させます。
# journaldデーモンを再起動（ログ収集は中断されず即座にリロードされます）
sudo systemctl restart systemd-journald
これで、サーバーを再起動しても journalctl -b -1 などで前回の起動ログを確実に追跡できるようになります。
容量上限の自動制御（journald.conf の SystemMaxUse）
ログを永続化させた場合、ディスクが溢れないように「ジャーナルログが使用してよいディスク容量の上限」をあらかじめ設定しておくのが実務の鉄則です。
/etc/systemd/journald.conf を開き、以下のパラメータを環境に合わせて調整します。
[Journal]
# ジャーナルログ全体が消費するディスクの最大サイズ（例: 1GB）
SystemMaxUse=1G
# ファイルシステムに残しておくべき最小空き容量（例: 2GB）
SystemKeepFree=2G
# 個々のログファイルの最大サイズ
SystemMaxFileSize=128M
# ログを保持する最長期間（例: 1ヶ月）
MaxRetentionSec=1month
設定変更後に sudo systemctl restart systemd-journald を実行すれば、ログ容量が SystemMaxUse（上記例では1GB）に達した時点で、古いログから自動的にローテーション・削除されます。手動で定期的に削除スクリプトを回す必要がなくなり、安定した無人運用が可能になります。
よくあるトラブル・落とし穴と対処法
日常の実務で journalctl を使っていると、予期せぬエラーメッセージが出たり、期待したログが表示されなかったりすることがあります。ここでは現場で頻発するトラブルとその解決策をまとめました。
「No journal files were found.」と表示される原因と対策
journalctl を実行した際に No journal files were found. や -- No entries -- とだけ表示され、ログが一切確認できない場合があります。主な原因は以下の3点です。
- 一般ユーザー権限で実行している
システムログの閲覧権限がない一般ユーザーで実行すると、自分自身のプロセスのログしか検索対象になりません。sudo journalctlで実行するか、後述の手順でユーザーをログ閲覧グループに追加してください。 - ユニット名（サービス名）の綴りや拡張子ミス
前述の通り、-u Nginxのように大文字で指定したり、存在しないユニット名を渡すとログが見つかりません。systemctl list-units --type=serviceで正確な名称を確認してください。 - 揮発性ストレージ（/run）環境で再起動直後
ログ永続化（Storage=persistent）が未設定のサーバーでは、再起動によって過去ログが完全に消滅します。再起動前のログを探そうとして-b -1を指定しても「No journal files were found」となります。前述の永続化設定を行ってください。
一般ユーザーでログが見えない（sudo / admグループ設定）
実務では、「開発者や運用担当者に毎回 sudo を打たせずにシステムログを確認させたい」という運用要件がよくあります。Linuxの標準セキュリティ設計では、特定のグループに所属するユーザーに対して journald の全ログ閲覧権限が付与されます。
# 現在のユーザーを systemd-journal グループ（または adm グループ）に追加
sudo usermod -aG systemd-journal,adm $USER
# 反映のためにグループ情報を再読み込み（または再ログイン）
newgrp systemd-journal
UbuntuやDebian、RHEL/AlmaLinux等では、systemd-journal または adm グループに追加することで、sudo なしでもシステム全体のログを journalctl で閲覧できるようになります。
–sinceのクォート忘れ・タイムゾーンのずれ
特定の日時を指定した際に、意図したログが抽出されない典型例です。
# NG: スペースで引数が区切られエラー
journalctl --since 2026-10-12 12:00:00
# OK: 必ずダブルクォートで1つの引数として渡す
journalctl --since "2026-10-12 12:00:00"
また、クラウド上の仮想マシンや海外リージョンのサーバーでは、システム時刻が UTC に設定されていることが多々あります。「日本の15時に起きた障害だから」と --since "15:00:00" と指定すると、UTCの15時（日本時間24時）として解釈されてしまいログがヒットしません。サーバーのタイムゾーンを timedatectl で確認し、必要に応じて --utc オプションを併用してUTC基準で指定するか、ローカルタイムゾーンを JST に修正してください。
まとめ＆関連コマンド
モダンLinuxにおけるログ管理の中核を担う journalctl は、オプションを正しく理解して組み合わせることで、障害調査のスピードを劇的に高めることができます。実務で成果を出すための3大原則をおさらいしましょう。
- ファーストビューの逆引きを活用する：全体を流し見せず、
-u（サービス名）、-f（リアルタイム）、--since（時間帯）、-p err（エラー以上）でピンポイントに絞り込む。 - Pattern #19の障害切り分けフローを守る：サービス異常時は
systemctl statusで状態を検知し、すかさずjournalctl -xeu <service>でカタログ付き詳細エラーを特定して復旧確認を行う。 - 容量管理と永続化をセットで設計する：本番環境では
Storage=persistentで再起動前のログ消失を防ぎつつ、SystemMaxUse=1Gでディスク枯渇を自動防止する。
実務で併用する関連コマンド一覧
systemctl: サービスの起動・停止・自動起動・状態確認。障害発生時の一次検知コマンド。dmesg: カーネルのリングバッファを表示。journalctl -kと並びハードウェア・メモリ障害調査に活用。logger: シェルスクリプトやコマンドラインから任意のメッセージを systemd-journald / syslog に書き込む。df/du: サーバー全体のディスク使用量とディレクトリ別消費容量の調査。logrotate: アプリケーション独自のテキストログファイルのローテーション・圧縮管理。systemd ユニット: 自作スクリプトのデーモン化や再起動戦略の設計。
コメント