# オリジンの余計なヘッダーにサヨナラ！Cache Response Rules 登場だよ

やっほー、しぃちゃんだよ！

今日はキャッシュまわりで地味だけどかゆいところに手が届く発表を見つけたよ。さっそく紹介しちゃうね！

## なにが発表されたの？

Cloudflare の Blog によると、新しいルールタイプ「**Cache Response Rules**」が登場したよ。これは、オリジンサーバーからの応答が返ってきた後、キャッシュに書き込まれる前のタイミングで実行されるルールなの。

本来ならキャッシュされるべきコンテンツが、オリジン側で付いた `Set-Cookie` や意図しない `Cache-Control` のせいでオリジンまで引き戻されてしまう……という、原文いわく「オリジン側では直しづらいヘッダー」による問題を解決するための機能だよ。

## 今までどうだったの？

これまでのキャッシュ制御は、主に **Cache Rules** というリクエスト時のルールで行われていたの。「キャッシュ対象にするか」「何をキャッシュするか」「どう保存するか」は、リクエストの段階で決められる仕組みだったんだよね。

でも、`Set-Cookie` が静的ファイルに付いてしまっていたり、`Cache-Control: no-cache` が不適切に設定されていたりする問題は、オリジンが応答するまで分からないから、リクエスト時のルールだけでは解決できなかったの。オリジン側の設定を直接いじれない・いじりにくいケースも多くて、ここが長年のもどかしいポイントだったみたい。

## これで何が変わるの？

Cache Response Rules は、応答を受け取った直後というタイミングで動くから、オリジンの実装を変えずに、キャッシュの挙動だけをピンポイントで調整できるようになったよ。

- 邪魔なヘッダーが原因でキャッシュされなかったコンテンツを、キャッシュ可能にできる
- オリジン側のコード変更なしで、Cloudflare 側だけで挙動を直せる
- Cache Rules（リクエスト時）と組み合わせて、キャッシュの入り口と出口の両方をコントロールできる

## 深く潜ってみよう

Cache Response Rules では、応答に対して次のようなアクションが実行できるよ。

- **ヘッダーの削除**: `Set-Cookie` や `ETag`、`Last-Modified` などを応答から取り除いて、キャッシュ可能にする
- **キャッシュタグの管理**: タグの追加・削除・設定ができ、タグベースのパージに活用できる。ヘッダーの値から動的にタグを計算することも可能
- **Cache-Control ディレクティブの修正**: `max-age`・`s-maxage`・`no-store` などを個別に上書きできる。`cloudflare_only` フラグを使えば、ブラウザ側の挙動は変えずに Cloudflare 側だけに適用する変更も指定できる

設定方法は 2 通りだよ。

- **ダッシュボード**: 「Cache」→「Cache Rules」→「Create rule」から Cache Response Rule を選ぶ
- **API**: `/zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint` を使う

利用は**全プランで可能**とのこと。ただし注意点もいくつかあるよ。

- 応答フェーズなので、キャッシュキー（何をキーにキャッシュするか）自体は変更できない
- `ETag` と `Last-Modified` を両方削除すると、Smart Edge Revalidation が有効になる
- 静的でないコンテンツにキャッシュタグの削除を適用するときは注意が必要

## まとめ

- Cloudflare が応答フェーズで動く「Cache Response Rules」を発表した
- オリジンを直接変更しなくても、ヘッダー削除・キャッシュタグ管理・Cache-Control 修正で、キャッシュされない問題を解決できる
- ダッシュボードまたは API から設定でき、全プランで利用可能

オリジン側をいじれずにキャッシュヒット率で悩んでいたインフラ・Web エンジニアさんに、ぴったりのアップデートなの！