JPEG XLにはWeb標準として追加採用するだけの明確な性能上の余剰利益が見えない:Webコーデックにとって、最大限の表現力が必ずしも良い特性とは限らない理由 #九14 #2025王02ChromiumとJpegXL関係_令和IT史ざっくり解説

 　筆者は、JPEG XLが技術的には非常に優れた画像コーデックであり、従来のJPEGを大幅に改良し、WebPよりも多用途で、Web以外の用途にも適していると評価している。しかし、Chromeが2023年に対応を拒否したことで、JPEG委員会が推進するロイヤリティフリーかつ柔軟で高効率な形式が、大企業の影響によって不当に扱われたのではないかという議論が生じた。近年はRust製のJPEG XLデコーダーがFirefoxやChromeに導入されつつあり、2023年に発生したWebPの脆弱性を受け、主要ブラウザ関係者が方針を変えた可能性もあるが、それだけでWebにJPEG XLを採用する十分な理由になるのかを筆者は検討している。 　筆者は過去にはJPEG XLを幅広い用途で強く支持し、2024年のJPEG XL interopにも参加し、主要開発者であるJon SneyersやJyrki Alakuijalaとも交流してきた。両者の技術力、冷静な態度、公開活動、形式に対する情熱を高く評価している。一方で、今回の論考は作者や成果を攻撃するものでも、フリーソフトウェアにおけるJPEG XLの象徴性を否定する政治的主張でもなく、2026年時点の画像圧縮とWebプラットフォームの状況を実証的に考察する教育的な試みだと位置づけている。 　筆者はもともと動画圧縮を起点に画像圧縮に取り組み、AV1エンコーダーの開発やAVIFの改善を通じて多くの知見を得た。その後、自身のエンコーダーを開発する際、将来性、最適化のしやすさ、圧縮性能、現在および潜在的な用途を比較した結果、JPEG XLを採用しない判断をした。Webにおける多用途の非可逆圧縮では、現状ほとんどの用途が満たされており、一般的な利用者にはロスレス圧縮よりも、写真以外の画像でも目立つ破綻を避けられる汎用的な非可逆形式のほうが重要だと考えている。 　JPEG XLのロスレス圧縮はWebPより約11.9％小さい場合があるものの、その比較にはWeb用途として現実的とは言いにくい大容量の写真、イラスト、書籍画像が使われている。さらに、Web上のコンテンツの多くは帯域幅の影響を強く受けないため、限られた画像だけを約12％削減する目的で新しいブラウザ対応を導入する価値は低いと筆者は見る。JPEG XLは非可逆圧縮で競争力を十分に示せておらず、ロスレス性能が実質的な強みだとしても、その利点だけではWeb採用を正当化しにくいという判断である。 　かつてJPEG XLを支持する主要な論拠の一つは、参照エンコーダーが競合形式よりも人間の知覚に最適化されているというものだった。しかし現在では、AV1やSVT-AV1などのエンコーダーが、管理された主観評価試験に基づく知覚調整を行い、画質指標向けの設定と人間の視覚向けの設定を両立させている。そのため、現代の競合エンコーダーが人間の目に合わせて調整されていないという主張には説得力がない。 　知覚評価指標は完全ではないものの、CVVDP、MS-SSIM、SSIMULACRA2などの結果はJPEG XLに厳しい状況を示している。Halide Compressionが開発中のApertureエンコーダーも、libjxlが圧縮効率の最前線に追いつくべき差の大きさを示す例として挙げられている。JPEG XLは指標上の性能以上に知覚的な強さがあるという反論も存在するが、差がこれほど大きい場合、評価グラフが実際には完全に逆転していると考える十分な証拠はないと筆者は述べる。また、JPEG XLの参照エンコーダーには、現在も解決しきれていない知覚上の問題が残っている。 　筆者は、コーデックそのものではなくエンコーダーを比較すべきだと認めており、理論上はJPEG XL形式の性能上限がlibjxlの現在の結果より高い可能性も認めている。しかし、圧縮技術者として見ると、その差を埋めることは容易ではないと考えている。その理由の一つとして、JPEG XLには方向予測モードがない点を挙げる。JPEG XLでは画像を2×2から256×256までのVarDCTブロックに分割し、画素を周波数表現へ変換するが、WebPのような他のブロック型コーデックは周囲の情報から対象ブロックの画素を予測し、予測との差分だけを符号化できる。この仕組みの違いが圧縮効率や処理性能に影響すると考えられている。 　後半では、同じ画像を同程度のサイズに圧縮した比較として、JPEGが2,478,828バイト、JPEG XLが2,599,428バイト、AVIFが2,649,949バイト、WebPが2,693,794バイトだった例が示される。JPEG XLはWebPより9万キロバイト以上小さい一方、wpdを用いたjxl-rsではWebPより10倍以上遅くデコードされた。つまり、JPEG XLはファイルサイズの面で一定の利点を示す場合があるものの、Webで重要なデコード速度との交換条件が大きい。 　さらに、JPEG XLの表現力の高さは、極端にデコード時間の長い画像を作れるという危険性にもつながる。ある画像は素数を33,599まで計算させる処理を含み、M5 Pro上のRustデコーダーで17.43秒のユーザー時間を要した。その画像自体はわずか1,918バイトであり、ChromeやFirefoxなどに導入される可能性のあるデコーダーを利用すれば、低性能な端末を簡単に過負荷状態にできる。SafariではすでにJPEG XLをネイティブ対応しているため、同様の画像をWebページに数十個配置するだけでも、Apple製端末の動作を大幅に遅くできる可能性がある。 　筆者は、Web向けコーデックはWebの要件に特化し、効率的で、用途を過度に広げない設計であるべきだと主張する。WebPはやや用途を限定しすぎた面があるものの、Web向けに設計するという方向性は正しかったと評価している。AVIFについてはコンテナや、画像の特定の性質、たとえば4:2:0のアップサンプリング処理を規範的に定めるAV1仕様に改善の余地があるが、AV1を基盤とするためWebへの導入は必然的であり、成熟したエコシステムの恩恵も受けている。 　それに対してJPEG XLは、あらゆる用途に対応することを目指した形式であり、Webに必要な範囲を大きく超えている。Webでは帯域幅の削減、迅速なデコード、安全性、実装上の予期せぬ負担の回避が重要だが、筆者はJPEG XLがWebP以上に適しているとは考えていない。さらに、WebPの普及でさえ多くの時間を要した中、AVIFとJPEG XLの両方を追加すれば、画像をダウンロードして別の環境で利用したい開発者や利用者に、互換性上の負担を二重に課すことになる。 　筆者は以前、AVIFとJPEG XLが共存し、開発者がそれぞれの長所に基づいて形式を選べるWebを望んでいた。当時はJPEG XLが中高画質の非可逆圧縮でAVIFより有力であり、両者には異なる用途に向いた本質的な強みがあると考えていた。しかし現在では、AVIFが画質のほぼ全域で優位に立つようになり、JPEG XLが持っていたWeb向けの実質的な優位性は失われたと判断している。 　また、JPEG XLはCloudinaryとGoogleに由来する技術であるにもかかわらず、Googleのブラウザ市場での支配力、Google発のAV1、WebPをめぐる論争の影響から、JPEG XLを支持する議論の一部は、技術的優越性よりもWebにおける開発者の選択肢を増やしたいという願望に基づいているのではないかと筆者は推測する。その動機には理解を示しつつも、JPEG XLはWeb以外の専門用途でこそ、AVIFにはない価値を発揮できると考えている。 　具体的には、Adobe製品などの専門的な画像編集環境、カメラ、スマートフォン、その他の機器でJPEG XLが普及する可能性に期待している。JPEG XLは決して無用な技術ではなく、Web以外の用途にとっては魅力的で、柔軟かつ高機能なコーデックである。しかし、現時点でブラウザに広く導入する必要性については、筆者は納得していない。結論として、JPEG XLの技術的価値は認めながらも、WebではAVIFやWebPのほうが要件に適合し、JPEG XLの追加対応による性能、安全性、互換性の負担を正当化するだけの明確な利点はないと結論づけている。

評価

この論考の核心は、**「JPEG XLは優れたコーデックか？」ではなく、「その優秀さはWebブラウザに新たな標準として実装するコストを正当化するか？」**という問いに置き換わっています。

この切り分けはかなり重要です。

筆者の主張を整理すると、次のような構造です。

論点	筆者の評価
JPEG XLそのもの	技術的には非常に優秀
ロスレス圧縮	強みがある
高機能性・柔軟性	AVIF/WebP以上
Web向け非可逆圧縮	AVIFに対する明確な優位性を失った
デコード速度	問題がある
デコーダーの複雑性	Webではリスク要因
極端なデコード負荷	セキュリティ／DoS的懸念
Web以外	むしろ有望
ブラウザ標準化	現時点では費用対効果が悪い

つまり、**「JPEG XLはダメ」ではなく「Webという特定の実行環境におけるJPEG XLの限界効用が低い」**という議論です。

1. 最も強い論点は「コーデック」から「プラットフォーム」への視点移動

JPEG XLをAVIFと比較して、

どちらが圧縮率に優れるか

だけを議論すると、話がcodec benchmarkに閉じてしまいます。

しかしWebの場合、実際には、

圧縮率 × エンコードコスト × デコードコスト × メモリ × セキュリティ × 実装コスト × 互換性 × エコシステム

の総合評価になります。

したがって、仮にJPEG XLが特定条件でAVIFより10%小さくなるとしても、

「10%小さいからブラウザに実装すべき」

とは自動的にはなりません。

ここは筆者の論証としてかなり強いところです。

---

2. 「12%小さい」の扱いには注意が必要

一方で、ここは少し慎重に読むべきです。

「Webコンテンツの多くは帯域幅の影響を強く受けないから、12%程度の削減には意味がない」という部分は、JPEG XLのWeb価値を否定するための補助論拠であって、決定打ではありません。

大規模CDNでは、

数％の転送量削減 × 数十億リクエスト

でも相当な意味を持ちます。

したがって本当に重要なのは、

JPEG XLが12%削減できるか

ではなく、

AVIF等に対して、Web全体で十分な割合の画像を、十分な品質で、十分なデコードコストの範囲内で、どの程度削減できるか

です。

ここを大規模な実Webデータで検証しない限り、「12%だから価値がない」という結論はやや強すぎます。

---

3. 「ロスレス」はJPEG XLの本当の戦場

むしろこの論考で面白いのはここです。

JPEG XLのロスレス性能は、単純な「次世代Web画像フォーマット」の競争より、

JPEGの後継／アーカイブ／編集／マスターデータ／カメラRAW／画像ワークフロー

という領域で評価したほうが合理的です。

特に、

JPEG → JPEG XLへの可逆トランスコード

というJPEG XL固有の強みがあります。

この場合、

既存JPEGの完全な復元可能性 + より小さい保存サイズ

という、WebPやAVIFとは違う価値になります。

したがって筆者が最後に、

JPEG XLはWeb以外でこそ価値がある

と方向転換するのは、かなり筋が通っています。

---

4. 「知覚品質」の論争は、かなり重要

ここも2026年時点では議論の前提が変わっています。

JPEG XL支持側には以前、

JPEG XLは人間の視覚特性を考慮した設計だから、単純なPSNR/SSIM比較では評価できない

という論法がありました。

これは一定の合理性があります。

しかし、AV1系エンコーダー側も高度なpsychovisual optimizationを行うようになると、

「JPEG XLだけが知覚最適化されている」

という差別化は成立しにくくなります。

したがって筆者が指摘しているのは、

JPEG XLの知覚品質が悪い

というより、

「JPEG XLだから知覚品質で圧倒的に有利」という歴史的な優位性が薄れた

ということです。

この区別は重要です。

---

5. ただし「AVIFが画質のほぼ全域で優位」は最も検証すべき主張

ここは論考全体の中でもっとも疑って読むべきところです。

コーデック比較では、

エンコーダーのバージョン
プリセット
速度設定
量子化設定
画像カテゴリー
解像度
クロマサブサンプリング
HDR/SDR
評価指標
主観評価方法

によって結果が大きく変わります。

したがって、

AVIF > JPEG XL

というグラフが存在しても、それだけで

AVIFという規格そのもの > JPEG XLという規格そのもの

とは言えません。

筆者自身も「codecではなくencoderを比較すべき」と認めています。

ここには論理的な緊張があります。

「libjxlの現在の性能ではAVIFに負ける」

と

「JPEG XLというフォーマットはAVIFに負けている」

は別命題です。

---

6. デコードDoSの議論は非常に面白いが、これも「JPEG XL固有の脆弱性」とは分ける必要がある

1,918 bytesの画像をデコードするのに17.43秒という例は、Webプラットフォームの観点では確かに強烈です。

ここで問題になるのは、

compressed size ≠ computational complexity

ということです。

つまり、

小さい画像ファイルだから安全・高速

とは限りません。

JPEG XLの表現力が高いほど、

「非常に小さい入力から非常に大きな計算量を誘発する」

という攻撃面が発生し得ます。

これはユーザーが以前から考えているVerification Economics / Runtime Politicsにもかなり近い問題です。

Webブラウザではファイルフォーマットは単なる「データ形式」ではなく、

未信頼入力によってブラウザの計算資源を消費する実行境界

になります。

その意味で、

「高機能なフォーマットほどWebに適している」

とは限らない。

むしろ逆に、

Webでは表現力そのものがattack surfaceになる

という非常に重要な設計原理が見えてきます。

---

7. ただし、ここから「JPEG XLは危険」と一般化するのは早い

17.43秒という結果から直ちに、

JPEG XLブラウザ実装は危険

とは言えません。

重要なのは、

• デコーダーの実装

• 最大計算量

• メモリ上限

• タイムアウト

• sandbox

• progressive decoding

• worker分離

• 悪意ある画像へのresource budgeting

などです。

つまり問題は、

「JPEG XLという仕様に計算量爆発の余地があるか」

と、

「ブラウザ実装がそれを安全に制御できるか」

の二段階に分ける必要があります。

ここを分けないと、codec designとbrowser implementationの責任範囲が混ざります。

---

8. この論考で最も重要なのは「Webは万能フォーマットを必要としていない」という思想

ここが私は一番面白いと思います。

JPEG XLは、

画像を何でも表現できる汎用的な「画像の母語」

を目指している。

一方WebP/AVIFは、

Web配信に必要な機能を、既存のWebインフラの中で効率よく提供する

方向です。

この違いを図式化すると、

JPEG XL

表現力 ↑
汎用性 ↑
機能 ↑
実装複雑性 ↑
Webで必要な範囲を超える可能性 ↑

Web向けcodec

必要機能に限定
デコード容易性
予測可能性
実装可能性
エコシステム

となります。

これは「高機能＝優秀」というソフトウェア設計思想への反論にもなっています。

---

9. そして「ブラウザ対応」という問題はネットワーク効果の問題になる

JPEG XLの最大の弱点は、単純な圧縮率ではなく、

既存フォーマットを置き換えるネットワーク効果

でしょう。

Webでは、

ブラウザが対応する
↓
Webサイトが採用する
↓
CDNが最適化する
↓
ユーザー環境が対応する
↓
さらにサイトが採用する

という正のフィードバックが必要です。

しかし既に、

JPEG + WebP + AVIF

が存在しています。

ここにJPEG XLを追加すると、

「JPEG XLの性能が良いから採用する」

ではなく、

「JPEG XLを採用することで既存の複雑性をどれだけ減らせるのか」

が問われる。

ところがJPEG XLには既存JPEGを置換する強い用途はあるものの、Webの非可逆配信についてはAVIFとの重複が大きい。

そのため、

技術的には優秀なのに、標準化競争では勝てない

という現象が起こります。

---

10. Google陰謀論に寄せないところも評価できる

「ChromeがJPEG XLを拒否した → GoogleがAVIF/WebPを推進している → JPEG XLが不当に排除された」

というストーリーは非常に作りやすい。

しかしこの論考はそこから一歩引いて、

Googleの市場支配という政治的問題は理解できる
しかし、それとJPEG XLをWebに採用すべきかは別問題

と切り離しています。

これはかなり重要です。

標準化の公平性と技術的妥当性は別の評価軸だからです。

仮にChromeの判断が競争政策上問題だったとしても、

だからJPEG XLはWebに最適

とはならない。

逆に、

JPEG XLはWebに最適ではない

としても、

Chromeによる標準化判断が完全に正当だった

とも限りません。

この二つを分離できている点は、論考として健全です。

---

私なら最終的にこう評価します

この論考の一番強い命題は、

「JPEG XLは悪いコーデックだからWebに不要なのではなく、JPEG XLの長所がWebブラウザという実行環境で必要とされる長所ではなくなってきた」

です。

逆に一番弱いのは、

「AVIFがほぼ全域でJPEG XLを上回ったので、JPEG XLにはWeb上の実質的価値がない」

という部分。

これはエンコーダー、画像カテゴリ、品質領域、評価指標、実ユーザー環境によって再検証する必要があります。

そして、さらに一段抽象化すると、この論考はJPEG XL論争というより、

「汎用性」と「プラットフォーム適合性」は同じではない

という話になっています。

これはかなり普遍的な原理です。

JPEG XL = capability maximization
WebP/AVIF = platform optimization

と見ると、なぜ「技術的には優秀なのにWebでは採用されない」という一見矛盾した現象が起きるのか、かなり綺麗に説明できます。

そしてこの視点から見ると、JPEG XLの最も有望な未来は「AVIFをWebから追い出すこと」ではなく、JPEG互換・ロスレス・編集・アーカイブ・カメラ・プロフェッショナル画像処理という、Web配信とは異なる計算経済圏を取ることだと思います。はい、このURLが元記事ですね。先ほどの要約と照合すると、あなたが提示した文章はかなり忠実に記事全体を要約しています。記事は2026年9月13日公開のGianni Rosatoによる “The case against JPEG XL” です。(Gianni Rosato)

そして原文を実際に読むと、先ほどの私の評価を少し修正したほうがいいです。

特に重要なのは、これは単なる「JPEG XL vs AVIF」の画質比較記事ではなく、JPEG XLのコーデック設計そのものに対する、かなり技術的な批判になっています。

原文で特に重要な5点

1. 批判の中心はlibjxlではなく、JPEG XLの「coding tools」にまで踏み込んでいる

著者は「codec benchmarkではなくencoder benchmarkだ」と明言し、理論上はJPEG XLの性能上限がlibjxlより高いことを認めています。ところが、そのうえで、

• directional predictionがない

• deblocking loop filterがない

• XYBの効率上の利点が当初ほど大きくない

• 非写真画像への対応が弱い

• patchesがAV1のIntraBCより複雑

• residual codingも不利

と、**「そもそも最適なエンコーダーを作ったとしてもAV1系を追い越すのは簡単ではない」**というところまで論じています。(Gianni Rosato)

これはかなり強い批判です。

「libjxlが未熟だから負けているだけ」

というJPEG XL側の反論に対して、

How hard would it be to close the gap?

と問い、その答えとしてフォーマットのcoding-tool architecture自体に疑問を呈しているわけです。

---

2. 特に「directional predictionがない」という指摘は重要

ここはJPEG XL批判の技術的な核心の一つです。

WebP/AV1系では、

周囲の画素 → 対象ブロックを予測 → prediction residualだけを符号化

という構造を使えます。

一方、JPEG XLのVarDCTでは基本的にブロックを周波数領域に変換する。

そのため、エッジや線などを効率的に表現する場合、

「予測して差分を送る」

という非常に強力な道具が不足している、というのがRosatoの主張です。さらにその代替としてpatchesやsplinesを持ち出すと、今度はエンコーダー側のRDOが非常に複雑になる。(Gianni Rosato)

これは単なるベンチマーク結果ではなく、コーデック設計思想への批判です。

---

3. 非写真画像の弱さをかなり強く問題視している

これはWeb用途では非常に重要です。

Web画像は写真だけではありません。

• UI

• スクリーンショット

• イラスト

• 漫画

• ロゴ

• ダイアグラム

• テキスト主体画像

などがあります。

RosatoはJPEG XLのpatchesについて、AV1のIntraBCより構造が複雑で、参照フレーム、crop、blend、patch dictionary、coordinates、residual frameなどのオーバーヘッドが発生し得ると詳細に説明しています。(Gianni Rosato)

つまり、

「JPEG XLは万能だからWebにも向いている」

ではなく、

「万能性そのものが、Webで頻出する画像に対して最適化されていない可能性がある」

という逆説です。

---

4. 「Web codecは狭く作れ」という結論が非常に明確

原文では、

Web codecs should be purpose-built, efficient, and narrowly scoped

という設計思想が結論になっています。(Gianni Rosato)

これは今回の記事の一番重要な思想だと思います。

JPEG XLは、

「画像という媒体を広くカバーする」

ことを目指している。

対してWeb codecは、

「Webページで画像を高速・安全・安価に表示する」

ことだけを最適化すればいい。

だから、

4096 channels
arbitrary color depth
JPEG recompression
progressive decode
その他多数の表現能力

はJPEG XLにとっては長所ですが、Webブラウザにとっては実装・検証・攻撃面を増やす可能性のある余計な能力にもなる。(Gianni Rosato)

これは、以前あなたが考えていた**「高機能なAI/エージェントほど統治・検証コストが増える」**という問題と構造的にかなり似ています。

Capability ↑
→ Use case ↑
→ Implementation complexity ↑
→ Verification surface ↑
→ Attack surface ↑

という構造です。

---

5. ただし私は「この記事はJPEG XLを決着させた」とまでは評価しない

ここは重要です。

この記事は非常に技術的で、著者自身もAV1/AVIFのエンコーダー開発者なので、JPEG XLを外部から雑に批判している記事ではありません。(Gianni Rosato)

しかし、それでも、

「JPEG XLはWebに不要」

を完全に証明したわけではありません。

最大の弱点はやはり、

特定の現行エンコーダー／デコーダーの性能

↓

JPEG XLという規格そのもののWeb適性

への外挿です。

著者自身がそこを認めています。

したがって最も正確な読み方は、

2026年時点のlibjxl/JXL ecosystemを基準にすると、JPEG XLにはAVIFをWeb標準として追加採用するだけの明確な性能上の余剰利益が見えない

という主張です。

これはかなり説得力があります。

一方、

JPEG XLというフォーマットの潜在性能がAVIFを超えられない

まで証明されたわけではありません。

---

そして「17.43秒のJPEG XL」は別格で重要

記事で私が最も注目するのは、実は画質比較よりここです。

1,918 bytesの画像が、M5 Pro上のRust decoderで17.43秒のCPU時間を消費する。(Gianni Rosato)

これは、

compressed representationの小ささとcomputational costは独立している

ことを非常に分かりやすく示しています。

Web標準ではこれは重大です。

なぜならWebは、

「サーバーが信頼できない入力を送ってくる」

世界ではなく、

「誰でもHTMLを作って、誰でも他人のブラウザにデータを処理させられる」

世界だからです。

したがってWeb codecの評価関数は、

compression ratio

だけではなく、

compression ratio × decode latency × worst-case computational cost × memory × implementation complexity × attack surface

で考える必要がある。

ここまで考えると、この記事の本当のタイトルはむしろ、

「Why maximum expressiveness can be a bad property for Web codecs」

でも成立すると思います。

そしてこれはJPEG XLに限らず、WebAssembly、フォント、PDF、画像、動画、AIモデルなど、ブラウザに投入される複雑なバイナリフォーマット全般に適用できる原理です。じゃあ意図的に厳しく読む。原典はGianni Rosatoの `The case against JPEG XL`。

この論考は強いけど、批判的に分解すると穴は5つある。

### 1. 一番の論理的緊張： encoder vs codec を自分で破っている

著者は自分で

> There's no such thing as a codec benchmark, only an encoder benchmark

と書いている。これは正しい。

なのに結論では

> AVIF now dominates the entire fidelity range, so JPEG XL's one real advantage has disappeared.

まで行く。これは **現時点のlibjxl vs SVT-AV1-psy / aomの勝敗を、そのまま規格の天井の勝敗に外挿** している。

あなたが記事内で指摘した通り、これは

> libjxlの現在の性能ではAVIFに負ける ≠ JPEG XLというフォーマットはAVIFに負けている

の混同。著者自身がcoding toolsの弱さを列挙することでそれを補強しようとするが、directional predictionがない、deblockingがない、というのは「AV1型の最適化がやりやすいか」という観点では正しくても、**それが超えられない天井なのか**は証明されていない。特にXYBやVarDCTの潜在能力については、JPEGの再実装であるjpegliがXYBで効いた例もある。

### 2. データセットと指標の選択バイアス

2つの数字の使い方が危うい。

**ロスレスで11.9%の話：**

> roughly 11.9% smaller than lossless WebP

> on an unrealistic test dataset for the Web (157 MP photos, 10 MP illustrations, and 27 MP books)

これは著者が「Webではロスレスは量が少ないし、データセットも非現実的だから価値がない」と切る根拠。だが逆に読めば、**WebPロスレスとの比較で使われたデータセットが157MP写真中心なら、Webの実画像分布ではもっと差が開く可能性もある**。小さいアイコンやスクショこそロスレスの主戦場なのに、そこで評価していない。

**非可逆のグラフ：**

CVVDP / MS-SSIM / SSIMULACRA2で大きく負けているのは事実だが、著者の新しいエンコーダー `aperture-alpha` を一緒に出している。つまり比較対象が「最新のAV1心理視覚チューニング済みエンコーダー vs 安定版libjxl」という非対称。AV1側が

> specialized perceptual tuning based on controlled subjective human trials

をやった結果勝っているなら、それはフォーマットの勝ちではなくエンコーダー開発リソースの勝ち。後発のJPEG XLに同じリソースを注げば逆転する余地は論理的に残る。

### 3. デコードDoSの例は強力だが、一般化しすぎ

> computes primes up to 33,599 and takes 17.43s of user time to decode

> this is just 1,918 bytes, so it's about to become trivially easy to JXL-bomb low-end devices

これはWebの文脈では一番刺さる指摘で、あなたが書いた `compressed size ≠ computational complexity` は完全に正しい。ただし、これをもって

> Web codecは表現力を絞るべき

まで行くのは早い。なぜなら:

- これはRustデコーダー (jxl-rs) の未成熟なresource budgetingの問題でもある。AVIF / WebPでも初期は同様の爆弾があった。

- 対策は仕様変更ではなく実装側で可能：最大メモリ、最大チャネル(4096chはWebでは不要)、最大計算ステップ、progressiveの打ち切り。著者自身が多チャネルや任意ビット深度を

> Many of these features are not broadly useful on the Web

と切り捨てているなら、Webプロファイルで禁止すれば済む話でもある。

つまり「高機能だから危険」は真だが、「高機能だからWebに向かない」は別。WebPもアニメーションやICCで同じ批判を受けた。

### 4. ネットワーク効果の議論が自己成就的

> it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL

これは事実だが、**既に3つあるから4つ目は不要**という論法は、3つ目だったAVIFにも同じく当てはまるはず。実際AVIFは

> AVIF was always a guaranteed addition to the Web due to AV1

というエコシステムの既得権で正当化されている。JPEG XLが「技術的に優れていても勝てない」のは圧縮効率ではなく、あなたが言うネットワーク効果の問題。だとすればこれは技術的敗北ではなく、**プラットフォームの経路依存性**の話で、善悪ではない。

### 5. 著者の立場バイアス

著者は

> I do image compression work, coming from video compression originally. While working on an AV1 encoder, Julio Barba and I made significant advancements to AVIF

> When I decided to start building my own encoder, I had to think very hard... I decided not to work with JPEG XL.

と明言している。つまりAV1系のエンコーダーを作ってきた当事者で、これからapertureという自作エンコーダーを出す立場。これは利害衝突ではないが、評価軸が自然に **「RDOで最適化しやすいか」「directional predictionのような古典的道具があるか」** に寄る。JPEG XLのsplinesやpatchesが

> vastly more difficult to use

> more difficult to use than AV1's Intra Block Copy

というのはエンコーダー実装者の視点では正しいが、Webの利用者視点では「難しいが実装されれば効く」なら価値は残る。

---

### じゃあ何が残るか？

批判しても、この論考の核心は崩れない。

1. **プラットフォーム適合性 ≠ 汎用性** という思想は正しい。Webでは4096チャネルやJPEG再圧縮の20%削減より、高速デコードと予測可能性が優先される。

2. **デコード時間**で `JPEG was 2,478,828 bytes, the JPEG XL was 2,599,428... WebP is over 90kb larger and still manages to decode over 10x faster than jxl-rs`という実測は、サイズマッチさせてもJXLが遅いという現時点の事実として重い。

3. **「Web以外でこそ有望」**という結論は、批判的読解後もむしろ強まる。ロスレスやJPEGトランスコード、編集・マスター用途はAVIFが苦手な領域で、そこを取りに行く方がJPEG XLの能力主義に合致する。

なので、僕の批判的評価はこう：

> **「JPEG XLはWebに不要」までは証明されていないが、「2026年時点のエコシステムで、AVIFに加えてJPEG XLをWeb標準として追加採用するだけの明確な余剰利益は観測されていない」** は十分に示された。

これはあなたのタイトルそのままだし、最も誠実な読み方だと思う。

反証したいなら必要なのは、①大規模な実Web画像コーパスでのAVIF vs JXLのレート歪み比較、②Webプロファイルに絞った上でデコードDoSを防げるresource limitの実装と計測、③非写真画像でのpatchesの有効なPoC、この3つ。　本文は、JPEG XL、AVIF、WebPなどの画像形式をめぐり、画質、ハードウェアデコード、ロスレス圧縮、プログレッシブ表示の利点と限界について交わされた議論をまとめたものである。 　議論の中心的な懸念は、AVIFが動画圧縮規格AV1を基盤としているため、画像用途でも動画向けハードウェアデコーダーの制約を受ける可能性がある点である。 　特にAV1のメインプロファイルでは、一般的なハードウェア実装が4:2:0の色差サブサンプリングに偏る可能性が指摘されている。 　4:2:0は写真や動画では一定の圧縮効率を得られる一方、イラスト、スクリーンショット、文字、ピクセルアートなどの静止画では色の境界や細部を大きく損なうことがある。 　したがって、画像形式としてAVIFを利用する際に、ハードウェアデコード対応を優先すると、4:4:4や高ビット深度などの機能が実質的に使いにくくなる未来が懸念されている。 　ピクセルアートは、色境界を正確に保持する必要があるため、4:2:0との相性が特に悪く、ロスレス圧縮も不可欠な分野の例として挙げられている。 　また、ウェブでは非可逆圧縮だけでなく、編集、比較、保存、再利用などのために優れたロスレス圧縮も重要であると主張されている。 　画像をYUVへ変換する段階で情報が失われる場合、それをロスレス形式として扱うことはできないという指摘もある。 　4:2:0の問題は静止画だけに限らず、動画でも細い線、文字、ゲーム画面などのコンテンツに悪影響を与える。 　ゲーム映像が一般的な動画エンコード処理を通ると粗く見える主因の一つも、4:2:0による色解像度の低下だと説明されている。 　もっとも、ストリーミング動画はビットレートが低いことが多く、4:2:0以外にも多くの圧縮要因が画質を悪化させるため、視聴者は必ずしも問題を強く意識していない。 　さらに、1チャンネルあたり8ビットという制約も、滑らかな階調を必要とする画像ではバンディングを生じさせる。 　8ビット画像は編集時に階調の劣化を拡大しやすく、ディザリングも圧縮によって失われやすいため、十分な解決策にならないとされている。 　一方で、AVIFの仕様自体は4:4:4、ロスレス圧縮、非写真画像などをサポートしており、ブラウザも4:4:4 AVIFをすでに扱えるという反論がある。 　そのため、互換性を理由にブラウザが4:4:4対応を後退させるとは考えにくく、現時点では4:4:4 AVIFを利用できるという説明がなされている。 　AVIFのハードウェアデコードが画像表示で大きな利点になるかどうかについては、意見が分かれている。 　ブラウザは動画に対してハードウェアデコードとソフトウェアデコードを使い分けているが、画像ではハードウェアデコードの実験が過去に何度も行われ、その多くが成功しなかったとされている。 　Safariを含む主要ブラウザも、AVIFやWebPの画像表示に積極的なハードウェアデコードを導入していないという指摘がある。 　画像デコードはソフトウェアでも十分軽量であり、わざわざ専用ハードウェアを利用する必要性は小さいという見方も示されている。 　さらに、現代の画像デコーダーはインターネットから届く信頼できないデータを処理するため、大手企業はメモリ安全性や脆弱性を重視し、ハードウェア画像デコードを慎重に扱う。 　メッセージングアプリやファイルブラウザーは、画像を受信または発見した時点で自動的にプレビューを生成するため、デコーダーの脆弱性がゼロクリック攻撃につながる可能性もある。 　ただし、ブラウザが動画ではハードウェアデコードを広く使っていることから、安全性だけが画像デコードを避ける理由とは限らないという反論もある。 　ハードウェア実装の制約に関する具体例として、H.264では10ビット動画を規格上扱えても、当時のハードウェアデコーダーが対応しなかったため、10ビット利用が主流にならなかったことが挙げられている。 　その後、より新しい動画規格が10ビット対応を標準的な要件にしたことで、ようやく広範な普及が進んだ。 　この事例から、規格上の対応だけでは不十分であり、ハードウェアがどの機能を標準的に実装するかが、実際の利用範囲を左右すると論じられている。 　AV1やAVIFについても、仕様上4:4:4を扱えても、GPUや専用エンコーダー・デコーダーが4:2:0に限定されれば、高品質な画像用途が圧迫される可能性がある。 　NVIDIAのNVENCやNVDECなどで、世代や実装によって4:2:0のみを扱う制約が存在したという経験談も提示されている。 　ただし、すべての実装が4:4:4を扱えないわけではなく、主要なソフトウェアやハードウェアの対応状況には差がある。 　後半では、AVIFとJPEG XLのプログレッシブ表示方式も比較されている。 　JPEG XL側は、画像を少数の段階で表示する設計を採用している一方、AV1のインター予測を利用するAVIFでは、最大4段階のパスを設定できると説明されている。 　AVIFの各パスは前の段階を参照して細部を追加できるため、繰り返し模様の多い画像では、プログレッシブ形式のほうが効率的になる場合もある。 　後続のパスがすでに取得済みなら、ブラウザは中間パスの描画を省略でき、計算量やバッテリー消費を抑えられるという利点もある。 　低速な通信環境では、画像の全体像や主要な被写体を早期に確認できるプログレッシブ表示が有用だと評価されている。 　一方、画像をぼかして表示する方式よりも、未完成であることが明確でありながら内容を把握できる表示のほうが、利用者体験として望ましいという意見もある。 　プログレッシブ表示は、サムネイルと完全な画像という二つの独立した画像を保存するのではなく、画素データを段階的に配置する仕組みだと説明されている。 　これに対して、別々の画像を重ねる方式では二つの画像を保存・描画する必要があり、プログレッシブデコードのほうが容量や帯域幅で効率的だという主張がある。 　反対に、描画途中のバッファを安全に表示するには複数の領域が必要であり、AVIFのプログレッシブ表示も技術的には二層構造と大きく変わらないという反論がある。 　その見方では、AVIFのプログレッシブデコードは技術的な圧縮上の利益が限定的で、二つの画像要素を重ねるだけでも同様の表示効果を実現できるとされる。 　さらに、macOSのFinderなどでは、プログレッシブ表示を導入しても、ファイル情報の取得やプレビュー生成がメイン画面を待たせる問題は残るという指摘がある。 　これに対して、サムネイル生成はバックグラウンド処理で実行でき、Finderの停止感はネットワーク上のメタデータ取得など別の要因による場合が多いと説明されている。 　最終的に、プログレッシブレンダリングはウェブの低速通信環境では実用的な価値を持つが、圧縮効率や実装上の利点については、形式ごとの方式と利用条件を分けて評価する必要があるとまとめられる。この文章の要点は、単純な「AVIF vs JPEG XL」の圧縮性能比較ではなく、「規格上できること」と「ハードウェア・ブラウザ・エコシステム上、実際に使えること」の乖離にあります。

特に重要なのは次の構図です。

論点	AVIF	JPEG XL	評価上の注意
4:4:4	規格上サポート	サポート	AVIFの仕様上の能力と実装状況を分離すべき
10/12-bit	サポート	サポート	ハードウェア対応が普及を左右しうる
ロスレス	サポート	強い	「YUV変換後のロスレス」と「元画像に対する完全可逆」を区別
写真	非常に強い	非常に強い	実用条件で比較が必要
イラスト・文字	条件次第	強みがある	4:2:0を使う場合は特に注意
ピクセルアート	4:4:4等なら対応可能	適性が高い	「AVIFそのものが不適」とは言えない
ハードウェアデコード	動画系HWを利用できる可能性	専用HWの普及度が低い	画像デコードでは動画ほど単純ではない
プログレッシブ	AV1系の段階的表示	JPEG XLの設計上の強み	「見た目」と「圧縮効率」を分ける必要
Web普及	非常に高い	Chrome非対応が大きな障壁	エコシステムが決定的

最大の論点は「4:2:0問題」そのものではない

ここは少し慎重に書いたほうがよいです。

「AVIFは4:2:0なので静止画に向かない」

という結論にすると、技術的には言い過ぎになります。

AVIFは仕様上、4:4:4、10/12-bit、ロスレスなどを扱えます。したがって本質的な問題は、

AVIFというフォーマットが何を表現できるか

ではなく、

その能力のうち、実際のハードウェア・エンコーダー・ブラウザ・CDN・画像パイプラインが何を標準的に利用するのか

です。

これは非常に重要な区別です。

たとえば、

Specification → Codec implementation → Hardware → Browser → Image pipeline → Authoring tool

という各層のどこかで4:2:0への制約が入れば、最終ユーザーから見れば「4:4:4をサポートしている形式なのに、4:4:4が実質使えない」という状況が発生します。

この意味で、H.264の10-bit普及史を持ち出す議論はかなり面白いです。

さらに重要なのは「ハードウェア化＝必ずしも善ではない」こと

本文後半のハードウェアデコード論は、むしろJPEG XL/AVIF論争を一段深いところへ持っていけます。

一般には、

ハードウェアデコード
↓
高速・低消費電力
↓
優れたフォーマット

と考えがちです。

しかし画像の場合、

デコード対象が「インターネットから届く信頼できないバイト列」である

という別の問題があります。

ブラウザ、メッセージングアプリ、ファイルマネージャーなどは、ユーザーが明示的に「開く」と指定する前に画像を自動デコードすることがあります。

したがって画像コーデックは、

圧縮性能 × デコード速度

だけではなく、

圧縮性能 × デコード速度 × メモリ安全性 × 攻撃面 × 実装複雑性

で評価する必要があります。

ここは非常に重要な視点です。

---

「プログレッシブ」の議論も分解したほうがいい

本文では「プログレッシブ表示」のメリットについて複数の議論が混ざっています。

実際には少なくとも、

1. 初期視認性

2. 帯域幅効率

3. 圧縮効率

4. デコード計算量

5. メモリ使用量

6. レンダリング回数

7. ユーザーが待ち時間をどう知覚するか

を分けるべきです。

たとえば、

「途中まで表示できる」

ことと、

「途中まで表示することでファイルサイズが小さくなる」

ことは別問題です。

さらに、

「途中まで表示できる」

ことと、

「途中まで表示するためのデコード・バッファリング・再描画コストが小さい」

ことも別です。

したがって「JPEG XLのプログレッシブ表示はAVIFより優れている」というような一枚岩の結論ではなく、

Progressive rendering is a UX property, while progressive coding is a compression/codec property.

という整理のほうが強いでしょう。

---

この文章から導ける、より大きな論点

私はこの議論で最も面白いのは、実はJPEG XLそのものではないと思います。

それは、

「標準規格の自由度は、実装エコシステムの自由度ではない」

という問題です。

規格が、

4:4:4
12-bit
lossless
progressive
alpha
HDR

を全部サポートしていても、

ハードウェアが、

4:2:0
8-bit

を中心に実装すれば、ユーザーが実際に利用できる画像表現の空間は狭くなります。

つまり、

Format capability ≠ Ecosystem capability

です。

これは画像コーデックだけでなく、動画コーデック、GPU API、AIアクセラレータ、ストレージ、ネットワークプロトコルなどにもそのまま一般化できます。

そして、あなたが以前扱っていたJPEG XLのChrome非対応問題とも接続できます。

「技術的に優れているか」ではなく、「どの層が実効的な選択空間を決めるのか」

という問題です。

この観点から見ると、JPEG XL vs AVIF論争は単なる「圧縮率競争」ではなく、

仕様 → 実装 → ハードウェア → ブラウザ → 配信インフラ → ユーザー体験

という技術スタック全体のガバナンス問題として読むことができます。リンク先を確認しました。これはまさに、先ほどの要約の元になっているHacker Newsの議論です。記事タイトルは The case against JPEG XL で、現在148 points・196 commentsまで伸びています。(Hacker News)

そして、先ほどの文章には重要な修正ポイントがあります。

このHacker News議論を踏まえた評価

1. 「AVIFは4:2:0しか使えない」は明確に誤り

スレッドで最も重要な反論はここです。

JPEG XL側の投稿者は、

AVIFはAV1ベースなので、ハードウェアデコーダーが動画用途中心なら4:2:0に限定されるのではないか

と懸念しています。実際、AV1 Main Profile / AVIF Baseline Profileとの関係を根拠にしています。(Hacker News)

しかしMozilla側のJaffa氏は、

Browsers already fully support 4:4:4 AVIF

と反論しています。つまり、現在のブラウザで4:4:4 AVIFを使うこと自体に問題がある、という主張にはならない。(Hacker News)

したがって、

「AVIFは4:2:0だから静止画に不適」

ではなく、

「AVIFは4:4:4を仕様上・ソフトウェア上サポートするが、将来のハードウェアデコード普及がその表現能力を実質的に制約する可能性がある」

とするのが正確です。

これは現在の事実ではなく、将来のアーキテクチャ上の懸念です。

---

2. そして、この懸念には実際に反例・実例がある

ここが議論を面白くしています。

スレッドではNVIDIAのNVENC/NVDECについて、

過去のハードウェア実装では4:2:0しか扱えないケースがあった

という指摘が出ています。

さらに別の参加者がNVIDIAの資料を確認し、H.264の4:4:4デコードが比較的新しい世代まで制約されていたことを認めています。(Hacker News)

つまり、

「規格上対応している」
≠
「ハードウェアが対応する」

というJPEG XL側の問題提起自体には、歴史的な根拠があります。

ただし、

H.264の過去のハードウェア制約 → AV1/AVIFでも同じことが起こる

とまでは言えません。

ここは本文でかなり明確に区別したほうがいいでしょう。

---

3. むしろ現在の議論で強いのは「AVIFのHWデコード問題は本当に重要なのか？」

これが非常に面白いポイントです。

スレッドには、

画像デコーダーはソフトウェアで十分軽量

という意見があります。(Hacker News)

さらに別の参加者は、

ブラウザで画像のハードウェアデコードを利用する実験は過去にもあったが、うまく定着していない

としています。SafariでさえAVIF/WebPについて積極的なHW画像デコードを使っていない、という主張です。(Hacker News)

すると議論の構造は、

JPEG XL側

AVIFは動画由来
→ HW decoderが4:2:0中心になる
→ 4:4:4画像が不利になるかもしれない

に対して、

反論側

そもそもブラウザは画像にHW decoderをほとんど使っていない
→ ならばAV1 HW decoderの4:2:0制約は画像には関係しない

となります。

これはかなり強い反論です。

---

4. ただし「HWデコード不要」で完全に片付けるのも早い

ここは記事の議論でもまだ決着していません。

JPEG XLの問題提起には、

現在そうなっているかではなく、将来そういうアーキテクチャになったとき何が起きるか

という意味があります。

特にモバイルSoCでは、

動画AV1 decoderが既に存在する

↓

AVIFを同じハードウェアパスで処理したくなる

↓

HWが得意なのは標準的な動画プロファイル

↓

4:2:0 / 8-bitなどが「事実上の共通分母」になる

という経済的・実装的な圧力は理論的にはあり得ます。

したがって、これは「AVIFの現在の欠陥」というより、

codec convergenceによって静止画の表現能力が動画codecのハードウェア制約に従属する可能性

という問題として扱うべきです。

---

5. 4:2:0問題より、実は「lossless」の議論のほうが強い

スレッドには非常に重要なやり取りがあります。

「AVIFはlosslessをサポートしている」という指摘に対して、

“It's not lossless if you have to convert to YUV first.”

という反論があります。(Hacker News)

ここは技術的にかなり重要です。

「AVIFにlosslessモードがある」ということと、

RGB/RGBAの元画像をビット単位で完全に復元できる

ことは同義ではありません。

特に、

RGB → YUV変換

の段階で不可逆な変換をしていれば、そこから先をlosslessに圧縮しても、元のRGB画像に対するend-to-end losslessではありません。

したがって、

AVIFはlosslessをサポートしている

だけでは不十分で、

どの色表現から、どの段階までをlosslessと定義しているのか

を見る必要があります。

これはJPEG XLの優位性を論じる際には、4:2:0問題よりもむしろ強い論点になり得ます。

---

6. そして「8-bit問題」もかなり重要

JPEG XL支持側は4:2:0だけでなく、

8 bits per channelという制約自体が問題

と指摘しています。(Hacker News)

特に、

• HDR

• グラデーション

• 写真編集

• カラーグレーディング

• 再圧縮

• ディザリング

では、8-bit → 編集 → 再圧縮というパイプラインが品質劣化を累積させます。

ここでも本質は、

配信用の最終画像

だけを見るのか、

制作・保存・編集・再利用を含む画像ライフサイクル

を見るのか、という違いです。

---

7. このスレッドで最も興味深いのは、実は「JPEG XL vs AVIF」ではない

私はこの議論を、次のように整理するのが一番強いと思います。

AVIFの思想

「既存の巨大な動画codecエコシステムを画像に持ち込む」

その結果、

• 強力な低bitrate圧縮

• AV1との技術共有

• ハードウェア資産の利用可能性

• Webでの急速な普及

を得る。

一方で、

• 動画由来の設計思想

• プロファイル/ハードウェア依存

• 画像特有のlossless要求

• progressive rendering

との緊張関係が生じる。

JPEG XLの思想

逆に、

「静止画を第一級のデータ型として再設計する」

ことで、

• JPEG transcoding

• lossless

• 高bit-depth

• HDR

• progressive decoding

• 高品質lossy

• 大規模画像

などを一つの画像codecに統合する。

その代わり、

巨大な既存動画ハードウェアエコシステムを持たない。

---

だから、このHacker News議論から得られる結論

かなり端的に言えば、

AVIFの弱点として「4:2:0」を現在形で断定するのは弱い。しかし、「動画codecのエコシステムに静止画を乗せることで、将来のハードウェア実装が静止画の表現空間を規定してしまうのではないか」という問題提起は成立する。

一方で、

「JPEG XLなら必ず勝つ」という結論にもならない。

なぜならJPEG XL側にも、

• デコード速度

• ハードウェアアクセラレーション

• ブラウザ普及

• エコシステム

• CDN/画像最適化サービス

• エンコーダー成熟度

という別の問題があるからです。

実際、現在のHacker News議論でも、AVIFがWeb品質域ではJPEG XLより小さくなる一方、losslessではJPEG XLが有利になるという具体的な比較が紹介されています。別の最近のHNスレッドでも、AVIFはWeb向け低bitrateでは強いが、JPEG XLはlosslessやprogressive renderingに強みがあるという整理が出ています。(Hacker News)

したがって、この記事を批評するなら、最大のポイントは、

「JPEG XLはAVIFより技術的に優れている」

ではなく、

「画像codecを動画codecの延長として設計することによって、圧縮効率とエコシステムを得る代わりに、静止画固有の要求をどこまで犠牲にしてよいのか」

という問いです。

そしてこれは、あなたが進めている 「JPEG XLのWeb評価」 の記事にかなり使える論点です。特に「ChromeがJXLを採用しなかった＝JXLが技術的に劣る」という単純な説明を避け、codecの技術的Pareto frontierと、ブラウザ・HW・標準化・エコシステムによって形成される実効的Pareto frontierは別物、というところまで持っていくと、かなり強い論考になります。 (Hacker News)