ChromeがJPEG XLを再び受け入れた — 4年ぶりの方針転換は何を変えたのか

ChromeのJPEG XL復帰は、フォーマットが勝ったというシグナルなのか。それとも、ブラウザが新しいデコーダを取り込むコストの公式が変わったというシグナルなのか?

導入

2026年10月6日、Chrome for Developersブログに「Shipping JPEG XL in Chrome」という記事が掲載された。著者はLuca Versari、Moritz Firsching、Philip Jägenstedtの三人である。要旨は短い。Chrome 155からJPEG XL(.jxl)画像フォーマットのデコード対応を出荷するというものだ。この記事はHacker Newsに投稿され、575ポイントを集めた。

発表文はJPEG XLを、Web開発者と写真家のニーズに応える次世代フォーマットとして紹介し、JPEGより30〜50%優れた圧縮、ロスレス圧縮、組み込みのHDR対応、ロスレスなJPEGトランスコードを利点に挙げる。その一方で「一般には、AVIFとJPEG XLの両方を試すことを勧める」と書き、JPEG XLが最も役立つ場面として、高忠実度またはロスレス圧縮、特に写真画像や、きめ細かいプログレッシブデコードが好まれるケースを挙げている。「JPEG XLの方が優れている」ではなく「こういう場合に優れている」という慎重な文である。

この慎重さには歴史がある。Chromeは2022年に、まさにこのフォーマットをコードベースから取り除いたことがある。当時の理由の一つは「既存フォーマットに対して十分な増分的利点がない」というものだった。それから約4年、フォーマットのビットストリーム自体が大きく変わったわけではない。では、何が変わったのか。本稿では、発表文自身が明かした理由、Hacker Newsの議論に現れた解釈、そしてAVIFとの実際のトレードオフを順に見ていく。

削除から出荷まで: 発表文とタイムライン

まず事実関係を時系列で整理しておく。Hacker Newsのあるユーザー(swiftcoder)は今回のスレッドに過去の議論を四つリンクし、文脈を補った（直接の引用ではなく、コメントの要旨の要約）。それらの項目を実際に確認した結果は次の通りである。

2022年10月30日: 「Google set to deprecate JPEG XL support in Chrome 110」(Phoronix記事、146ポイント)
2022年12月10日: 「JPEG XL support has officially been removed from Chromium」(Chromiumのコードレビューへのリンク、292ポイント)
2025年11月24日: 「Chrome Jpegxl Issue Reopened」(Chromiumイシュートラッカーへのリンク、293ポイント)
2026年9月14日: 「The case against JPEG XL」(Gianni Rosatoのブログ、277ポイント)

2022年のPhoronix記事は、当時GoogleのエンジニアがChromiumのイシュートラッカーに残した削除理由を転載している。四つある。実験的なフラグとコードは無期限に残すべきではない。エコシステム全体の関心が、実験を続けるほど十分ではない。新フォーマットはデフォルト有効化を正当化するほどの増分的利点をもたらさない。そして、M110でフラグとコードを削除すればメンテナンス負担が減り、既存フォーマットの改善に集中できる。当時のJPEG XLはフラグの裏に隠れた実験機能であり、Phoronixは、ビットストリームが凍結されたのは2020年末にすぎず、libjxlのツールもまだ1.0未満だったことを挙げ、「エコシステムの関心がない」という判断は性急だと批判した。フラグの裏にある機能に開発者が殺到するはずがない、という鶏と卵の指摘である。

2025年11月の再オープンのスレッドでは、あるユーザー(markdog12)がblink-devメーリングリストの投稿を引用した（直接の引用ではなく、コメントの要旨の要約）。その内容は、前向きなシグナルを踏まえ、高性能かつメモリ安全なJPEG XLデコーダをChromiumに統合するコントリビューションを歓迎する、デフォルトで有効化するには長期メンテナンスへのコミットメントが必要であり、それと通常のローンチ基準が満たされればChromeで出荷する、というものだった。この文が今回の発表の設計図である。条件は三つ。性能、メモリ安全性、長期メンテナンスだ。

2026年10月の発表文は、この三条件に一つずつ答える構成として読める。メモリ安全性については、C++のリファレンス実装であるlibjxlではなく、純粋なRustで書き直したデコーダjxl-rsを統合したと述べる。性能については「最良のメモリ非安全な代替とおおむね同等の速度のメモリ安全なデコーダは、性能面で大きな妥協を伴う選択肢よりもはるかに明白な選択だ」と書き、そのためにRustのtarget_feature_11機能が安定化され、unsafeコードなしでSIMD命令を使えるようになったこと、C++のHighwayライブラリに着想を得たSIMD抽象化レイヤjxl_simdを作ったことを説明する。unsafeな操作は「少数の、徹底的に検証された箇所」に限定した。検証については、ファジングやAIによるコードレビューを含む手法を用い、実装の全履歴を通じてメモリ安全性のバグを一つも発見しなかったと記している。

最後に発表文は、決定の根拠を開発者フィードバックに置く。Interop ProcessにおいてJPEG XLは2026年およびそれ以前の数年にわたって人気のある提案であり、ChromeチームはInterop 2026 JPEG XL Investigationに参加して、JPEG XLの全機能についてテストカバレッジを確保し、Chromeがそれらのテストに通るようにしたという。

深層分析: 変わったのはフォーマットではなくコストの公式だ

2022年の理由リストと2026年の発表文を並べると、興味深い非対称が見えてくる。2022年のリストには「セキュリティ」という言葉がない。ところが2026年の発表文は、最初のセクションをまるごとセキュリティに充てている。画像デコーダは現代のブラウザで最も重要かつ最も狙われる攻撃面の一つであり、ネットワークから来た複雑で信頼できないバイナリ構造をレンダラプロセス内で直接処理する、と発表文は言う。C++のようなメモリ非安全な言語で書かれたデコーダは、歴史的に境界外読み取り、ヒープオーバーフロー、use-after-freeといった脆弱性に悩まされてきた。Chromeのセキュリティモデルはサンドボックスと多層防御、そして「rule of two」に依拠しているが、発表文自身、サンドボックスは二次的な防御層にすぎないと認めている。

ここから一つの解釈が成り立つ。2022年の理由のうち「メンテナンス負担」という項目は、実際には大規模なC++デコーダをレンダラに取り込むセキュリティコストを含んだ言葉だったのかもしれない。Hacker Newsでsurajrmalというユーザーがまさにこの解釈を示した（直接の引用ではなく、コメントの要旨の要約）。現実は単純で、既存ライブラリのセキュリティ問題に対処するコストが割に合わないと判断されてフォーマットが見送られ、産業界での採用が増えて、より安全な新しいライブラリが登場したことで決定が覆った、という説明である。彼は、Rustライブラリを開発したのはGoogleだが、その投資をしたのはChromeチームではなかった点も付け加えた。この最後の主張は発表文からは確認できない。ただし発表文の謝辞には、Chromeへの統合とjxl-rsの両方に大きく貢献した人物としてHelmut Januschkaが、jxl-rs自体に貢献した人物としてMartin Bruse、Zoltan Szabadka、Sami Boukortt、Wonwoo Choiの名が挙がっている。

この解釈が正しければ、今回の方針転換の核心は、JPEG XLというフォーマットが良くなったことではなく、「新フォーマットを一つ受け入れるコスト」の分母が小さくなったことにある。フォーマットの圧縮効率は2022年と大差ないかもしれない。しかし、デコーダをレンダラに入れるリスクがRustと安全なSIMDによって劇的に下がったのなら、同じ利点でも費用対効果の判断が逆転しうる。これはJPEG XLだけの話ではない。今後ブラウザが新しいコーデック、新しいフォント形式、新しいパーサを受け入れるかを判断する際、「メモリ安全な実装があるか」が事実上の入場条件になりうるという前例である。

もちろん別の解釈もある。「Googleの経営陣が阻み、エンジニアがついに説得したという社内抗争の話を期待していた」というYesThatTom2のコメントには、いくつもの反論や代替説明がついた（直接の引用ではなく、コメントの要旨の要約）。pwgは、AdobeがPDF仕様の次期改訂でJPEG XLを承認済みの圧縮方式として採用したことが転換点だったと主張した。すべてのブラウザはPDFレンダラでもあるので、どのみちJPEG XLデコーダを搭載せざるを得ず、ならばそれをimgタグにも公開するのが自然だ、という論理である。pmarreckは、AppleがiOSでネイティブ対応し、iPhoneで撮った写真をJPEG XLで保存するオプションを設けたことが影響したのだろうと推測した。cboltonは、JPEG XL自体が仕様、リファレンス実装、Rust実装に至るまで大部分がGoogleの仕事であることを挙げて「経営陣が阻んだ」という物語に反論し、Chromeのエンジニアが望まなかった理由は、コードが大きく、当時は採用が少なく、Web用途ではAVIFやWebPと重複していたからだと見ていると書いた。

これらの主張のうち、PDF仕様での採用やApple対応の具体的な内容は、本稿では別途確認できていない。ただ、同じスレッドでJyrkiAlakuijalaは、自らJPEG XLの標準化の過程でPIKとFUIFを一つに統合する案を委員会に提案したと明かしたうえで、プロ向け写真(Digital Negativeなど)、文書(PDF/EPUB)、医用画像(DICOM)で採用された後、いまWeb互換性を完成させる段階にあると書いた（直接の引用ではなく、コメントの要旨の要約）。当事者の記述であることを差し引いても、「Webの外で先に地位を固め、Webへ逆流した」という経路は、複数のコメントが共通して描く図である。Chromeの発表文がInteropを強調するのも同じ文脈だ。他のブラウザが既に対応しているか対応を準備している状況で、Chromeだけが欠けていることは相互運用性の穴になる。

とはいえ、誰もが歓迎したわけではない。「The Case Against JPEG XL」の筆者だと名乗るcomputerbusterは、今回のスレッドでも、このフォーマットがなぜWebへの価値ある追加なのか依然として分からないと書いた（直接の引用ではなく、コメントの要旨の要約）。彼の論点は四つある。非可逆圧縮では、最新のエンコーダを使ったAVIFがどんな忠実度目標でもはるかに効率的である。ロスレスではWebPより約10〜13%優れるが、デコードが6倍以上遅くなりうるので、そのコストをクライアントが払う。JPEG再圧縮でも、増えたデコード時間が表示時間の利得を相殺することが多い。AVIFもプログレッシブデコードのパスを好きなだけ持てる。彼は32ビット浮動小数点の精度や多数のレイヤ対応といった強みは認めつつ、新しいコーデックをWebに入れる基準が何なのか分からないと述べた。これに対しyyykは、ブラウザはもはやWebだけに狭く特化したソフトウェアではなく、PDFやカメラといった他の用途がJPEG XLの恩恵を受け、いったん対応が入ればWebで有効にするのは容易だと反論した。議論は結局、「WebのコーデックはWebに特化すべきか、それとも汎用でよいか」という哲学の違いに収束する。

展望と示唆: どこでJPEG XLを使うのか

実務者に残る問いは「で、何を使えばいいのか」である。発表文の推奨は先に見た通り両方試せというもので、高忠実度・ロスレス・写真・プログレッシブをJPEG XLの居場所として名指ししている。

Hacker Newsのコメントに現れた実務上の論点も、この境界線の上にある。theandrewbaileyは、1ビット/ピクセル以下ではAVIFが依然として優れ、それ以上ではJPEG XLの方が効率的だと整理した。jugは、損失の大きい圧縮ではAVIFがわずかに勝ることもあるが、CPUが極端に制約されていない限りJPEG XLで大きく間違うことはなく、AVIF・PNG・JPEG・WebP、一部のTIFF用途まで置き換えられる汎用性が強みだと書いた。互換性の面では、flockonusがcaniuse基準でJPEG XL対応が17%、WebPが97%だと指摘し、boutellはSafariがプログレッシブレンダリングとアニメーションにまだ対応していないとcaniuseを根拠に述べた。tepmocは、拡張子だけでは非可逆かロスレスか分からないという欠点を挙げた（以上すべて直接の引用ではなく、コメントの要旨の要約）。これらの数値はコメント投稿時点のcaniuseの値であり、本稿では別途確認していない。

ここから示唆を三つにまとめられる。

第一に、ロスレスなJPEG再圧縮はJPEG XLならではのカードである。既にJPEGとして蓄積された膨大な画像アーカイブを画質劣化なしに縮め、必要ならビット単位で元のJPEGに復元できるという性質は、AVIFにはない。デコードコストが実際の利得をどれだけ食うかは議論が続いているが、ストレージコストが支配的なアーカイブ用途では計算が変わりうる。

第二に、エンコーダの品質がフォーマットの評価を左右する。llm_nerdは、AffinityのJPEG XL出力が圧縮率も品質も悪いせいでこのフォーマットに失望した人を知っているとし、非圧縮で書き出してからリファレンスツールのcjxlで変換するよう助言した（直接の引用ではなく、コメントの要旨の要約）。フォーマットの比較は、結局のところ特定のエンコーダ実装の比較なのである。

第三に、プログレッシブデコードはユーザー体験の問題として残る。cyberrockは、Firefox(Android版を除く)とChromeがプログレッシブ読み込みを有効にして出荷したのに対し、Safariはまだ有効にしていないと指摘した（直接の引用ではなく、コメントの要旨の要約）。同じファイルがブラウザごとに異なる「現れ方」をする状況は、しばらく続くだろう。

(10月17日追記: 10月15日、Jake Archibaldが「JPEG XL vs AVIF for web use-cases」を公開し、Hacker Newsで319ポイントを集めた。彼はJPEG XLが今や全主要ブラウザに入ったことを前提に、avifenc 1.4.2、libjxl 0.12.0、新しいエンコーダjixel 0.4.2でベンチマークを取った。結論は次の通りだ。Webの非可逆写真ではAVIFがほぼ常により小さなファイルを作り、デフォルトのeffort設定で最良のJPEG XLファイルは通常15〜25%、最大effortでは6〜20%大きい。スクリーンショットやイラスト、透過のある画像ではAVIFがはるかに優れる。デコードはAVIFが速く、JPEG XLは中品質で2〜3倍かかるが、非常に高い品質ではその差が縮まる。一方でJPEG XLは既存のJPEGを追加の劣化なしに9〜20%小さくでき、ロスレスでは明確な勝者である。プログレッシブJPEG XLは高effortではほぼ無償であり、AVIFもChromeでプログレッシブレンダリングに対応している。彼のデフォルトはAVIF 4:4:4で、AVIFが妙に大きなファイルを出したときにjixelでJPEG XLを試すという。さらに、両フォーマットとも最近大きく改善しているので推奨は変わりうるとし、自分の画像で直接テストせよと付け加えた。Chromeの発表文の「両方試せ、JPEG XLは高忠実度・ロスレスで」という推奨とおおむね整合する結果である。)

結論

ChromeのJPEG XL出荷を「フォーマット戦争で誰が勝ったか」として読むと、誤読しやすい。非可逆のWeb画像という最大の市場でAVIFの優位は今回の発表で消えておらず、Chrome自身も両方試せと勧めている。

今回の方針転換が実際に示しているのは、ブラウザが新機能を受け入れるコストの公式の変化である。2022年のChromeは「利点が十分でない」と言った。2025年のChromeは「高性能かつメモリ安全なデコーダと長期メンテナンスの約束があれば出荷する」と言った。2026年のChromeは、Rustで書き直したデコーダ、unsafeなしで書くSIMD、ファジングとInteropテストを携えて戻ってきた。利点の大きさよりもリスクの大きさが縮んだことが判定を変えた、と見る方が史料によく合う。そこにPDF・カメラ・OSといったWeb外での採用が圧力を加えたという解釈もあるが、その因果の重みは公開資料だけでは判定しがたい。

あなたの画像パイプラインで、JPEG XLが入る場所はどこだろうか。既存のJPEGアーカイブ、ロスレスな原本の保管、高忠実度の写真であれば、いま試す理由がある。それ以外のWeb画像なら、当面は自分の画像で直接測ってみる以外に正解はない。

出典: