Cloud Run実践ガイド｜コンテナ型サーバーレスのデプロイ・スケーリング・コールドスタート対策の現場ノウハウ

Cloud Runとは何か｜AWS Lambda・ECS Fargateとの位置関係

Cloud Runの基本的な位置づけ

Cloud RunはGoogle Cloudが提供するフルマネージド型のコンテナ実行環境です。開発者がインフラの管理を一切せずに、Dockerコンテナをそのままデプロイして本番稼働させることができます。2026年5月時点で、国内外の多くの企業が本番環境での採用を進めており、特にマイクロサービスアーキテクチャやイベント駆動型システムでの導入事例が増加しています。

従来のサーバーレスサービスと比較すると、AWS LambdaやAzure Functionsが関数単位の実行環境であるのに対し、Cloud Runはコンテナ単位で動作します。このためアプリケーション全体をコンテナ化して動かすことができ、ローカル開発環境との整合性を高く保つことが可能です。実際に複数のフレームワークやランタイムを自由に選択でき、既存のコンテナ資産をそのまま活用できる点が大きな強みとなっています。

AWS Lambda・ECS Fargateとの機能比較

AWS Lambdaとの最も大きな違いは、実行単位がコンテナである点です。Lambdaは関数ごとにデプロイパッケージを用意しますが、Cloud Runではアプリケーション全体を含むコンテナイメージをデプロイします。このため依存関係の管理が容易になり、ローカルでの動作確認がそのまま本番環境で再現できます。また実行時間の上限もCloud Runの方が長く、2026年5月時点でリクエストあたり最大60分まで対応しています。

ECS Fargateとの比較では、両者ともコンテナベースのサーバーレス環境ですが、Cloud RunはHTTPリクエストベースの自動スケーリングに最適化されています。Fargateがタスク定義やサービス定義を細かく設定する必要があるのに対し、Cloud Runはコンテナイメージとポート番号を指定するだけでデプロイが完了します。運用の簡便性ではCloud Runに優位性があり、特にWeb APIやマイクロサービスの構築では迅速な立ち上げが可能です。

Google Cloudエコシステム内での役割

Google Cloud内では、Cloud RunはCompute EngineやGoogle Kubernetes Engine（GKE）と並ぶコンピューティングサービスの選択肢として位置づけられています。Compute EngineがIaaS、GKEがCaaSであるのに対し、Cloud RunはPaaS寄りのサービスとして、より高い抽象度で運用負荷を削減します。

・Compute Engine: 仮想マシン単位でOSから自由に構成可能、運用負荷が高い
・GKE: Kubernetesクラスタを管理、柔軟性とスケーラビリティが高いが運用知識が必要
・Cloud Run: コンテナをHTTPエンドポイントとして自動公開、運用が最も簡素

実際の現場では、APIゲートウェイやマイクロサービスのエンドポイントとしてCloud Runを採用し、バックエンドのデータ処理にはCloud FunctionsやBigQueryを組み合わせるパターンが多く見られます。これによりインフラ運用コストを最小化しながら、スケーラブルなシステムを構築できます。

コンテナファーストの設計思想

Cloud Runの設計思想は「コンテナをそのまま本番環境で動かす」ことにあります。開発者はローカル環境でDockerコンテナを動作確認し、そのイメージをGoogle Container Registry（GCR）またはArtifact Registryにプッシュするだけでデプロイが完了します。このシンプルさが開発サイクルを加速させ、CI/CDパイプラインとの統合も容易になります。

実際の導入事例では、GitHubへのpushをトリガーにCloud Buildが自動的にコンテナをビルドし、Cloud Runへデプロイする構成が標準的です。この仕組みにより、コードのマージから本番反映までを数分で完結させることができます。また複数のリビジョンを保持し、トラフィック分割やロールバックも即座に実行できるため、リリース時のリスク管理も大幅に改善されます。

Cloud Run ServicesとJobsの違い・使い分け

Servicesの特性とユースケース

Cloud Run Servicesは、HTTPリクエストに応答する形でコンテナを起動・スケーリングするサービスです。外部からのHTTP/HTTPSリクエストを受け付け、自動的にコンテナインスタンスを増減させます。リクエストが来ない間はインスタンス数をゼロまで縮退させることができ、課金も発生しません。

典型的なユースケースとしては、REST APIの提供、Webアプリケーションのホスティング、Webhookの受信エンドポイントなどがあります。特にトラフィックの変動が大きいサービスや、夜間・休日にアクセスがほとんどないシステムでは、コスト削減効果が顕著に現れます。1日のうち数時間しかアクセスがないシステムでは、リクエストがない間はインスタンス数がゼロまでスケールインするため、常時起動の仮想マシン運用と比べて月額コストを大きく削減できます。

Jobsの特性とユースケース

Cloud Run Jobsは、バッチ処理やスケジュール実行を目的としたサービスです。HTTPリクエストではなく、手動実行またはCloud Schedulerからのトリガーで起動します。実行が完了すると自動的に終了し、その間だけ課金が発生します。

データのETL処理、定期的なレポート生成、機械学習モデルの推論バッチなど、リクエスト/レスポンス型ではない処理に最適です。従来はCompute EngineのインスタンスをCronで起動停止させていた処理を、Jobsに移行することで運用負荷を大幅に削減できます。また並列実行数を指定することで、大量のタスクを効率的に処理することも可能です。

両者の比較表

使い分けの判断基準

現場での判断基準として、外部からのリクエストに即座に応答する必要がある場合はServices、決まった時間に一定の処理を実行する場合はJobsを選択します。ただしServicesでも定期実行は可能であり、Cloud SchedulerからHTTPリクエストを送信する構成で実現できます。この場合、コールドスタート時間が許容できるかどうかが判断のポイントになります。

・Servicesを選ぶケース: ユーザーからの直接アクセス、リアルタイム性が必要、トラフィック変動が大きい
・Jobsを選ぶケース: 定時バッチ処理、大量データの一括処理、リアルタイム性が不要

実際の運用では、同じアプリケーションでもエンドポイント部分はServicesで実装し、重い集計処理はJobsに分離する設計が推奨されます。これによりリクエスト応答性を維持しながら、バッチ処理のコストも最適化できます。

コンテナデプロイの基本（gcloud・Cloud Build連携）

gcloudコマンドによる手動デプロイ

最もシンプルなデプロイ方法は、gcloudコマンドを使った手動デプロイです。ローカル環境でDockerfileを用意し、以下のコマンドでデプロイが完了します。

gcloud run deploy SERVICE_NAME \
  --image gcr.io/PROJECT_ID/IMAGE_NAME \
  --platform managed \
  --region asia-northeast1 \
  --allow-unauthenticated

このコマンドでは、すでにContainer Registryにプッシュ済みのイメージを指定してデプロイします。–allow-unauthenticatedフラグを指定すると、認証なしで外部からアクセス可能なエンドポイントが公開されます。本番環境では認証設定を慎重に検討する必要がありますが、開発環境やプロトタイプではこの設定で迅速に検証を進めることができます。

リージョンの選択は重要で、asia-northeast1（東京）を選択することで日本国内からのレイテンシを最小化できます。2026年5月時点では、大阪リージョン（asia-northeast2）も利用可能ですが、東京リージョンの方がサービスの提供開始が早く、機能の展開も先行する傾向があります。

Cloud Buildとの統合デプロイ

本番運用ではCI/CDパイプラインとの統合が不可欠です。Cloud Buildを使うことで、ソースコードのコミットをトリガーに自動的にビルド・デプロイを実行できます。cloudbuild.yamlファイルに以下のような設定を記述します。

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/myapp', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/myapp']
- name: 'gcr.io/cloud-builders/gcloud'
  args:
  - 'run'
  - 'deploy'
  - 'myapp'
  - '--image=gcr.io/$PROJECT_ID/myapp'
  - '--region=asia-northeast1'
  - '--platform=managed'

このファイルをリポジトリのルートに配置し、Cloud Build トリガーを設定することで、GitHubやCloud Source Repositoriesへのpushを検知して自動デプロイが実行されます。実際の現場では、mainブランチへのマージで本番環境へ、developブランチへのpushで検証環境へデプロイする構成が一般的です。

Artifact Registryの活用

2026年5月時点では、Container Registryは非推奨となり、Artifact Registryへの移行が推奨されています。Artifact Registryは複数のフォーマット（Docker、Maven、npmなど）に対応し、より細かいアクセス制御が可能です。Cloud Runへのデプロイ時にはイメージURLをArtifact Registry形式に変更します。

・Container Registry形式: gcr.io/PROJECT_ID/IMAGE_NAME
・Artifact Registry形式: asia-northeast1-docker.pkg.dev/PROJECT_ID/REPO_NAME/IMAGE_NAME

移行作業自体は既存のイメージをタグ付けし直してpushするだけで完了します。Artifact Registryではリポジトリごとにアクセス権限を設定できるため、複数チームでの開発やマルチプロジェクト環境での権限管理が容易になります。

リビジョン管理とトラフィック分割

Cloud Runでは、デプロイごとに新しいリビジョンが作成されます。過去のリビジョンは自動的に保持され、必要に応じてロールバックやトラフィック分割が可能です。本番環境では新リビジョンに10%のトラフィックを流して動作確認し、問題がなければ100%に切り替える運用が推奨されます。

gcloudコマンドでトラフィック分割を設定する例は以下の通りです。

gcloud run services update-traffic SERVICE_NAME \
  --to-revisions=REVISION_NEW=10,REVISION_OLD=90 \
  --region=asia-northeast1

この設定により、新旧両方のリビジョンが同時に稼働し、リスクを最小化しながら新機能をリリースできます。実際の現場では、カナリアリリースやブルーグリーンデプロイメントの実装にこの機能が活用されています。

スケーリング設計（min/max instances・同時実行数・CPUプロビジョニング）

最小・最大インスタンス数の設定

Cloud Runのスケーリングは、最小インスタンス数（min-instances）と最大インスタンス数（max-instances）で制御します。最小インスタンス数を0に設定すると、リクエストがない間はインスタンスが完全に停止し、コストがゼロになります。ただしリクエスト到着時にコールドスタートが発生し、初回応答に数秒かかる可能性があります。

最小インスタンス数を1以上に設定すると、常に指定数のインスタンスが待機状態を維持し、コールドスタートを回避できます。2026年5月時点の料金では、最小インスタンス1台を常時起動した場合、月額約3,000～5,000円の固定費が発生します。これはトラフィック量に依存しない基本コストとなるため、応答速度を重視するサービスでは必要な投資として許容されます。

最大インスタンス数は、予期しない大量トラフィックによるコスト暴騰を防ぐために設定します。実際の運用では、通常時のピークトラフィックの2～3倍程度を上限に設定し、それを超える場合はHTTP 429エラーを返す構成が推奨されます。

同時実行数（concurrency）の調整

同時実行数は、1つのコンテナインスタンスが同時に処理できるリクエスト数を指定します。デフォルトは80ですが、アプリケーションの特性に応じて調整が必要です。CPU負荷が高い処理では10～20程度に下げ、I/O待ちが多い処理では100～1000まで引き上げることで、リソース効率が向上します。

・CPU集約型処理: 同時実行数10～20、1インスタンスあたり2vCPU以上を割り当て
・I/O待ち中心: 同時実行数100～1000、1vCPUでも十分に処理可能

実際の現場では、負荷テストを実施して最適な同時実行数を見極めます。同時実行数を高く設定しすぎるとメモリ不足やデータベース接続プールの枯渇が発生し、低く設定しすぎるとインスタンス数が増加してコストが上昇します。モニタリング指標を見ながら段階的に調整することが重要です。

CPUプロビジョニングモード

Cloud RunではCPUの割り当てモードを2種類から選択できます。デフォルトの「リクエスト処理時のみ割り当て」モードでは、リクエストを処理している間だけCPUが割り当てられ、アイドル時は割り当てが停止します。一方「常時割り当て」モードでは、インスタンスが起動している間は常にCPUが利用可能です。

常時割り当てモードは、バックグラウンドタスクやWebSocketの維持、定期的なヘルスチェック送信など、リクエスト処理以外でもCPUを使う必要がある場合に選択します。ただし料金は約2倍になるため、本当に必要かどうかを慎重に判断する必要があります。2026年5月時点では、多くのWeb APIはデフォルトモードで十分に動作しています。

オートスケーリングの挙動と閾値

Cloud Runのオートスケーリングは、現在のリクエスト処理状況とCPU使用率を基に自動的にインスタンス数を増減させます。新しいリクエストが到着し、既存インスタンスの同時実行数が上限に達すると、即座に新しいインスタンスが起動します。逆にリクエストが減少すると、不要なインスタンスは数分以内に停止されます。

実際の運用では、急激なトラフィック増加に対してスケールアウトが間に合わず、一時的にレイテンシが上昇する現象が観測されることがあります。これを防ぐには、最小インスタンス数を適切に設定し、トラフィックのピーク時に備えてウォームアップインスタンスを確保しておくことが有効です。モニタリングダッシュボードでインスタンス起動のタイミングとレイテンシの相関を継続的に確認することが推奨されます。

コールドスタート対策の実装パターン（最小インスタンス・CPU常時割り当て）

コールドスタートが発生する仕組み

コールドスタートとは、インスタンスが完全に停止した状態から新たにリクエストを受け付けるまでの初期化時間を指します。Cloud Runではリクエストがない間にインスタンスをゼロまでスケールインさせることができますが、その状態から最初のリクエストが来た際にコンテナの起動、アプリケーションの初期化、依存ライブラリのロードなどが発生し、応答までに数秒から十数秒かかることがあります。

コールドスタート時間はコンテナイメージのサイズ、アプリケーションの初期化処理、メモリ割り当て量などに依存します。軽量なイメージと高速な初期化処理を実装することで、コールドスタート時間を1秒以下に抑えることも可能です。実際の測定では、Node.jsやGoなどの軽量ランタイムは500ms前後、JavaやPythonの大規模フレームワークでは3～5秒程度のコールドスタートが観測されています。

最小インスタンス数による対策

最も確実なコールドスタート対策は、最小インスタンス数を1以上に設定することです。これにより常に指定数のインスタンスが起動状態を維持し、どのタイミングでリクエストが来ても即座に応答できます。

gcloud run services update SERVICE_NAME \
  --min-instances=1 \
  --region=asia-northeast1

この設定により、月額約3,000～5,000円のコストが追加されますが、ユーザー体験を重視するサービスでは必要な投資です。実際の現場では、営業時間帯のみ最小インスタンスを1に設定し、深夜帯は0に戻すスケジュール運用も採用されています。Cloud Schedulerと組み合わせて、時間帯ごとに最小インスタンス数を変更するスクリプトを実行することで、コストとパフォーマンスのバランスを最適化できます。

CPU常時割り当てモードの活用

CPU常時割り当てモードを有効にすると、インスタンスが起動している間は常にCPUリソースが利用可能になります。これによりバックグラウンドでのウォームアップ処理や、定期的な外部APIへのヘルスチェック送信などが可能になり、実質的なコールドスタートを回避できます。

・ウォームアップ処理の例: データベース接続プールの事前確立、キャッシュの事前ロード、外部APIの接続確認
・定期タスクの例: セッション管理の維持、WebSocket接続の保持、内部状態の更新

ただしCPU常時割り当てモードは料金が約2倍になるため、本当に必要な場合にのみ採用します。多くのREST APIではデフォルトのリクエスト時割り当てモードで十分であり、初期化処理を最適化することでコールドスタート時間を短縮する方が費用対効果が高い場合が多いです。

アプリケーション側の初期化最適化

コンテナイメージとアプリケーションコードの最適化により、コールドスタート時間を大幅に短縮できます。現場で効果が実証されている対策は以下の通りです。

・マルチステージビルドの活用: Dockerfileでビルド環境と実行環境を分離し、最終イメージサイズを削減
・依存ライブラリの最小化: 不要なパッケージを削除し、軽量な代替ライブラリに置き換え
・遅延ロードの実装: アプリケーション起動時に必要最低限の初期化のみ実行し、重い処理は最初のリクエスト時に実行
・環境変数の事前設定: 実行時の設定ファイル読み込みを減らし、環境変数で直接注入

実際の改善事例では、Pythonアプリケーションでインポートするライブラリを厳選し、初期化処理を遅延ロード化することで、コールドスタート時間を8秒から1.5秒に短縮した例があります。この対策により最小インスタンス数を0に維持しながら、実用的な応答速度を実現できました。

料金体系（リクエスト課金・vCPU秒・メモリ秒・ネットワーク）

基本的な料金構成要素

Cloud Runの料金は2026年5月時点で以下の要素で構成されます。すべての料金はリージョンによって若干異なりますが、asia-northeast1（東京）の料金を基準に説明します。

・リクエスト課金: 200万リクエストまで無料、以降は100万リクエストあたり約40円
・vCPU秒課金: 1vCPU秒あたり約0.000024ドル（約0.0036円）
・メモリ秒課金: 1GBメモリ秒あたり約0.0000025ドル（約0.00038円）
・ネットワーク送信: 1GBあたり約12円（リージョン外への送信時）

実際の月額料金は、これらの要素の合計に無料枠を適用して算出されます。無料枠は毎月リセットされ、vCPU秒は180,000秒、メモリ秒は360,000GB秒、リクエスト数は200万回まで無料で利用できます。小規模なAPIやプロトタイプであれば、この無料枠内で運用できることも多いです。

実際の料金シミュレーション

具体的な利用パターンでの料金を計算してみます。

パターン1: 軽量API（月間10万リクエスト、平均応答時間100ms、1vCPU/512MBメモリ）
・リクエスト課金: 無料枠内のためゼロ
・vCPU秒: 10万リクエスト × 0.1秒 × 1vCPU = 10,000vCPU秒 → 無料枠内
・メモリ秒: 10万リクエスト × 0.1秒 × 0.5GB = 5,000GB秒 → 無料枠内
・合計: 約0円

パターン2: 中規模API（月間500万リクエスト、平均応答時間200ms、2vCPU/1GBメモリ）
・リクエスト課金: (500万 – 200万) × 40円 / 100万 = 約120円
・vCPU秒: 500万 × 0.2秒 × 2vCPU = 200万vCPU秒 → (200万 – 18万) × 0.0036円 = 約6,550円
・メモリ秒: 500万 × 0.2秒 × 1GB = 100万GB秒 → (100万 – 36万) × 0.00038円 = 約240円
・合計: 約6,910円/月

このように実際の運用コストは処理時間とリソース割り当てに大きく依存します。最適化により処理時間を半減させれば、料金もほぼ半減します。

コスト最適化のポイント

現場でのコスト削減実績がある対策を挙げます。

・処理時間の短縮: 不要な処理を削除し、データベースクエリを最適化することで応答時間を短縮
・メモリ割り当ての適正化: 過剰なメモリ割り当てを見直し、実際の使用量に合わせて調整
・キャッシュの活用: 頻繁にアクセスされるデータをメモリキャッシュし、外部APIやデータベースへの問い合わせを削減
・バッチ処理の統合: 個別に実行していた処理をバッチ化し、インスタンス起動回数を削減

たとえばデータベースクエリのN+1問題を解消して平均応答時間を短縮すると、リクエストあたりの実行時間（課金対象）が減り、月額コストの削減につながります。また不要に大きく設定されていたメモリ割り当てを2GBから512MBに下げれば、メモリ割り当てに比例するメモリ課金もその分だけ抑えられます。

予期しないコスト暴騰の防止策

Cloud Runはスケーラビリティが高い反面、予期しない大量トラフィックやバグによる無限ループで料金が急増するリスクがあります。これを防ぐための対策は以下の通りです。

・最大インスタンス数の設定: 上限を設けることで最悪ケースの料金を予測可能にする
・予算アラートの設定: Google Cloud Billingで予算を設定し、閾値超過時に通知
・Cloud Armorの導入: DDoS攻撃や異常なトラフィックパターンを検知してブロック
・レート制限の実装: アプリケーション側でIPアドレスごとのリクエスト数を制限

実際の事故事例では、バグにより無限ループが発生し、1日で通常の10倍以上のリクエストが発生したケースがあります。最大インスタンス数を設定していたため料金の暴騰は限定的でしたが、モニタリングアラートにより早期に検知して修正することが重要です。

セキュリティと認証（Service Account・IAM・Cloud IAP連携）

認証設定の基本

Cloud Runのエンドポイントは、デフォルトでは認証が必要な状態でデプロイされます。外部からアクセス可能にするには、明示的に–allow-unauthenticatedフラグを指定する必要があります。本番環境では、公開APIとして外部に公開する場合と、内部システム間の通信にのみ使う場合で、認証設定を使い分けます。

・公開API: –allow-unauthenticatedで外部公開、アプリケーション側でAPIキーやJWT認証を実装
・内部システム: 認証必須のまま、Service AccountによるIAM認証を使用

IAM認証を使う場合、呼び出し側のService AccountにCloud Run Invokerロールを付与します。これによりGoogleが提供する認証基盤を活用でき、独自の認証機構を実装する必要がありません。特にマイクロサービス間の通信では、この方式が標準的に採用されています。

Service Accountの設定

Cloud Runのコンテナは、指定されたService Accountの権限で実行されます。デフォルトではCompute Engine default service accountが使用されますが、セキュリティベストプラクティスとしては、専用のService Accountを作成して最小権限を付与することが推奨されます。

実際の現場では、以下のような役割分担でService Accountを設計します。

・API用Service Account: Cloud SQLへの接続権限、Cloud Storageへの読み取り権限のみ
・バッチ用Service Account: BigQueryへの書き込み権限、Pub/Subへのメッセージ送信権限
・管理用Service Account: Cloud Runサービスの更新権限、ログ閲覧権限

Service Accountごとに必要最小限の権限を付与することで、万が一コンテナが侵害された場合でも被害範囲を限定できます。この権限分離により、万一サービスが侵害された場合でも、サービスアカウントに付与された範囲外のリソースへの影響を抑えられます。

Cloud IAPとの連携

Cloud Identity-Aware Proxy（IAP）を使用すると、Google アカウントやWorkspaceアカウントによる認証を簡単に実装できます。Cloud Runの前段にLoad BalancerとIAPを配置することで、アプリケーションコードを変更せずに認証機能を追加できます。

この構成は特に社内向けダッシュボードや管理画面で有効です。外部公開せず特定のユーザーのみにアクセスを許可する場合、IAPで認証を行い、許可されたユーザーのみがCloud Runのエンドポイントに到達できるようにします。実際の運用では、組織のWorkspaceアカウントを持つユーザーのみにアクセスを制限する設定が一般的です。

VPCとの連携とプライベート化

Cloud RunはデフォルトでパブリックIPアドレスを持ち、インターネットからアクセス可能です。より厳格なセキュリティが必要な場合、Serverless VPC Access Connectorを使ってVPC内のリソースにアクセスしたり、Internal Load Balancerと組み合わせてプライベートエンドポイント化することができます。

・VPC Access Connector: Cloud RunからVPC内のCompute EngineやCloud SQLにプライベートIPでアクセス
・Internal Load Balancer: Cloud Runをインターネットから隔離し、VPC内部からのみアクセス可能に

実際の金融系システムや医療系システムでは、機密データを扱うCloud RunサービスをVPC内部に閉じ込め、外部公開用のAPIゲートウェイのみをインターネットに公開する構成が採用されています。これによりデータの流出リスクを最小化しながら、必要な機能を外部に提供できます。

よくあるトラブル（タイムアウト・ストリーミング応答・接続プール枯渇）

タイムアウトエラーの原因と対策

Cloud Runのデフォルトタイムアウトは300秒（5分）ですが、設定により最大3600秒（60分）まで延長できます。タイムアウトエラーが発生する主な原因は、長時間かかる処理をリクエスト/レスポンス型で実装している場合です。

・データベースクエリの最適化不足: インデックスが適切に設定されておらず、全件スキャンが発生
・外部APIの応答待ち: タイムアウト設定がなく、外部APIの遅延がそのまま影響
・大量データの処理: メモリ内で大量のデータを処理し、処理時間が長期化

対策としては、長時間処理をCloud Run Jobsに移行し、リクエスト/レスポンスは即座に返してバックグラウンドで処理を継続する非同期パターンに変更します。Pub/SubやCloud Tasksと組み合わせることで、タスクキューイング機構を実装できます。実際の改善事例では、30分かかる集計処理をJobsに移行し、APIは処理IDのみを即座に返すよう変更することで、タイムアウトエラーを解消しました。

ストリーミング応答の実装と制約

Cloud Runはストリーミング応答をサポートしていますが、いくつかの制約があります。HTTP/1.1のChunked Transfer Encodingを使うことで、データを逐次送信できますが、Load Balancer経由の場合は一部のストリーミング機能が制限されることがあります。

実際の実装では、以下の点に注意が必要です。

・バッファリングの回避: 中間プロキシでのバッファリングを防ぐため、適切なヘッダー設定が必要
・タイムアウトの考慮: ストリーミング中もタイムアウトがカウントされるため、長時間のストリーミングには上限延長が必要
・エラーハンドリング: ストリーミング途中でエラーが発生した場合、クライアント側での適切な処理が必要

現場では、大容量ファイルのダウンロードやリアルタイムログの配信にストリーミング応答を活用していますが、安定性を重視する場合はCloud Storageに一旦書き出してから署名付きURLを返す方式も併用されています。

データベース接続プールの枯渇

Cloud Runの自動スケーリングにより大量のインスタンスが起動すると、それぞれがデータベースへの接続を確立しようとし、接続プールが枯渇する問題が発生します。特にCloud SQL for PostgreSQLやMySQLでは、最大接続数に上限があり、それを超えると新しい接続が拒否されます。

対策として以下の方法が有効です。

・Cloud SQL Proxyの使用: 接続プールを効率的に管理し、接続数を削減
・最大インスタンス数の制限: 同時起動するインスタンス数を制限し、接続数を予測可能に
・接続プールの適切な設定: アプリケーション側で接続プールサイズを小さく設定し、インスタンスあたりの接続数を削減
・読み取りレプリカの活用: 読み取り専用クエリは読み取りレプリカに分散し、プライマリへの負荷を軽減

実際のトラブル事例では、急激なトラフィック増加により100インスタンスが起動し、それぞれが10接続ずつ確立しようとして合計1000接続を要求し、Cloud SQLの上限である100接続を大幅に超過したケースがありました。最大インスタンス数を10に制限し、接続プールサイズを5に設定することで、合計50接続以内に収めて問題を解決しました。

メモリ不足とOOMキラー

割り当てられたメモリを超過すると、LinuxカーネルのOOM（Out Of Memory）キラーによりコンテナが強制終了されます。Cloud Runのログには「Memory limit exceeded」というエラーが記録され、リクエストは失敗します。

メモリ不足が発生する主な原因は以下の通りです。

・大量データの一括読み込み: データベースから全件取得してメモリに展開
・画像処理や動画処理: 大容量ファイルをメモリ上で処理
・メモリリークの存在: 長時間稼働するインスタンスで徐々にメモリが増加

対策としては、メモリ割り当て量を増やすか、処理方法を変更してメモリ使用量を削減します。現場での典型的な対策は、ストリーミング処理への変更です。全件をメモリに読み込むのではなく、ページング処理やカーソルベースのクエリを使って少量ずつ処理することで、メモリ使用量を一定範囲に抑えることができます。実際の改善例では、1GB分のデータを一括処理していた実装を、100MB単位のストリーミング処理に変更することで、メモリ割り当てを2GBから512MBに削減できました。

よくある質問

Cloud RunとCloud Functionsの使い分けは？

Cloud Functionsは単一の関数を実行する軽量なサーバーレス環境で、Cloud Runはコンテナ全体を動かすより柔軟な環境です。現場では以下のような基準で使い分けています。シンプルなイベント処理や単一の目的に特化した処理であればCloud Functionsを選択し、複数のエンドポイントを持つAPIや既存のコンテナ資産を活用する場合はCloud Runを選択します。2026年5月時点では、新規プロジェクトの多くがCloud Runを第一選択肢としており、Functionsは既存資産の維持や特定のトリガー（Cloud Storageのファイルアップロードなど）に特化した用途に限定される傾向があります。

本番環境での可用性はどの程度保証される？

Cloud RunのSLA（Service Level Agreement）は99.95%で、これは月間のダウンタイムが約22分以内に収まることを意味します。実際の運用では、リージョン障害に備えて複数リージョンにデプロイし、グローバルロードバランサーで振り分ける構成が推奨されます。金融機関や大規模ECサイトなど、高可用性が求められるシステムでは、asia-northeast1（東京）とasia-northeast2（大阪）の両方にデプロイし、片方に障害が発生しても自動的にフェイルオーバーする構成が採用されています。ただし複数リージョン構成はコストが約2倍になるため、ビジネス要件と照らし合わせて判断する必要があります。

ローカル開発環境での動作確認方法は？

Cloud Runはコンテナベースであるため、ローカル環境でもDockerを使って同じコンテナを動かすことができます。開発者は通常のDocker開発フローでコンテナをビルドし、ローカルでテストした後、そのままCloud Runにデプロイします。具体的にはdocker buildでイメージをビルドし、docker runでローカルのポート8080にバインドして動作確認します。環境変数もローカルの.envファイルで管理し、本番環境では同じ変数をCloud Runの環境変数設定で注入します。このワークフローにより、ローカルと本番の環境差異を最小化でき、本番デプロイ後の予期しないエラーを大幅に削減できます。実際の開発現場では、Docker Composeを使って関連サービス（データベース、キャッシュなど）を含めた統合環境をローカルに構築し、本番環境と同等の動作確認を行うことが標準的です。

既存のKubernetesアプリケーションは移行できる？

Cloud RunはKnative互換であるため、Kubernetes上で動作するコンテナの多くはそのまま移行可能です。ただしKubernetesの高度な機能（StatefulSet、DaemonSet、カスタムリソースなど）を使用している場合は、Cloud Run向けに設計を見直す必要があります。移行の典型的なパターンは、ステートレスなWeb APIやマイクロサービスから順次移行し、ステートフルなコンポーネントは引き続きGKEで運用する方式です。移行にあたっては、ステートレスで小〜中規模のマイクロサービスをCloud Runに寄せ、複雑な状態管理が必要なサービスはGKEに残すといった使い分けが現実的で、運用負荷の軽減につながります。移行時にはヘルスチェックエンドポイントやログ出力形式など、Cloud Runの要件に合わせた調整が必要になる点に注意が必要です。

機密データを扱う際のセキュリティ対策は？

機密データを扱う場合、複数の層でセキュリティ対策を実装します。まずCloud Runサービスを認証必須に設定し、IAMによるアクセス制御を行います。次にVPC Access Connectorを使ってデータベースへの接続をプライベートネットワーク経由に限定し、インターネット経由のアクセスを遮断します。さらにSecret ManagerでAPIキーやデータベース認証情報を管理し、コンテナイメージやソースコードに認証情報を含めないようにします。実際の医療系システムでは、患者データを扱うCloud Runサービスを完全にVPC内部に隔離し、外部公開用のAPIゲートウェイのみをインターネットに公開する構成が採用されています。加えてCloud Armorでレート制限とDDoS対策を実装し、Cloud Loggingですべてのアクセスログを記録してコンプライアンス要件を満たしています。2026年5月時点では、HIPAA準拠やPCI DSS準拠のシステムでもCloud Runが採用されており、適切な設定により高いセキュリティレベルを実現できることが実証されています。

導入前チェックリスト

・コンテナ化の準備: アプリケーションがDockerコンテナとして動作することを確認済みか
・ポート設定: コンテナが環境変数PORTで指定されたポートでリッスンする実装になっているか
・ステートレス設計: アプリケーションがローカルストレージに依存せず、状態を外部データベースやキャッシュで管理しているか
・ヘルスチェック: アプリケーションがHTTPヘルスチェックに応答するエンドポイントを持っているか
・ログ出力: 標準出力・標準エラー出力にログを出力し、Cloud Loggingで収集可能か
・環境変数管理: 設定値を環境変数で注入する設計になっており、ハードコードされた値がないか
・認証設計: 公開APIか内部システムかを明確にし、適切な認証方式を選択済みか
・データベース接続: 接続プールの設定が適切で、インスタンス増加時に接続枯渇が発生しないか
・タイムアウト設定: 処理時間が想定範囲内に収まり、タイムアウトエラーが発生しないか
・メモリ割り当て: 想定されるピーク時のメモリ使用量を測定し、適切なメモリ量を割り当てたか
・スケーリング設定: 最小・最大インスタンス数と同時実行数を業務要件に合わせて設定したか
・コスト試算: 想定トラフィックでの月額コストを試算し、予算内に収まるか確認したか
・モニタリング設定: Cloud MonitoringとCloud Loggingでアラート設定を行い、異常検知できるか
・CI/CDパイプライン: Cloud BuildまたはGitHub Actionsでの自動デプロイ環境が構築済みか
・ロールバック計画: 問題発生時に前のリビジョンへ即座にロールバックできる手順が確立しているか

本記事のまとめ

Cloud Run導入の主要なメリット

Cloud Runは、コンテナベースのアプリケーションを最小限の運用負荷で本番環境に展開できるサーバーレスプラットフォームです。自動スケーリング、従量課金、高い可用性を標準機能として提供し、開発者はインフラ管理から解放されてアプリケーション開発に集中できます。既存のコンテナ資産をそのまま活用でき、ローカル開発環境との整合性が高い点も大きな強みです。

成功する導入のポイント

Cloud Runで成果を上げるには、アプリケーションのステートレス化、適切なスケーリング設定、コールドスタート対策の3点が重要です。特にデータベース接続プールの管理とメモリ使用量の最適化は、安定運用のために欠かせません。コスト最適化には処理時間の短縮とリソース割り当ての適正化が効果的で、継続的なモニタリングと改善が必要です。

今後の展望と推奨アクション

2026年5月時点でCloud Runは成熟したサービスであり、本番環境での採用事例が急増しています。今後はさらに機能が拡充され、より複雑なワークロードにも対応していくことが予想されます。まずは小規模なAPIやマイクロサービスから導入を開始し、実運用での知見を蓄積してから段階的に適用範囲を拡大することを推奨します。ローカル環境でのコンテナ動作確認から始め、開発環境での検証を経て本番展開へと進めることで、リスクを最小化しながら確実に成果を得ることができます。