Azure VMでOSディスク256GB＋データディスク1TBの構成なのに、Windows 11の［ディスクの管理］で“さらに約440GBのディスク”が見える。しかもAzureポータルのディスク一覧には存在しない——この現象は多くの場合、VMサイズに付属するローカル一時ストレージ（Temporary Storage）が原因です。見分け方と安全な使い方を整理します。
現象の整理：Azureポータルに無いのに「ディスクの管理」に440GBが出る
まず前提として、Azure VMのストレージは大きく分けて次の2系統があります。
- Azure側で管理される永続ストレージ（マネージド ディスク）：OSディスク、追加したデータディスクなど
- ホスト側に“おまけ”として用意される一時領域（Temporary / Resource Disk / Local SSD）：VMサイズ（SKU）により容量が決まる
質問のケース（OS 256GB＋データ 1TB）で、Windowsの［ディスクの管理］に“追加の約440GB”が見えるのにAzureポータルのディスク一覧（マネージド ディスク）に存在しない場合、ほとんどは後者のローカル一時ストレージです。Azureポータルに出ないこと自体が、むしろ典型的な挙動です。
| 見えているもの | 容量の例 | Azureポータルの「ディスク一覧」 | Windowsの「ディスクの管理」 | 永続性 |
|---|---|---|---|---|
| OSディスク | 256GB | 表示される | 表示される | 永続 |
| 追加データディスク | 1TB | 表示される | 表示される | 永続 |
| ローカル一時ストレージ（Temporary / Resource Disk） | 約440GB（SKU次第） | 表示されない | 表示される | 非永続（消える前提） |
結論：その440GBは「ローカル一時ストレージ（Temporary Storage）」の可能性が高い
Azureの多くのVMサイズには、ホスト（物理サーバー）側のローカルディスクを「テンポラリ領域」として使える仕組みが用意されています。呼び方がいくつかあり、資料や画面によって表記が揺れます。
- Temporary Storage / Temp storage
- Resource Disk（リソースディスク）
- Local SSD / Local NVMe / Local storage
これがWindowsでは“追加ディスク”のように見えます。VMサイズによってはNVMeとして認識され、数百GB単位（例：440GB前後）になることがあります。
ポイント：この領域は「消える（初期化される）」ことが仕様
ローカル一時ストレージは、あくまでホスト側の作業領域です。次のようなタイミングで内容が失われる前提で設計されています。
- AzureポータルやCLIでVMを停止（割り当て解除 / Deallocate）したとき
- VMのサイズ変更（リサイズ）、再デプロイ、ホスト移動が起きたとき
- 基盤側のメンテナンスや障害対応でホストが変わったとき（可能性）
「見えている＝使っていい」ではありますが、「消える前提でしか使えない」のが最大の注意点です。
なぜAzureポータルのディスク一覧に出てこないのか
Azureポータルの［ディスク］一覧に並ぶのは、基本的にマネージド ディスク（Azureがストレージとして管理する永続ディスク）です。これらはスナップショット、バックアップ、暗号化、RBACなど、Azure側の管理対象になります。
一方でローカル一時ストレージは、VMホストに“直結”した領域であり、Azureのディスク リソースとして作成されるわけではありません。そのため、ポータルのディスク一覧に出ない（またはVMのサイズ情報の中にだけ出る）挙動になります。
| 比較項目 | マネージド ディスク（OS/データ） | ローカル一時ストレージ（Temporary / Resource Disk） |
|---|---|---|
| Azureポータルの「ディスク」リソース | 作成される（一覧に出る） | 作成されない（一覧に出ない） |
| 耐久性 | 高い（永続） | 低い（消える前提） |
| スナップショット / Azure Backup | 可能 | 不可（基本対象外） |
| 課金の考え方 | ディスク容量・種類で別途課金 | 多くはVM料金に含まれる（別ディスク課金ではない） |
| 性能傾向 | 種類に依存（Standard/Premium/Ultraなど） | ローカルなので高速なことが多い |
| 用途 | 業務データ、アプリ、DB本体 | キャッシュ、テンポラリ、ページファイル、ビルド成果物など |
確認方法：本当にTemporary Storageなのかを10分で見分ける
1) Windows側で「バス種別」と「ディスク名」を確認する
Windows 11 / Windows Server どちらでも、PowerShellでディスク一覧を出すと判断材料が増えます。
Get-Disk | Sort-Object Number | Select-Object Number,FriendlyName,BusType,PartitionStyle,Sizeチェックするポイントは次の通りです。
- BusType：NVMe / RAID / SAS など。ローカル一時領域はNVMeとして見えることがあります（VM/世代により表示は異なります）。
- FriendlyName：一時ディスクはそれっぽい名前、またはOS/データディスクと違う名前で出ることがあります。
- PartitionStyle：未初期化の場合はRAW/Unknownのように見えます（ただし初期化して使っている環境もあります）。
2) ボリューム（ドライブ）として割り当たっているかを確認する
ドライブレターが付いている場合は、ラベル名から判断しやすくなります。
Get-Volume | Sort-Object DriveLetter | Select-Object DriveLetter,FileSystemLabel,FileSystem,Size,SizeRemainingAzureのWindowsイメージでは、一時領域がD:として割り当てられ、ラベルが「Temporary Storage」などになっていることがよくあります。ただし、データディスクにD:を割り当ててしまうと見分けが難しくなるため、運用上は一時領域にD:を空けるのが無難です。
3) ［ディスクの管理］で“ディスクのプロパティ”を開く
GUIでも確認できます。
- ［コンピューターの管理］→［ディスクの管理］を開く
- 該当ディスク（約440GB）を右クリック→［プロパティ］
- ［詳細］タブで「デバイスの説明」「場所」「ハードウェアID」などを見る
マネージドディスクとローカル一時ディスクで、表示される情報が異なることがあります。特にNVMeや“Local”を想起させる表記がある場合はTemporary Storageの可能性が高いです。
4) AzureポータルでVMサイズ（SKU）を確認し、Temp storage容量と突き合わせる
最も確実なのは、Azure側で「そのVMサイズに付属するローカル/一時ストレージ容量」を確認することです。
- Azureポータル → 対象VM → ［サイズ］
- サイズ一覧や詳細に表示される「Temp storage」「Local storage」などの値を確認
ここに表示される容量が、Windowsの［ディスクの管理］で見えている約440GBと一致（または単位の違いで近い値）なら、それが正体です。表示単位がGiB/GBで異なるため、数%のズレが出ることもあります。
5) CLIでVMサイズ名だけ先に抜き出す（権限がある場合）
GUIより素早く確認したい場合は、Azure CLIでVMのサイズ名（SKU）を取得できます。
az vm show -g <リソースグループ> -n <VM名> --query "hardwareProfile.vmSize" -o tsv取得したサイズ名をもとに、ポータルのサイズ画面やSKU情報でTemp storage容量を確認します。
やってはいけない使い方：440GBが“増えた”からといって永続保存に使わない
「440GBもあるならデータ置き場にできるのでは？」と考えがちですが、ローカル一時ストレージは消える前提です。特に次のような用途は避けるべきです。
| 保存してよい？ | 具体例 | 理由 |
|---|---|---|
| ✕（避ける） | 業務データ、ユーザーのアップロードファイル、DBの本体（mdf/ldf）、重要なログ | 割り当て解除やホスト移動で消えると復旧できない |
| △（設計次第） | 再生成可能なログ、監視エージェントの一時バッファ | 失っても再送・再生成できるなら可。ただし運用設計が必要 |
| ○（向いている） | キャッシュ、テンポラリファイル、ビルド/変換の作業領域、DBのtempdb、ページファイル | 消えても問題が少なく、ローカルなので高速になりやすい |
実務で役立つ運用のコツ：Temporary Storageを“安全に使う”ための考え方
ドライブレターとラベルを固定し、用途を明確にする
運用が長くなるほど「どれが一時ディスクか」が曖昧になりがちです。次のような運用ルールを決めると事故が減ります。
- 一時領域はTemp専用のドライブレターにする（例：T: など）
- ボリュームラベルをTEMPやSCRATCHなどにして識別しやすくする
- アプリの設定で「キャッシュ保存先」「作業ディレクトリ」を明示的に指定する
ただし、WindowsイメージによってはD:が一時領域として前提になっているケースもあります。既存のVMでページファイル等がD:を参照している場合、ドライブレター変更は慎重に行いましょう。
起動時に“存在確認→作業フォルダ作成”を自動化する
一時領域は再デプロイ等で初期状態に戻る可能性があります。そこで、VM起動時に次を行うスクリプトを用意すると堅牢になります。
- 一時ドライブが存在するか確認
- 必要な作業フォルダ（例：T:\work、T:\cache）を作成
- キャッシュが無いことを前提にアプリが起動できるようにする
「消えても自動で復旧する」構成にしておくと、Temporary Storageの利点（高速・無料枠的）を活かしやすくなります。
停止操作の違いを理解する（特に“割り当て解除”）
日常運用で意外に多い事故が、「停止したら一時領域が消えた」というものです。ポイントはAzure側の割り当て解除（Deallocate）です。
- OS再起動：一時領域は残ることが多い
- Azureポータルで停止（割り当て解除）：一時領域は消える前提
コスト最適化で夜間停止を自動化している環境ほど、Temporary Storageに置いたものが消える事故が起きやすいので注意してください。
「追加ディスクが見える」別パターンもある？切り分けの観点
ほとんどはTemporary Storageですが、念のため次もチェックしておくと安心です。
- 本当に“データディスクを追加”していないか：ポータルのVM→［ディスク］でデータディスクの行数を確認
- スナップショット/イメージから復元した構成：過去のディスク構成が残っていないか
- アプリが作った仮想ディスク：ストレージソフトや暗号化ツールが“仮想ドライブ”を作ることがあります（ただし容量440GBの“物理ディスク”として見えるケースは稀）
ただし「Azureポータルのディスク一覧に無い」「VMサイズを確認するとTemp storageが同程度ある」「Windows側でNVMe/Temporaryっぽい」——この3点が揃えばTemporary Storageとみてまず間違いありません。
永続ディスクが必要なら、正しく“追加”するのが最短ルート
もし目的が「440GBくらいの永続領域が欲しい」なのであれば、Temporary Storageを転用するよりも、Azure側でマネージド ディスクを追加するのが安全です。
- Azureポータル → VM → ［ディスク］ → ［データ ディスクの追加］
- 必要なサイズ（例：512GiB相当など）と種類（Standard SSD / Premium SSD など）を選択
- Windowsの［ディスクの管理］で初期化し、ドライブレターを付ける
これならポータルにも“ディスク”として残り、バックアップやスナップショットの対象にもできます。
Temporary Storageを“実際に使う”場合の設定例（Windows）
ローカル一時ストレージは「何もしなくても見える」こともあれば、「未初期化で未割り当て」として見えることもあります。消える前提で使うなら、次の流れが分かりやすいです。
未初期化の場合：オンライン化→初期化→ボリューム作成
- ［ディスクの管理］で対象のディスクを右クリックし、オフラインなら［オンライン］にする
- 「初期化されていません」と出る場合は、用途に合わせてGPT（推奨）で初期化する
- 未割り当て領域を右クリック→［新しいシンプル ボリューム］でフォーマット（NTFSなど）
- ラベルを「TEMP」「SCRATCH」などにし、“一時用”と一目で分かるようにする
すでにD:などで使われている場合：勝手に作り直さない
Windows on Azureのイメージでは、一時領域が最初からD:で構成され、ページファイル（pagefile.sys）が置かれていることがあります。この状態で“ディスクを初期化し直す”と、OSの設定と食い違いが起きてトラブルになることがあります。
- まずはドライブのラベルとpagefileの配置を確認する
- 用途が無ければ、無理に触らずそのままにする（表示が気になるだけなら放置が安全）
- キャッシュ用途に使うなら、既存ボリューム配下にフォルダを切って使う（例：D:\cache）
ページファイルを一時領域へ置く運用は“あり”だが、設計前提を揃える
Temporary Storageはローカルなので、ページファイルや一時ファイル置き場として性能面のメリットがあります。一方で、割り当て解除で消える前提なので「起動時に必ず作り直されても問題ない」設計にしておくのが重要です。たとえば、起動スクリプトでフォルダを再作成し、アプリのキャッシュ破損を前提にしておく、といった考え方です。
よくある質問（Q&A）
| 質問 | 回答 |
|---|---|
| Azureポータルに無い440GBは、誰かのディスクが残っている？ | 多くの場合はVMサイズに付属するTemporary Storageです。Azure側のディスク リソースではないため、ポータルのディスク一覧に出ないだけ、というケースが典型です。 |
| この440GBを消したい（表示させたくない） | “ディスクそのもの”をAzure側で削除する概念は基本的にありません。OS側でオフラインにすると表示上は抑えられますが、OS/エージェントが利用している場合もあるため、必要性が無いなら放置が安全です。 |
| 一時領域に置いたデータは、再起動でも消える？ | OS再起動だけなら残ることが多い一方、割り当て解除（Deallocate）や再デプロイ、ホスト移動で消える前提です。運用では「いつ消えても困らない」扱いにします。 |
| Temporary Storageを“安全に使う”コツは？ | キャッシュや作業領域など再生成できる用途に限定し、起動時にフォルダ再作成などの自動化を入れるのが実務で効きます。重要データはマネージド ディスクへ置きます。 |
今回のオチ：440GBのNVMe一時領域を持つSKUだった
質問のケースでは、最終的に「そのVMサイズ（SKU）が、約440GBのNVMeローカル一時ストレージを備えていた」ことが確認できた、という結論でした。Azure VMはサイズによって“付属する一時領域”が大きく変わります。
同じように「ディスクの管理に謎の追加ディスクが見える」「ポータルに無い」と感じたら、まずはVMサイズのTemp storage容量を確認し、Windowsで見えている容量と突き合わせてみてください。原因が分かるだけでなく、Temporary Storageをキャッシュや作業領域として活用できるようになり、パフォーマンス改善につながることもあります。
コメント