Microsoft Azure documentation update「Updates for CLI release + Fix DeploymentTemplateScenario/ModelScenario tests」は、Azure全体の大規模な仕様変更ではなく、主に Azure Machine Learning の ml CLI拡張機能とテスト資産の更新です。結論として、管理者や開発者が最初に確認すべきことは、ml 拡張機能のバージョン、CI/CDでのAzure CLI拡張機能の更新方法、そしてDeployment Template YAML内の allowed_instance_types の書き方です。
公式PRでは、azure-ai-ml を 1.32.0 から 1.33.0 に更新し、Azure Machine Learning向けCLI拡張機能のバージョンを 2.43.0 に上げる変更が示されています。あわせて、レジストリ探索URLのテスト再生時に api-version などのクエリ差分で失敗しにくくする修正と、Deployment Templateの allowed_instance_types をYAMLリスト形式に直す修正が含まれます。(GitHub)
今回のMicrosoft Azure documentation updateは何の更新か
今回の更新は、GitHub上の Azure/azure-cli-extensions リポジトリにあるPR「Updates for CLI release + Fix DeploymentTemplateScenario/ModelScenario tests」として、2026年5月20日に main ブランチへマージされています。PRの対象はAzure CLI拡張機能のうち、Azure Machine Learningで使われる ml 拡張機能まわりです。(GitHub)
重要なのは、これを「Azureのリソース設定が自動的に変わる更新」と捉えないことです。影響を受けやすいのは、次のようなチームです。
| 対象者 | 影響の出やすい場面 |
|---|---|
| Azure管理者 | 開発端末、踏み台環境、CI/CDエージェント上のAzure CLI拡張機能管理 |
| MLOps担当者 | az ml コマンドを使ったモデル登録、エンドポイント作成、デプロイ自動化 |
| Azure ML開発者 | Deployment Template、Model Scenario、Registry関連のテストやYAML管理 |
| テスト基盤担当者 | VCRなどの記録・再生型テストでAzure ML RegistryのURL差分を扱うケース |
一方で、Azure PortalだけでAzure Machine Learningを操作しているユーザーや、Azure MLを利用していない環境では、直接的な作業は少ないと考えられます。
変更点の要約
公式PRに記載された主な変更は、以下の4点です。自動チェック上は「Non Breaking Changes」と表示されていますが、YAMLの書き方やCI/CD環境の依存関係によっては、検証時にエラーが表面化する可能性があります。(GitHub)
| 変更点 | 内容 | 実務上の確認ポイント |
|---|---|---|
azure-ai-ml の更新 | 1.32.0 から 1.33.0 へ更新 | Python SDKとCLIを併用している環境で依存関係を確認する |
ml 拡張機能の更新 | 拡張機能バージョンが 2.43.0 に更新 | az extension show --name ml でインストール済みバージョンを確認する |
| Registry関連テストの安定化 | Registry discovery URLのクエリパラメーターを記録・再生時に調整 | VCRカセットや録画済みテストを使う独自テスト基盤で確認する |
| Deployment Templateの修正 | allowed_instance_types をYAMLリスト形式に修正 | 既存テンプレートで文字列指定していないか点検する |
Microsoft LearnのAzure CLI拡張機能一覧でも、ml はAzure Machine Learning向け拡張機能として掲載され、GA版の拡張機能バージョンが 2.43.0 になっています。(Microsoft Learn)
管理者がまず確認すべきAzure CLI拡張機能の状態
Azure CLI拡張機能は、Azure CLI本体とは別に管理されます。Microsoft Learnでも、拡張機能はCLI本体と一緒に更新されるものではなく、個別に更新が必要だと説明されています。(Microsoft Learn)
まず、利用している端末やCI/CDエージェントで、次のコマンドを実行します。
az version
az extension show --name ml --output tableml 拡張機能が入っていない場合は、次のように確認できます。
az extension list --output table更新する場合は、名前でインストール済みの拡張機能に対して次のコマンドを使います。Microsoft Learnでは、名前でインストールした拡張機能は az extension update で更新すると説明されています。(Microsoft Learn)
az extension update --name mlCI/CDのセットアップスクリプトで「存在すれば更新、なければインストール」をまとめて扱いたい場合は、az extension add の --upgrade オプションも使えます。このオプションは、既にインストールされている場合は更新し、未インストールならインストールする動作です。(Microsoft Learn)
az extension add --name ml --upgrade --yesCI/CDでは「Azure CLI本体の更新」と「拡張機能の更新」を分けて考える
失敗しやすいのは、DockerイメージやビルドエージェントでAzure CLI本体だけを更新し、ml 拡張機能の更新を忘れるケースです。
たとえば、次のようなパイプラインは注意が必要です。
az upgrade --yes
az ml job create --file job.ymlこの流れでは、環境によって ml 拡張機能が古いまま残ることがあります。MLOps用途では、以下のように拡張機能の更新確認を明示的に入れるほうが安全です。
az upgrade --yes
az extension add --name ml --upgrade --yes
az extension show --name ml --query version --output tsv組織で再現性を重視する場合は、すぐに全環境を自動更新するのではなく、検証用環境で 2.43.0 を確認してから本番パイプラインに反映するのが現実的です。
Deployment Templateで注意すべき allowed_instance_types
今回の更新で最も実務に近い注意点は、Deployment Templateの allowed_instance_types です。PRでは、SDK 1.33.0 のスキーマ検証に対応するため、deployment_template_basic.yaml の allowed_instance_types をYAMLリスト形式に修正したと説明されています。(GitHub)
古いテンプレートで次のように文字列として書いている場合は、見直し対象です。
allowed_instance_types: Standard_DS3_v2リストとして扱うなら、次のように記述します。
allowed_instance_types:
- Standard_DS3_v2複数のインスタンスタイプを許可する場合は、次のように並べます。
allowed_instance_types:
- Standard_DS3_v2
- Standard_DS4_v2
- Standard_F4s_v2ここでのポイントは、値が1つだけでもリストとして書くことです。YAMLでは見た目が似ていても、文字列とリストは別の型として解釈されます。SDK側のスキーマ検証が厳しくなると、以前は通っていたテンプレートが失敗することがあります。
既存テンプレートの確認方法
リポジトリ内のDeployment Templateをまとめて確認するなら、次のように検索します。
grep -R "allowed_instance_types" .Windows PowerShellでは、次のように確認できます。
Select-String -Path .\* -Pattern "allowed_instance_types" -Recurse確認時は、単に項目が存在するかではなく、次の観点で見てください。
| 確認項目 | OKの例 | 見直しが必要な例 |
|---|---|---|
| 値の型 | allowed_instance_types: の下に - Standard_DS3_v2 | allowed_instance_types: Standard_DS3_v2 |
| 複数指定 | YAMLリストで複数行に分ける | カンマ区切りの1つの文字列にする |
| 古いキー名 | allowed_instance_types | 古いテンプレート由来の単数形や独自項目が残っている |
テンプレートを修正したら、いきなり本番デプロイに使うのではなく、検証用のAzure Machine Learningワークスペースで az ml コマンドを実行し、スキーマ検証とデプロイ作成の両方を確認してください。
RegistryDiscoveryQueryStripperの追加は何を意味するか
今回のPRでは、RegistryDiscoveryQueryStripper というリプレイプロセッサーの追加も含まれています。目的は、Azure Machine Learning Registryの探索URLに付く api-version などのクエリパラメーター差分によって、VCRの再生一致が失敗しないようにすることです。PRでは、再生時にRegistry discovery URLから api-version クエリを取り除く処理と、記録時にもクエリパラメーターを取り除いてSDKバージョン間の一貫性を保つ処理が説明されています。(GitHub)
これは、通常のAzure利用者がネットワーク設定やAzure Policyを変更しなければならない、という意味ではありません。影響が出やすいのは、Azure CLI拡張機能をフォークしてテストしている開発者、またはAzure ML RegistryまわりのHTTP記録・再生テストを独自に持っているチームです。
たとえば、次のようなテスト失敗がある場合は、今回の修正内容と同種の問題を疑えます。
Recorded request not found
URL differs only by api-version query parameter
Registry discovery request mismatchこの場合、SDKのバージョン差で実際の処理が壊れているのではなく、記録済みリクエストとの照合条件が厳しすぎるだけの可能性があります。独自のVCRカセットを使っている場合は、URL全体を完全一致させるのではなく、検証対象にすべきパス、ホスト、重要なクエリだけを比較する設計に見直すと安定します。
開発者・MLOps担当者向けの確認チェックリスト
今回のMicrosoft Azure documentation updateを受けて、開発者やMLOps担当者は次の順番で確認すると効率的です。
| 確認内容 | 実行する作業 | 合格基準 |
|---|---|---|
ml 拡張機能のバージョン | az extension show --name ml を実行 | 組織で承認したバージョン、または 2.43.0 への更新方針が明確 |
| CI/CDのセットアップ | az extension add --name ml --upgrade --yes を追加 | ビルドごとに古い拡張機能が残らない |
| Deployment Template | allowed_instance_types を検索 | YAMLリスト形式で記述されている |
| Registry関連テスト | VCRカセットや録画済みHTTPテストを確認 | api-version 差分だけで失敗しない |
| Python SDK併用環境 | pip show azure-ai-ml を確認 | CLIとPythonスクリプトの依存関係が混在していない |
| 本番展開前の検証 | 検証用ワークスペースで az ml を実行 | ジョブ作成、モデル参照、デプロイ作成が通る |
特に、Azure MLのYAMLをGitで管理し、Azure PipelinesやGitHub Actionsから az ml を実行しているチームは、テンプレート形式とCLI拡張機能バージョンの両方を見る必要があります。片方だけを確認しても、問題の切り分けに時間がかかります。
移行や展開で失敗しやすいポイント
動的インストールに頼りすぎる
Azure CLIには、未インストールの拡張機能コマンドを実行したときに拡張機能を自動インストールする仕組みがあります。ただし、CI/CDでは「どのバージョンが入ったか」を明示的に記録しづらくなります。
本番デプロイに使うパイプラインでは、動的インストール任せにせず、セットアップ段階で次のように明示するのが安全です。
az extension add --name ml --upgrade --yes
az extension show --name ml --query version --output tsvYAMLの見た目だけで判断する
allowed_instance_types は、1つの値だけなら文字列でもよさそうに見えます。しかし、SDKのスキーマがリストを期待している場合、1件だけでもリストとして渡す必要があります。
見た目ではなく、型で判断してください。
# よい例
allowed_instance_types:
- Standard_DS3_v2# 避けたい例
allowed_instance_types: Standard_DS3_v2SDK v1・CLI v1の移行問題と混同する
今回のPRは、Azure Machine Learningの ml 拡張機能、つまりCLI v2側の更新です。ただし、組織内に古い azure-cli-ml やSDK v1のワークフローが残っている場合は、別途移行計画が必要です。
Microsoft Learnでは、Azure Machine Learningのv1/v2はサービス本体ではなく、API、SDK、CLI拡張機能などクライアント側の区分であり、ワークスペース自体をアップグレードする作業ではないと説明されています。また、CLI v1のサポートは2025年9月30日に終了し、SDK v1は2026年6月30日にサポート終了予定とされています。(Microsoft Learn)
つまり、今回の ml 拡張機能更新を機に、次の切り分けをしておくと運用が楽になります。
| 利用状況 | 対応方針 |
|---|---|
az ml を使っている | ml 拡張機能のバージョンとYAMLを確認 |
azure-cli-ml を使っている | CLI v2への移行計画を立てる |
azureml-core を使っている | SDK v2である azure-ai-ml への移行可否を確認 |
| 既存ワークスペースを使っている | ワークスペース自体の移行ではなく、クライアントコードを見直す |
本番反映前のおすすめ手順
今回の更新を安全に展開するなら、次の順番で進めるのがおすすめです。
検証環境でCLI拡張機能を更新する
最初に、開発端末ではなく検証用のCI/CDエージェントやコンテナイメージで更新します。
az extension add --name ml --upgrade --yes
az extension show --name ml --output tableAzure ML関連のYAMLをまとめて検査する
Deployment Template、ジョブ定義、エンドポイント定義、モデル関連のYAMLを検索します。今回の更新で特に見るべきなのは allowed_instance_types です。
grep -R "allowed_instance_types" ./azureml ./mlops ./deploy該当があれば、リスト形式になっているかを確認します。
代表的なデプロイだけ先に実行する
すべてのパイプラインを一気に更新する前に、代表的なモデルやDeployment Templateを使って検証します。確認すべき観点は、スキーマ検証、Registry参照、モデル参照、エンドポイント作成、ロールバック手順です。
az ml online-deployment create --file deployment.yml --resource-group <resource-group> --workspace-name <workspace>実行後は、エラーの有無だけでなく、警告やログに古い拡張機能、古いSDK、YAMLスキーマの警告が出ていないかも確認してください。
本番パイプラインにバージョン確認を残す
更新後も、パイプラインのログに ml 拡張機能のバージョンを出すようにしておくと、障害時の切り分けが速くなります。
echo "Azure CLI version"
az version
echo "Azure ML extension version"
az extension show --name ml --query version --output tsvこの2行を残しておくだけで、「Azure CLI本体の問題か」「ml 拡張機能の問題か」「YAMLやSDK依存の問題か」を判断しやすくなります。
よくある疑問
Azure PortalやAzureリソースの設定変更は必要か
今回の更新は、主にAzure Machine Learning向けCLI拡張機能、SDK依存関係、テスト資産、Deployment Template YAMLの修正に関するものです。Azure Portal上の設定や、既存のAzureリソース設定を一律で変更する更新ではありません。
ただし、az ml を使ってデプロイやモデル操作を自動化している場合は、CLI環境とYAMLを確認してください。
すぐに ml 拡張機能を2.43.0へ上げるべきか
開発環境や検証環境では、早めに更新して問題がないか確認する価値があります。本番CI/CDでは、更新前後で同じYAMLと同じモデルを使ったテストを実行し、問題がなければ反映する流れが安全です。
特に、Deployment Templateを利用している場合は、allowed_instance_types の形式確認を先に済ませてください。
Azure CLI本体を更新すれば十分か
十分ではありません。Azure CLI拡張機能はCLI本体とは別に更新が必要です。Microsoft Learnでも、拡張機能はCLIと共に更新されるものではなく、個別に更新する必要があると説明されています。(Microsoft Learn)
CI/CDでは、az upgrade だけでなく az extension add --name ml --upgrade --yes または az extension update --name ml を明示的に入れるのが実務的です。
VCRテストを使っていない場合もRegistryDiscoveryQueryStripperを気にするべきか
通常のAzure ML利用者は、細かく気にする必要はありません。これは主に、Azure ML Registry関連の記録・再生型テストを安定させるための修正です。
ただし、Azure CLI拡張機能をフォークしているチーム、またはAzure ML RegistryのHTTPリクエストを録画してテストしているチームは、api-version のようなクエリパラメーター差分だけでテストが落ちないか確認したほうがよいでしょう。
まとめ：次にやるべきこと
今回のMicrosoft Azure documentation updateは、Azure Machine Learningの ml CLI拡張機能を使う管理者・開発者にとって、軽視しないほうがよい更新です。大きなポイントは、azure-ai-ml の 1.33.0 対応、ml 拡張機能 2.43.0、Registry関連テストの安定化、そして allowed_instance_types のYAMLリスト形式です。
まずは、利用環境で次の3つを確認してください。
az extension show --name ml --output table
grep -R "allowed_instance_types" .
az extension add --name ml --upgrade --yesそのうえで、検証用ワークスペースで代表的な az ml デプロイを実行し、CI/CDログにAzure CLI本体と ml 拡張機能のバージョンを残すようにします。これにより、今回の更新を安全に取り込みつつ、将来のSDK更新やAzure ML CLI拡張機能更新にも対応しやすい運用になります。
コメント