コンテナ運用を効率化できる Cloud Run とは？概要や特徴、料金体系まで徹底解説！

---

Cloud Run とは何かをご存知でしょうか？ Google が提供するパブリッククラウド「 Google Cloud 」に内包されており、コンテナ運用を効率化できるサービスです。本記事では、 Cloud Run の仕組みや活用事例、料金体系など、あらゆる観点から一挙に解説します。コンテナを効率的に運用したいと考えている方は、ぜひ最後までご覧ください。

---

専門家支援×Cloud Runで、Kubernetes不要のサーバーレス環境構築が可能！
事例資料を公開中！

＼無料で相談可能／

すぐにお打ち合わせご希望ならば、
こちらから日程調整が可能です。

---

Cloud Run とは？

Cloud Run は Google のパブリッククラウド「 Google Cloud 」に内包されているサービスであり、フルマネージドで提供されているコンテナの実行環境です。

なお、コンテナとはアプリケーションや設定用ファイル、ライブラリなどを OS 上にまとめたものを意味します。

通常、コンテナを使用する際は Kubernetesの知識を求められることが一般的です。

しかし、 Kubernetes を使うには一定のスキルが必要となるため、学習にかける費用・時間を確保しなければならない点が大きな課題だと言えます。

もちろん、 Kubernetes を使わずにコンテナを扱うことも可能ですが、オーケストレーション（設定・管理などの作業を自動化すること）を実現するためには、 Kubernetes を避けて通ることはできません。そして、このような課題を解決するうえで Cloud Run が有効な選択肢になります。

構築したコンテナイメージを Cloud Run の環境に乗せることで、 Kubernetes によって処理できる様々な機能を手間なく実現できます。このように、 Cloud Run の活用により、開発者は煩雑なインフラ管理から解放され、コードの書き込みやデプロイメントに集中できるようになります。

なお、以前はハイブリッド・マルチクラウド環境向けに「Cloud Run for Anthos」という選択肢が用意されていましたが、現在この仕組みは新規利用が推奨されておらず、公式ドキュメント上も旧バージョンの扱いとなっています。

オンプレミスや他クラウドを含めた環境でコンテナを一元管理したい場合は、GKE Enterprise（旧Anthos）や通常のGKEクラスタ上でコンテナを運用する構成が現在の主流です。

Cloud Run単体は、単一プロジェクト・単一リージョンを前提としたフルマネージドなサーバーレス環境でコンテナをシンプルに実行することに特化したサービスであるため、マルチクラウドやハイブリッド環境を前提とした要件がある場合は、GKEなど他サービスとの組み合わせを検討することが推奨されます。

---

専門家支援×Cloud Runで、Kubernetes不要のサーバーレス環境構築が可能！
事例資料を公開中！

＼無料で相談可能／

すぐにお打ち合わせご希望ならば、
こちらから日程調整が可能です。

---

コンテナ技術とサーバーレスアーキテクチャの重要性

Cloud Run について理解する前に、コンテナ技術やサーバーレスアーキテクチャの重要性を把握しておくことが大切です。なぜなら、 Cloud Run の導入・活用を検討するうえで、これらが重要なポイントになるためです。

以下、それぞれについて詳しく解説します。

コンテナ技術

アプリケーションを動かすためには実行環境が必要になりますが、その環境を構築するために「コンテナ」を作り、コンテナによってアプリケーションを動作させる仕組みをコンテナ技術と呼びます。

コンテナ技術はゲスト OS を使用せずにアプリケーションの実行環境を構築することが可能なため、一般的な仮想化技術と比較して、 CPU やメモリの使用リソースを抑えられるというメリットがあります。

また、コンテナの起動プロセスはシンプルに設計されているため、起動時間の短縮や処理スピードの向上、サーバー負荷の低減などを実現できる点も嬉しいポイントです。さらに、コンテナは試験環境で動かしていたものを本番環境でも使えるため、環境に依存したトラブルを事前に回避することが可能です。

このように、コンテナ技術は自社の生産性向上やリスク回避に大きく貢献します。アプリケーションを効率的に運用したい場合には、コンテナの利用が有効な選択肢になると言えるでしょう。

サーバーレスアーキテクチャ

サーバーレスアーキテクチャとは、自社で物理サーバーを用意する必要がなく、外部ベンダーがサーバー管理を代行してくれる仕組みのことです。昨今、身近な存在になったクラウドサービスに関しても、このサーバーレスアーキテクチャを採用しているものが数多く存在します。

従来、システムを構築するためには自社で物理サーバーを用意する必要があり、多額の初期費用が発生するケースが一般的でした。しかし、サーバーレスアーキテクチャは外部ベンダーが管理しているサーバーを利用するため、初期コストをかけずにシステムを構築できます。

ただし、サーバーレスアーキテクチャを利用する場合、従量課金（使用量に応じて金額が変動する仕組み）で月々のサービス利用料金が発生することは覚えておきましょう。

また、サーバーの管理・運用は外部ベンダーが巻き取ってくれるため、自社の作業工数を大幅に削減することが可能です。さらに、契約内容を変更するだけで柔軟にスケーリング（使用リソースを増減すること）ができるため、柔軟なシステム運用の実現に繋がります。

Cloud Run の特徴

Cloud Run は様々な特徴・強みを持つサービスです。具体的にどのような特徴があるのか、代表的なものをいくつかご紹介します。

フルマネージドなサーバーレスプラットフォーム

フルマネージドとは、ほぼ全てのサーバー管理をベンダーが代行してくれることを意味します。 Cloud Run はフルマネージドサービスとして提供されているため、自社の工数をかけずに管理・運用できる点が大きな特徴となっています。

これにより、社員は利益に直結する業務にリソースを集中させることができ、自社の生産性向上やビジネス成長に繋がります。

コンテナベースのアプリケーション実行

本来、アプリケーションを実行するためには、アプリケーション本体や設定ファイル、ライブラリなど、様々なものを組み合わせて使う必要があります。しかし、 Cloud Run はこれらをコンテナ上に集約し、ひとまとめにしてコンテナベースでアプリケーションを動かせるため、アプリケーションの実行にかかる作業負荷を大幅に低減できます。

高速なスケーリングと低レイテンシー

Cloud Run は外部からのアクセスがない状態ではコンテナのインスタンスが 0 になり、アクセスの発生に伴って必要量までスケールする仕組みを採用しています。

そのため、手動でリソースを調整する必要がなく、高速なスケーリングを実現できます。また、他の Google Cloud サービスと同様、強固なインフラをベースとして設計されているため、低レイテンシーな環境でコンテナを扱える点も大きなメリットです。

シンプルなデプロイとバージョン管理

Cloud Run のデプロイはとてもシンプルな仕組みを採用しており、「 gcloud run deploy 」などの単一コマンドを実行するだけで簡単にデプロイできます。

コマンドでデプロイを行った後は固有の URL が自動発行されるため、それを使えば外部へのアプリケーション公開を容易に行うことが可能です。

また、 Cloud Run はそれぞれのデプロイが新しいリビジョンを生成し、これにより以前のバージョンへ簡単にロールバックできるため、状況に応じて過去のバージョンへ戻すことも可能です。このように、バージョン管理を効率的に行える点も Cloud Run の大きな特徴となっています。

柔軟な言語とフレームワークのサポート

Cloud Run は言語・ライブラリの制約が少なく、自社の状況に合わせて様々な言語を使用可能なため、柔軟なコンテナ運用を実現できます。

また、フレームワークに関するサポートも充実しており、 Spring Boot などの有名なフレームワークについては、 Google の公式サイト上に説明用のドキュメントが用意されています。このように、初心者でも安心して扱える点が Cloud Run の魅力の一つだと言えるでしょう。

従量課金モデルによるコスト最適化

詳しい料金体系は後述しますが、 Cloud Run は使用量に応じて料金が変動する従量課金モデルを採用しています。

そのため、予算の範囲内でおさまるように計画的に使えば、コストを最適化しながらコンテナを運用することが可能になります。また、 Google 公式サイトには料金計算ツールが用意されており、使用するプロダクトやリソース量などを入力することで、コストを事前にシミュレーションできるため、不安な方は料金計算ツールを活用することをおすすめします。

---

専門家支援×Cloud Runで、Kubernetes不要のサーバーレス環境構築が可能！
事例資料を公開中！

＼無料で相談可能／

すぐにお打ち合わせご希望ならば、
こちらから日程調整が可能です。

---

Cloud Run の仕組み

Cloud Run でコードを実行する際には、

• Cloud Run サービス
• Cloud Run ジョブ
• Cloud Run 関数（Functions）
• Cloud Run ワーカープール（Worker Pools）

という 4 種類から用途に応じたものを選択して利用できる仕組みとなっています。

以下、それぞれについて詳しく解説します。

Cloud Run 関数（Functions）

Cloud Run 関数は、HTTPリクエストやCloud Storage・Pub/Subなどのイベントをトリガーに、単一の関数単位でコードを実行できる実行モデルです。以前は「Cloud Functions」として提供されていたサービスがCloud Runに統合され、現在は「Cloud Run 関数（第2世代）」として提供されています。コンテナ全体を構築せずに関数コードをデプロイするだけで済むため、小規模な処理や特定のイベント処理を素早く実装したい場合に適しています。

スケーリングやインフラ管理はCloud Runの他の実行モデルと同様にフルマネージドで行われ、他のGoogle Cloudサービスと組み合わせたイベント駆動型のアーキテクチャを構築しやすい点が特徴です。

Cloud Run ワーカープール（Worker Pools）

Cloud Run ワーカープールは、外部からのリクエストを受けて処理するのではなく、Pub/SubやApache Kafkaなどのキューからタスクを自ら取得して処理する「プル型」の実行モデルです。

従来、こうしたプル型のワークロード処理にはGKEなどインフラ管理が必要なツールが必要でしたが、ワーカープールを使えばサーバーレス環境のままバックグラウンド処理やメッセージ処理を実行できます。

リビジョンごとにインスタンス分割やロールバックが可能な点は他のCloud Runの実行モデルと共通しており、常時稼働型の非同期処理をインフラ管理の手間なく運用したい場合に有効な選択肢です。

Cloud Run サービス

Cloud Run サービスは、 Web のリクエストやイベントに応答するためのコードを実行する際に使用されるケースが一般的です。 Cloud Run サービスの特徴としては、すべてのサービスに利用できる一意の HTTPS エンドポイントや、迅速な自動スケーリングなどが挙げられます。

Cloud Run には「 *.run.app 」ドメインの一意のサブドメインに HTTPS エンドポイントが用意されており、状況に応じてカスタムドメインを構成することも可能なため、 TLS （ Transport Layer Security ： Web ブラウザと Web サーバー間のデータ通信を暗号化し、送受信を行うための仕組み）を Cloud Run で管理することができます。また、 WebSocket や HTTP / 2 、 gRPC などをサポートしている点も大きな特徴です。

加えて、 Cloud Run サービスはすべての受信リクエストを処理するため、迅速にスケールアウトするように設計されています。最大 1,000 個のインスタンスをスケールアウトできますが、事前にリクエストを送信し、 Google の承認を取得することで、 1,000 個以上のインスタンスへスケールアウトできます。また、リクエストが少なくなった場合、 Cloud Run サービスはアイドル状態のコンテナを削除するため、使用リソースの最適化にも繋がります。

以下、 Cloud Run サービスの構成イメージを図で示します。

Cloud Run ジョブ

Cloud Run ジョブは、コードが動作後に停止する場合に使用されるケースが一般的です。例えば、データベースの移行のように、作業完了後に終了するコードを実行する際は、 Cloud Run ジョブが適切な選択肢になると言えるでしょう。

また、 Cloud Run ジョブはコマンドラインから「 gcloud CLI 」を使用してジョブを実行したり、定期的なジョブをスケジュールしたりすることで実行できます。通常、スクリプトやツールを実行するためには、コード実行のための 1 つのインスタンスを開始しますが、配列ジョブ（独立した同一のインスタンスを複数並行）を用いて開始することも可能です。

以下、配列ジョブのイメージを図で示します。

このように、 Cloud Run でコードを実行する際には、「 Cloud Run サービス」と「 Cloud Run ジョブ」という 2 つの選択肢が用意されています。それぞれ特徴が異なるため、自社の状況に合わせて、適切なものを選択することが大切です。

Cloud Run と Google Cloud の他コンピュ―トサービスとの違い

Google Cloud には、 Cloud Run 以外にも様々なコンピュートサービスが用意されています。本章では、 Google Cloud の代表的なコンピュートサービスと Cloud Run との違いをご説明します。

Cloud Run と Google Kubernetes Engine （ GKE ）との違い

Google Kubernetes Engine （以下 GKE と記載）とは、 Kubernetes の運用を効率化できるツールです。コンテナ運用を効率化できる点は Cloud Run と共通していますが、両者には様々な違いが存在します。

例えば、リクエストがない時にCloud Runは追加設定なしで自動的に0までスケールインできますが、GKEで同様の挙動を実現するには、AutopilotモードやHPA（水平Pod自動スケーラー）などの設定を別途組み合わせる必要があります。

近年はGKE Autopilotの自動スケーリング機能が強化され、必要なリソースを素早く確保できるようになっていますが、Cloud Runのようにデフォルトで0スケールが組み込まれているわけではありません。

また、Cloud RunはVPC内のリソースと通信を行うには設定が必要ですが、GKEは設定なしでVPC内のリソースと直接接続することができます。このように、Cloud RunとGKEは異なる特徴を有したサービスであり、それぞれメリット・デメリットが存在します。

Cloud Run と App Engine との違い

App Engine とは、アプリケーションを手間なく実行できるサービスです。構成ファイルやコードをデプロイするだけで簡単に実行可能なため、自社の業務効率化に大きく貢献します。

Cloud Run の場合、柔軟な実行環境を構築できる点が大きな特徴ですが、 App Engine のように構成ファイルとコードのみでデプロイを行うことはできません。また、 App Engine は Identity Aware Proxy の認証がサポートされていますが、 Cloud Run で同様の認証を行うためには Serverless NEG に紐付ける必要があります。

ただし、フレキシブル環境の App Engine は VM ベースの実行環境であるため、 Cloud Run と比較してスケーリングの速度が遅く、 0 までスケールインすることもできません。

このように、 Cloud Run と App Engine は異なるメリット・デメリットを持っているため、簡単にデプロイしたい場合は App Engine 、柔軟な環境を求める場合は Cloud Run など、状況に合わせて使い分けることを意識してください。

Cloud Run と Artifact Registry との違い

Artifact Registryは、Dockerイメージだけでなく、Java・Node.js・Pythonなどのパッケージも一元管理できる、Google Cloudの標準的なアーティファクト管理サービスです。

以前はコンテナイメージの保存先として「Container Registry」が使われていましたが、Container Registryは2025年に廃止されており、現在はすべてのプロジェクトでArtifact Registryへの移行が完了しています。

Cloud Runはコンテナアプリケーションを実行するためのサービスである一方、Artifact Registryはそのコンテナイメージを保存・管理するためのサービスであり、両者は役割が異なります。Cloud Runでコンテナをデプロイする際は、Artifact Registryに保存されたイメージを参照する構成が現在の標準的な運用方法です。

Cloud Run のセキュリティ対策

Cloud Run には、コンテナを安全な環境で利用するための様々なセキュリティ対策が施されています。本章では、 Cloud Run のセキュリティ対策について、いくつか内容を抜粋して解説します。

各種認証

Cloud Run は簡単にデプロイを行うことが可能ですが、アクセス制限をしなかった場合、不特定多数が自由にアクセスできるようになってしまい、情報漏洩などのリスクが増加します。そこで、 Cloud Run には、サービスを安全な環境で利用するための各種認証が備わっています。

Cloud Run に搭載されている認証機能としては、

• サービス間通信の認証
• Google Cloud 間の認証
• エンドユーザーの認証

などが挙げられます。

これらの認証を活用することで、様々なシーンにおけるセキュリティを高めることが可能です。 Cloud Run を安全に使いたいのであれば、認証は必要不可欠な機能であると言えるでしょう。

アクセス制限

Cloud Run はオープンな URL を発行するため、そのままの状態ではセキュリティが担保されているとは言えません。しかし、 Cloud Run 単体でファイアウォールの制御などを行うことは不可能であり、アクセス制限を実現するためには「 Google Cloud ロードバランサ（以下 GCLB と記載）」と「ネットワークエンドポイントグループ（以下 NEG と記載）」を連携する必要があります。

Cloud Run に登録した NEG と GCLB のバックエンドサービスを連携させれば、バックエンドサービスに複数の NEG を設定できるようになります。これにより、リージョン単位で Cloud Run サービスを稼働させ、 GCLB を使って近いリージョンの Cloud Run にリクエストをルーティングさせることが可能になるため、外部からのトラフィックを柔軟に制御することができます。

VPC 連携

特定のユーザーのみがアクセスできる状態を作るためには、 Virtual Private Cloud （以下 VPC と記載）と Cloud Run を連携させる必要があります。例えば、サーバーレス VPC アクセスを経由して Cloud Run に接続すれば、 VPC 内のリソースへアクセスすることが可能になります。

また、 Cloud Run 発信で通信を行う際に IP アドレスを固定したい場合は、 Cloud NAT とサーバーレス VPC アクセスを連携させることで実現できます。これにより、 IP アドレスを固定化し、通信先のファイアウォールを用いてアクセスを制御できるようになります。

Cloud Run の活用事例

主に時計事業を展開するセイコーホールディングスのシステムソリューション事業を担っている「セイコーソリューションズ」では、 Cloud Run を活用してクラウド辞書サービスの開発に Cloud Run を活用しています。

同社のマーケティングの結果、サービスの潜在顧客は 300 万人にも上ることが判明し、利用者が爆発的な増加に耐えうるだけのインフラ整備が大きな課題となっていました。

そこで、サービス規模の拡大にも柔軟に対応できるよう、サーバーレスで運用できる Cloud Run の導入を決めたのです。

同社は Cloud Run でコンテナ運用を効率化しつつ、 Cloud Datastore や Cloud SQL をはじめとした、他の Google Cloud サービスも組み合わせて利用しています。表示部分を担うフロントエンドと機能部分を担うバックエンドを分割し、マイクロサービス化の工夫を施すことで、サービス拡大後のコスト低減や信頼性の向上、メンテナンス工数の削減などを担保する狙いです。

また、同社はクラウド辞書サービスにおける検索のレスポンスを重視しており、高速レスポンスを実現できる点も Google Cloud の導入を決めた一因となっています。このように、 Cloud Run や Google Cloud の各種サービスを活用し、自社のビジネス成長に繋げている好事例だと言えるでしょう。

まとめ

本記事では、 Cloud Run の仕組みや活用事例など、あらゆる観点から一挙に解説しました。企業が Cloud Run を活用することで、コンテナ運用の効率化や高速スケーリングなど、様々なメリットを享受できます。この記事を読み返して、サービスの特徴や料金体系などを理解しておきましょう。

---

専門家支援×Cloud Runで、Kubernetes不要のサーバーレス環境構築が可能！
事例資料を公開中！

＼無料で相談可能／

すぐにお打ち合わせご希望ならば、
こちらから日程調整が可能です。

---