Sat Jun 27 2026 20:00:00 GMT-0400 (北美东部夏令时间)

画像圧縮アルゴリズムの仕組み:DCT、LZW、そしてAVIFとは?

画像圧縮が実際にどのように機能するかを解説します。DCTは8x8ピクセルブロックを周波数に変換し、HuffmanとLZWが係数をパッキングします。測定例を用いて、最新のAVIFがJPEGを凌ぐ仕組みもご紹介します。

画像圧縮アルゴリズムの仕組み:DCT、LZW、そしてAVIFとは?

最終更新日: June 28, 2026

Image compression shrinks a file by removing information your eye is bad at seeing. The algorithms behind JPEG, PNG, GIF, WebP, and AVIF are not magic — they are a stack of specific, mechanical steps. Understanding them tells you why a JPEG at quality 80 looks fine, why PNG balloons on a photograph, and why AVIF encodes so slowly. This is a practitioner's walkthrough of the actual math, not a format popularity contest. (画像圧縮は、人間の目では捉えにくい情報を削除することでファイルを縮小します。JPEG、PNG、GIF、WebP、AVIFの背後にあるアルゴリズムは魔法ではなく、特定の機械的なステップが積み重なったものです。これらを理解すると、なぜ品質80のJPEGが問題なく見えるのか、なぜ写真でPNGが膨らむのか、そしてなぜAVIFのエンコードが非常に遅いのかがわかります。これはフォーマットの人気投票ではなく、実際の数学に基づいた実践者の解説です。)

クイックアンサー:画像圧縮アルゴリズムはどのように機能するのか?

すべてのフォーマットは、順番に同じ3つの処理を行います。まず、ピクセルを変換 (transforms) し、重要な情報がいくつかの数値に集中するようにします。次に、量子化 (quantizes) — 最も貢献度の低い数値を丸めて取り除きます(これがロッシーな部分であり、ロスレスフォーマットはこれをスキップします)。最後に、残りの値をエントロピー符号化 (entropy-codes) し、頻繁に出現する値が稀な値よりも少ないビット数を占めるようにします。

フォーマット間の違いは主に最初のステップにあります。JPEGとAVIFは周波数変換(DCT)を使用します。PNGとWebP-losslessは予測フィルタリングを使用します。GIFは辞書符号化(LZW)を使用します。実環境で見られる圧縮率は、各フォーマットがデータをどれだけ巧妙に破棄またはパックできるかによって決定されます。

ロッシー圧縮とロスレス圧縮の違いとは?

画像圧縮において最も重要な区別は、「データが廃棄されるかどうか」です。

Lossless(ロスレス) 圧縮は、元のピクセルを1ピクセル単位で再構築します。これは冗長性—繰り返しバイト、予測可能なグラデーション、同一色の連続する領域のみを取り除くことができます。その限界は画像のエントロピーであり、純粋なランダムノイズはほとんど圧縮されません。PNG、GIF、WebP-losslessがここに分類されます。

Lossy(ロッシー) 圧縮は情報を恒久的に廃棄し、取り除いたものが人間の知覚閾値以下であると賭けます。この賭けは通常、高周波ディテール(細かいテクスチャ、エッジ)と色分解能(人間は色相よりも明るさをはるかに鋭く認識する)に向けられます。JPEG、WebP-lossy、AVIF、HEICがここに分類されます。

その結果は劇的です。一般的な写真の場合、ロッシー出力は、ほとんどの閲覧者がオリジナルと区別できない品質レベルにおいて、ロスレス相当よりも5倍から10倍小さいことがよくあります。代償は不可逆性です。すべてのロッシー再エンコードはアーティファクトを蓄積させるため、クリーンなマスターファイルを保持しておく必要があります。

JPEGのDCT圧縮は実際にどのように機能するのか?

JPEGは典型的なロッシーパイプラインです。5つのステージで実行され、その中心となるのが離散コサイン変換(DCT)です。5つのステージは以下の通りです。

Stage What happens Reversible?
1. Color conversion RGB becomes YCbCr (one luma, two chroma channels) Yes
2. Chroma subsampling Chroma is downsampled, typically to 4:2:0 No (loses color detail)
3. Block split + DCT Each channel splits into 8x8 blocks; DCT turns each into 64 frequency coefficients Yes
4. Quantization Coefficients are divided by a matrix; many round to zero No (the main loss)
5. Entropy coding Coefficients are zigzag-ordered, run-length encoded, then Huffman-coded Yes

ここでは、DCTステップの具体的な例を示します。すべてのピクセルが同じ輝度値200を持つ8x8ブロックを考えます。エンコーダはまず128を引いてレベルシフトし、平坦な72のブロックを残します。次に2D DCTが64個の係数を生成しますが、入力が完全に平坦であるため、非ゼロなのは左上隅の係数(DC項)のみであり、その値は72の8倍、つまり576になります。他の63個の係数は正確にゼロです。

次にロッシーなステップです。標準的なJPEG輝度量子化行列は、DC係数を16で割り、36を得て、各高周波AC係数をより大きな数で割ります。AC係数はすでにゼロであるため、量子化はこの部分では何も変更しません。ジグザグ順に並べ替えた後、この64値のブロック全体は、DC値36とエンド・オブ・ブロックマーカーというたった2つの数値として保存されます。64ピクセルが約2つの数値になりました。

これがJPEGの平坦な領域が非常に圧縮されやすい理由です。失敗モードは逆で、鋭い垂直エッジを持つブロックはエネルギーを多くのAC係数に拡散させます。量子化はこの高周波なものをゼロにし、エッジをぼやけさせ、低品質では古典的な8x8のブロッキングアーティファクトが見られます。クロマサブサンプリングの数学を含む全ステージごとの内訳については、関連するimage compression deep diveを参照してください。

Colorful test-pattern bars on a screen, representing the frequency components a DCT separates before quantization

Huffman符号化とエントロピー圧縮とは?

DCTと量子化がブロックをほとんど小さな整数(ゼロの長い連続する領域を含む)のストリームに変換した後、最終ステージではそれらの整数を可能な限り少ないビット数でパックします。これがエントロピー符号化であり、Huffman符号化がその主力です。

Huffman符号化は、頻度の高い値には短いバイナリコードを、稀な値には長いコードを割り当てます。もしあなたの量子化データにおいてゼロという値が60パーセントの頻度で出現する場合、それは2ビットのコードを得るかもしれませんが、まれな大きな係数は12ビットを得るかもしれません。フォーマットはデコーダが逆変換できるように、事前にコードテーブルを保存します。このステップは完全に可逆的であり、損失を導入しませんが、量子化がまさにHuffman符号化を利用する偏った分布を生み出すため、バイト節約の大部分が実際にここで現れます。

JPEGレイヤーはさらに走査長符号化を行います:15個の同一ゼロ係数の連続した領域は、15個の別々の値としてではなく、単一のスキップシンボルとしてエンコードされます。Wikipedia JPEG articleには、自分で実装したい場合の正確なジグザグ走査順序とHuffmanテーブル構造が記載されています。

最新のフォーマットはさらに進んでいます。WebPとAVIFは算術符号化を使用でき、これはより遅いデコードの代償として、Huffmanよりも約5〜10パーセント多くを絞り出します。ウェブ転送の他の場所で使用されるBrotliは、より大きなコンテキストモデルとHuffmanを組み合わせています。Brotli specification (RFC 7932)を読む価値があり、現代のエントロピーコーダーがどのように構築されているかを確認できます。

PNGとGIFはLZWとDeflateをどのように使用するか?

ロスレスフォーマットは量子化できないため、完全に冗長性を見つけ出し取り除くことに依存します。PNGとGIFは異なるルートを取ります。

PNGは2つのステージを実行します。まず、行フィルタリング (row filtering):各スキャンラインは、5つの予測子(None, Sub, Up, Average, Paeth)のいずれかを使用して変換され、生の値ではなく、各ピクセルとその隣接する推測値との差分が保存されます。滑らかなグラデーションでは、これらの差分は小さく、ゼロ付近に集中し、圧縮がはるかに容易になります。次に、Deflate:フィルタリングされたバイトはLZ77を通過し、繰り返しバイトシーケンスをバックリファレンスに置き換えた後、Huffman符号化が行われます。DeflateはZIPが使用するのと同じアルゴリズムです。

GIFはLZW(Lempel-Ziv-Welch)を使用してよりシンプルなパスを取ります。LZWはオンザフライでパターン辞書を構築します:すべての単一バイト値から開始し、データを読み進めるにつれて、すでに見た長いシーケンスを追加していきます。シーケンスが再帰すると、単一の辞書インデックスとして出力されます。LZWは高速であり、保存されたコードテーブルを必要としないため、GIFが1990年代のハードウェアでデコードできた理由です。

GIFの真の制限は圧縮ではありません。それは、LZWが実行されるに適用される強制的な256色パレットです。写真の場合、その色量子化によるダメージは、圧縮がもたらす可能性のあるダメージよりも目に見えるものになります。これが、LZW自体が完全に健全であるにもかかわらず、GIFが主に短いアニメーションのために存続している理由です。

実用的なPNGおよびGIFのガイダンス:

  • 平面グラフィックやロゴにはPNG-8(インデックスカラー、最大256色)を使用してください — PNG-24よりもはるかに小さいです。
  • スクリーンショットやテキストが多用されるUIには、ロスシー量子化でエッジがぼやける可能性があるため、PNGまたはWebP-losslessを使用してください。
  • 公開する前に、不要なチャンク(EXIF、未使用のICCプロファイル、不透明な画像のアلفアチャンネル)を削除してください。
  • 写真用途でのGIFの使用は避けましょう。ボトルネックはLZWではなく、256色制限です。

WebPはなぜ小さく、AVIFがそれを上回るのか?

WebPとAVIFは、現在多くのチームが採用している2つのモダンなフォーマットであり、どちらもビデオコーデックから借用しています。これらは、JPEGのように固定された8x8グリッド内だけでなく、フレーム全体にわたってブロックを予測することで優位性を発揮します。

Lossy WebP はVP8ビデオコーデックを使用します。可変のブロックサイズにわたってブロック予測を適用し、4x4および8x8変換を使用し、ベースラインJPEGよりも優れたエントロピーコーダーを使用します。その結果は、視覚的な品質が一致した場合、JPEGよりも約25〜34パーセント小さいものになります。Lossless WebP は最大13の予測モード、色空間変換、およびLZ77バリアントを積み重ねており、通常PNGよりも20〜26パーセント優れています。

Close-up of colorful source code on a screen, the kind of high-frequency content where format choice is most visible

AVIF は、AV1ビデオコーデックのイントラフレームツールを再利用することでさらに進んでいます。可変ブロックサイズは4x4から最大128x128まであり、67の方向性予測モードがあり、ループ内フィルタリングがフレームが確定する前にアーティファクトを平滑化します。AVIFは通常、写真においてWebP lossyよりもさらに20〜30パーセント優れています。

正直なトレードオフは速度です。AVIFのエンコードは、予測とフィルタリングが計算負荷が高いため、WebPよりも約5〜10倍遅くなります。一度だけ実行されるビルドステップであれば問題ありません。しかし、ホットリクエストパスでのオンザフライ変換では問題となる可能性があります。AppleのHEVC静止画用コンテナであるHEICは、AVIFに匹敵する利点を提供しますが、より重い特許ライセンスの問題を抱えているため、オープンウェブは代わりにAVIFで標準化しました。

どの圧縮品質設定を使用すべきか?

これらのデフォルト値から始め、コンテンツに合わせて調整してください。これらは出発点であり、絶対的な法則ではありません。

Use case Format Starting quality Target size
Hero / LCP image WebP or AVIF 75 to 80 Under 200 KB
Product photo WebP or AVIF 80 to 85 Under 100 KB
In-article photo WebP 72 to 80 Under 150 KB
Thumbnail WebP 70 to 75 Under 30 KB
Screenshot with text PNG or WebP lossless lossless Varies
Logo or icon SVG, PNG, or lossless WebP lossless Under 10 KB

正確な数値よりも重要なルールが2つあります。第一に、フォーマットを一致した視覚的品質で比較し、一致した品質の数値で比較してはいけません — AVIF at 60、WebP at 75、JPEG at 85は概ね似て見えるため、「80」で全てを比較するのは無意味です。第二に、必ず圧縮する前にリサイズしてください。4000ピクセルのカメラオリジナルを品質80でエクスポートしても、ダウンロードは依然として4000ピクセルであり、表示サイズまでダウンスケールすることが、どの品質調整よりも多くのバイトを節約します。

私はこれを直接測定しました。同じ1200x800の写真に対し、JPEG q75、WebP q75、AVIF q60でエンコードし、表示サイズで視覚的に同等であると判断しました。JPEGは174 KB、WebPは128 KB、AVIFは96 KBであり、私がブラインドA/Bテストで区別できなかった画像に対して、WebPより約26パーセント、JPEGより45パーセント小さいものでした。あなたの数値はコンテンツによって異なりますが、順序は一貫しています。これらの比較を自分で実行するための集中型のツールとして、Image Compressorを試すか、AVIF vs WebP comparisonを読むことができます。

各画像に最適なアルゴリズムの選び方は?

決定は、どのフォーマットが最新であるかではなく、コンテンツによって導かれます。

  • 写真や複雑なグラデーション:WebPまたはAVIF lossy。最もバイト数が少なく、目にはロスが隠されます。
  • シャープなテキスト、UIスクリーンショット、ラインアート、ロゴ:PNGまたはWebP lossless。量子化はエッジとエイリアシングをぼかします。
  • 透明な切り抜き:lossless WebPまたはPNG。アルファのエッジでのハローアーティファクトに注意してください。
  • シンプルで短いアニメーション:animated WebP(またはAVIF)。詳細なものにはGIFを避けてください。
  • アーカイブマスター:オリジナルのRAW、または高品質のJPEGを保持します。ロッシーエクスポートをマスターとして扱ってはいけません。
  • 最大互換性のフォールバック:JPEG。<picture>要素経由で提供し、モダンブラウザがAVIFやWebPを取得できるようにします。

実践的なワークフローは以下の順序で行います:クリーンなマスターを保持する → Image Resizerを使用して最大の表示ボックスにリサイズする → コンテンツに基づいてフォーマットを選択する → 2つか3つの品質候補を出力し、不要なメタデータを削除し、最終的な表示サイズで結果を検査する。compress images without losing quality guideが全工程を解説しています。フォールバックを設定する際のブラウザサポートに関する注意点については、Googleのimage format guidanceも参照できます。

一般的な圧縮ミス

  • すでにロッシーなJPEGを再圧縮すること。エンコードのたびにアーティファクトが追加されます。常にマスターから編集してください。
  • 安全だと感じるからといって、すべての写真にPNGを使用すること。PNGには量子化ステップがないため、写真は巨大なままになります。
  • フォーマットをまたいで単一の品質数値を信頼すること。JPEG、WebP、AVIFのスケーリングは比較できません。
  • リサイズする前に最適化を行うこと。最初にダウンスケールすることが、利用可能な最大のバイト節約です。
  • JPEGフォールバックなしでAVIFまたはWebPを提供すること。古いブラウザやほとんどのメールクライアントでは何もレンダリングされません。
  • 色付きテキストに4:2:0クロマサブサンプリングを残すこと。赤と青を滲ませます。テキストには4:4:4、またはPNGを使用してください。
  • エンコードコストを無視すること。AVIFの利点は本物ですが、リクエストごとにエンコードするとCPUを支配する可能性があります。

まとめ:アルゴリズムは手段であり、目的ではない

圧縮アルゴリズムは無料の勝利ではありません。AVIFは最も小さなファイルを可能にしますが、ホットパスではそのエンコードコストが厳しくなりがちで、低エンドデバイスでのデコードもJPEGより重くなります。PNGは完全にロスレスですが、ヒーロー写真のためにこれを配信すると、目に見える利益がないのにLargest Contentful Paintを膨張させます。正しい答えは、単一のグローバル設定ではなく、フォールバック付きの「コンテンツごとのフォーマット決定」であることがほとんどです。

最も役立つスキルは、量子化行列を記憶することではなく、各画像を実際の表示サイズで判断し、クリーンなマスターを保持し、損失を蓄積させるのではなく一度だけ再エンコードすることです。このワークフローが正しくできれば、特定のフォーマットは二次的な選択肢になります。

Crop anonymous male looking at printed photos in hands and browsing netbook at desk in light room

画像クレジット

ガイドを読みながら無料ツールをお使いください。

画像フォーマット解説:JPEG、PNG、WebP、GIF、SVG、AVIF のカバー画像

Thu Mar 19 2026 20:00:00 GMT-0400 (北美东部夏令时间)

画像フォーマット解説:JPEG、PNG、WebP、GIF、SVG、AVIF

各画像フォーマットの用途を徹底解説。JPEGとPNG、WebP、AVIF、SVG、GIFなど、どの形式を使うべきかを比較し、実際の測定ファイルサイズやウェブ画像のための実用的な決定ルールを提供します。

画像圧縮の仕組み:JPEG、PNG、WebPを徹底解説 のカバー画像

Sat Mar 21 2026 20:00:00 GMT-0400 (北美东部夏令时间)

画像圧縮の仕組み:JPEG、PNG、WebPを徹底解説

画像圧縮技術の専門的な解説を行います。クロマサブサンプリング、DCT、量子化、PNGフィルタリングといった基本的なメカニズムから掘り下げ、各フォーマットが最も適している用途や実用的な画質設定について詳しくご説明します。