シリコンバレーのスタートアップ界隈では、クラウドの請求書を前に頭を抱えるケースが珍しくありません。「AI機能を追加したら、インフラコストが跳ね上がった」「ユーザーが使っていない夜間も課金され続けている」――これらは、MLOpsにおける典型的な「成長痛」です。
特に画像アノテーションや推論処理のような重たいワークロードにおいて、多くの開発現場では最初に「常時起動型のエンドポイント（Online Prediction）」を構築しがちです。APIを叩けば即座に結果が返ってくる、これは開発体験としては素晴らしいものです。しかし、ビジネスの財務健全性という観点では、しばしば「富豪的プログラミング」の罠に陥ります。
一般的に、同期処理から非同期処理への移行は、単なるアーキテクチャの変更ではなく、コスト構造の変革であると考えられています。
今回は、Google Cloudの Pub/Sub と Vertex AI を組み合わせたイベント駆動型アーキテクチャが、なぜ経済的に理にかなっているのか。技術的な実装論ではなく、「お金（コスト）」にフォーカスして、その妥当性を徹底的にシミュレーションしていきます。
これはCFOやプロジェクトマネージャーとインフラコストについて議論する際の、論理的な根拠となるはずです。
なぜ「非同期×サーバーレス」がコスト最適解なのか
まず、前提となる考え方を共有しましょう。クラウドコストの最適化において最大の敵は「アイドルタイム（待機時間）」です。
常時起動エンドポイントの「待機コスト」という無駄
従来のWeb API的な発想で構築された画像処理システムは、一般的に以下のような挙動をとります。
- ユーザーが画像をアップロードする。
- サーバーがリクエストを受け取り、AIモデルに推論を投げる。
- 推論完了まで待ち、結果をレスポンスとして返す。
この同期処理モデルを実現するために、Vertex AIの Online Prediction エンドポイントを24時間365日稼働させたとします。ここで問題になるのが、リソースの固定化です。
例えば、推論用アクセラレータとしてGPU搭載ノードを使用する場合、リクエストが1件も来ない深夜帯であっても、インスタンスが起動している限り時間あたりの課金が発生し続けます。
かつて主流だったNVIDIA T4のような従来型GPUを使用している場合はもちろん、コストパフォーマンスに優れ、現在の推論ワークロードで推奨されるNVIDIA L4などの最新GPUへ移行したとしても、常時起動させていれば「待機コスト」からは逃れられません。これは、スーパーマーケットでお客さんがいない時間帯にも、レジ打ちのスタッフ全員が待機している状態と同じです。リソース効率の観点から見て、非常に非効率であると言わざるを得ません。
Pub/Subによるバッファリングがもたらす経済的メリット
ここで Cloud Pub/Sub の登場です。非同期アーキテクチャでは、ユーザーからのリクエストを一度Pub/Subという「郵便受け」に放り込みます。ユーザーには「受け付けました（HTTP 202 Accepted）」とだけ返し、実際の処理は裏側で行います。
この「バッファリング（一時貯留）」が経済的に巨大なメリットを生みます。
- ピークカット効果: 例えば、特定の1時間に1万枚の画像がアップロードされたケースを想像してください。同期処理なら、その瞬間の最大負荷に耐えるために大量のGPUノードを並列で用意する必要があります。しかし非同期なら、キューに積んでおき、許容可能な時間内で平準化して処理することで、ピーク時のリソース要求を大幅に抑制できます。
- ゼロスケーリング: リクエストがない時間は、処理側のリソース（例えばCloud RunやVertex AIのオートスケール設定）をゼロに落とすことが可能です。Pub/Sub自体はメッセージが来るまで待機コストがかかりません（メッセージ量等に基づく従量課金）。
同期処理 vs 非同期処理のコスト構造比較
簡単な比較イメージを持ってみましょう。
- 同期処理（Online Prediction）: 固定費に近い変動費。リクエストがなくても最低料金（ベースライン）が高止まりしやすい構造です。
- 非同期処理（Batch / Async）: 完全従量課金。使った分だけ支払うモデルに限りなく近づきます。
特に、画像アノテーションやバッチ分析のような「必ずしも1秒以内に結果を返す必要がない（数分〜数時間遅れても許容される）」ワークロードにおいては、SLA（サービスレベル合意）における即時性を少し緩和するだけで、コスト削減効果は劇的です。最新のクラウドアーキテクチャでは、こうした「必要な時だけリソースを立ち上げる」設計が、コスト効率を最大化する鍵となります。
課金ポイントの完全分解：どこにいくらかかるのか
では、具体的にGoogle Cloudのどのサービスにいくらかかるのか、解像度を上げて見ていきましょう。見積もりを作る際、どんぶり勘定は命取りです。
※価格は変動するため、設計時は必ず公式のGoogle Cloud Pricing Calculatorで最新の単価を確認してください。以下は目安としての概算です。
Vertex AI：予測ノード時間とデプロイコスト
Vertex AIの課金体系は、使用するモデルの種類（カスタムモデルか生成AIモデルか）によって異なりますが、従来の画像処理モデル（カスタム学習モデル）をデプロイする場合、基本は「コンピュート時間」です。
1. Online Prediction（常時起動）の場合
- 計算式:
ノード単価 × ノード数 × 稼働時間 - 構成例: 従来から広く使われている
n1-standard-4+NVIDIA T4(1基) の組み合わせなどが代表的です。 - SREの視点: T4は推論用として実績豊富なGPUですが、現在はより新しいL4 GPU（G2インスタンス）が登場しており、処理性能あたりのコストパフォーマンスが向上しているケースがあります。また、基盤となるOS（Container-Optimized OSなど）のサポートライフサイクルも考慮し、レガシーな構成に固執せず最新のインスタンスタイプと比較検討することが重要です。
- 注意点: オートスケーリングを設定しても、コールドスタート（起動遅延）を防ぐために「最小ノード数: 1」に設定することが多く、その場合、夜間や休日でリクエストがゼロでも固定費が発生します。
2. Batch Prediction（バッチ処理）の場合
- 計算式:
ノード単価 × 処理にかかった実時間 - ジョブが起動し、処理が完了したら即座にリソースが破棄されます。待機コストはゼロです。ただし、ジョブの起動オーバーヘッド（数分）があるため、リアルタイム性が求められない一括処理に向いています。
※なお、Geminiなどの生成AIモデルをAPI経由で利用する場合は、上記のようなノード時間課金ではなく、入力/出力トークン数や画像枚数に応じた従量課金となる点が異なります。
Pub/Sub：メッセージ転送量とストレージコスト
Pub/Subは非常に安価ですが、塵も積もれば山となります。
- スループット料金: 一定の無料枠（月間10GBなど）を超過した場合、データ転送量（TiBまたはGB単位）に応じて課金されます。
- メッセージストレージ: 未配信メッセージの保持に対してもストレージ料金が発生します。
画像データそのもの（バイナリ）をPub/Subメッセージに含めるのはアンチパターンです。数MBの画像をメッセージに入れると、あっという間に転送量コストが膨らみます。画像はCloud Storage (GCS) に置き、その「パス（gs://...）」だけをPub/Subに流すのが鉄則です。これならメッセージサイズは1KB以下になり、Pub/Subコストは実質無視できるレベルになります。
周辺リソース：Cloud Storage, Cloud Functions/Run
- Cloud Storage (GCS): 画像の保存料金。Standardクラスなどのストレージクラスに応じたGB単価がかかります。
- Cloud Run / Functions: Pub/Subトリガーで起動し、Vertex AIへリクエストを投げる「接着剤」の役割。ここはリクエスト数と処理時間（ミリ秒単位）の従量課金です。
ネットワーク下り転送量の落とし穴
意外と見落とすのが Network Egress（下り転送） です。
Google Cloud内部（同一リージョン内）でのデータ移動（GCS → Vertex AIなど）は基本的に無料ですが、異なるリージョン間や、処理結果をインターネット経由で外部へ返す場合には課金されます。
計算式: 外部への転送量(GB) × 転送単価
画像処理の場合、入力は大きくても、出力（アノテーションデータ、JSON）は非常に小さいテキストデータであることが多いので、ここはあまり心配しなくて良いケースが大半です。しかし、処理後の画像を加工してダウンロードさせる場合は要注意です。
規模別コストシミュレーション：1万枚 vs 100万枚
ここからが本題です。具体的な数字を入れてシミュレーションしてみましょう。
前提として、1画像あたりの推論処理時間を「0.5秒（GPU使用）」と仮定します。
小規模・散発的ユースケース（1日1,000〜1万枚）
スタートアップやPoC（概念実証）段階の規模感です。リクエストは不定期に来るとします。
パターンA：常時起動（Online Prediction, 最小ノード1）
- 稼働時間: 24時間 × 30日 = 720時間
- コスト: 720時間 × $0.60 = $432 / 月
- 1画像あたりの単価（1万枚の場合）: $0.0432（約6.5円）
パターンB：非同期・バッチ化（Batch Predictionを1日1回起動）
- 処理時間: 1万枚 × 0.5秒 = 5,000秒 ≈ 1.4時間
- 起動オーバーヘッド等含め、余裕を見て 2時間分 のリソース使用と仮定。
- コスト: 2時間 × $0.60 = $1.20 / 月
驚くべき差です。$432 vs $1.2。処理量が少ない場合、常時起動のコストパフォーマンスは壊滅的です。Pub/Subに溜めておき、ある程度溜まったらBatch Predictionをキックする、あるいはCloud Runで都度処理する構成にすることで、コストを1/300以下に圧縮できる可能性があります。
大規模・バッチ的ユースケース（1日100万枚〜）
ビジネスがスケールし、毎日大量の画像が送られてくるフェーズです。
パターンA：常時起動（Online Prediction, オートスケール）
- 必要処理時間: 100万枚 × 0.5秒 = 500,000秒 ≈ 139時間
- これを24時間で処理するには、平均して約6台のノード並列稼働が必要。
- コスト: 139時間 × 30日分...ではなく、単純に総処理時間で計算。
- 月間総処理時間: 100万枚 × 30日 × 0.5秒 = 15,000,000秒 ≈ 4,166時間
- コスト: 4,166時間 × $0.60 = $2,499 / 月
パターンB：非同期・バッチ化（Batch Prediction）
- コスト: 基本的に計算リソースの使用量は同じなので、理論値は $2,499 / 月 に近くなります。
「あれ？ 大規模になると変わらない？」と思いましたか？ ここにSREの視点が必要です。
Vertex AI Batch Prediction vs Online Predictionの分岐点
大規模環境においてBatch Prediction（非同期）が有利な理由は、「スポットインスタンス（Preemptible VM）の利用」が可能になりやすい点です。
バッチ処理であれば、途中でインスタンスが中断されてもリトライすれば良いため、安価なスポットインスタンスを利用するオプションが現実的になります。これを使えば、計算コストをさらに 60〜70%削減 可能です。
つまり、スポット適用後の大規模バッチコストは、
- コスト: $2,499 × 0.3（70%OFF） = 約 $750 / 月
となります。規模が大きくなればなるほど、この「単価の違い」が経営に直結します。
見落としがちな「隠れコスト」とリスク管理
コスト試算表には現れない、しかし現場で頻発する「隠れコスト」についても触れておかなければなりません。ここでの失敗が、せっかくの節約分を吹き飛ばすことがあります。システム全体の信頼性を担うSREの視点から、リスクを最小化するためのポイントを解説します。
エラーリトライによる「無限課金ループ」の防止策
Pub/SubとCloud Functions/Runを連携させる際、最も恐ろしいのが「毒入りメッセージ（Poison Pill）」です。
処理できない不正な画像データがキューに入ってきたと想定してください。ワーカーが処理を試み、エラーで落ちる。Pub/Subは「処理失敗」と判断し、再度メッセージを送る。これが無限に繰り返されます。
これはクラウド破産の典型例です。エラーで落ちている間も、コンピュートリソースは消費され、ログ出力料金（Cloud Logging）も爆発的に増加します。
対策: Pub/Subの「最大配信試行回数」を必ず設定してください（例: 5回）。これにより、無限ループを物理的に遮断します。
デッドレターキュー（DLQ）のストレージコスト
配信試行回数を超えたメッセージは、デッドレターキュー（DLQ） という別のトピックに移動させます。これにより無限ループは止まりますが、DLQに溜まったメッセージを放置すれば、ストレージコストがじわじわとかかります。
「DLQにメッセージが入ったらSlackに通知し、7日後には自動削除する」といったライフサイクル管理ポリシーを設定し、ゴミデータが溜まり続けない仕組みを構築しましょう。
開発・検証環境の維持費と削除忘れリスク
非同期アーキテクチャは構成要素が多くなります（Pub/Sub, GCS, Cloud Run, Vertex AIなど）。これらを手動で管理していると、検証環境の削除忘れによる無駄なコストが発生しがちです。
TerraformなどのIaC（Infrastructure as Code）ツールを活用し、環境構築をコード化することは、SREの観点からも必須と言えます。terraform destroy コマンド一つでリソースを確実に破棄できる状態を維持することが、最も確実なコスト削減策です。
また、Terraformの最新バージョンでは機密情報の取り扱い機能も強化されています。バージョン管理には tfenv などのツールを使用し、チーム全体で実行環境を統一することも、予期せぬデプロイエラーや設定ミスを防ぐための重要なポイントです。
総所有コスト（TCO）視点での判断基準
最後に、技術的なコストだけでなく、人的コストを含めたTCO（Total Cost of Ownership）で判断しましょう。
SaaS型アノテーションツール vs 自社構築パイプライン
世の中には、画像を送ればAIがアノテーションして返してくれるSaaSも存在します。1枚あたり10円〜数10円程度でしょうか。
- 自社構築（Pub/Sub + Vertex AI）: 1枚あたり数円〜0.数円まで下げられる可能性がありますが、初期構築と運用保守にエンジニア工数がかかります。
- SaaS利用: 1枚あたりの単価は高いですが、開発・運用工数はゼロ。
運用保守（エンジニア工数）を含めた最終的な損益分岐点
もしチームのエンジニア時給が5,000円で、このパイプラインの維持管理に月10時間かかると仮定したら、月額5万円の「運用人件費」が乗っかります。
- 月間処理数 1,000枚: SaaSの方が安いでしょう。
- 月間処理数 10万枚: 自社構築によるコスト削減額（クラウド利用料の安さ）が、運用人件費を大幅に上回り、黒字化します。
このアーキテクチャを採用すべき企業、すべきでない企業
採用すべき:
- 月間の画像処理数が数万枚を超える、または今後急増する見込みがある。
- 社内にGoogle Cloudに詳しいエンジニア（SRE）がいる。
- 処理のリアルタイム性よりも、コスト効率を重視する。
採用すべきでない:
- PoC段階で、来月サービスが続いているか分からない。
- インフラ専任者がおらず、アプリケーションエンジニアが手一杯。
- 超低遅延（ミリ秒単位）のレスポンスがビジネスのコア価値である。
まとめ：コストは「設計」で決まる
非同期アーキテクチャへの移行は、単なる技術的なトレンド追従ではありません。それは、ビジネスの収益性を高めるための「財務戦略」そのものです。
- 待機コストをゼロにする: Pub/Subでバッファリングし、必要な時だけリソースを使う。
- 規模に応じた使い分け: 小規模ならCloud Run、大規模ならBatch Prediction + スポットインスタンス。
- リスク管理: 無限リトライと削除忘れを防ぐガードレールを設置する。
これらを実践することで、クラウド破産の恐怖から解放され、健全なスケーラビリティを手に入れることができます。
コメント