ChromeにJPEG XLが戻る

Googleは、Chrome 155がJPEG XL画像のデコードに対応すると発表した。主にRustで書かれた実装を通じて、.jxl形式をブラウザーに導入する。Chromeチームによると、この形式は従来のJPEGより高い圧縮率を実現できるほか、可逆圧縮、ハイダイナミックレンジへのネイティブ対応、既存のJPEGファイルを元に戻せる形で変換する機能を備える。

Googleの10月7日の発表によると、JPEG XLは素材や設定に応じて、JPEGに比べファイルサイズをおよそ30～50％削減できる。同社はこれをあらゆる用途での置き換えではなく、AVIFと並ぶ選択肢と位置付け、開発者に両方を試すよう勧めている。特に、高品質または可逆圧縮の写真や、細かな段階的デコードを生かせる体験に有用だと見込んでいる。

デコーダーは、Chromeに組み込まれた、すべてRustで実装されたjxl-rsだ。画像デコーダーは、ネットワークから受信する複雑で信頼できないバイナリデータを処理するため、ブラウザーの重要な攻撃対象領域となる。Googleによると、Rustの採用は安全でないメモリー操作に伴う種類のエラーを根本で抑えるものであり、Chromeのサンドボックスなどの防御は、それに加わる保護層として残る。

性能と互換性の取り組み

メモリー安全性は要件の一つにすぎなかった。実運用向けのコーデックには、移植性を損なわずに現代のプロセッサーのベクトル処理能力を活用することも求められる。Chromeチームによると、Rustでの安定化作業によってSIMD命令を安全に利用できるようになった。また、別の抽象化層であるjxl_simdは、参照実装のlibjxlコーデック向けに当初開発されたC++ライブラリ、Highwayの影響を受けている。安全でない操作は、レビュー済みの少数の箇所に限定されている。

性能改善でもlibjxlの着想を取り入れた。画像内の領域境界をまたぐ操作の処理手法や、不要なデータコピーを避ける取り組みなどだ。Googleは複数のハードウェアプラットフォーム上でRustデコーダーを継続的に確認し、ファジングとコードレビューによって実装をテストしたとしている。同社は、実装のこれまでの履歴全体を通じてメモリー安全性の欠陥を発見していないと報告した。ただし、この主張が示すのはテストの実績であり、欠陥が存在し得ないという保証ではない。

ブラウザー間の相互運用性も判断に影響した。Googleは、標準への対応に重点を置くInteropの提案におけるJPEG XL対応の要望を含め、ウェブ開発者から繰り返し要請があったことを挙げた。Chromeは、同形式についてブラウザー横断のテスト範囲を確立するための2026年の相互運用性調査に参加しており、GoogleによるとChromeはこれらのテストに合格している。

ブラウザーが対応したからといって、ある形式が自動的にあらゆる配信環境に適するわけではない。発行者には、互換性のあるデコーダーを備えないクライアント向けの代替手段が引き続き必要であり、実際の画像、エンコード時間、配信コストを比較しなければならない。それでもChrome 155により、開発者は写真、アニメーション、保存品質のウェブ素材にJPEG XLを使う価値を評価できる主要クライアントをもう一つ得ることになる。