Linuxログ調査の基本コマンド集（grep, awk, tail）：巨大ログと戦う技術

「障害が発生した。至急ログを確認して原因を特定してくれ！」

そんな緊迫した場面で、あなたはどうやってログを調査していますか？ 数GBを超えるような巨大なログファイルを前に、いつもの癖で vi や cat を実行しようとしているなら、少しだけ待ってください。その一打が、さらなる悲劇を招くかもしれません。

今回は、インフラエンジニアとして18年間、数多くの現場でログと格闘してきた私が、「巨大ログを安全に、かつ迅速にさばくための実践テクニック」を、愛用の基本コマンドとともに紹介します。

【警告】巨大ログを 「vi」で開いてはいけない

まず、鉄則中の鉄則です。数GBクラスのログを vi などのテキストエディタで開くのは、非常に危険な行為です。

• メモリの枯渇： エディタはファイルをメモリ上に読み込もうとします。巨大なファイルを読み込んだ瞬間、メモリを食いつぶし、最悪の場合は OOM Killer（OSがメモリ確保のためにプロセスを強制終了させる仕組み）が発動して、稼働中のサービスを停止させてしまう恐れがあります。
• システムのフリーズ： 巨大なスワップファイルが作成され、ディスクI/Oを圧迫。操作が一切受け付けられなくなることもあります。

巨大なログは「開く」のではなく、これから紹介するコマンドを使って「必要な部分だけを抜き出す」のがプロの作法です。

【tail】「今」何が起きているかを最速で知る

ファイルがどれほど巨大でも、末尾の数十行だけを読み取る tail は非常に軽量で安全です。

• 実践例：特定のエラーをリアルタイム監視する

エラーを色付きで強調しながら、リアルタイムに監視

tail -f /var/log/syslog | grep --line-buffered --color=auto -i "error"

tail -f は基本ですが、grep と組み合わせる際は --line-buffered を付けると、バッファ溜まりによる表示遅延を防げるのでおすすめです。

詳細リファレンス：tail (日本語)/tail (English)

【grep】膨大なノイズから「真実」を抜き出す

調査の要となるのが grep です。私が現場で助けられた3つの実践例を紹介します。

混在したログから「特定のホスト」を分離する

統合ログサーバのように、複数台のサーバからログが集約されている環境では、まず対象を絞る必要があります。

特定のホスト名 “web-server-01” のログだけを抽出して別ファイルに保存

grep "web-server-01" /var/log/remote_combined.log > web01_investigation.log

大文字・小文字を無視して「正常性」を一括確認

「エラーが出ていないこと」を確認するのも重要な仕事です。-i オプションで表記の揺れをカバーします。

Error, ERROR, Warningなどをまとめて検索

grep -Ei "error|warning|critical" /var/log/app.log

特定の「時間帯」を狙い撃つ

「14:05分頃に何が起きたか」を探す際、正規表現で時間を指定すると瞬時に絞り込めます。

14:00〜14:09のログを抽出

grep "2026-02-14 14:0" /var/log/syslog > 1400_incident.log

詳細リファレンス：grep (日本語)/grep (English)

【awk】ログを「報告書に貼れるデータ」に変える

awk は、特定の列（カラム）だけを抜き出すのに非常に便利です。

• 実践例：日時とエラーメッセージだけを抜き出す

第1列（日付）と第5列（メッセージ）だけを表示

awk '{print $1, $5}' /var/log/auth.log

調査結果をチャットや報告書に貼る際、不要な列を awk で削っておくだけで、情報の伝わりやすさが劇的に変わります。

詳細リファレンス：awk (日本語)/awk (English)

コマンドで必要な情報を抽出できても、そのエラーが何を意味するのか、どう対処すべきかを読み解くには時間がかかります。

最近では、抽出したログを生成AIに読み込ませて、原因の要約や解決策の提案を受けることで、調査スピードを劇的に上げることが可能です。以下の記事もあわせてチェックしてみてください。

あわせて読みたい

18年の現場経験で分かった！インフラエンジニアの生成AI活用術｜スクリプト作成から障害対応まで 「深夜のアラート対応で起こされ、膨大なエラーログと格闘する……」「定型的なシェルスクリプトや環境構築コードの作成に何時間も取られる……」 日々の運用保守や構築作業…

【巨大ログ攻略】さらに一歩進んだテクニック

数GBのログを扱うなら、以下の2点も覚えておきましょう。

1. 解凍せずに戦う (zgrep)： ログローテーションで圧縮された .gz ファイルは、解凍せずに zgrep で直接中身を検索しましょう。ディスク容量と時間の節約になります。
2. パイプの順番を意識する： grep | awk の順で使いましょう。最初に grep で行数をガッツリ減らしてから awk に渡すのが、最も処理効率が良い（CPU負荷が低い）方法です。

まとめ：コマンドは「思考の武器」

ログ調査の速さは、単なるスキルの証明ではなく、「システムを安定させたい」というエンジニアの誠実さそのものです。

最新のログ分析ツールも便利ですが、トラブルの現場で最後に頼りになるのは、やはり grep や tail といった基本コマンドです。これらを自在に組み合わせ、巨大なログの中から「真実」を最短ルートで掴み取りましょう。

また、ログ調査は、原因を特定して終わりではありません。

特定した事実を整理し、ステークホルダーへ正確に伝える『報告』までがインフラエンジニアの大切な仕事です。18年の現場経験で磨いた、技術的な調査結果を『通る報告書』へと落とし込むための構成案についても、こちらの記事で詳しく解説しています。

あわせて読みたい

サーバ200台の現場で学んだ「通る報告書」の鉄則〜マネージャーが本当に求めている3つの情報〜 「復旧作業でヘトヘトなのに、やっと出した報告書が『これじゃわからない』と突き返された……」 「結局、何が悪かったの？と聞かれて言葉に詰まってしまった……」 インフ…