Chrome 155でJPEG XLが既定ON — 2022年に消された形式がRust製デコーダで戻った理由

はじめに

Chrome 155 で、JPEG XL（.jxl / image/jxl）のデコードが既定で有効になった。Chrome チームが 10 月 6 日に公式ブログ「Shipping JPEG XL in Chrome」で発表し、Hacker News でも 390pt を集めている。

Chrome は 2022 年 10 月に、実験的に入れていた JPEG XL を「エコシステムの関心が足りない」として削除している。その形式が 4 年かけて戻ってきた。復帰の決め手は圧縮率ではなく、デコーダを Rust で書き直したことだった。

この記事では、何が出荷されたのか、なぜ一度消えたものが戻れたのか、そして Web の画像配信で何を変えればいいのかを整理する。

Chrome 155 で何が出荷されたか

Chrome 155 では JPEG XL 画像をそのままページ内に表示できる。フラグを触る必要はない。Chrome ブログが挙げる利点は「JPEG より 30〜50% 良い圧縮」「可逆圧縮」「HDR の標準サポート」「JPEG からの無劣化トランスコード」「きめ細かいプログレッシブデコード」だ。

経緯を時系列で並べるとこうなる。

時期	出来事
2022年10月	Chromium が実験的な JPEG XL 実装を削除
2023年9月	Safari 17 が JPEG XL に対応（部分対応）
2025年11月	Chrome のエリア技術リード（ATL）Rick Byers 氏が「高性能でメモリ安全なデコーダ」の貢献を歓迎すると表明
2026年2月	Chrome 145 に Rust 製デコーダ jxl-rs が入る（フラグ付き・既定 OFF）
2026年10月6日（ブログ発表）	Chrome 155 で既定 ON
2026年10月13日（予定）	Firefox 158 で既定 ON

注意したいのは Firefox だ。「Firefox 157 で既定 ON」とする報道もあったが、caniuse の更新 PR の議論によると Mozilla は既定化を 158 に延期している。157 では既定 OFF のままで、主要ブラウザで最初に既定 ON にしたのは Chrome という順番になった。

なぜ戻れたのか — 決め手は Rust 製デコーダ

画像デコーダは最も狙われる場所

Chrome ブログは、画像デコーダを「最も重要で、最も狙われる攻撃面のひとつ」と位置づけている。ネットワークから来た信頼できない複雑なバイナリを、レンダラープロセス内でそのまま解析するからだ。C/C++ のデコーダでは境界外読み取り、ヒープオーバーフロー、use-after-free といったメモリ破壊のバグが起きやすい。

Chromium には「Rule of 2」というセキュリティ方針がある。「信頼できない入力」「メモリ安全でない言語」「高い権限」の 3 つのうち、同時に満たしてよいのは 2 つまで、という考え方だ（サンドボックスは権限を下げる代表的な手段）。画像デコーダはネットワークから来る信頼できない入力をレンダラー内で解析する最前線なので、Chrome はこの方針に沿って、言語の側でも安全性を確保する道を選んだ。

C++ 版を捨てて Rust 版へ

Chromium への統合を進めた Helmut Januschka 氏の記録によると、最初はリファレンス実装の C++ 版 libjxl で統合を試み、アニメーションまで動く状態になっていた。それでもメモリ安全性を優先するべきというフィードバックを受けて、この方針は取り下げられた。代わりに採用されたのが、JPEG XL プロジェクト内で開発された純 Rust のデコーダ jxl-rs だ。

Mozilla も、Rust 製デコーダが用意されることを条件に支持を表明していた。jxl-rs の README には Chrome / Chromium と Firefox の両方で使われる実装だと書かれており、2 つのブラウザが同じデコーダで出荷する形になった。

unsafe を使わずに速度を出す

Rust で書き直すと、今度は速度が問題になる。画像デコードは SIMD による高速化がほぼ前提で、従来は unsafe なしでは書きにくかった。Chrome ブログによると、unsafe なしで SIMD を使うには Rust の target_feature_11 の安定化が必要だった（安定化の PR は jxl-rs 開発者の Luca Versari 氏が出し、2025 年 2 月にマージされている）。その上に、C++ の Highway ライブラリを参考にした抽象化レイヤー jxl_simd を作っている。

Januschka 氏の計測では、統合作業中の最適化で 2048×2560 の画像のデコードが 265ms から 198ms に縮んだ。C++ 版 libjxl（170ms）より 2 割弱遅い水準まで詰めた計算になる。Chrome ブログは、ファジングと AI によるコードレビューを経て「実装の歴史全体でメモリ安全性のバグはゼロ」と述べている。

Chrome 削除時の理由は「関心が足りない」だった。今回の復帰は、関心が増えたことに加えて、ブラウザが受け入れられる安全性の基準を満たす実装が出てきたことで成立した、と読むのが自然だ。Interop 2026 でも JPEG XL は人気の提案だったとされ、Chrome は Interop の JPEG XL 調査に参加してテストを揃えている。

エンジニアへの影響 — 今日から何を変えるか

`<picture>` で JXL を先頭に足す

Safari 17 以降と Chrome 155 以降が既定で表示でき、Firefox は 10 月 13 日の 158 で続く予定だ。一方で caniuse の表では、10 月 8 日時点で Edge は未対応、Chrome Android は 154 の「既定で無効」の表示で止まっている。古いブラウザも残るので、当面は <picture> でフォールバックを組むのが基本になる。

<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 を選ぶ。CDN やサーバーでフォーマットを切り替える場合は、リクエストの Accept ヘッダーに image/jxl が含まれるかで判定し、レスポンスには必ず Vary: Accept を付ける。Chrome 155 が実際に image/jxl を送ってくるかは、実機で確認しておきたい。

AVIF を置き換えるのではなく、得意分野で使い分ける

Chrome ブログ自身が「AVIF と JPEG XL の両方を試して、良いほうを使う」ことを勧めている。JPEG XL が向いているのは、高画質・可逆圧縮、特に写真の場合と、プログレッシブ表示を細かく効かせたい場合だ。裏を返せば、それ以外の用途では AVIF と比べて決める必要があるということで、「JXL が来たから AVIF をやめる」という話ではない（ここは筆者の読み）。

既存の JPEG 資産を無劣化で縮められる

実務で効きやすいのは、JPEG からの無劣化トランスコードだ。既存の JPEG を画質を一切落とさずに JPEG XL に詰め替えられ、元の JPEG にビット単位で戻すこともできる。corewebvitals.io の解説では平均約 20% の削減とされている。画像を大量に抱える EC サイトやメディアでは、再エンコードによる画質劣化を気にせずに配信量を減らせる。

Safari は部分対応、配信側の対応はまだ

caniuse では Safari の対応は「部分対応」の扱いで、corewebvitals.io はアニメーションとプログレッシブデコードに対応していないと説明している。プログレッシブ表示に期待した設計をするなら Safari での見え方は別に確認したい。

また、画像変換を CDN に任せている場合は、その CDN が JXL を生成できるかが先に効く。Cloudinary や Fastly は対応を打ち出している。一方、corewebvitals.io（2026 年 3 月 3 日更新）の整理では、Cloudflare は JXL への変換に未対応（オリジンが出す JXL のキャッシュは可能）で、AWS CloudFront・Akamai・Azure もネイティブ対応はないとされていた。ブラウザ側が揃っても、配信パイプラインが JXL を出せなければ効果は出ない。

まとめ

Chrome 155 が JPEG XL のデコードを既定で有効化した。Firefox は 157 ではなく 158（10/13 予定） で続く
2022 年に削除された形式が戻れたのは、Rust 製デコーダ jxl-rs がメモリ安全性の基準を満たしたから
unsafe なしの SIMD を実現し、C++ 版との速度差を 2 割前後まで詰めた
導入は <picture> の先頭に image/jxl を足すのが基本。AVIF とは用途で使い分ける
既存 JPEG の無劣化トランスコードは、画質を落とさずに配信量を減らせる手段として現実的になった

「新しいフォーマットをブラウザに入れるなら、メモリ安全な言語で書く」という流れは今後も続きそうだ。次に注目したいのは、Edge・Chrome Android への展開と、主要 CDN が JXL 生成にどれだけ早く対応するかだ。