次世代画像フォーマットの展望 - JPEG XL と WebP2 が変える未来
次世代画像フォーマットの全体像 - なぜ新しいフォーマットが必要なのか
JPEG が標準化された 1992 年から 30 年以上が経過し、画像圧縮技術は飛躍的に進歩しました。現在の Web では、JPEG の後継として複数の次世代フォーマットが競合しています。WebP (2010 年)、AVIF (2019 年)、JPEG XL (2022 年) がその代表格です。
次世代フォーマットが求められる背景には、モバイルトラフィックの爆発的増加があります。2024 年時点で Web トラフィックの 60% 以上がモバイルデバイスからのアクセスであり、帯域幅の制約が厳しい環境で高品質な画像を配信する必要性が高まっています。JPEG と比較して 30-50% のファイルサイズ削減は、ページ読み込み時間の短縮と通信コストの削減に直結します。
次世代フォーマットに求められる要件:
- JPEG を大幅に上回る圧縮効率 (同品質で 30% 以上のサイズ削減)
- 可逆・非可逆の両方をサポート
- アルファチャンネル (透過) のネイティブサポート
- HDR (High Dynamic Range) と広色域のサポート
- プログレッシブデコード (段階的な表示)
- 高速なエンコード・デコード性能
しかし、フォーマットの優劣は単純な圧縮率だけでは決まりません。エコシステムの成熟度、ブラウザ対応、ツールチェーンの充実度、そして既存資産との互換性が実用上の決定要因となります。さらに、画像フォーマットの選択は SEO にも影響します。Google は Core Web Vitals のスコアをランキング要因として使用しており、次世代フォーマットによるファイルサイズ削減は LCP (Largest Contentful Paint) の改善に直結します。
JPEG XL の技術的特徴 - JPEG の正統後継を目指す万能フォーマット
JPEG XL (ISO/IEC 18181) は JPEG 委員会が策定した次世代フォーマットで、既存の JPEG を完全に置き換えることを目標に設計されています。Google の PIK と Cloudinary の FUIF を統合して開発され、2022 年に正式標準化されました。
JPEG XL の主要な技術的優位性:
- JPEG からのロスレス変換: 既存の JPEG ファイルを品質劣化なしで JPEG XL に変換でき、平均 20% のサイズ削減が得られます。さらに、JPEG XL から元の JPEG にビット単位で完全復元が可能です。これは数十億枚の既存 JPEG 資産を持つ組織にとって極めて重要な機能です
- プログレッシブデコード: ファイルの先頭部分だけで低解像度のプレビューを表示し、データの到着に応じて段階的に品質が向上します。JPEG のプログレッシブモードよりも柔軟で、任意の解像度・品質レベルでの中間表示が可能です
- 超高解像度対応: 最大 1,073,741,823 x 1,073,741,823 ピクセルまでサポート。衛星画像や医療画像など、超高解像度が必要な分野にも対応
- HDR と広色域: PQ (Perceptual Quantizer) と HLG (Hybrid Log-Gamma) の両方の HDR 転送関数をサポート。色深度は最大 32 bit 浮動小数点
圧縮性能は JPEG と比較して非可逆で 60% 以上、可逆で 35% 以上のサイズ削減を実現します。AVIF と同等かそれ以上の圧縮効率を持ちながら、エンコード速度は AVIF の 5-10 倍高速です。デコード速度も JPEG と同等レベルで、リアルタイム表示に支障がありません。
リファレンス実装の libjxl はオープンソースで提供されており、C++ で書かれた高性能なエンコーダ・デコーダが利用可能です。
JPEG XL のブラウザ対応問題 - Chrome の撤退と今後の展望
JPEG XL の最大の課題は、ブラウザ対応の不確実性です。Chrome は 2022 年にフラグ付きで JPEG XL サポートを実装しましたが、2023 年 10 月に「十分なエコシステムの関心が得られなかった」として実験的サポートを削除しました。この決定は Web 開発コミュニティで大きな議論を呼びました。
2025 年時点のブラウザ対応状況:
- Safari: iOS 17 / macOS Sonoma 以降で完全サポート。Apple のエコシステムでは標準利用可能
- Chrome: サポートなし。再導入の公式予定なし
- Firefox: フラグ付きで実験的サポート (
image.jxl.enabled)。デフォルト有効化の時期は未定 - Edge: Chrome と同じ Chromium ベースのためサポートなし
Chrome の不採用は JPEG XL の普及にとって致命的な障壁です。デスクトップブラウザの約 65% を Chrome が占めるため、Web 配信用途では JPEG XL を主要フォーマットとして採用することは現時点では困難です。ただし、Apple のエコシステム (Safari, iOS アプリ) やネイティブアプリケーション、画像アーカイブ用途では積極的に採用が進んでいます。
Web 配信で JPEG XL を使う場合は、<picture> 要素でフォールバックを設定する必要があります。Accept ヘッダーによるコンテンツネゴシエーションと組み合わせ、対応ブラウザにのみ JPEG XL を配信する CDN レベルの最適化が現実的なアプローチです。Cloudflare や Fastly などの CDN は JPEG XL の自動変換機能を提供し始めています。
WebP2 の開発状況 - WebP の後継は実現するのか
WebP2 は Google が WebP の後継として開発を進めていた次世代フォーマットです。AV1 動画コーデックの技術を静止画に応用し、WebP を大幅に上回る圧縮効率を目指していました。しかし、2023 年後半から開発の進捗が大幅に鈍化しており、プロジェクトの将来は不透明な状況です。
WebP2 の設計目標 (開発中の仕様):
- WebP と比較して 30% 以上の圧縮効率向上
- AV1 のイントラフレーム予測技術を活用した高度な空間予測
- 可逆・非可逆の統合フォーマット
- アニメーションのネイティブサポート
- 10 bit / 12 bit の色深度サポート
技術的には、AV1 の予測モードを静止画に最適化し、ブロックサイズの柔軟な選択 (4x4 から 64x64) と方向性予測 (56 方向) により、WebP の VP8 ベースの予測を大幅に上回る圧縮効率を実現する設計でした。
WebP2 の現状と課題: Google の公式リポジトリ (libwebp2) は 2024 年以降ほとんど更新されておらず、実質的に開発が停滞しています。Google が AVIF (AV1 ベース) のエコシステム構築に注力していることから、WebP2 が正式リリースされる可能性は低いと見られています。AVIF が WebP2 の設計目標の多くを既に達成しているため、Google にとって WebP2 を別途リリースする動機が薄れたと考えられます。
Web 開発者の観点からは、WebP2 を待つよりも AVIF への移行を進める方が現実的です。AVIF は Chrome、Firefox、Safari のすべてでサポートされており、エコシステムも急速に成熟しています。
AVIF の現在地 - 実用段階に入った AV1 ベースフォーマット
AVIF (AV1 Image File Format) は AOM (Alliance for Open Media) が策定した画像フォーマットで、AV1 動画コーデックのイントラフレーム符号化を静止画に適用したものです。2024-2025 年時点で最も実用的な次世代フォーマットとして、Web 配信での採用が急速に拡大しています。
AVIF の圧縮性能: JPEG と比較して同品質で 50% 以上のファイルサイズ削減を実現します。WebP と比較しても 20-30% の追加削減が得られます。特に低ビットレート (高圧縮) 領域での品質維持に優れ、サムネイルや帯域幅が制約される環境で威力を発揮します。
ブラウザ対応状況 (2025 年):
- Chrome 85+ (2020 年 8 月〜): 完全サポート
- Firefox 93+ (2021 年 10 月〜): 完全サポート
- Safari 16.1+ (2022 年 10 月〜): 完全サポート
- Edge 85+ (2020 年 8 月〜): 完全サポート
主要ブラウザすべてが AVIF をサポートしており、グローバルカバレッジは 95% を超えています。Can I Use のデータによると、AVIF 非対応ブラウザのシェアは 5% 未満まで低下しています。
AVIF の弱点: エンコード速度が遅いことが最大の課題です。JPEG の 10-50 倍、WebP の 5-20 倍の時間がかかります。リアルタイムエンコードが必要な場面 (ユーザーアップロード画像の即時変換など) では、事前エンコードまたは非同期処理が必須です。また、最大解像度が 8,192 × 4,352 ピクセルに制限されるため (タイリングで回避可能)、超高解像度画像には不向きです。プログレッシブデコードも標準ではサポートされていません。
移行戦略 - 次世代フォーマットへの段階的な移行アプローチ
次世代フォーマットへの移行は、一度にすべてを切り替えるのではなく、段階的に進めることが推奨されます。既存の画像資産との互換性を維持しながら、対応ブラウザに最適なフォーマットを配信する戦略が現実的です。
Phase 1: マルチフォーマット配信の基盤構築
HTML の <picture> 要素を使い、ブラウザの対応状況に応じてフォーマットを出し分けます。
<picture> <source srcset="image.avif" type="image/avif"> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="説明"></picture>
CDN レベルでの自動変換も有効です。Cloudflare Polish、imgix、Cloudinary などのサービスは、Accept ヘッダーを解析して最適なフォーマットを自動配信します。
Phase 2: ビルドパイプラインの整備
画像アセットのビルド時に複数フォーマットを自動生成する仕組みを構築します。Sharp (Node.js)、libvips、ImageMagick などのライブラリで AVIF、WebP、JPEG の 3 フォーマットを生成し、HTML テンプレートで自動的に <picture> 要素を出力します。
Phase 3: JPEG XL の条件付き採用
Safari ユーザーが多いサービスや、ネイティブアプリでは JPEG XL の採用を検討します。既存 JPEG からのロスレス変換による即座のサイズ削減は、大量の画像アーカイブを持つサービスにとって魅力的です。Chrome の対応状況を注視しつつ、将来的な全面採用に備えてエンコードパイプラインを準備しておくことが賢明です。
現時点での推奨: Web 配信では AVIF を第一候補、WebP をフォールバック、JPEG を最終フォールバックとする 3 段構成が最も安全かつ効果的です。