Cloud Runとはサービス・ジョブの違いと課金・スケーリングの考え方

Cloud Runとは

Cloud Run とは、Google のインフラ上で、コード・関数・コンテナを実行できるフルマネージドのアプリケーションプラットフォームです。Google Cloud の公式ドキュメントでは、クラスタを作ったりインフラを管理したりすることなく使え、運用・構成・スケーリングにかかる時間を減らして、コードの作成に集中できると説明されています。

コンテナ イメージをビルドできるなら、どのプログラミング言語で書いたコードでも載せられます。さらに、Go、Node.js、Python、Java、.NET、Ruby などでは、ソースコードから自動でコンテナを作る「ソースベースのデプロイ」も選べます。Docker に慣れていない人でも、入口が用意されています。コンテナそのものの考え方は Docker の記事で整理しています。

基本（3つの実行方法）

公式ドキュメントでは、Cloud Run でコードを動かす方法として、主に次の3種類が説明されています。なお、2026年10月時点の公式ドキュメントでは、長時間動き続ける単体の「インスタンス」を加えた4種類のリソースが案内されています。

サービスには、*.run.app ドメインの一意の HTTPS エンドポイントが付き、TLS は Cloud Run が管理します。カスタムドメインも設定できます。コードが TCP ポートで待ち受けて HTTP リクエストを処理するようにするのは、利用者側の責任です。

具体例（スケーリングと課金の考え方）

公式の説明をもとに、動きを整理します。

つまり、アクセスがほとんど無い時間帯が長い社内ツールや試作品は、ゼロへのスケーリングと相性が良い構造です。逆に、常に待機させたいなら最小インスタンス数を設定し、その分の料金を見込む必要があります。具体的な単価と無料枠は変わるため、必ず公式の料金ページで確認してください。

Cloud Runの実践ステップ

1. 動かしたいアプリが HTTP で待ち受ける形か確認します。定期実行の処理ならジョブを選びます。
2. コンテナ イメージを用意するか、ソースベースのデプロイを使います。
3. サービスをデプロイし、発行された HTTPS のURLで動作を確かめます。
4. 公開範囲を決めます。インターネットから届くサービスにするか、IAM や上り（内向き）の設定、Identity-Aware Proxy で絞ります。
5. 最小・最大インスタンス数を決めます。最大を制限すると、費用の急増や、接続先のシステムの過負荷を防げます。
6. 新しいリビジョンを出すときは、トラフィックの一部（たとえば1%）だけ新版に流し、様子を見ながら増やす段階的なロールアウトを使います。

Cloud Runの注意点

• ファイルは残らない: インスタンスは使い捨てで、メモリ上の書き込み可能なファイルシステムは、コンテナが止まると消えます。保存したいデータは、Cloud Storage やデータベースなどの外部に置きます。
• コールドスタート: ゼロから起動する最初のリクエストは遅くなることがあります。遅延が許されないなら最小インスタンス数を検討します。
• ステートレス設計が前提: 複数のインスタンスに処理が分散するため、メモリ上にだけセッション情報を持つ作りは不向きです。
• 公開設定の確認: サービスはインターネットから到達できる形にできるため、認証が必要なものは公開範囲を必ず見直します。
• 料金の見積もり: リクエスト数、実行時間、メモリ、CPU、ネットワークで決まります。数値は時点で変わるため、公式で確認します。

Cloud Runでよくあるミス

• ローカルのファイルに書き込む前提のまま載せて、再起動のたびにデータが消える。
• 最大インスタンス数を制限せず、想定外のアクセスで利用料が膨らむ。
• 待ち受けるポートの設定を誤り、起動に失敗する。
• 常時動くべき処理をサービスに入れて、リクエストが無いと動かない。この場合はワーカープールやジョブを検討します。

Cloud Runのチェックリスト

• 実行方法（サービス・ジョブ・ワーカープール）を選べたか
• 書き込むデータの保存先を外部に決めたか
• 課金設定（リクエストベースかインスタンスベースか）を選んだか
• 最小・最大インスタンス数を決めたか
• 公開範囲と認証を確認したか
• 料金は公式ページで見積もったか

Cloud RunのFAQ（よくある質問）

Q. Kubernetes との違いは何ですか。
A. Cloud Run は、クラスタを自分で作らず運用しない形で使えます。細かな制御が必要なら、Kubernetes のような仕組みを選ぶ余地があります。

Q. 使っていない間も料金はかかりますか。
A. 公式ドキュメントでは、最小インスタンス数を設定していなければ、サービスが使われていないとき料金は発生しないと説明されています。ただし、課金設定や条件によって異なるため、料金ページで確認してください。

Q. データベースは使えますか。
A. Cloud SQL、Firestore、Spanner、Cloud Storage などの Google Cloud のサービスと統合できると説明されています。

筆者の見解（Cloud Run）

Cloud Run の魅力は、運用の手間を減らせる点にあると考えます。小さな API や社内ツールを、サーバーの面倒を見ずに出せるのは大きな利点です。一方で、「ファイルが残らない」「最初のリクエストが遅い」という性質を理解せずに載せると、思わぬところで詰まります。私は、まず小さなサービスで動かし、ゼロへのスケーリングの挙動と請求の内訳を自分の目で確かめてから、本番へ広げる進め方を勧めます。また、他社クラウドの類似サービスと比べるときは、機能名の対応だけでなく、課金の粒度と無料枠の条件まで見るのが無難です。これは筆者の意見であり、要件によって最適な選択は変わります。

Cloud Runの関連項目

• Docker
• コンテナと仮想マシンの違い
• Kubernetes
• AWS・Azure・Google Cloudの比較
• APIゲートウェイ

出典（一次情報）

• Cloud Run とは｜Google Cloud Documentation
• Cloud Run へのコンテナ イメージのデプロイ｜Google Cloud Documentation