Cloudflare移管の翌日、買収サイトが落ちた

2026年6月1日(月) 08:00

Cloudflareにはアカウント単位の所有権移転を認める公式手段がなく、譲渡できるのはゾーン単位のみのため、WAF・Workers・KV・R2等30箇所の設定が移管時に自動コピーされず消失しうる。買い手はDD段階で読み取り権限を取得しcf-terraforming等で設定差分ゼロを検証すべきで、Cloudflare依存度（粗利への寄与度等）は企業価値評価に減点要素として織り込む必要がある。

「DNSはCloudflareなので移行はゾーン移管で大丈夫です」── 買収側のエンジニアがそう答えた瞬間に、その案件は危険信号を出している。Cloudflareの設定はDNSレコードだけではない。WAF・SSL・Workers・キャッシュルール・Page Rules・Rate Limiting・Bot Management・Access・Tunnel・R2・KV、そして「誰がそのアカウントの本当のオーナーなのか」という権限構造そのものまで、すべてがCloudflareダッシュボード内に積み上がっている。

そしてここに、業界がほとんど直視してこなかった構造的な問題がある。Cloudflareには「法人間でアカウントごと所有権を移転する」という公式のメニューが存在しないのだ。譲渡できるのはゾーン（zone）単位までで、アカウント（account）そのものは譲渡不可。結果としてM&Aの現場では、買い手側が「新しいCloudflareアカウントを自社で作り、設定をすべて手動でコピーする」という、規模感に対して恐ろしく原始的な作業を強いられることになる。

本稿では、Cloudflare移管時に「消える」ことになる30箇所の設定を6カテゴリに分解し、棚卸しの実務手順、Cloudflare依存度を企業価値評価にどう織り込むか、そして売り手・買い手それぞれが契約前にやっておくべき作業を整理する。読み終えた頃には、買収契約書に「Cloudflareアカウントの引き継ぎ」と一行書くだけでは不十分な理由が、立体的に理解できるはずだ。

1. なぜCloudflareは"アカウント所有権移転"を公式に認めないのか

1-1. 「ゾーン移管」と「アカウント移管」は別物 ── 規約上の建付けが招く構造的な詰み

Cloudflareの公式ドキュメントには、「Transfer a domain to another Cloudflare account」という手順が用意されている。これを見て「ちゃんと移管手順があるじゃないか」と判断してしまうと、最初の罠にはまる。この手順で移せるのは、あくまで個別のゾーン（ドメイン）であって、アカウントそのものではない。

ゾーン移管で引き継がれるのはDNSレコード・SSL設定の一部・基本的なゾーン設定のみで、Page Rules・Workers・Workers KV・R2・D1・Access・Tunnel・カスタムWAFルール・Rate Limitingの設定群は移管先アカウントに自動コピーされない。Cloudflareは「ドメインの所有権」を移すための仕組みであって、「事業の引き継ぎ」を想定した仕組みではない。これは設計思想の根底にある考え方であり、有償サポートに問い合わせても基本的な回答は変わらない。

もう一つ重要なのが、Enterpriseプラン契約の扱いだ。Enterprise契約はCloudflare社と契約者（法人）の個別契約として結ばれており、契約者が変わる場合は「新規契約のやり直し」になる。年額数百万円から数千万円の契約条件・割引率・ロックイン期間が、買収を機にゼロからの再交渉になることがある。これは買収シナジーの試算から完全に抜け落ちやすい項目だ。

1-2. 「メンバー招待で凌ぐ」という現場のグレー対応 ── 二要素認証の電話番号が前オーナーに残るリスク

移管手順がないなら、現場はどうしているのか。多くのケースで実際に採用されているのが、「旧オーナーのアカウントに、買い手側のメールアドレスをAdminメンバーとして招待してもらう」という運用だ。これでダッシュボードへの操作権限は確保できる。

しかし、これは構造的にかなり危うい。アカウントの「Super Administrator（実質オーナー）」は最初に作ったメンバーであり、そこには旧オーナーの個人メールアドレス、二要素認証用の電話番号、回復用のバックアップコードが紐づいたままになる。買い手は管理画面を操作できるようになっただけで、「アカウントを完全に支配している」状態にはなれない。

さらに悪いケースだと、旧オーナーが個人Googleアカウント（個人Gmail）でCloudflareアカウントを作っていて、そのGmailを退職時に削除してしまい、二要素認証のリカバリーがオーナー本人にも不可能になる事態が起きる。こうなるとCloudflareサポートに「事業譲渡の経緯と契約書」を提示して所有権移転を依頼する泥仕合になり、解決まで数週間〜数か月単位の時間を浪費することになる。

1-3. 「DNSは新アカウントで作り直す」という最終手段 ── ダウンタイムを許容できるかどうかが分水嶺

権限移譲の交渉が長引いたり、旧オーナーのアカウントが回復不能になった場合、最後の手段として「買い手側で新規Cloudflareアカウントを作り、すべての設定をゼロから再構築し、ネームサーバーを切り替える」という選択肢がある。理論上は確実な方法だが、実務上の負担はきわめて大きい。

なぜなら、ネームサーバーの切り替えにはDNSの伝播時間が伴い、世界中のリゾルバが新ネームサーバーを認識するまで数時間から最大48時間程度かかる。この間、設定差分があれば一部ユーザーから見たサイトが落ちる。さらにEdge Certificate（Universal SSL）は新アカウントで再発行となるため、HSTS設定や証明書ピンニングを行っている場合は深刻な問題を引き起こす。「設定を完全に揃えてから切り替えないとサイトが落ちる」という前提が常に成立する。

2. 移管時に消える設定 30箇所の地図 ── 6カテゴリで網羅する

2-1. カテゴリA：DNS関連（6箇所） ── 「Aレコードだけコピーすれば十分」という最初の誤解

DNS関連で見落とされがちな設定は次の通りだ。①Aレコード、②CNAME、③MXレコード、④TXTレコード（SPF/DKIM/DMARC含む）、⑤CAAレコード、⑥DNSSEC設定。このうちMXとTXTの設定漏れは、移管翌日に「顧客からのメールが届かなくなる」「自社からのマーケティングメールが全件迷惑メール判定される」という致命的な事態を直接的に引き起こす。

特にCAAレコードは存在自体を知らないエンジニアも多い。CAAは「このドメインに対してSSL証明書を発行できる認証局はLet's EncryptとDigiCertだけ」というように、証明書発行を制限するレコードで、これを移管先で再設定し忘れると、新環境で証明書を発行しようとした時にCertificate Authorityから発行拒否されるという地味で致命的な事故が起きる。

2-2. カテゴリB：SSL/TLS関連（5箇所） ── Edge Certificateの再発行が引き起こすHSTS事故

SSL/TLS関連の設定は、①Universal SSL（Edge Certificate）、②Custom Certificate（持ち込み証明書）、③Origin Certificate、④SSL/TLS暗号化モード（Off / Flexible / Full / Full Strict）、⑤Minimum TLS Version。アカウント移管に伴いEdge Certificateは新アカウントで再発行となり、有効期間や発行元認証局が変わる可能性がある。

もしHSTS（HTTP Strict Transport Security）を有効化していて、includeSubDomainsとpreloadフラグを設定済みの場合、証明書チェーンに不整合が起きるとブラウザがそのドメインへの接続を完全に拒否する。「サイトは生きているのに、世界中のブラウザから一切アクセスできない」という地獄が、HSTSの設定ミスでは現実に起きる。

2-3. カテゴリC：セキュリティ（6箇所） ── WAFカスタムルールが守っていた攻撃面が丸裸になる

セキュリティ系で消える設定は、①WAF Custom Rules、②WAF Managed Rules、③Rate Limiting Rules、④Bot Management設定、⑤IP Access Rules（ホワイトリスト・ブラックリスト）、⑥Country Blocking。中規模以上のサービスでは、WAFのCustom Rulesに「特定エンドポイントへの異常なリクエストパターンをブロック」「特定User Agentの遮断」「クレデンシャルスタッフィング攻撃の遮断」といった、過去の被害から学んだ防御ルールが何十本も蓄積されている。

これらのルールが消えた状態でサービスを公開すると、過去にブロックしてきた攻撃が再び素通りになる。攻撃者側は新アカウントでの設定漏れを検知すると、即座に旧来のパターンで再攻撃を開始する。Bot Managementを有効化していたサービスでは、スクレイピングやスパム登録の量が一晩で10倍以上に跳ね上がるケースがある。

2-4. カテゴリD：ルーティング・書換え（5箇所） ── Page Rulesが消えるとリダイレクトが全滅する

ルーティング系の設定として、①Page Rules、②Configuration Rules、③Origin Rules、④Transform Rules、⑤Redirect Rules（Single Redirects / Bulk Redirects）が存在する。Cloudflareは2023年以降、旧Page Rulesから新しいRule Engine（Configuration Rules / Origin Rules / Transform Rules等）へと段階的に移行しており、設定が複数のレイヤーに分散している状態が一般的だ。

Bulk Redirectsで何千件もの旧URL→新URLのリダイレクトを設定しているサイトの場合、これが移管時に消えるとSEO的にも致命的な事態になる。検索インデックスは旧URLを参照しており、リダイレクトが消えた瞬間に404の量産が始まる。Googleのクロール頻度の高いサイトほど、設定漏れによる検索順位の毀損が早く・深く現れる。

2-5. カテゴリE：エッジ実行・ストレージ（5箇所） ── Workers / KV / R2 / D1 / Pagesの「アカウント縛り」

Cloudflare Workers、Workers KV、R2 Storage、D1 Database、Cloudflare Pagesは、いずれもアカウント単位で課金・管理されるリソースだ。これらは原則として「別アカウントへの引き継ぎ」がそもそも提供されておらず、新アカウントで再デプロイする運用になる。

Workers KVに数千万キーのデータが蓄積されている場合、それらをエクスポートして新アカウントのKVにインポートする作業は、APIスループットの制限と料金両面で重い負荷を生む。R2 Storageに数TBのデータがある場合、新アカウントへのコピー転送料と所要時間が問題になる。「Workersはコードを再デプロイすれば終わる」と言うエンジニアは、KVとR2とD1の存在を忘れている。

2-6. カテゴリF：運用情報（3箇所） ── Analytics履歴・Audit Log・API Tokensという「見えない資産」

最後のカテゴリは、①Analytics履歴（過去のトラフィック・セキュリティイベント）、②Audit Log（操作履歴）、③API Tokens / Members権限の3つ。Analytics履歴は新アカウントには引き継がれず、過去の傾向分析や攻撃検知のベースラインがゼロからやり直しになる。

API Tokensの監査はもっと深刻だ。旧アカウントには、CI/CDパイプライン・監視ツール・社内システム・退職した社員の個人開発環境など、過去に発行された無数のAPI Tokenが残存している可能性がある。これらは「Read All Zones」「Edit DNS」「Cloudflare Pages Edit」といった強力な権限を持つことが多く、移管後も旧アカウント側で有効なまま、誰の管理にも属さないゾンビ権限として残り続ける。

3. 棚卸しの実務 ── 「設定差分ゼロ」を保証する3つの手順

3-1. cf-terraforming で現状をTerraformコードにエクスポートする

30箇所の設定を人間が目視で書き写すのは現実的ではない。第一に推奨されるのが、Cloudflareが公式に提供しているcf-terraformingというツールを用いて、現アカウントの設定をTerraformコードとしてエクスポートする方法だ。これによりDNSレコード・Page Rules・WAFルール・Workersの紐付け・Access設定まで、ほぼ全領域がコードとして手元に残る。

コード化された設定は、新アカウント側で `terraform apply` することで、人手によるコピーミスを排した形で再構築できる。さらにGit管理することで、移管前後の差分をdiffで検証できる。「移管後に何かが変わっていないか」を確認する場合に、コード化されていれば差分検証は数分で終わる。これを行わない場合、検証作業に数日単位の工数が消える。

3-2. /client/v4/zones API による全ゾーン設定のJSONダンプ

cf-terraformingでカバーできないリソース（Workers KVの内容、R2のメタデータ、Analyticsの履歴など）については、Cloudflare REST API（/client/v4/）で個別にダンプを取る必要がある。WAFのカスタムルールは `/zones/{zone_id}/firewall/rules` で、Rate Limitingは `/zones/{zone_id}/rate_limits` で、Page Rulesは `/zones/{zone_id}/pagerules` で、それぞれJSON取得できる。

取得したJSONはバージョン管理下に置き、新アカウントで同じJSONをPOSTすることで設定を再構築する。ここで重要なのは、移管直前と移管直後の両方で同じAPIを叩き、差分をdiffで突き合わせること。設定差分ゼロが確認できるまでネームサーバーを切り替えてはならない。

3-3. ロールバック前提のネームサーバー切り替え ── TTLを300秒以下に下げる

移管当日のネームサーバー切り替えは、本番反映の前にTTL（Time To Live）を300秒以下まで下げておくことが定石だ。通常のCloudflareのデフォルトTTLは「Auto」になっており、これは長い場合4時間〜24時間に設定されている。この状態でネームサーバーを切り替えると、問題が発生してもロールバックが「世界中の半数のリゾルバから見て効かない」状態が長時間続く。

切り替え前48時間以上前にTTLを300秒に下げ、切り替え後30分以内にトラフィックの問題（502エラー率の上昇・SSL警告・WAFブロック率の急増等）を検知したら、旧ネームサーバーに即座に戻す。この前提を契約書のクロージング条件に組み込んでおくべきだ。

4. バリュエーション減点ロジック ── Cloudflare依存をどう企業価値に織り込むか

4-1. 「Direct Origin（Cloudflare無し）で何分耐えるか」のストレステスト

Cloudflareが事業価値に占める比率を定量化する最初の問いは、「Cloudflareが30分間ダウンしたら、このサービスは何を失うか」だ。Cloudflareを単なるCDN・DNS層として使っているサイトと、Workersにビジネスロジックの中枢を載せているSaaSとでは、Cloudflare停止時のインパクトが全く違う。

具体的なDDの作法としては、Cloudflareをバイパスして直接オリジンサーバーにアクセスした場合の挙動を、ステージング環境で必ず検証する。Cloudflare無しでも動くサービスはバリュエーションの減点幅が小さく、Cloudflare依存度が中核に達しているサービスは「インフラ非連続リスク」として価値の10〜20%程度を割り引く判断材料になる。

4-2. Worker依存ロジックが粗利の何%を支えているかの可視化

Cloudflare WorkersがCRUDの中核（認証・課金処理・API GW・パーソナライゼーション）を担っているサービスは、Workers移管時に「コードは引き継げてもWorkers KV・Durable Objectsのデータ移行で連続稼働を維持できるか」という別問題に直面する。

バリュエーション評価としては、Workers実行回数・KV読み書き回数・Durable Objects接続数を粗利にマッピングし、「Cloudflare固有機能に粗利の何%が依存しているか」を算出する。粗利の30%以上がCloudflare固有機能に依存している事業は、Cloudflare依存リスクを単独のリスクファクターとしてDCF評価に組み込むべきだ。これを織り込まずに買収価格を算定すると、移管失敗時の損失が想定の倍以上に膨らむ。

4-3. 旧オーナーアカウントに残るAPI Tokenの監査 ── 「ゾンビ権限」が企業価値に与える隠れ負債

API Tokensの監査は、定量化しづらいが本質的なリスクだ。旧オーナーのアカウントに「DNS編集権限つきAPI Token」が複数残存していて、それを誰が管理しているか分からない状態は、買収後の事業に対するセキュリティリスクをそのまま引き継ぐことを意味する。

DD段階で必ず実施すべきは、`/user/tokens` および `/accounts/{account_id}/tokens` のAPIで全Token一覧を取得し、それぞれの権限スコープ・最終使用日時・発行者を棚卸しすることだ。退職者・元業務委託者・解約済みSaaSサービスに紐づくTokenは、移管前に無効化しておく。これを怠ると、買収後に「DNSが第三者によって書き換えられ、サイトが乗っ取られる」事故が現実に起きうる。

4-4. Enterpriseプラン専用機能への暗黙の依存 ── 維持費の階段関数

もう一つの定量評価ポイントが、Enterpriseプラン専用機能（Argo Smart Routing、高度なBot Management、Load Balancer、Magic Transit等）への依存度だ。これらの機能は買収によりEnterprise契約が「再交渉ステータス」になると、契約条件が変わる可能性がある。割引率の喪失、最低契約期間の再設定、特定機能のアドオン化など、買収後の維持費が階段状に跳ね上がるケースがある。

Enterpriseプラン機能を粗利の中核で使っている事業のバリュエーションは、Enterprise契約の再交渉前提として年間維持費の20〜40%上振れを織り込むべきだ。これを開示資料に含めないDD報告書は、技術的DDとして実務レベルに達していない。

5. 売り手・買い手それぞれの実務チェックリスト

5-1. 売り手側 ── 譲渡前に提出すべき「Cloudflare棚卸し書類」

売り手側が買収交渉に入る段階で開示できる状態にしておくべきは、次の5点だ。①現アカウントのMembers一覧と権限、②ゾーン一覧、③Page Rules・WAF Custom Rules・Rate Limiting Rulesの全件エクスポート、④Workers / KV / R2 / D1 / Pagesの利用状況とリソース量、⑤過去6ヶ月分のAnalyticsサマリー。

これらをcf-terraformingでコード化したリポジトリと、API JSONダンプの両方で提示できれば、買い手の技術DD工数を大幅に短縮できる。「インフラの状態を可視化された形で提示できる売り手」はそれ自体がバリュエーションの加点要素であり、デューデリの中で「ブラックボックスではない事業」として評価される。

5-2. 買い手側 ── DD段階でCloudflareへの読み取り権限を獲得する

買い手側がDDで最初にやるべきは、「Cloudflareアカウントへの読み取り専用権限（Analyst権限）を発行してもらう」ことだ。これにより、売り手側からの開示資料と実際のダッシュボードの整合性を、自分の目で確認できる。

同時に、cf-terraformingを買い手側のサンドボックスで実行し、設定をTerraformコードとしてエクスポートできるか検証する。エクスポートできない構成（独自のWorkersスクリプト、未公開のKVキー、独自Bot Managementルール等）が見つかった場合、それは「移管時の手戻り工数」としてバリュエーションに反映させるべきだ。

5-3. 移管当日のロールバック手順 ── 旧ネームサーバーへの差し戻し条件を契約書に明記する

移管当日の実務として、ロールバックの判断条件を契約書または覚書に明記しておくことは、トラブル発生時の責任所在を明確にする上で極めて重要だ。具体的には、「移管後30分以内に5xxエラー率が5%を超えた場合は旧ネームサーバーに即時切り戻し」「24時間以内にWAFブロック率が著しく低下した場合は再検証」といった、定量的なトリガーを設定しておく。

判断基準が曖昧だと、移管後にトラブルが起きた際に売り手・買い手の双方が「これはロールバックすべき状況か」を巡って空白の数時間を浪費する。その数時間がそのまま売上消失とユーザー離反になるのがインフラ移管の現実だ。

結論：Cloudflareアカウントはバランスシートに載らない最大の隠れ資産であり、隠れ負債である

Cloudflareの設定群は、財務諸表のどこにも載らない。資産の部にも、負債の部にも、固定資産にも仕掛品にも計上されない。しかし、その設定が10年かけて積み上がった結果として、サービスの可用性・セキュリティ・ユーザー体験・SEO・売上の連続性が守られている。買収契約書に「DNS移管します」と一行書くだけの取引が、なぜ移管翌日にサイトを落とすのか。理由はこの「見えない資産」の存在を、契約書も財務DDも捉えきれないからだ。

事業を譲渡する側にとっても、買収する側にとっても、Cloudflareの棚卸しは「インフラの可視化」そのものであり、可視化された事業はバリュエーションの土俵に正々堂々と乗せられる。逆に、棚卸しを拒む事業は「中身を見せられない事業」として、それ自体が買収側に強い警戒シグナルを発することになる。技術的DDの本質は、こうした「数字に載らない領域」を数字に載るかたちに翻訳する作業であり、Cloudflareはその最前線の一つだ。