キャッシュルールを設定することで、CDN/ のポイントオブプレゼンス (POP) にあるリソースのキャッシュ期間を制御し、コンテンツの鮮度、アクセスパフォーマンス、オリジンフェッチコストのバランスを取ることができます。本ドキュメントでは、キャッシュルールの設定方法と検証方法、トラブルシューティング、およびベストプラクティスについて説明します。
仕組み
リクエストが CDN/ のポイントオブプレゼンス (POP) に到達すると、システムは以下の優先順位に従って、キャッシュされたコピーを配信するか、オリジンサーバーから最新のコンテンツを取得するかを決定します。
オリジンサーバーが
pragma:no-cache、cache-control:no-cache(またはno-store、max-age=0) で応答した場合、CDN/ はリソースをキャッシュしません。上記のようにオリジンサーバーが明示的にキャッシュしないディレクティブを送信しない限り、CDN/ コンソールで設定されたキャッシュルールが優先されます。
複数のコンソールキャッシュルールがリクエストに一致する場合の優先順位ロジック：
シナリオ
優先順位ロジック
例
重みが異なる場合
重みが大きい (1～99) ルールが優先されます。
ルール A (ディレクトリ
/image/、重み 50) とルール B (ファイル拡張子.jpg、重み 90) の両方がimage/a.jpgに一致します。ルール B の方が重みが大きいため、ルール B が適用されます。重みが同じ場合
最も早く作成されたルールが優先されます。
あるドメイン名に対して、ディレクトリールール (
/static/) とファイル拡張子ルール (.js) の両方を重み 60 で設定したとします。ディレクトリールールがファイル拡張子ルールより先に作成された場合、/static/app.jsへのリクエストはディレクトリールールに一致します。リクエストがキャッシュルールに一致すると、他のルールは評価されません。
デフォルトでは、オリジンサーバーが
Pragma: no-cacheまたはCache-Control: no-cache/no-store/max-age=0で応答した場合、CDN/ の POP はリソースをキャッシュしません。キャッシュを強制するには、キャッシュの有効期限ルールを設定する際に レスポンスヘッダーを無視 を選択します。
リクエストが CDN/ コンソールのどのルールにも一致しない場合、または一致したルールで [オリジンの TTL に従う] が有効になっている場合、CDN/ はオリジンサーバーの HTTP レスポンスヘッダーに従います。ヘッダーの優先順位は、高いものから順に
cache-control>expires>last-modified>ETagとなります。レスポンスヘッダー
CDN/ での処理
注意点と例
Cache-Control
s-maxage(CDN/ のキャッシュ期間) を優先的に使用し、次にmax-ageを使用します。例：
s-maxage=86400, max-age=3600Expires
有効期限を指定します。これは、
Cache-Controlヘッダーが存在しない場合にのみ使用されます。例：
Expires: Wed, 21 Oct 2025 07:28:00 GMTLast-Modified
Last-Modifiedヘッダーは、リソースが最後に変更された日時を示すタイムスタンプです。キャッシュ期間は次のように計算されます：
(現在の時刻 -
last-modified) × 0.1。計算された期間は、10 秒から 3,600 秒の範囲に収まります。例：
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMTETag
ETagは、サーバーがリソースの特定バージョンに対して生成する一意の識別子で、通常はハッシュまたはバージョン番号です。ETagヘッダーがあるリソースは、デフォルトで 10 秒間キャッシュされます。例：
ETag: "abc123"CDN/ のキャッシュしないポリシー：リクエストが CDN/ コンソールのどのキャッシュルールにも一致せず、かつオリジンサーバーが
Cache-Controlなどのキャッシュレスポンスヘッダーを返さない場合、CDN/ はキャッシュしないポリシーを適用します。
CDN/ は、オリジンサーバーがステータスコード 200、203、206、300、301、308、または 410 を返すリクエストにのみキャッシュポリシーを適用します。404 などの他のステータスコードが返されるリクエストをキャッシュするには、[キャッシュ設定] > [ステータスコードの有効期限] でこの動作を設定する必要があります。
操作手順
コンソール (推奨)
CDN コンソールの[ドメイン名] ページで、対象のドメイン名の横にある管理をクリックします。
キャッシュ設定 > キャッシュ有効期限 ページで、「追加」をクリックしてキャッシュルールを設定します。
パラメーター
説明
デフォルト/例
タイプ
ルールのスコープを「ディレクトリ」または「ファイル拡張子」で指定します。
• ディレクトリ：パス配下のすべてのリソースに統一されたキャッシュルールを設定します。
• ファイル拡張子：特定の種類のファイルに統一されたキャッシュルールを設定します。ディレクトリ、ファイル拡張子
アドレス
選択したタイプに基づいて値を入力します：
• ディレクトリ：スラッシュ (/) で始まる必要があります (例：/static/)。単一のスラッシュ (/) はすべてのパスに一致します。一度に追加できるディレクトリは 1 つだけです。
• ファイル拡張子：1 つ以上のファイル拡張子をカンマで区切って入力します (例：jpg,png,css)。入力値は大文字と小文字を区別し、縦棒 (|) やその他の記号はサポートしていません。/static/、jpg,png,css有効期限
POP 上のリソースのキャッシュ期間。最大期間は 3 年です。
• 更新頻度の低い静的リソース (例：画像、インストーラー) には、1 か月以上の期間を設定します。
• 更新頻度の高い静的リソース (例：JS/CSS ファイル) には、1～7 日などの短い期間を設定します。
• 動的コンテンツ (例：PHP/JSP ページ) には、期間を 0 秒 (キャッシュなし) に設定します。0 秒～3 年
オリジンの TTL を優先
デフォルトでは無効になっています。有効にすると、オリジンサーバーのキャッシュポリシーが優先され、このルールは上書きされます。
オフ
レスポンスヘッダーを無視
有効にすると、CDN はオリジンサーバーからの次のキャッシュしないディレクティブを無視します：
Cache-Control: no-store、no-cache、またはmax-age=0、およびPragma: no-cache。リソースはコンソールのルールに従ってキャッシュされます。オフ
CDN のキャッシュルール優先
有効にすると、CDN はレスポンスヘッダーで、
max-age=3600などの有効なキャッシュポリシーをクライアントに返します。オフ
コンテンツの強制再検証
この設定は、有効期限が 0 秒に設定されている場合にのみ有効です。
• 無効 (デフォルト、no-storeキャッシュポリシーに相当)：POP はファイルをキャッシュせず、すべてのリクエストはコンテンツを取得するためにオリジンサーバーに転送されます。
• 有効 (no-cacheキャッシュポリシーに相当)：POP はファイルをキャッシュしますが、すべてのリクエストは 304 メカニズムを使用してオリジンサーバーで再検証されます。これは、リアルタイムの検証が必要でありながら、オリジンサーバーの帯域幅への負荷を軽減したい場合に役立ちます。オフ
重み
ルールの優先度。値は 1～99 の範囲で、値が大きいほど優先度が高くなります。複数のルールが同じリソースに一致する場合、優先度の高いルールが優先されます。優先度が同じ場合、最初に作成されたルールが優先されます。きめ細かい制御を実現するために、特定のパスやファイル拡張子には高い優先度を設定し、ルートディレクトリ (
/) には低い優先度を設定することをお勧めします。1～99
ルール条件
ヘッダーや URL パラメーターなどのリクエストパラメーターに基づいて、ルールのスコープをさらに絞り込みます。これはデフォルトでは使用されません。条件を設定するには、ルールエンジンを使用します。ルールに条件が設定されている場合、機能自体の設定順序ではなく、関連する条件の優先順位に基づいて照合されます。
使用しない
キャッシュルールのマッチングロジック
CDN キャッシュの有効期限ルールは、異なるマッチング動作を持つ 2 つのルールタイプをサポートしています：
ディレクトリ：パスのプレフィックスマッチングを使用します。たとえば、
/static/を設定すると、そのディレクトリ配下のすべてのリソース (例：/static/image/1.jpgや/static/css/style.css) に一致します。/を設定すると、すべてのパスに一致します。ディレクトリパスはスラッシュ (/) で始まる必要があります。各ルールは 1 つのディレクトリのみをサポートします。ファイル拡張子：完全な拡張子マッチングを使用します。拡張子はドットなしで入力し、複数の拡張子はカンマで区切ります (例：
jpg,css,js)。拡張子は英数字のみをサポートし、特定の拡張子タイプに制限はありません。以下のタイプはすべて設定可能です：一般的な静的リソースの拡張子：
jpg、png、gif、css、js、htmlフォントファイルの拡張子：
ttf、otf、woff、woff2、eot動的ページの拡張子：
php、aspx、jspその他の英数字の拡張子
キャッシュルールのマッチングについては、次の点にご注意ください：
複数のキャッシュルールが同じリクエストに一致する場合 (たとえば、ディレクトリールールとファイル拡張子ルール)、重み が大きいルールが優先されます。重みが等しいルールは、作成順 (先に作成されたルールが優先) に従って優先順位が決まります。詳細については、上記の「仕組み」セクションをご参照ください。
ルール条件 (ルールエンジンで設定) をキャッシュルールに関連付ける場合、複数の条件は AND ロジックで評価されます。つまり、リクエストはすべての一致条件を満たす必要があります。
すべての動的拡張子 (
aspxなど) に包括的なキャッシュしないルールを設定する場合は、キャッシュする予定の静的リソースに影響を与えないようにしてください。フォントファイルをキャッシュするには、ttf,otf,woff,woff2,eotなどの拡張子を持つ専用のルールを追加します。
API
BatchSetCdnDomainConfig API を呼び出して、複数のドメイン名を一括で設定します。他の機能のパラメーター設定方法の詳細については、「ドメイン名設定機能」をご参照ください。
ルール変更の即時適用
新規または変更されたルールは、新しくキャッシュされるリソースにのみ適用されます。以前にキャッシュされたリソースは、有効期限が切れるまで古いキャッシュポリシーを使用し続けます。
新しいルールをネットワーク全体に即時適用するには、既存のキャッシュを手動でクリアする必要があります。ルールを変更した場合は、「リソースのパージとプリフェッチ」機能を使用してパージ操作を実行してください。新しいルールを追加した場合は、「リソースのプリフェッチ」機能を使用してプリフェッチ操作を実行してください。
検証
設定が完了したら、curl コマンドまたはブラウザーの開発者ツールを使用して、リソースの HTTP レスポンスヘッダーを確認し、キャッシュが期待どおりに機能していることを確認できます。
1. 検証コマンドの実行
ターミナルで次のコマンドを実行して、設定をテストします。
curl -I "https://your.domain.com/path/to/file.jpg"2. 主要なレスポンスヘッダーの解釈
レスポンスヘッダー | 説明 |
| リクエストが CDN/ でキャッシュヒットしたかどうかを示します。 |
| 「クライアントは CDN キャッシュポリシーに従う」を有効にすると、このヘッダーには、CDN がブラウザに渡す、 |
| POP 上で設定されたリソースの合計キャッシュ期間 (秒単位)。 |
ベストプラクティス
バージョン管理されたファイル名の使用 (推奨)：
style.cssのような静的リソースを更新する場合、style-v2.cssやstyle-a1b2c3d.cssのようにバージョンまたはハッシュを含む新しいファイル名を使用し、HTML 内の参照を更新します。この方法により、手動で CDN/ のキャッシュをパージする必要なく、ユーザーが即座に最新のコンテンツを受け取れるようになり、キャッシュされたコンテンツを更新する上で推奨される方法です。動的コンテンツと静的コンテンツの分離：動的リソースと静的リソースには、異なるドメイン名またはディレクトリパスを使用します。ポリシーの競合を避けるために、それぞれに個別の優先度の高いキャッシュルールを設定します。たとえば、
/static/ディレクトリ内のすべてのリソースには長いキャッシュ期間を設定し、/api/ディレクトリ内のリソースにはキャッシュしないように設定します。ブラウザーキャッシュの効果的な活用: [クライアントは CDN キャッシュポリシーに従う] を有効にすると、CDN への繰り返しリクエストが削減され、読み込み速度が向上し、CDN のトラフィックを節約できます。
過度に短いキャッシュ期間の回避：短いキャッシュ期間は、CDN/ が頻繁にオリジンフェッチを実行する原因となり、アクセラレーションのメリットを損ない、オリジンサーバーのトラフィックとコストを増加させます。
長いキャッシュ期間への注意：長いキャッシュ期間は、クライアントが適時にコンテンツの更新を受け取れなくなる可能性があります。頻繁な更新が必要なコンテンツについては、必ずキャッシュをパージするか、バージョン管理されたファイル名を使用してください。
小容量ファイルのシナリオ：ゲーム業界の小容量ファイルリソース (設定ファイルやアセットパッケージなど) で、更新頻度が低い (週次または隔週など) ものについては、キャッシュの有効期限を 15 日に設定するか、実際のリソース更新サイクルに合わせます。これにより、更新速度とアクセラレーション性能のバランスが取れます。キャッシュ期間が短すぎると頻繁なオリジンフェッチにつながり、アクセラレーションのメリットが減少し、長すぎると古いコンテンツがプレイヤーに提供される可能性があります。コンテンツが更新された際には、「パージとプリフェッチ」機能を使用して、事前にキャッシュを更新することを推奨します。
HTTPキャッシュ制御メカニズム
HTTP プロトコルは、キャッシュ制御のために 3 種類のヘッダーを使用します：