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

最終更新日: July 26, 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つのステージは以下の通りです。

ここでは、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を参照してください。

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パーセント優れています。

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

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

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

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

正確な数値よりも重要なルールが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パーセント小さいものでした。あなたの数値はコンテンツによって異なりますが、順序は一貫しています。これらの比較を自分で実行するための集中型のツールとして、画像圧縮ツールを試すか、AVIF vs WebP comparisonを読むことができます。

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

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

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

実践的なワークフローは以下の順序で行います：クリーンなマスターを保持する → 画像リサイズツールを使用して最大の表示ボックスにリサイズする → コンテンツに基づいてフォーマットを選択する → 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を膨張させます。正しい答えは、単一のグローバル設定ではなく、フォールバック付きの「コンテンツごとのフォーマット決定」であることがほとんどです。

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

よくある質問

非可逆圧縮と可逆圧縮の違いは？

非可逆圧縮は知覚上の細部を恒久的に捨てて大幅に小さくし、可逆圧縮は冗長性だけを取り除いて元の画素を1ピクセル単位で復元します。

JPEG が離散コサイン変換を使う理由は？

DCT は 8×8 画素ブロックのエネルギーを少数の周波数係数に集中させるため、量子化で最も目立たない成分だけを最小限の劣化で捨てられます。

JPEG のハフマン符号化は実際に何を圧縮している？

ハフマン符号化は出現頻度の高い量子化値ほど短いビット列を割り当てます。JPEG の最終的なバイト削減のかなりの部分は、実はここから生まれています。

GIF の LZW は PNG の方式とどう違う？

LZW は繰り返し現れるバイト列の辞書をその場で構築します。PNG はまず各走査線を予測器でフィルタし、その結果に Deflate（LZ77 とハフマンの組み合わせ）をかけます。

写真に GIF が向かないのはなぜ？

GIF は LZW が動く前の段階で 256 色パレットへの減色を強制します。この減色による写真の劣化のほうが、LZW 圧縮そのものより遥かに大きいのです。

実際のところ AVIF は JPEG よりどれだけ小さい？

同一の 1200×800 写真を直接エンコードした結果、視覚的に同等の品質で、AVIF の品質 60 は JPEG の品質 75 より約 45%、WebP の品質 75 より約 26% 小さくなりました。

AVIF のエンコードが WebP より大幅に遅いのはなぜ？

AVIF は扱うブロックが大きく、方向予測モードが 67 種類あり、ループ内フィルタも行うため、エンコードの計算量が WebP のおよそ 5〜10 倍になります。

最小サイズのために常に AVIF へ変換すべき？

そうとは限りません。AVIF の遅いエンコードはリクエスト処理の即時経路を圧迫しますし、旧来のブラウザやメールクライアント向けに JPEG のフォールバックが依然として必要です。

画像クレジット

• Abstract pixelated pattern in blue and pink — photo by Suzy Hazelwood on Pexels
• Colorful test-pattern bars — photo by Tim Mossholder on Pexels
• Close-up of colorful source code on a screen — photo by Pixabay on Pexels