Googleは2026年10月6日、Webブラウザ「Chrome 155」から、画像形式「JPEG XL（.jxl）」のデコードに正式対応すると発表した。これにより、これまでのように実験的な機能を有効にしなくても、JPEG XL形式の画像をChrome上で直接表示できるようになる。2022年に対応を見送った画像形式が、Rust製の新しいデコーダーを採用して復活することになった。
JPEG XLには、既存のJPEG画像を画質を損なわずに再圧縮できる機能や、ダウンロードの途中から画像の全体像を表示できる機能がある。ただし、Webサイトで使用する画像を常に最小のファイルサイズにできるわけではなく、用途によってはAVIFなどの形式が有利になる。
今回の正式対応によって、Web開発者は画質やファイルサイズだけでなく、画像をどれだけ早く表示できるかも考慮して、適切な形式を選びやすくなる。Googleの公式発表と開発過程の議論から、JPEG XLの特徴と今後の課題を見ていく。
一度は撤回されたJPEG XL、Rust製デコーダーで正式対応へ
ChromeがJPEG XLへの対応を一度見送った背景には、圧縮性能だけでなく、処理速度や開発・保守に伴う負担への懸念があった。
2022年11月、GoogleのJim Bankoskiは、新しい画像形式を採用する際には、さまざまな画像に対する圧縮性能や、小さな画像を表示する際のデコード速度などを総合的に評価する必要があると説明していた。
画像を圧縮する処理にどれだけ時間や計算資源が必要か、ほかのブラウザやOSが対応しているかも重要な判断材料になる。
対応する画像形式が増えれば、Webサイトの運営者だけでなく、ブラウザやデバイスの開発者にも、追加の形式をサポートし続ける負担が生じる。
Googleはこうした要素を検討した結果、当時のJPEG XLの試験的な実装を中止し、関連コードを削除する方針を示していた。
その後、再導入に向けた条件が明確になったのは2025年11月のことだ。
ChromeのRick Byersは、高速でメモリ安全性の高いJPEG XLデコーダーであれば統合を歓迎すると表明した。ただし、標準で有効にするには、長期的な保守体制を確保し、通常のリリース基準を満たす必要があると説明している。
2022年と2025年の公開議論からは、JPEG XLの圧縮性能だけでなく、ブラウザに安全に組み込み、長期にわたって維持できる実装が求められていたことが分かる。
その条件を満たすために採用されたのが、Rustで開発されたJPEG XLデコーダー「jxl-rs」だ。
Chrome 145のリリースノートには、jxl-rsを試験的な機能として導入したことが記されている。そして今回、Chrome 155から標準で有効にする方針が発表された。
つまり、JPEG XLという画像形式そのものが新しく作り直されたわけではない。既存の規格を安全かつ高速に処理できるデコーダーが整備されたことで、Chromeへの正式採用が実現したのだ。
Rustの採用で、安全性と処理速度の両立を目指す
画像デコーダーは、インターネットから受信した画像ファイルのデータを解析し、画面に表示できる形へ変換するプログラムだ。
外部から送られてくるデータを直接処理するため、細工された画像によってメモリへの不正なアクセスが発生すると、セキュリティ上の問題につながる可能性がある。
今回のjxl-rsでは、Rustが備えるメモリ安全性の仕組みを活用しながら、高速な画像処理に必要な最適化も取り入れている。
特に重要なのが、複数のデータを一度に処理するSIMD命令の活用だ。
Googleは、Rustの機能拡張と専用のSIMD処理基盤によって、安全性を維持しながら高速な処理を実現したと説明している。
また、メモリ安全性について開発者が特に注意して管理する必要がある処理を、十分に検証された少数の箇所に限定している。
ただし、Rustを採用したからといって、プログラム全体に脆弱性が存在しなくなるわけではない。
今回の変更は、安全性を重視するために処理速度を犠牲にしたものでも、あらゆる安全上の問題が解消されたという宣言でもない。安全性と処理性能の両立を図ったことが、正式採用につながったといえる。
JPEG XLの強みは、既存JPEGの完全復元と段階的な画像表示
JPEG XLの大きな特徴の一つが、すでに広く使われているJPEG画像を、そのまま活用できることだ。
JPEG標準化委員会によると、JPEG XLは既存のJPEGファイルを、情報を失うことなく再圧縮できる。
さらに、必要になれば、変換前と完全に同一のJPEGファイルへ復元することも可能だ。
例えば、サーバー側ではJPEG XL形式で画像を保存し、対応ブラウザにはJPEG XLのまま配信する。一方、JPEG XLに対応していない環境には、元のJPEG形式へ戻して配信するといった仕組みを構築できる。
ここで重要なのは、「元に戻せる」という意味だ。
単に見た目が同じ画像を再生成できるということではなく、元のJPEGファイルをデータ単位で完全に復元できる点に特徴がある。
参照実装libjxlの技術資料によると、JPEG XLは元のJPEGに含まれる画像情報に加え、元ファイルの再構成に必要な「jbrd」と呼ばれる情報や、必要なメタデータを保持できる。
JPEGでは、同じ画像を表現する場合でも、ファイル内部のデータ構造に違いが生じることがある。そのため、画像の見た目だけでなく、元のファイルそのものを再現するには追加情報が必要になる。
jbrdは画像を表示するだけなら必要ないが、元のJPEGファイルを完全に復元するには欠かせない。
したがって、JPEG XLを画像の保存形式として採用する場合は、変換後の画像が正常に表示されることだけでなく、復元に必要な情報が保持されているかも確認する必要がある。
なお、この機能は、JPEG画像を最初に圧縮した際に失われた画質を取り戻すものではない。
すでにJPEGとして保存された画像の情報を、それ以上失うことなく再圧縮し、必要に応じて元のファイルへ戻せるという仕組みだ。
ダウンロード完了前から画像の全体像を表示できる
もう一つの特徴が、画像のダウンロードが終わる前から、段階的に表示できることだ。
JPEG XLのVarDCT方式では、まず画像全体の大まかな明暗や色を表す低周波成分を送り、その後に細部の情報を追加できる。
これにより、最初はぼんやりとした画像が表示され、データの受信が進むにつれて徐々に鮮明になっていく。
大きな写真を掲載するWebページでは、画像のダウンロードが完了するまで待たなくても、利用者が早い段階で写真の内容を把握できるようになる。
従来、画像の表示速度を評価する際には、ダウンロードの完了時間やファイルサイズが重視されてきた。
しかし、JPEG XLの段階的な表示を活用すれば、利用者が画像の内容を認識できるまでの時間も、重要な評価基準になる。
JPEG XLとAVIF、圧縮性能はどちらが優れているのか
JPEG XLは高い圧縮性能を持つものの、すべての条件でAVIFよりファイルサイズを小さくできるわけではない。
Mozillaが2026年8月に公開した比較では、同じ写真を使っても、非可逆圧縮と可逆圧縮で両形式の優劣が逆転している。
Mozillaの比較記事では、草の上で眠るキツネの写真を使用している。
画素情報の一部を削減する非可逆圧縮では、画像の見た目の品質を評価する「SSIMULACRA 2」という指標を62.8にそろえて比較した。
一方、可逆圧縮では、元の画素情報を完全に保持する条件で比較している。
| 同一写真の圧縮条件 | AVIF | JPEG XL | AVIFと比較したJPEG XLの容量 |
|---|---|---|---|
| 非可逆圧縮（SSIMULACRA 2＝62.8） | 116kB | 134kB | 15.5%大きい |
| 可逆圧縮（画素情報を完全に保持） | 1.76MB | 1.45MB | 17.6%小さい |
容量差は、AVIFを基準として「（JPEG XLの容量 ÷ AVIFの容量 − 1）×100」で計算し、小数点以下1桁に丸めたものだ。
非可逆圧縮ではJPEG XLの方が15.5%大きい一方、可逆圧縮ではJPEG XLの方が17.6%小さくなっている。
つまり、同じ写真でも、圧縮条件が変わればファイルサイズの優劣が逆転する。
この結果から分かるのは、写真を高画質のまま保存する用途と、通常のWebページで配信する用途とでは、最適な画像形式が異なる可能性があるということだ。
画素情報を完全に残す必要がある場合は、JPEG XLの可逆圧縮が有力な選択肢になる。
一方、画質を一定程度維持しながらファイルサイズを小さくしたい場合には、AVIFの方が適していることもある。
Googleも、最良の結果を得るためにはJPEG XLとAVIFの両方を試すことを推奨している。
ただし、Mozillaが公開した数値は、あくまで特定の写真1枚を使った比較結果だ。
記事にはエンコーダーのバージョンや詳細な設定がすべて示されているわけではなく、あらゆる写真における平均的な圧縮性能を表すものではない。
実際に配信する画像を使い、目標とする画質をそろえて比較することが重要になる。
JPEG XLのデコードは「30倍遅い」？ 開発者間で訂正された測定結果
画像形式を選ぶ際には、ファイルサイズだけでなく、画像を表示するためのデコード処理にかかる時間も考慮する必要がある。
Chromeへの正式採用を巡る公開議論では、JPEG XLの可逆圧縮画像を表示する際の処理負荷が、議論の対象となった。
2026年8月、議論に参加したSergey Davidoffは、約1億画素の画像を可逆圧縮し、単一スレッドのコマンドラインツールでデコード速度を比較した結果、JPEG XLは可逆WebPより約30倍遅かったと報告した。
これに対し、開発者のLuca Versariは、測定に使用されたテスト設定では、デフォルトでデコード処理が2回実行されることを指摘した。
Davidoffはこの指摘を認め、当初の「約30倍」という数値を「約15倍」に訂正している。
さらにVersariは、JPEG XLには圧縮時の設定によってデコード速度を優先する方法があることや、今回のような巨大な画像では複数スレッドによる並列処理が効果的であることも説明した。
つまり、画像の種類や圧縮設定、デコードの実行回数、並列処理の有無によって、測定結果は大きく変わり得る。
また、この議論で使われたのは、開発途中の実装と約1億画素の巨大な可逆圧縮画像だ。
Chrome 155で通常のWebサイトに表示する写真が、WebPより一律に15倍遅くなるという意味ではない。
実際のブラウザ内での表示時間や、スマートフォンなどのバッテリー消費量を直接測定した結果でもない。
それでも、この議論は画像形式を評価する際の重要な問題を示している。
ファイルサイズが小さくなれば、ネットワーク経由で転送するデータ量は減る。しかし、その画像を表示するための処理が重くなれば、端末側のCPU負荷や消費電力が増える可能性がある。
そのため、配信データの削減効果と、デコード処理の負担は分けて検証する必要がある。
最終的には、実際に使用する端末で、画像の受信から画面への描画までにかかる時間を測定し、利用者にとって本当に快適になるかを判断することが重要だ。
Chromeの正式対応後も、ブラウザ間の違いは残る
Chrome 155のJPEG XL対応によって、主要ブラウザでの利用環境は大きく前進する。
ただし、画像を表示できることと、JPEG XLが持つすべての機能を各ブラウザで同じように使えることは別の問題だ。
Mozillaの開発者が2026年8月に示した実装状況によると、Safari 17からのJPEG XL対応には、段階的な画像表示やアニメーションのサポートが含まれていない。
また、FirefoxではHDR画像をSDRへ変換して表示する仕組みになっていると説明されていた。
こうした違いは、単純にJPEG XLへの対応・非対応を示す一覧表だけでは分からない。
GoogleとMozillaは同じRust製デコーダーを採用しているが、実際のWebページで画像を処理する仕組みはブラウザごとに異なるため、それぞれの環境で動作を検証する必要がある。
この問題に対応するため、ブラウザ間の互換性向上を目指す「Interop 2026」でも、JPEG XLが調査対象に選ばれている。
Interop 2026のJPEG XL調査では、色管理やHDRに加え、段階的な画像表示やアニメーションなども検証対象となっている。
さらに、HTMLの画像要素だけでなく、CSSの背景画像やCanvasでの利用についてもテストを進める計画だ。
JPEG XLの規格自体が備えている機能を、実際のWebページでもブラウザを問わず利用できるようにするための取り組みが続いている。
Webサイト側の対応も必要になる
Chrome 155の正式対応によって、Webサイトの運営者はJPEG XL形式の画像を生成し、対応ブラウザへ直接配信しやすくなる。
しかし、ブラウザが画像形式に対応したからといって、Webサイト側の画像生成や配信の仕組みまで自動的に変わるわけではない。
JPEG XLを導入する場合には、対応していない古いブラウザ向けに、JPEGやAVIFなどの代替画像を用意する必要がある。
また、画像の種類や求める画質に応じて形式を選び、実際の端末で表示速度や処理負荷を確認することも欠かせない。
例えば、元のJPEG画像を情報を失わずに保存する用途であれば、JPEG XLの再圧縮機能が大きな利点になる。
一方、大きな写真を掲載するWebページでは、ダウンロードの途中から画像の内容を把握できる段階的な表示が役立つ可能性がある。
通常のWeb配信用画像では、AVIFの方がファイルサイズを小さくできる場合もあるため、用途に応じた使い分けが必要だ。
今回のChrome 155への正式採用は、JPEG XLがあらゆる画像形式を置き換えることを意味するものではない。
重要なのは、画質、ファイルサイズ、表示速度のどれを優先するかによって、Web開発者が選べる画像形式の選択肢が広がることだ。
ブラウザ間の互換性や配信環境が整えば、JPEG XLは高画質な画像の保存から、Webページでの効率的な画像表示まで、幅広い用途で採用が進む可能性がある。
