JPEG XLがChrome・Firefoxで解禁──画像配信はAVIFとどう使い分けるか

2026年10月、画像配信の選択肢が大きく変わりました。Chrome 155（10月6日）がJPEG XLのデコードに対応し、Firefox 158（10月13日）がJPEG XLをデフォルト有効化しました。Safariは17.0から部分対応しており、主要3エンジンでJPEG XLが実用圏に入ったことになります。

これまでJPEG XLは「Chromeが対応していないから使えない」と言われがちでした。しかし現在は、静止画であればChrome・Firefox・Safariで表示できます。この記事では、JPEG XLで何が変わるのか、AVIFとどう使い分けるのか、`<picture>`フォールバックを含む実装方法を整理します。

30秒でわかる結論

Chrome 155とFirefox 158でJPEG XLがデフォルト対応。Safariは17以降で部分対応。
JPEG XLは高圧縮、HDR、可逆圧縮、既存JPEGからの可逆トランスコード、アニメーションに対応。
Safariはプログレッシブ表示やアニメーションに制限があり、静止画中心の運用が現実的。
AVIFと優劣がつくわけではない。画像ごとにサイズと画質を測って選ぶ。
配信は`<picture>`フォールバック＋CDNの`Accept`対応で段階導入する。

何が起きたのか：ChromeとFirefoxの対応

Chrome 155は、メモリ安全なPure Rust実装の`jxl-rs`を使ってJPEG XLのデコードを追加しました。Chromeは2022年にJPEG XL対応を一度取り下げていましたが、今回はデフォルトで有効になっています。

Firefox 158はJPEG XLをデフォルト有効化し、画像リクエストの`Accept`ヘッダにも`image/jxl`を含めるようになりました。これにより、サーバー側がコンテンツネゴシエーションでJPEG XLを返しやすくなります。Safariは17.0からJPEG XLを部分的にサポートしており、静止画の表示は可能です。

ブラウザ	対応状況	備考
Chrome 155以降	対応	デコードに対応。`jxl-rs`を使用
Firefox 158以降	対応	デフォルト有効。`Accept`に`image/jxl`
Safari 17以降	部分対応	静止画は表示可。プログレッシブ・アニメーションに制限
Edge / Opera	追随待ち	執筆時点では未対応・無効

何が変わるのか：画像形式の選択肢が増える

これまで画像配信は、JPEG/WebP/AVIFの3択が中心でした。JPEG XLが加わることで、用途に応じた選択ができます。特に大きいのは、既存JPEGを可逆でJPEG XLに変換できること、HDRやアニメーションを1形式で扱えること、高圧縮に加えて可逆圧縮も選べることです。

形式	強み	弱み・注意
JPEG	互換性が最も高い	圧縮効率は低い
WebP	広い対応、実績がある	HDRや可逆圧縮には弱い
AVIF	高い圧縮効率、広い対応	エンコードに時間がかかる場合がある
JPEG XL	高圧縮、可逆、HDR、アニメーション、JPEG変換	Safariは部分対応。Edge/Operaは未対応

「JPEG XLの方が常に小さい」とは限りません。AVIFの方が小さくなる画像もあります。大切なのは、同じ画像をAVIFとJPEG XLで書き出し、実際のファイルサイズと画質を比較することです。

使い方：`<picture>`でフォールバックする

もっとも安全なのは、JPEG XLを第一候補にし、未対応ブラウザにはAVIF/WebP/JPEGを返す`<picture>`構成です。

HTML

<picture>
  <source srcset="/hero.jxl" type="image/jxl">
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="..." width="1200" height="800">
</picture>

ブラウザは上から順に`type`を確認し、対応する最初の形式を選びます。Chrome 155、Firefox 158、Safari 17以降はJPEG XLを選び、それ以外はAVIF/WebP/JPEGにフォールバックします。

CDNを使うなら、`Accept`ヘッダに`image/jxl`が含まれるかを確認し、含まれる場合だけJPEG XLを返す設定にします。Firefox 158はデフォルトで`image/jxl`を送るため、サーバー側の対応だけで自動的にJPEG XL配信できます。

AVIFとどう使い分けるか

AVIFはすでに広く対応しており、ツールチェーンも成熟しています。一方、JPEG XLは次のような場面で有利です。

既存JPEGを可逆変換したい：画質を落とさずにJPEG XLへ移行できる。
HDR画像を扱いたい：HDR、広色域、高ビット深度に対応。
アニメーションも1形式にしたい：GIF/WebP/APNGの置き換え候補になる。
ロスレス画像を高圧縮したい：スクリーンショットや図版で効く場合がある。

逆に、AVIFの方が向くのは「とにかく広いブラウザで確実に表示したい」「既存のAVIFパイプラインが安定している」「エンコード時間を短くしたい」場面です。両方を同じ`<picture>`に入れておけば、ブラウザごとに最適な形式を選ばせられます。

実務への影響：写真中心のサイトから試す

JPEG XLの効果が大きいのは、写真や画像が多いメディア、EC、ポートフォリオです。転送量が減れば、LCPやINPの改善につながる可能性があります。一方、画像が少ないサイトでは、ビルドパイプラインの複雑さに見合わないこともあります。

導入順は、次の3段階が現実的です。

人気の高いヒーロー画像1枚で、AVIFとJPEG XLのサイズ・画質を比較する。
比較で勝った画像だけJPEG XLを追加し、`<picture>`でフォールバックする。
CDNの`Accept`対応と、Safariでの表示を確認してから対象を広げる。

Safariの部分対応はどのくらい気にする？→ 静止画の表示はできますが、プログレッシブ表示やアニメーションには制限があります。写真ギャラリーなら問題になりにくく、アニメーションJPEG XLを主力にするなら慎重に判断してください。

注意点：デコードコストと対応差

JPEG XLは圧縮率が高い一方、デコードに時間がかかる端末がある。低スペック端末で確認する。
Safariは部分対応。プログレッシブ表示やアニメーションを前提にしない。
Edge/Operaは執筆時点で未対応。`<picture>`フォールバックを必ず残す。
CDNが`Accept`を見ずに常にJPEG XLを返すと、未対応ブラウザで表示できない。
ビルド時にAVIFとJPEG XLを両方生成すると、ストレージとビルド時間が増える。

最初から全画像をJPEG XLに置き換えず、`<picture>`の先頭に追加するだけにします。失敗しても次の`source`に落ちるため、ロールバックが容易です。

対応状況と使う判断

用途	判断	理由
写真ギャラリー	条件付きで使う	AVIFとサイズ比較して勝った画像だけ
HDR画像	条件付きで使う	Safariの対応差を確認
アニメーション	まだ様子見	Safariの部分対応とEdge/Opera未対応
ロスレス図版	条件付きで使う	PNG/WebPと比較して効果を測る