この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
セミナーや個別相談でこの質問を受けるたびに、私は「その疑問が出てきた段階で、あなたはすでに一歩先に進んでいます」と答えています。
この記事では、Linuxのログ読解がなぜ現場の仕事を根本から変えるのか、20年以上サーバーを運用してきた経験から、正直に話します。「ログを読む」というのは技術というより習慣の話です。
この記事のポイント
・ログを読む習慣があると障害の原因が数分で特定できる
・/var/log/ 配下の主要ログ4種類を押さえるだけで全体が見える
・ログを「読めない人」は問題が起きてから気づく、読める人は予兆をつかむ
・現場での信頼はログの読み方ひとつで決まる場面がある
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ログを「なんとなく見ている人」と「読んでいる人」の差
ログを開いているけれど何も分からない、という状態はよくあります。私がSE時代に先輩から言われた言葉があります。
「ログは問題が起きた後で読むものだと思っていたら、もう手遅れだ。」
当時はその意味がよく分かりませんでした。障害が起きたら tail -f /var/log/messages を開いて、エラーらしき行を探す——それで十分だと思っていたからです。
でも20年以上サーバーを運用してきた経験から言うと、ログの読み方が変わったのは「問題が起きてから見る」のをやめた瞬間でした。
日常的に、何もない時にもログを眺める習慣がつくと、「普通の状態」がわかります。普通の状態がわかると、「普通でない状態」に気づくのです。
まず覚えるべき主要ログファイルと役割
1. /var/log/messages（または /var/log/syslog）
システム全体の動きが記録される総合ログです。Linuxの教科書には「カーネルとシステムのメッセージ」とありますが、現場ではまずここを見る、という基準点として扱います。# /var/log/messages の末尾をリアルタイムで監視する tail -f /var/log/messages # 出力例（AlmaLinux 9.4 での実際の出力） May 4 23:11:34 sv01 kernel: [123456.789] EXT4-fs (sda1): mounted filesystem May 4 23:15:02 sv01 systemd[1]: Starting Network Manager... May 4 23:15:03 sv01 NetworkManager[987]:
Loaded config May 4 23:20:01 sv01 CROND[2341]: (root) CMD (/usr/sbin/logrotate /etc/logrotate.conf)
2. /var/log/secure（または /var/log/auth.log）
認証・ログイン関連の記録です。SSHの接続試行がすべて残ります。不審なアクセスを検知するために定期的に確認すべきファイルです。# SSH接続の失敗記録を抽出する grep "Failed password" /var/log/secure | tail -20 # 出力例（実際のサーバーで収集したもの、IPはマスク済み） May 4 03:12:45 sv01 sshd[4512]: Failed password for root from 203.x.x.x port 52341 ssh2 May 4 03:12:47 sv01 sshd[4513]: Failed password for root from 203.x.x.x port 52342 ssh2 May 4 03:12:49 sv01 sshd[4514]: Failed password for admin from 203.x.x.x port 52343 ssh2
3. /var/log/cron
cron（定期実行）の記録です。「cronが動いているか」を確認するために使います。「自動バックアップが実行されていない」「定期メール送信が止まっている」といったトラブルは、ここを確認すれば最初の手がかりが見つかります。# 昨日のcron実行記録を確認する grep "$(date -d 'yesterday' '+%b %e')" /var/log/cron | grep CMD # 出力例 May 4 02:00:01 sv01 CROND[1234]: (root) CMD (/usr/local/bin/backup.sh) May 4 02:00:03 sv01 CROND[1235]: (root) CMD (/usr/local/bin/backup.sh >> /var/log/backup.log 2>&1)
4. /var/log/httpd/error_log（Webサーバーの場合）
ApacheやNginxのエラーログです。Webサービスを運用する場合、ここは最優先で確認します。# Apacheエラーログの直近50行を確認 tail -50 /var/log/httpd/error_log # 出力例 [Mon May 04 23:45:12.123456 2026] [error] [pid 1234] ... [Mon May 04 23:45:13.234567 2026] [warn] [pid 1235] ...
「ログを読む習慣」が現場の見え方を変える3つの理由
1. 障害の原因特定が分単位から秒単位に変わる
ログを普段から読んでいない人は、問題が起きた時に「どこを確認すればいいか」の判断から始まります。ログを習慣的に読んでいる人は、「いつもと違う行がある」という感覚で絞り込めます。私がセミナーで受講生に伝えている例え話があります。
「部屋が散らかっている人は、なくし物をするたびに全部ひっくり返す。整理されている人は、なくした瞬間に『あの引き出しにないはずがない』という仮説が立てられる。」
ログも同じです。普段の状態を知っている人は、異常を「仮説として」絞り込めます。
2. 問題が起きる前の予兆をつかめるようになる
私が過去に運用していたサーバーでの話です。ある夜、/var/log/messages を眺めていたら、ディスクへの書き込みエラーが散発的に記録されているのを発見しました。# このようなエラーが散発的に記録されていた（実際の出力パターン） kernel: [error] EXT4-fs error (device sda1): ext4_find_entry:1455... kernel: [error] Buffer I/O error on device sda1, logical block 12345678
でも私はログを見ていたから気づいた。翌週、ディスクを交換しました。もし気づかなければ、本番サービスがダウンしていたかもしれません。
「問題が起きた後で読む」のと「予兆をつかむために読む」のでは、根本的に役割が違います。
3. ログで「証拠」を残せると周囲から信頼される
障害対応後の報告で、「たぶん問題の原因はネットワーク系だったと思います」と言う人と、「/var/log/secure の 03:12:45 のエラーから始まり、その2分後に /var/log/messages でサービス停止を確認しました」と言える人では、信頼度が違います。受講生からよく聞かれる質問が「ログってどこまで説明すればいいですか？」というものです。
私の答えは「タイムスタンプ・ファイルパス・エラー文字列の3点セットを示せれば十分です」。この3点があれば、誰でも後から検証できます。
ログを読む習慣を作るための具体的なステップ
1. 毎朝1分、/var/log/messages の最終100行を確認する
いきなり全部読もうとしない。まず「昨夜から今朝にかけて何が動いたか」を確認する1分を習慣にします。# 最終100行の確認コマンド tail -100 /var/log/messages # エラーだけを抽出して確認する場合 grep -i "error\|failed\|critical" /var/log/messages | tail -30
2. 「エラーが出ていないことを確認する」だけでいい
最初は「読む」ではなく「異常がないことを確認する」だけで十分です。明らかにおかしい単語（error、fail、critical）がないかをざっと眺める。これだけでも習慣として価値があります。3. エラーを見つけたら必ず調べて記録する
エラーを見つけた時に「まあいいか」で流すのが一番の機会損失です。原因を調べて、解決したらメモに残す。この繰り返しで「ログの語彙」が増えていきます。私のセミナーでは「ログ日記」と呼んでいます。エラーログを見つけて調べた記録を残すだけで、半年後には参照できる自分だけのナレッジベースになります。
ログローテーションとアーカイブの扱い
ログは時間が経つと自動的に圧縮・ローテーションされます。過去のログを参照する際には以下を知っておくと便利です。# ローテーション済みのgzipログを検索する zgrep "Failed password" /var/log/secure-20260504.gz # 複数のローテーションファイルをまとめて検索する zgrep "Failed password" /var/log/secure*.gz # /var/log/ 配下のログファイル一覧を確認する（サイズ付き） ls -lh /var/log/
journalctlで systemd ベースのシステムログを読む
AlmaLinux 9やUbuntu 24.04以降のシステムでは、journalctl を使うと systemd が管理するログをより精密に参照できます。# 今日のログをリアルタイムで監視する journalctl -f --since today # 特定サービスのログを確認する journalctl -u sshd.service --since "2026-05-04 00:00" --until "2026-05-05 00:00" # エラーと警告だけを絞り込む journalctl -p err -b # 出力例 May 04 23:11:01 sv01 sshd[4512]: error: PAM: Authentication failure for root May 04 23:11:03 sv01 sshd[4513]: error: PAM: Authentication failure for admin
ログを見たのに原因が分からない時のトラブルシュート
ログを開いても「どこを確認すればいいか分からない」という状態は、経験を積む途中では必ず来ます。そういう時のアプローチを3点挙げます。注意：ログを眺めているだけで満足しないこと。大量のログを眺めても、何を探しているかが分からなければ意味がありません。まず「何が起きているか」の仮説を立ててから、その仮説に合う文字列を grep で探す、という手順を踏むのが鉄則です。
・タイムスタンプで絞り込む：問題が起きた時刻の前後10分を grep で抽出する。全体を読もうとしない
・エラーレベルで絞り込む：error / critical / failed のキーワードだけを抽出し、warn は後回しにする
・サービス名で絞り込む：journalctl -u サービス名 で対象サービスのログだけを見る
# 特定時刻前後のログをタイムスタンプで絞り込む例 # 問題発生が「May 4 23:15」頃だった場合 grep "May 4 23:1[0-9]" /var/log/messages # critical/errorだけを抽出してタイムライン順に並べる grep -i "critical\|error" /var/log/messages | grep "May 4"
まとめ：ログは「読む技術」ではなく「見続ける習慣」
| 確認したいこと | 使うコマンド |
|---|---|
| システム全体の動作確認 | tail -100 /var/log/messages |
| SSH不正ログイン試行の確認 | grep "Failed password" /var/log/secure |
| cronの実行確認 | grep CMD /var/log/cron | tail -20 |
| エラーのみ抽出 | grep -i "error" /var/log/messages | tail -30 |
| systemdサービスのログ | journalctl -u サービス名 --since today |
| ローテーション済みログの検索 | zgrep "キーワード" /var/log/messages*.gz |
セミナーで3,100名以上を指導してきた中で、ログを日常的に読んでいるエンジニアとそうでないエンジニアの差は、障害対応のスピードだけでなく、「信頼されるかどうか」という部分にまで影響していると実感しています。
まずは今日から、1日1回 tail -100 /var/log/messages を開く習慣から始めてみてください。
Linuxログの読み方を体系的に学びたいあなたへ
ログの読み方が変わると、現場での動き方が変わります。
「どのログを確認すればいいか分からない」「エラーの意味がつかめない」という方もいるかもしれません。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxのセミナーで20年以上教えてきて最も後悔を聞く話｜3,100名を指導した講師が語る「早く始めれば良かった」の正体
- 前のページへ：障害発生時の第一報を上手く書ける人が現場で信頼される理由｜現役講師が教えるインシデント連絡の型
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます