Compute Engineは、Google Cloudのインフラ上で仮想マシン（VM）を起動して使うIaaS型のサービスです。この記事では、用途別に分かれたマシンファミリーとvCPU・メモリを自由に決めるカスタムマシンタイプの仕組み、gcloudコマンドでVMを作って接続し、停止してオートスケールまで設定する手順、秒単位課金に継続利用割引・確約利用割引・Spot VMが乗る料金構造、ホストメンテナンスでもVMを止めないライブマイグレーションを、Google Cloud公式ドキュメントの一次情報で整理します。AWSのAmazon EC2やサーバーレスのCloud Run、マネージドKubernetesのGKEとの使い分け、そしてCompute Engineを採用すべき条件と見送るべき場面まで、構成設計で迷う論点を数値で示します。
まとめ：Compute Engineのマシンタイプ・料金と採用判断の要点
Compute Engineは、Google Cloud上でOSごと自分で握れる仮想マシンを秒単位で借りられるIaaSで、AWSでいえばAmazon EC2に当たる基盤サービスです。まず決めるのはマシンタイプで、汎用・演算特化型・メモリ特化型・アクセラレータ型などのマシンファミリーから用途に合うシリーズを選び、事前定義タイプで形が合わなければvCPUとメモリを任意に指定するカスタムマシンタイプを使います。ストレージは永続ディスクやHyperdisk、ローカルSSDから選び、水平スケールはマネージドインスタンスグループで台数を自動増減させる構成です。
料金は秒単位のオンデマンドが基準で、そこへ3系統の割引が乗ります。月内の稼働割合で自動適用される継続利用割引（N1で最大30%、N2・N2D・C2で最大20%）、1年・3年の確約と引き換えの確約利用割引（リソースベースで最大55%、メモリ特化型は最大70%）、中断を許容する代わりに最大91%安くなるSpot VMの3つです。数値はいずれも2026年9月時点の公式ドキュメントに基づきます。
手を動かすなら、gcloudで1台作ってSSH接続し、停止と削除まで一度通すのが近道です。コンテナを動かしたいだけならCloud Run、KubernetesならGKE、AWS前提ならAmazon EC2という選択肢もあり、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて判断してください。
Compute Engineとは何か：GCPの仮想マシンとマシンタイプの仕組み
Compute Engineを設計に落とすには、どんなVMを・どのストレージで・どう増減させるかという三つの軸を押さえるのが基本です。IaaSという提供モデルの上で、仮想マシンそのものの概念を前提に読むと構造が整理できます。ハイパーバイザーでCPUやメモリを分割する土台の仕組みは、仮想化技術の種類とサーバー仮想化の採用判断で先に確認しておくと、ライブマイグレーションやカスタムマシンタイプがなぜ成り立つのかが読み解けます。
用途別のマシンファミリーとシリーズ・世代でVMの性格が決まる
Compute EngineのVMは、まずマシンファミリーで性格が分かれます。公式のマシンファミリー一覧によると、汎用ファミリーにはE2・N1・N2・N2D・N4系・C3系・C4系・Tau T2D/T2Aが並び、E2は低コスト志向、N系は汎用の主力、C4系は高い性能を狙う新しい世代という位置づけです。CPU性能に振った演算特化型はH4D・H3・C2・C2D、大容量メモリを要するインメモリ処理向けのメモリ特化型はM1〜M4とX4・X5、GPUを載せるアクセラレータ型はA2〜A4X系とG2・G4です。このほかローカルSSDを大量に積むストレージ特化型（Z3・Z4D）や、ネットワーク帯域に振ったネットワーク特化型（C4N・M4N）もあります。
各ファミリーはシリーズ・世代・プロセッサでさらに細分化され、数字が大きいほど新しいCPUプラットフォームを指します。機械学習の学習や推論、SAPのような大規模インメモリDB、Web/APIの汎用ワークロードといった用途ごとに選ぶ設計なので、まず用途からファミリーを決め、その中で世代とサイズを選ぶ順序で考えると迷いません。旧来の記事ではC4を演算特化型として紹介する例もありますが、2026年9月時点の公式分類では汎用ファミリーに入っています。
| マシンファミリー | 代表シリーズ | 向く用途 |
|---|---|---|
| 汎用 | E2・N2・N4・C4 | Web/API・汎用サーバー |
| 演算特化型 | H3・C2・C2D | 高CPU負荷・HPC演算 |
| メモリ特化型 | M3・M4・X4 | インメモリDB・SAP |
| ストレージ特化型 | Z3・Z4D | 大容量ローカルSSD |
| アクセラレータ型 | A3・A4・G2 | GPUでのAI学習・推論 |
事前定義マシンタイプとカスタムマシンタイプをどう使い分けるか
マシンタイプには、vCPUとメモリの組み合わせが決められた事前定義タイプと、両者を任意に指定するカスタムマシンタイプがあります。事前定義タイプは選ぶだけで済む反面、必要なメモリに対してvCPUが過剰になるといった無駄が生じがちです。カスタムマシンタイプはワークロードの実測値に合わせてvCPUとメモリを刻めるため、余剰リソースへの支払いを削れます。
カスタムマシンタイプの公式ドキュメントでは、対応シリーズは汎用のN4・N4D・N4A・N2・N2D・E2・N1と、アクセラレータ型のG2に限られます。刻める範囲にもシリーズごとの上限があり、たとえばE2はvCPU 2〜32、1vCPUあたりメモリ0.5〜8GBで、拡張メモリには対応しません。N2は1vCPUあたり8GBを超える拡張メモリを付けられるため、メモリ偏重のワークロードはN2系で組むほうが形に合わせやすくなります。
ただしカスタムには一律の追加料金（プレミアム）が乗るため、事前定義で形がぴったり合うならそちらが割安です。実測でメモリ偏重やCPU偏重が明確なワークロードはカスタム、標準的な比率で足りるなら事前定義、という切り分けが起点になります。
永続ディスク・イメージとマネージドインスタンスグループの役割
VMに付けるストレージは、公式のストレージオプション一覧にあるとおり、ネットワーク接続の永続ディスク（Standard／Balanced／SSD／Extreme）、性能とサイズを独立して決められるHyperdisk、VMに直結して高速だが揮発性のローカルSSDから選びます。新しいC4系やN4系はHyperdisk前提の設計になっているため、シリーズを決めた時点で使えるディスク種別も絞られる点に注意してください。
起動元は公開イメージや、自社の構成を焼き込んだカスタムイメージで、インスタンステンプレートに設定をまとめておけば同じ構成のVMを何台でも量産することが可能です。台数を需要に合わせて増減させるのがマネージドインスタンスグループ（MIG）で、テンプレートを元にオートスケーラーがCPU使用率などの指標でVMを自動追加・削減し、ヘルスチェックで異常なVMを自動で入れ替えます。単発のVMではなく、テンプレート＋MIGで水平スケールと自己修復を前提に組むと、本番運用が安定します。
gcloudでCompute EngineのVMを作成・接続・停止する手順
ここからは、Cloud ShellやローカルのGoogle Cloud CLIでそのまま実行できるコマンドで、VMの作成から後片付けまでを一通り試します。プロジェクトを選択済みで、Compute Engine APIが有効になっていることが前提です。フラグの正式な一覧はgcloud compute instances createのリファレンスで確認できます。
gcloud compute instances createで最初のVMを1台作成する
東京リージョン（asia-northeast1）のゾーンに、汎用E2のe2-mediumでDebian 12のVMを作る例です。ブートディスクはBalanced永続ディスクの20GBにしています。
# 東京ゾーンで使えるE2のマシンタイプを確認する
gcloud compute machine-types list \
--zones=asia-northeast1-b \
--filter="name~^e2-"
# 事前定義タイプ e2-medium でVMを1台作成する
gcloud compute instances create web-1 \
--zone=asia-northeast1-b \
--machine-type=e2-medium \
--image-family=debian-12 \
--image-project=debian-cloud \
--boot-disk-size=20GB \
--boot-disk-type=pd-balanced \
--tags=http-serverカスタムマシンタイプにする場合は、マシンタイプ名を「シリーズ-custom-vCPU数-メモリMB」の形で渡すか、–custom-cpu・–custom-memory・–custom-vm-typeの3フラグで指定します。止まってよい検証用のVMなら、Spot VMとして起動すると単価を大きく下げられます。
# N2のカスタムマシンタイプ（4 vCPU・メモリ12GB）で作成する
gcloud compute instances create batch-1 \
--zone=asia-northeast1-b \
--custom-vm-type=n2 \
--custom-cpu=4 \
--custom-memory=12GB \
--image-family=debian-12 \
--image-project=debian-cloud
# Spot VMとして作成し、プリエンプト時は削除でなく停止にする
gcloud compute instances create spot-1 \
--zone=asia-northeast1-b \
--machine-type=e2-standard-2 \
--provisioning-model=SPOT \
--instance-termination-action=STOP \
--image-family=debian-12 \
--image-project=debian-cloudVMのSSH接続から停止・削除までの手順と課金が止まる状態の確認
作成したVMへはgcloud compute sshで接続できます。初回はSSH鍵が自動生成され、プロジェクトかインスタンスのメタデータに登録されます。検証が終わったら、停止か削除で課金を止めてください。
# SSHで接続する
gcloud compute ssh web-1 --zone=asia-northeast1-b
# 一時停止する（vCPU・メモリの課金は止まる）
gcloud compute instances stop web-1 --zone=asia-northeast1-b
# 検証が終わったら削除する（ブートディスクも既定で一緒に消える）
gcloud compute instances delete web-1 --zone=asia-northeast1-b --quiet見落としやすいのは停止と削除の違いです。VMの停止に関する公式ドキュメントのとおり、停止中のVMはvCPUとメモリの課金は止まるものの、アタッチしたままの永続ディスクや予約済みの静的外部IPアドレスには課金が続きます。検証用VMは削除まで行い、残ったディスクとIPを一覧で確かめる習慣を付けておくと、請求の想定外を防げます。
インスタンステンプレートとMIGによるVMのオートスケール設定
本番の水平スケールは、テンプレート→MIG→オートスケーラーの順に組みます。次の例は、CPU使用率60%を目標に2〜5台の範囲で台数を増減させる設定です。オートスケーラーが見られる指標はオートスケーリングの公式ドキュメントに整理されており、CPU使用率のほかロードバランサの処理量やCloud Monitoringの指標も使えます。
# 1. インスタンステンプレートを作る
gcloud compute instance-templates create web-tmpl \
--machine-type=e2-medium \
--image-family=debian-12 \
--image-project=debian-cloud \
--tags=http-server
# 2. テンプレートからゾーンMIGを2台で作る
gcloud compute instance-groups managed create web-mig \
--zone=asia-northeast1-b \
--template=web-tmpl \
--size=2
# 3. CPU使用率60%目標・2〜5台でオートスケールさせる
gcloud compute instance-groups managed set-autoscaling web-mig \
--zone=asia-northeast1-b \
--min-num-replicas=2 \
--max-num-replicas=5 \
--target-cpu-utilization=0.6 \
--cool-down-period=90ゾーン障害まで考えるなら、–zoneの代わりに–regionを指定したリージョンMIGにすると、同じリージョン内の複数ゾーンへVMが分散されます。スケール判断の元になる指標やアラートの設計は、Cloud Monitoringの機能と設定とあわせて組むと、台数の増減と監視を同じ指標で揃えられます。
Compute Engineの料金モデルと割引・付帯コストを実務目線で押さえる
Compute Engineのコストは、秒単位のオンデマンド料金という基準に、3系統の割引と付帯コストが重なって決まります。割引の効かせ方を設計に織り込むと、同じ構成でも総額は異なるものです。マシンタイプ別・リージョン別の単価はCompute Engineの公式料金ページで確認できます。
秒単位のオンデマンド課金に3系統の割引を重ねる料金設計の考え方
基準となるオンデマンドは、VMの稼働に対して秒単位（1分の最低課金）で課金されます。ここへ乗る割引は三つです。
1つ目の継続利用割引（Sustained Use Discounts）は、対象VMを月内で長く動かすほど自動で適用される仕組みで、申請は要りません。2026年9月時点の公式ドキュメントでは、N1とメモリ特化型のM1・M2が最大30%、N2・N2D・C2が最大20%です。E2・N4・C4などの新しいシリーズは対象一覧に載っていないため、新シリーズを選ぶと継続利用割引は効かないと考えて見積もります。
2つ目の確約利用割引（Committed Use Discounts）は、1年または3年の利用を確約する代わりに割引を受ける仕組みです。特定のマシンシリーズのvCPU・メモリを確約するリソースベースでは最大55%、メモリ特化型は最大70%まで下がります。シリーズをまたいで使える支出額ベースのCompute Flexible CUDは、1年で16〜28%、3年で38〜54%の幅です。常時稼働する土台に効かせます。
3つ目のSpot VMは、Googleの余剰キャパシティを最大91%の割引で使う代わりに、キャパシティが必要になると停止または削除される方式です。シャットダウンの猶予はベストエフォートで最大30秒と短く、ライブマイグレーションにも対応しません。中断に耐えるバッチや検証環境向けと割り切り、常時稼働は確約利用割引、断続的で止まってよい処理はSpot、というように稼働の性格ごとに割引を割り当てるとコストを削れます。
| 料金・割引 | 適用の条件 | 向くワークロード |
|---|---|---|
| オンデマンド | 秒単位（申請不要） | 変動が読めない稼働 |
| 継続利用割引 | 月内の稼働で自動・最大30% | N1・N2等で常時稼働 |
| 確約利用割引 | 1年/3年確約・最大55% | 常時稼働の土台 |
| Spot VM | 中断を許容・最大91% | 止まってよいバッチ・検証 |
無料枠e2-microと300ドルの無料トライアルで検証する範囲の決め方
手を動かして試す段階では、無料で使える範囲を先に把握しておくと安心です。Google Cloudの無料プログラムの公式ページによると、Compute Engineの無料枠は、プリエンプティブルでないe2-micro 1台を月あたり、オレゴン（us-west1）・アイオワ（us-central1）・サウスカロライナ（us-east1）のいずれか1リージョンで使えるものです。標準永続ディスク30GB・月と、北米からの下り通信1GB・月（中国・オーストラリア宛を除く）も含まれます。
東京リージョンは無料枠の対象外なので、日本からの応答速度や日本リージョンの構成を確かめたい場合は、新規アカウント向けの無料トライアル（300ドル分のクレジットを90日間）の範囲で検証します。無料枠のe2-microはOSや起動スクリプトの動作確認まで、本番に近い性能検証はトライアルクレジットで東京ゾーンのVMを使う、と分けておくと、検証の途中で課金が始まる事故を防げます。
ライブマイグレーションを前提にした可用性とゾーン分散の設計の勘所
Compute Engineの特徴の一つが、ホスト側の計画メンテナンス時にVMを別の物理ホストへ無停止で移すライブマイグレーションです。ハードウェア更新やパッチ適用の裏でVMが移動するため、メンテナンスのたびにVMを落とす手間を避けられます。ただしライブマイグレーションの公式ドキュメントにあるとおり、対象はホストメンテナンスポリシーをMIGRATEにしたVMに限られ、GPUを付けたVM、Cloud TPU、ベアメタルのマシンタイプ、多くのConfidential VMは対象外です。GPU付きVMはメンテナンス時に停止する設定が必須で、Spot VMもライブマイグレーションしません。
可用性をさらに上げるなら、VMを複数ゾーンへ分散配置し、前段にCloud Load Balancingを置いてリージョンMIGで台数を維持する構成が定石です。単一ゾーンに1台だけ置く構成はゾーン障害に弱いため、本番はゾーン分散とロードバランサ、自己修復を前提に組みます。GPUでAI推論を回す構成は、メンテナンス停止を見込んで複数台で受ける設計にしてください。
コンピューティング費だけでは読み切れない付帯コストの見積もり方
VMの料金だけを見積もると総額を外します。VMに付ける永続ディスクやHyperdisk、ローカルSSDのストレージ費、外部公開に使うCloud Load Balancing、そして下り（外部）通信やリージョン間・ゾーン間のデータ転送料が別に積み上がるためです。停止したVMでも、確保したままの永続ディスクや予約済みの外部IPには課金が続く点も見落としがちです。
使っていないディスクや外部IP、ロードバランサを棚卸しし、通信の多いVMは同一リージョンへ寄せて転送料を抑えると、請求の想定外を減らせます。OSにWindows ServerやRHEL、SLESを使う場合はライセンス料金も上乗せされます。VM単価の割引と付帯コストの削減は別の作業として、両方を設計に入れておくのが実務です。AWS・Azureと月額の総額を比べたい場合は、AWS・Azure・Google Cloudの料金・無料枠と選定基準の比較で3社の前提を揃えてから比較すると判断がぶれません。
Compute Engineの採用条件とEC2・Cloud Run・GKEの使い分け
ここでは判断を言い切ります。Compute EngineはOSごと自由に握れる強力な基盤ですが、その分だけOSやミドルウェアの運用責任を自社が負います。自社システムのどこにCompute Engineを差し込むかを、条件付きで見極めてください。
Compute Engineの採用が効くワークロードの具体条件
採用が効くのは、OSレベルの制御が要る、既存のオンプレVMやサーバーをそのままGoogle Cloudへ移す（リフト＆シフト）、特定のミドルウェアやライセンス条件でコンテナ化しづらい、GPUを使うAI学習やHPCを回す、といった条件が重なるときです。オンプレからの移行を7Rのどれで進めるかは、クラウド移行の進め方と7Rの選び方で費用試算と切り替え手順まで整理できます。
とくに確約利用割引やSpot VMを効かせられる常時稼働・大規模並列の土台では、VMを直接持つコスト効率が出ます。こうしたGoogle Cloud上のインフラを自社に取り入れるなら、AWS・Google Cloud・Azureを横断したクラウドインフラ構築の相談窓口で、マシンタイプの選定やスケール設計、割引の効かせ方を含めた運用体制の妥当性を相談するとよいでしょう。
Amazon EC2・Cloud Run・GKEへ寄せるべき場面の見極め
クラウドの選択がAWS前提なら、同じIaaSでもAmazon EC2が土俵になります。Compute EngineとEC2はどちらもOSを自分で握るVMを提供しますが、マシンタイプの体系や課金の刻み、周辺サービス連携がクラウドごとに異なり、既存資産とチームの習熟がどちらへ寄っているかが選定の軸です。
一方、コンテナを動かしたいだけでVMもOSも持ちたくないなら、リクエスト単位で自動スケールするCloud Runが向きます。Kubernetesでコンテナ群をオーケストレーションしたいなら、ワーカーノードにCompute Engineを使うGoogle Kubernetes Engine（GKE）が選択肢です。OSまで握る必要があるならCompute Engine、コンテナで足りるならCloud RunやGKE、という分岐が実務の起点になります。
| 選択肢 | 管理する範囲 | 向く場面 |
|---|---|---|
| Compute Engine | OS・ミドルウェアまで | リフト＆シフト・GPU |
| Amazon EC2 | OS・ミドルウェアまで | AWS前提の既存資産 |
| Cloud Run | コンテナイメージのみ | ステートレスなWeb/API |
| GKE | コンテナとクラスタ設定 | 多数のサービス群の運用 |
Compute Engineを見送るべき場面と運用ではまりやすい失敗
見送るべきなのは、ステートレスなWebアプリやAPIをただ動かしたいだけの用途、OSやパッチを運用できる人員がいない小規模チーム、そして断続的にしか使わない処理に常時稼働のVMを立てておく構成です。これらをCompute Engineで抱えると、運用責任とアイドル時間の課金が回収できません。
失敗パターンとして多いのは、割引を検討せずオンデマンドのまま常時稼働させて単価を取りこぼす、新シリーズに継続利用割引が効くと思い込んで見積もりを外す、停止済みVMのディスクや外部IPを放置して課金を垂れ流す、下り・リージョン間通信を意識せず転送料を積み上げる、GPU付きVMがメンテナンスで止まる前提を設計に入れていない、といった構成です。稼働の性格に割引を割り当て、不要リソースを棚卸しし、通信を局所化する前提で組めば、Compute Engineの自由度を過剰投資なしに使えます。要件がCloud Runで足りるなら、無理にVMを持つ必要はありません。
よくある質問
Compute Engineの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。
Compute EngineとAmazon EC2は何が違いますか？
どちらもクラウド上でOSを自分で握る仮想マシンを提供するIaaSで、VMを直接運用するという使い勝手は共通です。違いはマシンタイプの体系や割引の仕組み、周辺サービスとの連携先で、Compute EngineはGoogle CloudのVPC・永続ディスク・Cloud Load Balancingと、EC2はAWSのVPC・EBS・ELBと統合します。Compute Engineには申請不要の継続利用割引やカスタムマシンタイプがある点も特徴です。選定は、既存インフラがGCPかAWSか、チームの習熟がどちらへ寄っているかで決めるのが実務的です。
Compute Engineの料金はどう決まりますか？
基準は稼働に対する秒単位（1分の最低課金）のオンデマンド料金で、ここへ3系統の割引が乗ります。月内で長く動かすほど自動で効く継続利用割引（対象シリーズのみ・最大30%）、1年・3年の確約でリソースベース最大55%（メモリ特化型は最大70%）になる確約利用割引、中断を許容する代わりに最大91%安いSpot VMです（2026年9月時点）。これとは別に永続ディスクなどのストレージ費、ロードバランサ、下り・リージョン間通信のデータ転送料が積み上がるため、VM単価だけでなく付帯コストまで含めて見積もります。
Compute Engineは無料で使えますか？
無料枠があります。e2-micro 1台を月あたり、米国のus-west1・us-central1・us-east1のいずれかで使え、標準永続ディスク30GB・月も無料枠の対象です。東京リージョンは対象外なので、日本リージョンで試すなら新規アカウント向けの無料トライアル（300ドル分のクレジットを90日間）を使います。無料枠を超えた分や対象外のリージョン・マシンタイプは通常料金になるため、検証後はVMとディスクの削除まで行ってください。
事前定義マシンタイプとカスタムマシンタイプはどちらを選ぶべきですか？
標準的なvCPUとメモリの比率で足りるなら事前定義タイプが割安です。ワークロードがメモリ偏重やCPU偏重で、事前定義だと片方が過剰になる場合は、N4・N2・E2などの対応シリーズでカスタムマシンタイプを使い、vCPUとメモリを実測値へ刻むと余剰への支払いを削れます。ただしカスタムには一律の追加料金が乗るため、実測で偏りが明確なときにカスタムを選ぶのが基本です。
ライブマイグレーションとは何ですか？
Googleがホスト側の計画メンテナンス（ハードウェア更新やパッチ）を行う際に、稼働中のVMを別の物理ホストへ無停止で移す仕組みです。ホストメンテナンスポリシーをMIGRATEにしたVMが対象で、メンテナンスのたびにVMを落とす必要がなくなります。ただしGPU付きVM、Cloud TPU、ベアメタル、Spot VMなどは対象外のため、可用性はVMのゾーン分散やロードバランサ、マネージドインスタンスグループの自己修復と合わせて設計します。
なお、オートスケールはマネージドインスタンスグループ（MIG）で実現でき、設定コマンドは本記事のgcloud手順の章に載せています。
関連記事
- IaaSとは？PaaS・SaaSとの違いと責任共有モデル・採用判断：Compute Engineが属する提供モデルの上位概念
- 仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで：Compute Engineが提供する実体＝VMの基礎
- 仮想化技術とは？種類・仕組みからサーバー仮想化の採用判断まで：VMを成り立たせるハイパーバイザーの仕組み
- Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断：AWS側の同等IaaSと迷ったときの比較軸
- Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金：VMを持たずコンテナを動かす選択肢との使い分け
- Google Kubernetes Engine（GKE）とは？運用モードと料金・EKSとの使い分け：Compute Engineをノードに使うマネージドKubernetes
- AWS・Azure・Google Cloudの違いを比較｜シェア・料金・無料枠と選定基準：クラウド3社の選定から入りたい場合
