はじめに
Webサイトやアプリのパフォーマンス改善（Core Web Vitalsの向上など）において、最も手っ取り早く、かつ効果が高い方法として「画像の最適化」が挙げられます。
皆さんは、JPEGやPNGに代わるWebPやAVIFといった次世代フォーマットを正しく理解し、プロジェクトに導入できているでしょうか？
前半でフォーマットの特徴を整理し、後半でコスト試算を行います。
1. 知っておくべき次世代画像フォーマット
まずは、現在主流となっている（または意識すべき）フォーマットをおさらいします。
WebP（ウェッピー）
- 開発元: Google
-
特徴:
- 現在のWeb標準とも言える「大本命」のフォーマット。
- 非可逆圧縮（JPEGの代替）と可逆圧縮・透過（PNGの代替）、さらにアニメーション（GIFの代替）のすべてを1つのフォーマットでカバーできます。
-
サポート状況:
- 主要なモダンブラウザの97%でサポート済みです。
- よくある質問 | WebP | Google for Developers
AVIF（エーブイアイエフ）
- 開発元: Alliance for Open Media
-
特徴:
- 最新の動画圧縮技術（AV1）を応用した、WebPのさらに次を行くフォーマット。
- WebPよりも20〜30%ほどファイルサイズを小さくでき、バンディング（グラデーションの縞模様）も出にくく高画質です。
- ただし、画像をAVIFに変換（エンコード）する際のサーバーのCPU負荷が非常に高いという弱点があります。
-
サポート状況:
- 現在の主要モダンブラウザで幅広くサポートされています。
- Image file type and format guide - Media | MDN
HEIC / HEIF（ヒーフ）※番外編
-
特徴:
- iPhoneの標準カメラで撮影した写真の保存形式。JPEGの半分の容量で同等の画質を保ちます。
-
注意点:
- ライセンス（特許）の都合上、Webブラウザでの表示は事実上Safariに限定されます。そのため、Webサイトにそのまま表示することは現実的ではなく、「ユーザーがアップロードしてきたHEICを、サーバー側でWebP等に変換して配信する」という処理が必須になります。
2. 既存フォーマット（JPEG / PNG）との詳細比較
従来のフォーマットと次世代フォーマットを、用途や得意分野を含めて比較表にまとめました。
| フォーマット | 得意な画像（用途の特色） | メリット | デメリット | 結論・使い所 |
|---|---|---|---|---|
| JPEG | 写真、グラデーションなど色数が多い画像 | 互換性100%、エンコードが速い | 透過不可、ファイルサイズが大きい | 旧ブラウザ向けの予備（フォールバック）用 |
| PNG | 単色塗り、線画、ロゴ、透過が必要な画像 | 透過が可能、画質が劣化しない（可逆） | 写真に使うとファイルサイズが爆発する | アイコンの原本、旧ブラウザ向け透過画像 |
| WebP | 万能（写真からイラスト、アニメまで） | 軽量、透過・アニメ対応、変換が速い | ごく一部の古い環境で非対応 | 現在のデフォルト。 基本は全画像をWebP化 |
| AVIF | 写真、高画質な透過画像 | 最強の圧縮率、高画質、透過対応 | 変換（エンコード）処理が非常に重い | インフラコストが許容できれば積極的に採用したい形式 |
3. WebPやAVIFへの変換方法（書き出し）
次世代フォーマットを実際の業務でどうやって用意するのか、主流な方法を紹介します。
🛠️ 手軽なWebツールで変換（Squoosh）
Googleが提供している Squoosh（スクッシュ） という無料のWebアプリが簡単で便利です。
ブラウザ上に画像をドラッグ＆ドロップするだけで、JPEG/PNGからWebPやAVIFへリアルタイムに画質と容量を見比べながら変換できます。
実際に動かしてみるとわかりますが、WebPへの変換はすぐ完了しますが、AVIFへの変換には数秒かかります。
💻 開発・サーバーサイドでの自動変換
実際のWebサービスでは、以下のような仕組みで一括・自動変換を行うのが一般的です。
- ImageMagick / FFmpeg: コマンドラインやバックエンド処理での変換
- CDNのエッジ処理: CloudflareのImage Resizingや、AWS（CloudFront + Lambda@Edge）、imgixなどのサービスを使い、アクセス時に自動で最適なフォーマット（AVIF優先、次点でWebPなど）に変換して配信する構成がモダンです
4. 試算
｢JPEG画像をWebP/AVIFに変換すべきか？｣AWSにホスティングされるWebサービスで、S3・CloudFront・Lambdaのコストから検証してみましょう。
Webサービスでユーザーがアップロードした JPEG 画像を、そのまま配信するか、WebP や AVIF に変換して配信したケースを想定してみます。
「次世代フォーマットのほうが軽い」というのは周知の事実ですが、変換処理にも当然コストがかかります。AWS 上での具体的なコストを試算し、本当にペイするのか を数字で検証します。
前提条件
| 項目 | 値 |
|---|---|
| 元画像（JPEG） | 平均 500KB/枚 |
| 月間アップロード数 | 10万枚 |
| 1枚あたりの月間表示回数 | 10回（= 月100万リクエスト） |
| リージョン | ap-northeast-1（東京） |
| 配信 | CloudFront 経由 |
| 変換処理 | Lambda + ImageMagick |
各フォーマットの圧縮率は以下を想定します。
| フォーマット | 圧縮後サイズ | JPEG比 削減率 |
|---|---|---|
| JPEG（そのまま） | 500KB | — |
| WebP | 250KB | 50% |
| AVIF | 150KB | 70% |
コスト試算
S3 保存料金
S3 Standard の料金は約 $0.025/GB/月です。
| フォーマット | 月間保存量 | 料金 |
|---|---|---|
| JPEG | 50GB | $1.25 |
| WebP | 25GB | $0.625 |
| AVIF | 15GB | $0.375 |
保存料金は月々のアップロード分が累積していく点に注意してください。2ヶ月目以降は差額がどんどん拡大します。
CloudFront データ転送料金
日本向け配信の場合、最初の 10TB まで約 $0.114/GB です。
| フォーマット | 月間転送量 | 料金 |
|---|---|---|
| JPEG | 500GB | $57.00 |
| WebP | 250GB | $28.50 |
| AVIF | 150GB | $17.10 |
ここが最大のコスト要因です。 画像フォーマットの選択が月額コストに最も大きく影響するのは、保存料金ではなくデータ転送料金であることがわかります。
Lambda 変換コスト
Lambda の料金（x86アーキテクチャ・東京リージョン）は $0.0000166667/GB-秒 + $0.20/100万リクエスト です。
※10万リクエストあたりのリクエスト料金は $0.02 となります。
各フォーマットの変換パラメータと月間コストは以下の通りです。
| フォーマット | メモリ | 実行時間/枚 | 月間コスト（リクエスト料金込み） |
|---|---|---|---|
| JPEG | — | — | $0 |
| WebP | 512MB | 約1秒 | $0.85 |
| AVIF | 1024MB | 約7秒 | $11.69 |
WebP の変換コストが非常に安い（\$0.85/月）のに対し、AVIFは約14倍（\$11.69/月）のコストがかかります。
AVIF のエンコード（libaom）は計算量が多く、メモリ&実行時間どちらも大きくなるためです。
総コスト比較
| 項目 | JPEG | WebP | AVIF |
|---|---|---|---|
| S3 保存 | $1.25 | $0.63 | $0.38 |
| CloudFront 転送 | $57.00 | $28.50 | $17.10 |
| Lambda 変換 | — | $0.85 | $11.69 |
| 合計 | $58.25 | $29.98 | $29.17 |
| JPEG比 削減額 | — | -$28.27/月 | -$29.08/月 |
| 年間削減額 | — | -$339 | -$349 |
考察
WebP 変換は明確にペイする
JPEG → WebP の変換は、Lambda のコスト（\$0.85/月）に対してデータ転送の削減効果（$28.50/月）が圧倒的に大きく、投資対効果は約33倍 です。
また今回の試算はJPEGからの変換を例にしていますが、PNGの場合は一般的にJPEGよりサイズが大きいため、変換効果はさらに顕著になることが想定できます。
AVIF は「計算コスト」が転送量削減を食いつぶす
WebP → AVIF に切り替えた場合の追加削減額は、わずか $0.81/月 (\$29.98 - \$29.17) にとどまりました。
AVIFはファイルサイズが小さくなるためCloudFrontの転送コストは大きく下がりますが、その削減分をLambdaの重い計算コストが見事に食いつぶしてしまう構図が浮き彫りになりました。
AVIF 特有の運用リスク
コスト面以外にも、AVIF には以下の運用上の考慮点があります。
Lambda のタイムアウトリスク
平均7秒はあくまで目安で、高解像度画像では15〜20秒かかるケースもあります。タイムアウト設定に余裕を持たせ、リトライや DLQ（デッドレターキュー）の設計が必要です。
同時実行数の圧迫
処理時間が WebP の約7倍なので、同じスループットを出すには7倍の同時実行数を消費します。バースト的なアップロード（キャンペーン時など）では、Lambda の同時実行数上限（デフォルト1,000）に到達するリスクがあります。
メモリ消費
WebP が 512MB で済むのに対し、AVIF は 1024MB、高解像度では 1536〜2048MB が必要になるケースもあります。
ブラウザ対応率
WebP は約97%以上のブラウザで対応していますが、AVIF は約93%程度です。
詳細な対応バージョンは下記リンクなどから確認ができます。
結論：どのフォーマットを選ぶべきか
まず WebP 変換を検討する
変換コストは極めて安く、データ転送コストの削減効果が大きく、ブラウザ対応率も十分で、運用も簡単です。
AVIF は「画像の表示回数」が多い規模で検討する
今回の試算（1枚あたり月10回表示）ではAVIFのコストメリットはほぼゼロでしたが、画像表示回数が圧倒的に多いサービス（例：1枚あたり月100回、1000回表示されるなど）であれば、1回の変換コストを多大な転送量削減で回収できるため、AVIFが活きてきます。
逆に小〜中規模であれば、運用の複雑さと計算コストに見合わない可能性が高いです。
理想的な構成
余裕があれば、アップロード時に WebP と AVIF の両方を生成し、CloudFront Function で Accept ヘッダーを見て出し分ける のがベストです。
S3 保存料金の増分は微々たるもの（+$1/月程度）なので、対応ブラウザには AVIF、非対応には WebP を返す構成が最も効率的です。
ただし、パイプラインの複雑さとトレードオフになるため、サービスの規模感に合わせて判断する必要が出てきます。
補足：コストに現れないメリット
本記事ではコストにフォーカスしましたが、画像の軽量化にはコストに現れない効果もあります。
- ページロード時間の短縮 → UX 向上、直帰率の低下
- Core Web Vitals（LCP）の改善 → SEO へのポジティブな影響
- CloudFront キャッシュ効率の向上 → 容量が小さい分、同じキャッシュサイズでより多くの画像をエッジに保持可能
これらを加味すると、画像フォーマットの最適化は金銭的なコスト削減以上の価値があると言えます。