--- title: "Azure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計、App Service／SQL Databaseとの違いを実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15643/" published: 2026-07-25 updated: 2026-09-27 categories: ["Azure"] publisher: "株式会社一創" --- # Azure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計、App Service／SQL Databaseとの違いを実装者目線で解説 Azure Virtual Machines（Azure VM）は、Microsoft Azureがオンデマンドで提供するスケーラブルなIaaS（Infrastructure as a Service）のコンピューティングリソースです。物理ハードウェアを買わずに仮想化の柔軟性を得られる一方、OSのパッチ適用・構成・ソフトウェア導入といった保守は自分で担う点が、App ServiceなどのPaaSとの決定的な違いになります。この記事では定義から、VMを支えるサポートリソースと課金、用途で分かれるVMシリーズとマネージドディスクの選び分け、従量課金からスポットまでの料金モデル、可用性ゾーンやスケールセットによる可用性設計、そしてPaaS各サービスとの違いと「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。 ## まとめ：Azure Virtual Machinesの要点と採用判断の分岐 Azure VMは、コンピューティング環境をきめ細かく制御したいときに選ぶIaaSの計算リソースです。仮想化の柔軟性を借りられる代わりに、OS以上の層（パッチ・ミドルウェア・アプリ）の運用責任は利用者に残ります。実装で最初に押さえるべきは、ワークロードで決まるVMサイズ（シリーズ）、料金を左右する購入モデル、そして可用性ゾーンやスケールセットによる冗長構成の三点です。2026年時点では、開発・検証、需要が変動するクラウドアプリ、オンプレミスの延伸（拡張データセンター）が代表的な用途に位置づけられています。 採用が合理的なのは、OSやミドルウェアまで自分で握りたい、既存のオンプレミスサーバーをそのままクラウドへ移したい、あるいはPaaSでは対応できない特殊な構成が要るケースです。逆に、アプリの実行環境だけあればよいなら[Azure App Serviceの仕組みを解説した記事](https://www.issoh.co.jp/tech/details/15639/)で扱うPaaS、データベースだけ要るなら[Azure SQL Databaseを解説した記事](https://www.issoh.co.jp/tech/details/15641/)のマネージドサービスのほうが運用は軽くなります。自社システムでどの計算基盤を組むべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。 ## Azure Virtual Machinesの定義とIaaSとしての仕組み Azure VMを理解する起点は、「サーバー1台分の仮想マシンをオンデマンドで借り、OSより上は自分で組む」という発想です。ハードウェアの調達・保守からは解放されますが、仮想マシンそのものの管理からは解放されません。 ### 物理ハードウェアなしの仮想化と、利用者に残る自己管理の責任範囲 Azure VMは、物理ハードウェアを購入・保守せずに仮想化の柔軟性を得られる計算リソースです。ただしMicrosoftが引き受けるのは物理基盤とハイパーバイザーまでで、その上で動くOSの構成・パッチ適用・ソフトウェア導入は利用者の責任として残ります。ここがPaaSとの責任分界点です。仮想マシンと物理マシン・コンテナの関係をまず整理したい場合は、[仮想マシンとは何かを物理マシン・コンテナとの違いから解説した記事](https://www.issoh.co.jp/tech/details/13372/)を先に読むと、この記事のIaaS特有の話が理解しやすくなります。 ### 仮想マシンを支えるサポートリソースと、それぞれの課金の考え方 仮想マシンを作成すると、それを支える周辺リソースも同時に作られ、各々に費用が発生します。実装前に課金の内訳を押さえておくと、見積もりのずれを防げます。 | リソース | 役割 | 課金の考え方 | | --------------------- | -------------- | ------------------------- | | 仮想ネットワーク（VNet）／NIC | 他リソースとの通信 | NIC自体は無償・数はVMサイズで上限 | | パブリック／プライベートIP | ネットワーク内外との通信 | IPアドレス料金が別途発生 | | ネットワークセキュリティグループ（NSG） | 受信・送信トラフィックの制御 | 追加料金なし | | OSディスク／データディスク | OSとデータの永続保存 | マネージドディスク料金・ローカル一時ディスクは無償 | | OSライセンス | Windows等のOS実行 | コア数で変動・ハイブリッド特典で削減可 | OSディスクは通常127GiB前後（イメージにより小さい場合あり）で、通常のディスク料金で課金されます。ストレージはVMの計算料金とは別建てで課金される点が要点です。OSライセンス費はコア数に比例するため、VMサイズはワークロードに見合う範囲で選び、過剰なコア数を避けると費用を抑えられます。 ### 開発・検証からオンプレミスの延伸まで、想定される主な用途の広さ Azure VMの用途は幅広く、代表例は三つに整理できます。第一は開発・テストで、特定の構成を持つ計算機を素早く用意してアプリを検証する使い方です。第二はクラウド上のアプリケーションで、需要が増えたときだけ追加のVMを立て、不要になれば停止して費用を圧縮します。第三は拡張データセンターで、Azure仮想ネットワーク内のVMを自社ネットワークへ接続し、オンプレミスの延長として運用します。どれも「必要な分だけ計算資源を確保する」というIaaSの特性を活かした形です。 ## ワークロードで決まるVMシリーズとマネージドディスクの選び分け Azure VMは、選んだサイズが処理能力・メモリ・ストレージ容量・ネットワーク帯域を決めます。用途に見合わないシリーズを選ぶと、性能不足や過剰コストに直結します。 ### ワークロード用途別に分かれるVMシリーズの役割と選び分けの基準 Azureは多数のサイズを用途別のシリーズにまとめて提供しています。代表的なシリーズは次のとおりです。 | シリーズ | 分類 | 向く用途 | | ---- | ------------ | ----------------------- | | B | バースト可能 | 常時は低負荷で時々跳ねるWeb・小規模サーバー | | D | 汎用 | Webサーバー・業務アプリなどバランス型 | | E | メモリ最重視 | インメモリDB・大容量キャッシュ | | F | コンピューティング重視 | バッチ処理・アプリサーバー・解析 | | N | GPU搭載 | 機械学習の学習・推論・可視化 | | L／M | ストレージ／大容量メモリ | 大規模DB・NoSQL・SAP等 | 2026年時点では、AMD第5世代EPYC（開発コード名Turin）ベースの新世代シリーズが順次一般提供へ移行し、前世代比でネットワーク性能が向上する系統が加わっています。命名規則に「d」を含むサイズ（Dadsv6系など）はローカルNVMeの一時ストレージを備え、SQL Serverのtempdbや高I/Oの一時ファイルを載せる用途で性能を稼げる点が特徴です。まずはDシリーズの汎用サイズで組み、性能特性が見えた段階で専用シリーズへ寄せる進め方が実装の手戻りを減らします。AWSのインスタンスタイプ・Google Cloudのマシンタイプとの命名規則の対応は[インスタンスタイプとは？AWS・Azure・Google Cloudの命名規則と選定手順](https://www.issoh.co.jp/tech/details/17753/)で解説しています。 ### マネージドディスクの種類と性能階層による使い分けの基本的な考え方 ストレージはマネージドディスクで扱い、ストレージアカウントの作成・スケール管理はAzureが背後で引き受けます。利用者が指定するのはサイズと性能階層だけです。性能階層は用途で次のように分かれます。 | ディスク種類 | 性能の位置づけ | 向く用途 | | -------------- | -------------- | ---------------- | | Ultra Disk | 最高IOPS・低遅延 | 基幹DB・高負荷トランザクション | | Premium SSD v2 | 高性能・容量と性能を独立設定 | 本番の汎用〜高負荷ワークロード | | Premium SSD | 安定した高性能 | 本番の一般的なワークロード | | Standard SSD | 中程度の性能 | Web・軽負荷アプリ・開発 | | Standard HDD | 低コスト・低頻度アクセス | バックアップ・アーカイブ | OSとデータは別ディスクに分けるのが定石で、VMが故障してもデータディスクを切り離して別VMへ付け替えられます。加えてローカル一時ストレージは物理的にホスト直結のため低遅延ですが、VMの割り当て解除や削除でデータが消えるため、キャッシュや一時ファイルなど失われても支障のないデータに限って使います。 ## 従量課金からスポットまでの料金モデルとコスト削減の主な手段の考え方 Azure VMの費用は、VMサイズとOSに応じた時間単価で課金され、部分利用時は使った分数だけ請求されます。ストレージは別建てです。同じVMでも購入モデルの選択で単価が大きく変わるため、稼働パターンから逆算して選びます。 | 購入モデル | 仕組み | 向くワークロード | | ------------ | ------------------ | -------------------- | | 従量課金（PAYG） | 使った時間分を都度課金 | 短命・予測しにくい負荷 | | 予約インスタンス | 1年／3年の前払いで割引 | 常時稼働する本番 | | Savings Plan | 時間あたりの支出をコミットして割引 | 台数が変動する本番 | | スポット | 空き容量を最大約90%引き・中断あり | 中断に耐えるバッチ・検証 | | ハイブリッド特典 | 保有OSライセンスを持ち込み割引 | 既存Windows／SQL資産がある場合 | 常時動かす本番サーバーなら予約インスタンスやSavings Planでコミットして単価を下げ、途中で止まっても再実行できるバッチや検証はスポットで空き容量を安く使う、という配分が費用対効果の基本です。既存のWindows ServerやSQL Serverのライセンスがあるなら、Azureハイブリッド特典を重ねて計算コストをさらに削減できます。なお1サブスクリプションあたりのリージョン別コア数には初期クォータがあり、多数のVMを一度に展開する計画では事前の上限引き上げ申請を見込んでおきます。 ## 可用性ゾーン・スケールセット・Site Recoveryによる可用性設計 単体のVMは1つの物理基盤に依存するため、本番では冗長化の設計が前提になります。Azureは可用性を高める複数の仕組みを用意しています。 ### 可用性ゾーンとスケールセットによる冗長化と自動スケールの設計 可用性ゾーンは、1つのAzureリージョン内で物理的に分離されたゾーンです。同一リージョンの2つ以上のゾーンにまたがって2インスタンス以上を配置すると、少なくとも1インスタンスへの接続を99.99%の時間で保証するSLAが適用されます。仮想マシンスケールセットは、負荷分散された同一構成のVM群を作成・管理する仕組みで、需要やスケジュールに応じてインスタンス数を自動で増減させる設計です。スケールセット内のVMは複数の可用性ゾーン、単一ゾーン、あるいはリージョン内へ配置でき、可用性の確保と一括更新の両方を担えます。 ### リージョン全体の障害に備えるAzure Site Recoveryの役割 リージョン全体が停止するようなまれな事態には、Azure Site Recoveryでの災害復旧を構成します。任意のリージョンへVMを複製しておき、復旧計画で切替手順を自動化しておけば、障害時に数分でアプリを別リージョンへ引き上げられる仕組みです。本番前に切替テストを流し、実運用や複製に影響を与えずに手順を検証できる点も、可用性設計に組み込む価値があります。RPO／RTOの要件は、この複製構成とストレージの地理冗長の組み合わせで担保します。 ## App Service・SQL DatabaseなどPaaSとの違いと採用・見送りの判断 Azure VMは万能の計算基盤ではありません。同じアプリを動かすにも、IaaSのVMとPaaSの各サービスでは管理範囲と運用負荷が段階的に異なります。ここを取り違えると、過剰な運用コストを抱え込みます。 ### IaaS（VM）とPaaSを管理範囲と運用負荷で切り分ける判断軸 同じワークロードでも、どこまで自分で握るかで選ぶサービスが変わります。 | 選択肢 | 管理モデル | 利用者の管理範囲 | 向く要件 | | ------------------ | ----------- | ------------- | ---------------- | | Azure VM | IaaS | OS・ミドルウェア・アプリ | OSまで制御・特殊構成・移行 | | Azure App Service | PaaS | アプリのコードと設定 | Web／APIの実行環境だけ要る | | Azure SQL Database | PaaS（DBaaS） | スキーマとクエリ | マネージドなDBだけ要る | Azure VMはOSレベルまで制御できる代わりに、パッチやバックアップの運用も自分の責任です。アプリの実行環境だけあればよいなら[Azure App Serviceの仕組みと料金プランを解説した記事](https://www.issoh.co.jp/tech/details/15639/)で扱うPaaSのほうが運用は軽く、データベースだけ要るなら[Azure SQL Databaseの購入モデルと階層を解説した記事](https://www.issoh.co.jp/tech/details/15641/)のマネージドサービスが向きます。管理を任せたい順にPaaS→IaaSと並べ、自分で握る必要がある層だけVMに降ろす、と捉えると選定しやすくなります。 ### Azure Virtual Machinesの採用が第一候補になるケースの条件 次のいずれかに該当するなら、Azure VMが第一候補になります。 - OS・ミドルウェア・特定バージョンの固定など、実行環境をOSレベルまで自分で制御したい - 既存のオンプレミスサーバーを構成を変えずにクラウドへ移す（リフト＆シフト） - PaaSがサポートしないソフトウェアやサードパーティ製エージェントの常駐が要る - GPUや大容量メモリなど、特定ハードウェア特性を持つサイズが必要 いずれも制御の自由度が効く領域です。まず汎用シリーズで小さく立ち上げ、負荷特性が見えた段階で専用シリーズや予約インスタンスへ寄せる段階的な進め方が、コストと性能の両面で無理を避けます。 ### Azure Virtual Machinesを選ぶべきでない場面と代替の選択 一方で、次の要件にはAzure VMを選びません。第一に、標準的なWebアプリやAPIを載せるだけなら、OSの保守が不要なApp ServiceなどのPaaSのほうが運用負荷が小さく済みます。第二に、リレーショナルDBだけが要るなら、パッチやバックアップを自前で回すVM上のDBより、フルマネージドのSQL Databaseが適した選択です。第三に、イベント駆動で断続的にしか動かさない処理なら、常時課金のVMよりサーバーレスの計算サービスが費用を圧縮できます。運用を任せられるところはPaaSへ寄せ、どうしても自分で握る必要がある層だけVMに残すのが、総保有コストを抑える定石です。 ### 受託開発におけるクラウドインフラ設計の相談と外注先選定の勘所 実際のシステムでは、Azure VM単体ではなくネットワーク・ストレージ・認証・監視・データベースを役割ごとに組み合わせる構成が普通です。どのワークロードをVMに載せ、どこをPaaSへ寄せ、どのシリーズとディスク階層を選び、どの可用性ゾーン構成とSite RecoveryでRPO／RTOを満たすかは、負荷・可用性要件・月次コストのトレードオフで決まり、稼働後のサイズ変更や購入モデルの移行には相応の検証が伴います。要件定義の段階で全体設計を固めておくほど、後の作り直しを避けられる設計です。Azureを含む[クラウド基盤の構築・移行の相談](https://www.issoh.co.jp/service/system/aws/)では、IaaSとPaaSの切り分けを含めた設計から実装・運用までを一貫して支援できます。 ## よくある質問 Azure Virtual Machinesの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。 ### Azure VMとApp Serviceはどう使い分けますか？ 管理範囲で分かれます。Azure VMはIaaSで、OS・ミドルウェア・アプリまで自分で構成できる代わりに、パッチやバックアップの運用も自分の責任です。App ServiceはPaaSで、アプリのコードと設定だけを扱えばよく、OSの保守はプラットフォームが担います。OSレベルの制御や特殊なソフトウェアが要るならVM、Web／APIの実行環境だけあればよいならApp Serviceが向きます。 ### スポットVMはどんなときに使いますか？ 中断されても再実行できるワークロードに向いた購入モデルです。Azureの空き容量を通常価格から最大約90%引きで使えますが、Azureがその容量を必要とすると予告なく中断される可能性があります。バッチ処理、検証環境、レンダリングのように途中で止まっても支障のない処理でコストを大きく圧縮できる用途です。常時稼働が要る本番には、中断のない従量課金や予約インスタンスを選びます。 ### VMのサイズ（シリーズ）はどう選べばよいですか？ ワークロードの特性から選びます。バランス型ならD、メモリを多く使うならE、CPUを多く使うならF、GPUが要るならN、常時低負荷で時々跳ねるならB、という対応が基本です。最初から専用シリーズに絞り込むより、汎用のDシリーズで動かして処理能力・メモリ・I/Oの使われ方を計測し、ボトルネックが見えた層に合わせてシリーズを寄せると、過剰なサイズ選択を避けられます。 ### 予約インスタンスとSavings Planはどちらがよいですか？ 稼働の読みやすさで分かれます。特定サイズのVMを長期に固定で動かすなら、そのサイズを1年／3年で予約する予約インスタンスが単価を下げます。台数やサイズが変動するなら、時間あたりの支出額をコミットするSavings Planのほうが柔軟です。どちらも従量課金より単価を下げられるので、常時稼働する本番から順に適用先を検討します。 ### 可用性ゾーンを使うと何が保証されますか？ 接続の稼働率が保証される仕組みです。同一リージョン内の2つ以上の可用性ゾーンにまたがって2インスタンス以上を配置すると、少なくとも1つのインスタンスへの接続が99.99%の時間で保たれるSLAが適用されます。ゾーンは物理的に分離されているため、データセンター単位の障害に耐えられる構成です。リージョン全体の停止に備えるなら、これに加えてSite Recoveryでの別リージョンへの複製を組み合わせます。 ## 関連記事 - [仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13372/)：Azure VMの土台となる仮想化そのものの仕組みを概念から押さえられます。 - [Azure App Serviceとは？仕組み・料金プラン・デプロイスロットとStatic Web Apps／AKSとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15639/)：VMに載せるか任せるかを判断するPaaS側の対応物を読み比べられます。 - [Azure SQL Databaseとは？仕組み・購入モデル・サービス階層とSQL Server／Managed Instanceとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15641/)：VM上でDBを自己管理するか、マネージドDBに任せるかの使い分けを確認できます。 --- 出典: [Azure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計、App Service／SQL Databaseとの違いを実装者目線で解説]()（株式会社一創）