「Cloudflare（クラウドフレア）を使えば、レンタルサーバーは必要なくなるの？」
「レンタルサーバーを契約しているのに、Cloudflareも導入する意味はあるの？」
ホームページを運用していると、このような疑問を持つことがあるのではないでしょうか。Cloudflareとレンタルサーバーは、どちらもWebサイトに関係するサービスですが、基本的な役割は異なります。
この記事では、サーバーやネットワークの専門知識がない方にも分かるように、両者の違いから、ホームページが表示される仕組み、併用するメリット、メール設定の注意点、使い分けの考え方までを、図解を交えて解説します。
最初に、両者の基本的な役割を整理しておきましょう。
レンタルサーバーは、インターネット上でホームページを公開するために、サーバーの機能を借りるサービスです。
ホームページを家に例えるなら、レンタルサーバーは家そのものにあたります。
家の中に家具や家電を置くように、レンタルサーバーには、HTML、CSS、画像、JavaScriptなどのファイルや、必要に応じてデータベースやプログラムを置きます。訪問者がホームページを開くと、サーバーは求めに応じてファイルやページのデータを返します。
レンタルサーバーには、例えば次のような役割があります。
ただし、これらすべての機能が、すべてのレンタルサーバーで同じように提供されるわけではありません。
静的なHTMLファイルを公開するだけの使い方もあれば、WordPressのようにプログラムとデータベースを使う使い方もあります。
Cloudflareは、Webサイトやインターネット上のサービスを、より安全で快適に利用できるようにするためのサービスです。
家の例えで言えば、訪問者を出迎えて不審な人を通さない「門番」と、荷物を近くの拠点から届ける「配達網」を合わせたような役割です。
代表的な機能は、次のとおりです。
| 機能 | 役割 |
|---|---|
| DNS | ドメインと接続先の情報を管理する |
| CDN | コンテンツを世界各地のネットワークから配信する |
| リバースプロキシ | 訪問者と公開元サーバーの間で、通信を仲介する |
| DDoS対策 | 大量の通信による妨害への対策を支援する |
| WAF | 不正なWeb通信を検知・遮断する |
| SSL/TLS | 通信を暗号化するための設定を支援する |
| キャッシュ | コンテンツを一時的に保存し、再利用する |
さらに、Cloudflare WorkersやCloudflare Pagesなど、プログラムを動かしたり、Webサイトを公開したりするためのサービスもあります。
つまりCloudflareは、単なるセキュリティサービスではなく、Webサイトの通信・配信・保護、そして一部の公開や処理まで、幅広い機能を持っています。どの機能を使うかによって、できることは変わります。
| 比較項目 | レンタルサーバー | Cloudflare |
|---|---|---|
| 基本的な役割 | Webサイトの公開元になる | 通信・配信・保護などを支援する |
| ファイルの保管 | 主な用途の1つ | 使う機能によって異なる |
| PHPやデータベース | 対応プランなら利用できる | 一般的なレンタルサーバーと同じ仕組みではない |
| 表示の高速化 | サーバーの性能や設定による | CDNやキャッシュを利用できる |
| セキュリティ対策 | サーバー側の機能や設定による | DDoS対策、WAFなどを利用できる |
| DNS | 提供会社の機能を使える場合がある | DNSサービスを利用できる |
| メール | 対応プランなら利用できる | メールはWebの通信とは分けて設定を考える |
| 併用 | Cloudflareと組み合わせられる | レンタルサーバーと組み合わせられる |
このように、両者は単純な競合サービスではありません。レンタルサーバーを使いながらCloudflareを導入する構成もあれば、Cloudflareのサービスを使ってWebサイトを公開する構成もあります。
ここで、訪問者がホームページを開くときに、何が起きているのかを見てみましょう。例えば、ブラウザで https://kinfuu.co.jp/ を開いたとします。実際には、いくつかの段階を経てページが表示されます。
この構成では、訪問者からの通信が、原則として公開元のサーバーに直接届きます。もちろん、レンタルサーバー会社がファイアウォールやDDoS対策を提供している場合もあるので、Cloudflareを使わないから必ず無防備、というわけではありません。
WebサイトのDNSレコードを、Cloudflareのプロキシを経由する設定にすると、通信の流れが変わります。
このとき、Cloudflareは訪問者と公開元のサーバーの間に立つ役割を果たします。このような仕組みをリバースプロキシと呼びます。Cloudflareは通信を中継するだけでなく、設定に応じてキャッシュを使ったり、セキュリティ機能を適用したりできます。
Cloudflareを経由していても、毎回レンタルサーバーにアクセスするとは限りません。例えば、キャッシュできる画像やCSSなどのファイルは、Cloudflareに保存されたコピーを訪問者に返せる場合があり、そのときは公開元に問い合わせずに配信できます。
一方、ログイン情報を確認するページや、利用者ごとに違う情報を表示するページは、キャッシュの扱いに注意が必要です。すべてのページを同じようにキャッシュすればよいわけではありません。
Cloudflareの代表的なメリットを、具体的に見ていきましょう。
例えば、会社案内のページに大きな画像が10枚あるとします。訪問者がページを開くたびに、すべてのファイルを公開元から取得する構成では、サーバーやネットワークに負荷がかかります。
CloudflareのCDNやキャッシュを適切に使えば、対象のファイルをCloudflareのネットワークから配信でき、公開元へのアクセスを減らしたり、ファイルが届くまでの時間を短くしたりできる可能性があります。特に、画像やCSSのように内容があまり変わらないファイルは、キャッシュと相性がよいことが多いです。
ただし、Cloudflareを入れれば必ず速くなるわけではありません。ページを作る処理が重い場合や、画像が大きすぎる場合などは、Cloudflareだけでは解決しないことがあります。サーバー、プログラム、画像、キャッシュを総合的に見直すことが大切です。
レンタルサーバーには、CPUやメモリ、通信量などに一定の上限がある場合があります。例えば、キャンペーン情報がSNSで広まり、一時的にアクセスが急増したとします。そのページや関連ファイルが適切にキャッシュされていれば、すべてのアクセスを公開元で処理する必要がなくなります。
ただし、ログインやデータベースの検索など、毎回サーバー側で処理しなければならない部分は、キャッシュだけで負荷をなくせるわけではありません。
DDoS攻撃とは、たくさんの端末から大量の通信を送りつけ、Webサイトを使えなくする攻撃です。公開元のサーバーだけで受け止めようとすると、負荷が高まり、ふつうの訪問者までページを見られなくなるおそれがあります。Cloudflareは、大きなネットワークで大量の通信を受け止め、DDoS攻撃への対策を提供しています。
ただし、あらゆる攻撃を完全に防げるわけではありません。また、公開元のサーバーのIPアドレスが別の経路から知られていると、Cloudflareを通らずに直接アクセスされ、保護を迂回されるおそれがあります。必要に応じて、公開元への通信をCloudflare経由に限る対策も検討します。
WAF（Web Application Firewall）は、Webサイトへの通信の中身を調べ、攻撃に使われそうなリクエストを検知・遮断する仕組みです。例えば、お問い合わせフォームに不正な入力を送りつけたり、プログラムの弱点をねらった通信を送ったりする攻撃を、適切な設定で止められる場合があります。
ただし、WAFですべての弱点がなくなるわけではありません。プログラムそのものに問題がある場合は、修正や更新が必要です。また、正しい利用者の通信が誤って止められることもあるため、導入後の確認も大切です。
「https://」から始まるURLでは、SSL/TLSで通信を暗号化しています。ここで注意したいのは、訪問者からCloudflareまでと、Cloudflareから公開元のサーバーまでは、別の区間だということです。
Cloudflare側でhttpsが有効になっていても、公開元までの通信が暗号化されているとは限りません。安全性を重視する場合は、Cloudflareと公開元の間もhttpsで接続し、公開元の証明書に合わせて、CloudflareのSSL/TLSの設定（モード）を正しく選ぶことが大切です。
ここは、誤解されやすいポイントです。結論から言うと、Cloudflareを導入しただけで、レンタルサーバーが不要になるわけではありません。
Cloudflareを通信の中継やセキュリティ対策に使う構成では、Webサイトを公開する場所が別に必要です。例えば、レンタルサーバーにHTMLや画像を置き、その前にCloudflareを置く構成では、レンタルサーバーは公開元として引き続き必要になります。
一方、Cloudflareには、Webサイトを公開するCloudflare Pagesや、サーバー側の処理を動かすCloudflare Workersなどのサービスもあります。これらを使う場合は、レンタルサーバーを使わずにWebサイトを作れるケースもあります。どちらが合うかは、サイトの作りや必要な機能によって変わります。
会社概要、事業内容、サービス紹介、所在地・アクセス、お問い合わせ先の案内といったページが、HTMLファイルとして用意されていて、アクセスのたびにプログラムを動かす必要がなければ、静的なサイトとして公開できます。公開先には、レンタルサーバーを使う方法も、Cloudflare Pagesなどを使う方法もあります。
ただし、お問い合わせフォームを設ける場合は、送信内容を受け取る処理やメールの送信など、別の仕組みが必要になることがあります。静的HTMLだからといって、どんな機能でもサーバー側の仕組みが要らなくなるわけではありません。
WordPressは、一般的にPHPとデータベースを使って動くCMSです。そのため、レンタルサーバーでWordPressを運用している場合、Cloudflareを入れただけでWordPressを動かす環境が不要になるわけではありません。
Cloudflareは、WordPressのサイトの前で通信を中継し、キャッシュやセキュリティ機能を使う形で組み合わせます。管理画面、ログイン、投稿の更新、データベースへのアクセスなどには、WordPressを動かす環境が引き続き必要です。WordPress本体・テーマ・プラグインの更新、バックアップ、アカウントの管理も、Cloudflareに任せきりにはできません。
では、レンタルサーバーを使っている会社がCloudflareを導入する意味はあるのでしょうか。サイトの作りや運用の方針によっては、併用するメリットがあります。
レンタルサーバーは公開やプログラムの実行を、Cloudflareは通信の中継・キャッシュ・セキュリティ対策を担当する、と役割を分けて考えると、Webサイトの運用を整理しやすくなります。もちろん、Cloudflareを入れたからといって、公開元のサーバーの管理をやめてよいわけではありません。
静的なファイルなどを適切にキャッシュできれば、公開元へのアクセスを減らせる可能性があります。ただし、キャッシュの対象や期限を誤ると、更新した内容がすぐに表示されなかったり、利用者ごとに違うはずの情報が共有されてしまったりするおそれがあります。ログインや個人情報を扱うページは、特に慎重に設計しましょう。
Cloudflareの機能を、一度にすべて使う必要はありません。まずDNSをCloudflareで管理し、サイトの作りに合わせてプロキシやキャッシュを使い、その後必要に応じてWAFなどを検討する、という進め方ができます。
ただし、DNSをCloudflareで管理することと、Webの通信をCloudflare経由にすることは同じではありません。DNSレコードを登録しただけで、すべての通信がCloudflareを通るわけではなく、レコードごとの設定が重要になります。
会社では、ホームページだけでなく、独自ドメインのメールも使っていることが多いと思います。例えば、次のような構成です。
kinfuu.co.jp：ホームページのドメインwww.kinfuu.co.jp：ホームページ（www付き）mail.kinfuu.co.jp：メールサーバーのホスト名これらは同じドメインに関係していても、同じサーバーで動かす必要はありません。ホームページはレンタルサーバーで公開し、メールは別のメールサービスで運用することもできます。Cloudflareを入れる場合も、Webの通信とメールの通信を分けてDNSを設定します。メール用のホスト名をWebのプロキシ経由にすると、メールの送受信に支障が出ることがあるので、メール関連のレコードは、使っているメールサービスの案内に従って設定しましょう。
Cloudflareは便利なサービスですが、導入すればすべての問題が解決するわけではありません。特に気をつけたい点をまとめます。
ドメインのDNSは、ホームページだけでなくメールなどにも関係しています。DNSをCloudflareに移すときに、Webサイト用のレコードだけを設定し、メール用のMXレコードや関連するTXTレコードを忘れると、メールが届かなくなるおそれがあります。移す前に、次の設定を確認しましょう。
CloudflareのDNS設定では、レコードごとに、プロキシを使うかどうかを選べます。オレンジ色の雲はプロキシ有効（Webの通信がCloudflareを経由する）、灰色の雲はDNSのみ（接続先を案内するだけ）を表します。
例えば、ホームページの通信はCloudflare経由にしたい一方、メールは別のメールサーバーへ直接つなげたい、という場合があります。その場合は、上の図のように、レコードごとに役割を考えて設定します。
Cloudflareのプロキシを使うと、ふつうのアクセスに対しては、公開元のサーバーのIPアドレスを直接見せずに済む場合があります。しかし、別のレコードや過去の設定からIPアドレスが知られていれば、直接アクセスされる可能性があります。また、公開元に弱点があれば、Cloudflareだけで完全には解決できません。必要に応じて、次のような対策を検討します。
共有のレンタルサーバーでは、利用者が変えられるネットワークの設定に制限がある場合もあります。その場合は、サーバー会社が提供する機能の範囲で対策を考えます。
キャッシュは便利な仕組みですが、設定を誤ると、更新したページが古いまま表示されたり、本来は人ごとに違う情報が共有されたりするおそれがあります。ログイン後のマイページや、個人情報を表示する画面を、一般の公開ページと同じようにキャッシュするのは危険です。表示の速さだけでなく、情報の正確さやプライバシーも考えて設定しましょう。
Cloudflareには無料で使える機能がありますが、無料で使えることと、設定や運用が要らないことは別です。DNSの設定を誤れば、ホームページやメールに影響が出ることがあります。また、WAFなどの機能は、プランや設定によって使える範囲が違います。まず今の構成を把握し、変更による影響を確認してから進めることが大切です。
どちらが優れているかではなく、何を実現したいかによって選ぶことが大切です。ケースごとに考え方をまとめます。
| ケース | 考え方 |
|---|---|
| 会社案内が中心のホームページ | あまり更新しないページが中心なら、静的HTMLで公開する方法も選択肢。公開先はレンタルサーバーでも、Cloudflare Pagesでもよい。Cloudflareを中継やセキュリティ対策に使う構成も考えられる |
| WordPressでブログやお知らせを頻繁に更新する | レンタルサーバーでWordPressを動かし、必要に応じてCloudflareを組み合わせる。WordPress本体やプラグインの更新は引き続き必要 |
| セキュリティを強化したい | 大量の通信や不正なアクセスへの対策には、Cloudflareの機能が役立つ可能性がある。ただし、どの問題を解決したいのかを先にはっきりさせる |
| メールはそのままで、ホームページだけ見直したい | 今のDNS設定を確認し、メール関連のレコードを残したうえで、Webサイトに必要な設定を行う |
例えば、お問い合わせフォームへのスパム投稿が困っていることなら、フォーム自体の対策や入力のチェックに加えて、CloudflareのTurnstile（ロボットかどうかを確かめる仕組み）を使う方法があります。当社（金風株式会社）のサイトでも、お問い合わせやメルマガ登録のフォーム、管理画面のログインにTurnstileを使っています。一方、サーバーの弱点やCMSの管理のしかたに問題があるなら、それらは別に改善する必要があります。
導入を検討している場合は、次の項目を確認してみましょう。
これらを整理しておけば、必要以上に複雑な構成にしたり、目的があいまいなままサービスを導入したりすることを避けやすくなります。
DNSやCDN、基本的なDDoS対策など、無料のプランで使える機能があります。ただし、使える機能の範囲はプランによって違い、無料でも設定や確認の作業は必要です。
DNSを移すときに、メール用のMXレコードやSPFなどのTXTレコードを設定し忘れると、届かなくなることがあります。移す前に今のDNSレコードをすべて控え、移したあとにメールの送受信を確認しましょう。
サイトの作りによります。静的なHTMLのサイトなら、Cloudflare Pagesなどで公開できる場合があります。一方、WordPressのようにPHPとデータベースで動くサイトや、フォームの送信処理・メールをサーバーで行っている場合は、それらの置き場所を別に用意する必要があります。
Cloudflareとレンタルサーバーは、どちらもWebサイトに関係するサービスですが、基本的な役割は異なります。
大切なのは、自社のホームページに何が必要かを整理することです。どのページを公開するのか、どのくらい更新するのか、CMSやデータベースが必要か、メールをどこで運用するのか、どんなセキュリティ対策が必要か、そして誰が設定や更新、トラブルの対応を担当するのか。これらを確認したうえで構成を選ぶことが、無理のないWebサイトの運用につながります。
金風株式会社では、ホームページの構成の見直しや、Cloudflareの導入・DNSの移行、セキュリティ対策のご相談も承っています。「今の構成で何が足りないか分からない」という段階でも、お気軽にご相談ください。