2026年のWeb画像フォーマット選び：JPEGの帝国、AVIFの台頭、JPEG XLの亡命

1枚の12 MPの写真（4000 × 3000ピクセル）を、6通りで書き出してみる。PNGなら24 MB。品質90のJPEGなら3.4 MB。同等の見た目の画質に揃えたWebPなら約2.4 MB。同じく画質を揃えたAVIFなら約1.7 MB。256色の上限までディザリングで落としたGIFは6 MBで、いたるところにバンディングが目立つ。SVGはこのリストにはない。SVGが記述するのは図形であり、写真は図形ではないからだ。

画面に映るのは同じ画像、ディスク上の差は14倍。この差は好みではなく工学の問題だ。各フォーマットは、特定の年の特定の制約のもとで下された技術判断の束であり、その判断は今日もあなたのページ容量にそのまま現れている。

この記事では、その実験をもとに選び方を整理する。各フォーマットが実際にピクセルに何をするのか、2026年半ばにどのブラウザがデコードできるのか、現実のWebが何を配信しているのか。そして最後には、チームのwikiにそのまま貼れる決定表を置く。

各フォーマット、ひとつずつ見ていく

JPEG（1992年）。 仕組み：画像を8 × 8ブロックに分割し、各ブロックを離散コサイン変換で周波数に変換してから、人間の視覚モデルに基づいて細かい成分をゼロに向けて量子化する。強み：90年代半ば以降に作られたあらゆるデバイスでデコードでき、エンコードが速く、連続階調の写真に優れる。弱み：透過なし、アニメーションなし、シャープなエッジや文字のまわりにリンギングが目立ち、保存し直すたびに劣化が蓄積していく。向いているのは写真、そしてどの環境でも確実に開ける必要があるすべてのものだ。

PNG（1996年）。 仕組み：完全な可逆圧縮。各スキャンラインを予測器でフィルタリングしてから、DEFLATE（gzipの中身と同じLZ77とハフマン符号化の組み合わせ）で詰める。強み：ピクセル単位で完全に正確な出力、フルアルファ、普遍的な対応。弱みは写真だ。センサーノイズが予測器を無力化するため、12 MPの写真を圧縮しても生ピクセルに対してせいぜい1.5:1程度にしかならない。向いているのはスクリーンショット、UIのキャプチャ、図表、そして文字や平坦な色を含むすべてのものだ。

GIF（1987年）。 仕組み：最大256色のパレットに対するLZW圧縮で、複数フレームを1ファイルに詰められる。残された唯一の強みは、どこでも再生できるアニメーションだ。最新のフォーマットに対応していないメールクライアントでも動く。弱みはそれ以外のすべてだ。256色、1ビットの透過、同等の動画よりはるかに大きなファイル。向いているのはミームと小さなUIループだ。

SVG（2001年）。 仕組み：ラスターの意味では「なし」。SVGは図形、パス、グラデーションを記述するXMLであり、レンダラーが画面に必要な解像度でピクセルを描き出す。強み：解像度に依存しない、幾何学的なアートでは極小、CSSでスタイルを当てられる。弱み：本当にベクターであるコンテンツにしか使えないこと。そして、数千のノードや重いフィルターを含む極端なファイルは、ビットマップより高くつくこともある。向いているのはロゴ、アイコン、チャート、図表だ。

WebP（2010年）。 仕組み：非可逆モードはVP8動画コーデックのイントラフレーム予測を借り、可逆モードは空間予測とLZ77風の後方参照を使う。強み：1フォーマットに両モード、非可逆モードでもアルファ、アニメーション対応、そしてGoogle自身の調査で同等画質のJPEGより25〜34%小さいファイル。弱み：16383 × 16383ピクセルという厳格な上限と、libjpegよりCPUを食うエンコーダー。ほぼすべてに向いており、だからこそWeb上でJPEG、PNG、GIFのデフォルトの置き換え先になった。

AVIF（2019年）。 仕組み：AV1動画コーデックの静止画をHEIFコンテナに包んだもの。強み：ブラウザで配信できる最高の非可逆圧縮。Netflixの2020年のテストでは同等画質のJPEGより約50%小さく、さらに10ビット・12ビットカラー、HDR、アルファ、アニメーションに対応する。弱み：エンコードが本当に遅い、プログレッシブレンダリングがない（画像は一気に表示されるか、まったく表示されないかのどちらか）、そして極端に低い品質設定では、JPEGの素直なブロッキングとは違う、テクスチャのにじみが出る。向いているのは、ファイルサイズが最も重要になる写真やヒーローイメージだ。

HEIC（2015年）。 仕組み：HEVCの静止画で、これもHEIFコンテナ入り。強み：AV1級の圧縮率と、2017年以降すべてのiPhoneのデフォルト撮影フォーマットであること。弱みは技術ではなく法律だ。HEVCはパテントプールに取り囲まれており、Apple以外のブラウザベンダーはすべて、ライセンス料の支払いを拒んだ。居場所はカメラロールであり、Webではない。

JPEG XL（2021年）。 仕組み：非可逆用のVarDCTと可逆用のモジュラーモードという2つのエンジンが1つの屋根の下にあり、さらに他のどのフォーマットにもない機能がある。既存のJPEGを可逆のまま、ピクセルをビット単位で保ったまま約80%のサイズに再圧縮できるのだ。強み：プログレッシブデコード、優れた可逆圧縮率、高忠実度の写真。弱みは普及度で、これは主にブラウザベンダーをめぐる政治的な話であり、後述する。向いているのは写真のパイプラインとアーカイブ、そしてAppleデバイス上ではWebでも使える。

ブラウザ対応状況、2026年半ば

caniuseのデータに基づく、各フォーマットがデフォルトで有効になったバージョン：

フォーマット	Chrome	Edge	Firefox	Safari
WebP	32（2014年1月）	18（2018年11月）	65（2019年1月）	14（2020年9月）
AVIF	85（2020年8月）	121（2024年1月）	93（2021年10月）	16.4（2023年3月）
JPEG XL	145、フラグ有効時（2026年2月）	なし	フラグ有効時	17（2023年9月）
HEIC	なし	なし	なし	17（2023年9月）

この表には注目すべき点が3つある。iOSのAVIFは技術的にはSafari 16.0で対応したが、アニメーションは含まれなかった。macOSとiOSの両方で完全対応になったのは16.4だ。EdgeはChromiumでありながらChromeより何年も遅れてAVIFを搭載した。MicrosoftがGoogleよりも長くデコーダーを無効のままにしていたからだ。そしてJPEG XLの行には珍しい経緯が隠れており、これには後で専用の節を設ける。

caniuseの2026年の数字による世界カバー率は、WebPが約97%、AVIFが約93〜94%。JPEGとPNGは実質100%であり、それが変わることはなさそうだ。

互換性のヒエラルキー

リーチの広さで分類すると、フォーマットは5つの層に分かれる。

第1層は普遍的なセットだ。JPEG、PNG、GIF、SVG。あらゆるブラウザ、あらゆるメールクライアント、あらゆるOSのプレビューペイン、あらゆる10年前のキオスク端末でデコードできる。ファイルが絶対に開けなければならないなら、この4つのどれかで出す。

第2層はWebP単独だ。最後まで残った大手の未対応ブラウザはSafariで、Safari 14が2020年9月にその穴を埋めた。残るはInternet Explorerの残存環境と古いAndroid WebViewくらいだ。メールではなくWebサイトの話であれば、WebPはここ5年ほど安全なデフォルトであり続けている。

第3層はAVIFだ。Chromeは2020年、Firefoxは2021年、Safariは2022年（2023年3月の16.4で完全対応）、Edgeは2024年1月にデフォルトで有効にした。2024年初頭以降、主要エンジンはすべてAVIFを追加設定なしでデコードする。残りの数%は古いiPhoneと管理対象外のWindows端末群であり、そこはフォールバックの出番だ。

第4層は、停滞したままのJPEG XLだ。Appleは2023年9月のSafari 17以降、ネイティブで搭載している。GoogleはChromiumの実験的デコーダーを2022年末に削除し（2023年2月のChrome 110で適用）、その後方針を転換してRust製デコーダー（jxl-rs）をマージした。これは2026年2月のChrome 145で搭載されたが、いまだフラグの内側だ。Firefoxも何年もフラグの内側にデコーダーを置いている。つまり2026年半ば時点でJPEG XLに対応しているのは、全Appleユーザーと、フラグを有効にするChrome・Firefoxユーザーのごく一部を足したもので、頼りにするには小さすぎる母集団だ。

第5層はHEICだ。AppleプラットフォームのSafari 17のみ、ほかは世界中どこにもない。これはもう層というより、単一ベンダーのエコシステムだ。

現実のWebが配信しているもの

対応と利用は別物だ。HTTP ArchiveのWeb Almanacは実際の数百万ページをクロールし、配信されているものを数えている。2024年版（メディアデータが揃っている最新版）を読むと、氷河のようにゆっくり動いているように見える。JPEGは全画像の32%で依然として最多のフォーマットだったが、2022年の40%から8ポイントも下げている。WebPはそのうち3ポイントを拾って12%に届いた。SVGは約2ポイント伸ばした。AVIFは約1%に到達した。丸め誤差のように聞こえるが、相対的に読めば違う。2年でほぼ4倍の成長だ。ICOは1.3%を保ったが、そのほとんどはファビコンだ。そして登場から37年のGIFは、なぜか1ポイント伸ばした。

なぜこんなにゆっくり動くのか。3つの摩擦が大部分を説明する。CDNのキャッシュ：画像はURLをキーにエッジに置かれており、フォーマットを変えるということはキャッシュを無効化し、ライブラリ全体を再エンコードするということだ。古いデバイス：対応状況の表は97%と言うが、欠けた3%は安いAndroidフォンと企業の端末群に集中しており、壊れた画像1枚のために売り上げを1件も失えないサイトもある。ツールの惰性：CMSがJPEGのサムネイルを生成するのは昔からそうだからで、デザインツールがPNGを書き出すのはそれが一番大きなボタンだからだ。デフォルトを変えるということは、誰もオーナーのいないビルドパイプラインに手を入れるということだ。

エンコードコストもある。AVIFの圧縮上の優位はエンコード時のCPUで支払われる。だからこそ画像CDNはそれに課金し、経験のあるチームはオンデマンドではなくビルド時やアップロード時にAVIFを事前生成する。

この先どこへ向かうのか

今後数年で最も安全な賭けはAVIFだ。設計上ロイヤリティフリーであり（Alliance for Open Mediaは2015年にAmazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflixが、HEVC式のパテントプールから逃れるためだけに設立した）、非可逆と可逆を1つの仕様で扱い、HDRを載せられ、フォールバックチェーンのコストがほぼゼロになる対応の閾値も越えた。実際のコストはエンコード時間とプログレッシブデコードの欠如だ。前者は事前生成で解決でき、後者は妥当なトレードオフだ。

JPEG XLは、実際に得られた結果よりも報われるべきフォーマットだった。技術的な実力で言えば、標準化された歴代フォーマットの中で最も完成度が高い。プログレッシブデコード、最高の可逆モード、高ビット深度の写真、そして既存JPEGの全資産を可逆のまま再圧縮する能力。Googleは「エコシステムの関心が不十分」を理由にChromiumから取り除き、復活を求める要望はChromiumトラッカーの歴史上最もスターを集めたissueのひとつになった。3年後、Googleはこの決定を撤回したが、その時点で普及の機会の窓はほぼ閉じていた。JPEG XLが主流から外れている間に、AVIFはCDNの統合もCMSのプラグインも、デフォルトのチェックボックスも集めてしまった。JPEG XLはアーカイブ愛好家のお気に入りとして、そしてAppleデバイスでは正式対応のフォーマットとして生き続けるだろう。主流になるだけの技術的な根拠はあった。それでも、その座には届かなかった。

HEICがWebフォーマットになることはない。理由は品質とは無関係だ。HEVCのデコードには特許ライセンスが必要で、無料のブラウザを提供するベンダーたちは10年間その支払いを拒んできた。Webはロイヤリティフリーの技術で回っている。主要4エンジンのうち3つがデコードしないフォーマットはWebフォーマットではない。それは境界で解決すべき、書き出しの問題だ。

一方、移行の手法は完全に確立しており、2つの形態がある。サーバーサイドのコンテンツネゴシエーション：ブラウザがデコードできるものを列挙したAcceptヘッダーを送り、サーバーかCDNが同じURLに対して最適なバリアントを選ぶ。クライアントサイド：候補を列挙し、ブラウザに理解できる最初のものを取らせる<picture>要素だ。

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

一番下の<img>が普遍的なフォールバックなので、どこでも何も壊れない。これが、2つのサイトを保守せずに93%にはAVIFを、残りにはJPEGを配信する方法だ。

決定表

用途	配信するもの	理由
写真	AVIF、フォールバックにWebPとJPEG	写真こそ、最もバイト数を削れる場所だ
スクリーンショット、UIキャプチャ	PNG、または可逆WebP	文字とシャープなエッジは、ピクセル単位で正確に保つ必要がある
ロゴとアイコン	SVG、フォールバックにPNG	ベクターはどんな密度にも拡大できる。ラスタライズは最後にする
ページ上の短いアニメーション	まず動画（MP4/WebM）、最大のリーチが必要な場合だけGIF	アニメーションWebPとAVIFはブラウザで動くが、動画のほうがはるかに圧縮できる
ファビコン	最大のリーチにはICO、モダンブラウザにはPNGかSVG	ICOはPNGフレームを格納できるコンテナだ

ファビコンについて一言補足する。表の行には書ききれない詳細があるからだ。モダンブラウザはPNG、さらにはSVGのファビコンも受け付けるが、あらゆるクローラー、RSSリーダー、古いブラウザのタブが理解する唯一のフォーマットはいまだICOであり、ICOファイルは複数サイズを1つのコンテナに束ねられる。ロゴがいま別のフォーマットにあるなら、JPGからICO、WebPからICO、PNGからICOで、ブラウザ内で直接、適切なマルチサイズICOを作れる。

フォーマット間の変換

変換の雑事の大半は、上の節から自然に導かれる。圧倒的に多いのは、iPhoneのHEICを世界の残りが開けるものに変える作業だ。共有が目的ならHEICからJPGが正しい選択だ。HEICはすでに非可逆なので、JPEGにすれば劣化がこれ以上蓄積するのを防げる。HEICからPNGは現在の状態を編集用に固定し、HEICからWebPは行き先がWebサイトなら理にかなう。

次は、JPEG・PNG・WebPの3フォーマット間の行き来だ。JPEGをデザインワークフローに入れるならJPGからPNG。画質が上がるからではなく（上がることはない）、これ以上劣化しなくなるからだ。Web用に小さくするならJPGからWebP。古いソフトウェア向けに逆方向へ行くならWebPからJPGとWebPからPNG。フォトギャラリー行きのPNGスクリーンショットならPNGからJPG、あるいは小さくしつつ透過を残したいならPNGからWebP。非圧縮のBMPスキャンを引き継いだなら、BMPからJPG、BMPからPNG、BMPからWebPのどれを選んでも、数メガバイトもあるファイルをメールで送り回すよりましだ。ドキュメントでも同じ分かれ道がある。写真中心のページはPDFからJPG、文字のシャープさを保つ必要があるならPDFからPNG、ページがWeb行きならPDFからWebPだ。