Cloudflareは2026年10月5日、CIDRをURL pathへ埋め込むZero Trust Networksのroute endpointを削除し、Cloudflare TunnelとMeshのlist・get responseからconnections fieldを除去する。API response shapeとresource identifierが同時に変わるため、route automationとmonitoringの両方を棚卸しする必要がある。

何が変わったか

route作成・更新・削除は/teamnet/routes/network/{ip_network_encoded}から、POST /teamnet/routesおよび/teamnet/routes/{route_id}へ移る。create時のCIDRはrequest bodyのnetworkへ入れる。同日、cfd_tunnelとwarp_connectorのlist・get responseからconnections arrayが消え、専用/{tunnel_id}/connections endpointを呼ぶ必要がある。

変更前後の差

旧route APIはURL-encoded CIDRをidentifierとして使っていた。新APIはUUIDのroute_idを使う。旧monitoringはtunnel objectの一部としてconnectionsを読めたが、新方式は必要時だけdetail endpointから取得する。responseが小さくなる一方、API call数とcache設計が変わる。

誰に影響するか

custom script、backend service、CI/CD、Terraform、cloudflared tunnel route ip、inventory dashboard、connection health monitorを運用する組織が対象である。Terraformはcurrent provider/resourceへ更新する。connections field部分についてはcloudflaredとTerraform providerは読んでいないとCloudflareは説明しているが、自作toolは確認が必要である。

期限

2026年10月5日に旧endpointとfieldが削除される。それまでにproduction trafficを新方式へ切り替え、旧呼び出しが0であることを確認する。

必要な対応

List tunnel routesで既存routeのroute_idを取得し、CMDBやstateへ保存する。create responseからIDを保持し、CIDRを再度identifierとして組み立てない。connectionsの取得はdedicated endpointへ分離し、polling intervalとrate limitを見直す。

実装・移行手順

  1. source、log、dashboardから旧pathとconnections参照を検索する
  2. 全routeのroute_idを取得してmappingを作る
  3. createをbody方式へ変更する
  4. update・deleteをroute_id方式へ変更する
  5. connection取得を専用endpointへ分離する
  6. dual-readで旧・新結果を比較する
  7. cloudflaredとTerraform providerを更新する
  8. 旧endpoint callが0になった後に旧codeを削除する

失敗しやすい点

CIDRからroute_idを毎回検索する、create responseのIDを保存しない、list responseのconnectionsが空になるだけだと思う、tunnelとMeshのendpointを混同する、URL encodingのtestだけ残す、といった問題が起きやすい。

リスク

route更新・削除失敗、private networkの経路残存、monitoringのconnection数が0になる、専用endpoint追加によるrate limit、stateと実体のID不一致がある。migration中のdual writeは重複routeを作らないよう注意する。

評価方法

  • 旧endpoint呼び出し数
  • route_id保有率
  • route create・update・delete成功率
  • connections取得成功率
  • monitoring欠損時間
  • API request数とlatency
  • Terraform plan差分
  • 旧新route inventoryの一致率

ロールバック

10月5日までは新codeに問題があれば旧endpointへ一時的に戻せるが、期限後は使えない。feature flagで旧新を切り替え、route mutationは一方だけをwriterにする。connection monitorは旧fieldと新endpointを並行比較し、切替後の欠損時はalertを抑制せずfallback表示へ戻す。

編集部分析

今回の変更はURL置換だけではない。resource identityをCIDRからUUIDへ変え、summary responseからconnection detailを分離するAPI設計変更である。migration成功条件はHTTP 200ではなく、route stateとmonitoring valueが旧方式と一致することである。

実務チェックリスト

  • [ ] 旧CIDR endpointを全検索した
  • [ ] route_id mappingを保存した
  • [ ] create bodyへnetworkを移した
  • [ ] connections専用endpointへ変更した
  • [ ] cloudflared・Terraformを更新した
  • [ ] dual-readで結果を比較した
  • [ ] 10月5日前に旧callを0にした

一次情報