GCP Cloud Runとは｜サーバレスの仕組み・AWS Lambdaとの違い・案件単価をフリーランス視点で解説

Cloud Runの基礎｜コンテナで動かすサーバレス

Cloud Runは、コンテナイメージをアップロードするだけでHTTPSエンドポイントが払い出され、リクエストに応じてインスタンスが自動で起動・停止するサービスです。Knative（Kubernetes上のサーバレス標準）をベースに、Google Cloudがマネージド提供しています。

「サーバレス」と聞くとAWS Lambdaのような関数実行を思い浮かべる人が多いものの、Cloud Runは「コンテナをそのまま投げ込めるサーバレス」という立ち位置です。Node.js、Python、Go、Java、PHPなど、Dockerfileで動かせるものはほぼ何でも乗ります。

Cloud Runの主な特徴

• HTTPS/gRPC/WebSocketに対応したフルマネージドな実行環境

• リクエスト数に応じてゼロから自動スケール（最小0、最大はサービスごとに設定）

• 同一インスタンスで複数リクエストを並列処理できる（既定80・最大1000）

• 任意のコンテナイメージを利用可能。コンテナ資産はGKE Autopilotなどに移しやすい一方、IAM・監視・周辺サービスはGoogle Cloud依存が残る点には注意

• リージョン単位のサービスで、グローバルロードバランサと組み合わせるとマルチリージョン構成も組める

想定される使いどころ

公式ドキュメントの全体像はCloud Run overview - Google Cloudを参照してください。

ミニFAQ｜Cloud Run と Cloud Run functions の関係

Q. Cloud Run functions は別物ですか？

かつての「Cloud Functions」が、現在はCloud Run functionsとして統合されています。実体はCloud Runサービスの上に関数実行モデルを乗せたもので、ソースコード（関数）を渡せばGoogle側でコンテナビルドまで自動化してくれるイメージです。コンテナを自分でビルドしたい場合はCloud Run、関数とトリガーだけ書いて済ませたい場合はCloud Run functionsを選ぶ、という整理になります。

Cloud Runの仕組み｜コンテナ・リビジョン・トラフィック

Cloud Runのアーキテクチャは、シンプルですが押さえておくべき概念がいくつかあります。

コンテナ起動の流れ

1. DockerイメージをArtifact Registry（Google製のコンテナレジストリ）にPush

2. gcloud run deploy コマンドでサービスを作成。新しいリビジョンが払い出される

3. リクエストが来ると、Cloud Runはコンテナを起動してPORT環境変数のポートにHTTPリクエストを転送

4. リクエストが落ち着くとインスタンスは自動で停止（最小0の場合）

リビジョンはイミュータブルで、変更があるたびに新しいリビジョンが作られます。これを活用するとカナリアリリース（例：90% : 10%でトラフィック分割）が標準機能だけで実現できます。

自動スケールの考え方

• 同時実行数（concurrency）：1インスタンスが同時に捌くリクエスト数。既定80。WebアプリやAPIではここを正しく設定するだけでコストが大きく変わる

• 最小インスタンス数（min-instances）：0にすると完全に従量課金。1以上に設定するとコールドスタートを避けられる代わりにアイドル料金が発生する

• 最大インスタンス数（max-instances）：意図しないスケールアウトによるコスト爆発を防ぐためのリミッタ

Lambdaは「1関数=1リクエスト」が原則のため、トラフィックが増えるとインスタンス数が線形に伸びます。Cloud Runは同時実行数を上げれば1コンテナで複数リクエストを捌けるため、インスタンス本数を抑えやすいのが特徴です。

コールドスタートとプリウォーム

最小インスタンスを0にしている場合、しばらくリクエストが無いとインスタンスは停止します。次のリクエストではコンテナの起動時間＋アプリの初期化時間が遅延として乗ります（コールドスタート）。

軽減策はいくつかあります。実際の効果はワークロードによって変わるため、設計段階で計測しながら選択することが推奨されます。

• 最小インスタンスを1以上に設定する（アイドル料金は発生）

• CPU always-allocatedを選び、起動後のバックグラウンド処理や初期化を含めた挙動を最適化する（CPU設定の見直しが有効な場合がある）

• 起動が重い処理（依存読み込み・モデルロード等）にはCloud Run の Startup CPU Boostの利用を検討する

• 画像サイズを小さく抑える（Alpine / distroless ベースなど）

実運用では「コールドスタートが許容できないエンドポイントだけ min-instances=1、それ以外は0」のように、サービスごとに使い分けるのが現実的です。

Cloud Run・AWS Lambdaの違い｜6つの観点で整理

ここからは検索意図の中心である「AWS Lambdaとの違い」を実務目線で整理します。前提として、両者は「サーバレス」と一括りにできるものの、設計思想が異なるサービスです。

違い①：実行単位（コンテナか関数か）

• Cloud Run：Dockerコンテナを実行。Dockerfileで動くものは何でも持ち込める

• AWS Lambda：関数（ハンドラ）を実行。コンテナイメージにも対応しているが、ベースはランタイム＋ハンドラの仕組み

既存のWebアプリ（Express・Flask・Spring Boot等）をそのままサーバレスに乗せたい場合はCloud Runの方が移行が早くなるケースが多くなります。

違い②：同時処理の仕組み

WebアプリのようにI/O待ちが多いワークロードでは、Cloud Runの方がインスタンス本数が少なくて済むため、コスト・コールドスタート発生頻度の両面で有利になりやすい設計です。

違い③：実行時間の上限

• Cloud Run（サービス）：最大60分まで実行可能

• Cloud Run（ジョブ）：最大24時間

• AWS Lambda：最大15分

長尺のレポート生成・動画変換などはCloud Runの方が組み込みやすくなります。Lambdaで15分を超える場合はStep FunctionsやECS Fargateを併用する必要があるため、構成がやや複雑になります。

違い④：料金モデル

• Cloud Runはリクエスト課金とインスタンス課金の2モデル

• Lambdaはリクエスト数＋実行時間（GB-秒）の固定モデル

Cloud Runの料金はCloud Run pricing - Google Cloudにあるとおり、CPU/メモリの割当時間に対して秒単位で課金されます。リクエスト課金モデルではリクエスト処理中＋短い余裕時間のみ課金され、無リクエスト時は基本的に0円です。

ロード処理の重いWebアプリで「同時実行数を上げて1インスタンスで複数捌く」設計にすると、Lambda換算より安くなるケースもあります。一方、軽量・低頻度・ステートレスな処理ではLambdaの方が安く済むことが多くなります。

違い⑤：コールドスタート

• Cloud Run：コンテナ起動＋アプリ初期化。Startup CPU Boostやmin-instancesで短縮可

• Lambda：ランタイム起動＋関数初期化。Provisioned Concurrencyで短縮可

実測値はランタイムやイメージサイズに依存するため、本記事では具体的なミリ秒数の断定は避けます。実プロジェクトでは負荷試験段階で必ず計測することを推奨します。

違い⑥：ロックインの強さ

• Cloud RunはKnative準拠で、GKE Autopilot / Cloud Run for Anthosなどにイメージごと移しやすい

• LambdaはAWS固有の実行モデル。コンテナサポートはあるが、起動ライフサイクルやイベントソースがAWS依存

「将来GKEに移すかも」「マルチクラウドで動かしたい」というニーズがある場合、Cloud Runを選ぶ意義は大きくなります。

ミニFAQ｜どちらを選ぶべきか

Q. 既にAWSをメインで使っています。Cloud Runに乗り換えるべきですか？

基本的には既存クラウドに揃える方が運用負荷は下がります。ただし、コンテナの並列処理性能や60分上限がボトルネックになるなら、Cloud Runを部分的に併用する選択肢が現実的です。AWS Lambdaの詳細はAWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説で別途解説しています。

Cloud Run・Cloud Run functions・App Engineの使い分け

Google Cloudのサーバレス系は似たサービスが並んでいて迷いやすい領域です。用途で割り切るのが現実的です。

おおまかな選定フローは次の通りです。

1. ソースコードだけ書いてデプロイしたい → Cloud Run functions

2. Dockerfileがある／コンテナで動かしたい → Cloud Run

3. 既にApp Engineで動いている既存資産 → App Engineを維持

公式の選定ガイドはGoogle Cloud computeの選び方が読みやすくまとまっています。

Cloud Runの料金体系｜リクエスト課金とインスタンス課金

Cloud Runのコスト設計はサーバレスの中でも自由度が高い反面、設定を誤ると意図せず常時課金が走ることがあります。

料金モデルの違い

Cloud Run pricingに主要リージョンの単価表があります。最新の単価は公式ページで必ず確認してください。

コスト爆発を避けるためのチェックポイント

コスト見積もりは公式料金ページとGoogle Cloud料金計算ツールで事前確認するのが基本です。そのうえで、運用設計では次の点を優先的に検討するとよいでしょう。

• max-instances の設定を優先的に検討する。既定値のままだと意図せぬスケールアウトでコストが急増する場合がある

• 同時実行数（concurrency）を見直す。低すぎるとインスタンスが無駄に増える

• min-instances は常時起動が必要なサービスだけに絞って設定する

• Cloud Loggingの集約と、Budget Alertによる予算通知を有効化しておく

• 開発環境は起動から数分でアイドルになる構成にしておくと、放置事故が起きにくい

参考事例として、LambdaのつもりでCloud Runを設定して想定外の金額が発生したという個人ブログでの報告もあります（GCPのCloud RunをAWSのLambda感覚で触ったらびっくりする請求が来た話）。主根拠は公式料金ページに置きつつ、実運用での落とし穴の例として参照してください。

ミニFAQ｜無料枠について

Q. Cloud Runに無料枠はありますか？

執筆時点ではGoogle Cloudの「Always Freeプログラム」にCloud Runも含まれており、毎月一定量のリクエスト・vCPU秒・メモリ秒が無料枠として提供されています。ただし金額・対象は変更されることがあるため、公式の料金ページで最新条件を必ず確認してください。

Cloud Runのメリット・デメリット｜現場目線で整理

実プロジェクトでCloud Runを採用するかどうかを判断するときに参考になる観点をまとめます。

メリット

• Docker資産がそのまま乗る：既存リポジトリ・既存CI/CDからの移行が早い

• 同時実行制御が強力：1コンテナで複数リクエストを捌けるため、Lambda比でインスタンス効率が出やすい

• Knative互換：将来GKEに乗り換える際にイメージ・マニフェストを使い回しやすい

• デプロイが速い：gcloud run deploy の1コマンドで本番URLが払い出される

• gRPC・WebSocketに対応：Lambdaでは扱いづらいプロトコルもネイティブに使える

デメリット・注意点

• コンテナの基礎知識が前提：Dockerfile・マルチステージビルド・ベースイメージ選定が必要

• VPCアクセス時にコネクタが必要：プライベートIPのDB・社内APIにつなぐ場合、Serverless VPC Access ConnectorかDirect VPC Egressを構成する

• コールドスタートは設計次第：min-instancesを使うとコストが上がる

• GPU対応リージョン・モデルが限定的：執筆時点ではGPU対応サービスは一部リージョン・特定マシン構成に限られている。GPU対応の可否や対象リージョンは変更されるため、導入前に公式ドキュメントで最新条件を確認してください

• ロギング設計が初見だと迷いやすい：構造化ログ（JSON）でCloud Loggingへ流す前提を意識する

Cloud Runのフリーランス案件動向｜単価と求められるスキル

Cloud Run単体スキルでの案件募集は少なく、「GCP/サーバレス全般」もしくは「Webアプリ開発」案件の構成要素として登場するのが一般的です。

案件単価のレンジ（公開案件の目安）

2026年時点で主要フリーランスエージェント（レバテックフリーランス、フォスターネット、ITプロパートナーズなど）の公開案件ページを目視確認すると、GCP関連の業務委託案件では月額60〜100万円程度の募集が多く見られます。これは「週5日・業務委託・リモート可」を想定した目安で、エージェント・案件・経験年数で大きく変動します。集計時点や抽出条件によっても変わるため、最新の単価感は実案件を直接確認してください。出典は各社の公開案件ページ（レバテックフリーランス GCP案件、フォスターネット GCP案件動向、ITプロパートナーズ GCP案件）を参照してください。

具体的な案件単価については、【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？も併せて参考にしてください。

よく募集される業務内容

• BFFサーバ・Web APIをCloud RunにデプロイするWebアプリ開発

• Cloud Tasks / Pub/Sub と組み合わせた非同期処理基盤の構築・運用

• BigQuery／Cloud SQL／Firestoreなどとの連携アプリ開発

• Cloud Build / Cloud Deploy / GitHub ActionsでのCI/CD整備

• TerraformによるIaC実装とコスト最適化レビュー

• LLM／RAGアプリのバックエンドAPIをCloud RunでGCP上にホスティングする案件

高単価帯で求められる人物像

月額80万円以上のレンジでよく求められる経験を整理すると、1スキル単体ではなく組み合わせで評価される傾向があります。

• GCP実務2〜3年以上＋AWSなど他クラウドの経験

• Python / Go / Node.jsなどでのWebアプリ・APIサーバ開発経験

• DockerとCI/CD（Cloud Build・GitHub Actions等）でのデプロイ自動化経験

• Terraformによるインフラ管理経験（Terraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説）

• BigQueryやCloud SQLとの組み合わせでのデータ基盤構築経験（BigQueryとは？特徴・できること・データ分析案件の単価をフリーランス視点で解説）

• 監視・SLO設計（Cloud Monitoring・Cloud Logging）の経験

「Cloud Runだけ書ける」状態より、Docker + Terraform + 何かしらの言語スタックまで揃った状態の方が、案件の選択肢は明確に広がりやすくなります。

ミニFAQ｜AWS経験しかない場合の入口

Q. AWSしか触ったことがありません。Cloud Runを案件で使えるレベルまでどれくらい必要ですか？

Dockerでアプリを動かせる前提なら、Cloud Run自体は1〜2週間程度のハンズオンで基本操作・デプロイ・IAM設定までは習得できるケースが多くなります。ただしCloud BuildやVPCコネクタ、Cloud SQLとの接続など周辺サービスの理解が案件選定の差を生むため、ハンズオンを通して周辺サービスを含めて触っておくとよいでしょう。

Cloud Runの始め方｜最短ハンズオン手順

ここでは「とにかく動かしてみる」段階の手順を整理します。詳細な準備は公式クイックスタートを参照してください。

必要な準備

1. Google Cloudアカウント（無料トライアル可）

2. gcloud CLI のインストール

3. Docker のインストール（ローカルでイメージビルドする場合）

4. プロジェクト作成と請求先アカウントのリンク

5. Cloud Run API・Artifact Registry APIの有効化

最小構成のデプロイ手順

具体的なgcloudコマンド例は公式ドキュメントに譲りますが、流れは次の通りです。

1. アプリのDockerfileを用意する

2. ローカルでDockerビルドして動作確認

3. Artifact Registryへイメージをプッシュ

4. gcloud run deploy でサービスを作成

5. 払い出されたHTTPS URLにアクセスして疎通確認

gcloud run deploy --source . を使うと、Dockerfileがなくてもソースコードから自動ビルドしてくれます（内部でBuildpacksが使われる）。まず動かす段階ではこちらが手軽です。

学習を進めるおすすめ順序

1. Cloud Runで「Hello World」を動かす

2. 環境変数とシークレット管理（Secret Manager連携）に進む

3. Cloud SQLへの接続（Cloud SQL Auth Proxy or Private IP）を試す

4. Cloud Buildで自動デプロイするパイプラインを組む

5. Terraformでインフラをコード化して再現性を確保する

6. 監視・ログ設計を整える（Cloud Logging / Cloud Monitoring / Error Reporting）

7. 余裕があればCloud Run for Anthos / GKE Autopilotまで触ってKnative互換性を体感する

Cloud Runを学ぶ際に押さえたい関連サービス

Cloud Run単独で完結する案件は少なく、周辺サービスを含めて理解すると現場で詰まりにくくなります。

コンテナ・基盤系

• Docker：Cloud Runの前提技術。Dockerfile・マルチステージビルドは押さえておく（Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説）

• Kubernetes：Cloud Runの内部はKnative＋Kubernetes。本格的なオーケストレーションが必要になったら（Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説）

• Terraform：複数環境（dev/stg/prd）を運用するなら必須レベル（Terraformとは？）

データ・連携系

• BigQuery：Cloud Runで集計APIを書くとき、裏側がBigQueryになるケースが多い

• Firestore / Firebase：軽量なWebサービスではこちらが多用される（Firebaseとは？特徴・主要サービス・案件単価をフリーランス視点で徹底解説）

• Cloud SQL：Postgres / MySQL を使う案件で頻出

• Pub/Sub / Cloud Tasks：非同期処理・イベント駆動の中核

CI/CD・開発支援

• Cloud Build / Cloud Deploy：GCP内で完結したいときに採用される

• GitHub Actions：他クラウドや既存リポジトリと組み合わせるならこちら（GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説）

Cloud Runを選ぶか迷ったときの判断軸

最後に、Cloud Run採用の判断を整理します。

Cloud Runが向くケース

• 既存のDockerアプリ・Webアプリをサーバレス化したい

• 並列処理量が多く、1リクエスト=1インスタンスでは効率が悪い

• 60分の処理時間が必要・WebSocketや双方向通信を使いたい

• 将来GKEに移す可能性がある

• AWS Lambdaの15分制約・1リクエスト=1関数で困っている

Cloud Runが必ずしも向かないケース

• 関数ベースで小さく書ければ十分。トリガーが主にPub/Sub・GCSの単発処理 → Cloud Run functionsが向く

• 既存App Engineで運用が回っている → 無理に移行しない方が無難

• AWSで完結させたい（運用負荷・体制都合） → Lambda + ECS Fargateの組み合わせも一案

まとめ｜Cloud Runは「コンテナそのままのサーバレス」

Cloud Runは任意のコンテナをそのままサーバレスに乗せられる点が最大の価値で、AWS Lambdaが苦手とする並列処理や長時間ジョブ、WebSocketに強みがあります。フリーランス案件としてはGCP全体の中で需要が安定しており、Docker・Terraform・BigQueryなど周辺スキルとセットで評価される傾向です。

本記事の要点

• Cloud Runはコンテナベースのフルマネージドサーバレス。任意言語・任意フレームワークに対応

• AWS Lambdaとは実行単位・同時処理・実行時間・課金・コールドスタート・ロックインの6観点で違いがある

• 料金はリクエスト課金とインスタンス課金の2モデル。max-instancesと同時実行数の設計が重要

• フリーランス案件は月額60〜100万円程度のレンジが公開案件で観測される目安。Cloud Run単独より周辺技術との組み合わせで評価が決まる

• 学習はDocker → Cloud Runデプロイ → 周辺サービス連携 → IaCの順で進めるのが現実的

• AI / RAG・LLM案件のバックエンドとしての採用例も見られ、関連スキルとして学ぶ価値は高い

次のアクション

• 自身のスキルセットと突き合わせ、Cloud Run・周辺サービスのうち未経験領域を洗い出す

• Cloud Run公式クイックスタートで「Hello World」を1日で動かしてみる

• 案件探しの段階に入っているなら、フリーランスエンジニアのスキルシートの書き方を徹底解説！記入例や今すぐ使えるフォーマットも紹介！を参考にスキルシートにGCP関連スキルを整理する

• 単価交渉まで視野に入れるならフリーランスエンジニアの単価交渉のコツ｜タイミング・伝え方・根拠の作り方も併読

参考リンク・一次情報

• Cloud Run overview - Google Cloud

• Cloud Run pricing - Google Cloud

• Cloud Run quickstarts - Google Cloud

• Compare Cloud Run functions - Google Cloud

• Google Cloud computeの選び方 - Google Cloud Blog

• レバテックフリーランス GCP案件一覧

• FOSTERNET NAVI GCP案件動向

• ITプロパートナーズ GCP案件