# Cloud Run の並行性・オートスケール・課金モデルとコスト最適化：スケールトゥゼロと冷起動を実コードで攻略

> Cloud Runのコストを決める3要素——並行性（既定80・最大1000）・オートスケール（60%使用率目標・スケールトゥゼロ）・課金モデル（リクエスト課金 vs インスタンス課金）——を公式仕様に忠実に解説。冷起動対策（最小インスタンス・起動CPUブースト・gen1/gen2・スリムイメージ）、損益分岐の試算、コスト最適化チェックリストまでをgcloud・Terraformの実コードで体系化します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: GCP, Cloud Run, コスト最適化, オートスケール, サーバーレス, パフォーマンス, インフラ, FinOps
- URL: https://tomodahinata.com/blog/google-cloud-run-autoscaling-concurrency-billing-cost-optimization-guide
- カテゴリ: Google Cloud Run 本番運用
- 総合ガイド: https://tomodahinata.com/blog/google-cloud-run-production-guide

## 要点

- Cloud Runの原価は『並行性 × インスタンス数 × 単価』。並行性（1インスタンスが同時に捌くリクエスト数・既定80）を上げると、同じ負荷をより少ないインスタンスで捌けて安くなる。並行性1はコストもスケール性能も悪化させる
- 課金は2モード。リクエスト課金（--cpu-throttling・既定）はリクエスト処理中のみCPU課金で散発トラフィック向き。インスタンス課金（--no-cpu-throttling）はライフサイクル全体で課金されるが、レスポンス後のバックグラウンド処理が可能で定常トラフィック向き
- スケールトゥゼロが最大のコスト武器。トラフィックゼロなら課金ゼロ。代償は冷起動。最小インスタンスで温める・起動CPUブースト・gen1・スリムイメージ・遅延初期化・接続再利用で冷起動を縮める
- オートスケールは60%使用率を目標にインスタンス数を調整。最大インスタンス（既定100）はコストの安全弁、最小インスタンスは冷起動の保険。両方を必ず設定する
- 公式のコスト最適化の柱は『最大インスタンスで上限を作る』『CPU/メモリを右サイズ化』『並行性を上げる』『認証必須で無駄リクエストを止める』『Direct VPC egressでコネクタ常駐費を消す』『同一リージョン配置』

---

Cloud Runの請求書は、ある日突然跳ねます。「無料枠で動いていたはずなのに」「スパイクが来たらインスタンスが青天井に増えた」「最小インスタンスを盛ったら常時課金が乗っていた」——これらはすべて、**並行性・オートスケール・課金モデルという3つのダイヤルを理解していない**ことから来ます。逆に言えば、この3つを押さえれば、Cloud Runは**「速く・安く」を両立できる、極めてコスト効率の高い基盤**になります。

私は[放送事業者向けプラットフォームをGCP・Cloud Runで運用](/case-studies/broadcaster-ai-content-platform)する中で、**本番リージョンは最小インスタンスで温め、副リージョンはゼロスケールでDR用**という非対称構成にして、平常時コストと障害時の回復性を両立させていました。コストは「我慢」ではなく「設計」で決まります。

この記事は、**[Cloud Run公式ドキュメント](https://docs.cloud.google.com/run/docs/tips/services-cost-optimization)に忠実に**、コストを決める仕組みを分解し、実コードと試算で「どこを回せばいくら変わるか」を示します。本番運用の全体像は [Cloud Run 本番運用ガイド](/blog/google-cloud-run-production-guide) を参照してください。

> ⚠️ **価格について**：本記事の単価は2026年6月時点・Tier 1リージョン・リクエスト課金の目安です。価格は改定されます。実額は必ず公式の [Cloud Run pricing](https://cloud.google.com/run/pricing) で最新を確認してください。本記事の価値は「**何が原価を動かすか**」という構造の理解にあります。

---

## 原価の式：何にお金を払っているのか

Cloud Run（Services）の課金は、突き詰めると3つの軸の積です。

1. **CPU時間**（vCPU秒）
2. **メモリ時間**（GiB秒）
3. **リクエスト数**（100万件あたり）

**Tier 1リージョン・リクエスト課金の目安単価**：

| 項目 | 目安単価（無料枠超過分） |
|------|----------------------|
| CPU | 約 **$0.000024 / vCPU秒** |
| メモリ | 約 **$0.0000025 / GiB秒** |
| リクエスト | 約 **$0.40 / 100万リクエスト** |

**無料枠（月あたりの目安）**：約 **240,000 vCPU秒**・**450,000 GiB秒**・**200万リクエスト**。さらに**使用量は100ミリ秒単位で切り上げ**られます。

ここで決定的に重要なのは——**課金されるのは「インスタンスが起きている時間 × 確保したCPU/メモリ」**だということ。つまり原価は「**何インスタンスが、どれだけの時間、どれだけのリソースを確保して起きていたか**」で決まります。だから、**インスタンス数を減らす（＝並行性を上げる）**ことと、**起きている時間を減らす（＝スケールトゥゼロ／適切なアイドル管理）**ことが、コスト最適化の二大レバーになります。

---

## ダイヤル1：並行性（concurrency）— 原価の中心

並行性は「**1インスタンスが同時に何リクエストまで捌くか**」です。

> The maximum concurrency ... is `80`. The maximum value is `1000`. ... a concurrency of `1` is likely to negatively affect scaling performance, because many instances will have to start up to handle a spike.（— [About concurrency](https://docs.cloud.google.com/run/docs/about-concurrency)）

**並行性がなぜ原価を決めるのか**を、数字で見ます。同時に **400リクエスト** を捌くケース：

| 並行性 | 必要インスタンス数（概算） | 相対コスト |
|-------|--------------------------|----------|
| 1 | 400 | 高い（インスタンス数＝リクエスト数） |
| 10 | 40 | |
| **80**（既定） | **5** | **低い** |

並行性を上げるほど、**同じ負荷をより少ないインスタンスで捌ける**＝起きているインスタンス時間が減る＝安くなります。公式のコスト最適化ガイドも明言しています。

> A higher concurrency setting lets fewer instances handle the same request volume, which can reduce costs.（— [Best practices for cost-optimized Cloud Run services](https://docs.cloud.google.com/run/docs/tips/services-cost-optimization)）

**ただし無条件ではありません**。並行性を上げられるのは、アプリが**リクエストを並行に捌ける**（I/O待ちが主＝DB・外部API呼び出し）場合です。1リクエストでCPUを食い尽くす処理（画像変換・重い計算）で並行性を上げると、レイテンシが悪化します。

**チューニングの指針：**

- **I/Oバウンド（DB・API待ちが多い）** → 並行性を上げて密度を稼ぐ（80→100〜の検討）。
- **CPUバウンド（重い計算）** → 並行性を下げる、ただし**1は避ける**（スケール性能とコストが悪化）。
- **並行性1が妥当なのは例外**：1リクエストがインスタンスのリソースを完全占有する、グローバル状態が並行に弱い、などの明確な理由があるときだけ。

```bash
gcloud run deploy api --concurrency 80 --region asia-northeast1 ...
```

---

## ダイヤル2：オートスケール — 60%目標とスケールトゥゼロ

Cloud Runは需要に応じてインスタンス数を自動調整します。

> The autoscaler ... targets ... 60% CPU utilization / 60% concurrency utilization by default. ... revisions scale to zero instances when not receiving traffic ... instances are kept idle for up to 15 minutes.（— [About instance autoscaling](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)）

- **60%使用率を目標**にインスタンス数を増減（CPU使用率・並行使用率の両面）。
- **トラフィックが無ければゼロまで縮む（scale to zero）**。これが最大のコスト武器。
- リクエスト処理後、**最大15分はインスタンスを温存**して冷起動を減らす。

### 最小インスタンスと最大インスタンスを必ず設定する

- **最大インスタンス（max instances・既定100）**＝**コストの安全弁**。スパイクやループ、攻撃で青天井に増えるのを止める。
- **最小インスタンス（min instances）**＝**冷起動の保険**。常時温めて初回レイテンシを消す。ただし**温めた分は常時課金**される。

```bash
gcloud run deploy api --region asia-northeast1 \
  --min-instances 1 \    # 入口は1台温める（冷起動を消す）。0ならフルにゼロスケール
  --max-instances 10     # コストの安全弁。これ以上は増やさない
```

> **「全部を温める」必要はありません。** 私のプロジェクトでは、ユーザーが直接触る本番リージョンの入口だけ `min-instances=1` で温め、**副リージョンと、内部バッチ系サービスは `min-instances=0`** にしていました。冷起動が許容できる経路はゼロスケールに振り、許容できない経路だけ温める——この**選択的な温め**が、コストと体験のスイートスポットです。

---

## ダイヤル3：課金モデル — リクエスト課金 vs インスタンス課金

ここが最も誤解されやすく、最もコストに効きます。Cloud Runには**2つの課金モード**があり、これは**CPUの割り当て方**で決まります（[Billing settings](https://docs.cloud.google.com/run/docs/configuring/billing-settings)）。

| | **リクエスト課金（既定）** | **インスタンス課金** |
|---|--------------------------|---------------------|
| フラグ | `--cpu-throttling` | `--no-cpu-throttling` |
| CPUの割り当て | **リクエスト処理中のみ** | **インスタンスのライフサイクル全体** |
| 課金タイミング | リクエスト処理中＋起動/終了時 | 起きている間ずっと |
| レスポンス後のバックグラウンド処理 | できない（CPUが絞られる） | **できる** |
| 向くトラフィック | **散発・スパイク・バースト** | **定常・緩やかに変化** |

公式の使い分けはシンプルです。

> For services with steady, slowly varying traffic, consider using instance-based billing ... services with sporadic, bursty, or spiky traffic, consider using request-based billing.（— [Cost optimization best practices](https://docs.cloud.google.com/run/docs/tips/services-cost-optimization)）

### どちらを選ぶか：3つの判断

1. **トラフィックが散発・スパイク的** → **リクエスト課金**（既定）。アイドル時にCPU課金が止まるので、間欠負荷で圧倒的に安い。
2. **トラフィックが定常的・高稼働** → **インスタンス課金**を検討。常に処理しているなら、絞ったり戻したりのオーバーヘッドが無いぶん有利になり得る。
3. **レスポンスを返した後にバックグラウンド処理をしたい**（非同期のログ送信、後処理、キャッシュ更新） → **インスタンス課金**。リクエスト課金ではレスポンス後にCPUが絞られ、後処理が走らない。

```bash
# 既定（リクエスト課金）：散発トラフィック向き
gcloud run deploy api --cpu-throttling --region asia-northeast1 ...

# インスタンス課金：定常トラフィック / レスポンス後のバックグラウンド処理が要る
gcloud run deploy worker --no-cpu-throttling --region asia-northeast1 ...
```

Terraformでは `resources.cpu_idle` で表現します（`true`＝リクエスト課金、`false`＝インスタンス課金）。

```hcl
resources {
  limits   = { cpu = "1", memory = "512Mi" }
  cpu_idle = true   # true=リクエスト課金（既定・散発向き） / false=インスタンス課金（定常向き）
}
```

---

## 冷起動（cold start）を縮める

スケールトゥゼロの代償が**冷起動**です。ゼロから起きるとき、コンテナ起動＋アプリ初期化の時間だけ初回レイテンシが伸びます。打ち手は段階的にあります。

### 1. 最小インスタンスで温める（最も確実）

`--min-instances 1` 以上にすれば、その分は常に起きていて冷起動がゼロになります。**確実だが常時課金**。「ユーザーが体感する経路」だけに使うのがコツ。

### 2. 起動CPUブースト

`--cpu-boost` で**起動中だけCPUを増やし**、初期化を速くします。追加費用は小さく効果は大きい、定番の設定です。

```bash
gcloud run deploy api --cpu-boost --region asia-northeast1 ...
```

### 3. 実行環境を選ぶ（gen1 は冷起動が速い）

[gen1（gVisor）は冷起動が速く](https://docs.cloud.google.com/run/docs/about-execution-environments)、軽量APIに向きます。完全なLinux互換やNFS・VPC性能が要るなら gen2。冷起動最優先なら gen1 を明示します。

### 4. イメージを小さくする・初期化を遅らせる

- **スリムなベースイメージ**（`distroless`・`alpine`・マルチステージビルド）で起動を速く。
- **遅延初期化**：起動時に全部読み込まず、必要になってから初期化。
- **接続の再利用**：DB/HTTPクライアントは**ハンドラの外で一度だけ生成**し、インスタンス内で使い回す（毎リクエストで接続を張らない）。

```python
# 良い例：プール/クライアントはモジュールスコープで一度だけ生成 → インスタンス内で再利用
import httpx
client = httpx.AsyncClient(timeout=10.0)   # ハンドラの外。再利用される。

@app.get("/proxy")
async def proxy():
    r = await client.get("https://upstream.example/api")  # 接続を張り直さない
    return r.json()
```

冷起動対策は「**温める（金で解決）**」と「**速く起きる（設計で解決）**」の二段構え。まず設計で起動を速くし、それでも足りない体感経路だけ温める——この順序がコスト効率的です。

---

## 損益分岐の考え方：ざっくり試算

「リクエスト課金とインスタンス課金、どっちが安いか」を体感するため、**1 vCPU / 512 MiB のサービス**で考えます（単価は前掲の目安）。

- **インスタンスが1台、1か月（約 2,592,000 秒）起きっぱなし**だと：
  - CPU：2,592,000 秒 × $0.000024 ≈ **$62**
  - メモリ：2,592,000 秒 × 0.5 GiB × $0.0000025 ≈ **$3.2**
  - 合計 ≈ **$65/月**（無料枠超過分、リクエスト課金不要なインスタンス課金の上限イメージ）

- 一方、**1日合計1時間しかリクエストが来ない**散発サービスなら、リクエスト課金では**実際に処理した時間しか課金されない**ため、桁違いに安くなります（理屈上 1/24 以下）。

**結論の感覚**：

- **稼働率が低い（アイドルが長い）** → **リクエスト課金 × スケールトゥゼロ**が圧勝。
- **ほぼ常時処理している（高稼働）** → **インスタンス課金**が有利になり得る。さらに定常負荷なら**確約利用割引（committed use discounts）**も検討対象。
- **判断軸は「稼働率」**。これはAWS Lambdaの「常時稼働ならFargate/EC2が安くなる」のと同じ構造で、[API vs 自前ホスティングの損益分岐](/blog/generative-ai-cost-api-vs-self-hosting-decision-guide)と通底する考え方です。

> 実額は構成・リージョン・トラフィック分布で大きく変わります。**必ず[公式pricing](https://cloud.google.com/run/pricing)とCloud Billingの実データで検証**してください。ここで持ち帰ってほしいのは「**稼働率という一本の軸で課金モードを選ぶ**」という判断の型です。

---

## コスト最適化チェックリスト（公式ベストプラクティス）

[公式のコスト最適化ガイド](https://docs.cloud.google.com/run/docs/tips/services-cost-optimization)を、実務で使える順に整理します。

- [ ] **最大インスタンスで上限を作る**（暴走・攻撃・ループによる青天井を止める安全弁）
- [ ] **CPU/メモリを右サイズ化**（ピーク時でも使用率が低いなら下げる。メトリクスで判断）
- [ ] **並行性を上げる**（I/Oバウンドなら密度を稼いでインスタンス数を減らす。1は避ける）
- [ ] **課金モードを稼働率で選ぶ**（散発→リクエスト課金 / 定常→インスタンス課金）
- [ ] **最小インスタンスは必要な経路だけ**（全部を温めない。体感経路に絞る）
- [ ] **認証を必須に**（`--no-allow-unauthenticated`。無駄・不正リクエストはそのままコスト）
- [ ] **Direct VPC egress に移行**（Serverless VPCコネクタの常駐VM・アイドル費を消す）
- [ ] **同一リージョンに配置**（リージョン間データ転送費を避ける）
- [ ] **静的コンテンツは Cloud CDN**（Cloud Runにリクエストを到達させない）
- [ ] **イメージをスリムに**（冷起動短縮＝起動課金とレイテンシの両方を改善）
- [ ] **Budget alerts / Recommender を有効化**（請求の異常を早期検知し、最適化提案を受ける）

---

## 監視：請求を「設計の結果」として観測する

コスト最適化は一度きりではなく、**観測してチューニングし続ける**営みです。

- **Cloud Monitoring**：インスタンス数・CPU/メモリ使用率・リクエスト数・レイテンシ。使用率が常時低ければ右サイズ化のサイン。
- **Budget alerts**：閾値超過で通知。請求の異常（無限ループ・攻撃）を早期に掴む。
- **Recommender**：実トラフィックに基づく最適化提案を受け取る。
- **Cloud Run の Billing パネル / Cost Explorer**：どのサービス・どのリビジョンがコストを生んでいるかを分解。

> コストは「我慢」ではなく「設計と観測」の結果です。私が非対称リージョン構成（本番は温め・副リージョンはゼロスケール）に到達できたのも、メトリクスで「どこにいくらかかっているか」を可視化していたからです。**まず観測、次に設計、そして検証**——この順番を守れば、Cloud Runは速さとコストを両立できます。

---

## まとめ：3つのダイヤルで「速く・安く」

Cloud Runのコストは、3つのダイヤルで決まります。

1. **並行性** — 上げればインスタンス数が減って安くなる（I/Oバウンドなら。1は避ける）。
2. **オートスケール** — スケールトゥゼロが最大の武器。最小/最大インスタンスで「温める保険」と「コストの安全弁」を両立。
3. **課金モデル** — 稼働率で選ぶ。散発ならリクエスト課金、定常ならインスタンス課金。

そして冷起動は「設計で速く起こす」を先に、「温めて金で解決」を後に。最後に**観測してチューニングし続ける**。これだけで、Cloud Runは**スタートアップや一人開発でも本番品質を保ちつつ、請求書に怯えない**基盤になります。

全体の本番設計は [Cloud Run 本番運用ガイド](/blog/google-cloud-run-production-guide)、どのコンピュートを選ぶかは [GCPコンテナ技術選定ガイド](/blog/google-cloud-run-vs-gke-app-engine-cloud-run-functions-compute-selection-guide) へ。

GCPのコスト設計・基盤構築でお困りなら、**一人 × 生成AIで、速く・安く・安全に**伴走します。放送事業者プラットフォームをCloud Runで運用してきた実コストの肌感を踏まえ、御社の負荷特性に合う構成と課金設計を一緒に詰めましょう。