多くの人は圧縮ツールを選ぶとき、世間に広く流布したいくつかの言説を頼りに判断している。どれももっともらしく聞こえるが、実際の文書に当てはめると頻繁に躓く。まずはそれらを並べ、一つずつ解体し、その上で本当に動くエンジニアリングがどういう姿をしているかを見ていこう。
よくある「常識」
一つ目、圧縮率を高く謳っているほど凄い。誰が 90% と書こうものなら、そのツールが優れているという。
二つ目、すべてのファイルは大幅に圧縮されるべきで、圧縮できないならツールがダメなのだ。
三つ目、オンラインの圧縮サイトもローカルツールも結果は同じ、どうせ圧縮するのだから。
四つ目、圧縮はファイルを傷つけ、印鑑や署名は圧縮すればぼやけてしまう。
五つ目、圧縮は一度で終わる作業で、一つのスライダーがすべての形式をこなす。
この五つは、どれも足元が覚束ない。
誤解その一：圧縮率が高いほど良い——その誤りは「絶対値」を物差しにしている点にある
圧縮率は絶対値ではなく、あくまで「冗長」に対する比率だ。シャノンは情報理論において、あるデータのうち文脈から予測可能な部分はすべて冗長であり、圧縮ができるのはそうした冗長をより短い符号で再表現し、そのデータの「情報エントロピー」の下限に近づけることだけだと結論づけている。
分かりやすい例を挙げよう。日本語において「の」は極めて頻出し、「霾（ばい）」のような字はまれだ。よく出る字には短いビットを、珍しい字には長いビットを割り当てれば、全体の長さは「すべての字を同じ長さにする」よりずっと短くなる。圧縮アルゴリズムは情報を消すのではなく、予測できる部分にこれ以上ビットを払わないだけだ。
問題はこうだ。JPEG、MP4、ZIP、そして PDF 内で既に最適化された画像のように、エントロピー限界に近い形式はこれ以上圧縮する余地が極めて小さい。これはツールが弱いのではなく、土台がすでに天井に達している。本当に問うべきは「あなたのそのファイル種別において、冗長の占める割合はどれほどか」であって、他人の宣伝にある 90% を凝視することではない。高い数字を売りにするツールは、往々にして特定のサンプルでのみ成り立つ。
誤解その二：圧縮できないのはツールが悪い——その誤りは「ファイル自身の土台」を無視している点にある
文書と文書の差は、多くの人が思うよりずっと大きい。最適化されていない PDF、Office 文書、スキャン原稿には、容積の中に大量の冗長が潜んでいる。同じ会社のロゴや同じフォントが数十ページにわたって参照ではなく埋め込まれ続けていたり、多くのスクリーンショットやスキャンが表示に必要な解像度をはるかに超えて保存されていたり、編集履歴や冗長な構造ツリー、隠れたサムネイルも黙って場所を取っている。
こうした冗長を除けば、六割から八割は圧縮できることが多い。逆に、既に圧縮された画像や、既に固められたコンテナは、もともと冗長が少ないから圧縮できないのが通常だ。だから「圧縮できない」は、多くの場合ファイルの土台が薄いからであり、エンジンが悪いからではない。圧縮の効果を見るには、まずそのファイルにどれだけ絞れる水分があるかを見なければならない。
誤解その三：オンラインもローカルも同じ——その誤りは「データの外部流出」を軽視している点にある
圧縮は計算集約的だが、極めてセンシティブな操作でもある。まだ署名されていない契約書や、顧客情報を含む帳票をどこかのオンライン圧縮サイトに放り込めば、ファイルはその瞬間、あなたのデバイスを離れ、第三者のサーバーに入ってしまう。IBM の 2025 年データ漏洩レポートには見落とされがちな数字がある。データ漏洩の成因の 26% が人的ミスによるもので、外部からの攻撃よりも地味だが、より一般的なのだ。機密ファイルを出所の怪しいオンラインツールに任せることは、まさにこの避けられたはずの人的露出にあたる。
ローカルで完結させるのがより堅いパラダイムだ。データは最初から最後までデバイスを離れず、プライバシーの帳尻は自然に合う。ローカルでの一括処理なら、ネットワーク帯域や同時実行の制限も受けない。コンプライアンスの最低ラインを満たす必要のあるチームにとって、「処理過程でデータを内部ネットワーク外に出さない」ことを要件として課すのは、事後の監査より頼りになることが多い。
誤解その四：圧縮すると印鑑がぼやける——その誤りは「ロスレスとロスありの境界」を分けていない点にある
工学的に圧縮は二つに分かれる。ロスレス圧縮は、展開後に元ファイルとバイト単位で一致することを保証する。文書、コード、データのように「一バイト違えばエラーになる」こうした内容はロスレスを通らねばならない。一方ロスあり圧縮は、人間の目や耳が敏感でない細部をあえて捨てて容積を得る。画像、動画、音声が頼るのは知覚符号化であり、人間の視覚が高周波の細部や色の色度に鈍感な特性を利用し、気づかれない情報を先に除くのだ。
難しいのは、PDF や Office 文書は本質的に「ハイブリッド体」だという点だ。そこにはロスレスでなければならない文字構造とベクターグラフィックスがあり、同時にロスありで処理してよいビットマップ、スクリーンショット、スキャン面が大量に内包されている。一つのパラメータで無理に圧縮するからこそ、守るべき文字構造を壊したり、既に最適化された画像に無駄な力を尽くしたりする。正しいやり方は分割して治めることだ。文字と構造はロスレス経路を通り、内包された画像リソースは知覚符号化ごとに個別に再符号化し、重複オブジェクトは重複排除して、それぞれがそれぞれの最適解をたどる。
これもまた、なぜアーカイブの現場で版式の保全が重視されるのかを説明している。電子記録のアーカイブ基準では、圧縮は冗長部分のみを削り、レイアウトや検証可能性を損なってはならない。圧縮はあくまで冗長に手を付けるだけで、版式や検証可能性には触れられないから、その要求そのものとは矛盾しない。
誤解その五：一つのスライダーですべてをこなせる——その誤りは「シチュエーションのトレードオフ」を過小評価している点にある
圧縮は決して「小さければ小さいほど良い」ではなく、あなたの制約の下でちょうど良く圧縮することだ。三つの典型的なシチュエーションでは、トレードオフがまったく異なる。アーカイブの現場では時間はボトルネックではないから、より強く圧縮して長期保存と転送コストの最小化を狙える。メール添付の現場では送り出せる大きさまで圧縮することが目標で、同時に印鑑、署名、表は鮮明に読める状態を保ち、品質優先となる。ウェブとモバイルの現場では軽量さ優先で、開く速さも両立させる。
さらに進んだ工学的価値は「形式を越えた統一基準」にある。同じバッチのファイルが、PDF、画像、Office のいずれであっても、圧縮後に比較的そろった容積の幅に収まるなら、一つずつ「今回は小さすぎないか、大きすぎないか」と推し量る必要がなくなる。
これらの認識をどうエンジニアリングに落とすか
上の五つを地に足つけて実践するなら、まともに戦える圧縮エンジニアリングには少なくとも四つの備えが要る。
一つ目、分割して治めるパイプライン。文字構造はロスレス、内包画像は知覚符号化で再符号化、重複オブジェクトは重複排除と、それぞれが最適解をたどる。文書に内包された画像やオブジェクトも、外側のコンテナだけを圧縮するのではなく、パイプラインに組み込んで一括処理して初めて、全体の利益が本当に実現する。
二つ目、シチュエーションごとの分檔（タクソノミー）。アーカイブ、メール、ウェブそれぞれに一つの基準を持ち、形式を越えて圧縮後の容積をそろえれば、ユーザーが一つずつ推し量る必要はなくなる。
三つ目、ローカル優先。ファイルは終始自分のデバイスに留まり、一括処理もネットワークや同時実行の制限を受けない。コンプライアンスの最低ラインを守るチームにとって、「ファイルを内部ネットワーク内に留める」ことを処理フローの硬い制約にするのは、事故後の監査より堅い。これもまた、ハードウェアにネイティブに構築され、一つ少ない翻訳層を持つ圧縮パイプラインが企業に好まれる理由を説明する。配備が軽く、挙動が制御しやすく、出力が再現性高く、プライベート化配備もしやすいのだ。
四つ目、スケールするコールドデータへのレバレッジ意識。Komprise の顧客調査によれば、企業の NAS 上で 60% から 70% のデータが 90 日以上アクセスされていないにもかかわらず、最も高価な主記憶域を占め続けている。この冗長を絞れば、浮くのは紛れもないストレージの請求書だ。
選定時に見るべき次元
よくある三つのアプローチを並べて見ると、違いは主にデータの行き先、形式のカバー範囲、一括処理と分檔の能力、そしてコンプライアンスの制御可能性にある。
| 次元 | ローカル圧縮ツール | オンライン圧縮サイト | 手動 ZIP / 自前処理 |
|---|---|---|---|
| データの行き先 | 全行程が自端末、デバイスを出ない | ファイルを第三者サーバーにアップロード要 | 自端末だが圧縮率に限り |
| 形式カバー | 一般的と専門的形式を統一処理 | 一般的な形式のみ、複雑な形式は非対応が常 | 個人の力量に依存 |
| 一括・分檔 | 用途で分檔、形式越えで基準一致 | 多くが単発・単ファイル | 分檔の概念ほぼ無し |
| コンプライアンス制御 | データが内部ネットワーク外に出ず、企業方針に組込可能 | 企業のコンプライアンス要求を満たし難い | 制御は可能だが効率が低い |
手元のファイルがオフィス文書、スキャン原稿、一般的な画像が中心なら、ローカル圧縮ツールが最もコストパフォーマンスの高い選択だ。そしてファイル量が自動アーカイブを要するほど大きくなったり、ファイル検索や整理と繋ぎ合わせたくなったりしたときは、「圧縮」と「ファイルの組織化」を一つのワークフローとして設計しても良い。例えば、まず MagiFiler で資料を整理し、次に SmartSlim で一括スリム化するように、SmartSlim で統一して痩せさせる。両者を組み合わせる方が、孤立して処理するよりずっと気が楽だ。
よくある質問
Q：なぜある PDF はほとんど圧縮できないのか？
A：内包された画像が既に最適化されエントロピー限界に近いか、容積の大半がロスレスでなければならない文字構造から来ている可能性が高い。これはツールの失效ではなく、もともと冗長が少ないのだ。
Q：圧縮すると契約書の印鑑や署名がぼやけるか？
A：細部を保つ軽量な再符号化経路をたどり、目標は冗長の容積を除くことであって、鮮明さを犠牲にすることではない。スキャン原稿や印鑑を含む文書は、圧縮後に重要な箇所を開いて確認してからアーカイブすることを勧める。
Q：ローカル圧縮とオンライン圧縮では、容積の差は大きいか？
A：実際の文書に対しては、どちらも概ね似た割合で圧縮できることが多い。差は主に「どれだけ圧縮するか」ではなく「ファイルが第三者を訪ねたかどうか」にある。公開済みの素材ならオンラインツールでも構わないが、機密情報を含むファイルはローカル処理の方が望ましい。
Q：すべての形式は圧縮できるか？
A：一般的なオフィスや画像形式、スキャン原稿には概ね十分な余地がある。既に高度に最適化された形式の利得は限られる。医療画像、地理情報、ライダーデータのような専門の長尾形式には、往々にして的を絞った圧縮戦略が要り、汎用パラメータをそのまま当てることはできない。
以上を繋ぐと、文書圧縮の真実は実に素朴だ。まず冗長がどこにあるかを見極め、次に種別ごとに別々に処理し、あなたのシチュエーションの制約の下で均衡を取る。こうした「分割して治める・ローカルで完結・形式越えで一致」を備えたツールが、日常では最も気が楽なのだ。
もしこの種の要請がちょうどあなたのワークフローに当てはまるなら、単一の圧縮率の数字に説得されるのではなく、この考え方に沿ってツールを評価してほしい。ファイル処理とローカル優先の工学的覚書については、https://www.uglypear.com/blog/ も参照いただきたい。