概要
「オートスケールするので大丈夫」は定性論
Cloud Runのオートスケールは瞬時ではなく、新規コンテナの起動時間（コールドスタート）を必ず伴う。今回は平均1.8秒/インスタンスというレイテンシを数値化せずに判断していた。
レイテンシ悪化はCVRで金額に変換する
実測CVR差（4.2% → 2.8%）をそのまま放置せず、セッション数×客単価で機会損失額に変換して初めて、削減額と同じ土俵で比較できる。
一律設定ではなく時間帯で制御する
平常時とフラッシュセール時ではトラフィックの急変度がまったく違う。Cloud Scheduler + Admin APIでmin-instancesを時間帯別に自動制御すれば、コスト最小化とリスク回避を両立できる。
削減額とリスクは同じ通貨で比較する
「9,817円/月の削減」だけを見ると魅力的だが、比較対象であるリスク側（今回は月437万円）を金額換算しない限り、意思決定の土台が成立しない。
問題
ECサイト MOps チームのシニアエンジニアとして、バナー配信API（banner-api、Cloud Run v2）のインフラコストレビューを任された。後輩エンジニアが「常時稼働のための待機コストが無駄なので、min-instances を全時間帯 0 にすべき」という Bad コスト比較メモを作成し、来週のインフラ定例でこのまま提案する予定だという。
以下の Bad メモから 試算・設計上の問題（7点）を洗い出し、コールドスタートが売上（CVR）に与える影響の金額換算・時間帯別min-instancesスケジューリング設計・現状案/Bad案/Good案の比較・実装工数とROI・インフラ定例への推奨文までを一気通貫で回答してください。
制約・前提条件
- Cloud Run v2 料金前提（東京リージョン想定）: vCPU $0.000024/秒（常時割り当て時）/ メモリ $0.0000025/GiB秒 / リクエスト $0.40/百万件（Bad・Good共通のため比較対象外）/ 為替1USD=150円
- banner-api構成: 1vCPU/512MiB、現状min-instances=1（CPU常時割り当てON）で24時間365日稼働。concurrency（同時実行数）設定: 40req/インスタンス
- コンテナイメージ: 850MB（Python 3.12 + 依存ライブラリ）、実測コールドスタート時間: 平均1.8秒/インスタンス
- トラフィックパターン: 平常時は平均5req/秒。フラッシュセールは月4回×2時間、開始と同時にプッシュ通知を一斉配信するため5→200req/秒へ1分未満で急増
- 実測CVR: セール実測（min-instances=1、コールドスタートなし）= 4.2% / min-instances=0で運用していた別サービスの同種スパイクでの実測 = 2.8%（レイテンシ悪化・タイムアウト離脱が主因）
- セール1回あたりセッション数12,000件、平均客単価6,500円
- エンジニア単価: 80万円/月（20営業日=4万円/人日）。Cloud Scheduler+Admin API連携の実装工数: 2人日
期待する回答形式: 問題点の列挙（番号付き） + 現状の待機コスト再検証 + コールドスタートによるCVR低下の金額換算 + 時間帯別min-instancesスケジューリング設計とコスト試算 + 現状/Bad案/Good案の3案比較 + 実装工数とROI + インフラ定例への推奨文
悪いコスト比較メモ (Before)
このメモには 7つの問題 が隠れています。見つけてみてください。
Bad メモ — コールドスタート未数値化、リスク側の金額換算なし
件名: banner-api Cloud Run コスト削減のご提案
現状: min-instances=1（CPU常時割り当てON）で24時間365日稼働
常時待機コストが約9,800円/月、無駄に発生している
← 問題⑤: 削減額の算出根拠が示されていない
改善案: 全時間帯 min-instances=0 へ変更する
リクエスト時のみ課金されるようになり、待機コストがゼロになる
Cloud Runはオートスケールする仕組みなので、アクセスが増えても
自動的にインスタンスが増えて対応してくれるはず
← 問題①②⑥: コールドスタート(1.8秒)を数値化せず、
フラッシュセールでのスケールアウト遅延・必要インスタンス数の
逆算をしていない
← 問題③④: CVR低下の金額換算なし、時間帯別の使い分けを検討せず
よって全時間帯 min-instances=0 への変更を提案します。
← 問題⑦: 削減額とリスクを比較(ROI)せず結論づけている問題点サマリー（7点）
1コールドスタート(平均1.8秒)を数値化せず定性判断のみ — 「オートスケールするので大丈夫」という安心感だけで結論
25→200req/秒を1分未満で急増する状況でのスケールアウト遅延リスクを見落とし
3実測CVR差(4.2%→2.8%)を金額換算していない — 比較材料があるのに未使用
4平常時とセール時を区別せず一律min-instances=0のみ検討 — 時間帯別スケジューリングの選択肢がない
5削減額「約9,800円/月」の算出根拠が示されておらず未検算
6concurrency(40req/インスタンス)から必要インスタンス数を逆算していない
7削減額とリスク側を比較(ROI)せず、削減額の小ささのみで結論づけている
ヒント（段階的開示）
ヒント1 — 方向性
Bad メモの罠は3系統。(1) 「オートスケールするので大丈夫」という定性的な安心感のみで、コールドスタートという物理的な起動時間（今回は1.8秒/インスタンス）を一切数値化していない — Cloud Runのオートスケールは「瞬時に」ではなく「新しいコンテナを起動してから」応答可能になる仕組みであり、起動中のリクエストは待たされるかタイムアウトする。(2) 通常時とフラッシュセール時という性質の異なる2つのトラフィックパターンを、min-instances=0という単一の設定で一律に扱おうとしている — 平常時5req/秒であれば多少のコールドスタートは許容範囲でも、1分未満で200req/秒へ急増するフラッシュセールでは致命的になりうる。(3) 削減額（待機コスト）とコールドスタートが引き起こしうる損失（売上インパクト）を同じ土俵で比較していない — 「9,800円/月の削減」という数字だけを見て判断すると、比較対象であるリスク側の金額がまったく見えてこない。
ヒント2 — アプローチ
- 問題①: コールドスタート（起動に平均1.8秒）を考慮せず「オートスケールするので問題ない」という定性的判断のみで結論づけている
- 問題②: フラッシュセール開始直後、5→200req/秒へ1分未満で急増する状況で、min-instances=0からのスケールアウトが起動時間に追いつかず、リクエストのキューイング・タイムアウトが発生するリスクを見落としている
- 問題③: コールドスタートによるレイテンシ悪化がCVR（延いては売上）に与える影響を金額換算していない → 実測CVR差(4.2% vs 2.8%)から失注件数・機会損失額を算出する
- 問題④: 「全時間帯min-instances=0」という一律の設定変更のみを検討し、平常時とフラッシュセール時を分けたスケジュール制御（時間帯別min-instances）という選択肢を検討していない
- 問題⑤: 「約9,800円/月」という削減額の算出根拠（CPU/メモリの常時割り当て課金の内訳）が示されておらず、検算されていない → 月間秒数×vCPU単価+メモリ単価で検算する
- 問題⑥: concurrency設定（40req/インスタンス）から、フラッシュセールのピーク時に必要なインスタンス数・起動シーケンスを逆算していない → ピーク200req/秒÷40req/インスタンス=5インスタンス
- 問題⑦: 削減額（コスト側）とコールドスタートによる機会損失（リスク側）を比較（ROI／期待値）せず、削減額の小ささのみを根拠に「無駄」と結論づけている
ヒント3 — 誘導
【現状の待機コスト再検証】
月間秒数 = 30日 × 86,400秒 = 2,592,000秒
CPU費 = 2,592,000秒 × 1vCPU × $0.000024
メモリ費 = 2,592,000秒 × 0.5GiB × $0.0000025
【コールドスタートによる機会損失】
CVR差 = 4.2%（現状） − 2.8%（min-instances=0実測） = 1.4pt
失注件数/回 = セッション数12,000 × CVR差1.4%
機会損失額/回 = 失注件数 × 客単価6,500円
月次換算 = 機会損失額/回 × 月4回開催
【Good案: 時間帯別スケジューリングのコスト】
必要インスタンス数 = ピーク200req/秒 ÷ concurrency 40req/インスタンス
昇格ウィンドウ（セール前30分＋セール中2時間＋セール後30分）のみ
min-instances を必要数に引き上げ、それ以外はmin-instances=0問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | コールドスタートを数値化せず定性判断のみ | 試算欠如 | 実測コールドスタート時間(1.8秒)を明示する |
| 2 | 急激なトラフィック増加へのスケールアウト遅延リスク見落とし | 運用リスク | 必要インスタンス数と起動時間の重なりを試算 |
| 3 | CVR低下を金額換算していない | 試算欠如 | CVR差×セッション数×客単価で機会損失額を算出 |
| 4 | 時間帯別スケジューリングという選択肢を未検討 | 設計不足 | Cloud Scheduler+Admin APIで動的制御 |
| 5 | 削減額の算出根拠が示されていない | コスト比較 | CPU/メモリ課金を月間秒数から検算 |
| 6 | 必要インスタンス数を逆算していない | 容量計画 | ピークトラフィック÷concurrencyで算出 |
| 7 | 削減額とリスクをROI比較せず結論 | 意思決定プロセス | コスト側とリスク側を同一通貨で比較 |
コストとリスクの非対称性 — 全時間帯min-instances=0 vs 時間帯別スケジューリング
模範解答
修正⑤: 現状の待機コスト再検証
| 項目 | 計算式 | 値 |
|---|---|---|
| 月間秒数 | 30日 × 86,400秒 | 2,592,000秒 |
| CPU費 | 2,592,000秒 × 1vCPU × $0.000024 | $62.208 |
| メモリ費 | 2,592,000秒 × 0.5GiB × $0.0000025 | $3.24 |
| 合計（月額） | - | $65.448 ≒ 9,817円 |
Bad メモの「約9,800円/月」は計算自体はほぼ一致している。問題は削減額の正確性ではなく、削減によって発生するリスク側を一切試算していない点にある。
修正③: コールドスタートによるCVR低下の金額換算
| 項目 | 値 |
|---|---|
| セール実測CVR（min-instances=1、コールドスタートなし） | 4.2% |
| min-instances=0運用時の実測CVR（別サービス） | 2.8% |
| CVR差 | 1.4pt |
| 失注件数/回 | 12,000 × 1.4% = 168件 |
| 平均客単価 | 6,500円 |
| 機会損失額/回 | 168件 × 6,500円 = 1,092,000円 |
| 開催頻度 | 月4回 |
| 機会損失額/月 | 1,092,000円 × 4 = 4,368,000円 |
削減額9,817円/月 に対し、リスク側は4,368,000円/月 — 約445倍の非対称。Bad案は「安く見える削減額」のみを見て、比較にならないほど大きいリスクを見落としている。必要インスタンス数の逆算（参考）: ピーク200req/秒 ÷ concurrency 40req/インスタンス = 5インスタンス。
修正④⑥⑦: 時間帯別min-instancesスケジューリング設計とROI
| 時間帯 | min-instances | 理由 |
|---|---|---|
| 通常時（平常時5req/秒） | 0 | 定常的なトラフィックがあり、コールドスタートの影響は限定的 |
| セール前30分〜セール中2時間〜セール後30分（計3時間/回） | 5 | ピーク200req/秒を必要インスタンス数と同数で暖機し、コールドスタートを完全回避 |
| 項目 | 計算式 | 値 |
|---|---|---|
| 昇格ウィンドウ時間 | 3時間 × 月4回 | 12時間 = 43,200秒 |
| CPU費 | 43,200秒 × 5vCPU × $0.000024 | $5.184 |
| メモリ費 | 43,200秒 × 5 × 0.5GiB × $0.0000025 | $0.27 |
| 合計（月額） | - | $5.454 ≒ 818円 |
- 実装工数（Cloud Scheduler + Admin API連携、監視設定）: 2人日 × 4万円/人日 = 8万円
- 月次直接削減効果: 9,817円 − 818円 = 8,999円/月
- 直接効果のみのペイバック期間: 80,000円 ÷ 8,999円/月 ≒ 8.9ヶ月（地味）
直接削減効果だけ見るとペイバック9ヶ月弱とやや地味だが、本当の価値は「Bad案をそのまま実行し、フラッシュセール中にコールドスタートが直撃して月換算437万円の売上を取り逃す」という最悪シナリオを未然に防いだ点にある。8万円の投資でこの規模のリスクを排除できる時点で、実質的なペイバックはフラッシュセール1回未満と言える。
現状・Bad案・Good案の3案比較
| 案 | 待機コスト/月 | 機会損失/月 | 実質コスト/月 | 判定 |
|---|---|---|---|---|
| 現状（min-instances=1固定） | 9,817円 | 0円 | 9,817円 | コストは最大だがリスクなし |
| Bad案（全時間帯min-instances=0） | 0円 | 4,368,000円 | 4,368,000円 | 表面上最安だが実質最悪 |
| Good案（時間帯別スケジューリング） | 818円 | 0円 | 818円 | 最適 |
インフラ定例への推奨文
全時間帯 min-instances=0 への変更（Bad案）は、待機コスト
9,817円/月の削減という表面上のメリットのみを見た提案です。
しかし banner-api はフラッシュセール開始時に5→200req/秒へ
1分未満で急増する特性があり、コールドスタート（起動平均
1.8秒/インスタンス）が発生した場合、実測でCVRが4.2%→2.8%
まで悪化することが別サービスの運用実績から分かっています。
これを金額換算すると、フラッシュセール1回あたり約109万円、
月4回開催で月間約437万円の機会損失リスクがあり、削減額
9,817円/月とは比較にならない規模です。
代わりに、Cloud SchedulerとCloud Run Admin APIを使い、通常時
は min-instances=0、フラッシュセール前後3時間のみ
min-instances=5 に自動昇格させる時間帯別スケジューリングを
提案します。実装工数8万円に対し、待機コストを91.7%削減
（9,817円→818円/月）しつつ、コールドスタートによる売上
リスクも完全に排除できます。ポイント解説
1「オートスケールするので大丈夫」は定性的な安心感であり、コールドスタート時間という物理的な制約を数値化しない限り判断材料にならない — Cloud Runのオートスケールは瞬時ではなく、新規コンテナの起動時間（今回は1.8秒/インスタンス）というレイテンシを必ず伴う。
2待機コストの削減額とレイテンシ悪化によるビジネスインパクトは、必ず同じ通貨単位（円）に揃えて比較する — 「削減額が小さいから無駄」という判断は、比較対象であるリスク側を金額換算して初めて妥当性を検証できる。
3トラフィックの性質（平常時 vs スパイク時）が異なる場合、単一の設定で一律に扱わず、時間帯別・条件別に制御を分ける — Cloud SchedulerとAdmin APIを組み合わせれば、min-instancesのような設定値も動的にスケジュール制御できる。
4concurrency設定から必要インスタンス数を逆算する習慣を持つ — 「オートスケールするはず」という曖昧な期待ではなく、ピーク時トラフィック÷concurrencyで必要インスタンス数を具体的に算出し、起動シーケンスのボトルネックを事前に特定する。
5ROIは直接的なコスト削減額だけでなく、回避できたリスク（機会損失）を含めて評価する — 今回のペイバック8.9ヶ月という数字だけを見ると地味だが、Bad案実行時の月間437万円という損失リスクを踏まえれば、投資判断は自明である。
実務への応用
MOpsチームのようにフラッシュセール・タイムセールなど瞬間的なトラフィックスパイクが発生するサービスでは、「常時稼働コストは無駄」という発想に流れやすい。しかし実務では、コスト削減の対象となる設定（min-instances、オートスケール閾値など）がビジネス上のクリティカルパス（売上に直結するトラフィックパターン）に紐づいているかどうかを必ず確認する必要がある。Cloud SchedulerでAdmin APIを叩いて設定を動的に切り替える仕組みは、Terraformでのコード管理と組み合わせれば「セール前に手動でmin-instancesを上げ忘れる」という属人的な事故も防げる。
証券会社経験との接続: 証拠金（バッファ）を常に厚めに積んでおけば安全だが機会コストが発生し、逆にギリギリまで削れば平常時は効率的でも重要指標発表前などボラティリティが急拡大する局面でロスカット（強制決済）のリスクが跳ね上がる。だからこそ「常に厚く」でも「常に薄く」でもなく、価格急変が予想されるタイミングだけ証拠金水準を引き上げるという判断をする。Cloud Runのmin-instancesを時間帯別に制御する発想は、この「平常時は効率優先、リスクが高まる局面だけバッファを積む」という構造そのものである。
今日のまとめ
Cloud Runのmin-instances設定は「待機コストの無駄」という一面だけで判断せず、トラフィックの急変パターンとコールドスタートがビジネス指標（CVR・売上）に与える影響を金額換算した上で判断する。今回のケースでは、削減額9,817円/月に対しコールドスタートによる機会損失リスクは月間437万円と445倍の非対称があり、削減額の小ささだけを見た判断は致命的だった。時間帯別スケジューリングにより、コスト削減（91.7%減）とリスク排除を両立できる。
次のステップ
- 発展問題: Good案の運用開始から2ヶ月後、マーケティング部門から「フラッシュセールの開催が不定期（SNSでのバズを見て当日決定するケースあり）になり、事前3時間のスケジュール昇格が間に合わないことがある」と報告された。この場合、(1) Cloud Run v2のstartup CPU boost機能で対応するか、(2) 常時min-instances=1〜2程度の低水準ベースラインを維持しつつセール決定時に追加昇格するハイブリッド案にするかを、それぞれの追加コストとコールドスタート緩和効果を比較した上で判断せよ。
- 参考: Cloud Run v2 / min-instances / concurrency / コールドスタート / startup CPU boost / Cloud Scheduler / Cloud Run Admin API / CVR・機会損失試算