--- title: "Cloudflareの危険性は本当か：デメリット・障害・SLA・情報漏えいの実態と点検手順" url: "https://www.issoh.co.jp/tech/details/3682/" published: 2024-09-30 updated: 2026-10-20 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Cloudflareの危険性は本当か：デメリット・障害・SLA・情報漏えいの実態と点検手順 **Cloudflare（クラウドフレア）**は、世界のWebサイトの4分の1前後が経由する巨大なネットワークです。無料で高速化とDDoS対策が手に入る一方、「Cloudflareが落ちると自分のサーバーが無事でもサイトが見えなくなる」「通信を全部見られているのでは」という不安から、**危険性**を調べる人が絶えません。本記事は、2025年9月の管理画面・API障害から2026年2月のBGP障害までの公式ポストモーテム、Business SLAの原文、サポート窓口経由の流出を含む情報漏えい事故、日本での賠償命令といった一次情報をもとに、危険性の中身を検証します。そのうえで、自社サイトが危険な設定になっていないかをコマンドで点検する手順、障害時にCloudflareを外して配信を続ける切替手順、デメリットと料金・SEOへの影響、採用と見送りの判断まで扱います。閲覧中に「危険なサイト」と警告されたCloudflare経由のページをどう見るかも説明します。 ## まとめ：Cloudflareの危険性の中身と最初に確認すべき設定 Cloudflareは「使うと危険なサービス」ではありません。危険性の実体は、**Cloudflare自身が落ちたときにサイトも一緒に落ちる集中リスク**と、**無料・ProプランにはアップタイムSLAが存在しない**という契約上の事実、そして**利用者側の設定ミスによる平文通信やキャッシュ事故**です。ここにTLS終端という構造と、サポート窓口経由の流出のような周辺の事故が加わります。実際、2025年11月18日には設定ファイルの不具合でコア配信などに広範な5xxエラーが発生し、2026年2月20日にはBGP経路の誤った取り下げで6時間超の障害が起きました。どちらもサイバー攻撃ではなく、Cloudflare内部の変更が原因です。 一方で「共有IPを使うとSEOが下がる」といった指摘は、根拠が確認できません。実害が出やすいのは、SSL/TLSを**フレキシブルのまま運用している構成**です。このモードではCloudflareとサーバーの間が平文になります。まずAPIかダッシュボードでSSLモードを確かめ、「フル（厳密）」へ寄せてください。障害への備えは、プロキシをオフに切り替える手順をAPIで用意し、オリジンにブラウザが信頼する証明書があるか、直トラフィックに耐えるかを平時に確かめておくこと。Always Onlineやロードバランサーは「Cloudflare本体の障害には効かない」という前提から出発します。 閲覧する側の危険は別物です。Cloudflareの無料ホスティングやトンネルはフィッシングに悪用されることがあり、ブラウザの警告はそのページの中身に対して出ています。Cloudflareを経由していること自体は、安全の証明にも危険の証拠にもなりません。 ## Cloudflareとは何か：Webの約4分の1が経由するリバースプロキシの仕組み Cloudflareは、DNS・CDN・WAF・DDoS対策を1つのプラットフォームで提供する米国企業です。読み方は「クラウドフレア」。2009年設立で、2019年にニューヨーク証券取引所へ上場しています（ティッカーはNET）。[公式のネットワークページ](https://www.cloudflare.com/network/)では、2026年10月時点で拠点は348都市・100か国超に広がり、インターネット上のサイトの5つに1つを支えていると説明しています。第三者調査の[W3Techsの統計](https://w3techs.com/technologies/details/cn-cloudflare)では、2026年10月20日時点で全Webサイトの27.6%がCloudflareを利用し、リバースプロキシが判明しているサイトに限ると、その割合は85.9%です。多くのサイトが同じネットワークを通る構造が、高速化と防御の強さの源であり、後述する集中リスクの源でもあります。 ### 仕組み：プロキシを有効にしたホスト名とエッジでのTLS終端 一般的なフルセットアップでは、Cloudflareへドメインを追加してDNSレコードを確認し、ネームサーバーを変更したうえで、Web配信用レコードのプロキシを有効にします。プロキシを有効にしたホスト名では、訪問者のアクセスはCloudflareのエッジ拠点にいったん着地し、そこからサーバー（オリジン）へ中継されます。こうした中継役の基本は[リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説](/tech/details/13554/)、配信網としての位置づけは[CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説](/tech/details/13095/)で整理しています。この構造により自動的に働く機能は、次の3つです。 - **キャッシュ配信**：画像・CSS・JavaScriptなどを各拠点に保存し、訪問者に最も近い拠点から返す（キャッシュそのものの基礎は[ディスクキャッシュとは？仕組み・メモリキャッシュとの違いとLinux・Windowsでの確認方法](/tech/details/3534/)で整理しています）。 - **リクエストの検査と遮断**：WAFルールとボット判定で、攻撃と判定した通信をオリジンに到達させない（WAFの守備範囲は[WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説](/tech/details/13275/)を参照）。 - **HTTPSの終端**：訪問者との暗号化通信をCloudflare側で復号し、必要な処理を加えてからオリジンへ渡す。 3つ目が肝心です。CloudflareはリバースプロキシなのでTLSを終端します。つまり**設計上、Cloudflareは通信の中身を平文で扱える**位置にあるという構造です。これは欠陥ではなくCDN・WAFが成立する前提条件ですが、危険性を考えるときの出発点になります。なお、プロキシ（オレンジ雲）を通せるのはA・AAAA・CNAMEレコードだけで、MXやTXTは常にDNS onlyです（[公式のプロキシ状態の説明](https://developers.cloudflare.com/dns/proxy-status/)）。メールの経路はCloudflareを通らない、という点も押さえておきます。 ### 主な機能：無料プランで使える範囲と上位プランに限られる機能の境目 | 機能 | 役割 | 無料プラン | | ------- | --------------------- | ------------------- | | CDN | 静的コンテンツを拠点からキャッシュ配信 | 利用可 | | DNS | ドメインのDNSレコードを権威DNSで応答 | 利用可 | | DDoS対策 | L3〜L7を帯域無制限で防御 | 利用可 | | WAF | SQLインジェクション・XSS等を遮断 | カスタムルール5本まで | | SSL/TLS | 証明書の自動発行・更新 | 利用可 | | Workers | エッジ拠点でのコード実行 | 1日10万リクエスト | | R2 | エグレス無料のオブジェクトストレージ | 標準ストレージ10GB-month／月 | | Tunnel | サーバーのポートを開けずに公開 | 利用可 | WAFのカスタムルール上限は[公式ドキュメント](https://developers.cloudflare.com/waf/custom-rules/)でFree 5本・Pro 20本・Business 100本・Enterprise 1,000本と定められています（2026年10月時点）。エッジでの実行環境は[Cloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方](/tech/details/6760/)、S3互換ストレージは[Cloudflare R2とは？料金・無料枠とS3互換の範囲、使い方を解説](/tech/details/7455/)で個別に扱っています。 ## Cloudflareの危険性に関する5つの論点と公式報告・判決の検証 検索されている「危険性」は、実際には性質の違う5つの話が混ざっています。どれが自社に当てはまるかで、取るべき対策がまったく変わります。 ### 理由1：Cloudflareが落ちるとサイトも落ちる集中リスクと障害の履歴 最も現実的なリスクです。自社サーバーが健全でも、経路上のCloudflareが5xxを返せば訪問者にはサイトが落ちて見えます。公式ポストモーテムが公開されている主な障害は次のとおりです。現在の稼働状況は[Cloudflare Status](https://www.cloudflarestatus.com/)で確認できます。 | 発生日 | 原因 | 停止時間 | 影響 | | ---------- | ------------------------ | ------------------ | --------------- | | 2019-07-02 | WAFの正規表現がCPUを食い潰す | 27分 | グローバルに502 | | 2020-07-17 | バックボーンのルータ設定ミス | 27分 | 一部地域が到達不能 | | 2022-06-21 | 19拠点のネットワーク構成変更の誤り | 1時間15分 | 主要19拠点 | | 2023-11-02 | データセンターの電源障害 | 約40時間41分 | 管理画面・API・ログ・分析等 | | 2025-06-12 | Workers KVが依存する外部ストアの障害 | 2時間28分 | KV取得の90%が失敗 | | 2025-09-12 | 管理画面の不具合で内部APIが過負荷 | 約1時間15分 | 管理画面とAPIが5xx | | 2025-11-18 | Bot Managementの設定ファイル肥大化 | 主要影響約3時間／全復旧5時間38分 | コアCDNなどで5xx | | 2025-12-05 | WAF設定の即時展開でLuaのバグ | 約25分 | 全HTTPの約28% | | 2026-01-22 | マイアミのルーター設定でBGP経路を漏えい | 25分 | IPv6の一部で遅延・損失 | | 2026-02-20 | BYOIPの経路を誤ってBGP撤回 | 6時間7分 | 約1,100プレフィックス | 並べると原因の傾向がはっきりします。**大規模障害のほとんどはサイバー攻撃ではなく、Cloudflare自身の設定変更やデプロイが引き金**です。[2025年11月18日の障害のポストモーテム](https://blog.cloudflare.com/18-november-2025-outage/)によると、ClickHouseの権限変更をきっかけにボット判定用の特徴量ファイルへ重複行が入り、ファイルサイズが倍増して、プロキシが確保していた200項目の上限を超過。Rust製プロキシがエラー処理でpanicして5xxを返し続けました。11時28分（UTC）に影響が出始め、主要な影響の解消が14時30分、全サービス復旧は17時6分。公式は「2019年以来、最悪の障害」と表明しています。 翌月の[2025年12月5日の障害](https://blog.cloudflare.com/5-december-2025-outage/)は、React Server Componentsの脆弱性対応の一環として、内部のWAFテストツールを無効化する設定変更を全体へ即時展開したことが引き金でした。この変更が旧プロキシ（FL1）のルール処理に潜んでいたLuaのバグを踏み、全HTTPトラフィックの約28%が約25分間HTTP 500を返しています。[2026年2月20日の障害](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)では、BYOIP（持ち込みIP）の管理方法を変更した処理が、約1,100のBYOIPプレフィックスのBGP経路を取り下げ、解消まで6時間7分かかりました。公式は、これもサイバー攻撃ではないと明言しています。その1か月前の[2026年1月22日](https://blog.cloudflare.com/route-leak-incident-january-22-2026/)にも、ネットワーク自動化コードの不具合でマイアミ拠点のルーターがBGP経路を漏えいさせ、IPv6の一部の通信で25分間、遅延と損失が出ています。 Cloudflare側もこれを重く受け止め、2026年5月1日に全社改修[「Code Orange: Fail Small」の完了](https://blog.cloudflare.com/code-orange-fail-small-complete/)を公表しました。設定変更を全世界へ即時に反映する従来方式をやめ、健全性監視を挟んだ段階展開と自動ロールバックを担う社内コンポーネント（Snapstone）を導入しています。障害時は直前の正常な設定を使い続ける「fail stale」を優先し、管理系が落ちたときの緊急用の認可経路（break glass）も18の主要サービスで用意したとしています。ただし、**2026年2月20日の障害が起きたのは、その改修期間中でした**。公式ブログの[ポストモーテム一覧](https://blog.cloudflare.com/tag/post-mortem/)には、2026年10月20日時点で2026年2月20日より後の障害報告は載っていません。それでも「対策が入ったからもう落ちない」とは考えず、落ちる前提で設計するのが妥当です。 ### 理由2：TLS終端によって通信がCloudflareで復号されるという構造 前述のとおりCloudflareはTLSを終端します。したがって「Cloudflareは通信内容を見られるのか」という問いへの答えは、技術的にはイエスです。これを緩和する[Keyless SSL](https://developers.cloudflare.com/ssl/keyless-ssl/)という仕組みはありますが、これは**秘密鍵を自社側のサーバーに残すだけで、TLS終端自体はCloudflareが行います**。しかもEnterprise限定の有料アドオンで、TLS 1.3には対応していません。契約や規制で第三者に平文を通過させられない要件があるなら、リバースプロキシ型のCDNはそもそも要件を満たしません。 TLS終端を契約上許容できる場合でも、次に確認すべきなのはオリジンまでの通信が暗号化されているかです。SSL/TLSの暗号化モードを**「フレキシブル（Flexible）」のまま運用している構成**です。[Flexibleモードの公式ドキュメント](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/flexible/)のとおり、このモードでは訪問者とCloudflareの間はHTTPSでも、**Cloudflareとオリジンの間はHTTPの平文**になります。同ドキュメントは、個人に紐づくデータやログインを扱うなら「フル」か[「フル（厳密）」](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/)を使うよう明記しています。ブラウザに鍵マークが出るため安全だと思い込みやすく、危険性という観点では最優先で確認すべき設定です。確認方法は後述の点検手順で示します。 ### 理由3：過去の情報漏えい事故（Cloudbleed・拠点からの位置推定・サポート窓口経由の流出） 2017年2月の「Cloudbleed」では、HTMLパーサのバッファオーバーランにより、他ユーザーのCookieや認証トークンがレスポンスに混入して漏えいしました。[公式のインシデントレポート](https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/)によると、影響が最大だった期間には約330万HTTPリクエストに1回の割合でメモリ漏えいが起こり得たとされ、顧客のSSL秘密鍵は別プロセスで処理されていたため漏えいしませんでした。Cloudflareは報告から47分でEmail Obfuscationを無効化して初期緩和を行い、残る機能への対応を含め、7時間未満で全世界の修正を完了したと報告しています。 より新しい例では、2025年1月に[研究者が公表した](https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117)位置推定の手口があります。Cloudflareのキャッシュ応答から「どの拠点が返したか」を読み取ることで、標的の大まかな居住地（およそ250マイル圏）を推定できるというもので、メッセージアプリの画像自動ダウンロードと組み合わせると相手の操作なしに成立しました。Cloudflareは悪用経路のひとつ（Workersのバグ）を修正しましたが、**研究者は当該報告の時点で、修正後もVPNを使う別経路で同等の結果が得られたと述べています**。拠点が分かれば地域が推定できるという性質は、CDNの構造そのものに由来するためです。匿名性が安全に直結する用途では、CDN経由という事実自体をリスクとして数えるべきです。 2025年8月には、Cloudflareのネットワークではなく、問い合わせ管理に使っていたSalesforceから情報が抜かれました。[公式の報告](https://blog.cloudflare.com/response-to-salesloft-drift-incident/)によると、Cloudflareは8月23日に被害の通知を受けています。Webサイトのチャット窓口に使っていたSalesloft DriftのSalesforce連携から、OAuth認証情報が盗まれ、サポートケースの本文が外部へ持ち出されました。Cloudflareが流出データを調べると、顧客が問い合わせに貼り付けたCloudflareのAPIトークンが104件見つかり、すべて再発行しています。サービスや基盤そのものは侵害されていないとしたうえで、サポートに共有したログ・トークン・パスワードは漏えいしたものとして扱い、変更するよう呼びかけました。**問い合わせにはAPIトークンやパスワードを貼らない。貼ってしまったものはすぐ失効させる**。これは利用者側で守れる対策です。 加えて、自社設定に起因する漏えいもあります。キャッシュルールを広く書きすぎて、ログイン後のページや`Set-Cookie`付きレスポンスをキャッシュ対象にすると、ある利用者向けに生成された画面が別人へ配信される状態です。[既定のキャッシュ動作](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)ではHTMLやJSONはキャッシュ対象外ですが、「すべてキャッシュ」系のルールを足した瞬間にこの前提が崩れます。プラットフォームの欠陥ではなく運用ミスですが、実害の大きさでは上位に来ます。 ### 理由4：海賊版サイトの温床という批判と日本での賠償命令の位置づけ Cloudflareは登録時の本人確認が緩く、違法サイトもオリジンIPを隠せてしまうため、以前から「海賊版を助けている」と批判されてきました。2025年11月19日、東京地方裁判所はKADOKAWA・講談社・集英社・小学館の4社が起こした訴訟で、**侵害通知を受けながら適切な対応を取らずサービス提供を続けた行為は著作権侵害の幇助にあたる**と判断し、Cloudflareに約5億円の賠償を命じました。CDN事業者の責任を認めた点で注目された判決です。[出版社側の発表](https://group.kadokawa.co.jp/information/news%5Frelease/2025111901.html)によると、判決が認定した損害は4社・4作品で総額約36億円で、4社が損害の一部だけを請求していたため、支払いを命じられた額は約5億円になりました。ここで説明したのは**2025年11月19日の東京地方裁判所の判断**で、2026年10月20日時点で、控訴審の判断は出版社や裁判所の発表では確認できません。 この論点は、自社サイトの安全性という意味での危険性とは別物で、Cloudflareを使う企業が違法行為に加担することになる、という話ではありません。ただし、海賊版対応をめぐって日本の裁判所で責任を認められた事業者であることは、調達の場で説明を求められる可能性のある事実です。 ### 理由5：無料トンネル・ホスティングの悪用と閲覧者向け警告 5つ目は、Cloudflareを使う側ではなく、Cloudflare経由のページを見る側の危険です。Cloudflareの無料機能は、攻撃者にとっても手軽な足場になります。セキュリティ企業Proofpointの[2024年8月1日の報告](https://www.proofpoint.com/us/blog/threat-insight/threat-actor-abuses-cloudflare-tunnels-deliver-rats)によると、アカウントを作らずに一時的なトンネルを立てられるTryCloudflareを使い、遠隔操作型のマルウェア（RAT）を配る攻撃が2024年2月から観測され、5月から7月にかけて増えました。配られたのはXworm・AsyncRAT・VenomRAT・GuLoader・Remcosで、1回の攻撃で送られるメールは数百通から数万通です。使い捨てのURLを次々に作れるため、URLのブロックリストだけでは追いつきません。メールセキュリティ企業Fortraの[調査](https://www.fortra.com/blog/cloudflare-pages-workers-domains-increasingly-abused-for-phishing)でも、Cloudflare Pagesを使ったフィッシングは2023年の460件から2024年10月中旬までに1,370件へ、Workersを使ったものは2023年の2,447件から2024年の年初来4,999件へ増えています。Workersの例では、人間確認を装ったページを挟んでからMicrosoft 365の偽ログイン画面へ転送していました。 ブラウザが出す「危険なサイト」の赤い警告は、Googleのセーフブラウジングがそのページの中身（フィッシングやマルウェアの配布）を判定した結果です。Cloudflareを経由していることが理由ではありません。警告が出たページでは、ログイン情報の入力やファイルのダウンロードをしないのが原則です。悪用されているページを見つけたら、Cloudflareの[不正利用の報告フォーム](https://www.cloudflare.com/abuse/form)から、具体的なURLを添えて通報できます。手口の見分け方と技術的な対策は[フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](/tech/details/13548/)で整理しています。 自分のサイトに警告が出た場合は、Search Consoleの[セキュリティの問題レポート](https://support.google.com/webmasters/answer/9044101?hl=ja)を開きます。Googleの手順では、レポートに挙がった問題をサイト全体で直してから「審査をリクエスト」を選び、修正した内容を書いて送ります。再審査はほとんどが数日から数週間かかり、決定の通知が来るまで再送信しないよう求められています。Tunnelで公開した管理画面に認証なしで誰でも届く状態は、乗っ取られて悪用される入口になります。公開範囲の絞り方は[Cloudflare Tunnelとは？料金は無料か・仕組み・安全性とcloudflaredの設定手順](/tech/details/8634/)で扱っています。 ## 自社サイトの危険な設定をdigとcurlとCloudflare APIで点検する手順 ここまでの5つの理由のうち、自社の手で潰せるのは「平文区間」と「キャッシュ事故」、そしてCloudflareを迂回する直接アクセスです。どれも導入時に誰かが設定したまま見直されていないことが多いので、次の4段階で現状を確かめます。コマンドの書式は[公式APIリファレンス（ゾーン設定の取得）](https://developers.cloudflare.com/api/resources/zones/subresources/settings/methods/get/)に沿っています。`example.com`は自社ドメインに置き換えてください。 ### 手順1：digによるネームサーバー・プロキシ経由・TTLの確認 まず、そのホスト名が本当にCloudflareを通っているのかを確かめます。プロキシ有効のレコードはCloudflareのIPを返し、TTLは300秒で固定されます。オリジンの実IPが返ってくるなら、そのレコードはDNS onlyで、WAFもDDoS防御も効いていません。 ``` # ネームサーバーがCloudflareか（*.ns.cloudflare.com が返れば Cloudflare DNS） dig +short NS example.com # 回答のIPとTTLを確認（再帰リゾルバのキャッシュ回答ではTTLは残存秒数） dig +noall +answer www.example.com A # 返ってきたIPが Cloudflare の公開レンジか照合する curl -sS https://www.cloudflare.com/ips-v4/ # IPv6の回答と公開レンジも確認する dig +noall +answer www.example.com AAAA curl -sS https://www.cloudflare.com/ips-v6/ ``` DNSの読み方そのものは[名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説](/tech/details/13556/)で扱っています。`www`は保護されているのに、`api`や`admin`のサブドメインだけDNS onlyのままになっていないかも確認してください。 ### 手順2：curlのレスポンスヘッダでログイン後ページのキャッシュ状態を確認 次に、キャッシュしてはいけないページがキャッシュされていないかを見ます。キャッシュ処理の結果は、付与されている場合には`cf-cache-status`ヘッダで確認でき、`HIT`ならエッジのキャッシュから返されています。 ``` # 公開ページ：HIT や MISS なら正常にキャッシュ判定されている curl -sI https://www.example.com/assets/app.css | grep -iE "^(server|cf-cache-status|cf-ray)" # ログイン後・マイページなど：HIT が出たら他人の画面が配信される恐れ curl -sS -D - -o /dev/null --cookie "${SESSION_COOKIE_FILE:?ログイン済みテストアカウントのCookieファイルを指定}" https://www.example.com/mypage/ | grep -iE "^(cf-cache-status|set-cookie|cache-control)" ``` `SESSION_COOKIE_FILE`には、テスト用アカウントでログインしたときのCookieを保存したファイル（`curl -c`で書き出したものやブラウザから書き出したもの）のパスを入れます。Cookieを渡さないと未ログインの画面を調べることになり、点検になりません。ログイン後のページや`set-cookie`を返すページで`cf-cache-status: HIT`が出たら、対象ページをキャッシュから除外し、既に保存された機密情報を含むキャッシュを削除します。その後、認証状態を変えて複数回取得し、キャッシュ状態と応答内容を確認してください。`DYNAMIC`や`BYPASS`だけで安全性の確認は完了しません。 ### 手順3：Cloudflare APIでのSSL/TLS設定点検と平文通信の判別 続いて、暗号化モードがflexibleで、オリジンとの区間が平文になっていないかをCloudflare APIで確かめます。ダッシュボードの「SSL/TLS」画面でも確認できますが、複数ゾーンを管理しているならAPIでまとめて見るほうが漏れがありません。APIトークンにはゾーン設定の読み取り権限を付けます。 ``` # 環境変数にトークンとゾーンIDを入れておく export CF_API_TOKEN="（ゾーン設定の読み取り権限を持つトークン）" export ZONE_ID="（対象ゾーンのID）" # SSLモードを取得："value" が "flexible" なら Cloudflare とオリジン間は平文 curl -s "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/ssl" \ -H "Authorization: Bearer ${CF_API_TOKEN}" ``` 返ってくる`value`は`off`・`flexible`・`full`・`strict`・`origin_pull`のいずれかです。`origin_pull`はEnterprise限定で、訪問者側の通信方式にかかわらずオリジンへTLS接続し、証明書も検証するモードです。通常のフル（厳密）とは区別し、HTTPアクセスをHTTPSへ転送する設定も別途確認してください。`strict`または`origin_pull`以外なら、オリジンに有効な証明書（Cloudflareが発行するオリジン証明書でも可）を入れてから切り替えます。オリジンでHTTPS接続を受けられない場合は525など、フル（厳密）で証明書の検証に失敗する場合は526が発生するため、順番を逆にしないでください。 ### 手順4：curlによるオリジン直接アクセスとWAF迂回の点検 Cloudflareの防御が効くのは、Cloudflareを通った通信だけです。オリジンのIPアドレスが知られていて、そのIPへ直接つながる状態なら、攻撃者はWAFもDDoS防御も素通りできます。手順1でDNS onlyのサブドメインが見つかった場合や、Cloudflareを入れる前と同じIPのまま運用している場合は、オリジンIPは既に知られている前提で確かめます。 ``` # オリジンの実IP（例：203.0.113.10）を指定し、Cloudflareを通さずに同じホスト名で接続する # -k はオリジン証明書が公開CA発行でない場合（Cloudflareのオリジン証明書など）でも応答を見るため curl --noproxy '*' -sSkI --connect-timeout 5 --max-time 15 --resolve www.example.com:443:203.0.113.10 https://www.example.com/ | head -n 1 # 「HTTP/2 200」などが返れば、WAFを迂回して直接アクセスできる状態 ``` 応答が返ったら、オリジンのファイアウォールで80番・443番の受信をCloudflareのIPレンジ（手順1で取得した一覧）だけに絞ります。証明書でも縛りたい場合は[Authenticated Origin Pulls](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/)を有効にします。オリジン側でもクライアント証明書の検証を必須にするmTLSの仕組みで、Freeを含む全プランで使えます。標準の共有証明書が証明するのはCloudflareネットワークからの接続であり、自社アカウントからの接続に限定するには独自証明書によるゾーン単位などの設定が必要です。SSLモードがオフかフレキシブルのときは働かず、Cloudflare Tunnel経由のオリジンにも使えません。Tunnelは外向き接続で動作するため公開受信ポートを必要としませんが、既存の公開ポートが自動的に閉じるわけではないので、オリジンへの別経路の直接アクセスが遮断されていることは確認してください。 この4段階は、設定が正しいかを確かめる最小限の点検です。WAFルールの抜けやアプリケーション側の脆弱性まで含めて第三者の目で確かめたい場合は、一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、診断から修正後の再診断まで対応しています。 ## 契約面の盲点：無料・ProプランにアップタイムSLAが無いことの意味 障害の話は「無料なのだから文句は言えない」で終わりがちですが、契約面は正確に把握しておくべきです。Cloudflareの[公式プランページ](https://www.cloudflare.com/plans/)のプラン表で、アップタイムSLAが記載されているのは**Business以上だけ**です。**Freeはもちろん、月払い25ドルの有料プランであるProでも、アップタイムSLAとそれに基づくサービスクレジットはありません**。 ではBusinessなら安心かというと、こちらも実損害の補償ではありません。[Business SLAの原文](https://www.cloudflare.com/business-sla/)は「100%稼働」を掲げますが、返ってくるのは金銭返金ではなく**サービスクレジット**で、12か月間の累計で月額料金1か月分が上限です。請求にも期限があり、インシデントから5営業日以内にサポートへ通知し、発生月の翌請求月末までに根拠を添えて請求する必要があります。月額サービス料金に適用するクレジット率は「停止分数×影響を受けたユニーク訪問者の割合÷予定稼働分数」で計算されるため、一部地域だけの障害では額がさらに小さくなります。売上が止まった分を取り戻す手段ではないと理解しておきましょう。 したがって判断はこうなります。**ダウンタイムが直接売上に響くサイトを、CloudflareのFree／Proプランだけに載せるのは、可用性を無保証で運用すると宣言しているのと同じ**です。次章の備えを取るか、可用性要件に見合ったプランと冗長構成を選ぶかの二択になります。 ## Cloudflare障害への備え：APIによるプロキシ解除と切替訓練 ### DNS onlyへのAPI切替手順と保護機能を失う影響 Cloudflareのプロキシ層が5xxを返す型の障害では、DNSレコードのプロキシ設定をオン（オレンジ雲）からオフ（グレー雲）へ切り替えると、Webトラフィックをオリジンへ直接向けられます。ただし、ブラウザが信頼する公開CAの証明書、直接接続を受け入れる接続制御、必要な処理能力が前提です。点検の手順4で示したCloudflare IP限定やAuthenticated Origin Pullsを適用した構成では、事前に検証した緊急配信経路への切替も必要です。Cloudflare Origin CA証明書だけでは、直接接続したブラウザに証明書エラーが出ます。障害時はダッシュボードが重くなることがあるため、[DNSレコード更新API](https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/edit/)で切り替えるスクリプトを平時に用意しておくと確実です。トークンには対象ゾーンのDNS編集権限を付けます。以下は対象ホスト名にAレコードが1件だけある構成の例です。同名のA・AAAAレコードが複数ある場合はすべてを確認し、プロキシ有効のレコードを残さず切り替えます。CNAME構成では対象のCNAMEレコードを確認してください。 ``` # 1) 対象レコードのIDを調べる curl -s "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records?type=A&name=www.example.com" \ -H "Authorization: Bearer ${CF_API_TOKEN}" # 2) 取得した対象レコードの id を設定する export RECORD_ID="（取得した対象レコードのID）" # proxied を false にする（PATCH は送った項目だけを更新） curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records/${RECORD_ID}" \ -H "Authorization: Bearer ${CF_API_TOKEN}" \ -H "Content-Type: application/json" \ --data '{"proxied": false, "ttl": 60}' # 3) 復旧後は proxied を true に戻す（プロキシ有効時の TTL は自動で300秒になる） curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records/${RECORD_ID}" \ -H "Authorization: Bearer ${CF_API_TOKEN}" \ -H "Content-Type: application/json" \ --data '{"proxied": true, "ttl": 1}' ``` APIリファレンスでは全体を書き換えるPUT（Overwrite）と、項目単位で更新するPATCH（Update）が分かれています。`ttl`の`1`は「自動」を意味し、DNS onlyの手動指定は通常60〜86400秒で、Enterpriseでは最小30秒です。この切替には、次の制約と代償があります。 - WAF・キャッシュ・L7のDDoS防御・オリジンIPの秘匿がすべて無効になる（[公式ドキュメント](https://developers.cloudflare.com/dns/proxy-status/)も、DNS onlyではレコードを問い合わせた誰にでもオリジンIPが見えると明記しています）。 - 切替後の直トラフィックをオリジンが受け止められる必要がある。キャッシュ頼みのサイトはここで落ちます。 - プロキシ有効のレコードはTTLが自動（300秒）に固定されるため、切替の反映には通常このTTLに応じた待ち時間が生じますが、端末側のDNSキャッシュなどにより5分を超える場合もあります。プロキシ有効時のTTLは短縮できません。切替後は残存TTLに応じて順次反映されるため、5分を目安に複数のリゾルバで確認し、端末側のキャッシュによる遅延も見込みます。 - **コントロールプレーン（管理画面やAPI）自体が落ちていると、この切替操作ができません**。2023年11月の電源障害に加え、[2025年9月12日の障害](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/)では、ダッシュボードの不具合がAPIの認可を担う内部サービスを過負荷にし、17時57分から19時12分（UTC）まで管理画面が使えず、APIも2度にわたり5xxを返しました。切替スクリプトを用意していても、APIが落ちている間は動きません。 訓練していない手順は本番で使えません。平時に一度切り替え、オリジンが直トラフィックに耐えるかを測っておくべきです。 ### Always Onlineとロードバランサーが本体の障害に効かない理由 誤解が多い点です。[Always Onlineの公式ドキュメント](https://developers.cloudflare.com/cache/how-to/always-online/)のとおり、この機能は**Cloudflareがオリジンへ接続できないとき**に、キャッシュやInternet Archiveの保存版を代わりに配信するものです。オリジンに到達できて5xxを返している場合も作動しませんし、Cloudflare本体が5xxを返している状況では、そもそもリクエストがこの機能に到達しません。ショッピングカートなどの動的な操作は対象外で、クロール間隔もFreeは30日おき（Proは15日、Business以上は5日）と粗く、静的な閲覧の延命にしかなりません。 ロードバランサー（有料アドオン）も同じで、ヘルスチェックで切り替えるのは**オリジン**です。Cloudflareネットワークの障害からは守ってくれません。ここを取り違えると、対策済みのつもりで丸ごと落ちる状態になります。 ### Cloudflare障害から独立する権威DNS・配信経路の冗長化 Cloudflareの障害から本当に独立したいなら、切り替えの判断をCloudflareの外に置く必要があります。具体的には、権威DNSを別事業者にも持たせる（Cloudflareを[セカンダリDNSとして使う構成](https://developers.cloudflare.com/dns/zone-setups/zone-transfers/cloudflare-as-secondary/)はEnterprise限定です）、あるいはマルチCDN構成で配信先を切り替える設計です。ネームサーバーそのものをCloudflareから別事業者へ移す場合は、登録事業者の処理やNSレコードのキャッシュにより反映時間が変わるため、障害当日の即時復旧手段としては当てにできません。コストは跳ね上がるので、止まったときの損失額と釣り合うかで決めます。中小規模のサイトなら、前述のグレー雲切替の訓練で十分に現実的です。なお、ドメインの登録までCloudflare Registrarへ寄せると、ネームサーバーをCloudflare以外へ変えられなくなります。この制約は[Cloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装【2026年9月版】](/tech/details/17851/)で扱っています。 ## 料金プランとアップタイムSLAの有無（2026年10月時点の公式プラン表） | プラン | 月額（年払い） | 月額（月払い） | アップタイムSLA | WAFカスタムルール | | ---------- | ------- | ----------- | ----------- | ---------- | | Free | $0 | $0 | なし | 5本 | | Pro | $20 | $25 | なし | 20本 | | Business | $200 | $250 | 100%（クレジット） | 100本 | | Enterprise | 個別見積もり | 100%（クレジット） | 1,000本 | | 価格は米ドル建てで、日本語ページでも円建て表記はありません（改定があるため最新額は公式のプランページで確認してください）。プラン表では、障害時のクレジット倍率がBusinessの1倍に対し、Enterprise（表記はContract）は契約内容に応じて10倍または25倍と差が付けられています。無料プランで足りるのは、DDoS防御・CDN・DNS・証明書という基礎部分です。上位機能はきれいに切り分けられており、Polishによる画像データ容量の削減はPro以上（画像変換はImages Freeでも月5,000件のユニーク変換まで使えます）、セカンダリDNSはEnterprise限定です。 ## サイト導入時の手順と、平文通信やメール不達などの事故が起きやすい設定 設定作業の所要時間は、DNSレコード数、既存のDNSSEC設定、オリジン証明書の準備状況によって変わります。APIと`dig`で各段階を確かめながら進める詳しい手順は[Cloudflareにドメインを追加する手順：ネームサーバー変更とDNS移行をAPIとdigで確かめる【2026年9月版】](/tech/details/17915/)にまとめています。 1. Cloudflareにアカウントを作り、対象ドメインを登録する。 2. 既存のDNSレコードが自動で読み込まれるので、**漏れがないか必ず突き合わせる**（メール関連のMX・TXTの取りこぼしが、メール不達の典型原因です）。 3. 既存のDNSSECが有効なら、標準的な移行手順では登録事業者側のDSレコードを解除し、その反映を確認してからネームサーバーをCloudflareの指定値に変更する。移行後はCloudflare側でDNSSECを有効にし、新しいDSレコードを登録する。切替時間は登録事業者の処理とDNSキャッシュに左右される。 4. SSL/TLSの暗号化モードを**「フル（厳密）」**に設定する。オリジンに有効な証明書が無い場合は、Cloudflareが発行するオリジン証明書を入れてから切り替える。 導入時には、上の4番目のSSL/TLS設定とキャッシュ設定を確認してください。フレキシブルのまま放置すればサーバーとの間が平文になり、キャッシュルールを雑に広げればログイン後の画面が他人に配信される。**導入直後に確認すべきは速度ではなく、この2点**です。「自社サイトの危険な設定をdigとcurlとCloudflare APIで点検する手順」のコマンドで、導入後のSSLモード、キャッシュ状態、オリジンへの直接接続を確認してください。なお、サーバーのポートを開けずに公開したい場合は、DNS切り替えとは別に[Cloudflare Tunnelとは？料金は無料か・仕組み・安全性とcloudflaredの設定手順](/tech/details/8634/)の構成が使えます。外部にポートを開けずに済むぶん攻撃面は狭くなりますが、経路がCloudflareに一本化されるため、前述の集中リスクは一段深くなります。 ## SEOへの影響：高速化のプラスとボット判定によるクローラ遮断のマイナス プラス側は表示速度です。キャッシュ配信でTTFBが短縮されれば、LCPの改善につながる場合があります。TTFB自体やHTTPSの自動化はCore Web Vitalsの評価項目ではないため、導入前後の実測値で効果を確認してください。ネームサーバー切替時の反映遅延も、DNSは古い設定でも並行して解決されるため、正しく設定していればサイトが検索から消えることはありません。 マイナス側で現実的なのは**ボット判定によるクローラーの遮断**です。Under Attackモードやカスタムルールで広い範囲にチャレンジ・ブロックを適用すると、Googlebotを含む検索エンジンやSEOツールのクローラーがチャレンジ画面に当たり、クロールできなくなります。順位が落ちたときは、まずCloudflareのセキュリティイベントログで自社サイトへのクローラーがブロックされていないかを確認してください。ボットスコアの仕組みと、通したい相手を許可するルールの書き方は[Cloudflare Adaptive Intelligenceとは：ボットスコア再学習の仕組みとAIエージェントを通すルール設定例](/tech/details/18231/)で扱っています。 ### 「共有IPだとSEOが下がる」という説の根拠が薄いと言える理由 Cloudflare否定論としてよく見かけるのが、「スパムサイトとIPを共有するとブラックリスト入りして順位が落ちる」というものです。しかしGoogleは、同一IPに多数のサイトが同居する共有ホスティングを長年前提としており、[Googleの公式ブログ](https://developers.google.com/search/blog/2024/12/crawling-december-cdns)では、メインホストをCDNで配信する構成もGoogleのクロール基盤で扱えると説明しています。順位が落ちた原因を探す際は、確認可能な要因として、前段のクローラー遮断を調べてください。 ## Cloudflareのメリットとデメリット：費用対効果と引き換えに負う4つの制約 ### メリット：無料プランに付く帯域無制限のDDoS防御と証明書の自動更新 危険性を並べてきましたが、Cloudflareが世界のWebの4分の1前後に使われているのには理由があります。メリットは費用対効果に集約されます。無料プランでも**帯域無制限（unmetered）のDDoS防御**が付き、証明書は自動更新され、キャッシュでオリジンの転送量と負荷が下がる。自前構築と比較する際は、サービス料金に加え、運用担当者の工数と障害対策費用を含めて見積もってください。攻撃の種類と防御の考え方は[DDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策を解説](/column/details/13260/)で整理しています。 ### デメリット：可用性の委託・TLS終端・ボット判定の巻き添え・WordPressのキャッシュ設定 デメリットは4つあり、重さには差があります。 - **可用性がCloudflareに握られる**：最も重い。Free／ProにアップタイムSLAが無いことは前述の契約面の章のとおりで、冗長化まで含めた費用で他CDNと比べてください。 - **TLS終端という構造**：第三者に平文を通過させられない要件があるなら、理由2のとおりこの時点で要件を満たしません。 - ボット判定の巻き添え：APIクライアントやパートナーのクローラーが403やチャレンジで弾かれることがあり、許可リストの運用コストがかかります。 - WordPressでHTMLまでキャッシュするときの除外漏れ：公式の[Automatic Platform Optimization（APO）](https://developers.cloudflare.com/automatic-platform-optimization/about/)は、ログイン・セッション・WooCommerceのCookieが付いた要求や、checkoutなどの除外パスをキャッシュせず、`cf-cache-status: DYNAMIC`で返す設計です。事故の典型例は、自前のキャッシュルールでHTMLをキャッシュし、認証状態による除外を忘れるケースです。APOでも独自のCookieや追加ルールを使う場合は、既定の除外条件だけで十分かを確認してください。WordPress側の設定全体は[WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】](/tech/details/18610/)で扱っています。 ## Cloudflareを採用すべきサイトと見送るべきサイトを分ける判断の条件 判断を言い切ると次のとおりです。**採用してよいのは**、メディアやコーポレートサイトのように静的コンテンツの比率が高く、数分〜数十分の停止が致命傷にならないサイト、そして攻撃を受けやすいのに専任のインフラ担当がいない組織です。この場合は無料プランから始めてかまいませんが、SSLモード、キャッシュ除外、オリジンの接続制限を確認し、障害時の切替が許容停止時間内に完了することを訓練で確かめてください。**見送るか、冗長化込みで設計し直すべきなのは**、許容停止時間が単独構成の想定復旧時間を下回る決済・予約・業務システムと、第三者に平文を通過させられない契約・規制を抱えるシステムです。前者は権威DNSの多重化かマルチCDNを前提に費用を比べ、後者はリバースプロキシ型CDNそのものを候補から外します。 ## よくある質問 ### Cloudflare経由のページでブラウザに「危険なサイト」と表示されるのはなぜですか？ 警告の理由は、Googleのセーフブラウジングがそのページをフィッシングやマルウェアの配布と判定したことで、Cloudflareを経由していること自体ではありません。Cloudflareの無料のトンネルやホスティングは攻撃者にも使われるため、警告付きのページがCloudflare上にあるのは珍しくありません。閲覧者は入力やダウンロードをせずに離れてください。自分のサイトの場合は、Search Consoleのセキュリティの問題レポートで原因を確かめ、サイト全体を直してから審査をリクエストします。 ### Cloudflareの障害でサイトが落ちたら何をすればいいですか？ まずCloudflare Statusで障害が出ているかを確かめ、DNSレコードのプロキシをオフ（グレー雲）に切り替えると、Cloudflareを経由せずオリジンへ直接アクセスさせられます。ダッシュボードが重いときはAPIで切り替えます。ただしWAF・キャッシュ・L7 DDoS防御を同時に失い、オリジンIPも公開されます。オリジンにブラウザが信頼する公開CAの証明書があり、直接の接続を受け付ける設定で、直トラフィックに耐えられることが前提です。CloudflareのIPだけを許可する制限をかけている場合は、その解除手順も一緒に用意します。切替手順は平時に訓練しておいてください。 ### 1.1.1.1やWARPアプリを使うのは安全ですか？ サイト運営者としてCloudflareを使う話とは別に、端末の参照先を1.1.1.1に変える利用者も多くいます。Cloudflareは[公開リゾルバのプライバシー方針](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/)で、利用者の個人データを第三者に販売・共有せず広告にも使わないこと、通常の送信元IPアドレスは末尾を切り詰め、切り詰めたIPと通常のリゾルバログを25時間以内に削除するとしています。ただし、ネットワーク障害調査用のサンプルや集計生成用データには例外があります。同社はこれらの運用について、4大会計事務所の1社による監査報告も公開しています。端末の通信全体をCloudflare経由にするWARPアプリは、[公式のプライバシー説明](https://developers.cloudflare.com/warp-client/privacy/)で、集めるのはDNSクエリと通信量などの限られたデータで、通信の中身（ペイロード）は含まないとしています。ただし、どちらを使っても、問い合わせ先や通信の経路をCloudflareに預ける点は変わりません。 ### サイト閲覧時に出るCloudflareの人間確認画面は危険ですか？ Cloudflareのチャレンジ画面（人間であることの確認）は、そのサイトがCloudflareのボット対策を有効にしている印であり、マルウェアではありません。ただし、この画面を模したフィッシングや、偽の認証手順を踏ませてコマンドを実行させる手口が報告されています。**確認画面の指示としてWindowsのファイル名を指定して実行やターミナルへの貼り付けを求められたら、それは偽物**です。正規のチャレンジはブラウザ内で完結します。手口と検知の方法は[ClickFixとは？偽CAPTCHAでコマンドを実行させる手口と実装者向けの検知・防御【2026年時点】](/tech/details/13269/)で解説しています。 ### Cloudflareを使うとSEOに悪影響はありますか？ 高速化はプラスに働きます。悪影響が出るとすれば、セキュリティ設定を強くしすぎてクローラーがブロックされるケースです。「共有IPだとブラックリスト入りして順位が落ちる」という説には、Googleの公式見解や公開された検証による裏づけがありません。順位が落ちたら、セキュリティイベントログでクローラーの遮断が無いかを先に確認してください。 ## 関連記事 - [Cloudflareにドメインを追加する手順：ネームサーバー変更とDNS移行をAPIとdigで確かめる【2026年9月版】](/tech/details/17915/) - [Cloudflare Tunnelとは？料金は無料か・仕組み・安全性とcloudflaredの設定手順](/tech/details/8634/) - [ClickFixとは？偽CAPTCHAでコマンドを実行させる手口と実装者向けの検知・防御【2026年時点】](/tech/details/13269/) - [CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説](/tech/details/13095/) - [Cloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方](/tech/details/6760/) --- 出典: [Cloudflareの危険性は本当か：デメリット・障害・SLA・情報漏えいの実態と点検手順]()（株式会社一創）