つくれる外部CAIO
「サイトを作ったらCloudflareは入れておいたほうがいい」——Web制作の現場では、ほぼ定型文のように言われます。
無料で使えて、表示が速くなって、攻撃も防いでくれる。断る理由がないように聞こえます。
ただ、実際に複数のサイトとアプリを運用していると、入れる意味がある場所と、入れると逆に事故を起こす場所がはっきり分かれることが分かってきます。判断を分けているのは、社長のセキュリティ意識の高さではありません。サイトの構成そのものです。
この記事では、自社サイトにCloudflareを入れるべきかどうかを、構成別に判断できる基準を整理します。記載内容は2026年9月時点の各社公式資料を基準にしています。
結論：判断軸は1つだけ
先に答えを書きます。
そのサイトの実体（オリジン）が、自社で管理しているサーバーかどうか。
自社で借りたサーバーの上で動いているなら、入れる価値があります。SaaSやPaaS（レンタルカート、Vercelなど）の上で動いているなら、まずサービス事業者の公式構成を優先し、Cloudflareのプロキシは原則オフから検討します。
理由は、マネージドサービス側が配信網・TLS・DDoS対策・WAFなどをすでに提供している場合が多いからです。二重に重ねても単純に強くなるわけではなく、キャッシュやアクセス元の判定、障害時の切り分けが複雑になります。たとえばVercelは、Cloudflareなどのリバースプロキシを前段に置く構成を一般には推奨していません（Vercel公式ガイド）。
Cloudflareは3つの層に分かれている
判断を間違える原因のほとんどは、Cloudflareを「一つの機能」だと思っていることにあります。実際には別々に判断すべき層が3つあります。
1. DNS層（ネームサーバーの引っ越し）
ドメインの住所録をCloudflareで管理する機能です。DNSだけを使い、各レコードを「DNSのみ」にしている間は、Web通信はCloudflareのプロキシを経由しません。APIで管理でき、複数のサービスにまたがった構成を1画面で見られるようになります。
この層は、構成が複雑なサイトほど価値があります。
2. プロキシ層（オレンジ色の雲）
実際にHTTP/HTTPS通信がCloudflareを経由する設定です。キャッシュ、WAF、DDoS対策、サーバーIPを直接見せにくくする効果が働くのはここです。議論になるのは常にこの層です。
A・AAAA・CNAMEレコードごとにON/OFFできます。Cloudflareの公式資料でも、プロキシできるのは原則としてIPアドレス解決に使うA・AAAA・CNAMEであり、Web以外の用途にはDNSのみを使うよう案内されています（Cloudflare：Proxy status）。
3. DNSのまま扱う領域
メール関連（MX・SPF・DKIM・DMARC）です。MXやTXTレコード自体はプロキシ対象になりません。また、MXが参照するメール用ホスト名のA・AAAAレコードもDNSのみにする必要があります。
DNS層を使うかどうかと、プロキシ層を使うかどうかは、完全に別の判断です。ここを分けずに「Cloudflareを入れる／入れない」と考えると、話が必ずこんがらがります。
構成別：入れるべきか早見表
| サイトの実体 | プロキシ | 理由 |
|---|---|---|
| レンタルサーバー上のWordPress | 入れる価値あり | Web用のオリジンIPを直接見せにくくし、ログイン試行などを前段で制御できる |
| VPS・自社構築サーバー | 入れる価値あり | 守る対象と設定責任が自社側にある |
| VercelなどのPaaS | 原則不要 | 配信網・TLS・基本的な防御を内包。事業者の公式構成を優先する |
| ショップカート系SaaS | 原則不要 | 決済・セッション・サポート範囲に影響し得る。事業者の指示に従う |
| メール用ホスト | 不可 | MXの参照先を含め、メール用レコードはDNSのみにする |
自社サイトが1本だけで、それがレンタルサーバーのWordPressなら、答えは「入れる価値がある」です。中小企業のコーポレートサイトはこのパターンが最も多いはずです。
入れると壊れる側の話
ここからは、あまり語られない側です。
なお以下は、筆者が実際に事故を起こした記録ではなく、仕組み上そうなる構造の説明です。逆に言えば、経験しなくても設計段階で避けられる種類の失敗です。
1. メールが止まる
最も被害が大きいパターンです。
MXレコードが example.co.jp 自身を指していて、その名前のAレコードをオレンジ雲にした場合、メールの宛先がCloudflareのIPに解決されます。Cloudflareの通常のHTTPプロキシはSMTP通信を受けないため、DNSの反映後にメールを受信できなくなる可能性があります。
MXが mail.example.co.jp のような別ホスト名を向いていて、そちらがDNSのみになっていれば問題ありません。Google WorkspaceやMicrosoft 365を使っている場合も、MXの向き先が外部サービスなので通常は影響しません。Cloudflareも、MXの参照先ホスト名をDNSのみにするよう案内しています（Cloudflare：Troubleshooting email issues）。
危ないのは、Webもメールも同じレンタルサーバーで完結している構成です。中小企業ではかなり多いパターンなので、着手前に必ずMXの向き先を確認してください。
2. 引っ越し時にSPF・DKIMが消える
ネームサーバーをCloudflareに移すとき、既存レコードのクイックスキャンを利用できます。ただし、このスキャンは完全ではなく、独自名のDKIMなどを取りこぼすことがあります。Cloudflare自身も、ネームサーバー変更前に全レコードを確認し、不足分を手動で追加するよう案内しています（Cloudflare：Records quick scan）。
Webは問題なく表示されるので気づきません。数日後に「送ったメールが相手の迷惑メールに入る」という形で表面化します。
移行前に、現在のDNSレコードをすべて手元に書き出しておく。これだけで防げます。
3. PaaSの前に置くと配信が二重になる
VercelなどのPaaSは、それ自体が世界中に配信網を持っています。その前段にCloudflareのプロキシを置くと、キャッシュやセキュリティ判定の層が重なります。
結果として、
- デプロイしたのに古い内容が表示され続ける
- どちらのキャッシュを消せば直るのか分からなくなる
- アクセス元IPやセキュリティ判定に必要な信号が、事業者側で正確に扱いにくくなる
といった状態になり得ます。速くするために入れたものが、原因の切り分けを難しくします。例外的にリバースプロキシが必要な場合はありますが、対応プランや必須ヘッダー、キャッシュ除外など、PaaS側の公式手順に従うことが前提です。
4. SSLの設定を間違えると通信が保護されない
Cloudflareには、サーバーとの間の通信をどう扱うかの設定があります。Flexibleを選ぶと、訪問者とCloudflareの間は暗号化されても、Cloudflareとオリジンサーバーの間はHTTPになります。
ブラウザには鍵マークが表示されるため、見た目だけでは判別しにくい状態です。導入するなら、サーバー側に有効な証明書を入れた上で、原則としてFull (strict)を選びます（Cloudflare：Full (strict)）。
それでも「入れる価値がある」と言える理由
ネガティブな話を並べましたが、レンタルサーバー上のWordPressに関しては、入れる価値は明確にあります。
理由は3つです。
Web用オリジンのIPアドレスを、公開DNSから直接見えにくくできる。 ドメインを調べただけではWebサーバーのIPが分かりにくくなり、直接攻撃の入口を減らせます。ただし、過去のDNS履歴やメール用レコードなど別経路からIPが露出している場合は、この効果だけに頼れません。
ログイン画面への総当たりを、サーバーに届く前に止められる。 WordPressのログイン画面は、公開した瞬間から自動化された試行を受け続けます。サーバー側のセキュリティ機能でも防げますが、CloudflareのWAFやレート制御を適切に使えば、オリジンの処理負荷を減らせます。
キャッシュを自分でコントロールできる。 記事中心のサイトほど効果が出ます。ただし、管理画面・ログイン・フォーム・ECカートなど、キャッシュしてはいけない経路は除外が必要です。
なお、Xserverビジネスのような法人向けレンタルサーバーには、独自のWAFと高速化機能がすでに入っています。この場合、Cloudflareの上乗せ分は素のサーバーほど大きくありません。「入れる価値はあるが、最優先ではない」という評価が妥当です。
DNS層だけ使うという選択
プロキシを使わなくても、DNS管理だけCloudflareに寄せるという使い方があります。
これは、こういう状態の会社に効きます。
- コーポレートサイトはレンタルサーバー
- ECは別のSaaS
- 業務アプリはまた別のサービス
- メールはGoogle Workspace
- ドメインの管理画面はレジストラ
つまり、どこで何が動いているのか、社内の誰も全体像を把握していない状態です。DNSを1箇所に集約すると、少なくとも「この会社のドメインで何が動いているか」が1画面で見えるようになります。
全レコードをグレー（DNSのみ）のままにすれば、Web通信の配信経路は今と同じです。ただし、権威DNSの移行自体にはレコード漏れやDNSSEC不整合のリスクがあります。「DNSのみだから無条件に安全」ではなく、移行手順を分離しやすい選択だと考えてください。
導入前チェックリスト
実際に手を動かす前に、これだけは確認してください。
- MXレコードの向き先を確認する（自ドメイン自身を指していないか）
- 現在のDNSレコードを全件書き出す（特にTXT・メール関連のA/CNAME）
- レジストラ側でDNSSECが有効なら、DSレコードのTTLを確認して先に無効化する。高度なマルチサイナー移行を行わない限り、旧DSが残ったままネームサーバーを変えると名前解決に失敗し得る（Cloudflare：DNSSEC）
- サーバーに有効なSSL証明書が入っているか確認する
- 最初は全レコードをDNSのみで移し、DNS移行とプロキシ有効化を別工程にする
- プロキシをONにするWeb用レコードだけを事前に決める（全部ONにしない）
- 切り替え後、Webだけでなくメールの送受信、フォーム、ログイン、アクセス解析も確認する
まとめ：判断は2段階で
- プロキシを使うか → そのサイトの実体が自社管理のサーバーか、サービス事業者が前段プロキシを正式にサポートするかで決める。レコード単位の判断
- DNSを移すか → 構成が複雑なほど価値がある。ドメイン単位の判断
「Cloudflareを入れるべきか」という問いは、実際には「自社のどこに、自分で守るべきサーバーが残っているか」という問いです。
そして多くの中小企業では、その答えは「コーポレートサイトのWordPressだけ」になります。だとすれば、やるべき作業はごく限られています。