Cloudflareで守れる場所は、機能ごとに違う
会社のサイトをCloudflareに移すときは、まず何を守りたいかを分けます。訪問者がページを開く、フォームを送る、担当者が確認用ページを見る。この三つだけでも、通る場所と必要な対策は同じではありません。
Cloudflare WAFは、Webサイトに来る通信をルールに照らして調べる機能です。たとえば不審なリクエストを止める役割があります。ただし、元のプログラムの欠陥を直す機能ではありません。第1回で扱ったPHPの問題のように、修正版が出ているときは更新を先に行います。
この連載の第2回ではWordPressからの移行手順を説明しました。今回は移行先で名前を見かける六つの機能を、選び方に絞って整理します。具体的な管理画面の設定値や、the N Creativeの個別の防御設定は掲載しません。
まず、何に困っているかで選ぶ
- 怪しいアクセスを減らしたい：WAF。ページやAPIへ来る通信をルールで検査します。
- 大量アクセスでサイトが見られなくなるのを防ぎたい：DDoS対策。攻撃的な大量通信を検知し、緩和します。
- 訪問者との通信を暗号化したい：TLS。ブラウザーに表示されるHTTPSを支えます。
- 確認用サイトを関係者だけに見せたい：Access。本人確認と許可条件を加えます。
- フォームへの機械的な送信を減らしたい：Turnstile。送信時の確認に使います。
- 公開ページの動かし方を見直したい：Workers。HTMLなどのファイルを配信し、必要な処理も実行できます。
後半では、それぞれの「守れること」「使う前の確認」「守れないこと」を説明します。機能を全部入れることが目的ではありません。自社サイトにないもの、たとえば関係者限定のページがなければ、Accessを急いで使う必要もありません。
最初の確認：通信はCloudflareを通っているか
CloudflareのDNSにドメインを登録するだけで、すべてのWeb通信がCloudflareを通るわけではありません。CloudflareのDNS公式説明では、Web用のレコードを「Proxied」にするとCloudflareが訪問者と配信元の間に入り、「DNS only」では元の配信先へ直接つながると説明しています。WAFやWeb向けのDDoS対策を期待する場合は、対象の通信が実際にCloudflareを通る構成かを確かめます。
元のサーバーを残す構成なら、別の入口からそこへ直接アクセスできないかも確認が必要です。Cloudflare自身が元サーバーを保護する方法を案内しています。入口だけを整えて、裏口を開けたままにしないためです。反対に、メール用のDNSなど、Webの代理配信を通さないものまで一律に「Proxied」にする話ではありません。
この条件は全機能に同じ形で当てはまりません。TurnstileはCloudflareの代理配信を使わないサイトにも導入できます。Accessは保護したいアプリを指定して設定します。Workersはページを届ける仕組みそのものとして使う場合があります。どこを通る通信に、どの機能を置くのかを一枚の簡単な図にしてから選ぶと、見落としを減らせます。
1. WAF：不審なWebアクセスを調べる
WAFは、WebサイトやAPIへ届くリクエストを、用意されたルールや自分で作るルールに照らす機能です。CloudflareのWAF公式資料には、Managed RulesとCustom Rulesが説明されています。たとえば、既知の攻撃パターンに似た通信を検知したり、特定の条件に合うアクセスへ対応したりできます。
守れること。 Cloudflareを通るWeb通信について、ルールに合う不審なアクセスを遮断・検査できます。サイト側へ届く前に対応できる点が利点です。一般公開のページだけでなく、対象となるWeb用の入口を見定めて使います。
使う前の確認。 まず対象のホスト名が代理配信の対象か、どのルールを利用できるプランかを確認します。CloudflareのWAF導入ガイドは無料のManaged Rulesetと、プランによって異なるルール群を分けています。導入後は、通常の閲覧と問い合わせが通るかを試します。正しい訪問者まで止めてしまうことがあるためです。
守れないこと。 WAFはPHPやWordPress、プラグインの更新を代行しません。新しい攻撃を必ず見つける保証もなく、Cloudflareのトラブルシュート資料には、正しい通信を止める場合と、悪意ある通信を見逃す場合の両方が示されています。「WAFを入れたので更新しなくてよい」という判断はできません。
2. DDoS対策：大量の攻撃通信を緩和する
DDoSは、多数の場所から大量の通信を送り、サービスを使いにくくする攻撃です。CloudflareのDDoS対策資料によると、攻撃の検知と緩和は全プランで提供されます。
守れること。 Cloudflareを通る通信に対する大量アクセス攻撃の影響を抑えることを狙います。WAFが「届いたWebリクエストの中身や条件」を見るのに対し、こちらは大量通信によるサービス停止を防ぐ役割です。両者は重なり合う場面があっても、同じ機能ではありません。
使う前の確認。 Web用の通信がCloudflareを通るかを見ます。導入後は、正しい訪問者がページを開けるか、フォームを送れるかも確かめます。大量アクセスには広告やイベント告知で急に人が増えた場合もあるため、正常なアクセスを攻撃と決めつけない確認が要ります。
守れないこと。 大量通信を緩和しても、サーバー上の欠陥、フォームの不正入力、誤った権限設定は直りません。また、Web以外の通信やCloudflareを通らない入口まで、同じ保護が自動で及ぶと考えないでください。稼働率を保証するものでもありません。
3. TLS：通信を暗号化する
ブラウザーのアドレス欄にある「https」は、訪問者とサイトの間でやり取りする通信を暗号化する仕組みに支えられています。その中心になる技術がTLSです。CloudflareのUniversal SSLは、条件を満たすドメインに証明書を用意します。証明書が用意されても、Cloudflare側の証明書が訪問者に提示されるのは、対象の名前が代理配信される場合です。
守れること。 訪問者のブラウザーとCloudflareの間の通信を暗号化します。たとえば問い合わせフォームで名前や内容を送るとき、経路上で通信をそのまま読まれないようにするための基本です。
使う前の確認。 HTTPSでページを開けるか、証明書の対象に必要なドメインやサブドメインが含まれるかを試します。別の元サーバーへCloudflareから接続する構成なら、訪問者からCloudflareまでと、Cloudflareから元サーバーまでの二つの経路を分けて確認します。CloudflareのFull (strict)説明には、元サーバーの証明書も検証する接続方式が記されています。構成を見ずに設定名だけを選ぶべきではありません。
守れないこと。 HTTPSの表示だけで、ページの内容が正しいことや、フォームの保存先が安全なことまでは証明できません。TLSは通信経路の対策であり、閲覧権限やアプリの欠陥は別に扱います。
4. Access：関係者だけが開ける入口を作る
公開前の確認用サイトや社内向けの画面には、検索から見えないようにする設定だけでは足りません。Cloudflare Accessは、対象のアプリに入る前に本人確認と許可条件を適用する機能です。公式の設定ガイドでは、保護対象のアプリを登録し、許可する人の条件と本人確認の方法を設定します。
守れること。 許可した人だけに確認用サイトや社内向けアプリを見せる入口を作れます。一般の訪問者に見せる本番ページと、担当者だけが見るページを分けたい場合に向きます。
使う前の確認。 どのURLを保護し、誰を通すかを決めます。作業者だけでなく、依頼主が正しく開けるかも試します。公開ページ全体に誤って制限をかけると、見込み客がサイトを見られなくなります。利用人数や認証方法の条件は、Cloudflareの現行プラン案内で確認します。
守れないこと。 Accessは公開ページの脆弱性修正や、フォームの迷惑送信対策ではありません。許可を得て入った後の操作まで、すべて安全にするわけでもありません。中で扱うデータや権限は別に設計します。
5. Turnstile：フォームの機械的な送信を減らす
問い合わせフォームは、見込み客にとって連絡の入口です。同時に、機械的な送信が集まりやすい入口でもあります。Turnstileは、自動化された送信を見分ける助けになる仕組みです。Cloudflareの利用条件によると、Cloudflareのほかのサービスを使わないサイトにも導入できます。
守れること。 フォームへの自動送信を減らす助けになります。ページを見るだけの訪問者へ制限を広げず、送信の入口に対策を置けます。
使う前の確認。 画面に部品を表示するだけでは完了しません。受信側でトークンをSiteverifyに送って検証することが必須です。実際の問い合わせで送信・記録・通知・自動返信が動くか、迷惑送信対策が正しいお客さまの送信を妨げないかを確認します。
守れないこと。 Turnstileだけで迷惑メールがゼロになるとは言えません。入力された内容が正しいか、添付ファイルが安全か、受け取った個人情報をどう保管するかは、フォーム本体と運用側で扱います。画面の部品だけを置いて受信側で検証しなければ、対策として完成していません。
6. Workers：公開ページの作り方を変える
Workersは、Cloudflare上で処理を実行する仕組みです。Workers Static Assetsを使うと、HTML、CSS、画像などのファイルを配信でき、必要な場所ではWorkerのプログラムも動かせます。ここはWAFやTurnstileとは役割が違います。攻撃を見つける専用の盾ではなく、サイトをどう作り、どこで動かすかという選択肢です。
守れること。 公開ページをファイルとして配信できる構成なら、その公開ページの表示にPHPを使わずに済みます。これは「PHPを動かす場所を減らす」という設計上の効果であって、Cloudflareが既存のPHPを自動で直すという意味ではありません。WordPressを別の用途で残すなら、その保守は続きます。
使う前の確認。 記事や画像だけでなく、フォーム、検索、会員機能など、今のサイトで動いている仕事を洗い出します。静的ファイルの配信とWorkerのプログラム実行では、利用条件・上限が別です。無料で使える範囲を判断するときも、ファイルだけを見るのでは足りません。
守れないこと。 Workerで動かすプログラムにも設計や入力検証が必要です。PHPを使わなくなっても、新しい処理に欠陥を作れば別のリスクが生まれます。問い合わせの受信、保存、通知に使う別サービスの管理も残ります。静的な配信への変更を「セキュリティ対策の完了」と呼ばない理由です。
無料枠で考えるときの注意
Cloudflareの機能には無料で始められるものがあります。ただし「Cloudflareは無料だから、六つすべてを同じ条件で使える」とは言えません。2026年11月3日時点の公式資料では、DDoS対策は全プランにあります。WAFは無料プランでも使えるルール群があり、使えるルールや細かな調整はプランで異なります。Universal SSLも提供されますが、証明書が対象とする名前や代理配信の条件を確認します。TurnstileにはFreeとEnterpriseの区分があり、Accessは利用人数や認証方法の条件、Workersはプログラム実行と静的ファイルの条件をそれぞれ見ます。
見積もるときは、必要な機能ごとに「無料で使える条件」「利用が増えたときの上限」「有料の機能が必要になる理由」を確認してください。サービス料金と、サイトの制作・保守にかかる費用も別です。料金や上限は変わるので、契約の前にはCloudflareのプラン一覧と各機能の公式資料を開き直します。
自社サイトで最初に確かめる三つのこと
1. 入口を三つに分ける。 公開ページ、問い合わせフォーム、関係者だけが見るページを書き出します。ページが一つしかない会社でも、フォームがあれば二つ目の入口があります。元のサーバーを残すなら、その入口も別に書きます。
2. 守る目的を一つずつ付ける。 公開ページへ来る不審な通信にはWAF、大量通信にはDDoS対策、送信にはTurnstile、関係者限定の画面にはAccessというように結び付けます。TLSは通信経路に、Workersは公開ページの構成に関わります。機能名を並べる前に、目的が空欄の入口をなくします。
3. 正しいお客さまの動線を試す。 スマートフォンとPCでページを読み、問い合わせを送ります。必要な担当者が確認用ページを開けるかも見ます。保護を強めると閲覧や送信を誤って止めることがあるため、導入後も確認を続けます。
the N Creativeでも、公開ページと問い合わせの安全対策を分けて考え、移行後の表示と送信を確認しました。ここで紹介した六つをすべて採用したという意味ではありません。会社ごとにサイトの機能と運用が違うため、同じ設定をそのまま当てはめることはできません。
よくある質問（FAQ）
Q. Cloudflare WAFを使えば、WordPressやPHPの更新は不要ですか？
A. 不要にはなりません。WAFはCloudflareを通る通信をルールで調べる追加の対策です。WordPress、PHP、プラグインに修正版が出たら、更新の必要性を確認してください。PHPの問題が見つかったときの順序は第1回にまとめています。
Q. CloudflareへDNSを移しただけで、WAFとDDoS対策が効きますか？
A. そうとは限りません。対象のWeb通信がCloudflareを通るかを確認します。DNS onlyのWeb用レコードは、元の配信先へ直接つながります。別の入口から元サーバーに届く場合も、対策の範囲を分けて考えます。
Q. フォームにはWAFとTurnstileのどちらが必要ですか？
A. 目的が違います。WAFはWeb通信をルールで調べ、Turnstileは送信時の機械的な操作を見分ける助けになります。フォームでTurnstileを使うなら、画面への表示と受信側でのトークン検証が一組です。フォームの入力内容や通知先の管理も必要です。
Q. Workersを使えば、サイトのセキュリティ対策は完成しますか？
A. 完成しません。公開ページの配信方法は変えられますが、フォームなどの処理には別の設計と検証が要ります。旧環境を残すなら、そちらの更新も続けます。移行の工程は第2回で説明しています。
用語の説明
- WAF：Webサイトへ来る通信をルールに照らして調べる仕組み。元のプログラムを修正するものではありません。
- DDoS：多数の場所から大量の通信を送り、サイトやサービスを使いにくくする攻撃。
- TLS／HTTPS：訪問者とサイトの通信を暗号化する技術と、それを使ってWebページを開く方式。
- Access：指定したアプリやページに、本人確認と「誰を通すか」の条件を付けるCloudflareの機能。
- Turnstile：フォーム送信などで機械的な操作を見分ける助けになる機能。受信側での検証も必要です。
- Workers：Cloudflare上でプログラムを動かし、必要に応じてWebページのファイルも届ける仕組み。
- 静的ファイル：あらかじめ作ったHTML、CSS、画像など。ページを開くたびにPHPで本文を組み立てる方式とは異なります。
- Proxied／DNS only：Web通信をCloudflare経由にするか、元の配信先へ直接向けるかを示すDNS設定の違い。
- 元サーバー：Cloudflareの後ろに別の配信元を置く構成で、Webページや処理を実際に持つサーバー。
- トークン：Turnstileの確認結果を受信側へ渡すための短いデータ。受け取っただけで信頼せず、受信側で検証します。
参考情報
- Proxy status
- Protect your origin server
- Overview of Cloudflare WAF
- Get started with Cloudflare WAF
- Troubleshoot managed rules
- Cloudflare DDoS Protection
- Enable Universal SSL certificates
- Full strict SSL TLS encryption mode
- Publish a self-hosted application to the Internet
- Cloudflare Turnstile plans
- Validate the token
- Static Assets
- Billing and Limitations for Static Assets
- Cloudflare plans
