何万行もあるログファイルを前に、どう絞り込もうかとターミナルに向かって落ち着いて考えている一人運用の保守担当者
障害対応・運用監視約11分

大量のログからエラーを絞り込む｜grep・tail・lessの実務術

「エラーが出ているらしいので、ログ見てもらえますか」。 そう言われて開いたログが、何万行もある1枚のファイル。スクロールバーが米粒みたいに小さくて、正直、どこから見ればいいのか気が遠くなりますよね。

一人で保守運用をしていると、こういう場面がしょっちゅうあります。全部を上から読む時間はない。でも、原因の1行はこのどこかに必ずいる。 そんなとき、実は道具は3つで足ります。grep（絞る）・tail（新しい方から見る）・less（大きいまま安全に開く）。この3つの使い分けさえ体に入っていれば、何万行あっても迷子になりません。

この記事では、大量のログからエラーを絞り込む順番を、コマンドの具体例つきで一緒に整理します。難しい正規表現は使いません。まず今日から手が動く形にしておきましょう。

結論：ログを絞るときは、①tail で「今も出ているか・いつまで出ているか」を掴む → ②grep で「エラーだけ」に絞る → ③grep の前後表示や less で「その1件の前後」を読む、の順です。いきなり全部を読まず、「新しい方から見て、エラー行だけ拾って、当たりの前後を広げる」。この3手だけで、たいていの原因にたどり着けます。

コマンドやログのパスは、環境（Linuxのディストリビューション、Webサーバー、アプリ）で少しずつ変わります。この記事の例は出発点として、自分の現場のパスやログ形式に置き換えて使ってください。

その前に：巨大なログを cat で開かない

まず一つだけ、事故を避けるための約束です。 数百MB〜数GBあるログを、cat や普通のエディタで丸ごと開こうとすると、画面が固まったり、サーバーのメモリを食いつぶしたりすることがあります。障害対応の最中に、調査のせいで別のトラブルを起こしたら本末転倒です。

大きいログは、丸ごと開かず、必要なところだけ切り出して見る。そのための3つが tail・grep・less です。まずファイルの大きさを ls -lh ログファイル で確かめる癖をつけておくと、「これは重いから慎重に」と一呼吸置けます。

① tail：まず「新しい方」から見る

障害の多くは「今まさに」か「さっきから」起きています。だから最初に見るべきは、ファイルの末尾＝いちばん新しい行です。

tailで新しい方を掴み、grepでエラーだけに絞り、その前後を読む、という3段階の絞り込みの流れを示した図
上から順に。まず末尾を見て、エラーだけ拾い、当たりの前後を広げる

今どんな行が出ているか、直近の様子がひと目で分かります。-n の数字は好みで増減できます。

問題の操作を自分で再現しながら「今この瞬間、何が出るか」を見たいときに使います。止めるときは Ctrl + C。

流れてくる行のうち、error を含むものだけが画面に出ます（-i は大文字小文字を区別しない指定）。

まず tail で「今も出続けているのか、さっき止まったのか」を掴む。これだけで、次にどれくらい急ぐか、どこを狙うかの見当がつきます。

② grep：エラー行だけに絞る

新しい方の様子が掴めたら、次は本命です。何万行の中から、エラーに関係する行だけを引き抜きます。ここが grep の出番です。

error という文字を含む行だけを表示します。まずはこれで十分なことが多いです。

エラーは error 以外の言葉で記録されることもあります。-E を付けて |（または）で並べると、まとめて拾えます。

「何件くらい出ているのか」を先に知ると、全体障害か、たまに出るだけかの見当がつきます。多すぎるときは、次の「時刻で絞る」に進みます。

監視のヘルスチェックなど、無視していい行が混じるときは、grep -v（除外）でノイズを減らせます。

時刻や特定のIDで、さらに狭める

エラーが多すぎるときは、「いつ」「どの処理」で区切ると一気に見やすくなります。

障害が起きた時間帯が分かっているなら、その時刻の文字列で絞るのが手っ取り早いです（ログの時刻表記に合わせてください）。

抜き出した結果をファイルに保存しておくと、あとで落ち着いて読めますし、報告にも添えられます。調査の途中でログがローテーション（古いものが消える設定）で消えても、手元に証拠が残ります。

複数ファイルにまたがっているとき（app.log、app.log.1 など）は、grep -i error app.log* のようにまとめて検索できます。「昨日から出ていた」ようなケースは、これで古いファイルまで一度に拾えます。

③ 前後を読む：エラーの「1行だけ」では分からない

エラー行を見つけても、その1行だけでは原因が分からないことがよくあります。本当のきっかけは、たいていそのすぐ前の数行にいます。だから「当たりの前後」を一緒に見ます。

-C 5 は「見つかった行の前後5行も表示」という指定です。前だけなら -B 5、後ろだけなら -A 5。スタックトレース（エラーの発生経路の記録）は複数行に渡るので、-A を大きめにすると全体が読めます。

less は大きなファイルでも軽く開けるビューアです。開いたあと /error と打って Enter で検索、n で次の一致へ移動できます。行き来しながら前後の文脈を読むのに向いています。終わるときは q。

+G を付けると、開いた瞬間にファイルの末尾（最新）へ飛びます。tail で当たりを付けてから、じっくり読むのに便利です。

エラー行の少し前に「何を実行しようとしていたか」「どこへ接続しようとしていたか」が残っていることが多いです。1行で判断せず、前後を含めて「物語」として読むと、原因の姿が見えてきます。

長いスタックトレースや見慣れない例外で当たりが付かないときは、そのエラー行と前後の数行をAIに渡して、一次解析やあたりづけを手伝ってもらうのも一つの手です。「どこで何を待って失敗していそうか」「次に見るべき箇所はどこか」を要約させると、潜る場所を絞る時間を短くできます。ただしAIの説明はそう見えるという仮説であって答えではありません。接続先・鍵・個人情報などの機微な情報は渡す前に伏せ、示された原因は必ず実物のログで裏を取り、再現確認と最終判断は人がやる——この順番だけは崩さないでください。

具体例：3つの「絞り込み」のたどり方

3手を当てはめると、こんなふうにたどれます。

共通するのは、いきなり全部を読まないこと。新しい方から見て、エラーだけに絞って、当たりの前後を広げる。入口を決めれば、読む量は自然と減ります。

影響：絞り込む順番を持っておくと、何が変わるか

tail・grep・less の3手を持っておくと、調べるのが速くなるだけでなく、気持ちが落ち着きます。

逆に、毎回ゼロから勘でスクロールしていると、同じログでも、たどり着くまでの時間が日によって大きく変わってしまいます。3手を決めておくだけで、その差がぐっと小さくなります。

明日やること：よく使う3〜4本を「自分用メモ」にする

いきなり全部を覚える必要はありません。明日できる、いちばん小さな一歩はこれです。

  1. 今いちばん見る機会の多いログを1つ思い浮かべる（アプリのログ、Webサーバーのログなど）。
  2. そのログのパスと一緒に、次の3〜4本をコピペできる形でメモしておく。
  1. パス の部分を、自分の環境の実際のパスに置き換えて保存する。
  2. 次に「ログ見て」と言われたとき、そのメモから貼るだけで手が動く状態にしておく。

完璧なコマンド集を目指さなくて大丈夫です。よく使う3〜4本が、自分の環境のパス入りで貼れるだけで、次からの調査がぐっと楽になります。

「ログの絞り込み」チェックリスト

これは「自分のログ調査メモが揃っているか」を平時に確かめるための確認用で、本番中に全部やる前提ではありません。コピーして、自分のメモに当ててみてください。

全部に○が付かなくても大丈夫です。まずは tail と grep の2本が自分のパス入りで貼れれば、次にログを開くときの「どこから」で固まらずに済みます。残りは、次の調査のときに1本ずつ足していけば十分です。

よければ、こちらも

ログの絞り込みは、障害対応や問い合わせ調査の途中で必ず通る作業です。前後の段取りもあわせて1枚にしておくと、当日とても楽になります。

大量のログから原因の1行を見つけ出し、椅子に背を預けてほっと一息つく保守運用の担当者

何万行ものログは、開いた瞬間は本当に気が重いものです。でも、原因の1行は必ずそのどこかにいます。新しい方から見て、エラーだけに絞って、前後を読む。この3手さえ手に馴染んでいれば、ログの海で溺れることはありません。 今日は、よく使う3〜4本を自分の環境のパス入りでメモしておくだけで十分です。次に「ログ見て」と言われたとき、その一枚が、あなたを迷子にさせず原因まで案内してくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語