JPEGの33年：なぜ1992年のフォーマットが消えないのか

.jpgファイルをhexエディタで開くと、最初に現れるのは先頭2バイトだけだ。

FF D8

これがSOI（Start of Image）マーカーで、JPEGファイルの始まりを示す。そのあとに続くバイト列は、これがどのJPEG亜種か、どの色空間を使うか、ピクセルデータがどこから始まるかをデコーダーに伝える。Webブラウザより前からあるこのフォーマットだが、2025年Web Almanacによれば、現代のWebで配信される画像の約**57%**を占めている。

JPEGを生んだストレージ危機

1986年、生の640 × 480グレースケール画像はディスク307 KBを消費した。同じ解像度のカラー画像には921 KB必要だった。20 MBのハードドライブが数百ドルし、1.44 MBフロッピーディスクが標準的な交換媒体だった時代に、1枚の非圧縮写真がフロッピー2枚分以上を占める。

必要だったのは、連続階調画像（写真であって線画ではない）向けの標準圧縮フォーマットだった。ISO/IECとITU-Tが1986年に設立したJoint Photographic Experts Group（JPEG）は、いくつかの有力なアイデアを1つの草案にまとめた。6年の洗練を経て、1992年にISO/IEC 10918-1として標準が公開された。

JPEGが唯一の画像フォーマットになることを目指したわけではない。目標はただ写真を保存・送信に十分小さくすることで、そのために情報を決まった順序で削っていく。

JPEGはなぜこれほど小さくなるのか

JPEG圧縮は単一のアルゴリズムではなく、複数のステージからなるパイプラインだ。それぞれの段階で、人間の視覚に気づかれにくいデータを取り除いていく。

色空間の変換（RGB → YCbCr）

画面はRGBで表示されるが、JPEGはYCbCrで保存する。Yは輝度（明るさ）、CbとCrは色差（青差と赤差）を表す。人間の目には輝度に敏感な錐体細胞が約250万個あり、色を感知するのは約10万個にすぎない。そのため、輝度のディテールは色のディテールよりずっと鮮明に見える。

クロマサブサンプリング

ほとんどのJPEGは4:2:0サブサンプリングを使う。輝度サンプル4つに対して、CbとCrはそれぞれ1つずつだ。つまりクロマチャンネルは輝度チャンネルの4分の1の解像度で保存される。4000 × 3000の画像なら、Yプレーンはフル解像度、CbとCrはそれぞれ2000 × 1500になる。本当の圧縮が始まる前に、生データの約50%を削減でき、ほとんどの人はその違いに気づかない。

離散コサイン変換（DCT）

画像は8 × 8ピクセルブロックに分割され、各ブロックをDCTに通す。これは空間データ（ピクセル値）を周波数データ（ブロック内で値がどれだけ速く変化するか）に変換する。結果は8 × 8の係数行列になる。左上の値はDC係数で、ブロックの平均輝度を表す。残り63個はAC係数で、だんだん高周波のディテールを表す。

高周波係数は細かいテクスチャ（髪の毛や草、ノイズ）を符号化し、低周波係数は大まかな形状（空、壁、肌の色合い）を符号化する。

量子化

ここでロスが発生する。JPEGは各DCTブロックに量子化テーブルを適用する。これは2つ目の8 × 8除数行列で、各DCT係数を対応する値で除算し、最も近い整数に丸める。

標準量子化テーブルは高周波係数を最も強く押さえ込む：

16  11  10  16  24  40  51  61
12  12  14  19  26  58  60  55
14  13  16  24  40  57  69  56
14  17  22  29  51  87  80  62
18  22  37  56  68 109 103  77
24  35  55  64  81 104 113  92
49  64  78  87 103 121 120 101
72  92  95  98 112 100 103  99

例えば、7という高周波係数が121で除算されると0に丸められる。消えた。元に戻すことはできない。デコーダーはその値を二度と見ることがない。これがロス圧縮の本質だ。データは再符号化されるのではなく、破棄される。

品質90では量子化値が小さいスケーリング係数で除算されるため、より多くの係数が残る。品質50ではスケーリング係数が大きくなり、より多くの係数がゼロになる。ファイルは小さくなり、画像は柔らかくなる。

エントロピー符号化

量子化後、残った係数はジグザグスキャンされ、ランレングス符号化され、ハフマン符号化で圧縮される。この段階はロスレスで、すでに破棄されたデータをより効率的に詰め込むだけだ。

1200万画素の非圧縮RGB画像は36 MBにもなる。JPEG品質90、4:2:0サブサンプリングで保存すると約3.5 MBに縮まる。10:1の削減で、拡大しない限り品質劣化は目に見えない。

実際にどれだけ劣化するのか

損傷は均一ではない。

品質が下がると、3種類のアーティファクトが目立ちやすくなる。ブロッキングは8 × 8グリッドの境界が浮き出る現象で、空のような滑らかなグラデーションで特に目立つ。リンギングは、文字の周りのような高コントラストなエッジに振動するハローが出ることだ。カラーブリーディングは、クロマサブサンプリングによって鋭い境界を越えて色が滲む現象だ。

もっとも困るのは**世代劣化（generation loss）**だ。JPEGを開いて編集し、再びJPEGで保存するたびに、RGB → YCbCr → サブサンプリング → DCT → 量子化というパイプラインが再実行される。丸め誤差が積み重なり、10世代後には水彩画のようになり、50世代後には元の内容を判別できなくなる。

再圧縮で起きる色ずれ（グリーンスフト）

JPEGを何度も再保存すると、色温度がずれていることに気づくことがある。一部の画像には薄らいだ緑味が乗り、別の画像はマゼンタに寄る。原因はクロマチャンネルの扱い方にある。

JPEGはCbとCrを低解像度で保存し、強く量子化する。保存のたびに両チャンネルに丸め誤差が入る。RGBへの逆変換には次の行列が使われる：

R = Y + 1.402 × (Cr - 128)
G = Y - 0.344136 × (Cb - 128) - 0.714136 × (Cr - 128)
B = Y + 1.772 × (Cb - 128)

緑はCbとCrの両方から計算される。繰り返し量子化でCbが少し上に、Crが少し下にずれても、Gチャンネルは変わる。Cbの正のバイアスは緑を下に押し、Crの負のバイアスは緑を上に押す。この相互作用は対称ではない。係数-0.344136と-0.714136が異なる大きさを持つからだ。結果、元のクロマ値が量子化境界の近くにあった領域で、緑が徐々に蓄積していく。

これが毎回起きるわけではない。エンコーダーの量子化テーブル、サブサンプリングモード、画像の内容によって左右される。ただし実在し、再現可能な現象で、プロのワークフローでJPEGの再保存を避ける理由の一つになっている。

なぜJPEGは消えないのか

JPEGが広く使われているのは完璧だからではない。十分に通用し、どこでも動くからだ。

特許面では、ベースラインJPEGの特許（Forgent Networks保有）は2006年に期限切れとなり、ロイヤリティフリーになっている。ハードウェア面では、カメラ、スマートフォン、プリンター、ブラウザが、シリコンか高度に最適化されたCでJPEGデコーダーを内蔵しており、レンダリングコストはほとんどかからない。品質面では、ソーシャルメディア、ニュースサイト、メール添付のような用途では、スマートフォン画面であれば品質75のJPEGはソースと区別がつかないことが多い。エコシステム面では、CMS、CDN、画像ライブラリ、レガシーアーカイブがみなJPEGを扱っており、より良いフォーマットがあってもペタバイト規模の既存アセットを移行する理由が必要だ。

JPEGに勝てなかったフォーマットたち

JPEGを倒そうとしたフォーマットはいくつもあるが、どれも完全には成功していない。

PNGはロスレス問題を解決したが、写真ではJPEGの5–10倍のファイルサイズになる。スクリーンショット、UIアセット、グラフィックスを支配している。

WebP（Google、2010）はサイズでJPEGを上回り、透過とアニメーションも追加した。今や主要なブラウザすべてに搭載されている。2025年Web Almanacによれば、WebPはLCP画像の**11%**を占め、2024年の7%から上昇した。現時点では安全なアップグレードパスだ。

HEIC（Apple、2017）はISOBMFFコンテナ内でHEVC圧縮を使う。JPEGより約40–50%小さく、1ファイルに複数画像を格納できる。Appleエコシステムを支配しているが、HEVCの特許プールのため、他の環境では普及が停滞している。

AVIF（AOM、2019）はAV1動画から派生した。広くサポートされたフォーマットの中では最高の圧縮率を達成し、同等品質でWebPより約30%小さい。欠点はデコード速度だ。モバイルデバイスではJPEGの2–3倍の時間がかかることがあり、バッテリーを消費しLCPを遅らせる。

JPEG XL（ISO/IEC 18181、2021）は技術的にこれらすべてを凌駕する。JPEGより50–60%小さく、デコードも速い。プログレッシブデコードに対応しており、ファイルの約1%をダウンロードした時点で表示可能な画像が得られる。最も重要なのは、既存のJPEGをロスレス再圧縮でき、約20%のサイズ削減を実現しつつ元のファイルをビット単位で復元できる点だ。他のフォーマットではこれができない。

2026年の現在地

JPEG XLのスタートは厳しかった。Googleは2021年にChromeで実験的サポートを追加したが、2022年10月31日に削除した（「ハロウィン決定」と呼ばれる）。公表された理由は、既存フォーマットに対するインクリメンタルな利益が不十分だったことだった。反発はすぐに起き、そのChromium issueはプロジェクト史上2番目にスター数が多いものになった。Googleが共同設立したAlliance for Open Mediaに関係するAVIFを守っているのではないかと非難された。

2025年末、Chromiumは方針を転換した。新しいRustデコーダー（jxl-rs）がChrome Canaryに導入され、Chrome 145は2026年2月にリリースされ、フラグの背後でJPEG XLサポートを搭載した。Safariは2023年からサポートしている。Firefox Nightlyも同じRustデコーダーを統合中だ。JPEG XLはまだデフォルトで有効ではないが、コードベースには戻ってきた。

一方、AVIFは2026年の現実的な選択だ。ブラウザサポートは広く、エンコーダーも改善し続けている。CloudinaryとCloudflareは、Acceptヘッダー交渉を通じて自動的にAVIFを配信する。CoreDashのデータによれば、AVIFまたはWebPを配信するページのLCP良好率の中央値は**81%で、JPEGのみのページは64%**だ。

33年後の現実

JPEGは33年前の妥協案だ。色の解像度、高周波テクスチャ、数値精度を引き換えに、1990年代にデジタル写真を現実にしたファイルサイズを実現した。そのアーティファクトはよく知られており、世代劣化や緑への色ずれも実際に起きる。

それでもJPEGが残っているのは、切り替えコストが現状維持の苦痛を上回っているからだ。QWERTYキーボードと同じようなものだ。

実用的な対処はいくつかある。まず、オリジナルはPNG、TIFF、または品質95以上のJPEGでアーカイブし、品質75のWeb書き出しから再編集しないこと。次に、ブラウザのAcceptヘッダーに基づいてAVIF、WebP、JPEG XLを交渉するCDNや画像サービスを使い、マスターは1つだけ保存してエッジでオンデマンド変換させること。そして、JPEGを一括再エンコードしないこと。各世代がデータを破壊するので、より小さいファイルが必要ならマスターから再エンコードする。

JPEGは急に消えることはない。GIFが影を潜めていったのと同じように、徐々に使われなくなっていくだろう。どのビューアでも開くし、どこでもサポートされているが、同じ仕事をより少ないバイトとより少ないアーティファクトでこなすフォーマットに、次第に勝てなくなっていく。今回は、置き換えるフォーマットが本当に機能し始めている。