Cloudflare WorkersとTransform Rulesでトラッキングパラメータを除去する

なぜトラッキングパラメータがキャッシュヒット率を破壊するのか

utm_source、gclid、fbclidなどのトラッキングパラメータは、マーケターがキャンペーンのパフォーマンスを測定するのに役立ちます。Core Web Vitalsにとって、それらはキャッシュを破壊するため悪夢です。一意のURLはすべて個別のキャッシュエントリを作成します。Facebookで共有された1つのページはクリックごとに一意のfbclidを取得します。つまり、Facebookからのすべての訪問者がキャッシュミスを引き起こし、遅延したTime to First Byteを経験することになります。

Cloudflareでは、キャッシュを汚染する前にエッジでこれらのパラメータを除去する3つの方法を提供しています：Transform Rules（コード不要）、Workers（完全な制御）、およびCache Keyのカスタマイズ（Enterprise版）。これら3つすべてについて説明します。

最終レビュー Arjen Karel 2026年3月

トラッキングパラメータにおけるキャッシュの問題

キャッシュシステムは、完全なURLをキャッシュキーとして使用します。URLに?utm_source=googleや?fbclid=abc123が含まれている場合、コンテンツがまったく同じであっても、キャッシュはそれを別のページとして扱います。これがキャッシュミスです。URLのクエリ文字列の値が異なるというだけで、サーバーはすでにキャッシュしているページを再構築します。

この問題の規模は、多くの人が認識しているよりも大きいです。マーケティングエコシステム全体で129の既知のトラッキングパラメータが存在します。fbclidパラメータは最も破壊的です。なぜなら、Facebookは有料広告だけでなく、すべてのアウトバウンドリンククリックにそれを追加するからです。オーガニックなシェア、コメント内のリンク、あなたのサイトにリンクするすべての投稿が、一意のfbclid値を取得します。

2025 Web Almanacによると、モバイルオリジンのわずか44%しか良好なTTFBを達成していません。Cloudflareは、クエリ文字列のキャッシュ動作を修正することで、キャッシュヒット率が平均3%向上し、オリジンのバイト数が5%削減されたと報告しています。これは、訪問者のLargest Contentful Paintを直接的に高速化することにつながります。

すべてのクエリパラメータがトラッキングのゴミというわけではありません。?q=laptopsや?color=blueなどのパラメータはページコンテンツを変更します。目標は、コンテンツに影響を与えないパラメータを除去し、影響を与えるものを保持することです。

どのトラッキングパラメータを除去すべきか？

以下は、プラットフォームごとにグループ化された最も一般的なトラッキングパラメータです。これらは、ページコンテンツを変更することなく、キャッシュ不可能な一意のURLを作成します。

これは完全なリストではありません。トラッキングクエリパラメータレジストリには、129の既知のパラメータすべてが文書化されています。ほとんどのサイトにおいて、Google、Meta、およびMicrosoftのパラメータをカバーすることで、問題の95%を処理できます。

オプション1: Transform Rules（コード不要）

Cloudflareにはremove_query_args()と呼ばれる組み込み関数があり、URLがキャッシュに到達する前に特定のクエリパラメータをURLから除去します。これはTransform Ruleとして実行され、コードは不要で、無料枠を含むすべてのプランで利用可能です。

これを設定するには：

1. Cloudflareダッシュボードで、Rules、Transform Rules、URL Rewriteの順に移動します。
2. 新しいルールを作成します。
3. ドメインに一致するようにフィルターを設定します（例: (http.host eq "example.com")）。
4. Queryについて、Rewrite toを選択し、次にDynamicを選択します。
5. 次の式を入力します：
   remove_query_args(http.request.uri.query, "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content", "utm_id", "gclid", "gclsrc", "wbraid", "gbraid", "dclid", "gad_source", "fbclid", "msclkid", "ttclid", "twclid", "li_fat_id", "epik", "srsltid", "_ga", "_gl")
6. Pathについて、Preserveを選択します。

これで完了です。Workerもコードのデプロイも不要です。無料プランでは10個のTransform Rulesが許可され、Proプランでは25個が許可されます。ほとんどのサイトにとって、これが最適なオプションです。

オプション2: Cloudflare Workers

Cloudflareにはクエリ文字列を無視するオプションが標準で用意されていますが、その保守的な設定だけでは、Cloudflareプランを最大限に活用するには不十分です。Transform Rulesが提供する以上の制御（たとえば、正規表現のマッチング、条件付きロジック、ロギングなど）が必要な場合、Cloudflare Workerを使用すると完全な柔軟性が得られます。

Workersはエッジでリクエストを傍受し、リクエストがキャッシュやオリジンに到達する前にコードを実行します。CloudflareはTLSハンドシェイク中にWorkersをロードするため、実質的なオーバーヘッドは1ミリ秒未満です。

コード

以下は、現在のES modules構文を使用した完全なWorkerスクリプトです：

export default {
  async fetch(request) {
    const url = new URL(request.url)

    const trackingParams = /^(utm_|gad_|gclid|gclsrc|wbraid|gbraid|dclid|fbclid|fb_action_|srsltid|msclkid|ttclid|twclid|li_fat_id|epik|igshid|_ga$|_gl$|mc_[ce]id|_hs[em])/

    // Collect matching keys first (do not delete during iteration)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

    keysToDelete.forEach(key => url.searchParams.delete(key))

    return fetch(url.toString(), request)
  }
}

このWorkerはURLを解析し、各クエリパラメータを正規表現に対してテストし、一致するものを削除します。クリーンなURLはその後、キャッシュとオリジンに送信されます。ここで重要な詳細が2つあります。1つ目は、コードがキーを削除する前に配列に収集していることです。なぜなら、URLSearchParamsの反復中に削除するとエントリがスキップされる可能性があるためです（これはライブイテレータの既知の仕様の問題です）。2つ目は、Cloudflareが古いaddEventListener構文を非推奨にしたため、スクリプトがES modulesフォーマット（export default）を使用していることです。

デプロイメント

1. Cloudflareにサインインします。 Cloudflareダッシュボードにログインします。
2. Workerを作成します。 まだサイトに移動しないでください。Workersセクションに移動し、新しいWorkerを作成します。
   
3. Workerに名前を付けてデプロイします。 このステップは少し直感に反するように見えるかもしれませんが、心配しないでください。空の「hello world」Workerに名前を付けて、デプロイをクリックするだけです。
   
4. Workerを編集します。 次のページで「Edit Code」をクリックします。
   
5. スクリプトを貼り付けます。 上記のスクリプトをコピーしてエディタに貼り付けます。その後、デプロイをクリックします。
   
6. Workerをルートにバインドします。 戻って、Cloudflareであなたのサイトに移動します。「Worker Routes」をクリックし、次に「Add Route」をクリックします。新しく作成したWorkerを選択し、サイトに適用します。
   

カスタマイズ

特定のパラメータを含めたり除外したりするために、正規表現を変更できます。サーバー側の処理のために特定のutm_パラメータを保持したい場合は、正規表現からそれらを削除します。デフォルトの正規表現でカバーされていないマーケティングプラットフォームを使用している場合は、そのパラメータを追加してください。

オプション3: Cache Keyのカスタマイズ（Enterprise版）

Cloudflare Enterpriseプランを使用している場合、URLからクエリパラメータをまったく除去せずに、特定のクエリパラメータを除外するようにカスタムキャッシュキーを設定できます。キャッシュは、キーを計算する際に単にそれらを無視します。URLが変更されないため、これは最もクリーンなアプローチですが、Enterprise版が必要です。

Enterprise版以外のプランの場合、Transform RuleまたはWorkerのアプローチで同じキャッシュのメリットが得られます。

どのアプローチを使用すべきか？

ほとんどのサイトでは、Transform Rulesから始めてください。ルールの制限に達したり、より高い柔軟性が必要になったりした場合は、Workersに移行してください。

Cloudflare APOとWordPressを使用している場合、これらの設定は一切不要かもしれません。APOは、キャッシュキーを計算する際に無視する25以上のマーケティングパラメータの許可リストを維持しています。WorkerやTransform Ruleを追加する前に、特定のパラメータがカバーされているかどうかを確認してください。

パラメータを除去すると分析が壊れるか？

いいえ。除去はCDNとオリジンサーバーの間のエッジで行われます。ブラウザのURLには、元のトラッキングパラメータが引き続き含まれています。Google Analytics、Google広告のコンバージョントラッキング、およびFacebookのピクセルはすべて、クライアント側のdocument.locationから読み取ります。ここには、すべてのパラメータがそのまま残っている完全なURLがあります。

これが問題を引き起こす可能性のある唯一のシナリオは、サーバー側のコードがURLからトラッキングパラメータを読み取る場合（たとえば、サーバー側の分析の実装など）です。その場合は、それらのパラメータを除去の対象から外すか、Workerが削除する前にリクエストヘッダーでキャプチャしてください。

キャッシュにとどまらず、トラッキングや分析のスクリプトがパフォーマンスにどのように影響するかについての詳細は、分析およびトラッキングスクリプトを制限する理由をご覧ください。

除去すべきURLパラメータの特定方法

適切なツールを使用すれば、どのURLパラメータを除去すべきかを簡単に見つけることができます。CoreDashのようなRUMツールは、サイトを24時間年中無休で監視し、すべてのクエリ文字列とそれがパフォーマンスに与える影響を記録します。CoreDashでLargest Contentful Paintに移動し、クエリ文字列ごとの結果を確認します。

CoreDashによって監視されているサイト全体で、トラッキングパラメータが除去されたページは、キャッシュヒット率が約8〜15%向上しています。キャッシュミスになっていたはずの訪問者にとって、これはTTFBが200〜500ミリ秒高速になることを意味します。

Cloudflareを使用しており、キャッシュ期間のTTFBサブパートが高い場合、トラッキングパラメータによる汚染は最初に確認すべきことの1つです。パラメータの除去と適切なCloudflare設定を組み合わせることで、フィールドデータに測定可能な改善が見られるでしょう。