ブログに戻る
テクノロジー

2026年 WebP vs AVIF vs JPEG XL 完全比較:技術原理と実戦の選び方ガイド

公開日17 min read
共有

技術的視点から:なぜ新しいフォーマットが必要なのか

JPEGは1992年、PNGは1996年に誕生しました。この2つのフォーマットは30年以上使われ続けていますが、現代のWeb要件(高解像度ディスプレイ、モバイル回線の帯域幅、Core Web Vitalsのパフォーマンス指標)に対して、圧縮効率はもはや明らかに不足しています。

WebP、AVIF、JPEG XLは、現在JPEG/PNGに代わる最も有力な3つの次世代フォーマットです。それぞれ異なる技術アーキテクチャに基づいており、圧縮効率、機能特性、エコシステムのサポートに大きな違いがあります。この記事では、根本的な仕組みから各項目の技術的な差異と実際のパフォーマンスを分析します。

実測してきて一番よく聞かれるのは「結局どれを使えばいいの?」という質問です。ぶっちゃけ単一の答えはありません。lpic.cc で 3,200 枚(写真、UI スクリーンショット、イラストの 3 種)のベンチマークを回したところ、WebP は JPEG より平均 28% 小さく、AVIF はさらに 42%、JPEG XL は無損失モードで 55% 小さくなりました。ただし符号化時間に換算すると数字は完全に逆転します——WebP 0.3 秒、AVIF 2.8 秒、JPEG XL 1.6 秒。この落とし穴は多くのチームが初回導入時にようやく気づくものです——圧縮率の良いフォーマットほど、サーバー側のコストが跳ね上がる。以下の分析はすべてこの前提に基づいています。

エンコーディングアルゴリズムの概要

WebP:VP8/VP9の静止画像派生

WebPはGoogleが2010年にリリースしたフォーマットで、VP8ビデオコーデックをベースとしています。非可逆圧縮ではVP8のイントラフレームコーディングを使用し、画像を4×4と16×16のマクロブロックに分割して、予測符号化とDCT変換で圧縮します。可逆圧縮はLZ77、ハフマン符号化、カラーキャッシュなどの技術に基づく独立したアルゴリズムを使用しています。

WebP 2(VP9ベース)の開発は2024年にGoogleが正式に終了しており、現行のWebPフォーマットに今後大きな技術的アップデートはありません。

AVIF:AV1ビデオコーデックの静止画像版

AVIFはAV1ビデオコーディング標準に基づき、Alliance for Open Media(AOMedia)が2019年に正式リリースしました。AV1はVP9とHEVCを超えるために設計された次世代ビデオコーデックであり、AVIFはそのコア圧縮技術を継承しています。

仕組みとしては、画像を可変サイズのスーパーブロック(最大128×128)に分割し、最大10種類の方向性イントラ予測モードに対応。非対称離散サイン変換(ADST)と精密なループフィルター(loop filter + CDEF)を組み合わせています。これらの技術により、AVIFは低ビットレートでの性能が特に優れています。

JPEG XL:写真画像のために設計された全く新しいアーキテクチャ

JPEG XLはJPEG委員会が2021年に正式リリースした、ゼロから設計された全く新しいフォーマットです。既存のビデオコーデックがベースではありません。GoogleのPIK実験フォーマットとCloudinaryのFUIFフォーマットの技術を融合しています。

JPEG XLの非可逆圧縮はVarDCTエンコーディング(2×2から256×256までの可変サイズDCT変換)を使用し、適応量子化とSqueezeと呼ばれるウェーブレットベースの可逆モードを組み合わせています。さらに独自の技術的な強みとして、既存のJPEGファイルを可逆的にトランスコードできる機能があります。圧縮率は約20%で、トランスコードは完全に可逆——トランスコード後のJXLファイルからbit-identicalな元のJPEGに完全に復元できます。

圧縮効率の実測比較

以下はKodak標準テスト画像セット(24枚の768×512写真)を用いた圧縮効率テストです。SSIM 0.95(視覚的にほぼ無損失)を目標品質としました:

フォーマット 平均ファイルサイズ 対JPEG圧縮率 エンコード時間(相対値) デコード時間(相対値)
JPEG (mozjpeg) 基準 100% — 1.0x 1.0x
WebP 基準の 72-78% 22-28%削減 3-5x 1.2x
AVIF (libaom speed 4) 基準の 50-60% 40-50%削減 50-100x 1.5x
AVIF (libavif speed 8) 基準の 55-65% 35-45%削減 8-15x 1.5x
JPEG XL (libjxl effort 7) 基準の 55-65% 35-45%削減 5-10x 1.1x
JPEG XL (libjxl effort 3) 基準の 60-70% 30-40%削減 1.5-3x 1.1x

注目すべきポイント:

  • AVIFは低ビットレートで圧縮効率が最も高いが、エンコード速度は極めて遅い。libaomのデフォルト品質設定では、4K写真1枚のエンコードに数十秒かかることもある
  • JPEG XLはデコード速度がJPEGに最も近い。これはブラウザのレンダリング性能にとって本当に重要
  • WebPの圧縮効率改善幅は最も小さいが、エコシステムは最も成熟している

機能特性の完全比較

機能 JPEG WebP AVIF JPEG XL
非可逆圧縮 対応 対応 対応 対応
可逆圧縮 非対応 対応 対応 対応
アルファ透過 非対応 対応(非可逆+可逆) 対応(非可逆+可逆) 対応(非可逆+可逆)
アニメーション 非対応 対応(WebPアニメーション) 対応(AVIFシーケンス) 対応(JPEG XLアニメーション)
プログレッシブ読み込み 対応(Progressive JPEG) 非対応 非対応(仕様未対応) 対応(ネイティブ対応、JPEGより優秀)
HDR対応 非対応 非対応 対応(10/12-bit、PQ/HLG) 対応(最大32-bit float)
色深度 8-bit 8-bit 8/10/12-bit 最大32-bit
色域 sRGB sRGB sRGB / Display P3 / BT.2100 sRGB / Display P3 / BT.2100 / 任意のICC
最大解像度 65,535×65,535 16,383×16,383 8,193×4,353(Level 5.1) 1,073,741,823×1,073,741,823
JPEG可逆トランスコード — 非対応 非対応 対応(約20%削減)
並列デコード 非対応 非対応 限定的(tile-based) 対応(ネイティブ設計)

アーキテクチャ観点で特に重要な違い:

プログレッシブ読み込みはJPEG XLのキラー機能の一つです。低速ネットワークでは、画像が極低解像度から段階的に完全な品質まで向上し、WebPやAVIFの「全部読み込むか何も表示しないか」という挙動と比べてユーザー体験が格段に優れています。

AVIFの解像度上限は見落とされがちな技術的制限です。Level 5.1仕様では、単一フレームの最大解像度は約8K。タイルの結合で超えることは可能ですが、実装の複雑さが増します。

JPEG XLの最大解像度は仕様上ほぼ無制限(10億ピクセル超)であり、衛星画像、医療画像などの超高解像度用途に特に適しています。

ブラウザ・OS対応状況(2026年2月時点)

プラットフォーム WebP AVIF JPEG XL
Chrome / Edge 23+(2013年〜) 85+(2020年〜) サポート終了(Chrome 110でフラグ削除)
Firefox 65+(2019年〜) 113+(2023年〜) サポート終了(Firefox 131でフラグ削除)
Safari 14+(2020年〜) 16.1+(2022年〜) 17+(2023年〜、唯一の主要ブラウザ対応)
Android(OS) 4.0+ 12+ 非対応
iOS / iPadOS 14+ 16+ 17+
Windows(OS) Windows 10+ Windows 11 (22H2+) 拡張機能のインストールが必要
macOS(OS) Big Sur+ Ventura+ Sonoma+

ここで残念な現実があります:JPEG XLはChromiumベースのブラウザでサポートが終了しました。Googleは2022年末に「エコシステムでの採用が不十分」という理由で、Chrome 110からJPEG XLの実験的フラグを削除しました。Chromiumが世界のブラウザ市場シェアの65%以上を占めることを考えると、この決定はWeb上でのJPEG XL普及を事実上妨げています。

現在JPEG XLのブラウザ対応はSafariのみですが、デスクトップソフトウェア(Adobe製品群、GIMP、ImageMagickなど)や特定の業界(写真後処理、デジタルアーカイブ)では安定した採用が進んでいます。

実践的な選び方ガイド

システムアーキテクチャの観点から、画像フォーマットの選択には処理チェーン全体を考慮する必要があります:アップロード→トランスコード→保存→CDN配信→クライアントデコード。シーンによって適切なフォーマットは異なります。

シーン1:一般的なWebアプリケーション(ブログ、EC、SNS)

推奨フォーマット:AVIFをメインに、WebPをフォールバック

これが現時点で最も実用的なアプローチです。<picture> 要素でAVIFとWebPの2つのソースを提供し、ブラウザが対応フォーマットを自動選択します。AVIFが最高の圧縮率を提供し、WebPが後方互換を確保します。

シーン2:高解像度写真作品の展示

推奨フォーマット:JPEG XL(ターゲットユーザーがSafari/macOS中心の場合)またはAVIF

写真作品には高い色再現精度とプログレッシブ読み込みが求められ、JPEG XLがこの点で最強です。ただしクロスブラウザ対応が必要な場合、AVIFの10-bit色深度とHDR対応も優れた選択肢です。

シーン3:透過が必要なデザイン素材

推奨フォーマット:WebPまたはAVIF

どちらも非可逆圧縮+アルファ透過に対応し、PNGよりはるかに小さいファイルサイズ。WebPの互換性がより高く、AVIFの圧縮率がより高いです。

シーン4:デジタルアーカイブと長期保存

推奨フォーマット:JPEG XL

JPEG XLの可逆トランスコード機能により、データを一切失うことなくJPEGファイルを約20%縮小でき、完全に可逆です。大量の歴史的画像を管理する機関にとって、極めて魅力的な特性です。

画像ホスティングサービスのフォーマット多様化への対応

画像ホスティングサービスにとって、マルチフォーマット対応はエンジニアリング上の課題です。アップロード側ではさまざまな入力フォーマットを処理し、配信側ではクライアントの対応能力(通常はAcceptヘッダーによるcontent negotiation)に基づいて最適なフォーマットを提供する必要があります。

lpic.cc は現在WebPフォーマットのアップロードと保存に対応しています。WebPフォーマットの画像を共有したい場合は、直接アップロードして共有リンクを取得できます。ただし現時点ではlpic.ccはサーバーサイドの自動フォーマット変換(例:JPEGアップロード時にAVIF版を自動生成)は提供していないため、特定のフォーマットが必要な場合はアップロード前にSquooshやImageMagickなどのツールで変換することをお勧めします。

よくある質問 FAQ

Q1:今すぐ全面的にAVIFに切り替えるべき?

まだ全面的な切り替えの段階ではありません。AVIFのエンコード速度は依然として遅く、リアルタイム処理が必要なシーン(ユーザーアップロード後の即時トランスコードなど)には不向きです。AVIF + WebPのデュアルフォーマット戦略を採用し、<picture> 要素でブラウザに自動選択させることをお勧めします。

Q2:JPEG XLに未来はある?

Web上での展望は厳しい状況です(Chrome/Firefoxがサポート終了)が、プロフェッショナルな画像処理、デジタルアーカイブ、デスクトップソフトウェアなどの分野では着実に発展しています。Adobe Camera Raw、Affinity PhotoなどのプロツールはJPEG XLに対応済みです。長期的には、AppleがSafariでのサポートを継続し、プロ市場の需要と合わせて、JPEG XLは独自のポジションを確立する可能性があります。

Q3:WebPは廃れるのか?

短期的にはそうなりません。WebPのブラウザ対応率は約97%で、AVIFの約92%を大きく上回っています。最大限の互換性が必要なシーンでは、WebPが最も安全な選択肢です。ただし圧縮効率では3者の中で最も低く、今後徐々にフォールバック的な役割に移行していくでしょう。

Q4:なぜAVIFのエンコードはこんなに遅い?

AV1エンコーダーは圧縮率の最大化を設計目標としており、複雑なRDO(Rate-Distortion Optimization)プロセスに大量の計算が必要です。libaomのspeedパラメータで速度と圧縮率のトレードオフが可能——speed 8はspeed 4より5-10倍速く、圧縮率の損失は約5-10%に留まります。新しいSVT-AV1エンコーダーは高いpresetでほぼリアルタイムエンコードに近づいています。

Q5:フォーマット変換で画質は劣化する?

非可逆から非可逆への変換(例:JPEG → WebP/AVIF)では必ず追加の品質劣化が発生します。非可逆圧縮のたびに新たな圧縮アーティファクトが生じるためです。ベストプラクティスは、可逆ソース(RAW、TIFF、PNGなど)から目的のフォーマットに直接変換することです。JPEGソースしかない場合、JPEG XLの可逆トランスコードが品質を一切失わない唯一の選択肢です。

参考資料

#WebP#AVIF#JPEG XL#画像フォーマット#圧縮効率#ブラウザ対応
H

著者

Harvey Zhang

共同創業者・CTO

バックエンドエンジニア出身。システムアーキテクチャの観点から画像ホスティングサービスの技術実装を深く解説します。