膨大な画像をどう配信・最適化するか？QiitaがImgixを選んだ理由
―― はじめに、Imgixを導入する前のQiitaが抱えていた課題について教えてください。
清野：大前提として、Qiitaは画像データが非常に多いサイトです。ユーザーが自由に記事を投稿できるUGCサイトのため、トラフィックが多く、スクリーンショットや図解画像、アニメーションGIFなど画像の種類が膨大になります。その数、現時点で100万以上にのぼります。導入前はそれらを十分に最適化できておらず、ページを開いてから画像が表示されるまでに時間がかかってしまっていました。
―― UGCならではの難しさですね。
清野：また、Markdownで記事を自由に書けるので、Qiita側のストレージにある画像だけでなく、外部サイトの画像URLも埋め込めます。最適化をするとしても、自社の画像だけならCDNでキャッシュする一般的な方法を採れますが、運営側が把握できない外部コンテンツまで含めて行おうとすると、当時なかなかフィットするソリューションが見つかりませんでした。
―― 外部画像の扱いも難しいですね。
清野：速度の問題だけではありません。QiitaのページはHTTPSで配信されているのですが、記事の中にHTTPで配信される外部画像が埋め込まれていると、安全なHTTPS通信と安全性の低いHTTP通信が同じページ内に混在する「混在コンテンツ」になり、ブラウザによっては画像の表示がブロックされる場合があります。
そこでQiitaでは、外部画像を自前のプロキシサーバーでいったん取得し、HTTPS経由で配信しなおしていました。ただし、扱う画像の形式や保存場所、元のURLの通信方式はばらばらです。そのため、一般的なCDNを追加してキャッシュするだけでは、外部画像の取得、HTTPS化、画像の軽量化などの複数の要件をまとめて満たすことが難しかったのです。
ユーザー体験を改善するには単純な画像の軽量化だけでなく、安全かつ効率的に取得・配信する仕組みをトータルで考える必要がありました。
―― これらの課題を解決するために、どのように選択肢を検討したのでしょうか。
清野：結論からお伝えすると、当時はImgixを入れるか、自前で仕組みを作るかのほぼ2択でした。国内のCDNサービスにも相談しましたが、画像最適化に加え、URLベースのWebプロキシとして外部画像を動的に取得してキャッシュできることまで求めると、なかなかフィットしなかったです。
―― 自前で作る道もあったと思うのですが、いかがでしょうか？
清野：画像最適化を本格的にやろうとすると、単にサイズを変えるだけでは済みません。色彩、圧縮率、画面サイズごとの適切な寸法、新しいフォーマットへの対応など、考慮すべきことがたくさんあり、継続的に試行錯誤しなければいけないことが容易に想像できました。当時の開発組織の状況を踏まえると、作った仕組みを保守しつづけるのは厳しかったですし、画像対応だけに多くの開発リソースを割くべきかという優先順位の問題もありました。
―― Imgix導入にあたって、費用対効果はどのように考えたのでしょうか？
清野：当時の料金体系を前提に試算すると、総コストは意外と大きく変わらなかったです。Imgixを導入すれば自前のプロキシサーバーを外せますし、CDNにキャッシュされることで発生するオリジンからの転送費も下がります。それであれば、自分たちで複雑な基盤を作りつづけるよりも、専門サービスに任せる方が合理的だと考えました。
派生画像を増やさず、キャッシュを分散させない設計
―― これまでのImgixの導入実績を踏まえて、大規模UGCサイトが画像基盤を運用するときに直面しやすい、共通している問題を教えてください。
金本：最大の難しさは、「ユーザーがどのような画像をアップロードするか」を、運営側では事前に把握しきれないことです。清野さんがおっしゃったとおり、スクリーンショットや図、アニメーションGIF、スマートフォンで撮影したHEIC形式の写真、解像度の高い巨大なPNGなど、ファイル形式も画像サイズも容量もばらばらです。
企業側が用意した画像だけを扱うサイトであれば、あらかじめ形式やサイズを統一できます。しかしUGCサイトでは、ユーザーごとに異なる画像が継続的に追加されるため、想定外の形式や極端に容量の大きい画像も含めて処理できる仕組みが必要になります。
―― 形式もサイズも異なる画像を、あらかじめ用途別に加工しておく方法もありますよね。
金本：はい。従来型の画像処理基盤では、アップロードされた元画像に対して事前処理を行い、例えば一覧画面のサムネイル用、記事本文用、拡大表示用といった複数サイズの画像（以下、派生画像）を作ります。
この方法でも一定の運用はできますが、元画像1枚に対して複数の派生画像を保存するため、画像数が増えるほど、変換処理の量とストレージ使用量が増えていきます。さらに、後からWebPやAVIFのような新しい画像フォーマットへ対応しようとすると、過去に保存した画像も含め、既存画像から新しい派生画像を作り直さなければなりません。
対象が数千枚であれば対応できても、数百万規模になると、全画像を一括処理するための計算資源や保存容量、処理状態を管理する仕組みなどが必要になります。
―― 画像の種類や表示パターンが増えるたびに派生画像も増えるので、次第に運用負荷が大きくなっていくと。
金本：Imgixでは、画像の横幅や高さ、フォーマットなどをURLのパラメーターで指定し、リクエストに応じて変換します。そのため、将来AVIFに対応するときも、既存の全画像を事前に変換して保存し直すのではなく、配信時に指定するパラメーターを変更するだけで大丈夫です。必要になった画像だけを、必要なサイズやフォーマットで生成できる点が特徴です。
―― 過去に作った全データへ一括でバッチ処理をかけ直すのではなく、配信時の指定を変えるわけですね。導入初期に気を付けるべき設計はありますか？
金本：特に重要なのが、キャッシュヒット率です。一度生成・配信した画像はCDNにキャッシュされ、同じURLへのリクエストがあれば、キャッシュされた画像を再利用できます。変換前の元画像を置いているオリジンへ毎回アクセスしたり、同じ変換処理を繰り返したりする必要がなくなるため、効率よく画像を配信できます。
例えば、使用する画像の横幅を300、600、900、1200ピクセルの4種類に決めておけば、同じURLが繰り返し呼び出されるので、キャッシュされた画像が利用されやすくなります。
一方で、リクエストのたびに300、301、302ピクセルといった異なる横幅を指定すると、それぞれが別のURL、別の画像として扱われます。ほとんど同じ見た目の画像でもキャッシュを共有できず、オリジンへのアクセスや新たな画像変換が発生しやすくなります。
―― キャッシュが分散してしまうわけですね。
金本：そのため、まずは一覧画面、記事本文、拡大表示といったUI上の用途を整理し、本当に必要な画像幅を決めることが大切です。レスポンシブ対応についても、端末や画面幅に応じて無制限にサイズを変えるのではなく、必要な段階を有限個に絞った上で、それぞれに対応するパラメーターを設定します。
もちろん、サイズだけの話ではなく、細かい体験設計の改善にも活用いただけます。例えば、画像が表示されるまで何も見えない状態だと、実際の待ち時間以上に「遅い」と感じることがありますよね。
―― はい、経験があります。そのようなサイトは離脱率が跳ね上がりそうです。
金本：この場合、画面を開いた時点ですべての画像を読み込むのではなく、ユーザーがスクロールし、画像が表示領域へ近づいた段階で読み込みを始める「遅延読み込み」のためのパラメーターがあります。最初に通信するデータ量を抑えられるため、ページの初期表示を軽くできます。
また、最初に横幅20ピクセル程度の非常に小さく軽い画像を表示し、拡大してぼかしをかけておく方法もあります。その後、高解像度の画像を読み込めた段階で、鮮明な画像へ切り替えます。画像そのもののダウンロード時間が必ず短くなるわけではありませんが、ユーザーには、画像が配置される場所やおおまかな色合いを先に示せます。
何も表示されないまま待たせるよりも、読み込みが進んでいることが視覚的に伝わるため、体感上の待ち時間を短くできると考えています。
―― それは良いですね。ちなみに、多くのパラメーターがある分、利用する側としては「何が正解か」が分かりにくいとも感じるのですが、その点はいかがでしょうか？
金本：おっしゃるとおり、Imgixには選択肢が多いからこそ、最初に「どの画面で、どのような画像を、どの品質で表示したいのか」を明確にすることが重要です。公式サイトではベストプラクティスを紹介していますし、カスタマーサクセスチームもサービスの仕様や実現したいユーザー体験を伺った上で、適したパラメーターの設計を提案しています。
投稿者が気付く「わずかな色の違い」と向き合った導入初期
―― QiitaでのImgix導入はいかがでしたか？スムーズに進みましたか？
清野：導入自体はそれほど大変ではありませんでした。もともとQiitaには、クエリパラメーターに画像URLを入れるとHTTPSで返す自前のプロキシがあり、Imgixのインターフェースとよく似ていたからです。接続先やURLを切り替えることで、大部分を動かせました。ただ、画像の最適化度合いの調整が難しく、そこは試行錯誤しながら進めました。
Qiitaユーザーの多くは、こだわりを持って記事をアウトプットしています。記事で使用した画像に少しでも色彩の変化があったり、拡大したときにわずかでも粗さがあったりしても、投稿者本人は気付く場合があります。実際に問い合わせやSNSで「オリジナルと違う」という反応も複数あり、品質と軽量化のちょうど良いバランスを探りながら進めていきました。
―― 全体へ一気に適用すると、影響範囲も大きくなりそうですね。
清野：最初から全記事へ適用せず、まずは全体の10％ほどを対象に試す形で導入し、そこから徐々に対象を広げていくという形で、段階的に進めました。意見が出たらいったん適用を戻し、設定を修正してからもう一度割合を上げる、といった具合です。
金本：写真やデザインを重視するサービスでも、色の維持は重要な論点になります。Imgixには、変換時にも元画像の色空間を保持するための「cs=origin」という指定があります。軽量化を最大限に進めるだけでなく、色を優先して圧縮を控えめにするなど、サービスごとの品質基準に合わせられます。
※具体的なパラメーター例については以下の記事でも紹介されているので、併せてご確認ください。
https://qiita.com/official-columns/interview/202607-imgix/
Imgixの標準パラメーターだけで実現しているQiitaのOGP画像
―― 標準のパラメーターでは対応できない設定をしたい場合は、どうするのでしょうか？
金本：その場合は、お客さまの課題に合わせてカスタムパラメーターを設計できます。例えば海外の化粧品関連企業のサイトでは、AIで生成した人物モデルの口紅の色を、選択した商品に合わせて変更しています。家具販売企業では、ベッドや照明、カーペットなど別々の商品を1枚の室内画像に合成しています。ほかにも、不動産画像の曇り空を晴天に変えるといったニーズがあります。
このようなカスタムパラメーターのうち、幅広い需要があるものは標準機能へ発展する場合もあります。先日リリースした「AIイメージ編集」も、カスタムパラメーターから標準機能になった事例です。
12種類の「redecorate-<style>」値（minimalistからfarmhouseまで）でインテリアをバーチャルステージングする。例えば「ai-image-edit=redecorate-minimalist」と設定することで、ミニマリストのインテリアでバーチャルステージングされる
―― 便利そうですね！現在、Qiitaでは他にどのような機能やパラメーターを使っていますか？
清野：先ほどお話ししたような画像最適化に加えて、記事のOGP画像を動的に生成する用途でも使っています。ベースとなる無地の画像を1枚用意し、記事タイトル、投稿者のアイコンやアカウント情報を、テキストや画像の重ね合わせに関するクエリパラメーターで配置します。記事ごとにリッチな画像を作れますが、画像生成用の別基盤を用意せず、Imgixの標準パラメーターだけで実現しています。
動的に生成したOGP例
記事のタイトルや、ユーザーアイコン・ユーザー名などが反映される
―― パラメーターが多いと、試した結果が違ったときに戻すのが大変ではないかとも感じますが、その点はいかがでしょう？
清野：付けるのも外すのも、クエリパラメーターを変更するだけなので自由度は高いです。URLから外した瞬間に変更が反映されるので、ステージング環境で見た目を確認し、問題がなければ、その設定をリリースできます。
この手軽さは運用だけでなく、改善の回しやすさにも効きます。派生画像を事前生成する構成だと、設定変更のたびに全画像を作り直し、保存と配信をやり直さなければなりません。Imgixならパラメーターを直して確かめられるため、PDCAサイクルを短くできます。
―― Imgix導入後、ユーザー体験と開発チームにはどのような変化がありましたか？
清野：PageSpeed Insightsなどのパフォーマンス指標が大きく改善し、体感でもページ表示が速くなりました。また、自前のプロキシサーバーを廃止できたため、保守対象も減りました。
さらに、コストを予測しやすくなったことと、配信が安定したことも大きな変化ですね。ストレージから直接配信する構成では、想定外のアクセスで転送量が跳ねる懸念がありました。しかし、Imgixに任せることでその心配もなく、Qiitaそのものの機能開発へ集中しやすくなりました。
金本：一般的な導入でも、既存のストレージへ接続し、画像URLのドメインを差し替えるところから始めます。環境が合えば、アカウント作成後、主要なクラウドストレージとAPIで接続して、15分ほどで使い始められる場合もあります。導入時に期待される主な価値として、パフォーマンス向上、制作工数の削減、画像変換基盤を自前で持たないことによる開発リソースの節約などが挙げられます。
画像最適化にとどまらない、クリエイティブ制作への活用拡大
―― 他のUGCサービスへの導入事例があれば教えてください。
金本：UGCサービスでは、Eventbrite、Exposure、Leaflyの事例が参考になると思います。イベント管理・チケット販売サービスのEventbriteでは、主催者がイベントごとに複数の画像を投稿します。導入前は1,000万枚のオリジナル画像から最大2億枚の派生画像を保存する可能性があり、内製基盤の維持にも専任のエンジニアが必要でした。Imgix導入後は、端末ごとに適したサイズと形式を配信し、画像1枚につき少なくとも100KBを削減しています。
金本：また、写真と文章を組み合わせたストーリーを公開できるExposureでは、毎週1万5,000枚以上の画像が追加されます。画面サイズや端末の向きに応じて写真グリッドを組み替える必要がありますが、必要な派生画像だけを生成・キャッシュすることで、2人のチームでも画像基盤を自前で抱えず、サービス開発に集中できています。
金本：記事、商品情報、ユーザーレビューを扱うLeaflyでは、251万枚のオリジナル画像に対し、月間4億1,600万件の画像リクエストが発生していました。Imgix導入後は画像ストレージを90％削減し、ページ速度も60％改善しています。投稿画像が増えるほど派生画像や処理基盤の負担が膨らむ点は、Qiitaをはじめとする大規模UGCサイトにも共通する課題だと思います。
―― どのような状態になったら、自前の画像処理基盤からImgixへの移行を検討すべきでしょうか？
金本：お客さまの導入目的は大きく3つあります。Core Web Vitals、特にLCPの改善につながるパフォーマンス向上、画像制作の工数削減、そして変換サーバーの保守をなくすことによる開発リソースの節約です。
最近では、AIによる背景編集やオブジェクトの追加・削除、素材感の変更など、クリエイティブ制作にも活用が広がっています。
画像を十分に最適化できているか分からない、キャッシュ設定に不安がある、派生画像や変換サーバーの保守、クリエイティブ制作に時間を取られているという場合は、まずお気軽にご相談いただければと思います。
Imgix導入の大きなメリットの一つがPDCAサイクルの短縮化
―― Qiitaでは今後、どの領域へ挑戦したいですか？
清野：現在はユーザーの投稿画像を中心にImgixを使っていますが、社内のクリエイティブ制作にも広げたいです。Qiitaでは自社で開催するイベント告知や広告バナーなどのために、多くの画像を制作しています。共通のトーンを保ちながら季節感やテーマを変え、掲載先に応じて横長や正方形などへ展開する作業を自動化したいと考えています。
―― 他の画像生成AIでもできそうな気がしますが、いかがでしょう？
清野：もちろん、画像生成AIでもできますが、生成や修正のPDCAに時間がかかる印象です。
―― たしかに、画像生成そのものに時間がかかる上に、修正してほしい箇所が適切に修正されないことも多々ありますね。
清野：Imgixのメリットの一つは、PDCAサイクルを短縮できることです。AI加工も含めてImgixを制作フローへ組み込み、ベース画像を1つ作れば、各サイズや媒体向けの画像をまとめて生成できる状態が理想です。金本さんたちとも相談しながら、画像を届ける基盤から、活用する基盤へ進めたいと考えています。
金本：他には、画像の見た目をA/Bテストする使い方も考えられます。通常、商品画像の背景色や利用シーンを変えるには、デザイナーが複数案を制作します。ImgixならURLベースで変換できるため、制作時間と費用を抑えながら検証できます。画像から動画を生成することもできるので、スピーディな配信を土台に、クリエイティブの検証へ踏み込んでほしいと思います。
―― 動画も、画像と同じように最適化できるのでしょうか？
金本：Imgix Video APIでは、動画もURLパラメーターでリサイズや切り抜き、ビットレート、コーデックなどを調整できます。人物や物を中心に保つオートクロップを使い、モバイルやSNSに合わせた配信も可能です。株式会社クラシコムさんでも、重い動画ファイルの最適化にVideo APIが活用されています。
動画はブランドや利用シーンを伝えやすい一方で、ファイルが重いため、配信の最適化が欠かせません。静止画と動画を別々の基盤で管理せず、同じURLベースの考え方で扱えることがImgixの価値です。
―― ありがとうございます。最後に、Qiita読者へメッセージをお願いします。
金本：ビジュアルは、サービスの価値やブランドをユーザーへ伝える大切な接点です。Imgixはパフォーマンス改善を出発点に、画像制作、A/Bテスト、AI編集、動画最適化までご支援できます。パラメーターの選び方に迷う場合も、ベストプラクティスとカスタマーサクセスの支援がありますので、実現したい体験から相談していただければうれしいです。
清野：URLパラメーターで変更をすぐ試せるようになると、開発と改善のサイクルそのものが速くなります。大量の画像を扱うサイトで、運用を効率化したい、ユーザー体験を良くしたい、画像を使った新しい施策を始めたいと考えているなら、試す価値があると思います。Qiitaも最初は最適化が目的でしたが、今ではOGP画像の動的生成まで活用が広がりました。先ほどお話に上がった「cs=origin」など、まだまだ使い切れていない機能があり、できることの幅が広いと感じています。
編集後記
「URLから外した瞬間に、変更の反映が終わっている」という清野さんの言葉が、とりわけ印象に残りました。画像最適化というと圧縮率や表示速度に目が向きますが、Qiitaの事例が示していたのは、改善を試し、確かめ、戻せる速さの価値です。AI時代は、この速度が非常に大事だと思うので、そこにImgixの基盤を活用できるのは目から鱗でした。画像配信を運用コストではなく、プロダクト改善の要として見直すヒントが詰まった取材でした。
取材／文：長岡 武司
撮影：平舘 平
提供：Imgix, inc.