AVIF 導入ガイド - ブラウザ対応状況とフォールバック戦略の実践
AVIF とは何か - AV1 動画コーデックから生まれた画像フォーマット
AVIF (AV1 Image File Format) は、AV1 動画コーデックのフレーム内圧縮技術を静止画に応用した画像フォーマットです。Alliance for Open Media (AOMedia) が策定し、Google、Apple、Microsoft、Netflix、Amazon など主要テック企業が参画するオープンかつロイヤリティフリーの規格です。2019 年に仕様が確定し、2020 年から主要ブラウザでの実装が始まりました。
AVIF の最大の特徴は圧倒的な圧縮効率です。同等の視覚品質で比較した場合、JPEG より 50% 以上、WebP より 20-30% 小さいファイルを生成できます。Netflix の検証では、同じ SSIM スコアを維持しながら JPEG 比で 50%、WebP 比で 25% のファイルサイズ削減を達成しています。
技術的には、AVIF は HEIF (High Efficiency Image File Format) コンテナに AV1 コーデックでエンコードされた画像データを格納する構造です。10 ビット・ 12 ビットの色深度、HDR (PQ/HLG)、広色域 (BT.2020)、アルファチャンネル、アニメーションをサポートし、現時点で最も機能が豊富な画像フォーマットと言えます。
ただし、AVIF にはエンコード速度が遅いという明確な弱点があります。同じ画像を WebP でエンコードする場合の 5-10 倍の時間がかかります。このため、リアルタイムでの画像変換が必要なユースケースでは、事前エンコードまたは CDN のオンザフライ変換機能の活用が必須です。
ブラウザ対応状況 2024 - 実用レベルに達した互換性
2024 年時点で、AVIF は主要ブラウザの大半でサポートされ、グローバルカバレッジは約 93% に達しています。ただし、WebP の 97% と比較するとまだ差があり、フォールバック戦略が必須です。
- Chrome: バージョン 85 以降 (2020 年 8 月〜) で完全対応。アニメーション AVIF は Chrome 93 以降で対応。デスクトップ・モバイルともに安定動作します。
- Firefox: バージョン 93 以降 (2021 年 10 月〜) で完全対応。
image.avif.enabledフラグはデフォルトで有効化されています。アニメーション AVIF も Firefox 113 以降で対応。 - Safari: バージョン 16.1 以降 (2022 年 10 月〜、macOS Ventura / iOS 16.1) で対応。Safari 16.0 では部分的な対応にとどまっていたため、16.1 以降を基準とします。アニメーション AVIF は Safari 17 以降で対応。
- Edge: Chrome と同じ Chromium エンジンのため、バージョン 85 以降で対応。
- Samsung Internet: バージョン 14.0 以降で対応。Android ユーザーの多い地域では重要です。
非対応の主要環境としては、古い iOS (15 以前)、古い macOS (Monterey 以前) の Safari が挙げられます。日本国内では iPhone ユーザーの iOS アップデート率が高いため影響は限定的ですが、企業の社内ブラウザや教育機関の端末では古い OS が残存している場合があります。
Can I Use のデータを自社のアクセス解析と照合し、実際のユーザーベースでの AVIF 対応率を確認することを推奨します。Google Analytics 4 のブラウザレポートで、Safari 16.1 未満のシェアが 5% 以下であれば、AVIF を積極的に採用する判断が妥当です。
picture 要素によるフォールバック戦略の実装
AVIF を安全に導入するための核心技術が、<picture> 要素によるプログレッシブエンハンスメントです。ブラウザが対応するフォーマットを上から順に評価し、最初にサポートされているものを使用します。
基本的なフォールバックチェーンは以下の構造です:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="説明文" width="800" height="600">
</picture>
この構造により、AVIF 対応ブラウザは最も効率的な AVIF を、WebP のみ対応のブラウザは WebP を、どちらも非対応の古いブラウザは JPEG をダウンロードします。ブラウザは type 属性を見て対応可否を判断するため、非対応フォーマットのダウンロードは一切発生しません。
レスポンシブ対応を組み合わせる場合は、各 <source> に srcset と sizes を設定します:
<picture>
<source srcset="img-400.avif 400w, img-800.avif 800w, img-1200.avif 1200w" sizes="(max-width: 600px) 100vw, 50vw" type="image/avif">
<source srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w" sizes="(max-width: 600px) 100vw, 50vw" type="image/webp">
<img src="img-800.jpg" srcset="img-400.jpg 400w, img-800.jpg 800w, img-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, 50vw" alt="説明文" width="800" height="600">
</picture>
この構成では、フォーマット × 解像度の組み合わせで最適な画像が自動選択されます。ファイル数は増えますが、ビルドツールで自動生成すれば運用負荷は最小限です。
AVIF エンコード設定の最適化 - 品質とサイズのバランス
AVIF のエンコード設定は、用途に応じた最適値を選択することが重要です。主要なパラメータとその推奨値を解説します。
- 品質 (Quality / CRF): libavif や avifenc では品質値 0-63 (0 が最高品質) を指定します。Web 配信用途では CRF 23-32 が推奨範囲です。CRF 28 前後が品質とサイズのバランスが最も良い「スイートスポット」です。SSIM 0.95 以上を維持しながら、JPEG 品質 80 相当の画像より 40-50% 小さいファイルが得られます。
- 速度 (Speed): エンコード速度を 0 (最遅・最高圧縮) から 10 (最速・低圧縮) で指定します。Speed 6 が品質と速度のバランスが良く、Speed 4 以下は圧縮率の改善が 5% 未満にとどまる一方でエンコード時間が 3-5 倍になります。バッチ処理では Speed 4、リアルタイム変換では Speed 8 が実用的です。
- 色深度 (Bit Depth): Web 配信では 8 ビットで十分です。10 ビットは HDR コンテンツや写真のグラデーション品質を重視する場合に使用しますが、ファイルサイズが 10-20% 増加します。
- サブサンプリング: 4:2:0 が Web 配信の標準です。4:4:4 はテキストやシャープなエッジを含む画像で色にじみを防ぎますが、ファイルサイズが 30-50% 増加します。
実際のコマンド例として、avifenc を使用する場合: avifenc --min 20 --max 32 --speed 6 --yuv 420 input.png output.avif で、品質範囲 20-32、速度 6、4:2:0 サブサンプリングのエンコードが実行されます。sharp (Node.js) では sharp(input).avif({ quality: 65, speed: 6 }).toFile(output) が同等の設定です。
ビルドパイプラインへの AVIF 統合 - 自動化の実践
AVIF を本番環境で運用するには、ビルドパイプラインに組み込んで自動生成する仕組みが不可欠です。手動変換は現実的ではありません。
Node.js (sharp) による実装: sharp は libvips をバインディングしており、AVIF エンコードに対応しています。ビルドスクリプトで元画像から AVIF、WebP、JPEG の 3 フォーマット × 複数解像度を一括生成します。sharp の AVIF エンコードは libavif を内部で使用しており、品質と速度のバランスが良好です。1000 枚の画像を処理する場合、並列度 4 で約 10-15 分 (Speed 6 設定) が目安です。
Webpack / Vite プラグイン: vite-plugin-image-optimizer や image-minimizer-webpack-plugin を使用すると、ビルド時に自動的に AVIF 変換が実行されます。設定例として、Vite では imageOptimizer({ avif: { quality: 65 }, webp: { quality: 75 } }) のように宣言的に指定できます。
CDN のオンザフライ変換: Cloudflare Images、CloudFront + Lambda@Edge、imgix などの CDN サービスは、リクエスト時に Accept ヘッダーを解析し、AVIF 対応ブラウザには自動的に AVIF を返します。この方式ではビルド時の変換が不要で、オリジンには元画像 (JPEG/PNG) のみを配置すれば済みます。ただし、初回リクエスト時のエンコード遅延 (100-500ms) が発生するため、キャッシュウォームアップの戦略が必要です。
CI/CD での品質検証: AVIF 変換後の品質を自動検証するステップを追加します。dssim (構造的非類似度) で元画像との差分を計測し、閾値 (例: DSSIM 0.001 以下) を超えた場合にビルドを失敗させることで、過度な圧縮による品質劣化を防止します。
AVIF 導入の判断基準と移行ロードマップ
AVIF の導入を検討する際の判断フレームワークと、段階的な移行計画を提示します。
導入すべきケース:
- 画像が多いサイト (EC、メディア、ポートフォリオ) で、帯域幅コストが課題になっている場合
- Core Web Vitals の LCP が画像起因で「要改善」判定を受けている場合
- ユーザーベースの AVIF 対応率が 85% 以上の場合 (アクセス解析で確認)
- ビルドパイプラインに画像処理の自動化が既に組み込まれている場合
慎重に検討すべきケース:
- 画像枚数が少ないサイト (コーポレートサイト等) で、最適化の効果が限定的な場合
- 古い iOS/macOS ユーザーが 10% 以上を占める場合 (教育機関、官公庁向けサイト)
- エンコード時間がビルドパイプラインのボトルネックになる場合 (数万枚規模)
段階的移行ロードマップ:
- Phase 1 (1-2 週間): ヒーロー画像やサムネイルなど、LCP に影響する主要画像のみ AVIF 化。picture 要素でフォールバックを確保。効果測定で LCP 改善を確認。
- Phase 2 (1 ヶ月): ビルドパイプラインに AVIF 自動生成を統合。新規アップロード画像は自動的に AVIF が生成される状態にする。
- Phase 3 (2-3 ヶ月): 既存画像の一括変換。バッチ処理で全画像を AVIF 化し、CDN キャッシュをウォームアップ。
移行の効果測定には、Google Search Console の Core Web Vitals レポートと、RUM (Real User Monitoring) データを併用します。AVIF 導入前後で LCP の 75 パーセンタイル値を比較し、500ms 以上の改善が確認できれば移行は成功と判断できます。