Azure から「2028年9月8日までに OS ディスクを Standard SSD / Premium SSD に変換してください」と通知された場合、慌てて全ディスクを移行する必要はありません。対象は“Standard HDD をOSディスクとして使っている”ケースのみです。具体的な洗い出しと安全な切り替え手順を解説します。
結論:今回の移行対象は「Standard HDD をOSディスクとして使っているVM」だけ
まず最初に結論です。今回のアラート(「2028年9月8日までに OS ディスクを Standard SSD または Premium SSD に変換」)で対応が必要なのは、Standard HDD(標準HDD)を“OSディスク”として利用しているマネージドディスクだけです。
反対に、以下は今回のアナウンスでは基本的に対象外です。
- データディスクとして Standard HDD を使っているケース
- OSディスクがすでに Standard SSD / Premium SSD のケース
- エフェメラル OS ディスク(Ephemeral OS) を利用しているケース
なぜこの通知が出るのか:Standard HDD の「OSディスク利用」が 2028年9月8日に廃止
Microsoft のガイダンスでは、2028年9月8日に「Standard HDD を OS ディスクとして使う機能」が廃止されます。廃止日以降、Standard HDD を OS ディスクとして利用している VM は、同等サイズの Standard SSD に自動変換される可能性があり、そのタイミングでサービス中断が発生し得るため、事前に Standard SSD もしくは Premium SSD に変換しておくことが推奨されています。
ポイントは「Standard HDD が完全に使えなくなる」という話ではなく、“OSディスクとしての利用”が対象だという点です。Standard HDD をデータディスク用途で使うこと自体は、このアラートが示す範囲では求められていません。
対象・対象外が一目で分かる判定表
| ディスクの役割 | ディスク種類(例) | Azure上のSKU例 | 今回の変換が必要? | 補足 |
|---|---|---|---|---|
| OSディスク | Standard HDD | Standard_LRS | 必要 | 廃止対象。事前に Standard SSD / Premium SSD へ |
| OSディスク | Standard SSD | StandardSSD_LRS / StandardSSD_ZRS | 不要 | すでにSSD。アラートの主旨から外れる |
| OSディスク | Premium SSD | Premium_LRS / Premium_ZRS | 不要 | すでにSSD。高性能だがコスト注意 |
| OSディスク | Ephemeral OS | (マネージドOSディスクなし) | 不要 | 今回の廃止対象外 |
| データディスク | Standard HDD | Standard_LRS | 不要 | 今回の通知では対象外(ただし性能/運用要件で判断) |
どのディスクを変換すべきか:必要なのは「Standard_LRS かつ OSディスク」の抽出
実務では「OSディスクかどうか」と「Standard HDDかどうか」を機械的に判定できる形にしておくと迷いません。今回の条件はシンプルです。
| 判定条件 | 見るプロパティ例 | 意味 |
|---|---|---|
| Standard HDD である | Sku.Name == "Standard_LRS" | マネージドディスクが Standard HDD(LRS) |
| OSディスクである | OsType != null | Windows/Linux の OS ディスクとして使われている |
| どのVMに紐づくか | ManagedBy | 利用しているVMのリソースID(棚卸しに便利) |
対象OSディスクの洗い出し方法
ポータルで横断的に一覧化したい:Disk Storage Center
サブスクリプションが複数ある、または横断的に一覧を作りたい場合は、ポータルのDisk Storage Centerを使う方法が分かりやすいです。フィルターを以下のように設定することで、対象の「Standard HDD OSディスク」をまとめて抽出できます。
- Storage type:Standard HDD LRS
- OS type:Linux / Windows
一覧の Owner 列から、そのディスクを利用している VM 名を把握できます。
Azure PowerShell(Cloud Shell可)で抽出する
最短で確認したい場合は、PowerShell のフィルターが手堅いです。Cloud Shell(PowerShell)でも動かせます。
Get-AzDisk |
Where-Object {
$_.Sku.Name -eq "Standard_LRS" -and
$_.OsType -ne $null
} |
Select-Object ResourceGroupName, Name, Location, OsType, @{N="Sku";E={$_.Sku.Name}}, ManagedBy |
Format-Table -AutoSize
ここに出てきたディスクが、今回の通知で変換が必要な候補です。ManagedBy が VM の参照先なので、「どのシステムの停止が必要か」まで落とし込めます。
Azure CLI で抽出する(スクリプト運用に向く)
CLI 派なら、次のクエリがそのまま使えます。
az disk list --query "[?sku.name=='Standard_LRS' && osType!=null]" --output table
Azure Resource Graph で“運用用の台帳”を作る
運用で「いつ、どのVMを、どのSKUに変えたか」を管理したいなら、Azure Resource Graph(KQL)で一覧化してExcel化するのが便利です。例として、ディスクと紐づくVM情報を拾う形は次のようになります。
resources
| where type =~ 'microsoft.compute/disks'
| where tostring(sku.name) == 'Standard_LRS'
| where isnotempty(properties.osType)
| project subscriptionId, resourceGroup, diskName=name, location,
osType=tostring(properties.osType),
managedBy=tostring(properties.managedBy),
diskId=id
上記の結果をベースに「業務影響(停止可能時間帯)」「移行先(Standard SSD/Premium SSD)」「担当」「実施日」「結果」を列として足すと、移行作業が一気に回しやすくなります。
変換前に必ず確認したい実務チェックリスト
ディスク種類の変更そのものはシンプルですが、業務で事故を起こしがちなポイントは「変換操作」ではなく止め方・戻し方・性能見積りです。以下を事前に押さえると移行が安定します。
| 確認項目 | なぜ必要? | 実務でのやり方 |
|---|---|---|
| 停止(割り当て解除)が可能な時間帯 | 変換にはVMの再起動/停止が絡む | メンテナンス枠を確保し、関係者へ周知 |
| スナップショット/バックアップ | “切り戻し”の保険があると安心 | OSディスクのスナップショット、またはAzure Backupの整備 |
| Premium SSD を使えるVMサイズか | Premiumは対応VMサイズが必要 | 必要なら事前にVMサイズ変更も計画に含める |
| 変更回数制限 | 同一ディスクは1日に何度も切替できない | 検証→本番の順で“やり直し”が出ないように手順を固める |
| 性能要件(IOPS/スループット) | Standard SSDで十分か、Premiumが必要かを判断 | Azure Monitor でディスクI/Oを数日〜数週間観測し、ピークを確認 |
| コスト影響 | Standard HDDよりSSDの方が高くなる傾向 | 移行後の月額増分を概算し、予算と合意 |
特に重要なのが「変換にはメンテナンスを組む」ことです。Microsoft Learn でも、ディスク種別の変換は VM の再起動を伴うため、メンテナンス期間にスケジュールすることが前提として説明されています。
Azureポータルでの変換手順(最も簡単で安全)
台数が少ない、または一台ずつ確実に進めたいならポータル操作が分かりやすいです。大まかな流れは次のとおりです。
- 対象 VM を 停止(必要に応じて割り当て解除)する
- VM の画面で [ディスク] を開く
- OSディスクをクリックしてディスクのリソース画面へ移動
- [サイズ + パフォーマンス] を開く
- アカウントの種類(ストレージの種類)を「Standard SSD」または「Premium SSD」に変更
- [保存]
- VM を起動し、OS起動・アプリ動作・ログなどを確認
なお、ディスク種別の変換自体は素早く完了しますが、OSディスクの変更はVM停止を伴うケースが多いので、「いつ止めるか」を先に決めてから実施するのが実務的です。
PowerShell / CLI での変換手順(台数が多い場合に便利)
対象VMが多い場合は、手作業よりもスクリプトで“手順のブレ”をなくす方が安全です。ただし、いきなり全台に適用せず、まずは影響の小さい検証環境から実施してください。
PowerShell 例:Standard HDD(OSディスク)を Standard SSD に変更
# 例:OSディスク(マネージドディスク)のSKUを StandardSSD_LRS に変更する
# 前提:Az モジュールでログイン済み
$rgName = "YOUR-RG"
$diskName = "YOUR-OSDISK-NAME"
# ディスク取得
$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $diskName
# どのVMが使っているか(OSディスクなら通常 ManagedBy が入る)
$vmResource = Get-AzResource -ResourceId $disk.ManagedBy
# VM停止(割り当て解除)
Stop-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name -Force
# SKU変更(Standard SSD)
$disk.Sku = [Microsoft.Azure.Management.Compute.Models.DiskSku]::new("StandardSSD_LRS")
$disk | Update-AzDisk
# VM起動
Start-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name
Premium SSD に上げる場合、VMサイズが Premium に対応していないと選べない(または期待通りの性能が出ない)ことがあります。必要に応じて VM サイズ変更も同じメンテナンス枠に含めます。
CLI 例:ディスクSKUを更新して VM を再開
# 例:OSディスクを Premium SSD (Premium_LRS) に変更する流れ
rgName="YOUR-RG"
diskName="YOUR-OSDISK-NAME"
sku="Premium_LRS"
# ディスクから親VMを取得
vmId=$(az disk show --name "$diskName" --resource-group "$rgName" --query managedBy --output tsv)
# VM割り当て解除
az vm deallocate --ids "$vmId"
# ディスクSKU更新
az disk update --sku "$sku" --name "$diskName" --resource-group "$rgName"
# VM起動
az vm start --ids "$vmId"
Standard SSD と Premium SSD の選び方
「通知が来たから Premium SSD にすべき?」と迷うことが多いのですが、結論としてはまず Standard SSD を基準にし、必要なVMだけ Premium SSD にするのが現実的です。Microsoft のガイダンスでも、Standard HDD の価格・性能に近い移行先として Standard SSD を挙げつつ、より高い性能が必要なら Premium SSD を選ぶ流れが示されています。
| 項目 | Standard SSD | Premium SSD | こういう時に選ぶ |
|---|---|---|---|
| 狙い | コストと安定性能のバランス | 低レイテンシ・高IOPS | 用途に応じて使い分け |
| 向くワークロード例 | Web/APサーバ、軽量な業務、検証環境 | DB、I/Oが多い本番、ミッションクリティカル | ディスクI/Oのピークで判断 |
| 注意点 | サイズ(ティア)で性能が変わる | Premium対応VMサイズが必要な場合がある | 性能計測と予算の両方を見る |
なお、ディスク種類の比較情報では、Standard SSD は「Web サーバー、あまり使用されていないエンタープライズアプリ、開発/テスト」、Premium SSD は「運用環境のパフォーマンスが重要となるワークロード」といった位置づけで整理されています。OSディスクとして Standard HDD を使えるのは、廃止日までの猶予期間があるものの、その後は移行が前提になります。
移行後に確認しておきたいこと(“変えたら終わり”にしない)
- OS起動(ブート、ログイン、サービス自動起動が正常か)
- アプリの起動と主要機能(特にI/Oが多い処理)
- 監視メトリクス(Disk Read/Write、Queue Depth、Latency、VMの再起動回数)
- バックアップの状態(Azure Backupの最新復旧ポイント、ジョブ失敗がないか)
- コスト(移行後のディスク課金・VMサイズ変更があればその影響)
“速度が上がったはずなのに体感が変わらない”場合、ボトルネックがCPU/RAM/ネットワーク/アプリ設計にあることも多いので、移行後はディスクだけでなくシステム全体のメトリクスをセットで確認すると判断がブレません。
よくある質問
データディスクも Standard SSD / Premium SSD に変換しないといけませんか?
今回の通知の範囲では不要です。廃止対象は「Standard HDD を OS ディスクとして使う機能」であり、他のディスク種別やエフェメラルOSは対象外とされています。
OSディスクを変換すると、インストールしたアプリやファイルは消えませんか?
一般的な「ディスク種別(SKU)の変更」は、ディスク内容を初期化する操作ではありません。ただし、万一に備えてスナップショット/バックアップを取った上でメンテナンス枠で作業するのが安全です(“戻せる前提”にしておくと、心理的にも作業が安定します)。
変換作業のダウンタイムはどれくらいですか?
環境差はありますが、主に「VM停止(割り当て解除)→ SKU変更 → VM起動」の停止時間がダウンタイムです。ディスク変換自体は素早く行われる一方、変換はVM再起動を伴うためメンテナンス期間での実施が推奨されています。
同じディスクで何度も切り替えてテストできますか?
注意点として、ディスク種類の変更には回数制限があります。やり直しが多いと計画が崩れるため、検証環境で手順と影響を固めてから本番に適用するのがおすすめです。
実務的な進め方:失敗しない移行ロードマップ
最後に、現場で回しやすい進め方を“型”としてまとめます。
- 棚卸し:Standard HDD のOSディスク(Standard_LRS & OsTypeあり)を一覧化
- 紐づけ:ManagedBy で VM / システム名 / 責任者を整理
- 分類:本番/検証、業務影響、停止可能時間帯、性能要件でグルーピング
- 移行先決定:基本は Standard SSD、要件が高いもののみ Premium SSD
- 手順固定:スナップショット→停止→変換→起動→確認 をチェックリスト化
- 段階実施:影響の小さい環境から順に実施し、同じ手順で本番へ展開
- 完了判定:対象一覧がゼロになったことをもって完了(証跡も残す)
廃止日まで猶予はありますが、台数が多いほど「いつかやる」は後回しになりがちです。通知を受け取ったタイミングで棚卸しと分類まで終わらせ、あとはメンテ枠ごとに淡々と消化できる状態を作っておくと、直前で慌てません。
まとめ
- 今回の「2028年9月8日までに変換」は、Standard HDD をOSディスクとして使っている場合のみが主対象
- データディスクは本通知の範囲では対象外(ただし性能・運用要件で別途検討余地はあり)
- まずは Standard_LRS かつ OsTypeあり で対象OSディスクを抽出し、停止計画と移行先(Standard/Premium)を決めて順次実施

コメント