LASSIC Media らしくメディア
GCP Cloud Run/GKE Autopilotのコストを最適化する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- GKE AutopilotとStandard・Cloud Runの課金モデルは根本的に異なり、使い分けがコスト最適化の出発点になります
- Compute Flex CUD・Spot Pod・リソースrequestの適正化を組み合わせることで、クラウド費用を大幅に抑えられる可能性があります
- 外注を活用する場合は「現状把握→適正化→コミット設計→移行」の順に進めると、過剰投資や移行リスクを抑えながら進められます
目次
Cloud Run・GKE Autopilot・Standardの課金モデルの違い
GCP Cloud Run・GKE Autopilot・GKE Standardのコスト最適化外注とは、Google Cloud上でコンテナワークロードを運用する際の課金モデルの違いを正確に把握したうえで、過剰なクラウド支出を削減するための設計・運用改善を外部パートナーに委託する取り組みです。
3サービスの課金モデルは大きく異なります。GKE Standardはノード（VM）単位で課金されるため、ワークロードが少なくてもノードが稼働していれば空き容量分のコストも発生します。一方、GKE Autopilotはワークロードが要求したvCPU・メモリ・ストレージの分だけ課金される設計です。ノード管理とビンパッキング（リソース効率化）はGoogle側が担います。
Cloud RunはHTTPリクエストを受けたときだけCPUが割り当てられる「リクエストベース課金」と、インスタンスを常時起動する「CPU常時割当」から選択できます。アイドル時間が長いワークロードであればリクエストベースの方が割安になりますが、レスポンスタイムの要件によって選択肢は変わります。
両GKEモードには共通でクラスタ管理料として$0.10/時がかかります。無料枠として$74.40/月のクレジットが適用されるため、1クラスタ運用であれば管理料は実質ゼロになります。料金はいずれもGoogle Cloud公式料金に基づく執筆時点の目安であり、リージョンや改定によって変動します。
| サービス | 課金単位 | 管理負担 | 向いているワークロード |
|---|---|---|---|
| Cloud Run | リクエスト処理時間 or CPU常時割当 | サーバーレス・フルマネージド | API・バッチ・イベント駆動の短命タスク |
| GKE Autopilot | Pod要求vCPU・メモリ・ストレージ （us-central1目安：約$0.0445/vCPU時・$0.0049/GiB時） |
ノード管理はGoogle。クラスタ管理料$0.10/時 | 常駐型サービス・ステートレスWebアプリ |
| GKE Standard | ノード（VM）単位。空き容量も課金 | ノード管理はユーザー側。クラスタ管理料$0.10/時 | GPUワークロード・細かいスケジューリング制御が必要なケース |
※料金はGoogle Cloud公式料金（執筆時点の目安）に基づきます。リージョン・時期によって変動するため、最新の料金はGoogle Cloud公式料金ページでご確認ください。
コストが膨らむ3つの典型パターン
GCP料金が想定以上に膨らむ場合、原因は「モード選択の誤り」「リソース過剰割当」「割引活用の未着手」の3つに集約されます。
1点目はワークロード特性とモードのミスマッチです。常時起動が不要なAPIやバッチジョブをGKE Standardで動かすと、アイドル中のノード費用が積み上がります。逆に、接続を長時間維持するWebSocketやステートフルな処理をCloud Runに乗せると、タイムアウトや接続制限の問題が出ることがあります。
2点目はPodのリソースrequestの過剰設定です。Autopilotはrequestの値そのものに課金されるため、requestを実使用量より大きく設定していると、その差分が無駄になります。開発時のデフォルト設定を本番でそのまま使い続けているケースが少なくありません。
3点目はCUDやSpotの未活用です。GCP上でコミットしたリソース量に対して割引を受けられるFlex CUD（Committed Use Discount）や、中断可能なワークロード向けのSpot Pod／Spot VMを使用していないと、オンデマンド料金がそのままかかり続けます。これら割引制度の検討が後回しになりがちです。
Cloud Run/GKE Autopilot固有のコスト最適化手法
Compute Flex CUDへの移行
GKE AutopilotのCUD（長期利用割引）は2024年以降、Autopilot固有のCUDが廃止されCompute Flex CUDへ統合されています。Compute Flex CUDは1年コミットで約28%、3年コミットで約46%の割引が適用されます（Google Cloud公式料金に基づく執筆時点の目安）。
Flex CUDはvCPUとメモリのコミット量をリージョン単位で設定します。Autopilotのみでなく、同一リージョンのGCE VMや他のKubernetesワークロードにも適用できるため、複数サービスを運用している場合はまとめてコミット量を算定する方が効率的です。コミット前に過去の使用実績をBigQueryやCloud Monitoringで確認し、適切なコミット量を算出することが大切です。
Spot Pod（Autopilot）・Spot VM（Standard）の活用
バッチ処理・CI/CD・ステージング環境など、中断が許容されるワークロードにはSpot Pod（Autopilot）またはSpot VM（Standard）が有効です。中断される可能性がある代わりに、オンデマンド価格から〜91%程度の割引が期待できます（Google Cloud公式情報に基づく執筆時点の目安）。
ただし本番の常駐サービスにそのまま適用するのは可用性リスクを伴います。PodDisruptionBudget（PDB）を設定して最低稼働Pod数を保証する、Spot PodとオンデマンドPodを混在させる、といった可用性設計をあわせて行うことが前提です。
リソースrequestの適正化
Autopilotではrequestの値がそのまま課金対象になります。Vertical Pod Autoscaler（VPA）のレコメンデーションモードを使うと、実際のCPU・メモリ使用量に基づいてrequestの推奨値を算出できます。まずVPAをrecommend専用で動かして推奨値を確認し、段階的に本番反映する方法が実務上とりやすいアプローチです。
Cloud Runのアイドルコスト最小化
Cloud Runはリクエストベース課金にすることでアイドル時のCPUコストをゼロに近づけられます。ただし、コールドスタート（起動遅延）が許容できない場合は最小インスタンス数を設定する必要があり、その分のCPU常時割当コストが発生します。最小インスタンス数をゼロにするか1以上にするかは、SLA要件とコストのトレードオフを見ながら決定します。
外注で進める4ステップ：現状把握からコミット設計まで
GCPコスト最適化を外注で進める場合、以下の4ステップで段階的に取り組むと、過剰投資や移行リスクを抑えながら進められます。
- 現状把握：コスト配分の可視化と過剰部分の特定
- 適正化：requestの見直し・モード変更・Spot導入
- コミット設計：Flex CUDのコミット量と期間を算定
- 移行・運用定着：変更適用・モニタリング設定・ルール整備
ステップ1：GCP Billing分析でコスト配分を可視化
最初に行うのは現状のコスト配分の可視化です。Cloud Billing ReportsやBigQuery Export（Cloud BillingのデータをBigQueryへ転送する機能）を使い、サービス・プロジェクト・ラベル単位でコストを分解します。「どのサービスのどのリソースが全体のコストの何割を占めているか」を明らかにすることが出発点です。
外注先にはBillingデータの閲覧権限（Billing Account Viewer相当）を適切に付与します。権限の範囲は事前に合意しておく必要があります。
ステップ2：requestの見直しとモード変更
コスト配分が見えたら、影響の大きいサービスから順にrequestの適正化とモード変更を検討します。VPAの推奨値を参照しながらrequestを段階的に引き下げ、実使用量のモニタリングを継続します。Cloud RunとGKE Autopilotの使い分けも、ワークロードの特性をあらためて整理したうえで見直すことがあります。
ステップ3：Flex CUDのコミット量と期間を算定
requestの適正化が落ち着いたタイミングでFlex CUDのコミット設計に進みます。コミット後にrequestを大幅に下げると、コミット量が過剰になって割引効果が薄れます。適正化が先、コミットが後という順番が重要です。コミット量は過去30〜90日分の実使用量の中央値を基準に算定するのが実務上の目安です。
ステップ4：移行・モニタリング・ルール整備
変更を本番に適用した後は、Cloud Monitoringのダッシュボードでリソース使用率と課金額の推移を継続的に確認します。request設定の変更手順・Spot Pod導入基準・CUDの見直しタイミングを社内ドキュメントとして整備することで、外注終了後も自社でコスト管理を継続できる体制が整います。
依頼前に確認しておく5つのポイント
外注先に相談する前に以下を整理しておくと、見積もりの精度が上がり、依頼後の手戻りを減らせます。
- 現在のGCP月額費用の内訳：サービス別・プロジェクト別の費用規模を共有できる状態にしておきます
- 利用しているGCPサービスと構成：Cloud Run・GKE（Autopilot/Standard）・Cloud SQL・Cloud Storageなどの構成図があると相談がスムーズです
- SLAとダウンタイム許容度：Spotの活用可否や最小インスタンス数の設定に直結します
- 既存のCUD・割引契約の有無：既にコミット済みの契約がある場合は期間と対象リソースを確認します
- 変更適用の意思決定フロー：本番環境への変更承認者・テスト環境での検証プロセスを事前に明確にします
これらが整っていない状態で外注を始めると、現状把握フェーズに余分な工数がかかり、コスト最適化の効果が出るまでの期間が延びます。
GCPコスト最適化に強い外注先の選び方
依頼先を選ぶ際には、Google Cloud特有のコスト最適化経験と、可用性設計を含む運用支援力の両方を確認することが大切です。
具体的には以下の観点で比較するとよいでしょう。GKE Autopilot・Cloud Run固有の最適化（VPA活用・Spot Pod設計・Flex CUD算定）の実務経験があるか、Billing ExportやMonitoringを使ったコスト可視化の支援ができるか、最適化後のモニタリング設計と社内引継ぎドキュメントの整備まで含まれるか、といった点です。
外注形態としては、スポットのアセスメント（現状把握・改善提案のみ）と、変更適用・運用支援まで含む継続契約の2種類があります。初期費用を抑えたい場合はアセスメントから始め、提案内容を自社で評価してから継続依頼を判断する方法がリスクを抑えやすいです。
内製でGCPコスト最適化を完結させるには、Kubernetes（GKE）の運用知識、Billing API・BigQueryの分析スキル、Flex CUDの算定経験が必要です。これらのスキルを持つエンジニアを社内で確保することが難しい場合、外注によってリスクと費用の双方を管理しやすくなります。
まとめ：Cloud Run/Autopilot最適化を外注で進める3つの判断軸
本稿ではGCP Cloud Run・GKE Autopilot・Standardの課金モデルの違いから始め、コストが膨らむ典型パターン、Flex CUD・Spot・request適正化・Cloud Runのアイドル設計という固有の最適化手法、外注で進める4ステップ、依頼前の確認ポイント、外注先の選び方を整理しました。
要点を3点に集約します。第一に、GKE AutopilotはPod request量に課金されるため、requestの過剰設定が直接コストに影響します。適正化を先行させてからFlex CUDをコミットする順番が重要です。第二に、Spot Pod・Spot VMは〜91%程度の割引が期待できる反面、可用性設計とセットで検討しないと本番障害リスクを生みます。第三に、外注を活用する際は「現状把握→適正化→コミット設計→移行・定着」のステップを明確にし、各フェーズで外注先に求めるアウトプットを事前に合意することが、成果につながる依頼の進め方です。
よくある質問
GKE AutopilotとGKE Standardはどちらを選ぶべきですか？
ノード管理の工数を削減したい、または空き容量への課金をなくしたい場合はAutopilotが向いています。GPU専用ノードを使う、ノードのkernelパラメータを変更するといった細かい制御が必要なケースではStandardを選ぶことになります。まずワークロードの要件を洗い出し、制御の必要性がなければAutopilotから始める方がコスト管理はしやすいです。
Flex CUDのコミット量はどのように決めればよいですか？
過去30〜90日分のCloud Billing ExportデータをBigQueryで集計し、vCPU・メモリの使用量の中央値（p50）を基準に算定するのが実務上の目安です。ピーク値でコミットすると過剰になりやすいため、安定して使う「ベース分」をコミットし、変動分はオンデマンドまたはSpotで対応する設計にすることでリスクを抑えられます。
Spot Podを本番環境に使うのはリスクがありますか？
Spot Podは需要状況によって中断される可能性があるため、単独で本番の常駐サービスに使うと可用性リスクがあります。PodDisruptionBudget（PDB）で最低稼働Pod数を設定し、オンデマンドPodとSpot Podを混在させる構成にすることで、コスト削減と可用性をバランスさせられます。バッチ処理やステージング環境への適用から始めるのが、リスクを抑えた進め方です。
外注先がGCPの操作をする際に必要な権限はどの程度付与すべきですか？
現状把握フェーズではBilling Account ViewerとCloud Monitoring Viewer程度の読み取り専用権限で対応できます。変更作業が発生するフェーズでは、対象プロジェクトのKubernetes Engine AdminやCloud Run Admin等が必要になります。権限は必要最小限に絞り、作業完了後に削除するか有効期間を設定することをお勧めします。IAM条件（Conditions）で対象リソースや期間を限定する方法も有効です。
GCPコスト最適化の外注費用はどのくらいが目安ですか？
外注費用はスコープや対象システムの規模によって異なるため、一概には言えません。アセスメント（現状分析・改善提案）のみであれば数十万円台から、変更適用・運用支援を含む継続契約では月額数十万円以上が市場参考値として挙げられますが、これは市場参考値であり一次資料に基づく数値ではありません。実際には複数社から見積もりを取り、スコープと成果物を明確にしたうえで比較することをお勧めします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google Cloud「Google Kubernetes Engine の料金」（2026年）
