Cloudflareとは？DNS・CDN・WAF・Workers・Zero Trustまで徹底解説

Cloudflare（クラウドフレア）は、Webサイトの表示高速化やDDoS対策で知られています。しかし、現在のCloudflareはCDNだけのサービスではありません。DNS、WAF、ボット対策、サーバーレス実行環境、オブジェクトストレージ、SQLデータベース、Zero Trustまでを同じグローバルネットワーク上で提供しています。

機能が多いため、「レンタルサーバーと何が違うのか」「DNSを移すだけでよいのか」「WorkersやR2はいつ使うのか」が分かりにくくなりがちです。大切なのは、Cloudflareを一つの製品として見るのではなく、通信の入口、配信と防御、アプリケーション実行、データ保存、社内アクセス制御という層に分けて理解することです。

結論として、Cloudflareは利用者とWebサイト・アプリケーションの間に入り、通信を速く安全に処理すると同時に、そのネットワーク上でコードやデータを動かせるクラウドプラットフォームです。既存サイトにはDNS・CDN・WAFから段階導入でき、新規開発ではWorkers、Pages、R2、D1などを組み合わせてアプリケーション基盤として利用できます。

Cloudflareとは何か

Cloudflareの基本構造は、権威DNSとリバースプロキシです。一般的なWebサイトでは、利用者のブラウザがDNSで接続先を調べ、オリジンサーバーへ直接アクセスします。Cloudflareで対象のDNSレコードを「プロキシ済み」にすると、DNS応答にはCloudflareのAnycast IPアドレスが返り、HTTP/HTTPS通信がCloudflareのネットワークを経由してオリジンサーバーへ届きます。

Cloudflareの公式ドキュメントでは、Cloudflareが権威DNSプロバイダーとリバースプロキシとして動き、キャッシュ、攻撃防御、SSL/TLS処理、負荷分散などを担う仕組みが説明されています。利用者に近い拠点で処理できる通信はそこで処理し、必要なリクエストだけをオリジンサーバーへ送るため、表示速度と安全性、オリジン負荷の改善を同時に狙えます。

ただし、Cloudflareを導入しただけで、レンタルサーバーやクラウドサーバーが自動的に不要になるわけではありません。DNS・CDN・WAFだけを使う場合、HTMLや画像、データベースを持つオリジンサーバーは引き続き必要です。一方、PagesやWorkersでサイトとAPIを動かし、R2やD1にデータを置く構成では、Cloudflare側がホスティングとアプリケーション基盤の役割まで担います。Webサイトの構築方式全体を比較したい場合は、ウェブサイト構築の選択肢も合わせて確認すると整理しやすくなります。

層	Cloudflareの役割	代表的な機能	利用者が得る効果
通信の入口	ドメイン名を接続先へ解決し、対象通信をCloudflareへ誘導する	Authoritative DNS、DNSSEC、Proxy status	高速で安定した名前解決と一元管理
配信と防御	リクエストを受け、キャッシュ、暗号化、検査、攻撃緩和を行う	CDN、Cache Rules、WAF、DDoS Protection、Turnstile	表示速度、可用性、セキュリティの改善
アプリケーション	エッジ側でコード、API、静的ファイル、バックグラウンド処理を動かす	Workers、Pages、Workflows、Queues	サーバー管理を減らし、世界へ展開しやすくする
データ	オブジェクト、SQL、Key-Value、状態を用途別に保存する	R2、D1、KV、Durable Objects	アプリと近い場所でデータ基盤を構成する
組織アクセス	社内システムやSaaSへの接続をIDと端末状態で制御する	Cloudflare Access、Tunnel、Secure Web Gateway	VPN依存を減らし、最小権限でアクセスさせる

Cloudflareの主要機能と使い分け

Cloudflareは機能名を覚えるより、「何を速くするのか」「何を守るのか」「どこでコードを動かすのか」「どの形式のデータを置くのか」で分けると選びやすくなります。すべてを最初から導入する必要はありません。既存サイトならDNS・CDN・SSL/TLS・WAFから始め、必要に応じて開発者プラットフォームやZero Trustへ広げます。

DNS：ドメインと通信経路の入口

Cloudflare DNSは、ドメイン名に対する問い合わせへ応答する権威DNSです。一般的なフルセットアップでは、ドメインのネームサーバーをCloudflareへ変更し、Cloudflareの管理画面やAPIでDNSレコードを管理します。

A、AAAA、CNAMEなどの対象レコードをプロキシ済みにすると、そのホスト名へのHTTP/HTTPS通信はCloudflareを経由します。DNSのみのレコードは、Cloudflareが名前解決を行っても通信自体はCloudflareを通りません。メール用レコードや検証用レコードなど、プロキシ対象にできない・すべきでないレコードもあるため、雲のアイコンを一括で切り替えず、用途ごとに確認します。

CDNとキャッシュ：表示速度とオリジン負荷を改善する

CDNは、画像、CSS、JavaScript、Webページなどのコピーを利用者に近い拠点から返し、オリジンサーバーまで取りに行く回数を減らします。Cloudflare Cacheは全プランで利用でき、標準のキャッシュ動作に加えてCache Rulesで対象URL、保存時間、除外条件を調整できます。

注意したいのは、CDNを有効にすればすべてのページが自動的に最適化されるわけではない点です。ログイン後の画面、カート、問い合わせ完了ページ、個人別レスポンス、更新頻度が高いAPIを誤ってキャッシュすると、古い情報や別利用者向けの内容を返す危険があります。キャッシュ対象と除外対象を先に決め、更新時のPurge手順まで用意します。

WAF・DDoS対策・Turnstile：攻撃と不要な自動アクセスを減らす

WAFは、WebサイトやAPIへのリクエストを検査し、ルールに基づいて許可、ブロック、チャレンジなどを行います。Cloudflare WAFには、Cloudflareが更新するManaged Rules、自社で条件を書くCustom Rules、一定時間内のアクセス回数を制御するRate limiting rulesがあります。公開直後から強いルールを全体へ適用するのではなく、Security Eventsで影響を確認しながら段階的に調整します。

DDoS Protectionは、大量の通信でサービスを停止させる攻撃を自動検知・緩和する機能です。公式ドキュメントでは、レイヤー3/4とレイヤー7を対象とする標準DDoS対策が全プランで提供されると説明されています。ただし、オリジンサーバーのIPアドレスが別のDNSレコードや過去の記録から露出し、攻撃者がCloudflareを経由せず直接接続できる状態では、リバースプロキシの防御を迂回されます。オリジン側のファイアウォールや認証も組み合わせる必要があります。

Turnstileは、画像選択式CAPTCHAに代わる人間確認機能です。CloudflareのCDNを使っていないサイトにも埋め込めるため、問い合わせフォーム、会員登録、ログイン、キャンペーン応募などの自動送信対策に利用できます。導入時は画面へウィジェットを置くだけでなく、サーバー側でトークンを検証し、失敗時の挙動とアクセシビリティも確認します。

WorkersとPages：WebサイトやAPIを動かす

Cloudflare Workersは、Cloudflareのグローバルネットワーク上でサーバーレスアプリケーションを実行するプラットフォームです。JavaScriptやTypeScriptを中心に、対応する言語やWebAssemblyを使い、API、認証、リダイレクト、パーソナライズ、定期処理、AIアプリなどを構築できます。インフラを一台ずつ管理せず、リクエストに近い場所で処理を実行できる点が特徴です。

Cloudflare Pagesは、Git連携、直接アップロード、CLIからフロントエンドをデプロイするサービスです。Pages Functionsを使えばサーバー側の処理も追加できます。Workersも静的ファイルやフルスタックアプリを扱えるため、新規構築ではフレームワーク対応、既存のデプロイ方法、必要なバインディング、ローカル開発と監視のしやすさで選びます。AIエージェントを使って内製する場合も、公開先だけでなくローカル開発、レビュー、監視、復旧まで含めて構成を決めます。

R2・D1・KV・Durable Objects：データの性質で保存先を選ぶ

R2は、画像、動画、バックアップ、生成物、データセットなどの非構造化データを保存するオブジェクトストレージです。S3互換APIを利用でき、一般的なクラウドストレージで課題になりやすいインターネットへのデータ転送料を抑えやすい設計です。ただし、保存容量や操作回数などの料金は発生するため、「転送が無料だから全体も無料」とは考えず、アクセスパターンで見積もります。

D1はSQLiteのSQLセマンティクスを持つマネージド・サーバーレスデータベースです。小規模な業務アプリ、顧客向けポータル、コンテンツデータ、マルチテナント構成などで、WorkersやHTTP APIから利用できます。KVは設定値や読み取り中心のデータ、Durable Objectsはチャットルームや共同編集のようにエンティティ単位の一貫した状態管理へ向きます。製品名から選ばず、整合性、読み書き頻度、検索方法、データ量、復旧要件で決めます。

Cloudflare One：社内アクセスをZero Trust化する

Cloudflare Oneは、ネットワーク接続とZero Trustセキュリティを統合するSASEプラットフォームです。Cloudflare Accessで社内WebアプリへのアクセスをIDと条件で制御し、Cloudflare Tunnelでオリジン側から外向き接続を作れば、サーバーの公開IPや受信ポートを直接さらさずに接続できます。Secure Web Gateway、DLP、CASB、Browser Isolationなどを組み合わせ、利用者・端末・接続先を一つの管理面で統制します。

Webサイト向けのCDN/WAFと、従業員向けのZero Trustは目的が異なります。前者は公開サービスを訪れる不特定多数の通信を処理し、後者は誰がどの社内資源へ接続できるかを管理します。同じCloudflareネットワークを使いますが、導入責任者、ポリシー、ログの扱い、障害時の代替手段を分けて設計します。

Workers AI・AI Gateway・Vectorize：AIアプリを運用する

Workers AIは、Cloudflareのネットワーク上にあるサーバーレスGPUでAIモデルを実行するサービスです。AI Gatewayは外部を含むAIモデル呼び出しの観測、キャッシュ、レート制御、再試行、フォールバックを支援し、Vectorizeはセマンティック検索やRAGで使うベクトルデータを保存します。Workers、R2、D1と組み合わせると、アップロード、推論、検索、結果保存までを同じ開発基盤で構成できます。

一方、公開サイトではAIアプリを作ることだけでなく、AIクローラーをどこまで許可するかも運用課題です。検索利用、ユーザーの依頼で動くエージェント、モデル学習を同じボットとして一括処理すると、検索流入と権利保護の判断が混ざります。AIトラフィックの分類とrobots.txtの考え方は、OAI-SearchBotとAIクローラーの設定も参考にしてください。

Cloudflareを導入するメリットと注意点

メリット1：既存サイトを移転せずに改善を始められる

既存のレンタルサーバー、WordPress、VPS、クラウド環境を維持したまま、DNSとプロキシ設定から導入できます。サイトを全面的に作り直さず、CDN、SSL/TLS、DDoS対策、WAF、アクセス分析を段階的に追加できるため、移行リスクを抑えやすい方法です。

メリット2：性能とセキュリティを同じ通信経路で管理できる

表示高速化とセキュリティを別々の製品で導入すると、障害時にどこで通信が止まったのか追いにくくなります。Cloudflareでは、DNS、TLS、キャッシュ、WAF、DDoS対策、ボット対策、エッジ処理が同じリクエスト経路にあるため、ルールとイベントを関連付けて確認できます。複数ドメインを運用する企業では、設定の標準化にもつなげられます。

メリット3：サイト改善からアプリ開発へ拡張できる

最初はCDNとWAFだけを使い、後からWorkersでAPIやフォーム処理を追加し、R2へファイルを保存し、D1でデータを管理するといった拡張ができます。小さな機能を追加するたびに新しいサーバーを契約する必要がなく、検証から本番まで同じ基盤を使いやすくなります。

注意点1：設定ミスの影響範囲が大きい

DNS、SSL/TLS、キャッシュ、WAFは通信の入口にあるため、設定を誤るとサイト全体が表示できなくなります。DNSレコードの不足、証明書の不一致、HTTPからHTTPSへのリダイレクトループ、必要なCookieを無視したキャッシュ、WAFによる管理画面やAPIのブロックが代表例です。変更前の設定記録、段階反映、確認URL、ロールバック手順を必ず用意します。

注意点2：オリジンサーバーの保護は別途必要

Cloudflareを経由する通信が守られていても、オリジンIPへ直接接続できれば防御を迂回されます。過去のDNS履歴、メール送信元、別サブドメイン、エラーメッセージなどからIPアドレスが推測される場合もあります。オリジン側ではCloudflareからの通信だけを許可する、Authenticated Origin Pullsを検討する、管理画面をAccessやVPNで制限するなど、直接接続への対策を行います。

注意点3：キャッシュとセキュリティの誤判定を監視する

キャッシュヒット率だけを高めると、更新反映の遅れや個別コンテンツの誤配信につながります。ブロック数だけを増やすと、検索クローラー、決済通知、外部連携、社内利用者まで止める可能性があります。性能指標とセキュリティイベントを別々に見るのではなく、変更内容、対象URL、利用者影響、オリジン負荷を同じ運用記録で確認します。

Cloudflareの料金をどう考えるか

Cloudflareの料金は、Webサイト向けゾーンプランと、Workers、R2、D1、Workers AIなどの使用量課金を分けて考える必要があります。無料プランでもDNS、キャッシュ、標準DDoS対策、一部のWAF機能などを試せますが、高度なマネージドルール、ログ、分析、SLA、組織全体の設定管理、サポートなどは上位プランや追加契約が必要になります。

判断対象	小規模・検証	事業サイト・業務利用	大規模・規制対応
Webサイト向け機能	DNS、CDN、基本的な防御を小さく試す	WAF、キャッシュ、分析、サポート要件で選ぶ	SLA、詳細ログ、複数アカウント統制、個別要件を確認する
Workers	無料枠でAPIや小機能を検証する	リクエスト数、CPU時間、外部通信、ログ量を見積もる	可用性、デプロイ統制、観測性、サポートを含める
R2・D1	小規模データで読み書きの特性を確認する	保存量、操作回数、クエリ、バックアップを見積もる	データ所在地、復旧、監査、移行性を確認する
Zero Trust	少人数のAccessやTunnelから始める	利用者数、端末、ポリシー、ログ保管で設計する	DLP、CASB、ネットワーク統合、運用責任を含める

見積もりでは月額料金だけでなく、オリジンサーバーの転送量や負荷が減る効果、WAFやDDoS対策を別製品で用意する場合の費用、運用担当者の作業時間も比較します。反対に、設定がCloudflare固有機能へ深く依存すると、将来の移行コストが上がります。DNSレコード、ルール、Workersコード、データのエクスポート方法を管理し、特定機能を外した場合の代替手段を把握しておくことが重要です。

Cloudflareを安全に導入する手順

1. 対象ドメインと責任者を決める
   本番ドメインをいきなり切り替える前に、DNS管理者、Web担当者、サーバー担当者、セキュリティ担当者の役割を決めます。影響の小さいサブドメインや検証環境から始めると、ルールの影響を確認しやすくなります。
2. 現在のDNSレコードを棚卸しする
   A、AAAA、CNAMEだけでなく、MX、TXT、DKIM、DMARC、検証レコード、外部SaaSのレコードまで比較します。Cloudflareへ自動取り込みされた内容を信用し切らず、現行DNSと照合します。ドメイン更新と権限管理も含めた点検方法は、企業ドメインの更新期限を見逃さない管理方法で整理しています。
3. ネームサーバーを変更し、プロキシ対象を限定する
   レジストラでCloudflare指定のネームサーバーへ変更します。最初からすべてをプロキシ済みにせず、Web公開用のホスト名から切り替えます。メール、FTP、独自プロトコル、外部サービスの検証用レコードは要件を確認します。
4. SSL/TLSをFull (strict)へ寄せる
   オリジンサーバーに有効期限内でホスト名と一致する証明書を設定し、可能な限りFull (strict)を使います。Cloudflare公式も最良のセキュリティのために可能な限りFull (strict)を選ぶよう案内しています。切り替え前に443番ポート、証明書チェーン、HTTP/HTTPSリダイレクトを確認します。
5. キャッシュ対象と除外対象を定義する
   画像や静的ファイルから始め、ログイン、カート、フォーム確認・完了、管理画面、個別APIは除外を検討します。更新時のPurge方法、キャッシュキー、ブラウザキャッシュとCloudflareキャッシュの違いも記録します。
6. WAFとレート制御を観測しながら有効化する
   管理画面、API、フォーム、検索、Webhookなど重要経路ごとに正常通信を用意し、ルール適用後に再テストします。誤検知時に全防御を無効化せず、対象ルール、パス、送信元、例外条件を限定して調整します。
7. オリジンへの直接接続を制限する
   Cloudflare経由以外のHTTP/HTTPS通信をオリジン側で制限し、管理用経路を分離します。Cloudflare停止時に一時的にDNSのみへ戻すのか、別の配信経路へ切り替えるのかも決めます。
8. 監視と復旧テストを行う
   トップページだけでなく、問い合わせ、ログイン、API、画像、ファイルダウンロード、外部連携を監視します。DNS変更、ルール変更、証明書更新、Workersデプロイを誰が承認し、どのログを残し、どう戻すかを運用手順にします。

公開前の確認では、HTTPステータス、TLS証明書、主要ページ、フォーム送信、キャッシュヘッダー、WAFイベント、オリジン負荷を一つずつ点検します。「サイトが開く」だけでは、メールが届かない、Webhookが止まる、管理画面がブロックされる、古いページが残るといった問題を見逃します。

よくある質問

Cloudflareとは何ですか？

Cloudflareは、権威DNSとリバースプロキシを基盤に、CDN、WAF、DDoS対策、サーバーレス実行環境、ストレージ、Zero Trustなどを提供するクラウドプラットフォームです。既存サイトの前段に置いて高速化・防御する使い方と、WorkersやPagesでアプリケーション自体を動かす使い方があります。

Cloudflareは無料で使えますか？

無料で利用できるWebサイト向けプランや開発者向けの無料枠があります。ただし、利用できるWAFルール、ログ、分析、サポート、Workersの実行量、R2やD1の保存・操作量などにはプランや使用量に応じた条件があります。導入時は公式料金ページで最新の対象機能と上限を確認してください。

Cloudflareを使えばレンタルサーバーは不要ですか？

DNS、CDN、WAFだけを使う場合は、Webサイト本体を置くレンタルサーバーやクラウド環境が必要です。PagesやWorkersへサイト・APIを移し、R2やD1へデータを置く構成なら、従来のサーバーを減らせる場合があります。ただし、利用するCMS、データベース、メール、バッチ処理の要件を個別に確認します。

CloudflareとAWS、Vercelの違いは何ですか？

AWSは計算、ネットワーク、データベースなど広範なクラウド基盤を提供し、Vercelはフロントエンド開発とデプロイ体験に強みがあります。Cloudflareはグローバルネットワーク、DNS、配信、セキュリティとエッジ実行を一体化している点が特徴です。実際には排他的ではなく、AWSをオリジンにしてCloudflareを前段へ置く、Vercel上のサイトでCloudflare Turnstileを使うなどの組み合わせもあります。

Cloudflareを導入するとSEOに有利ですか？

導入だけで検索順位が上がるわけではありません。ただし、表示速度、可用性、HTTPS、適切なキャッシュはユーザー体験とクロールの安定に役立ちます。一方、WAFで検索クローラーを止める、リダイレクトを誤る、キャッシュで古いcanonicalやnoindexを返すと逆効果です。技術設定とコンテンツ品質を分けて管理します。

Cloudflare導入で最初に確認すべき設定は何ですか？

DNSレコードの完全性、プロキシ対象、SSL/TLSのFull (strict)、キャッシュ除外、WAFの誤検知、オリジンへの直接接続、問い合わせ・ログイン・Webhookの正常動作を優先します。変更前の設定とロールバック手順も残してください。

仕様確認に使えるCloudflare公式情報

Cloudflareの機能、プラン、上限、対応ランタイムは更新されます。導入時は、記事の説明だけで決めず、利用する機能の公式ドキュメントと料金ページを確認してください。

• How Cloudflare DNS works：権威DNS、プロキシ済みレコード、Anycast、リバースプロキシの基本構造
• Cloudflare Cache：キャッシュ、Cache Rules、Purge、Tiered Cache
• Cloudflare WAF：Managed Rules、Custom Rules、Rate limiting rules
• Cloudflare DDoS Protection：自動検知・緩和とマネージドルール
• Cloudflare Workers：サーバーレスアプリ、静的配信、API、バックグラウンド処理
• Cloudflare R2：オブジェクトストレージの用途と機能
• Cloudflare D1：SQLiteセマンティクスを持つサーバーレスSQLデータベース
• Cloudflare One：Access、Tunnel、Secure Web Gatewayを含むSASE・Zero Trust基盤
• Cloudflare Turnstile：CDN利用を必須としないCAPTCHA代替
• Cloudflare Workers AI：サーバーレスGPU上でのAIモデル実行