Azure VMを従量課金から1年予約インスタンスに切り替える方法｜既存VMの名前・ID・データはそのまま

稼働中のAzure仮想マシンを、停止や再作成をせずに従量課金から1年予約インスタンスへ切り替えたい――結論は「VMはそのまま、同条件の予約を購入するだけ」です。本記事では確認ポイントと購入手順、割引適用のチェック方法まで具体的に解説します。

結論：既存VMを「変換」する必要はない（データ・名前・リソースIDはそのまま）

Azureの「予約インスタンス（Azure Reserved VM Instances）」は、仮想マシンそのものを作り替える仕組みではなく、条件に一致した稼働中のVM利用分に割引を自動適用する“料金の予約（割引の権利）”です。つまり、既存VMのリソースIDやVM名、OSディスク／データディスク、NIC、Public IP、NSG、拡張機能、他システム連携などを触らずに、料金だけを予約価格に近づけられます。

やること	やらないこと（不要）
既存VMと同じ「リージョン」「VMサイズ」「スコープ」に合う1年予約インスタンスを購入	VMの再作成／再デプロイ／移行
購入後、割引が適用されているかをコスト管理で確認	VM名やリソースIDの変更
重要システムなら事前にバックアップ（スナップショットやAzure Backup）	ディスクの削除・初期化
将来の変更に備えて、スコープや最適化設定（サイズ柔軟性など）を理解	停止・再起動（通常は不要）

なぜ「何も変えずに」料金だけ変えられるのか

予約インスタンス購入後、Azure側で「予約の条件」と「実際の使用量（利用メーター）」が突合され、条件に一致したVM利用に対して自動で割引が当たります。個々のVMに「この予約を割り当てる」といった操作は基本的に不要で、同一スコープ内で一致する利用に順番に適用されるイメージです。

さらに、VMを停止（割り当て解除）すると、その時間帯は「使わなかった予約枠」になり得ますが、スコープ内に別の一致リソースがあればそちらに自動で回る、という考え方になります（使い切れない分はその時間帯は失効）。

購入前に確認すべきポイント（ここがズレると割引が当たらない）

「予約を買ったのに安くならない」の原因の多くは、リージョン／サイズ／スコープの不一致です。購入前に、まず既存VMの条件を正確に押さえます。

確認項目	見る場所（例）	重要な理由
リージョン	VMの概要（Location）	予約は原則リージョン単位で一致が必要
VMサイズ（SKU）	VMのサイズ（例：D2s_v3）	サイズが違うと一致しない（サイズ柔軟性設定で吸収できる場合あり）
VMシリーズ／世代	Dsv3 / Dsv4 など	“似ているサイズ”でも世代違いは別SKUになりやすい
スコープ（割引適用範囲）	どのサブスクリプション／管理グループに適用するか	適用対象サブスクが範囲外だと割引が当たらない
台数（数量）	同条件VMが何台・何時間稼働するか	予約は「時間×台数」を買うイメージ。少なすぎても多すぎてもムダが出る
OSコストの扱い	Windows / Linux、ライセンス形態	予約は主にCompute部分。Windowsは別の最適化（AHB等）も検討余地

CLIでサッと確認したい場合（変更は一切しない）

運用中のVMに触れずに「いまの条件」を正確に控える用途として有効です。

# VMのリージョンとサイズを確認（Azure CLI）
az vm show -g <リソースグループ> -n <VM名> --query "{name:name, location:location, size:hardwareProfile.vmSize}" -o table

# PowerShell（Az）で確認
Get-AzVM -ResourceGroupName <リソースグループ> -Name <VM名> | Select-Object Name,Location,HardwareProfile

Azureポータルで「1年予約インスタンス」を購入する手順（VM側の作業は不要）

操作の流れはシンプルで、購入画面で既存VMに合わせた条件を選びます。

1. Azureポータルにサインイン
2. 左メニューから「Reservations（予約）」を開く（上部検索で「予約」「Reservations」でも可）
3. 「追加（Add）」をクリック
4. 対象サービスで「Virtual machine（仮想マシン）」を選択
5. 購入条件を既存VMに合わせて入力（後述の表を参照）
6. 内容確認後、購入（Review + buy）で確定

購入画面で迷いやすい項目と、実務的な選び方

項目	何を意味する？	おすすめの決め方
Region（リージョン）	割引を当てたいVMが動いている地域	既存VMのLocationと完全一致（Japan East / Japan Westの取り違えに注意）
VM size（サイズ）	割引対象となるSKU	既存VMのvmSizeと一致。将来サイズ変更の可能性があるなら「サイズ柔軟性」も検討
Term（期間）	1年/3年などのコミット期間	要件どおり1年。不確実性が高いなら数量を抑えて様子見も現実的
Quantity（数量）	同条件で割引できる台数（時間単位で消費）	まずは「常時稼働の台数」を基準に。変動が大きいなら控えめ→利用率を見て追加購入
Scope（スコープ）	どの範囲の利用に割引を当てるか	単一サブスクならSingle、複数サブスクにまたがるならSharedや管理グループを検討
Billing（支払い）	一括/毎月など	予算管理に合わせる。月額オプションが用意されるケースもある
Optimize for（最適化）	サイズ柔軟性を優先するか、容量優先にするか	基本は「サイズ柔軟性」。確実に同サイズの容量確保が重要なら「容量優先」も検討（条件あり）

スコープの選び方：割引を当てたい「範囲」を間違えない

予約インスタンスは「どのサブスクリプション／どのまとまりの利用に割引を当てるか」を決められます。運用でありがちな失敗は、予約を買ったサブスクと、VMが動いているサブスクが違う／適用範囲が狭すぎるケースです。

スコープ	向いているケース	メリット	注意点
Single（単一サブスクリプション）	割引を必ず特定サブスク内に閉じたい	部門別会計などで管理しやすい	対象サブスク外のVMには当たらない
Shared（共有）	同じ請求単位内に複数サブスクがあり、どこでも割引を使い切りたい	一致する利用に自動で広く当たりやすく、利用率を上げやすい	どのVMに当たるかは自動（“特定VM固定”にはできない発想）
Management group（管理グループ）	共有ほど広くしたくないが、複数サブスクに跨って適用したい	対象範囲を「管理グループ配下」に絞れる	請求スコープとの関係など前提条件を確認

購入後でも、予約のスコープ変更はポータルから可能です。範囲を広げて利用率を上げたいとき、組織変更で割引を別サブスクに寄せたいときに使います。

サイズ一致の考え方：「同じSKU」だけでなく、将来変更まで視野に入れる

基本は「既存VMのサイズと同じ予約を買う」が最も分かりやすく確実です。一方で、運用上はスケールアップ／スケールダウンや、同じシリーズ内でのサイズ変更が起こることがあります。

Azureには「インスタンスサイズの柔軟性（instance size flexibility）」という考え方があり、同一のサイズグループ（同系列）内であれば、予約の割引を別サイズに回せる設計が用意されています（設定・対象条件あり）。

「サイズ柔軟性」vs「容量優先」：最適化設定の違い

最適化	目的	こんなときに選ぶ	実務でのポイント
インスタンスサイズの柔軟性	割引を“使い切る”ことを重視	サイズ変更や台数増減があり得る／複数VMで食い合っても良い	「割引最適化」寄り。共有スコープでは既定で有効になりやすい
容量優先（Capacity priority）	データセンター容量を優先的に確保したい	将来の起動・増設で“確実に同SKUを確保したい”	主に単一スコープで選べるなど条件があるため、要件と制約を確認

購入後に確認すること：本当に予約インスタンス割引が適用されたか

予約は「買って終わり」ではなく、割引が当たっている（=利用率が高い）状態を作って初めて効果が最大化します。特に、1台だけのVMでも、リージョンやサイズを取り違えると効果がゼロになり得ます。

ポータルで利用率（Utilization）を確認する

1. Azureポータルで「Reservations（予約）」を開く
2. 対象の予約を選択
3. 利用率（Utilization）や使用トレンドを確認

利用率が低い場合は、サイズ・リージョン・スコープが合っていないか、単純に稼働時間が足りず「使い切れていない」可能性が高いです。

コスト分析で「予約が当たった利用」になっているか確認する

Cost Management（コスト管理）側では、実コスト（Actual）と償却（Amortized）などの見え方が異なることがあります。運用としては次の観点で見ると判断が速いです。

• 対象VMの稼働時間帯で、予約適用後の単価感になっているか
• 予約の時間枠が使い切れているか（使い切れない時間が多いなら数量過多）
• 該当利用のConsumedServiceがCompute側（Microsoft.Compute等）であるか（分析時の切り口）

よくある落とし穴と、現場での回避策

リージョン違い（Japan EastとJapan West）

「同じ日本だから大丈夫」と思いがちですが、予約のリージョンが違うと一致せず割引が当たりません。VMのLocationをコピペして一致させるくらい慎重でOKです。

サイズの取り違え（D2s_v3 と D2s_v4、D2s_v3 と D2_v3）

末尾の「s」や「v3/v4」の違いは別SKUです。既存VMのサイズ表記をそのまま採用し、予約購入画面でも同一SKUを選びます。サイズ変更の余地がある運用なら、サイズ柔軟性の考え方まで含めて設計すると事故が減ります。

「特定の1台に固定して割引を当てたい」という発想

予約は“条件一致の利用”に当たるため、共有スコープなどでは特定VMに紐付けるというより、プールとして最適配分されるイメージです。外部連携や監査上「このVMだけに当てたい」要件が強いなら、スコープをSingleに寄せるなど会計設計で寄せます。

停止（割り当て解除）時間が多く、予約が“使い捨て”になっている

予約は時間単位の割引で、未使用分を翌日に繰り越せません。夜間停止する運用のVMにフル数量を買うと、利用率が下がります。対策は次のいずれかです。

• まずは控えめな数量で購入し、利用率を見て追加購入
• 共有スコープで、別の一致VMに割引が回るように設計
• 稼働が読めない部分は、予約ではなく別の最適化（サイズ見直し等）で吸収

Spot VMには予約を当てられない

開発・バッチなどでSpot VMを使っている場合、予約の考え方がそのままは使えません。Spotは深い割引がある一方で、予約とは別物です。

Windowsのコストが想定ほど下がらない（OS料金の勘違い）

予約インスタンスは主にCompute側の最適化です。Windows Serverを使っている場合、ライセンスコストの扱いによって「思ったほど下がらない」と感じることがあります。環境によっては、Azure Hybrid Benefit（保有ライセンス活用）やソフトウェア予約の検討余地があります。

“止められない本番VM”で安全に進めるための実務手順

「外部システム連携がある」「VMのIDや名前を変えられない」「止められない」――こうした本番VMほど、手順はシンプルに、検証は丁寧に進めるのがポイントです。

フェーズ	やること	狙い
事前準備	VMのリージョン・サイズ・稼働形態（24/7か）・サブスクを控える	一致条件の取り違え防止
安全策	スナップショット/Azure Backupで念のため保険を作る	予約購入自体は非破壊だが、運用上の安心材料
購入	1年予約を、まず必要最小限（例：1台分）で購入	効果確認→追加で最適化
確認	Reservationsの利用率、Cost Managementで割引適用を確認	「本当に当たっている」を可視化
運用最適化	利用率が低ければスコープ変更／サイズ柔軟性／数量の見直し	“買っただけ”を防ぎ、コスト削減を最大化

FAQ：よくある質問

予約を買ったら、いつから安くなる？

予約の期間は購入後すぐに開始し、条件に一致する利用があれば割引が適用される考え方です。既存VMを作り直す必要はありません。

VMを停止・再起動しないと反映されない？

通常は不要です。割引は使用量に対して自動的に適用されるため、購入後にVMを再デプロイするような手順は基本的にありません。

予約を買い間違えたら終わり？

組織や契約形態、ルールによって条件は異なりますが、予約には交換・キャンセル等の選択肢が用意されることがあります。購入前に「リージョン・サイズ・スコープ」を固め、購入後は早めに利用率を確認するのが現実的なリスク低減策です。

同じサイズのVMが複数ある場合、どのVMに割引が当たる？

予約は“条件一致の利用”に対して自動的に適用されます。固定割り当てというより、スコープ内で一致する利用に順次当たるイメージで理解すると運用が楽になります。

まとめ：既存VMを一切変えずに、手堅くコストを下げるなら「同条件の1年予約購入」

従量課金のAzure VMを、データ削除なし・VM名やリソースIDもそのままで1年予約インスタンスに切り替える方法はシンプルです。既存VMに合わせて予約を購入し、割引が当たる条件（リージョン・サイズ・スコープ）を揃えるだけ。重要なのは「買い方」と「買った後の利用率チェック」です。運用が安定している本番VMほど、まずは小さく購入して効果確認→追加購入、という進め方が失敗しにくくおすすめです。