GCPコストをCUDs、Spot VM、BigQuery Editions、Active Assist、Cloud Storage Autoclassで最大70%削減する実践ガイド。月$40Kから$1.8M規模のGCPアカウント8社で使ったgcloudコマンド、実測パーセンテージ、比較表を余さず公開します。
最終更新: 2026年8月29日
GCPコスト最適化とは、Committed Use Discounts（CUDs）、Spot VM、BigQuery Editions、Cloud Storage Autoclass、Active Assistレコメンダーを組み合わせて、Google Cloudの請求書を最大70%削減するFinOpsの実践フレームワークだ。正直な話、私が過去2年で担当した8つのGCPアカウント（月額$40Kから$1.8M規模）で共通していたのは、Flex CUDsを未購入、Spot移行対象のバッチワークロードがオンデマンド、BigQueryは全プロジェクトがオンデマンドクエリ課金という3点セットの浪費だった。本稿ではその3点を含む10の削減レバーを、gcloudコマンドと実測値付きで解説していく。
私が最初に監査に入るとき、真っ先に確認するのはBilling Reports → 「割引タイプ別」ビューだ。ここで「オンデマンド」の比率が80%を超えていたら、CUDs購入の余地がまだ数百万円分は眠っていると考えていい。GCPの主要な浪費パターンは驚くほど定型的で、次の6つに集約される。
これらのパターンはGoogle Cloud Architecture Framework のコスト最適化ピラーにも列挙されているが、公式ドキュメントは「原則」レベルで止まる。以下では、gcloudコマンドと実測パーセンテージまで踏み込んで、それぞれの削減レバーを解説していく。同様のフレームワークをAWSで実践したい方は、AWSコスト最適化 完全ガイド2026を参照してほしい。
CUDsはGCPコスト削減の主砲だ。2026年時点で、Compute Engineには2種類のCUDsが存在する。Resource-based CUDsはマシンタイプ×リージョンに固定され、1年で最大37%、3年で最大55%オフ。Flex CUDs（Flexible CUDs）は「時間あたりの支出額」にコミットし、マシンファミリー・リージョン横断で柔軟に適用され、1年28%、3年46%オフになる。
安定したベースラインが常時同じマシンタイプで動いているワークロード（例：本番APIサーバー、常時起動のCloud SQL）は、割引率の高いResource-based CUDsが向いている。一方、リージョンをまたぐHAデプロイ、マシンファミリーを頻繁に切り替えるCI/CDやデータ処理には、Flex CUDsのほうがミスマッチリスクが低い。私は原則としてベースラインの60〜70%をFlex CUDs、残りをオンデマンドまたはSpotで賄う設計にしている。過去に「安全策」と称して90%コミットしたら、翌四半期の減産で使い切れず、逆に損したことがある。反省。
gcloud compute commitments create flex-cud-prod-2026 \
--region=asia-northeast1 \
--plan=twelve-month \
--type=general-purpose \
--resources=type=vcpu,amount=200 \
--resources=type=memory,amount=800 \
--auto-renew
# 3年のFlex CUD（46%オフ）：本番の安定分に推奨
gcloud compute commitments create flex-cud-prod-3yr \
--region=asia-northeast1 \
--plan=thirty-six-month \
--type=general-purpose \
--resources=type=vcpu,amount=150 \
--resources=type=memory,amount=600
2026年時点で、Cloud SQL、Cloud Spanner、Cloud Run（vCPU/Memory）、Memorystore（Redis Enterprise含む）、AlloyDB、VMware Engineにも独立したCUDsが用意されている。特にCloud SQL for PostgreSQLはenterprise plus editionと3年CUDを組み合わせると、標準edition＋オンデマンド比で55%以上安くなる。マネージドDBは往々にして請求書の20〜30%を占めるので、ここを取り逃すと最適化の効果が半減する。
Spot VMは2022年にPreemptible VMの後継として登場し、24時間制限が撤廃され、価格も動的化された。マシンタイプとリージョンによって60〜91%割引で、私がus-central1のC3D-standard-16で計測した割引率は平均79%だった。中断は30秒前のシャットダウンシグナルで通知されるので、実装側でGracefulな終了処理を書いておけばよい。
gcloud container node-pools create spot-pool \
--cluster=prod-cluster \
--region=asia-northeast1 \
--spot \
--machine-type=c3d-standard-8 \
--num-nodes=3 \
--enable-autoscaling --min-nodes=0 --max-nodes=50 \
--node-taints=cloud.google.com/gke-spot=true:NoSchedule \
--node-labels=workload-class=interruptible
そしてDeployment側で明示的にtolerationとnodeSelectorを指定する。
apiVersion: apps/v1
kind: Deployment
metadata:
name: batch-worker
spec:
replicas: 20
template:
spec:
tolerations:
- key: cloud.google.com/gke-spot
operator: Equal
value: "true"
effect: NoSchedule
nodeSelector:
workload-class: interruptible
terminationGracePeriodSeconds: 25 # Spotの30秒シャットダウンより短く
containers:
- name: worker
image: gcr.io/my-project/batch-worker:v42
2023年6月にリリースされたBigQuery Editionsは、2026年までにオンデマンド課金の対抗馬として完全に定着した。Standard / Enterprise / Enterprise Plusの3階層があり、スロットベースの課金にオートスケーリング＋コミットメント割引を組み合わせる。私が担当した広告テック企業（月次BigQuery費用$62K）では、Enterpriseエディションへの切替＋100スロットの1年コミットで月$24Kまで下がった（約61%減）。CFOに報告した瞬間の空気は、今も忘れない。
| 特徴 | オンデマンド | Standard | Enterprise | Enterprise Plus |
|---|---|---|---|---|
| 課金モデル | スキャン量($6.25/TB) | スロット時間 | スロット時間 | スロット時間 |
| マテリアライズドビュー | × | × | ○ | ○ |
| BigQuery ML | ○ | × | ○ | ○ |
| CMEK / VPC-SC | △ | × | ○ | ○ |
| クロスリージョンレプリカ | × | × | × | ○ |
| 1年コミット割引 | - | -20% | -20% | -20% |
| 3年コミット割引 | - | -40% | -40% | -40% |
-- 直近30日のスロット消費（時間帯別のピークを掴む）
SELECT
TIMESTAMP_TRUNC(creation_time, HOUR) AS hour,
SUM(total_slot_ms) / (1000 * 3600) AS slot_hours_avg
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
GROUP BY hour
ORDER BY slot_hours_avg DESC
LIMIT 100;
詳細な要件比較はBigQuery Editionsの公式ドキュメントにまとまっている。特にBI EngineやData Governance機能が必要ならEnterprise Plusに寄せる意味がある。
Cloud Storageのストレージクラスは Standard / Nearline / Coldline / Archive の4層で、価格差は最大22倍（Standard $0.020/GB/月 vs Archive $0.0012/GB/月、us-central1）。Autoclassは各オブジェクトのアクセスパターンを監視し、30日/90日/365日のしきい値で自動的に下位クラスへ落とす仕組みだ。オブジェクトあたり月$0.0025のオーバーヘッドを許容できるなら、ライフサイクルルールを手書きするより運用が楽になる。
# 既存バケットでAutoclassを有効化（Archiveまで到達させる）
gcloud storage buckets update gs://my-data-lake \
--autoclass-terminal-storage-class=ARCHIVE
# ライフサイクルルール併用パターン：410日以上のオブジェクトを削除
cat > lifecycle.json <<EOF
{
"lifecycle": {
"rule": [
{"action": {"type": "Delete"},
"condition": {"age": 410, "matchesPrefix": ["logs/"]}}
]
}
}
EOF
gcloud storage buckets update gs://my-data-lake --lifecycle-file=lifecycle.json
クラウド請求書で最も見落とされがちなのが下り（Egress）料金だ。GCPの標準下り料金はインターネット向けで$0.12/GB（北米、月100TBまで）、大陸間で$0.05〜$0.19/GB。私が診断した中規模SaaSでは、Egressだけで月間$18Kが飛んでいて、以下の5つを適用したら$7Kまで下がった。
下り料金の詳細な体系はVPCネットワーク料金の公式ページを確認しよう。マルチクラウド環境で下り料金を統合管理したい方は、Azureコスト最適化 完全ガイド2026のネットワーク設計セクションも参考になる。
Active Assistは、GCPが提供するAIベースのレコメンダー群だ。Recommender APIを叩けば、アイドルVM、オーバープロビジョニングされたVM、未使用のPersistent Disk、放置されたStatic IP、非効率なIAMロールなどが構造化データで取れる。私は毎週月曜に以下のスクリプトをCloud Schedulerで走らせ、Slackへ集約している。
# アイドルVMのレコメンデーションを一覧化（全プロジェクト・全リージョン）
for project in $(gcloud projects list --format="value(projectId)"); do
for region in asia-northeast1 us-central1 europe-west1; do
gcloud recommender recommendations list \
--project=$project \
--location=$region \
--recommender=google.compute.instance.IdleResourceRecommender \
--format="table(name.basename(), primaryImpact.costProjection.cost.units, description)"
done
done
# オーバープロビジョニングVMのレコメンデーション（Rightsizing）
gcloud recommender recommendations list \
--project=my-prod \
--location=asia-northeast1 \
--recommender=google.compute.instance.MachineTypeRecommender \
--format=json | jq '.[] | {name: .name, savings: .primaryImpact.costProjection.cost.units}'
私の経験則では、Active Assistの推奨をそのまま適用するだけでCompute Engine費用の12〜18%が消える。ただし本番のミッションクリティカルVMは、レコメンデーションが「7日間の観測ベース」なので、月次バッチのピークを見落とすことがある。適用前に必ずCloud Monitoringのカスタムメトリクスで28日分の負荷を確認する。ここでケチると、翌月にオンコール担当が呼び出される。
GKEには「Standard」と「Autopilot」の2モードがある。Autopilotはノードのプロビジョニング、Bin-packing、ノードプールのスケーリングを完全にGoogleが管理し、Pod単位のvCPU・Memory・エフェメラルストレージで課金される。ノードが常にBin-packingされるため、Standardクラスタで発生しがちな「50%しか使っていないn2-standard-4が20台」といった浪費が起きにくい。
# Autopilotクラスタを作成
gcloud container clusters create-auto prod-autopilot \
--region=asia-northeast1 \
--release-channel=regular
# 既存Standardクラスタで、Cluster AutoscalerとNode Auto-Provisioningを併用
gcloud container clusters update prod-cluster \
--enable-autoprovisioning \
--min-cpu=10 --max-cpu=500 \
--min-memory=40 --max-memory=2000 \
--autoprovisioning-scopes=https://www.googleapis.com/auth/cloud-platform
削減後のリバウンドを防ぐには、Cloud Billing側で予算・アラート・異常検知を三段構えで仕込む。私はプロジェクトごとに月次予算を切り、50% / 90% / 100% / 120%のしきい値でPub/Sub → Cloud Functions → Slackに通知している。さらに2024年からGAされたCost Anomaly DetectionをすべてのBillingアカウントで有効化しておくのが、2026年の常識だ。
# 予算作成（gcloud alpha billing budgets）
gcloud billing budgets create \
--billing-account=012345-ABCDEF-678901 \
--display-name="prod-monthly-budget-2026" \
--budget-amount=15000USD \
--threshold-rule=percent=0.5 \
--threshold-rule=percent=0.9 \
--threshold-rule=percent=1.0 \
--threshold-rule=percent=1.2,basis=forecasted-spend \
--filter-projects=projects/my-prod-project \
--notifications-rule-pubsub-topic=projects/my-billing/topics/budget-alerts
異常検知はプロジェクト単位で「日次支出が過去14日平均から3σ以上乖離」した場合に自動アラートが飛ぶ。閾値ベースの予算アラートよりも早く「今日、いきなり請求書が2倍になっている」に気付ける。
私の実測ベースでは、未着手のワークロードから始めた場合、6か月で35〜55%、12か月で55〜70%削減が現実的です。CUDs購入 + Spot VM移行 + BigQuery Editions切替の3点セットだけで、平均40%は取れます。
Flex CUDsは「時間あたりの支出額」にコミットし、マシンファミリー・リージョン横断で自動適用されます（3年で最大46%オフ）。Resource-based CUDsはマシンタイプ×リージョンに固定される代わりに、割引率が高い（3年で最大55%オフ）です。ベースラインが安定していればResource-based、動的な環境ならFlexを選びます。
Spot VMはPreemptible VMの後継です。2022年以降、24時間で強制終了される制約がなくなり、価格も動的に変動するようになりました。API的にはPreemptibleフラグを立てても内部でSpot VMとして扱われますが、新規実装ではSpotフラグを使うべきです。
月間のスキャン量が概ね5TBを超えたら、Standard Editionのオートスケーリング＋ベースラインスロットのほうが安くなるケースが多いです。$6.25/TBのオンデマンドはスパイク型の少量クエリには向いていますが、定常的なETLパイプラインではEditions＋1年コミットで40〜50%は下がります。
単一ツールでの効果順は、(1) Active Assistレコメンダー（無料、即効性）、(2) Cloud Billing Export → BigQuery → Looker Studio（可視化）、(3) Recommender APIをTerraformでプログラマティックに適用する自動化基盤、です。まずレコメンデーションを毎週レビューする運用をルーチン化するのが第一歩です。