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

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

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

この記事は、Cloud Run公式ドキュメントに忠実に、コストを決める仕組みを分解し、実コードと試算で「どこを回せばいくら変わるか」を示します。本番運用の全体像は Cloud Run 本番運用ガイド を参照してください。

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

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

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

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

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

無料枠（月あたりの目安）：約 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）

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

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

A higher concurrency setting lets fewer instances handle the same request volume, which can reduce costs.（— Best practices for cost-optimized Cloud Run services）

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

チューニングの指針：

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

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）

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

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

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

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）。

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

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）

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

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

# 既定（リクエスト課金）：散発トラフィック向き
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＝インスタンス課金）。

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

冷起動（cold start）を縮める

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

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

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

2. 起動CPUブースト

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

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

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

gen1（gVisor）は冷起動が速く、軽量APIに向きます。完全なLinux互換やNFS・VPC性能が要るなら gen2。冷起動最優先なら gen1 を明示します。

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

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

# 良い例：プール/クライアントはモジュールスコープで一度だけ生成 → インスタンス内で再利用
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 自前ホスティングの損益分岐と通底する考え方です。

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

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

公式のコスト最適化ガイドを、実務で使える順に整理します。

• 最大インスタンスで上限を作る（暴走・攻撃・ループによる青天井を止める安全弁）
• 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 本番運用ガイド、どのコンピュートを選ぶかは GCPコンテナ技術選定ガイド へ。

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