この記事は、Cloudflare上でAIプロダクトを運用する中で見つけた落とし穴シリーズの1本である。事前描画を直すデプロイをしたのに本番だけ古いHTMLが配信され続けた事故と、その原因がWorker自身のキャッシュだったという話をまとめる。
この記事で分かること
- デプロイは成功しているのに一部ページだけ古い内容が出る、という症状の正体
- ゾーンのキャッシュパージが効かない理由
- HEADリクエストでは見分けられない、という検証上の注意点
この記事で分からないこと(正直に書く)
- 同種のキャッシュを他プロダクトでどこまで使っているかは、本記事執筆時点で全数点検していない
何が起きたか
自社が運営する検索サイトの一部ページに事前描画を入れる修正をデプロイした。プレビューURLでは本文が正しく1,634字・1,551字で出るのに、本番ドメインでは13字・21字のままだった(出所: 自社の運用記録、確認日2026-09-06)。管理画面で確認すると、プレビューと本番は同じデプロイを指していた。同じコードなのに結果が違うなら、経路上の何らかの状態を疑う必要がある。
なぜ気づけなかったか
最初に疑ったのはCDNキャッシュだったが、レスポンスヘッダーは動的コンテンツを示す値のままで、ゾーン全体のパージもすでに実行済みだった。User-Agent別の違いやクエリパラメータでのキャッシュ回避も試したが結果は変わらず、診断用エンドポイントで関数自体が正常に動くことも確認できた。ゾーンのキャッシュでもAPIの不調でもないなら、残る候補はWorkerのコード自身が何かを保存している、という線だけになる。
どう直したか
原因は、Worker内のミドルウェアが独自にHTMLを保存する仕組みを持っていたことだった。保存先はゾーンのHTTPキャッシュとは別物で、ゾーン全体のパージを実行しても消えない。Cloudflareの公式ドキュメントでも、このキャッシュは「オリジナルのデータセンターの外には複製されない」「Cloudflareのグローバルなキャッシュとは別個の、ゾーンごとのキャッシュオブジェクトである」と説明されている(https://developers.cloudflare.com/workers/runtime-apis/cache/, 確認日2026-09-06)。保存キーがパスだけでクエリを含まないため、クエリを付けたキャッシュ回避も効かなかった。対応として、保存キーにコンテンツの版番号を含め、内容を変えるたびに版を上げる形に直し、保存期間も短くした。古いままだったのは、修正前に実測で最初にアクセスした少数のページだけで、「一部だけ直らない」という見え方は確認した順番と一致していた。
同じ構成の製品で先に見る場所
自社はカンタン補助金や弁護士みつかるなど複数のプロダクトをCloudflare Workers上で運用している。デプロイ別URLと本番URLで挙動が違うときは、まずWorkerのコードの中でキャッシュ用のAPIを自前で呼んでいる箇所がないかを探すのが最初の一手になる。あれば、保存キーにコンテンツの版が含まれているかを確認する。見分け方は、GETリクエストで自作の目印ヘッダーが付くかを見る方法があるが、HEADではこの目印が付かない実装もあるため検証はGETで行う。
キャッシュの層がどこにあるかで挙動が変わる点は、静的アセットがWorkerを素通りする記事や504がEarly Hintsだった記事とも通じる。関連してRAGの保管費用の記事も参照してほしい。
Cloudflare運用・キャッシュ設計の相談は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. デプロイは成功しているのに古い内容が出るとき、まず何を疑うべきか
同じデプロイIDを指すプレビューURLと本番URLで結果が違うなら、ゾーンのキャッシュではなくWorkerのコード自身が何かを保存している可能性を疑う。
Q2. ゾーン全体のキャッシュパージを実行しても直らないのはなぜか
Workerが独自に保持するキャッシュはゾーンのHTTPキャッシュとは別物で、パージの対象に含まれないため。
Q3. HEADリクエストで確認しても異常が見つからないのはなぜか
動作確認用の目印ヘッダーがGETリクエスト限定の実装だったため、HEADでは正常に見えてしまう。
Q4. 「一部のページだけ直らない」という現象は何を意味するか
修正前に実測で最初に触れたページだけ古い内容が保存され続け、後から測ったページはすでに新しい内容で保存されていた、という観測順との一致を意味する。