Azure API Management Premium v2で複数カスタムドメインが一般提供されたことで、1つのAPI Managementインスタンスに対して、用途や組織、ブランドごとに異なるドメインを割り当てやすくなりました。たとえば、外部パートナー向けにapi.contoso.com、社内HRシステム向けにapis.hrportal.contoso.com、開発者ポータル向けにdevelopers.contoso.comを使い分ける、といった構成が現実的になります。
結論から言えば、この更新は「複数のAPI公開面を、別々のAPI Managementインスタンスに分けずに整理したい企業」に特に有効です。ただし、DNS、TLS証明書、Azure Key Vault、CORS、上流のAzure Front DoorやApplication GatewayのHostヘッダー設定を誤ると、ドメインを追加しても通信できない、証明書エラーになる、開発者ポータルのテスト実行が失敗する、といったトラブルにつながります。
2026年6月のAzure Updatesでは、この機能は「Launched / General Availability」として扱われています。Azure Updates上のLaunchedは、Azure顧客向けに完全リリースされ、本番利用可能な状態を示す区分です。(Microsoft Azure)
Microsoft AzureのAPI Management更新で何が変わるのか
今回の更新は、Azure API Management Premium v2で複数のカスタムドメインを利用できるようになった点が中心です。従来、部門別・ブランド別・地域別に異なるドメインでAPIを公開したい場合、設計によっては複数のAPI Managementインスタンスを用意したり、Application Gatewayなどの前段サービスで複雑に振り分けたりする必要がありました。
Premium v2の1つのインスタンスで複数ドメインを扱えるようになると、APIポリシー、認証、監視、開発者ポータル運用を一元管理しながら、利用者には用途に合った分かりやすいドメインを提示できます。
| 観点 | これまで起こりやすかった課題 | 今回の更新で期待できる改善 |
|---|---|---|
| ドメイン設計 | 1つの代表ドメインにAPIを集約し、用途が分かりにくい | 部門・ブランド・利用者種別ごとにドメインを分けやすい |
| 運用コスト | 複数インスタンス運用で設定・証明書・監視が分散する | 1つのPremium v2インスタンスに集約しやすい |
| 開発者体験 | API利用者が目的のAPI公開面を判断しにくい | 外部向け、社内向け、地域向けなどをURLで区別しやすい |
| ガバナンス | インスタンスごとにポリシーや監査設定がばらつく | API Management配下で統制しやすい |
重要なのは、カスタムドメインの追加は単なる見た目の変更ではないという点です。APIの入口が増えるため、DNS、証明書、認証、監視、ログ分析、クライアント設定まで含めて確認する必要があります。
複数カスタムドメインが役立つ具体的なシーン
Azure API Management Premium v2の複数カスタムドメイン対応は、大規模組織ほど効果が出やすい機能です。特に、APIの利用者が社外・社内・グループ会社・地域拠点に分かれている場合、ドメインを分けることで運用と利用者体験の両方を改善できます。
外部パートナー向けAPIと社内APIを分ける
外部パートナーにはapi.partner.example.com、社内システムにはapi.internal.example.comのように別ドメインを用意すると、利用者は接続先の目的を理解しやすくなります。
ただし、ドメインを分けただけではセキュリティ境界にはなりません。外部向けAPIにはサブスクリプションキー、OAuth 2.0、JWT検証、IP制限、レート制限などのポリシーを適切に設定する必要があります。
部門やサービスブランドごとにAPI公開面を分ける
人事、経理、販売、物流などの部門別にAPIを公開している場合、すべてをapi.example.com配下にまとめると、API利用者が対象APIを見つけにくくなることがあります。
たとえば、HR関連はapis.hr.example.com、決済関連はpayments.api.example.comのように分けると、APIカタログやドキュメントの導線も整理しやすくなります。
開発者ポータルのブランドを分ける
API Gatewayだけでなく、開発者ポータル側のドメイン設計も重要です。社外開発者向けポータル、社内開発者向けポータル、地域別ポータルを分けたい場合、カスタムドメインを使うことで、利用者にとって自然な入口を作れます。
Microsoft Learnのカスタムドメイン設定ドキュメントでは、API呼び出しに使われるGatewayと、開発者ポータルはよくカスタムドメイン化されるエンドポイントとして説明されています。(Microsoft Learn)
対象になる環境と影響範囲
今回の主な対象はAzure API Management Premium v2です。Azure API ManagementにはClassic tiers、Consumption、Basic v2、Standard v2、Premium v2など複数のSKUがあるため、「Azure API Managementならすべて同じように複数カスタムドメインを使える」と考えるのは危険です。
Microsoft Learnでは、v2 tiersはBasic v2、Standard v2、Premium v2に適用される新しいSKU群であり、Premium v2は仮想ネットワーク分離、高ボリュームワークロード向けのスケーリング、Availability Zonesなどのエンタープライズ機能を提供する階層として説明されています。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 利用SKU | 対象インスタンスがPremium v2か確認する |
| 対象エンドポイント | Gateway、Developer portal、Managementなど、実際に設定したいエンドポイントがSKUで対応しているか確認する |
| DNSの公開性 | v2 tiersのGatewayカスタムドメインでは、公開解決可能なDNS名が必要になる点を確認する |
| 証明書方式 | PFXアップロード、Azure Key Vault連携、マネージド証明書の可否を確認する |
| 既存移行 | Classic tierからv2 tierへ自動移行できる前提で計画しない |
| 前段サービス | Front Door、Application Gateway、Traffic ManagerなどでHostヘッダーを維持できているか確認する |
特に注意したいのは、v2 tiersではClassic tierと完全に同じ機能が使えるわけではない点です。Microsoft Learnでは、v2 tiersで現在利用できない機能として、マルチリージョン展開、API Managementサービス構成のGit利用、バックアップと復元、Classic tierからv2 tierへのアップグレード、セルフホストゲートウェイ、無料マネージドTLS証明書などが挙げられています。(Microsoft Learn)
管理者が確認すべき設定
DNSはCNAMEを基本にし、v2 tiersでは公開解決性を確認する
カスタムドメインを追加するには、DNS側でカスタムドメインをAPI Managementの既定ホスト名へ向ける必要があります。Microsoft Learnでは、カスタムドメインからAPI Managementサービスホスト名へCNAMEレコードを設定する方法が説明されており、IPアドレス変更に備える意味でもCNAMEのほうが安定しやすいとされています。(Microsoft Learn)
Premium v2で特に注意すべきなのは、Gatewayエンドポイントにカスタムドメインを設定する場合、そのDNS名が公開解決可能である必要がある点です。プライベートDNSゾーンだけに閉じた名前では、v2 tiersのGatewayトラフィックで問題になる可能性があります。Microsoft Learnでは、Standard v2とPremium v2ではGatewayに対して公開解決可能なDNS名が必要であり、プライベートドメインを使う場合の回避策としてApplication Gatewayで受けてAPI Managementへルーティングする構成が示されています。(Microsoft Learn)
TLS証明書はSAN、秘密鍵、Key Vault権限まで確認する
カスタムドメインを本番で使う場合、TLS証明書の管理が運用品質を左右します。証明書のSubjectまたはSANが対象ドメインと一致していないと、ブラウザやAPIクライアントで証明書エラーになります。
証明書の選択肢は、主に次の3つです。
| 証明書方式 | 向いているケース | 注意点 |
|---|---|---|
| PFXファイルをアップロード | 小規模構成、証明書更新頻度が低い環境 | 更新漏れや秘密鍵管理に注意 |
| Azure Key Vault連携 | 本番環境、複数ドメイン、証明書自動更新を重視する環境 | API ManagementのマネージドIDにKey Vault参照権限が必要 |
| マネージド証明書 | 証明書管理を簡素化したい場合 | v2 tiersではサポート状況に制約があるため要確認 |
Microsoft Learnでは、API ManagementでカスタムTLS証明書やAzure Key Vaultからインポートした証明書を利用できること、Key Vaultを使う場合は証明書をsecretではなくcertificateとして挿入すること、API Managementが証明書を取得するためにKey Vaultへの権限が必要であることが説明されています。(Microsoft Learn)
また、2026年6月時点では、API Managementの無料マネージドTLS証明書について制約があります。Microsoft Learnでは、無料マネージド証明書はGatewayエンドポイントのみ、v2 tiersでは未サポートと説明されており、さらにマネージド証明書の新規作成は2025年8月15日から2026年6月30日まで一時的に利用不可とされています。(Microsoft Learn)
Hostヘッダーを変更するとAPI Management側で拒否されることがある
Azure Front Door、Application Gateway、Traffic Managerなどを前段に置いている構成では、Hostヘッダーの扱いを必ず確認してください。
API Managementは、Gatewayの既定ドメイン名または構成済みカスタムドメイン名に一致するHostヘッダーのリクエストを受け付けます。Microsoft Learnでも、HostヘッダーがAPI Managementに設定されたカスタムドメインと一致しない場合、リクエストが拒否されることが説明されています。(Microsoft Learn)
よくある失敗は、前段のApplication Gatewayでバックエンドホスト名に書き換えてしまい、API Managementへ到達した時点でHostがapi.contoso.comではなく既定ホスト名や別名になっているケースです。複数ドメインを使う場合は、ドメインごとにHostヘッダーが維持されているかをテストしてください。
開発者ポータルではCORSと既定URLの扱いに注意する
開発者ポータルをカスタムドメイン化する場合、APIリファレンスページの対話型コンソールを使うためにCORS設定が必要になる場合があります。Microsoft Learnでは、Developer portalにカスタムドメインを設定する際、新しいドメインに対してCORSを有効化できることが説明されています。(Microsoft Learn)
また、Gatewayの既定エンドポイントはカスタムドメイン設定後も残りますが、Developer portalなど他のエンドポイントでは、カスタムドメインを設定すると既定エンドポイントが利用できなくなる扱いがあります。既存のブックマーク、社内ポータル、API利用手順書、OAuthのリダイレクトURIに古いDeveloper portal URLが残っていないか確認しましょう。(Microsoft Learn)
変更反映には時間がかかる前提で作業枠を確保する
カスタムドメインや証明書の変更は、API定義の軽微な修正とは違い、API Managementサービスのインフラ構成変更に該当します。Microsoft Learnでは、カスタムドメイン、CA証明書、スケーリング、仮想ネットワーク設定などのインフラ変更は、サービス階層や展開規模によって15分以上かかる場合があると説明されています。(Microsoft Learn)
本番環境では、DNS TTLを事前に短くする、証明書の有効期限を確認する、疎通確認用APIを用意する、ロールバック手順を決める、といった準備をしてから作業するのが安全です。
開発者が確認すべき影響
複数カスタムドメイン対応は管理者向けの設定に見えますが、API利用者やアプリ開発者にも影響します。特に、APIのベースURLが変わる場合は、環境変数、SDK、OpenAPI定義、OAuth設定、CORS設定を確認する必要があります。
| 確認対象 | 変更が必要になりやすい内容 |
|---|---|
| アプリケーション設定 | APIベースURL、環境変数、接続先ドメイン |
| OpenAPI定義 | server URL、ドキュメント上のエンドポイント例 |
| OAuth / OIDC | リダイレクトURI、許可済みオリジン、IssuerやAudienceの検証条件 |
| CORS | フロントエンドアプリのOrigin追加 |
| SDK・CLI | 生成済みクライアントの接続先再生成または設定変更 |
| 監視・テスト | ヘルスチェックURL、Synthetic monitoring、アラート条件 |
| セキュリティポリシー | JWT検証、サブスクリプション、IP制限、レート制限の適用範囲 |
ドメインを分けると、利用者にとっては分かりやすくなります。一方で、運用側が「どのドメインにどのAPIを公開しているか」を管理できていないと、古いURLが残り続けたり、認証設定がドメイン間で不一致になったりします。
実務では、APIごとに「正式ドメイン」「旧ドメイン」「廃止予定日」「利用者通知先」「監視対象」を一覧化しておくと、移行後の問い合わせを減らせます。
移行・展開時のおすすめ手順
既存のAPI Management環境からPremium v2へ移行する場合は、単純なSKU変更として考えないほうが安全です。Microsoft Learnでは、既存のConsumption、Developer、Basic、Standard、Premium tierのAPI Managementインスタンスをv2 tierへ自動移行するツールは現在なく、v2 tiersは新規作成インスタンス向けと説明されています。(Microsoft Learn)
そのため、実務ではサイドバイサイド方式で新しいPremium v2インスタンスを用意し、設定とAPIを段階的に移す進め方が現実的です。
| フェーズ | 実施内容 | 失敗を防ぐポイント |
|---|---|---|
| 現状調査 | 既存ドメイン、証明書、API、ポリシー、利用者を棚卸し | 使われていないように見える旧URLもアクセスログで確認する |
| 設計 | ドメイン命名、証明書方式、DNS、前段構成を決める | ワイルドカード証明書と個別証明書の優先関係を整理する |
| 構築 | Premium v2インスタンス、API、Products、Policiesを作成 | Gitベース構成やバックアップ復元が使えない前提でIaC化する |
| 検証 | ドメイン別にTLS、Hostヘッダー、認証、CORS、監視を確認 | ブラウザだけでなくAPIクライアント、古いランタイムでも確認する |
| 切り替え | DNS TTLを下げて段階的にCNAMEを切り替える | 重要APIは利用者単位で移行日を分ける |
| 安定化 | ログ、失敗率、証明書同期、利用者問い合わせを監視 | 旧ドメインの廃止日を明示し、並行稼働を長引かせすぎない |
Premium v2への移行では、複数カスタムドメインだけを見て判断しないことも大切です。v2 tiersでは高速なデプロイやスケーリング、ネットワーク分離などのメリットがある一方、Classic tierで利用していた一部機能が未対応の場合があります。既存環境でセルフホストゲートウェイ、バックアップと復元、Gitベースのサービス構成、マルチリージョン展開を使っている場合は、代替策を先に決めてください。
ワイルドカードカスタムホスト名との違い
同時期のAzure API Management v2関連更新では、ワイルドカードカスタムホスト名も注目されています。ただし、複数カスタムドメイン対応とワイルドカード対応は同じ意味ではありません。
| 機能 | 目的 | 例 |
|---|---|---|
| 複数カスタムドメイン | 異なるドメインやサブドメインを複数登録して使い分ける | api.contoso.com、api.fabrikam.com、developers.contoso.com |
| ワイルドカードカスタムホスト名 | 多数のサブドメインをまとめて扱う | *.api.contoso.com |
ワイルドカードは、サブドメインが大量に増えるAPI群で証明書やホスト名管理を簡素化するのに向いています。一方、ブランドや組織が異なる複数ドメインを明確に分けたい場合は、複数カスタムドメインの設計が重要になります。
Microsoft Learnでは、ワイルドカードドメイン名はDeveloper、Basic、Standard、Standard v2、Premium、Premium v2でサポートされ、特定サブドメインの証明書はワイルドカード証明書より優先されると説明されています。(Microsoft Learn)
失敗しやすいポイント
複数カスタムドメイン対応で特に多い失敗は、機能そのものより周辺設定にあります。以下の項目は、本番反映前に必ず確認してください。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| カスタムドメインでアクセスできない | DNSが公開解決できない、CNAME先が誤っている | v2 tiersの公開DNS要件を確認し、外部DNSから名前解決をテストする |
| 証明書エラーになる | SAN不一致、中間証明書不足、期限切れ | 対象ホスト名を含む証明書を使い、更新日を監視する |
| Key Vault証明書が同期されない | マネージドIDの権限不足 | API ManagementのIDにKey Vault参照権限を付与する |
| Front Door経由で失敗する | Hostヘッダーが書き換えられている | 元のHostヘッダーを維持する設定にする |
| 開発者ポータルのテスト実行が失敗する | CORS設定が不足している | 新しいポータルドメインを許可Originに追加する |
| 旧URLへのアクセスが残る | 利用者通知やSDK更新が漏れている | ログで旧ドメイン利用者を特定し、段階的に廃止する |
| ドメイン分離をセキュリティ分離と誤解する | ポリシーや認証を共通のままにしている | ドメイン別ではなくAPI・Product・利用者単位で認可を設計する |
まず実施すべきチェックリスト
Azure API Management Premium v2で複数カスタムドメインを使う予定がある場合、最初にやるべきことは「追加したいドメインをAzure portalに登録すること」ではありません。先に、運用上の責任範囲と切り替え計画を整理することが重要です。
- 追加したいドメイン名と用途を一覧化する
- Gateway、Developer portal、Managementなど、どのエンドポイントに割り当てるか決める
- 対象インスタンスがPremium v2であることを確認する
- DNSが公開解決可能か確認する
- CNAMEの向き先を確認する
- 証明書のSAN、秘密鍵、中間証明書、有効期限を確認する
- Azure Key Vaultを使う場合はマネージドIDと権限を確認する
- Azure Front DoorやApplication GatewayでHostヘッダーを維持する
- OAuth、CORS、OpenAPI、SDK、監視設定の変更点を洗い出す
- DNS切り替え前にTTLを下げ、ロールバック手順を決める
- 旧ドメインの廃止日と利用者通知の文面を用意する
この更新は、API公開基盤を整理したい組織にとって実用性の高い改善です。複数のドメインを1つのPremium v2インスタンスで扱えるようになることで、API利用者には分かりやすい入口を提供しつつ、管理者はポリシー、証明書、監視、開発者ポータルを集約しやすくなります。
一方で、ドメイン追加はDNSと証明書だけの作業ではありません。Hostヘッダー、CORS、OAuth、監視、既存クライアント、v2 tiersの未対応機能まで確認しておくことで、本番切り替え時のトラブルを大きく減らせます。まずは現在のAPIドメインと証明書を棚卸しし、Premium v2に集約する価値があるAPI群から段階的に検証するのが安全です。
コメント