Azure SDK documentation updateとして確認すべき結論は、azure-mgmt-securityを使うPythonアプリでは、まだ本番コードを急いで書き換える段階ではないものの、8.x系、とくにTypeSpec生成版へ移行する前に、クライアント名・モデル名・メソッド引数・戻り値の扱いを必ず棚卸しする必要があるという点です。
今回の更新は、Azure Security Center / Microsoft Defender for Cloud関連の管理プレーンSDKであるazure-mgmt-securityについて、従来のSwaggerベースの生成からTypeSpecベースの生成へ移行する流れに関するものです。2026年5月5日時点のPython SDK側PRはOpenで、レビュー待ちの状態でした。一方、元になるREST API仕様側のTypeSpec移行PRは2026年4月28日にマージされています。つまり、仕様側の移行は進んでいるものの、Python SDKとして利用者が取り込む段階では、PRのマージ状況とPyPIへの公開状況を分けて確認することが重要です。(GitHub)
今回のAzure SDK documentation updateで何が変わるのか
今回の中心は、Python向け管理ライブラリazure-mgmt-securityの生成元がTypeSpecへ移行されることです。TypeSpecは、クラウドサービスAPIを記述し、OpenAPI仕様やクライアントコード、ドキュメントなどを生成するためのMicrosoftの言語・ツールセットです。Azure REST API specsリポジトリでは、TypeSpec仕様がOpenAPI 2.0、つまりSwagger APIドキュメントを生成するソースとして位置付けられています。(GitHub)
この変更は「SDKの内部生成方式が変わるだけ」と軽く見ないほうがよい更新です。生成元が変わると、Python SDKで公開されるクラス名、モデル名、列挙型、操作メソッド、引数の順序やキーワード専用引数、一覧取得時の戻り値などに差分が出る可能性があります。
特にazure-mgmt-securityは、Defender for Cloud、セキュリティ評価、セキュリティコネクタ、Secure Score、脆弱性評価、Private Link、IoT Securityなど、多数の機能領域を含む管理プレーンSDKです。REST API仕様側のPRでは、単一の最新タグだけを変換するのではなく、複数のTypeSpecプロジェクトとして移行対象が整理されています。対象にはAssessment、SecurityConnectors、Pricings、PrivateLinks、SecureScore、SqlVulnerabilityAssessmentsなどが含まれます。(GitHub)
すぐに影響を受ける人、まだ様子見でよい人
今回のAzure SDK documentation updateで、最初に確認すべきなのは「自分のコードがどのバージョンを使っているか」です。
| 利用状況 | 影響度 | 取るべき対応 |
|---|---|---|
azure-mgmt-security 7.0.0など安定版を固定している | 低 | すぐに動作は変わりにくい。将来の8.x移行に備えて差分を確認 |
--preを使って8.x betaを検証している | 高 | PR・CHANGELOG・実コードで破壊的変更を確認し、テスト環境で検証 |
from azure.mgmt.security import SecurityCenterを使っている | 中〜高 | クライアント名変更の可能性を確認。移行用ラッパーを用意 |
| モデルクラスを直接importしている | 高 | 削除・リネームされたモデルに該当しないか確認 |
| Private LinkやSQL脆弱性評価の操作を使っている | 高 | メソッド引数の変更、順序変更、キーワード専用化を確認 |
| Azure PortalやREST APIだけを使っている | 低 | SDK利用コードがなければ直接影響は限定的 |
2026年5月時点のPyPIページでは、azure-mgmt-securityのページ見出しは7.0.0で、リリース日は2024年5月20日です。一方、リリース履歴には8.0.0b1のpre-releaseも表示されています。通常のpip install azure-mgmt-securityで本番環境に入るものと、pre-releaseやPR上の8.0.0b2相当の差分は分けて扱う必要があります。(PyPI)
重要な変更点は「クライアント名」「モデル削除」「引数変更」
Python SDK側PRの変更ファイルでは、azure.mgmt.securityの公開クライアントが従来のSecurityCenterからSecurityManagementClientへ変わる差分が見えます。__init__.pyでも、旧来のSecurityCenterではなくSecurityManagementClientを公開する形の変更が確認できます。(GitHub)
現在のMicrosoft LearnやPyPIの説明では、認証サンプルにまだSecurityCenterが使われています。したがって、ドキュメント・PyPI・GitHub PRのどれを見ているのかを混同しないことが大切です。正式リリース前の移行検証では、次のように一時的な互換ラッパーを用意すると、既存版と新生成版の差分を切り分けやすくなります。(Microsoft Learn)
from azure.identity import DefaultAzureCredential
try:
from azure.mgmt.security import SecurityManagementClient as SecurityClient
except ImportError:
from azure.mgmt.security import SecurityCenter as SecurityClient
client = SecurityClient(
credential=DefaultAzureCredential(),
subscription_id="00000000-0000-0000-0000-000000000000",
)ただし、この書き方は移行確認用です。本番コードでは、利用するazure-mgmt-securityのバージョンをrequirements.txtやpyproject.tomlで固定し、どちらのクライアント名を採用するかを明確にしてください。
破壊的変更で特に確認すべきポイント
PR上のBreaking Change Analysis Summaryでは、破壊的変更項目が483件、うち6件が緩和、477件がTypeSpec移行に伴う想定変更として受け入れられたとされています。カテゴリとしては、*List系のページング用モデル削除、共通エラー型の削除、未参照モデルの削除、フラット化されたプロパティの削除、listメソッドの同期化、列挙型まわりの差分などが挙げられています。(GitHub)
実務では、すべての差分を読むよりも、まず次の5点を重点的に確認すると効率的です。
*List系モデルを直接参照していないか
AlertList、PricingList、SecurityConnectorsListのような一覧レスポンス用モデルは、TypeSpec生成版で削除・リネームされる可能性があります。CHANGELOG上でもAlertList、ApiCollectionList、SecurityAssessmentList、SecurityConnectorsListなど、多数のList系モデルが削除またはリネーム対象として記載されています。(GitHub)
次のようなコードは要注意です。
from azure.mgmt.security.models import AlertList一覧取得の戻り値は、特定の*Listモデルとして扱うより、反復可能な結果として処理するほうが移行に強くなります。
alerts = client.alerts.list()
for alert in alerts:
print(alert.name)モデルのフラット化プロパティに依存していないか
TypeSpec移行では、フラット化されていたプロパティがproperties配下へ戻る、またはモデル構造が変わるケースがあります。CHANGELOGでは、IoTSecuritySolutionModel.workspace、SecurityAssessment.status、SecureScoreControlDetails.currentなど、多数のインスタンス変数が削除またはリネーム対象として挙げられています。(GitHub)
たとえば、次のような直接参照は移行時に壊れやすい書き方です。
print(assessment.status)
print(assessment.display_name)移行後は、実際のモデル定義を確認し、必要に応じてproperties配下や新しいモデル名へ置き換えます。自動化スクリプトでは、属性が存在しない場合に落ちるため、hasattr()や型チェックを使って段階的に検証すると安全です。
Private Link関連のメソッド引数が変わっていないか
Private Link関連では、private_link_parametersが削除・リネームされ、private_link_nameが挿入される差分が複数あります。対象にはPrivateLinksOperations.get、PrivateLinksOperations.begin_create、PrivateEndpointConnectionsOperations.get、PrivateEndpointConnectionsOperations.begin_create_or_updateなどが含まれます。(GitHub)
特に危険なのは、位置引数で呼び出しているコードです。
# 壊れやすい例
client.private_links.get(resource_group_name, private_link_parameters)移行前後の差分を吸収しやすくするには、できるだけキーワード引数を使います。
# 移行時に確認しやすい例
client.private_links.get(
resource_group_name=resource_group_name,
private_link_name=private_link_name,
)SQL脆弱性評価の操作でdatabase_nameの渡し方を確認する
SqlVulnerabilityAssessmentBaselineRulesOperations.addやcreate_or_updateでは、database_nameがキーワード専用引数へ変わる、または引数順序が変わる差分が記載されています。(GitHub)
この種の変更は、静的解析では見落とされることがあります。単体テストだけでなく、実際のAzureリソースを使った検証環境で、対象操作を1回以上実行して確認してください。
エラー型を個別クラス名で捕捉していないか
CloudErrorAutoGenerated、ErrorDetailAutoGenerated、ErrorResponseAutoGeneratedなどの自動生成エラー型は、削除・リネーム対象に含まれています。例外処理でこれらのクラスを直接importしている場合、移行後にimportエラーになる可能性があります。(GitHub)
Azure SDK for Pythonの管理ライブラリでは、一般的にはazure.core.exceptions.HttpResponseErrorを中心に捕捉するほうが、生成方式の変更に強くなります。
from azure.core.exceptions import HttpResponseError
try:
result = client.assessments.get(
resource_id=resource_id,
assessment_name=assessment_name,
)
except HttpResponseError as error:
print(f"Azure API error: {error.message}")認証・環境変数・クラウド設定で確認すべきこと
TypeSpec移行は、認証方式そのものを置き換える更新ではありません。現在のドキュメントでも、DefaultAzureCredential、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET、AZURE_SUBSCRIPTION_IDを使う構成が案内されています。(Microsoft Learn)
ただし、PR上の新しいクライアント実装では、base_url、cloud_setting、credential_scopesの扱いが生成コード内に含まれています。Azure Government、Azure China、独自のエンドポイント設定、プロキシ配下の実行環境を使っている場合は、通常のパブリックAzureだけで動作確認を終えないようにしてください。(GitHub)
確認コマンドの例です。
python -c "import azure.mgmt.security as s; print(s.__version__)"
pip show azure-mgmt-security
env | grep AZURE_CIでは、最低限次の観点をテストに入れておくと移行失敗を早期に見つけられます。
| 確認項目 | 失敗時に起きやすい症状 |
|---|---|
| クライアントimport | ImportError: cannot import name 'SecurityCenter' |
| モデルimport | ImportErrorまたはAttributeError |
| list操作 | .result()前提のコードが失敗する、反復処理が変わる |
| 位置引数の操作呼び出し | 想定と違う値が引数に入る、TypeErrorが出る |
| 例外処理 | 古いエラー型のimportで失敗する |
| sovereign cloud設定 | 認証スコープやARMエンドポイント不一致で失敗する |
移行前に実施したいコード棚卸し
まず、リポジトリ全体で古い名前や壊れやすい参照を検索します。
grep -R "SecurityCenter" .
grep -R "CloudErrorAutoGenerated\|ErrorDetailAutoGenerated\|ErrorResponseAutoGenerated" .
grep -R "AlertList\|SecurityAssessmentList\|SecurityConnectorsList\|PricingList" .
grep -R "private_link_parameters" .次に、requirements.txtやpyproject.tomlを確認します。
azure-mgmt-security==7.0.0
azure-identity>=1.16.0pre-releaseを検証する場合は、本番環境ではなく検証用ブランチで行います。pip install --pre azure-mgmt-securityのような指定は、他のpre-releaseも取り込む可能性があるため、検証ではバージョンを明示するほうが安全です。
pip install "azure-mgmt-security==8.0.0b1"PR上のCHANGELOGでは8.0.0b2相当の変更が見えますが、PyPI上で実際に利用できるバージョンは公開状況に依存します。GitHub PRの差分、PyPIのリリース履歴、Microsoft Learnのドキュメントは更新タイミングがずれるため、移行判断では必ず3つを分けて確認してください。(GitHub)
実務でのおすすめ移行手順
安全に進めるなら、いきなり本番のazure-mgmt-securityを更新するのではなく、次の順序で進めます。
| 手順 | 作業内容 | 判断基準 |
| -: | ——————————————— | ———————— |
| 1 | 現在の利用バージョンを確認 | 7.0.0固定か、8.x betaを使っているか |
| 2 | SecurityCenterやモデル直接importを検索 | import変更の影響範囲を把握 |
| 3 | Private Link、SQL脆弱性評価、Secure Scoreなど利用機能を洗い出す | CHANGELOGの該当箇所と照合 |
| 4 | 検証環境で8.x betaまたはPR相当の差分を試す | import、認証、主要API呼び出しが通るか |
| 5 | 位置引数をキーワード引数へ寄せる | 引数順序変更に強くする |
| 6 | エラー処理をHttpResponseError中心へ整理 | 生成エラー型の削除に備える |
| 7 | 本番反映前にバージョンを固定 | 意図しないpre-release混入を防ぐ |
この移行で失敗しやすいのは、SDKの更新を「依存パッケージの軽微なアップデート」として扱ってしまうことです。azure-mgmt-securityは管理プレーンSDKであり、セキュリティ設定、評価、価格設定、コネクタ、脆弱性評価など、運用自動化に直結する処理で使われます。失敗すると、単なる画面表示の不具合ではなく、セキュリティ運用ジョブやIaC後処理が止まる可能性があります。
今回の更新で次に取るべき行動
今回のAzure SDK documentation updateは、azure-mgmt-securityをTypeSpec生成へ移行するための重要な準備段階です。2026年5月5日時点ではPython SDK側PRはレビュー待ちで、少なくとも1件の承認レビューが必要な状態でした。また、Microsoft.SecurityサービスチームがSDKリリースを待っている旨のコメントも確認できます。(GitHub)
今すぐ行うべきことは、依存関係の棚卸しです。SecurityCenter、*Listモデル、CloudErrorAutoGenerated系、Private Link関連の位置引数、SQL脆弱性評価の引数指定を検索し、影響範囲を把握してください。安定版7.0.0を固定している環境では即時対応は不要な場合もありますが、8.xへ移行する予定があるなら、検証環境で先に壊れやすい箇所を潰しておくのが安全です。
コメント