CDNをどこまで前に置くかの設計 — エッジに載せる範囲とオリジンへの通し方

CDN設計で最初に問われるべきは「何をエッジに載せるか」ではなく「何を載せてはならないか」の線引きです。キャッシュ可能なコンテンツと動的処理を混在させたままCDNを前段に置くと、認証漏れ・キャッシュ汚染・オリジン負荷の集中が連鎖します。本記事では、エッジに載せる範囲の判断基準、プロバイダ選定、キャッシュ戦略、SSL終端設計、監視設計、そして現場でよく踏まれる落とし穴を、構築の意思決定の観点から整理します。

CDNが効くコンテンツとエッジに載せてはいけないコンテンツの判断

キャッシュヒット率が見込めるコンテンツの条件

CDNが有効に機能するのは、同一のレスポンスを複数のリクエストに返せるコンテンツです。画像・CSS・JavaScriptといった静的アセット、共通ヘッダーやフッターのHTMLフラグメント、APIのうちユーザーに依存しないマスターデータのレスポンスなどが代表例です。これらはキャッシュヒット率が80〜90%以上に達しやすく、オリジンへの負荷軽減効果が顕著に出ます。判断の基準は「このレスポンスはリクエストした人が誰であっても同じか」という一点です。ユーザーIDに依存しない、セッションを参照しない、かつ一定期間は内容が変わらない——この3条件がそろえばキャッシュ対象として検討できます。逆に言えば、3条件のうち一つでも崩れた場合は設計に慎重さが必要です。

載せてはいけないコンテンツの特徴

「エッジに載せてはいけない」コンテンツの特徴は、リクエストごとにレスポンスが変わる可能性があるという点に集約されます。カート情報・ログイン後のダッシュボード・パーソナライズされたレコメンドは、ユーザー単位でレスポンスが異なるため、誤ってキャッシュすると別ユーザーに他者の情報が返るという重大なインシデントに直結します。管理画面やAPIの書き込み系エンドポイント（POST/PUT/DELETE）はCDNをバイパスさせるのが原則です。CDNによってはPOSTリクエストをキャッシュしない設定がデフォルトになっていますが、ミドルウェアの設定やHTTPレスポンスヘッダーの誤設定でキャッシュが有効になるケースが報告されており、「デフォルトで安全」という過信が事故の温床になります。

判断フロー — エンドポイント分類の手順

以下のフローで各エンドポイントを分類すると、設計判断を統一しやすくなります。チームで共有するルールとして定めておくことで、新規エンドポイントが追加された際の判断ブレを防げます。

1. レスポンスはリクエストしたユーザーに依存するか？ → Yes: CDNバイパス確定 / No: 次へ
2. 認証・セッション情報をレスポンス生成に使うか？ → Yes: CDNバイパス確定 / No: 次へ
3. レスポンスに Set-Cookie ヘッダーが含まれるか？ → Yes: キャッシュ除外を強く推奨 / No: 次へ
4. 書き込み系HTTP動詞（POST/PUT/PATCH/DELETE）か？ → Yes: CDNバイパス確定 / No: 次へ
5. レスポンスは最低60秒間は変化しないか？ → Yes: キャッシュ候補として設計 / No: バイパスまたは短TTL

CDNプロバイダの選定 — オリジンとの距離・キャッシュ制御・価格比較

選定の主要判断軸

CDNプロバイダの選定では、PoP（接続ポイント）の地理的分布、オリジンとの接続方式、キャッシュ制御の柔軟性、ログ出力の形式の4軸で比較するのが現場での定番です。エンドユーザーが国内中心なら国内PoPの密度が高いプロバイダを選ぶのが基本ですが、オリジンが海外リージョンにある構成では、CDNがオリジンまでどのルートで通信するかも確認が必要です。オリジン接続方式の差は、キャッシュミス時のフォールバック速度に直結するため、動的コンテンツの比率が高い構成では無視できません。

オリジンとの距離と接続方式

オリジンとCDNエッジ間の通信は「公衆インターネット経由」と「プロバイダのバックボーン経由」で品質が大きく変わります。CDNプロバイダが自社バックボーンを持っている場合、エッジからオリジンまでの往復レイテンシが公衆インターネット経由より20〜40ms程度改善されるケースがあります。オリジン側にはCDNからのみアクセスを許可するIP制限をかける設計が一般的で、CDNプロバイダが提供するIPレンジをアローリストに登録し直接アクセスを遮断することで、CDNをバイパスした攻撃やキャッシュを迂回した不正アクセスを防ぎます。この設定を後から追加しようとすると既存の運用との整合を取る工数がかかるため、構築当初から組み込む方針にしておくことが重要です。

主要プロバイダ比較

観点	Cloudflare	AWS CloudFront	Fastly
国内PoPの密度	東京・大阪など複数拠点	東京・大阪	東京・大阪
キャッシュ制御の柔軟性	Cache Rules / Workers	Cache Policy + Lambda@Edge	VCL / Compute@Edge
動的コンテンツの扱い	Argo Smart Routing対応	オリジンシールド対応	即時パージ・細粒度制御
ログ出力形式	Logpush（S3/BigQuery等）	CloudWatch / S3	Real-time Log Streaming
証明書管理	自動更新・無料	ACM連携	自動更新対応
オリジン接続	Argo / 自社バックボーン	AWS内部ネットワーク優先	自社バックボーン

選定に際して重要なのは、既存インフラとの統合コストです。オリジンがAWSリージョン内にある場合、CloudFrontはS3やALBとの統合が直接行えるため、設定工数が他プロバイダの3分の1程度で済むケースも多く、AWS利用環境では有力な候補になります。一方でキャッシュルールの細粒度制御や即時パージの応答速度を優先する場合、Fastlyの設計柔軟性が選定理由になります。

キャッシュ戦略の設計 — TTL・バリエーション・パージ方針の決め方

TTLの設計原則

TTL（Time To Live）はコンテンツの更新頻度と整合性要求で決まります。画像・フォントなどのアセットは1年（31,536,000秒）のTTLを設定しバージョニング（ファイル名にハッシュを含める）で鮮度管理するのが標準です。HTMLドキュメントはコンテンツ更新の頻度に応じて60〜600秒の範囲で設定するケースが多く、リアルタイム性が求められるコンテンツはキャッシュTTLをゼロにして実質バイパスとする設計も選択肢に入ります。TTLの設定は、HTTPレスポンスヘッダーの`Cache-Control`をオリジン側で明示的に返す方法と、CDNのルール設定で上書きする方法の2系統があります。オリジン側で制御する方が一貫性を保ちやすい一方、CDN側でルールを持つと柔軟に変更できます。どちらに主導権を持たせるかを設計段階で決めておかないと、後から「CDNがオリジンのヘッダーを無視している」という事態に行き詰まります。

バリエーションキャッシュの設計

同一URLで複数のバリエーションをキャッシュする設計は、Varyヘッダーを使って実現します。たとえば`Vary: Accept-Encoding`を指定すれば、gzip圧縮版と非圧縮版を別キャッシュとして保持できます。しかし`Vary: User-Agent`や`Vary: Cookie`を指定すると、バリエーション数が爆発してキャッシュヒット率が著しく低下します。バリエーション設計の原則は「Varyヘッダーの値は可能な限り少なく、かつ固定値にする」ことです。デバイス別のコンテンツ出し分けはVaryではなくURLレベルで分離するか、CDN側のエッジロジック（CloudflareのWorkers、FastlyのVCL等）で処理する方が管理しやすく、キャッシュヒット率への悪影響も抑えられます。

パージ方針の決め方

コンテンツ更新時のキャッシュパージは「即時全パージ」「タグ/サロゲートキーによる部分パージ」「TTL自然期限切れ待ち」の3方針のいずれかで設計します。本番環境でよく見られるのは、重要なコンテンツのみタグベースで即時パージし、その他はTTL期限切れに任せるハイブリッド方式です。即時全パージは確実性が高い反面、パージ直後のキャッシュミスでオリジンに負荷が集中する「サンダリングハード問題」が起きやすく、特に月間数百万PV以上の規模では注意が必要です。パージ後の再プリウォームを自動化するか、トラフィックシフトと組み合わせて段階的に移行する設計を採用する現場が増えています。

動的コンテンツをCDN経由で通すかバイパスするかの判断基準

CDN経由にするメリットとリスク

動的コンテンツをCDN経由で通すメリットは、TLS終端をエッジで行うことによるレイテンシ削減と、DDoS/WAFによる保護の適用です。キャッシュしなくてもCDNを経由させるだけで、オリジンへの直接アクセスを遮断しつつエッジでの保護層を確保できます。一方で、CDN経由にすると通信経路が増えるためデバッグが複雑になります。ヘッダーの付与・書き換え・削除がどこで行われているかを追跡しにくくなり、問題発生時の原因特定に工数がかかります。認証系エンドポイントをCDN経由にする場合は、後述の落とし穴に挙げるキャッシュ汚染リスクへの対策を設計に含める必要があります。

バイパス設計の実装と注意点

CDNバイパスの実装は、ヘッダー条件（例：`X-No-Cache: 1`）やパスパターン（`/api/auth/*`）に基づいてCDN側でオリジンにパススルーするルールを設定する方法が一般的です。バイパスルールは一か所に集約して管理し、エンドポイントが増えるたびにルールが散乱しないよう設計段階でルールの名前空間と優先順位を定めておくことが重要です。バイパス設定が漏れた場合のリスクは低くありません。認証エンドポイントへのリクエストが意図せずキャッシュされた事例は国内外問わず報告されており、「設定したつもりが反映されていなかった」というヒューマンエラーも一定頻度で発生します。IaCでCDNルールを管理し、変更時にCI/CDで差分をレビューする体制が防止策として有効です。

動的コンテンツのCDN経由判断チェックリスト

• このエンドポイントはユーザーIDやセッションに依存するレスポンスを返すか（Yesならバイパスを基本とする）
• Set-CookieをレスポンスするエンドポイントをCDN経由にする場合、CDN側でSet-Cookieのストリップルールが設定されているか
• 認証・認可の検証はオリジン側で完結しているか（エッジでの認証は補助的な扱いにとどめているか）
• WAF・DDoS保護を目的としてCDN経由にするなら、そのエンドポイントのキャッシュ設定を明示的に無効化しているか
• バイパスルールの設定はIaCで管理されており、変更時にレビューが入る仕組みになっているか
• 新規エンドポイント追加時にバイパス/キャッシュの判断を行うレビュープロセスがチームに存在するか

オリジンのSSL証明書終端をCDNとの間でどう設計するか

エッジ終端とオリジン間のSSL設計の考え方

CDNを前段に置いた場合、TLS終端の設計は「クライアント〜エッジ間」と「エッジ〜オリジン間」の2区間で独立して考える必要があります。クライアント〜エッジ間は通常HTTPSが必須ですが、エッジ〜オリジン間をHTTPで通すか、HTTPSで通すかは設計次第です。エッジ〜オリジン間をHTTPにすると設定が簡略化される反面、内部ネットワーク内でも平文が流れる構成になります。クラウドのプライベートサブネット内に閉じた構成であれば許容範囲とする現場もありますが、コンプライアンス要件や通信経路の設計によってはHTTPS一貫が求められます。設計段階で要件を確認しておかないと、後から変更する際の工数が大きくなります。

Full SSL vs Full Strict の選択基準

CloudflareのSSLモードを例にとると、「Flexible」はクライアント〜エッジはHTTPS・エッジ〜オリジンはHTTPという構成です。「Full」はエッジ〜オリジン間もHTTPSになりますが、オリジンの証明書は自己署名でも通ります。「Full (Strict)」ではオリジンに有効な証明書（CA署名済み）が必要です。本番環境では「Full (Strict)」が推奨されます。自己署名証明書を許容する「Full」モードは中間者攻撃に対して脆弱であり、CDNを使っているからといってオリジン側の証明書検証を省略することはセキュリティ上のリスクになります。オリジン証明書はLet’s Encryptやクラウドプロバイダが提供する証明書サービス（ACM等）で自動更新する設計が、運用負荷とセキュリティのバランスで標準的です。

証明書管理と更新設計

証明書の更新失敗はサービス停止に直結する重大な障害です。CDNを前段に置く構成では、CDN側の証明書とオリジン側の証明書の2系統を管理する必要があり、更新タイミングや有効期限の監視を1か所で見られるようにしておくことが重要です。CDN側の証明書はほとんどのプロバイダが自動更新を提供していますが、オリジン側はAnsible・Terraform・certbotなどによる自動化が別途必要です。証明書の有効期限を監視し、30日前・7日前に通知が届く仕組みを設けておくことで、更新漏れによるサービス断を防げます。複数環境（本番・ステージング・開発）をまとめて管理する場合、環境ごとの証明書を一覧できる管理台帳をIaCのコメントやドキュメントとして整備しておくと、担当者交代時の引き継ぎコストを大幅に下げられます。

ログと監視をCDN側・オリジン側のどちらで取るかの設計

CDN側ログで取れる情報とその限界

CDN側のアクセスログにはクライアントIP・リクエストURL・HTTPステータス・キャッシュヒット/ミスのステータス・エッジのレスポンスタイムが含まれます。キャッシュヒット率の推移やエッジでのエラー率を監視するには、CDN側のログが有効です。特にキャッシュヒット率が突然低下した場合、オリジン側では気づきにくく、CDN側のログを見て初めて判明することがあります。一方、CDN側のログにはオリジン内部の処理時間やアプリケーションレベルのエラーが反映されません。CDN側のレスポンスタイムが正常でもオリジン内部でデータベース処理に時間がかかっている場合、CDN側ログだけでは検出できず、複合的な問題の切り分けに支障が出ます。

オリジン側ログが必要なシーン

オリジン側ログが必須になるのは、認証・認可のトレース、エラーの原因調査、監査要件のあるアクセスログの保管です。CDN経由のリクエストはオリジンに届く前にIPが書き換わるため、オリジン側でクライアントの実IPを記録するには`X-Forwarded-For`または`True-Client-IP`ヘッダーを参照する設定が必要です。この設定漏れは監査ログの不備につながるため、設計段階での確認が必要です。構築を任されたある担当者が、CDN導入後に監査要件を満たすログが取れていないことを指摘され、後からオリジン側のログ設定を変更した事例があります。こうした後付け対応は既存のログ集計基盤との整合を取る手間が生じるため、構築初期に設計に組み込む方が合理的です。

両側を突き合わせる監視設計

CDN側とオリジン側のログを突き合わせることで、「CDN側は正常なのにオリジンが高負荷」「CDN側でキャッシュミスが多発しているが原因不明」といった問題を素早く切り分けられます。リクエストIDをCDN側のカスタムヘッダーとしてオリジンに渡し、オリジン側のログにも記録することで、両側のログを単一のリクエストIDで突き合わせる設計が有効です。これを実装しておくと、インシデント発生時の原因特定にかかる時間を大幅に短縮できます。現場では、この設計がないために障害対応が数時間以上にわたる事例が報告されており、監視設計はCDN導入時にセットで組み込むのが望ましい判断です。

落とし穴 — キャッシュと認証が絡む設計で踏みやすいミス

認証付きレスポンスのキャッシュ漏れ

最も頻繁に報告される落とし穴は、認証が必要なエンドポイントのレスポンスが意図せずキャッシュされ、別ユーザーに返ってしまうインシデントです。CDNの設定でキャッシュルールを適用する際、エンドポイントのパスパターンを曖昧に設定すると、`/api/user/*`のつもりが`/api/`以下すべてをキャッシュしてしまうケースがあります。対策として有効なのは「キャッシュは明示的にオプトインで設計する」原則です。デフォルトはすべてバイパス（あるいは`Cache-Control: no-store`）とし、キャッシュを有効にするエンドポイントを明示的にホワイトリスト管理することで、設定漏れによるキャッシュ汚染を防げます。この設計思想は構築当初から徹底しないと、エンドポイントが増えるにつれて整合が取りにくくなります。

Set-Cookieとキャッシュの競合

`Set-Cookie`ヘッダーを含むレスポンスがキャッシュされると、最初にアクセスしたユーザーのCookieが後続ユーザーに返るという重大な問題が発生します。CDNプロバイダによってはSet-Cookieを含むレスポンスをデフォルトでキャッシュしない設定になっていますが、カスタムキャッシュルールを設定する際に誤って上書きしてしまうケースが報告されています。ログイン処理やセッション発行のエンドポイントは、CDN側のキャッシュルールとは完全に分離して管理することを設計段階で明示しておくことが重要です。IaCでキャッシュルールを管理している場合でも、Set-Cookieを返すエンドポイントが新たに追加された際にレビューが必要な旨をコードのコメントに明記しておくと、後任の担当者が誤設定を踏むリスクを下げられます。

パージ遅延と整合性の問題

コンテンツを更新した直後にキャッシュパージAPIを叩いても、全PoPへの反映に数秒〜数十秒かかることがあります。この間にリクエストが来ると古いキャッシュが返り続けます。重要なコンテンツ更新（価格・在庫・規約など）では、パージ完了を確認してからオリジン側の更新をコミットする順序設計や、`stale-while-revalidate`を用いた段階的な切り替えを検討する価値があります。また、複数のCDNを並列で使うマルチCDN構成では、パージが片方にしか届かず不整合が生じるケースが現場では報告されています。マルチCDN構成では、パージをオーケストレーションするレイヤーを設けるか、コンテンツのバージョニングURLで整合性を保つ設計が必要です。こうしたパージ設計の考慮漏れは、「CDNを使っているのにコンテンツが更新されない」という問題として表面化しやすく、設計段階で明示しておくべき判断事項の一つです。