App Service＋Azure CDN / Front Door Classic で運用している大規模サイトを、Azure Static Web Apps（SWA）＋Enterprise Grade Edge（EGE）に移行しようとしたら、カスタム ドメインがいつまでも「Adding / Deleting」のまま動かない――そんなときに原因を切り分け、ゼロ／最小ダウンタイムで安全に切り替えるための具体的な手順を整理します。
Azure Static Web Apps（SWA）＋Enterprise Grade Edge（EGE）移行時に何が起きているのか
まずは、SWA＋EGE への移行時に「カスタムドメインが Adding / Deleting のまま止まる」とき、内部でどのようなことが起きているかを整理します。
典型的なシナリオ
- 既存構成：Azure App Service（あるいは VM / コンテナ）＋Azure CDN / Front Door Classic 等で
www.example.comを配信中 - 新構成：Azure Static Web Apps（SWA）＋Enterprise Grade Edge で段階的に移行したい
- やりたいこと：ダウンタイムほぼゼロで SWA 側へトラフィックを切り替えたい
- しかし：SWA ポータルでカスタムドメインを追加しても 「Adding」のまま数日進まない、別環境では削除が 「Deleting」のまま終わらない
このときの本質的な問題は、同じホスト名を複数のエッジ／配信基盤が同時に「所有」しようとしていることにあります。
Adding / Deleting が止まるときのイメージ
| 状態 | ユーザーが見ている挙動 | 裏側で起きていることのイメージ |
|---|---|---|
| Adding | ポータルのステータスがいつまでも「Adding」のまま | ドメインの所有証明や証明書発行が完了せず、内部ジョブが待ち状態のまま |
| Deleting | 削除済みのつもりなのに、ステータスが「Deleting」から変わらない | エッジ側の設定削除、証明書失効、キャッシュパージなどが非同期で残っている |
特に、旧 Azure CDN / Front Door Classic と、SWA の Enterprise Grade Edge（実体として Front Door Premium を利用）が同じホスト名を取り合っている場合、検証用 TXT / CNAME レコードの評価がうまく進まず、SWA 側が半端な状態で止まりやすくなります。
根本原因の整理：同一ドメインの二重所有と残存設定
Adding / Deleting の問題を構造化すると、次の 3 つにほぼ集約されます。
同一ホスト名を複数のエッジが同時に握っている
Azure CDN / Front Door Classic と、SWA＋EGE（内部的には Front Door Premium 相当の機構）が、同じ www.example.com を登録しようとすると、以下のような衝突が起こります。
- 同じ FQDN に対して、複数の配信基盤が「自分のものだ」と主張
- ドメイン所有の検証（TXT / CNAME）が、旧構成の情報を見てしまう
- 証明書の自動発行が進まず、SWA 側が「Adding」でフリーズしたように見える
この状態では、どれだけ待っても自然に解決することはほぼありません。根本的に、どちらか一方がドメインを手放す必要があります。
DNS の残骸・古いレコードによる衝突
DNS 側にも罠があります。たとえば、以下のような状態です。
- 過去の検証用 TXT レコードが残ったまま
- 古い CNAME レコードが消されず、Azure 側が想定する値と違う
- A / AAAA レコードで独自に IP を向けてしまい、CNAME ベースの検証と矛盾
- TTL が 1 時間以上になっていて、変更しても伝播が遅い
DNS レベルで矛盾があると、Azure 側では「所有証明に必要なレコードが正しく見えない」ため、Adding / Deleting が進まなくなります。
削除処理の非同期化とタイムラグ
Deleting が長く続く典型的な理由は、内部処理がまとめて非同期で走っていることです。
- エッジネットワーク側の設定削除
- 証明書の失効・ローテーションの反映
- グローバルキャッシュのパージ
これらはすべて世界中の POP に反映されるため、一瞬で終わるわけではありません。とはいえ、数時間～数日以上、永遠に「Deleting」のまま変わらない場合は、内部ジョブがエラーで停止している可能性も疑うべきです。
Adding で止まるときの実践ワークアラウンド（ダウンタイム最小）
本番カスタムドメインをいきなり SWA に握らせようとすると、旧 CDN / Front Door と衝突しやすくなります。そこで、一時ステージング用サブドメインを使った迂回手段が現実的です。
ステージング用サブドメインを先に完成させる
まず、本番とは別のサブドメインを準備します。
- 本番：
www.example.com - ステージング：
staging.example.com（任意の名前で可）
この staging.example.com を SWA のカスタムドメインとして追加し、ポータルが指示する通りに TXT / CNAME を設定します。
- SWA ポータルで
staging.example.comを追加 - 表示された TXT / CNAME レコードを DNS に設定
- 数分～十数分待ってから、ブラウザや
curlで疎通確認
ここで重要なのは、本番ドメインを触る前に、SWA 側の配信経路・アプリ動作・EGE の挙動をステージングで検証しておくことです。
TTL を事前に短くしておく
本番ドメインを切り替える直前に TTL を短縮すると間に合わないことがあります。切り替えの数日前～数時間前には、TTL を 300 秒（5 分）前後にしておくと安全です。
| 期間 | 推奨 TTL | 目的 |
|---|---|---|
| 通常運用時 | 3,600 秒（1 時間）～ 10,800 秒（3 時間）程度 | DNS クエリ負荷軽減・安定性重視 |
| 移行前日～当日 | 300 秒（5 分）程度 | 切り替え・ロールバックを素早く反映 |
切替ウィンドウでやること：DNS スイッチ＋旧側の解除
いよいよ本番切り替えです。ここでのポイントは、「DNS を SWA に向ける」ことと「旧 CDN / Front Door からカスタムドメインを削除する」ことをセットで行うことです。
- DNS の CNAME を SWA の配信ドメインに変更
例：www.example.com → <swa-name>.azurestaticapps.netまたは EGE 用のエンドポイント - 旧 Azure CDN / Front Door Classic 側から
www.example.comの関連付けを削除 - 数分～数十分かけて、ブラウザ・
curl・監視ツール等で新経路に切り替わったことを確認
これにより、Azure の内部では www.example.com を握っているのが SWA 側だけになります。同じ FQDN を取り合っていた状態が解消されるため、その後の証明書発行や EGE の有効化がスムーズに進むようになります。
切替作業の全体像（例）
| フェーズ | 実施内容 | ポイント |
|---|---|---|
| 事前準備 | ステージングドメインを SWA に追加し、疎通確認 | アプリ挙動やヘッダー、ログなどを確認しておく |
| TTL 調整 | 本番ドメインの TTL を 300 秒程度に短縮 | 数時間前には実施しておくと安心 |
| 切替ウィンドウ | DNS CNAME を SWA に変更し、同時に旧 CDN / Front Door の関連付けを削除 | ダウンタイムを最小にするため、作業者・手順・時間帯を明確化 |
| 検証 | HTTP ステータス・証明書・レスポンスヘッダを確認 | 問題なければ旧側の残存設定を整理・削除 |
Deleting で止まるときの実務的な対処
既に SWA に追加したカスタムドメインを削除しようとした際、「Deleting」のまま進まないケースもあります。ここでは、現場でよく有効なステップをまとめます。
基本：Azure CLI で削除をトリガーし直す
ポータルで削除しても進まない場合、Azure CLI から削除 API を叩き直すことで解消することがあります。
az staticwebapp hostname delete \
--name <SWA名> \
--resource-group <リソースグループ> \
--hostname <削除したいFQDN>
このコマンドを数回リトライすると、バックエンドの削除フローが再実行され、数分後にポータル上のステータスが消えるケースがよくあります。
DNS レコードの一時撤去も有効
それでもダメな場合は、該当ドメインに紐づく TXT / CNAME / A / AAAA のうち、検証用に残っているものを一時的に撤去してから再度 CLI で削除すると、うまくいくことがあります。
- 古い TXT が残っていると、「まだ使われている」と判断されることがある
- CNAME 先が旧エンドポイントのままだと、解放処理が完了しづらい
どうしても進まないときはサポート チケット
Deleting が明らかに長期間続き、CLI でも解消しない場合は、Azure サポートへの問い合わせが現実解です。その際、以下を添えておくと調査が早く進みます。
- SWA 名／リソースグループ／サブスクリプション ID
- 問題の FQDN（例：
www.example.com） - 削除操作を行った日時とポータル／CLI のスクリーンショット
- 現在の DNS レコードの一覧（TXT / CNAME / A / AAAA）
ゼロ／最小ダウンタイムでの現実的な移行フロー
Adding / Deleting でハマらないために、移行全体の流れを設計しておくと安全です。ここでは、実績ベースでうまくいきやすい例を紹介します。
ステップ 1：一時的に EGE を無効化して SWA を通常配信
いきなり EGE 有効の状態で戦うのではなく、一度 EGE を無効化した状態の SWA を通常配信モードで立ち上げます。こうすることで、問題の論点を「SWA のアプリ側」と「EGE／Front Door 側」に分離できます。
ステップ 2：本番トラフィックを SWA へ移行（DNS スイッチ）
次に、DNS の CNAME を SWA 側に切り替え、本番トラフィックをいったん SWA 直配信にします。このタイミングでは、旧 CDN / Front Door を前段に残す構成も可能ですが、同じ FQDN を複数サービスに登録しないよう設計が必要です。
ステップ 3：旧 CDN / Front Door 側のカスタムドメインを削除
本番が SWA で安定して配信できていることを確認したら、旧側の Azure CDN / Front Door Classic からカスタムドメインを削除します。ここを曖昧にしておくと、あとで EGE を有効化するときに衝突しやすくなります。
ステップ 4：1〜2 日程度待機（ドメイン解放・パージ待ち）
旧側からドメインを解放しても、内部的なキャッシュや証明書のパージにはタイムラグがあります。1～2 日程度は様子を見ながら待機すると、安全に次のステップへ進めます。
ステップ 5：SWA で EGE を有効化し、カスタムドメインを再追加
最後に、SWA の Enterprise Grade Edge を有効化し、改めてカスタムドメインを追加します。このとき、旧 CDN / Front Door 側には FQDN が紐付いていないため、ドメイン所有証明と証明書発行がスムーズに進むことが期待できます。
この流れで、実際に「最終的に EGE 有効のまま移行完了」した事例が複数存在します。特に大規模トラフィックを扱う場合は、いきなり EGE 全部の設定を詰め込むのではなく、段階的に切り替えるのがポイントです。
詳細チェックリスト：移行前に必ず押さえておきたい項目
以下は、実際に移行前のレビューで使えるチェックリストです。単なる羅列ではなく、なぜ必要なのかも合わせて解説します。
| 観点 | チェック内容 | 理由・背景 |
|---|---|---|
| ドメイン分離 | www（本番）と staging（一時）を明確に役割分担して検証しているか | ロールバックや追加検証を行う余地を残すため |
| TTL 設定 | 本番ドメインの TTL を 300 秒前後まで短縮済みか | DNS 切替に失敗した場合でも、素早く戻せるようにするため |
| 旧側の関連付け | 旧 CDN / Front Door 側のカスタムドメイン関連付けが削除済みか | 同一ドメイン二重所有による Adding / Deleting 固着を防ぐため |
| DNS レコード | 最新の TXT / CNAME のみが残り、不要な A / AAAA が残っていないか | 検証ロジックに矛盾した情報を渡さないため |
| 証明書 | 切替後、証明書の CN / SAN に本番ホスト名が含まれ、期限・発行者が想定どおりか | 閲覧者のブラウザで証明書警告が出ないことを保証するため |
| レスポンス確認 | server や x-azure-ref などのヘッダで SWA / EGE 側にヒットしているか | 本当に新構成から配信されているかを技術的に確認するため |
Azure CLI で状態を見える化する
ポータルだけに頼らず、Azure CLI でホスト名の状態を機械的に確認しておくと安心です。
現在のホスト名一覧を確認
az staticwebapp hostname list \
--name <SWA名> \
--resource-group <RG名>
このコマンドは、SWA に紐づいているカスタムドメインの一覧と、そのステータスを返します。Adding / Deleting の状態や、EGE 有効化との関連もここから確認できます。
カスタムドメインの追加
az staticwebapp hostname set \
--name <SWA名> \
--resource-group <RG名> \
--hostname <FQDN>
ポータル UI から追加しても実態は同じ API が呼ばれていますが、CLI であれば自動化やログ取得がしやすいため、繰り返し試すときや IaC と併用するときに便利です。
カスタムドメインの削除（リトライ前提）
az staticwebapp hostname delete \
--name <SWA名> \
--resource-group <RG名> \
--hostname <FQDN>
Deleting で止まったように見えても、数分～数十分後に状態が消えることがあります。一定時間を置いて数回だけリトライし、それ以上はサポートに切り替える、といった運用ルールを決めておくとよいでしょう。
カスタムドメイン設計のベストプラクティス
Adding / Deleting でハマらないためには、最初のドメイン設計をシンプルにしておくことも重要です。
www は CNAME で運用する
www.example.comは基本的に CNAME で運用する- Apex ドメイン（
example.com）をどうしても使う場合は、DNS プロバイダの ALIAS / ANAME を利用する - もしくは、ユーザー向けには
wwwをメインとして設計する
Azure 側のカスタムドメイン検証は CNAME ベースで設計されていることが多く、CNAME を素直に使ってあげる方が圧倒的にトラブルが少ないです。
検証用 TXT / CNAME は事前準備しておく
メンテナンスウィンドウに入ってから DNS 作業を始めると、想定外の遅延が発生しがちです。できるだけ事前に以下を済ませておきましょう。
- ステージングドメイン分の TXT / CNAME を先に登録
- 本番ドメイン向けの TXT / CNAME も可能な範囲で事前反映
- 社内の DNS 管理フロー（申請・承認）があれば、余裕を持って申請
理想は、本番切替当日は DNS の向き先変更だけで完了する状態を作ることです。
ロールバック手順を明文化しておく
どれだけ慎重に準備しても、完全にトラブルゼロにすることは難しいです。そのため、ロールバック手順を事前にドキュメント化しておくことが非常に重要です。
- どの CNAME を、どの値に戻せばよいか
- 旧 CDN / Front Door 側の設定を一時的に復活させる場合の手順
- 監視通知やステータスページの運用方針
これらを準備しておくことで、移行作業時の心理的プレッシャーを大きく下げることができます。
旧 Azure CDN / Front Door Classic からの卒業を前提にする
旧 Azure CDN（from Microsoft）や Front Door Classic は、機能・サポート面で徐々に制約が増えつつあります。長期的には、Front Door Standard / Premium や SWA＋EGE への集約を前提に設計する方が安全です。
今回紹介したように、「同一ドメインの二重所有」さえ避ければ、SWA＋EGE への移行は比較的スムーズに進められます。新旧サービスの役割を整理し、段階的に切り替えていきましょう。
よくある質問（FAQ）
Q. 旧 Front Door Classic にドメインが残っているかどうか、どう確認すべき？
A. ポータルの対象 Front Door リソースを開き、「ドメイン」あるいは類似メニューで www.example.com が残っていないか確認します。Terraform や Bicep で構成管理している場合は、コード側からも削除が反映されていることを確認してください。
Q. Apex ドメイン（example.com）を SWA に直接向けることはできる？
A. DNS プロバイダが ALIAS / ANAME に対応していれば、Apex から SWA へのルーティングも実現可能です。ただし、実装や挙動はプロバイダ依存になることが多いため、まずは www をメインとして設計する方が安全です。
Q. Adding / Deleting が発生したときに、まず見るべきポイントは？
A. 次の順番で確認するのがおすすめです。
- DNS に古い TXT / CNAME / A / AAAA が残っていないか
- 旧 Azure CDN / Front Door 側に、同じ FQDN の設定が残っていないか
- Azure CLI で hostname list / delete を実行し、状態が変化するか
- それでもダメなら Azure サポートにエスカレーション
まとめ：同一ドメイン二重所有を避け、段階的に移行する
本記事で紹介したポイントを振り返ります。
- Adding / Deleting の根本原因は、同一ドメインの二重所有と DNS 残存設定にある
- ステージングドメイン＋DNS スイッチ＋旧側の確実な解除が、ダウンタイム最小の王道パターン
- 削除が進まないときは、CLI での再トリガー＋不要レコード除去で解消するケースが多い
- 一度 EGE を無効化して SWA 単体にトラフィックを乗せ、その後 EGE を有効化する段階的移行が現実的
- 適切なドメイン設計（
wwwの CNAME 運用、Apex の扱い、ロールバック手順など）を最初から意識しておくと、後々のトラブルを大幅に減らせる
Azure Static Web Apps と Enterprise Grade Edge は、正しく設計すれば高トラフィックサイトでも十分に戦える基盤です。「Adding / Deleting から進まない」状態に不安を感じたら、本記事のチェックリストと手順に沿って、落ち着いて原因を切り分けてみてください。
コメント