Azure App Service の「管理対象証明書（無料）」は手軽に HTTPS 化できる一方、まれにカスタム ドメイン追加や証明書発行が延々と終わらず失敗することがあります。同じ Terraform 定義で他環境は成功しているのに、特定の 1 環境だけタイムアウトする――そんな状況で、既存の App Service を削除せずに正常化するための切り分け手順と、現場で効いた復旧策をまとめます。
現象を整理する（Terraformでもポータルでも長時間待たされる）
今回の相談内容は、典型的な「設定ミスなのか、Azure 側の処理詰まりなのか」を切り分けにくいパターンです。ポイントは、Terraform 実行時だけでなく Azure ポータル操作でも同様に失敗していること、そして同一の構成で複数環境は正常であることです。
| 観点 | 起きていること | 示唆 |
|---|---|---|
| 自動化 | Terraform からカスタム ドメイン追加＋証明書作成が 20〜30 分でタイムアウト | IaC 側の待ち時間不足の可能性もあるが、後述のとおり単独原因ではないことが多い |
| 手動操作 | ポータルでも 30〜45 分ほど Get Certificates が続いた後に失敗 | Terraform 固有の問題より、App Service 側のバックエンド処理が詰まっている疑いが強い |
| 再現性 | 同じ構成で 4 環境は成功、特定の 1 環境だけ失敗 | DNS やアプリ設定の差分がないなら「特定インスタンスのプラットフォーム側要因」を疑う |
| 制約 | 既存の App Service は削除・再デプロイしたくない | “現在のインスタンスを生かしたまま”の復旧策を優先する |
結論：まず疑うべきは「Terraform」ではなく「特定 App Service インスタンス側の詰まり」
同一の Terraform 定義が他環境で通っている場合、構成ミスの線は相対的に薄くなります。もちろん DNS 伝播やドメイン検証などの基本条件は前提として必要ですが、ポータル操作でも長時間待たされた末に失敗するなら、証明書発行ワークフローがバックエンドで滞留している（プラットフォーム側の一時障害）が疑わしいです。
このタイプの不具合は、ユーザー設定をいくら見直しても改善しないことがあります。一方で、App Service を別ホストへ“載せ替える”操作（スケールアップ／ダウン、プラン移動）で突然直ることがあり、現場での打率も高めです。
前提知識：管理対象証明書が作られるまでの流れ
App Service の管理対象証明書（無料／管理対象）は、ざっくり言うと「ドメイン所有の検証が通ったら、Azure 側が自動で証明書を発行し、App Service にバインドする」仕組みです。途中で検証に失敗したり、内部処理が詰まったりすると、ポータル上は延々と処理中に見えることがあります。
| 段階 | Azure 側で起きている処理 | つまずきポイント |
|---|---|---|
| カスタム ドメイン追加 | CNAME/A と TXT(asuid) でドメイン所有を検証し、ホスト名バインディングを作成 | DNS が引けない／伝播不足／プロキシ経由で検証できない |
| 証明書の発行要求 | 管理対象証明書の作成ジョブを開始し、発行元との連携や内部状態を更新 | バックエンドジョブが詰まると “Get Certificates” が長引く |
| 証明書バインド | 対象ホスト名に SSL バインド（SNI）を設定し、HTTPS で有効化 | バインド対象のホスト名が未検証・未登録だと失敗する |
| 自動更新 | 期限前に自動更新（再発行） | 更新時にも DNS 状態が影響することがあるため、運用時も DNS の整合性が重要 |
切り分けの第一歩：DNS レコードと伝播状況を“世界中から”確認する
「同じ構成で他環境は成功している」とはいえ、証明書作成が止まる原因として DNS は最優先の確認項目です。特に、ローカル PC からは引けていても、Azure の検証基盤（別リージョン／別リゾルバ）からは見えていないケースがあります。ここで詰まると、証明書発行の前段が通らず、結果として長時間の待ち→タイムアウトに見えます。
最低限そろえるべき DNS レコード
サブドメイン（例：www）を付ける場合は CNAME が基本です。ルートドメイン（例：example.com）を使う場合は A レコード（または DNS 事業者の ALIAS/ANAME 等）になることが多いです。いずれの場合も、所有確認用の TXT（asuid）が重要です。
| 目的 | レコード種別 | 例 | チェック観点 |
|---|---|---|---|
| アプリへの到達 | CNAME | www.example.com → <app_name>.azurewebsites.net | 別の CNAME と競合していないか、余計な空白や末尾ドットが紛れていないか |
| ルートドメイン到達（必要な場合） | A（または ALIAS/ANAME） | example.com → <App Service の IP> | IP が古くないか、CDN/プロキシで隠蔽されていないか |
| ドメイン所有確認 | TXT（asuid） | asuid.www.example.com = <検証トークン> | 値が一致しているか、別 TXT に埋もれていないか（複数 TXT の扱いに注意） |
「伝播完了」を判断するコツ
- 複数リージョンの DNS リゾルバで同じ結果が返ることを確認します（オンラインの DNS チェッカーや、複数のパブリック DNS を使った
digなど）。 - TTL が長いと、修正が反映されるまで時間がかかります。レコードを直した直後は「まだ旧情報を掴んでいる場所がある」前提で見ます。
- DNS 事業者の「CNAME フラット化」や「ALIAS」機能は便利ですが、実装差で検証が不安定になることがあります。問題切り分けの間だけでも、できる限り標準的な CNAME/A/TXT 構成に寄せます。
見落としがちな落とし穴（同じ構成でも環境差が出るポイント）
- DNS プロキシを有効にしている：CDN/セキュリティサービスで DNS をプロキシすると、検証要求が想定と違う経路になり失敗することがあります。切り分け中は「DNS only」にするのが安全です。
- TXT が複数行になっている：管理画面上は 1 行に見えても、内部的に分割されることがあります。短いトークンでも、余計な引用符や改行が入っていないか確認します。
- 同名の別レコードが存在する：CNAME と A を同名で併存させるなど、仕様上矛盾するレコードがあると検証が不安定になります。
- 検証対象ホスト名が違う：
asuid.example.comとasuid.www.example.comを取り違えるなど、ホスト名の粒度ミスはよくあります。
復旧策として有効なことが多い：App Service プランを一時的にスケールアップ／ダウンする
DNS が問題なさそうなのに「Get Certificates」が延々と続く場合、次に試したいのがスケールアップ／ダウンです。これは単に性能を上げる目的ではなく、裏側で App Service の配置先が変わり、詰まっていた内部処理が解消されることを狙います。
ポータルでの実施手順（最小限の変更で試す）
- 対象の App Service プラン を開きます。
- 左メニューで 「スケールアップ（App Service プラン）」 を選びます。
- 現在と異なる SKU（例：P1v2 → P2v2 など）に変更します。
- 反映完了を待ち、対象 App Service でカスタム ドメイン追加／管理対象証明書作成を再実行します。
- 結果にかかわらず、不要なコストを避けるため、必要に応じて元の SKU に戻します。
| 確認事項 | なぜ重要か | 実務上のコツ |
|---|---|---|
| コスト増 | 上位 SKU は従量で課金が上がる | 検証時間を短くする、成功したらすぐ戻す |
| 一時的な影響 | 構成変更で再起動に近い挙動が起きる場合がある | 可能なら低トラフィック時間帯に実施、監視を見ながら行う |
| 失敗しても価値がある | 「プラットフォーム詰まり」の可能性を強く絞り込める | 試行日時を控え、後でサポートに伝えられるようにする |
スケール変更で直らない場合：別 App Service プランへ移動して“別インフラ”に載せ替える
スケールアップ／ダウンで改善しないときは、新しい App Service プランを用意して移動する方法があります。これも狙いは同じで、「同じ App Service（アプリ本体）はそのままに、実行基盤だけ変える」アプローチです。再デプロイを避けたい要件とも相性が良いです。
基本手順（イメージ）
- 同じリソース グループ・同じリージョンに 新しい App Service プラン を作成します。
- 対象の App Service を開きます。
- 左メニューの 「App Service プランの変更」 から移動先プランを選びます。
- 移動後、カスタム ドメイン追加／証明書作成を再実行します。
移動できない・やりにくい代表例（無理に進めない）
ここで引っかかりやすいのが VNet 統合です。構成やプラン種別によっては、移動に制約が出ます。移動が難しい場合は、無理に操作を重ねるより、後述のサポート問い合わせに進むほうが安全です。
| 制約になりがちな要素 | 起きやすいこと | 判断の目安 |
|---|---|---|
| VNet 統合 | 移動がグレーアウトする／移動後に接続が再設定になる | ネットワーク要件が厳しい場合は、変更前に影響範囲を洗い出す |
| リージョン差 | 別リージョンへは移動できない（基本は同一リージョン前提） | 新プランは同一リージョンで作る |
| SKU/機能差 | 移動先 SKU に機能がないと設定が保持できない | 移動先は現在と同等以上の SKU を選ぶ |
最終手段ではなく“必須手段”：Azure サポートに問い合わせる
DNS が問題なく、スケール変更やプラン移動でも改善しない場合、ユーザー側でできることは限られます。特に、ポータルのアクティビティ ログに「Get Certificates」関連の失敗が残るなら、バックエンドの処理状態やログを Microsoft 側で確認してもらう必要があります。
サポートに渡すべき情報
問い合わせの質（＝解決までの速さ）を左右するのが、失敗操作に紐づく Correlation ID（相関 ID） です。これがあると、サポートは該当処理の内部ログを追いやすくなります。
| 項目 | 具体例 | 補足 |
|---|---|---|
| 対象 App Service | サブスクリプション / リソース グループ / App 名 | 同名があると混乱するためフルパスで |
| カスタム ドメイン名 | www.example.com | 複数ある場合は全部 |
| 失敗した日時 | YYYY-MM-DD HH:MM JST のようにタイムゾーン付き | 再現試験をした場合はその時刻も |
| アクティビティ ログ | Get Certificates / Create Managed Certificate 等の失敗イベント | イベント詳細を開いてコピー |
| Correlation ID | イベント詳細に表示される相関 ID | これが最重要 |
問い合わせ文テンプレ（そのまま貼れる形）
サポートに投げるときは、状況・再現・試したことが 1 通で伝わる文章にします。以下のテンプレをベースに埋めるとスムーズです。
現象:
- App Service の管理対象証明書（無料）を作成できません。
- Terraform でも Azure ポータルでも同様にタイムアウト/失敗します。
- 同一構成の他環境では成功しており、特定の 1 環境のみ発生しています。
対象:
* Subscription: <サブスクリプション名 or ID>
* Resource Group:
* App Service:
* Custom Domain: <[www.example.com](http://www.example.com)>
発生日時:
*
Activity Log:
* Operation: Get Certificates（または該当操作名）
* Correlation ID: <相関ID>
試したこと:
* DNS（CNAME/TXT asuid）の確認と伝播チェック
* App Service プランのスケールアップ/ダウン
* （可能であれば）別プランへの移動
結果:
* 改善せず。バックエンドの調査と復旧を依頼します。Terraform 利用者向け：切り分けを早くする小さな工夫
今回のケースはプラットフォーム要因が濃厚ですが、Terraform を使っているなら「誤検知（Terraformだけが先に諦める）」を減らす工夫もしておくと切り分けが早くなります。
- リソース間の順序を明確にする：ホスト名バインド → 管理対象証明書 → SSL バインドの順序が崩れると失敗しやすくなります。依存関係が曖昧なら
depends_onで固定します。 - タイムアウト値を現実に寄せる：管理対象証明書はバックエンドの都合で待ちが長くなることがあります。ポータルでも時間がかかるなら、Terraform の create timeout を延ばして「Terraformだけが落ちる」状況を避けます（ただしポータルでも失敗するなら根本解決ではありません）。
- まずは手動で 1 回だけ成功させる：環境固有の問題がないかを見極めるため、最初の 1 回はポータルで成功させ、以後を Terraform に寄せる運用も有効です（変更管理が必要な組織では、手動作業の記録を残します）。
削除・再デプロイを避けたいときの判断フロー
「今動いている App Service は触りたくない」「でも証明書だけ作れない」という状況では、リスクと効果のバランスを取りながら進めます。以下のフローに沿うと、遠回りしにくくなります。
| 状況 | まずやること | 次の一手 |
|---|---|---|
| DNS を最近いじった／引けたり引けなかったりする | DNS の CNAME/TXT(asuid) を世界中のリゾルバで確認 | 伝播が安定してから再試行 |
| DNS は安定、でも Get Certificates が長時間続く | App Service プランを一時的にスケールアップ/ダウン | 改善しなければ別プラン移動（可能なら） |
| VNet 統合などでプラン移動が難しい | 無理に移動せず、アクティビティログを収集 | Correlation ID を添えてサポート起票 |
| 他環境は成功、当該環境だけ失敗が続く | 「設定」より「基盤」を疑う前提で進める | 試行ログを残し、早めにサポートへ |
再発防止の観点：運用で押さえておくポイント
管理対象証明書は更新まで自動化されるのが魅力ですが、発行・更新の前提条件は “DNS が正しいこと” に依存します。次のような運用をしておくと、将来の更新失敗も拾いやすくなります。
- DNS の変更履歴を残す：誰がいつレコードを変更したか追えるようにする（IaC 化、監査ログの活用など）。
- 監視は「期限」だけでなく「更新失敗の兆候」も見る：アクティビティ ログや診断ログで証明書関連の失敗を拾えるようにしておく。
- 環境差分を最小化する：同じ Terraform を使っていても、DNS 管理が手動だと差分が生まれます。DNS も含めてテンプレ化すると “なぜこの環境だけ？” を減らせます。
- サポートに渡せる情報を習慣化する：Correlation ID と発生時刻（タイムゾーン付き）をメモする運用にしておくと、緊急時に強いです。
まとめ：同じ Terraform で他環境が成功しているなら、インスタンス固有の障害を疑う
カスタム ドメインの追加や管理対象証明書の作成が、Terraform でもポータルでも長時間の末に失敗する場合、まず DNS を疑い、それが問題なければ“基盤の載せ替え”で復旧を狙うのが定石です。具体的には、DNS（CNAME/TXT asuid）の世界的な伝播確認 → スケールアップ/ダウン →（可能なら）別プラン移動 → サポート起票（Correlation ID 添付）という順に進めると、既存 App Service を守りながら最短距離で原因に到達できます。
コメント