MENU

Azure REST APIでMicrosoft.NetworkCloud 2024-10-01-previewが削除｜影響範囲と移行確認

Azure

2026年5月初旬のAzure REST API更新で確認すべきポイントは、Microsoft.NetworkCloud の 2024-10-01-preview がREST API仕様から削除されたことです。これは新機能追加ではなく、すでに非推奨となっていたpreview APIバージョンの整理です。ARM/Bicep、Terraform AzAPI、az rest、独自RESTクライアント、SDK生成、CIのOpenAPI検証で api-version=2024-10-01-preview を使っている場合は、影響確認と移行計画が必要です。対象PRはARM、つまりControl Plane APIの仕様変更として扱われ、目的欄でも「fully deprecated 2024-10-01-preview API version」を削除すると説明されています。(GitHub)

特に注意したいのは、単に文字列を 2025-09-01 や 2026-05-01-preview に置き換えればよい、という変更ではない点です。Microsoft.NetworkCloud はAzure Operator Nexus / Network Cloudのリソース管理に関わるため、クラスター、ベアメタルマシン、Kubernetesクラスター、ネットワーク、ストレージ、仮想マシンなどの作成・更新・操作に使われている可能性があります。まずは自社のコード、IaC、スクリプト、SDK、パイプラインから 2024-10-01-preview の利用箇所を洗い出し、リソースと操作ごとに移行先APIバージョンを判断しましょう。

目次

Azure REST APIの今回の更新で何が変わったか

今回の変更は、Azure REST API仕様リポジトリ Azure/azure-rest-api-specs のPull Request Microsoft.NetworkCloud remove 2024-10-01-preview によるものです。PRは2026年5月6日にmainブランチへマージされており、2026年5月5日前後に確認されたドキュメント更新として扱う場合でも、実際の仕様リポジトリ上の反映日は5月6日と見ておくのが安全です。(GitHub)

削除対象は次のパス配下です。

specification/networkcloud/resource-manager/Microsoft.NetworkCloud/preview/2024-10-01-preview

この配下には networkcloud.json と多数のサンプルJSONが含まれていました。PRのFiles changedでは .json が137件、.md が2件変更対象として表示され、AgentPools、BareMetalMachines、CloudServicesNetworks、ClusterManagers、Clusters、KubernetesClusters、L2Networks、L3Networks、Racks、StorageAppliances、TrunkedNetworks、VirtualMachines、Volumes などの例が削除対象に含まれていることが確認できます。(GitHub)

確認項目内容
対象サービスAzure REST API / Azure Operator Nexus – Network Cloud
対象リソースプロバイダーMicrosoft.NetworkCloud
削除されたAPIバージョン2024-10-01-preview
変更の種類ARM Control Plane API仕様の整理
実務上の意味OpenAPI仕様、サンプル、SDK生成、CI検証、ドキュメント参照で旧preview版に依存できなくなる
まず確認すべき対象ARM/Bicep、Terraform AzAPI、az rest、PowerShell/Bash、独自RESTクライアント、SDK、OpenAPI検証

今回の変更は、Azure上の既存リソースが即座に削除されるという意味ではありません。ただし、API仕様から削除されたバージョンに依存していると、ドキュメント参照、SDK生成、型チェック、CIのスキーマ検証、将来のAPI呼び出しで問題が起きる可能性があります。preview APIを本番運用の自動化に組み込んでいる場合は、早めに移行したほうが安全です。

影響を受ける可能性が高いケース

Microsoft.NetworkCloud をAzure Portalだけで操作している利用者よりも、コードや自動化で管理しているチームのほうが影響を受けやすい変更です。特に、APIバージョンを明示する仕組みを使っている場合は確認が必要です。

利用箇所影響の例確認ポイント
ARMテンプレート"apiVersion": "2024-10-01-preview" が残っているデプロイ対象リソースのAPIバージョンを更新する
BicepMicrosoft.NetworkCloud/...@2024-10-01-preview を使っているリソース型ごとに現在の参照バージョンを確認する
Terraform AzAPItype = "Microsoft.NetworkCloud/...@2024-10-01-preview" を指定しているbodyのプロパティ差分も確認する
az restURLに ?api-version=2024-10-01-preview が固定されているGETだけでなくPUT、PATCH、POST、DELETEも確認する
PowerShell/BashREST URLを文字列で組み立てている変数や共通関数に旧バージョンがないか探す
独自RESTクライアントAPIバージョンを定数化している定数、環境変数、設定ファイルを確認する
SDK生成削除されたOpenAPI仕様からクライアントを生成している生成元のswaggerパスとSDKの型変更を確認する
CI/CDOpenAPI snapshotやfixtureを参照している削除済みパスへの参照を更新する

PRではAPIViewがJavaScriptの @azure/arm-networkcloud とJavaの com.azure.resourcemanager:azure-resourcemanager-networkcloud にAPIレベルの変更を検出したことも記録されています。さらに、JavaScript SDKのBreaking Changeに関するラベルも付与されています。これは、すべてのアプリケーションが必ず壊れるという意味ではありませんが、SDK生成や型定義に依存しているチームは、ビルドとテストを確認すべきサインです。(GitHub)

移行先APIバージョンはどう選ぶべきか

移行先は「最新previewを選べばよい」とは限りません。基本方針は、対象リソースと操作が安定版で利用できるなら安定版を優先し、preview固有の機能が必要な場合のみpreviewを選ぶことです。

現在の networkcloud/resource-manager/readme.md では、グローバル設定のtagが package-2025-09-01 になっています。また、package-2025-09-01 は Microsoft.NetworkCloud/stable/2025-09-01/networkcloud.json を参照しています。(GitHub)

一方で、同じreadmeには package-2026-01-01-preview や package-2026-05-01-preview も存在します。つまり、安定版で対応できる操作と、preview版を参照すべき操作が混在している可能性があります。(GitHub)

判断基準推奨される選び方
本番運用の通常リソース管理まず安定版の 2025-09-01 で対応できるか確認する
preview限定の操作や新機能を使うMicrosoft Learnで対象操作のAPI Versionを確認し、該当previewを使う
既存テンプレートを移行するリソース型、必須プロパティ、レスポンス差分を比較してから変更する
SDKを使っているSDKのリリースノート、型定義、生成元APIバージョンを確認する
複数の操作を同じスクリプトで実行している1つのAPIバージョンを全操作に流用せず、操作単位で確認する

たとえば、Microsoft Learnの Cloud Services Networks - Get はAPI Version 2025-09-01 として公開されており、URLにも api-version=2025-09-01 が指定されています。また、URI Parametersでは api-version が必須のqueryパラメーターとして説明されています。(Microsoft Learn)

一方、Clusters - Inspect や Clusters - Rotate Credential のような操作は、API Version 2026-05-01-preview のページとして公開されています。これらの操作を使う場合は、安定版へ機械的に寄せるのではなく、操作ごとのドキュメントを確認する必要があります。(Microsoft Learn)

まずやるべき確認手順

リポジトリ全体で旧APIバージョンを検索する

最初にやるべきことは、利用箇所の棚卸しです。リポジトリ、IaC、runbook、CI設定、手順書、サンプルコードから 2024-10-01-preview を探します。

Linux、macOS、WSLなら次のように検索できます。

grep -R "2024-10-01-preview" .
grep -R "Microsoft.NetworkCloud" .

PowerShellなら次のコマンドが使えます。

Get-ChildItem -Recurse -File |
  Select-String -Pattern "2024-10-01-preview","Microsoft.NetworkCloud"

検索対象はソースコードだけでは不十分です。以下も忘れずに確認してください。

場所見るべき内容
*.bicepMicrosoft.NetworkCloud/...@2024-10-01-preview
ARMテンプレート"apiVersion": "2024-10-01-preview"
TerraformMicrosoft.NetworkCloud/...@2024-10-01-preview
Bash / PowerShellREST URL内の api-version=2024-10-01-preview
GitHub Actions / Azure DevOpsOpenAPI検証、snapshot、fixture
アプリ設定APIバージョンを環境変数やJSONで管理していないか
社内ドキュメント手順書のサンプルURLやテンプレート

リソースと操作ごとに分類する

旧APIバージョンが見つかったら、すぐに置換するのではなく、リソースと操作で分類します。

分類例は次のとおりです。

分類例優先度
読み取りGET、LIST低〜中。移行検証の最初に使いやすい
作成・更新PUT、PATCH高。body差分や必須項目の確認が必要
削除DELETE高。誤実行防止と検証環境が必要
アクションPOST .../start、.../restart、.../inspect など高。長時間操作や状態変化を伴う可能性がある
SDK生成OpenAPIからクライアントを生成高。型変更やメソッド変更がビルドに影響する
CI検証swagger pathやexample pathを固定中〜高。仕様削除でパイプラインが失敗しやすい

Network Cloud系のAPIは、単なる参照だけでなく、クラスターのデプロイ、バージョン更新、ベアメタルマシンの操作、ストレージアプライアンスの操作など、運用に直結する操作を含みます。状態変更を伴うAPIは、検証環境で十分に試してから本番へ反映しましょう。

具体的な移行例

REST API呼び出しの例

旧APIバージョンを使っているREST呼び出しは、次のような形になっていることがあります。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.NetworkCloud/cloudServicesNetworks/{cloudServicesNetworkName}?api-version=2024-10-01-preview

Cloud Services Networks - Get のように 2025-09-01 で公開されている操作なら、ドキュメントに合わせて次のように変更します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.NetworkCloud/cloudServicesNetworks/{cloudServicesNetworkName}?api-version=2025-09-01

ただし、これは該当操作が 2025-09-01 で利用できる場合の例です。inspect や rotateCredential のように 2026-05-01-preview で公開されている操作もあるため、REST APIリファレンスで操作ごとのAPI Versionを確認してください。

Bicepの例

Bicepで旧previewを指定している場合、次のような記述が残っている可能性があります。

resource ncCluster 'Microsoft.NetworkCloud/clusters@2024-10-01-preview' = {
  name: clusterName
  location: location
  properties: {
    // 既存の設定
  }
}

安定版で対象リソースがサポートされている場合は、候補として次のように変更します。

resource ncCluster 'Microsoft.NetworkCloud/clusters@2025-09-01' = {
  name: clusterName
  location: location
  properties: {
    // 新しいAPIバージョンのスキーマに合わせて確認
  }
}

ここで重要なのは、@2025-09-01 に変えるだけで完了にしないことです。APIバージョンが変わると、必須プロパティ、許可される値、レスポンス、長時間操作の扱いが変わる場合があります。既存のbodyをそのまま使えるか、Microsoft Learnのリファレンスと実際のデプロイ検証で確認してください。

Terraform AzAPIの例

Terraform AzAPIでは、type にAPIバージョンを含めていることがあります。

resource "azapi_resource" "networkcloud_cluster" {
  type      = "Microsoft.NetworkCloud/clusters@2024-10-01-preview"
  name      = var.cluster_name
  parent_id = azurerm_resource_group.example.id
  location  = var.location

  body = {
    properties = {
      # 既存の設定
    }
  }
}

移行時は、対象リソースが安定版で利用できるなら次のように変更を検討します。

resource "azapi_resource" "networkcloud_cluster" {
  type      = "Microsoft.NetworkCloud/clusters@2025-09-01"
  name      = var.cluster_name
  parent_id = azurerm_resource_group.example.id
  location  = var.location

  body = {
    properties = {
      # 新しいAPIバージョンのスキーマに合わせて確認
    }
  }
}

AzAPIは柔軟な反面、bodyの型チェックが利用者側に寄りがちです。terraform plan が通っても、Azure Resource Manager側の検証で失敗することがあります。更新系の操作は検証用リソースグループで実行し、エラー内容を確認してから本番へ展開しましょう。

移行時に失敗しやすいポイント

preview版だから本番では使っていないと思い込む

実務では、preview版APIが検証時に作られたスクリプトから本番運用へ流れ込むことがあります。特に、az rest のURLやTerraform AzAPIの type は、作成当時のサンプルをそのまま使い続けがちです。

「本番では使っていないはず」ではなく、必ず検索で確認してください。

GETの確認だけで移行完了にする

読み取りAPIが成功しても、PUT、PATCH、POSTが成功するとは限りません。作成・更新系はrequest bodyのスキーマ差分が影響します。

移行テストは次の順序が安全です。

順序テスト内容目的
1GET / LIST認証、URL、基本的なAPIバージョンの確認
2既存bodyのschema確認必須項目や型の差分を把握
3非破壊の更新tags更新など影響の小さい操作で確認
4作成・更新検証環境でPUT/PATCHを確認
5操作系POSTstart、restart、inspectなど状態変化を伴う操作を慎重に確認
6削除誤削除を防ぐため検証環境でのみ実施

最新previewへ一括移行する

2026-05-01-preview のような新しいpreviewは、特定の新機能や操作には必要な場合があります。しかし、本番運用の全リソースをpreviewへ寄せるのは慎重に判断すべきです。

安定版で足りるリソースは安定版を使い、previewが必要な操作だけ個別に扱うほうが保守しやすくなります。

SDKの型変更を軽視する

PR上では、JavaScriptとJavaのAPIレビューが生成されています。SDKを使っている場合、REST URLの文字列だけでなく、クライアントのメソッド名、パラメーター、型、サンプルコードが変わる可能性があります。(GitHub)

次の観点で確認しましょう。

  • SDKパッケージのバージョン
  • 生成元のAPIバージョン
  • 既存コードの型エラー
  • シリアライズされるrequest body
  • サンプルコードや社内共通ライブラリ
  • モック、fixture、snapshotテスト

CIのOpenAPI参照パスを更新し忘れる

OpenAPI仕様やexampleファイルをCIで参照している場合、削除されたパスに依存しているとビルドが失敗します。特に、次のような設定は見落としやすいです。

specification/networkcloud/resource-manager/Microsoft.NetworkCloud/preview/2024-10-01-preview/networkcloud.json

このようなパスを直接指定している場合は、移行先の仕様ファイルに更新してください。あわせて、旧preview版の利用を防ぐテストを追加すると再発防止になります。

社内で使える確認チェックリスト

移行作業では、担当者ごとに確認範囲が分散しやすくなります。次のチェックリストを使うと、影響範囲を整理しやすくなります。

チェック確認内容
旧APIバージョン検索2024-10-01-preview がリポジトリや手順書に残っていないか
リソース分類clusters、kubernetesClusters、virtualMachines など、対象リソースを分類したか
操作分類GET、PUT、PATCH、POST、DELETEを分けて確認したか
移行先判断安定版で足りるか、previewが必要かを操作単位で判断したか
body差分確認request bodyの必須項目、型、enum、ネスト構造を確認したか
SDK確認JavaScript、Java、Python、Goなど利用SDKの影響を確認したか
CI更新削除されたOpenAPIパスやexampleパスを参照していないか
検証環境テスト本番前に読み取り、更新、操作系APIを段階的に試したか
ロールバック準備失敗時に元のデプロイ手順へ戻せるか
再発防止2024-10-01-preview を禁止するCIチェックを追加したか

旧APIバージョンを検出するCIガードの例

GitHub Actionsなどで、旧APIバージョンが再び混入しないように簡易チェックを入れておくと安全です。

if grep -R "2024-10-01-preview" . \
  --exclude-dir=.git \
  --exclude-dir=node_modules \
  --exclude-dir=.terraform; then
  echo "Deprecated Microsoft.NetworkCloud API version 2024-10-01-preview was found."
  exit 1
fi

ただし、移行メモやこの記事へのリンクなど、意図的に旧バージョン名を残すファイルがある場合は除外設定を追加してください。CIガードの目的は、運用コードやデプロイ定義に旧APIバージョンが戻ることを防ぐことです。

今回の更新をどう扱うべきか

Microsoft.NetworkCloud remove 2024-10-01-preview は、表面的には「古いpreview API仕様の削除」です。しかし、実務では次の3つの観点で重要です。

1つ目は、古いpreview APIへの依存を見つける機会になることです。preview APIは検証段階では便利ですが、本番の自動化に長期間残ると、ドキュメント更新やSDK生成のタイミングで保守負荷が高くなります。

2つ目は、APIバージョンをリソース単位ではなく操作単位で見る必要があることです。Microsoft.NetworkCloud には安定版で管理できる操作もあれば、preview版のドキュメントを参照すべき操作もあります。Microsoft LearnのREST APIページでは、各操作にAPI VersionとURL例が示されています。(Microsoft Learn)

3つ目は、SDKとCIへの影響です。REST APIを直接呼んでいなくても、生成SDK、OpenAPI snapshot、example JSON、型定義、社内共通ライブラリを通じて影響することがあります。

まずは、2024-10-01-preview の利用箇所を検索してください。次に、見つかった箇所をリソースと操作ごとに分類し、安定版 2025-09-01 で足りるもの、preview版が必要なもの、SDKやCIの修正が必要なものに分けます。最後に、読み取り、非破壊更新、状態変更操作の順で検証し、本番反映後は旧APIバージョンの再混入をCIで防ぎましょう。

Azure
ARM Azure REST API API version Microsoft.NetworkCloud Operator Nexus

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次