本文は「業界平均」の数字を引用していません。ここでの圧縮データはすべて自社で実施した実測に基づいており、コスト計算には公式を提供しています。ご自身の請求書上の単価を代入するだけで結果が算出できます。
毎月クラウドの請求書を見る多くの人は、合計額だけを見て、「前月より少し増えた程度で、予算内にあるのでこれでよし」と済ませてしまいます。
しかし請求書を展開し、製品ごとに分割して確認すると、多くのウェブサイト、小程序、コンテンツプラットフォームで、上位に表示される項目はたいてい2つだけになることがわかります：
- オブジェクトストレージ：GB・月あたりのストレージ料金
- CDN / 公網トラフィック：GBあたりの下行トラフィック料金
そしてその2つの項目の中で、最も占めているのは通常画像です。
問題は、これらの画像の一部のバイト数は、ユーザーには全くわからず、あなたは毎月それらのために支払いを続けているということです。
1. 「アップロード時に圧縮した」と言っても、圧縮は「十分」ではない
多くのチームはこう言います。「アップロード時に圧縮したから大丈夫だ」。私たちはこの状況について専門的にテストを行いました。サンプルはユーザーが画像をアップロードできるウェブサイトで、インポート時に既に通常の圧縮処理が行われています：78個のフォルダ、4624枚の画像、合計1.41 GB。
| サイズ | 元のファイルに対する比率 | |
|---|---|---|
| ウェブサイトが既に圧縮したファイル | 1.41 GB | — |
| ZIPに圧縮 | 1.41 GB | -0.2% |
| ImgZillaでの再圧縮 | 0.75 GB | -46.8% |
「既に圧縮済み」の上からさらに半分近く節約できました。 そして4624枚のうち、一枚一枚に対してもさらに圧縮可能で、「圧縮限界に達し、スキップする」ものは一枚もありませんでした。
理由は単純です。ほとんどのインポート時の圧縮は、品質パラメータを統一して設定するか、サイズを制限する程度で、一括処理に過ぎず、各フォーマットのエンコーディングスペースを最大限に使い切っているわけではありません。
画像ライブラリがカメラからの直出、デザインファイルのエクスポート、あるいは運営が直接アップロードしたオリジナル画像の場合、節約できる空間はもっと大きくなります。32188枚のカメラ直出JPEGでテストしたところ、全体のサイズは76.8%削減されました。
2. ストレージ料金は加算、トラフィック料金は乗算
これが最も見落とされがちなポイントです。
- ストレージ料金：画像がバケットに保存されるたびに、そのサイズに基づいて毎月1回料金が発生します
- トラフィック料金：画像が1回アクセスされるたびに、そのサイズに基づいてもう1回料金が発生します
したがって、ホームページのバナーで300 KBの無効なバイトが余分にあったとしても、ストレージの請求書上ではほとんど目立ちませんが、1日に10万回アクセスされれば、トラフィックの請求書上では1日あたり約29 GBの増加となります。
画像がより人気であればあるほど、支払う無駄遣いが増えます。 そして最も人気のある画像は、まさにホームページ画像、商品メイン画像、記事のオフ画像など、「気まぐれにオリジナルをアップロードする」場所です。
3. ご自身の請求書を計算する
誰の見積もりも信用する必要はありません。先月の請求書を取り出し、以下の2つの公式に代入してください：
月間に節約できるストレージ料金 ≈ 画像の総ストレージ量(GB) × 圧縮率 × ストレージ単価(円/GB・月)
月間に節約できるトラフィック料金 ≈ 画像の月間下行トラフィック(GB) × 圧縮率 × トラフィック単価(円/GB)
圧縮率はまず保守的に**40%**で推定してください（私たちが「既に圧縮済み」のサンプルで測定した46.8%よりも低い数値です）。ご自身の画像処理を実行したら、実際の数字に置き換えてください。
デモ用の例（単価は仮定値です。ご自身の請求書上の数字に置き換えてください）：
| 項目 | 数値 |
|---|---|
| 画像のストレージ量 | 500 GB |
| 画像の月間下行トラフィック | 10 TB |
| ストレージ単価（仮定） | 0.12 円/GB・月 |
| トラフィック単価（仮定） | 0.20 円/GB |
- ストレージ：500 × 40% × 0.12 ≈ 24 円/月
- トラフィック：10240 × 40% × 0.20 ≈ 819 円/月
本命はトラフィックにあることがわかります。ストレージで節約できるのは目立った金額ではなく、トラフィックで節約できるのが本物です。しかも、この金額は毎月支払い続けられ、画像を処理しない限りずっと支払い続けます。
請求書上では見えないその他のメリットもあります：ページの読み込みが速くなり、モバイルユーザーがデータ量を節約でき、LCP（最大コンテンツのペイント）の指標が良くなり、小程序のメインパッケージを制限内に収めるのが容易になります。
4. なぜ分かっていても圧縮しないのか
開発者やウェブサイト管理者に聞いてみると、答えは基本的に3つでした。
1. パスを変更することへの恐怖。
従来のオンライン圧縮ツールは「アップロード → ダウンロード → 名前変更 → 置換 → コード内の参照を変更」という手順が必要で、数千枚の画像があるプロジェクトでは、誰も触りたがりません。
2. 画質に問題が生じることへの恐怖。
圧縮後にデザイン、運営、あるいは上司から「画像がぼやけている」と言われるのを避けたいと考え、誰もがその責任を負いたくありません。
3. 面倒くさい。
フォルダがネストされており、一枚一枚処理するのは現実的ではなく、スクリプトを書くにはパラメータの調整や各種フォーマットの処理が必要です。
ImgZillaはこれら3つの問題を解決するために作られました：
- 原地圧縮：圧縮後、元のファイルを直接置換します。ファイル名、ディレクトリ構造は完全に変更されず、コード内の参照は一行も変更する必要がありません
- 視覚的に損なわない：PNG、SVGは本格的な無損圧縮です。JPEG、WebP、AVIF、HEICは各フォーマットごとにパラメータを調整し、肉眼で識別できない範囲に制御します。左右分割画面による比較機能を内蔵しており、実際のピクセルまで拡大してご自身で確認できます
- フォルダをドラッグ＆ドロップするだけ：サブディレクトリを再帰的に処理します。ファイルを選ぶ必要も、スライダーを調整する必要もありません
- すべてローカル処理：内部リソース、未公開の商品画像など、サードパーティのサーバーにアップロードする必要はありません
5. ストレージバケットの「痩身」を実践する手順
画像がすでにオブジェクトストレージに保存されている場合、手順はだいたいこのようになります：
- ローカルに同期：
rclone、ossutil、coscmd、aws s3 syncなどのツールを使って、画像ディレクトリをMacに取り込みます - バックアップを作成：安心してください。これは習慣として良いことです。ツールが信頼できないからではありません
- ImgZillaにドラッグ：フォルダ全体をドラッグして実行し、完了するまで待ちます
- ストレージバケットに同期戻す：同じツールを使って上書きアップロードします。パスは変わりません
- CDNキャッシュを更新：画像ディレクトリに対してディレクトリ更新を行い、エッジノードに新しいファイルを取得させます
5番目の手順を忘れないでください。更新しないと、CDNノードは古いファイルを引き続き配信し続け、トラフィックの請求額はキャッシュの有効期限が切れるまで下がりません。
6. 確実な説明
- ImgZillaは現在、macOS版のみ（macOS 12.3以降が必要）、Windows版はありません
- PNGとSVG以外は視覚的に損なわない圧縮です。ピクセル単位で完全に変更されていないことを求める業務（医療画像など、ピクセル比を比較する素材など）がある場合は、このようなファイルの再エンコードを行わないでください
- 圧縮率は画像によって異なります。私たちが実測した単一画像の圧縮比は32%から86%まであり、まずはディレクトリを一つ選んでテスト実行し、実際の数字を見てから判断することをお勧めします
最後に
クラウドプロバイダは画像をさらに小さくできることを教えてくれませんし、請求書にも「無効なバイト」として別途行はありません。
しかし、そこには常に存在し、毎月GB単位で請求され、アクセスされるたびに再び料金が発生します。
画像ディレクトリをImgZillaにドラッグして実行し、来月の請求書を比較してみてください。
👉 ImgZillaをダウンロード：https://imagetool.app/ImgZilla