詳説 LightFile Proxy (1) サイトに手を加えず画像をWebPで配信する仕組み

一般的にWebサイトは転送量の多くを画像が占める。この画像を従来フォーマットのJPEG/PNG/GIFから次世代フォーマットのWebPに変えるだけで転送量が減り、CloudFrontの料金も下がる。しかし既存のサイトをWebPに対応させるには、システムの改修やデザイナーの画像ファイル出力作業の変更が必要になる。

弊社のLightFile Proxyは、そういった変更を必要とせず、今まで通りのシステムと運用でいつの間にか画像がWebPに変わって画像を軽量化、転送量とAWSコストを削減するための製品だ。本記事からしばらく連載として、その仕組みと機能、AWSが公式に提供するDynamic Image Transformation for Amazon CloudFront（DIT）との違いを詳しく解説したい。

転送量で決まるCloudFrontの料金 ​

CloudFrontの料金は基本的に従量課金で、AWSからエンドユーザーへ送ったデータの量とリクエストの数で決まる。2025年11月からは上限付きの定額プランも選べるようになったが、上限を超えれば上位のプランへ移ることになる。送るデータが減れば費用が下がる構造は変わらない。

では、送っているデータの中身は何だろうか。HTTP ArchiveのWeb Almanac 2025によると、デスクトップの中央値でページ全体が約2.86MB、そのうち画像が約1,058KBを占める。リソースの種類としては画像が最も大きい。

画像を軽くすればCloudFrontの請求額が下がる。どのくらい下がるのかを、東京リージョンの単価で計算してみる。

CloudFrontのデータ転送料金は段階制で、東京では最初の10TBが1GBあたり$0.114、次の40TBが$0.089という単価になっている（AWS Price List APIで取得した2026年9月時点の値）。月に10TBを配信しているサイトで計算してみる。

さきほどのWeb Almanacの中央値どおり、画像が転送量の37%を占めるサイトを想定した。その画像が半分になると、月額は$1,167から$951へ、18%下がる。画像以外の転送は変わらないので、減るのは青い部分だけになる。

転送量が増えれば差も広がる。月10TBなら年間で$2,600ほど、50TBなら$10,000ほどになる。

なお、無料枠は配信がTB単位になると相対的にかなり小さいため計算に入れていない。

ここまでは一般的なサイトの話になる。実際の通販サイトでは画像の比率がもっと高く、転送量の70%、ときには80%を画像が占める。そしてWebP変換で70%減るケースも珍しくない（(4) 次世代画像フォーマットでどのくらい軽くなるか）。同じ月10TBの配信で計算し直すとこうなる。

$1,167が$595になる。CloudFrontの従量課金がほぼ半分になる。

閲覧する側の負担も減る ​

画像を軽くすると表示も速くなる、というのが一般的な定説になっている。だが昨今の高速回線とハイスペック端末を前提にすると、残念ながら画像を軽くしただけで表示が速くなることは期待できない。表示速度は前段の処理でほぼ決まってしまうためで、これは弊社の実測でも確かめている（実例に学ぶサイトスピード改善(2) 画像は次世代フォーマットに移行する）。

いまや画像の軽量化は、数ある高速化施策のうちの一つでしかない。それでも画像が軽いに越したことはない。

むしろスピードの面より、ユーザーのモバイル通信料金の負担を軽減したり、省エネルギーによって環境に配慮したりする側面が相対的に重要になっている。 同じページを見るのに必要なデータが半分で済むなら、それは閲覧する側の負担がそのまま半分になるということでもある。

表示速度のためだけに画像を最適化していた頃から、動機が一つ増えている。

なぜ次世代フォーマットから手を付けるのか ​

画像を軽くする方法はいくつかあるが、削減幅が大きいのはWebPやAVIFといった次世代フォーマットへの移行だ。JPEGやPNGのまま圧縮を詰めるより減り方が大きい。

今や対応ブラウザも実用レベルに充実している。WebPとAVIFはどちらも主要ブラウザの対応率が95%を超えた。弊社も以前は「まだ早い」と書いていたが、そろそろWeb画像はWebPだけでよいかを書いた2024年には判断が変わっている。

ところが実際のサイトでは採用が進んでいない。弊社が国内のECサイトを300サイト調べたEC画像最適化白書では、次世代フォーマットをほとんど採用していない（全体の0〜10%）サイトが、まだ半数近くを占めている。

移行を進めるときに考える3点 ​

ではなぜ移行が進んでいないのか。次世代画像フォーマットへの移行を進める上で考えることは、大きく次の3点である。

• システムの改修。 CMSやECなどが出力するHTMLと画像URLに手を入れ、<picture>要素かサーバー側の設定で、対応ブラウザにだけWebPを配信する仕組みを入れる必要がある
• データ作成手順の変更。 デザイナーや制作会社に周知し、画像ファイルを書き出すときにWebPも出力する手順へ変える必要がある
• 過去の画像の扱い。 すでに登録された何万枚もの画像をどうするかを決めないと、新しい画像だけが対応した状態になる

どれも単独ではそこまで難しいわけではないが、一斉に調和をとって進めようとするとアーキテクチャや体制に関するスケールになる。

これが最適解だ、と自信を持ってリードしきるのは案外難しい。それで手付かずになっているのではないか、というのが弊社の見立てだ。

CloudFrontには画像最適化のオプションがない ​

このように画像最適化は思ったよりハードルが高い。そこで大手のCDNにはオプションが用意されている。追加料金を支払えば、配信する画像が自動で最適化されるというものだ。

DITはAWS公式だが、CloudFormationのテンプレートを自分のアカウントに建てて更新と監視を自分で回すもので、設定を入れるだけのマネージドなオプションとは言いにくい（(9) AWS純正のDITで代替できるか）。LightFile Proxyは、CloudFrontでImage ManagerやPolishと同じ位置をSaaSで埋める製品として作った。

配信経路に画像変換を後付けする ​

そこでLightFile Proxyは、この3つをどれも動かさずに済ませる。システムにもデータ作成の手順にも手を付けず、配信の途中でだけ画像を差し替える。置き場所はCloudFrontとオリジン（既存のWebサーバー、またはS3バケット）の間になる。

導入前の経路はこうだ。

導入後はこうなる。

CloudFrontから見ると、LightFile Proxyがオリジンに見える。LightFile Proxyはオリジンからオリジナルの画像を取りに行き、WebPに変換してCloudFrontへ渡す。CloudFrontはそれをエンドユーザーへ配信する。

このとき画像のURLは変わらない。/images/item.jpg は /images/item.jpg のままで、中身だけがWebPになる。HTMLとCMS、データ作成の手順は変わらず、オリジンに置かれているJPEG/PNG/GIFにも触れない。作業はCloudFrontの設定を数手順変えるだけで、やめるときは設定を元に戻す。

上の3つをどれも動かさずに、運営者が気づかないうちに、配信される画像だけが次世代フォーマットになる。

この連載で扱うこと ​

ここまでが全体像になる。この説明をすると、たいてい次の2つを聞き返される。

拡張子が.jpgのままで中身がWebPというのは問題ないのか。 ブラウザが画像の形式をどう判断しているかで決まる。(2) 拡張子は.jpgのまま中身をWebPにしてよいのかで仕様に当たって確かめる。

変換する分だけ表示が遅くならないか。 いつ変換するかで答えが変わる。事前に全部変換する方法、リクエストの中で変換する方法、LightFile Proxyが採っている半同期変換の3つを比べる。(3) 画像変換のタイミングとその最適解で扱う。

連載ではこのほかに、効果の測り方、画質とメタデータ、障害時の挙動、キャッシュ戦略、複数サイトの収容とそのほかの細かな特徴、AWS純正のDITで代替できるか、そして料金体系を扱っている。どの記事から読んでも構わない。