Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説

Cloud Runは、任意の言語で書いたアプリをコンテナにして渡すだけで、サーバーの用意やクラスタ管理をせずに動かせるGoogle Cloudのサーバーレスコンテナ実行基盤です。この記事では、サービスとジョブという2つの実行形態、リクエスト数に応じてインスタンスを0まで縮めるゼロスケール、1インスタンスで複数リクエストをさばく同時実行、第1世代と第2世代の実行環境、そしてリクエストベースとインスタンスベースの料金モデルを一次情報で整理します。運用の自由度が高いGKE（Google Kubernetes Engine）や、関数単位のCloud Functionsとの違い、Cloud Runを採用すべき条件と見送るべき場面の判断基準まで、実装者が基盤選定で迷う論点を具体的に示します。

まとめ：Cloud Runの仕組みと採用判断の要点

Cloud Runは、コンテナイメージを渡すだけでスケール管理なしにアプリを動かせるサーバーレス基盤です。HTTPやイベントで常駐するサービスと、処理を終えたら止まるジョブの2形態があり、デプロイはリビジョン単位でトラフィックを分割しながら段階的に切り替えられます。アクセスが無ければインスタンスを0まで縮め、リクエストが増えれば自動で増やすため、待機時のコストを抑えながら急な負荷にも追随できます。コンテナで動くので、言語やフレームワークをGoogle Cloud側の制約に合わせて選び直す必要がありません。

料金は、リクエストを処理している間のCPUとメモリの時間をミリ秒粒度で課金するリクエストベースと、アイドル時もCPUを割り当て続けるインスタンスベースを選べる構造です。クラスタやノードを自分で持って運用の自由度を取りたいならGKE、関数単位の軽いイベント処理ならCloud Functions、その中間でコンテナのまま手間を減らしたいならCloud Runという棲み分けになります。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて選定してください。

Cloud Runの仕組みとサーバーレスコンテナという位置づけの整理

Cloud Runを設計へ落とし込むには、まず「サーバーレスとコンテナを同時に取る」という立ち位置を押さえます。ここが曖昧だと、GKEやCloud Functionsとの役割の境目を見誤り、過剰な運用や不要な作り込みを抱え込みかねません。サーバーレスという考え方そのものから確認したい場合は、サーバーレスとは何か・コンテナとの使い分けを解説した記事が上位の入り口になります。

サーバーレスとコンテナを両取りするCloud Runの設計思想

従来のサーバーレスは、あらかじめ用意された言語ランタイムに関数を載せる形が主流で、実行環境の自由度に制約がありました。Cloud Runは、その制約を、コンテナを実行単位にすることで外します。任意の言語やライブラリを含むコンテナイメージを用意すれば、Google Cloud側はそのイメージをリクエストに応じて起動・停止するだけを担い、OSやミドルウェアの構成はコンテナの中で自由に決められる点が持ち味です。コンテナという単位そのものを整理したい場合は、コンテナとは何か・仮想マシンとの違いから解説した記事で前提を固めておくと、この「持ち込んだ環境がそのまま動く」利点が理解しやすくなります。

サービスとジョブというCloud Runの2つの実行形態の違い

Cloud Runには、用途の異なる2つの実行形態があります。1つはサービスで、HTTPリクエストやイベントを受けて応答する常駐型の使い方です。WebアプリやAPI、Webhookの受け口がこれに当たり、リクエストが来ると起動し、途切れると縮小します。もう1つはジョブで、バッチ処理のように「実行して完了したら終わる」タスク向けです。日次の集計やデータ変換、メンテナンススクリプトなどをコンテナとして走らせ、終われば課金も止まります。同じCloud Runでも、常時受け付けるサービスと、走り切って終わるジョブでは設定と料金の考え方が変わるため、まず自分のワークロードがどちらかを見極めます。

リビジョンとトラフィック分割による段階的なリリースの仕組みと復旧

Cloud Runでは、デプロイのたびにリビジョンという不変のスナップショットが作られます。新しいイメージや設定を反映すると新リビジョンが生成され、旧リビジョンはそのまま残る点が特徴です。この仕組みにより、新リビジョンへ最初は数％だけトラフィックを流し、問題がなければ割合を上げていくカナリアリリースや、旧新を並行させた段階的な切り替えが設定だけで組めます。不具合が出た場合も、トラフィックを旧リビジョンへ戻すだけで素早く復旧でき、デプロイに伴う停止時間を作らずに更新を回せます。

Cloud Runのスケーリング・同時実行と実行環境の設計前提

次に押さえるのが、リクエストに合わせてインスタンスを増減させるスケーリングの挙動と、1インスタンスがどれだけのリクエストを同時にさばくかという同時実行の設定です。ここの理解が、性能とコストの両面を左右します。

ゼロスケールと最小・最大インスタンス数によるスケール設計の勘所

Cloud Runは、リクエスト数に応じてコンテナインスタンスを自動で増減させます。特徴的なのは、アクセスがまったく無い時間帯にインスタンス数を0まで縮められる点で、待機だけのコストが発生しません。一方で、0からの起動には初回の立ち上がり（コールドスタート）の遅延が伴うため、応答速度をそろえたいサービスでは最小インスタンス数を1以上に保ち、常に温めておく設定を選びます。急増するアクセスに上限を設けたい場合は最大インスタンス数を定め、想定外のスパイクでコストや下流の負荷が跳ねないよう抑えます。待機コストを取るか応答の安定を取るかを、サービスの性質に合わせて決めるのが設計の起点です。

コンテナ同時実行数（concurrency）という他サービスとの分岐点

Cloud Runの大きな特徴が、1つのコンテナインスタンスで複数のリクエストを同時に処理できる点です。この同時実行数（concurrency）を上げれば、少ないインスタンスで多くのリクエストをさばけて、起動回数とコストを抑えられます。逆に、1リクエストで多くのメモリやCPUを使う重い処理では、同時実行数を下げて1インスタンスあたりの負荷を軽くします。関数単位で原則1リクエストずつ処理する従来型のサーバーレスと違い、この同時実行の調整幅こそがCloud Runの効きどころです。既定値や上限はGoogle Cloud公式のドキュメントで対象時点を実測し、自分のワークロードの処理特性に合わせて調整してください。

コンテナを動かす第1世代と第2世代の実行環境の違いと選び分け

Cloud Runは、コンテナを動かす実行環境として第1世代（gen1）と第2世代（gen2）を選べます。第1世代は軽量で起動が速く、コールドスタートを短くしたい一般的なWeb用途に向く選択肢です。第2世代はLinuxとの互換性が高く、ネットワークファイルシステムのマウントや、より広いシステムコールを要するミドルウェアなど、通常のサーバーに近い挙動が要る場合に効きます。まずは起動の速い第1世代を基準に置き、互換性やマウントの要件で引っかかったら第2世代へ切り替える、という順序で判断すると迷いにくいでしょう。数値や対応範囲は断定せず、公式ドキュメントで時点を確認して確定させてください。

Cloud Runの料金モデルとGKE・Cloud Functionsとの違い

基盤選定の決め手になるのが、料金の積み上がり方と、近い立ち位置のGKE・Cloud Functionsとの役割の差です。ここを条件で切り分けます。

リクエストベース課金とインスタンスベース課金の使い分けの判断軸

Cloud Runの料金は、大きく2つの課金方式から選べます。リクエストベース課金は、リクエストを処理している間だけ割り当てたCPUとメモリの時間をミリ秒粒度で課金し、加えてリクエスト数に対して課金する方式です。アクセスが無い時間はインスタンスが縮んで課金も止まるため、トラフィックにムラがある用途で無駄が出にくくなります。もう1つのインスタンスベース課金は、リクエストの有無にかかわらずインスタンスにCPUを割り当て続ける方式で、常時バックグラウンド処理を回すアプリや、コールドスタートを避けたい常駐処理に向く方式です。アクセスパターンが読めない、あるいは待機時のコストを削りたいならリクエストベース、常に動かし続けるならインスタンスベース、という軸で選びます。

GKEとの違いはクラスタを持つか持たないかという運用の粒度の差

GKE（Google Kubernetes Engine）は、Kubernetesをベースにコンテナ群を運用するマネージドサービスで、ノードやクラスタを自分で持ち、スケジューリングやネットワーク、権限を細かく制御できます。自由度が高い反面、クラスタの設計と運用という手間を引き受ける点は否めません。Cloud RunはKnative由来の仕様に沿い、クラスタを持たずにコンテナ単位でデプロイするため、運用の負担が小さく済みます。細かなノード制御や独自のオーケストレーションが要るならGKE、まずコンテナを手早く動かして運用を軽くしたいならCloud Runという分岐です。Kubernetesによる運用そのものの必要性を見極めたい場合は、コンテナオーケストレーションとは何か・自社に必要かの判断を解説した記事が判断材料になります。

Cloud Functions（Cloud Run functions）との違い

Cloud Functionsは、ソースコードだけをデプロイして関数単位でイベントに応答する軽量なサーバーレスです。コンテナを意識せずに単純な処理を載せられる手軽さがある一方、実行環境の自由度はCloud Runより狭くなります。2026年時点では、この関数型のサーバーレスがCloud Run functionsとしてCloud Runの枠組みへ統合される流れにあり、両者の境目は近づいています。目安としては、HTTPやイベントを起点にした小さな処理を最短で載せたいならCloud Functions（Cloud Run functions）、任意の言語やミドルウェアを含むコンテナをそのまま動かし、同時実行や実行環境を調整したいならCloud Runと考えるとよいでしょう。

Cloud Runを採用すべき条件と見送るべき場面の判断基準

ここでは判断を言い切ります。Cloud Runはコンテナを手早く動かすことに強い反面、あらゆるワークロードの受け皿ではありません。自社システムの実行基盤をどこに置くかを、条件付きで見極めてください。

Cloud Runの採用が効くワークロードと要件の条件の見極め

採用が効くのは、コンテナで動くアプリを、クラスタ運用の手間を負わずにデプロイし、アクセスのムラに合わせてスケールさせたい、という条件が重なるときです。具体例は、トラフィックが読みにくいWeb API・Webhookの受け口、社内向けの管理画面、日次バッチやデータ変換のジョブ、コンテナ化した既存アプリをそのまま載せたい移行案件が当てはまります。特に、待機時間の長いサービスをゼロスケールで安く保ちたい、コンテナはそのまま使いたいがKubernetesの運用までは持ちたくない、という要件で効きます。こうしたGoogle Cloud上のコンテナ実行基盤を自社に取り入れるなら、AWS・Google Cloudを含むクラウドインフラ構築の相談窓口で、サービス/ジョブの切り分けやスケーリング設定、料金方式の妥当性を相談するとよいでしょう。

Cloud Runでは向かない要件とGKEや関数型へ寄せる場面

常時サーバーを起動しておき、長時間の常駐プロセスやステートフルな接続を細かく制御したい、あるいはノード単位の独自スケジューリングやサイドカー構成を作り込みたい要件は、Cloud Runでは窮屈になります。この場合はGKEでクラスタを持つ設計へ寄せるのが素直でしょう。逆に、ソースだけを載せて単発のイベント処理を最短で回したいなら、コンテナを組む手間の要らない関数型のCloud Functionsが向きます。リクエストの処理時間が極端に長い、あるいは特殊なプロトコルを常時待ち受ける用途も、Cloud Runの前提と噛み合わないことがあるため、処理の形（都度応答か常駐か）と運用の粒度を軸に選定してください。

コンテナイメージのデプロイ実装フローとレジストリ連携の全体像

実装面では、コンテナイメージをArtifact Registryなどのコンテナレジストリへ格納し、そのイメージを指定してCloud Runへデプロイする流れが基本です。ソースコードから直接ビルドしてデプロイする経路もあり、Dockerfileを持たないアプリでもビルドツールがイメージを生成します。イメージの保管とバージョン管理、脆弱性スキャンといったレジストリ側の設計は、デプロイの安定に効く部分です。レジストリの種類や選び方を固めておきたい場合は、コンテナレジストリとは何か・種類と選び方を解説した記事を先に押さえておくと、Cloud Runへのデプロイ経路を組みやすくなります。

よくある質問

Cloud Runの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Cloud RunとGKEはどう使い分ければよいですか？

コンテナをクラスタ運用の手間なく手早く動かし、アクセスのムラに合わせてスケールさせたいならCloud Run、ノードやクラスタを自分で持って細かな制御や独自のオーケストレーションを組みたいならGKEが基本の分岐です。Cloud RunはKnative由来でインフラを持たず運用が軽く、GKEはKubernetesベースで自由度が高い代わりに運用の手間を引き受けます。運用の粒度を軸に選びます。

Cloud RunとCloud Functionsの違いは何ですか？

Cloud Functionsはソースだけをデプロイして関数単位でイベントに応答する軽量な形態で、Cloud Runは任意の言語やミドルウェアを含むコンテナをそのまま動かせる点が違います。2026年時点では関数型がCloud Run functionsとしてCloud Runへ統合される流れにあり、単純な処理は関数型、コンテナや同時実行の調整が要るならCloud Runという目安で選びます。

Cloud Runのコールドスタートはどう抑えますか？

インスタンスを0まで縮めるゼロスケールでは初回起動の遅延が出るため、応答速度をそろえたいサービスでは最小インスタンス数を1以上に保ち、常に温めておく設定にします。加えて、起動の速い第1世代の実行環境を選ぶ、コンテナイメージを軽くして起動時間を短くする、といった打ち手で遅延を抑えられます。待機コストと応答の安定のバランスで決めてください。

Cloud Runの料金はどのように決まりますか？

リクエストベース課金では、リクエストを処理している間のCPUとメモリの時間をミリ秒粒度で課金し、リクエスト数にも課金します。インスタンスベース課金では、アイドル時もCPUを割り当て続けて課金する仕組みです。ムラのあるアクセスは前者、常時動かす処理は後者が向きます。具体的な単価と無料枠は公式ドキュメントで対象時点を確認してください。

Cloud Runでバッチ処理は動かせますか？

動かせます。常駐して応答するサービスとは別に、処理を実行して完了したら終わるジョブという形態があり、日次集計やデータ変換、メンテナンススクリプトをコンテナとして走らせられる形です。ジョブは走り切ると課金も止まるため、定期的なバッチをコンテナのまま運用したい場合に向きます。サービスとジョブのどちらが要件に合うかで設定を選びます。

関連記事

• サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説：Cloud Runの前提となるサーバーレスの考え方を事業者向けに整理した上位概念の記事
• コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説：Cloud Runが動かす対象であるコンテナの基礎を解説した記事
• コンテナレジストリとは？種類・選び方から企業の導入判断まで解説：Cloud Runのデプロイ元になるイメージ格納庫の選び方を解説した記事
• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説：GKEとの比較の前提になるオーケストレーションの必要性を整理した記事