結論から言うと、2026年6月3日の更新により、Azure API Management の Premium v2 と Standard v2 でワイルドカード カスタムホスト名が一般提供されました。これにより、payments.api.contoso.com、inventory.api.contoso.com、orders.api.contoso.com のように増え続けるサブドメインを、*.api.contoso.com の1つのホスト名設定とワイルドカード証明書で扱いやすくなります。APIの数やチーム数が増えている組織ほど、証明書更新、DNS管理、ホスト名登録の手間を減らせる変更です。(マイクロソフト Azure)
ただし、「ワイルドカードを設定すればすべて自動で解決する」という機能ではありません。DNS、証明書、Azure Key Vault、ホストヘッダー、既存の個別ドメイン設定、フロントエンドに Azure Front Door や Application Gateway を置いている構成では、事前確認が欠かせません。この記事では、Azure API Management のワイルドカード カスタムホスト名対応で何が変わるのか、管理者・開発者が確認すべきポイント、移行時に失敗しやすい点を実務目線で整理します。
Azure API Management のワイルドカード カスタムホスト名とは
Azure API Management のカスタムホスト名は、API Gateway や開発者ポータルなどのエンドポイントを、Azure 既定の azure-api.net ドメインではなく、自社ドメインで公開するための設定です。たとえば、既定の contoso-apim.azure-api.net ではなく、payments.api.contoso.com のようなURLでAPIを公開できます。
今回の更新で重要なのは、Premium v2 と Standard v2 において、*.api.contoso.com のようなワイルドカード形式のカスタムホスト名を利用できるようになった点です。Microsoftの説明では、API資産が増えるほどサブドメインごとのホスト名登録と証明書管理が運用上の負担になり、ワイルドカード対応によってこの負担を減らせるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
たとえば、次のような構成を考えると分かりやすいです。
| API公開名 | 従来の考え方 | ワイルドカード利用時の考え方 |
|---|---|---|
payments.api.contoso.com | 個別にホスト名と証明書を設定 | *.api.contoso.com の配下として扱う |
inventory.api.contoso.com | 個別にホスト名と証明書を設定 | 同じワイルドカード設定で扱う |
orders.api.contoso.com | 個別にホスト名と証明書を設定 | 同じワイルドカード設定で扱う |
これにより、新しいAPIサーフェスを追加するたびに、Azure API Management 側でサブドメインごとのカスタムホスト名を繰り返し追加する必要が減ります。特に、事業部、地域、プロダクト、顧客テナントごとにAPIのサブドメインを分けている組織では、運用設計を見直すきっかけになります。
何が変わったのか
今回の変更は、単なるURL表記の拡張ではありません。API公開基盤の運用負荷に直接関わる変更です。
Premium v2 と Standard v2 でワイルドカードが使いやすくなる
Microsoftの更新情報では、Azure API Management Premium v2 と Standard v2 がワイルドカード カスタムホスト名をサポートし、*.api.contoso.com のような1つの設定と1つのワイルドカード証明書で複数のサブドメインをカバーできると説明されています。(マイクロソフト Azure)
これまで v2 レベルでサブドメインを多く扱う場合、個別のホスト名登録や証明書運用が増えやすく、APIの追加スピードに運用作業が追いつかないケースがありました。今回の対応により、少なくともホスト名と証明書の管理面では、よりスケールしやすい構成を取りやすくなります。
個別ホスト名とワイルドカードの使い分けが重要になる
Microsoft Learn では、*.contoso.com のようなワイルドカード ドメイン名が複数のレベルでサポートされること、また api.contoso.com のような特定サブドメインの証明書は、*.contoso.com のようなワイルドカード証明書より優先されることが説明されています。(Microsoft Learn)
つまり、すべてをワイルドカードに寄せる必要はありません。むしろ、次のように使い分けるのが現実的です。
| 使い方 | 向いているケース |
|---|---|
| ワイルドカードホスト名 | APIサブドメインが頻繁に増える、チームやテナント単位で命名を分ける |
| 個別ホスト名 | 重要APIだけ証明書やポリシー管理を分けたい、特定のブランドドメインを使いたい |
既定の azure-api.net ドメイン | 検証、内部テスト、移行期間中の疎通確認 |
ワイルドカードは便利ですが、すべてのドメイン管理を雑にまとめるための機能ではありません。セキュリティ要件、監査要件、障害時の切り分け方まで含めて設計する必要があります。
影響を受ける利用者と構成
今回の更新で特に確認すべきなのは、Azure API Management を単体で使っている組織だけではありません。DNS、証明書、Key Vault、フロントドア構成、CI/CD、API公開ルールまで影響します。
影響が大きい組織
次のいずれかに当てはまる場合、今回のワイルドカード カスタムホスト名対応を確認する価値があります。
| 対象 | 確認すべき理由 |
|---|---|
| APIサブドメインが多い企業 | ホスト名と証明書の個別管理を減らせる可能性がある |
| マルチテナント型SaaS | テナントごとのサブドメイン設計を簡素化できる可能性がある |
| 事業部ごとにAPIを公開している組織 | 命名規則を統一しやすくなる |
| Azure Key Vault で証明書を管理している環境 | ワイルドカード証明書の保管・更新・権限設定を確認する必要がある |
| Front Door、Application Gateway、WAF を前段に置いている環境 | ホストヘッダー保持や証明書終端位置の確認が必要 |
| Infrastructure as Code で APIM を管理しているチーム | Bicep、ARM、Terraform などの定義変更が必要になる可能性がある |
特に、APIサブドメインの追加をアプリチームが頻繁に依頼し、インフラチームが毎回カスタムドメインと証明書を設定している環境では、作業フローそのものを改善できます。
すぐに移行しなくてもよいケース
一方で、次のような環境では急いで変更する必要はありません。
| 状況 | 判断 |
|---|---|
| API公開ドメインが1つだけ | ワイルドカード化の効果は限定的 |
| サブドメイン追加が年に数回程度 | 運用負荷削減より変更リスクが大きい場合がある |
| 監査上、APIごとに証明書を分ける必要がある | 個別証明書のまま維持する方がよい |
| DNSや証明書管理が別部門で厳格に運用されている | 先に運用ルールの合意が必要 |
ワイルドカード対応は「使えるようになった」機能であり、既存環境を必ず変更しなければならない更新ではありません。既存のカスタムドメインが安定稼働している場合は、API追加頻度や証明書更新工数を見て導入判断をするのが現実的です。
管理者が確認すべき設定
Azure管理者が最初に確認すべきなのは、ドメイン名、証明書、DNS、APIMのエンドポイント種別です。ワイルドカード カスタムホスト名は、設定対象を誤ると「証明書は正しいのに接続できない」「DNSは解決できるのにAPIMが拒否する」といった障害につながります。
対象の API Management レベルを確認する
今回の主な更新対象は、Azure API Management の Premium v2 と Standard v2 です。Microsoft Learn の v2 レベル概要では、v2 レベルはデプロイ、構成、スケーリングの迅速化や、Standard v2 / Premium v2 のネットワーク分離オプションなどが説明されています。(Microsoft Learn)
まず、対象の API Management インスタンスがどのレベルで動作しているかを確認してください。Azure portal では、API Management インスタンスの概要や価格レベルの画面から確認できます。
確認ポイントは次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| サービスレベル | Standard v2 または Premium v2 か |
| 対象エンドポイント | Gateway、Developer portal など、どこに設定するのか |
| 既存ホスト名 | 個別ドメインがすでに登録されているか |
| 既存証明書 | PFX、Key Vault、マネージド証明書のどれを使っているか |
| フロント構成 | Front Door、Application Gateway、Traffic Manager、WAF の有無 |
特に重要なのは、Gatewayエンドポイントです。通常、API利用者が実際に呼び出すURLは Gateway のカスタムドメインであり、ワイルドカード化の効果が最も大きい部分です。
DNSレコードを確認する
Azure API Management のカスタムドメインでは、DNS側でカスタムドメインを API Management の既定ホスト名に向ける必要があります。Microsoft Learn では、CNAMEレコードを使ってカスタムドメインを API Management の既定ホスト名へ向ける構成が説明されています。(Microsoft Learn)
ワイルドカードを使う場合は、DNSゾーン側でも *.api.contoso.com のようなワイルドカードレコードを設計する必要があります。ただし、DNSプロバイダーや社内DNS運用ルールによって、ワイルドカードレコードの扱いが異なる場合があります。
事前に確認すべき点は次の通りです。
| 項目 | 確認内容 |
|---|---|
| ワイルドカードDNSの可否 | DNSプロバイダーが *.api.contoso.com のようなレコードを許可するか |
| CNAMEの向き先 | APIMの既定Gatewayホスト名に向いているか |
| 既存レコードとの競合 | payments.api.contoso.com などの個別レコードが残っていないか |
| TTL | 切り替え時に影響を短くするため、事前にTTLを調整するか |
| 内部DNSとの関係 | 社内向け名前解決と公開DNSで差異がないか |
失敗しやすいのは、APIM側だけワイルドカードを設定して、DNS側のワイルドカードレコードを忘れるパターンです。逆に、DNSだけ設定しても、APIM側に一致するカスタムホスト名がなければ、リクエストは期待通り処理されません。
証明書の種類を確認する
ワイルドカード カスタムホスト名を使う場合、通常は対象ドメインに合うワイルドカード証明書が必要です。Microsoft Learn では、API Management のカスタムドメイン証明書として、カスタムTLS証明書、Azure Key Vault からインポートした証明書、無料のマネージド証明書が説明されています。(Microsoft Learn)
実務では、ワイルドカード運用には Azure Key Vault を使った証明書管理が向いています。証明書の期限切れや秘密鍵ファイルの手作業アップロードを避けやすいためです。
| 証明書管理方法 | 向いているケース | 注意点 |
|---|---|---|
| PFXアップロード | 小規模、更新頻度が低い | 更新忘れ、手作業ミスに注意 |
| Azure Key Vault | 本番運用、複数環境、監査重視 | APIMのマネージドID権限が必要 |
| マネージド証明書 | 証明書管理を簡略化したい場合 | v2レベルでは制限や時期による注意があるため要確認 |
Microsoft Learn では、Key Vault証明書を使う場合、API Management が証明書を取得するために Key Vault への適切な権限を持つ必要があることも説明されています。(Microsoft Learn)
v2 レベルの公開DNS要件を確認する
Standard v2 と Premium v2 のカスタムドメインでは、Gatewayエンドポイントへのトラフィックを許可するために、カスタムドメイン名が公開DNSで解決できる必要があると説明されています。プライベートDNSゾーンだけに制限された名前は、そのままでは利用できない点に注意が必要です。(Microsoft Learn)
これは、閉域ネットワークでAPIを公開している組織にとって重要です。たとえば、社内専用の payments.api.internal.contoso.com のような名前をプライベートDNSだけで運用している場合、v2レベルのカスタムドメイン要件と合わない可能性があります。
この場合は、Application Gateway などを前段に置いて、プライベート側の名前で受けた通信を APIM の Gateway エンドポイントへルーティングする設計を検討します。ただし、その場合もホストヘッダーや証明書終端位置を慎重に設計する必要があります。
開発者が確認すべきポイント
開発者にとって今回の更新は、単に「APIのURLが増やしやすくなる」だけではありません。APIクライアント、CORS、認証、リダイレクトURL、テスト環境のURL設計にも影響します。
APIクライアントがホスト名を固定していないか確認する
アプリケーション側でAPIのベースURLを固定している場合、ワイルドカード化に伴って接続先URLの扱いを見直す必要があります。
たとえば、次のような実装は注意が必要です。
https://payments.api.contoso.com/v1/transactionsこれを環境変数や設定ファイルで管理していれば変更は比較的容易です。一方、コード内に複数箇所ハードコードされている場合、サブドメイン追加やドメイン統合のたびに修正漏れが発生します。
推奨される考え方は次の通りです。
| 悪い例 | 改善例 |
|---|---|
| コード内にAPI URLを直接記述 | 環境変数や設定ファイルで管理 |
| サブドメイン命名がチームごとにバラバラ | サービス名.api.example.com など命名規則を統一 |
| 本番・検証でURL規則が異なる | dev、stg、prod など環境を含めた規則を作る |
ワイルドカード対応を機に、APIベースURLの設定管理を整理しておくと、今後のAPI追加や環境分離が楽になります。
CORSと開発者ポータルの動作を確認する
API Management の開発者ポータルにカスタムドメインを設定する場合、Microsoft Learn では、新しいドメイン名に対してCORSを有効化できることが説明されています。これは、開発者ポータル上のAPIリファレンスからインタラクティブにAPIを試す場合に関係します。(Microsoft Learn)
ワイルドカード化によってAPI呼び出し元やポータルURLが変わる場合、ブラウザからの呼び出しでCORSエラーが出ることがあります。
確認すべき項目は次の通りです。
| 確認項目 | 例 |
|---|---|
| 許可オリジン | https://portal.contoso.com、https://dev.portal.contoso.com |
| API Gateway URL | https://payments.api.contoso.com など |
| 認証フロー | OAuth2、OpenID Connect、Entra ID のリダイレクトURI |
| Cookie設定 | SameSite、Secure、ドメイン属性 |
| ブラウザ検証 | 開発者ツールでプリフライトリクエストを確認 |
特にOAuth2やOpenID Connectを使っている場合、リダイレクトURIに旧ドメインが残っているとログイン後に失敗します。API Gateway の変更だけでなく、認証プロバイダー側の登録も確認してください。
サブドメイン単位のルーティングをどう扱うか決める
ワイルドカードホスト名を使うと、複数のサブドメインをAPIMで受けやすくなります。ただし、どのAPIにルーティングするか、どのポリシーを適用するかは別途設計が必要です。
たとえば、次のような方針を決めておくと運用しやすくなります。
| 設計項目 | 判断例 |
|---|---|
| サブドメイン命名 | サービス名.api.contoso.com に統一する |
| API単位の分離 | APIMのAPI、製品、タグ、ワークスペースで管理する |
| 認証方式 | 全API共通か、サービスごとに分けるか |
| レート制限 | サブドメイン別、サブスクリプション別、API別のどれで制御するか |
| ログ分析 | ホスト名をログに残し、サブドメイン別に集計できるようにする |
ワイルドカードは入口を広げる機能です。入口の先で、どのAPIにどう振り分け、どのポリシーを適用するかを決めておかないと、トラブル時の切り分けが難しくなります。
移行・展開時のおすすめ手順
既存の個別カスタムドメインをワイルドカードへ整理する場合、いきなり本番切り替えをするのは避けるべきです。DNSと証明書が絡むため、段階的に確認するのが安全です。
推奨ステップ
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状棚卸し | 既存のカスタムホスト名、証明書、DNS、利用APIを一覧化 | どのURLが実利用されているか |
| 命名規則を決める | *.api.contoso.com など対象範囲を決める | 既存ドメインと競合しないか |
| 証明書を準備 | ワイルドカード証明書を用意し、必要なら Key Vault に格納 | SAN、期限、秘密鍵、チェーン |
| DNSを準備 | ワイルドカードCNAMEなどを設定 | 名前解決、TTL、既存レコード |
| APIMへ追加 | ワイルドカード カスタムホスト名を設定 | Gatewayに正しく紐づくか |
| 検証用サブドメインで疎通 | test.api.contoso.com などで確認 | TLS、HTTPステータス、APIMログ |
| 段階移行 | 既存APIを順次新ルールへ寄せる | クライアント影響、CORS、認証 |
| 旧設定整理 | 不要な個別ホスト名や証明書を削除 | 参照中のクライアントが残っていないか |
本番環境では、既存の個別ホスト名をすぐに削除せず、一定期間は並行稼働させるのが安全です。アクセスログを見て旧URLの利用がなくなったことを確認してから整理しましょう。
curlで最低限確認したいこと
展開後は、ブラウザだけでなくコマンドラインでも確認すると原因切り分けがしやすくなります。
curl -I https://payments.api.contoso.com/health確認すべきポイントは次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| DNS解決 | 期待するAPIMまたは前段サービスに向いているか |
| TLS証明書 | ワイルドカード証明書が返るか |
| HTTPステータス | 200、401、403、404など意図した応答か |
| Hostヘッダー | 前段サービスで書き換えられていないか |
| APIMログ | 対象リクエストがAPIMまで届いているか |
curl でTLSエラーが出る場合は証明書、404 や 403 が返る場合はAPIMのホスト名設定やポリシー、前段で失敗する場合はFront DoorやApplication Gatewayのルーティングを疑います。
よくある失敗と対策
ワイルドカード カスタムホスト名は便利ですが、設定対象が広がるぶん、誤設定時の影響範囲も広がります。特に次の失敗は起こりやすいです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| DNSは引けるのにAPIMが応答しない | APIM側に一致するカスタムホスト名がない | APIMのCustom domains設定を確認 |
| TLS証明書エラーになる | 証明書が *.api.contoso.com に一致していない | 証明書のCN/SANを確認 |
| 特定サブドメインだけ別証明書になる | 個別サブドメイン設定が優先されている | 個別設定の意図を確認 |
| Front Door経由で失敗する | Hostヘッダーが書き換わっている | 元のHostヘッダーを保持する設定を確認 |
| 社内専用DNSで使えない | v2レベルで公開DNS解決が必要 | Application Gatewayなどの構成を検討 |
| 証明書更新後に反映されない | Key Vault権限や同期に問題がある | マネージドID権限と証明書同期ログを確認 |
| CORSエラーが出る | 呼び出し元ドメインが変わった | 許可オリジンとポリシーを更新 |
| 旧URL利用者が残る | クライアント側が旧ドメインを固定 | ログ確認と移行期間の設定 |
Microsoft Learn では、API Management はGatewayの既定ドメイン名、または構成済みのGatewayカスタムドメイン名に一致するHostヘッダーを持つリクエストを受け付けると説明されています。つまり、前段サービスでHostヘッダーが変わると、APIM側で意図通り処理されない可能性があります。(Microsoft Learn)
Front Door や Application Gateway を使う場合の注意点
Azure API Management の前段に Azure Front Door、Application Gateway、Traffic Manager、WAF などを置いている場合、ワイルドカード対応の確認ポイントは増えます。
Hostヘッダーを保持する
APIMは受信リクエストのHostヘッダーと、設定済みのカスタムドメイン名を照合します。そのため、前段サービスがHostヘッダーをAPIM既定ドメインなどに書き換えてしまうと、ワイルドカードホスト名を設定していても期待通りに扱えないことがあります。
確認すべきポイントは次の通りです。
| レイヤー | 確認内容 |
|---|---|
| Azure Front Door | オリジンへ転送するHostヘッダーをどう扱うか |
| Application Gateway | HTTP設定でホスト名を上書きしていないか |
| WAF | ワイルドカード配下のサブドメインを許可しているか |
| APIM | 実際に到達するHostヘッダーとカスタムホスト名が一致するか |
Microsoft Learn でも、内部VNet構成などでFront DoorやApplication Gatewayを使う場合、ターゲットのカスタムドメイン/ホスト名をAPIMまで保持する必要があると説明されています。(Microsoft Learn)
TLS終端位置を明確にする
TLSをどこで終端するかも重要です。
| 構成 | 注意点 |
|---|---|
| Front DoorでTLS終端 | Front Door側の証明書とAPIM側への通信方式を確認 |
| Front DoorからAPIMまでHTTPS | APIM側にも一致する証明書とホスト名が必要 |
| Application GatewayでTLS終端 | バックエンド設定とHostヘッダーの扱いを確認 |
| エンドツーエンドTLS | 前段とAPIMの両方で証明書・名前解決を整合させる |
ワイルドカード証明書を1つにまとめても、前段サービス側とAPIM側で別々に証明書管理が必要な構成もあります。「証明書が1枚で済む」と思い込まず、通信経路ごとにどの証明書が使われるかを確認してください。
セキュリティとガバナンスで見直すべき点
ワイルドカード カスタムホスト名は運用を簡単にしますが、同時に「どのサブドメインを誰が作れるのか」「作ったサブドメインにどのAPIを公開してよいのか」という統制が重要になります。
サブドメインの命名ルールを決める
ワイルドカードを導入する前に、命名ルールを明文化しておくべきです。
たとえば、次のようなルールです。
| ルール | 例 |
|---|---|
| サービス名を使う | payments.api.contoso.com |
| 環境名を含める | payments.dev.api.contoso.com |
| 地域名を含める | orders.jp.api.contoso.com |
| テナント名を含める | tenant-a.api.contoso.com |
命名ルールがないままワイルドカードを使うと、似た名前のAPIが乱立し、棚卸しや監査が難しくなります。APIの入口が増えやすくなるからこそ、命名、所有者、用途、公開範囲を管理する台帳が必要です。
証明書の権限を絞る
ワイルドカード証明書は、多数のサブドメインをカバーします。便利な反面、秘密鍵の取り扱いを誤ると影響範囲が広くなります。
実務では、次の対策を推奨します。
| 対策 | 内容 |
|---|---|
| Key Vaultで管理 | PFXファイルの配布を避ける |
| マネージドIDを使う | APIMが必要な範囲で証明書を取得できるようにする |
| 権限を最小化 | 証明書を更新できる担当者を限定 |
| 更新監視 | 有効期限アラートを設定 |
| 監査ログ | 証明書アクセスと変更履歴を確認できるようにする |
Microsoft Learn でも、Key Vault証明書を使う場合は、証明書やKey Vault、アクセスに使うマネージドIDを削除しないよう注意が示されています。(Microsoft Learn)
ポリシー適用単位を整理する
ワイルドカード配下に複数APIを置く場合、APIMポリシーの適用単位も整理してください。
| ポリシー | 検討ポイント |
|---|---|
| 認証・認可 | 全API共通か、APIごとか |
| レート制限 | サブスクリプション単位か、API単位か |
| IP制限 | 全サブドメイン共通でよいか |
| ログ出力 | ホスト名別に分析できるか |
| ヘッダー制御 | クライアントや前段サービスと整合しているか |
ワイルドカード化により入口が共通化されても、APIごとのセキュリティ要件まで共通化できるとは限りません。特に決済、個人情報、社内限定APIなどは、個別の認可や監査要件を維持すべきです。
導入判断の基準
今回の更新を受けて、すべての組織がすぐにワイルドカードへ移行すべきとは限りません。導入判断では、APIの増加ペースと運用負荷を基準にすると判断しやすくなります。
| 判断軸 | ワイルドカード導入を検討すべき状態 |
|---|---|
| サブドメイン数 | 今後も継続的に増える |
| 証明書更新工数 | 複数証明書の期限管理が負担になっている |
| API追加頻度 | 月次または週次で新しいAPI公開がある |
| チーム数 | 複数チームがAPIMを共有している |
| テナント分離 | 顧客や事業部ごとにサブドメインを分けたい |
| 運用自動化 | IaCやCI/CDでAPIM設定を管理している |
反対に、API公開URLが少なく、証明書更新も年数回で問題ない場合は、既存の個別ホスト名運用を続ける方が安定することもあります。
管理者・開発者が次に取るべき行動
今回の Azure API Management Premium v2 / Standard v2 のワイルドカード カスタムホスト名対応は、API基盤を拡張しやすくする実用的な更新です。特に、APIサブドメインが増え続ける組織では、ホスト名登録や証明書更新の作業を減らし、より一貫したドメイン設計を取りやすくなります。
まず行うべきことは、すぐに本番へ適用することではありません。既存のカスタムドメイン、証明書、DNS、Front DoorやApplication Gatewayの有無、APIクライアント側のURL固定を棚卸ししてください。そのうえで、*.api.contoso.com のようなワイルドカードが本当に運用負荷を下げるかを判断します。
導入する場合は、検証用サブドメインでTLS、DNS、Hostヘッダー、APIMログ、CORS、認証フローを確認し、問題がなければ段階的に移行するのが安全です。ワイルドカードは「設定を減らす」ための機能ですが、設計を省略するための機能ではありません。APIの命名規則、証明書管理、ポリシー適用範囲まで含めて見直すことで、Azure API Management をよりスケールしやすいAPI公開基盤として活用できます。
コメント