画像圧縮比：品質とサイズのガイド

最終更新日: June 28, 2026

画像圧縮率は、エクスポート後に画像がどれだけ小さくなったかを示す指標です。これは有用ですが、単なる数値としてではなく、視覚的な確認と組み合わせて使用することが重要です。12:1の比率が柔らかい背景写真には優れているかもしれませんが、小さな文字を含む製品スクリーンショットには不適切かもしれません。

このガイドでは、WebP、JPEG、PNG、および AVIF のための計算式、一般的な品質範囲、そしてパブリッシングチェックリストを提供します。画像がぼやけることなく、より軽量なページが必要な場合に役立ちます。

クイックアンサー：適切な画像圧縮率とは？

良い画像圧縮率とは、最終的な表示サイズでもクリーンに見える最大のバイト削減率です。これは、「元のファイルサイズ ÷ 圧縮後のファイルサイズ」で計算します。4 MBの画像を500 KBに圧縮した場合、8:1の比率になります。

ウェブ写真の場合、リサイズして WebP や AVIF にエクスポートした後、実用的な目標は通常 5:1 から 12:1 です。一方、テキストが多用されるスクリーンショット、ロゴ、UI画像の場合は、シャープなエッジやフラットな色が保護を必要とするため、低い比率が正常です。ロスレスの PNG や WebP は、せいぜい 1.2:1 から 3:1 しか達成できない場合があります。

圧縮率は比率だけで判断しないでください。顔、製品のエッジ、グラデーション、小さなテキストを点検してください。ユーザーがブロックノイズ、リンギング、にじみ、またはバンディングを見ることができれば、ファイルサイズが魅力的に見えても、その比率は過度にアグレッシブすぎます。

画像圧縮率の計算方法は？

元のバイトサイズと、トリミング、リサイズ、メタデータ除去、フォーマット変換、品質設定といったすべての実際のパブリッシングステップを経た後の最終的なバイトサイズを使用します。リサイズする前に計算すると、その数値は通常誤解を招きます。

ビルドパイプラインを調整している際は、正確なバイト数を使用してください。編集設定を文書化している場合は、丸めた KB または MB を使用します。決定は変わりません。画像がその役割を果たし続ける限り、「小さい」ことが有用なのです。

Google の画像ガイダンスは、速度と品質の両方を重視しています。画像はページの重さに影響を与えることがよくありますが、ぼやけたり不明瞭な画像はユーザーや検索プレビューにとって良くありません。また、Google Images best practices では、クロール可能な HTML 画像要素、説明的な alt テキスト、そして JPEG、PNG、WebP、SVG、AVIF のようなサポートされているフォーマットを推奨しています。

WebP、JPEG、PNG、および AVIF にはどの比率を使うべきですか？

適切な比率は画像の内容によって異なります。写真は小さなテクスチャの変化が気づきにくいため、圧縮しにくいものです。一方、スクリーンショットや図表は、テキスト、線、UIの境界線があるため、アーティファクトが目立ちやすく、圧縮しにくい傾向があります。

MDN の画像フォーマットガイドによると、WebP は可逆圧縮（lossy）と非可逆圧縮（lossless）の両方が可能であり、ロスリー WebP とロスレス WebP では異なる内部表現を使用します。そのため、「WebP比率」という単一のものは存在せず、正しい設定はコンテンツが損失を許容できるかどうかによって異なります。フォーマットの動作については、MDN の image file type and format guide を参照してください。

この記事のために、ImageMagick と WebP を使ってローカルで 1400 by 788 のグラフィックを4つエンコードしました。ファイルサイズはそれぞれ 23 KB、28 KB、35 KB、および 40 KB でした。これらはアセットがカメラ写真ではなくクリーンな図表であるため、異常に小さい値です。この数値を、「フラットなグラフィック」と「写真のディテール」では圧縮が異なるという証拠として使用してください。

より広範なフォーマットのトレードオフについては、この記事を AVIF vs WebP Comparison と比較してください。アーティファクトの背後にあるアルゴリズムの詳細が必要な場合は、How Image Compression Works を読んでください。

品質設定はなぜある点から大きく節約しなくなるのか？

ほとんどのエンコーダーには、初期段階で大きな改善が見られるものの、後半になると痛みを伴うトレードオフがあります。元のカメラファイルから WebP q80 に移行すると、多くの目に見えないデータが除去される可能性があります。しかし、q70 から q55 に移行しても、節約できるバイト数は少ないかもしれませんが、アーティファクトは気づきやすくなります。

実用的な効果は単純です。サイズ曲線が平坦化する一方で、品質曲線は低下し続けます。これが WebP q75-85 が記事や製品写真の一般的な出発点となる理由です。これはすべてのファイルに適用されるルールではありません。結果を検査する前の良い最初のテストなのです。

品質を調整する際は、以下の順序を使用してください。

1. 実際に提供する最大のレンダリング幅にリサイズします。
2. WebP を q85 で一つ、q80 で一つ、そして q75 で一つエクスポートします。
3. それらを元のファイルと意図した表示サイズで並べて開きます。
4. 顔、テキスト、製品のエッジ、影、滑らかなグラデーションを確認します。
5. 劣化して見えない最小のバージョンを選びます。
6. そのコンテンツタイプの結果的な比率を記録します。

画像が Largest Contentful Paint (LCP) 要素になる可能性が高い場合、圧縮は解決策の一部に過ぎません。web.dev の LCP ガイダンスでは、fetchpriority="high" を使用してLCPになりそうな画像を優先し、Optimize Largest Contentful Paint でネットワークウォーターフォール内のリソースディスカバリを確認することを推奨しています。

フォーマットをまたいだ圧縮率の比較はどのように行うべきですか？

フォーマットをまたいで比率を比較する際は、スライダーの数値が一致しているのではなく、目に見える品質が一致するように比較してください。JPEG q82、WebP q78、および AVIF q55 はすべて、同じソースから得られる合理的な出力である可能性があります。これらの数値はエンコーダーの制御値であり、普遍的な品質スコアではありません。

ここでチームが比率を誤解することがよくあります。両方とも画面上で同じに見える場合、5.7:1 の JPEG は 8:1 の WebP よりも悪い場合があります。アセットが価格表のスクリーンショットである場合、2:1 のロスレス WebP は 10:1 のロスリー WebP よりも優れているかもしれません。

バッチ処理を行う場合は、同じマスターから複数の出力を生成し、その決定をファイル名やビルドログに残しておく必要があります。Batch Resize Guide はリサイズ・ファーストのワークフローを網羅しており、Complete Image Optimization Checklist は最終的なパブリッシュ前のチェックリストを提供します。

高い圧縮率が悪い兆候となるのはいつですか？

高い比率は、画像に人が検査するディテールがある場合に警告サインとなります。店舗のオーナーは製品のテクスチャに気づきます。デザイナーは柔らかくなった文字に気づきます。購入者は泥のようなジュエリーのエッジに気づきます。そのような場合、「最も小さいファイル」が節約できる以上のコストを払う可能性があります。

画像に以下の要素が含まれる場合は、高い比率に追加の点検が必要です。

• 製品ラベル、パッケージテキスト、成分、またはシリアル番号。
• UIスクリーンショット、ダッシュボード、コード、または価格表。
• 顔、肌のテクスチャ、髪、ジュエリー、布地、または食べ物。
• 滑らかなグラデーション、空、影、ネオン、または暗い背景。
• 細い線、アイコン、透明なエッジ、またはブランドマーク。
• ズームされる、トリミングされる、または広告で再利用される画像。

eコマースの場合、装飾的なブログ画像に使用する場合よりも厳しいチェックが必要です。カテゴリーのサムネイルは、メインの商品画像よりも多くの損失を許容できます。同じマスターが両方に供給される場合、一つの比率にすべてのスロットを合わせようとするのではなく、別個のエクスポートを作成してください。

視覚的な品質低下なしに最高のサイズを得るワークフローは？

圧縮率は最初の設定としてではなく、測定値として使用します。出力の品質は、最終的な比率の数値よりも、ソース、トリミング、ピクセル寸法、およびフォーマットの選択によってより左右されます。

以下のパブリッシングシーケンスを使用してください。

1. 何度も再エンコードされていないマスターファイルを保持します。
2. リサイズする前に、最終的なユースケースに合わせてトリミングします。
3. 必要な場合はレスポンシブバリアントを用意し、最大のレンダリング幅にリサイズします。
4. コンテンツによってフォーマットを選択します：写真には WebP または AVIF、テキストが多用されるグラフィックにはロスレスを使用します。
5. 品質候補を2つまたは3つエクスポートします。
6. 法的または編集的に必須でない限り、公開コピーからメタデータを除去します。
7. デスクトップとモバイルのレンダリングサイズで候補を比較します。
8. LCP の可能性が高い画像は、ファールドの下の画像とは分けて処理します。
9. 安定した CDN URL にパブリッシュし、HTTP 200 を検証します。
10. 次のバッチがより速くなるように、最終バイト数、比率、および設定を記録します。

厳格なサイズ予算を目標とする場合は、Compress Image to 100KB または Compress Image to 200KB のワークフローから始めることをお勧めします。モバイルページの場合は、比率の決定を Mobile Image Optimization Guide と組み合わせてください。

圧縮率と SEO はどのように関連していますか？

圧縮率は間接的に SEO に役立ちます。画像が小さいほど転送サイズが減り、特に圧縮された画像が適切にサイズ設定されている場合、ロードパフォーマンスが向上する可能性があります。しかし、検索エンジンやユーザーは依然として有用な画像、安定した URL、読みやすい周囲のテキスト、そして説明的な alt テキストを必要とします。

検索プレビューやソーシャルカードで壊れて見える小さな画像を配信しないでください。Google は、メタデータのために代表的な画像を選択し、より関連性の高い画像が存在する場合に構造化データや og:image のために一般的な画像を使用することを避けるよう明示的に推奨しています。画像は高速で明確である必要があります。

ブログ記事の場合、これは通常以下のことを意味します。

• フロントマターと Open Graph データにはユニークな WebP カバーを使用する。
• ソーシャルプレビューサイズでもカバーが読みやすいように保つ。
• 画像を、要点を説明するテキストの近くに配置する。
• キーワードを詰め込むのではなく、説明的な alt テキストを使用する。
• 最終アセットをクロール可能な CDN URL から配信する。
• アセットが間違っている限り、インデックスされた画像 URL を置き換えることは避ける。

比率はパブリッシング記録上の単なる一行です。これは、レンダリング幅、フォーマット、品質設定、バイトサイズ、および視覚的なメモの隣に位置すべきものです。

圧縮率チェックリスト

公開する前に、この短いレビューを実行してください。

有用な目標は「最大圧縮」ではありません。それは、ページを軽く保ち、画像を信頼できる状態に維持するための再現可能な設定です。迷った場合は、視覚的なチェックが合格した後でのみ、より小さいファイルを使用してください。