ログとは、コンピューターやシステムが「いつ、何をしたか」を残した記録です。人でいう日誌やメモに近く、障害が起きたときに原因をたどる手がかりになります。画面が動かない、処理が遅い、エラーが出る。そんなときは、まずログを見て「どこで何が起きたか」を確認します。
ただし、ログは読めばすぐ答えが出る魔法の紙ではありません。大事なのは、症状の起きた時刻や場所をそろえて、必要な記録だけを順番に見ることです。この記事では、ログの基本、身近なたとえ、実務での見方、図解、クイズまでまとめて整理します。
ログの基礎を先に押さえる
ログは、システムの動作記録です。たとえば「ログインに成功した」「商品一覧を開いた」「エラーで止まった」「誰が設定を変えた」といった出来事が残ります。すべての記録が同じではなく、よく使うものには次のような種類があります。
- アクセスログ：誰が、いつ、どの画面やURLに来たかの記録
- エラーログ：失敗や例外が起きたときの記録
- アプリケーションログ：アプリの中で起きた処理の流れ
- 操作ログ：人が何をしたかを残す記録
ログを見る目的は、「何が起きたか」を確かめることです。原因を決めつける前に、事実を集める道具だと考えるとわかりやすいです。とくに、クライアントとサーバーの違いを意識すると、どこで記録が残るかを整理しやすくなります。画面側の動きはフロントエンドとバックエンドの違いで分けて考えると、ログの場所も見えやすくなります。
また、ログは保存される場所や名前が環境によって少し変わります。開発中に見える内容と、本番で見える内容が同じとは限りません。調査では、開発環境と本番環境の違いも一緒に確認するのが大切です。
調べるときは、文字で操作する場面が多いので、コマンドラインを使ってログを開くこともよくあります。検索や絞り込みをしたいときに便利です。
身近なたとえで考える
ログは、学校のクラス日誌や駅の改札記録に近いです。たとえば、クラス日誌には「誰が休んだか」「どんな連絡があったか」が残ります。あとから「今日は何があったのか」を確認できますよね。ログも同じで、あとから出来事をたどるための記録です。
もう少し実務に近い例でいうと、宅配便の追跡番号がわかりやすいです。荷物がどこで止まったのか、いつ移動したのかを順番に見られます。システムのログも、時刻順にたどると「どの処理までは進んだか」「どこで止まったか」が見えてきます。
ただし、ログは荷物の追跡と違って、1つの画面を見れば終わりではありません。ブラウザ、アプリ、サーバー、データベースのように、複数の場所に分かれて記録されます。だからこそ、デバッグの考え方と組み合わせて、順番に切り分けることが重要です。
実務ではどう使うのか
では、仕事の現場でログはどう使うのでしょうか。よくある流れは、次のようになります。
- まず、障害の起きた時刻を確認する
- 次に、どの画面や機能で起きたかを確認する
- その時刻前後のログを開く
- エラー文、警告、処理の途中で止まった行を探す
- 必要なら、再現条件をしぼってもう一度確認する
たとえば「保存ボタンを押したら失敗した」という連絡が来たとします。このとき、いきなり全部のログを読むのではなく、まず失敗した時刻を見ます。次に、その時刻の少し前後を見て、保存処理の開始、入力チェック、送信、結果の順に追います。ログには成功の流れも失敗の流れも残るので、どこで止まったかを探しやすくなります。
ここで役立つのが、ログの中にある日時、URL、ユーザーID、リクエストIDのような手がかりです。これらを使うと、似た記録の中から対象だけを絞れます。もし複数人が同時に使っているシステムなら、時間だけでなく対象の画面や操作内容も合わせて見ると、取り違えを防げます。
また、ログは原因調査だけでなく、再発防止にも使います。障害のときに何が起きたかを記録として残しておくと、次に同じ問題が起きたときの比較材料になります。確認の考え方は、テストにもつながります。期待した動きと実際の動きを見比べるからです。
なお、ログには個人情報や秘密情報が含まれることがあります。調べやすさは大切ですが、見てよい人、残してよい内容、共有してよい範囲はルールに合わせて扱いましょう。
図解で整理
ログ調査は、次の順番で考えると迷いにくくなります。
よくある疑問：ログを見れば、すぐ原因がわかりますか？
すぐ断定はできません。ですが、いつ・どこで・何が起きたかを整理する大切な手がかりになります。
- 症状を確認する：何が起きたかを一言で言えるようにする
- 時刻をそろえる：画面の時刻、通知、依頼時間を合わせる
- 見る場所を決める：画面、アプリ、サーバーなどに分ける
- 必要なログだけ読む：前後の流れを中心に確認する
- 仮説を立て直す：思い込みではなく記録を根拠に考える
この流れを頭に入れておくと、ログは「読みにくい記録」ではなく「原因を探す地図」になります。最初から全部を読む必要はありません。どこから見ればよいかを決めることが、実は一番大事です。
コマンドでログを調べるときは、コマンドラインで「読む」「追う」「探す」を分けると考えやすくなります。たとえば、全体を読む、末尾を追う、特定の文字を探す、というように目的で使い分けます。
まとめ
ログとは、システムの動作記録です。障害対応では、まず症状の時刻と場所をそろえ、その前後の記録から事実を集めます。ログは答えそのものではありませんが、原因を見つけるための大事な手がかりになります。デバッグやテストと組み合わせて、落ち着いて順番に確認するのがコツです。
「どこで、いつ、何が起きたか」を読む習慣がつくと、ログは難しい専門用語ではなく、現場で頼れる道具になります。
図解のイメージでは、ユーザーの操作から画面、アプリ、サーバーへと流れ、その途中ごとにログが残ると考えると整理しやすいです。調査では、デバッグの視点で仮説を立て、必要ならプルリクエストの前に確認を増やす、といった使い分けも役立ちます。
クイズで確認しよう
問1. ログの役割として、いちばん近いものはどれでしょうか。
A. 画面の色をきれいにする機能
B. システムの動作をあとから確認できるように残す記録
C. 画像を圧縮する機能
D. パスワードを自動で作る機能
答えを見る
答え：B. システムの動作をあとから確認できるように残す記録
問2. 障害調査で、ログを見る前に先にそろえたい情報として適切なものはどれでしょうか。
A. そのときの時刻や、どの画面で起きたか
B. 好きな色
C. パソコンの重さ
D. 机の材質
答えを見る
答え：A. そのときの時刻や、どの画面で起きたか
問3. ログを使うときの考え方として、より近いものはどれでしょうか。
A. まず思いついた原因を決めてしまう
B. 記録を見て事実を集め、少しずつ原因をしぼる
C. ログは読まずに再起動だけする
D. 毎回すべての記録を最初から最後まで読む
答えを見る
答え：B. 記録を見て事実を集め、少しずつ原因をしぼる
