JPEG XL vs AVIF：どちらのフォーマットを採用すべきか？

2026年のプロダクション向けWeb配信においては、AVIFを採用してください。2026年半ば時点でグローバルブラウザカバレッジは約93%に達しており、CDN・CMS・ビルドツールのサポートも成熟しています。技術的な優位性はJPEG XLにあります——エンコードが高速で、ロスレス圧縮において圧倒的に優れており、ネイティブのプログレッシブデコードにも対応しています——しかしChromeはいまだにJXLをフラグの背後に置いており、JXLのカバレッジはSafari経由の約15%にとどまり、caniuseでは部分的サポートに分類されています。この一点が、公開サイトにおける判断を決定づけます。ChromeがJXLをデフォルトで有効にするまでは、JXLファーストの配信スタックを構築しても、大多数のユーザーにはAVIFまたはJPEGが配信されることになります。

本記事は、意思決定の中間段階にある方を対象としています。すでにWebPまたはAVIFを配信しており、JPEGの限界も把握した上で、フォーマット論争ではなく現在のブラウザの実情に基づいた判断を求めている方に向けて、明確な答えを提示します。圧縮率・ブラウザサポート・エンコードコスト・プログレッシブレンダリングの各基準を順に検討し、正しい<picture>スニペットを提示するとともに、推奨が変わるタイミングを判断するための具体的なシグナルをお伝えします。

各フォーマットの実態

AVIFとJPEG XLは同じ課題——同等以上の品質でより小さな画像を実現すること——を解決しますが、その設計思想は対照的な系譜から生まれています。AVIF（AV1 Image File Format）は2019年にAlliance for Open Mediaによって発表され、YouTubeやNetflixなどが採用するAV1ビデオコーデックのキーフレームイントラ符号化から派生しています。JPEG XL（ISO/IEC 18181）は、Joint Photographic Experts GroupがGoogleおよびCloudinaryと共同で静止画フォーマット専用に設計し、2022年に標準として策定されました。

この系譜の違い——AVIFがビデオコーデックから派生し、JPEG XLが静止画専用に設計されたという点——が、以下に述べるトレードオフのほとんどを説明しています。AVIFはAV1の優れたロッシー写真圧縮を継承する一方、CPUへの負荷が高いエンコーダも受け継いでいます。JPEG XLは画像固有の要件——プログレッシブデコード、高ビット深度カラー、ロスレスモード、そして他のモダンフォーマットにはない機能——を中心に設計されました。その唯一無二の機能とは、ロスレスJPEG再圧縮です。既存のJPEGをJXLにトランスコードしてファイルサイズを約20%削減し、元のJPEGをバイト単位で完全に復元できます。これにより、JXLは品質劣化なしに大規模なJPEGライブラリをアーカイブするための唯一の実用的なフォーマットとなります——これは脚注ではなく、実際の意思決定基準です。

圧縮率：勝者はコンテンツによって異なる

ロッシー写真圧縮の低〜中品質域ではAVIFが優位であり、高品質域・非写真系またはフラットグラフィックコンテンツ、そしてロスレス圧縮ではJPEG XLが優位です。「XはN%小さい」という単一の答えは存在せず、そのような数値を提示する記事はコンテンツ依存の結果を過度に単純化しています。

実用的な内訳は以下の通りです：

• ロッシー写真・中品質域： AVIFは積極的なビットレートでも劣化が柔らかく自然です——JPEG XLのVarDCTモードがレガシーJPEGに似たリンギングやブロッキングを生じさせる箇所でも、AVIFはエッジをぼかしてアーティファクトを隠します。これはAVIFの得意領域であり、最も一般的なWebのユースケースです。
• 高品質域および非写真系コンテンツ： JPEG XLはAVIFと同等以上の性能を発揮します。特にイラスト・ロゴ・スクリーンショット・テキストを多く含むグラフィックにおいて、モジュラーエンコードモードがフラットカラー領域をクリーンに処理します。
• ロスレス： JPEG XLが圧倒的に優位です。ロスレスAVIFは実用的ではなく、PNGをわずかに上回る程度にとどまりますが、ロスレスJXLはPNGと競合し、多くの場合はるかに小さなファイルサイズを実現します。

圧縮率は画像コンテンツと品質設定によって大きく異なります。JXL対AVIFの優位性は特にコンテンツ依存であり、確定した数値はありません。コンテンツライブラリをフォーマットに移行する前に、Squooshで実際のアセットをテストしてください。Squooshはブラウザ上で両フォーマットをエンコードし、他人のベンチマークセットではなく、あなた自身の画像におけるサイズと品質のトレードオフを確認できます。

ブラウザサポート：意思決定の決定的な軸

ブラウザサポートこそが実際にこの判断を左右する軸であり、多くの参考記事が誤って報告するか、古い情報を掲載している部分でもあります。2026年半ば時点で、AVIFはグローバルカバレッジ約93%を持ち、Chrome・Edge・Firefox・Safariでデフォルト有効です。JPEG XLは約15%のカバレッジにとどまり——すべてSafari経由で、部分的サポートに分類されています。

Chromeの経緯は重要です。最もよく引用される3つの記事のうち2つが誤って報告しているためです。正確なタイムラインは以下の通りです：

Chromeが「JPEG XLを廃止した」という広く流布した主張は、現在では時代遅れです。ChromiumはこのフォーマットのObsolete指定を撤回し、C++のlibjxlではなく新しいRustベースのデコーダを使用してデコードを再統合しました。しかし再統合は出荷と同義ではありません。現在の安定版チャンネルでは、ChromeのJXLデコードはデフォルトで無効のままであり、chrome://flags/#enable-jxl-image-formatから手動で有効化する必要があります。FirefoxはNightlyビルドにimage.jxl.enabledプリファレンスの背後でJXLコードを保持していますが、リリースビルドにはコンパイルされておらず、出荷タイムラインも公表されていません。

これを配信の意思決定に翻訳すると、多くの参考記事が示唆しながら明確に述べていない部分が見えてきます。現時点でJXLファーストの<picture>要素を使用すると、約85%のユーザーにはAVIFまたはJPEGが配信されます。7人に1人のユーザーにJXLを届けるために3種類のフォーマットをエンコード・保存することになり——しかもそのリーチはSafari限定の部分サポートです。これがJXLファーストを今すぐ採用することの実際のコストであり、Chromeがデフォルトでこのフォーマットを有効にして初めて回収できます。

エンコードコストとプログレッシブレンダリング

JPEG XLはAVIFよりも高速にエンコードでき、プログレッシブデコードをネイティブサポートしています。一方、AVIFのエンコードはCPU負荷が高く、真のプログレッシブモードはありません。どちらの違いも運用上重要です——一方はビルドパイプラインに、もう一方はユーザーの知覚的なロード時間に影響します。

AVIFエンコードがほとんどのパイプラインのボトルネックになる

AV1リファレンスエンコーダ（libaom-av1）を使用したAVIFエンコードは、典型的な画像パイプラインにおける最も遅い処理です。同等の知覚品質では、JPEG XLよりも1枚あたりのエンコード時間が大幅に長くなります。手作業で1枚のヒーロー画像を変換する場合は無視できる差ですが、デプロイのたびに数百枚のプロダクト画像を処理するCIジョブでは、実際の制約となります。エンコード時間は画像数に比例してスケールし、AV1エンコーダは設計上、計算コストが高いためです。

Node.jsパイプラインにおける実践的な対策：

• AVIFおよびJXLのエンコードには、libvipsをラップしたSharpを使用してください。qualityとeffortのコントロールが公開されており、エンコード時間と出力サイズのトレードオフを調整できます。
• デフォルトで最大effortでエンコーダを実行するのではなく、effort/speedの設定をチューニングしてください——高effortのAVIFエンコードは、大きな時間コストに対してわずかなファイルサイズ削減しかもたらしません。
• ワーカースレッドまたはCPUコアをまたいで並列化するか、変換をオンザフライでエンコードするCDNにオフロードしてビルドをブロックしないようにしてください。

const sharp = require("sharp");

// AVIF: `effort`を下げることで、CIエンコードを大幅に高速化（サイズはわずかに増加）
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXLは同等の品質でより高速にエンコード（libjxl対応ビルドが必要）
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

インストールされたsharpビルドのフォーマット対応状況はsharp.formatで確認してください——JXLサポートはバンドルされたlibvips/libjxlに依存しており、すべてのディストリビューションで保証されているわけではありません。

プログレッシブデコードは知覚的なLCPに影響する

JPEG XLはネイティブのプログレッシブデコードをサポートしています。ブラウザはデータが届き次第、低品質版の画像を即座にレンダリングし、データの受信に伴って鮮明化していきます。AVIFには真のプログレッシブモードがないため、大きなAVIF画像は完全に描画されるか、まったく描画されないかのどちらかです。低速な接続環境では、これがLargest Contentful Paint（LCP）の遅延として顕在化します——ファイル全体が届くまでヒーロー画像のスロットが空白のままになります。

これはセッションリプレイで直接確認できる問題のクラスです。画像の多いページでは、制約のある接続環境において、ヒーロー画像のスロットが大きな画像のダウンロード全体を通じて空白のままになり、LCPのタイムスタンプはファイルが完全に描画された瞬間に固定されます。JXL方式のプログレッシブデコードは、まさにその失敗パターンに対処します——低品質な画像が早期に表示されて徐々に鮮明化するという動作は、低速ネットワーク上の実際のユーザーにとって重要な知覚的パフォーマンスの挙動であり、ペイロードサイズとプログレッシブレンダリングがLCPのレバーであって、見た目上の好みではない理由です。

意思決定フレームワーク：X を採用する条件

公開Web向けプロダクションでは、WebPとJPEGのフォールバックを<picture>で組み合わせてAVIFを採用してください。JPEG XLは特定の限定されたケース——ロスレスまたはアーカイブワークフロー、非写真系画像ライブラリ、Safariユーザーが多いオーディエンス、品質劣化なしに再圧縮したい大規模JPEGアーカイブ——で活用してください。

AVIFを採用する場合：

• 今すぐ幅広いカバレッジが必要な公開向けプロダクションサイトを運営している。
• アセットが主に写真系またはミックスコンテンツである。
• ネイティブサポートを持つCMSまたはCDNを使用している——AVIFはWordPressではWP 6.5（2024年4月）からネイティブサポートされており、主要CDNはオンザフライでエンコードします。
• 4つ目のフォーマットバリアントを管理することなく、JPEG/WebPに対して測定可能なLCP改善を求めている。

JPEG XLを活用する場合：

• 大規模なJPEGアーカイブを管理しており、ロスレス再圧縮を求めている——JXLにトランスコード（約20%削減）し、元ファイルをバイト単位で復元できる。
• コンテンツが主に非写真系：イラスト・ロゴ・図表・スクリーンショット。
• オーディエンスがSafari中心で、ヘッドレスまたはカスタム構成で<picture>マークアップを完全にコントロールできる。
• ChromeがJXLをデフォルト有効にする時点を見据えた先進的な配信を構築している。

2026年半ば時点でJPEG XLはWordPressのネイティブアップロードサポートがなく、これによりAVIFが実用的なCMSの選択肢として強化されます。

正確で最新の<picture>スニペット

<picture>要素では、ブラウザはドキュメント順に<source>エントリを評価し、サポートする最初のtypeを選択します。いずれも一致しない場合は<img>にフォールバックします。したがって順序は見た目の問題ではなく、選択アルゴリズムそのものです。優先度の高い順にフォーマットを列挙し、<img>フォールバックはWebPではなく、すべての環境でサポートされているJPEGにしてください（WebPは独自のMIMEタイプを持つため、専用の<source>エントリが必要です）。

<picture>
  <!-- JXL優先：Safari 17+（部分的）のみに配信。2026年半ば時点でChromeはフラグオフ -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF：~93%カバレッジ、ほぼすべてのトラフィックを担うメインティア -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP：AVIFより前のChrome/Firefoxをカバー -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG：無条件フォールバック。常にレンダリングされるsrc -->
  <img src="hero.jpg" alt="説明テキスト" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

この4ティアスタックを正直に評価すると、現時点ではSafari限定のマイノリティにJXLを届けるために4種類のエンコードバリアントが必要です。オーディエンスがSafari中心でなく、JXLのアーカイブ用途もない場合は、最初の<source>を省略して3ティアのAVIF/WebP/JPEGバージョンを採用してください——ほぼすべてのトラフィックをカバーしつつ、ビルドと保存が必要なフォーマットを1つ減らせます。JXLのソースはChromeがフラグを切り替えたとき——それ以前ではなく——に追加してください。

推奨が変わるタイミングのシグナル

JPEG XLをプライマリ配信フォーマットにする実際のトリガーは、Chromeがchrome://flags/#enable-jxl-image-formatをデフォルトオンで出荷することです。それまでは、カバレッジの数字——JXL約15%（Safari限定・部分的）対AVIF約93%——により、AVIFが公開Web向けプロダクションにおける唯一の合理的なプライマリフォーマットであり続けます。監視する価値のある具体的なシグナルは以下の通りです：

• Chrome Platform StatusのJPEG XLエントリが「フラグ付き」から「出荷済み/デフォルトオン」に変わること。
• caniuse.com/jpegxlのフルサポートカバレッジが実用的な閾値を超え、部分的サポートの指定がなくなること。
• FirefoxがJXLをNightlyからリリースビルドに移行すること。
• 主要CDNが画像パイプラインでJXL変換をデフォルト有効にすること。

これらのいずれかが実現した時点で、JXLファーストの<picture>スタックは投機的なコストではなくなり、デフォルトの推奨となります。そして上記のフレームワークは逆転します。

まとめ

今すぐAVIFを採用し、JPEG XLに向けた<picture>マークアップを準備しておいてください。AVIFは現時点でユーザーに届くフォーマットであり、ツールとCMSサポートも充実しています。JPEG XLは技術的な優位性とロスレスアーカイブおよびJPEG再圧縮における適切なツールとしての地位を持ちますが、公開Web向けのケースはChromeがデフォルトで有効化することに完全に依存しています。アセットをAVIFに変換し、WebPとJPEGのフォールバックを追加して、Chrome Platform Statusのエントリを監視してください——そのフラグがデフォルトオンになる日が、JXLをリードソースとして再検討すべき日です。

よくある質問

同じpicture要素にAVIFとJXLのソースを両方配置すると、ストレージと帯域幅が2倍になりますか？

ストレージは増加しますが、リクエストごとの帯域幅には影響しません。列挙するフォーマットバリアントごとにエンコード済みファイルの保存が必要なため、JXL・AVIF・WebP・JPEGの4ティアスタックでは1枚の画像につき4つのファイルを保存することになります。ブラウザはサポートする最初のソースのみをダウンロードし、複数のバリアントを同時にダウンロードすることはないため、帯域幅への影響はありません。JXLファーストスタックの実際のコストは、ダウンロードの重複ではなく、Safari限定のマイノリティに届けるための追加エンコードとストレージです。

AVIFをJPEG XLに変換する際、元ファイルから再エンコードせずに変換できますか？

いいえ、品質劣化なしには変換できません。JPEG XLのロスレストランスコードはJPEGソース固有の機能であり、AVIFやWebPには適用できません。既存のJPEGをJXLにラップしてバイト単位で復元することは可能ですが、AVIFとWebPはロッシーフォーマットであり、同様の可逆的な変換パスは存在しません。AVIFをJXLに変換するには、すでに圧縮されたAVIFをデコードして再エンコードする必要があり、アーティファクトが累積します。常にロスレスの元ファイルを保持しておくことで、任意のフォーマットへクリーンに再エンコードできます。

AVIFのヒーロー画像はJPEGよりファイルサイズが小さいのに、なぜLargest Contentful Paintが改善されないのですか？

AVIFには真のプログレッシブデコードがないため、大きなAVIF画像は低品質プレビューを先に表示することなく、ファイル全体が届いて初めて描画されます。低速な接続環境では、ダウンロード全体を通じてヒーロー画像のスロットが空白のままになり、LCPのタイムスタンプは最終的な描画の瞬間に固定されます。ファイルサイズが小さくても、この「全か無か」の挙動は変わりません。JPEG XLのプログレッシブデコードは段階的に鮮明化するため、バイト数が同程度でも知覚的なロードが改善されます。

AVIFとJPEG XLの両方をサポートするブラウザは、最初に列挙されたソースを選択しますか？

はい。picture要素は、ブラウザがサポートするtypeアトリビュートを持つ最初のソースを、ファイルサイズやフォーマット性能に関係なく、ドキュメント順に評価して選択します。AVIFより前にJXLを列挙した場合、両方をサポートするSafariビルドはJXLを配信します。順序を逆にするとAVIFが配信されます。ブラウザは品質や重みを比較しないため、ソースの順序が選択メカニズムです。優先するフォーマットを最初に配置し、すべての環境でサポートされるJPEGのimgフォールバックで締めくくってください。