AVIFとは？知っておくべきモダンな画像フォーマット
AVIFの正体
AVIFはAV1 Image File Formatの略です。これは静止画像のためのモダンなコンテナフォーマットで、Google、Apple、Mozilla、Netflix、Amazonといった巨大企業が参加するコンソーシアム「Alliance for Open Media」によって開発されたAV1ビデオコーデックから派生したものです。最初の安定版仕様は2019年に登場し、それ以来、ブラウザのサポートは着実に増え続けています。 AVIFを本当に理解するには、その系譜を辿る必要があります。親であるAV1は、ロイヤリティフリーのビデオコーデックとして、特許に縛られたHEVC (H.265)に対抗するために作られました。HEVCはAppleのHEIF画像の背景にある技術です。AV1はオープンソースで無料なので、どんな開発者でもライセンス料を支払うことなく実装できます。これは普及にとって非常に大きな意味を持ちます。Chrome、Firefox、EdgeがすべてAVIFをネイティブでサポートしている一方で、ウェブ上でのHEIF/HEICのサポートが依然として混乱しているのは、これが理由です。 AVIFは、AV1のフレーム内エンコーディングツールを利用して機能します。基本的には、一枚の写真をビデオの1フレームとして扱うわけです。これは安易な近道ではありません。AV1ビデオを非常に効率的にしているのと同じ、洗練された圧縮技術（最大64×64ピクセルの可変変換ブロックサイズ、フィルムグレイン合成、ループフィルターなど）をAVIFが利用できるのはこのためです。その結果、今日の最も効率的な画像フォーマットの称号をかけて、JPEG XLやWebP 2と競い合うフォーマットが生まれました。 単なる圧縮だけでなく、AVIFは機能豊富なフォーマットでもあります。8ビット、10ビット、さらには12ビットの色深度をサポートし、HDRやRec. 2020、Display P3といった広色域にも対応しています。また、アルファ透明度や短いアニメーションも扱えます。この柔軟性により、写真コンテンツとグラフィックコンテンツの両方で優れた性能を発揮しますが、後述するように、特有の長所と短所も存在します。
AVIFとJPEG、WebP、PNGの圧縮比較
形容詞よりも数字の方が雄弁に物語ります。AV1の主要な開発者であるNetflixが2021年に行った調査によると、同等の視覚品質でAVIFファイルはJPEGより約50%小さいことが示されました。Google独自のWebPは、通常JPEGに対して25〜34%の削減効果があります。これは小さな漸進的な改善ではありません。世代的な効率の飛躍です。 具体的に見てみましょう。高品質な180KBの商品写真をJPEG（品質85）で保存した場合、WebPでは約130KBになります。同じ画像をAVIFで固定レート係数（crf）30で保存すると、良いモニターで見ても知覚できる品質の低下なしに、わずか90〜100KBになるかもしれません。サムネイルなど、わずかな品質低下が許容できる場合は、crfを40にすることでファイルサイズを60KB未満に抑えることも可能です。 ではグラフィックはどうでしょうか？ロゴやイラスト、フラットな色合いのUIスクリーンショットでは、PNGがロスレスの王様でした。AVIFにもロスレスモードはありますが、こちらの方が優れていると思い込んではいけません。私の経験上、この用途には不向きです。ロスレスAVIFファイルは、同等のPNGよりも10〜20%大きくなることがよくあります。一方、WebPのロスレスモードは一貫してPNGを約26%上回り、ロスレスAVIFよりも優れています。結論は明らかです。AVIFの真の強みは写真のロッシー圧縮にあり、ロスレスグラフィックではありません。 アルファ透明度こそ、AVIFが真価を発揮する分野です。JPEGは透明度を全く扱えません。WebPは可能ですが、AVIFは多くの場合、より高品質でより小さなファイルサイズで実現できます。Eコマースの基本である背景が透明な商品写真は、PNGの counterpart と比べて60〜70%も小さいAVIFとして保存でき、髪の毛や毛皮のような厄介なディテールの周りもくっきりとしたエッジを保つことができます。
2025年時点でのブラウザとプラットフォームのサポート状況
AVIFはもはや実験的なものではありません。caniuse.comによると、2025年半ばの時点で、世界のブラウザサポート率は93%を超えています。Chromeは2020年8月のバージョン85から対応。Firefoxは2021年10月のバージョン93で追随しました。重要なことに、macOS VenturaとiOS 16以降のSafariもAVIFをデコードできます。EdgeはChromiumベースであるため、2020年後半からサポートしています。 これが何を意味するかというと、ウェブサイトでAVIF画像を提供すれば、ほぼ全ての人がそれを見ることができるということです。残りの約7%の古いブラウザを使っているユーザーには、フォールバックを用意すればいいだけです。そのためのエレガントで標準的な解決策がHTMLの`<picture>`要素です。 <picture> <source srcset="image.avif" type="image/avif"> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="商品写真"> </picture> このシンプルな3層のフォールバックは、重要なブラウザをすべてカバーします。AVIFを解釈できないブラウザはWebPを試し、それも失敗すれば、普遍的なJPEGにフォールバックします。これだけでうまくいきます。JavaScriptは不要です。 デスクトップでは、話は少し複雑になりますが、概ねポジティブです。Windows 11では、Microsoft Storeから無料のAV1 Video Extensionをインストールすれば、フォトアプリでAVIFを表示できます。macOSはmacOS Monterey以降、プレビューアプリでネイティブサポートしています。Adobe Photoshopはバージョン23.2（2022年2月）でAVIFサポートを統合し、直接開いたり保存したりできるようになりました。GIMPはバージョン2.10.22からサポートしています。FigmaでさえAVIFファイルを開けますが、まだエクスポートはできません。 自動化ワークフローを構築する人にとって、サーバーサイドのツールも成熟しています。リファレンス実装であるlibavif、Node.js用のSharp、Python 3.10+用のPillow、ImageMagick 7.1+といった主要なライブラリは、すべて堅牢なAVIFエンコード・デコード機能を提供しています。
AVIFを使うべき時、使うべきでない時
では、実際にどこでAVIFを使うべきなのでしょうか？主なターゲットは、ファイルサイズがパフォーマンスに影響するウェブ上のあらゆる写真画像です。Eコマースの商品ギャラリー、ニュース記事のヒーロー画像、ポートフォリオサイトなどを考えてみてください。もしあなたのウェブサイトが1日に何千もの画像を配信しているなら、AVIFに切り替えることでCDNの帯域幅コストを30〜50%削減できます。規模が大きくなれば、これは現実的な金額になります。 HDR写真も、最高の使い道の一つです。10ビットおよび12ビットの色深度とRec. 2020のような広色域をサポートすることで、AVIFはHDRコンテンツをSDRに情報を圧縮することなく表示できます。JPEGはこれが全くできず、WebPは8ビットに留まります。HDRスクリーンを持つユーザーにハイエンドな画像を見せる写真家や不動産サイトにとって、AVIFはそのハードウェアの性能を最大限に引き出す、広くサポートされた唯一のウェブフォーマットです。 しかし、AVIFは万能薬ではありません。最大の欠点は、エンコードが遅いことです。本当に遅い。高解像度の写真を高品質設定で1枚エンコードするだけで、CPUファンが唸りを上げ、数秒かかることがあります。一方、JPEGはミリ秒単位でエンコードが完了します。この遅延のため、AVIFは頻繁に保存を行う写真編集ソフトのような、リアルタイムの画像生成が必要なアプリケーションには不向きです。ハードウェアエンコーディングのサポートは改善されつつありますが、ソフトウェアのみのエンコーディングは依然として大きなボトルネックです。 他のタスクには、適材適所でツールを使い分けるべきです。ベクターグラフィックスや図表は、依然としてSVGが適しています。ピクセルパーフェクトな鮮明さが必要なコードやUIテキストのスクリーンショットには、PNGかロスレスWebPを使い続けましょう。そして印刷関連の用途では、AVIFは全く関係ありません。TIFFとPDFが今も揺るぎない標準です。 アニメーションについてはどうでしょうか？AVIFは対応していますが（AVISシーケンスとして）、エンコードは静止画よりもさらに遅く、ブラウザのサポートも信頼性が低いです。正直なところ、アニメーションWebPか、さらに言えば自動再生設定の短いMP4やWebMビデオファイルを使った方が良いでしょう。
画像をAVIFに変換する方法
さて、では実際にどうやってこれらのファイルを作成するのでしょうか？ニーズに応じて、いくつかの選択肢があります。 開発者やコマンドライン好きの方には、`avifenc`（libavifツールキットに含まれる）がリファレンスエンコーダーです。典型的なコマンドは次のようになるでしょう：`avifenc --min 20 --max 40 --speed 6 input.jpg output.avif`。`--min`と`--max`フラグは品質範囲（0〜63のスケールで、数値が低いほど高品質）を設定し、`--speed`はエンコード時間とファイルサイズのトレードオフ（0が最も遅く効率的、10が最速）を制御します。speed 6はバッチ処理の出発点として最適です。 何をしているか視覚的に確認したいなら、GoogleのSquoosh (squoosh.app) は素晴らしいブラウザベースのツールです。視覚的な品質スライダーと即時の左右比較でAVIFの設定を微調整できます。これは単発の変換や、品質設定が特定の画像にどう影響するかを体感するのに最適です。 コマンドラインに触れることなく大量変換を行いたい場合、CocoConvertはJPEG、PNG、WebP、HEICなどのソースからAVIFを出力フォーマットとして提供しています。ファイルをアップロードし、AVIFを選んで、結果をダウンロードするだけです。エンコーダーは、ウェブ用途でのサイズと品質のバランスが良くなるように事前設定されています。正直に一つ注意点を挙げるとすれば、CocoConvertは固定レート係数（crf）やクロマサブサンプリングの手動制御機能は提供していません。プロの写真で4:4:4カラーを保証するなど、そのレベルのきめ細やかな制御が必要な場合は、コマンドラインツールやPhotoshopのエクスポートダイアログがその精度を提供してくれます。 Photoshop（CC 2022以降）では、「ファイル」>「書き出し」>「書き出し形式」と進み、フォーマットリストからAVIFを選択するだけです。しかし、Lightroom ClassicはまだネイティブでAVIFを書き出せず、そのギャップを埋めるにはサードパーティのプラグインが必要です。
AVIF vs. JPEG XL: もう一つの対抗馬
AVIFについて正直に語るなら、その主なライバルであるJPEG XL（JXL）に触れないわけにはいきません。JXLは素晴らしいフォーマットで、AVIFにはないいくつかの特徴を持っています。例えば、真のロスレスJPEG再圧縮（JPEGをJXLに変換し、品質の劣化ゼロで元に戻せる）や、同等の品質レベルでのより高速なエンコード速度などです。また、シャープな線やテキストを含む画像に対しても、より良い結果を出すことが多いです。 圧縮率の直接対決では、どちらのフォーマットも全面的に圧勝しているわけではありません。AVIFは非常に低いビットレートでの詳細な写真で優位に立つことが多く、一方のJPEG XLはグラフィック、テキストの多い画像、そしてエンコード速度が重要なワークフローで優れている傾向があります。 しかし、技術仕様だけが全てではありません。決定的な違いはブラウザのサポート状況です。2023年、Chromeの開発者はエコシステムからの関心が低いことを理由に、実験的なJPEG XLサポートを削除し、その決定が事実上、市場を凍結させました。2025年半ばの時点で、JXLをネイティブでサポートしているのはSafari（17+）のみで、Firefoxのサポートはフラグの裏に隠されています。これは、今日ウェブ上でJXLをJavaScriptのポリフィルなしに安定して提供できないことを意味します。ウェブ開発者にとって、この状況が、少なくとも現時点での我々の選択を決めています。93%以上のネイティブサポートを誇るAVIFが、モダンな画像展開における唯一の実用的な選択肢なのです。 この状況は変わるかもしれません。JPEG XLコミュニティは情熱的で活発であり、ブラウザベンダーが再考する可能性もあります。しかし、今まさにウェブサイトを構築している人にとって、AVIFは、重要な場面で実際にサポートされているという、巨大で否定しようのないアドバンテージを持っています。
既存の画像をAVIFに移行すべきか？
では、あなたの画像ライブラリ全体を変換すべきでしょうか？幸いなことに、移行は白か黒か、といった大変な作業である必要はありません。ほとんどの場合の最善の戦略は、既存のJPEGやPNGに加えてAVIFバージョンを追加し、`<picture>`要素を使ってブラウザに最適なフォーマットを選ばせることです。これは古いファイルを削除する必要がなく、ただ補強するだけだということを意味します。 大規模なライブラリを持つサイトでは、バッチ変換が唯一の現実的な方法です。Node.js用のSharpやシェルループ内のImageMagickのようなツールを使ってスクリプトを設定するか、Viteやwebpackのビルドステッププラグインを使用します。そして一晩実行させておけばいいでしょう。遅いエンコードは一度きりのコストですが、帯域幅の節約はページが読み込まれるたびに恩恵をもたらします。 今後すべての新しい画像については、ワークフローはさらにシンプルです。ウェブ配信用にAVIFバージョンをエンコードすることを標準的な手順にしましょう。元の高解像度ソースファイル（RAW、TIFF、高品質JPEGなど）は保持し、公開プロセスの一環としてウェブに最適化されたAVIFを生成するのです。 ストレージについてはどうでしょうか？確かに、各画像の複数のバージョンを保持すると、一時的にストレージ使用量が増加します。AVIFファイルは小さいですが、既存のライブラリに追加する形になるからです。しかし、ほとんどのウェブサイトでは、CDNの転送帯域幅の大幅な節約が、オリジンストレージのわずかなコスト増を補って余りあるでしょう。 最後に一つ注意点を。アーカイブについてです。15年前のプロプライエタリなファイルフォーマットを開こうとしたことがある人なら誰でも、ビット腐敗と陳腐化の痛みを知っています。AVIFはまだ若いです。JPEGは30年以上の歴史があり、まだ発明されていないソフトウェアでも読み取れるでしょう。最も重要な画像の長期的かつ恒久的なアーカイブのためには、保守的な選択が正解です。高品質のJPEGかTIFFを使い続けましょう。AVIFは配信用に使い、オリジナルは常に実績のあるフォーマットで保管してください。