Google Cloudは、Vertex AI RAG EngineのManaged Databaseで使用するGoogle管理のSpannerインスタンスについて、標準Spanner SKUに基づく課金を導入した。

RAGの費用をモデル推論、Embedding、Object Storageだけで見積もっていた組織では、継続的なデータベース費用が加わる。PoCで問い合わせが少なくても、管理基盤の費用が残る可能性があるため、固定費と変動費を分けて評価する必要がある。

何が変わったか

RAG EngineのManaged Databaseは、利用者がSpannerを直接構築・管理せずに使える管理型構成である。課金導入後は、Google管理インスタンスに関連する標準Spanner SKUが請求へ現れる。

具体的な金額はRegion、構成、使用量、Google Cloudの最新料金で確認する。記事では単価を固定記載せず、費用構造と運用対応を扱う。

変更前後の差

項目課金導入前の見積り導入後の見積り
モデル推論必要必要
Embedding必要必要
Data Storage必要必要
Managed Spanner見落としやすい標準SKUで考慮
低トラフィックPoC変動費中心固定的費用が目立つ可能性
配賦API利用量中心Project・Corpus・DB費用も必要

Managedという語は無料を意味しない。運用作業をGoogleへ委ねる代わりに、基盤リソース料金を負担する。

誰に影響するか

  • Managed DatabaseでRAG Corpusを作成している
  • PoCを多数のProjectへ分散している
  • テナントごとにCorpusやProjectを分離している
  • Query量が少ないが長期間データを保持する
  • 費用をユーザーリクエスト数だけで配賦している
  • Budget AlertにモデルSKUしか含めていない
  • 開発・検証環境を常時残している
  • RAG Engineと自前Vector DBを比較している

本番より、放置された検証環境で費用が目立つ可能性がある。

必要な対応

RAG費用を次の層へ分解する。

ingestion:
  source storage
  parsing
  embedding
  indexing / database

serving:
  retrieval
  reranking
  generation
  network

baseline:
  managed database
  monitoring
  retained corpora

固定費をQuery数で割るだけでなく、データ量、保持期間、同期頻度、環境数も配賦キーにする。

実装・移行手順

1. Billing Exportを有効化する

Cloud Billing ExportをBigQueryへ送り、Vertex AI、Spanner、Storage、NetworkなどRAG関連SKUを抽出する。請求画面の総額だけで判断しない。

2. Project・Region・Corpusを棚卸しする

各Corpusの所有者、用途、環境、データ量、最終Query、最終同期、保持期限を記録する。所有者不明のPoCは停止候補にする。

3. 費用タグ・ラベルを整える

直接ラベルを付与できない管理リソースがある場合、Project、Folder、Billing Account、Corpus台帳を使って配賦する。管理リソースの内部名へ依存し過ぎない。

4. Baseline Costを測る

Queryがほぼない期間の費用を測り、1環境・1Corpusを維持する最低費用を把握する。利用量が増えたときの限界費用と分ける。

5. 共有と分離を比較する

環境・テナントを共有すれば固定費を抑えられる可能性があるが、権限、データ漏えい、Quota、障害範囲が広がる。費用だけで共有しない。

6. Budgetと自動通知を設定する

日次・月次の予算、異常増加率、未使用Corpus、同期失敗、データ急増を監視する。自動削除は誤操作リスクがあるため、まず所有者通知と承認を行う。

失敗しやすい点

  • モデル料金だけを見て管理DB費用を除外する
  • 全費用をQuery数だけで配賦する
  • 費用削減のため全テナントを安易に共有する
  • 削除前に原文・Metadata・設定をExportしない
  • Regionによる料金・所在地・Network差を無視する

データ量が大きくQueryが少ない部門と、データ量が小さくQueryが多い部門では費用構造が違う。複数の配賦キーを使う。

評価方法

  • RAG全体月額
  • Baseline Costと変動費の比率
  • Corpus・Project・Region別費用
  • 1,000 Query当たり総費用
  • 1GB・1万Chunk当たり維持費
  • 最終利用から30日以上のCorpus費用
  • 同期1回当たり費用
  • Query成功率と費用
  • 取得品質改善1ポイント当たり追加費用
  • 共有構成と分離構成のTCO
  • 削除・再構築に必要な時間と費用

品質と費用を同時に比較する。安いがRecallが低い構成は本番価値がない。

ロールバック

費用が想定を超えた場合は、まず新規Ingestionと大規模同期を停止し、Queryを継続できるか確認する。即時にCorpusを削除すると復旧が難しい。

  1. 新規Corpus作成を停止する
  2. 非本番の同期を一時停止する
  3. 未使用Corpusの所有者へ確認する
  4. 原文・Metadata・設定をExportする
  5. 読み取り専用期間を設ける
  6. 承認後に削除または代替基盤へ移す
  7. BudgetとQuotaを修正する

別Vector Storeへ移行する場合は、Embeddingモデル、Distance Metric、Chunk ID、Metadata Filterの差を評価する。

編集部分析

管理型RAGの評価では、開発速度と運用省力化を費用へ含める必要がある。Spanner料金だけを見て自前基盤が安いと結論づけると、バックアップ、可用性、更新、監視、人件費を見落とす。

一方、管理型サービスは小規模PoCで固定費が相対的に大きく見えやすい。多数の試験環境を無期限に残す運用とは相性が悪い。PoCには終了日、所有者、成功条件、削除手順を必須にすべきである。

最適化の順序は、単価交渉より、不要環境の削除、データ量の適正化、同期頻度、共有・分離設計、Query品質である。費用を可視化できなければ、品質改善の投資判断もできない。

実務チェックリスト

  • [ ] Billing ExportでRAG関連SKUを抽出した
  • [ ] 全Corpusに所有者・用途・終了日を付けた
  • [ ] Baseline Costと変動費を分けて測った
  • [ ] Project・Region・Corpus別に配賦できる
  • [ ] Query数以外にデータ量・保持期間も配賦へ使った
  • [ ] 共有構成のデータ漏えいリスクを評価した
  • [ ] 非本番の未使用Corpusを定期検出する
  • [ ] Budget Alertと異常増加通知を設定した
  • [ ] 削除前の原文・Metadata・設定Export手順がある
  • [ ] 代替Vector StoreとのTCOを品質込みで比較した

一次情報