WordPressでCloudflare Snippetsを使う前の判断ガイド｜Rules・Workersとの違い

WordPressのリダイレクトやレスポンスヘッダーをCloudflare側で調整したいとき、「Rulesでは足りないが、Workersを作るほどではない」と感じることがあります。その間を埋める選択肢がCloudflare Snippetsです。

Snippetsは、条件に合うHTTPリクエストへ短いJavaScriptを適用し、オリジンへ届く前の要求や、返ってきた応答を変更できる機能です。ただし、WordPressへ入れるプラグインではなく、Cloudflareのエッジで動きます。対象条件を誤ると、公開ページだけでなく管理画面、REST API、フォーム、決済などにも影響します。

単純な転送や設定変更はまずCloudflare Rulesで実現できないか確認し、軽量なJavaScriptだけSnippets、永続データや重い処理はWorkersへ分けてください。導入前にコード、条件式、変更前の応答を保存し、最初はURL範囲を狭くして試します。

先に結論：Snippetsを選ぶかは7項目で判断する

変更したい対象がHTTPリクエスト・レスポンスか確認する
Single Redirects、Transform Rules、Cache Rulesなど標準機能で実現できないか確認する
短いJavaScriptで完結し、永続データや重い計算が不要か確認する
対象DNSレコードがCloudflareでProxiedになっているか確認する
契約プランのSnippet数、subrequest数、共通上限を確認する
対象URLを狭くした検証条件と、元へ戻す手順を作る
WordPress特有の管理画面、ログイン、API、フォームまで確認してから広げる

この7項目のうち、永続データ、外部サービスとの深い連携、重い処理、十分な実行ログが必要なら、最初からWorkersを検討します。逆に、URL転送やヘッダー追加が標準Rulesで完結するなら、JavaScriptを増やさない方が管理しやすくなります。

Cloudflare Snippetsとは？

Cloudflare公式のSnippets概要では、SnippetsはCloudflareのネットワーク上で短いJavaScriptを実行し、サイトやアプリのリクエスト・レスポンス処理を調整する機能と説明されています。利用には対象ドメインまたはサブドメインのDNSレコードをCloudflareでプロキシする必要があります。

Snippetsは、次の2要素で構成されます。

Snippet rule：どのリクエストへ適用するかを決める条件式
Code snippet：条件に一致したときに実行するJavaScript

複数のSnippet ruleが一致すると、対象Snippetは順番に実行され、前のSnippetが変更したリクエストを次のSnippetが受け取ります。つまり、1本だけを見て安全でも、複数本の組み合わせでヘッダー上書きや経路の衝突が起きる可能性があります。

Rules・Snippets・Workersの違い

選択肢	向く処理	避けたい使い方	運用の重さ
Cloudflare Rules	単純なリダイレクト、URL・ヘッダー・キャッシュ・オリジン設定	条件分岐が複雑なJavaScript処理	軽い
Snippets	軽量な要求・応答変更、複雑な書き換え、短い認証・キャッシュ制御	永続データ、重い計算、長い処理、十分なログが必要な機能	中程度
Workers	API、状態管理、外部連携、画像処理、高度なアプリ処理	標準Rulesだけで済む単純設定	重い

Cloudflare公式のSnippetsとWorkersの比較では、Snippetsは軽量なエッジ処理、Workersは状態・計算・Developer Platform連携を必要とする処理に向くと整理されています。

Workersで未処理例外が出た場合はCloudflare Error 1101の確認手順、CPU・メモリ上限ならCloudflare Error 1102の確認手順、自己参照や相互参照ならCloudflare Error 1019の確認手順で切り分けます。

WordPressでSnippetsが向く場面

Snippetsは「何でもJavaScriptで置き換える機能」ではありません。WordPressでは、既存のRulesで表現しにくく、短いHTTP処理として完結する場面へ限定すると管理しやすくなります。

条件が複数あるリダイレクトや移行時のURL調整
要求または応答ヘッダーの動的な追加・削除
特定パスだけのキャッシュキー・キャッシュ応答調整
軽量なメンテナンス応答や経路切替
特定条件でのオリジン変更やフォールバック
HTML応答の限定的なリンク書き換え

公式のSnippets例一覧には、セキュリティヘッダー、メンテナンスページ、ドメイン転送、リンク書き換え、オリジン切替などがあります。ただし、例をそのまま本番へ貼るのではなく、WordPressのテーマ、プラグイン、ログイン方式、CDN、フォーム構成に合わせて検証します。

標準Rulesを先に選びたい場面

次の処理は、まずCloudflareの標準Rulesで実現できるか確認します。コードを使わない方が、後任者が設定意図を追いやすく、構文エラーや実行上限も避けられます。

旧URLから新URLへの単純な301・302転送
決まった条件でのURL Rewrite
固定的な要求・応答ヘッダー変更
パスやCookieに基づく基本的なCache Rules
特定ホスト・パスを別オリジンへ送るOrigin Rules
既知の条件によるWAF・Configuration Rules

リダイレクトを複数箇所で設定すると循環することがあります。WordPress、サーバー、Cloudflareの転送先を一覧にし、ループが起きた場合はWordPressのリダイレクトループ確認手順を使ってください。

Workersを選びたい場面

KV、D1、Durable Objectsなどへ状態を保存する
外部APIと複雑に連携する
画像変換、AI推論、検索など計算量が大きい
環境変数、Bindings、Cron Triggersが必要
実行ログ、性能指標、段階的な公開、CLI運用が重要
JavaScript以外の言語や本格的なAPIを使う

Snippetsの上限へ処理を無理に押し込むと、Error 1202〜1204の原因になります。最初の実装量だけでなく、半年後に条件・例外・連携先が増えるかも含めて選びます。

利用条件と上限を確認する

2026年8月17日に確認したCloudflare公式情報では、SnippetsはFreeプランでは利用できず、Pro以上で利用できます。プラン・上限は変更される可能性があるため、導入時は公式画面を再確認してください。

項目	Pro	Business	Enterprise
Snippet数	25	50	300
1回の実行で使えるsubrequest数	2	3	5

全プラン共通の上限	値	設計上の意味
最大実行時間	5ms	重い計算や長い反復処理を置かない
最大メモリ	2MB	大きな応答全体の保持・加工を避ける
最大パッケージサイズ	32KB	大規模な依存関係やアプリ処理を入れない

リダイレクトを追うsubrequestは、途中の転送も1回として数えられます。また、公式概要では現在Version ManagementがSnippetsに対応していません。保存前にコードと条件式を別途保管し、直前の安定版へ手動で戻せる状態を作ります。

WordPressへ安全に導入する8段階

1. 解決したい問題を1つに絞る

「高速化したい」のような広い目的ではなく、「特定の旧URLだけ条件付きで転送する」「特定パスの応答ヘッダーだけ変える」のように、入力・出力・対象URLを明確にします。

2. Rulesで代替できるか確認する

Single Redirects、URL Rewrite Rules、Transform Rules、Cache Rules、Origin Rulesを確認します。標準機能で表現できるなら、運用負担が小さい方を選びます。

3. 現在の応答と設定を保存する

変更前のSnippetコードとrule条件
対象URL、HTTPメソッド、応答コード
主要な要求・応答ヘッダー
WordPress、サーバー、Cloudflareの関連設定
正常なページの画面と確認時刻
元へ戻すコード・条件式・担当者

4. 条件式を最小範囲にする

最初からホスト全体へ適用せず、検証用サブドメイン、限定パス、特定メソッドなどへ絞ります。/wp-admin/、/wp-login.php、/wp-json/、/wp-cron.php、/admin-ajax.phpを意図せず含めないか確認します。

5. 単独で試してから組み合わせる

既存のRules、Workers、他のSnippetsと同時に変更せず、新しいSnippetだけの影響を確認します。複数Snippetは順番に実行されるため、同じヘッダー、URL、キャッシュキー、オリジンを触る処理は特に注意します。

6. 未ログインとログイン中を分けて確認する

公開ページが正常でも、管理者Cookie、プレビュー、投稿保存、REST API、フォーム送信だけ壊れる場合があります。通常ブラウザーとシークレットウィンドウを分け、必要なら別回線でも確認します。

7. 低アクセス時間帯に狭く公開する

公開日時、担当者、対象URL、確認項目、戻す判断基準を決めます。エラー率、応答コード、フォーム失敗、ログイン失敗など、問題が見えたら対象Snippetだけを止めるか条件を狭めます。

8. 変更記録を残してから範囲を広げる

誰が、いつ、何のために、どのコードと条件を公開し、何を確認したかを残します。正常を確認してから対象URLを広げ、同じ日に別のキャッシュ・WAF・WordPress設定を重ねて変更しません。

管理画面へ入れない状態に備え、Cloudflare側で対象Snippetを停止できる権限と、保存済みの安定版コードを先に用意してください。WordPress管理画面だけを復旧手段にしないことが重要です。

セキュリティヘッダーは段階的に試す

Snippetsの公式例にはセキュリティヘッダー設定がありますが、Content-Security-PolicyやHSTSは値を誤ると、画像、外部フォント、計測タグ、フォーム、別サブドメイン、管理画面へ影響します。一般的な名前だけを見て一括追加しないでください。

現在のヘッダーと利用中の外部ドメインを記録する
対象ホスト・パスを限定して試す
ブラウザーの開発者ツールで違反・遮断を確認する
ログイン、投稿編集、プレビュー、フォームを確認する
HSTSは対象範囲と有効期間を理解してから設定する
WordPress本体の安全対策もWordPressセキュリティ設定の基本で確認する

本番反映後に確認する場所

トップ、投稿、固定ページ、カテゴリー、検索、404
WordPressログイン、管理画面、投稿保存、プレビュー
REST API、admin-ajax、wp-cron、サイトヘルス
画像、CSS、JavaScript、Webフォント
お問い合わせ、会員、予約、決済など使用中のフォーム
サイトマップ、robots.txt、OGP、構造化データ
PC・スマートフォン、ログイン中・未ログイン
期待する応答コード、Location、Cache-Controlなどのヘッダー
1201〜1206、1101、1102、1019、リダイレクトループが出ていない

Snippets固有の1201〜1206が表示された場合は、Cloudflare Snippetsエラーの原因別確認手順で、fetch回数、subrequest、CPU、メモリ、反映中、例外を分けて確認してください。

やってはいけない導入

公式例を対象URLの確認なしでサイト全体へ適用する
単純なRulesで済む処理までJavaScript化する
コードとrule条件を保存せず上書きする
WordPress、サーバー、Cloudflareを同時に変更する
管理画面、ログイン、REST APIを本番確認から外す
セキュリティヘッダーを意味・影響範囲の確認なしで追加する
実行時間・メモリ・subrequest上限を無視して処理を増やす
SnippetsとWorkersに同じURL処理を重複させる
異常時にCloudflare全体を停止し、原因範囲を広げる

よくある質問

FreeプランでSnippetsを使えますか？

2026年8月17日に確認した公式表ではFreeは対象外で、Pro以上が利用対象です。プラン条件は変わる可能性があるため、契約前・導入前に公式のAvailabilityを再確認してください。

Snippetsを入れればWordPressプラグインを減らせますか？

処理によります。HTTPの軽量な変更を置き換えられる場合はありますが、データ保存、管理画面、投稿処理、WordPressフックへ依存する機能は別物です。役割と復旧手段を比較してから判断します。

SnippetsとWorkersを同じURLで使えますか？

技術的な組み合わせはありますが、公式ガイドは衝突を避けるため処理するパスを分ける考え方を示しています。同じURLを両方が書き換える構成は、実行順、キャッシュキー、オリジン、ヘッダーを設計し、十分に検証できる場合だけにします。

公開後に不具合が出たら何を戻しますか？

直前に追加・変更したSnippetとrule条件を対象にします。Cloudflare全体や無関係なWAF・DNSを止めず、保存した安定版へ戻して、対象URLとWordPress機能を再確認します。

まとめ

Cloudflare Snippetsは、標準Rulesでは表現しにくい軽量なHTTP処理を、条件付きの短いJavaScriptで補う機能です。WordPressプラグインの代わりとして一括導入するのではなく、解決したい問題を1つに絞って使います。

Rulesで済む処理はRules、軽量な要求・応答変更はSnippets、状態・重い計算・外部連携はWorkersへ分けてください。コードと条件式を保存し、限定パスで試し、管理画面・API・フォームまで確認してから範囲を広げることが安全な導入につながります。