Azure CDN ClassicからAzure Front Door Standard/Premiumへ移行後にAPIが404になる原因と対処法｜Microsoft.Cdnでカスタムドメイン証明書を自動チェック

Azure CDN Classic から Azure Front Door Standard/Premium へ移行した後、従来の Front Door API を呼ぶと 404 になる──これは「リソースの実体が別プロバイダーにある」ことが原因です。本記事では、なぜ起きるのかを整理し、Microsoft.Cdn 側の API/SDK でカスタムドメインや証明書状態を自動チェックする実装手順までまとめます。

移行後に API が 404 になる現象は「呼び先のリソースが違う」

結論から言うと、移行後に Azure ポータル上で “Front Door” に見えているものが、Classic 用のリソース（Microsoft.Network/frontDoors）ではなく、Standard/Premium 用のリソース（Microsoft.Cdn/profiles 配下）として作成されているためです。

そのため、以前使っていたような /providers/Microsoft.Network/frontDoors/... の REST API（あるいは Classic 向け SDK）を叩くと、Azure Resource Manager から見れば「そのリソースは存在しない」ので 404 になります。Classic の API 自体は別ツリーで定義されているため、同名の Front Door があっても相互に参照できません。

まず覚えておきたい：Front Door には “世代” がある

区分	管理リソースの名前空間	代表的な子リソース	API の典型例	よくある落とし穴
Front Door Classic	`Microsoft.Network/frontDoors`	frontEnds / routingRules など（Classic 世代）	`.../providers/Microsoft.Network/frontDoors/{name}/...`	Standard/Premium のリソースに対して叩くと 404
Front Door Standard/Premium	`Microsoft.Cdn/profiles`	`afdEndpoints`, `routes`, `customDomains`, `secrets` など	`.../providers/Microsoft.Cdn/profiles/{profile}/afdEndpoints/...`	「CDN の API に見える」ので混乱しやすい

Standard/Premium は “CDN のプロファイル（profiles）” という器の中に Front Door の各要素（エンドポイント、ルート、カスタムドメイン等）がぶら下がる設計です。REST でも .../providers/Microsoft.Cdn/profiles/{profileName}/... の形になっています。

移行の背景：Classic の制約と期限を知っておく

自動化や運用を組み直すなら、なぜ “Standard/Premium 前提” で考えるべきかも押さえておくと判断がブレません。Microsoft Learn の比較ページでは、Azure Front Door (classic) / Azure CDN from Microsoft (classic) に関して、新規ドメイン追加や新規プロファイル作成、マネージド証明書の扱いなどが段階的に制限され、さらにリタイア日も明記されています。

つまり、今後の運用自動化（証明書チェックやドメイン監視など）は、Classic API を延命するのではなく、Standard/Premium の管理 API に寄せていく方が長期的に安全です。

最初にやるべき確認：リソース ID と “どのツリーにいるか” を固定する

API を正しく選ぶには、Azure 上の実体がどのリソース ID で作られているかが全てです。移行後に作られたリソースのパスが次の形なら、Standard/Premium で確定です。

/subscriptions/.../resourceGroups/.../providers/Microsoft.Cdn/profiles/{profileName}

この場合、以降の操作（エンドポイント、ルート、カスタムドメイン、証明書など）も Microsoft.Cdn 名前空間で辿ります。たとえば “カスタムドメイン一覧” は profile 直下にあります。

旧スクリプトが壊れる典型パターン

Classic の REST パスを叩き続けている（Microsoft.Network/frontDoors を参照）
エンドポイント配下に customDomains がある前提（旧 CDN/Classic の階層を引きずる）
customDomainName に FQDN をそのまま入れる（例：www.contoso.com）
API バージョンが古く、必要な操作やプロパティが出てこない

特に 3 つ目はハマりどころです。Standard/Premium の customDomains/{customDomainName} における customDomainName は “リソース名” であり、FQDN そのものではありません。実際のドメインは properties.hostName に入ります。リソース名は英数字とハイフン中心の制約があり、ドットを含められません（FQDN はほぼ確実にドットを含むため、そのままは不適合）。

Standard/Premium で使うべき REST API：まずは “3 本柱” を押さえる

カスタムドメインと証明書の自動チェックに直結する API は、運用上まず次の 3 つを押さえるのが近道です。

やりたいこと	API（代表例）	HTTP	ポイント
カスタムドメインを列挙する	`/providers/Microsoft.Cdn/profiles/{profileName}/customDomains`	GET	「profile 直下」。旧 endpoint 配下とは別構造
ドメインごとの検証状態・HTTPS 展開状況を見る	`/providers/Microsoft.Cdn/profiles/{profileName}/customDomains/{customDomainName}`	GET	`domainValidationState` と `deploymentStatus` を見る
DNS が正しい AFD エンドポイントを指しているか検証する	`/providers/Microsoft.Cdn/profiles/{profileName}/afdEndpoints/{endpointName}/validateCustomDomain`	POST	リクエストは `{"hostName":"..."}` 、結果は `customDomainValidated`

特に 2 本目（custom domain の GET）は、証明書プロビジョニングの “いま” を自動チェックするのに使えます。レスポンスには、検証トークンや有効期限、検証状態、デプロイ状況などが含まれます。

カスタムドメイン証明書の自動チェック設計

「証明書が正しくプロビジョニングされているか」を機械的に判定するには、DNS 検証（ドメイン所有の検証）とHTTPS の展開（証明書の発行・配布）を分けて見るのがコツです。Standard/Premium では、REST のレスポンスにそれぞれを示す状態が明確に出ます。

判定に使える主要プロパティ

プロパティ	意味	運用上の解釈
`properties.domainValidationState`	ドメイン所有の検証ステータス	Approved になって初めて “所有が確認できた”
`properties.validationProperties.validationToken`	DNS TXT レコード等の検証チャレンジ	TXT レコードの値として使う（期限 `expirationDate` も確認）
`properties.deploymentStatus`	HTTPS 有効化/無効化の進行状況	Succeeded になれば “展開完了” と判断しやすい
`properties.tlsSettings.certificateType`	証明書の種類（Managed か BYOC か等）	運用要件に合うタイプかを検査（例：ManagedCertificate）

状態別に「何をすべきか」を決めておく

domainValidationState	deploymentStatus	状況の例	運用アクション
Submitting / Pending	NotStarted	TXT レコード未設定、または伝播待ち	DNS 側に `_dnsauth` TXT を追加し、TTL と伝播を待つ
Approved	InProgress	所有は OK、HTTPS 展開中	リトライ（間隔を空ける）。最大 1 時間程度を許容
Approved	Succeeded	検証済み＆HTTPS 展開完了	“正常” として記録。定期監視に移行
PendingRevalidation	Succeeded	更新期が近く、再検証が必要になるケース（特に apex）	再検証フローへ。CNAME 条件や apex 特性を確認
Rejected / TimedOut	NotStarted / Failed	TXT が不一致、期限切れ、または手順ミス	トークン再生成（refreshValidationToken）→ TXT 再設定

DNS 検証を “API で” 行う：validateCustomDomain の使い方

Standard/Premium では、特定の AFD エンドポイントに対して validateCustomDomain を POST することで、そのドメインが正しく当該エンドポイントにマップされているかを検証できます。

POST https://management.azure.com/subscriptions/{subscriptionId}
  /resourceGroups/{resourceGroupName}
  /providers/Microsoft.Cdn/profiles/{profileName}
  /afdEndpoints/{endpointName}
  /validateCustomDomain?api-version=2025-04-15

{
  "hostName": "www.someDomain.com"
}

レスポンスは customDomainValidated（true/false）に集約されているため、スクリプトの判定に組み込みやすいのが利点です。

“TXT の値を更新したい” を自動化する：refreshValidationToken

検証が詰まったときに有効なのが、検証トークンの更新です。Standard/Premium では custom domain に対して refreshValidationToken を呼び出せます。これにより、新しい TXT 値が払い出され、検証状態を進められるケースがあります。

POST https://management.azure.com/subscriptions/{subscriptionId}
  /resourceGroups/{resourceGroupName}
  /providers/Microsoft.Cdn/profiles/{profileName}
  /customDomains/{customDomainName}
  /refreshValidationToken?api-version=2025-04-15

運用でよくあるのは、DNS の更新はできたが TTL や伝播の都合で “Pending のまま” に見える状況です。焦って何度も再生成すると監視上のノイズにもなるため、「更新（再生成）→ DNS 反映 → 一定待機 → 再チェック」の順序をコードに固定しておくと安定します。

証明書が想定より進まないときに疑うポイント

マネージド証明書は “時間がかかる” を前提にする

Azure Front Door 管理の TLS 証明書は、発行・インストールに数分〜1 時間程度かかることがあります（状況によりそれ以上の場合もあります）。自動チェックは「即時成功」を期待せず、InProgress を許容する再試行設計にしてください。

CNAME の向き先によって “自動更新” の扱いが変わる

Standard/Premium のマネージド証明書は、CNAME が Front Door エンドポイントを直接指している場合に自動ローテーションされやすく、そうでない場合は再検証が必要になります。運用上は「CNAME の構成」を証明書監視の前提条件として扱うと事故が減ります。

CAA レコードで DigiCert を許可していない

一部のドメインでは、CAA レコードで DigiCert を明示的に許可しないと証明書が発行されない場合があります。マネージド証明書を使う場合、CAA 設定の有無はトラブルシュートの初手に入れておくと便利です。

Node.js での実装例：@azure/arm-cdn に一本化する

Standard/Premium の操作は Classic 用の SDK ではなく、@azure/arm-cdn を軸に組むのが分かりやすいです。CdnManagementClient には apiVersion というプロパティがあり、必要に応じて API バージョン指定もできます。

最小構成のイメージ（TypeScript）

import { DefaultAzureCredential } from "@azure/identity";
import { CdnManagementClient } from "@azure/arm-cdn";

const subscriptionId = process.env.AZURE_SUBSCRIPTION_ID!;
const rg = "your-rg";
const profileName = "your-afd-profile"; // Microsoft.Cdn/profiles
const endpointName = "your-afd-endpoint";

const credential = new DefaultAzureCredential();
const client = new CdnManagementClient(credential, subscriptionId, {
// 必要に応じて固定（環境でサポートされる GA を選ぶ）
apiVersion: "2025-04-15",
});

async function main() {
// 1) customDomains を列挙
const domains = [];
for await (const d of client.afdCustomDomains.listByProfile(rg, profileName)) {
domains.push(d);
}

// 2) 各ドメインの状態を判定
for (const d of domains) {
const hostName = d.properties?.hostName;
const domainValidationState = d.properties?.domainValidationState;
const deploymentStatus = d.properties?.deploymentStatus;
const certificateType = d.properties?.tlsSettings?.certificateType;


console.log({
  name: d.name,
  hostName,
  domainValidationState,
  deploymentStatus,
  certificateType,
});

// 3) DNS マッピング検証（hostName が取れる場合）
if (hostName) {
  const result = await client.afdEndpoints.validateCustomDomain(
    rg,
    profileName,
    endpointName,
    { hostName }
  );
  console.log("validateCustomDomain:", hostName, result.customDomainValidated, result.reason);
}


}
}

main().catch(console.error);

ポイントは次の通りです。

取得（list/get）と検証（validateCustomDomain）を分離し、どちらで落ちているのか判別しやすくする
apiVersion を固定するなら GA を優先し、機能が足りないときだけプレビュー利用を検討
custom domain の “リソース名” と “FQDN（hostName）” を混同しない

なお、SDK やツールによっては GA として 2025-06-01 をデフォルトにしているものもあります。自前 REST を書く場合は、対象操作のドキュメントで “Current version” を確認しつつ、組織内でバージョンを統一すると運用が安定します。

実務での移行手順：スクリプト・IaC の置き換えチェックリスト

リソース ID の置換を “機械的に” 済ませる

旧（Classic など）	新（Standard/Premium）	置換の考え方
`Microsoft.Network/frontDoors`	`Microsoft.Cdn/profiles`	API/SDK の入口が別。混在させない
`/endpoints/{endpoint}/customDomains`	`/customDomains`（profile 直下）	階層変更。旧パスは前提から崩す

監視は「状態プロパティ + 実通信」の二段構えが強い

運用監視の現実解としては、次の二段構えが強いです。

ARM の状態（domainValidationState, deploymentStatus）で “Azure 側がどう見ているか” を把握
実際の HTTPS（アプリ側の疎通や TLS ハンドシェイク）で “ユーザーがどう見えるか” を確認

ARM の状態が Succeeded でも、DNS キャッシュやクライアント経路の影響で “利用者目線ではまだ揺れている” ことは起こり得ます。逆に、疎通が見えていても ARM が PendingRevalidation を示している場合、更新タイミングで事故るリスクがあります。両方を見ると判断がブレません。

よくある質問

なぜ移行後の Front Door が “Microsoft.Network/frontDoors” じゃないの？

Standard/Premium は、管理プレーン上は Microsoft.Cdn/profiles を親として構成される設計だからです。Front Door の機能（WAF、ルーティング、証明書など）自体は “Front Door” ですが、リソースの実体は Microsoft.CdnMicrosoft.Network を叩き続けると 404 になります。

証明書が “正しい” を API でどう判定すればいい？

最低限は次のセットで判定できます。

domainValidationState === "Approved"
deploymentStatus === "Succeeded"
（必要なら）validateCustomDomain の customDomainValidated === true

時間がかかる場合があるため、InProgress を即エラーにせず、リトライで吸収するのが運用向きです。

マネージド証明書の更新で “Pending revalidation” が出たら？

主に DNS の向き先や apex 特性（CNAME flattening 等）の影響で、自動ローテーションが効かないケースがあります。状態が PendingRevalidation に遷移したら、TXT による再検証フローを回す前提で運用設計してください。

まとめ：404 を止めて、証明書チェックを自動化する最短ルート

移行後の Front Door Standard/Premium は Microsoft.Cdn/profiles 配下のリソース。Classic 用の Microsoft.Network/frontDoors を叩くと 404 になり得る
カスタムドメインは profile 直下で管理する（旧 endpoint 配下前提を捨てる）
証明書の自動チェックは domainValidationState + deploymentStatus を軸にし、必要なら validateCustomDomain で DNS マッピングも検証する
Node.js なら @azure/arm-cdn を使い、必要に応じて apiVersion を明示する

これらを前提に、スクリプトや IaC を “Standard/Premium のリソースツリー” に寄せていけば、移行後の 404 問題と証明書運用の不安を同時に解消できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure CDN ClassicからAzure Front Door Standard/Premiumへ移行後にAPIが404になる原因と対処法｜Microsoft.Cdnでカスタムドメイン証明書を自動チェック

移行後に API が 404 になる現象は「呼び先のリソースが違う」

まず覚えておきたい：Front Door には “世代” がある

移行の背景：Classic の制約と期限を知っておく

最初にやるべき確認：リソース ID と “どのツリーにいるか” を固定する

旧スクリプトが壊れる典型パターン

Standard/Premium で使うべき REST API：まずは “3 本柱” を押さえる

カスタムドメイン証明書の自動チェック設計

判定に使える主要プロパティ

おすすめの判定ロジック（疑似フロー）

状態別に「何をすべきか」を決めておく

DNS 検証を “API で” 行う：validateCustomDomain の使い方

“TXT の値を更新したい” を自動化する：refreshValidationToken

証明書が想定より進まないときに疑うポイント

マネージド証明書は “時間がかかる” を前提にする

CNAME の向き先によって “自動更新” の扱いが変わる

CAA レコードで DigiCert を許可していない

Node.js での実装例：@azure/arm-cdn に一本化する

最小構成のイメージ（TypeScript）

実務での移行手順：スクリプト・IaC の置き換えチェックリスト

リソース ID の置換を “機械的に” 済ませる

監視は「状態プロパティ + 実通信」の二段構えが強い

よくある質問

なぜ移行後の Front Door が “Microsoft.Network/frontDoors” じゃないの？

証明書が “正しい” を API でどう判定すればいい？

マネージド証明書の更新で “Pending revalidation” が出たら？

まとめ：404 を止めて、証明書チェックを自動化する最短ルート

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure CDN ClassicからAzure Front Door Standard/Premiumへ移行後にAPIが404になる原因と対処法｜Microsoft.Cdnでカスタムドメイン証明書を自動チェック

移行後に API が 404 になる現象は「呼び先のリソースが違う」

まず覚えておきたい：Front Door には “世代” がある

移行の背景：Classic の制約と期限を知っておく

最初にやるべき確認：リソース ID と “どのツリーにいるか” を固定する

旧スクリプトが壊れる典型パターン

Standard/Premium で使うべき REST API：まずは “3 本柱” を押さえる

カスタムドメイン証明書の自動チェック設計

判定に使える主要プロパティ

おすすめの判定ロジック（疑似フロー）

状態別に「何をすべきか」を決めておく

DNS 検証を “API で” 行う：validateCustomDomain の使い方

“TXT の値を更新したい” を自動化する：refreshValidationToken

証明書が想定より進まないときに疑うポイント

マネージド証明書は “時間がかかる” を前提にする

CNAME の向き先によって “自動更新” の扱いが変わる

CAA レコードで DigiCert を許可していない

Node.js での実装例：@azure/arm-cdn に一本化する

最小構成のイメージ（TypeScript）

実務での移行手順：スクリプト・IaC の置き換えチェックリスト

リソース ID の置換を “機械的に” 済ませる

監視は「状態プロパティ + 実通信」の二段構えが強い

よくある質問

なぜ移行後の Front Door が “Microsoft.Network/frontDoors” じゃないの？

証明書が “正しい” を API でどう判定すればいい？

マネージド証明書の更新で “Pending revalidation” が出たら？

まとめ：404 を止めて、証明書チェックを自動化する最短ルート

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル