Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 「戻ってきた」と「使える」は別の話です
簡単な振り返り — 2022年に何があったか
2025年11月22日 — 4年前のあのスレッドに投稿された方針転換
Chrome に実際に入ったもの — Gerrit で追う
Firefox — 同じデコーダー、半歩後ろ
Safari と Interop 2026 — 残りのパズルの正確な位置
今日時点の状況表
実務上の判断 — 今何をすべきで、何をすべきでないか
おわりに
参考資料

はじめに — 「戻ってきた」と「使える」は別の話です

2025年11月末から「Chrome が JPEG XL を再びサポートすることにした」という記事が出回り、2026年初めには「Chrome 145 に JPEG XL が入った」、最近では「Firefox 152 にも入った」という話まで出てきました。どれもある程度は事実です。そして、それをそのまま信じて .jxl をプロダクションに配信すると事故になります。

画像フォーマットのサポート状況は、噂と実際の状態の間の差が特に大きい話題です。「コードがツリーにある」「フラグの裏にある」「Nightly でデフォルト有効」「リリースでデフォルト有効」はすべて別々の段階なのに、ニュースの見出しはこの区別を潰してしまいます。そこで本稿は記事ではなく1次ソースだけを見ます — Chromium Gerrit のマージ済み CL、ソースツリーの実際のゲート、Bugzilla のマイルストーン、ブラウザーベンダーの公式リリース API です。今日(2026-07-17)時点で JPEG XL が正確にどこまで来ているか、そして実務者はいつ動くべきかを整理します。

フォーマット自体(AVIF との圧縮効率比較、ロスレス JPEG 再圧縮のような機能比較)は画像フォーマット 2026 — AVIF / JPEG XL / WebP / HEIC / MozJPEG / QOI / Sharp / Squoosh 徹底ガイドで扱ったので、ここでは「ブラウザーに載りつつあるか」という一点だけを問います。

簡単な振り返り — 2022年に何があったか

時系列でまとめるとこうです。

2021年、Chromium は libjxl(C++)ベースの実験的デコーダーをフラグの裏に入れ、blink-dev に Intent to Prototype スレッドを投稿しました。
2022年10月、同じスレッドに削除の告知が投稿されました。要点は3つでした — 実験用フラグを無期限には維持しない、エコシステム全体の関心が実験を続けるに足るほど大きくない、既存フォーマットに対する増分的な利得がデフォルト有効化を正当化するほど大きくない。
コードとフラグは実際に Chrome 110 で削除されました。Chrome 公式のバージョン履歴 APIによれば、110 の安定版ロールアウト開始は2023年2月1日です。

その後3年間、この決定は Chrome の Issue トラッカーで最も騒がしい画像フォーマット論争であり続けました。その間に外の状況は変わっていきました。Apple はSafari 17 のリリースノート(2023年9月)に JPEG XL サポート追加を明記しており — 今なおデフォルト有効でサポートする唯一のメジャーエンジンです。Mozilla は公式の標準ポジション文書で position 自体は neutral を維持しつつ、根拠文には「もう一つ C++ の画像デコーダーを追加するコストを正当化するほどの利得はないが、メモリ安全なデコーダーであればそのコストは大きく下がり、要件を満たす実装であれば出荷する意向がある」という趣旨を明記しました。「Mozilla が positive に転じた」とよく言われますが、登録されているポジションは今も neutral です — 条件付きの開放という表現が正確です。

そして、その条件に合うものが現れました。libjxl チームが作る純 Rust デコーダー jxl-rsです。リポジトリ自身が「仕様準拠・安全性・速度を目指す進行中(work-in-progress)の再実装」だと紹介しています。この「進行中」という注記は、後でまた重要になります。

2025年11月22日 — 4年前のあのスレッドに投稿された方針転換

方針転換の告知は新しいブログ記事ではなく、2021年に Intent to Prototype が投稿されたまさにその blink-dev スレッドへの返信として投稿されました。執筆者は Rick Byers、Chrome ATL(Architecture Tech Leads)名義です。内容を要約すると:

前回の評価以降に状況が変わった — Safari が出荷し、Firefox が position を更新し、バグのスター数・Interop 提案・アンケートといった開発者シグナルが観測され続けており、PDF 標準に JPEG XL が追加されるという発表もあった。
これらのシグナルを根拠に: "we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder"(性能が良くメモリ安全な JPEG XL デコーダーを統合する貢献を歓迎する)。
ただし、デフォルト有効化には長期保守への約束が必要であり、それと通常のリリース基準が満たされれば Chrome に載せる。

文章を読み解くと、これは「私たちがやる」ではありません。「誰かが持ってきて、なおかつ保守を続けると約束すれば、載せてやる」です。2022年の削除の核心的な論拠が保守負担だったことを思い出せば、これは一貫した態度です — 負担を負わないという条件のもとでのみ門を開いたのです。この構造を理解して初めて、その後8か月の進捗速度が読み解けます。

Chrome に実際に入ったもの — Gerrit で追う

マージ済みの CL と公式スケジュールだけでタイムラインを描くとこうなります。すべてChromium Gerritで確認できます。

2025-11-22  blink-dev への条件付き方針転換の告知 (Chrome ATLs)
2025-12-10  jxl-rs を third_party にベンダリング — CL 7201443、+73,908行
2025-12-28  JXL インフラ追加: enum とビルドフラグ
2026-01-08  jxl-rs ベースの JXL 画像デコーダー追加 (revert 後 01-09 に reland)
2026-01-13  デコーダーの接続(wire up)+ フィーチャーフラグのゲーティング + WPT テスト追加
2026-01-16  [M145] タグが付いた 145 ブランチへのチェリーピック開始
2026-02-10  Chrome 145 安定版 (chromiumdash 公式スケジュール) — M110 以来
            初めて JPEG XL デコーダーが安定版バイナリに復帰
2026-02-24  DevTools 統合 (JXL 無効エミュレーション、host config の公開)
2026-01〜04  jxl クレート 0.1.4 → 0.4.3 のバージョンロールを反復
2026-05-07  chrome://flags 項目の失効を M152 に延長
2026-06-28  切り詰められたファイルのレンダリング・アニメーションのクラッシュなど、安定化修正が継続してマージ中

いくつか押さえておくべき点があります。

まず、ゲートは三重です。 ソースを見ると、コンパイルスイッチはgn 引数 enable_jxl_decoderで、デフォルト値が true なので公式ビルドにはデコーダーが含まれます。しかしランタイムを握っているのはblink::features::kJXLImageFormatで、この base::Feature は今日の main 時点で FEATURE_DISABLED_BY_DEFAULT です。ユーザーが有効化する方法は chrome://flags の enable-jxl-image-format 項目だけです。要するに、Chrome 145 から 151(現行の安定版)まで、バイナリの中にデコーダーはあるものの、デフォルトではオフのままです。

次に、「貢献歓迎」モデルは文字どおりに実行されました。 flag-metadata.jsonに記録されたこのフラグの所有者は、Google の社員ではなく外部の貢献者(helmut@januschka.com)です。実際、C++ libjxl ベースの最初の実装はレビューで「Rust で」というフィードバックを受けて破棄され、jxl-rs ベースで作り直した経緯が貢献者本人による振り返り記事にまとめられています。その記事に載っている著者自身の測定(2025年12月、jxl-rs コミュニティによる SIMD 最適化 26 件の PR 後の時点)を見ると、テスト画像3枚のうち2枚では依然として C++ libjxl の方が速く(例: 2048x2560 の写真で jxl-rs 198ms 対 libjxl 170ms)、1枚では jxl-rs が3倍以上速い結果でした。あくまで特定の画像数枚に対する個人的な測定なので一般化は難しいものの、「Rust デコーダーはまだ全面的に速いわけではない」という方向性くらいは読み取れます。

さらに、リリース手続きはまだ始まってすらいません。 chromestatus の項目の Chrome ステータスは今も「Proposed」のままで、Intent to Ship スレッドはありません。5月にフラグの失効が M152 に延長されましたが、chromiumdash のスケジュール上、152 の安定版は2026年8月25日です。この延長は「それまではフラグの状態に留めておく」という意味であって「152 でリリースする」という意味ではありません — フラグ失効の延長は慣例的なハウスキーピングです。6月末になっても、切り詰められたファイルの部分レンダリング処理や、アニメーションの繰り返し回数を取得する際のクラッシュを修正する CL がマージされ続けているという事実が、このコードがまだ「デフォルト有効化の候補」段階ではなく「安定化中」段階であることをより正確に物語っています。

Firefox — 同じデコーダー、半歩後ろ

Firefox 側の進捗は、Bugzilla のマイルストーンで正確に押さえられます。

バグ 1986393 (2025-09-02 作成、FIXED、マイルストーン 149): 「初期の jpegxl rust コードを pref オフのままランディング」。興味深いことに、これは Chromium の方針転換の告知より2か月以上先行しています — Mozilla は自分たちの条件(メモリ安全なデコーダー)が満たされた時点で、静かに先に動いていたのです。
バグ 2016688 (FIXED、マイルストーン 152): 「beta/release ビルドでも jpeg xl コードをビルドする」。実際、ESR 140 の moz.configureには Nightly でのみコンパイルする条件が残っていますが、152 のリリースブランチではその条件が消えており、すべてのチャンネルでコンパイルされます。
ただし、StaticPrefList.yamlの image.jxl.enabled のデフォルト値は @IS_NIGHTLY_BUILD@ です。つまり、2026年6月16日にリリースされた Firefox 152 のリリースビルドにはデコーダーがコンパイルされていますが、pref はオフのままで、about:config で手動で有効化しないと動きません。152 の公式リリースノートに JPEG XL への言及はありません — 「Firefox 152 が JPEG XL をサポートする」という記事の見出しと実際の出荷状態の間には、ちょうどこれだけの差があります。

注目すべき事実がひとつあります。Firefox の Cargo.lock が固定しているデコーダーは jxl クレート 0.4.3、つまり Chromium がベンダリングしたのと同じ libjxl/jxl-rs です。両エンジンは同じサードパーティのデコーダー実装を共有しているのです。2022年の削除の論拠の一つが「ブラウザーごとに C++ デコーダーをもう一つ抱える保守負担」だったことを思い出すと、負担の構造そのものが変わったことになります — 今では一つのリポジトリの安全性・性能の改善が、二つのブラウザーに同時に流れ込みます。

もちろん、未完了のリストもソースにそのまま見えます。追跡用メタバグ 1539075 は2019年に開かれ、7年目に入っても ASSIGNED のままで(最後の活動は本稿の2日前)、mac x86_64 でデコードが3倍遅くなる問題のワークアラウンドはまだ残っており(バグ 2043091)、色空間を ICC プロファイルの合成ではなく CICP enum で認識させる作業(バグ 2055224)のような品質issueが今週も新たに登録され続けています。

Safari と Interop 2026 — 残りのパズルの正確な位置

Safari はこの話における変数ではありません。2023年9月の Safari 17 からデフォルト対応済みで、Byers の告知が最初の根拠として挙げたのも Safari でした。

より慎重に読まなければならないのは Interop 2026 です。「JPEG XL が Interop 2026 に含まれた」という話が出回っていますが、公式の READMEを見ると、JPEG XL は採点対象の focus area ではなく investigation effort です。文書自体が、現状 Web プラットフォームテストが乏しいことを認め、今年の目標を「この機能をテスト可能にすること」に据えており、開発者が重視している progressive rendering ですら、ブラウザーがいつどのように行うべきかまだ議論中だと記しています。つまり、相互運用性のスコアを付ける段階ではなく、採点基準そのものを作る段階だということです。実際、今年上半期は Gerrit と Bugzilla の両方で、jpegxl の WPT ディレクトリにテストを埋めていくコミットが流れ続けています — 方向は正しいものの、完走時期は誰も約束していません。

今日時点の状況表

まとめると、2026年7月17日現在の状態はこうです。

                          デコーダーコンパイル  デフォルト有効  手動有効化方法
Chrome 151 (安定版)              O              X       chrome://flags の
                                                          enable-jxl-image-format
Firefox 152 (リリース)           O              X       about:config の
                                                          image.jxl.enabled
Firefox Nightly (154)            O              O       -
Safari 17+                       O              O       -

Intent to Ship (Chromium):       なし (chromestatus ステータス「Proposed」)
リリースでのデフォルト有効化予定: どのエンジンも公表していない
Interop 2026:                    investigation effort (採点対象外)

「3年ぶりに三つのエンジンすべてのコードベースに JPEG XL デコーダーが存在する」という文と、「それでもウェブトラフィックの大半では JPEG XL はレンダリングされない」という文は、同時に真です。この二つの文を両方とも手放さずに持っておくことが、今この話題に対する正確な理解です。

実務上の判断 — 今何をすべきで、何をすべきでないか

まず、今やってはいけないことから。 それは、ユーザーに届ける Web 画像フォーマットを JPEG XL に切り替えることです。Chrome 系列とリリース版 Firefox でデフォルト非対応である以上、content negotiation なしに .jxl を配信すれば、ほとんどのユーザーには壊れた画像が届きます。WASM ポリフィルで回避する選択肢もありますが — 先の振り返り記事の著者が作ったポリフィルは、制作者の表記によれば gzip 後で約540KBです — 画像数十KBを節約するために540KBのランタイムを載せるのは、多くのWebパフォーマンスのシナリオでは本末転倒です。ポリフィルが価値を発揮するのは、JXL の原本をすでに大量に保有している特殊なビューアー系アプリケーションくらいです。

今のうちにやっておいて良いこと。 第一に、画像パイプラインがすでに <picture> や Accept ヘッダーベースのフォーマット分岐を備えているか点検してください。WebP から AVIF へ移行したときに作ったその構造が、そのまま JXL の受け入れ経路になります — フォーマットが一つ増えるだけです。第二に、CDN やオリジンのログで Accept: image/jxl の出現比率を観測項目に加えておいてください。Safari とフラグを有効にしたユーザーがすでに送っており、この比率が階段状に跳ね上がる日が、どこかのブラウザーがデフォルトを変えた日です。第三に、判断のシグナルはニュースではなく1次ソースに掛けておいてください。本物のシグナルは二つだけです — blink-dev に「Intent to Ship: JPEG XL」が投稿されること、そして Firefox の image.jxl.enabled のデフォルト値が Nightly 条件なしに true へ変わるコミットです。このどちらかが起きるまでは、すべて準備運動にすぎません。

付け加えると、この事例には、フォーマットとは無関係な教訓が一つあります。2022年の削除は「品質が悪かったから」ではなく「保守負担を負うだけの理由が乏しかったから」であり、2025年の方針転換はベンチマークではなく、その負担の構造を変えたこと(メモリ安全な共有デコーダー + 外部貢献 + 保守の約束)によって生まれました。ブラウザーに機能を組み込む問題において、技術的優位性をめぐる論争は思ったほど変数ではなく、保守の経済学こそが定数なのです。

おわりに

「JPEG XL が戻ってきた」の正確なバージョンはこうです — Chromium が条件付きで門を開き、外部の貢献者と libjxl チームによる Rust デコーダーがその門をくぐり、Firefox は同じデコーダーを一足先に載せ始め、Safari はそもそも離れたことがなかった。しかし2026年7月現在、どのエンジンもリリースのデフォルト値を変えておらず、変える予定もありません。

だから今やるべきことは切り替えではなく観測です。フォーマット分岐の構造を整えておき、Accept ヘッダーを見張り、Intent to Ship というたった一つの本物のシグナルを待つこと — それが、今日この時点で JPEG XL について実務者が取りうる最も正直なポジションです。