画像圧縮で画質を保つ完全ガイド2026 — 品質85%の黄金点からブラウザ完結処理まで

Web ページが重くなる原因の第1位は画像である。Google の Web Almanac 2023 によれば、ページあたりの転送量の中央値の約 50% を画像が占める。表示速度の改善もプライバシーの確保も、圧縮の基礎を正しく理解するところから始まる。

本記事では「どの設定で圧縮するか」「どのフォーマットを選ぶか」「どのツールが安全か」の3点を実証的に整理する。ツール選定は後半で行い、前半は仕組みの解説に徹する。

なぜ画像圧縮が収益・SEO・UXに直結するのか

Core Web Vitals と LCP の関係

Google の検索品質アルゴリズムは Core Web Vitals を正式な順位シグナルとして使用している。LCP（Largest Contentful Paint）は「画面内で最大のコンテンツが表示されるまでの時間」を計測し、推奨値は 2.5秒以内 だ。

遅延の最大要因は未圧縮の画像である。4K スマホカメラで撮影した JPEG はそのままだと 6〜12 MB になる。モバイル回線（下り実効 10 Mbps 程度）では1枚で転送に 5〜12 秒かかる計算だ。圧縮して 200 KB に抑えると、同じ回線で 0.16 秒に短縮できる。

ストレージ・CDN コストの累積

画像 1 枚を節約する効果は小さく見えるが、PV が積み上がると転送コストに直接影響する。月 100 万 PV のサイトで 1 枚あたり 1 MB を 200 KB に削減した場合、月間転送量を 800 GB 節約できる計算になる。

プライバシーリスク：EXIF メタデータ

スマートフォンで撮影した写真には EXIF データが埋め込まれており、撮影日時・GPS 座標・端末機種などが記録されている。企業の社内資料や個人の写真をそのまま Web にアップすると、位置情報が意図せず公開されるリスクがある。圧縮処理の際に EXIF を除去することは、容量削減と同時にプライバシー保護にもなる。

画像フォーマットの選び方：JPG・PNG・WebP・AVIF

JPG と PNG の使い分け原則

写真を PNG で保存するのは最も多い初歩的ミスで、JPG 比で 5〜10 倍の容量になりやすい。ロゴやテキスト入り画像を JPG にすると、輪郭のギザギザ（JPEG アーティファクト）が発生する。

WebP と AVIF の現在地（2026年時点）

MDN Web Docs の WebP ブラウザ互換表 によると、WebP は 2026 年現在で全主要ブラウザの最新版で対応済みである。Edge Legacy など古い環境への対応が必要でなければ、WebP を第一選択肢にして問題ない。

AVIF は JPG より 30〜50% 小さい容量を実現できるが、エンコード処理が重く、古いデバイスでは表示が遅くなる場合がある。対応状況は Chrome・Firefox・Safari で概ね揃っているが、業務用イントラや特定企業環境では注意が必要だ。

<picture> 要素の srcset を使えば、対応ブラウザには AVIF を、非対応ブラウザには WebP または JPG を自動配信できる。

可逆圧縮と非可逆圧縮の選択基準

可逆（lossless） はファイルを展開すれば元データと完全に一致する。PNG がその代表例で、ロゴや図版など「1 ピクセルも変えたくない」素材に適している。

非可逆（lossy） は人間の視覚が感知しにくい情報を捨てることで大幅な容量削減を実現する。JPG・WebP lossy・AVIF がこれに当たる。Web 配信用の写真は非可逆で十分だ。

画質を保ったまま圧縮する5つの実践的コツ

コツ1：品質 80〜85% が最適点

JPG の品質設定は 100% である必要はなく、85% が最適点 である。視覚的に差がほぼ分からないにもかかわらず、ファイルサイズは 100% 比で約 40% に減少する。

以下は品質設定と容量・画質の関係を示した実測ベースの目安だ。

85% より上は容量削減効率が急落し、75% 以下は輪郭にブロックノイズが発生し始める。この「85% の黄金点」は Google の PageSpeed Insights が推奨する水準とも一致している。

コツ2：リサイズは圧縮より先に行う

「圧縮前にピクセル数を表示サイズに合わせる」は、品質と容量の両立において圧縮設定の調整より効果が大きい。

3,000px 幅の写真を 300px で表示するページに置くと、ダウンロードされるのは 3,000px の高解像度データであり、ブラウザが表示時に縮小するだけだ。無駄な転送が発生している。画像リサイズツール で先に縮小してから圧縮する手順を徹底すること。

なお、元画像より 大きく拡大しても画質は上がらない。補間処理でぼやけるだけで情報量は増えないため、リサイズは縮小方向にのみ使う。

コツ3：EXIF メタデータを除去する

前述のプライバシーリスクに加え、EXIF は数 KB〜数十 KB のオーバーヘッドになる。多くの圧縮ツールは EXIF 除去をオプションとして提供しているが、デフォルトでオフ のものも多い。除去設定を確認してから処理することを習慣にする。

コツ4：非可逆圧縮を繰り返さない

JPG の非可逆圧縮は「元画像 → 圧縮済み JPG」の処理ごとに画質が劣化する。一度圧縮した JPG を再度読み込んで再圧縮すると、劣化が積み重なる。必ず 元画像（RAW または高品質 JPG）から 1 回だけ 圧縮する運用にする。

コツ5：重要な画像は目視で差分確認する

アイキャッチ・製品写真・プレゼン図版など視覚的品質が重要な画像は、圧縮前後の比較確認を行う。多くのツールは圧縮前後を並べて表示するプレビュー機能を持つ。自動バッチ処理に任せると過剰圧縮が見落とされることがある。

オンライン画像圧縮ツールの比較

主要ツール比較表

以下は 2026 年時点での主要な画像圧縮ツールの比較だ。

TinyPNG や Smallpdf は高品質なサービスだが、ファイルを一度クラウドサーバーに送信する設計であるため、機密性の高い画像（社内資料・個人情報を含む写真など）には適さない。

サーバー送信有無を自分で確認する方法

ツールの説明を信頼するだけでなく、DevTools の Network タブで実際に確認する のが確実だ。

1. 圧縮ツールのページを開く
2. ブラウザの DevTools を起動（Windows: F12、Mac: Cmd + Option + I）
3. 「Network」タブを選択し「Preserve log」を有効にする
4. 画像をドラッグ&ドロップして処理を実行する
5. Network タブの通信ログを確認する

サーバー送信型のツールは、処理時に大きなペイロードを含む POST リクエストが発生する。Zerosend の場合、画像をドロップしても POST リクエストは発生せず、CDN・アナリティクスなどの通常のページリクエストのみが表示される。アップロード通信ゼロ を自分で確認できる。

Zerosend でブラウザ完結の画像圧縮を行う手順

Zerosend の画像圧縮ツールは browser-image-compression ライブラリを Web Worker 上で動作させている。Web Worker はメインスレッドとは別のスレッドで処理を実行するブラウザの仕組みであり、処理中でもページの操作が固まらない。圧縮処理はすべてユーザーのブラウザ内で完結し、外部サーバーへの送信は一切発生しない。

操作手順

1. /tools/image-compress にアクセスする
2. JPG / PNG / WebP 形式の画像をドラッグ&ドロップ、または「ファイルを選択」から複数選択する
3. 品質スライダーを調整する（推奨値は 80〜85）
4. 「圧縮する」ボタンをクリックする
5. 圧縮結果のプレビューと圧縮率を確認する
6. 1 枚の場合はそのままダウンロード、複数の場合は ZIP でまとめてダウンロードする

オフライン動作について

Zerosend は Service Worker によるキャッシュを実装しており、初回アクセス後はネットワーク接続がなくても動作する。出張先や電波の届かない環境でも、ブラウザを開いていれば画像圧縮を実行できる。

よくある落とし穴と対処法

透過 PNG を JPG 変換すると白背景になる

JPG フォーマットは透過（アルファチャンネル）をサポートしていない。透過 PNG を JPG 変換すると、透過部分が白で塗りつぶされる。ロゴやアイコンで透過が必要な場合は PNG のまま圧縮するか WebP に変換する。画像形式変換ツール を参照。

圧縮後に色がくすんで見える

Adobe RGB や Display P3 プロファイルで保存された画像を sRGB 非対応の処理フローに通すと、色空間の変換時に彩度が失われる。Web 配信では sRGB に統一 するのが安全だ。プロファイルが不明な画像は、圧縮後に別のブラウザやデバイスで色味を確認する。

SNS 投稿は自分での極限圧縮が逆効果になる場合がある

Twitter（X）・Instagram・LINE は投稿時に独自アルゴリズムで再圧縮を行う。自分で品質を 40〜50% まで下げた上に SNS 側の再圧縮が重なると、最終的な画質が著しく低下することがある。SNS 向けの画像は 80〜85% の設定で一度だけ圧縮 し、プラットフォームの再処理に任せる方が綺麗な結果になりやすい。

バッチ処理後に全件確認をしない

一括処理の便利さから、圧縮後の全ファイルを確認しないまま公開するケースがある。異常に小さいファイルサイズになっているものや、極端に品質が下がっているものが混入していることがある。少なくともサムネイル一覧で目視確認する習慣をつける。

FAQ

Q1. WebP への変換は必須ですか？

必須ではないが、推奨する。同等の画質で JPG より 25〜35% 容量を削減できるケースが多い。ただし古い環境への対応が必要な場合は <picture> タグでフォールバックを設定する。

Q2. PNG を圧縮しても容量があまり減らないのはなぜですか？

PNG は可逆圧縮であるため、非可逆圧縮の JPG ほど大幅な削減は期待できない。PNG の容量を大きく削減したい場合は、非可逆の WebP への変換を検討する。透過が不要な写真系コンテンツであれば JPG または WebP lossy が最適だ。

Q3. 圧縮ツールに画像をアップロードするとデータは保存されますか？

サーバー処理型のツール（TinyPNG・Smallpdf 等）は各社のプライバシーポリシーに従って一定期間保存される場合がある。ブラウザ処理型のツール（Zerosend・Squoosh 等）はファイルをサーバーに送信しないため、保存の問題自体が発生しない。

Q4. 圧縮後にファイルが元より大きくなることはありますか？

ある。既に高圧縮済みの JPG をさらに圧縮しようとすると、再エンコードのオーバーヘッドでわずかに大きくなる場合がある。また、小さな PNG を WebP に変換した際に逆に大きくなるケースもある。圧縮後サイズを必ず確認し、大きくなっていた場合は元ファイルを使用する。

Q5. スマートフォンのカメラ写真に含まれる GPS 情報を削除できますか？

EXIF 除去機能を持つ圧縮ツールであれば削除できる。Zerosend の画像圧縮はデフォルトで EXIF を除去する。除去されているかどうかは、処理後のファイルを Jeffrey's Exif Viewer 等のオンラインツールで確認できる。

まとめ

画像圧縮の実践的な結論をまとめる。

• フォーマット選択：写真は JPG または WebP lossy、ロゴ・透過は PNG または WebP lossless
• 品質設定：JPG / WebP は 80〜85% を起点に調整する
• 処理順序：リサイズ（ピクセル数削減）→ 圧縮（品質調整）→ EXIF 除去
• 非可逆圧縮は元画像から1回のみ：再圧縮による劣化の積み重ねを避ける
• ツール選定：機密画像を扱う場合はサーバー送信の有無を DevTools で確認する

機密性の高い画像、個人写真、社内資料の圧縮には、ブラウザ完結処理の Zerosend 画像圧縮ツール が選択肢の一つとなる。処理が完全にローカルで完結するため、送信リスクが構造的にない。品質スライダーと圧縮前後のプレビューで結果を確認しながら、適切な設定を見つけることができる。