「その画像、重すぎます。」AVIF / WebP 自動変換でサイトを半分にする、AWS Lambda 画像パイプラインの構築

そう言われてPageSpeed Insightsを開くと、警告の筆頭にあるのは常にこれです。

「次世代フォーマットでの画像の配信」。

テキストコードをどれだけ圧縮しても、たった1枚の巨大なヒーロー画像の容量には敵いません。Webの通信量の平均60%以上は「画像」が占めているからです。

しかし、デザイナーに「Photoshopで一枚ずつWebPに書き出して、スマホ用にリサイズして…」とお願いするのはナンセンスです。それは人間の仕事ではありません。

本記事では、JPGやPNGをS3に放り込むだけで、**勝手に最新の軽量フォーマット（AVIF/WebP）に変換・最適化される「画像自動処理パイプライン」**のアーキテクチャを解説します。

---

第1章：なぜ「JPG」では戦えないのか？

長年、Webの主役はJPEG（JPG）とPNGでした。しかし、これらは「過去の遺物」になりつつあります。

Googleが開発したWebP、そしてさらに新しいAVIFの登場により、圧縮率は劇的に進化しました。

圧倒的なサイズ差

同じ画質の画像を用意した場合、サイズ感はこれほど違います。

フォーマット	サイズ	特徴	評価
JPEG (Original)	100 KB	汎用性は高いが、圧縮ノイズが目立つ。	🔺 遅い
WebP	70 KB	JPGより30%軽い。現在のWeb標準。	⭕️ 必須
AVIF	50 KB	JPGの半分。画質も維持される次世代規格。	SS 最強

これを見れば、**「すべての画像をAVIFにする」のが正解です。

しかし、問題があります。「古いブラウザがAVIFに対応していない」ことと、「変換の手間がかかる」**ことです。

この2つの問題を、AWSのアーキテクチャで解決します。

---

第2章：人間が変換するのをやめなさい

解決解決策は、**「サーバーレス画像パイプライン」**の構築です。 運用フローは以下の通りです。

1. 運用担当者は、いつもの JPG/PNG をそのまま S3（クラウドストレージ）にアップロードする。
2. 以上。

裏側では、以下のシステムが全自動で稼働します。

アーキテクチャ構成図 (AWS)

1. Trigger: S3にファイルが置かれた瞬間、**AWS Lambda（関数）**が起動。
2. Process: Lambdaが画像を処理し、image.webp や image.avif を生成。
3. Output: 最適化された画像群を、公開用のバケットに保存。

これにより、人間は画質やフォーマットを気にする必要がなくなります。**「置けば、軽くなる」**魔法の箱の完成です。

アーキテクチャ構成図 (AWS)

1. Trigger: S3にファイルが置かれた瞬間、**AWS Lambda（関数）**が起動。
2. Process: Lambdaが以下の処理を並列実行。
   • リサイズ: スマホ用（幅400px）、PC用（幅1200px）を生成。
   • 変換: 元画像から image.webp と image.avif を生成。
   • 圧縮: 画質を人間が気づかないレベル（Quality: 80%程度）まで落とす。
3. Output: 最適化された画像群を、公開用のS3バケットに保存。

これにより、人間は画質やフォーマットを気にする必要がなくなります。**「置けば、軽くなる」**魔法の箱の完成です。

---

第3章：実装の勘所「Sharp」と「CloudFront」

この仕組みを自社開発する際の、技術的なポイントを2つ紹介します。

1. Node.js最速の画像処理ライブラリ「Sharp」

Lambdaの中で動かすエンジンには、sharp を採用します。

ImageMagickなどの従来ツールに比べ、圧倒的に高速でメモリ消費も少ないため、従量課金のLambdaコストを最小限に抑えられます。

例）JavaScript

// Lambda内での処理イメージ
const sharp = require('sharp');

await sharp(inputBuffer)
  .resize({ width: 800 }) // リサイズ
  .avif({ quality: 65 })  // AVIF変換（品質65でも十分綺麗）
  .toFile('/tmp/output.avif');

2. CloudFrontによる「出し分け」戦略

AVIFは最強ですが、古いブラウザ（IEなど）では表示できません。

そこで、配信サーバーである Amazon CloudFront の機能を活用します。

ブラウザからのリクエストヘッダー（Accept）を見て、自動で出し分けます。

• Chromeユーザーには 👉 AVIF を返す（爆速）
• 少し古いSafariには 👉 WebP を返す（高速）
• ガラケーなどには 👉 JPG を返す（互換性）

アプリケーション側（HTML）は <img src="image.jpg"> と書いておくだけでOK。CloudFrontが裏で賢くファイルを差し替えてくれます（※Lambda@Edgeの活用、または <picture> タグの併用による）。

---

第4章：WordPressプラグインじゃダメなのか？

画像を作っても、配り方が間違っていては意味がありません。 AVIFは最強ですが、古いブラウザ（例えば古いiPhoneやInternet Explorer）では表示すらされません。

そこで、Amazon CloudFront（CDN） の出番です。 CloudFrontには、相手に合わせて出し分ける**「コンテンツ・ネゴシエーション」**という機能を持たせることができます。

「パスポート」を確認する入国審査官

ブラウザが画像を取りに来るとき、実はこっそりと「自分が見れる形式」を宣言しています（リクエストヘッダーの Accept 情報）。CloudFrontはこれを見て判断します。

• Chrome君: 「僕はAVIFが見れます！（パスポート提示）」
  • CloudFront: 「よし、君にはAVIF画像を渡そう。」
• 古いiPhone君: 「僕はJPGしか見れません…」
  • CloudFront: 「OK、君にはJPG画像を渡そう。」

HTMLは書き換えなくていい

素晴らしいのは、WebページのHTMLコードは <img src="photo.jpg"> と書いておくだけで良いという点です。 URLは .jpg のままですが、CloudFrontが裏側で中身を .avif にすり替えて配信してくれます。

これにより、**「最新のiPhoneユーザーには爆速体験を、古い端末ユーザーには確実な表示を」**自動で提供できるのです。ろうが、「画像配信基盤」として永続的に使い回すことができます。 これがアーキテクチャへの投資価値です。

---

まとめると、資産（アセット）を負債にするな

高解像度の写真は、ブランドイメージを高める**「資産」ですが、Webにおいては表示速度を殺す「負債」**になり得ます。

その負債を解消するために、デザイナーの時間を浪費してはいけません。

「アップロードしたら自動で最適化」。

このパイプラインを一度構築すれば、あなたのサイトは永続的に、LCP（最大視覚コンテンツの表示速度）のスコア改善という恩恵を受け続けることになります。

---

👇 【あわせて読みたい】「0.1秒」の遅れが命取りになる理由

【UX】Amazonはなぜ「0秒」で切り替わるのか？ 知覚パフォーマンスの設計論

画像を軽くした後は、それを見せる「タイミング」を最適化しましょう。
ユーザーの脳をハックする「プリフェッチ」や「Optimistic UI」について解説しています。

👉 記事を読む：知覚パフォーマンスと3つの実装パターン

:

👇 【基盤】AWSで「自動化」する技術

【AWS】UXを爆速にする「非同期処理」アーキテクチャ

本記事のLambdaと同様に、バックエンド処理を自動化・非同期化する「SQS × Lambda」の基本構成についてはこちら。

👉 記事を読む：AWSによる非同期ログ基盤の構築手法

---

👉 記事を書いた人