ハクソク

世界を動かす技術を、日本語で。

ChromeでのJPEG XLの配信

2026年10月7日原文(developer.chrome.com)

概要

  • Chrome 155 で JPEG XL （.jxl）画像フォーマットのデコーディングサポート開始
  • JPEG XLは 高圧縮率 ・ HDR対応 ・ ロスレス変換 を特徴とする次世代画像フォーマット
  • Rust製デコーダ （jxl-rs）で メモリ安全性 を重視
  • SIMD最適化 による高速処理と安全性の両立
  • 開発者フィードバック と Interop Project による標準化推進

ChromeでJPEG XLサポート開始

  • Chrome 155 から JPEG XL (.jxl) 画像のデコードに対応
  • JPEG XLは JPEG比30-50%高い圧縮率、 ロスレス圧縮、 HDR対応、 JPEGからのロスレス変換 などを実現
  • AVIF と JPEG XL の併用推奨
    • AVIF: 汎用的な用途向け
    • JPEG XL: 高画質やロスレス圧縮、細かいプログレッシブデコードが必要な場面で有効
  • 写真画像 や 高精細画像、 プログレッシブデコード重視のケース で特に有用

Rustによる安全なデコーダ実装

  • 画像デコーダは Webブラウザの主要な攻撃対象
  • 従来の C++実装 では バッファオーバーフロー や use-after-free などの脆弱性リスク
  • Rust製デコーダ（jxl-rs） をChromeに統合し、 メモリ安全性 を根本から強化
  • サンドボックス は補助的な防御策、Rust導入で根本対策

高速化と安全性の両立

  • メモリ安全性 と 高速処理 の両立が重要
  • SIMD命令 による最適化のため、 target_feature_11 Rust機能を安定化
  • jxl_simd によるSIMD抽象化レイヤー構築
    • C++の Highwayライブラリ を参考に設計
  • マルチプラットフォーム対応 かつ 最小限のunsafeコード で高速化
  • libjxl の最適化技術を継承
    • 領域をまたぐ汎用パイプライン設計
    • データコピー最小化によるハードウェア性能最大化
  • jxl-rsパフォーマンスダッシュボード で各種ハードウェア上の性能追跡
  • ファジング や AIコードレビュー などでメモリ安全性を徹底検証
  • 実装履歴全体で メモリ安全性バグゼロ を達成

開発者フィードバックと標準化

  • Chromeチーム は バグ報告 ・ アンケート ・ Developer Signals Project ・ Interop Project から幅広くフィードバック収集
  • JPEG XL対応決定 は、 Interop Process での開発者からの強い要望が背景
  • Interop 2026 JPEG XL Investigation に参加し、他ブラウザとの 互換性検証 と テストカバレッジ 強化
  • Chromeで 全機能のテスト合格 を確認

利用開始の呼びかけ

  • JPEG XL正式対応 によりWebが 高速化 ・ 高画質化 ・ 安全性向上
  • 開発者、 コンテンツ制作者、 プラットフォーム運営者 に.jxl画像・アニメーションの積極的利用を推奨
  • フィードバックやバグ報告 を通じて、より良いWeb構築への協力を呼びかけ

貢献者への謝辞

  • jxl-rs や Chrome統合 への貢献者に感謝
    • Helmut Januschka: Chrome統合・jxl-rsへの大きな貢献
    • Martin Bruse, Zoltan Szabadka, Sami Boukortt, Wonwoo Choi: jxl-rs本体への主要貢献

Hackerたちの意見

JXLのサポートがChromeに再追加されるのを見るのはワクワクするね。前は削除されてたし、あんまりサポートする気がないみたいだったからさ。JXLはクールな画像フォーマットだと思うけど、人気のブラウザがサポートしてなかったせいで、特にウェブでは使いづらかったよね。

└

それってセキュリティが悪かったからじゃなかった？libjxlには、ブラウザにあったらwebpの脆弱性と同等の悪名高いバグがあったんだ。Project ZeroがGoogleのブラウザチームに対して、安全でないデコーダーやエンコーダーを追加しないよう警告してたのを覚えてる。

└

しばらく前に削除されて、彼らがサポートに興味を示さなかった。サポートしても誰もGoogleに利益がなかったから削除されたんだ。今はサポートすることで誰かが昇進できるかもしれないから再追加された。

└

ブラウザがすべてのメディアフォーマットをサポートする必要があるのはなぜ？システム全体で使える共有ライブラリとして提供できないの？

└

そうだね、ここでの大きな話はGoogleが一度削除してから再追加したことだと思う。大企業はプライドが高いから、これはかなりの奇跡だよね。今はJXLが定着する気がする。

前のHNのディスカッションを見てみてね：GoogleがChrome 110でJPEG XLのサポートを廃止する予定 - https://news.ycombinator.com/item?id=33399940 JPEG XLのサポートが正式にChromiumから削除された - https://news.ycombinator.com/item?id=33933208 ChromeのJpegxl問題が再オープンされた - https://news.ycombinator.com/item?id=46033330 JPEG XLに対する反対意見 - https://news.ycombinator.com/item?id=49690554

くそっ！これがGoogleの幹部がJPEG XLを止めようとする内部の戦いをカバーする内容だと思ってたんだけど、エンジニアたちが最終的に彼らを説得したって話が聞けると思ったんだ。俺の予想では、エンジニアたちは議論に勝てなかったんだろうな。幹部たちは、他のブラウザがサポートを追加したら諦めたみたいだし。

└

幹部たちは、他のブラウザがサポートを追加したら諦めたみたいだ。 大きな転機は、Adobeが次のPDF仕様の更新のためにJpegXLを承認された画像圧縮アルゴリズムとして採用したことだったみたい。これで、すべてのブラウザがPDFレンダラーになりたいと思っているから、JpegXLデコーダーを含めざるを得なくなったんだ。もしここに勝ちがあったとしたら、結局出荷しなきゃいけないデコーダーがタグでもPDFレンダラーでも使えるようになったことだね。

└

私の予想では、AppleがiOSでネイティブにサポートしたことで（iPhone 16以上には、撮った写真をAppleの独自フォーマットではなくJPEG-XLとして保存するオプションがある）、それが影響を与えたんじゃないかな。

└

JPEG XLに対して恐怖や不安、疑念を十分に持たせたから、今はまともな組織は採用しないだろうね。神様、Googleが2027年にまたサポートを外すかもしれないし。

└

Googleが自分たちの新しいwebpフォーマットを独占したいから、競争を促進したくなかったって理由だと思ってたんだけど？

└

情報が不足していて先入観が強いと、いろんな理論が生まれるのは面白いね。現実はもっとシンプルで、既存のライブラリのセキュリティ問題を解決するコストに見合わないと判断されたから、誰かがそのフォーマットを放棄することにしたんだ。でも、業界での採用が増えて新しい安全なライブラリが現れたことで、決定が変わったんだよ。また、Googleが新しいRustライブラリを開発したけど、それを投資したのはChromeチームじゃなかったことにも注意してね。

Hacker Newsで議論の続きを見る