Azure Machine LearningのDeployment Templatesは、これまでポータル中心で扱っていたデプロイ構成を、az mlコマンドやPython SDKから管理しやすくなる方向に進みました。2026年6月3日に案内された「Public Preview: CLI and SDK support for Deployment Templates」は、モデルのデプロイ設定をチーム標準として管理したいプラットフォーム担当者やMLOps担当者にとって重要な更新です。結論から言うと、すぐに本番運用を全面移行する話ではなく、まずは開発・検証環境で「テンプレートの作成、更新、一覧確認、無効化、復元、SDK操作」をCI/CDやIaCパイプラインに組み込めるか確認する段階です。
Deployment Templatesは、Azure MLのデプロイ設定を再利用可能な形で定義する仕組みです。今回のポイントは、テンプレートを画面操作だけでなくCLIとSDKから扱えるようになり、標準化・自動化・レビュー可能な運用に寄せやすくなったことです。一方で、Public Previewは非本番用途での検証を前提とするステータスであり、仕様変更の可能性を見込んだ設計が必要です。Azure Updates上でも「In preview」は、すべてのAzure顧客が非本番用途のテストに利用できる段階として説明されています。(Microsoft Azure)
今回の変更点は「Deployment TemplatesをCLI/SDKで管理できること」
今回のPublic Previewでは、Azure Machine LearningのDeployment TemplatesにCLIとSDKのサポートが追加されました。Deployment TemplatesはAzure MLのデプロイ構成を定義する再利用可能なテンプレートで、チームやプロジェクトをまたいでデプロイ設定を標準化・共有するために使います。Microsoft LearnのCLIリファレンスでは、Deployment Templatesは「Azure MLのデプロイ構成を定義する再利用可能なテンプレート」であり、ワークスペースベースではなくレジストリベースの操作をサポートすると説明されています。(Microsoft Learn)
ここで注意したいのは、Azure Resource ManagerのARMテンプレートやBicepの話ではない点です。名前に「Deployment Template」とありますが、この記事で扱うのはAzure Machine Learningのモデルデプロイ設定をテンプレート化する機能です。インフラ全体を作るARM/Bicepテンプレートとは目的が異なります。
実務上の意味は明確です。モデルをオンラインエンドポイントへデプロイするたびに、インスタンスタイプ、インスタンス数、環境、プローブ、スコアリング設定などを個別に調整していたチームは、標準構成をDeployment Templateとして管理し、CLIやSDKから再利用できるようになります。
何が便利になるのか
これまでポータル操作に寄りがちだったテンプレート管理を、Git管理されたYAML、CI/CD、レビュー、承認フローに載せやすくなります。特に複数チームがAzure Machine Learningを使っている組織では、デプロイ構成のばらつきを抑える効果があります。
| 観点 | これまで起きやすかった課題 | CLI/SDK対応後に期待できること |
|---|---|---|
| 標準化 | チームごとにデプロイ設定が微妙に異なる | 推奨構成をテンプレート化して横展開しやすい |
| 変更管理 | ポータル変更の履歴やレビューが弱くなりやすい | YAMLやコードをGitでレビューできる |
| 自動化 | 手作業が残り、環境差分が出やすい | パイプラインから作成・更新・確認を実行できる |
| 監査 | 誰がどの設定を使ったか追いづらい | テンプレート名、バージョン、タグで管理しやすい |
| 再現性 | デプロイ時の暗黙設定が残りやすい | 明示的なテンプレートで再現性を高められる |
特にMLOpsでは「学習パイプライン」だけでなく「推論環境の標準化」が重要です。モデル精度が同じでも、デプロイ時のインスタンスサイズ、レプリカ数、ヘルスチェック、環境変数、モデルマウント設定が違えば、コストや可用性、トラブル時の切り分けに影響します。
利用できる主なCLI操作
Azure CLIでは、az ml deployment-templateコマンドグループが用意されています。Microsoft Learnでは、このコマンドグループはAzure CLIのml拡張機能に含まれ、プレビュー中の機能として扱われています。(Microsoft Learn)
代表的な操作は次のとおりです。
| 操作 | コマンド例 | 用途 |
|---|---|---|
| 作成 | az ml deployment-template create | YAMLファイルからテンプレートを作成 |
| 一覧 | az ml deployment-template list | レジストリ内のテンプレートを確認 |
| 詳細確認 | az ml deployment-template show | 名前とバージョンを指定して内容を確認 |
| 更新 | az ml deployment-template update | 説明やタグなど一部フィールドを更新 |
| アーカイブ | az ml deployment-template archive | テンプレートを非アクティブ扱いにする |
| 復元 | az ml deployment-template restore | アーカイブ済みテンプレートを再び有効化 |
基本的な利用イメージは次のようになります。
az extension update -n ml
az ml deployment-template create \
--file template.yml \
--registry-name myregistry
az ml deployment-template list \
--registry-name myregistry \
--output table
az ml deployment-template show \
--name my-template \
--version 1 \
--registry-name myregistryCLIで特に重要なのは、--workspace-nameではなく--registry-nameを使う点です。Deployment Templatesはレジストリベースの操作のみをサポートすると説明されており、既存のAzure MLワークスペース操作と同じ感覚でスクリプトを書くと失敗しやすくなります。(Microsoft Learn)
また、CLIのupdateは何でも変更できる万能操作ではありません。Microsoft Learnでは、az ml deployment-template updateは説明やタグなどのメタデータ更新に使い、エンドポイントやデプロイ構成など構造的な変更にはYAMLファイルを指定したcreateコマンドを使うと説明されています。(Microsoft Learn)
SDKではPythonコードからテンプレートを扱える
Python SDK側では、MLClientからdeployment_templates操作を扱えます。Microsoft Learnでは、MLClientにdeployment_templates属性があり、Deployment Template関連の操作コレクションを返すと説明されています。(Microsoft Learn)
SDKでは、YAMLファイルを読み込んでDeploymentTemplateオブジェクトを作成するload_deployment_templateも用意されています。これは、ローカルのYAMLファイルや開いているファイルオブジェクトからDeployment Template構成を読み込むメソッドです。(Microsoft Learn)
利用イメージは次のようになります。
from azure.identity import DefaultAzureCredential
from azure.ai.ml import MLClient, load_deployment_template
ml_client = MLClient(
credential=DefaultAzureCredential(),
registry_name="myregistry"
)
template = load_deployment_template("template.yml")
ml_client.deployment_templates.create_or_update(template)SDKでは、create_or_update、delete、get、list、archive、restoreといった操作が定義されています。create_or_updateはDeploymentTemplateオブジェクト、辞書、またはYAMLファイルパスからテンプレートを作成・更新できます。deleteは名前とバージョンを指定してテンプレートを削除する操作として説明されています。(Microsoft Learn)
ただし、SDKのDeploymentTemplate関連クラスやメソッドにはExperimentalの注記があります。プレビュー段階ではメソッド名、引数、挙動が変わる可能性があるため、本番系パイプラインへ入れる場合はSDKバージョンを固定し、リリースノートを確認する運用が必要です。(Microsoft Learn)
Deployment Templateに含めるべき設定
Deployment Templateは、単なる名前付きメモではありません。デプロイの再現性に関わる設定を明示するためのものです。Microsoft LearnのDeploymentTemplateクラスでは、環境、リクエスト設定、liveness/readiness probe、インスタンス数、インスタンスタイプ、モデル、コード構成、環境変数、Application Insights、許可するインスタンスタイプ、既定のインスタンスタイプ、スコアリングポート、スコアリングパスなどの要素がコンストラクターに含まれています。(Microsoft Learn)
実務では、少なくとも次の観点をテンプレート化の対象にすると効果が出やすくなります。
| 設定項目 | 確認すべきポイント | 失敗しやすい例 |
|---|---|---|
instance_type | 推奨するVM SKUやGPU有無 | 高性能SKUを既定にして不要なコストが発生 |
instance_count | 最小構成と可用性のバランス | 検証用の1台構成を本番相当に流用 |
allowed_instance_types | 利用可能なSKUを制限 | チームごとに異なるSKUを自由に選んで費用管理が崩れる |
environment | 推論環境の再現性 | 手元環境との差分でデプロイ後に起動失敗 |
code_configuration | スコアリングコードの場所と入口 | ポータルで指定した暗黙設定がテンプレートに残らない |
liveness_probe / readiness_probe | ヘルスチェック条件 | 起動に時間がかかるモデルで早期失敗する |
app_insights_enabled | 監視の有効化 | 障害時にログ不足で原因調査が遅れる |
environment_variables | 環境ごとの差分管理 | シークレットをYAMLに直書きしてしまう |
シークレットや接続文字列をテンプレートに直接書かないことも重要です。テンプレートはGit管理やチーム共有の対象になりやすいため、Key Vault、マネージドID、接続設定など、組織の標準的なシークレット管理方針と合わせて設計してください。
管理者が確認すべきポイント
管理者が最初に見るべきなのは、機能そのものよりも「誰が、どのレジストリに、どのテンプレートを登録・変更できるか」です。Deployment Templatesはチーム標準のデプロイ構成になり得るため、権限が広すぎると、標準化のための仕組みが逆に混乱の原因になります。
レジストリ単位の権限を整理する
CLIリファレンスでは、Deployment Templatesはワークスペースベースではなくレジストリベースの操作をサポートするとされています。(Microsoft Learn) そのため、既存のAzure MLワークスペースに対する権限だけでなく、Azure MLレジストリに対する権限設計を確認してください。
運用上は、次のような分離が現実的です。
| 役割 | 付与する権限の考え方 |
|---|---|
| プラットフォーム管理者 | テンプレートの作成、更新、アーカイブ、復元を実行できる |
| MLOps担当者 | 検証用レジストリで作成・更新、本番相当レジストリは承認制 |
| データサイエンティスト | テンプレートの参照、必要に応じて検証環境での利用 |
| CI/CDサービスプリンシパル | 必要なレジストリへの最小権限のみ付与 |
「便利だから全員に書き込み権限を付ける」は避けるべきです。Deployment Templateは推論環境の標準そのものになるため、変更にはコードレビューや承認を挟む設計にしてください。
CLIとSDKのバージョンを固定する
プレビュー機能では、CLIやSDKの更新により挙動が変わる可能性があります。Azure CLIのaz mlはml拡張機能で提供され、リファレンスではバージョン2.15.0以上の拡張機能に含まれると説明されています。(Microsoft Learn)
CI/CDでは、次の確認をパイプライン冒頭に入れておくとトラブルを減らせます。
az version
az extension show -n ml
az ml deployment-template --helpSDKを使う場合は、azure-ai-mlのバージョンをrequirements.txtやpyproject.tomlで固定し、検証環境で更新テストをしてから本番系パイプラインへ反映しましょう。
CLI v1 / SDK v1からの移行状況も見直す
Azure Machine Learningでは、CLI v1のサポートは2025年9月30日に終了しており、SDK v1のサポートは2026年6月30日に終了予定と説明されています。MicrosoftはCLI v2、SDK v2への移行を推奨しています。(Microsoft Learn)
Deployment TemplatesのCLI/SDK対応を試すタイミングで、古いazure-cli-ml拡張やSDK v1に依存したスクリプトが残っていないかも確認してください。テンプレート管理だけ新しくしても、周辺のジョブ作成、モデル登録、デプロイ処理がv1のままだと、保守性が中途半端になります。
開発者・MLOps担当者が確認すべきポイント
開発者やMLOps担当者は、テンプレートを「便利な設定ファイル」として扱うだけでなく、「チームが合意したデプロイ契約」として設計することが重要です。
YAMLをGitで管理する
CLIのcreateはYAMLファイルからDeployment Templateを作成できます。リファレンスでは、YAMLにはエンドポイント、パラメーター、メタデータを含む完全なテンプレート定義を入れられると説明されています。(Microsoft Learn)
おすすめの管理例は次のような構成です。
ml-deployment-templates/
├── README.md
├── templates/
│ ├── cpu-small-online.yml
│ ├── cpu-standard-online.yml
│ └── gpu-inference.yml
└── pipelines/
└── publish-template.ymlREADME.mdには、どのテンプレートをどの用途で使うかを書いておきます。たとえば「PoC用」「小規模本番相当」「GPU推論用」のように用途を明確にすると、利用者が迷いにくくなります。
バージョンを必ず指定して使う
テンプレートを参照するときは、可能な限り名前だけでなくバージョンも指定します。SDKのgetでは、バージョンを省略すると最新バージョンを取得すると説明されています。(Microsoft Learn) これは便利ですが、CI/CDでは意図しない最新化につながることがあります。
たとえば、検証環境では最新テンプレートを使い、本番相当環境では承認済みバージョンを固定する、といったルールが現実的です。
| 環境 | 推奨する参照方法 |
|---|---|
| 個人検証 | 最新版の利用を許容 |
| チーム検証 | バージョン指定を推奨 |
| ステージング | リリース候補バージョンを固定 |
| 本番相当 | 承認済みバージョンのみ利用 |
updateで構造変更しようとしない
CLIのupdateは、説明やタグなどのメタデータ更新が中心です。エンドポイントやデプロイ構成のような構造的な変更は、YAMLファイルを使ったcreateを使うと説明されています。(Microsoft Learn)
そのため、次のように使い分けると安全です。
| 変更内容 | 推奨操作 |
|---|---|
| 説明文の修正 | az ml deployment-template update --set "description=..." |
| タグの追加 | az ml deployment-template update --set "tags=..." |
| インスタンスタイプ変更 | YAMLを更新し、新バージョンとして作成 |
| ヘルスチェック設定変更 | YAMLを更新し、新バージョンとして作成 |
| 利用停止 | archiveで非アクティブ化 |
| 誤って停止したテンプレートの再利用 | restoreで復元 |
「既存バージョンを上書きして直す」のではなく、「新しいバージョンを作る」運用にした方が、障害時の切り戻しが簡単になります。
導入手順：まず検証環境で小さく始める
いきなり全チームのデプロイをDeployment Templatesへ寄せる必要はありません。まずは1つのモデル、1つの検証用レジストリ、1つのテンプレートから始めるのが安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 現状把握 | 既存のデプロイ設定を洗い出す | インスタンスタイプ、環境、プローブ、環境変数を一覧化 |
| テンプレート設計 | YAMLに標準構成を定義する | レビュー可能なPRとして作成 |
| 検証用登録 | az ml deployment-template createで登録 | listとshowで内容を確認 |
| SDK検証 | Python SDKから読み込み・作成を試す | CI環境のIDで成功する |
| パイプライン化 | GitHub ActionsやAzure Pipelinesへ組み込む | 手作業なしで登録できる |
| 運用ルール化 | 命名、バージョン、アーカイブ基準を決める | READMEや運用手順に反映 |
| 段階展開 | 複数モデル・複数チームへ拡張 | 例外設定を把握できる |
小さく始める理由は、テンプレート自体よりも周辺ルールの調整に時間がかかるためです。権限、命名、レビュー、承認、ロールバック、コスト管理が決まっていない状態でテンプレートだけ増やすと、後から整理する負担が大きくなります。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| ワークスペース操作と同じ感覚で使う | --workspace-name前提のスクリプトが失敗する | Deployment Templatesは--registry-name中心で設計する |
| プレビュー機能を本番前提で固定化する | 仕様変更時にパイプラインが止まる | CLI/SDKのバージョン固定と検証環境での更新テストを行う |
| 最新版テンプレートを暗黙参照する | ある日突然デプロイ構成が変わる | 本番相当環境ではテンプレートバージョンを固定する |
| YAMLにシークレットを書く | Git履歴やレビュー画面に機密情報が残る | Key VaultやマネージドIDを使う |
| アーカイブと削除のルールがない | 使ってよいテンプレートが分からなくなる | 非推奨はarchive、完全削除は承認制にする |
| タグ設計がない | 用途や所有者が追跡できない | owner、environment、statusなどを標準化する |
| コスト観点が抜ける | 高価なSKUが標準化されてしまう | allowed_instance_typesで利用可能SKUを制限する |
| ヘルスチェックが厳しすぎる | 大きなモデルが起動前に失敗する | モデルの起動時間を測り、probe設定を調整する |
特に避けたいのは、「ポータルで動いた設定をそのままテンプレート化しただけ」で満足することです。テンプレート化の目的は、動く設定を保存することではなく、チームとして安全に再利用できる設定を作ることです。
本番導入の判断基準
Public Previewの段階では、全面的な本番移行よりも、開発・検証・ステージングで運用設計を固めるのが現実的です。次の条件を満たせる場合は、段階的な導入を検討できます。
| 判断項目 | 導入しやすい状態 | まだ待つべき状態 |
|---|---|---|
| プレビュー機能の扱い | 社内で非本番検証ルールがある | プレビュー利用の承認基準がない |
| テンプレート管理 | Gitレビューと承認フローがある | 個人がローカルでYAMLを管理している |
| 権限管理 | レジストリ単位の書き込み権限を絞れる | 全員が自由に変更できる |
| CI/CD | CLI/SDKのバージョン固定ができる | 実行環境が毎回変わる |
| ロールバック | 旧バージョンへ戻す手順がある | 最新版しか残していない |
| 監視 | Application Insightsやログ確認手順がある | デプロイ後の確認が手作業のみ |
プレビュー段階で最も価値が出るのは、チーム横断の標準テンプレートを作る準備です。本番デプロイをすぐ置き換えるより、まず「推奨テンプレートをどの粒度で作るか」「誰が承認するか」「どの環境から適用するか」を決める方が効果的です。
既存運用から移行する場合の考え方
既存のAzure Machine Learning運用がある場合、Deployment Templatesへの移行は一括置換ではなく、既存設定の棚卸しから始めます。
まず、よく使われているデプロイ構成を3種類程度に分類します。
| 分類例 | 想定用途 |
|---|---|
cpu-small-online | PoC、小規模検証、低トラフィック推論 |
cpu-standard-online | 標準的なオンライン推論 |
gpu-inference | GPUが必要な大規模モデル推論 |
次に、それぞれの構成について、インスタンスタイプ、インスタンス数、環境、ヘルスチェック、監視設定、許可SKUをYAML化します。最後に、既存モデルのうち影響が小さいものからテンプレートを適用し、デプロイ結果、コスト、起動時間、ログ出力を確認します。
移行時に重要なのは、既存の全設定を無理にテンプレート化しないことです。例外が多すぎる構成は、まず例外の理由を確認してください。単なる過去の名残であれば標準テンプレートへ寄せ、業務上必要な差分であれば別テンプレートとして明示します。
まず確認すべきチェックリスト
導入前に、次の項目を確認してください。
- Azure CLIの
ml拡張機能が利用できるか az ml deployment-template --helpでコマンドが表示されるか- 操作対象のAzure MLレジストリが決まっているか
- CI/CDで使うサービスプリンシパルまたはマネージドIDの権限が足りているか
- テンプレートYAMLをGitでレビューできる状態になっているか
- テンプレート名とバージョン番号のルールがあるか
archive、restore、SDKのdeleteを誰が実行できるか決まっているか- プレビュー機能を利用できる環境範囲が明確か
- 既存のSDK v1、CLI v1依存が残っていないか
- 本番相当環境ではテンプレートのバージョン固定ができるか
まとめ：Deployment Templatesは「推論環境の標準化」を進める機能
今回の「Public Preview: CLI and SDK support for Deployment Templates」は、Azure Machine LearningのデプロイテンプレートをMLOpsの管理対象にしやすくする更新です。CLIではaz ml deployment-templateで作成、一覧、詳細確認、更新、アーカイブ、復元を扱え、SDKではPythonコードから作成・更新・取得・一覧・削除などの操作を組み込めます。
管理者は、まずレジストリ単位の権限、CLI/SDKバージョン、プレビュー機能の利用範囲を確認してください。開発者やMLOps担当者は、YAMLをGit管理し、テンプレート名・バージョン・タグ・アーカイブ基準を決めるところから始めるのが現実的です。
次に取るべき行動は、既存のデプロイ設定を1つ選び、検証用レジストリにDeployment Templateとして登録してみることです。そのうえで、手作業で行っていた設定がどこまでCLI/SDKで再現できるか、CI/CDに組み込んだときに権限やバージョン管理で問題が出ないかを確認しましょう。いきなり本番へ広げるより、まず標準テンプレートを小さく作り、チーム内でレビューできる形にすることが成功への近道です。
コメント