圧縮ツールの最も一般的な宣伝文句は、「サイズが70%削減」といった検証不能な数字です。本記事は業界統計を一切引用せず、実際に実施した計測結果と、誰でも再現できる完全な手順のみを提示します。
一、テスト対象：原画像ではなく「すでに一度圧縮された」画像
多くの圧縮テストは、カメラが直接出力した原画像を使うため、条件が理想的すぎます。今回のテストは、実際のビジネスシナリオに意図的に近づけました。ユーザーによる画像アップロードを許可するWebサイトが、取り込み時にすでに標準的な圧縮を1回実行済み——つまり、テスト対象は未処理の生画像ではなく、すでに「一度圧縮された」完成画像です。
サンプル規模：78フォルダ、合計4624枚（主にJPG）。ディレクトリ構造は「1アルバム＝1フォルダ」という一般的なアーカイブ形式で、フィルタリングやクリーニングは一切行っていません。
このファイル群のサーバー上での元の合計サイズ：1.41 GB。
核心となる問い：すでに圧縮ツールで処理された画像を、別の圧縮ツールで処理したら、まだどれだけの容量を削れるのか？ 多くのユーザーは「一度圧縮したら、もう圧縮し直しても意味がないのでは」と直感的に考えます。
二、対照群：zipとしてまとめるとどれだけ削減できるか？
ImgZilla を実行する前に、同じファイル群をそのまま zip にまとめ、汎用圧縮アルゴリズムの効果を確認しました。
| サイズ | 元との差 | |
|---|---|---|
| サイトで圧縮済みの元ファイル | 1.41 GB | — |
| zip にまとめた場合 | 1.41 GB | -0.2% |
ほぼ変化なし。理由は複雑ではありません。JPEG 自体が圧縮形式であり、画像データはすでにエントロピー符号化されています。汎用アルゴリズム（zip は DEFLATE）は、圧縮済みデータに対してさらなる圧縮をほとんど行えません。元画像がWebサイト側で処理されたかどうかに関わらず、zip では効果が得られないのです。
三、ImgZilla による再圧縮の実測
上記のファイルを ImgZilla にドラッグ＆ドロップし、その場（上書き）で圧縮しました。78フォルダ、4624枚の画像は、ファイル名とディレクトリ構造がすべて保持されています。
| サイズ | 元との差 | |
|---|---|---|
| サイトで圧縮済みの元ファイル | 1.41 GB | — |
| zip にまとめた場合 | 1.41 GB | -0.2% |
| ImgZilla で再圧縮後 | 0.75 GB | -46.8% |
Webサイト側で圧縮済みの状態から、ImgZilla はさらに約 662 MB を削減し、サイズはほぼ半分になりました。 すべてのフォルダパス、ファイル名、階層関係は圧縮前後で完全に一致しています。これは直接検証可能な実際のデータであり、マーケティング上の表現ではありません。
ここからわかる重要な事実は、「アップロード時にWebサイト側で圧縮した」ことと、「フォーマット固有のパラメータで細かく調整したエンコード圧縮」は別物だということです。多くのサイトが取り込み時に行う圧縮は、一度きりの控えめな設定（通常は品質パラメータや寸法を制限するだけ）で、各フォーマットのエンコード余地を十分に使い切っていません。ImgZilla はフォーマットごとにパラメータを個別調整し、JPEG には視覚ロスレスな再エンコードを実施します。ピクセルレベルでは確かに変化がありますが、肉眼ではほとんど判別できない範囲にパラメータが設定されており、その結果「圧縮済み」の状態からさらに容量を削り出せます。
混同しやすい概念を明確にしておきます：「視覚ロスレス」と「ロスレス」は異なります。真正のロスレス（ピクセルが完全に不変）は PNG（oxipng）と SVG にのみ適用されます。JPEG、WebP、AVIF、HEIC、GIF は原理上はいずれも非可逆の再エンコードですが、圧縮パラメータが視覚的にロスレスの閾値内に調整されているだけです。ImgZilla は比較ウィンドウを内蔵しており、圧縮前後を左右分割表示したり、実サイズに拡大してピクセル単位で照合したりできるため、ご自身で検証可能です。
四、詳細分析：ファイル別の圧縮率・ピクセル寸法・処理時間
先ほどの全体圧縮率 46.8% は、4624枚を合算した結果です。個々のファイルレベルに分解すると、さらに多くの詳細が得られます。
画像ごとの圧縮率は一様ではない
画像ごとの圧縮率（圧縮後バイト数 ÷ 圧縮前バイト数）を1枚ずつ計算すると、32.3%〜85.8% に分布しました。
- 圧縮率が最も高い一群：約 765 KB → 109 KB、圧縮率 85.8%。こうした画像は通常、初期圧縮の強度が不十分で、再エンコードの余地がまだ大きい。
- 圧縮率が最も低い一群：約 572 KB → 387 KB、圧縮率 32.3%。こうした画像は以前にしっかり圧縮されており、削れる余地は限られている。
- 4624枚の圧縮率の算術平均は 46.44%。合計サイズから算出した 46.8% に近いが、完全には一致しない。前者は各ファイル圧縮率の単純平均、後者は「総削減バイト数 ÷ 総元バイト数」。この差は、圧縮率の高いファイルと低いファイルが全体サイズに占める重みが非対称であり、少数の大容量ファイルが全体へ与える影響が大きいことを示す。
注目すべきは、すべての画像で圧縮率が正の値であり、「すでに最小、スキップ」というケースがゼロだったことです。つまり、この「Webサイトで圧縮済み」の画像すべてについて、ImgZilla は実際に容量を削減できたのです。
ピクセル寸法：完全に一致
全4624枚のピクセル寸法を集計したところ、最も多いのは 1600×2400（1756枚）と、その横長版 2400×1600（500枚）。寸法の範囲は最小の 450×675（約30万画素）から最大の 3000×2000 / 2000×3000（約600万画素）までありました。
ピクセル寸法を圧縮前後でサンプル照合したところ、完全に一致し、変化はありません：
| ファイル（例） | 元の寸法 | 圧縮後の寸法 |
|---|---|---|
| サンプル1 | 1600×1066 | 1600×1066 |
| サンプル2 | 2000×3000 | 2000×3000 |
| サンプル3 | 1416×2128 | 1416×2128 |
これは「その場（上書き）圧縮」の定義で見落とされがちなもう半分です。ファイル名とパスが変わらないだけでなく、解像度も固定されたままです。ImgZilla はリサイズもトリミングも行わず、サイズ削減はすべて再エンコードに由来しており、ピクセルを犠牲にしていません。
処理時間：4624枚を51分32秒で処理、平均1枚あたり0.669秒
テスト環境：Apple M1 チップ搭載の Mac mini（ユニファイドメモリ8GB）、画像は2.5G有線ネットワークで接続したNASのHDDに保存。
各画像の最終書き込み時刻（ImgZilla が圧縮を完了してディスクに書き戻した時刻）からタスクの進行を追跡しました。最初の書き込みは16:06:09、最後の書き込みは16:57:41。全バッチの処理時間は合計51分32秒、1枚あたり平均0.669秒です。
この数値は製品の「シリアル処理」という設計と一致します。1枚ずつ順番に圧縮し、並列でランダムに書き込むわけではありません。換算すると、1分あたり約 90枚 の処理です。実際の速度は画像サイズとマシン性能に依存します。ここに示したのは、平均1枚約305KBのこの画像群を上記環境で処理したときの実測所要時間であり、一般的なベンチマークではありません。
五、別名保存ではなく「その場（上書き）圧縮」を選ぶ理由
今回のテストで「圧縮版を別名保存する」ツールを使った場合、結果はどうなっていたでしょうか。元ファイル1.41 GB ＋ 圧縮版0.75 GB で、合計2.16 GBを占めることになり、むしろ余計に容量を使います。さらに大量の xxx-min.jpg ファイルが生成され、手動で整理し、データベースや商品テーブルの参照先を更新しなければなりません。
ImgZilla はその場で上書きする方式です。圧縮結果は元のパスに直接書き戻され、78フォルダ内の4624ファイル名はすべて不変です。これは、画像パスをデータベースやCDN、CMSに登録しているサイトにとって特に重要で、圧縮後にリンクを変更する必要がありません。代わりに元ファイルを変更するため、デフォルトでは元画像をまずシステムのゴミ箱に移してから圧縮結果を書き込みます。元に戻したい場合は、ゴミ箱で右クリックして「元の場所に戻す」ことができます。
六、効果の分析：実際のシナリオから月額コストへ
このデータが実際に役立つのはどんな人か
- ユーザー画像アップロード機能を持つサイト／開発者：画像ストレージとCDN転送量は通常GB単位で課金されるため、サイズが半分になれば請求額もそのまま半分になります。しかも転送料金はアクセスのたびに発生するため、アクセス数が多いほど複利効果が顕著です。取り込み時に標準的な圧縮をしていても、専用チューニングによる圧縮をもう1回実行する価値があることを、今回の実測は示しています。
- ストレージ容量が逼迫しているサーバー／小容量ディスクのユーザー：クリーンアップツールは通常キャッシュや重複ファイルを削除しますが、数カ月後には再び溜まります。一方、圧縮で生まれる空き容量は、使用中のファイル自体が小さくなった結果であり、元に戻りません。この78フォルダは、圧縮後に直接662MBの空き容量が増え、永続的に解放されます。
- データを頻繁に移動するユーザー：コピー、同期、バックアップの際、サイズが46.8%削減されていれば、転送時間もほぼ同じ割合で短縮されます。一度圧縮しておけば、その後の移動のたびに時間を節約できます。
月額コストに換算：この46.8%は実際いくらになるのか
サイズ削減は、最終的に請求額に反映されてこそ説得力があります。以下では「圧縮によりコンバージョンが向上」といった統計を一切引用せず、今回の実測値 46.8% を主要クラウド事業者の公開ストレージ／転送料金に掛け合わせた、純粋な算術試算を示します。
ストレージ費用の削減額 = 削減したサイズ（GB） × 単価（元または米ドル / GB / 月）
送信（ダウンロード）転送費用の削減額 = 削減したサイズ（GB） × 当月のダウンロード／アクセス回数 × 単価（元または米ドル / GB）
サイズが半分になれば、2つの請求額も基本的に半分になります。これは推測ではなく算数です。
ストレージ費用：ライブラリが大きいほど効果が明確
中国国内事業者：
| ライブラリの元サイズ | 削減サイズ | Alibaba Cloud OSS 標準ストレージ ¥0.09/GB/月 |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/月 |
| 100 GB | 46.8 GB | ¥4.21/月 |
| 1 TB | 479 GB | ¥43.1/月 |
海外事業者：
| ライブラリの元サイズ | 削減サイズ | AWS S3 Standard $0.023/GB/月 |
Google Cloud Storage $0.020/GB/月（米国リージョン） |
Azure Blob Storage $0.018/GB/月（ホットLRS） |
Cloudflare R2 $0.015/GB/月 |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/月 | $0.09/月 | $0.08/月 | $0.07/月 |
| 100 GB | 46.8 GB | $1.08/月 | $0.94/月 | $0.84/月 | $0.70/月 |
| 1 TB | 479 GB | $11.02/月 | $9.58/月 | $8.62/月 | $7.19/月 |
海外主要各社のストレージ単価は非常に近く（差は30%以内）、重要なのはどの事業者を選ぶかではありません。どれを選んでも、サイズが半分になればその請求もほぼ半分になるという点です。しかも月単位で繰り返し課金されます。一度圧縮すれば、以後は毎月新しいサイズで課金されるため、一度きりの投資で長期間にわたり効果が続くメリットがあります。
転送料金：本当の主要コストであり、アクセス数に応じて拡大する
転送費用はストレージ費用よりも注目に値します。なぜなら サイズ × ダウンロード回数 の積だからです。画像へのアクセスが頻繁なほど、圧縮による効果は大きくなります。100GBの画像ライブラリで、月間にCDNから500GBのダウンロード転送が発生したと仮定します（ライブラリ全体を約5回ダウンロードした計算）。
| CDN / 送信転送料金（最低ティア） | 圧縮前の月間転送料金 | 圧縮後（転送量は46.8%減） | 毎月の削減額 | 年間の削減額 |
|---|---|---|---|---|
| Alibaba Cloud CDN 中国国内（低ティア ¥0.15/GB） | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront アジア太平洋リージョン（$0.12/GB） | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN 北米／欧州（$0.08/GB） | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door Standard Zone 1（$0.08/GB） | $40.0 | $21.3 | $18.7 | $224 |
上記は各社の最低ティア料金です。実際にはティアが上がるほど高くなる場合が多く（Alibaba Cloud CDN 中国国内の最上位ティアは ¥1.31/GB に達することもあります）、請求額が大きいほど圧縮による削減額の絶対値も大きくなります。なお、Azure のこの料金は現在 Front Door 標準版のもので、GB単位の送信転送に加えて約 $35/月の基本サービス料が含まれます。この基本料金は圧縮では減らせないため、上表の削減額には含めていません。
Cloudflare R2 は例外です。その送信（egress）転送量はそもそも $0 です。ストレージをR2に置いた場合、圧縮の効果はほぼストレージ費用にのみ現れ、転送部分自体に請求がありません。これは「ストレージ＋転送」の二重課金構成（例：Alibaba Cloud OSS+CDN、AWS S3+CloudFront）とは異なるコスト構造であり、事業者を選ぶ前に自社の課金項目を明確にしておく必要があります。
上記の単価は2026年時点の各プラットフォーム公開価格をまとめたものです。実際の価格は地域、アカウント割引、ティア帯の影響を受けるため、公式サイトのリアルタイム価格を確認してください。ダウンロード回数・アクセス数は仮定の例であり、ご自身の請求データに置き換えて試算してください。
七、転送・アップロード時間の削減
サイズが半分になれば、転送時間もほぼ同じ割合で短縮されます。この法則はクラウドの請求に依存せず、ローカルコピーやバックアップだけでなく、ユーザーのアップロード時にも当てはまります。
ローカル環境：USB 3 とギガビットネットワーク
- USB 3 ポータブルHDD：連続読み書きスループットは一般的に100〜150 MB/s。中央値をとって 120 MB/s。
- USB 3 ポータブルSSD：スループットはかなり高く、一般的に400〜500 MB/s。450 MB/s を採用。
- ギガビット有線ネットワーク（1000 Mbps）：理論上の上限は125 MB/s。プロトコルオーバーヘッドを差し引くと、実測の連続スループットは約100〜110 MB/s。105 MB/s を採用。
上記は一般的な実測範囲に基づく概算値です。実際の速度はHDD/SSDの種類、インターフェース品質、ネットワーク環境に左右されるため、あくまで概算の参考値です。
| シナリオ | 削減サイズ | USB 3 HDD @120 MB/s | USB 3 SSD @450 MB/s | ギガビットネットワーク @105 MB/s |
|---|---|---|---|---|
| 今回の実測対象の画像群 | 662 MB | ≈5.5秒 | ≈1.5秒 | ≈6.3秒 |
| 10 GB ライブラリ | 4.68 GB | ≈40秒 | ≈10秒 | ≈45秒 |
| 100 GB ライブラリ | 46.8 GB | ≈6.5分 | ≈1.7分 | ≈7.4分 |
| 1 TB ライブラリ | 479 GB | ≈66分 | ≈18分 | ≈76分 |
今回の実測では662MBで1回あたりほんの数秒と、小さく見えるかもしれません。しかしストレージ費用と同じく、これは一度きりの投資で長期間続く効果です。ポータブルHDDへの書き出し・取り込み、NASの同期、Time Machineの実行、新しいMacへの移行、同僚への転送など、このデータを今後も移動し続ける限り、毎回同じ割合で時間を節約できます。一度圧縮すれば、それ以降の移動ごとに時間を節約できます。
ユーザーアップロード前に圧縮を実行する場合：削減できる待ち時間
ここまで計算したのは「画像を保存した後」の効果、つまりストレージ費用、CDN転送料金、ローカル転送です。もう1つ注目すべきは、ユーザーが「アップロード」ボタンを押してからプログレスバーが完了するまでの待ち時間です。これはユーザー自身の上り帯域を使いますが、上りは通常、回線全体の中で最も遅いボトルネックになります。多くのコンシューマー向けブロードバンドの上り速度は下りの10分の1〜5分の1で、モバイルネットワークではさらに顕著です。ユーザーがアップロードする前に、Webサイトまたはアプリが ImgZilla で画像を圧縮すれば、削減されたサイズはそのままユーザーの待ち時間短縮につながります。
今回の実測における1枚あたりの平均サイズで計算すると、Webサイト圧縮後の元画像は平均 299 KB、ImgZilla 再圧縮後は平均 159 KB、1枚あたり平均約 140 KB の削減です。
| アップロード帯域（公開スピードテストの一般的な範囲、参考値） | 1枚の場合 299KB→159KB |
50枚のアルバムをアップロード 約15.0MB→8.0MB |
今回の全4624枚をアップロード 1.41GB→0.75GB |
|---|---|---|---|
| モバイルネットワーク（4G/5G総合、中国国内の公開スピードテスト中央値は約10〜50Mbps、30Mbpsを採用） | 約0.04秒削減 | 約1.9秒削減 | 約3分削減 |
| 一般的な家庭用ブロードバンド上り（100M/1G下りプランでは上りが制限されることが多く、約20〜30Mbps、25Mbpsを採用） | 約0.04秒削減 | 約2.2秒削減 | 約3.5分削減 |
| ギガビット対称回線の上り（一部の通信事業者／企業専用線、1000Mbps） | 約0.001秒削減 | 約0.06秒削減 | 約5.3秒削減 |
| 海外参考：米国の平均的な固定ブロードバンド上り（Ooklaデータ、2026年） | 約0.02秒削減 | 約1秒削減 | 約1.5分削減 |
1枚単位でこの表を見ると意味がないように思えるかもしれません。0.04秒はほとんど体感できないからです。これは正直な結果です。このテストサンプル自体がもともと大きくなかった（サイト取り込み時にすでに圧縮され、平均1枚わずか299KB）からです。本当に価値が出るのは、アルバム1冊や数十枚の画像をまとめてアップロードする一括操作と、より大きなサイズの元素材（例：カメラ直出しのJPEGや、サイト圧縮前のUGC初回アップロード。1枚が数百KBではなく数MBになることが多い）の2つの場面です。同じ圧縮率なら、削減される秒数も同じ割合で大きくなります。上り帯域がもともと遅いモバイルネットワークユーザーにとっては、待ち時間の短縮がさらに明確に感じられます。
モバイルネットワークと家庭用ブロードバンドの範囲は、中国国内の公開スピードテスト統計（4G/5G中央値、ブロードバンドの上り速度の一般的な比率）に基づいています。実際の速度は通信事業者、地域、デバイス、ネットワーク混雑の影響を大きく受けるため、桁の目安としてのみご参照ください。米国の固定ブロードバンド上りデータは Ookla Speedtest の関連レポートから引用しています。
実際に検証してみたい方へ：Mac App Store から ImgZilla をダウンロードし、ご自身のサイトで処理済みの画像を数枚テストしてみてください。その上で、他の画像も圧縮するかどうかを判断できます。
Mac App Store： https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
詳細情報： https://imagetool.app/ImgZilla