Cloudflareの「Full Setup」と「CNAME Setup」の違い｜DNS移管・部分導入の選び方
Cloudflareを導入するときに最初にぶつかるのが「ドメインをどう紐づけるか」という設定方式の選択です。一般的に紹介される手順はネームサーバー（NS）を丸ごとCloudflareに向ける「Full Setup」ですが、実は既存のDNSプロバイダーを残したまま特定のホスト名だけCloudflareに通す「CNAME Setup（パーシャル・セットアップ）」も用意されています。
両者は同じCloudflareのCDN・WAF・Zero Trust製品を使うための仕組みですが、適用範囲・利用条件・運用負荷が大きく異なります。間違えるとメールが届かなくなる、想定したセキュリティ機能が動かない、追加コストが想定外にかかる、といった事故につながりやすい領域です。
本記事では、CloudflareのFull SetupとCNAME Setupの違い、それぞれの長所と短所、企業規模・既存環境別の選び方を整理します。
前提：CloudflareはなぜDNSと密結合なのか
Cloudflareの中核は「ドメインへのアクセスを一度Cloudflareのエッジに受け取り、そこからオリジン（自社サーバー）に転送する」というリバースプロキシ型のアーキテクチャです。CDN、WAF、Bot対策、DDoS防御、Cloudflare Access（ZTNA）といった機能は、すべてこの「Cloudflareがトラフィックの間に入る」状態が前提になります。
トラフィックをCloudflareに通すために必要なのが、DNSレコードの書き換えです。www.example.com の問い合わせに対して、本来のオリジンサーバーのIPアドレスではなくCloudflareのエッジサーバーのIPアドレスを返すように、DNSを変更する必要があります。
この書き換えをどこで・どのレコード範囲で行うかが、Full SetupとCNAME Setupを分ける本質的な違いです。
Full Setup（フルセットアップ）とは
Full Setupは、ドメインのネームサーバーを丸ごとCloudflareに移管する方式です。レジストラ（お名前.com、Google Domains、AWS Route 53、Value Domain等）のドメイン管理画面で、ネームサーバーを xxx.ns.cloudflare.com と yyy.ns.cloudflare.com の2つに変更します。
仕組み
- ドメインの権威DNSがCloudflareに切り替わる
- 既存のDNSレコード（A、AAAA、MX、TXT、CNAME等）はすべてCloudflareにインポートされる
- 以降のDNS変更はCloudflareの管理画面で行う
- Cloudflareを通したいレコードは「プロキシON（オレンジ雲）」、通したくないレコードは「プロキシOFF（グレー雲）」で個別に制御する
メリット
全レコード分の自由度がある：A、AAAA、CNAMEはもちろん、サブドメインを後から追加する場合も、Cloudflareの管理画面で完結します。SPF/DKIM/DMARCといったメール認証レコードも同じ画面で管理できます。
プランの制限がない：Cloudflareの無料プランから利用でき、Business以上の有償プランは必須ではありません。中小企業や個人事業主でも使えます。
DNSSECやDNS解決の高速化が得られる：CloudflareのDNSは世界中のエッジから応答するため、外部からの名前解決が高速です。DNSSECも管理画面の操作のみで有効化できます。
APEXドメインを直接プロキシできる：example.com（サブドメインを付けない、いわゆるルートドメイン）に対してもCloudflareの保護を適用できます。
デメリット・注意点
ネームサーバー移管にダウンタイムリスクがある：既存DNSプロバイダーで設定していたレコードをCloudflareに完全にコピーしないと、メールやサブドメインで提供している社内システムが止まります。MX、SPF、DKIM、DMARC、A/CNAME、TXT、SRVといったレコードを事前に棚卸しする必要があります。
他システムのDNS設定が散在している場合に影響が広い：Microsoft 365のドメイン認証用TXT、Google Workspaceのドメイン所有権確認、HubSpot/Salesforce等のSaaSが要求するCNAME、PR配信会社が指定するTXTなど、現代のDNSは1ドメインあたり数十レコードに膨れがちです。Full Setupではこれらを全部Cloudflare側で再現する責任を負います。
既存の社内DNS運用フローを変える必要がある：DNS変更の権限がインフラ部門ではなく別部署にある、変更承認のワークフローツールが既存DNSに紐づいている、といったケースでは、Cloudflareへの移管によって運用ルールの再設計が必要になります。
CNAME Setup（パーシャル・セットアップ）とは
CNAME Setupは、既存のDNSプロバイダーをそのまま残し、Cloudflareに通したい特定のホスト名（例：www.example.com、app.example.com）だけをCNAMEレコードでCloudflareの専用FQDNに向ける方式です。Cloudflareの公式名称は「Partial（CNAME）Setup」です。
仕組み
- ドメインのネームサーバーは既存DNSプロバイダーのまま
- Cloudflareは、特定のホスト名だけを「ゾーン」として登録する
- 既存DNS側で、対象ホスト名をCloudflareが指定する
xxxxx.cdn.cloudflare.netのようなFQDNにCNAMEで向ける - ホスト名単位でCloudflareの保護を適用できる
メリット
既存DNS環境を維持できる：AWS Route 53、Akamai Edge DNS、社内DNS、レジストラ提供DNS、エンタープライズDNS製品（BlueCat、Infoblox等）といった既存環境を変えずにCloudflareの恩恵を受けられます。
範囲を絞った段階的導入ができる：まずは公開Webサイト1つだけ、次にAPIエンドポイント、次にZTNA用サブドメイン、というように、ホスト名単位でリスクを切って導入できます。全社的なDNS移管の合意形成が難しい大企業で特に有効です。
他のDNSベースのサービスと衝突しない：オンプレ系のDNSフェイルオーバー、地理的なDNSラウンドロビン、社内向けスプリットDNSなど、既存のDNS固有の仕組みを温存できます。
デメリット・注意点
Business以上の有償プランが必須：Partial SetupはCloudflareのBusinessプラン（月額200ドル〜／ドメイン）またはEnterpriseプランでのみ利用できます。無料プランやProプランでは選べません。中小企業がコスト最優先で導入する場合、ここがネックになります。
APEXドメインをプロキシできない：CNAMEレコードはRFC上、ZONE APEX（ルートドメイン）には設定できません。example.com 自体をCloudflareに通すには、Aレコードのままでは不可で、Cloudflareが提供するCNAME Flatteningを利用するためにFull Setupに切り替えるか、Enterpriseプランの専用機能を使う必要があります。
設定ホスト名の追加・変更ごとに二重管理が発生する：新しいサブドメインをCloudflareに通したいときは、まずCloudflare側でゾーン追加、その後既存DNS側でCNAMEを向ける、という2ステップが必要です。Full Setupに比べて手数が増えます。
プロキシOFFのレコードを混在管理しにくい：Full Setupなら「ホスト単位でプロキシON/OFFを切り替えるだけ」で済む構成変更が、Partial Setupでは既存DNSとCloudflareの両方を触る必要があります。
機能・運用面の比較
| 比較項目 | Full Setup | CNAME Setup（Partial） |
|---|---|---|
| ネームサーバー | Cloudflareに移管 | 既存DNSのまま |
| 対象範囲 | ドメイン全体 | 個別ホスト名 |
| 最低プラン | Free〜 | Business以上 |
| APEXドメインのプロキシ | 可能 | 原則不可（Enterprise例外あり） |
| 既存DNS環境への影響 | 大（移管が必要） | 小（既存維持） |
| CDN・WAF・Bot対策 | 利用可 | 利用可（対象ホストのみ） |
| Cloudflare Access（ZTNA） | 利用可 | 利用可 |
| DNSSEC | Cloudflare側で有効化 | 既存DNS側の対応に依存 |
| メール（MX/SPF/DKIM） | Cloudflareで管理 | 既存DNSで管理（影響なし） |
| 段階的導入のしやすさ | 一括移管 | ホスト単位で段階導入可 |
| 月額コスト（最小構成） | 0円〜 | 約200ドル/ドメイン〜 |
どちらを選ぶべきか：判断軸
Full Setupを選ぶケース
- ドメインを丸ごとCloudflareで保護・高速化したい
- 既存DNS環境にこだわりがない（レジストラ付属DNS等）
- 中小企業で月額コストを抑えたい
- 公開Webサイトとメールが主なユースケース
- SaaSが要求するTXT/CNAMEを一括管理したい
中小企業の大半はFull Setupで問題ありません。既存DNSがレジストラ標準DNSである場合、移管のリスクも小さく、無料プランで始められるためコストパフォーマンスも高い構成です。
CNAME Setupを選ぶケース
- 既存のエンタープライズDNS（Akamai、Route 53の高度設定、社内DNS）を維持したい
- 大規模組織でドメインの所有権がIT部門以外にもまたがる
- 公開サイト・APIなど特定のホスト名だけをCloudflareに通したい
- DNSの全面移管に対する社内承認が現実的に難しい
- 既にBusinessまたはEnterpriseプランの契約予定がある
中堅・大企業や、複数の事業部・グループ会社で同じドメインを使い分けているケースでは、Partial Setupの「ホスト名単位での導入」が現実解になることが多いです。
移管手順の概要
Full Setupの場合
- Cloudflareアカウントを作成し、ドメインを追加する
- 自動でインポートされたDNSレコードを必ず棚卸しする（M365、Workspace、SaaS関連を見落とさない）
- プロキシON/OFFを設定する（A/AAAA/CNAMEのみ対象）
- MX、SPF、DKIM、DMARCなどメール系レコードは必ずプロキシOFF（DNSのみ）にする
- レジストラでネームサーバーを変更する
- TTL分の伝搬を待つ（通常数時間〜24時間）
- 全レコードが正しく解決されるか確認する
メールの停止リスクが最も高いので、MX/SPF/DKIM/DMARCの棚卸しは念入りに行ってください。
CNAME Setup（Partial）の場合
- CloudflareでBusiness以上のプランを契約する
- ドメインをPartialモードで追加し、所有権確認用のTXTレコードを既存DNSに登録する
- Cloudflare側で対象ホスト名（例：
www.example.com）のゾーンを作成する - 既存DNS側で対象ホスト名のCNAMEをCloudflareが指定する宛先に向ける
- 名前解決を確認後、Cloudflare側でプロキシをONにする
- 対象ホスト名のみCloudflareの保護が有効になる
よくある事故と回避策
メールが届かなくなる：Full Setup時にMXレコードのインポートを忘れる、またはMXにプロキシをONにしてしまうケース。MXは必ずプロキシOFFのままにしてください。
Microsoft 365のドメイン認証が外れる：M365が要求するTXT（MS=ms…）やCNAME（autodiscover、enterpriseregistration、enterpriseenrollment）を移管時に取り込み忘れるケース。M365管理センターの「ドメイン」→「DNSレコード」画面で必要レコードを一覧できます。
APEXドメインがCloudflareを経由しない：Partial SetupでルートドメインのAレコードを既存DNSに残したまま運用するケース。APEXもCloudflareに通したい場合はFull Setupへの切り替えを検討してください。
料金プランを誤認する：Partial SetupをFreeプランで試そうとして失敗するケース。必ず事前にBusinessプラン以上の契約が必要です。
まとめ
CloudflareのFull SetupとCNAME Setup（Partial）は、それぞれ異なる前提のもとで設計されています。
- 中小企業・既存DNS自由：Full Setupで十分。コストも運用負荷も最小。
- 大企業・既存DNS固定・段階導入が必要：CNAME Setup（Partial）。Business以上の有償契約が前提。
どちらを選んでも、Cloudflareが提供するCDN、WAF、Bot対策、ZTNA（Cloudflare Access）といったコア機能は使えます。違いはあくまで「DNSの所在」と「対象範囲」です。
導入前に既存DNSレコードの棚卸しを行い、メール認証系（MX/SPF/DKIM/DMARC）とSaaS連携用レコードを漏らさないこと。これが事故を防ぐ唯一かつ最大のポイントです。
情シス365では、Cloudflareを含むDNS／CDN／ゼロトラスト製品の導入設計と運用代行をご支援しています。「無料プランから始めるべきか、Business以上を契約すべきか」「既存DNSの移管リスクをどう評価するか」といった判断にお悩みの企業様は、お気軽にご相談ください。