ログ確認の入口

この記事でわかること

障害発生時、どのログを見るべきかの症状別切り分け
systemctl status コマンドの出力結果の正しい読み方
システムログを詳細検索・追跡する journalctl の使い方
ハードウェアやOS深部の不具合を調査する dmesg の使い方
ログを解析・共有する際のセキュリティ面（秘密情報漏洩）などの注意点

最初の結論

Linuxサーバーや開発環境で「Webサーバーが起動しない」「ネットワークが繋がらない」「不具合が起きた」といったトラブルが発生した際、手当たり次第に再起動したり設定ファイルを書き換えたりするのは悪手です。

結論として、エラー発生時の原因調査は以下のコマンドを使い分けることからスタートします。

原因のサービス名がわかっている場合 👉 systemctl status <サービス名> でステータスと直近のエラーメッセージを確認する。
システム全体の時系列の動き、またはサービス起動前後の詳細を知りたい場合 👉 journalctl でログの追跡や特定の時間帯を絞り込んで検索する。
ハードウェア、ディスク、メモリ不足、またはOSのクラッシュに近いエラーの場合 👉 dmesg でLinuxカーネルが出力したメッセージを確認する。

Linuxのログはエラー解決のための「答え」がほぼ記載されています。難しそうに見えるログ表示ですが、確認すべきポイントを絞り込めば、初心者でも迅速に原因にたどり着くことができます。

症状別：最初に実行すべき確認コマンド早見表

発生しているトラブルの症状に合わせて、以下のコマンドを実行して切り分けを開始してください。

トラブルの症状	最初に実行するコマンド	主な調査対象
NginxやDocker、MySQLなどの特定のサービスが起動しない	`sudo systemctl status <サービス名>`	サービスの稼働ステータスと、起動スクリプトが吐いた直近のエラーメッセージ。
コマンドがエラーを吐いたが、画面出力だけでは原因が不明	`sudo journalctl -xe`	システム全体からエラー（Error/Failed）に該当する直近のログを抽出し、解決のアドバイス付きで表示。
サーバーに接続できない、ログインに失敗する	`sudo journalctl -u sshd -n 50` （または `/var/log/auth.log` の確認）	不正アクセス、ログイン試行の履歴、SSHデーモンのエラー。
動いていた特定のプログラムが突然強制終了（クラッシュ）した	`sudo dmesg -T \| grep -i -E "oom\|kill"`	メモリ容量不足によるOSの保護機能（OOM Killer）が作動したかどうかのログ。
USBデバイスを挿したが認識しない、 SSD/HDDがおかしい	`sudo dmesg -T \| tail -n 50`	カーネルが検知したハードウェアの接続・切断・エラーイベント。

関連記事：Linuxの目的別基本操作コマンド一覧
関連記事：Linuxセキュリティの基本と設定方法

1. `systemctl status` の出力結果の読み方

サービスが「起動しない（Active: failed）」となった際、最初に実行するコマンドの表示を解読するポイントです。

sudo systemctl status nginx

注目すべき出力箇所と意味：

Active:
- active (running)：正常に起動・動作しています。
- failed (Result: exit-code)：エラーで停止しています。
Process:
- エラーが発生して終了した際のプロセスID（PID）や終了コード（例：code=exited, status=1/FAILURE）が記載されます。設定ファイルの文法エラーなどがあると、ここがFAILUREになります。
直近のログ（末尾の数行）
- コマンド実行結果の最後の部分に、そのサービスが出力した直近10行程度のログがダイジェストで表示されます。「設定ファイルの〇行目にエラーがある」「ポート80番がすでに使われている」といった具体的なエラー理由がここに書かれていることが非常に多いです。

2. `journalctl` の使い方と重要オプション

systemctl の簡易表示だけではエラー理由が入り切らず、省略されてしまっている場合は、systemdのログ管理システム（ジャーナル）を journalctl コマンドで詳しく検索します。

よく使うコマンドライン一覧

エラー（Error）ログのダイジェスト表示（-xe）
Terminal window
```
sudo journalctl -xe
```
システムログの末尾から、エラー箇所の前後をページャー（スクロール画面）で表示します。エラーに関する解説や対応のヒントが追加で表示されるため、最初に実行するのに適しています。
特定のサービスログのみに絞り込む（-u）
Terminal window
```
sudo journalctl -u nginx
```
Nginxのログだけを最初から時系列で表示します。
最新のログをリアルタイムで追跡監視する（-f）
Terminal window
```
sudo journalctl -f
```
Windowsのイベントビューアーのリアルタイム監視に相当します。このコマンドを起動したまま、別ターミナルでエラーの起きる操作を再現することで、「どの瞬間に、何のエラーが出たか」をリアルタイムに画面上で追うことができます。
時間帯を指定して絞り込む（--since）
Terminal window
```
sudo journalctl --since "1 hour ago"
sudo journalctl --since "2026-07-09 13:00:00"
```
「1時間前から現在まで」「特定の指定日時以降」に絞り込んで効率的に原因を探します。

3. `dmesg` の使い方とカーネルログの確認

OSやハードウェアに近い部分、またはプログラムがOSによって強制終了された場合は、カーネルが記録するリングバッファログ dmesg を使用します。

向いている主な場面

OOM Killer（Out Of Memory）の検知 プログラムがメモリを大量消費してシステムの空きメモリが枯渇した際、LinuxカーネルはOS全体のクラッシュを防ぐために、最もメモリを食っているプロセスを警告なしで強制終了させます。この記録はサービスのログには残らず、dmesg に「Out of memory: Killed process…」と出力されます。
ディスクエラー（I/Oエラー）の検知 HDDやSSDの物理セクタ破損、接続ケーブルの接触不良などが発生した場合に、カーネルが出力する読み書きエラーを確認できます。

4. ログ調査時に絶対に避けては通れないセキュリティと運用上の注意点

トラブルの原因がわからず、インターネット上のQ&Aサイト（Teratail、Stack Overflowなど）にログを貼り付けて質問する、あるいはチームの共有チャット（SlackやTeams）にログを投げる際には、以下の点に厳重に注意してください。

個人情報や秘密情報の黒塗り（マスキング）の徹底 エラーログの中には、Webサーバーへのアクセス元IPアドレス、メールアドレス、APIの認証トークン、DBのパスワード、SSHの秘密鍵のエラー情報、ドメイン名やサーバーのローカルIPなどがそのままプレーンテキストで出力されていることがあります。これらをそのままネット上に公開すると、直ちに重大なセキュリティ侵害につながります。貼り付ける前に、必ずテキストエディタ等でダミーの文字列（例：xxx.xxx.xxx.xxx や [SECRET_API_KEY] など）に書き換える作業を行ってください。
タイムゾーンの確認 ログ内の時刻が「JST（日本標準時）」なのか「UTC（協定世界時）」なのかを確認してください。サーバーのタイムゾーンがデフォルトのUTCになっている場合、日本時間のマイナス9時間でログが出力されているため、トラブルが起きた本当の時間帯を見失う原因になります。
- 関連情報：Linuxの脆弱性チェックとパッケージ管理コマンド
- 関連情報：Ubuntuでのタイムゾーンとロケール設定

FAQ（よくある質問）

Q1. `/var/log/syslog` や `messages` ファイルはもう見ないのですか？

A1. 現在のsystemdを採用した主要OSでは、journalctl を使うのが基本かつ推奨されています。 古いLinuxでは、テキストファイルとして /var/log/syslog（Debian/Ubuntu系）や /var/log/messages（Red Hat系）にシステムログが書き込まれており、tail コマンドなどで閲覧していました。現在も互換性のために残されていることが多いですが、journalctl を使う方が「フィルタリング機能が強力」「バイナリ形式で高速」「アクセス権限の管理がスマート」であるため、こちらに移行することをお勧めします。

Q2. 一般ユーザーの権限で `journalctl` を実行するとログが空だったりエラーが出ます。

A2. システムログの閲覧には管理者（root）権限が必要です。コマンドの前に sudo を付与して実行してください。 また、一般ユーザーを systemd-journal グループに追加することで、sudo をつけなくても自分の所属するユーザーでシステムログを閲覧できるように設定することも可能です。

Q3. ログのファイルサイズが肥大化してディスク容量を圧迫しています。削除してもいいですか？

A3. 直接ファイルを削除するのではなく、systemdの保持設定で制限してください。 journalctl のログは、/etc/systemd/journald.conf で最大保存容量（例：SystemMaxUse=1G）を設定したり、以下のコマンドを実行して「過去〇日分より古いログを安全に削除」することができます。

sudo journalctl --vacuum-time=7d

Q4. `systemctl status` で「lines 1-12/12 (END)」と表示されてターミナルが入力できなくなりました。

A4. 閲覧モードに入っています。キーボードの q キーを押すと終了し、元のターミナル入力画面に戻ります。 これは less というテキスト閲覧ツールが裏で動いているためです。矢印キーで上下スクロールも行えます。

Q5. サービスを起動しようとすると「Job for x.service failed」と一行だけ出て失敗します。

A5. この簡易メッセージが出たときは、即座に sudo journalctl -u <サービス名> -n 50 を実行してください。 systemdがサービス起動スクリプトの失敗を検知したものの、画面にはエラーの詳細を出力しきれなかった時にその表示になります。指定サービスの最新ログを確認すれば、必ず具体的なエラー理由が記載されています。