G-gen の佐々木です。当記事では Google Cloud（旧称 GCP）のサーバーレスなコンテナプラットフォームサービスである Cloud Run を解説します。
- Cloud Run とは
- 4種類の Cloud Run
- Cloud Run サービスの基本
- デプロイ
- サービスの構成
- サービス間連携（トリガー）
- ネットワーク
- 認証
- 料金
- 他サービスとの比較
- Cloud Run を使ってみる
Cloud Run とは
Cloud Run とは、Google Cloud（旧称 GCP）のサーバーレスなコンテナプラットフォームサービスです。任意のプログラミング言語でコードを記述して、コンテナイメージ化すれば、デプロイするだけでアプリケーションを実行することができます。Cloud Run はフルマネージドサービスであり、クラスタの作成や、インフラの管理は必要ありません。
コンテナを実行するインスタンスは負荷に応じて自動的にスケールアウトし、処理がないときはインスタンス数を 0 までスケールインさせることができす。
- 参考 : Cloud Run とは
Cloud Run では、アプリケーションをコンテナイメージからデプロイできるため、実行環境の柔軟性が高く、ユースケースは多岐に渡ります。ウェブサイトやモバイルバックエンド、API バックエンドやバッチデータ処理など、以下の公式ドキュメントにいくつかのユースケースが紹介されています。
- 参考 : 一般的な使用例
なお Cloud Run は、Kubernetes 上にサーバーレスなコンピューティング基盤を構築できるオープンソースソフトウェアの Knative が基盤技術となっています。
- 参考 : Knative
4種類の Cloud Run
4つの実行モデル
Cloud Run には、以下の4つの実行モデルがあります。
- Cloud Run サービス（Cloud Run services）
- Cloud Run ジョブ（Cloud Run jobs）
- Cloud Run 関数（Cloud Run functions）
- Cloud Run ワーカープール（Cloud Run worker pools）
Google Cloud プロダクトとして「Cloud Run」があり、その中のリソースとして「サービス（services）」と「ジョブ（jobs）」、「関数（functions）」、「ワーカープール（worker pools）」を作成できるイメージです。
当記事では、主に「Cloud Run サービス」にフォーカスして解説しています。
Cloud Run サービス（services）
Cloud Run サービスでは、コンテナイメージをデプロイするだけで、コンテナの実行環境（コンテナインスタンス）とリクエストを受信する HTTPS エンドポイントが提供されます。
Cloud Run サービスは、リクエストを受けてレスポンスを返す、ウェブサイトや API バックエンドなどのユースケースに用いられます。
Cloud Run ジョブ（jobs）
Cloud Run ジョブでは、コンテナインスタンスを使用して、ユーザーが作成したコードをジョブとして実行することができます。
ジョブは任意のタイミングで実行することができ、コンテナインスタンスを複数組み合わせて実行することにより、60 分以上のジョブ実行や並列処理を実現できます。
Cloud Run ジョブは、コンテナでリソース効率の高いバッチ処理を行いたい場合に選択肢となります。
Cloud Run ジョブの詳細については、以下の記事で解説しています。
Cloud Run 関数（functions）
Cloud Run 関数は、元々は Cloud Functions という独立したプロダクトでしたが、2024年8月には Cloud Run に統合されました。
Cloud Run functions は、HTTP リクエストをトリガーとする HTTP 関数と、特定のイベントをトリガーとするイベントドリブン関数の2種類に分けられます。
Cloud Run 関数は Cloud Run サービスと似た使い方ができますが、構築の容易さと、柔軟性に差異があります。
Cloud Run 関数では、コンテナイメージを用意することなく、ソースコードだけをデプロイすることで、ランタイム上でアプリケーションを実行することができます。その代わり、ランタイムにはライフサイクルが存在し、古いバージョンのプログラミング言語を使用している場合はランタイムの非推奨化や廃止に気を配る必要があります。また、ランタイムでサポートされるプログラミング言語の種類にも制限があります。
Cloud Run 関数の詳細については、以下の記事で解説しています。
Cloud Run ワーカープール（worker pools）
Cloud Run ワーカープールはここまで紹介した3種類の実行モデルとは異なり、外部からのリクエストをトリガーとする実行ではなく、Pub/Sub や Kafka といったメッセージキューなどに対して、コンテナインスタンスが能動的にメッセージやタスクの取得を行う pull 型のワークロードをサーバーレスに実行することができます。
2025年7月1日現在は、パブリックプレビュー版のサービスとなっています。
Cloud Run ワーカープールの詳細については、以下の記事で解説しています。
Cloud Run サービスの基本
動的スケーリング
Cloud Run サービスは、HTTPS エンドポイントで受信したリクエストを迅速に処理するために、コンテナインスタンスを自動でスケールアウトします。
コンテナインスタンスはデフォルトで最大 1000 までスケールアウトでき、リクエストのないときはインスタンス数が 0 になるまでスケールインします。
サービスの冗長性
Cloud Run サービスは特定のリージョンに作成され、冗長性とフェイルオーバーのため、リージョン内の複数のゾーンに自動的に複製されます。
Cloud Run は「リージョナルサービス」です。つまり、利用リージョンは選択できますが、その中のゾーンは選択しません。逆に言うと、利用者はゾーンを意識する必要がなく、適切に負荷分散されますし、ゾーン障害も自動的に対応されます。
デプロイ
デプロイ元のコンテナイメージ
Cloud Run にデプロイするコンテナイメージは、Google Cloud のマネージドなコンテナレジストリである Artifact Registry に格納します。
また、Cloud Run サービスとは別のプロジェクトにある Artifact Registry リポジトリに格納されたコンテナイメージを使用することもできます。
サーバーレス CI / CD プラットフォームである Cloud Build を使用することで、Git リポジトリへの push をトリガーとして、Cloud Run への継続的なデプロイを実現することも可能です。
コンテナの要件
Cloud Run サービスで実行することができるコンテナにはいくつかの要件があります。
- 参考 : コンテナ ランタイムの契約
要件の詳細については上記の公式ドキュメントに記載されています。以下は、一部を抜粋したものです。
- コンテナイメージ内の実行可能ファイルは、Linux 64 ビット用にコンパイルする必要がある
- リクエストの送信先ポート（デフォルトのポートは 8080）で 0.0.0.0 のリクエストをリッスンする必要がある
- リクエストを受信してからリクエストのタイムアウト設定で指定された時間内に、レスポンスを返す必要がある
トラフィック移行とロールバック
サービスをデプロイもしくは構成を変更すると、新しいリビジョン（版）が作成されます。
新しいリビジョンを作成した際に、既存のリビジョンに対する全てのトラフィックを即座に移行するか、段階的に移行するかを選択することができます。
また、複数のリビジョンでトラフィックを分割したり、古いリビジョンにロールバックしたりできます。
コンテナ実行環境（世代）
Cloud Run のコンテナ実行環境として、第 1 世代 と 第 2 世代から選択できます。gcloud コマンド等でサービスをデプロイする際に実行環境を指定しなかった場合、デフォルトでは、設定にあわせて自動的に世代が選択されます。第 2 世代を使用するには、少なくとも 512 MiB のメモリを指定する必要があります。
世代ごとの特徴とユースケースは以下の通りです。
- 参考 : サービス実行環境について
| 世代 | 特徴 | ユースケース |
|---|---|---|
| 第 1 世代 | ・高速なコールドスタート | ・Cloud Run サービスに対するバーストトラフィックが予測される場合 ・アプリケーションがコールドスタートの影響を受けやすい場合 ・Cloud Run サービスに対する定常的なトラフィックがなく、コンテナインスタンスの数が頻繁にゼロまでスケールインする場合 ・512 MiB 未満のメモリを使用したい場合（第 2 世代は最低 512 MiB） |
| 第 2 世代 | ・ネットワークファイルシステムのサポート ・Linux との完全な互換性（すべてのシステムコール、名前空間、cgroup が利用可能） ・CPU とネットワークパフォーマンスの高速化 |
・アプリケーションからネットワークファイルシステムを使用する場合 ・Cloud Run サービスに対する定常的なトラフィックがあり、コールドスタートが多少遅くても許容できる場合 ・CPU やネットワークに高いパフォーマンスが求められるワークロードの場合 ・第 1 世代ではサポートされていない OS のシステムコールを使用する場合（参考） ・Linux の cgroup 機能を使用したい場合 ・Cloud Run Threat Detection を使用したい場合（参考） |
サービスの構成
エンドポイント URL
デフォルトでは、Cloud Run サービスには *.run.app ドメインの一意のサブドメインがサービスの HTTPS エンドポイント URL として提供されます。
Cloud Run サービスをデプロイすると、Deterministic URL と Non-deterministic URL の2つが発行されます。前者は、サービス名とリージョンによって一意に定まる URL であり、後者はランダムハッシュが含まれておりデプロイするまで決定しない URL です。
# Deterministic URL の形式 https://{サービス名}-{プロジェクト番号}.{リージョン}.run.app
# Non-deterministic URL の形式 https://{サービス識別子}.run.app
グローバル外部 HTTPS ロードバランサ、または Firebase Hosting を利用することで、カスタムドメインを設定することもできます。
- 参考 : HTTPS リクエストで呼び出す - 決定論的 URL
- 参考 : カスタム ドメインのマッピング
コンテナインスタンスの最大・最小数
動的スケーリングの最大・最小インスタンス数は、あらかじめ設定することができます。
最大インスタンス数はデフォルトが 100、上限は 1000 です。この上限は、Google Cloud コンソールの「割り当てとシステム上限」ページから、引き上げ申請が可能です。
最小インスタンス数はデフォルトで 0 となっており、リクエストがないときはインスタンス数が 0 になるまでスケールインします。
- 参考 : Cloud Run の割り当てと上限
コールドスタートとその対処
Cloud Run サービスでは、インスタンス数が 0 の状態のときにリクエストが発生した場合、最初のインスタンスの起動が完了するまで、処理の遅延が発生します。これをコールドスタートといいます。
最小インスタンス数を 1 以上 にすることにより、コンテナインスタンスのウォーム状態（いつでも呼び出し可能な状態）を維持し、リクエストをすぐに処理することが可能になります。
最小インスタンス数が 1 以上の場合、指定した数のコンテナインスタンスがアイドル状態で常に起動しており、リクエストを処理していないときでも、アイドル状態のインスタンスの料金が発生します。
アイドル状態のインスタンスの料金は、実際にリクエスト処理をしているときの料金よりも安く設定されています（課金モードがデフォルトの「リクエストベースの課金」の場合）。
- 参考 : サービスの課金設定
- 参考 : Cloud Run pricing
以下の記事では、コールドスタートやその対処についてさらに深堀りしています。
Startup CPU boost
コールドスタート対策、すなわちゼロスケールからのコンテナ起動や、リクエスト数が上昇してスケールアップする際のコンテナ起動を高速化するために、Startup CPU boost 機能が存在します。
- 参考 : 起動時の CPU ブーストを設定する
Startup CPU boost については、以下の記事で詳細に解説しています。
CPU・メモリ
Cloud Run サービスのデプロイ時に、コンテナインスタンス 1 つあたりに割り当てる CPU の数と、メモリ容量の上限を設定できます。デプロイ後も変更が可能です。
CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。
| CPU（個） | メモリ容量 |
|---|---|
| 1 未満（最小 0.08） | 128 MiB ~ 512 MiB（CPU 数が 0.08 の場合） |
| 1 | 128 MiB ~ 4 GiB |
| 2 | 128 MiB ~ 8 GiB |
| 4 | 2 GiB ~ 16 GiB |
| 6 | 4 GiB ~ 24 GiB |
| 8 | 4 GiB ~ 32 GiB |
- 参考 : サービスの CPU 上限を構成する
- 参考 : サービスのメモリ上限を構成する
リクエストのタイムアウト
Cloud Run サービスでは、エンドポイントで受信したリクエストの処理に使用できる時間を設定できます。
デフォルトは 300秒 で、1~3600秒 の範囲で設定することができます。
コンテナインスタンスあたりの同時リクエスト最大数
1つのコンテナインスタンスが処理できる同時リクエストの数を設定できます。
デフォルトは 80 で、1~1000 の範囲で設定することができます。
- 参考 : サービスの最大同時リクエスト数
サービス間連携（トリガー）
Cloud Run サービスでは、クライアントからの HTTPS リクエスト経由の呼び出しのほか、gRPC や WebSocket を使用した通信や、他の Google Cloud サービスからの呼び出しをサポートしています。
Google Cloud のサービスからの呼び出しは、Pub/Sub、Cloud Scheduler、Cloud Tasks、Eventarc、Workflows などが利用できます。
ネットワーク
Cloud Run サービスに対する接続
デフォルトでは、ネットワークレベルでは任意のアクセス元から Cloud Run サービスにアクセスすることが可能です。
上り（内向き）設定 を変えることで、ネットワークアクセス元について 3 段階の制限をかけることが可能です。
| 設定名 | 許可するアクセス元 |
|---|---|
| 内部 (Internal) | ・ 内部アプリケーションロードバランサ ・ VPC Service Controls 境界内のリソース ・ 同一プロジェクトの VPC ・ Eventarc, Pub/Sub, Workflows |
| 内部 (Internal) と Cloud Load Balancing | ・ 内部 (Internal) で許可されているもの ・ 外部アプリケーションロードバランサ |
| すべて (All) | すべて |
なお Google Cloud で「上り」「内向き」「Ingress」という言葉は、サービス（Google Cloud）に入る方向のトラフィックを指します。サービスの外部や Google Cloud の外部を「下」「外」とみなし、外方向へのトラフィックに対して「下り」「外向き」「Egress」という言葉を使います。
Cloud Run サービスから VPC ネットワークへの接続
Compute Engine VM や Google Kubernetes Engine（GKE）クラスタ等とは異なり、Cloud Run サービスは VPC ネットワークの外に作成されるため、デフォルトでは VPC 内のリソースに Internal IP（内部 IP）アドレスでアクセスすることができません。
サーバーレス VPC アクセス、もしくは Direct VPC Egress を使用することにより、Cloud Run サービスから Internal IP アドレスを使用して、VPC リソース接続することができます。
- 参考 : VPC とコネクタ
- 参考 : VPC ネットワークによるダイレクト VPC 下り（外向き）
サーバーレス VPC アクセスと Direct VPC Egress については、以下の記事で解説しています。
認証
非公開サービスの認証
Cloud Run サービスは、デフォルトでは非公開サービスとしてデプロイされます。非公開のサービスを呼び出す際には、リクエスト時に IAM の認証情報が必要です。つまり IAM 認証情報を持っていない人やプログラムからのリクエストは受け付けません。
他の Google Cloud サービスから Cloud Run サービスを呼び出す場合は、Cloud Run 起動元（roles/run.invoker）ロール、もしくは同等の権限をもつカスタムロールが付与されたサービスアカウントによる認証が必要です。
- 参考 : 認証の概要
なお、Workload Identity 連携を用いることで、OpenID Connect（OIDC）もしくは SAML 2.0 をサポートする外部 ID プロバイダを使用した認証も可能となっています。
- 参考 : Workload Identity 連携
公開アクセスの許可
Cloud Run サービスを、一般公開する API やウェブサイトとして公開する場合、公開アクセスを許可することができます。
コンソールや CLI から、allUser メンバータイプ に対して Cloud Run 起動元（roles/run.invoker）ロールを割り当てるだけで、未認証のサービス呼び出しを許可することができます。
- 参考 : 公開（未認証）アクセスを許可する
また上記の方法以外でも、Cloud Run サービス呼び出し時の IAM チェックを無効化することで、Cloud Run サービスを一般公開することもできます。組織のポリシーで、IAM ロールを付与できるドメインを限定している場合には、こちらの方法を使います。
以下の記事も参考にしてください。
独自のユーザー認証
サービスに対して、許可されたエンドユーザーのみにアクセスを制限する場合において、エンドユーザーが Google アカウントによる認証を利用できれば通常の IAM の仕組みで呼び出し元を制御できますが、独自の認証機構を実装したい場合、Identity Platformを使用することもできます。
Identity Platform は独立した Google Cloud プロダクトであり、Cloud Run とは別プロダクトです。Identity Platform では、メールアドレスとパスワード、電話番号、Google、Facebook、GitHubなどのソーシャルプロバイダや、カスタム認証メカニズムを用いたユーザー認証が可能となっています。
- 参考 : Identity Platform
料金
料金体系
Cloud Run サービスの料金体系は、デプロイしたサービスごとに、リクエストベースの課金と、インスタンスベースの課金から選択できます。
デフォルトでは、サービスは、リクエストベースの課金としてデプロイされます。この場合、Cloud Run サービスはリクエストを処理しているときにのみ CPU が割り当てられ、割り当て時間に応じて料金が発生します。また、リクエスト数に応じた課金も発生します。
Cloud Run サービスをインスタンスベースの課金モードでデプロイすることもできます。この場合、リクエストがない場合でもコンテナインスタンスに CPU を常に割り当てて、バックグラウンドタスクや非同期処理タスクを実行することができます。リクエスト数に応じた課金はありません。
インスタンスベースの課金では、リクエストの処理中だけではなく、コンテナインスタンスの起動から終了まで CPU が割り当てられ、そのライフサイクル全体で料金が発生します。ただし、料金単価は通常よりも安価です。そのため、常時何かしらの処理が発生しているような場合、インスタンスベースの課金のほうが結果的に安価になります。
- 参考 : サービスの課金設定
- 参考 : CPU の割り当て（サービス）
最新の料金単価は、以下のページから確認できます。
- 参考 : Cloud Run の料金
リクエストベースの課金
コンテナインスタンスがリクエストを処理している間に割り当てられた CPU とメモリの利用時間について、100 ミリ秒の粒度で課金されます。
最小インスタンス数を 1 以上にしている場合、最小インスタンス数に設定している数のインスタンスは、処理をしていない間、低い単価のアイドル状態の料金が発生します。
またリクエストベースの課金では、サービスに対するリクエストの数に対して、100 万リクエスト単位で課金されます。
| CPU | メモリ | リクエスト | |
|---|---|---|---|
| 無料枠 | 毎月最初の 180,000 vCPU 秒 | 毎月最初の 360,000 GiB 秒 | 毎月 200 万リクエスト |
| 通常料金 | $0.00002400 / vCPU 秒 アイドル状態の場合 $0.00000250 / vCPU 秒 (最小インスタンス数が1以上のとき) |
$0.00000250 / GiB 秒 アイドル状態の場合 $0.00000250 / GiB 秒 (最小インスタンス数が1以上のとき) |
$0.40 / 100 万リクエスト |
| 確約利用割引 | $0.00001992 / vCPU 秒 | $0.000002075 / GiB 秒 | CUD $0.332 / 100 万リクエスト |
※2025年4月現在、東京リージョンのもの
vCPU 秒 : vCPU が 1 つのインスタンスを 1 秒間 実行すること
GiB 秒 : メモリ容量が 1 ギビバイトのインスタンスを 1 秒間実行すること
アイドル状態 : 最小インスタンス数でウォーム状態を維持している場合
インスタンスベースの課金
CPU を常に割り当てる場合、リクエスト単位の課金はなく、CPU とメモリの利用時間についての課金のみとなっています。コンテナインスタンスの起動から終了までの間、リソースの利用料金が発生します。常時リソースが割り当てられている分、単価は安くなっています。
| CPU | メモリ | |
|---|---|---|
| 無料枠 | 毎月最初の 240,000 vCPU 秒 | 毎月最初の 450,000 GiB 秒 |
| 通常料金 | $0.00001800 / vCPU 秒 | $0.00000200 / GiB 秒 |
| 確約利用割引 (1年間の Flex CUD) |
$0.00001296 | $0.00000144 |
※2025年4月現在、東京リージョンのもの
Recommender による最適化
Cloud Run サービスの課金設定の選択にあたり、Recommender を参考にすることができます。Recommender は、Cloud Run サービスの過去 1 ヶ月間のトラフィック受信状況から、料金が安くなる場合にインスタンスベースの課金に変更するよう推奨してくれます。
- 参考 : Recommender による最適化
他サービスとの比較
Compute プロダクトの考え方
Google Cloud が提供する Compute プロダクト（プログラムが動作するためのプラットフォームを提供するプロダクト。Compute Engine、GKE、Cloud Run 等）は、構築の柔軟性と運用負荷に差があります。
例として、Compute Engine は仮想サーバーのサービスのため、OS やミドルウェアなどを柔軟にカスタマイズできます。これは、柔軟性が高い代わりに、運用負荷が高いことを意味します。
どこまでの柔軟性が必要か、運用負荷をどれだけ抑えたいか、などの観点で適切なサービスを選択することが重要です。
Cloud Run は、柔軟性と運用負荷において、Compute プロダクト内でも中間の位置にあります。
コンピュート系サービスの選択方法については以下の記事でも論じています。当記事では Cloud Run を軸として説明しますが、以下の記事もぜひご参照ください。
Cloud Run と Compute Engine の比較
Compute Engine は、Google Cloud の VPC ネットワーク内に仮想マシンを構築することができる、IaaS プロダクトです。
Compute プロダクトの中で最高の柔軟性があり、他のプロダクトにデプロイできるものは概ね、Compute Engine の VM にデプロイすることができます。その代わり に、Compute Engine では、仮想マシンの OS から上のレイヤにあるものは、すべてユーザーが構築したり、管理する必要があります。また Cloud Run のようなサーバーレスアーキテクチャではないため、仮想マシンの実行中は何も処理をしていなくても課金され続けます。
Compute Engine については以下の記事も参考にしてください。
Cloud Run と Google Kubernetes Engine の比較
Google Cloud の代表的なコンテナサービスである Google Kubernetes Engine（GKE）では、コンテナをデプロイする Kubernetes クラスタをユーザーが管理します。フルマネージドの Cloud Run と比較して、OS、CPU、GPU、ディスク、メモリ、ネットワークなどの柔軟な構成が可能です。
また GKE には、Kubernetes クラスタの管理の大部分を Google Cloud に任せることのできる Autopilot モードがあります。
Cloud Run と GKE では、主に以下のような点が異なります。
- リクエストがないとき、GKE は 0 までスケールインできない。Cloud Run ではゼロスケールが可能
- GKE はマイクロサービスアーキテクチャ等の複雑な構成が可能。Cloud Run では、設計が複雑になる
- GKE は VPC ネットワーク内で動作するため、VPC 内 のリソースとの接続が容易。Cloud Run では VPC 内のリソースと通信するためには、サーバーレス VPC アクセスや Direct VPC Egress などの設定が必要
Cloud Run と GKE は、どちらもコンテナ実行環境を提供するサービスですが、GKE は「高度なコンテナオーケストレーションを実現できるサービス」、 Cloud Run は「コンテナをサーバーレスで容易に実行することができるサービス」という位置づけです。
GKE については以下の記事も参考にしてください。
Cloud Run と App Engine の比較
Cloud Run と コンセプトが似ているサービスとして、App Engine（GAE）があります。
GAE は、コードと構成ファイルをデプロイするだけで、アプリケーションを容易に実行できるサービスとなっています。
スタンダード環境の GAE では開発言語の制限がありますが、Cloud Run 同様、リクエストがないときにインスタンスが 0 までスケールインします。
GAE と Cloud Run の主な違いは以下の点となります。
- GAE ではデプロイに必要なのはコードと構成ファイルのみであり、Cloud Run よりも実行環境の柔軟性が劣る代わりに、容易にアプリケーションを実行することができる
また、フレキシブル環境の GAE のみのデメリットとして、VM ベースの実行環境のためスケーリングが遅い、0 までスケールインできないなどがあります。
GAE との比較では、デプロイの容易さで GAE、環境の柔軟性で Cloud Run が優れています。
GAE については以下の記事も参考にしてください。
Cloud Run を使ってみる
以下の記事では、Cloud Run のサービスをデプロイするまでの基本的な手順や設定項目、Cloud Run を中心とした一般的なサービス構成について解説しています。
佐々木 駿太 (記事一覧)
G-gen最北端、北海道在住のクラウドソリューション部エンジニア
2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。
趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。
Follow @sasashun0805