Google Cloudのコスト削減は、なにから始めるか

Google Cloudの請求が増えると、Cloud RunのCPUを減らすか、確約利用割引を買うかという話から始まりがちです。僕は、どちらからも始めません。請求の内訳と、費用について決める人が分からないまま設定を変えても、削減できた金額を説明できず、同じ費用がまた増えるからです。

Google Cloudのコスト削減は、請求を同じ条件で見られるようにし、費用の責任者を決めるところから始めます。次に上位のサービスとSKUを特定し、未使用リソースの削除、ライトサイジング、設計の見直し、効果測定へ進みます。確約利用割引を検討するのは、削減後にも残る利用量が分かってからです。

Google Cloudのコスト削減は、請求の可視化と責任者決めから始めます

最初にCloud BillingのReportsを開きます。Google Cloudの公式資料にある通り、期間を指定し、プロジェクト、サービス、SKU、ロケーションなどで費用を分けられます。僕なら、請求が確定した直近月と前月を同じ条件で表示し、増減を保存します。

請求書との照合にはCost tableを使います。Cost tableは請求月ごとの費用をプロジェクト、サービス、SKU、利用モデルまで掘れる画面です。日々の利用傾向を見るReportsと、請求書へ合わせるCost tableを混ぜず、比較に使った期間と画面名を記録します。

プロジェクト数が少なければ、最初は標準画面で十分です。複数チームへの配賦や長期集計が必要になった段階で、Cloud BillingデータのBigQueryエクスポートを検討します。

請求を見えるようにしたら、費用の責任者を決めます。財務担当者は請求書と総額を確認し、サービス責任者は利用を続けるか判断し、クラウドを操作する担当者は変更と復旧を担います。上位の費用に名前と次回確認日が付いていない状態は残しません。

AWSも併用する場合は画面を統合せず、クラウド名、費用、責任者、確認日を月次台帳でそろえます。AWSのコスト削減手順も同じ項目で進めます。

予算アラートも早い段階で設定します。ただし、Google Cloud公式は、予算に支出上限を設ける機能がないと説明しています。通知を受け取る人、調査を始める人、利用停止を決める人まで決めて、初めて運用になります。

上位のサービスとSKUから削減対象を特定します

請求総額だけを見ても、削減対象は選べません。ReportsかCost tableでサービス別の金額を大きい順に並べ、上位のサービスをSKUまで掘ります。サービス名がCompute Engineでも、請求を作っているSKUが仮想マシン、ディスク、IPアドレス、データ転送のどれかで、取るべき対応は変わります。

金額だけでなく、前月からの増加額と利用量も見ます。顧客や処理件数が増えて費用も増えた場合は、削るより先に一件あたりの費用を確認します。割引やクレジットが変わっただけなら、システム設定を触っても同じ差額は出ません。

上位SKUごとに、対象プロジェクト、利用目的、担当者、費用が増えた理由を一文で残します。理由が分からない項目には調査担当と回答日を置きます。会議の場で全サービスを眺め続けるより、上位三つへ担当者を割り当てるほうが削減作業は進みます。

FinOps hubでは、アイドルリソースの停止、ライトサイジング、構成変更、確約利用割引などの候補を確認できます。推奨金額は将来の請求減少を保証する実績ではありません。請求の上位SKUと一致する候補を探すために使い、事業上の必要性と復旧方法は人が確認します。

未使用を削除してから、ライトサイジングを進めます

上位SKUの対象が分かったら、使っていないプロジェクト、仮想マシン、永続ディスク、IPアドレスなどを確認します。Google CloudのRecommenderにもアイドル状態のディスクやIPアドレスを探す機能がありますが、推奨が出た事実だけで削除しません。

削除前に、作成目的、最後に使った人、依存先、保存すべきデータ、復旧方法、承認者を確かめます。停止できるリソースなら、先に止めて影響を監視します。仮想マシンを消してもディスクや外部IPアドレスが残れば課金は続くため、関連リソースと翌月のSKUまで確認します。

稼働中のリソースは、未使用分を片付けた後にライトサイジングします。CPUの平均使用率だけで小さくせず、メモリ、応答時間、エラー率、バッチの終了時刻、月末処理、障害時に必要な余力を見ます。推奨結果の観測期間に繁忙日が含まれていなければ、必要な容量まで削る危険があります。

変更前には、維持する性能と戻す条件を決めます。影響の小さい環境や一部の処理で試し、費用と性能を同じ期間で比べます。安くなっても顧客の待ち時間や失敗件数が増えた変更は、コスト削減とは呼べません。

請求と性能を同じ表で判断できる担当者がいない場合は、外部の技術責任者へ調査と変更管理を任せる方法もあります。

ログ、ネットワーク、BigQuery、Cloud Runは設計まで確認します

未使用削除とライトサイジングを終えても上位SKUが残る場合は、使い方と設計を確認します。Google Cloudでは、ログ、データ転送、BigQuery、Cloud Runの費用が構成や処理方法に連動します。ただし、四つのサービスがすべての会社で高いわけではありません。請求の上位に出た項目だけを調べます。

Cloud Loggingでは、保存量を作っているログ名と送信元を確認します。Google Cloudの公式コスト最適化ガイドは、価値の低いログをシンクの除外フィルタでログバケットへ保存しない方法を案内しています。デバッグログや高頻度の正常系ログを候補にできますが、障害調査、セキュリティ、法令や契約上の保存要件を先に確認します。除外できない監査ログもあるため、保持期間の短縮と保存対象の除外を同じ変更として扱いません。

ネットワークでは、SKU名だけでなく、送信元、送信先、リージョン、通信経路、転送量を確認します。Cloud Runとバックエンドを同じリージョンへ置く方法や、Serverless VPC Access connectorからDirect VPC egressへ替える方法は、Cloud Runの公式コスト最適化ガイドにも記載されています。データの所在、障害時の構成、遅延を確認せず、転送料だけを理由にリージョンを移しません。

BigQueryでは、オンデマンド料金と容量料金を分けます。オンデマンド料金なら処理バイト数を見て、必要な列だけを読む、パーティションを絞る、クラスタリングを使う、maximum bytes billedで上限を置く方法を検討します。容量料金なら、クエリの処理量だけでなく予約したスロットと自動スケーリングを確認します。BigQueryの公式コスト管理手順を読み、料金モデルを変える理由、決裁者、見直す条件は技術の意思決定を組織へ残す方法と同じ形式で記録します。

Cloud Runでは、リクエストベースとインスタンスベースの課金設定、最小・最大インスタンス数、CPUとメモリ、同時実行数を確認します。アクセスが断続的なサービスと、安定した負荷やバックグラウンド処理があるサービスでは、適した課金設定が違います。最小インスタンス数をゼロへ戻す、CPUを減らす、同時実行数を増やすという変更も、起動時間、遅延、メモリ、並列処理の安全性を測ってから採用します。

設計変更には実装と移行の費用もかかります。削減対象のSKU、減らす利用量、変更作業、性能条件、復旧手順、回収までの期間を一枚へ書き、月額だけで採否を決めません。

効果を測定してから、確約利用割引を検討します

変更前に、対象のプロジェクト、サービス、SKU、利用量、金額、性能指標を記録します。変更日と担当者も残し、Cloud Billingへデータが反映された後に同じReportsの条件で比べます。請求データには遅れがあり、変更直後の当月値だけでは効果を確定できません。

総額だけでなく、リクエスト、顧客、分析ジョブなど事業に合う単位あたりの費用も見ます。利用が増えた月に総額が上がっても、一件あたりの費用が下がっている場合があります。反対に、総額が下がっていても売上や利用件数が大きく落ちたなら、設定変更だけの成果にはできません。

僕は、割引購入から始めません。確約利用割引は、使わなかった分を後から返せる割引券ではなく、対象リソースや支出について一年または三年の利用を約束する契約だからです。Google Cloudの公式資料でも、期間中の月額料金は解約できず、実際の利用量にかかわらず適用されると説明されています。

未使用削除、ライトサイジング、設計変更の効果を測り、事業を続ける限り残る利用量が見えてから、確約利用割引の推奨を開きます。標準の推奨は直近30日間の利用履歴を分析するため、季節変動、移行予定、サービス終了、新規開発の計画を別に重ねます。割引率より、対象サービス、リージョン、請求先アカウント、期間、確約量を確認します。

2026年7月11日時点では、Cloud Run向けの新しい確約にはサービス固有の確約ではなくCompute flexible CUDを使います。対象外のGPUやネットワーク費用まで割引される前提にはできません。制度と対象SKUは変わり得るため、購入時点の確約利用割引の公式仕様で確認します。

明日はCloud BillingのReportsを開き、直近の確定月をサービス別に並べてください。上位三つをSKUまで掘り、各項目へ費用の責任者と次回確認日を書きます。最初の日に買うものはありません。請求の大きい場所と、判断する人を同じ表へ置くところから始めます。