Azure Networkingの「Azure Networking documentation update: Fix NetworkCloud ChangeLog」は、Azureのネットワーク機能そのものが突然変わる更新ではなく、Az.NetworkCloudのChangeLogにAPIバージョン更新と事前告知済みの破壊的変更を正しく反映するためのドキュメント修正です。実務上は、Azure Operator Nexus / Microsoft.NetworkCloudをPowerShell、ARM/Bicep、CI/CDで管理しているチームが、API version 2025-09-01への移行影響を確認する必要があります。一般的なVNet、NSG、Azure Firewallだけを使っている環境では、直接の影響は限定的です。
今回のポイントは、ChangeLogの記載が「Upcoming Release」に整理され、Az.NetworkCloudモジュールでAPI version 2025-09-01へのアップグレードと、事前告知済みのbreaking changesが明示されたことです。特に、Managed Identity、VolumeのSizeMiB、一部コマンドのJSON入力、リソース定義のapiVersionを固定している自動化スクリプトは、展開前に確認しておくべきです。(GitHub)
Azure Networking documentation update: Fix NetworkCloud ChangeLogで何が変わったのか
今回の更新は、GitHub上のAzure PowerShellリポジトリに対するPull Request「Fix NetworkCloud ChangeLog」として反映されたものです。PRは2026年5月20日にマージされ、説明には「API version upgrade」と「preannounced breaking changes」をChangeLogに反映する更新だと記載されています。(GitHub)
修正後のAz.NetworkCloud ChangeLogでは、## Upcoming Releaseの下に次の2点が追加されています。(GitHub)
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| API versionの更新 | 2025-09-01へアップグレード | PowerShellモジュールや生成クライアントが新しいMicrosoft.NetworkCloud APIを使う可能性がある |
| 破壊的変更の事前告知 | Preannounced breaking changesを明記 | 既存スクリプト、CI/CD、IaC定義の一部で修正が必要になる可能性がある |
ここで重要なのは、ChangeLog修正そのものが既存リソースを変更するわけではないという点です。影響が出るのは、今後のAz.NetworkCloudモジュール更新、APIクライアント更新、ARM/BicepテンプレートのapiVersion変更、または自動化パイプラインで新しいコマンド仕様を使う場面です。
NetworkCloudはどの範囲のサービスか
NetworkCloudは、Azureの一般的な仮想ネットワーク管理とは異なり、Microsoft.NetworkCloudリソースプロバイダーを通じて、オンプレミスのクラスタ、ラック、ベアメタルマシン、仮想マシン、ワークロードネットワークなどを管理する領域です。Azure Operator Nexusの文脈で使われることが多く、通信事業者向けのハイブリッドクラウド基盤やネットワーク機能の運用に関わります。(Microsoft Learn)
そのため、今回の更新を「Azure Networking全体の仕様変更」と広く捉えるより、Az.NetworkCloud / Microsoft.NetworkCloudを使う運用・開発チーム向けの変更として読むのが正確です。
影響を受けやすいのは、次のようなチームです。
| 対象者 | 確認すべき内容 |
|---|---|
| Azure Operator Nexus / NetworkCloudの管理者 | クラスタ、クラスタマネージャ、ベアメタルマシン、ストレージ、ネットワーク関連リソースの更新手順 |
| Azure PowerShellで運用している担当者 | Az.NetworkCloudモジュールのバージョン、コマンド構文、パラメーター変更 |
| ARM/Bicepで展開している開発者 | Microsoft.NetworkCloud/*のapiVersion、リソース定義の差分 |
| CI/CD管理者 | PowerShellモジュールの自動更新、パイプライン内の固定パラメーター、テスト環境での検証 |
| SDK / REST API利用者 | 2025-09-01 APIへの切り替え時のレスポンス・プロパティ差分 |
一方で、通常のAzure NetworkingであるVNet、Subnet、NSG、Route Table、Azure Firewall、Application Gatewayなどだけを管理している場合、今回のAz.NetworkCloud ChangeLog修正による直接影響は基本的にありません。
API version 2025-09-01への更新で確認すべきこと
Microsoft LearnのMicrosoft.NetworkCloudリソースプロバイダーのバージョン一覧では、複数のNetworkCloudリソースに2025-09-01 API versionが掲載されています。このページも2026年5月20日に更新されています。(Microsoft Learn)
API versionの更新で注意すべきなのは、単に日付が新しくなることではありません。Azureでは、API versionごとに利用できるプロパティ、必須項目、型、応答内容が変わることがあります。既存のテンプレートが動いていても、apiVersionを変更した瞬間に検証エラーやデプロイ失敗が起きることがあります。
たとえば、Microsoft.NetworkCloudのl2NetworksのChangeLogでは、2025-09-01で共通型のExtended Locationが追加され、従来のExtendedLocationが削除されたことが示されています。これは、テンプレートや生成コードで拡張ロケーションの型を前提にしている場合、差分確認が必要になる典型例です。(Microsoft Learn)
ARMテンプレートやBicepで次のようにapiVersionを固定している場合は、対象リソースごとにChangeLogを確認してから更新してください。
resource networkCloudResource 'Microsoft.NetworkCloud/xxxxx@2025-09-01' = {
name: name
location: location
properties: {
// 対象リソースの仕様に合わせて定義
}
}実務では、すべてのMicrosoft.NetworkCloudリソースを一括で2025-09-01に上げるより、クラスタ、ネットワーク、ストレージ、仮想マシンなどの単位で段階的に検証する方が安全です。
Az.NetworkCloudモジュールで注目すべき変更点
Az.NetworkCloudの関連PRでは、NetworkCloud ARM API version 2025-09-01を対象に、生成クライアント、UXメタデータ、ヘルプ、テスト記録、コマンドエクスポートなどが更新されたことが説明されています。(GitHub)
特に確認すべきポイントは次の3つです。
Managed Identity関連のパラメーター
Azure PowerShellのリリースノートでは、Az.NetworkCloud 2.0.0において、Managed Identity設定をサポートするコマンドとして、New-AzNetworkCloudCluster、New-AzNetworkCloudClusterManager、Update-AzNetworkCloudCluster、Update-AzNetworkCloudClusterManagerが挙げられています。また、ユーザー体験と整合性の改善により、破壊的変更が入る可能性があるとも説明されています。(Microsoft Learn)
New-AzNetworkCloudClusterのヘルプでは、-EnableSystemAssignedIdentityや-UserAssignedIdentityなどのパラメーターが確認できます。クラスタ作成時にユーザー割り当てマネージドIDを渡す例も示されています。(GitHub)
既存スクリプトでIdentity関連のオブジェクトを直接組み立てている場合は、次の観点で確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| システム割り当てID | -EnableSystemAssignedIdentityを使う設計に変えるべきか |
| ユーザー割り当てID | -UserAssignedIdentityに渡すリソースID形式が正しいか |
| 既存のIdentityオブジェクト | 古い型やプロパティ名に依存していないか |
| RBAC | Managed Identityに必要な権限が事前に付与されているか |
| 更新処理 | 新規作成だけでなくUpdate-*でも同じ設定が必要か |
Managed Identityは「認証設定」ではなく、展開後の運用権限にも関わります。スクリプト上でパラメーターを追加するだけでなく、対象IDに付与するロール、スコープ、最小権限の設計まで確認してください。
VolumeのSizeMiBに関する互換性リスク
破壊的変更の事前告知に関する静的解析情報では、Get-AzNetworkCloudVolume、New-AzNetworkCloudVolume、Update-AzNetworkCloudVolumeにおいて、IVolumeのSizeMiBプロパティ型がNullableなInt64から通常のInt64へ変わる差分が記録されています。(GitHub)
これは、スクリプト内でSizeMiBが未設定、空、またはnullになる可能性を前提にしている場合に影響します。たとえば、次のような処理は見直し候補です。
$volume = Get-AzNetworkCloudVolume -Name $name -ResourceGroupName $rg
if ($null -eq $volume.SizeMiB) {
Write-Host "サイズ未設定として処理"
}新しい仕様では、値が常に数値として返る前提になる可能性があります。運用スクリプトでは、null判定だけで分岐するのではなく、「期待するサイズと一致しているか」「0や異常値ではないか」「作成時に明示的なサイズ指定が必要か」を確認する方が安全です。
JSON入力パラメーターを使う更新処理
同じ静的解析情報では、Update-AzNetworkCloudVirtualMachineにおいて、JsonFilePath、JsonString、および関連するパラメーターセットのサポート終了が互換性リスクとして記録されています。(GitHub)
ただし、公開ドキュメントやモジュールの反映タイミングは、対象バージョンによってずれることがあります。そのため、「いま見ているWeb上のヘルプ」だけで判断せず、実際にパイプラインで使うモジュールに対して構文を確認してください。
Get-Command Update-AzNetworkCloudVirtualMachine -SyntaxJSONファイルを渡して更新する運用をしている場合は、次のどれに移行できるかを検討します。
| 現在の運用 | 移行候補 |
|---|---|
JsonFilePathでJSONファイルを渡す | 展開用PowerShellパラメーターへ分解する |
JsonStringでJSON文字列を渡す | ARM/BicepまたはREST API呼び出しに寄せる |
| CI/CDでテンプレート生成後にPowerShell更新 | IaC側でリソース定義を完結させる |
| 手動更新時だけJSONを使う | 手順書を新しいコマンド構文に更新する |
この種の変更は、本番環境で初めて検出されると復旧に時間がかかります。少なくとも、検証環境でGet-Command -Syntax、既存スクリプトのドライラン、差分デプロイを実行してから切り替えてください。
管理者・開発者向けの事前確認チェックリスト
今回のChangeLog修正を受けて、管理者や開発者がすぐ確認すべき項目は次の通りです。
| 確認対象 | コマンド・確認方法 | 判断基準 |
|---|---|---|
| インストール済みモジュール | Get-InstalledModule Az.NetworkCloud -AllVersions | 想定外の自動更新が入っていないか |
| コマンド構文 | Get-Command -Module Az.NetworkCloud | 使用中コマンドのパラメーターが変わっていないか |
| VM更新コマンド | Get-Command Update-AzNetworkCloudVirtualMachine -Syntax | JSON入力系のパラメーターに依存していないか |
| IaCテンプレート | Microsoft.NetworkCloud/*@apiVersionを検索 | 古いAPI versionや未検証の2025-09-01が混在していないか |
| Identity設定 | Cluster / ClusterManagerの作成・更新処理 | Managed Identityの指定方法とRBACが正しいか |
| Volume処理 | SizeMiBを扱うスクリプト | null前提の分岐がないか |
| CI/CD | PowerShellモジュールのインストール手順 | バージョン固定なしで最新版を取得していないか |
リポジトリ全体を検索する場合は、次のようなキーワードを使うと影響箇所を見つけやすくなります。
rg "Microsoft\.NetworkCloud|AzNetworkCloud|Az\.NetworkCloud|apiVersion.*2025-09-01|apiVersion.*2025-02-01|IdentityUserAssignedIdentity|SizeMiB|JsonFilePath|JsonString" .Windows環境でripgrepを使っていない場合は、PowerShellでも確認できます。
Get-ChildItem -Recurse -File |
Select-String -Pattern "Microsoft\.NetworkCloud|Az\.NetworkCloud|AzNetworkCloud|IdentityUserAssignedIdentity|SizeMiB|JsonFilePath|JsonString"検索結果が多い場合は、まずCI/CD、運用Runbook、障害対応スクリプト、定期棚卸しスクリプトを優先してください。影響が大きいのは、普段は手で触らないものの、障害時や定期処理で必ず実行される自動化です。
移行・展開時に失敗しやすいポイント
PowerShellモジュールを自動で最新版にしている
CI/CD内で次のように書いている場合、将来の実行時に意図せず新しいAz.NetworkCloudが入る可能性があります。
Install-Module Az.NetworkCloud -Scope CurrentUser -Force本番パイプラインでは、検証済みのバージョンを固定する運用が基本です。
Install-Module Az.NetworkCloud -RequiredVersion "x.y.z" -Scope CurrentUser -Forceバージョン固定は更新を止めるためではなく、検証済みのタイミングで更新するための仕組みです。新しいAPI versionを使う場合は、検証環境で成功したモジュールバージョンを明示してから本番に展開してください。
API versionだけを先に変更する
ARM/BicepでapiVersionだけを2025-09-01に置き換えるのは避けるべきです。API version変更では、プロパティの追加だけでなく、型の変更や削除が起こることがあります。Microsoft.NetworkCloudのリソース一覧では多くのリソースに2025-09-01が掲載されていますが、影響はリソース種別ごとに異なります。(Microsoft Learn)
安全な進め方は、次の順番です。
| 手順 | 作業内容 |
|---|---|
| 1 | 使っているMicrosoft.NetworkCloud/*リソースを一覧化する |
| 2 | 各リソースのChangeLogで2025-09-01差分を確認する |
| 3 | テンプレートのスキーマ差分を修正する |
| 4 | 検証環境でwhat-ifまたはドライランを実行する |
| 5 | 本番環境はメンテナンス手順とロールバック条件を決めてから展開する |
「動くはず」ではなく、「対象リソースで差分を確認した」と言える状態にしてから切り替えることが重要です。
事前告知済みのbreaking changesを軽視する
今回のChangeLogには「Preannounced breaking changes」が明記されています。別PRでは、NetworkCloudモジュールをAPI version 2025-09-01へ更新する前に、breaking changesを事前告知する内容がマージされています。(GitHub)
事前告知は、すぐに全環境へ影響が出るという意味ではありません。しかし、モジュール更新やAPI version更新のタイミングで、既存のスクリプトが失敗する可能性を示します。
特に次のような運用は、事前に棚卸ししてください。
Az.NetworkCloudコマンドの出力プロパティをそのまま別処理に渡しているConvertTo-Json/ConvertFrom-Jsonでオブジェクト構造を前提にしているJsonFilePathやJsonStringのような入力形式に依存しているSizeMiBなどの数値プロパティをnull判定している- Managed Identityのオブジェクト型を独自に組み立てている
- コマンドの
-DefaultProfileや認証コンテキストを複数サブスクリプションで使い回している
小さな型変更でも、PowerShellではパイプライン処理やJSON変換の結果が変わることがあります。単体コマンドだけでなく、前後の処理まで含めて確認してください。
展開前に行うべき検証手順
本番適用前には、次の流れで確認すると失敗を減らせます。
現在の実行環境を記録する
まず、現在使っているPowerShellとモジュールの状態を保存します。
$PSVersionTable
Get-InstalledModule Az.NetworkCloud -AllVersions |
Select-Object Name, Version, InstalledDate
Get-InstalledModule Az.Accounts -AllVersions |
Select-Object Name, Version, InstalledDateNetworkCloudの更新では、Az.Accountsなど依存モジュールのバージョンも関係する場合があります。モジュールだけでなく、実行環境全体を記録しておくと、問題発生時に原因を切り分けやすくなります。
使用中コマンドの構文を比較する
検証環境に新しいモジュールを入れたら、使用中のコマンドだけを抜き出して構文を比較します。
$commands = @(
"New-AzNetworkCloudCluster",
"Update-AzNetworkCloudCluster",
"New-AzNetworkCloudClusterManager",
"Update-AzNetworkCloudClusterManager",
"New-AzNetworkCloudVolume",
"Update-AzNetworkCloudVolume",
"Update-AzNetworkCloudVirtualMachine"
)
foreach ($cmd in $commands) {
Get-Command $cmd -Syntax
}差分を見るときは、「パラメーターが存在するか」だけでなく、「型が変わっていないか」「必須になっていないか」「パラメーターセットが変わっていないか」を確認してください。
IaCとPowerShellの責任範囲を整理する
NetworkCloud環境では、ARM/Bicepで作る部分とPowerShellで更新する部分が混在しがちです。API version更新のタイミングで、次のように責任範囲を整理しておくと運用が安定します。
| 領域 | 推奨される管理方法 |
|---|---|
| 繰り返し作成する基盤リソース | ARM/BicepなどIaCで管理 |
| 一時的な運用操作 | PowerShellで手順化 |
| IdentityやRBAC | IaCと権限申請フローを連携 |
| 障害時の復旧操作 | バージョン固定済みRunbookとして管理 |
| 棚卸し・監視 | ページングや出力形式の変更に強いスクリプトにする |
PowerShellは柔軟ですが、リソースの望ましい状態を長期的に保つにはIaCの方が向いています。API version更新を機に、「どちらで管理するか」を見直すと、将来の変更にも対応しやすくなります。
管理者が今すぐ取るべき対応
今回の「Fix NetworkCloud ChangeLog」は、ドキュメント修正だからといって無視する更新ではありません。ChangeLogに反映された内容は、今後のAz.NetworkCloudモジュールやMicrosoft.NetworkCloud APIを使う運用に関わります。
まず行うべきことは、次の3つです。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | Az.NetworkCloudを使っているスクリプトとCI/CDを棚卸しする | 影響範囲を明確にする |
| 高 | モジュールバージョンを固定し、検証環境で新バージョンを試す | 本番での予期しない失敗を防ぐ |
| 中 | Microsoft.NetworkCloudのapiVersionをリソース別に確認する | IaC更新時のデプロイ失敗を防ぐ |
| 中 | Managed Identity、Volume、VM更新処理を重点確認する | 破壊的変更の影響を先に潰す |
| 中 | Runbookと手順書を新しい構文に合わせて更新する | 障害時対応の手戻りを防ぐ |
今回の更新を正しく扱うコツは、ChangeLog修正を「単なる記載変更」ではなく、API version 2025-09-01移行の準備サインとして読むことです。Az.NetworkCloudやMicrosoft.NetworkCloudを本番運用している場合は、モジュールの自動更新をいったん抑制し、検証環境でコマンド構文、IaCテンプレート、Managed Identity、Volume、VM更新処理を順に確認してください。これにより、API更新後の展開失敗や運用スクリプトの停止を事前に防げます。
コメント