--- title: "Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15435/" published: 2026-07-21 updated: 2026-10-14 categories: ["Google Cloud"] publisher: "株式会社一創" --- # Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説 Cloud Runは、任意の言語で書いたアプリをコンテナにして渡すだけで、サーバーの用意やクラスタ管理をせずに動かせるGoogle Cloudのサーバーレスコンテナ実行基盤です。この記事では、サービスとジョブに2026年4月から加わったワーカープールまでを含むリソース構成、ゼロスケールと同時実行、第1世代と第2世代の実行環境、リクエストベースとインスタンスベースの料金モデルを、2026年9月時点の公式ドキュメントの数値で整理します。gcloud run deployでコンテナを公開するまでの実コマンド、GKE（Google Kubernetes Engine）やCloud Run functionsとの違い、採用すべき条件と見送るべき場面の判断基準まで、実装者が基盤選定で迷う論点を具体的に示します。 ## まとめ：Cloud Runの仕組みと採用判断の要点 Cloud Runは、コンテナイメージを渡すだけでスケール管理なしにアプリを動かせるサーバーレス基盤です。HTTPやイベントを受けて常駐するサービス、処理を終えたら止まるジョブ、リクエストに紐づかない常駐処理を受け持つワーカープールの3形態が一般提供されています。デプロイはリビジョン単位でトラフィックを分割でき、アクセスが無ければインスタンスを0まで縮めるため、待機時のコストを抑えながら急な負荷にも追随できます。言語やフレームワークをGoogle Cloud側の制約に合わせて選び直す必要もありません。OSまで自分で握るVMが要るなら、[Compute Engineとは？の解説](https://www.issoh.co.jp/tech/details/15665/)が選択肢になります。 料金は、処理中のCPUとメモリの時間を100ミリ秒単位で切り上げて課金するリクエストベースと、アイドル時もCPUを割り当て続けるインスタンスベースの2択です。東京リージョン（asia-northeast1）が属するティア1では、リクエストベースの稼働中CPUが1vCPU秒あたり0.000024ドル、インスタンスベースが同0.000018ドルで、月180,000vCPU秒と200万リクエストまでの無料枠が付きます（2026年9月時点）。クラスタを自分で持って運用の自由度を取りたいならGKE、関数単位の軽いイベント処理ならCloud Run functions、その中間でコンテナのまま手間を減らしたいならCloud Runという棲み分けです。重い後処理を非同期へ切り出すなら、[Cloud Tasksとは（GCPの非同期タスクキュー）の記事](https://www.issoh.co.jp/tech/details/15744/)もあわせて確認してください。 ## Cloud Runの仕組みとサーバーレスコンテナという位置づけの整理 まず「サーバーレスとコンテナを同時に取る」という立ち位置を押さえます。ここが曖昧だと、GKEやCloud Run functionsとの役割の境目を見誤ります。サーバーレスという考え方そのものは、[サーバーレスとは何か・コンテナとの使い分けを解説した記事](https://www.issoh.co.jp/column/details/13005/)が上位の入り口です。 ### サーバーレスとコンテナを両取りするCloud Runの設計思想 従来のサーバーレスは、あらかじめ用意された言語ランタイムに関数を載せる形が主流で、実行環境の自由度に制約がありました。Cloud Runは、その制約を、コンテナを実行単位にすることで外します。任意の言語やライブラリを含むイメージを用意すれば、Google Cloud側はそれをリクエストに応じて起動・停止するだけを担い、OSやミドルウェアの構成はコンテナの中で決められる点が持ち味です。コンテナという単位そのものは[コンテナとは何か・仮想マシンとの違いから解説した記事](https://www.issoh.co.jp/column/details/13000/)で先に固めておくと、この「持ち込んだ環境がそのまま動く」利点が理解しやすくなります。リソースの全体像は公式の[What is Cloud Run（2026年9月16日更新）](https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run)に一覧があります。 ### サービスとジョブというCloud Runの2つの実行形態の違い 1つはサービスで、HTTPリクエストやイベントを受けて応答する常駐型の使い方です。WebアプリやAPI、Webhookの受け口がこれに当たり、リクエストが来ると起動し、途切れると縮小します。イベントを起点にした起動の配線には[Eventarc](https://www.issoh.co.jp/tech/details/15748/)を使えます。もう1つはジョブで、バッチ処理のように「実行して完了したら終わる」タスク向けです。日次の集計やデータ変換、メンテナンススクリプトをコンテナとして走らせ、終われば課金も止まります。この2つは設定と料金の考え方が変わります。 ### ワーカープールとインスタンスを加えた4リソース構成の選び分け サービスとジョブに加えて、2026年4月14日にワーカープールが一般提供となりました。ワーカープールはHTTPリクエストを受け付けず、KafkaやPub/Subのようなプル型のキューからメッセージを引き取って処理し続ける常駐型のリソースです。スケーリングは手動指定か、外部メトリクスに連動するCREMAオートスケーリングから選びます。さらに2026年8月25日からは、単一インスタンスで長時間動かす「インスタンス」がプレビューに入りました。作成手順と共有vCPUの挙動、停止時に消えるデータの扱いは[Cloud Run instancesの解説記事](https://www.issoh.co.jp/tech/details/18244/)で扱っています。判断の順序はこうです。HTTPで応答するならサービス、走り切って終わるバッチならジョブ、キューを読み続ける常駐処理ならワーカープール。ワーカープールの1vCPU秒あたり0.000011244ドルは、インスタンスベース課金のサービス（同0.000018ドル）より約38%安いので、リクエスト駆動でない常駐処理は移すだけで単価が下がります。設定手順は[ワーカープールのデプロイ手順](https://docs.cloud.google.com/run/docs/deploy-worker-pools)に記載があります。 ### リビジョンとトラフィック分割による段階的なリリースの仕組みと復旧 Cloud Runでは、デプロイのたびにリビジョンという不変のスナップショットが作られます。新しいイメージや設定を反映すると新リビジョンが生成され、旧リビジョンはそのまま残る点が特徴です。おかげで、新リビジョンへ最初は数％だけ流して問題がなければ割合を上げるカナリアリリースが設定だけで組めます。不具合が出ても旧リビジョンへ戻すだけで復旧でき、停止時間を作らずに更新を回せます。 ## Cloud Runのスケーリング・同時実行と実行環境の設計前提 性能とコストの両方を決めるのが、インスタンスを増減させるスケーリングの挙動と、1インスタンスが同時にさばくリクエスト数の設定です。 ### ゼロスケールと最小・最大インスタンス数によるスケール設計の勘所 Cloud Runは、リクエスト数に応じてコンテナインスタンスを自動で増減させます。特徴的なのは、アクセスがまったく無い時間帯にインスタンス数を0まで縮められる点で、待機だけのコストが発生しません。一方で、0からの起動には初回の立ち上がり（コールドスタート）の遅延が伴うため、応答速度をそろえたいサービスでは最小インスタンス数を1以上に保ちます。アクセス急増に上限を設けたいなら最大インスタンス数を定め、スパイクでコストや下流の負荷が跳ねないよう抑える設定です。月額で上限を決めて超えたら止める予算上限（spend cap）の設定手順と、停止中に返る5xxへの備えは[Cloud Run 予算上限の設定手順の記事](https://www.issoh.co.jp/tech/details/18341/)で扱っています。処理時間側にも枠があり、サービスのリクエストタイムアウトは既定で5分（300秒）、最大60分（3600秒）まで延ばせます。15分を超える設定では接続が切れる前提でリトライと再接続を組んでおくよう、公式ドキュメントが明示しています。 ### コンテナ同時実行数（concurrency）という他サービスとの分岐点 Cloud Runの大きな特徴が、1つのコンテナインスタンスで複数のリクエストを同時に処理できる点です。この同時実行数（concurrency）を上げれば、少ないインスタンスで多くのリクエストをさばけて、起動回数とコストを抑えられます。既定値はデプロイ経路で変わります。Google Cloud CLIまたはTerraformでデプロイしたインスタンスの上限はvCPU数の80倍で、1vCPUなら80、2vCPUなら160という計算です。コンソールからのデプロイは一律80が既定値で、いずれも最大1,000まで引き上げられます（[同時実行の公式ドキュメント](https://docs.cloud.google.com/run/docs/about-concurrency)・2026年9月16日更新）。1リクエストで多くのメモリやCPUを使う重い処理では、逆にこの値を下げます。関数単位で原則1リクエストずつ処理していた従来型のサーバーレスと違い、この調整幅こそがCloud Runの効きどころです。 ### コンテナを動かす第1世代と第2世代の実行環境の違いと選び分け Cloud Runは、コンテナを動かす実行環境として第1世代（gen1）と第2世代（gen2）を選べます。第1世代はgVisorによるサンドボックスで、システムコールをエミュレートする分だけLinux互換性が部分的になる代わりに、コールドスタートが速い実行環境です。第2世代はmicroVM上で動き、すべてのシステムコールに対応し、ネットワークファイルシステム（NFS）のマウントにも対応します。CPUとネットワークも速く、パケットロスのある経路では差が出ます。制約は最小メモリで、第2世代には512MiB以上が必要です。料金は両者で同じ。既定では実行環境が未指定の状態で、Cloud Runが自動で選びます。起動の速さを取るなら第1世代を明示し、互換性やマウントの要件で引っかかったら第2世代へ切り替える、という順序で判断すると迷いにくいでしょう。差分は[実行環境の比較ドキュメント](https://docs.cloud.google.com/run/docs/configuring/execution-environments)に一覧があります。 ## gcloud run deployでコンテナを公開するまでの実装手順 ここからは手を動かす段です。イメージを置いてから公開し、トラフィックを移すまでを、そのまま打てるコマンドで示します。 ### コンテナイメージのデプロイ実装フローとレジストリ連携の全体像 実装面では、コンテナイメージを[Artifact Registry](https://www.issoh.co.jp/tech/details/15559/)などのレジストリへ格納し、そのイメージを指定してCloud Runへデプロイする流れが基本です。イメージの保管とバージョン管理、脆弱性スキャンの設計は、デプロイの安定に効きます。レジストリの種類や選び方は[コンテナレジストリとは何か・種類と選び方を解説した記事](https://www.issoh.co.jp/tech/details/13259/)で先に押さえておくと迷いません。継続的デリバリーを昇格・承認付きで自動化したいなら、[GKE/Cloud RunへのマネージドCDのCloud Deploy](https://www.issoh.co.jp/tech/details/15673/)でリリースとロールバックを標準化できます。 ### ソースとイメージの2経路でサービスを公開するgcloudコマンド デプロイの入口は2つあります。`--source` を指定すれば、Dockerfileを持たないアプリでもビルドからデプロイまで1コマンドで通る経路です。イメージを自分で管理するなら、Artifact Registryのパスを `--image` で渡します。下は東京リージョンへ公開する例で、同時実行80・最小1インスタンス・タイムアウト300秒を明示しました。 ``` # ソースから直接デプロイする（Dockerfile が無くてもビルドされる） gcloud run deploy cloudrun-demo \ --source . \ --region asia-northeast1 \ --allow-unauthenticated # Artifact Registry のイメージを指定してデプロイする gcloud run deploy cloudrun-demo \ --image asia-northeast1-docker.pkg.dev/PROJECT_ID/app/demo:v1 \ --region asia-northeast1 \ --concurrency 80 \ --min-instances 1 --max-instances 10 \ --cpu 1 --memory 512Mi \ --timeout 300 \ --no-allow-unauthenticated ``` `--allow-unauthenticated` を付けると allUsers に Invoker ロールが付与され、公開URLを誰でも呼べる状態になります。社内向けなら `--no-allow-unauthenticated` で閉じたうえ、IAMで呼び出し元を絞る手順です。フラグの一覧は公式の[サービスのデプロイ手順](https://docs.cloud.google.com/run/docs/deploying)にあります。公開URLの手前で独自ドメインやWAF、複数リージョンの振り分けを受けるなら、[Cloud Load Balancingの種類と選び分けを解説した記事](https://www.issoh.co.jp/tech/details/15669/)で前段を先に決めると手戻りが減ります。 ### トラフィック分割による段階移行とワーカープール常駐のコマンド操作 新しいリビジョンをいきなり全量へ当てず、割合を刻んで移すのが標準的な進め方です。`update-traffic` で比率を指定し、問題が出たら旧リビジョンへ全量を戻します。キューを読み続ける常駐処理は、サービスではなくワーカープールとして別に立てます。 ``` # 新リビジョンへ 10% だけ流す（残り 90% は直前のリビジョン） gcloud run services update-traffic cloudrun-demo \ --region asia-northeast1 \ --to-revisions LATEST=10 # 問題が出たら特定リビジョンへ全量を戻す gcloud run services update-traffic cloudrun-demo \ --region asia-northeast1 \ --to-revisions cloudrun-demo-00012-abc=100 # キュー処理用のワーカープールを立てる gcloud run worker-pools deploy queue-worker \ --image asia-northeast1-docker.pkg.dev/PROJECT_ID/app/worker:v1 \ --region asia-northeast1 ``` ジョブを毎日決まった時刻に走らせる配線は、スケジューラ側が担います。cron式・ターゲット・リトライの設計は[Cloud Schedulerのフルマネージドcronを解説した記事](https://www.issoh.co.jp/tech/details/15746/)にまとめました。マネージドRDBへつなぐ構成なら、[Cloud SQLの仕組みとエディションを解説した記事](https://www.issoh.co.jp/tech/details/15551/)で接続方式を押さえておくと、同時実行数を上げたときの接続数を見積もれます。 ## Cloud Runの料金モデルとGKE・Cloud Functionsとの違い 基盤選定の決め手は、料金の積み上がり方と、近い立ち位置のGKE・Cloud Run functionsとの役割の差です。公開するAPIの前段に認証・監視を足すなら、[Cloud Endpointsとは何か・GCPのAPI管理の仕組みを解説した記事](https://www.issoh.co.jp/tech/details/15675/)が参考になります。 ### リクエストベース課金とインスタンスベース課金の使い分けの判断軸 Cloud Runの料金は2つの課金方式から選べます。リクエストベース課金は、処理中に割り当てたCPUとメモリの時間を100ミリ秒単位で切り上げ、リクエスト数にも課金する方式です。アクセスが無い時間はインスタンスが縮んで課金も止まるため、トラフィックにムラがある用途で無駄が出にくくなります。インスタンスベース課金はリクエストの有無にかかわらずCPUを割り当て続ける方式で、常時バックグラウンド処理を回すアプリに向きます。東京リージョンを含むティア1の実額は下表のとおりで、無料枠はリクエストベースが月180,000vCPU秒・360,000GiB秒・200万リクエスト、インスタンスベースが月240,000vCPU秒・450,000GiB秒でした（2026年9月時点の[公式の料金ページ](https://cloud.google.com/run/pricing)）。待機コストを削りたいならリクエストベース、常に動かし続けるならインスタンスベースという軸で選びます。 | 課金方式 | CPU単価（1vCPU秒） | リクエスト課金 | 向く用途 | | --------- | ------------- | ----------- | ----------- | | リクエストベース | 稼働中0.000024ドル | 100万件0.40ドル | ムラのあるアクセス | | インスタンスベース | 0.000018ドル | なし | 常駐・バックグラウンド | | ワーカープール | 0.000011244ドル | なし | キューの常駐処理 | 最小インスタンスを1以上に張ったときのアイドル時間は、リクエストベースでも1vCPU秒あたり0.000002500ドルが積み上がります。常時1インスタンスを温める構成は月およそ2,592,000秒ぶんが課金対象なので、コールドスタート対策の費用は先に見積もっておきます。 ### GKEとの違いはクラスタを持つか持たないかという運用の粒度の差 GKE（Google Kubernetes Engine）は、Kubernetesをベースにコンテナ群を運用するマネージドサービスで、ノードやクラスタを自分で持ち、スケジューリングやネットワーク、権限を細かく制御できます。自由度が高い反面、クラスタの設計と運用という手間は否めません。Cloud RunはKnative由来の仕様に沿い、クラスタを持たずにコンテナ単位でデプロイするため、運用の負担が小さく済みます。ノード制御や独自のオーケストレーションが要るならGKE、手早く動かしたいならCloud Runという分岐です。Kubernetesそのものの必要性は、[コンテナオーケストレーションとは何か・自社に必要かの判断を解説した記事](https://www.issoh.co.jp/column/details/13003/)が判断材料になります。 ### Cloud Functions（Cloud Run functions）との違い Cloud Functionsは、ソースコードだけをデプロイして関数単位でイベントに応答する軽量なサーバーレスです。コンテナを意識せずに単純な処理を載せられる手軽さがある一方、実行環境の自由度はCloud Runより狭い形になります。関数側の定義・トリガー・料金と実装は[Google Cloud Functionsとは？仕組みと採用判断](https://www.issoh.co.jp/tech/details/15538/)で詳しく解説しました。名称はすでに切り替わっており、旧第2世代はCloud Run functionsとしてCloud Run上のサービスへデプロイされ、旧第1世代はCloud Run functions（第1世代）と呼ばれます。統合に伴って上限も広がり、メモリは8GBから最大16GiB、1インスタンスあたりの同時実行は1件から最大1,000件、HTTP関数のタイムアウトは9分から最大60分になりました。イベント起点の小さな処理を最短で載せたいならCloud Run functions、コンテナをそのまま動かしたいならCloud Runという目安です。 ## Cloud Runを採用すべき条件と見送るべき場面の判断基準 ここでは判断を言い切ります。Cloud Runはコンテナを手早く動かすことに強い反面、あらゆるワークロードの受け皿ではありません。 ### Cloud Runの採用が効くワークロードと要件の条件の見極め 採用が効くのは、コンテナで動くアプリを、クラスタ運用の手間を負わずにデプロイし、アクセスのムラに合わせてスケールさせたい、という条件が重なるときです。具体例は、トラフィックが読みにくいWeb API・Webhookの受け口、社内向けの管理画面、日次バッチやデータ変換のジョブ、コンテナ化した既存アプリの移行案件です。待機時間の長いサービスをゼロスケールで安く保ちたい、コンテナはそのまま使いたいがKubernetesの運用までは持ちたくない、という要件で効きます。Google Cloud上のコンテナ実行基盤を自社に取り入れるなら、[AWS・Google Cloudを含むクラウドインフラ構築の相談窓口](https://www.issoh.co.jp/service/system/aws/)で、サービス／ジョブ／ワーカープールの切り分けや料金方式の妥当性を相談するとよいでしょう。 ### Cloud Runでは向かない要件とGKEや関数型へ寄せる場面 ノード単位の独自スケジューリングやサイドカー構成を細かく作り込みたい要件、ステートフルな接続を自前で制御したい要件は、Cloud Runでは窮屈になります。この場合はGKEでクラスタを持つ設計へ寄せるのが素直でしょう。ただし「リクエストに紐づかない常駐処理を動かしたい」という理由だけでGKEを選ぶ判断は、2026年4月のワーカープールGAで前提が変わりました。GKEへ寄せる根拠は、ノード制御やオーケストレーションの必要性へ絞り直してください。運用モード（Autopilot／Standard）と料金は[Google Kubernetes Engine（GKE）とは](https://www.issoh.co.jp/tech/details/15661/)で確認できます。1リクエストの処理が60分を超える、あるいは特殊なプロトコルを常時待ち受ける用途も、Cloud Runのサービスとは噛み合いません。単発のイベント処理を最短で回したいだけなら、コンテナを組む手間の要らないCloud Run functionsを選びます。 ## よくある質問 Cloud Runの導入検討で実装者から多く挙がる質問を、一次情報に基づいて整理します。 ### Cloud RunとGKEはどう使い分ければよいですか？ コンテナをクラスタ運用の手間なく動かし、アクセスのムラに合わせてスケールさせたいならCloud Run、ノードを自分で持って細かな制御や独自のオーケストレーションを組みたいならGKEが基本の分岐です。リクエスト駆動でない常駐ワーカーは2026年4月にGAしたワーカープールで受けられるため、その用途だけでGKEを選ぶ理由は薄くなりました。 ### Cloud RunとCloud Functionsの違いは何ですか？ Cloud Functionsはソースだけをデプロイして関数単位でイベントに応答する形態、Cloud Runはコンテナをそのまま動かせる形態という違いです。名称はすでにCloud Run functionsへ切り替わり、旧第2世代はCloud Run上のサービスとしてデプロイされます。メモリ最大16GiB・同時実行最大1,000件・HTTP関数のタイムアウト最大60分まで広がりました。 ### Cloud Runのコールドスタートはどう抑えますか？ 最小インスタンス数を1以上に保って常に温めておくのが第一の打ち手です。gVisorベースで起動の速い第1世代の実行環境を明示する、イメージを軽くして起動時間を短くする、という手も効きます。ただし最小インスタンスのアイドル時間は1vCPU秒あたり0.000002500ドルが積み上がるので、待機コストと応答の安定は金額で比べて決めてください。 ### Cloud Runの料金はどのように決まりますか？ リクエストベース課金は処理中のCPUとメモリの時間を100ミリ秒単位で切り上げ、リクエスト数にも課金します。東京リージョンが属するティア1では稼働中CPUが1vCPU秒あたり0.000024ドル、リクエストは100万件あたり0.40ドルです。インスタンスベース課金はアイドル時もCPUを割り当てて1vCPU秒あたり0.000018ドルが積み上がります（2026年9月時点）。 ### Cloud Runでバッチ処理は動かせますか？ 動かせます。処理を実行して完了したら終わるジョブという形態があり、日次集計やデータ変換、メンテナンススクリプトをコンテナとして走らせられる形です。ジョブは走り切ると課金も止まります。並列で分割したいときは複数タスクを同時に走らせるArray jobsが使えます。 ## 関連記事 - [サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](https://www.issoh.co.jp/column/details/13005/)：Cloud Runの前提となるサーバーレスの考え方を整理した上位概念の記事 - [コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説](https://www.issoh.co.jp/column/details/13000/)：Cloud Runが動かす対象の基礎を解説した記事 - [コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](https://www.issoh.co.jp/tech/details/13259/)：デプロイ元になるイメージ格納庫の選び方を解説した記事 - [コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説](https://www.issoh.co.jp/column/details/13003/)：GKEとの比較の前提になる必要性判断を整理した記事 - [Cloud CDNとは？Google Cloudの仕組み・キャッシュモードと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15667/)：Cloud Runをオリジンに据えて配信を高速化するCDNの記事 --- 出典: [Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説]()（株式会社一創）