要約

  • Fastlyのバージョンレスドメインは、サービスの個々のバージョンとは別に管理できる。公開名の準備とアプリケーションのリリースを分けて進められる点に利点がある。
  • 運用委託先を交代できるかどうかは、DNS、証明書による制御の証明、アカウント権限、サービスやルーティングとの関連付けを誰が担うかに左右される。
  • アカウント間の委譲は、Fastlyから他社への移行やドメインの法的な権利移転とは異なる。従来型ドメインとPlatform TLSには、手続き上の制約もある。

検収したものと、使えるようになった権限

ある企業がウェブサイトの運用委託先を交代するとしよう。新しい担当会社はソースコードと構築手順を受け取り、アプリケーションを動かせる。旧担当会社も引き継ぎに協力している。検収の対象がアプリケーションであれば、作業はほぼ完了したように見える。

それでも、顧客がいつものURLにアクセスしたとき、その要求を新担当者のサービスへ届ける準備まで終わったとは限らない。ドメインを管理するアカウント、DNSを変更する権限、証明書の手配が別の担当者に残っていれば、アプリケーションの受領と公開入口の引き継ぎには間がある。

これはFastlyの顧客で起きた紛争の事例ではなく、製品の仕組みから考える仮定の場面だ。問いは、外部に運用を任せた企業が、次の運用者を選ぶための能力をどこに残すかにある。業務を委託することと、その委託先を替える手段まで相手に預けることは同じではない。

Fastlyのドメインに関する説明は、この違いを製品上でも明確にしている。バージョンレスドメインはサービスのバージョンと独立して管理でき、サービスに関連付ける前に追加できる。ドメイン側の変更のためにサービスのバージョン番号を進める必要もない。

その価値は、単にリリース作業が一つ減ることだけではない。公開名を先に準備し、受け皿となるサービスを後から決めることができる。アプリケーション担当者とドメイン担当者が別々の予定で作業する余地が生まれる。一方で、最新バージョンを納品したという記録だけでは、入口に関する権限まで引き継いだことを示せなくなる。

「証明済み」は所有権の証明ではない

Fastlyのドメイン管理APIは、複数の関係を分けて記録する。証明書に基づく制御の確認がverified、少なくとも一つのTLS有効化が存在する状態がactivatedである。サービスとの関連付けとルーティング設定との関連付けは別の項目で、未設定の場合もある。

これらは運用上の条件を示すものであり、ドメイン登録上の権利、商標、企業の所有者を決めるものではない。製品が求める制御の証明を提示できることと、その名称の法的な権利を持つことは区別しなければならない。TLSが有効でも、すべての業務用の経路が意図したアプリケーションに到達するとは、それだけでは分からない。

引き継ぎの際には、この区別が役立つ。「ドメイン移管完了」という一つの社内表示にまとめるより、誰が何をできるようになったのかを分けて確認する方が、残る作業と責任者を特定しやすい。すべてを同じ部署が実行する必要はないが、権限の対象は共有されている必要がある。

ファイルとして渡せる証明書にも、継続する仕事がある。自社管理証明書の手順では、有効な証明書と対応する秘密鍵のほか、TLS設定、対象ドメインの有効化、適切なDNS設定が必要になる。証明書に複数の名称が含まれていても、使用予定のドメインがすべて自動的に明示的な有効化を終えているわけではない。

自社管理の場合、更新は顧客の責任になる。ファイルを受け取るだけで、期限の監視、次の証明書の用意、更新に必要な権限まで受け継いだことにはならない。TLSの前提条件にあるアカウントと権限の要件も、担当会社が替わっただけで満たされるものではない。

自分で手続きできる範囲を先に確かめる

Fastlyが従来型と呼ぶクラシックドメインは、サービス設定とそのバージョンに組み込まれている。サービスとの関連を変更するには新しいバージョンが必要で、この機能は2025年9月16日より前に作成されたアカウントに限られる。他のFastlyアカウントで使用中のクラシックドメインを別アカウントへ委譲する場合は、サポートを通す。

これに対して、バージョンレスドメインには別アカウントや別顧客へのセルフサービスの委譲手順がある。ドメインの説明には、DNSによる確認でFastly管理の証明書を取得しDNSトークンを設定する方法と、信頼される公開認証局が発行した有効な証明書と対応する秘密鍵を提示する方法が記されている。これは製品の証明要件であり、委託先の間で本番用の秘密鍵を無造作に共有するよう勧めるものではない。

商取引上の意味は、条件を満たす一部の引き継ぎで、必ずしもサポートへの依頼から始める必要がなくなることだ。適切な権限と証明手段が顧客側の持続可能な管理下にあれば、担当者を交代する準備を自分たちで組み立てやすくなる。逆に、前提となるアクセスをすべて旧委託先に預けていたなら、セルフサービスの画面があるだけでそれが顧客に戻るわけではない。

全顧客に共通する方法でもない。バージョンレスドメインの操作ガイドによれば、Platform TLSの顧客はUnified Domain Managementを読み取り専用で利用し、ドメイン管理や移行ではサポートへの連絡が必要になる。採用しているTLS製品とアカウントの形を特定せずに、引き継ぎ日程だけ決めるのは早計である。

公開資料からは、委譲の平均所要時間、成功率、個別料金や節約額は分からない。言えるのは、ドメイン管理をリリースから分けることで、一定の条件のもとで運用関係を組み替えやすくなるということだ。実際に選択肢として使えるかは、証明と権限を誰が維持しているかによる。

利用者を動かす前に済ませられる仕事

準備の順番にも意味がある。Fastly管理証明書のガイドでは、標準のACME DNSチャレンジで、確認用サブドメインだけをFastlyへ向ける。本番トラフィックをその時点で移す必要はない。TLSの準備と、利用者の要求を新しい経路へ動かす作業を分けて進められる。

一方、HTTPチャレンジはトラフィックを直ちにFastlyへ向ける。TLSやサービスが未完成なら、利用者にセキュリティ警告が表示されたり、サイトへ接続できなくなったりする可能性があると文書は注意している。違いは単なる技術方式ではない。未完了の作業が準備担当者の手元にとどまるのか、それともすでに顧客の利用に影響するのかを分ける。

先行準備ができれば、権限の不足や担当の不明点を、切り替え直前の緊急依頼として発見せずに済む可能性がある。旧環境が本番を受けている間に、新担当者がどこまで進められるかを確かめられる。ただし、無停止の移行を保証する機能ではない。受け入れ側のサービスやアプリケーションが適切に動くことも別途必要だ。

準備が終わっても依存関係は続く。DNSの変更や証明書の発行を制限するCAA設定は、管理証明書の更新を妨げることがある。TLSサブスクリプションAPIも、発行、更新、再試行の状態を区別している。再試行中という事実から、期限が切れた証明書も有効だと解釈してはいけない。

また、すべてのTLS有効化を解除しても、それだけで管理証明書の更新が止まるわけではなく、サブスクリプションの削除とは異なるとガイドは説明する。ここでいずれかの操作を勧めているのではない。証明書を「使用すること」と「継続して管理すること」の責任が、同じ操作で一緒に終わるとは限らない点が重要なのである。

共通の入口に残る配分ルール

公開名とアプリケーションが分かれると、引き継ぐべきものにはサービスの外側にある設定も含まれる。Fastlyのリクエストルーティングは、パスや条件に応じて複数のFastlyサービスへ要求を振り分けられる。そのためのVCLやComputeのコードを書く必要はない。

例えば、サイトを段階的に作り替え、一部の機能だけを別サービスへ移す場合に使える。これは文書化された機能から考えられる用途であり、確認済みの顧客事例ではない。名称を変えずに作業範囲を分けられるのは利点だが、どの要求がどの担当者へ届くかを決めるルールにも、引き継ぎ先が必要になる。

ガイドは、Domain Managementのドメイン、有効なTLS証明書、稼働中のサービスを前提とし、デフォルトルールを必須としている。設定はデプロイしたうえでドメインに関連付ける必要がある。すでにデプロイされた設定は、関連付けた時点で要求の振り分けを始める。したがって、この関連付けを管理する権限には、アプリケーションの納品とは別の効果がある。

コードの担当範囲だけで委託契約を分けると、共通の入口に残るルールが責任のすき間に入りやすい。新しいサービスを受け取っても、どの要求をそこへ送るかは別チームが決め続けるかもしれない。柔軟なルーティングを避ける必要はないが、契約上の担当範囲も実際の要求の流れに合わせる必要がある。

Fastly内の再配置と、他社への移行

一つのアカウント内でサービスを変更すること、別アカウントへドメインを委譲すること、Fastlyを離れて他社にトラフィックを移すことは、それぞれ違う。前の二つはFastlyの内部での再配置である。三つ目では、移行先のサービス、証明書、アプリケーションの条件を整えなければならない。法的な権利の移転は、さらに別の問題になる。

Fastlyのトラフィック経路の説明は、そこで扱う構成ではFastlyがマネージドDNSを提供せず、顧客がDNS事業者を選んで指定のレコードを設定すると明記している。アプリケーションのリリースとは別に、公開名の向き先を管理する場所が存在する。ただし、その場所を顧客が実際に操作できるかは、自社のアカウントと委託の設計次第だ。

DNSには移行の時間条件もある。以前のレコードがキャッシュに残ることは、引き継ぎの署名が終わっても変わらない。反対に、Fastly内でドメインとサービスの関連を変えたからといって、公開DNSを移行したことにはならない。両者を混同すれば、他社へ移る容易さを過大評価し、内部の担当変更が持つ影響を過小評価するおそれがある。

Fastlyは2026年第2四半期の決算発表で、売上高1億8,330万ドル、うちNetwork Servicesを1億3,390万ドルと報告した。これは同社が公表した事業規模の数字であり、バージョンレスドメインの採用数や顧客の節約額を示すものではない。ドメイン管理は、小さな設定作業でありながら、大規模な配信事業の入口を扱っている。

調達側が求めるべきものは、すべての外部事業者から独立することではない。自社の公開入口を動かす能力を取り戻す作業から始めずに、その奥を運用する相手を交代できることだ。Fastlyは名前とバージョンを分ける手段を提供する。証明、権限、継続する責任を分けて受け渡す仕組みは、顧客と委託先が用意しなければならない。