Cloudflare 09：ルール ― エッジの「もし〜なら」

一言でいうと：エッジで「もし〜なら、〜する」

Cloudflare のルールは、どれも同じ形をしています。

もし（条件）なら、こうする（やること）。

条件は「どのリクエストか」を表すルール式、やることはルールの種類ごとに決まっています。管理画面の Rules の下に、種類ごとの画面が並んでいます。

大事なのは、種類ごとに「当たる段」が決まっていることです。エッジの中では、リクエストが決まった順番で段を通り、それぞれの段で、その種類のルールが評価されます。図のように、おおまかには「転送 → 書き換え → 設定・行き先 → キャッシュ」の順です。

正確な順番は、管理画面の Rules の概要ページや、公式の「Traffic sequence」の図で確かめられます。順番を知っておくと、「書き換えた後の URL で次のルールが判定される」といった動きが理解しやすくなります。

ルール式：条件の書き方は全部共通

ルールの条件は、ルール式（Rules language）で書きます。Wireshark というネットワーク解析の道具の書き方をもとにした言語で、転送・書き換え・キャッシュ・WAF（05号）・レート制限（06号）まで、全部同じ書き方です。1度覚えれば、Cloudflare のあちこちで使い回せます。

式は「項目 演算子 値」の組み合わせです。

http.host eq "old.example.com"
starts_with(http.request.uri.path, "/blog/")
ip.src.country ne "JP" and http.request.uri.path contains "/admin"

演算子には、eq（等しい）、ne（等しくない）、contains（含む）、in（一覧のどれか）、and・or・not などがあります。starts_with() や ends_with()、lower() のような関数も使えます。

はじめのうちは、管理画面の式ビルダーを使うのがおすすめです。項目・演算子・値をプルダウンで選ぶと、式が自動で組み立てられ、「Edit expression」で文字の式として確かめられます。

Redirect Rules：別の URL へ案内する

Redirect Rules（Single Redirects とも呼ばれます）は、条件に当たったリクエストに対して、エッジがその場で 301 や 302 の転送を返すルールです。オリジンには何も届きません。利用者のブラウザは、返された新しい URL に行き直します。

例えば、「old.example.com の全ページを、同じパスのまま www.example.com へ」という転送は次のように書きます。

条件:   http.host eq "old.example.com"
転送先: 動的（Dynamic）
  concat("https://www.example.com", http.request.uri.path)
状態コード: 301
クエリ文字列を残す: オン

転送先は、固定の URL（Static）か、元の URL の一部を組み込んだ式（Dynamic）で書けます。concat() で文字をつなげ、http.request.uri.path で元のパスを取り出します。

転送をエッジで返す利点は、速いことと、オリジンが要らないことです。旧ドメインのサーバーを止めても、転送だけは Cloudflare が続けてくれます。ただし、その名前の DNS の行（オレンジ）は必要です（01号）。

Bulk Redirects：何千件の転送を一覧で

サイトを作り直すと、「この URL はこの URL へ」という転送が数百、数千件になることがあります。1件ずつ Redirect Rules を書いていては、本数の上限にすぐ届きます。そこで使うのが Bulk Redirects です。

Bulk Redirects は、転送元と転送先の一覧（リスト）を作り、それを有効にするルールを1本置く、という2段の仕組みです。リストは CSV でまとめてアップロードできます。

source_url,target_url,status_code
example.com/2019/post-a,https://example.com/posts/post-a,301
example.com/2019/post-b,https://example.com/posts/post-b,301
shop.example.com/,https://example.com/shop,301

規則で書けるなら Redirect Rules、書けないなら Bulk Redirects、と使い分けます。リストの各行では、サブドメインも含めるか、パスの下も含めるか、クエリ文字列を残すかといった細かい指定もできます。

リストに登録できる件数は、プランによって違います。大量の転送を予定しているなら、先に公式の上限を確かめてください。

URL 書き換え：見える URL はそのまま、中身だけ変える

Transform Rules の1つ、URL の書き換え（Rewrite URL）は、転送と似ていますが、動きがまったく違います。

例えば、利用者には /blog/hello というきれいな URL を見せたいが、古いブログのアプリは /posts?slug=hello という形でしか受け付けない、という場面です。書き換えを使えば、アプリを直さずに済みます。

条件: starts_with(http.request.uri.path, "/blog/")
パスを書き換え:  "/posts"
クエリを書き換え（動的）:
  concat("slug=", substring(http.request.uri.path, 6))

substring(文字, 6) は、先頭の6文字を飛ばした残りを取り出す関数です（数え方は0から）。/blog/ の6文字が飛ばされて、hello だけが残ります。

正規表現を使った書き換え（regex_replace() など）もありますが、上位のプランに限られます。

書き換えは、この後の段（Origin Rules や Cache Rules など）が見る URL も変えます。後の段の条件を書くときは、書き換えた後の URL で考える必要があることに注意してください。

ヘッダーの書き換え：足す・消す・変える

Transform Rules のもう1つの仕事が、ヘッダーの書き換えです。向きが2つあります。

やることは3つです。Set（値を入れる。無ければ足す）、Add（同じ名前がもう1つあっても足す）、Remove（消す）。値は固定の文字列でも、式から作ることもできます。

# レスポンス：全ページに安全のためのヘッダーを
条件: true（すべて）
Set    X-Frame-Options   = "DENY"
Set    Referrer-Policy   = "same-origin"
Remove X-Powered-By

# リクエスト：オリジンに国を伝える（動的）
Set    X-Country = ip.src.country

X-Frame-Options は、ほかのサイトに自分のページを埋め込ませない（クリックジャッキング対策）ためのヘッダーです。X-Powered-By は、サーバーの種類や版を外に教えてしまうので、消すのが定番です。

よく使う組み合わせは、Managed Transforms としてスイッチ1つで有効にできるものがあります。例えば、利用者の住んでいる地域の情報をリクエストに付けるもの、オリジンが付けた X-Powered-By を消すものなどです。

Origin Rules：行き先のサーバーを変える

Origin Rules は、リクエストをどのサーバーに届けるかを条件ごとに変えるルールです。

よくある使い方は、「1つのドメインの下に、パスごとに別のサーバーを並べる」ことです。example.com の本体はアプリのサーバー、example.com/blog は別のブログのサービス、という構成を、利用者から見て1つのサイトとして見せられます。

条件: starts_with(http.request.uri.path, "/blog")
DNS record を上書き: blog-origin.example.com
Host header を上書き: myblog.hosting-service.example

外部のサービスをオリジンにするときは、そのサービスが「自分宛ての Host ヘッダー」を求めることが多いので、DNS の名前と Host ヘッダーを一緒に変えます。

上書きの一部（Host ヘッダーや SNI など）は、プランによって使えないことがあります。使う前に、公式でプランごとの対応を確かめてください。行き先を「健康なサーバーの中から選ぶ」ところまでやりたい場合は、10号のロードバランシングを使います。

ほかのルール：一部だけ設定を変える

ここまでの4種類のほかにも、同じ「もし〜なら」の形をしたルールがあります。

Configuration Rules は、「管理画面のこの設定を、/admin の下だけ変えたい」というときに使います。例えば、ゾーン全体では有効にしている最適化の機能が、ある API のパスでだけ問題を起こす場合に、そのパスでだけ切る、といった使い方です。

Snippets は、ルールと Workers（18号）の中間にあるものです。式だけでは書けない、少しの計算やヘッダーの組み立てが必要なときに、数行の JavaScript で書けます。

さらに複雑な処理、例えば外部の API に問い合わせる、データを保存する、といったことが必要になったら、Workers の出番です。「まずルールで書けないか考え、書けなければ Snippets、それでも足りなければ Workers」と段階を上げていくのが基本の考え方です。

Page Rules は、もう新しく作れない

古くから Cloudflare を使っている人は、Page Rules という機能を知っているかもしれません。URL の型（example.com/blog/* のような）を条件に、転送・キャッシュ・各種の設定をまとめて変えられる、万能のルールでした。

でも、Page Rules には限界がありました。

そこで Cloudflare は、役目ごとの新しいルールを作り、Page Rules を非推奨（deprecated）にしました。2025年の初めからは、新しい Page Rules を作ることはできません。既存の Page Rules は、Cloudflare が順に新しいルールへ自動で移しています。

古い記事やブログには、今も Page Rules を使った手順が多く残っています。これから作るなら、最初から新しいルールで書いてください。

料金と制限

ルールは、無料プランから使えます。この号で扱った種類の多くは、無料プランでも作れます。

ルールの本数の上限は、2025年の見直しで全体に増えました。無料プランでも、種類ごとにある程度の本数が使えます。ただし、数字はプランや時期で変わるので、公式の各ルールの「Availability」の欄で確かめてください。

本数が足りなくなってきたら、まずルールをまとめられないかを考えます。例えば、同じ転送を10件書く代わりに、in {"/a" "/b" "/c"} のように一覧で条件を書いたり、Bulk Redirects に移したりできます。

※2026年9月時点の情報です。料金・上限は変わるので、公式で確かめてください。

よくある落とし穴

ルールは強力なぶん、ちょっとした書き間違いがサイト全体に効いてしまいます。

特に4つ目は気づきにくい問題です。ブラウザは 301 の転送を覚えてしまい、ルールを消しても、しばらく古い転送先に飛び続けます。開発者本人のブラウザでだけ直らない、ということがよくあります。まずは 302 で試すのが安全です。

ルールを作ったら、管理画面のトレース（Trace）の機能で、「この URL にリクエストが来たら、どのルールが当たるか」を確かめられます。本番で試す前に使ってください。

他の号とのつながり

この号で覚えたルール式は、05号（WAF）や06号（レート制限）でもそのまま使えます。「どのリクエストか」を表す書き方は、Cloudflare の中で1つに統一されているからです。