LASSIC Media らしくメディア
GCP Firestore/Spannerのコスト最適化を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- FirestoreはドキュメントI/O操作単位の課金、Spannerは処理ユニット（PU）単位の課金という異なるコスト構造を持ち、ワークロード規模によって最適解が変わります。
- インデックス設計の誤りや不要な全スキャンクエリが、コストを意図せず押し上げる主因となるため、両サービスで設計フェーズからの見直しが有効です。
- GCPデータベースの内製コスト管理は専門知識と継続的な監視が必要で、外注によりコスト分析・設計改善・コミットメント活用をまとめて任せる選択肢があります。
目次
GCP マネージドDBのコスト最適化とは
GCP Firestore/Spannerのコスト最適化とは、Google Cloud Platform（GCP）が提供するマネージド型データベースサービスの課金モデルを正確に把握し、インデックス設計・クエリ改善・データライフサイクル管理・コミットメント活用を組み合わせてクラウド費用を適正化する取り組みを指します。
GCPのマネージドデータベースは、Firestoreのようなドキュメント型NoSQLと、Spannerのような水平スケール可能なリレーショナルデータベースで構成されています。両者はビジネス要件に応じて使い分けられますが、課金の仕組みが根本的に異なるため、最適化アプローチも異なります。
両サービスに共通するのは、設計フェーズの意思決定がコストに大きく影響するという点です。インデックス設計やクエリパターンを後から変えると、サービス影響を伴う大規模な改修が必要になります。初期から正しいアーキテクチャで臨むことが、長期的なコスト最適化の前提となります。
Firestoreのコスト構造：操作課金・ストレージ・ネットワーク
Firestoreは、ドキュメントに対する読み取り・書き込み・削除という操作単位で課金される仕組みを採用しています*1。1日あたりの無料枠（読み取り5万回・書き込み2万回・削除2万回・ストレージ1GiB・アウトバウンド帯域10GiB/月）を超えた分から費用が発生します。
操作課金の特性上、アプリケーションのコード変更によってドキュメントへのアクセス回数が増えると、費用も比例して増加します。1回のAPIリクエストで複数のドキュメントを読み込むケースでは、それぞれのドキュメントが課金対象となります。
ネットワーク費用については、同一リージョン間の転送は無料です。異なるリージョン間（例：US内の複数リージョン）では課金が発生するため、アーキテクチャ設計時にデータの流れを考慮する必要があります*1。
ストレージはデータ本体とインデックス用ストレージの合算で請求されます。インデックスはFirestoreが自動作成するものも含まれ、ドキュメントへの書き込み1回ごとにインデックスエントリも更新されます。インデックスが多いほど書き込みコストと、インデックスのストレージコストが増加します。
Spannerのコスト構造：処理ユニット(PU)・ストレージ
Cloud Spannerは、コンピュートリソースを処理ユニット（PU）という単位で計測し、時間課金します*2。1,000 PUが1ノードに相当し、100 PU単位での指定が可能です（1,000 PU以上の場合はノード単位でも指定可能）*2。
1,000 PU未満のインスタンスは小規模データ向けに設計されており、インデックス書き込みのレイテンシが断続的に増加する可能性があります*2。本番ワークロードで強整合性・水平スケールが求められる場合は、1,000 PU（1ノード）以上が推奨されます。
ストレージは実際に使用した容量のみが課金され、プロビジョニングしたストレージ上限ではありません*2。1ノード未満の場合は100 PUあたり1,024 GiBのデータ格納が目安、1ノード以上では1ノードあたり10 TiBまでのデータに対応します*2。
コスト予測の観点では、アクセス量に関係なくコンピュートコストが固定的に発生する点がFirestoreと大きく異なります。低アクセス期間でもPUの費用は継続して発生するため、ワークロードの規模感と利用パターンを事前に把握しておくことが大切です。
FirestoreとSpanner、ワークロード規模での損益分岐点
FirestoreとCloud Spannerは、ターゲットとするワークロード規模が異なります。Google Cloudの公式ドキュメントでは、両者を補完関係として位置づけています*3。
| 比較軸 | Firestore | Cloud Spanner |
|---|---|---|
| データモデル | ドキュメント型NoSQL（スキーマレス） | フルマネージドリレーショナルSQL |
| 課金モデル | 操作（読み取り/書き込み/削除）単位 ＋ストレージ＋ネットワーク |
処理ユニット（PU）時間課金 ＋ストレージ（実使用分） |
| 無料枠 | 読み取り5万回・書き込み2万回/日 ストレージ1GiB |
無料枠なし（PUの時間課金が即発生） |
| 小規模向け | 低コストで開始可能（無料枠内運用も可） | 100 PU構成から起動可能だが継続費用が発生 |
| 大規模・整合性 | 水平スケール可能だが強整合性はトランザクション内に限定 | グローバル強整合性・外部整合性トランザクションに対応 |
| 向いているケース | モバイルアプリ・リアルタイム同期・スキーマ変動が多いシステム | 金融・在庫・予約など強整合性が必須の大規模トランザクション |
アクセス量が少ない開発・検証フェーズや中小規模のアプリケーションでは、操作単位で課金されるFirestoreの方が費用を小さく抑えやすい傾向があります。一方、強整合性・水平スケールの両立が必要で、常時高トランザクションなワークロードではCloud Spannerのコスト構造が合理的になります。
どちらのサービスも、要件に対してオーバースペックな状態で運用を続けると費用が膨らみます。定期的なワークロード評価と適切なサービス選択の見直しが、コスト最適化の出発点となります。
Firestoreのコスト削減：インデックス・クエリ・TTL最適化
インデックス設計の見直しで書き込みコストを抑える
Firestoreでは、すべてのフィールドに対してデフォルトでインデックスが作成されます*1。インデックスのエントリ数は1ドキュメントあたり40,000件が上限であり、大型の配列フィールドやマップフィールドを持つドキュメントは、書き込み時のインデックス更新コストが増大します*4。
コレクショングループ単位でのインデックス免除設定（例：降順インデックス・配列インデックスの無効化）を行うと、クエリで使用しないインデックスエントリを排除でき、書き込みレイテンシとストレージコストの両方を削減できます*4。クエリパターンを先に整理し、実際に必要なインデックスだけを残す設計が重要です。
オフセット型クエリの廃止でムダな読み取り課金を防ぐ
ページネーションにオフセット（offset）を使用すると、スキップしたドキュメントもFirestoreの内部では読み込まれるため、読み取り課金が発生します*4。カーソルベースのページネーション（startAt/startAfterを活用）に切り替えることで、実際に取得するドキュメント分だけの課金に抑えられます。
また、削除済みドキュメントを含む範囲を再スキャンするクエリも不要な読み取り料金を生みます。startAtメソッドで処理済みの位置を明示的に指定し、再スキャンを防ぐ設計が有効です*4。
TTLポリシーで不要データのストレージ費用を自動削減
Firestoreには、特定フィールドに設定した期限（タイムスタンプ）を過ぎたドキュメントを自動削除するTTL（Time-to-Live）ポリシー機能があります*5。TTLによる削除は削除操作として課金されますが、ストレージコストの継続的な増加を防ぐ効果があります。
TTLは1コレクショングループあたり1フィールドのみ設定でき、削除はポリシー設定から通常24時間以内に処理されます*5。ログデータ・セッション情報・一時データなど、保持期限が明確なデータに活用することで、ストレージ肥大化を防げます。
非同期処理による並列化で読み取り効率を高める
データに依存関係がない複数のドキュメント取得を順次実行（同期処理）すると、レイテンシが加算されます。並列（非同期）実行に切り替えることで、同じドキュメント取得量でも処理時間を短縮でき、高負荷時のオペレーション数増加を抑えられます*4。
Spannerのコスト削減：PUサイジング・クエリ計画・コミットメント割引
ワークロードに合わせたPUサイジング
Cloud Spannerのコストはプロビジョニングするコンピュートキャパシティ（PU数）に比例します。使用率が低い状態でPUを多めにプロビジョニングし続けると、固定費が継続的に発生します。Google Cloudのコンソールで提供されるCPU使用率・ストレージ使用量・スキャン統計を定期的に確認し、実際のピーク負荷に合わせてPUを調整することが基本的な削減策となります。
1,000 PU（1ノード）未満の構成は、小規模データ向けに100 PU単位で細かく指定できます*2。ただし、1,000 PU未満では断続的なレイテンシ増加が起こりうるため、SLA（サービス水準合意）要件と費用のバランスで判断する必要があります。
クエリ実行計画の分析でフルスキャンを排除する
SpannerはSQLクエリの実行前に複数の実行計画を評価し、効率的な計画を選択します*6。クエリ実行計画には「バックジョイン」（非インターリーブテーブル間のリモートフェッチ）と「コロケートジョイン」（インターリーブテーブル間のローカル実行）があり、バックジョインはコンピュートコストが高くなります*6。
Google Cloudコンソールの「クエリインサイト」ページでは、CPU時間の多いクエリのサンプルが30日分保持されます*6。このデータを定期的に確認し、フルテーブルスキャンや非効率なジョインが発生しているクエリを特定・見直すことで、不要なコンピュートコストを削減できます。
テーブルインターリーブで結合コストを下げる
Spannerのテーブルインターリーブ（親子テーブルの物理的な同一場所配置）は、関連するデータを同じサーバーに格納するため、ジョイン時のリモートフェッチが不要になります*6。親テーブルと子テーブルが頻繁に結合されるスキーマでは、インターリーブ設計がコスト削減に直結します。
コミットメント割引を活用した費用の予測可能化
Cloud Spannerではコミットメント使用割引（Committed Use Discounts）を適用することで、オンデマンド価格より低い料金でコンピュートリソースを確保できます。安定したベースロードが見込まれるワークロードでは、1年または3年のコミットメントを検討する価値があります。コミットメント割引の具体的な適用率はGoogle Cloudの公式価格ページでご確認ください*3。
内製が難しい理由：必要スキルと見落としがちな失敗コスト
内製で必要な専門知識と体制
GCPデータベースのコスト最適化を内製で行うには、次の知識が必要です。Cloud Billingの請求データ分析、Firestore/SpannerのクエリAPIと課金モデルの深い理解、BigQueryによるコスト傾向分析、Google Cloudコンソールのクエリインサイトを活用した継続的モニタリングです。
これらをカバーするには、GCPの認定資格（Professional Cloud Architect、Professional Data Engineerなど）を持つエンジニアと、日常的な監視を担当するオペレーターの両方が必要です。規模によりますが、専任のクラウドコスト管理者を置けないチームでは、監視が断続的になり費用増加を見逃しやすくなります。
設計フェーズの誤りが生む後追いコスト
インデックス設計の誤りは、サービス稼働後の修正が困難です。Firestoreでは複合インデックスをクエリに合わせて再設計する際、既存クエリへの影響を慎重に検証する必要があります。Spannerではテーブルインターリーブ変更がオンラインスキーマ変更として処理されますが、大規模テーブルでは完了まで相当な時間を要します。
クエリパターンの変更がなされずに運用が続くと、フルスキャンやカーソルなしのページネーションによる課金が毎月積み上がります。こうした「設計時の判断ミスによるランニングコストの継続的増加」は、気づくまでに費用が膨らむリスクがあります。
適切なPU・コミットメント選択を誤った場合の影響
SpannerのPU設定を過剰にした場合、必要以上のコンピュートコストが継続します。逆に不足した場合はパフォーマンス劣化が発生し、その影響がトランザクション処理の遅延としてビジネスに現れます。コミットメント割引を申請するタイミングを逃すと、オンデマンド料金が長期間続く状況も生まれます。
GCPデータベースコスト最適化を外注するメリット
GCP Firestore/Spannerのコスト最適化を外注するとは、クラウド費用の分析・設計改善提案・実装・継続監視を専門パートナーに委託する形態を指します。内製でカバーしきれない専門知識と継続的な工数を外部に補完する選択肢です。
外注により期待できる主な効果は次の3点です。第一に、GCPの最新仕様・料金体系・ベストプラクティスを把握した専門家がコスト分析を行うため、内製では見逃しやすい課題（インデックス肥大化・クエリ非効率・コミットメント未活用）を早期に特定できます。
第二に、PoC（概念実証）フェーズから本番フェーズへの移行時にPUサイジングを適切に設定することで、過剰プロビジョニングを防げます。第三に、継続的な監視体制をパートナーが担うことで、社内の開発リソースが本来の機能開発に集中できます。
外注先を選ぶ際の判断軸としては、GCPの認定パートナーであるか、Firestore・Spannerどちらの実績も持つか、コスト可視化ツール（Cloud Billing Report・Recommender等）を活用した提案実績があるかを確認することが大切です。
まとめ：Firestore/Spannerコスト最適化の3つの判断軸
本稿では、GCP FirestoreとCloud Spannerのコスト構造・削減手法・外注判断について整理しました。要点を3つに集約すると次の通りです。
第一に、FirestoreとCloud Spannerはコスト構造が根本的に異なります。Firestoreは操作単位課金で小規模から柔軟に使える反面、アクセス量増加に比例してコストが上昇します。SpannerはPU時間課金でコスト予測がしやすい一方、使用率に関わらず固定費が発生します。
第二に、両サービスとも設計フェーズの意思決定がコストの大部分を決定します。インデックス最適化・クエリ設計・TTL活用・テーブルインターリーブといった設計上の選択が、長期的なランニングコストを左右します。稼働後の変更は工数とリスクを伴います。
第三に、コスト最適化の継続的な運用には専門知識と監視体制が必要です。内製のみで対応しきれない場合、外注によって課題の早期発見・コミットメント割引の活用・継続的なコスト管理をまとめて依頼できる選択肢があります。
よくある質問
FirestoreとCloud Spannerはどちらを選べばよいですか？
ワークロードの性質によって判断します。モバイルアプリ・リアルタイムデータ同期・スキーマ変更が頻繁なシステムでは、スキーマレスで小規模から使えるFirestoreが向いています。金融取引・在庫管理・予約システムなど強整合性とグローバルスケールが必要なケースでは、外部整合性トランザクションに対応したCloud Spannerが適します。Google Cloudの公式ドキュメントでは両者を補完関係として位置づけており、要件に応じた選択が推奨されています*3。
Firestoreのインデックス費用はどうやって確認できますか？
Google Cloudコンソールの「Cloud Billing」から、Firestoreのストレージ費用の内訳を確認できます。インデックスストレージは本文データストレージと分けて表示されます。インデックス肥大化の兆候は、書き込み量に対してストレージ増加が急速なケースで現れます。Google Cloud公式の「Firestore ベストプラクティス」ガイドでは、コレクショングループ単位でのインデックス免除設定を行い、不要なインデックスエントリを削減することが推奨されています*4。
Cloud SpannerのPUはどのように決定すればよいですか？
Google Cloudの公式ドキュメントでは、1,000 PU（1ノード）未満の構成は小規模データ向けとされており、断続的なレイテンシ増加が起こりうると明記されています*2。本番環境での利用では、実際のピークトランザクション数・データ量・レイテンシ要件を負荷テストで計測し、必要なPUを算出してから決定することが推奨されます。スタート時は小さめのPUで始め、Cloud Monitoringで CPU使用率を継続的に監視しながら段階的に調整するアプローチが一般的です。
FirestoreのTTL削除は無料ですか？
TTLによる削除は削除操作として課金されます*5。ただし、期限切れドキュメントを手動でアプリケーションから削除する場合と比べ、TTLは自動的に処理されるためオペレーション管理コストを削減できます。また、TTLで削除されたドキュメントは削除後にストレージ費用が発生しなくなるため、長期的にはストレージコストの抑制に寄与します。削除規模と頻度を事前に見積もり、削除操作コストとストレージ削減効果のバランスを確認してから設定することをおすすめします。
GCPデータベースのコスト最適化を外注する際、どのような情報を準備しておくとよいですか？
相談前に準備しておくと有効な情報は次の通りです。現在の月次Cloud Billing請求金額とFirestore/Spannerの内訳、現在のPU数またはノード数（Spannerの場合）、主要なクエリパターンとインデックス設計のドキュメント、アクセス量の傾向（ピーク時・平常時）、強整合性・レイテンシなどのSLA要件です。これらを整理しておくことで、外注先が現状のコスト構造を把握しやすくなり、具体的な改善提案が出るまでの時間を短縮できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google LLC「Cloud Firestore の料金」（2025年）
- *2 出典：Google LLC「Cloud Spanner 処理ユニットとノードについて」（2025年）
- *3 出典：Google LLC「Cloud Spanner の料金」https://cloud.google.com/spanner/pricing（2025年）
- *4 出典：Google LLC「Cloud Firestore のベストプラクティス」（2025年）
- *5 出典：Google LLC「Cloud Firestore の TTL ポリシーについて」（2025年）
- *6 出典：Google LLC「Cloud Spanner クエリ実行計画について」（2025年）
