🔧 内部改善ロードマップVol.16【前編】｜CDNとキャッシュ設計で画像配信を“速く・安定・安く”する実践ロードマップ

画像配信を“速く・安定・安く”するための一番の近道は、距離を縮める（CDN） と 取り回しを賢くする（キャッシュ設計） の2つを正しく組み合わせることです。
とくに、画像点数が多いサイトや海外アクセスがあるサービス、そして更新頻度が高い運用では、この2つの設計を少し変えるだけで LCP/INPの改善・コスト削減・安定性向上 が一気に進みます。

本編（前編）では、

• そもそも CDNを導入すべき状況 とは？

• Cache-Control / ETag / stale-while-revalidate をどう使い分ける？

• WebP/AVIFなどの変換配信 は、どんな運用なら“アリ”なのか？

• 更新時に壊れない バージョン付与（cache busting） の型とは？

といったテーマを、ベンダ名や細かい数値に依存しない“普遍的な型”として整理します。

「原本を守りつつ、エッジで速く配る」
そのための設計手順を、今回の前編でしっかり固めていきましょう！

📌 本記事でわかること

• CDN導入の判断軸
  　地理（海外流入）／点数と帯域／更新頻度から判断する“導入すべき状況”がわかる

• キャッシュ設計の型
  　Cache-Control の期限・再検証・immutable、ETag／Last-Modified の使い分け
  　stale-while-revalidate の“古いまま速く”を許す条件が理解できる

• フォーマット自動変換（WebP/AVIF）の是非
  　原本管理の考え方、変換失敗時のフォールバック、CLS回避の寸法指定まで整理

• 壊さない URL・バージョン管理
  　?v= か /v/ の統一、ロングキャッシュと差し替えの両立、リンクの一貫性ルール

• 監視の最小KPI
  　ヒット率・TTFB・4xx/5xx・重い画像のP95──“とりあえずこれだけ”の監視セット

CDN導入の判断軸

CDN（Content Delivery Network）は“とりあえず入れれば速くなる”魔法の箱ではありません。
効果が出るサイトと、そこまで変わらないサイトには明確な違いがあります。
ここでは、導入の可否を判断するための3つの軸──地理／点数と帯域／更新頻度 を、実運用に沿った形で整理します。

地理と距離 — 海外流入／分散配信の必要性

画像配信の速さは、「どれだけ近い拠点から返せるか」に強く依存します。
ユーザーの多くが国内でも、海外からのアクセスが一定数あると、オリジンとの距離だけでLCPが悪化 してしまうケースはよくあります。

CDNは、この“距離の不利”を最も簡単に解消できる手段です。
エッジにキャッシュが乗ると、海外ユーザーでも国内ユーザーでも、ほぼ均等なTTFBに近づきます。
とくに以下のような状況では、CDN導入の効果が大きくなります。

• 海外SEO・海外流入が月間5〜10％以上ある

• 画像配信の地理的バラつきでLCPが安定しない

• オリジンまでの往復がどうしても長い（クラウドのリージョン固定など）

「地理的に不利な人をどう救うか？」という視点で見ると、CDNは最初に検討すべき改善ポイントになります。

点数と帯域 — 画像点数・平均サイズ・同時配信の傾向

CDNが真価を発揮するのは「点数が多い」「サイズが大きい」「同時ロードが多い」ケースです。
理由はシンプルで、“重い物”を“何度も”取りに行くほど、キャッシュの価値が跳ね上がるから です。

とくに、

• 1ページあたりの画像点数が多い（EC・ギャラリー・記事系）

• 画像の平均サイズが大きい

• 同じ画像が多ページで再利用されている

• スマホ・低回線環境が多い

こうしたサイトほど キャッシュヒットの積み上げ＝帯域コスト削減＆応答高速化 が一気に進みます。

また、CDNは「オリジンを守る盾」としても機能します。
キャンペーンやSNS流入で急にトラフィックが跳ねても、エッジで受け止められるため、オリジンのCPU・帯域の上限を気にする必要が減る のも大きな利点です。

更新の頻度 — 差し替えが多いならバージョン付与前提で検討

頻繁に画像を差し替える運用でこそ、CDN導入の価値が最大化します。
ただし“そのまま差し替えるだけ”では、キャッシュに古い版が残ってしまうため、適切なキャッシュ規律＋バージョン付与 が前提になります。

• 週次・日次で画像が更新される

• キャンペーンの差し替えが多い

• サムネイルの刷新が頻繁

• 多言語展開で画像差し替えが多い

こうした状況では、CDNで「長寿命キャッシュ」を使いつつ、更新時だけバージョン番号を変えるのが鉄板です。

「更新頻度が高い → バージョン付与が必須 → CDNと相性がいい」という構造を押さえておくと、配信面のトラブルが激減します。

以上が CDN導入の判断軸 です。
効果の強弱はサイトによって違いますが、
距離・点数/帯域・更新頻度
この3点のいずれかに該当すれば、CDNは“導入した方が速い・安定する”ケースがほとんどです。

キャッシュ規律（ブラウザ／CDN／オリジン）

キャッシュ設計は「とりあえず long cache！」で済ませられるほど単純ではありません。
画像配信では、ブラウザ・CDN・オリジン の3層がそれぞれ違う役割を持っており、どこで“どれくらいの期間”キャッシュさせるかで速度も安定性も大きく変わります。

ここでは、実運用で迷いやすい3つのポイント──
（1）三層の役割分担
（2）Cache-Control / ETag の考え方
（3）stale-while-revalidate の使いどころ
をまとめて整理します。

基本の三層 — ブラウザとCDNエッジとオリジンの役割分担

キャッシュは「どこで止めるか」がすべてです。

• ブラウザ（最も近い）
  → ユーザーと同じ端末内に保存。最速だが、更新が反映されにくい。

• CDN（エッジ）
  → 地理的に近い拠点。再利用率が高く、速度も帯域も大幅に改善。

• オリジン（原本サーバ）
  → 最後の砦。ここに来るアクセスは“できるだけ減らしたい”。

理想は、
「ブラウザとCDNでほぼ完結し、オリジンは原本を静かに守る」
という状態です。

とくに画像は再利用されるケースが多いため、
CDNエッジでキャッシュを長く保つメリットが非常に大きい のが特徴。
オリジンに到達するリクエストは“失敗時の保険”ぐらいの感覚にしておくと、安定性が一気に増します。

ヘッダ方針（概念） — Cache-Control（期限／再検証／immutable）／ETag / Last-Modified の使い分け

キャッシュ戦略では「どれくらい持たせる？」と「どう更新させる？」をセットで考えます。

代表的な要素は以下の3つです。

1. Cache-Control（期限）

画像のように比較的“壊れにくい”ものは、長寿命（数日〜数ヶ月） にするのが基本です。
ただし、長寿命にするほど“差し替えが反映されない”問題が増えるため、後述のバージョン付与が前提になります。

2. Cache-Control（immutable）

ブラウザに対し「絶対に変わらないよ」と伝える設定。
毎回の再検証すら不要になるため、LCP改善に効きやすい のが特徴です。
ただし、これを使うと差し替えミスが致命的になるため、バージョン管理とのセット運用が必須。

3. ETag / Last-Modified（再検証）

更新頻度が高い・差し替えが不規則といった運用の場合、
「常に長寿命」ではなく 短い期限＋再検証（ETagなど） をセットにする方が安定します。

• ETag：オリジン側で“中身が同じか”を判定する

• Last-Modified：最終更新時間で判定する

“キャッシュ期限を短めにしても、再検証が速いなら体感はほぼ劣化しない”
この考え方を押さえておくと、運用はかなり楽になります。

“古いまま速く”を許容する条件 — stale-while-revalidate 等の幅のある設計

画像配信では「多少古くても表示できればOK」という場面が多いです。
この“古いまま速く”を実現する代表的な設定が stale-while-revalidate。

stale-while-revalidate：

• 古いキャッシュを即返す（速い）

• 背後でこっそり新しいバージョンを取りに行く

という動きをします。

ユーザーは速く表示され、次の人は新しい画像を受け取れるため、
速度と鮮度のバランスがちょうど良い というのが最大のメリットです。

実際、以下のような状況では非常に相性が良いです。

• 更新頻度はそこそこ（週次・月次）

• “数分〜数時間のズレ”が許容される画像

• 負荷分散や障害時のリスクを減らしたい

• 海外ユーザーが多く、再検証が重くなるケース

stale-while-revalidate を中央に置いたキャッシュ設計は、
速度・帯域・安定性の三拍子がそろう万能型 と言えます。

以上が、キャッシュ規律の基本となる「三層」「ヘッダ方針」「stale-while-revalidate」の考え方です。
この型を押さえておけば、オリジンを守りながら、CDNエッジで高速に配る設計がぐっと簡単になります。

画像の自動変換配信（可否の判断）

画像配信を最適化するとき、多くの人が最初に気になるのが
「AVIF / WebP で自動変換すべき？」 という問題です。
確かに変換配信はサイズ削減効果が高く、LCP改善に効きます。
しかし、導入してはいけないケースや、運用で失敗しやすいポイントも存在します。

ここでは、原本の保存方針 → 変換配信の判断基準 → 失敗時のフォールバック → CLSを避ける寸法宣言 まで、実務に必要な“可否判断の型”として整理します。

方針 — 原本はロス少なめの安全形、配信は AVIF / WebP 優先＋フォールバック

結論から言うと、以下の形がほぼ最適解です。

• 原本（オリジンに置く画像）はロスの少ない安全形（例：JPEG 高品質 / PNG）

• 実際に配信する画像は AVIF / WebP を優先して出し分ける

理由は単純で、
変換仕様は年々変わるが、原本の品質は後から戻せない からです。

オリジンに“ギリギリまで圧縮した画像”しか残っていないと、
後からAVIFの圧縮率を改善したくても“元が粗いので上限が低い”という失敗が起きます。

その点、原本を安全形で保存しておけば、
変換エンジンやブラウザの対応状況が変わっても、
新フォーマットへ柔軟に再変換できる ため、運用の幅が大きく広がります。

失敗時の守り — クライアントが未対応でも必ず表示される経路

変換配信で絶対に避けたいのは、
「特定デバイスだけ表示されない」事故 です。

そのため、運用では次の2点が必須になります。

• WebP / AVIF が使えない環境では自動的に JPEG/PNG を返す

• 変換サーバやCDN側で失敗した時は“原本に戻す”シンプルなフォールバックを備える

特に低帯域や古いブラウザはAVIF非対応のことも多く、
“軽量化したつもりが表示崩壊”というケースは実務で何度も見かけます。

ポイントは、
「変換エラー時は迷わず原本に戻す」
これだけで、配信の安全性が一気に高まります。

メタ情報の整合 — width / height は HTML 側で固定（CLS回避）

どのフォーマットを返すにしても、CLS（Cumulative Layout Shift）対策 は必須です。
画像の横幅・高さがわからないと、読み込み途中でレイアウトが跳ねてしまい、UXもSEO評価も落ちます。

そこで大事なのが、
HTML側に width / height（または aspect-ratio）を必ず宣言すること。

• 「AVIFならこのサイズ、WebPならこのサイズ」

• 「画素密度でサイズが多少変わる」

といった揺れがあっても、HTMLで枠が決まっていればレイアウトは安定します。

フォーマット切り替えとCLS対策はセットで考えるのが鉄則です。

バージョン付与とURL設計（清書｜約900字）

画像をCDNで長寿命キャッシュさせるなら、更新時に古い版が残る問題 を必ず考えなければいけません。
ここで役に立つのが 「バージョン付与（cache busting）」 と、
それを前提に一貫性を持たせた URL設計 です。

画像の差し替えは“よくある運用”だからこそ、型を決めてしまうと更新トラブルがほぼ消えます。
ここでは、実務で迷いやすい3点──
（1）クエリ型／パス型どちらを使うか
（2）長寿命と差し替えの両立
（3）壊れリンクを出さないための一貫性ルール
を整理していきます。

クエリ型／パス型 — ?v=… か /v/… に統一してしまう

バージョン付与には大きく分けて2種類あります。

1. クエリ型（?v=202401 など）

/images/hero.jpg?v=202402

• “手軽”で既存のファイル構造を変えなくて済む

• CMSや静的サイトでも導入しやすい

• ただし、CDNによってはクエリを分岐として扱わない設定もあり、ヒット率がぶれやすいことも

2. パス型（/v/202402/hero.jpg）

/v/202402/hero.jpg

• CDNのキャッシュキーと相性が良い

• バージョンごとに完全に別URLとして扱われるため、古い版が干渉しない

• ディレクトリを追加する必要があるため、若干手間

どちらでも良いのですが、もっと大事なのは
“どちらかに統一して、全画像で同じルールを使う” こと。
これだけで更新トラブルは大幅に減ります。

長寿命×差し替え — ロングキャッシュ＋バージョン更新で両立させる

画像は本来、キャッシュを長くした方が速く・安く・安定 します。
しかし、長寿命キャッシュにすると“差し替えても古い版が残る”という問題が発生します。

そこで使うのが、
「ロングキャッシュ」＋「バージョン付与」
という組み合わせです。

• 通常時はキャッシュを長く保持し（CDN／ブラウザともに長寿命）

• 差し替え時だけバージョン番号を更新して新URLを発行する

こうすることで、

• LCP改善につながる“長寿命キャッシュ”

• 壊れ更新を防ぐ“確実な差し替え”

この2つが同時に成立します。

特に更新頻度が高いサイトでは、この型を取るだけで運用が劇的に楽になります。

壊れリンク防止 — 差し替え時の参照の一貫性ルールを決める

バージョン付与を導入しても、リンクの更新が不統一 だと意味がありません。
実務でよくあるトラブルは以下のようなパターンです。

• Aページは新バージョン、Bページは旧バージョンを参照してしまう

• CMSの一部だけ古いURLのまま残っている

• バージョン更新漏れが数ページだけ発生する

こうした“局所的なズレ”を防ぐには、
差し替え時の更新手順を1本にまとめる のが最も効果的です。

例：

• 「hero.jpg を更新する場合は CMS 全ページを一括置換」

• 「/images 配下に関する変更は、全テンプレートの diff を取ってから反映」

• 「バージョン番号は build 時に自動生成し、手動では触らない」

細かい運用ルールはサイトにより異なりますが、
“人が手で更新しないといけないところを極力減らす” のが鉄則です。

以上が、画像配信で欠かせない「バージョン付与とURL設計」の型です。
長寿命キャッシュと差し替え運用を両立させるうえで、
統一ルール × 自動化 × 明確な参照管理
この3つがそろうと、更新トラブルはほぼゼロになります。

監視の最小KPI（毎週／毎月）（清書｜約700字）

画像配信は「入れて終わり」ではなく、“壊れていないか”を定期的に確認する運用 が欠かせません。
とくに CDN × キャッシュ戦略では、設定そのものはシンプルでも、
更新や負荷変動で思いがけずヒット率が落ちたり、TTFBが跳ねたりすることがあります。

ここでは、毎週／毎月チェックしておくべき最低限のKPI を、実務で使える形に絞って整理します。

CDNヒット率／エッジTTFBの中央値／4xx/5xxの分布

まず押さえるべきはこの3つです。

1. CDNヒット率

• 「どれだけエッジで返せているか」の指標

• ヒット率が急に下がったら、バージョン更新漏れ・パスの揺れ・クエリ乱立 を疑う

• 画像点数が多いサイトでは最重要

2. エッジTTFB（P50 / P95）

• 画像の“最初のバイト”が届くまでの時間

• 地理分布の確認で、海外ユーザーの体感差も分かる

• P95（上位5％の遅いケース）が劣化していたら、エッジの再検証増加・オリジン負荷増大 を疑う

3. 4xx / 5xx の分布

• 404（壊れリンク）

• 403（権限系の誤設定）

• 500系（オリジン側の不調）

画像は“壊れているのに気づかれにくい”ため、この3集合は必ず追うべき領域です。

重いオブジェクト上位 — サイズ／応答のP95で把握

月次レベルでは、“重い画像のトップ10〜20” を把握するだけでもかなり差が出ます。

• サイズが極端に大きい

• 実寸に対して過大（2〜4倍）

• 画像形式が古い（PNG大型／非圧縮JPEG）

こうした“問題児画像”は、1つ直すだけで全ページの速度が改善する 場合があります。
特にEC・記事メディアのように、サムネイルの点数が多いサイトでは一撃の効果が大きい部分です。

実務ログテンプレ

毎週／毎月チェックする際は、次のログテンプレがシンプルで使いやすいです。

期間 | パス/パターン | ヒット率 | TTFB P50/P95 | 平均サイズ | 対応（圧縮/変換/期限調整） | 備考

• パス/パターン：画像グループごと（/hero/, /thumb/, /banner/）で集約

• ヒット率：50％→70％に上がるだけでも体感が大きく変わる

• TTFB P95：海外向けの遅延・再検証増大が如実にわかる

• 平均サイズ：過大配信の“気づき”の指標

• 対応欄：圧縮・変換・キャッシュ期限の微調整などを記録

とくに“改善後の変化”を並べておくと、次の施策判断が格段に楽になります。

以上が、画像配信の“壊れ”を防ぐために最低限押さえるべき監視KPIです。
CDN×キャッシュ戦略は、設定そのものよりも “動き続ける環境を見守る” ことのほうが重要です。

用語ミニ辞典

CDN（Content Delivery Network / エッジ配信）

ユーザーに近い拠点（エッジ）に画像をキャッシュし、距離と再取得の負荷を減らす仕組み。
“原本を守りつつ速く配る”ための基盤で、海外アクセスや画像点数が多いサイトほど効果が高い。

stale-while-revalidate（SWR）

キャッシュが古くても “すぐ返す” ことで体感速度を保ちつつ、裏側で 新しい版を取得する 仕組み。
鮮度とスピードのバランスが良く、更新頻度が中程度の画像配信と相性がいい。

ETag（エンティティタグ）

“中身が同じかどうか”をサーバ側で確認するための識別子。
キャッシュ期限が短い場合でも、軽い再検証で更新可否を正確に判断できるため、差し替えの多い運用で役に立つ。

以上が前編で登場する主要概念の要点です。
“どのレイヤーで何をコントロールしているか”を理解すると、画像配信の設計がぐっとシンプルに見えてきます。

前編の本文はこれで全H2/H3の清書が揃いました。
次は以下から選んでください：

1. 前編 全体の最終整形（タイトル〜まとめまで一つの本文として統合）

2. 後編（Vol.16【後編】）の清書へ進む

3. アイキャッチ画像生成用のプロンプトを作成する

番号で教えていただければ作業を続けます！

今回はここで終わりにしたいと思います！

最後までお読みいただきありがとうございました！

このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶

むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁

私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、

LINEスタンプのキャラ制作に挑戦したりしています👍

デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！

ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。

アイデアが出ないときも、相棒みたいに助けてくれます🎶

さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、

X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅

「AIって便利そうだけど、自分にも使えるのかな？」

と思っている人には、ぜひ読んでほしいです。

このブログは、AI初心者でも副業が始められるように、

体験ベースでわかりやすく書いています。

私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。

Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！

明日のあなたがより豊かになりますように😌

それでは、おやすみなさい😴