風景写真をWebに載せるとき、AVIF・JPEG・WebP のどれを選ぶかという話です。画像の配信を組む人に向けて書いています。
先に結論を書きます。原画と区別がつかない品質で配信するなら、AVIF 以外に選択肢がありません。逆に品質を1段落とすと、AVIF と JPEG の差は2割まで縮みます。差が開くのは高品質域だけでした。
測った条件はこうです。
- 素材は Lorem Picsum 経由で取得した写真から、目視で風景だけを選んだ10枚。都市のスナップ、車、動物、人物は圧縮の傾向が変わるため外しました
- いずれも 1600x1067 に揃えて PNG に展開し、そこから各形式へ変換
- エンコーダは ffmpeg 7.1.1 の libaom-av1、cwebp、cjpeg（libjpeg-turbo 3.2.0）
- 品質は JPEG と WebP が q70 から q100、AVIF が crf1 から crf30
- 測定日は 2026-09-06、macOS 26
画質は SSIM ではなく3つの指標で測っています
比較記事でよく使われる SSIM を、今回は使っていません。同じデータを SSIM で測ると、他の指標と違う順位が出たためです。どちらが正しいかを自分で決められなかったので、知覚品質に寄せて作られた指標を3つ使い、答えが揃うかどうかを見ることにしました。
- SSIMULACRA2（libjxl 付属）。100 が完全一致で、90 が「原画と1対1で見比べても区別できない」、70 が「高品質」と定義されています
- butteraugli（Google 製、libjxl 付属）。0 が完全一致で、値が小さいほど近い。1.0 を下回ると知覚的にほぼ同一とされます
- VMAF（Netflix 製）。0 から100 で、大きいほど近い
3つは開発元も設計も別です。同じ順位が出れば、指標ひとつの癖に引きずられた結論ではないと判断できます。
高品質域に到達できるのは AVIF だけでした
まず、各形式が最高品質の設定で到達できたスコアを並べます。JPEG と WebP は q100、AVIF は crf1 のときの値です。90 が「原画と区別できない」水準です。
JPEG q100 WebP q100 AVIF crf1
写真1 85.7 83.3 94.2
写真2 90.1 87.4 95.8
写真3 88.7 84.4 93.1
写真4 88.5 85.6 94.0
写真5 86.6 85.3 94.9
写真6 90.3 88.3 95.8
写真7 90.7 87.9 94.4
写真8 88.6 85.7 92.7
写真9 88.5 86.0 92.8
写真10 88.7 86.4 96.0
90に到達 3枚 / 10 0枚 / 10 10枚 / 10WebP は10枚すべてで90に届きません。最高でも88.3で、品質を上げきってもそこで頭打ちになります。JPEG は3枚だけ到達し、残る7枚は85.7から88.7の範囲で止まりました。AVIF は10枚とも92.7以上に届いています。
butteraugli でも同じ形になりました。こちらは値が小さいほど原画に近く、1.0 が目安です。
最良値 最悪値 1.0以下だった枚数
JPEG 0.74 3.15 1枚 / 10
WebP 1.33 3.76 0枚 / 10
AVIF 0.35 0.46 10枚 / 10AVIF は10枚とも0.35から0.46の狭い範囲に収まり、WebP は最も良い写真でも1.33でした。
到達できた条件でのファイルサイズを比べると、AVIF が10枚すべてで最小になります。JPEG が90に届いた3枚では、AVIF のほうが平均1.96倍小さくなりました。たとえば写真6は JPEG が 1,280,901 バイト、AVIF が 621,293 バイトです。
1枚の写真について、品質を振ったときの曲線を描くとこうなります。
3本とも途中で寝ます。ファイルサイズをいくら増やしても、そこから先はスコアが伸びません。寝る高さが形式ごとに違い、90の線を越えられるのは AVIF だけでした。JPEG と WebP は、品質設定を上げきってもその手前で止まります。
品質を1段下げると差は2割まで縮みます
SSIMULACRA2 が70以上、こちらは全形式が10枚とも到達しました。
JPEG WebP AVIF
写真1 314,127 301,754 255,681
写真3 223,552 197,776 155,677
写真8 156,186 100,960 77,582
写真10 396,807 404,924 320,991
到達 10枚 / 10 10枚 / 10 10枚 / 10AVIF が最小なのは変わりませんが、差は平均1.24倍です。高品質域の1.96倍と比べると、はっきり縮んでいます。
VMAF を95以上で揃えたときは、10枚のうち AVIF が8枚、JPEG が2枚で最小になりました。差も平均1.12倍です。3つの指標で答えが完全に一致したのは高品質域だけで、中品質域では指標によって勝者が入れ替わります。
ここまでは「品質を揃えたときのサイズ」を見てきました。逆にサイズを揃えて画質を見ると、差はこう出ます。300KB前後に揃えた3枚から、崖の上にいる人のあたりを切り出しました。
JPEG は岩肌がブロックに割れ、人の形が溶けています。AVIF は同じ容量で人の輪郭と岩の質感が残りました。スコアの差（66.9 対 79.9）が、そのまま見た目の差として出ています。
なぜ品質を上げるほど差が開くのか、その仕組みまでは分かりませんでした。JPEG が8x8のブロックに分けて変換する古い設計であることと関係がありそうですが、確かめていないので理由の欄は空けておきます。
エンコードは遅い。ただし既定値のせいでもある
2000x1682 の写真を1枚変換したときの所要時間です。
- JPEG（cjpeg q75）: 0.029秒
- WebP（cwebp q80）: 0.353秒
- AVIF（ffmpeg + libaom、既定設定）: 6.904秒
JPEG の238倍かかっています。ただしこの数字には理由があって、libaom の -cpu-used の既定値が 1、つまり最も時間をかける側に寄っているためです。ここを 6 にすると 0.9秒まで落ちました。
そのとき出力がどうなるかも測りました。
cpu-used=1 286,965 bytes 12.6秒
cpu-used=6 285,859 bytes 1.0秒サイズは0.4%大きくなるだけで、時間は12分の1です。既定のまま使うと、ほとんど得るものがない待ち時間を払うことになります。ユーザー投稿のように枚数が積み上がる用途では、ここを触らないと処理が詰まります。
なお macOS 標準の sips でも AVIF を書けて、こちらは0.284秒でした。ただし品質と圧縮率は libaom を細かく指定した場合と異なります。
表示できないブラウザにどう備えるか
AVIF を表示できるブラウザは、caniuse の集計で 94.65% です。Chrome 85、Firefox 93、Safari 16.4、iOS Safari 16.0、Edge 121 以降が対応しています。
Edge だけ番号が飛び抜けて遅く、経緯も変わっています。116 と 117 では --enable-features=msEdgeAVIF を付ければ有効にできました。ところが118 から120 でそのフラグごと消えて完全に非対応になり、121 で改めて対応しています。一度引っ込めた理由について、公表された説明は見つけられませんでした。
ポリフィルで埋めるのは諦めてください。npm で公開されている avif.js は v0.2.0 で、最終更新が2019年4月です。Chrome が AVIF に対応した2020年より前から止まっています。画像のデコードは、本来ブラウザのネイティブコードが担う処理です。JavaScript や wasm に置き換えると、デコーダ本体の転送量とデコード時間が AVIF で削ったバイト数を上回ります。維持されないのは自然な結果です。
残る手段は <picture> によるフォールバックです。実際に書いて確かめました。
<picture>
<source srcset="photo.avif" type="image/avif">
<img src="photo.jpg" width="600" alt="">
</picture>Chrome で開いてネットワークを見ると、取得されたのは photo.avif だけで、photo.jpg へのリクエストは発生しません。type を対応しない値に差し替えて開き直すと、今度は photo.jpg だけが取得され、AVIF は読まれませんでした。2枚用意しても、閲覧者がダウンロードするのは1枚だけです。
代償はストレージとビルド時間です。同じ画像を2つの形式で持ち、変換も2回走ります。
どれを選ぶか
品質をどこに置くかで答えが変わります。
- 原画と区別がつかない品質が要る（写真を売る、作品として見せる、拡大して見られる）: AVIF 一択。JPEG は10枚中7枚で到達できず、届いた3枚でも約2倍大きい。WebP は10枚とも到達しない
- 一般的な閲覧用（記事の挿絵、一覧のサムネイル、SNS 用）: AVIF が2割小さいが、JPEG でも困らない。エンコードが238倍速く、フォールバックも不要になる
- 枚数が多く変換コストが積み上がる: AVIF を使うなら
-cpu-usedを上げる。既定のままだと12倍の時間を無駄に払う - どの品質域でも、風景写真に WebP を選ぶ理由は見つかりませんでした。中品質域では AVIF に負け、高品質域には届きません
いちばん外しやすいのは、品質域を決めないまま形式だけ比べることでした。同じ10枚の写真で、高品質域なら AVIF が2倍近く小さく、中品質域なら2割差まで縮みます。先に「どの品質で配信するか」を決めれば、形式はそこから決まります。
測っていないことも書いておきます。目視での画質比較はしておらず、数字はすべて指標によるものです。透過を含む画像と、風景以外の被写体は今回の対象から外しました。