Google Cloud CUDの4種類と並行購入を完全解説

本記事の前提: 本記事は 2026年5月20日時点 の公式ドキュメントに基づいて執筆しています。 Google Cloud の仕様（特にCUDの対象サービス・割引率・モデル統合）は頻繁に更新されるため、 実際にCUDの購入や試算を行う際は必ず Google Cloud 公式ドキュメント で最新情報をご確認ください。

この記事で分かること

• Google Cloud CUD（Committed Use Discounts）は「リソースベース vs フレキシブル」の2種類ではなく 4種類 に分類される
• リソースベースCUDとフレキシブルCUDは 並行購入が可能 で、 公式が適用順序を明示している
• 2026年1月21日より、 spend-based CUDモデルの対象拡大が開始（既存アカウントはオプトインで切替可能）
• プロジェクト間でのCUD共有・リージョン制約はCUDの種類によって異なる

Google Cloud のCUD（Committed Use Discounts）について、 自分は長らく「リソースベースとフレキシブルの2種類がある」と理解していました。 比較表を作って整理した気になっていたし、 同僚と議論するときもその枠組みで話していた。

ところが先日、 Cloud SQL と BigQuery を含む複数サービスのCUDを設計する機会があり、 Google Cloudの公式ドキュメント（cloud.google.com 配下の各CUDページ）を1ページずつ読み下した ところ、 自分の認識がかなりズレていることに気づきました。 Google Cloud CUDは2種類ではなく 4種類 あり、 しかも 2026年1月に大きな仕様変更が入っていた。 さらに「リソースベースとフレキシブルは並行購入可能」「プロジェクト間でCUDが共有される」など、 コスト最適化を考えるうえで重要なのに見落としやすい仕様がいくつもありました。

この記事は、 Google Cloudの公式CUDドキュメントを横断調査した一次情報のみを根拠に、 Google Cloud CUDの仕様を網羅的に整理したものです。 同じくGoogle Cloudのコスト最適化に関心がある方の参考になればと思います。

読み終えたあと、 こんな問いに自分の言葉で答えられるようになっていれば嬉しいです。

• Google Cloud CUDの4種類とは何か。 各種類の対象サービスと割引率はどう違うのか。
• リソースベースCUDとフレキシブルCUDを並行購入するとどうなるのか。 適用順序は？
• 同じBilling Account内のプロジェクト間でCUDはどう共有されるのか。 リージョン制約はあるのか。
• 2026年1月のspend-based CUDモデル統合とは何だったのか。 既存契約への影響は？

Google Cloud CUDの全体像: 4種類の分類

まず結論から。 Google CloudのCUDは公式上、 少なくとも以下の 4種類 に分類されます。

この表を最初に見たとき、 自分が一番驚いたのは ③ Spend-based CUD の対象サービスの広さ でした。 Cloud SQL もBigtable もSpanner も全部含まれていて、 Compute Engine だけがリソースベースの対象。

これまで自分は「リソースベースの対象サービスは Cloud SQL / Memorystore / Compute Engine / BigQuery」と理解していたのですが、 これは完全に誤りでした。 実際にはこれらは 別々のCUD種類 に分かれていて、 Cloud SQL と Memorystore は費用ベース、 BigQuery は Capacity Commitments、 リソースベースは Compute Engine 専用、 という構造です。

公式の総合ページにこの分類が明記されています。

リソースベースのコミットメントは Compute Engine を対象とし、 費用ベースのコミットメントは支出が発生する各種サービスを対象とします。
（確約利用割引 | Google Cloud Documentation）

「2種類しかない」という認識が広まっているのは、 おそらく Compute Engine の世界に閉じて議論したときに「リソースベース vs フレキシブル」の選択肢が主役になるからだと思います。 ただ、 Compute Engine だけしか使っていない構成は現実には少なくて、 Cloud SQL や BigQuery も並行で使うケースが多い。 そうなると「2種類だけ」の前提では正しいCUD設計ができません。

Google Cloud CUD 4種類の詳細仕様

① Resource-based CUD（リソースベース）

Compute Engine 専用のCUDで、 4種類のなかで 割引率が最も高い のが特徴です。 マシンファミリ単位（N2 / C3 / M3 など）でコミットするため、 安定運用しているVMを長期間使い続ける構成に向いています。

公式記述:

メモリ最適化マシンシリーズには最大 70% の割引、 他のすべてのマシンシリーズには最大 55% の割引が適用されます。
（確約利用割引の概要 | Compute Engine）

割引率の高さと引き換えに、 マシンファミリとリージョンが固定 されるので柔軟性は低めです。 「N1 で買ったCUDを次のリプレイスでN2 に流用」というのはできません。 また GPU・Local SSD は vCPU/メモリとは別建てでコミットが必要です。

GKE 標準モードのワーカーノードは Compute Engine VM なので、 リソースベースCUDが間接的に適用されます。 一方、 GKE Autopilot や Cloud Run は対象外です。

② Flexible CUD（フレキシブル）

Compute Engine / GKE / Cloud Run の 3サービスの支出にまたがって適用 されるCUDで、 マシンタイプやリージョンを横断して使えるのが強みです。 リソースベースより割引率は控えめでも、 構成変更が予想される環境でも無駄なく消化できます。

N1 から N2 への移行があっても継続して適用されますし、 Cloud Run のコンピュート支出にも当てられます。

ここでひとつ重要な疑問があります。 「リソースベースとフレキシブル、 Compute Engine で使うならどちらを買えばいいのか」 。 自分は最初、 Either/Or で選ぶものだと思い込んでいました。 でも公式を読み直すと、 これは誤解でした。 後述しますが、 両方並行購入できる のです。

③ Spend-based CUD（費用ベース）

Compute Engine 以外の 11のサービスを対象とするCUD です。 ここがいちばん認識ズレが起きやすい領域で、 サービスごとに対象リソース・割引率・リージョン制約が微妙に違うのが厄介。

公式の cuds-multiprice ページに対象サービス一覧があります。

次の Google Cloud サービスは費用ベースのコミットメントをサポートしています。
（費用ベースの確約利用割引 | Google Cloud Documentation）

サービスごとに「対象になるリソース」が微妙に違うのが厄介で、 実装時には各サービスの公式CUDページを確認する必要があります。 例えば:

• Cloud SQL: vCPU + メモリ のみ対象。 ストレージ・バックアップ・IPアドレス・ネットワーク Egress・SQL Server ライセンス費は対象外
• Bigtable: ノード時間のみ対象。 ストレージ・バックアップ・ネットワーク転送は対象外
• Firestore: Read/Write/Delete 操作 のみ対象（特殊パターン）
• NetApp Volumes: ストレージ容量 が対象（他と逆転、 唯一ストレージ対象）

「同じ費用ベースCUDだから」と一括りにすると、 試算が合わなくなります。 サービスごとに公式ページで対象軸を確認するのが必須です。

なお、 2026年1月21日以降の新モデルでは、 公式の cuds-multiprice ページが費用ベースCUDの対象として Compute フレキシブル CUD / GKE / Cloud Run / BigQuery を含む形でリストアップしており、 「費用ベースCUDの傘」 が従来よりも広く解釈される可能性があります。 本記事では従来からの「個別購入される費用ベースCUD」として独立してコミットできる 11サービス を主軸に整理していますが、 新モデルでは分類の境界が薄まりつつある点は念頭に置いてください。

費用ベースCUDの11サービスごとの対象範囲・割引率の違いについては、 別記事 Google Cloud 費用ベースCUD 11サービス公式仕様の徹底比較 でサービス別に整理しています。

④ Capacity Commitments（BigQuery専用）

BigQuery 専用のCUDで、 他の3種類とは 完全に別系統 です。 コミット単位がスロット時間（slot-hour）で、 USD/時ではないこと、 そしてEditionによってCUDの可否が分かれることが大きな違い。

Edition別のCUD対応:

注: BigQuery のスロット料金体系は Editions モデル導入以降、 用語と仕様が継続的に更新されています。 「Flex Slots」という旧用語は現在「自動スケーリング スロット」に置き換わりつつあり、 具体的な割引率も公式 BigQuery 料金ページ で最新の数値を確認してください。

注意点はいくつかあります。 オンデマンド課金（TiBスキャン課金）はそもそもCUDの対象外で、 まず Capacity-based pricing（Editions）への切り替えが前提になります。

ベースライン算出ロジックも他のCUDと違って、 公式は「日次スロット使用量の p5 × 0.8 → 50スロット刻みで切下げ」を推奨しています。 Compute Engine 系の「日次最小値 × 0.8 / 24」とは別ロジックなので、 BigQuery の試算は別スクリプトで組む必要があります（自分はここで一度詰まりました）。

CUDの対象範囲とSKUフィルタリング

ここまで4種類のCUDを見てきましたが、 全種類に共通する 大原則 があります。 CUDが効くのはコンピュートリソースに対してのみ、 ということです。 ストレージ・ネットワーク・ライセンス費・バックアップなどは、 たとえ同じサービスの請求項目に並んでいても、 CUDの割引対象から外れる。

自分はCUD調査をするまで、 ここをかなり雑に理解していました。 「Cloud SQL でCUDを買えば請求書全体が安くなるんでしょ」程度の認識で、 「コンピュートのみが対象」という縛りに気を払っていませんでした。 でも実際にはサービスごとに「対象になるリソース」が異なり、 それを正確に把握しないと試算が10〜20%ズレます。

サービスごとの「コンピュート」の定義は次の通りです。

太字の2サービスが特殊で、 Firestore は「コンピュート」ではなく「操作回数」が対象、 NetApp Volumes に至っては「ストレージ」が対象という、 他と完全に逆転した構造をしています。 この2つを「他のサービスと同じだろう」で扱うと試算を派手に外します。

CSV試算時のSKUフィルタリング

CUDの試算をするときは、 Cloud Console から Billing CSV をダウンロードして集計するパターンが多いと思います。 そのとき重要になるのが、 「対象外SKUを除外する」フィルタリング作業 です。

例えば Cloud SQL のCSVには、 vCPU / メモリ の課金行に混じって、 ストレージ / バックアップ / Network Egress / IPアドレス / ライセンス費の行も並びます。 すべてを合算してベースラインを出すと、 「現状コスト」が CUD 対象外の支出も含んだ過大値になり、 算出される削減額がおかしくなる。

実務的には、 SKU description（SKU の説明）列に対して以下のような 除外キーワード で機械的にフィルタするのが効率的です。

除外キーワード（Cloud SQL の場合）:
Storage / Backup / Network / IP / Egress / Licens / Shared

Licens を License ではなく短縮形で指定するのは、 「Licensing Fee for Windows Server」のような表記にも対応するため。 自分は最初 License（単数形）で書いて、 「Licensing」 が引っかからずに $1,500 分のWindows ライセンス費がベースラインに残り続けたミスをしました。 SKU除外辞書は「短縮形で広めに引っかける」のが正解です。

サービスごとの推奨除外キーワードは公式CUDページに明示されている場合が多いので、 試算前に必ず確認することをおすすめします。

プロジェクト間でのCUD共有とリージョン制約

CUDを設計するときによく出てくるのが「同じBilling Accountに紐づく複数プロジェクトがあるとき、 CUDはプロジェクトごとに買う必要があるのか」という疑問です。

公式の答えは 「同一Billing Account内なら、 全プロジェクトに自動適用される」 です。 各サービスの公式CUDページに繰り返し書かれています。

CUD の割引は、 同じ Cloud Billing アカウントに紐づくすべてのプロジェクトの対象使用量に適用されます。
（確約利用割引 | Google Cloud Documentation）

これは4種類すべてに共通の仕様。 つまり Billing Account単位でCUDをまとめて購入すれば、 配下の複数プロジェクトに対して自動的に割引が分散適用される。 プロジェクトごとに個別購入する必要はありません。

ただし リージョン制約は種類によって違う ので注意が必要です。

CUDを設計するときは、 マルチリージョン構成を確認したうえで「同じBilling Accountだから1本で済む」「いや、 リージョンごとに別々に買う必要がある」を判定する必要があります。

リソースベースCUDとフレキシブルCUDの並行購入

ここがいちばん見落とされやすいポイントです。 自分も最初は「リソースベースとフレキシブルはどちらか1つを選ぶもの」と思い込んでいました。 でも公式を読むと、 両方並行購入が認められている と明記されています。

リソースベースのコミットメントとコンピューティング フレキシブル コミットメントの両方を購入すると、 Cloud 請求先アカウントのプロジェクトの Compute Engine リソースをカバーできます。
（確約利用割引の概要 | Compute Engine）

しかも 適用順序まで明示 されていて、 リソースベース（service-specific）が先に適用され、 そこで吸収しきれなかった超過分にフレキシブルが当たる仕組みです。

Google Cloud はまずリソースベースのコミットメントを利用し、 結果として得られるすべてのリソースベースの CUD を対象となる 1 時間あたりの使用量に適用します。
（確約利用割引の概要 | Compute Engine）

これが理解できると、 Compute Engine 中心の構成でのCUD設計の選択肢が一気に拡がります。

2層構造でイメージするとシンプルです。 1層目に リソースベースCUD を置いて Compute Engine の安定運用部分（毎日確実に使う最低稼働量）を最大70%の高割引率で確保し、 そこで吸収しきれない変動分・GKE Autopilot・Cloud Run の使用を、 2層目の フレキシブルCUD が17〜46%の割引率で柔軟にカバーする、 という構造です。

例えば、 Compute Engine で常時稼働している部分の vCPU/メモリ にリソースベースCUDをコミットしつつ、 マシンタイプ変更や Cloud Run のスポット利用にはフレキシブルCUDで吸収する、 という二層構造を組めます。 「リソースベースの高割引率」と「フレキシブルの柔軟性」の両方を取れるので、 単独購入よりもCUDの吸収効率が上がります。

自分はこの仕様を知らなかったとき、 「Compute Engine 中心ならリソースベース一択、 でもCloud Run も使ってるからフレキシブルだけ買おう」のように Either/Or で考えて、 削減できるはずのコストを取りこぼしていました。 並行購入が前提だと知ってからは、 ハイブリッド戦略を採用する場面が増えました。

2026年1月のspend-based CUDモデル統合（仕様変更点）

CUDの仕様で、 2026年1月にひとつ大きな変更がありました。 公式の Cloud Billing リリースノートに記載があります。

要点は次の通りです。

• 2026年1月21日 から、 新しい spend-based CUD モデルが Google Cloud 全体で展開・拡大開始
• 既存アカウントは オプトイン形式 で新モデルに切替可能。 早期オプトイン開始日は 2025年7月15日
• 旧モデルでは「クレジット方式」（CUDの割引分が後からクレジットとして付与される）だったのが、 新モデルでは 「ディスカウント方式」（請求書の単価が直接安くなる）に変わった
• 新モデルでは フレキシブルCUD も費用ベースCUDモデルに統合 され、 対象範囲が拡大した

公式記述を引用します。

このコンピュート フレキシブル CUD はすべての Cloud Billing アカウントで利用可能になり、 2026 年 1 月 21 日より改善され、 拡大されますが、 早期にオプトイン することも可能です。
（費用ベースの確約利用割引 | Google Cloud Documentation）

ここで自分が気になったのは「改善され、 拡大される」という表現です。 旧フレキシブルCUDは「Compute Engine / GKE / Cloud Run のCPU+メモリ時間」が対象でしたが、 spend-based モデル統合後の対象範囲は広がっている可能性があります。

具体的には、 例えば Cloud Run のリクエスト数課金（旧フレキシブルCUDの対象外）が新モデルでは対象内になったのか、 という疑問です。 これについては公式ドキュメントで明示的な記述を見つけられず、 自分の調査範囲ではグレーのままでした。 重要な試算をする前は Cloud Billing 担当者に確認するのが安全です。

実務への影響:

• 既存契約: 2025年7月15日以降は早期オプトインで新モデルへ切替可能。 2026年1月21日以降は新モデルがデフォルト方向で拡大。 切替タイミングは Cloud Billing 担当者と相談するのが安全
• 新規購入: 新モデルで購入される。 請求書には割引額が直接反映される（ディスカウント方式）
• 試算ロジック: 旧フレキシブルCUDの「CPU+メモリ時間ベース」で試算していた既存ロジックは、 新モデルで対象範囲が広がっている可能性があるため、 実データで割引適用範囲を再確認するのが望ましい

CUD購入前に知っておきたい5つのリスク

CUDは「コミットメント割引」という名前のとおり、 1年または3年の期間で支出を確約する契約 です。 割引率にばかり目が行きがちですが、 契約である以上リスクもあります。 自分が調査をやってみて、 ここはちゃんと注意喚起しないとダメだなと思った点をまとめます。

1. 解約・縮小は基本できない

1年/3年コミットは購入後の キャンセル不可 が原則です。 BigQuery の Flex Slots（月単位）だけ例外的に途中解約に近い運用ができますが、 それ以外のCUDは契約期間中に「やっぱり減らします」が効きません。

購入後にコミットメントをキャンセルすることはできません。
（確約利用割引の概要 | Compute Engine）

つまりコミット期間中にプロジェクトが縮小・終了しても、 コミット額は払い続ける義務がある。 「ちょっと多めに買って割引率を最大化しよう」と前のめりにいくと痛い目を見ます。

2. コミット枠未達でも全額支払い

CUDは「使った分が安くなる」のではなく 「コミットした額を必ず支払う」 契約です。 例えば 1時間 $1.0 の支出を3年間コミットしたなら、 実際の利用額が $0.5 だった月でも $1.0/時 × 24h × 30日 ぶんの請求が来ます（割引適用後の単価で）。

過剰コミットの怖いところは、 「使わなかった分が空コストになる」だけでなく、 契約期間の長さ × 過剰額 で損失が膨らむ点です。 3年契約で月10万円の過剰コミットなら、 累積で 360万円の空コストになる。

3. コミット枠を超えた利用はオンデマンド単価

逆に、 コミット枠を超えた利用は オンデマンド単価で支払い になります。 「月 $1.0/時でコミットしたけど実際は $1.5/時 使った」場合、 超過分の $0.5/時 はCUD割引が効かずに通常価格。

ベースラインを保守的に取りすぎると（コミット額を低くしすぎると）、 大半がオンデマンド支払いになってCUDの恩恵が小さくなります。 過剰でもダメ、 過小でもダメ、 という設計の難しさがここにあります。

4. 対応策: 安全係数とパーセンタイル

実務的には次のような工夫で過剰・過小のリスクをコントロールします。

• 安全係数 0.8 を掛ける: ベースライン日次の 80% でコミット。 残り 20% はオンデマンド単価で吸収するバッファ
• 観測期間は 90日以上、 できれば 6ヶ月: 短期間だと月次のばらつきが反映されない
• min（最小値）ではなく p5（下位5パーセンタイル）を使う: 祝日・障害日のような外れ値を排除した、 実態に近い「谷底」を採用
• 複数月のCSVを跨いで集計する: 1ヶ月単位だと季節性を見落とす

公式や Cloud Billing 担当者からも「保守的に始めて、 利用が安定してから段階的に増やすのが安全」と推奨されることが多いです。 CUDは 積み増しは可能、 減らすのは不可 という非対称性があるので、 最初の購入は控えめに見積もるのが鉄則です。

5. 既存のEDP契約に影響する可能性

意外と見落としやすいのが、 既に EDP（Enterprise Discount Program）を契約している場合の影響 です。 EDP は「年間 X円以上の支出にコミットすることで全体割引を得る」という大口向けのカスタム契約で、 多くの場合 最低支出額の条件 が付いています。

ここで CUD を導入してコスト削減を実現すると、 年間支出が EDP の最低条件を下回ってしまい、 EDP の割引そのものが失効する というリスクがあり得ます。 CUDで取れた削減額より EDP で失う割引額のほうが大きい、 という逆転現象も起こり得る。

EDP契約の条件は契約ごとに異なるので、 既に EDP を結んでいる利用者がCUDを追加購入する場合は、 CUD導入後の年間支出予測でEDP条件を満たし続けられるか を Google Cloud 担当者に確認するのが安全です。 EDPの存在を知らないままCUDを進めると、 全体としてはコスト増になる可能性もある、 ということだけは認識しておく必要があります。

まとめ: Google Cloud CUD設計のチェックポイント

ここまでの内容を1枚の早見表にまとめます。

CUDを設計するときに意識したいチェックポイント:

1. 利用サービスが Compute Engine 中心なら、 リソースベース + フレキシブルの並行購入 を検討する
2. Cloud SQL / BigQuery / Bigtable など複数サービスを使っている環境では、 サービスごとに別CUDを購入 する必要がある
3. 同一Billing Account内のプロジェクトはCUDが自動共有される（プロジェクトごとに買う必要はない）
4. リージョン制約の有無 を必ずCUD種類別に確認する
5. BigQuery のCUD（Capacity Commitments）は他と完全に別系統。 ベースライン算出ロジックも違うので、 専用の試算が必要
6. 2026年1月のモデル変更 を踏まえて、 旧スクリプト・旧資料の試算結果は対象範囲を再確認する

「CUDは2種類」という認識のままだと、 Cloud SQL や BigQuery を含むマルチサービス環境のコスト試算で必ずズレが発生します。 4種類の構造を踏まえたうえで、 サービス構成に応じて使い分けるのが、 結果としてコスト削減効果を最大化することにつながります。

費用ベースCUDのサービスごとの詳細を知りたい場合は、 Google Cloud 費用ベースCUD 11サービス公式仕様の徹底比較 も合わせて参照してください。 11サービスごとの対象リソース・割引率・特殊事情をまとめています。

関連記事

• Google Cloud 費用ベースCUD 11サービス公式仕様の徹底比較: 11サービスごとの対象リソース・割引率・リージョン制約をまとめた比較記事

参考リンク（Google Cloud CUD公式ドキュメント）

CUD総合

• Committed use discounts | Google Cloud Documentation
• Spend-based committed use discounts | Google Cloud Documentation

サービス別CUD公式

• Compute Engine: Resource-based CUDs
• Cloud SQL CUDs (MySQL)
• BigQuery Capacity Commitments
• Bigtable CUDs
• Spanner CUDs
• Firestore CUDs
• AlloyDB CUDs