Microsoft Azureの公式リポジトリで更新された「Microsoft Azure documentation update: fix: update deployment API version to 2025-04-01 in telemetry module」は、Azure Verified Modules（AVM）のテレメトリ用Bicepサンプルで使われる Microsoft.Resources/deployments のAPIバージョンを、2024-03-01 から 2025-04-01 に変更する内容です。結論から言うと、既存のAzureリソースを直接変更する更新ではなく、破壊的変更も明記されていません。ただし、AVMのサンプルコードをコピーして社内Bicepモジュールに組み込んでいる場合や、APIバージョンをIaC標準で管理している場合は、リポジトリ内の該当コードを確認しておくべき更新です。(GitHub)
Microsoft Azure documentation update: fix: update deployment API version to 2025-04-01 in telemetry module の変更点
今回の更新は、Azure Verified Modulesの中央リポジトリに対するPRとして、2026年5月20日にマージされました。変更対象は docs/static/includes/sample.telem.bicep の1ファイルで、テレメトリ用のBicepサンプル内にある Microsoft.Resources/deployments リソースのAPIバージョンだけが更新されています。(GitHub)
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 対象ファイル | docs/static/includes/sample.telem.bicep | 同左 |
| 対象リソース | Microsoft.Resources/deployments | 同左 |
| APIバージョン | 2024-03-01 | 2025-04-01 |
| 目的 | 旧APIバージョンでのサンプル記述 | 最新のAzure Resource Manager APIに合わせる |
| 破壊的変更 | なし | なし |
差分としては、次の1行が本質です。
// 変更前
resource avmTelemetry 'Microsoft.Resources/deployments@2024-03-01' = if (enableTelemetry) {
// 変更後
resource avmTelemetry 'Microsoft.Resources/deployments@2025-04-01' = if (enableTelemetry) {PR本文では、変更理由として「sample telemetry bicep fileのdeployment API versionを 2024-03-01 から 2025-04-01 に更新し、最新のAzure Resource Manager APIに合わせる」と説明されています。また、Breaking Changesは「None」とされています。(GitHub)
そもそもAVMのテレメトリ用Bicepとは
Azure Verified Modules（AVM）は、Azure向けInfrastructure as Code（IaC）モジュールの標準化を目的としたMicrosoft主導の取り組みです。BicepやTerraformなどの言語で、Azureリソースや再利用可能な構成パターンを一貫してデプロイするためのモジュール群として位置付けられています。(Azure)
AVMのテレメトリは、AVMモジュールのデプロイ状況をMicrosoft側が把握するための仕組みです。Bicepの場合、avmTelemetry というデプロイメントを作成し、たとえば 46d3xbcp.res.compute-virtualmachine... のような名前で、AVM由来のデプロイであることを識別します。(Azure)
重要なのは、このテレメトリが「どのリソースをどの設定で作ったか」「顧客データの中身」といった情報をMicrosoftに提供する目的のものではない点です。AVMの説明では、テレメトリはAzureプラットフォームの組み込みメカニズムで取得され、AVMコード由来のデプロイを識別するためのGUIDベースの仕組みとされています。(Azure)
今回の更新で実際に何が変わるのか
今回変わるのは、テレメトリ用の空に近いARMデプロイメントを作る際に参照するAPIバージョンです。現行のサンプルでは、enableTelemetry が true の場合に avmTelemetry リソースを作成し、mode: 'Incremental'、空の resources: []、テレメトリ説明用の outputs を含むテンプレートをデプロイします。(GitHub)
Microsoft.Resources/deployments@2025-04-01 は、Microsoft Learn上でもBicep、ARM template、Terraform AzAPI向けのリファレンスとして公開されています。このリソースタイプは、テナント、管理グループ、サブスクリプション、リソースグループの各スコープを対象にしたデプロイメントで利用できます。(Microsoft Learn)
API変更ログを見ると、2025-04-01 では identity、externalInputDefinitions、externalInputs、systemData などに関する追加・更新が記載されています。ただし、今回のAVMテレメトリサンプルはこれらの新しいプロパティを積極的に使う変更ではなく、基本的にはAPIバージョンの整合性を最新化する更新と捉えるのが妥当です。(Microsoft Learn)
影響を受ける可能性が高い対象者
今回の更新は、Azureを利用しているすべての管理者が即対応すべき障害対応ではありません。影響が出る可能性があるのは、主にBicepやAVMを使ってAzure基盤をコード管理しているチームです。
| 対象者 | 確認すべきこと |
|---|---|
| AVMモジュールの作成者・保守者 | 自作モジュールの avmTelemetry が新しいAPIバージョンに沿っているか |
| 社内IaCテンプレートの管理者 | sample.telem.bicep をコピーしたコードが残っていないか |
| Azure管理者 | デプロイメント履歴に追加されるテレメトリ用デプロイを運用上どう扱うか |
| CI/CD担当者 | Bicepビルド、lint、what-if、validateのパイプラインでAPIバージョン更新後も通るか |
| ガバナンス担当者 | 社内のAPIバージョン許可リスト、コードレビュー基準、テンプレート標準に反映するか |
特に注意したいのは、「AVMの公開モジュールを使っているだけの利用者」と「AVMのサンプルをコピーして自分たちのBicepモジュールに組み込んでいる利用者」では対応の優先度が違う点です。前者は利用中のモジュール更新時に確認すれば十分なケースが多い一方、後者は社内リポジトリに古い Microsoft.Resources/deployments@2024-03-01 が残り続ける可能性があります。
管理者・開発者が確認すべきポイント
リポジトリ内の古いAPIバージョンを検索する
まずは、Azure IaCコードを管理しているリポジトリで次の文字列を検索します。
Microsoft.Resources/deployments@2024-03-01見つかった場合は、すぐに一律置換するのではなく、用途を確認してください。avmTelemetry のようなAVMテレメトリ用であれば、今回の更新に合わせて 2025-04-01 へ変更する候補になります。一方、実際のネストされたARMデプロイメントやリンクテンプレートで使っている場合は、テンプレートの構造や利用プロパティを確認してから検証環境で試すべきです。
enableTelemetry の扱いを確認する
AVMの仕様では、Bicepモジュールのテレメトリは既定で有効にしつつ、利用者が enableTelemetry を false にすることで無効化できる設計が求められています。(Azure)
実務では、次の観点で確認します。
| 確認項目 | 推奨アクション |
|---|---|
| 社内ポリシーでテレメトリを許可しているか | セキュリティ・法務・クラウドガバナンスの方針と照合する |
| 無効化が必要な環境があるか | 本番、検証、顧客環境などで enableTelemetry の既定値を整理する |
| モジュール利用者が設定を上書きできるか | パラメーターとして公開されているか確認する |
| パターンモジュールから子モジュールを呼ぶか | テレメトリ設定が意図せず二重計上されないように渡し方を確認する |
AVMの仕様では、他の公開モジュールを参照するリソースモジュールでは、参照先モジュール側のテレメトリを無効化する考え方も示されています。複数モジュールを組み合わせる構成では、単にAPIバージョンを直すだけでなく、テレメトリの有効・無効の伝播も確認すると安全です。(Azure)
Bicepのビルドとデプロイ前検証を実行する
APIバージョンの更新自体は小さな差分ですが、IaCでは「小さな変更でもパイプライン全体で失敗する」ことがあります。更新後は、少なくとも次の順序で確認するのがおすすめです。
| 手順 | 確認内容 |
| -: | ——————————————————————— |
| 1 | bicep build またはAzure CLI経由のBicep変換で構文エラーがないか確認する |
| 2 | CIのlintや静的解析でAPIバージョン、命名、禁止リソースのルールに抵触しないか確認する |
| 3 | 検証用リソースグループでwhat-ifを実行し、予期しないリソース変更が出ないか確認する |
| 4 | 必要に応じてARM deployment validateを実行し、Azure Resource Managerに受け入れられるか確認する |
| 5 | 本番反映前に、デプロイメント履歴に作成される avmTelemetry の名前とスコープを確認する |
Microsoft Learnでは、Validate APIはテンプレートが構文的に正しくAzure Resource Managerで受け入れられるかを検証する操作、What-if APIはデプロイ実行時に発生する変更を返す操作として説明されています。(Microsoft Learn)
移行時に失敗しやすいポイント
すべての deployments を機械的に置換してしまう
今回の更新対象は、AVMテレメトリ用サンプルです。Microsoft.Resources/deployments は、テレメトリ以外にもネストされたテンプレート、リンクテンプレート、Template Spec、マルチスコープ展開などで使われることがあります。
そのため、次のようなコードは用途を分けて判断します。
resource avmTelemetry 'Microsoft.Resources/deployments@2024-03-01' = if (enableTelemetry) {
// AVMテレメトリ用
}これは今回の更新対象に近いコードです。一方で、次のような実際のリソース展開に使っているデプロイメントは、APIバージョン更新後の挙動を検証してから反映します。
resource nestedDeployment 'Microsoft.Resources/deployments@2024-03-01' = {
name: 'deploy-network-components'
properties: {
mode: 'Incremental'
templateLink: {
uri: networkTemplateUri
}
}
}Microsoft.Resources/deployments の mode には Incremental と Complete があり、Complete ではテンプレートに含まれない既存リソースが削除される可能性があります。今回のAVMサンプルは Incremental を使っていますが、社内テンプレートを点検する際は Complete の混入にも注意してください。(Microsoft Learn)
テレメトリの無効化方法を知らないまま運用する
AVMのテレメトリは既定で有効ですが、Bicepでは enableTelemetry を false にすることでオプトアウトできます。(Azure)
たとえば、社内ルールでテレメトリを無効化する必要がある場合は、モジュール呼び出し側で次のように指定します。
module vm 'br/public:avm/res/compute/virtual-machine:<version>' = {
name: 'deploy-vm'
params: {
// ほかのパラメーター
enableTelemetry: false
}
}ただし、すべての場面で無効化すべきとは限りません。AVM側は利用状況を把握して品質改善や採用状況の理解に役立てるため、既定では有効のままにすることを推奨しています。組織のプライバシー方針、監査要件、顧客契約に照らして判断しましょう。(Azure)
デプロイメント履歴のノイズを放置する
avmTelemetry はAzureのデプロイメントとして記録されます。AVMの説明でも、Bicep利用者は対応するスコープのDeploymentsセクションで同じデプロイメント情報を確認できるとされています。(Azure)
運用チームがAzure PortalやActivity Logを見ている場合、46d3xbcp... のような名前のデプロイメントが表示され、「これは誰が作ったのか」と混乱することがあります。対策として、運用RunbookやIaC標準に次の説明を入れておくと問い合わせを減らせます。
| 表示されるもの | 意味 |
|---|---|
46d3xbcp... で始まるデプロイメント | AVM Bicepモジュール由来のテレメトリ用デプロイメント |
resources: [] のテンプレート | 実リソース作成ではなく識別用のデプロイメント |
enableTelemetry: false | テレメトリ作成を抑止する設定 |
実務での対応方針
今回の更新は、重大な移行作業というより「IaC標準のメンテナンス」として扱うのが適切です。おすすめの対応は次の3段階です。
まずは棚卸しする
Bicepリポジトリ、テンプレート共有リポジトリ、社内のAVMラッパーモジュールで、次のキーワードを検索します。
avmTelemetry
enableTelemetry
Microsoft.Resources/deployments@2024-03-01
sample.telem.bicep見つかったコードを、次の3種類に分類します。
| 分類 | 判断 |
|---|---|
| AVMテレメトリ用 | 2025-04-01 への更新候補 |
| 独自のネストデプロイ用 | 影響確認後に更新 |
| 使われていない古いサンプル | 削除またはアーカイブを検討 |
次に検証環境で更新する
AVMテレメトリ用のコードであれば、APIバージョンを 2025-04-01 に更新し、検証環境でビルド、lint、what-if、validateを実行します。特に、社内でAPIバージョンを制限する静的解析ルールや、Bicepテンプレートの自動レビューを導入している場合は、そこで失敗しないかを確認してください。
最後に運用ドキュメントへ反映する
コードだけ直しても、運用チームがテレメトリ用デプロイメントの意味を知らないと問い合わせが残ります。次の内容をIaC標準や運用Runbookに追記すると、後続対応が楽になります。
AVM Bicepモジュールでは、利用状況把握のために avmTelemetry という空に近いデプロイメントが作成される場合がある。
2026年5月20日のAVM更新により、サンプルの Microsoft.Resources/deployments APIバージョンは 2025-04-01 に更新された。
テレメトリを無効化する必要がある場合は enableTelemetry を false に設定する。今回の更新をどう判断すべきか
「Microsoft Azure documentation update: fix: update deployment API version to 2025-04-01 in telemetry module」は、Azure本体の機能変更というより、AVMのBicepテレメトリサンプルを最新のAzure Resource Manager APIに合わせるためのドキュメント・サンプル更新です。PR上では破壊的変更なしとされ、変更ファイルも docs/static/includes/sample.telem.bicep に限定されています。(GitHub)
一方で、BicepやAVMを社内標準として使っているチームにとっては、放置してよいだけの更新ではありません。古いAPIバージョンが社内テンプレートに残ると、将来のlint、ポリシー、コードレビュー、モジュール更新時に小さな不整合として積み上がります。
次に取るべき行動はシンプルです。まずリポジトリ内で Microsoft.Resources/deployments@2024-03-01 と avmTelemetry を検索し、AVMテレメトリ用コードだけを優先的に 2025-04-01 へ更新します。その後、検証環境でBicepのビルド、what-if、validateを実行し、運用ドキュメントに enableTelemetry の扱いを明記しておきましょう。
コメント