Cloud CDNとは？Google Cloudの仕組み・キャッシュモードと料金・採用判断を実装者目線で解説

Cloud CDNは、Googleのグローバルなエッジネットワークを使い、オリジンのコンテンツを利用者に近いキャッシュから配信するGoogle CloudのCDN（コンテンツ配信ネットワーク）です。この記事では、Application Load Balancer上で有効化する仕組みと、Cloud StorageやCloud Run・GKEといったオリジンの選び方を一次情報で整理します。さらに、CACHE_ALL_STATICなど3つのキャッシュモードとTTL・キャッシュキーの設計、署名付きURLやCloud Armorによる保護、キャッシュエグレス・検索・フィルという課金モデル、そしてCloud CDNを採用すべき条件と見送るべき場面の判断基準まで、実装者が構成設計で迷う論点を具体的な数値で示します。

まとめ：Cloud CDNの仕組み・料金と採用判断の要点

Cloud CDNは、Cloud StorageのバケットやCompute Engine、Cloud RunなどのオリジンをGoogleのエッジキャッシュに載せ、利用者の近くから配信するマネージドCDNです。独立した製品というより、グローバル外部Application Load Balancerのバックエンドで「CDNを有効にする」フラグとして動く点が設計上の勘所になります。エッジにキャッシュがあれば即座に返し、なければオリジンへ遡って充填するため、オリジンへのアクセスとレイテンシの両方を抑えられます。

キャッシュの挙動はCACHE_ALL_STATIC・USE_ORIGIN_HEADERS・FORCE_CACHE_ALLの3モードとTTL・キャッシュキーで細かく制御し、料金はキャッシュエグレス（配信量）・キャッシュ検索・キャッシュフィルの3要素で決まります。静的資産の配信やロードバランサ配下のWebアプリ高速化に向く一方、大規模な動画配信ならMedia CDN、単一拠点向けの少量配信なら過剰になる場面もあります。判断に迷う実装者は、後半の採用条件と見送り条件を自社のワークロードへ当てはめてください。

Cloud CDNの仕組みとGoogle Cloud上での配信フロー

Cloud CDNを設計へ落とし込むには、まず「ロードバランサと一体で動く」という前提を押さえます。ここを取り違えると、CDN単体をどう作るかで手が止まり、オリジンやキャッシュ設定を置く場所を見失いやすくなります。

Application Load Balancer上で有効化する仕組みとオリジンの選択肢

Cloud CDNは、グローバル外部Application Load Balancer（および従来のApplication Load Balancer）のバックエンドに対してCDNを有効にすることで動きます。つまり配信の入口はロードバランサのフロントエンドIPで、その背後のバックエンドサービスやバックエンドバケットごとにキャッシュのオン・オフとキャッシュ設定を持たせる形です。ロードバランサそのものの役割や振り分け方式はロードバランサーの仕組みを解説した記事で整理しています。オリジンに指定できるのは、Compute Engineのマネージドインスタンスグループ、Cloud Storageのバックエンドバケット、Cloud RunやCloud Functions・App Engineを束ねるサーバーレスNEG、GKEのIngressやGateway、そしてインターネットNEG経由の外部オリジンです。たとえばコンテナで動くアプリならCloud Runの仕組みを解説した記事で触れているサーバーレスNEGをオリジンに据え、その前段にロードバランサとCloud CDNを重ねる構成が取れます。

CACHE_ALL_STATICなど3つのキャッシュモードの挙動と選び分け

Cloud CDNのキャッシュ挙動は、バックエンドごとに設定するキャッシュモードで決まります。既定はCACHE_ALL_STATICで、画像・動画・CSS/JSといった静的なコンテンツタイプを自動でキャッシュしつつ、明示的にキャッシュ不可とされた応答は載せません。オリジンのCache-Controlヘッダに厳密に従わせたいならUSE_ORIGIN_HEADERSを選び、キャッシュ可否をアプリ側のヘッダで完全に握ります。FORCE_CACHE_ALLは成功応答を無条件でキャッシュするモードで、オリジンのキャッシュ指示を上書きするため、ユーザー個別の機微な応答が混ざらないプライベートオリジン向けです。迷ったら既定のCACHE_ALL_STATICから始め、動的APIを厳密に制御したい箇所だけUSE_ORIGIN_HEADERSへ寄せると事故が起きにくくなります。

CDNの一般概念の中でのCloud CDNの位置づけと固有の強み

Cloud CDNはCDNというカテゴリのGoogle Cloud実装で、エッジキャッシュや配信という考え方自体はCDN全般に共通します。CDNの仕組みやキャッシュ制御の一般論、他社サービスとの選び方はCDNとは何かを実装目線で整理した記事にまとめました。Cloud CDN固有の強みは、Cloud StorageやCloud Run、GKEといったGoogle Cloudサービスと同じロードバランサ配下で完結できる点にあります。外部CDNを別途挟むより、配信までGoogle Cloud内でまとめたほうが構成も課金も見通しが立ちやすくなります。Cloud CDNはクラウドネイティブの構成技術を整理した記事でいう配信・エッジの層に当たり、コンピューティングやストレージの前段へ置く部品として捉えると設計に組み込みやすいでしょう。

Cloud CDNのキャッシュ制御と署名付きURLによるアクセス保護

Cloud CDNは単に静的ファイルを載せるだけでなく、保持期間とキャッシュの単位、そして到達範囲の制御まで細かく握れます。ここを設計すると、更新が反映されない構成やヒット率の上がらない構成を避けられます。

3つのTTLとキャッシュキーで決めるキャッシュ保持の設計方針

保持期間はTTLで制御し、Cloud CDNは3種類のTTLを持ちます。Default TTLはオリジンがCache-Controlヘッダを返さないときに適用される既定の保持期間で、初期値は3600秒（1時間）です。Max TTLはオリジンの指示より長くは保持しない絶対上限で、初期値は86400秒（24時間）。Client TTLはブラウザ側のmax-ageを制御する値で、初期値は同じく3600秒です。頻繁に変わるコンテンツはこれらを短く、更新の少ない画像やCSS/JSは長く設定します。あわせて設計するのがキャッシュキーで、既定ではプロトコル・ホスト・パス・クエリ文字列でオブジェクトを識別します。クエリ文字列はincludeやexcludeのリストで選別でき、指定ヘッダ（5個以下）やCookie（5個以下）をキーへ加えることも可能です。ここに不要な要素を含めると同一オブジェクトが別物として扱われ、ヒット率が落ちる点に注意します。

署名付きURL・negative caching・キャッシュ無効化での運用

会員向けや期限付きのコンテンツには、署名付きURL・署名付きCookie・署名付きリクエストで到達範囲を絞ります。これらはキャッシュ可能なオブジェクトへ有効期限や許可範囲を付与し、正規の署名を持つリクエストだけへ配信する仕組みです。オリジンの4xx・5xxエラーを一定時間キャッシュしてオリジンを守るnegative cachingは既定で無効なので、エラー応答の跳ね返りが多いバックエンドでは明示的に有効化を検討してください。キャッシュを即時に差し替えたいときは、キャッシュ無効化（invalidation）でパスパターンを指定して消します。ただし無効化の多用より、更新するファイルにバージョンやハッシュを付けて別URLにするほうが挙動が安定し、コストも読みやすくなります。

Cloud Armor連携とMedia CDNとの役割の使い分け

配信経路の保護は、Cloud CDNが載るロードバランサの前段にCloud Armorを組むのが基本形です。Cloud ArmorはWAFルールやIPベースのアクセス制御、L3/L4のDDoS防御を担い、アプリ層の攻撃をエッジで止めます。混同しやすいのがMedia CDNで、こちらは大規模な動画配信やOTT向けに設計された別サービスです。数万〜数百万規模の同時視聴が発生するライブ配信や大量の動画オンデマンドはMedia CDN、一般的なWebサイトやアプリの静的・動的コンテンツ配信はCloud CDN、という役割の違いで選び分けます。まずはCloud CDNで足りるかを見極め、配信規模が動画特化のスケールへ届く場合だけMedia CDNを検討すると判断がぶれません。

Cloud CDNの料金体系とキャッシュコストを抑える設計手順

Cloud CDNのコストは、同じ配信量でも課金要素の理解とキャッシュ設計の巧拙で変わります。何にいくら掛かるのかを分解し、無駄なオリジン充填を削るのがコスト設計の起点です。

キャッシュエグレス・キャッシュ検索・キャッシュフィルの課金要素

Cloud CDNの課金は主に3要素で構成されます。1つ目はキャッシュエグレスで、エッジから利用者へ配信したデータ量に応じ、配信先の地域別単価で課金されます。2つ目はキャッシュ検索（cache lookup）で、キャッシュを引く各HTTP/HTTPSリクエストに対する課金です。3つ目はキャッシュフィル（cache fill）で、キャッシュミス時にオリジンからエッジへ、あるいはリージョン間でキャッシュを充填する際のデータ転送に掛かります。なお、キャッシュ無効化のリクエストにも別途課金がある点に注意してください。月あたり500TiBを超える大量配信ではボリュームベースの割引をGoogleへ相談できるため、規模が読めるサービスは見積もり段階で確認すると設計が固まります。

キャッシュヒット率とキャッシュキーの適正化でコストを抑える実務

費用を左右する最大の要素はキャッシュヒット率です。ヒット率が上がればエッジで応答が完結し、割高になりがちなキャッシュフィルとオリジン負荷を同時に減らせます。まずTTLを用途別に設計し、更新の少ない資産は長く保持するのが基本です。次にキャッシュキーへクエリ文字列やCookie、ヘッダを無配慮に含めないよう絞り、同一コンテンツが別キャッシュとして分裂するのを防ぎます。地域別の配信単価に差があるため、利用者の分布と地域別のエグレス量をCloud MonitoringやCloud Loggingで実測し、取りこぼしの多いパスから見直すのが確実です。感覚で全部を短TTL・広いキャッシュキーに固定せず、実測値に基づいて絞り込むのがキャッシュコスト管理の勘所になります。

Cloud CDNを採用すべき条件と見送るべき場面の判断ポイント

ここでは判断を言い切ります。Cloud CDNは配信の高速化とオリジン保護に効く反面、キャッシュ設計を誤ると更新が届かない、あるいはヒット率が上がらず費用対効果を出せません。自社システムのどこにCloud CDNを差し込むかを、条件付きで見極めてください。

Cloud CDNの導入が効くワークロードの条件と設計の勘所

採用が効くのは、Google Cloud上でグローバル外部Application Load Balancerを既に使っている、または使う前提で、地理的に広い利用者へコンテンツを配りたいという条件が重なるときです。具体例は、Cloud Storageに置いた画像・動画・ダウンロード配布、Compute EngineやCloud Run・GKEで動くWebアプリの静的資産配信、キャッシュ可能なAPIレスポンスのエッジ配信などが当てはまります。オリジンからエッジへの構成がGoogle Cloud内で完結するため、外部CDNを別管理するより設定と監視の見通しが立ちます。こうしたGoogle Cloud上の配信基盤やインフラ構成を自社に取り入れるなら、AWS・Google Cloud・Azureに対応したクラウドインフラ構築の相談窓口で、キャッシュ設計やコスト見積もりを含めた構成の妥当性を相談するとよいでしょう。設計時は、まずキャッシュ可能なパスとそうでないパスを分け、キャッシュモードとTTL・キャッシュキーを用途別に決めるところから始めます。

Cloud CDNを見送る・他手段へ寄せる場面と失敗パターン

見送るべきなのは、利用者が単一拠点に固まり配信距離の短縮に意味がない社内向け用途、キャッシュできない完全に動的なレスポンスばかりの構成、そしてグローバル外部Application Load Balancerを使わない小規模な単一VM配信です。数万規模の同時視聴を伴う大規模動画配信は、前述のとおりMedia CDNへ寄せるのが筋で、Cloud CDNで無理に代替すると要件に噛み合いません。はまりやすい失敗は2つあります。1つはキャッシュキーにCookieやクエリ文字列を無配慮に含め、ヒット率が上がらず高コストと低速を招く構成です。もう1つはFORCE_CACHE_ALLをユーザー個別の応答を返すオリジンへ設定し、他人の応答がキャッシュされて配信される事故につながる構成です。キャッシュキーは必要な要素だけに絞り、無条件キャッシュは機微情報のないオリジンに限定する——この2点を前提に組めば、Cloud CDNの配信性能と保護を安全に引き出せます。

よくある質問

Cloud CDNの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Cloud CDNは単体で使えますか？ロードバランサは必須ですか？

Cloud CDNは単体の製品ではなく、グローバル外部Application Load Balancer（または従来のApplication Load Balancer）のバックエンドでCDNを有効にする形で使います。したがってロードバランサの構成が前提になります。オリジンにはCloud Storageバックエンドバケット、Compute Engineのインスタンスグループ、Cloud RunやCloud Functionsを束ねるサーバーレスNEG、GKEのIngress/Gateway、外部オリジンを指定でき、そのバックエンドごとにキャッシュを有効化する流れです。

キャッシュモードはどれを選べばよいですか？

迷ったら既定のCACHE_ALL_STATICから始めるのが安全です。静的コンテンツを自動でキャッシュしつつ、キャッシュ不可の応答は載せないため事故が起きにくい挙動になります。キャッシュ可否をアプリのCache-Controlヘッダで厳密に握りたい部分はUSE_ORIGIN_HEADERS、機微情報を含まないプライベートオリジンを丸ごとキャッシュしたい場合だけFORCE_CACHE_ALLへ寄せます。FORCE_CACHE_ALLはユーザー個別の応答を返すオリジンには使わないでください。

Cloud CDNの料金はどう決まりますか？

料金は主にキャッシュエグレス（エッジから利用者への配信量・地域別単価）、キャッシュ検索（リクエスト数）、キャッシュフィル（オリジンやリージョン間の充填）の3要素と、キャッシュ無効化のリクエストで構成されます。費用を抑える鍵はキャッシュヒット率で、ヒット率が上がるとエグレス以外のフィルとオリジン負荷を同時に減らせるのが効果的です。月500TiBを超える大量配信ではボリューム割引をGoogleへ相談できます。

Cloud CDNとMedia CDNはどう違いますか？

Cloud CDNは一般的なWebサイトやアプリの静的・動的コンテンツをロードバランサ配下で配信するCDNです。Media CDNは大規模な動画配信やOTT向けに設計された別サービスで、数万から数百万規模の同時視聴を想定したスケールに向きます。通常のWeb配信や画像・小〜中規模の動画はCloud CDN、動画配信に特化した大規模ワークロードはMedia CDN、と用途で選び分けます。

キャッシュを更新したいときはどうすればよいですか？

方法は主に2つです。1つはTTLを短く設定して自然に期限切れさせる方法、もう1つはキャッシュ無効化（invalidation）でパスパターンを指定してキャッシュを消す方法です。ただし無効化を多用すると挙動とコストが読みにくくなるため、頻繁に更新するファイルはファイル名にバージョンやハッシュを付けて別URLにするほうが安定します。更新頻度に応じてTTLと命名規則を先に決めておくと運用が楽になります。

関連記事

• CDNとは？仕組み・キャッシュ制御からサービスの選び方まで解説：Cloud CDNの上位概念であるCDN全般の仕組みとサービス選定の視点
• ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】：Cloud CDNが有効化されるApplication Load Balancerの土台
• Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを解説：サーバーレスNEGとしてCloud CDNのオリジンに据えるGCPサービス
• クラウドネイティブとは？CNCFの定義・構成技術と導入判断を解説：Cloud CDNが担う配信・エッジ層を含むクラウドネイティブ全体像