【Spring ’26】インフラ刷新：Cloudflareへの移行とExperience Deliveryにおける「静的アセット」のセキュリティ落とし穴

この記事はバージョン Spring ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。

Salesforce Spring ’26 リリースは、単なる機能追加の集合体ではありません。プラットフォームの基盤となるインフラストラクチャ、特にコンテンツデリバリネットワーク（CDN）における根本的な構造改革が含まれています。

Salesforceが掲げる「Agentic Enterprise（エージェント型企業）」へのシフトにおいて、AIエージェントと人間が協働するためには、低遅延かつ高スループットなデジタル体験が不可欠です。この戦略的転換の中核をなすのが、長年のパートナーであったAkamaiから Cloudflare へのCDN移行と、それに伴うアーキテクチャの刷新です。

本記事では、このインフラ移行がもたらす技術的メリットと、Experience Delivery を採用する上でアーキテクトが絶対に理解しておくべき「セキュリティ上の仕様変更」について深掘りします。

AkamaiからCloudflareへ：何が変わるのか？
Experience Deliveryにおけるセキュリティの「落とし穴」
開発者が意識すべきSSRの「ゲストコンテキスト」
まとめと提言
参考URL

AkamaiからCloudflareへ：何が変わるのか？

Spring ’26より、デジタルエクスペリエンス（Enhanced DomainsおよびCustom Domains）の基盤CDNが、順次Cloudflareへと移行されます。これは単なるベンダー変更ではなく、特にCommerceや大規模なLWRサイトにとって大きな制約解除を意味します。

URIサイズ制限の大幅緩和

従来のAkamai環境では、URIの最大サイズが約8KB（8,892バイト）に制限されていました。これがCloudflare環境では 16KB（約16,384バイト） まで拡張されます。

これまで： 複雑なフィルタリング条件を持つ検索結果ページや、長い認証トークンを含むディープリンクで “URI Too Long” エラーが発生することがありました。
これから： URLに約9,000文字まで含めることが可能になり、URLパラメータに状態（State）を持たせるSPA（シングルページアプリケーション）の設計柔軟性が飛躍的に向上します。

トラフィック制限の撤廃

もう一つの大きな変更点は、データ転送量の上限撤廃です。

Akamai (従来)： 年間48TBの上限（Experience Cloudライセンス）。
Cloudflare (Spring ’26以降)： Experience DeliveryまたはCommerce LWRサイトにおいて 「年間トラフィック無制限」 となります。

これにより、高解像度の製品画像や動画を多用するリッチなB2B Commerceサイトにおいても、帯域コストや制限を気にすることなく運用が可能になります。

移行スケジュール

手動移行： [設定] > [ドメイン] から手動でCDNプロバイダーを切り替えることも可能です。プロビジョニングには最大24時間（実測では数時間程度の場合もあり）かかるため、計画的な切り替えが推奨されます。

対象： 新規作成されるドメインはデフォルトでCloudflareを使用。既存ドメインは2026年1月〜6月にかけて段階的に移行。

機能	Akamai (従来)	Cloudflare (新)
最大 URI サイズ	~8,892 バイト	~16 KB (約16,384 バイト)
トラフィック制限	48 TB / 年	無制限
証明書	シングル証明書	ブランド証明書 (5つまで)
セキュリティ	WAF, レート制限	WAF, レート制限, DDoS保護

Experience Deliveryにおけるセキュリティの「落とし穴」

インフラ刷新の恩恵が大きい一方で、Experience Deliveryを採用する場合、セキュリティ設計において極めて重要な注意点があります。それは「静的アセットのキャッシング挙動」です。

仕様：認証済みページでもアセットは「パブリック」

ドキュメントによると、Experience Deliveryインフラストラクチャでは以下の仕様が存在します。

認証済みページ（ログインが必要なページ）で使用される静的アセット（画像、CSS、JSなど）であっても、CDN上ではパブリック（公開）にキャッシュされる。
Static assets that are available on authenticated pages are cached publicly and therefore potentially available to unauthenticated guest users.

これは、従来のSalesforceサイトのセキュリティ感覚とは異なる部分です。通常、認証済みページのリソースはセッションチェックを経て配信されると考えがちですが、Experience DeliveryのSSR（サーバーサイドレンダリング）によるパフォーマンスを最大化するため、静的アセットはCDNのエッジでアグレッシブにキャッシュされます。

リスク：隠したつもりの画像が見えてしまう

この仕様により、以下のようなリスクが生じます。

シナリオ： ポータルのログイン後ページに、「社外秘」と書かれたアーキテクチャ図（静的画像）を配置した。
リスク： その画像の直接URL（例: https://my.site.com/sfsites/c/resource/SecretDiagram）を推測、または何らかの方法で知った未認証のゲストユーザーは、ログインなしでその画像を閲覧できてしまいます。CDNレベルでは、静的アセットに対するセッション検証が行われないためです。

対策：機密情報は静的リソースに置かない

このアーキテクチャを採用する場合、以下の対策を徹底する必要があります。

監査の実施：
サイトで使用している静的リソース（Static Resource）やコンテンツアセット（Content Asset）に、PII（個人情報）や機密情報が含まれていないか確認する。
機密データの扱い（CMSとFilesの使い分け）：
通常、LWRサイトのコンテンツ管理には拡張CMS（Salesforce CMS）を使用するのがベストプラクティスです。しかし、Experience Delivery環境下では、CMS管理下のメディアであってもCDNでパブリックキャッシュされ、URLを知る第三者に閲覧されるリスクがあります。そのため、社外秘の図面や個人情報を含むドキュメントなど、厳格なアクセス制御が必要な「機密情報」に限っては、あえてSalesforce Files (ContentDocument) を使用することを推奨します。Filesであれば、ダウンロード時に必ずSalesforce側のセッション認証（レコード権限の確認）が実行されるため、CDNキャッシュによる漏洩を防ぐことができます。
動的配信：
これらはAPIコールを通じて動的に取得するか、セッション検証を必要とするCSR（クライアントサイドレンダリング）コンポーネントを介して配信し、パブリックCDNキャッシュをバイパスさせる。

開発者が意識すべきSSRの「ゲストコンテキスト」

インフラ面に関連して、開発者がコードを書く際にも意識すべき点があります。Experience Deliveryのサーバーレンダリングプロセスは、常に「ゲストユーザー」として実行されるという点です。

例えば、@salesforce/user/isGuest モジュールを使用している場合、実際のリクエストがログイン済みユーザーからであっても、サーバー上でのレンダリング中（SSRフェーズ）は常に true を返します。

import isGuest from '@salesforce/user/isGuest';
import { LightningElement } from 'lwc';

export default class UserGreeter extends LightningElement {
    connectedCallback() {
        // 注意：SSR中は常に true (ゲスト) と判定される
        // ログインユーザー名などをSSRで描画しようとすると、
        // クライアントでのハイドレーション時に表示が切り替わる「フラッシュ」の原因になる
        console.log('Is Guest User:', isGuest); 
    }
}

パーソナライズされたコンテンツ（例：「こんにちは、〇〇さん」）を表示する場合、SSRでの描画は避け、クライアントサイドでのハイドレーション後に表示するか、CSR専用領域（lwc:dom="manual"や特定の機能タグ設定）として実装する必要があります。