ホームページの表示速度やセキュリティについて調べていると、「Cloudflare を使うと良い」という情報を見かけることがあります。
ただ、Cloudflare はレンタルサーバーの名前として紹介されることもあれば、CDN やセキュリティのサービスとして説明されることもあります。さらに、Cloudflare Pages や Cloudflare Workers を使えば、Cloudflare 上で Web サイトやアプリケーションを公開することもできます。初めて調べる方にとって、全体像がつかみにくいのも無理はありません。
先に要点をお伝えすると、Cloudflare は、ドメインへのアクセスを案内し、閲覧者と Web サイトの間で通信を受け渡しながら、表示やセキュリティを支えるサービス群です。既存の WordPress サイトで使う場合、通常は WordPress やレンタルサーバーが Cloudflare へ置き換わるわけではありません。
この記事では、ホームページ運営者が Cloudflare を検討するときに知っておきたい役割を整理します。個別の導入手順や最適な設定は、サイトの構成や契約中のサービスによって変わるため、ここでは「何をする仕組みなのか」「どこまでが Cloudflare の役割なのか」を中心に扱います。
Cloudflare、サーバー、WordPress は役割が違う
最初に、それぞれの役割を分けておきましょう。
| 要素 | 主な役割 | たとえば… |
|---|---|---|
| ドメイン | ホームページへアクセスするための名前 | 住所の名前 |
| DNS | ドメイン名と接続先を対応させる | 住所を調べる案内帳 |
| レンタルサーバー | HTML、画像、WordPress のプログラムやデータを保管し、要求に応じて返す | 建物や保管場所 |
| WordPress | 記事や固定ページを管理し、Web ページを生成する CMS | 内容を作り、管理する仕組み |
| Cloudflare | DNS や通信の中継、キャッシュ、暗号化、通信の検査などを担う | 案内所と受付 |
CMS は「Content Management System」の略で、専門的なコードを毎回書かなくても、記事やページを作成・更新しやすくする仕組みです。WordPress は CMS のひとつです。
既存の WordPress サイトへ Cloudflare を導入する一般的な構成では、閲覧者からのアクセスを Cloudflare が先に受け取り、必要に応じてレンタルサーバーへ渡します。
このとき、WordPress 本体、画像、データベースなどは、引き続き元のサーバーにあります。Cloudflare の公式ドキュメントでは、このように Web サーバーの手前で通信を受け取り、転送または代理応答する仕組みを「リバースプロキシ」と説明しています。
Cloudflare を使い始めても、元のサーバーや WordPress の保守が不要になるわけではありません。 WordPress 本体、テーマ、プラグインの更新、バックアップ、障害対応は、Cloudflare とは別に続ける必要があります。
Cloudflare の基本機能をホームページ運営の視点で見る
Cloudflare には多くの製品がありますが、一般的なホームページと関係が深い基本機能は、DNS、CDN とキャッシュ、SSL/TLS、WAF です。
DNS はドメイン名から接続先を案内する
DNS は「Domain Name System」の略で、example.com のような人が読めるドメイン名を、コンピューターが通信先を見つけるための IP アドレスへ対応させる仕組みです。電話帳や住所案内にたとえられることがあります。
一般的な「フルセットアップ」で Cloudflare を使うと、Cloudflare がそのドメインの権威 DNS になります。権威 DNS とは、「このドメインはどの接続先を使うか」という最終的な DNS 情報を返す役割です。DNS レコードの管理場所も Cloudflare へ移ります。
ここで注意したいのは、DNS にはホームページ以外の接続情報も含まれることです。たとえば、メールの配送先や、外部サービスによるドメイン所有確認にも DNS レコードが使われます。Cloudflare へ切り替える前に既存の DNS レコードを確認しないと、ホームページだけでなくメールなどへ影響する可能性があります。
公式の導入手順でも、ネームサーバーを変更する前に DNS レコードを確認するよう案内されています。
CDN とキャッシュはデータを近くから返しやすくする
CDN は「Content Delivery Network」の略です。画像や CSS、JavaScript などのデータを複数の拠点から配信し、閲覧者に近い場所から返せるようにする仕組みです。
キャッシュは、一度取得したデータのコピーを一時的に保存し、同じ内容を求められたときに再利用する仕組みです。Cloudflare のキャッシュから応答できれば、元のサーバーへ毎回問い合わせる回数を減らし、表示時間やサーバー負荷を改善できる場合があります。
ただし、Cloudflare を有効にすれば、すべてのページが自動的にキャッシュされるわけではありません。公式ドキュメントによると、Cloudflare は既定では HTML や、データ交換に使われる JSON 形式をキャッシュしません。キャッシュできるファイル、元サーバーから返される指示、Cloudflare 側のルールなどによって動作が変わります。
WordPress では、ログイン中の画面、管理画面、カート、会員向けページ、フォーム送信後の表示など、利用者や操作によって内容が変わるページがあります。こうしたページを不適切にキャッシュすると、古い内容が残る、更新が反映されない、本来とは異なる内容が表示されるといった問題につながります。
したがって、「Cloudflare を導入したか」だけではなく、「何を、どの条件で、どのくらい保存するか」まで確認することが大切です。
SSL/TLS は通信を暗号化する
SSL/TLS は、閲覧者のブラウザと Web サイトの間で送受信される情報を暗号化し、通信中の盗み見や改ざんを防ぐための仕組みです。現在は TLS が使われますが、「SSL 証明書」という呼び方も広く残っています。
Cloudflare が通信の途中に入る構成では、次の2区間を考える必要があります。
- 閲覧者のブラウザから Cloudflare まで
- Cloudflare から元のサーバーまで
Cloudflare の公式ドキュメントでも、閲覧者へ提示するエッジ証明書と、Cloudflare から元のサーバーへの通信で使うオリジン証明書という、2種類の証明書が関係する場合があると説明されています。
ブラウザから Cloudflare まで暗号化されていても、Cloudflare から元のサーバーまでの設定が適切とは限りません。HTTPS で表示できたという結果だけで判断せず、元のサーバーの証明書と Cloudflare の暗号化モードを含め、通信経路全体を確認したいところです。
WAF は Web サイトへの通信をルールで検査する
WAF は「Web Application Firewall」の略で、Web サイトや API へ届く通信をルールに照らして検査し、不要または不審な通信を遮断、制限、追加確認する仕組みです。API は、異なるシステム同士がデータや機能をやり取りするための窓口です。Cloudflare WAF では、Cloudflare が用意するマネージドルールと、利用者が条件を決めるカスタムルールなどを利用できます。
WAF は WordPress への攻撃を減らす手段のひとつになりますが、導入すれば WordPress 自体の脆弱性がなくなるわけではありません。また、厳しいルールを設定すると、管理画面へのログインや画像のアップロードなど、正しい操作まで止めることがあります。
Cloudflare の WordPress 向け案内でも、セキュリティ機能が管理操作を妨げる場合があるため、ログを確認しながら必要な例外を狭く設定する流れが示されています。
WAF は「有効にしたら終わり」の機能ではなく、記録を見て、必要な通信と止めたい通信を調整し続ける仕組みとして考える方が良いでしょう。
WordPress サイトで Cloudflare を使う場合
すでにレンタルサーバー上で WordPress サイトを運営している場合、Cloudflare は主にサイトの手前に入ります。
基本的な通信の流れは、次のようになります。
- 閲覧者がドメインへアクセスする
- Cloudflare の DNS が接続先を案内する
- プロキシが有効な通信を Cloudflare が受け取る
- キャッシュから返せるデータは Cloudflare が応答する
- 必要な要求は元のレンタルサーバーへ送る
- レンタルサーバー上の WordPress がページを生成して返す
この構成でも、WordPress の記事編集やプラグイン管理は、これまでと同じ WordPress の管理画面で行います。レンタルサーバーの契約も基本的には続きます。
一方で、Cloudflare が通信経路へ加わるため、不具合が起きたときに確認する場所は増えます。DNS、Cloudflare のキャッシュやルール、元サーバー、WordPress のどこに原因があるのかを切り分ける必要があります。
たとえば、記事を更新したのに古い内容が表示される場合、WordPress 側だけでなく Cloudflare のキャッシュも確認します。管理画面へ入れない場合は、WordPress の不具合に加えて WAF の記録も確認します。元サーバーが Cloudflare からの通信を拒否していないか、SSL/TLS の設定が2区間で整合しているかも確認対象です。
僕は、Cloudflare を導入するかどうかを、機能数だけで決めない方が良いと考えています。運営者や保守担当者が、DNS の管理場所と設定変更の履歴を把握し、不具合時に Cloudflare と元サーバーの両方を確認できるか。そこまで含めて、導入後も無理なく運用できる構成かを判断したいところです。
Cloudflare 上でサイトを公開する場合
Cloudflare は、既存サーバーの手前で通信を中継するだけではありません。Cloudflare Pages や Cloudflare Workers を使い、Cloudflare のネットワーク上へ Web サイトやアプリケーションを公開する方法もあります。
Cloudflare Pages
Cloudflare Pages は、Git のリポジトリと連携したり、完成したファイルを直接アップロードしたりして、Web サイトを Cloudflare のネットワークへ配置できるサービスです。
Git のリポジトリは、変更履歴と一緒に制作ファイルを管理する保管場所です。ページの構造を記述する HTML、見た目を整える CSS、ブラウザ上の動作を加える JavaScript などで構成された静的サイトの公開に使えるほか、Pages Functions を組み合わせてサーバー側の処理を追加できます。
静的サイトとは、アクセスのたびにデータベースからページを生成するのではなく、あらかじめ用意したファイルを中心に配信するサイトです。
ただし、Cloudflare の公式ドキュメントは、2026年9月28日の確認時点で、Workers が Pages の多くの用途に対応し、より広い機能を持つ主要なアプリケーション基盤になったため、新しいプロジェクトは Workers から始めるよう案内しています。既存の Pages プロジェクトが直ちに使えなくなるという意味ではありませんが、新規採用では最新の位置づけと移行方針を確認する必要があります。
Cloudflare Workers
Cloudflare Workers は、サーバーを自分で構築・管理せずに、Cloudflare のネットワーク上でプログラムを動かせるサーバーレスのプラットフォームです。「サーバーレス」はサーバーが存在しないという意味ではなく、利用者が個別のサーバーを用意し、OS などを管理する負担を減らせる提供形態を指します。
Workers では、静的なファイルの配信に加え、API、フォーム処理、外部サービスとの連携など、要求に応じた処理を実装できます。
一方で、WordPress の管理画面やプラグインをそのまま Workers へ移せるわけではありません。WordPress とは仕組みが異なるため、サイトを Workers で作り直す場合は、記事の編集方法、データの保存先、フォーム、検索、更新担当者の作業まで含めた再設計が必要です。
導入すれば必ず速く、安全になるわけではない
Cloudflare には、表示やセキュリティを改善できる機能があります。ただし、効果は元のサイトと設定によって変わります。
たとえば、元のサーバーでページ生成に時間がかかり、該当ページをキャッシュしない構成なら、Cloudflare を通しても元サーバーの処理時間は残ります。画像が大きすぎる、不要な JavaScript が多い、WordPress のデータベース処理が遅いといった問題も、Cloudflare だけで解消するとは限りません。
セキュリティも同じです。WAF で遮断できる通信があっても、WordPress やプラグインの更新、強いパスワード、複数の確認手段を組み合わせる多要素認証、バックアップ、復元確認が不要になるわけではありません。元サーバーへ Cloudflare を経由せずにアクセスできる状態が残っていれば、想定した防御を迂回される可能性もあります。
また、DNS や SSL/TLS の設定を誤ると、サイトやメールが利用できなくなることがあります。Cloudflare の公式ドキュメントも、DNS レコード、証明書、元サーバーでの Cloudflare の IP アドレス許可などを確認してから、プロキシを有効にする手順を案内しています。
大切なのは、「Cloudflare を入れること」ではなく、現在の課題に必要な機能を選び、導入後も設定と記録を管理できることです。小規模なサイトで、現在のサーバーや運用に問題がなく、管理者を増やしたくない場合は、急いで導入しない判断もあります。
自分で確認できる範囲
設定を変更する前に、まずは次の情報を集めてみてください。この段階では、ネームサーバーや DNS レコードを変更する必要はありません。
- Cloudflare のログイン情報を管理している人がいるか
- ドメインを契約している会社と契約者名義
- DNS を現在どのサービスで管理しているか
- レンタルサーバーの契約先と管理者
- WordPress の管理者
- メールをどのサービスで利用しているか
- サイト更新、フォーム送信、会員、予約、購入など、止めたくない機能
- 表示速度、攻撃対策、DNS 管理など、Cloudflare を検討している理由
すでに Cloudflare を使っている場合は、管理画面へログインできるか、請求先と管理者は誰か、設定変更の記録が残っているかも確認します。
外部の確認サービスだけで DNS やサーバーの状態を推測し、契約者や管理者を断定しないようにしてください。請求書、契約メール、各サービスの管理画面など、手元の契約情報と照合する方が確実です。
専門家へ相談した方が良い状態
次のような状態では、自分で設定を変える前に、現在の構成を調査できる制作者やインフラの担当者へ相談した方が良いでしょう。
- DNS レコードやネームサーバーの役割が分からない
- ドメイン、DNS、サーバーの管理者が別々になっている
- 同じドメインでメールを利用している
- オンライン販売、予約、会員、外部 API など、止められない機能がある
- WordPress のログインや画像アップロードが Cloudflare 導入後に失敗する
- 更新内容が反映されず、キャッシュを消して良い範囲を判断できない
- SSL/TLS のエラーやリダイレクトの繰り返しが起きている
- 元サーバーへ直接アクセスできる状態をどう扱うか分からない
- Cloudflare のアカウント管理者と連絡が取れない
- Pages や Workers への移行を検討しているが、現在の WordPress 機能をどう置き換えるか決まっていない
Cloudflare の設定だけではなく、ドメイン、サーバー、メール、WordPress をまたいで確認できる相手へ相談することが重要です。大規模なネットワーク、社内システム、法令や契約上の要件が関係する場合は、それぞれの専門事業者や社内担当者にも確認してください。
相談前に用意しておきたい情報
相談するときは、次の情報が分かる範囲でまとまっていると、確認を始めやすくなります。
- ホームページの URL
- Cloudflare を使っているか、これから導入したいか
- 解決したい課題と、現在起きている症状
- 症状が始まった時期と、その直前に変更したこと
- ドメイン、DNS、サーバー、WordPress、Cloudflare の管理者
- 利用中のサーバー、メール、外部サービス
- Cloudflare やサーバーのエラー画面、通知、設定画面のスクリーンショット
- 希望する時期と、停止を避けたい時間帯
問い合わせフォームへパスワードや API トークンを書かないでください。API トークンは、外部のツールなどが Cloudflare へ接続するときに使う秘密の認証情報です。ログイン情報が必要になった場合は、相談後に安全な共有方法を確認してから渡します。
まとめ
Cloudflare は、レンタルサーバーや WordPress と同じものではありません。既存の WordPress サイトで使う場合は、閲覧者と元サーバーの間に入り、DNS、通信の中継、キャッシュ、SSL/TLS、WAF などで表示とセキュリティを支えます。
一方で、Pages や Workers を使い、Cloudflare 上にサイトやアプリケーションを公開する構成もあります。既存の WordPress へ Cloudflare を加える場合と、Cloudflare の基盤へサイトを作る場合を分けて考えると、役割を整理しやすくなります。
Cloudflare の導入で改善できることはありますが、元サーバー、WordPress、メール、DNS を含む構成と運用方法によって、必要な設定は変わります。導入すれば必ず高速・安全になると考えず、現在の課題、止められない機能、管理できる人を先に確認してみてください。
Cloudflare の導入や設定変更による WordPress サイトへの影響を整理したい場合は、ホームページの URL、現在の管理状況、困っていることを分かる範囲でまとめて、お問い合わせフォームからオレインデザインへご相談ください。個別の対応可否は、現在の構成と必要な確認範囲を伺ったうえで判断します。
