Cloudflareの危険性は本当か？障害・SLA・情報漏えいの実態と対策

Cloudflare（クラウドフレア）は、世界のWebサイトの2割前後が経由する巨大なネットワークです。無料で高速化とDDoS対策が手に入る一方、「Cloudflareが落ちると自分のサーバーが無事でもサイトが見えなくなる」「通信を全部見られているのでは」という不安から、危険性を調べる人が絶えません。本記事は、2025年11月・2026年2月の大規模障害の公式ポストモーテム、SLAの適用範囲、過去の情報漏えい事故、日本での賠償命令といった一次情報をもとに、危険性の中身を検証します。そのうえで、Cloudflareとは何か・仕組み・メリットとデメリット・料金・導入手順・SEOへの影響まで、判断に必要な材料をまとめます。

まとめ

Cloudflareは「使うと危険なサービス」ではありません。危険性の実体は、Cloudflare自身が落ちたときにサイトも一緒に落ちる集中リスクと、無料・ProプランにはアップタイムSLAが一切存在しないという契約上の事実に集約されます。実際、2025年11月18日には設定ファイルの不具合でネットワーク全体が5xxを返し、2026年2月20日にはBGP経路の誤削除で6時間超の障害が起きました。どちらもサイバー攻撃ではなく、Cloudflare内部の変更が原因です。

一方で「共有IPを使うとSEOが下がる」といった指摘は、根拠が確認できません。実害が出やすいのは、SSL/TLSをフレキシブルのまま運用している構成です。このモードではCloudflareとサーバーの間が平文になります。障害への備えは、DNSのTTLを短くしてプロキシをオフに切り替えられる状態を作ること。Always Onlineやロードバランサーは「Cloudflare本体の障害には効かない」という前提から出発してください。

Cloudflareとは：Webの2割が経由する巨大プロキシ

Cloudflareは、DNS・CDN・WAF・DDoS対策を1つのプラットフォームで提供する米国企業です。読み方は「クラウドフレア」。2009年設立で、2019年にニューヨーク証券取引所へ上場しています（ティッカーはNET）。公式のネットワークページによると拠点は100か国超・337都市に広がり、Web全体の約20%のトラフィックをプロキシしています（都市数は公式ページ間で330〜337と表記が揺れます）。第三者調査のW3Techsでは、2026年7月時点で全Webサイトの23.6%がCloudflareを利用しています。多くのサイトが同じネットワークを通る構造が、高速化と防御の強さの源であり、後述する集中リスクの源でもあります。

仕組み：DNSをCloudflareに向け、通信をいったん終端する

利用開始の操作は、ドメインのネームサーバーをCloudflareのものに変更するだけです。以降、訪問者のアクセスはCloudflareのエッジ拠点にいったん着地し、そこからサーバー（オリジン）へ中継されます。この構造から次の3つが自動的に働きます。

• キャッシュ配信：画像・CSS・JavaScriptなどを各拠点に保存し、訪問者に最も近い拠点から返す（キャッシュそのものの基礎はディスクキャッシュとは｜仕組み・メモリキャッシュとの違い・確認方法をわかりやすく解説で整理しています）。
• リクエストの検査と遮断：WAFルールとボット判定で、攻撃と判定した通信をオリジンに到達させない。
• HTTPSの終端：訪問者との暗号化通信をCloudflare側で復号し、必要な処理を加えてからオリジンへ渡す。

3つ目が重要です。CloudflareはリバースプロキシなのでTLSを終端します。つまり設計上、Cloudflareは通信の中身を平文で扱える位置にいます。これは欠陥ではなくCDN・WAFが成立する前提条件ですが、危険性を考えるときの出発点になります。

主な機能：無料で使える範囲と上位プラン限定の機能

エッジでの実行環境はCloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ、S3互換ストレージはCloudflare R2とは？エグレス無料のS3互換オブジェクトストレージを料金・無料枠から解説で個別に扱っています。

「Cloudflareは危険」と言われる4つの理由と、その実態

検索されている「危険性」は、実際には性質の違う4つの話が混ざっています。

理由1：Cloudflareが落ちるとサイトも落ちる（集中リスク）

最も現実的なリスクです。自社サーバーが健全でも、経路上のCloudflareが5xxを返せば訪問者にはサイトが落ちて見えます。公式ポストモーテムが公開されている主な障害は次のとおりです。

並べると原因の傾向がはっきりします。大規模障害のほとんどはサイバー攻撃ではなく、Cloudflare自身の設定変更やデプロイが引き金です。2025年11月18日の障害は、ClickHouseの権限変更をきっかけにボット判定用の特徴量ファイルへ重複行が入り、ファイルサイズが倍増して、プロキシが確保していた200項目の上限を超過。Rust製プロキシがエラー処理でpanicして5xxを返し続けました。11時28分（UTC）に影響が出始め、主要な影響の解消が14時30分、全サービス復旧は17時6分。公式は「2019年以来、最悪の障害」と表明しています。翌月の12月5日も、脆弱性対応の作業中に投入した設定のkillswitchを段階展開せず全世界へ即時伝播させたことが引き金でした。

Cloudflare側もこれを重く受け止め、2026年5月に全社改修「Fail Small」の完了を公表しました。設定変更を全世界へ即時伝播させる従来方式をやめ、段階展開と健全性監視を挟む仕組み（Snapstone）を導入しています。ただし、2026年2月20日の障害はその改修期間中に起きています。「対策が入ったからもう落ちない」とは考えず、落ちる前提で設計するのが妥当です。

理由2：通信をCloudflareに復号される（TLS終端）

前述のとおりCloudflareはTLSを終端します。したがって「Cloudflareは通信内容を見られるのか」という問いへの答えは、技術的にはイエスです。これを緩和するKeyless SSLという仕組みはありますが、これは秘密鍵を自社側のサーバーに残すだけで、TLS終端自体はCloudflareが行います。しかもEnterprise限定の有料アドオンで、TLS 1.3には対応していません。契約や規制で第三者に平文を通過させられない要件があるなら、リバースプロキシ型のCDNはそもそも要件を満たしません。

ただし、実務で本当に事故になるのはここではありません。SSL/TLSの暗号化モードを「フレキシブル（Flexible）」のまま運用している構成です。このモードでは、訪問者とCloudflareの間はHTTPSでも、Cloudflareとオリジンの間はHTTPの平文になります。公式ドキュメントも、ログインや個人情報を扱うなら「フル」か「フル（厳密）」を使うよう明記しています。ブラウザに鍵マークが出るため安全だと思い込みやすく、危険性という観点では最優先で確認すべき設定です。

理由3：過去の情報漏えい事故（Cloudbleedと位置推定）

2017年2月の「Cloudbleed」では、HTMLパーサのバッファオーバーランにより、他ユーザーのCookieや認証トークンがレスポンスに混入して漏えいしました。発生頻度は約330万リクエストに1回で、SSL秘密鍵は別プロセス管理だったため無事。Cloudflareは報告から47分で該当機能を無効化し、7時間で全世界にパッチを当てています。

より新しい例では、2025年1月に研究者が公表した位置推定の手口があります。Cloudflareのキャッシュ応答から「どの拠点が返したか」を読み取ることで、標的の大まかな居住地（およそ250マイル圏）を推定できるというもので、メッセージアプリの画像自動ダウンロードと組み合わせると相手の操作なしに成立しました。Cloudflareは悪用経路のひとつ（Workersのバグ）を修正しましたが、研究者は修正後も別経路で同等の結果が得られると報告しており、手口そのものは残っています。拠点が分かれば地域が推定できるという性質は、CDNの構造そのものに由来するためです。匿名性が安全に直結する用途では、CDN経由という事実自体をリスクとして数えるべきです。

加えて、自社設定に起因する漏えいもあります。キャッシュルールを広く書きすぎて、ログイン後のページやSet-Cookie付きレスポンスをキャッシュ対象にすると、ある利用者向けに生成された画面が別人へ配信されます。Cloudflareが「Bypass Cache on Cookie」やキャッシュ制御の設定を用意しているのは、この事故が起きうるからです。プラットフォームの欠陥ではなく運用ミスですが、実害の大きさでは上位に来ます。

理由4：海賊版サイトの温床という批判と、日本での賠償命令

Cloudflareは登録時の本人確認が緩く、違法サイトもオリジンIPを隠せてしまうため、以前から「海賊版を助けている」と批判されてきました。2025年11月19日、東京地方裁判所はKADOKAWA・講談社・集英社・小学館の4社が起こした訴訟で、侵害通知を受けながら適切な対応を取らずサービス提供を続けた行為は著作権侵害の幇助にあたると判断し、Cloudflareに約5億円の賠償を命じました。CDN事業者の責任を認めた点で注目された判決です。ただしCloudflareは控訴の方針を示しており、一審判決であって確定していません（その後の経過は公式発表で確認してください）。

この論点は、自社サイトの安全性という意味での危険性とは別物で、Cloudflareを使う企業が違法行為に加担することになる、という話ではありません。ただし係争中の事業者であることは、調達で説明を求められる可能性のある事実です。

契約面の盲点：無料・ProにアップタイムSLAは無い

障害の話は「無料なのだから文句は言えない」で終わりがちですが、契約面は正確に把握しておくべきです。Cloudflareの公式プラン表で、アップタイムSLAが記載されているのはBusiness以上だけです。Freeはもちろん、有料であるProにもアップタイム保証はありません。月25ドルを払っていても、何時間落ちようと契約上の救済はない、ということです。

ではBusinessなら安心かというと、こちらも実損害の補償ではありません。Business SLAは「100%稼働」を掲げますが、返ってくるのは金銭返金ではなくサービスクレジットで、しかも12か月間の累計で1か月分の料金が上限です。請求にも期限があり、インシデントから5営業日以内の通知が必要です。売上が止まった分を取り戻す手段ではないと理解しておきましょう。

したがって判断はこうなります。ダウンタイムが直接売上に響くサイトを、CloudflareのFree／Proプランだけに載せるのは、可用性を無保証で運用すると宣言しているのと同じです。次章の備えを取るか、可用性要件に見合ったプランと冗長構成を選ぶかの二択になります。

Cloudflare障害に備える実務的な対策

プロキシをオフ（DNS only）に切り替えられる状態を作る

Cloudflareのプロキシ層が5xxを返す型の障害では、DNSレコードのプロキシ設定をオン（オレンジ雲）からオフ（グレー雲）へ切り替えると、トラフィックがCloudflareを経由せずオリジンへ直接向かい、サイトが復活します。最も即効性のある回避策ですが、代償があります。

• WAF・キャッシュ・L7のDDoS防御・オリジンIPの秘匿がすべて無効になる（公式ドキュメントも、DNS onlyではオリジンIPが誰にでも見えると明記しています）。
• 切替後の直トラフィックをオリジンが受け止められる必要がある。キャッシュ頼みのサイトはここで落ちます。
• DNSのTTLが長いと切り替えが浸透しない。平時からTTLを短め（60〜300秒程度）にしておくことが前提条件です。
• コントロールプレーン（管理画面）自体が落ちていると、この切替操作ができません。2023年11月の障害がまさにその形でした。

訓練していない手順は本番で使えません。平時に一度切り替え、オリジンが直トラフィックに耐えるかを測っておくべきです。

Always Onlineとロードバランサーは、この障害には効かない

誤解が多い点です。Always Onlineは、オリジンが落ちたときにキャッシュやInternet Archiveの保存版を代わりに配信する機能です。Cloudflare本体が5xxを返している状況では、そもそもリクエストがこの機能に到達しません。ログイン後のページやフォーム送信も対象外で、クロール間隔もFreeは30日おきと粗く、静的な閲覧の延命にしかなりません。

ロードバランサー（有料アドオン）も同じで、ヘルスチェックで切り替えるのはオリジンです。Cloudflareネットワークの障害からは守ってくれません。ここを取り違えると、対策済みのつもりで丸ごと落ちる状態になります。

本気で冗長化するならDNSの上位で分ける

Cloudflareの障害から本当に独立したいなら、切り替えの判断をCloudflareの外に置く必要があります。具体的には、権威DNSを別事業者にも持たせる（Cloudflareのセカンダリネームサーバー機能はEnterprise限定です）、あるいはマルチCDN構成で配信先を切り替える設計です。コストは跳ね上がるので、止まったときの損失額と釣り合うかで決めます。中小規模のサイトなら、前述のグレー雲切替の訓練と短いTTLで十分に現実的です。

Cloudflareのメリットとデメリット：使う理由と、採用を見送るべきケース

危険性を並べてきましたが、Cloudflareが世界の2割に使われているのには理由があります。メリットは費用対効果に集約されます。無料プランでも帯域無制限（unmetered）のDDoS防御が付き、証明書は自動更新され、キャッシュでオリジンの転送量と負荷が下がる。同等のことを自前で用意する費用と比べれば、桁違いに安いというのが実態です。

デメリットは3つあり、重要度には差があります。

• 可用性がCloudflareに握られる：最重要。Free／ProにSLAが無い以上、停止が即座に売上・信用の毀損になる決済・予約システムを単独構成で載せるべきではありません。冗長化まで含めた費用で他CDNと比較してください。
• TLS終端という構造：契約・規制上、第三者に平文を通過させられない要件があるなら、この時点で要件を満たしません。
• ボット判定の巻き添え：APIクライアントやパートナーのクローラーが403やチャレンジで弾かれることがあります。致命的ではありませんが、許可リストの運用コストとして見込んでおいてください。

逆に導入が向くのは、メディアやコーポレートサイトのように静的コンテンツの比率が高く、数分〜数十分の停止が致命傷にならないサイトです。攻撃を受けやすいのに専任のインフラ担当がいない組織にも向きます。

料金プラン（2026年7月時点）

価格は米ドル建てで、日本語ページでも円建て表記はありません（改定があるため最新額は公式のプランページで確認してください）。無料プランで足りるのは、DDoS防御・CDN・DNS・証明書という基礎部分です。上位機能はきれいに切り分けられており、Polishによる画像最適化はPro以上（画像変換自体はFreeでも月5,000件まで使えます）、セカンダリDNSはEnterprise限定です。

導入手順と、事故が起きやすい設定

ネームサーバーの反映待ちを除けば、設定作業そのものは30分程度で終わります。

1. Cloudflareにアカウントを作り、対象ドメインを登録する。
2. 既存のDNSレコードが自動で読み込まれるので、漏れがないか必ず突き合わせる（メール関連のMX・TXTの取りこぼしが、メール不達の典型原因です）。
3. ドメイン登録事業者側で、ネームサーバーをCloudflareの指定値に変更する。反映まで数時間から最大48時間。
4. SSL/TLSの暗号化モードを「フル（厳密）」に設定する。オリジンに有効な証明書が無い場合は、Cloudflareが発行するオリジン証明書を入れてから切り替える。

事故のほとんどは、手順4とキャッシュ設定に集中します。フレキシブルのまま放置すればサーバーとの間が平文になり、キャッシュルールを雑に広げればログイン後の画面が他人に配信される。導入直後に確認すべきは速度ではなく、この2点です。なお、サーバーのポートを開けずに公開したい場合は、DNS切り替えとは別にCloudflare Tunnelとは？無料の仕組みと設定・使い方を初心者向けに解説の構成が使えます。外部にポートを開けずに済むぶん攻撃面は狭くなりますが、経路がCloudflareに一本化されるため、前述の集中リスクは一段深くなります。

SEOへの影響：高速化のプラスとクローラ遮断のマイナス

プラス側は表示速度です。キャッシュ配信によりTTFBが縮み、Core Web Vitalsの評価に効きます。HTTPSの自動化も同様です。ネームサーバー切替時の反映遅延も、DNSは古い設定でも並行して解決されるため、正しく設定していればサイトが検索から消えることはありません。

マイナス側で現実的なのはボット判定によるクローラーの遮断です。セキュリティレベルを上げすぎたり、独自のブロックルールを広く書いたりすると、Googlebot以外の検索エンジンやSEOツールのクローラーがチャレンジ画面に当たり、クロールできなくなります。順位が落ちたときは、まずCloudflareのセキュリティイベントログで自社サイトへのクローラーがブロックされていないかを確認してください。

「共有IPだとSEOが下がる」という説は根拠が薄い

Cloudflare否定論としてよく見かけるのが、「スパムサイトとIPを共有するとブラックリスト入りして順位が落ちる」というものです。しかしGoogleは、同一IPに多数のサイトが同居する共有ホスティングを長年前提としており、John Muellerも共有IPやCDNの利用そのものが順位を下げることはないと繰り返し否定しています。もしそれが成り立つなら、Web全体の2割が該当することになります。順位が落ちた原因を探すなら、前段のクローラー遮断のほうがはるかに頻度の高い容疑者です。

よくある質問（FAQ）

Cloudflareのデメリットは何ですか？

最大のデメリットは、可用性がCloudflare側に握られることです。自社サーバーが正常でもCloudflareが落ちればサイトは見えなくなり、しかもFree・ProプランにはアップタイムSLAがありません。次いで、TLSを終端する構造上、Cloudflareが通信を平文で扱える点、ボット判定で正規のクローラーやAPIクライアントが弾かれる点が挙げられます。

Cloudflareは無料で使えますか？

Freeプランで、CDN・DNS・帯域無制限のDDoS防御・SSL証明書の自動発行まで無料で使えます。ただしWAFのカスタムルールは5本まで、Polishによる画像最適化は使えず、アップタイムSLAもありません。

Cloudflareの障害でサイトが落ちたら何をすればいいですか？

DNSレコードのプロキシをオフ（グレー雲）に切り替えると、Cloudflareを経由せずオリジンへ直接アクセスさせられます。ただしWAF・キャッシュ・L7 DDoS防御を同時に失うため、オリジンが直トラフィックに耐えられることが前提です。平時からTTLを短くし、切替手順を訓練しておいてください。

パブリックDNSの1.1.1.1を使うのは安全ですか？

サイト運営者としてCloudflareを使う話とは別に、端末の参照先を1.1.1.1に変える利用者も多くいます。Cloudflareは、この公開リゾルバについて閲覧データを広告目的で販売せず、個人を特定できるクエリログを24時間を超えて保持しない方針を公表し、第三者による監査結果も公開しています。ただし、どの名前解決サービスを使ってもリゾルバ運営者に問い合わせ内容が渡る点は変わりません。

サイト閲覧時に出るCloudflareの人間確認画面は危険ですか？

Cloudflareのチャレンジ画面（人間であることの確認）は、そのサイトがCloudflareのボット対策を有効にしている印であり、マルウェアではありません。ただし、この画面を模したフィッシングや、偽の認証手順を踏ませてコマンドを実行させる手口が報告されています。確認画面の指示としてWindowsのファイル名を指定して実行やターミナルへの貼り付けを求められたら、それは偽物です。正規のチャレンジはブラウザ内で完結します。

Cloudflareを使うとSEOに悪影響はありますか？

高速化はプラスに働きます。悪影響が出るとすれば、セキュリティ設定を強くしすぎてクローラーがブロックされるケースです。「共有IPだとブラックリスト入りして順位が落ちる」という説には、Googleの公式見解や公開された検証による裏づけがありません。

関連記事

• Cloudflare Tunnelとは？無料の仕組みと設定・使い方を初心者向けに解説
• Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ
• Cloudflare R2とは？エグレス無料のS3互換オブジェクトストレージを料金・無料枠から解説
• CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル
• ディスクキャッシュとは｜仕組み・メモリキャッシュとの違い・確認方法をわかりやすく解説