任意の .jpg ファイルをhexエディタで開く。先頭2バイト：
FF D8
これが**Start of Image（SOI）マーカーだ。すべてのJPEGファイルはこれで始まる。地球上のすべてのJPEGデコーダーはこれを探す。その後のバイトは、これがどのJPEG亜種か、どの色空間を期待すべきか、ピクセルデータがどこから始まるかをデコーダーに伝える。このフォーマットはWebブラウザより古いにもかかわらず、2025年Web Almanacによると現代のWebで配信される画像の約57%**を担っている。
JPEGを生んだストレージ危機
1986年、生の640 × 480グレースケール画像はディスク307 KBを消費した。同解像度のカラー画像は921 KB必要だった。20 MBハードドライブが数百ドルし、1.44 MBフロッピーディスクが標準的な交換媒体だった時代に、1枚の非圧縮写真がディスクの3分の2を埋めることになる。
必要とされたのは明確だった：連続階調画像——写真であって線画ではない——向けの標準圧縮フォーマットだ。複数のグループがこの問題に取り組んでいた。1986年にISO/IECとITU-Tによって設立されたJoint Photographic Experts Group（JPEG）は、最も優れたアイデアを1つの草案にまとめた。6年の洗練を経て、1992年にISO/IEC 10918-1として標準が公開された。
JPEGは決して唯一の画像フォーマットになるつもりはなかった。設計された目的は1つ：写真を保存・送信に十分小さくすることだ。その目的は、情報を非常に特定の順序で破棄することで達成される。
JPEGがこれほど高圧縮である理由
JPEG圧縮は単一のアルゴリズムではなくパイプラインだ。各ステージで人間の視覚系が最も気づきにくいデータが除去される。
1. 色空間変換（RGB → YCbCr）
画面はRGBを表示する。JPEGはYCbCrを保存する。Yチャンネルは輝度（明るさ）を担う。CbとCrは色差（青差と赤差）を担う。これが重要なのは、人間の目には輝度に調整された約250万個の錐体細胞があるのに対し、色に調整されたのは10万個しかない。輝度のディテールは色のディテールよりはるかに鮮明に見える。
2. クロマサブサンプリング
ほとんどのJPEGは4:2:0サブサンプリングを使用する。輝度サンプル4つに対してCbサンプル1つ、Crサンプル1つ。つまりクロマチャンネルは輝度チャンネルの4分の1の解像度で保存される。4000 × 3000の画像では、Yプレーンがフル解像度。CbとCrプレーンはそれぞれ2000 × 1500。本当の圧縮が始まる前に、生データの約50%が削減され、ほとんどの閲覧者は気づかない。
3. 離散コサイン変換（DCT）
画像は8 × 8ピクセルブロックに分割される。各ブロックはDCTに通され、空間データ（ピクセル値）を周波数データ（ブロック内で値がどれだけ速く変化するか）に変換する。結果は8 × 8の係数行列になる。左上の値はDC係数——ブロックの平均輝度だ。残り63個は、段々と高周波のディテールを表すAC係数だ。
高周波係数は微細なテクスチャを符号化する：髪の毛、草、ノイズ。低周波係数は大まかな形状を符号化する：空、壁、肌の色合い。
4. 量子化
ここでロスが発生する。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ではスケーリング係数が大きい。より多くの係数がゼロになる。ファイルは小さくなる。画像は柔らかくなる。
5. エントロピー符号化
量子化後、残りの係数はジグザグスキャンされ、ランレングス符号化され、ハフマン符号化で圧縮される。この段階はロスレスだ。すでに破壊されたデータをより効率的に詰め込むだけだ。
結果：1200万画素の非圧縮RGB画像は36 MB。JPEG品質90、4:2:0サブサンプリングで保存すると約3.5 MBに縮まる。10:1の削減であり、拡大しない限り品質劣化は目に見えない。
実際にどれだけロスがあるのか？
損傷は均一ではない。
| 品質 | 典型的サイズ（1200万画素） | 視覚的影響 |
|---|---|---|
| 95+ | ~8 MB | ほぼ見えない；アーカイブ向き |
| 90 | ~3.5 MB | わずかな柔らかさ；カメラ標準 |
| 75 | ~1.8 MB | 微細ディテールでぼけが目立つ；Web標準 |
| 50 | ~1.0 MB | 100%ズームでブロックノイズが明瞭 |
| 30 | ~600 KB | 色バンディング、モスキートノイズ、印刷不可 |
品質が下がるにつれ、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を下に、たった1量子化ステップずつずらしても、Gチャンネルはずれる。Cbの正のバイアスは緑を下に押す。Crの負のバイアスは緑を上に押す。この相互作用は対称ではない。なぜなら係数-0.344136と-0.714136は異なる大きさを持つからだ。結果：元のクロマ値がすでに量子化境界付近だった領域で、緑が徐々に蓄積する。
これは必ず起きる効果ではない。エンコーダーの量子化テーブル、サブサンプリングモード、画像コンテンツに依存する。だがこれは実在し、再現可能であり、プロのワークフローがJPEGの再保存を避ける理由の一つだ。
JPEGにこんな欠陥があるのに、なぜすべてがJPEGを使うのか？
JPEGが普及しているのは完璧だからではない。普及しているのは十分で普遍的だからだ。
- 特許ロックインなし：ベースラインJPEG特許（Forgent Networks保有）は2006年に期限切れ。ロイヤリティフリーだ。
- ハードウェアデコード：すべてのカメラ、スマートフォン、プリンター、ブラウザに、シリコンか高度に最適化されたCでJPEGデコーダーが組み込まれている。レンダリングコストはほぼゼロ。
- 十分に良い：ソーシャルメディア、ニュースサイト、メール添付では、スマートフォン画面では品質75のJPEGはソースと区別がつかない。
- エコシステムの慣性：CMS、CDN、画像ライブラリ、レガシーアーカイブはみなJPEGを話す。置き換えるには、より良いフォーマットだけでは不十分だ。ペタバイト規模の既存アセットを移行する理由も必要だ。
勝つべきだったフォーマットたち
JPEGを打倒しようとしたフォーマットはいくつかある。どれも完全には成功していない。
| フォーマット | ロス | ロスレス | 透過 | アニメーション | 最大ビット深度 | 主要な利点 |
|---|---|---|---|---|---|---|
| JPEG | 有り | 無し | 無し | 無し | 8-bit | ユニバーサルサポート |
| PNG | 無し | 有り | 有り | 無し | 16-bit | 完全ロスレス、アルファ |
| WebP | 有り | 有り | 有り | 有り | 8-bit | JPEGより25–35%小さい、ブラウザネイティブ |
| HEIC | 有り | 有り | 有り | 有り | 16-bit | JPEGより約50%小さい、Apple既定 |
| AVIF | 有り | 有り | 有り | 有り | 12-bit | 現時点で最高の圧縮率、ロイヤリティフリー |
| JPEG XL | 有り | 有り | 有り | 有り | 32-bit | ロスレス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%のサイズ削減を実現しつつ、元のファイルをビット単位で復元できる。他のどのフォーマットもこれはできない。
現在地
JPEG XLの幼少期は厳しかった。Googleは2021年にChromeで実験的サポートを追加し、2022年10月31日に削除した——「ハロウィン決定」と呼ばれる。公表された理由：既存フォーマットに対するインクリメンタルな利益が不十分だった。反発は即座だった。そのChromium issueはプロジェクト史上2番目にスター数が多いものになった。Googleは、Googleが共同設立したAlliance for Open Mediaに紐づくAVIFを守っていると非難された。
2025年末、Chromiumは方針を転換した。新しいRustデコーダー（jxl-rs）がChrome Canaryにlandingした。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%**だ。
結論
JPEGは33年前の妥協案だ。色の解像度、高周波テクスチャ、数値精度を引き換えに、1990年代にデジタル写真を現実にしたファイルサイズを実現した。アーティファクトはよく理解されている。世代劣化は実在する。グリーンスフトも起きる。
それでもJPEGが存続するのは、QWERTYキーボードが存続するのと同じ理由だ：切り替えコストが、現状維持の苦痛を上回る。
実用的な前進パスは階層的だ：
- 高品質マスターを保持する。オリジナルをPNG、TIFF、または品質95以上のJPEGでアーカイブする。品質75のWeb書き出しから再編集してはいけない。
- 現代フォーマットを動的に配信する。ブラウザの
Acceptヘッダーに基づいてAVIF、WebP、JPEG XLを交渉するCDNや画像サービスを使う。マスターは1つだけ保存し、エッジでオンデマンド変換させる。 - JPEGを一括再エンコードしない。各世代がデータを破壊する。より小さいファイルが必要なら、別のJPEGではなくマスターから再エンコードする。
JPEGは突然死ぬことはない。GIFが消えたのと同じように、徐々に薄れていく：どこでもサポートされ、どのビューアでも開くが、同じ仕事をより少ないバイトとより少ないアーティファクトでこなすフォーマットに段々と勝てなくなる。違いは、今回は置き換えるフォーマットが実際に勝ちつつあるということだ。
