Azure SDKのdomainregistration更新まとめ|Python移行と確認ポイント

Azure SDK documentation update: [AutoPR azure-mgmt-domainregistration]-generated-from-SDK Generation – Python-5916508 は、単なるドキュメント更新として流し読みしない方がよい変更です。結論から言うと、PythonでAzure App Serviceのドメイン登録・更新・更新期限管理・移管などを自動化している場合は、azure-mgmt-web から独立した azure-mgmt-domainregistration への移行準備を確認すべきです。一方、Azure DNSのレコード操作だけをしている、またはAzureポータル上で手作業管理しているだけなら、今すぐコード修正が必要になる可能性は低めです。

今回の更新は、azure-mgmt-web に含まれていた一部領域を Microsoft.DomainRegistration/DomainRegistration として分離し、新しいPython向け管理ライブラリを用意する流れに関係しています。関連Issueでは、App Service関連仕様の一部をDomain RegistrationとCertificate Registrationへ分割し、それに合わせてSDKモジュールも新パッケージへ分割する方針が示されています。(GitHub)

目次

何が変わったのか:ドメイン登録管理が独立パッケージ化された

今回確認すべき中心は、azure-mgmt-domainregistration という新しいAzure SDK for Pythonの管理プレーンライブラリです。PyPIでは 1.0.0b1 がプレリリースとして公開され、Microsoft Learnにも azure.mgmt.domainregistration のリファレンスが追加されています。PyPI上の 1.0.0b1 は2026年4月29日にリリースされ、リリース履歴では初期版として扱われています。(PyPI)

PR #45322自体は、SDK生成パイプラインから作られたAutoPRで、構成ファイルとして specification/domainregistration/resource-manager/Microsoft.DomainRegistration/DomainRegistration/tspconfig.yaml、API Versionとして 2024-11-01、SDK Release Typeとして beta が記載されています。PRは2026年4月28日にclosedとなり、2026年5月3日に自動生成ブランチが削除されています。(GitHub)

確認項目内容実務上の意味
新パッケージazure-mgmt-domainregistrationドメイン登録管理を専用SDKで扱えるようになる
対象APIMicrosoft.DomainRegistration / API Version 2024-11-01既存のazure-mgmt-web配下の実装だけを前提にしない
リリース状態1.0.0b1、Beta本番導入前に検証環境での動作確認が必須
主な操作domainの取得、作成・更新、削除、更新、移管、所有権識別子、TLD確認などドメイン購入・管理系の自動化コードが影響を受けやすい
ドキュメントMicrosoft Learnにリファレンス追加実装時はPR差分ではなく最新の公式リファレンスを確認する

対応すべき人と、様子見でよい人

今回のAzure SDK documentation updateで優先的に確認すべきなのは、PythonでAzureのドメイン登録管理を自動化しているチームです。特に、App Serviceドメインの購入、更新、所有権識別子、トップレベルドメインの契約確認、ドメイン移管などをコード化している場合は、移行対象になり得ます。

利用状況対応優先度理由
azure.mgmt.web.WebSiteManagementClient で domains や top_level_domains を使っている高分割後の専用パッケージへ移す候補になる
TerraformやBicepではなく、Pythonスクリプトでドメイン登録を操作している高CI/CDや運用スクリプトがSDK変更の影響を受ける
Azureポータルでドメインを手作業管理している低SDKコードがなければ直接の修正対象は少ない
Azure DNSのAレコード、CNAME、TXTだけをPythonで操作している低〜中Domain RegistrationではなくDNS管理SDK側の話である可能性が高い
新規にApp Serviceドメイン管理の自動化を作る予定がある中〜高最初から新パッケージを前提に設計した方がよい

移行で最初に見るべき変更点

インポート元とクライアント名を確認する

現行のMicrosoft LearnとPyPIの説明では、利用するクライアントは DomainRegistrationMgmtClient です。サンプルでは azure.identity.DefaultAzureCredential と組み合わせ、AZURE_SUBSCRIPTION_ID を使って初期化する形が示されています。(Microsoft Learn)

from azure.identity import DefaultAzureCredential
from azure.mgmt.domainregistration import DomainRegistrationMgmtClient
import os

subscription_id = os.environ["AZURE_SUBSCRIPTION_ID"]

client = DomainRegistrationMgmtClient(
    credential=DefaultAzureCredential(),
    subscription_id=subscription_id,
)

既存コードが azure-mgmt-web のクライアント経由でドメイン関連操作を呼んでいる場合は、まず以下のように検索します。

grep -R "WebSiteManagementClient" .
grep -R "\.domains" .
grep -R "\.top_level_domains" .
grep -R "DomainRegistrationProvider" .

移行イメージは次のようになります。

# 旧:azure-mgmt-web 側でドメイン関連操作を呼ぶ例
from azure.mgmt.web import WebSiteManagementClient

web_client = WebSiteManagementClient(
    credential=credential,
    subscription_id=subscription_id,
)

domains = web_client.domains.list_by_resource_group("rg-example")
# 新:azure-mgmt-domainregistration 側へ分離する例
from azure.mgmt.domainregistration import DomainRegistrationMgmtClient

domain_client = DomainRegistrationMgmtClient(
    credential=credential,
    subscription_id=subscription_id,
)

domains = domain_client.domains.list_by_resource_group("rg-example")

注意したいのは、PRの初期差分だけを見ると DomainRegistrationClient という名前が出ている箇所がある一方、現行のMicrosoft Learnとリポジトリ上の実装では DomainRegistrationMgmtClient が使われている点です。移行時はPR差分の断片をコピーせず、インストール済みパッケージまたは最新リファレンスでクラス名を確認してください。(GitHub)

パッケージインストールは「プレリリース」に注意する

azure-mgmt-domainregistration では、PyPI上に 0.0.0 のプレースホルダー版と 1.0.0b1 のプレリリース版が存在します。通常の pip install azure-mgmt-domainregistration だけでは、環境や解決条件によって実コードを含まない 0.0.0 側を入れてしまうリスクがあります。PyPIでも 0.0.0 は「planning」扱いで、将来公開予定のプレースホルダーと説明されています。(PyPI)

検証目的で 1.0.0b1 を使うなら、明示的にバージョンを固定するのが安全です。

python -m pip install "azure-mgmt-domainregistration==1.0.0b1" azure-identity

または、プレリリースを許可してインストールします。

python -m pip install --pre azure-mgmt-domainregistration azure-identity

pipは標準では安定版を優先し、プレリリースや開発版を含めるには --pre などの指定が必要です。CI/CDで検証する場合は、requirements.txt やロックファイルに azure-mgmt-domainregistration==1.0.0b1 のように明示しておくと、意図しないバージョン解決を避けやすくなります。(pip)

Pythonバージョンは3.10以上で検証する

Microsoft LearnとPyPIの説明では、このパッケージはPython 3.10以上でテスト済みとされています。一方、PyPIのメタデータには Requires: Python >=3.9 も見えるため、3.9環境で使えるかどうかはプロジェクト側の実行テストで確認すべきです。新規導入なら、ドキュメント記載に合わせてPython 3.10以上を基準にした方が安全です。(Microsoft Learn)

python --version
python -m pip show azure-mgmt-domainregistration
python - <<'PY'
from azure.mgmt.domainregistration import DomainRegistrationMgmtClient
print(DomainRegistrationMgmtClient)
PY

操作範囲:どのAPIが使えるようになるか

DomainRegistrationMgmtClient には、domains、top_level_domains、domain_registration_provider という主要な操作グループがあります。クライアントの変数として、DomainsOperations、TopLevelDomainsOperations、DomainRegistrationProviderOperationsが公開されています。(Microsoft Learn)

domains:ドメイン登録の中心操作

domains では、ドメインの取得、作成・更新、削除、一覧、更新、移管、所有権識別子、空き状況確認、ドメイン名候補の取得などを扱えます。Microsoft Learnのリファレンスでは、check_availability、begin_create_or_update、delete、renew、transfer_out、list_recommendations などが確認できます。(Microsoft Learn)

代表的な確認コードは次の通りです。

for domain in client.domains.list_by_resource_group("rg-example"):
    print(domain.name)

ドメイン作成や削除は課金、契約、所有権確認、復旧可否に関わるため、いきなり本番サブスクリプションで実行しないでください。特に delete には force_hard_delete_domain というキーワード引数があり、即時削除の挙動に関わる可能性があります。リファレンスでは、既定では24時間後の削除、true 指定で即時削除する説明が記載されています。(Microsoft Learn)

top_level_domains:TLDと契約条件の確認

top_level_domains では、登録可能なトップレベルドメインの一覧、個別TLDの詳細、ドメイン購入前に受諾が必要な法的契約の取得を扱います。ドメイン購入を自動化する場合は、価格や在庫だけでなく、TLDごとの契約確認フローをテストに含める必要があります。(Microsoft Learn)

for tld in client.top_level_domains.list():
    print(tld.name)

domain_registration_provider:利用可能な操作の確認

domain_registration_provider.list_operations() は、リソースプロバイダー配下で利用できる操作メタデータを確認するためのメソッドです。権限設計や監査ログ設計で、どの操作が存在するかを棚卸しする際に役立ちます。(Microsoft Learn)

既存コードを移すときのチェックリスト

移行は「インストールして動けば完了」ではありません。ドメイン登録はアプリ停止、証明書、WHOIS情報、契約、課金に影響しやすいため、以下の順で確認すると失敗を減らせます。

手順確認内容具体的な作業
依存関係の棚卸しazure-mgmt-web でドメイン関連操作を使っていないかimport文、client.domains、client.top_level_domains を検索
パッケージ固定1.0.0b1 を明示しているかrequirements.txt やロックファイルにバージョンを記録
認証確認DefaultAzureCredential が期待通り動くかローカル、CI、Azure上の実行環境で認証方式を分けて検証
環境変数サブスクリプションIDとサービスプリンシパル情報があるかAZURE_SUBSCRIPTION_ID、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET を確認
権限ドメイン操作に必要なRBACがあるか読み取り、作成、更新、削除、移管で必要権限を分けて確認
モデル移行azure.mgmt.web.models からのimportが残っていないかazure.mgmt.domainregistration.models へ移す
破壊的操作削除、更新、移管を本番で誤実行しないかdry-run相当の確認処理、承認ステップ、対象名の明示を入れる
監視失敗時に検知できるかHttpResponseError のログ、操作対象ドメイン名、相関IDを記録

認証については、公式ドキュメントで AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET、AZURE_SUBSCRIPTION_ID を使った構成例が示されています。ローカル開発ではAzure CLIログイン、CIではサービスプリンシパル、Azure上ではマネージドIDなど、実行場所ごとに DefaultAzureCredential がどの資格情報を拾うかを明確にしておきましょう。(Microsoft Learn)

実務で失敗しやすいポイント

pip install だけで導入したつもりになる

今回もっとも起きやすいミスは、pip install azure-mgmt-domainregistration だけを実行し、実コードを含まない 0.0.0 を入れてしまうことです。検証時は必ず pip show とimportテストで、実際に 1.0.0b1 が入っているか確認してください。

python -m pip show azure-mgmt-domainregistration
python -c "from azure.mgmt.domainregistration import DomainRegistrationMgmtClient; print('ok')"

PR差分だけを見てクラス名を決める

AutoPRは生成途中の情報が含まれることがあります。今回も、PR差分の一部と現行ドキュメントでクライアント名が異なるように見えるため、最終的な実装確認が重要です。移行手順書を社内に展開する場合は、必ず「インストール済みパッケージでimport確認済み」のコードを載せてください。

Beta版を本番自動化にそのまま入れる

1.0.0b1 はBetaです。Beta版は将来の安定版でAPIやモデル名が変わる可能性があります。新規開発で検証する価値はありますが、ドメイン購入、削除、移管のような戻しにくい操作を本番ジョブへ組み込む場合は、バージョン固定、承認フロー、ログ、ロールバック手順をセットで用意するべきです。

モデルのimport元を見落とす

クライアントだけでなく、Domain、DomainPatchResource、NameIdentifier、DomainOwnershipIdentifier などのモデルもimport元が変わる可能性があります。既存コードで次のようなimportがある場合は要確認です。

from azure.mgmt.web.models import Domain

移行後は、用途に応じて新パッケージ側のモデルを使います。

from azure.mgmt.domainregistration.models import Domain

ただし、モデルの必須フィールドやサーバー側でのみ設定されるフィールドは変更される可能性があります。既存のJSONペイロードをそのまま流用せず、作成・更新・パッチの各操作で必要なフィールドを改めて確認してください。

検証環境で実行したい最小テスト

本番移行前に、少なくとも以下のテストを行うと安全です。

from azure.identity import DefaultAzureCredential
from azure.mgmt.domainregistration import DomainRegistrationMgmtClient
import os

client = DomainRegistrationMgmtClient(
    credential=DefaultAzureCredential(),
    subscription_id=os.environ["AZURE_SUBSCRIPTION_ID"],
)

# サブスクリプション内のドメイン一覧を取得
for domain in client.domains.list():
    print(domain.name)

続いて、対象リソースグループを限定して確認します。

resource_group_name = "rg-example"

for domain in client.domains.list_by_resource_group(resource_group_name):
    print(domain.name)

この段階で見るべきポイントは、単にエラーが出ないことではありません。認証に使われたID、対象サブスクリプション、取得されるドメイン数、例外発生時のログ、CI環境での再現性まで確認してください。特に複数サブスクリプションを扱う運用では、AZURE_SUBSCRIPTION_ID の取り違えが実害につながります。

今回の更新をどう判断すべきか

今回のAzure SDK documentation updateは、Azure SDK for Pythonのドメイン登録管理が専用パッケージへ切り出される流れを示す重要な更新です。すぐに全員が本番移行する段階というより、既存の azure-mgmt-web 依存コードを棚卸しし、新パッケージで同等操作ができるか検証するタイミングと見るのが現実的です。

まずやるべきことは、次の3つです。

  • azure-mgmt-web でドメイン関連操作を使っている箇所を検索する
  • 検証環境で azure-mgmt-domainregistration==1.0.0b1 を明示インストールし、importと一覧取得を確認する
  • 削除、更新、移管、契約確認のような影響の大きい操作は、本番反映前に承認フローとログ設計を見直す

新しいSDKは、ドメイン登録管理をApp Service全体の巨大な管理クライアントから分離できる点で扱いやすくなります。ただし、現時点ではBeta版であり、PyPI上のプレースホルダー版やクライアント名の確認など、導入時に踏みやすい落とし穴もあります。移行は急がず、まずは依存関係の棚卸し、バージョン固定、最小APIテストから始めるのが安全です。

この記事を書いた人

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

コメント

コメントする

目次