業務ファイルをZIP圧縮しても小さくならない理由と実測

結論

ZIPにまとめても、元のファイルより必ず小さくなるわけではありません。 ファイル名などを記録する分が加わり、JPEGのように既に圧縮された中身は、追加の圧縮が効きにくい場合があります。当サイトの現行処理でも、圧縮ありを選んだ画像PDFが元より39バイト増えました。

MicrosoftのZIPの説明では、JPEGなどのファイルについて次の記載があります。

小さくならないという結果だけで、ZIPの作成失敗とは判定できません。 中身を元どおりに取り出せることと、保存容量が減ることは別の確認です。

ZIPには、中身を圧縮せずに保存する方式もあります。 Pythonの公式資料は、ZIP_STOREDを一次資料の節に引用したとおり説明しています。

当サイトのZIP分割には、無圧縮と圧縮ありの設定があります。現行処理は圧縮ありの場合も、ファイルごとに圧縮前後を比べ、中身のデータが小さくなる場合にだけ、その圧縮結果を採用します。 JPEGの寸法やPDFの画質を下げる処理ではありません。

その比較は中身のデータに対するものです。ファイル名などの記録が加わった、最終的なZIP全体の容量とは一致しません。

自作の3ファイルを、現行処理の無圧縮・圧縮ありで測りました（n=3入力、出力ZIPは6件）。 2026-10-01、各ZIPに1ファイルを入れ、元と出力のバイト数を数えています。

自作した入力	元の容量	無圧縮のZIP	圧縮ありのZIP
同じ英文を3,000回並べたテキスト	102,000	102,118	469
1,024角の疑似乱数画像をJPEG保存	865,026	865,142	865,142
同じJPEGを1ページに置いた画像PDF	865,988	866,104	866,027

単位はすべてバイトです。テキストは繰り返しの多い検証用データで、JPEGは実写写真ではありません。この3例を、業務書類全体の平均圧縮率として扱うことはできません。

JPEGの中身を圧縮した試行値は865,069バイトで、元より大きくなりました。そのため現行処理は圧縮結果を採用せず、無圧縮と同じZIPを出力しました。設定が圧縮ありでも、内部の各ファイルが必ず圧縮方式になるわけではありません。

全6件を別のZIP読取処理で展開し、元ファイルとのバイト一致とCRC検査を確認しました。 テキストの圧縮ありとPDFの圧縮ありはDeflate方式、JPEGの圧縮ありは無圧縮方式でした。容量だけでなく、中身の保持も照合しています。

画像PDFの圧縮データは77バイト減りましたが、ZIPの記録116バイトが加わりました。 865,988−77＋116＝866,027バイトとなり、最終出力は元のPDFより39バイト大きい結果です。

ZIPの仕様書は、ローカルファイルヘッダーに次の項目を定めています。

ファイル名などを格納する記録は、ZIPに含まれる実データ以外の部分です。 今回はファイル名が異なるため、テキストの追加分は118バイト、JPEGとPDFは116バイトでした。この値は今回の出力に限られ、ファイル数・名前・追加情報が変われば同じとは限りません。

ZIPを繰り返し作ることと、PDF内の画像の解像度や画質を調整することも別です。後者は見え方が変わる可能性があり、容量だけを比べても適否は決まりません。

本文で参照した一次資料の引用と出典をまとめます。

「既に高度に圧縮されています。」

「アーカイブメンバを圧縮しない」

— Python「zipfile — ZIPアーカイブの処理」、ZIP_STORED https://docs.python.org/ja/3/library/zipfile.html（2026-10-01 到達）

“file name (variable size)”

— PKWARE「APPNOTE.TXT」、6.3.10・4.3.7 Local file header https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT（2026-10-01 到達）

実写写真、複数ファイルの組合せ、暗号化ZIP、メール送信、WindowsやMac標準機能の操作は測っていません。 他の圧縮方式との速度比較や、画質を下げた場合の読みやすさも対象外です。繰り返しテキストの結果を通常の文書へ外挿していません。

元ファイルの容量、ZIPの容量、展開後の中身を一組で比べることが入口です。ZIPの容量が減らなくても中身が正常な場合はあり、圧縮の設定とファイル自体の性質を分けて読むと、結果を理解しやすくなります。