「Cloudflare を入れる」だけでは、制作者が次に何を触るか決まらない。DNS の前段だけなのか、サイト本体を載せ替えるのか、問い合わせをデータベースに残すのかが混ざる。
よしあきが扱う案件の多くは、会員も決済もないコーポレートサイトである。中身は 情報発信 と 問い合わせ窓口 の2つで足りることが多い。その型では、レンタルサーバー上のファイルと PHP はそのままにして、閲覧と送信の前に Cloudflare を足す、が既定に近い。
この記事は、同業の制作者がサイトを作る・直すときに、今の案件ではどの層まで足すか を決めるための地図である。料金や上限の数字は変わるので、実務では公式を正とする。
関連して、打ち合わせで「CDN」と言われたときの層分けは ライブラリ CDN とインフラ CDN に書いた。本稿はインフラ CDN のうち、Cloudflare を制作スタックにどう乗せるかの話である。
この記事で決めること
結論を先に置く。
- 静的サイト＋問い合わせ PHP、または WordPress なら、オリジン（実ファイルがあるレンタルサーバー）を廃止しない。WordPress を動かす PHP と MySQL は Cloudflare には無い
- Cloudflare はまず、ネームサーバを Cloudflare にして権威 DNS を移し、サイト用レコードだけプロキシする。ドメインを Cloudflare で買い直す話ではない
- Workers でサイト本体を載せ替える 話と、前段の話は分ける
- 問い合わせは Turnstile（見た目のウィジェット＋サーバー側のトークン検証）までが定番。受け皿を D1 に移す必要はない
.jpを使うなら、ドメインは他社のままネームサーバだけ Cloudflare、が本命。Registrar（Cloudflare でドメインを買う）の代わりに.comへ変える話とは分ける- 「全部 Cloudflare に集約」「HTML 全部がキャッシュされて速い」は、この型では言わない
対象外に近いものもある。会員・決済・ログインが本体のサービス、先方が最初から Workers 前提で組んでいるサイト、自分用の検証公開である。それらは別判断になる。
「Cloudflare を使っている」を分解する
先方や記事で Cloudflare が出たら、製品を混ぜない。同じアカウントでも、役割は別である。
| やりたいこと | 名前 | 制作案件での位置 |
|---|---|---|
| 閲覧者をオリジンに直接届かせない。証明書・CDN・一部の検出 | DNS ＋ プロキシ | コーポレートの既定で足す層 |
| エッジで短い処理を動かす。静的の公開先にもなる | Workers / Pages | 前段の部品、または載せ替え。標準スタックではない |
| 問い合わせや投稿を残す | D1 | WordPress の代替ではない。通常案件では見送り |
| 画像・PDF・動画を置く | R2 | オブジェクトストレージ。無料だから始めない |
| ドメインを取る・移す | Registrar | お名前.com 等の代替候補。.jp は非対応 |
「Cloudflare 導入済み」と言われたら、まず次を聞く。
- DNS とプロキシだけか、Workers / Pages / R2 もあるか
- 支払い方法は登録済みか
- ドメインは Cloudflare で取得したのか、他社取得でネームサーバだけか
- メールはレンタルサーバーのままか
プロキシを足した瞬間に付くものと、ダッシュボードで追加するものは別である。前者が経路・閲覧者向け HTTPS・オリジン IP を隠すこと、後者が Turnstile やリダイレクト規則である。
まず足す2つの操作（権威 DNS とプロキシ）
「権威 DNS ＋ Web 用ホストのプロキシ」は、ドメインを Cloudflare で買い直すことではない。 やっているのは次の2操作である。
- 権威 DNS を Cloudflare にする
「example.co.jpはどこへ行けばよいか」と聞かれたときに答える正本を、エックスサーバーやお名前.com から Cloudflare に移す。レジストラ（ドメインの購入・更新窓口）の画面で、ネームサーバを Cloudflare 指定のものに変える。 - Web 用ホストだけプロキシする
その正本のうち、サイト用のレコード（だいたい apex のexample.co.jpとwww）に オレンジ雲（Proxied） を付ける。閲覧者のブラウザはレンタルサーバーの IP ではなく、Cloudflare の IP に繋がる。
契約の層は3つで、全部が同じ会社である必要はない。
| 層 | 何をするか | 典型 |
|---|---|---|
| レジストラ | ドメインの所有・更新の窓口 | お名前.com、エックスサーバードメイン、Cloudflare Registrar |
| 権威 DNS | A / CNAME / MX / TXT の正本 | 同じレジストラの DNS、または Cloudflare DNS |
| Web ホスト（オリジン） | ファイルと PHP が実際にある場所 | エックスサーバー、シンレンタル など |
プロキシを付けると、Web の流れはこうなる。
ブラウザ
→ Cloudflare（証明書・キャッシュ・Turnstile などを足せる）
→ レンタルサーバー（今までどおりのファイル / WordPress）たとえ話にすると、住所録の管理を Cloudflare に渡し、ホームページの番地だけ「受付（Cloudflare）経由」と書く、である。社屋（レンタルサーバー）は引っ越していない。
メール用レコードは プロキシしない（DNS only、灰色の雲） にする。メールソフトはレンタルのメールサーバーへ直接届く必要がある。Web 用だけオレンジ雲、mail は灰色、がセットである。メール用の A レコードを DNS only にすると、ダッシュボードが「オリジン IP が一部露出」と出すことがある。Web 用をプロキシしたままなら、その警告はメール用として無視してよい。
オレンジ雲の意味は公式の プロキシ状態 を正とする。
コーポレートの主機能は2つ
| 機能 | 中身 | Cloudflare が効くところ |
|---|---|---|
| 情報発信 | 会社情報、サービス、事例、FAQ。ニュースやコラムは更新コンテンツ | 静的ファイルのエッジ配信。HTML 全部がキャッシュされるとは限らない。更新の仕組み（CMS）は付いてこない |
| 問い合わせ窓口 | フォーム1本。協業ページも同じ受付に落とすことが多い | 経路の HTTPS。Turnstile（ウィジェット＋サーバー側検証） |
見た目だけ Turnstile を置くと意味が無い。ボットは受付 URL に直接送れる。PHP のメールフォームでも Contact Form 7 でも、製品は同じで、足し方だけが違う。
エッジ は、閲覧者とオリジンのあいだの配信地点である。閲覧者向けの証明書の発行・更新を Cloudflare が担う（Universal SSL など）。オリジンとエッジのあいだは別の証明書で、ダッシュボードの SSL モード（Flexible / Full / Full strict）は別確認になる。Full (strict) はオリジンの証明書を検証するので、切ると繋がらなくなる。公的 CA か確認してからにする。
WordPress を作るとき、サーバー契約は別途必要か
本物の WordPress（PHP ＋ MySQL）を動かすなら、Cloudflare とは別にホストが必須である。 Cloudflare は PHP もデータベースも動かさないので、WordPress の置き場にはならない。
| やりたいこと | Cloudflare だけで足りるか | 別途必要なもの |
|---|---|---|
| WordPress で会社サイト | 足りない | PHP と MySQL があるホスト（エックスサーバー、シンレンタル、他社の WP マネージドなど） |
| その WordPress の前に証明書・CDN・Turnstile | 前段としては足りる | 上のホストは残したまま、権威 DNS とプロキシを足す |
| 静的 HTML だけ（フォームなし／外部フォーム） | Pages 等で 選択肢 | レンタルは必須ではない（よしあきの既定スタックの置き換えではない） |
先方がすでに Cloudflare を使っていても、「WordPress 用のオリジン（レンタル）があるか」は別確認である。「Cloudflare だけ契約すれば WordPress が動く」は動かない。見た目が近い実験的な CMS を Workers に載せる話は別物で、WordPress そのものではない（EmDash の整理）。
Cloudflare のエッジでは PHP は動かない。Pages や Workers だけにサイトを移すと、WordPress も PHP のメールフォームもそこで動かない。一方、オリジンに PHP を残して前段だけ Cloudflare なら、PHP はそのまま動く。二者択一ではない。
速さは「事前に動いている」ではない
WordPress は、アクセスのたびに PHP が URL を解釈し、必要ならデータベースから HTML を組み立てて返す。Workers も、リクエストが来てから エッジで短い JavaScript を動かす。言語と場所が違うだけで、「Workers は事前に動いているから速い」ではない。
速さの説明は次の組み合わせにする。
| 何が速いか | 実体 | Workers か |
|---|---|---|
| 画像・CSS・JS | 以前の応答をエッジに置き、近い拠点から返す | いいえ。プロキシだけで起きうる |
| 静的 HTML | デプロイ時に HTML を作って置く | いいえ。静的配信 |
| Workers 自体 | リクエスト時に動く。ユーザーに近く、WordPress の起動と MySQL が無い | はい |
WordPress が遅く感じやすい理由は、「毎回リクエストする」こと自体より、毎回コア・プラグイン・テーマを起動して DB まで行く ことと、オリジンが閲覧者から遠い ことである。
閲覧者
│ どちらも「その都度リクエスト」
▼
Cloudflare の拠点（エッジ）
│ ・CSS/JS がキャッシュ済み → ここで返す
│ ・Workers があればここで短い JS が動く
▼
オリジン（レンタルサーバーの PHP / WordPress）
HTML が都度取りに行く設定なら、だいたいここまで届く公開面では「CDN で速い＝ HTML 全部がキャッシュ」と言わない。ハッシュ付きの CSS / JS はエッジに乗りやすく、HTML は都度オリジンまで届くことが多い。正規化（www と apex、http と https）は、規則を足すまで、レンタルサーバー直公開と同じ見え方のまま、ということもある。
Workers の使い方は3つある。「活用する」を「WordPress を JavaScript で置き換える」と読まない。
| 使い方 | 何をするか | PHP / WordPress との関係 |
|---|---|---|
| 前段だけ | リダイレクト、ボット判定、ヘッダ加工 | オリジンの PHP はそのまま。間に挟まるだけ |
| API / フォームだけ | /api/contact などをエッジで受ける | サイト本体は別 |
| サイト本体を載せる | URL を見て HTML や JSON を返す | ここで初めて「PHP の代わりに JS」 |
案件の型で、レンタルサーバーが要るか決める
| 案件の型 | レンタルサーバー（PHP ホスト） |
|---|---|
| 静的のみ。フォームなし、または外部フォーム。更新は Git | Pages だけでも選択肢。既定スタックの置き換えではない |
| PHP のメールフォーム / Contact Form 7 / WordPress | 必要（Cloudflare アカウントとは別契約） |
同じ契約で郵便受け（info@独自ドメイン の受信箱） | サイト公開とは別にメールの出口が要る。Pages には郵便受けが無い |
| 静的で納品し、あとから写真やページを足す運用 | なしは推奨しない。 公開と差し替えの出口がレンタル側にある前提が扱いやすい |
問い合わせスパムが多いなら Turnstile、画像が多く配信を速くしたいなら静的のエッジキャッシュに余地がある。どちらも、サイトを Workers に載せ替える必要はない。先に容量と枚数を見る。HTML 全部が速くなる、とは言わない。
無料プランのまま、今足してよいもの
前提は、ファイルとメールはこれまでどおりオリジン、という状態である。そのうえで前節の2操作（権威 DNS の移動、Web 用だけプロキシ）を済ませる。
プロキシにした瞬間に付くものと、追加で足すものを分ける。
すでに付いていることが多いもの
- 閲覧者はオリジン IP に直接届かない
- 閲覧者〜エッジの HTTPS（Universal SSL）
- 一部の DDoS 検出
- 静的アセットはエッジに乗りうる。HTML は都度取りに行きやすい
無料のまま追加しやすいもの
| 候補 | 何か | 注意 |
|---|---|---|
| Turnstile | 問い合わせのボット対策。多くの利用者は画像選択なし | ウィジェットだけ置かず、サーバー側でトークン検証 |
| Always Use HTTPS | http:// を https:// へ | オリジン側の http→https と二重だとループしうる |
| Redirect Rules | www / apex の正規化 | プロキシしているとき この層。DNS only ならオリジンの .htaccess。両方はやらない |
| Cache Rules | ハッシュ付き CSS / JS などを明示的にキャッシュ | HTML は都度取りに行くままでよいことが多い |
| SSL を Full (strict) | オリジン証明書を検証 | オリジンが公的 CA か確認してから |
| Block AI bots | 学習クローラを止める | 検索エンジン用クローラとの切り分けを読んでから |
Bot Fight Mode は既知ボットへのチャレンジがあるが、誤検知がある。問い合わせ防衛なら Turnstile の方が直結しやすい。
やらない寄り
- サイトを Pages / Workers に載せ替える
- 問い合わせを D1 に移す
- R2 を「無料だから」で始める（支払い登録が入口で、超過は従量）
- メール用レコードをプロキシする
有料プラン（ゾーンの Pro）は、Managed の WAF やサポートの話になる。小規模コーポレートで「Pro にしないと守れない」とは限らない。スパムや攻撃が無料の範囲を超えてからでよいことが多い。ゾーンの Pro と、R2 / Workers Paid は別口である。「同じ Cloudflare だから全部無料」とは言わない。
フォームの受け皿は、前段とは別件
外部の発信に「静的ならレンタル不要」「全部 Cloudflare に集約」とあっても、フォームの POST の行き先は別途決める。
Email Routing は、人が info@独自ドメイン に送ったメールを、検証済みの受け皿へ転送する機能である。サイトのフォーム送信の受け皿ではない。権威 DNS が Cloudflare であれば Registrar 移管は不要だが、有効化するとルートの MX を Cloudflare が管理する。既存のレンタルメールサーバーと共存できない。 郵便受けでもなく、送信・保管は別である。既存メールがあるゾーンでは足さない。
レンタルなし前提で取りうる型は次である。実装の細部は案件ごとに確認する。
| 型 | 何をするか | 向くもの | 注意 |
|---|---|---|---|
| 外部フォーム | Google フォーム、Tally、Formspree 等に飛ばす | LP・更新が少ない自社 | 見た目とドメインが別れやすい。個人情報の置き場が先方 |
| Functions ＋ 自分への通知だけ | POST を Pages Functions / Workers で受け、検証済みの自分の宛先へ送る | コーポレート1本 | 相手への自動返信は別課金になりやすい。公式の最新を見る |
| Functions ＋ メール API | 同上＋ Resend / SendGrid 等 | 自動返信が欲しいとき | 秘密は環境変数。Functions は Workers の枠。上限で止まる |
| Functions ＋ Slack 等 | メールせず Webhook | 自分が見られれば足りる | クライアントがメール受信を求めると足りない |
| D1 に残す | 送信を DB に保存し、通知は上のいずれか | 「CMS も Cloudflare に」の延長 | 保管・権限・バックアップが要る。WordPress の代替ではない |
どの型でも Turnstile（ウィジェット＋サーバー側検証）が定番である。
クライアントが 自動返信 と メールでの受信 を求めるなら、Functions 寄せより、レンタル上の PHP フォームの方が事故が少ない。よしあきの既定はこちらである。
課金は「止まって終わる」か「従量になる」か
機能一覧より、課金の型を先に見る。
-
Workers Free と D1
支払い方法を登録しなくても始められる。無料枠を使い切っても自動で有料にはならず、それ以上使えなくなる（止まる）。 -
R2
無料枠はあるが、利用開始時に支払い方法の登録が必要。超えたらプラン切替なしで 従量課金 になる。 -
Workers Paid
裏側の処理や D1 の読み書きが無料上限に当たってエラーが頻発するときの次段。Paid でも上限があり、超えると止まるのではなく 超過分が従量 になる。
静的配信と、Functions / Workers / D1 / R2 / AI 呼び出しを、同じ「無料公開」にまとめない。Pages Functions のリクエストは Workers の枠になる点に注意する。
記事時点（2026年8月）で特に引っかかりやすいのは次である。最新値は公式を見る。
- Workers の CPU 時間（Free は 1リクエストあたり短い上限）
外部 API や DB 待ちは対象外とされることが多い。単純なデータ返却なら足りることが多い。集計や画像処理を Workers にやらせると足を引っかけやすい。 - R2 の保存容量
読み書き回数より、画像・動画・ドキュメントを溜め続けると先に超えやすい。
バグや意図しない大量アクセスでも上限に達しうる。使用量の定期確認と 課金アラート を付ける。先方が「AI で Cloudflare を入れた」案件では、ダッシュボードで Workers / R2 の課金有無とアラートを見る項目にしてよい。
.jp が Registrar 非対応のとき、代わりは何か
非対応なのは Cloudflare Registrar（ドメインの購入・移管先） である。.jp でも Cloudflare DNS（権威 DNS だけ借りる）は使える。 .co.jp も同じである。
ここは2種類の「代わり」が混ざる。日本のコーポレートでは、TLD を変える方が本命ではない。
A. .jp のまま Cloudflare を使う（勧めやすい）
- ドメインはこれまでどおりお名前.com / エックスサーバードメイン / ムームードメイン など
- ネームサーバだけ Cloudflare にする（前節の操作1）
- Web 用をプロキシする（操作2）
既存の会社サイトで多い型はこちらである。「Cloudflare で独自ドメインを取れ」と一律に勧めない理由がこれである。
B. ドメイン自体を Cloudflare で取りたいとき
Registrar で取れる代表は次である（2026年時点。TLD 一覧 が正。ダッシュボードの検索に出なければ非対応）。
| 用途の目安 | 例 |
|---|---|
| 実務の本命 | .com / .net / .org |
| テック・個人・検証 | .dev / .app / .io / .me |
| 安めの汎用 | .xyz / .online / .site / .shop |
.jp や .co.jp の同等の代わりではない。 日本法人の信頼、メールアドレス、既存の印刷物まで含めると、.com に変えるのはブランド判断である。安さのために .xyz へ寄せる、はコーポレートでは勧めにくい。
Registrar 側のほかの制約もセットで見る。
- 手数料なしの原価販売なので、長期の更新料は安くなりやすい、とされる
- 他社からの移管では、1年分の更新料を先払いする形になる
- 日本語ドメイン（国際化ドメイン / Punycode）は非対応
- ネームサーバを Cloudflare 外に変更できない（一度移管すると NS を外に戻せない）
まとめ: .jp が欲しい → 他社で取ってネームサーバだけ Cloudflare。 Cloudflare で安く取りたい → .com 等を新規で検討。既存の .jp を Cloudflare レジストラに移す、は今はできない。
Email Routing は前述のとおり、既存 MX がある案件では足さない。
Workers ＋ D1 ＋ R2 を標準スタックにする ことも、よしあきの通常案件では見送りである。小規模静的の自分用公開や、先方が最初からその前提のときの説明材料、という位置づけに留める。
着手前チェックリスト
制作に入る前、または先方環境を触る前に、これだけ確認する。
- 権威 DNS はどこか（Cloudflare か、レジストラか、レンタルか）
- apex と
wwwはプロキシされているか。メール用は DNS only か - WordPress / PHP フォームがあるなら、オリジンのレンタル（PHP ＋ 必要なら MySQL）はどこか。Cloudflare アカウントと別か
- フォームは何か（PHP のメールフォーム、Contact Form 7、外部フォーム、未定）
- 郵便受けは同じレンタル契約か。MX / SPF / DKIM は誰が持っているか
- 支払い方法は登録済みか（R2 があると従量の入口が開いている）
- 課金アラートは付いているか
- ドメインは Registrar か、他社取得＋ネームサーバだけか（
.jpなら後者のことが多い） - 正規化は Cloudflare の Redirect Rules か、オリジンの
.htaccessか。両方になっていないか - Turnstile を足すなら、サーバー側検証の置き場はどこか（
mail.php、プラグイン、Functions）
エンドクライアント向けに横展開しやすいのは、DNS を Cloudflare にして Web をプロキシする、問い合わせに Turnstile、プロキシしているなら正規化は Redirect Rules、説明は「前段／キャッシュ／フォーム」を分ける、までである。
説明で言わないこと
- HTML 全部がキャッシュされて速い
- Cloudflare にしたから更新の仕組み（CMS）が付く
- Workers を使う＝ WordPress を置き換える
- Cloudflare だけ契約すれば WordPress が動く
- PHP サーバーと Cloudflare は同時にできない
.jpが欲しいのに、Registrar 用として.xyzへ寄せる- Email Routing をフォームの後ろに置く
- 「全部 Cloudflare に集約」を、既存メールと PHP オリジンがある案件にそのまま当てる
- 同じ Cloudflare だから全部無料
まとめ
会員・決済のないコーポレートなら、発信と窓口 に分け、Cloudflare は 閲覧と送信の前段 として足す。オリジンの PHP は残してよい。WordPress ならレンタルは別途必須である。
足す順番は、ネームサーバ変更（権威 DNS）→ Web 用だけプロキシ（メールは DNS only）→ HTTPS と正規化の二重化を避ける → Turnstile（検証まで）である。Workers / D1 / R2 / Registrar は、必要になってから個別に見る。.jp は他社レジストラのまま DNS だけ借りる。課金は「止まって終わる」ものと「従量の入口が開く」ものを混ぜない。
「使っている」と言われたら、製品名の前に どの層か を聞く。それが、次の案件で迷わないための地図になる。