Cloudflareの2026年BYOIP障害が突きつけた、プレフィックス状態管理の説明責任

要約

2026年2月20日、CloudflareのAddressing APIに対する変更が、顧客所有のBYOIPプレフィックスを意図せずインターネットから撤回させた。
Cloudflareによれば、変更停止までに約1,100プレフィックスが撤回された。これは攻撃、BGPハイジャック、オリジン検証の失敗、または実証された経路リークではない。
同社の冒頭説明は障害体験の開始を17時48分UTC、継続時間を6時間7分としている一方、詳細タイムラインは影響時間を17時56分から23時03分までとしている。両者には内部的な不一致があり、一つの時間区間へ合成すべきではない。
原因となった変更の取り消しは、新たな状態変更を止めたにすぎず、すでに削除・変更されたレコード、サービス結合、エッジ設定のすべてを元に戻したわけではなかった。
RIR登録、IRRオブジェクト、ROA、Letter of Agencyは広告権限を示すが、現在のBGP広告、サービス到達性、ルーターの実稼働状態を証明しない。
説明責任には、正確なドライラン、依存関係を理解した削除防止、限定された変更対象、代表性のあるカナリア、独立して実行できるロールバック、複数レイヤー間の照合が必要である。
顧客による再広告は有用な復旧経路になり得るが、事業者自身が担うべき全体照合や復旧責任の代替にはならない。

障害の境界と時間経過

本件は、2026年2月20日に発生したCloudflareのBring Your Own IP、すなわちBYOIPサービスの障害に限られる。過去に発生した同社の別の停止や、攻撃を起点とする事象とは切り分けなければならない。

Cloudflareの公開事後報告には、時間に関する二つの記述がある。冒頭の説明では、顧客が障害を体験し始めた時刻を17時48分UTCとし、継続時間を6時間7分としている。一方、詳細タイムラインでは、影響期間を17時56分から23時03分までとしている。この二つは算術的に一致しない。したがって「17時48分から23時03分までの6時間7分」といった一見整った表現に作り替えるのは不適切である。公開資料の内部に存在する差異として、そのまま残す必要がある。

障害の直接的な契機は、顧客所有IP空間を管理するAddressing APIへの変更だった。Cloudflareの説明では、クリーンアップを担うサブプロセスがレコードを誤った条件で扱い、利用中のプレフィックスまで撤回した。利用者によっては、アドレスに関する設定もエッジサーバーから失われた。

原因となった変更が止められるまでに、約1,100のBYOIPプレフィックスが撤回されたとCloudflareは報告している。約800プレフィックスは20時20分ごろまでに復元され、残る約300プレフィックスについては、データベースからの復旧、サービス結合の再構築、グローバルなマシン設定の展開など、追加の経路が必要になった。復旧作業は、詳細タイムライン上の23時03分まで続いたとされる。これらの数字と時刻はいずれもCloudflare自身の説明に基づくものであり、外部から独立して全件が確認されたことを意味しない。

重要なのは、変更の取り消しと状態の復元を同一視しないことだ。開始点となった変更を戻せば、それ以降の誤った処理は止められる。しかし、すでに削除されたレコード、失われたサービス結合、エッジへ展開された設定、撤回済みのBGP状態は、それぞれ別の復元操作を必要とする場合がある。本件では、この違いが復旧時間を左右した。

BYOIPが権限を到達性へ変えるまで

BYOIPは、顧客が所有するIPプレフィックスをクラウド事業者のネットワークから広告し、そのネットワーク上のサービスへトラフィックを引き込む仕組みである。しかし「顧客がそのアドレスを所有している」という一つの事実だけでは成立しない。

最初のレイヤーは、番号資源に対する権限である。RIRの登録は、どの組織にアドレス資源が割り当てられているかを示す。IRRのrouteオブジェクトは、経路とオリジンASの関係を運用上記録する。RPKIのROAは、特定のASが対象プレフィックスをオリジネートする権限を暗号学的に検証可能な形で表す。Letter of Agencyは、顧客がCloudflareに自らの空間を広告する権限を与えたことを記録する。

これらは重要な証拠だが、いずれも現在の広告状態そのものではない。有効なROAが存在しても、ルーターがUPDATEを送らなければ経路は広告されない。Letter of Agencyが有効でも、管理システム上のBGPプレフィックスがwithdrawnであれば、Cloudflareはその経路を引き付けない。RIR登録が正確でも、サービス結合が失われていれば、引き付けたトラフィックを正しい処理系へ渡せない。

次のレイヤーは、Cloudflareアカウントに登録されたプレフィックスと、必要に応じたアカウント間の委任である。プレフィックス委任では、親側のアカウントが管理権を保持しながら、別のアカウントがアドレス空間を利用できる場合がある。このとき、資源を利用できるアカウント、サービス結合を管理する主体、広告状態を変更できる主体が常に同一とは限らない。権限モデルを単純化して扱えば、正当な利用中レコードを不要なものと誤認する危険がある。

さらに、IPアドレスやプレフィックスをCDN、セキュリティ機能、Spectrum、Dedicated Egress、Magic Transitなどへ関連付けるサービス結合がある。アドレスマップも、特定のIPアドレスとプロキシ対象のDNS応答との対応を管理する。BGP経路が存在しても、この結合がなければ、到着したパケットをどのサービスとして処理すべきか決められない。

最後に、BGP広告の意図と実際の配備状態がある。管理画面やAPI上でadvertisedと表示されること、設定生成系が広告を意図していること、エッジルーターが実際に経路を送信していること、外部の隣接ネットワークや経路収集系がその経路を観測していることは、すべて別の証拠である。どれか一つが正しいだけでは、エンドツーエンドの到達性は証明できない。

撤回がサービス障害になる仕組み

BGPにおける経路撤回は、アプリケーション内部のエラーとは性質が違う。Cloudflareが顧客プレフィックスの広告を停止すると、インターネット上の他ネットワークは、その経路をCloudflareへ送る根拠を失う。代替経路が存在しなければ、利用者の接続はCloudflareのアプリケーションや顧客のオリジンサーバーへ届く前に失敗する。

その結果、外部からはタイムアウト、接続不能、到達性の消失として見える可能性がある。HTTPリクエストを受け取ってエラーコードを返す障害とは異なり、アプリケーションログに要求そのものが残らないこともあり得る。このため、アプリケーション監視だけでは障害の実態を捉えきれない。

一方、プレフィックス撤回が常に同じ影響を生むわけではない。同じ長さのプレフィックスを顧客自身が別のネットワークから広告していれば、BGP収束後にトラフィックがそちらへ移る場合がある。より広い集約経路しか残っていなければ、意図しない経路へ向かう可能性もある。利用可能な代替経路がなければ、ブラックホール化する。したがって、撤回操作の安全性はCloudflare側の状態だけでなく、外部経路の存在と収束状況にも左右される。

Cloudflareの現在の安全な撤回に関する文書は、同じ長さのネイティブ広告を先に開始し、収束を確認した後にCloudflare側の広告を止めるという順序を示している。これは、顧客が計画的に撤回する場合の有用な管理語彙である。ただし、その文書だけから2026年2月時点の内部実装や、障害時の自動処理が同じ仕組みを採用していたと結論付けることはできない。

影響の証拠をどう読むか

Cloudflareは、影響対象としてCDNおよびセキュリティサービス、Spectrum、Dedicated Egress、Magic Transitなど、同社による顧客プレフィックスの広告に依存する構成を挙げている。共通点は、Cloudflareが対象アドレスへのトラフィックを自社ネットワークへ引き付けることが、サービス成立の前提になっている点である。

公共向けの1.1.1.1については、ウェブサイトでエラーが発生した一方、公開DNSリゾルバーは問い合わせへの応答を続けた。この区別は重要である。「1.1.1.1が停止した」と一括りにすれば、ウェブ上の説明ページとDNS解決機能という別のサービス面を混同することになる。公開記録が示しているのは、ウェブサイト側のエラーと、リゾルバー機能が継続したという二つの事実である。

また、約1,100という値はプレフィックス数であり、顧客数、サービス数、利用者数、失われた通信量を表すものではない。一つの顧客が複数プレフィックスを利用する場合も、一つのプレフィックスが複数のサービスに関係する場合も考えられる。公開資料から、影響を受けた個別顧客、売上損失、補償額、社会的損害を推計することはできない。

観測可能な外部証拠にも限界がある。経路収集系が特定地点でプレフィックスを観測しなかったとしても、世界中のすべてのピアリング関係で同時に消えたことまで自動的に証明するわけではない。逆に、一つの収集地点で経路が見えても、すべての利用者から到達可能であるとは限らない。複数地域、複数上流、複数の収集基盤を組み合わせ、管理系の記録と時刻をそろえて評価する必要がある。

これはハイジャックでも経路リークでもない

本件をBGPハイジャックと呼ぶ根拠はない。公開された説明では、権限のない第三者が顧客プレフィックスを不正にオリジネートしたのではなく、正当な運用主体であるCloudflareの管理系が、自ら広告していた顧客プレフィックスを撤回した。

RPKIのオリジン検証失敗とも異なる。有効なROAは、指定されたオリジンASからの広告が権限上妥当かどうかを検証する材料になる。しかし、ROAは広告を生成する装置ではない。正当なオリジンが経路を送らなければ、検証対象となる経路そのものが存在しない。したがって、ROAが正しく維持されていても、撤回による到達性消失は防げない。

また、公開情報から経路リークが実証されたわけでもない。経路リークは、ある関係で学習した経路を、ポリシー上想定されない別の関係へ伝播する問題である。RFC 7908はその類型を整理し、RFC 9234はBGP RolesやOnly-to-Customer属性による防止の枠組みを定義している。本件の中心は、誤った相手へ経路を広げたことではなく、正当な顧客プレフィックスの広告を内部のライフサイクル処理が止めたことにある。

RFC 4271、RFC 6480、RFC 6811、RFC 8210、RFC 7908、RFC 9234は、それぞれBGP、RPKI、経路オリジン検証、RPKIとルーター間の通信、経路リーク、関係性に基づくリーク防止の境界を理解するために役立つ。ただし、RFCはCloudflareの非公開な配備構成、ルーター製品、データ保存方式、変更手順、復旧策の実効性を証明する資料ではない。

五つの状態を分離して考える

BYOIPの説明責任を明確にするには、少なくとも次の五つの状態を別々に扱う必要がある。

第一は、顧客がプレフィックスを管理する権限と、Cloudflareが広告を行う許可である。RIR登録、IRR、ROA、Letter of Agencyがこの層の主な証拠となる。

第二は、Cloudflare上のアカウント関係と委任状態である。どのアカウントがプレフィックスを保有し、どのアカウントが利用を許され、誰がサービス結合や広告状態を変更できるかを示す。

第三は、サービス結合である。CDN、Spectrum、Dedicated Egress、Magic Transit、アドレスマップなど、引き付けたトラフィックをどの機能へ接続するかを定義する。

第四は、広告の意図と配備状態である。管理系がadvertisedを意図しているか、生成済み設定に含まれているか、エッジやルーターがその設定を読み込んでいるか、BGPセッションから実際に経路が送信されているかを確認する。

第五は、外部観測と利用者到達性である。複数の経路収集地点から広告が見えるか、異なるネットワークから対象アドレスへ到達できるか、サービスが期待どおり応答するかを検証する。

この五層は相互に関連するが、同一ではない。権限記録が正常でも広告は消え得る。広告が見えてもサービス結合が壊れていれば、正しいサービスは提供されない。管理系がadvertisedでも、設定配備が失敗していればルーターは広告しない。外部で経路が見えても、特定地域では古い状態が残っている可能性がある。

なぜ単純なロールバックで戻らなかったのか

ロールバックという言葉は、しばしば「変更前の状態が完全に復元された」という意味で受け取られる。しかし実際には、開始点となったソフトウェア変更を戻すことと、その変更が引き起こしたデータ変異を元に戻すことは別である。

ある処理がレコードを誤分類し、削除、結合解除、広告状態の変更、設定再生成まで進めていた場合、コードを以前の版へ戻しても、削除済みレコードは自動では再作成されない。ルーターやエッジに配られたwithdrawn状態も、反対方向の設定展開が行われない限り残り得る。さらに、復元されたプレフィックスとサービス結合が正しく対応しているかを確認しなければ、見かけ上の広告回復だけで不整合が残る。

Cloudflareが説明した複数の復旧経路は、この非対称性を示している。顧客によるセルフサービスの再広告で戻せる対象がある一方、データベースからの復元が必要な対象、サービス結合を再構築する必要がある対象、グローバルなマシン設定の展開を必要とする対象があった。約800プレフィックスが比較的早い経路で戻り、約300プレフィックスに追加対応が必要だったという説明は、すべての影響対象が同じ状態ではなかったことを示唆する。

したがって、ロールバックの設計では、処理を停止できるだけでは足りない。変更された対象を列挙し、それぞれについて変更前の値、依存するレコード、配備先、外部観測を復元し、照合できなければならない。逆操作が存在していても、元の関係を再構築するための情報が失われていれば、完全なロールバックとは呼べない。

顧客セルフサービスと事業者責任

顧客が管理画面やAPIからプレフィックスを再広告できることは、復旧手段として価値がある。影響を把握した顧客が自ら操作し、事業者側の一括復旧を待たずにサービスを戻せる場合がある。特に、プレフィックスレコードとサービス結合が残り、広告状態だけがwithdrawnへ変わったケースでは有効である。

しかし、セルフサービスを主要な統制とみなすべきではない。顧客が障害に気付いていない場合、操作権限を持つ担当者が不在の場合、レコードや結合自体が消えている場合、あるいは再広告操作が失敗する場合には機能しない。また、約1,100の対象を顧客の申告だけで把握するなら、事業者は影響範囲を完全には認識できない。

事業者が担うべきなのは、変更対象の完全な台帳を作り、どのプレフィックスがどの理由で変更され、どの状態まで復旧したかを照合することである。顧客操作で戻ったプレフィックスも、自動復旧で戻ったプレフィックスも、外部広告とサービス応答まで確認されなければならない。セルフサービスは補助的な復旧経路であり、事業者所有の照合責任を移転する仕組みではない。

変更前に必要だった統制

最初の統制は、正確なドライランである。「何件が削除候補か」という総数だけでなく、各候補のプレフィックス、アカウント、委任関係、サービス結合、広告状態、最終更新時刻、外部観測、変更理由を一覧化しなければならない。実行系と異なる簡略化ロジックで候補を算出するドライランは、安心材料になっても安全性の証明にはならない。

第二は、依存関係を理解した削除防止である。advertised状態のプレフィックス、稼働中サービスに結び付いたプレフィックス、最近トラフィックが観測されたプレフィックス、委任先で利用中のプレフィックスは、単独のレコード条件だけで削除してはならない。強制的な保留、複数条件による確認、人手承認、または削除ではなく隔離状態への移行が必要になる。

第三は、変更対象の限定である。約1,100プレフィックスへ広がる前に、少数のコホートで結果を観測できる設計であるべきだった。アカウント種別、サービス種別、プレフィックス長、委任の有無、地域、広告状態などを考慮し、互いに異なる構成を含む小さな単位へ分ける必要がある。

第四は、代表性のあるカナリアである。単純な未使用プレフィックスだけを試しても、複雑なサービス結合や委任を持つ実運用状態の安全性は確認できない。CDN、Spectrum、Dedicated Egress、Magic Transit、アドレスマップ、委任付きプレフィックスなど、異なる依存関係を持つ構成を含めるべきである。ただし、カナリア自体が顧客影響を生まないよう、停止条件と即時復元手段が必要になる。

第五は、独立したロールバックである。変更を実行した同じ制御経路だけに復元を依存すると、その経路の誤分類や障害が復旧にも持ち込まれる。変更前のスナップショット、追記型の変異履歴、別経路からの復元、設定世代の切り戻し、対象ごとの再計算を組み合わせる必要がある。

第六は、横断的な照合である。管理データベースだけを見て成功と判断せず、サービス結合、設定生成、エッジ配備、ルーターのBGP状態、外部収集地点、利用者視点の到達性を同じ対象集合で比較する。照合結果が一致しない場合、処理を自動停止し、次のコホートへ進めないことが重要である。

事後に求められる説明責任

Cloudflareの事後報告は、原因、影響、復旧経路、改善方針を公表している。この透明性は評価に必要な材料を提供する。しかし、公表された改善策と、その実効性が独立に確認された状態は区別しなければならない。

説明責任のある事後対応では、「防止策を追加する」という将来形だけでなく、統制がどの不変条件を守るのかを示す必要がある。たとえば、稼働中のサービス結合を持つプレフィックスは自動削除されない、advertisedからwithdrawnへの変化は外部経路観測と照合される、ロールバックは削除レコードと配備設定の双方を復元する、といった検証可能な条件である。

さらに、顧客が自分のプレフィックスについて確認できる証拠が必要だ。変更前後の広告状態、サービス結合の状態、復旧時刻、外部観測、残存する不整合を、顧客単位で提示できれば、単なる全体ステータスよりも実用的である。顧客が独自に保持するBGP監視や可用性監視と照合できる時刻情報も重要になる。

ただし、公開資料だけからCloudflareの改善策が現在すべて有効に機能しているとは断定できない。改善項目が実装されたか、すべてのBYOIP構成を対象に試験されたか、独立監査が行われたかは、公開された障害記録の範囲を超える。言えるのは、この障害で既存統制が十分に機能しなかったことと、Cloudflareが改善を表明したことまでである。

プレフィックス状態管理の実務的評価軸

事業者のBYOIP統制は、次の問いに具体的な証拠で答えられるかによって評価できる。

権限 — 対象プレフィックスのRIR、IRR、ROA、Letter of Agencyは誰に結び付き、いつ確認されたか。
アカウント関係 — 所有アカウント、利用アカウント、委任、操作権限はどう記録されているか。
サービス結合 — プレフィックスや個別アドレスは、どのサービス、アドレスマップ、トラフィック処理へ結び付いているか。
広告意図 — 管理系はadvertisedとwithdrawnのどちらを意図し、誰が、どの理由で変更したか。
配備状態 — どの設定世代が、どのエッジまたはルーター群へ配られ、適用に失敗した対象はあるか。
外部観測 — 複数の独立地点から、意図したオリジンとプレフィックス長で経路が見えるか。
サービス到達性 — 経路が見えるだけでなく、期待されるサービスが正しく応答しているか。
変更範囲 — 一回の変更が影響できる最大件数は制限され、次のコホートへ進む条件が定義されているか。
削除保護 — 稼働中の依存関係、最近のトラフィック、委任、広告状態が削除前に検査されるか。
復元可能性 — 停止、データ復元、結合再構築、設定再配備を独立して実行できるか。
照合完了 — 復旧済み件数が単一システムの表示ではなく、全レイヤーの一致によって確定されるか。
顧客証拠 — 各顧客が自分のプレフィックスについて、影響と復旧を検証できる記録を受け取れるか。

この評価軸の目的は、事業者に特定の実装技術を強制することではない。内部データベースの種類、ルーターベンダー、設定配布方式が何であっても、権限から到達性までの連鎖が観測可能で、変更が限定され、復旧が再現可能でなければならないという点にある。

フィーチャー画像について

本記事のフィーチャー画像は、ネットワーク運用を象徴する一般的なドキュメンタリー形式の場面として扱うべきである。ラック、配線、監視画面、運用担当者を想起させる表現は可能だが、Cloudflareの施設、実際の障害現場、当日の担当者、使用された機器を撮影したものと説明してはならない。公開事実から、特定の設備、ルーターベンダー、内部チームを画像に結び付けることはできない。