月間1000万推論のリアルタイムAPIを捨て、Vertex AIバッチ予測でコスト65%減と安眠を手に入れた話

AI機能を本番環境にデプロイした直後、予想を遥かに超えるインフラコストに直面し、クラウドの請求書を見て血の気が引く。実務の現場では、こうした事態が業界内で決して珍しくありません。その原因の多くは、リアルタイム推論APIの過剰な利用にあります。

UI/UXデザインの観点から「ユーザー体験のためには即時レスポンスが必須だ」という固定観念に縛られ、高価なGPUインスタンスを常時稼働させてしまうプロジェクトは多数存在します。しかし、データ分析を通じて実際のトラフィックを客観的に評価すると、夜間はリソースが余り、日中のピーク時だけ処理能力が不足してエラーが発生するという、極めて非効率な状態に陥っていることがよくあります。

経営層の視点から見ると、このようなインフラコストの肥大化は、スタートアップの資金繰りやAIサービスの継続性を脅かす重大なリスクです。また、不要な計算リソースの浪費は、環境負荷の観点からもAI倫理に反する課題と言えます。

この問題を解決し、技術的な実現可能性とビジネス上の成果を両立させるためには、抜本的なアーキテクチャの刷新が不可欠です。すべての処理にリアルタイム性を求めるのではなく、最新のマネージドサービスと非同期処理を適切に組み合わせることが、現実的な解決策となります。

たとえば、Google Cloudの最新のVertex AI環境では、Cloud SQL for MySQLとの直接統合が一般提供されており、データベースから直接モデルを呼び出してオンライン予測やベクトル埋め込みを生成できるようになりました。さらに、最新のGeminiモデルの高度な推論能力を活用し、バッチ処理や非同期パイプラインとシームレスに連携させることで、不要な常時稼働リソースを削減しつつ、高いパフォーマンスを維持することが可能です。

こうしたアーキテクチャの最適化により、インフラコストの大幅な削減が期待できます。また、マネージドサービスの活用によってエラー時の自動リカバリが容易になり、インフラ運用担当者の深夜の対応負荷を軽減することにも直結します。

この記事では、システム受託開発などの現場で陥りがちな「初期アーキテクチャの失敗パターン」から、最新のVertex AIを活用した「安定稼働するパイプライン」の構築に至るまでの、実践的なアプローチを提示します。理想論だけではなく、現場で直面しやすい落とし穴とその回避策に焦点を当てています。

自社プロダクトやクライアントワークの開発現場で戦うプロジェクトマネージャーやエンジニアの皆さんが、コストとパフォーマンスの最適化を実現するための実践ガイドとして活用していただければ幸いです。

プロジェクト背景：なぜリアルタイムAPIを捨て、バッチ予測を選んだのか

多くのAI導入プロジェクトにおいて、初期段階で直面しがちなのが「過剰な即時性」へのこだわりです。特に昨今では、Geminiなどの高度な推論モデルを活用し、長文のPDFドキュメントや画像を含むマルチモーダルデータを解析するケースが増加しています。こうした高度な機能開発において、「ユーザーはデータをアップロードしたら、すぐに結果を見たいはずだ」という仮説のもと、常時稼働のエンドポイント（Vertex AI Online Predictionなど）を選択するケースが後を絶ちません。

月額コストが予測を超過するメカニズム

サービス利用が拡大し、月間の推論回数が数百万から1000万件規模に達した段階で、コスト構造の問題が明確に顕在化します。経営戦略の観点からは、ここで発生する構造的な課題を正確に把握することが求められます。
従来型の構成としてよく見られるNVIDIA T4（Google Cloud N1シリーズ等）や、現在主流となりつつあるL4（G2シリーズ）を用いたGPUインスタンスをオートスケーリング設定で稼働させた場合、あるいは最新のLLMのAPIをリアルタイムで大量に呼び出した場合、以下のような事態が発生します。

• アイドルタイムの無駄: B2Bサービスでは夜間や休日の利用が激減します。しかし、コールドスタートを避けるために最小構成台数を維持すれば、リクエストがない時間帯も課金され続ける「空費」が発生します。
• スパイクへの追従遅れ: 月曜日の朝など、利用が集中するタイミングでオートスケーリングが間に合わず、タイムアウトエラーが多発します。これを防ぐための余剰リソース確保は、さらなるコスト増を招く悪循環となります。

さらに、Geminiのようなモデルで長文コンテキストを処理する場合、リアルタイム推論の単価がビジネスモデルの許容範囲を大きく超えてしまうリスクが伴います。「AIを使えば使うほど赤字になる」という状況は、スケーリングを目指すスタートアップや新規事業にとって致命的なボトルネックです。

「即時性」は本当に必要だったのか？要件の再定義

ここで重要なのが、コスト削減のためにモデルの量子化やインスタンスタイプの変更といった技術的なチューニングに走る前に、プロジェクトマネージャーの視点で一度立ち止まり、「ビジネス要件」を根本から疑ってみることです。

データ分析の手法を用いてユーザーの利用実態を客観的に把握したり、ヒアリングを行ったりすると、意外な事実が浮かび上がることは珍しくありません。

「大量のPDFをアップロードして、その日は帰ることも多い。翌朝までに詳細な分析が終わっていれば十分だ」
「レポート作成の基礎データとして使いたいから、数時間後でも処理完了の通知が来れば問題ない」

開発チームが必死に守ろうとしている「数秒以内のレスポンス」というSLA（サービスレベル合意）が、実はエンジニア側の思い込みに過ぎないケースは多々あります。ビジネスの真の目的は「速さ」ではなく「確実で質の高いアウトプット」である場合が多いのです。

こうした気づきを得た場合、以下のような大胆な方針転換が極めて有効な解決策となります。

1. リアルタイムAPIの廃止: 即時性が不要な処理はすべて非同期化する。
2. バッチ予測への移行: Vertex AIのバッチ予測（Batch Prediction）を活用し、システムリソースを効率的に使いながらまとめて処理することで、スループットを高め、推論単価を劇的に下げる。
3. SLAの再設定: 「即時」から「アップロード完了後、X時間以内」へ変更し、ユーザーの期待値を適切にコントロールする。

これが、コスト効率の高い持続可能な運用体制へ移行し、経営の安定と開発チームの負担を軽減するための第一歩となります。

アーキテクチャ変遷：失敗した「V1」と安定した「V2」の比較

バッチ予測への移行という方針が決まっても、実装が一筋縄でいくとは限りません。多くのAIプロジェクトにおいて、初期に構築されがちな単純な「V1」アーキテクチャは、データ量が増加すると運用開始からわずか数週間で破綻するケースが珍しくありません。

V1：単純なcron実行が招いた「ジョブ詰まり」

システム受託開発の現場でもよく見られる初期の実装パターンは、非常にシンプルな構造で設計されます。

• トリガー: Cloud Schedulerで1時間に1回スクリプトを実行。
• 処理: 未処理のデータをデータベースから取得し、Vertex AIのバッチジョブを投入。
• 監視: 特になし（ジョブが失敗したらログを見る程度）。

この構成は、データ量が少ないうちは機能します。しかし、突発的に10万件規模のデータが投入されるような状況が発生すると、システムは容易に崩壊の危機に直面します。

1. ジョブ投入の失敗: Vertex AIには、同時に実行できるジョブ数やAPIコール数に制限（クォータ）が設けられています。大量のデータに対してスクリプトがループでジョブ投入リクエストを投げ続けた結果、429 Resource Exhausted エラーが多発します。
2. 状態の不整合: エラーハンドリングが不十分な場合、実際にはジョブが投入されていないにもかかわらず、データベース上は「処理中」のままスタックするレコードが大量に発生してしまいます。
3. リカバリの困難さ: 次のcron実行時にも「処理中」のステータスを持つデータは無視されるため、永遠に処理されないデータが蓄積されていきます。その結果、手動でデータベースを修正する「運用対応」という名の過酷な作業が常態化しがちです。

「夜中にアラートが鳴り止まない」「エンジニアが手動でSQLを実行してステータスを元に戻す」。このような状況は、プロジェクトマネージャーの視点から見るとチームの疲弊を招き、本来目指すべきスケーラブルなシステム運用とは言えません。

V2：Cloud WorkflowsとPub/Subによるイベント駆動型へ

こうした典型的な失敗パターンから学べる教訓は、主に2つあります。

1. ポーリング（定期実行）からの脱却: データが到着したタイミングで処理を開始する、イベント駆動型のアーキテクチャを採用する。
2. 状態管理の疎結合化: ジョブの投入、監視、完了通知のプロセスを分離し、各工程を独立したワークフローとして管理する。

これらの教訓を踏まえた解決策として推奨されるのが、Cloud Workflows と Cloud Pub/Sub を中心に据えた「V2」と呼べるアーキテクチャの構築です。

• 入力: システムにデータがアップロードされると、GCS（Google Cloud Storage）にファイルが保存され、同時にPub/Subへイベント通知が送信されます。
• オーケストレーション: Pub/Subのトリガーによって Cloud Workflows が起動します。このワークフローがシステム全体の「司令塔」として機能し、以下のステップを正確に制御します。
  1. 入力データの厳密なバリデーション。
  2. Vertex AIのバッチ予測ジョブの作成（APIリミットを考慮した指数バックオフ付き）。
  3. ジョブ完了の待機（Callbackによる非同期通知待ち）。
  4. 処理結果のデータベース格納と後続プロセスへの通知。

最近では、Cloud SQL for MySQLとVertex AIの統合が一般提供され、データベースから直接モデルを呼び出すアプローチも可能になりました。しかし、Geminiなどの最新の大規模言語モデルを活用して月間数百万件以上の推論を行う場合、コスト最適化とシステム安定性の両立という観点からは、依然としてGCSを経由する非同期のバッチパイプラインが強力な選択肢となります。

この構成を採用することで得られる最大の利点は、高度な「流量制御（スロットリング）」が実現できる点にあります。Cloud Workflows側で同時実行数を制御したり、APIエラー発生時に指数バックオフ（Exponential Backoff）を用いてリトライを実行したりといった複雑なロジックを、アプリケーションのコード内ではなくインフラ層で明確に定義できます。

これにより、突発的に10万件規模のデータが押し寄せてもシステムがパンクすることなく、設定された制限の中で淡々と順次処理をこなしていく「粘り強い」データパイプラインを構築することが可能になります。

実装の壁と克服策：Vertex AIバッチ予測特有のクセ

アーキテクチャの設計が完了しても、実際のVertex AI Batch Prediction APIの運用では、公式ドキュメントには明記されていない特有の挙動に直面することが珍しくありません。ここでは、実装フェーズで壁となりやすいポイントと、その実践的な回避策を解説します。

「インスタンス起動待ち」をどう扱うか

リアルタイムAPIと違い、バッチ予測はジョブを投入してから実際に推論が始まるまでに時間がかかります。裏側でリソースのプロビジョニングが行われるためです。

• 問題: ジョブ投入後、ステータスが JOB_STATE_RUNNING になるまで数分〜十数分かかることがあります。短いジョブを大量に投げると、この起動オーバーヘッドだけで全体の処理時間が間延びしてしまいます。
• 対策: データのバッチング（塊化）を徹底することが重要です。1件ごとの推論ではなく、最低でも1000件〜1万件程度のデータを1つのJSONLファイルにまとめ、1つのバッチジョブとして投入します。これにより、起動時間のオーバーヘッドを償却し、スループットを最大化できます。さらに、最新のGeminiモデル等で提供されているContext caching（コンテキストキャッシュ）機能を併用し、共通プロンプトや大容量のコンテキストの処理効率をさらに高める構成も、コスト削減の観点から検討の余地があります。

大量データ投入時のクォータ制限と「429エラー」対策

Google Cloudにはプロジェクトごとに厳格なクォータ（割り当て）が設定されています。特に注意すべきは「同時実行ジョブ数」と「APIリクエストレート」です。

• 問題: 複数のトリガーから同時に大量データの処理要求が発生すると、Vertex AIへのジョブ作成リクエスト（projects.locations.batchPredictionJobs.create）がクォータに抵触し、429エラーで弾かれるケースが報告されています。
• 対策: Cloud Workflowsなどのオーケストレーションツール内に「トークンバケット」的な制御ロジックを組み込むアプローチが有効です。具体的には、Firestoreなどを状態管理のカウンタとして使い、現在実行中のジョブ数を把握します。上限（例: 50ジョブ）に達している場合は、新規ジョブの投入を待機（sleep）させてリトライループに入れることで、APIリミットを安全に回避し、安定した処理基盤を構築できます。

JSONL形式データの分割と結合のベストプラクティス

Vertex AIのバッチ予測は、入力データとしてGCS上のJSONL（JSON Lines）ファイルを指定します。ここにも運用上の落とし穴が存在します。

• 問題: 巨大な1つのJSONLファイル（例: 10GB）を渡すと、処理の一部が失敗した際に、どこまで進んだかの追跡が難しく、再実行のコストも跳ね上がります。また、出力結果のパース時にフォーマット崩れによるエラーが起きるリスクもあります。
• 対策: 入力ファイルを適切なサイズ（例: 500MBごと、または1万行ごと）に分割（Sharding）してGCSに配置し、ワイルドカード指定（gs://bucket/data/*.jsonl）でジョブに渡す方式が推奨されます。Vertex AIは内部的にこれを並列処理するため、効率的です。出力も分割されて生成されるため、後処理の並列化も容易になります。また、最新のGeminiモデルでサポートされているStructured outputs（構造化出力）機能を活用し、JSONLの各行が厳密なスキーマに従うよう強制することで、後続のデータパイプラインにおけるパースエラーを劇的に減らすことが可能です。

運用フェーズ：エラー検知と自動リカバリの仕組み

バッチ処理において最も警戒すべきは「サイレントキラー（静かなる失敗）」です。翌朝になって「完了しているはずの処理が止まっていた」という事態を防ぐためには、堅牢な監視とリカバリ体制の構築が不可欠です。

「推論失敗」を即座に検知する監視ダッシュボード

Cloud Monitoringなどの監視ツールを活用し、以下のような指標を可視化することが推奨されます。なお、具体的なメトリクス名はプラットフォームのアップデートにより変更される可能性があるため、必ず公式ドキュメントで最新情報を確認してください。

1. ジョブ失敗率: 全体のジョブ数に対するエラー発生数の割合。
2. 推論レイテンシ: ジョブ投入から完了までの経過時間。
3. スタックジョブ数: ステータスが長時間更新されないジョブの数。

特に3つ目が重要です。クラウド側の障害などでジョブが「実行中」のまま数時間停止するケースは稀に発生します。これを検知するため、「投入から一定時間経過しても完了しないジョブ」を抽出するアラートを設定し、Slackなどのチャットツールへ即座に通知する仕組みを整えるべきです。

部分的な失敗（Partial Failure）への対応フロー

バッチ予測では、入力データ1万件のうち、数件だけがデータ不備などで失敗する「部分失敗」が頻発します。Vertex AIなどのプラットフォームでは、ジョブ全体としては「成功（SUCCEEDED）」と判定されても、出力ディレクトリにエラー詳細ファイル（例: error.jsonl）が生成される場合があります。

成熟したパイプラインでは、以下のフローを自動化することがベストプラクティスです。

1. ジョブ完了後、Cloud Functionsなどのイベント駆動型コンピューティングをトリガーする。
2. 出力ディレクトリ内にエラーファイルが存在するかチェックする。
3. 存在する場合、その内容を解析。再試行可能なエラー（例: 一時的な内部エラー）であれば、失敗したデータのみを抽出して再処理用の「リカバリジョブ」を自動投入する。
4. データ起因のエラー（例: 画像フォーマット不正）であれば、そのレコードのステータスを「失敗」として記録し、必要に応じて担当者に通知する。

さらに最近では、Geminiなどの最新モデルがサポートするStructured outputs（構造化出力）を活用することで、データ起因のエラーを劇的に減らすアプローチが注目されています。JSONスキーマなどを厳密に指定して推論を実行させることで、後続のパース処理でのエラーを未然に防ぎ、部分的な失敗そのものの発生率を引き下げることが可能です。この「失敗した分だけやり直す」仕組みと「そもそも失敗させない」プロンプト設計を組み合わせることで、運用担当者が手動でログを調査する工数を大幅に削減できます。

運用工数をゼロに近づける完全自動化への道

理想的な運用設計において、チームが介入するのは「クラウドベンダーの大規模障害」など、システム側で制御不能な事象が発生した場合のみに限定すべきです。

日常的なエラー（APIリミット、一時的なネットワークエラー、不正データ）はすべてプログラムが自動で判断し、リトライするか通知するかを決定します。

さらに、AI倫理やLLMOps（Large Language Model Operations）の観点からは、単なるシステムエラーだけでなく、生成内容の品質（ハルシネーションや不適切な回答）を監視し、社会的な責任を果たすことも重要視されています。Geminiのような最新モデルは推論能力が飛躍的に向上し、長文処理やマルチモーダル対応も強化されていますが、だからこそ出力品質の自動評価パイプラインを組み込む意義は大きくなっています。

また、大量のドキュメントを処理するバッチ予測においては、Context caching（コンテキストキャッシング）などの機能を活用することで、コストと処理時間をさらに最適化できる可能性があります。MLOps/LLMOpsにおいて「人手を介さない運用」を追求することは、コスト削減以上に、チームが創造的なタスクに集中するために極めて重要な要素です。最新の運用ツールやモデルの機能拡張については、各クラウドベンダーの公式ドキュメントを継続的に確認することをお勧めします。

成果とROI：コスト65%削減の裏側と副作用

V2パイプラインのようなイベント駆動型のアーキテクチャを導入した場合、経営戦略上、その効果は非常に大きくなります。

インフラコストの劇的な改善内訳

一般的な移行前後の月額コストの比較例として、以下のような傾向が見られます。

• 移行前（リアルタイムAPI）: GPUインスタンスの常時稼働費が支配的。アイドルタイムの無駄が大きく、月額コストが膨らみやすい。
• 移行後（バッチ予測）: 実際に推論が走った時間分だけの課金。さらに、非同期なので安価なリージョンやマシンタイプを柔軟に選択可能。

結果として、推論にかかるコンピュートコストが約65%削減されるケースもあります。浮いた予算は、より高精度なモデルの研究開発や、マーケティング支援のための新たな学習データの作成に回すことが可能になり、ROIの最大化に貢献します。

スループット向上によるビジネスメリット

コストだけでなく、処理能力（スループット）の向上も期待できます。従来は1時間に数千件が限界だった処理も、バッチ化により並列数をコントロールしやすくなり、1時間に数百万件の処理も安定してこなせるようになります。

これにより、エンタープライズ顧客からの「過去数年分のデータを一気に分析したい」という大規模案件にも対応しやすくなります。インフラがビジネスのボトルネックから、イネーブラー（実現させるもの）へと変わる重要なポイントです。

バッチ化によって失ったものと、その補完策

もちろん、良いことばかりではありません。「即時性」を捨てたことによる副作用も考慮する必要があります。

一部のユーザーから「アップロードしたのにすぐ結果が出ない」という声が上がることも想定されます。これに対しては、UI/UXデザイン改善の専門知識を活かしたケアを徹底することが重要です。

• 進捗バーの表示: 「現在処理中です（残り約X分）」という予測時間を表示。
• 完了通知: 処理が終わったらメールやSlack、ブラウザ通知を送る。
• プレビュー機能: 最初の数件だけは優先的に処理し、即座に結果を見せることで「動いている安心感」を提供する。

技術的な制約をUXでカバーすることで、顧客満足度を落とさずにバッチ化への理解を得ることが可能になります。

エンジニアへの提言：これからパイプラインを組むあなたへ

最後に、これから大規模な推論パイプラインの構築を検討されているエンジニアの方々へ、設計のポイントを整理します。

「マネージドだから楽」ではない、設計の勘所

Vertex AIのようなマネージドサービスは強力ですが、「リクエストを投げれば勝手に処理が完了する」と過信すると、クォータ制限や隠れた仕様に直面するケースは珍しくありません。

プロジェクトマネージャーとして現場を俯瞰すると、「エラーは例外ではなく、日常である」という前提での設計が不可欠だと痛感します。ネットワークの瞬断、APIの503エラー、入力データの欠損など、異常系（リトライ、バックオフ、デッドレターキュー）を正常系と同等の熱量で作り込むことが、結果的に安定稼働への最短ルートとなります。

さらに最新の環境では、Cloud SQL for MySQLとVertex AIの統合が一般提供され、データベースから直接モデルによる予測やベクトル埋め込みの生成が可能になりました。これによりデータ抽出・加工のパイプラインは大幅に簡略化されますが、その分、データベース側の負荷コントロールやトランザクションと連携したエラーハンドリングの重要性がより一層高まっています。

PoC段階で確認しておくべき3つのチェックリスト

本格的な設計を始める前に、以下の3点を検証しておくことを推奨します。

1. クォータの上限とスロットル確認: プロジェクトのデフォルト上限値は想定より低く設定されている場合があります。特に最新のGeminiモデルでContext caching（コンテキストキャッシュ）やマルチモーダル処理を多用する場合、APIの消費リソースが跳ね上がるため、早めの上限緩和申請が必要か確認すべきです。
2. コールドスタートとバッチサイズの影響: 1ジョブあたりの起動オーバーヘッドは許容範囲に収まるでしょうか。小さすぎるバッチは非効率であり、逆に大きすぎると再実行時の時間的コストが膨らむため、最適な分割サイズの検証が求められます。
3. 部分失敗の挙動とログの追跡性: 100件中1件が失敗した際、エラーログはどのように出力されるでしょうか。後続の処理でパースしやすい形式か、どのデータが失敗したかを即座に特定できるトレーサビリティを確保しておくことが重要です。

まとめ

リアルタイムAPIからVertex AIバッチ予測への移行は、単なるインフラの最適化やコスト削減にとどまらず、経営層の視点から「ビジネス価値の本質（本当に必要なのはミリ秒単位の速度か、それとも安定した品質と大量処理か）」を見つめ直す重要なプロセスとなります。

初期の設計フェーズにおける泥臭いエラーハンドリングの徹底と、堅牢なアーキテクチャの構築こそが、将来的にスケールするスタートアップの基盤をもたらします。

AI技術は急速に進化しており、Google Cloudの公式ドキュメントでもGeminiモデルの推論能力向上や、外部データで補強するGrounding（グラウンディング）機能の拡充が継続的に発表されています。高機能なAPIが次々と登場する一方で、それを本番環境で支えるのは地道なエンジニアリングと、ビジネス要件に対する深い理解に他なりません。

この記事で整理したパイプライン構築の視点が、堅牢でコスト効率の高いAIシステム設計の一助となれば幸いです。最新の機能仕様や詳細な料金体系については、導入前に必ず公式ドキュメントで確認し、自社の要件に合わせた最適な構成を選択してください。