Azure REST APIでAzure Localの展開や構成管理を自動化している場合、今回まず確認すべき点は api-version=2026-04-30 のGA APIとして、SAN構成を表す項目が追加されていること です。特に、Azure LocalインスタンスのDeployment SettingsをREST API、ARMテンプレート、Bicep、Terraformラッパー、SDK、社内ツールで扱っているチームは、storageType、san、sanNetworks まわりのスキーマ差分を確認してください。
一方、既存のS2Dのみの環境で、古いAPIバージョンを固定しているだけなら、すぐに設定変更が必要とは限りません。ただし、将来のSDK更新やAPIバージョン切り替えでレスポンス項目が増える可能性があるため、デシリアライズ処理、入力バリデーション、構成ファイル生成ロジックは早めに点検しておくのが安全です。
Azure REST APIのAzure Local向けSAN対応GA APIで何が変わったのか
2026年5月5日に更新されたAzure REST API仕様のPR「Azure Local : New GA API for SAN support」では、Azure Local、旧Azure Stack HCI向けのREST API仕様に、SAN構成を扱うためのGA APIバージョンが追加されています。PR上では resource-manager、RPaaS、TypeSpec、new-api-version、PublishToCustomers などのラベルが付いており、対象は管理プレーン、つまりAzure Resource Manager経由のAPIです。なお、確認時点でPRはOpenの状態として表示されているため、本番適用前にはマージ状況と公開済みドキュメントを再確認してください。(GitHub)
今回の仕様では、TypeSpec側に 2026-04-30 というAPIバージョンが追加され、readmeのAutoRest設定でも package-2026-04-30 が stable/2026-04-30/hci.json を参照する構成になっています。つまり、単なるプレビュー拡張ではなく、安定版APIとして扱う前提の更新です。(GitHub)
重要なのは、Azure Localという名称に変わっても、REST API上のリソースプロバイダー名は Microsoft.AzureStackHCI のままという点です。Microsoftの名称変更ドキュメントでも、Azure Stack HCI API/名前空間、リソースプロバイダー、PowerShellコマンドレット、Azure CLIコマンドは変更されないと説明されています。(Microsoft Learn)
確認すべき主な変更点
今回のAzure REST API documentation updateで実務上見るべき変更は、SANストレージそのものだけではありません。Deployment Settings、ネットワーク、エッジデバイスのディスク情報、SDK生成の影響まで含めて確認する必要があります。
| 確認項目 | 変更内容 | 実務上の影響 |
|---|---|---|
| APIバージョン | 2026-04-30 がGA APIとして追加 | 既存ツールでAPIバージョンを固定している場合、SAN関連フィールドを扱えない可能性がある |
| ストレージ種別 | storageType に S2D、SAN、SANS2D が定義 | 構成ファイル生成時にストレージ方式ごとの分岐が必要 |
| SANストレージ設定 | san.infraVolLunId、san.infraPerfLunId が追加 | SAN側のLUN設計・命名・ホスト割り当てとの整合確認が必要 |
| SANネットワーク設定 | hostNetwork.sanNetworks.clusterNetworkConfig が追加 | VLAN、CIDR、Jumbo Frame、QoSなどのネットワーク設計をAPI入力に反映する必要がある |
| S2D設定 | s2d.volumeType、s2d.overprovisioningRatio が明示 | S2D利用環境でも新APIへ移る場合は設定値の明示・検証が必要 |
| ディスク情報 | Edge Deviceのディスク種別にS2DまたはSANの例が追加 | インベントリ取得ツールや画面表示でディスク種別の扱いを見直す必要がある |
Storage 定義では、storageType の許可値として S2D、SAN、SANS2D が示され、SAN構成には infraVolLunId と infraPerfLunId が含まれます。また、SANネットワーク用に SanNetworks、SanClusterNetworkConfig、SanAdapterProperties、SanAdapterIPConfig が定義されています。(GitHub)
誰が対応すべきか
この更新は、Azure LocalをAzureポータルだけで操作している利用者よりも、APIやIaCで構成を管理しているチームへの影響が大きい更新です。
| 対象者 | 対応の優先度 | 具体的に確認すること |
|---|---|---|
| Azure Localの新規展開を自動化しているチーム | 高 | api-version=2026-04-30 への切り替え可否、Deployment Settingsの入力項目 |
| SANを使ったAzure Local構成を検討しているインフラ担当者 | 高 | LUN ID、SANネットワーク、OEM/ベンダー検証済み構成との整合 |
| ARM/Bicep/JSONテンプレートを保守している担当者 | 中〜高 | storageType と s2d / san の条件分岐 |
| SDKを使ってAzure Localを操作している開発者 | 中 | Python、JavaScript、GoなどのSDK更新タイミングとモデル差分 |
| 既存のS2D環境のみを運用している担当者 | 中 | すぐに変更するより、将来のAPIバージョン更新に備えた互換性確認 |
| 監視・棚卸しツールを作っている担当者 | 中 | 追加レスポンス項目を無視できる実装になっているか |
PRではSwagger、TypeSpec、Python、JavaScript、Go向けのAPIViewが作成されたことも示されています。これは、REST API仕様の変更が将来的に各言語SDKのモデルや型定義へ反映される可能性があることを意味します。ただし、PR上のAPIView作成と、実際のSDKパッケージ公開は同時とは限らないため、SDK利用者はパッケージのリリースノートも別途確認する必要があります。(GitHub)
SAN対応で追加されたストレージ設定の読み方
今回の中心は、Deployment Settingsの storage セクションです。新しいスキーマでは、まず storageType でストレージ方式を選び、その方式に応じて s2d または san の詳細を指定します。
storageType | 想定される使い方 | 必要になる主な設定 |
|---|---|---|
S2D | 従来のStorage Spaces Direct中心の構成 | s2d.volumeType、s2d.overprovisioningRatio |
SAN | 外部SANストレージを使う構成 | san.infraVolLunId、san.infraPerfLunId、sanNetworks |
SANS2D | SANとS2Dを組み合わせる構成 | s2d と san の両方の設定を整合させる必要がある |
API仕様上は SANS2D も定義されていますが、実際にどの構成が利用できるかは、Azure Localのバージョン、ハードウェア、OEMまたはストレージベンダーの検証、リージョンやサービス側のロールアウト状況に左右される可能性があります。列挙値があるからといって、すべての組み合わせを任意の環境で使えると判断しないでください。(GitHub)
SAN構成のJSON例
PR内のサンプルでは、api-version に 2026-04-30 を指定し、Deployment Settingsの storage.storageType を SAN にした例が追加されています。実際の環境では、LUN ID、NIC名、VLAN、CIDR、QoS値を自社の設計に合わせて置き換える必要があります。(GitHub)
{
"storage": {
"configurationMode": "Express",
"storageType": "SAN",
"san": {
"infraVolLunId": "PURE1234567890ABCDEF",
"infraPerfLunId": "PURE0987654321MNOPQR"
}
},
"hostNetwork": {
"sanNetworks": {
"clusterNetworkConfig": {
"adapterProperties": {
"bandwidthPercentageSmb": 50,
"jumboPacket": 9014,
"priorityValue8021ActionCluster": 7,
"priorityValue8021ActionSmb": 3
},
"adapterIPConfig": [
{
"name": "clusterNetwork-A",
"networkAdapterName": "ethernet 3",
"vlanId": 711,
"addressPrefix": "10.10.30.0/24"
}
]
}
}
}
}ここで注意したいのは、サンプル内で storageType が SAN でも、既存の storageNetworks と新しい sanNetworks が同じ hostNetwork 配下に出ていることです。既存のストレージネットワーク定義を単純に削除するのではなく、対象のAzure Local展開方式、OEMガイド、ネットワーク設計に基づいて、どの項目が必須かを確認してください。(GitHub)
移行・設定確認で見るべきポイント
APIバージョンを固定している箇所を洗い出す
Azure REST APIを使う社内ツールでは、URLやSDKの内部でAPIバージョンを固定していることがよくあります。まず、次のような箇所を検索してください。
2024-04-01
2025-10-01
2026-02-01
2026-04-01-preview
Microsoft.AzureStackHCI
deploymentSettings
AzureStackHCI2026-04-30 に切り替える前に、既存のPUTリクエストが新しいスキーマでも通るか、必須項目やレスポンス構造に差分がないかを検証します。PUT系APIでは、部分的な更新のつもりで送ったペイロードが既存設定を上書きするリスクがあるため、現在の設定をGETしてから差分を作る運用が安全です。
storageType と詳細設定を一致させる
最も起きやすいミスは、storageType と詳細設定の不一致です。
| 誤りやすい設定 | 起きる問題 | 確認方法 |
|---|---|---|
storageType: "SAN" なのに san がない | SAN用LUN情報が渡らない | infraVolLunId と infraPerfLunId の有無を確認 |
storageType: "S2D" なのに san だけを指定 | 意図しない構成、またはバリデーション失敗の可能性 | s2d と san の条件分岐を実装 |
SANS2D で片方の設定しかない | 複合構成として不完全になる可能性 | 両方の設定が必要か、サービス仕様とOEMガイドを確認 |
| 既存サンプル値をそのまま流用 | NIC名、VLAN、CIDR、LUN IDが実環境と不一致 | 現地ネットワーク・SAN設計書と突合 |
SanAdapterIPConfig では vlanId が0〜4095の値として説明され、0または省略はuntaggedを意味する旨が示されています。VLANを省略してよいかどうかはスイッチ側の設計に依存するため、ネットワーク担当者と確認してから投入してください。(GitHub)
LUN IDはストレージチームと突合する
SAN対応で新しく重要になるのが、infraVolLunId と infraPerfLunId です。これらは単なる任意文字列ではなく、インフラボリュームやパフォーマンス用途のLUNを識別する値として使われます。サンプルではPure Storage風の文字列が使われていますが、実際の値は利用するストレージアレイ、ホストグループ、ゾーニング、マルチパス構成に合わせて決める必要があります。(GitHub)
SAN構成をAPI化すると、設定ミスがコードレビューだけでは見つかりにくくなります。最低でも次の4点は変更前チェックリストに入れてください。
| チェック項目 | 見るべき内容 |
|---|---|
| LUNの用途 | インフラ用とパフォーマンス用のLUNを取り違えていないか |
| ホスト割り当て | Azure Localの対象ノードに正しく提示されているか |
| 冗長性 | コントローラー、パス、スイッチ障害時の設計が満たされているか |
| 命名規則 | APIに渡すIDとストレージ管理画面上のIDが追跡できるか |
SDKや型定義の更新で壊れやすい箇所を確認する
新しいAPI仕様がSDKに反映されると、StorageType、StorageSanConfig、SanNetworks のようなモデルが追加される可能性があります。静的型付けの言語では、新しい列挙値をswitch文で網羅しているコードが壊れやすいポイントです。
たとえば、既存コードが次のような実装になっている場合は注意が必要です。
S2D以外のstorageTypeはエラーにする
未知のdisk.typeを例外扱いする
レスポンスに未知のプロパティがあるとJSONパースに失敗する今回の仕様では、Edge Deviceのディスク情報にも type があり、例としてS2DまたはSANが示されています。また、isSupported という読み取り専用のサポート判定フィールドもあります。棚卸しツールや管理画面でディスク種別を表示している場合は、SANを未知値として落とさないようにしてください。(GitHub)
既存環境で急いで変更しなくてよいケース
今回の更新は重要ですが、すべてのAzure Local利用者がすぐに構成変更すべきという意味ではありません。次の条件に当てはまる場合、まずは影響調査と検証環境での確認から始めれば十分です。
| 状況 | 推奨対応 |
|---|---|
| 既存のS2D構成を安定運用している | 本番APIバージョンを急に変えず、検証環境で 2026-04-30 を確認 |
| Azureポータル中心で運用している | ポータル側の表示やガイド更新を待ちつつ、API利用箇所がないか棚卸し |
| SDKだけを利用していてREST直叩きはない | SDKのリリース後にモデル差分とサンプルを確認 |
| SANを使う予定がない | storageType の新しい値に対応できるよう、読み取り処理だけ先に強化 |
| preview APIを使ってSAN検証中 | GA APIのスキーマへ移行するため、ペイロード差分を比較 |
特にpreview APIを使って先行検証していたチームは、2026-04-01-preview から 2026-04-30 へ単純に文字列だけ差し替えるのではなく、サンプル、必須項目、レスポンスの差分を確認してください。PRでは一部リソースに @removed(Versions.v2026_04_30) が付与され、previewで存在した要素がGA APIでは対象外になるケースも示されています。(GitHub)
実務で使う確認手順
既存のDeployment Settingsを取得する
まず、現在の設定を取得し、既存の storage、hostNetwork、storageNetworks を保存します。以下はURL構成の例です。
az rest \
--method get \
--url "https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.AzureStackHCI/clusters/<clusterName>/deploymentSettings/default?api-version=2026-04-30"取得できない場合は、PRのマージ状況、対象サブスクリプションでのAPI公開状況、利用中のAzure Localバージョン、権限を確認してください。仕様上の安定版APIと、実際のテナントで使えるタイミングには差が出ることがあります。
SAN用の入力値を設計書から作る
APIに値を入れる前に、次の値を人手で確定します。
| 入力値 | 例 | 確認相手 |
|---|---|---|
infraVolLunId | PURE1234567890ABCDEF | ストレージ管理者 |
infraPerfLunId | PURE0987654321MNOPQR | ストレージ管理者 |
networkAdapterName | ethernet 3 | サーバー・ネットワーク担当 |
vlanId | 711 | ネットワーク担当 |
addressPrefix | 10.10.30.0/24 | ネットワーク担当 |
jumboPacket | 9014 | ネットワーク担当・OEMガイド |
priorityValue8021ActionCluster | 7 | ネットワーク担当 |
priorityValue8021ActionSmb | 3 | ネットワーク担当 |
サンプル値は理解のための例です。本番では、NIC名の表記ゆれ、VLANのタグ有無、Jumbo FrameのMTU不一致、LUNの提示先ノード違いが典型的な失敗原因になります。
PUT前に差分レビューを行う
Deployment Settingsのような大きなJSONをPUTする場合、手動編集したJSONをそのまま投入するのは危険です。次のように差分を分けてレビューすると、事故を減らせます。
| レビュー観点 | 確認内容 |
|---|---|
| API差分 | api-version を変えただけで不要な項目が消えていないか |
| ストレージ差分 | storageType、s2d、san の組み合わせが正しいか |
| ネットワーク差分 | 既存の intents、storageNetworks、新しい sanNetworks の整合 |
| セキュリティ差分 | Key Vaultのsecret参照や資格情報項目を誤って変更していないか |
| 運用差分 | 監視、ログ収集、Remote Support関連の読み取り項目を壊していないか |
今回の仕様にはRemote Support関連のプロパティも含まれており、Clusterの remoteSupportProperties やRemote Supportの状態、セッション詳細、プロビジョニング状態などが定義されています。SAN対応が主目的でも、レスポンス全体を厳密に型固定しているツールでは、こうした読み取り専用フィールドの追加にも注意が必要です。(GitHub)
失敗しやすいポイントと対策
| 失敗しやすいポイント | 具体例 | 対策 |
|---|---|---|
| PRだけ見て本番利用可能と判断する | GitHub上では更新されているが、まだ自テナントでAPIが使えない | PRのマージ、Microsoft Learn、SDKリリース、実API応答を確認 |
| 旧APIバージョンのままSAN項目を送る | storageType や sanNetworks が無視またはエラーになる | api-version=2026-04-30 を明示して検証 |
SAN と S2D の設定を混在させる | storageType はSANなのにS2D前提の処理を残す | ストレージ方式ごとにJSON生成ロジックを分ける |
| サンプルのQoS値を流用する | 実ネットワークの設計と合わない | OEMガイド、スイッチ設定、ネットワーク設計書で確認 |
| LUN IDを表示名と取り違える | APIに渡したIDが実LUNと一致しない | ストレージ管理画面とAPI入力値の対応表を作る |
| 未知の列挙値でツールが落ちる | SANS2D を想定していないswitch文 | default分岐でログ出力し、処理を継続できるようにする |
| レスポンス項目追加でJSONパース失敗 | 厳密なスキーマ検証で新フィールドを拒否 | 追加プロパティを許容する設計に見直す |
今回の更新で次に取るべき行動
Azure REST APIのAzure Local向けSAN対応GA APIは、SAN構成をコードで扱うための重要な仕様更新です。まずは本番変更ではなく、次の順で確認してください。
Microsoft.AzureStackHCIを使っているREST API、SDK、IaC、社内ツールを洗い出す。api-versionを固定している箇所を確認し、2026-04-30の検証対象を決める。- SANを使う予定がある場合は、
storageType、san、sanNetworksの入力値を設計書から作る。 - 既存S2D環境では、レスポンス項目追加や列挙値追加でツールが壊れないか確認する。
- PRのマージ状況、Microsoft LearnのREST APIページ、各SDKのリリース状況を確認してから本番に反映する。
今回の変更は「SANを使う人だけの話」ではありません。Azure LocalをAPIで管理しているなら、将来のGA API移行に備えて、ストレージ方式の分岐、未知の列挙値への耐性、Deployment Settingsの差分管理を見直すよいタイミングです。
コメント