AVIF と WebP：2026 年に使うべき画像フォーマットは？

手早い答え：フォーマットの話題性ではなくパイプラインで選ぶ

2026 年、多くのサイトにとって JPG と PNG からの単一フォーマットの置き換えとして無難なのは WebP です。パイプラインが WebP や JPEG のフォールバックも配信できるなら、AVIF を最初のソースにするのが最良の選択になります。

この後半こそ、AVIF vs WebP の比較記事が飛ばしがちな部分です。ベンチマークで最小の 1 枚を出せる形式が「最良」なのではなく、CMS、CDN、ビルド、閲覧者のブラウザ構成、扱う画像タイプを含めて安定して届けられる形式が最良です。

実務のスタート地点として：

• WebP を使う： シンプルなモダン形式、速いバッチ変換、広い対応、そして古いブラウザ、メールクライアント、CMS プラグイン、アプリ内ブラウザでのトラブルを減らしたいとき。
• フォールバック付きで AVIF を使う： 画像がパフォーマンスの大きなコストになっていて、ビルド時や画像 CDN でエンコードできて、公開前に見た目を確認できるとき。
• JPEG または PNG のフォールバックを残す： 画像が古い Safari / iOS、企業内で固定された環境、クローラー、メールクライアント、外部プラットフォームなど、どこでも動く必要があるとき。

AVIF と WebP を一望する

出自の違い

WebP は Google が開発し、2010 年に公開されました。可逆モードは独自の圧縮方式、非可逆モードは動画コーデック VP8 に基づいています。Google の WebP ドキュメントは、WebP が非可逆・可逆圧縮、透過、アニメーションをサポートし、主要ブラウザでネイティブに扱われることを述べています。

AVIF は AV1 Image File Format の略で、オープンな動画コーデック AV1 に基づく形式です。web.dev では AVIF を、透過やアニメーションのようなウェブ画像で必要とされる機能をカバーし、旧世代フォーマットに比べてバイトあたりの品質を高めることを狙ったラスター画像形式として説明しています。

実務上の違いは「年季」です。WebP はブラウザ、CMS プラグイン、デザインツール、画像ライブラリ、ビルドシステムに根付くまで 10 年以上ありました。AVIF はもはや珍しくはありませんが、遅いエンコーダ、書き出しオプション不足、フォールバックが必要なプラットフォームに出くわす確率は依然として高い形式です。

圧縮効率

同等の見た目品質で比べたとき、AVIF は WebP よりファイルが小さくなることが多く、特に写真画像で顕著です。とはいえ、あらゆる AVIF ファイルが 30 %、40 %、50 % 小さくなるわけではありません。実数はエンコーダ、品質設定、画像内容、そして「同じ品質」の判断基準に依存します。

差が最も出やすいのは：

• 空、肌、影、グラデーションを含む大きなヒーロー写真；
• ギャラリーのように 1 KB の削減が多くの画像で効くケース；
• モバイルページのように転送量削減が LCP と通信量に直結する場面。

一方、差が縮まりやすいのは：

• 小さなサムネイル（リクエストのオーバーヘッドやリサイズのほうが効く）；
• スクリーンショット、UI 画像、鮮明なテキストを含む図解；
• ノイズが多い写真や強いテクスチャの画像；
• 可逆グラフィック（PNG や可逆 WebP のほうが今なお合理的なこともある）。

実サイトでは、「完璧な 1 枚」ではなく代表的なフォルダで検証しましょう。ヒーロー、商品、人物、スクリーンショット、イラスト、サムネイルを含むテストセットが強力です。実際に公開する寸法で、ファイルサイズと見た目の両方を比較してください。

2026 年のブラウザ対応

両者ともに対応は広いものの、まったく同じではありません。2026 年 7 月時点の Can I use によれば、WebP のグローバル利用率対応は約 96.15 %、AVIF は約 93.42 % です。どちらもモダンなウェブ配信で成立する水準ですが、同格というわけではありません。

残りのギャップが特に効いてくるのは：

• 古い iPhone と iPad、特に iOS 15 以前；
• 古いデスクトップ Safari；
• ブラウザバージョンが固定された企業端末；
• アプリ内、キオスク、古い Android WebView などの組み込みブラウザ；
• 通常のブラウザとは違う挙動をするメールクライアントや外部プラットフォーム。

WebP なら、多くのサイトで「WebP + 古いクライアント向け JPEG フォールバック」で乗り切れます。AVIF は、いまでも安全な運用構成として「AVIF → WebP → JPEG または PNG」を残しておくのが無難です。

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="使用中の商品写真">
</picture>

順序が重要です。ブラウザは対応する最初のソースを選ぶため、AVIF 対応ブラウザに AVIF を届けたいなら、AVIF を WebP の前に置く必要があります。

エンコード速度

サイトを実際に運用してみて体感する差が、エンコード速度です。

WebP はローカル変換、バッチツール、CMS ワークフロー、シンプルな静的サイトビルドでも十分速く動きます。AVIF はエンコーダがより小さな結果を探し回るため、体感でずっと遅くなりえます。速い AVIF プリセットもありますが、たいてい圧縮の一部と引き換えです。

これは 4 つの場面で効いてきます：

• 静的ビルド： 画像 30 枚のブログなら問題なし。オリジナル写真 2,000 枚の旅行サイトでは、AVIF 生成がビルド時間の重要なコストになりえます。
• ユーザーアップロード： 即時プレビューを期待される場面では、AVIF のエンコードが待ち時間と CPU コストを増やします。
• サーバーレス関数： 遅い画像エンコードは、タイムアウトやコスト上限に触れやすくなります。
• ローカル作業： 手作業でフォルダをアップロード前に変換するなら、WebP のほうが手数が少なくて済みます。

役立つ経験則：エンコードが 1 回で、小さくなったファイルを何度も配信するなら AVIF。速度、シンプルさ、繰り返し可能なバッチ変換が要るなら WebP。

画像タイプ別の見た目の品質

AVIF と WebP は、サイト内のすべての画像に対する一発の決定ではありません。

発展的な機能

AVIF は WebP が同等に狙っていない機能を備えます。通常の sRGB のウェブ画像では効いてこないかもしれませんが、写真、HDR コンテンツ、高精細ディスプレイのパイプラインでは意味を持ちます。

• 高ビット深度： 一般的な 8 bit のウェブ配信を超える表現が可能。
• HDR と広色域： これらの信号を残すパイプラインとの相性が良い。
• モダンな AV1 系ツール： 効率的なイントラフレーム圧縮を含む AV1 エコシステムを共有できる。

パイプライン全体でこれらを保てないのに、機能目当てで AVIF を選ばないでください。ソースが普通の sRGB JPEG で、CMS がメタデータや色情報を落とす構成なら、実利は結局ファイルサイズであり、HDR 的な魔法ではありません。

ツールチェーンの成熟度

WebP は「地味に成熟した選択肢」で、これは褒め言葉です。ブラウザ、デザインツール、画像ライブラリ、ビルドプラグイン、CMS プラグイン、CDN のいずれでも安定して扱えます。問題が起きても、原因追跡は比較的楽です。

AVIF のサポートも大きく前進しましたが、まだ荒削りな部分に出くわしやすい：

• CMS が AVIF をアップロードできても、すべてのサムネイルサイズを生成しない；
• プラグインが AVIF を生成しても、フォールバック用のマークアップを吐かない；
• CDN が特定プランや Accept ヘッダーの条件付きでしか AVIF を扱えない；
• ブラウザ内エンコードが特定のブラウザだけで失敗する；
• 画像ごとに AVIF を作ることでビルドが遅くなる。

大規模サイトで AVIF に本腰を入れる前に、実際のパイプライン一式を通しで試してください。アップロード、リサイズ、バリアント生成、HTML レンダー、デプロイ、クロール、そして結果を Safari、Chrome、Firefox、ローエンドのモバイル機で開いて確認する、というところまでです。

どちらを選ぶか

2026 年の多くのウェブプロジェクトにとって、WebP は現実的な選択肢です。パイプラインが整っているとき、AVIF はパフォーマンス面の切り札になります。

次のいずれかに当てはまるなら WebP

• ほぼどこでも動くモダンな画像形式が欲しい。
• ローカルまたはブラウザでの高速な変換が必要。
• サイト規模が小さく、画像転送が最大のパフォーマンス課題ではない。
• CMS や EC プラットフォームがきれいな AVIF フォールバックを吐かない。
• スクリーンショット、図解、UI キャプチャ、小さなサムネイルが多い。
• AVIF 対応が不確かなメール、マーケットプレイス、外部プラットフォームへ画像を送る。

次のいずれかに当てはまるなら AVIF（WebP または JPEG フォールバック付き）

• ページ重量や LCP を画像が支配している。
• 大きな写真、ギャラリー、ヒーロー、メディア中心のランディングが多い。
• ビルド時、CDN、オフラインのパイプラインでエンコードできる。
• ツールが AVIF、WebP、JPEG/PNG フォールバックのマークアップを自動生成する。
• 単一のベンチマークではなく、実画像で品質を確認できる。
• 閲覧者の多くがモダンブラウザ。

次のいずれかに当てはまるなら JPEG または PNG を残す

• 古いクライアント、メール、書類、ダウンロードに耐える必要がある。
• 編集やアーカイブ用のマスターが必要。
• 画像がロゴ、アイコン、図、スクリーンショットで、可逆出力が意味を持つ。
• どのみちプラットフォーム側で再圧縮されるアップロードである。

自分のサイトで AVIF と WebP を試す方法

汎用ベンチマーク単体で結論を出さないでください。実際の画像で試すのが基本です。

1. 実物の画像を 10〜20 枚選ぶ。ヒーロー、商品、サムネイル、スクリーンショット、テキスト入り画像。
2. 妥当な品質設定で WebP と AVIF を書き出す。初回比較の目安は WebP 80〜85 前後、AVIF 60〜75 前後。あとは目で調整。
3. 100 % ではなく、実際にレンダリングされる寸法で確認する。
4. 顔、空、グラデーション、生地、商品ラベル、テキスト、シャープなエッジを注視する。
5. 1 枚ではなく、ページ全体の画像重量を比較する。
6. Lighthouse など使い慣れたツールで、前後にパフォーマンス測定を行う。
7. AVIF を無効にしたブラウザや対応していない機器でページを開き、フォールバックのレンダリングも確認する。

サムネイルで数 KB しか縮まないなら AVIF を無理に入れない。LCP のヒーローで数百 KB 減るなら、フォールバック付きで採用する。それが判断の目安になります。

手作業の変換は PhotoTools で

PhotoTools は、サイトへ入れる前にファイルを手元で確認・準備したい場面に向いています。

• 多くのモダンサイトで通用する、ブラウザローカルの手早い書き出しには JPG → WebP コンバーター。
• パイプライン化する前に AVIF 版と WebP 版を比べたいときは JPG → AVIF コンバーター。
• 開けないツール・クライアント・プラットフォームに渡す必要があるときは AVIF から JPG または PNG への変換。

コンバーターはブラウザ内でネイティブの Canvas API を用いて動きます。手早いバッチやアップロードなしのワークフローに便利ですが、大規模サイトの自動 CDN やビルドパイプラインを置き換えるものではありません。

参照した情報源

本記事は 2026 年 7 月 18 日、以下の最新情報にあたって内容を確認しています。Google の WebP ドキュメント、web.dev の AVIF ガイド、Chrome Lighthouse のモダン画像に関するガイダンス、Can I use AVIF、Can I use WebP。