はじめに
「Cloud Runって何？」
プログラミングを学び始めると、Webアプリケーションを「どこで動かすか」という壁にぶつかります。自分のパソコンでは動くけど、インターネットに公開するにはサーバーが必要。でもサーバーって高いし、管理も大変そう...。
この記事では、そんな悩みを解決するGoogle Cloud Runについて、サーバーやクラウドの基礎知識がない方でも理解できるよう、図解を交えて徹底的に解説します。
この記事の対象読者
- プログラミング初心者で、クラウドやサーバーもよく分かっていない方
- 「Cloud Runって何？」と検索してこの記事にたどり着いた方
- 自分で作ったWebアプリを公開したいけど、サーバーの選び方が分からない方
この記事で得られること
- サーバー、クラウド、コンテナの基本的な理解
- Cloud Runの概念と必要性
- 自前サーバー管理 vs Cloud Run の違い（As-Is / To-Be分析）
- 主要クラウドサービスの選び方（Fit & Gap分析）
1. 前提知識の整理：サーバー・クラウド・コンテナとは
Cloud Runを理解するには、まず「サーバー」「クラウド」「コンテナ」という3つの概念を知る必要があります。難しく考える必要はありません。身近な例で説明します。
サーバー ＝ 24時間営業のコンビニ
サーバーは、インターネット上でプログラムを動かし続けるコンピュータです。あなたのWebアプリを24時間365日、いつでも利用できる状態にしておく「お店」のようなものです。
自分のパソコンでWebアプリを動かすと、パソコンを閉じたら誰もアクセスできなくなります。だから、常に電源が入っている専用のコンピュータ（サーバー）が必要なのです。
クラウド ＝ レンタルサーバー屋さん
クラウドは、サーバーを「借りられる」サービスです。自分でサーバーを買って管理するのは大変なので、Google、Amazon、Microsoftなどの大企業が運営する巨大なサーバー群を、必要な分だけ借りて使います。
| 用語 | 身近な例 | 説明 |
|---|---|---|
| 物理サーバー | 自社ビルを建てる | 自分でサーバーを買って管理する |
| クラウド | 賃貸マンション | 必要な分だけ借りて使う |
コンテナ ＝ 引っ越し用の段ボール
コンテナは、アプリケーションとその動作に必要なものを「ひとまとめ」にしたパッケージです。
引っ越しを想像してください。荷物をバラバラに運ぶと「あれがない」「これが足りない」となりますが、段ボールにまとめておけば、どこに運んでもすぐに使えます。コンテナも同じで、アプリケーションを動かすのに必要なもの（プログラム、ライブラリ、設定ファイルなど）をすべて1つのパッケージにまとめます。
Cloud Runの構成要素（ER図）
Cloud Runは、いくつかの階層構造で管理されています。
この図は「ER図（Entity-Relationship Diagram）」と呼ばれ、要素同士の関係を表します。
-
PROJECT：Google Cloudの管理単位（請求やアクセス権限の単位） -
SERVICE：1つのWebアプリやAPI（公開URLが割り当てられる） -
REVISION：デプロイのバージョン（更新するたびに新しいリビジョンが作られる） -
CONTAINER：実際に動くコンテナの設定
ここまでのポイント
サーバー = プログラムを24時間動かすコンピュータ
クラウド = サーバーを借りられるサービス
コンテナ = アプリを動かすのに必要なものをまとめたパッケージ
2. Cloud Runとは
一言でいうと
Cloud Run（クラウド・ラン）は、Google Cloudが提供する 「コンテナ化したアプリケーションを、サーバーの管理なしで動かせる実行基盤（サーバーレス・プラットフォーム）」 です。
もっと簡単に言うと、 「プログラムをコンテナ（Dockerなど）に入れて渡せば、あとはGoogleが勝手にサーバーを立てて、アクセス数に合わせて増やしたり減らしたりしてくれるサービス」 です。
身近な例で理解する
Cloud Runは「タクシー配車アプリ」に例えると分かりやすいです。
自分で車を所有すると、使わない時でも駐車場代や保険料がかかります。でもタクシーなら、乗った時だけお金を払えばOK。Cloud Runも同じで、アクセスがない時は料金がかからないのです。
Cloud Runが解決する課題
Cloud Runを使わない場合、以下の問題が発生します。
| 問題 | 具体的な状況 |
|---|---|
| 初期費用が高い | サーバーを借りるだけで月額数千円〜数万円かかる |
| 管理が大変 | OSのアップデート、セキュリティ対策を自分でやる必要がある |
| スケールが難しい | アクセスが急増した時に対応できない |
| 無駄なコスト | 誰も使っていない深夜でも同じ料金がかかる |
3. Cloud Runの主な特徴
Cloud Runがなぜ人気なのか、主なメリットは以下の3点です。
3.1 自動スケーリング（ゼロまで減る）
アクセスが増えれば自動で処理能力を増やし、アクセスがゼロになればサーバーもゼロになります。これにより、 「誰も使っていない時間は料金がかからない」 というコスト効率の良さが最大の特徴です。
3.2 サーバー管理が不要（サーバーレス）
OSのアップデート、メモリの増設、負荷分散（ロードバランサー）の設定などを自分でする必要がありません。開発者は「コードを書くこと」だけに集中できます。
3.3 言語やライブラリの制限がない
コンテナ技術を使っているため、Python、Node.js、Go、Java、PHP、Rubyなど、どんな言語でも、どんな特定のライブラリでも動かすことができます。
4. なぜCloud Runが必要なのか
自前サーバー管理の辛さ
Cloud Runを使わない場合、開発者はサーバーを自分で管理する必要があります。
問題1：初期設定が大変
やるべきこと:
├── サーバーを契約
├── OSをインストール
├── セキュリティ設定（ファイアウォール、SSH鍵など）
├── Webサーバー（Nginx/Apache）の設定
├── SSL証明書の取得と設定
├── アプリケーションのデプロイ
└── 監視・ログ収集の設定
初心者が一からやると、数日〜数週間かかることも珍しくありません。
問題2：運用が終わらない
サーバーを立てた後も、以下の作業が永遠に続きます。
- セキュリティパッチの適用（毎月）
- SSL証明書の更新（年1〜2回）
- ディスク容量の監視と対応
- 障害対応（夜中でも...）
問題3：スケールの壁
アクセスが急増した時、サーバー1台では処理しきれません。複数台のサーバーを用意し、ロードバランサーで負荷分散する必要がありますが、これは非常に複雑です。
5. As-Is / To-Be 分析：自前管理 vs Cloud Run
ここでは、ビジネス分析でよく使われる「As-Is / To-Be フレームワーク」を用いて、自前サーバー管理とCloud Run導入の違いを明確にします。
As-Is（現状）：自前サーバー管理の課題
現状の課題一覧
| カテゴリ | 課題 | 影響度 |
|---|---|---|
| コスト | 使っていなくても固定費がかかる | 高 |
| 運用 | セキュリティパッチ適用が手動 | 高 |
| スケール | アクセス急増に即座に対応できない | 高 |
| 学習 | インフラ知識の習得に時間がかかる | 中 |
| 可用性 | 障害時の復旧が自己責任 | 中 |
To-Be（あるべき姿）：Cloud Run導入後
導入後の改善効果
| カテゴリ | 改善内容 | 効果 |
|---|---|---|
| コスト | 使った分だけ課金（ゼロスケール） | ◎ |
| 運用 | インフラ管理はGoogle任せ | ◎ |
| スケール | 自動スケーリング標準搭載 | ◎ |
| 学習 | Dockerの基礎知識だけでOK | ○ |
| 可用性 | 複数ゾーンで自動冗長化 | ○ |
Before / After 比較表
| 観点 | Before（自前管理） | After（Cloud Run） |
|---|---|---|
| 初期設定 | サーバー契約、OS設定、セキュリティ設定... |
gcloud run deploy 1コマンド |
| HTTPS対応 | SSL証明書を自分で取得・設定・更新 | 自動で発行・管理 |
| スケーリング | 手動でサーバー追加、ロードバランサー設定 | 完全自動（設定不要） |
| コスト | 月額固定（使わなくても払う） | 従量課金（使った分だけ） |
| 障害対応 | 自己責任（夜中でも対応） | Google SREチームが24時間監視 |
6. デプロイフローの違い（シーケンス図で理解）
実際のデプロイフローを、シーケンス図で比較してみましょう。
自前サーバーの場合
自前管理の問題点
- ステップ2-5：毎回SSHでログインして手動作業
- ステップ6-10：HTTPS対応だけで複数の外部サービスとやり取り
- ステップ11：設定ミスでサイトがダウンするリスク
Cloud Runの場合
Cloud Runのメリット
- ステップ2-5：Dockerイメージを作ってpushするだけ
-
ステップ6-10：
gcloud run deploy1コマンドで全自動 - ステップ11-13：スケーリングも自動、手作業ゼロ
7. Fit & Gap 分析：どのサービスを選ぶべきか
クラウドには似たサービスがたくさんあります。「Fit & Gap 分析」を用いて、あなたの状況に最適なサービスを選びましょう。
主要サービスの概要
| サービス | プロバイダ | 種類 | 難易度 | 特徴 |
|---|---|---|---|---|
| Cloud Run | Google Cloud | コンテナ実行 | ★☆☆ | ゼロスケール、最も簡単 |
| App Engine | Google Cloud | PaaS | ★☆☆ | コードだけで動く、歴史が長い |
| GKE | Google Cloud | Kubernetes | ★★★ | 最高の自由度、複雑 |
| AWS Lambda | AWS | 関数実行 | ★★☆ | イベント駆動、15分制限 |
| AWS Fargate | AWS | コンテナ実行 | ★★☆ | ECS/EKSと連携 |
| Azure Container Apps | Microsoft | コンテナ実行 | ★★☆ | Cloud Runに近い |
Fit & Gap 分析表
あなたの状況（左列）と各サービスの適合度を確認してください。
| 判断軸 | Cloud Run | App Engine | GKE | Lambda | Fargate | Azure Container Apps |
|---|---|---|---|---|---|---|
| 初心者で簡単に始めたい | ◎ | ◎ | × | ○ | △ | ○ |
| Dockerを使いたい | ◎ | △ | ◎ | △ | ◎ | ◎ |
| コストを最小限に | ◎ | ○ | × | ◎ | △ | ◎ |
| 15分以上の処理が必要 | ◎ | ◎ | ◎ | × | ◎ | ◎ |
| Kubernetesの知識がある | - | - | ◎ | - | ○ | ○ |
| AWSを既に使っている | △ | △ | △ | ◎ | ◎ | △ |
| Azureを既に使っている | △ | △ | △ | △ | △ | ◎ |
| GPU処理が必要 | ◎ | × | ◎ | × | × | ○ |
選定フローチャート
Gap（不足・課題）の対処法
各サービスには弱点もあります。事前に把握しておきましょう。
| サービス | Gap（弱点） | 対処法 |
|---|---|---|
| Cloud Run | コールドスタート（初回起動が遅い） | 最小インスタンス数=1に設定（ただし常時課金） |
| App Engine | コンテナのカスタマイズ性が低い | Flexible環境を使うか、Cloud Runへ移行 |
| GKE | 学習コストが高い、常時課金 | GKE Autopilotで管理負担を軽減 |
| AWS Lambda | 15分のタイムアウト制限 | Step Functionsで分割、またはFargateへ |
| AWS Fargate | ゼロスケールができない | Lambda併用、またはCloud Runへ |
| Azure Container Apps | GPUサポートが限定的 | AKSを検討 |
8. 各サービスの詳細紹介
8.1 Cloud Run（Google Cloud）
Google Cloudが提供するサーバーレスコンテナ実行環境。2019年にGA（一般提供）となり、2025年現在は最も人気のあるサーバーレスプラットフォームの1つです。
特徴
- ゼロスケール対応：アクセスがなければインスタンス0、料金0
- HTTPS自動発行：独自ドメインも簡単に設定可能
- GPU対応：NVIDIA L4 GPUでAI推論も可能（2024年〜）
基本的な使い方
# ステップ1：Dockerイメージを作成
docker build -t gcr.io/[PROJECT-ID]/my-app .
# ステップ2：Container Registryにプッシュ
docker push gcr.io/[PROJECT-ID]/my-app
# ステップ3：Cloud Runにデプロイ
gcloud run deploy my-app \
--image gcr.io/[PROJECT-ID]/my-app \
--platform managed \
--region asia-northeast1 \
--allow-unauthenticated
料金体系（2025年版）
| 項目 | 課金タイミング | 無料枠（毎月） |
|---|---|---|
| vCPU | リクエスト処理中のみ | 180,000 vCPU秒 |
| メモリ | リクエスト処理中のみ | 360,000 GiB秒 |
| リクエスト数 | 100万件ごと | 200万リクエスト |
8.2 App Engine（Google Cloud）
Google Cloudの最古参PaaS（Platform as a Service）。2008年から提供されており、コードをアップロードするだけで動く手軽さが特徴です。
特徴
- コードだけでOK：Dockerを知らなくても使える
- 自動スケーリング：Standard環境はミリ秒単位で起動
- 豊富な実績：長年の運用で安定性が高い
基本的な使い方
# app.yamlを作成
runtime: python39
# デプロイ
gcloud app deploy
8.3 GKE（Google Kubernetes Engine）
Kubernetesのフルマネージドサービス。最も自由度が高い反面、学習コストも高めです。
特徴
- Kubernetes完全対応：オープンソースのKubernetesをそのまま使える
- 高度なネットワーク制御：Service Mesh、Istioなどと連携
- Autopilotモード：ノード管理を自動化（2021年〜）
8.4 AWS Lambda（Amazon Web Services）
AWSのサーバーレス関数実行サービス。イベント駆動型の処理に最適です。
特徴
- イベント駆動：S3へのアップロード、API Gatewayからのリクエストなどで起動
- 豊富な連携：AWSの100以上のサービスと統合
- ミリ秒課金：1ms単位で課金
料金体系
| 項目 | 単価（US East） | 無料枠（毎月） |
|---|---|---|
| リクエスト | $0.20 / 100万件 | 100万リクエスト |
| 実行時間 | $0.0000166667 / GB秒 | 400,000 GB秒 |
制限事項
- 実行時間：最大15分
- メモリ：128MB〜10GB
- ペイロード：6MB（同期）、256KB（非同期）
8.5 AWS Fargate（Amazon Web Services）
AWSのサーバーレスコンテナ実行環境。ECSまたはEKSと組み合わせて使用します。
特徴
- ECS/EKS対応：既存のコンテナオーケストレーションと連携
- VPC統合：プライベートネットワーク内で実行可能
- Spotインスタンス：最大70%割引（中断あり）
料金体系
| 項目 | 単価（US East, Linux/x86） |
|---|---|
| vCPU | $0.04048 / vCPU時間 |
| メモリ | $0.004445 / GB時間 |
注意点
- ゼロスケール非対応：最低1タスクは起動したまま（常時課金）
- Cloud Runより約40%高い：同等スペックでの比較
8.6 Azure Container Apps（Microsoft Azure）
MicrosoftのサーバーレスコンテナプラットフォームCloud Runに最も近い設計思想を持っています。
特徴
- ゼロスケール対応：Cloud Runと同様
- Dapr統合：マイクロサービス開発を支援するランタイム内蔵
- KEDA対応：Kubernetesベースのイベント駆動オートスケーラー
料金体系
| 項目 | 無料枠（毎月） |
|---|---|
| vCPU | 180,000 vCPU秒 |
| メモリ | 360,000 GiB秒 |
| リクエスト | 200万リクエスト |
9. 料金シミュレーション（月額目安）
Cloud Runの料金を、実際のアクセス数を想定してシミュレーションします。
前提条件
- リージョン：東京（asia-northeast1）
- スペック：1 vCPU、512MB メモリ
- 処理時間：1リクエストあたり500ミリ秒（0.5秒）
- 同時実行数：80（1インスタンスで80リクエストを並行処理）
- 為替：1ドル = 150円
シミュレーション結果
| 規模 | 1日のアクセス数 | 月間リクエスト数 | 月額料金の目安 | 状態 |
|---|---|---|---|---|
| 個人・開発用 | 100件 | 3,000件 | 0円 | 無料枠内で余裕 |
| 小規模API | 3,000件 | 90,000件 | 0円 | まだ無料枠に収まる |
| 中規模サイト | 30,000件 | 900,000件 | 数百円程度 | 無料枠を超え始める |
| ビジネス利用 | 100万件 | 3,000万件 | 約5,000円〜 | 転送料が加算 |
無料枠のパワー（毎月リセット）
Google Cloudは太っ腹な無料枠を提供しており、以下の分までは毎月タダです。
- リクエスト数：最初の200万リクエスト/月
- CPU時間：最初の180,000 vCPU秒/月（1vCPUなら計50時間分）
- メモリ：最初の360,000 GiB秒/月
サービス間の料金比較
同等スペック（1 vCPU、2GB メモリ）で24時間稼働した場合の月額目安：
| サービス | 月額目安 | ゼロスケール | 備考 |
|---|---|---|---|
| Cloud Run | 約3,000円〜 | ◎ | アクセス0なら0円 |
| App Engine (Standard) | 約3,500円〜 | ◎ | アクセス0なら0円 |
| AWS Lambda | 約2,500円〜 | ◎ | 15分制限あり |
| AWS Fargate | 約7,000円〜 | × | 常時起動が前提 |
| Azure Container Apps | 約3,000円〜 | ◎ | Cloud Runと同等 |
| GKE Autopilot | 約15,000円〜 | × | 最低1ノード必要 |
※ 料金は概算です。実際の料金は利用状況により変動します。
10. 2025年の注目アップデート
Cloud Runは急速に進化しています。最近の注目アップデートを紹介します。
GPU対応（NVIDIA L4）
NVIDIA L4 GPUを搭載したインスタンスが利用可能になり、生成AIモデルの推論などをサーバーレスで安価に実行できるようになりました。
Gemini連携
Google CloudのコンソールからAI（Gemini）にコードを生成させたり、トラブルシューティングを相談したりしながらデプロイできるようになっています。
ワーカープール
HTTPリクエストを介さない、KafkaやPub/Subなどのキューを処理するための専用リソースも追加されました。
まとめ
Cloud Runとは
コンテナ化したアプリケーションを、サーバーの管理なしで動かせるGoogleのサーバーレスプラットフォーム。
なぜ必要か
- 自前サーバー管理は初期設定・運用・スケーリングが大変
- Cloud Runなら「コマンド1つ」でデプロイ、あとは全自動
サービスの選び方
| 状況 | 推奨サービス |
|---|---|
| 初心者でとにかく簡単に始めたい | Cloud Run または App Engine |
| AWSを既に使っている | AWS Lambda（短時間処理）または Fargate（長時間処理） |
| Azureを既に使っている | Azure Container Apps |
| 大規模・複雑なシステム | GKE Autopilot |
どんな時にCloud Runを使うべき？
- スタートアップや新規事業：アクセス数が読めないため、ゼロスケーリングでコストを抑えたい
- マイクロサービス：サービスごとに言語を使い分け、素早くデプロイしたい
- AI推論エンジン：必要な時だけGPUを使って安く推論を行いたい
次のステップ
- Google Cloudのアカウントを作成（無料枠あり）
- 簡単なDockerイメージを作成
-
gcloud run deployでデプロイしてみる
Cloud Runは、最初は「よく分からないサービス」に見えますが、使いこなせるようになるとWebアプリ公開のハードルが劇的に下がります。ぜひ実際に手を動かして試してみてください！