Cloudflare のエッジ制御試験：すべてのルールを元に戻せるか

概要

Cloudflare の最強の製品主張は、プログラマブルなグローバル制御です。同社の自社ページによると、同社は平均で毎秒 1 億 200 万の HTTP リクエストを処理し、125 カ国以上、335 都市からデータを提供しており、ネットワークページでは、顧客トラフィックは最寄りのデータセンターで処理され、すべてのサービスがすべてのデータセンターで稼働しているとされています。このアーキテクチャは商業的に魅力的です。なぜなら、キャッシュポリシー、WAF ルール、Worker バージョン、Zero Trust ルール、ネットワーク保護設定によって、各オリジン環境の再構築を待つことなく、ユーザー近くの挙動を変更できるからです。この同じアーキテクチャが、変更の規律を信頼性の中核的な問題にしています。
証拠は、Cloudflare Inc を狭くしかし重要な視点で支持しています。それは単なる CDN でも、単なる WAF でも、単なるサーバーレスランタイムでもありません。トラフィックプロキシ、ルール、キャッシュ動作、ボットと WAF の判断、Workers、R2、Access、Tunnel、Logpush、ステータス操作、ロールバックのメカニズムを組み合わせたエッジオペレーティング面です。Cloudflare は、運用するエッジサービスとその文書化された制御を所有していますが、顧客のオリジン、顧客の Worker コード、顧客のルール式、顧客の DNS の選択、サードパーティのクラウド、サードパーティの ID プロバイダー、または Cloudflare を使用する各チームの内部リリースプロセスは所有していません。
最良の公開証拠は、有益な形で混在しています。Cloudflare は、Worker バージョン、段階的デプロイメント、ロールバック、メトリクス、Logpush、Ruleset Engine のバージョン、WAF ルール、キャッシュパージオプション、Access ポリシーロジック、公開ステータス API などの本格的な安全機構を文書化しています。また、2025 年に 2 つのインシデント後レポートを公開し、安全機構が安全性と同じではない理由を示しました。2025 年 11 月 18 日、Bot Management の機能ファイルエラーがネットワーク全体に伝播し、5xx エラーが広範囲で発生しました。2025 年 12 月 5 日、WAF 関連の変更が Cloudflare が処理する HTTP トラフィックの約 28%に約 25 分間影響を与えました。これらは Cloudflare を否定する理由ではなく、製品の実際の運用負荷を判断するための最も明確な公開テストケースです。
したがって、商業的な問題は、Cloudflare がエッジの変更を迅速に行えるかどうかではありません。できます。バイヤーの問題は、そのスピードがオリジン負荷、デプロイの摩擦、セキュリティツール、ネットワーク露出、開発者のオーバーヘッドを十分に削減し、ベンダー依存、ルールテスト、ログ、フェイルオーバー計画、ランタイム制限、移行作業、サポートの複雑さを正当化できるかどうかです。Cloudflare の 2025 年の Form 10-K では、33 万 2446 の有料顧客と、年間収益 10 万ドル以上の 4298 の顧客が報告され、2026 年第 1 四半期のリリースでは、四半期収益が 6 億 3980 万ドルに達したと発表されました。これらの数字は需要を証明していますが、バイヤーが偽陽性の抑制、一貫した伝播、完全なログ、復旧計画を持っていることを証明するものではありません。

製品は制御であり、単なる配信ではない

Cloudflare は当初、ウェブサイトをより高速で安全にする手段として市場に登場しましたが、現代の Cloudflare 製品は、グローバルに分散した制御プレーンとして捉えられています。同社は、SASE、アプリケーションセキュリティ、アプリケーションデリバリ、ネットワークサービス、フルスタック開発が同じグローバルインフラストラクチャを共有するプラットフォームを説明しています。同社のCloudflare についてのページでは、任意のコードプッシュが自動的に数百万のインターネットプロパティに影響を及ぼし、125 カ国以上 335 都市から平均して毎秒 1 億 200 万の HTTP リクエストを処理していると述べられています。また、グローバルネットワークのページでは、すべてのサービスがすべてのデータセンターで稼働し、顧客トラフィックは発信元の近くで処理され、サービスプロバイダー、クラウドプロバイダー、エンタープライズネットワーク間で 1 万 3000 以上の相互接続があると述べられています。

これが運用上のテーゼです。すべてのサービスがどこでも利用可能であれば、同じインフラストラクチャでアセットのキャッシュ、攻撃のフィルタリング、アクセスポリシーの施行、トラフィックのルーティング、Workers コードの実行、ログのプッシュが可能になります。顧客は、複数の地域アプライアンスではなく、1 つのダッシュボードと API ファミリーを利用できます。ルールは 1 回の変更で複数の場所に施行され、Worker は顧客がリージョンを管理することなくエッジにデプロイでき、CDN の変更はオリジンを移動することなくオリジントラフィックを削減でき、Zero Trust ポリシーは Cloudflare Tunnel を中心にアーキテクチャを構築すればパブリック IP を公開することなくアプリケーションを保護できます。

これが、Cloudflare の価値提案が狭いホスティングプロバイダーとは異なる理由です。この製品は、アプリケーションの前に意思決定層を形成します。一部の決定は単純です：このオブジェクトをキャッシュし、このリクエストを通過させ、この IP 範囲をブロックし、この ID グループを要求する。他は確率的または文脈的です：ボットスコアを割り当て、管理対象 WAF ルールを評価し、リクエストにチャレンジを発行し、セキュアアクセスパスを通じてトラフィックを送信する。さらに開発者の決定もあります：この Worker バージョンを実行し、この KV 名前空間をバインドし、この R2 オブジェクトを読み取り、このダウンストリームサービスを呼び出す。

この区別は重要です。なぜなら、リスクはダウンタイムだけではないからです。誤ったエッジの決定は、明らかな停止になる前に、静かなビジネス上の害を生み出す可能性があります。実際の顧客をブロックしたり、古いコンテンツを漏洩させたり、セキュリティ制御を迂回したり、過負荷のオリジンにトラフィックを送信したり、Worker が制限を超えた場合にフェイルオープンしたり、可用性がより重要な場合にフェイルクローズしたり、まさにオペレーターが必要とする瞬間にログを不完全にしたりする可能性があります。Cloudflare を購入する企業は、意思決定を Cloudflare のエッジに移す権利を購入しています。また、それらの決定の正確性が共有責任になることを受け入れているのです。

Cloudflare Inc が所有するものと所有しないもの

Cloudflare Inc の境界は重要です。なぜなら、Cloudflare は多くの障害事例で出現しますが、それは経路の一部に過ぎないからです。あるサイトは Cloudflare DNS を使用しながら、アプリケーションを他の場所でホストしているかもしれません。顧客は欠陥のある Worker を書いてしまうかもしれません。オリジンはキャッシュ動作を驚かせるような不正なヘッダーを返すかもしれません。サードパーティの ID プロバイダーが Access ポリシーを使用不能にするかもしれません。クラウドプロバイダーが Cloudflare プロキシの背後で障害を起こすかもしれません。レジストラのレコードが誤って設定されるかもしれません。顧客は正規の購入者をブロックする WAF 式を書いてしまうかもしれません。

同社は、運用する Cloudflare サービス、文書化された制御面、デプロイするエッジソフトウェア、提供するステータスおよびサポートチャネル、公開する製品制限を所有していますが、インターネット経路全体を所有しているわけではありません。したがって、本記事は、Cloudflare が運用する接続性、セキュリティ、開発者向け制御の信頼性と経済性についてのものであり、たまたま Cloudflare を使用しているサイトやその背後にあるすべての顧客システムについてのものではありません。

Cloudflare の提出書類は、商業的な境界を補強しています。同社の2025 年 Form 10-Kでは、収益は主にネットワークと製品へのアクセスに対するサブスクリプションとサポートサービスから得られ、顧客にはネットワークを実行するソフトウェアの所有ではなく、Cloudflare のネットワークと製品への継続的なアクセスが付与されると述べられています。これはサービス契約であり、インフラ所有権の移転ではありません。同じ提出書類では、顧客維持と拡大は、Cloudflare の製品とグローバルネットワークのセキュリティ、パフォーマンス、信頼性に対する満足度に依存していると述べられています。

これが、Cloudflare の大規模顧客の成長が両刃の剣である理由でもあります。2025 年の提出書類では、年末時点で 33 万 2446 の有料顧客と、年間収益 10 万ドル以上の 4298 の顧客が報告されました。大規模顧客はプラットフォームの検証ですが、同提出書類では、大規模顧客はより複雑な構成、統合、デプロイメント、移行支援、サポート義務、ネットワークインフラ支出を必要とする可能性があるとも述べられています。言い換えれば、Cloudflare がエンタープライズ制御の販売に成功すればするほど、製品は単純なページスピードマーケティングではなく、厄介な変更管理によって評価されるようになるのです。

2026 年第 1 四半期も同じ緊張関係を示しています。Cloudflare の2026 年第 1 四半期決算では、収益が 6 億 3980 万ドルで前年比 34%増、非 GAAP 営業利益が 7310 万ドル、フリーキャッシュフローが 8410 万ドルと報告されました。これはバンドルに対する強い需要を示していますが、特定の顧客が WAF、CDN、Workers、R2、Access、ネットワーク保護を 1 つのベンダーの背後に置くべきかどうかを決定するものではありません。多くの顧客がその可能性に対して喜んで支払う意思があることを示しているに過ぎません。

ルールこそがスピードがリスクに変わる場所

Cloudflare のルール機構は、プラットフォームの中核です。Ruleset Engine のドキュメントでは、ルールセットを Cloudflare のグローバルネットワーク上のトラフィックに適用される順序付けられたルールのセットと定義しています。ルールセットはフェーズに属し、バージョン管理されており、各変更により新しいバージョンが作成されます。フェーズリストは、ルール実行が 1 つの一般的なアクションではないことを示しています。ネットワーク層フェーズ、Magic Transit フェーズ、リクエストフェーズ、製品固有のフェーズが定義された順序で実行されます。価値は、異なるセキュリティとトラフィックの決定をリクエストパスの適切な部分に配置できることです。コストは、順序、範囲、フェーズの選択が重要であることです。

WAF カスタムルールがこの点を明確に示しています。Cloudflare のカスタムルールのドキュメントでは、カスタム WAF ルールが式とアクションを使用してゾーンへの着信トラフィックをフィルタリングすると述べられています。アクションは、ブロック、チャレンジ、1 つ以上のセキュリティ機能のスキップ、またはその他の製品固有の作業を行うことができます。ルールは順序に従って評価され、ブロックアクションによって後続のルールの実行を停止できます。API ドキュメントでは、ゾーンレベルのカスタムルールをhttp_request_firewall_customフェーズのエントリポイントルールセットにデプロイする必要があり、更新と削除には正しいルールセットとルール ID が必要であると付け加えています。

その設計は、まさに容赦がないために強力です。狭いルールは、リクエストがオリジンに到達する前に攻撃露出を減らすことができます。広範なルールは、購入者、パートナー、クローラー、API をブロックする可能性があります。スキップルールは、あるパスでの誤検出を修正しながら、別のパスで意図せずに制御を迂回する可能性があります。ルール順序の誤りは、後の保護を無効にする可能性があります。管理されたルールの上書きは、ゼロから書くよりも安全かもしれませんが、それでも顧客はトラフィック、例外、ビジネスへの影響を理解する必要があります。

Cloudflare のWAF 製品ページでは、その WAF が管理ルールとカスタムルールを使用してエッジで HTTP/S リクエストを検査し、管理ルールは新しい脆弱性に対して迅速に保護できると主張しています。これは、フレームワークやライブラリの脆弱性がアプリケーションチームがパッチを適用する前に公開された場合に大きな利点です。しかし、迅速な仮想パッチ適用に関するベンダーの主張の証拠基準と、それを強制するバイヤーの決定の証拠基準は異なるはずです。問題は、"Cloudflare がルールを作成してデプロイできるか"だけではなく、"このルールは、実際のトラフィック、ログインフロー、チェックアウトパス、API クライアント、モバイルアプリ、パートナー統合に対して正しく動作するか"ということです。

ここで、監視コストが経済性に入り込みます。セキュリティの自動化は、盲目的に信頼されると最も安価ですが、注意深く監視されると最も価値があります。Cloudflare ルールを設定したら忘れる保護として扱うバイヤーは、テストトラフィック、許可リスト、アラート、例外処理、ロールバックへの投資を怠る可能性があります。本番に似たトラフィック、段階的なアクション、ログ、所有権をもってすべてのルールを監視するバイヤーは、リスクを減らすことができますが、より多くのエンジニアリング時間を費やします。商業的なケースは、Cloudflare がその監視を賄うのに十分な重複するセキュリティ作業を削減するかどうかにかかっています。

Workers はエッジ変更をソフトウェアリリースにする

Workers は、Cloudflare をトラフィック制御ベンダーからソフトウェアランタイムへと変化させます。Cloudflare Developer Docsは、Workers と関連プリミティブを、Cloudflare のグローバルネットワーク上でサーバーレス関数とフルスタックアプリケーションを構築およびデプロイする手段として位置付けています。Workers 製品ページでは、チームは 330 以上の都市にデプロイし、変更をユーザーの割合に対して徐々に展開し、エラーが急増した場合にロールバックできると述べています。これはまさにエンタープライズプラットフォームチームが望む約束です。リージョンサーバーフリートを管理することなくグローバルリーチを実現することです。

詳細な Workers ドキュメントは、マーケティング上の主張よりも有用です。なぜなら、運用上の契約を明らかにするからです。バージョンとデプロイメントでは、コードや構成の変更ごとにバージョンが作成されると述べられています。デプロイメントは、どのバージョンがアクティブにトラフィックを処理するかを決定します。1 つのバージョンが 100%か、段階的デプロイ中は 2 つのバージョンです。デフォルトでは、wrangler deployはバージョンを作成し、単一のステップで直ちにすべてのトラフィックにデプロイしますが、バージョンのアップロードとデプロイメントを分離することもできます。

このデフォルトは重要です。高速なグローバルデプロイは、変更が安全な場合には良いことですが、変更が間違っている場合には危険です。Cloudflare の回答は段階的デプロイメントです。段階的デプロイメントのドキュメントでは、トラフィックをバージョン間で分割し、エラー率と例外を監視し、問題が発生した場合には安定バージョンを復元できると述べられています。これは制御の正しい形です。バイヤーは、すべての実トラフィックではなく、一部の実トラフィックに対してリリースをテストできます。

ロールバックも文書化されていますが、魔法ではありません。Workers ロールバックでは、ロールバックは以前のバージョンを選択した新しいデプロイメントを作成し、ルートとドメイン全体でアクティブにすると述べられています。また、ロールバック中に接続されたリソースは変更されず、Durable エンティティの移行が発生した場合や、ターゲットバージョンが存在しなくなった R2 バケット、KV 名前空間、キューに依存する場合にロールバックがブロックされる可能性があると述べられています。この制限は欠陥ではなく、状態の現実です。コードのロールバックはデータのロールバックに比べて簡単です。ロジックのみを変更した Worker は、たいてい戻ることができます。バインディング、移行、オブジェクトセマンティクスを変更した Worker は、そうでないかもしれません。

Cloudflare の制限ページは、もう 1 つのデプロイメントの質問を追加します。Workers の制限では、Workers には一般的なリクエスト/秒の制限はありませんが、無料プランには毎日のリクエスト制限があり、サブリクエスト制限が存在し、ルートの動作はフェイルオープンまたはフェイルクローズに構成できると述べられています。その選択はアーキテクチャ上のものです。セキュリティ上重要な Worker はフェイルクローズ動作が必要かもしれません。ユーザー向けのパーソナライゼーション Worker はフェイルオープン動作を好むかもしれません。間違った選択は、障害モードを段階的な劣化から露出または停止に変えてしまいます。

正直な結論は、Workers はデプロイ時間を短縮できますが、リリースエンジニアリングを排除することはできないということです。バイヤーは依然としてテストスイート、バージョンタグ、所有者レビュー、段階的ロールアウトポリシー、ログ保持、アラートしきい値、バインディング規律、状態変更の計画が必要です。利点は、Cloudflare がグローバルなリリース面を提供することです。負担は、顧客のコードがエッジの一部になることです。

キャッシュの正確性はビジネス上の決定

CDN 層は Cloudflare の最も馴染み深い部分ですが、過度に単純化されやすい部分でもあります。Cloudflare のCDN 製品ページでは、CDN は 335 以上の都市で静的および動的コンテンツをキャッシュし、エッジから配信して配信を高速化し、オリジンサーバーからのトラフィックを吸収すると述べられています。これは、より少ないオリジンリクエスト、低遅延、トラフィックスパイク時のより高い回復力という、直接的な経済的価値です。

難しいのは正確性です。デフォルトキャッシュ動作のドキュメントでは、Cloudflare はCache-Controlが private、no-store、no-cache、max-age=0 の場合、Set-Cookie ヘッダーが存在する場合、またはリクエストメソッドが GET でない場合にリソースをキャッシュしないと述べられています。また、Cloudflare は特定のファイル拡張子をデフォルトでキャッシュし、HTML や JSON はデフォルトではキャッシュせず、単一のデータセンターで同じアセットに対する同時キャッシュミスが重複するオリジンフェッチを生じないようにリクエストの折りたたみを使用すると述べられています。これらは賢明なデフォルトですが、デフォルトは完全なポリシーではありません。

Cloudflare のキャッシュルールを使用すると、キャッシュの対象、保持期間、キャッシュ動作が適用される場所をカスタマイズできます。これは、アプリケーションに予測可能な静的ページ、画像アセット、API レスポンス、バージョン管理されたファイルがある場合に価値があります。ただし、ルールがパーソナライズされたコンテンツや認証依存のコンテンツをキャッシュ可能と扱うと危険です。エッジは正しいアセットをどこでも高速にできますが、間違ったレスポンスを多くの場所で永続化させることもできます。

パージ動作は、キャッシュ正確性の回復側面です。Cloudflare のキャッシュパージのドキュメントでは、インスタントパージと複数のパージスコープが説明されており、単一ファイルのパージが推奨されています。全パージのページでは、すべてをパージすると全データセンターのリソースがクリアされ、新しいリクエストがオリジンに戻るため、高トラフィックサイトではオリジン負荷が大幅に増加し、パフォーマンスが低下する可能性があると警告しています。

この警告は商業的な手がかりです。CDN の価値は低遅延だけではなく、オリジンストレスの低減です。不注意なパージは、CDN が吸収すべきオリジン負荷を一時的に戻す可能性があります。慎重なパージポリシーは、すべてのユーザーをオリジンリクエストにすることなく、悪いコンテンツを削除できます。したがって、バイヤーのエッジ制御の質問は、"Cloudflare はパージをサポートしていますか"ではなく、"リリースチームとインシデントチームが迅速に最小の安全なパージスコープを選択でき、広く選択しすぎた場合にオリジンに何が起こるかを把握しているか"ということです。

観測可能性はアドオンではなく、製品の一部

Cloudflare の制御プレーンは、オペレーターが何が変わったかを確認できる能力だけが有用です。ボットをブロックする WAF ルールとバイヤーをブロックする WAF ルールは、ダッシュボードメトリックが攻撃削減だけの場合、どちらも成功のように見えるかもしれません。1 つの地域や 1 つのバインディングパスでしか失敗しない Worker は、集計では見えないかもしれません。オリジン負荷を節約しながら古いコンテンツを提供するキャッシュルールは、顧客が苦情を言うまで効率的に見えるかもしれません。

Cloudflare はいくつかの観測ルートを文書化しています。Workers メトリクスと分析では、Workers メトリクスとゾーンベースの分析がトラフィック、リクエストの成功とエラーメトリクス、呼び出しステータスを示すことができると述べられています。Logpushは、ログをストレージ、SIEM、ログ管理プロバイダーに送信できます。Cloudflare のLogpush ヘルスダッシュボードは、ジョブステータスを監視し、エラーを診断できますが、同じページで重要な制限が指摘されています：データがドロップされると、Logpush はバックフィルできません。

この 1 つの制限がリスクモデルを変えます。ログは単にインシデント後のフォレンジックレコードではありません。ログは、ルールが安全かどうか、カナリア展開を拡大できるかどうか、ロールバックが機能したかどうか、顧客が誤ってブロックされたかどうかを判断するための証拠です。高圧の変更中にログエクスポートが失敗すると、チームは証拠なしで待つか、自信なしで行動するかの選択を迫られるかもしれません。ヘルス通知とダッシュボードは役立ちますが、監視する別のシステムを追加します。

価格と保持期間も運用を形作ります。Cloudflare のWorkers 料金ドキュメントでは、Workers ログは無料プランと有料プランに含まれており、イベントと保持の制限がありますが、Workers トレースイベント Logpush は有料で、フィルタリングまたはサンプリング後に宛先に到達したリクエストログに対して課金されると述べられています。これは製品が弱いわけではありません。バイヤーが観測可能性をアーキテクチャの予算項目として扱うべきであり、無料の副産物として扱うべきではないことを意味します。十分に完全なログのコストは、エッジ自動化を責任を持って使用する真のコストの一部かもしれないのです。

エンタープライズバイヤーにとって、実践的なテストは簡単です。重要なロジックを Cloudflare に移行する前に、誤った決定を覆すためにどのログが必要かを決定します。WAF チームは、ルール ID、アクション、一致式、IP レピュテーションコンテキスト、ボットスコア、パス、ホスト、ユーザー影響が必要かもしれません。Workers チームは、バージョン ID、例外率、サブリクエスト障害、バインディングエラーが必要かもしれません。キャッシュチームは、ヒットステータス、オリジンステータス、パージイベント、ヘッダーが必要かもしれません。これらのフィールドが利用可能でなく、保持され、インシデントワークフローに接続されていない場合、エッジには速度がありますが、十分な説明責任がありません。

Cloudflare One は同じパターンをアクセスに拡張

Cloudflare One は、エッジ制御モデルをエンタープライズアクセスとネットワーキングに適用します。Cloudflare One ドキュメントでは、Access、Tunnel、Secure Web Gateway、Browser Isolation、CASB、DLP、Email Security、Digital Experience Monitoring を含む SASE プラットフォームが説明されています。Access はユーザーを認証し、すべてのイベントとリクエストをログに記録します。Tunnel は、顧客インフラストラクチャからの外向き接続を介して、パブリック IP を公開することなくリソースを Cloudflare に接続します。

技術的な魅力は CDN や WAF と同じです。ポリシー適用を分散プロバイダーに移行し、レガシーアプライアンスの必要性を減らします。リスクも同じです。ポリシーの正確性が運用上の規律になるということです。Access ポリシーのドキュメントでは、Include ルールは OR のように機能し、Exclude は NOT、Require は AND のように機能すると述べられています。すべての Access ポリシーには少なくとも 1 つの Include ルールが必要で、Require ルールは範囲を狭めます。そのロジックは明確ですが、実際の組織は明確ではありません。請負業者、サービスアカウント、緊急管理者、合併、期限切れのデバイス、サードパーティの ID、モデル化が難しい例外が存在します。

Access は製品の相互作用にも依存します。同じポリシードキュメントでは、バイパスポリシーにデバイスポスチャチェックが含まれ、保護対象ゾーンで Zaraz が有効になっているか、Worker がリクエストをインターセプトする場合にバイパスポリシーの非互換性が指摘されています。推奨される回避策は、ポリシーアクションを Service Auth に変更することです。これはまさに、Zero Trust の展開が成熟しているかどうかを決定する詳細です。問題は非互換性が存在することではありません。問題は、顧客がどの製品が相互作用するか、誰が例外を所有するか、後のエッジ変更後に例外がどのようにテストされるかを知るためのガバナンスを持っているかどうかです。

Cloudflare One はアプライアンスの乱立を減らし、アクセスをよりインターネットネイティブにすることができます。また、ID 統合、クライアントヘルス、トンネル可用性、ポリシー順序、ログ、Cloudflare のダッシュボード/API という新たな依存関係を生み出すこともあります。Cloudflare One を VPN アプライアンスと比較するバイヤーは、機能だけを比較すべきではありません。障害モードを比較すべきです。Access が利用できない場合、何がまだ機能しますか？ID プロバイダーが劣化した場合、誰が非常用経路に到達できますか？Access 評価の前に Worker がリクエストを変更する場合、その相互作用はレビューされていますか？これらの質問が、統合がリスクを減らすのか、それともリスクをより洗練させるだけなのかを決定します。

Magic Transit は同じ賭けのネットワーク版を示す

Magic Transit は、Cloudflare の役割をアプリケーションプロキシからネットワーク保護へと拡大します。Magic Transit ドキュメントでは、オンプレミス、クラウドホスト、ハイブリッドネットワーク全体での DDoS 保護とトラフィック加速のためのエンタープライズサービスが説明されています。Cloudflare のグローバルネットワークを使用して攻撃を発信元の近くで取り込み、緩和し、ヘルスチェック、トラフィックステアリング、Cloudflare 所有 IP、ベータ版の BGP ピアリングが含まれます。リファレンスアーキテクチャでは、Magic Transit はインターネットに面したネットワークインフラストラクチャ向けの BGP ベースの保護であり、Cloudflare は数百 Tbps の緩和容量と、グローバル平均 3 秒未満の緩和時間を持っていると述べられています。

ネットワークの経済性は魅力的です。攻撃中にトラフィックを Cloudflare 経由で誘導できれば、最悪のトラフィックを吸収するのに十分なローカル容量を購入して運用することを回避できるかもしれません。Cloudflare が発信元の近くで緩和できれば、集中型スクラビングと比較して遅延と可用性が改善される可能性があります。ヘルスチェックとトラフィックステアリングが適切に構成されていれば、顧客は 1 つのサービスでクラウドと物理インフラストラクチャの両方を保護できます。

しかし、Magic Transit は回線に貼るシールではありません。BGP アナウンス、プレフィックス、トンネル、トラフィックステアリングの優先度、ヘルスチェック、ルーティングポリシー、ファイアウォールの期待、内部ランブックに影響します。バイヤーは、どのプレフィックスが保護されているか、非対称ルーティングがどのように処理されるか、オンデマンドモードと常時モードの違い、誤ったアナウンスが発生した場合の対処、インシデント中にルート優先度を変更する権限が誰にあるかを知る必要があります。公開されているリファレンスアーキテクチャは製品の高レベルの主張を裏付けていますが、特定の顧客のネットワークチームが製品を安全に実装していることを証明するものではありません。

これが Cloudflare のより広範なパターンです。同社は、社内で再現するには高コストなグローバル分散制御面を顧客に提供できます。しかし、その制御面がルーティング、セキュリティ、ID に及ぶと、顧客の運用成熟度が製品成果の一部になります。Cloudflare はネットワークを運用できますが、すべての顧客のルーティング意図を正しくすることはできません。

R2 はストレージ経済を変えるが、データ責任は変わらない

R2 は、Cloudflare がそのエッジポジションを利用してコスト問題に挑むもう 1 つの例です。R2 製品ページでは、エグレス料金が不要で、Workers 統合があり、既存のオブジェクトストレージから段階的に移行できる S3 互換オブジェクトストレージが説明されています。R2 料金ドキュメントでは、R2 はストレージに加えてクラス A およびクラス B オペレーションに対して課金し、どのストレージクラスにもエグレス帯域幅料金はなく、低頻度アクセスストレージには取得および最小期間ルールが適用されると述べられています。

開発者チームにとって、魅力は明らかです。エグレス料金はクラウドストレージの予測を困難にします。S3 互換 API は移行の摩擦を減らします。Workers 統合は、コンピュートとストレージ間で認証情報を管理する必要性を減らします。顧客はログ、メディア、モデルアーティファクト、アプリケーションオブジェクトを Cloudflare のランタイム近くに配置し、クロススクラウド転送の苦痛をある程度回避できます。

危険なのは、"エグレス料金無料"が"ストレージ経済性なし"のように聞こえかねないことです。それは真実ではありません。オペレーションは課金対象です。低頻度アクセスの取得にはコストがかかります。移行ツールはオペレーション料金を生み出す可能性があります。データガバナンス、ライフサイクルポリシー、バックアップ、暗号化、アクセス制御、一貫性の期待は引き続き顧客の責任です。アプリケーションがハイパースケーラーのストレージサービスから R2 に移行すると、チームは転送コストを削減できますが、Cloudflare の開発者プラットフォーム、API 動作、サポートパス、観測可能性への依存を高めます。

R2 が商業的に重要なのは、Cloudflare をより強力なアプリケーションプラットフォームにするからであり、ストレージ単独でエッジ制御テーゼを証明するからではありません。記事の核心的な問いに対する R2 の関連性は状態です。Workers ロールバックドキュメントは、ロールバック中に接続されたリソースは変更されないと警告しています。Worker と R2 バケットが共に進化する場合、コードロールバックは以前のデータ契約を復元しないかもしれません。ランタイムがコードデプロイを即時に感じさせる場合でも、チームには移行の規律が必要です。

2025 年 11 月の停止は最も有用な公開テスト

Cloudflare の 2025 年 11 月 18 日のインシデントは、エッジ制御リスクの最も明確な公開例です。インシデント後レポートで、Cloudflare はネットワークが 11:20 UTC に重大な障害を起こし始めたと述べました。問題は攻撃ではありませんでした。データベース権限の変更が原因で、クエリが Bot Management の重複機能行を返したことが引き金となりました。機能ファイルが予想以上に大きくなり、ネットワーク内のマシンに伝播し、プロキシモジュールの制限を超えて障害を引き起こしました。コアトラフィックは 14:30 までにほぼ正常に戻り、17:06 にはすべてのシステムが正常に機能していました。

いくつかの詳細がヘッドライン以上に重要です。第一に、障害は日常的な内部変更であり、新しいインターネットの大惨事ではありませんでした。第二に、不良ファイルは 5 分ごとに生成されたため、良好なファイルと不良ファイルが交互に現れ、ネットワークは回復しては再び失敗しているように見えたかもしれません。第三に、初期症状は誤解を招くほどであり、Cloudflare は当初、超大規模な DDoS を疑いました。第四に、顧客への影響は製品構成に依存していました。Cloudflare は、ルールでボットスコアを使用している一部の顧客は誤検出を経験しただろうが、そうしたルールを使用していない顧客は同じ影響を受けなかったと述べています。

復旧のストーリーも関連性があります。Cloudflare は不良機能ファイルの生成と伝播を停止し、既知の正常なファイルを配布キューに挿入し、システムの一部を再起動し、時間をかけてサービスを復旧しました。タイムラインによると、自動テストが問題を検出したのは 11:31、インシデントコールは 11:35、Bot Management ロールバックに作業が集中したのは 13:37、自動デプロイが停止したのは 14:24、修正されたファイルがグローバルにデプロイされたのは 14:30、すべてのダウンストリームサービスが復旧したのは 17:06 です。

これは単純な告発ではありません。Cloudflare は詳細な説明を公開し、具体的なトリガーを特定し、修正作業を説明しました。しかし、バイヤーにとっては厳しい教訓です。グローバル制御は、各変更経路に適切なゲートがない限り、グローバルな爆風範囲を意味します。セキュリティ製品が使用する機能ファイルがネットワーク全体の可用性問題になる可能性があります。無制限のメモリ使用を避けるための制限がクラッシュ条件になる可能性があります。顧客ルールで使用されるセキュリティスコアが誤検出メカニズムになる可能性があります。

Cisco ThousandEyes の独立分析は、外部の視点を追加します。ThousandEyes は、監視対象の Cloudflare 依存サービスで HTTP 500 エラーを観測し、ボット管理障害中のチャレンジコンポーネントの不在を診断し、一部の組織が Cloudflare AS 13335 から離れて DNS フェイルオーバーを実行するのを確認しました。そのフェイルオーバーは一部のサービスの到達可能性を回復しましたが、それはボット管理やエッジキャッシングなどの Cloudflare サービスを失うことも意味しました。これが顧客のトレードオフを一言で表したものです。Cloudflare をバイパスすればオリジン可用性を回復できますが、それはオリジンが Cloudflare 層なしで動作する準備ができている場合に限られます。

2025 年 12 月の停止がロールアウトの種類の重要性を示す

2025 年 12 月 5 日のインシデントはより短いものでしたが、同じポイントを鋭くしました。Cloudflare の12 月のレポートでは、ネットワークの一部が 08:47 UTC に重大な障害を起こし、09:12 UTC に復旧したと述べられています。Cloudflare は、同社が処理する全 HTTP トラフィックの約 28%が影響を受けたと述べました。トリガーは、重要な React Server Components の脆弱性の検出と緩和に関連する WAF ボディ解析の作業でした。

重要な詳細はロールアウトの形態です。Cloudflare によると、最初の変更であるバッファサイズの増加は、同社の段階的デプロイメントシステムを使用しました。そのロールアウト中に、内部の WAF テストツールが増加したバッファサイズをサポートしませんでした。2 番目の変更であるその内部テストツールの無効化は、段階的ロールアウトを実行せず、数秒でサーバーフリート全体に伝播するグローバル構成システムを使用しました。停止は、緊急の脆弱性から顧客を保護するアイデアから生じたのではありませんでした。1 つのアクションには段階的な安全策があり、もう 1 つにはなかった変更経路から生じたのです。

この区別は、バイヤーがすべての Cloudflare 制御を評価する方法に影響を与えるはずです。"Cloudflare は段階的ロールアウトをサポートしていますか"と尋ねるだけでは不十分です。本当の問題は、どの変更タイプがどのロールアウトメカニズムを使用するかです。Workers の段階的デプロイは文書化されています。ルールセットはバージョン管理されています。一部のグローバル構成システムは、異なる安全特性を持っているかもしれません。管理ルールの更新、顧客ルール、ボット機能、WAF 解析の変更、キャッシュ動作、内部テストツールが 1 つのロールアウトパスを共有しないかもしれません。

顧客にとって、これは変更の分類が重要であることを意味します。チームは自身の Worker を安全にカナリアテストできますが、プロバイダー側の管理ルールや構成変更には依然として露出しています。チームは自身の WAF カスタムルールをテストできますが、Cloudflare の管理ルールやプロキシモジュールに依存しています。これは Cloudflare に固有のものではありません。すべてのクラウドサービスにはプロバイダー側の変更リスクがあります。しかし、Cloudflare が顧客トラフィックの前に位置しているため、プロバイダー側の変更リスクがエンドユーザーに非常に迅速に見える可能性があります。

商業的な含意は微妙です。Cloudflare のスピードは、脆弱性に迅速に対応できるために価値があります。12 月のインシデントは、セキュリティプレッシャー下でのスピードが可用性リスクをもたらす可能性もあることを示しています。バイヤーは高速なエッジ緩和を拒否すべきではありません。プロバイダーの更新がどのように段階化されるか、顧客の例外がどのように表現されるか、管理ルールが変更されたときにログが何を示すか、Cloudflare が製品固有の影響をどれだけ迅速に伝達できるかを尋ねるべきです。

依存関係は統合の代価

Cloudflare の提案は、顧客がツールの乱立を減らそうとしているときに最も強力になります。Web チームは、別々の CDN、DNS、ボット管理、DDoS、WAF、オブジェクトストレージ、サーバーレスランタイム、アクセスプロキシ、ログエクスポーター、トラフィックステアリングベンダーを望まないかもしれません。セキュリティチームは、各地域のアプライアンスよりも 1 つのポリシー面を好むかもしれません。開発者プラットフォームチームは、クラウドコンピュート、CDN、オブジェクトストレージをスクラッチから組み立てるよりも、Workers、R2、Pages を好むかもしれません。

統合は合理的です。2025 年の 10-K の大規模顧客数と 2026 年第 1 四半期の収益成長は、市場がそれに支払っていることを示しています。WAF、Workers、R2 のページに掲載されているベンダー主催の顧客シグナルは、同じ需要を指しています：Carrefour が多くの E コマースサイトで Cloudflare WAF と Bot Management を使用していること、Intercom がコンセプトから本番までの Workers のスピードを称賛していること、Character.AI が R2 をマルチクラウドデータアーキテクチャの一部として説明していること。これらの例は選択された顧客シグナルとして扱うべきであり、普遍的な証明ではありませんが、バイヤーが Cloudflare に依頼している仕事を示しています。

代償は依存関係です。多くの制御を Cloudflare の背後に置く顧客は、統合作業を減らす一方で、Cloudflare のアカウント問題、ダッシュボード/API 問題、プロバイダーインシデント、課金変更、サポート遅延、製品固有の制限の結果を増大させます。また、脱出のコストも増加します。基本的な CDN から離れることは、WAF ルール、キャッシュルール、Worker ルート、R2 バケット、Access ポリシー、Tunnel、DNS レコード、ログ、Magic Transit ルーティングのスタックから離れるよりも簡単です。

これが、ロックインの議論がイデオロギー的ではなく運用上でなければならない理由です。Cloudflare は多くのオープンプロトコルと馴染みのあるインターフェースを使用しています。DNS は標準です。HTTP は標準です。R2 は S3 互換です。Workers は JavaScript と関連する Web ランタイム概念を使用します。しかし、運用上のロックインは、ベンダー周辺に成長するランブック、アラート、ダッシュボード、例外、アクセスポリシー、生産習慣から生じます。チームはコードやオブジェクトを移動できるかもしれませんが、それでも同じセキュリティとトラフィック動作を別の場所で再構築するのに数ヶ月必要かもしれません。

適切な比較は、Cloudflare と無料の比較ではありません。比較は、Cloudflare の統合制御プレーンと、ハイパースケーラー、CDN、セキュリティベンダー、ID スタック、観測チェーン全体で同等の制御を組み立て、テストし、運用するコストとの間です。小さなアプリケーションでは、個別のネイティブクラウドツールの方がシンプルかもしれません。多くのチームを持つグローバルな公共サービスやエンタープライズでは、Cloudflare が繰り返し作業を削減できます。バイヤーの責任は、依存関係を正直に価格設定することです。

真剣なバイヤーテストは日常の変更に注目する

Cloudflare は、壮絶な主張よりも日常の運用タスクによって評価されるべきです。重要な質問は、チームが害を及ぼさずに小さなエッジ変更をどれだけ頻繁に行えるかです。有用な概念実証は、合成の hello-world Worker や速度テストだけではありません。本番環境での通常の 1 ヶ月のように見える一連の代表的な変更です。

WAF とルールについては、バイヤーは段階的な施行をテストすべきです。可能な限りログ記録やチャレンジから始め、ブロックされたリクエストを既知の正当なフローと比較し、ルールの順序を確認し、スキップルールが意図以上に迂回しないことを確認し、広範な式には名前付き所有者を要求します。すべてのルールにはロールバックパスと存在理由が必要です。チームがルールが一致する理由を説明できないなら、おそらくルールが顧客をブロックした理由を説明できないでしょう。

Workers については、バイヤーはバージョン規律をテストすべきです。手動バージョンアップロード、段階的デプロイ、メトリクスレビュー、ロールバック、意図的なバインディング変更を伴う小さな実サービスをデプロイします。次に、エッジケースをテストします：欠落した KV 名前空間、Durable エンティティ移行、サブリクエスト制限、失敗したダウンストリームサービス、フェイルオープン対フェイルクローズのルート動作。目標は Cloudflare の障害を捕まえることではありません。目標は、どの障害がコードロールバックで回復可能で、どれがデータまたは構成の修復を必要とするかを学ぶことです。

キャッシュについては、バイヤーはヘッダー動作とパージ範囲をテストすべきです。静的アセット、パーソナライズされたページ、API レスポンス、エラーページを、本番サイトが使用するものと同じリリースプロセスで提供します。Set-Cookie と Cache-Control の動作がチームの想定と一致することを確認します。単一ファイルパージ、プレフィックスパージ、および不良キャッシュルール後のロールバックを練習します。インシデントが選択を強制する前に、広範なパージ後のオリジン負荷を見積もります。

観測可能性については、バイヤーはログをゴーライブ条件として扱うべきです。必要なフィールドが宛先に到達すること、Logpush ヘルス通知が運用に接続されていること、サンプリングが重大な障害を隠さないこと、保持期間がチームのインシデントレビューウィンドウをカバーすることを確認します。Logpush ドキュメントの、ドロップされたデータがバックフィルされないという警告は、サプライズではなくアーキテクチャレビューの一部であるべきです。

フェイルオーバーについては、バイヤーはバイパスが何を意味するかを決定すべきです。ThousandEyes は、11 月のインシデント中に一部の組織が Cloudflare からトラフィックを移動させるのを観測しました。これは、オリジンが直接負荷を処理でき、証明書とルーティングの準備ができており、セキュリティトレードオフを受け入れることができる場合にのみ有用です。図面だけに存在するバイパスは復旧計画ではありません。

評決は条件付き

Cloudflare Inc は、プログラマブルなグローバルエッジプラットフォームであるという信頼できる主張を持っています。公開ドキュメントは、ルール、キャッシュ動作、Workers バージョン、段階的デプロイ、ロールバック、ログ、Zero Trust ポリシー、ネットワーク保護のための成熟した制御面を示しています。財務的な証拠は、大規模かつ成長している顧客需要を示しています。インシデントの証拠は、その主張が実際の変更条件下でテストされなければならない理由を示しています。

強気ケースは、Cloudflare の制御の多くを一度に必要とするチームにとって最も有利です：深刻な攻撃露出を持つ公開 Web アプリケーション、グローバルなユーザーベース、オリジン負荷の圧力、Workers を使用できる開発者チーム、WAF とアクセスポリシーを統合するセキュリティチーム、Magic Transit を正当化できるネットワークチーム。これらの顧客にとって、Cloudflare は重複するインフラ作業を削減し、保護をユーザーに近づけることができます。

弱気ケースは、バイヤーが Cloudflare に運用規律を置き換えさせたい場合に最も強力です。プラットフォームは、不正確な WAF 式を正確にしたり、状態移行を可逆的にしたり、欠落したログを後で出現させたり、準備のできていないオリジンに直接フェイルオーバーを処理させたり、すべてのプロバイダー側の変更を無害にしたりすることはできません。Cloudflare はチームに強力なエッジレバーを提供できますが、すべてのチームがいつそれを引くべきかを知っていることを保証することはできません。

したがって、公正な評価は実用的です。Cloudflare は、より速いエッジデプロイ、より低いオリジン負荷、バンドルされたセキュリティ、グローバルルーティング、開発者の速度が、ルールテスト、ベンダー依存、観測可能性コスト、ランタイム制限、移行作業、停止露出、サポートの複雑さを上回る場合に価値があります。その最も難しいテストはネットワークの規模ではありません。それは、各日常のエッジ決定が、間違いがグローバルになる前に、正しく、可視化され、可逆的であるかどうかです。