imgix は、画像の変換と最適化配信を URL パラメータだけで完結させるサービスだ。オリジン画像を 1 枚置けば、リサイズ・クロップ・フォーマット変換は URL を組み替えるだけで済む。

「URL が API」という設計

imgix の特徴は、専用の API を叩いてバッチ変換するのではなく、?w=400&fit=crop&auto=format のような URL クエリでリアルタイムに変換が走る点だ。変換結果は CDN にキャッシュされ、2 回目以降は即座に返る。フロントエンドは欲しいサイズの URL を組み立てるだけでよく、サーバー側に画像処理のコードを持たなくて済む。

auto=format を付けるとブラウザに応じて WebP / AVIF を自動選択し、対応ブラウザには軽量フォーマットを配る。顔検出ベースのスマートクロップもあり、人物写真をサムネイル化したときに顔が切れる事故を減らせる。

向く規模・向かない規模

EC サイトのように大量の商品画像を複数サイズで配信する、あるいはユーザーアップロード画像を都度リサイズする用途では、自前の画像処理基盤を置き換えるだけの価値がある。

逆に、画像枚数が少なく固定サイズで足りる静的サイトでは過剰だ。料金は変換対象画像数（Master Image）と帯域幅ベースで、画像が少なければ素朴な静的ファイル配信や CDN の方が安く済む。

Master Image 課金の読み違いに注意

料金体系で誤解しやすいのが Master Image のカウントだ。同じオリジン画像を何サイズに変換しても Master Image は 1 枚だが、オリジン側で別ファイルとして持つ画像を増やすほど Master Image 数が伸びる。ユーザー投稿でオリジン画像が際限なく増えるサービスでは、ここが主要なコストドライバになる。「1 枚から無限のバリエーション」は得意でも、「オリジンそのものが大量」だと話が変わる、と押さえておくとよい。next-gen フォーマット変換などフロントを差し替えるだけで効く施策から試すのが、コスト対効果の高い入り口だ。

元画像の管理は自分側に残る

imgix は変換と配信に特化しており、元画像の保管は自社のストレージ（S3 等）に置いたまま接続する構成が基本になる。これは「画像の所有権が自分側に残る」という利点であり、乗り換え時に元画像を持ち出せないという心配がない。一方で、ストレージの権限設定やライフサイクル管理は自分で面倒を見る必要がある。責任分界点がどこにあるかを理解して選ぶべきだ。

💡
変換パターンを絞ると課金が読めるようになります

課金の基準となる元画像の数は、変換のバリエーションを増やしても増えません。逆にいえば、レスポンシブ対応で幅を細かく刻んでも元画像数は変わらないため、変換の自由度を活かしやすい構造です。ただし際限なく変換パラメータを受け付ける実装はキャッシュ効率を下げるため、使う幅を定義しておくほうが配信性能も安定します。

署名付き URL で改変を防ぐ

変換パラメータを URL に書ける以上、第三者が任意の変換を要求できる状態になりうる。署名付き URL を有効にすれば、自社が発行した URL 以外の変換を拒否できる。公開サイトで使う場合、この設定を入れておくかどうかで、意図しない負荷や課金の可能性が変わる。導入初期に決めておきたい設定のひとつだ。