AVIF vs WebP vs JPG: 現代の画像フォーマット徹底比較
この比較が本当に重要な理由
画像フォーマットを単なる見た目の問題だと勘違いしてはいけません。そうではないのです。トラフィックの多い商品ページでフォーマットの選択を一つ間違えるだけで、画像1枚あたり200～400KBも余計に増えてしまいます。これが積み重なると、読み込み時間が数秒も長くなり、コンバージョン率の明確な低下につながります。GoogleのCore Web Vitalsは、Largest Contentful Paintのスコアが低いサイトを直接ペナルティの対象にし、その原因は通常、画像にあります。AVIF、WebP、JPGのどれを選ぶかは、SEO、帯域幅の請求額、そしてユーザーがサイトに留まるかどうかに、現実的な影響を及ぼすのです。 JPGは90年代半ばから写真の世界を支配してきました。どこでも使え、エンコードは速く、どんな開発者もその扱い方を知っています。GoogleのWebPは2010年にその後継として登場し、同じ品質でより優れた圧縮を約束しました。新顔はAVIFで、2019年にAlliance for Open Mediaによって標準化されました。これはAV1ビデオコーデックから技術を借用することで、圧縮率をさらに押し上げています。 ここでの目的は、どれか一つのフォーマットを勝者と宣言することではありません。そんなことは無意味です。目的は、それぞれの具体的なトレードオフを理解し、2021年頃の古いアドバイスにただ従うのではなく、*あなたの*プロジェクトにとって正しい判断を下せるようになることです。私たちは、実世界での圧縮率、ブラウザのサポート、そしてエンコード速度のような隠れたコストを分析し、各フォーマットを効果的に使い、そしていつ変換すべきかを知るための文脈を提供します。
圧縮性能：その実力を数字で見る
はい、モダンなフォーマットはJPGより劇的にファイルサイズが小さいです。その部分の評判は本当です。しかし、どれだけ小さくなるかは、画像、エンコーダ、そして目指す品質によって異なります。 一般的な写真の場合、WebPは同等の画質のJPGより通常25～35%小さくなります。AVIFはさらにその上を行き、JPGより40～55%も小さくなることが多く、これはWebPより約15～25%小さいということです。つまり、180KBの商品写真（JPG、品質85）が、120KBのWebPや90KBのAVIFになる可能性があるということです。この節約効果は本物です。 しかし、フォーマット間で品質の数値を単純に比較することはできません。それらは等価ではないのです。「品質85」のJPGは、「品質85」のWebPと同じではありません。ImageMagickでJPGの品質を85から75に下げるとファイルサイズは削減できますが、グラデーションや空にブロックノイズが発生します。WebPは0～100のスケールを使い、80が良い出発点で、おおよそJPGの85に相当します。AVIFは通常0～63のCRF（Constant Rate Factor）スケールを使用し、数値が低いほど高品質になります。ウェブ用の写真では、CRF 30～40がスイートスポットになることが多いです。 UIのスクリーンショットやロゴ、インフォグラフィックのようなグラフィック画像になると話は変わってきます。PNGはその可逆圧縮品質から定番でしたが、WebPの可逆モードは一貫して20～30%小さいファイルを生成します。AVIFの可逆モードはまだ成熟しておらず、この種のコンテンツではWebPの可逆圧縮より*大きな*ファイルができてしまうことさえあります。AVIFがどこでも勝つと思い込んではいけません。 GoogleのSquooshチームが行ったテストでは、AVIFの圧縮における全般的な優位性が確認されましたが、ソース画像がすでに強く圧縮されている場合、その利点は縮小することもわかっています。高品質のオリジナルから作業するのではなく、古いJPGの山を再変換している場合、得られる効果は小さくなります。質の悪い入力からは、少しサイズが小さいだけの質の悪い出力しか得られません。
ブラウザとプラットフォームの対応状況：ここがややこしい
はっきりさせておきましょう。JPGのサポートは普遍的です。すべてのブラウザ、OS、画像ビューア、CMS、CDN、そしてメールクライアントが問題なく扱えます。この利点を過小評価してはいけません。それは新しいフォーマットがまだ到底及ばないレベルの普及度です。 ウェブでの利用において、WebPのサポートは今や素晴らしいものになっています。2024年現在、Chrome、Firefox、Safari（バージョン14以降）、Edge、Operaといったすべての主要ブラウザが対応しています。caniuse.comによると、世界的なサポート率は97%を超えています。唯一の未対応はiOS 13以前の古いSafariバージョンくらいで、あなたのオーディエンスにとっては問題にならないかもしれません。 AVIFのサポートも良好ですが、より注意が必要です。Chromeはバージョン85（2020年）から、Firefoxは93（2021年）から対応しており、Safariもついにバージョン16（2022年）で対応しました。これでほとんどのユーザーをカバーできますが、古いWindows 10ビルドのEdgeや特定のAndroid WebViewではまだ問題が発生する可能性があります。世界的なサポート率は93～95%あたりを推移しています。これは素晴らしい数字に聞こえますが、トラフィックの多いサイトにとって、5～7%のユーザーに画像が表示されないというのは非常に現実的な問題です。 ブラウザの外では、事態は複雑になります。デスクトップアプリ、モバイルアプリ、メールでのサポートはまだら模様です。macOSはVentura（13.0）からAVIFをサポートしています。Windows 11はサポートしていますが、Windows 10ではMicrosoft Storeからコーデックが必要です。Androidはバージョン12から、iOSは16からサポートしています。適切なフォールバックを指定したHTMLの`<picture>`要素を使っていればこれらはすべて問題になりませんが、ユーザーがこれらのファイルを自分でダウンロードして開くことを想定している場合は、大きな頭痛の種になります。 本番のウェブサイトで唯一まともな戦略は、画像を段階的に配信することです。つまり、最初にAVIF、フォールバックとしてWebP、そしてそれ以外すべてにJPGを使います。これは`<picture>`要素の`type`属性付き`source`タグを使うか、サーバーで`Accept`ヘッダーをチェックすることで実装できます。ただAVIFを配信して、うまくいくことを祈るだけではいけません。
エンコード速度とツール：隠れたコスト
AVIFの驚異的な圧縮性能には隠れたコストがあります。それは時間です。AVIFのエンコードは、JPGやWebPに比べて残酷なほど遅く、それがワークフローに現実的な影響を及ぼします。 数字を見てみましょう。2000×1500の写真をJPG（品質85、libjpeg-turbo）にエンコードすると、最新のマシンで50～80ミリ秒程度かもしれません。同じ画像をWebP（品質80、libwebp）にすると200～400ミリ秒。しかしAVIF（CRF 32、speed 6）にエンコードすると、2秒から8*秒*もかかることがあります。そして、エンコーダを最も遅く、最高品質の設定にすれば、1枚の画像に30秒以上待たされる可能性もあります。 500枚の商品画像をバッチ処理する場合、これは5分間のコーヒー休憩と4時間待ちの違いになります。一部のCDNのように画像を動的に生成している場合、キャッシュ戦略が完璧でない限り、このようなエンコードのオーバーヘッドは許容できない遅延を引き起こす可能性があります。 libavifエンコーダには0（最も遅く、最高の圧縮率）から10（最も速く、最低の圧縮率）までの速度設定があります。速度6が標準的な推奨設定で、ファイルサイズとあなた自身の正気との間の良い妥協点です。速度10はWebPとほぼ同じくらい速いですが、AVIFの圧縮上の利点の多くを犠牲にすることになります。 CocoConvertはサーバー側でこの複雑さを処理しますが、物理的な制約は変わりません。AVIFへの大量一括変換は、WebPやJPGのジョブよりも著しく時間がかかります。もし急いでいるなら、たとえAVIFがさらに数キロバイトを削れるとしても、WebPの方が実用的な選択肢であることが多いです。 WebP用のツールは成熟しており安定しています。cwebp、Squoosh、ImageMagick、Node.jsのSharpライブラリなど、すべてが堅牢なサポートを提供しています。AVIFのツールも追いついてきており、Sharpはv0.27.0でサポートを追加し、ImageMagickはlibheifを使用していますが、ライブラリの依存関係の問題と格闘したことがある人なら誰でも、「追いついてきている」という状況が、JPGやWebPの世界では単に存在しない奇妙なバグやバージョンの競合に遭遇することを意味する場合があると知っています。
低ビットレートでの画質：フォーマットの差が最も現れる点
高い品質設定では、ほとんどの圧縮画像はきれいに見えます。真価が問われるのは、ファイルから最後の1バイトまで積極的に絞り出す、低ビットレートのときです。ここで各フォーマットは本性を現し、その違いは明白になります。 強圧縮のJPGは、そのブロックノイズで悪名高いです。品質40～50では、青空の滑らかなグラデーションが、四角いパッチワークのように崩れてしまいます。テキストの周りにはぼやけた輪郭（リンギング）が現れます。誰もが見たことがあるでしょうし、それは醜いものです。 同じ低ファイルサイズのWebPは、ブロックノイズではなく、ぼやける傾向があります。細かいディテールを滑らかにしてしまいます。このぼやけは、ポートレートにとってはJPGの粗いブロックノイズよりも自然に見えるため、好ましいアーティファクトとなることがあります。しかし、シャープな線やテキストを含む画像では、その同じぼやけが大きな欠点になり得ます。 ここでAVIFが真価を発揮します。低ビットレートにおいて、他の2つを圧倒します。AV1ベースのエンコードは、ディテールを保持し、グラデーションを優雅に扱う能力が単純に優れているのです。50KBのAVIF画像は、同じサイズのWebPやJPGよりも明らかにきれいに見えます。AVIFの真の利点は、すべてが問題ない品質90のときではなく、限界に挑戦する品質50～60のときにあります。 知覚的品質指標もこれを裏付けています。1200×800の風景写真を50KBに圧縮した場合、DSSIMスコアはJPGで0.008、WebPで0.005、AVIFで0.003となるかもしれません（低いほど良い）。これらは単なる数字ではなく、目に見える改善を表しています。厳しいファイルサイズの予算がある場合、AVIFは一貫して最も見栄えの良い画像を提供してくれるでしょう。 一つ例外があります。それは、微細なフィルムグレインや自然なテクスチャです。AVIFのエンコーダはこれらのディテールを平滑化しすぎる傾向があり、一部の高ISO感度の写真では、少し人工的でプラスチックのような見た目になることがあります。常に自分の画像でテストしてください。AVIFがすべての種類のコンテンツにとって魔法の弾丸であると決めつけないようにしましょう。
実践的なユースケース：目的に合わせたフォーマット選び
理論は素晴らしいですが、実際に各フォーマットをどこで使うべきでしょうか？一般的なシナリオのための実用的なガイドを以下に示します。 **ウェブサイトのヒーローイメージと商品写真：** AVIFを第一候補とし、WebP、JPGへとフォールバックさせるのがよいでしょう。環境を自分でコントロールできるので、`<picture>`要素を使って最適なフォーマットを配信できます。帯域幅の節約は莫大です。CocoConvertのようなツールを使えば、元のJPGをAVIFとWebPの両方に一括変換でき、この作業が簡単になります。 **メール内の画像：** JPG一択です。メールクライアントは、レンダリングの一貫性がない無法地帯です。AVIFもWebPも、Outlook、Apple Mail、Gmailで信頼できるサポートはありません。WebPを送ると、多くの受信者には壊れた画像として表示されるだけです。 **ソーシャルメディアへのアップロード：** 高品質のJPGを使いましょう。すべてのプラットフォーム（Instagram、Twitter/X、Facebook）は、何をアップロードしても画像を再エンコードします。彼らのエンコーダが処理するための、可能な限り最高のソース素材を提供してあげましょう。事前に圧縮されたAVIFをアップロードしても何の得にもなりません。 **印刷またはアーカイブ用途：** どちらも使いません。オリジナルにはTIFFやPNGのような可逆圧縮フォーマットを使いましょう。圧縮されたプレビューを送る必要がある場合は、どんな印刷所や編集者でも開ける普遍的な標準である、高品質のJPG（90-95）が適しています。 **モバイルアプリのアセット：** これはサポート対象の最小OSバージョンによります。Android 12以上とiOS 16以上を対象にビルドしているなら、AVIFは素晴らしい選択です。より広いサポートを求めるなら、Android 4.0やiOS 14まで遡って動作するWebPの方が安全な賭けです。 **CMSのコンテンツ：** AVIFには注意が必要です。技術に詳しくないユーザーが画像をアップロードする場合、最も信頼性の高いワークフローが求められます。多くのCMSのメディアライブラリやサムネイル生成機能は、まだAVIFを適切に処理できません。JPGとWebPの方がはるかに実用的で、画像のプレビューが壊れているというサポートチケットを発生させる可能性が低くなります。
フォーマット間の変換方法（と注意点）
適切なツールを使えば、これらのフォーマット間の変換は簡単ですが、注意しないと、いくつかの地雷がバッチジョブを台無しにしてしまう可能性があります。 変換の鉄則は、常に最高品質のソースから始めることです。JPGをAVIFに変換しても、JPGの圧縮によってすでに失われたディテールが魔法のように復元されるわけではありません。劣化した同じデータを新しいフォーマットで包み直すだけです。もしRAWやTIFFのオリジナルがあるなら、それらを使いましょう。手元にあるのがJPGだけだとしても、それをAVIFに変換すればファイルは小さくなりますが、画像がより良く見えるようになるわけではありません。 CocoConvertのようなツールを使えば、プロセスは簡単です。アップロードし、フォーマットを選び、ダウンロードするだけ。JPGからWebPへのデフォルトの品質設定は、視覚的な品質を維持するように調整されています。JPGからAVIFへの変換では、デフォルト設定はファイルサイズと品質のバランスを取っていますが、大きく表示されユーザーに精査される画像の場合は、より高い品質を要求することを検討すべきです。 制限事項について正直にお伝えします。CocoConvertはアニメーション形式を扱いません。アニメーションWebPをアニメーションAVIFに変換するのは全く別の話で、フレームのタイミングやカラーパレットが関わってきます。そのためには、FFmpegのようなコマンドラインツールを持ち出す必要があります。 透明度には注意してください。JPGは透明度をサポートしていません。以上です。透明なPNGやWebPをJPGに変換すると、背景は単色（通常は白か黒）で塗りつぶされます。AVIFとWebPはどちらも透明度（アルファチャンネル）を問題なく扱えるので、これらの間で変換すれば透明度は保持されます。パイプラインの途中で誤って透明画像をJPG変換ステップに通さないように注意してください。 最後に、現実的なアドバイスを一つ。すべての画像に対してAVIFとWebPの両バージョンを生成する前に、本当に両方が必要か自問してみてください。2つのフォーマットを生成すると、処理時間とストレージが2倍になります。多くのサイトでは、単にWebPに標準化するだけでJPGから大幅な改善となり、はるかに少ない複雑さで97%以上のユーザーをカバーできます。AVIFは強力ですが、その追加作業を帯域幅の請求額が本当に正当化する場合にのみ追加すべきです。