Skip to content
Published on

画像フォーマット 2026 — AVIF / JPEG XL / WebP / HEIC / MozJPEG / QOI / Sharp / Squoosh 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. 2026年の画像フォーマット地図 — JPEG / WebP / AVIF / JPEG XL / HEIC のビッグ5

2026年5月時点で、Web / モバイルで実用的に使われる画像フォーマットは5つに絞られています。JPEG (1992)、PNG (1996)、GIF (1987) という30年級のトリオの上に、WebP (2010)、HEIC (2015)、AVIF (2019)、JPEG XL (2021) が順に積み上がり、その間に QOI (2021)、ロスレス変種、アニメーション変種が入り込みました。

大枠で分類すると次のようになります。

  • クラシックフォーマット — JPEG (写真)、PNG (UI / 透過)、GIF (アニメ、ほぼレガシー)
  • モダンな非可逆 — WebP、AVIF、HEIC、JPEG XL
  • モダンな可逆 — Lossless WebP、Lossless AVIF、JPEG XL Lossless、PNG (現役)、QOI
  • アニメーション — GIF、APNG、Animated WebP、Animated AVIF
  • ツール / パイプライン — Sharp、libvips、Squoosh、ImageMagick、MozJPEG、Cloudinary、imgix、Fastly Image Optimizer、ImgBot

2026年最大の出来事は2つです。第一に、AVIF が Edge / Chrome / Firefox / Safari すべての安定版で対応され、「modern image format」のデファクト標準になりました。第二に、JPEG XL が2023年に Chrome から削除されたものの、2023年9月の Safari 17 で正式採用され、2025年に入って Google が態度を軟化させたことで Chrome 復帰が再び議論されています。

この記事は、それらすべてのフォーマットとツールを2026年5月時点で一気に俯瞰するガイドです。初心者は「どこから始めるか」、シニアは「次のパイプラインに何を加えるか」を決めるのに役立つはずです。

2. AVIF — ブラウザ普遍対応、現代の標準

AVIF (AV1 Image File Format) は、動画コーデック AV1 のキーフレームを静止画として活用するフォーマットで、2019年に Alliance for Open Media が標準化しました。2020年8月の Chrome 85 で初めて対応され、2026年5月現在、すべてのメジャーブラウザの安定版で対応されています。

  • Chrome 85+ (2020年8月)
  • Firefox 93+ (2021年10月)
  • Safari 16.4+ (2023年3月、iOS 16.4 / macOS 13.3)
  • Edge 121+ (2024年)

AVIF 最大の長所は圧縮率です。同じ画質において、JPEG 比で平均50%、WebP 比で平均20%ほど小さくなります。HDR (10/12 ビット)、広色域 (BT.2020)、アルファチャンネル、アニメーション、画像シーケンスをすべてサポートします。

<picture>
  <source type="image/avif" srcset="hero.avif" />
  <source type="image/webp" srcset="hero.webp" />
  <img src="hero.jpg" alt="Hero image" width="1280" height="720" loading="lazy" />
</picture>

短所はエンコードが遅いことです。同じ画像を変換すると、MozJPEG 比で約10倍、WebP 比で約5倍以上の時間がかかります。そのため、ビルド時の事前エンコード、バックグラウンドジョブキュー、CDN 側の非同期変換が一般的です。

Sharp (libvips) の AVIF エンコーダは内部的に libaom (Google 参照エンコーダ) または SVT-AV1 (Intel / Netflix) を呼び出します。SVT-AV1 は速く、libaom は圧縮率が良好です。2024年以降、libaom のマルチスレッド最適化が大幅に改善され、その差は縮まっています。

import sharp from 'sharp'

await sharp('photo.jpg')
  .resize(1280, 720, { fit: 'inside' })
  .avif({
    quality: 50, // 0-100、50 前後がスイートスポット
    effort: 4, // 0-9、高いほど遅いが小さい
    chromaSubsampling: '4:2:0',
  })
  .toFile('photo.avif')

2026年時点の推奨設定は、写真なら quality 50-60 / effort 4、UI グラフィックなら quality 70 / effort 6 です。これ以上 effort を上げてもファイルサイズはほとんど変わらず、エンコード時間だけが爆発します。

3. JPEG XL — Chrome 削除 (2023) → Safari 17 復活 → 2025 Chrome 復帰?

JPEG XL (.jxl) は2021年に ISO/IEC 18181 として標準化された次世代 JPEG 後継フォーマットです。中核設計者は Cloudinary の Jon Sneyers (FUIF) と、Google チューリッヒの Jyrki Alakuijala (PIK) で、両者の成果を統合しました。技術的にはほぼあらゆる面で JPEG / WebP / AVIF を凌駕します。

主な特徴:

  • 写真圧縮率 — JPEG 比で平均60%、AVIF と同等またはやや優位
  • 可逆圧縮 — PNG 比で平均35%小さい
  • 可逆 JPEG 再エンコード — 既存 JPEG を画質無損失で約20%小さく再エンコード
  • プログレッシブデコード — 部分的にダウンロードしただけでもおぼろげなプレビューが見える
  • 可変ビット深度 — 1ビット~32ビット浮動小数
  • 高速デコード — AVIF より明確にデコードが速い

ところが2022年10月、Google は突如「Chrome 110 から JPEG XL 対応を削除する」と発表しました。理由は「十分な ecosystem interest がない」というもので、実際2023年1月の Chrome 110 でフラグごと完全に削除されました。この決定は大きな反発を呼び、Adobe、Facebook、Intel、Krita、Cloudinary が公に反対意見を表明しました。

その後、流れが変わりました。

  • 2023年9月、Apple が Safari 17 (iOS 17 / macOS Sonoma) で JPEG XL の正式対応を発表 — Image I/O と WebKit 両方で
  • 2024年、Adobe Camera Raw、Lightroom、Photoshop が正式対応
  • 2024年末、Google 自身の Pixel カメラの一部機能が内部的に JXL を採用
  • 2025年、libjxl 0.10 が安定化し、エンコード速度 / メモリが production グレードに到達
  • 2025年後半、Chromium issue tracker で JPEG XL 復帰の議論が再開 (Chromium issue 178205)

2026年5月現在、Chrome 公式復帰はまだ確定していませんが、流れは明確に「復帰」へ傾いています。Edge と Brave は libjxl を自社ビルドに含めるパッチを維持しています。

# エンコード (libjxl 0.10+)
cjxl input.png output.jxl --quality 90 --effort 7

# 可逆 JPEG 再エンコード (再エンコード後にデコードすると、元の JPEG とビット単位で一致)
cjxl photo.jpg photo.jxl --lossless_jpeg=1

# デコード
djxl output.jxl decoded.png

JPEG XL は「10年後も生き残るフォーマット」の最右翼です。印刷、写真、医療画像のような可逆 / 高ビット深度の領域では、すでに AVIF を上回っています。

4. WebP — Google の古い回答

WebP は2010年に Google が発表したフォーマットです。On2 の VP8 動画コーデックのキーフレームを切り出した構造で、「JPEG の後継」として登場しました。2014年に Chrome / Opera が先に対応、Firefox 65 (2019)、Edge 18 (2018)、Safari 14 (2020年9月) が順に合流し、普遍対応フォーマットになりました。

WebP の2026年における立ち位置は微妙です。

  • AVIF より明確に圧縮率が劣る (写真で平均15-20% の差)
  • エンコードは AVIF より5倍速い
  • Lossless WebP は PNG より平均25%小さい
  • Animated WebP は GIF より平均30%小さい
  • アルファチャンネル対応

つまり「AVIF 導入コストが負担になる場面の現実的代替」として残っています。ビルド時間がタイトな静的サイト、エンコードリソースに乏しいユーザーアップロードパイプラインでは、今も WebP が優先候補です。

import sharp from 'sharp'

// 非可逆 WebP — 写真用
await sharp('photo.jpg')
  .webp({ quality: 80, effort: 4 })
  .toFile('photo.webp')

// 可逆 WebP — UI / ロゴ用
await sharp('logo.png')
  .webp({ lossless: true, effort: 6 })
  .toFile('logo.webp')

// アルファチャンネルを保持した非可逆圧縮
await sharp('icon.png')
  .webp({ quality: 85, alphaQuality: 90 })
  .toFile('icon.webp')

CDN は AVIF と WebP を同時に生成しておき、ブラウザの Accept ヘッダーで最適なものを返す方式を採るのが一般的です。この方式では、WebP は「AVIF 非対応またはデコード遅延が大きいクライアント」向けのフォールバックとして組み込まれます。

5. HEIC/HEIF — Apple のデフォルト

HEIF (High Efficiency Image File Format) は ISO/IEC 23008-12 のコンテナ標準で、その中に HEVC (H.265) のキーフレームを格納したものが HEIC (.heic) です。2017年の iOS 11 から iPhone の標準写真フォーマットが HEIC に変わり、事実上すべての iOS / iPadOS / macOS 機器が HEIC で写真を生成します。

HEIC の圧縮率は JPEG 比で平均50%程度、AVIF / JPEG XL と同水準です。ただし以下の制限があります。

  • ライセンス — HEVC は特許プールが複雑でデコーダ / エンコーダにロイヤリティがあり、Web 標準にはなれなかった
  • ブラウザ対応 — Safari 17+ のみが直接対応 (Apple エコシステム限定)
  • Android は 9.0+ から HEIF コンテナ自体は読めるが、コーデックは機種次第
  • Windows / Linux デスクトップは別途コーデックパックが必要

そのため、HEIC は「ユーザーがアップロードする元ファイル」として頻繁に入ってきますが、サービスがそのまま配信することはほぼありません。一般的なパイプラインは次のとおりです。

import sharp from 'sharp'

// HEIC 入力 → AVIF / JPEG 変換
// libheif がビルドされた Sharp が必要 (sharp 0.32+)
await sharp('IMG_1234.heic')
  .resize(2048, null, { withoutEnlargement: true })
  .avif({ quality: 60 })
  .toFile('IMG_1234.avif')

// または別のオプション
await sharp('IMG_1234.heic')
  .resize(2048, null, { withoutEnlargement: true })
  .jpeg({ quality: 85, mozjpeg: true })
  .toFile('IMG_1234.jpg')

iOS 11 から約9年が経った2026年現在でも、ユーザーアップロードシステムには依然「HEIC ファイルが読めない」バグが多くあります。Sharp / ImageMagick / Pillow など主要ライブラリは、libheif のビルドオプションを有効にしないと HEIC に対応できません。

6. MozJPEG / 可逆変種

MozJPEG は、Mozilla が2014年に始めた JPEG エンコーダ最適化プロジェクトです。標準 JPEG デコーダと100%互換なビットストリームを生成しつつ、libjpeg-turbo より平均5-15%小さいファイルを作ります。つまり「受信側からは普通の JPEG に見えるが、サーバー側ではより強く絞った」ケースです。

MozJPEG の核となる技術:

  • Trellis quantization — 量子化係数をビットレート最適化で微調整
  • Progressive scan 最適化 — 8 種類の標準スキャンスクリプトから最適を選択
  • DC / AC 係数の事前分離圧縮

Sharp では mozjpeg: true フラグを立てるだけで、内部の libjpeg-turbo の代わりに MozJPEG 経路を通ります。

await sharp('input.jpg')
  .jpeg({
    quality: 82,
    mozjpeg: true, // MozJPEG エンコーダを使用
    progressive: true,
    trellisQuantisation: true,
    chromaSubsampling: '4:2:0',
  })
  .toFile('output.jpg')

可逆 (lossless) 変種は2026年時点で次のように整理されます。

  • Lossless WebP — PNG 比で平均25%小さい、アルファ対応
  • Lossless AVIF — PNG 比で平均15%小さい、エンコードが非常に遅い
  • JPEG XL Lossless — PNG 比で平均35%小さい、最もバランスの良い選択肢
  • QOI — PNG よりわずかに大きいが、エンコード / デコードが10倍以上速い
  • PNG (zopfli、oxipng) — いまだに最も互換性の高い可逆
  • WebP 2 — 事実上廃止、メインラインに合流せず

UI アイコン、スクリーンショット、図解のように「ピクセル単位の正確性が重要な画像」は今も可逆領域です。その中では JPEG XL Lossless が最小ですが、クライアント互換性を取るなら oxipng で最適化した PNG が安全です。

7. QOI — Quite OK Image format の魅力

QOI は2021年12月に Dominic Szablewski (phoboslab) が発表した可逆画像フォーマットです。仕様がわずか14ページ、リファレンスエンコーダが約300行の C コードという極端な単純さが魅力です。

QOI の特性:

  • 可逆
  • エンコード / デコードが PNG より平均20-50倍速い
  • ファイルサイズは PNG より平均10%ほど大きい
  • 依存ゼロ — 単一ヘッダファイル (qoi.h) だけあれば完結
  • 4種類のチャンクタイプ (INDEX、DIFF、LUMA、RGB/RGBA) のみを使用

Web 標準ではありませんが、ゲームアセット、ツールチェーン内部キャッシュ、WebGL テクスチャなど「デコード速度が重要な場所」で急速に定着しました。Godot 4.x が内蔵テクスチャインポータに QOI オプションを追加し、複数のインディーゲームが .pak の中に QOI でテクスチャをパッキングしています。

// QOI エンコードは非常に簡潔
#define QOI_IMPLEMENTATION
#include "qoi.h"

qoi_desc desc = {
  .width = 1024,
  .height = 1024,
  .channels = 4,
  .colorspace = QOI_SRGB
};
qoi_write("output.qoi", pixels, &desc);

ブラウザ対応がないため、Web で直接表示することはできません。ただし WASM デコーダが10KB 未満で実装可能なので、「超高速デコードが必要なインタラクティブページ」でバックグラウンドデコード用に使う事例が出てきています。通常の Web サイトの画像にはお勧めしません。

8. アニメーション — Animated AVIF は GIF を置き換えるか

GIF は1987年のフォーマットです。256色パレット、LZW 圧縮、フレームごとの時間遅延を持つ単純な構造で、短いクリップの事実上の標準になりました。2026年でも、メッセンジャー、Slack、Discord などほぼすべてのチャットプラットフォームが依然として .gif アップロードを受け付けます。

問題はファイルサイズです。5秒の 720p クリップが GIF で 5-20MB になることは珍しくないのに対して、同じ映像を MP4 でエンコードすると 200KB-1MB になります。そのため、Twitter、Slack、Discord などはユーザーが GIF を上げても、内部的に MP4 / WebM に変換して配信しています。

2026年の GIF 代替候補は次のとおりです。

  • MP4 / WebM 動画 — 最小、自動再生 / 無音処理が必要
  • Animated WebP — Chrome 32+ (2014)、Firefox 65+ (2019)、Safari 14+ (2020)、フォールバックが単純
  • Animated AVIF — すべてのブラウザで安定対応、最小 (WebP 比で約30%追加削減)
  • APNG — PNG のアニメーション拡張、可逆だが大きい

Animated AVIF は2024年から本格普及が始まりました。AV1 コーデックをそのまま活用し、単一静止画にはキーフレーム1枚、アニメーションには複数フレームを格納する構造です。

import sharp from 'sharp'

// 複数フレームを Animated AVIF にまとめる
// sharp 0.33+
await sharp('frames/', { animated: true, pages: -1 })
  .resize(640, 360)
  .avif({ quality: 50, effort: 4 })
  .toFile('animation.avif')

// あるいは ffmpeg で直接
// ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 output.avif

ただし、Animated AVIF のデコードメモリは GIF / WebP 比で大きいです。モバイル Safari で 5MB の Animated AVIF を1ページに50枚並べると、メモリ不足でページが落ちることもあります。そのため実サービスでは「動画に変換」が最も安定します。

9. Cloudinary / imgix / Fastly Image Optimizer — マネージド CDN

画像変換 / 最適化を自前運用する代わりに CDN に任せるのが2026年の標準です。主要な3つの選択肢は次のとおりです。

Cloudinary (2012年創業) は最も豊富な変換オプションを持つマネージド画像 / 動画プラットフォームです。URL の中に変換パラメータをインラインで書く方式が特徴です。

# 元画像
https://res.cloudinary.com/demo/image/upload/sample.jpg

# 横幅 800、AVIF 変換、自動品質
https://res.cloudinary.com/demo/image/upload/w_800,f_avif,q_auto/sample.jpg

# 顔認識クロップ + ウォーターマーク + グレースケール
https://res.cloudinary.com/demo/image/upload/w_400,h_400,c_thumb,g_face,e_grayscale,l_logo/sample.jpg

imgix (2011年創業) は URL クエリ文字列方式です。AVIF / WebP の自動選択は auto=format の1行で完了します。

# 元画像
https://example.imgix.net/photo.jpg

# 横幅 800、フォーマット自動、圧縮自動
https://example.imgix.net/photo.jpg?w=800&auto=format,compress

Fastly Image Optimizer (旧 Fastly IO、2017年提供開始) は Fastly Compute と統合されて動作します。自社オリジン (S3、GCS など) の元画像を Fastly が変換してキャッシュする構成です。

# Fastly ドメインでクエリ文字列により変換
https://cdn.example.com/photo.jpg?width=800&auto=avif&quality=80

価格は通常「元画像ストレージ + 変換後画像のトラフィック」で計算されます。2026年時点でおおよそ:

  • Cloudinary — 無料枠 25 credits/月、それ以降は $99 ~ enterprise
  • imgix — 無料 1000 画像、それ以降は $25 から
  • Fastly Image Optimizer — Fastly CDN 料金 + Image Optimizer アドオン

Vercel、Netlify、Cloudflare も独自の画像最適化を提供しています。Next.js の next/image は Vercel デプロイ時には Vercel Image Optimization、それ以外の環境では Sharp または外部ローダで動作します。

10. Sharp (Node.js, libvips) — サーバーサイド標準

Sharp は Lovell Fuller が2013年から維持している Node.js 画像処理ライブラリです。内部的に libvips (1989年に英国ヴィクトリア&アルバート博物館で生まれた C ライブラリ) を呼び出しますが、これが ImageMagick 比で平均4-8倍速く、メモリは1/4 程度しか使いません。

2026年5月現在の安定版は Sharp 0.34 です。主要機能:

  • 入力フォーマット — JPEG、PNG、WebP、AVIF、HEIC、GIF、SVG、TIFF、PDF
  • 出力フォーマット — JPEG (MozJPEG)、PNG、WebP、AVIF、GIF、TIFF、JPEG XL (実験的)
  • 変換 — リサイズ、クロップ、回転、色空間変換、メタデータの保持 / 除去
  • 合成 — ウォーターマーク、オーバーレイ、アルファ合成
  • ICC プロファイル、EXIF、IPTC、XMP すべて処理
import sharp from 'sharp'

// 一般的な写真変換パイプライン
async function processPhoto(inputPath, outputDir) {
  const image = sharp(inputPath)
  const metadata = await image.metadata()

  // 複数サイズ + 複数フォーマットを生成
  const sizes = [320, 640, 1024, 1920]
  const formats = ['avif', 'webp', 'jpeg']

  for (const size of sizes) {
    for (const format of formats) {
      const out = `${outputDir}/photo-${size}.${format}`
      let pipeline = sharp(inputPath).resize(size, null, {
        fit: 'inside',
        withoutEnlargement: true,
      })

      if (format === 'avif') {
        pipeline = pipeline.avif({ quality: 55, effort: 4 })
      } else if (format === 'webp') {
        pipeline = pipeline.webp({ quality: 80, effort: 4 })
      } else {
        pipeline = pipeline.jpeg({ quality: 82, mozjpeg: true })
      }

      await pipeline.toFile(out)
    }
  }
}

Next.js、Astro、Nuxt、SvelteKit などメジャーフレームワークの内蔵画像処理はすべて Sharp をデフォルトで使用します。Vercel Image Optimization の内部エンジンも Sharp です。

パフォーマンスのコツ:

  • sharp.cache(false) — サーバーレス環境でメモリリーク防止
  • sharp.concurrency(1) — マルチワーカー環境で CPU 競合回避
  • sharp.simd(true) — SIMD アクセラレーション、デフォルトでオン

11. Squoosh (Google) — Web アプリ

Squoosh は Google Chrome チームが2018年に作ったブラウザベースの画像圧縮ツールです。すべてのエンコーダが WASM にコンパイルされブラウザ内で動作するため、画像がサーバーに送られることは絶対にありません。デザイナー / マーケターが1-2枚を素早く最適化するときに最も便利です。

対応エンコーダ:

  • MozJPEG
  • OxiPNG
  • WebP (Google libwebp)
  • AVIF (libaom)
  • JPEG XL (libjxl)
  • QOI
  • WebP 2 (実験的)

URL: https://squoosh.app/

# Squoosh CLI もあります (npm パッケージ)
npx @squoosh/cli --webp '{"quality":85}' --avif '{"cqLevel":33}' input.jpg

ただし Squoosh CLI は2022年以降ほぼメンテナンスが止まっており、Sharp / cwebp / cavif / cjxl などのネイティブツールが production 用途には適しています。Squoosh の Web アプリ自体は活発に更新されています。

同じポジションの他ツール:

  • ImageOptim (macOS) — ドラッグアンドドロップで可逆最適化、PNG/JPEG/GIF/SVG
  • ImageAlpha (macOS) — PNG 8ビット変換に特化
  • Pixelmator Pro — macOS ネイティブ写真エディタ、Export for Web パネルから AVIF / WebP / JPEG XL を直接出力
  • Adobe Save for Web (Photoshop) — レガシーパネルだが今も動作、Generate / Quick Export が後継
  • Figma Export — SVG / PNG / JPEG / WebP 対応、AVIF は2025年から

12. ImageMagick — クラシック

ImageMagick は1987年に始まった、ほぼあらゆる画像フォーマットを扱える万能 CLI ツールです。2026年5月現在の安定版は 7.1.x です。200種以上の入力フォーマット、ほぼあらゆる変換 / エフェクト / 合成をコマンドライン1行で処理できます。

# リサイズ + フォーマット変換
magick input.jpg -resize 800x600 -quality 85 output.webp

# 複数画像を1行で一括処理
magick mogrify -resize 1920x -format avif -quality 60 *.jpg

# テキストウォーターマーク
magick input.jpg -gravity southeast -fill white -pointsize 24 \
  -annotate +10+10 "Copyright 2026" output.jpg

# GIF を Animated WebP に
magick input.gif -define webp:lossless=false output.webp

長所は互換性と機能の豊富さ、短所は遅さとメモリ使用量です。1枚ずつ処理するのには良いですが、大量処理では Sharp / libvips の方がはるかに高速です。また、ImageMagick は過去 (2016年の ImageTragick、CVE-2016-3714 など) いくつかの RCE 脆弱性を出しており、その後も新しい CVE が継続的に登場しています。ユーザーアップロードの処理には慎重を期す必要があります。

GraphicsMagick は2002年に ImageMagick からフォークされ、安定性と性能に集中した派生版です。機能は ImageMagick より少ないですが、より堅牢です。

ImgBot (https://imgbot.net/) は、GitHub リポジトリの画像を自動で可逆最適化して PR を開いてくれるボットです。オープンソースプロジェクトは無料、プライベートリポジトリは月 $5 から。一度設置すれば、それ以降すべての新規画像コミットに対して最適化 PR が自動で届きます。

13. 韓国 / 日本 — NAVER、ピクシブの画像インフラ

韓国で最大の画像トラフィックは NAVER (ブログ、Cafe、ショッピング、ニュース) と Kakao (Daum、KakaoTalk、KakaoStory) を経由します。NAVER は自社の分散ストレージ NCloud Object Storage と内部の画像変換ゲートウェイを運用しており、外部開発者には NAVER Cloud Image Optimizer として機能を提供しています。Kakao は Daum 時代から続く独自の画像 CDN を運用しています。

日本では、ピクシブ (Pixiv) が運営する ImageFlux がマネージド画像変換サービスとしてよく知られています。URL クエリ文字列方式で imgix に類似したインターフェースを提供しつつ、イラスト / マンガといったラインアートに特化した圧縮プリセットが強みです。ImageFlux はさくらインターネット (Sakura Internet) のインフラ上で動作しています。

# ImageFlux URL 例
https://example.com/path/to/image.jpg?w=800&h=600&f=webp&q=80

ニコニコ動画 / モバゲー / GREE といった他の日本の大型サービスも独自の画像変換パイプラインを運用していますが、外部 SaaS として公開されているものとしては ImageFlux が代表的です。日本市場進出時、ImageFlux は韓国の開発者にとって知っておくと良い選択肢です。

LINE のスタンプシステムは別途独自のフォーマットを使います。APNG、MP4、WebP を組み合わせたコンテナで、静止 / モーション / エフェクトスタンプがそれぞれ異なるフォーマットでエンコードされます。

楽天、ヤフージャパン、ZOZO といった日本の大型ショッピングモールは、ほとんどが自社 CDN 上で AVIF / WebP の自動変換を運用しています。2024年から ZOZO が AVIF をデフォルトに切り替えたという発表がありました。

14. 誰が何を選ぶべきか — 写真 / イラスト / UI アイコン / 動画サムネイル

写真 (人物 / 風景 / 製品):

  • 第1候補 — AVIF quality 50-60 + JPEG (MozJPEG) フォールバック
  • 第2候補 — WebP quality 80 + JPEG フォールバック (エンコード負荷が大きいとき)
  • ユーザーアップロード元画像は保存する (再エンコード用)

イラスト / マンガ / ラインアート:

  • 第1候補 — Lossless WebP または PNG (oxipng 最適化)
  • 第2候補 — JPEG XL Lossless (Safari 17+ のユーザー比率が高ければ)
  • AVIF はラインアートでリンギング / 色にじみが見えることがあるので注意

UI アイコン / ロゴ:

  • 第1候補 — SVG (ベクター)
  • 第2候補 — PNG (oxipng) — 小サイズでの互換性が最強
  • 第3候補 — Lossless WebP — SVG が難しい複雑なラスターアイコン

動画サムネイル / ヒーロー画像:

  • 第1候補 — AVIF quality 45-55 (大解像度でも小さい)
  • 第2候補 — WebP quality 75
  • LCP 最適化のために <link rel="preload" as="image"> と併用

スクリーンショット (ブログ、ドキュメント):

  • 第1候補 — PNG (oxipng) — テキスト可読性優先
  • 第2候補 — Lossless WebP — 同じ画質でより小さい
  • 非可逆変換 (JPEG / AVIF) はテキスト可読性を下げる

ユーザーアップロード (HEIC 処理):

  • iOS アップロードは HEIC で届く → サーバー側で AVIF + JPEG に変換
  • 元画像は別途保管または即廃棄 (個人情報 / EXIF 位置情報に注意)
  • Sharp のビルド時に libheif オプションが有効か確認

アニメーション:

  • 短いクリップ (5秒未満) — Animated WebP または Animated AVIF + GIF フォールバック
  • 長いクリップ — MP4 / WebM 動画 (<video autoplay muted loop>)
  • ユーザーにダウンロードさせるなら GIF が依然として無難

2026年の新しいデフォルト:

  • Sharp 0.34 + libvips 8.16 + Next.js 15 / Astro 5 / Nuxt 3
  • AVIF + WebP + JPEG の3種を事前生成
  • CDN 側で Accept ヘッダーに基づく自動選択
  • JPEG XL は1-2年後に Chrome 復帰したら4番目の選択肢として追加検討

2026年の画像ツールは5年前より圧縮率が良くなり、自動化が単純になり、マネージド CDN の価格が下がりました。AVIF がデフォルトに座ったことでトラフィック費用が平均で半分になり、Sharp + libvips の発展でビルド時の事前エンコードが実用領域に入りました。自分のプロジェクトに合うフォーマットとツールを選び、2026年の高速インターネットの上にきれいな画像を載せてみてください。

参考 / References

Discuss on Twitter • View on GitHub