gzip・zcat入門｜ログを圧縮したまま読む基本

ログを追いかけようとしたら、目当ての日付のファイルが .gz になっていた。

サーバーのログは放っておくと容量を食うので、古いものから自動で圧縮されていく運用がほとんどです。

そのたびに展開して、読んで、また片づける。

この往復は、実のところ必要ありません。

gzip で固めたファイルには、展開せずにそのまま読む手段がひととおり用意されているからです。

今回は gzip と zcat を軸に、圧縮したままログを扱う基本を整理しました。

本文の実行例は、Windows の Git Bash（GNU bash 5.2.37 / gzip 1.13）で実際に動かして出力を確認したものです。

gzip は元のファイルを置き換える

まずは圧縮そのものから見ていきます。

2万行のダミーログを作って、gzip にかけてみましょう。

$ seq 1 20000 | sed 's/^/2026-08-26 INFO request id=/' > app.log
$ ls -l app.log
-rw-r--r-- 1 user 648894 Aug 26 10:19 app.log

$ gzip app.log
$ ls -l app.log.gz
-rw-r--r-- 1 user 51362 Aug 26 10:19 app.log.gz

ここで真っ先に押さえたいのは、gzip は圧縮すると元の app.log を消してしまうという挙動。

tar や zip のように「新しい書庫を横に作る」のではなく、ファイルそのものを置き換えにいきます。

今回の実測では 648,894 バイトが 51,362 バイトになりました。

同じ書式の行が並ぶログなので、9割以上が削れている計算です。

圧縮率は gzip -l でも確認できます。

$ gzip -l app.log.gz
         compressed        uncompressed  ratio uncompressed_name
              51362              648894  92.1% app.log

元ファイルを残したまま圧縮したいなら -k を付けるだけ。

別名で保存したいときは -c で標準出力へ流し、自分でリダイレクト先を決めます。

$ gzip -k app.log          # app.log と app.log.gz が両方残る
$ gzip -c app.log > backup.log.gz   # 名前を変えて保存

バックアップ用に世代名を付けて置きたいときは、後者のほうが素直です。

展開せずに読む zcat・zgrep・zless

本題はここから。

.gz を読むのに、いちいち gunzip で戻す必要はありません。

$ zcat app.log.gz | head -3
2026-08-26 INFO request id=1
2026-08-26 INFO request id=2
2026-08-26 INFO request id=3

$ zcat app.log.gz | wc -l
20000

zcat は中身を展開しながら標準出力へ流すだけなので、ディスク上に展開後のファイルは残りません。

パイプの先は head でも wc でも awk でも、生ログを相手にするときと同じ道具が使えます。

検索したいなら、grep に対応する zgrep がそのまま用意されている。

$ zgrep 'id=12345$' app.log.gz
2026-08-26 INFO request id=12345

$ zgrep 'code=5' *.log.gz
b.log.gz:2026-08-25 ERROR code=5

ありがたいのは、ワイルドカードで複数の圧縮ログをまとめて串刺しにできる点です。

ヒットした行にはファイル名が頭に付くので、どのローテーション分に当たったのかも一目で分かります。

ページャで前後を追いたいときは zless、2つの圧縮ログを比べたいときは zdiff。

ひとつだけ、引っかかりやすい落とし穴。

圧縮されていないファイルを zcat に渡すと、not in gzip format と言われて止まります。

$ zcat app.log
gzip: app.log: not in gzip format

拡張子が .gz かどうかで zcat と cat を使い分ける、という前提だけは崩さないでおきましょう。

圧縮レベルと、tar との住み分け

圧縮の強さは -1 から -9 で指定でき、既定は -6 です。

同じ 648,894 バイトのログで、3段階を比べてみました。

$ gzip -1 -c app.log | wc -c
53242
$ gzip -6 -c app.log | wc -c
51362
$ gzip -9 -c app.log | wc -c
50484

-1 と -9 の差はおよそ 5%しかなく、そのぶん -9 は圧縮に時間がかかります。

ログのように「とりあえず容量を減らせればいい」用途なら、既定のまま触らないのが無難でしょう。

もうひとつ、gzip は1つのファイルを1つのファイルに圧縮するだけで、複数をまとめる機能を持ちません。

ディレクトリごと固めたいなら、そこは tar の役目になります。

tarコマンド入門｜ファイルをまとめる・圧縮する・展開する

複数のファイルを1つにまとめて圧縮できる tar コマンドの基本を、作成・展開・中身の確認の3操作に絞って整理しました。czf と xzf の使い分けや、よくある失敗の避け方まで具体例つきで解説します。

あわせて読みたい

逆に、日次でローテーションされる単体のログを相手にするなら、gzip だけのほうが取り回しは軽い。

そして読むときの流れは、tail や less で生ログを追うときとほとんど同じ形です。

tail・head・less入門｜巨大ログを速く読む基本

head・tail・less の3つで、ログの先頭・末尾・途中を素早く読む基本を整理。tail -f と -F の違い、head と tail を組み合わせた行範囲の切り出し、less のキー操作まで、そのまま打てる形でまとめています。

あわせて読みたい

最後に

.gz を見つけたらまず展開する、という反射をやめるだけで、ログ調査はずいぶん軽くなります。

読むだけなら zcat と zgrep、まとめて固めたいときは tar。

この住み分けさえ頭に入れておけば、圧縮されたログも生ログと同じ感覚で扱えるようになります。

以上です。