LASSIC Media らしくメディア
GCP BigQueryのコストを最適化する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- BigQueryの課金はクエリ（計算）とストレージの2軸。どちらを削るかで手法が変わります
- パーティション・クラスタリング・Editions切り替えで、スキャン量と固定費を大きく圧縮できます
- 外注で進める際の依頼前チェック・委託先の見極め方を具体的なステップで解説します
目次
BigQueryの課金モデル：クエリとストレージの2軸
GCP BigQueryのコスト最適化とは、クエリ（計算）とストレージという2つの課金軸を把握したうえで、スキャン量・予約スロット・保管データの各コストを体系的に削減することを指します。
BigQueryの課金は大きく2つに分かれます。クエリ課金（計算コスト）とストレージ課金です。この2軸を別々に管理することが、コスト削減の前提となります。
クエリ課金の2方式
クエリ課金には「オンデマンド」と「BigQuery Editions（スロット予約）」の2方式があります。オンデマンドは、クエリが実際にスキャンしたデータ量に応じて課金される従量課金方式です。執筆時点の目安として1TBあたり約$6.25（$建て・Google Cloud公式料金に基づく目安値）とされています*1。
BigQuery Editionsは、スロット（クエリ処理の計算単位）を事前に予約する方式です。確保スロット数×時間で課金されます。Autoscalerのbaselineスロット数を0に設定すれば、アイドル時の課金をゼロにできます。大量クエリが定常的に発生するワークロードでは、オンデマンドより総コストを抑えられる場合があります。
ストレージ課金の仕組み
ストレージはデータの更新頻度によって課金レートが変わります。アクティブストレージ（90日以内に更新されたデータ）と長期ストレージ（Long-term）（90日超更新なしのデータで自動的に割安レートに変更）の2種類があります*1。
さらに、課金対象バイトを「論理バイト」と「物理バイト（圧縮後）」から選択できます。圧縮率の高いデータを多く保管している場合、物理バイト課金に切り替えることでストレージコストを下げられる場合があります。
コストが膨らむ典型パターン
BigQueryでコストが想定を超えて膨らむ原因は、主に3つのパターンに集約されます。いずれも、クエリやスキーマの設計段階で見過ごされやすいポイントです。
フルテーブルスキャンの多発
パーティション（データを時間軸などで分割する設定）やクラスタリング（特定列でデータを物理的に整列させる設定）が設定されていないテーブルへのクエリは、WHERE句で絞り込みをしても全データをスキャンします。データ量が増えるほどオンデマンドコストが線形に膨らみます。
SELECT * による全列スキャン
BigQueryは列指向ストレージのため、SELECT *を使うと必要のない列も含めてスキャン対象に入ります。100列のテーブルで5列だけ必要なクエリでも、SELECT *では100列分のスキャンコストが発生します。
常時スロット確保による固定費超過
BigQuery EditionsでAutoscalerのbaselineを必要以上に高く設定すると、低負荷な時間帯でもスロット課金が発生し続けます。利用パターンを分析せずに予約枠を設定したケースで、オンデマンドより割高になることがあります。
コスト最適化の打ち手：手法と効果の比較
コスト削減の手法は複数あり、適用できる状況と期待できる効果が異なります。以下の表で整理します。
| 手法 | 削減対象 | 効果の目安 | 留意点 |
|---|---|---|---|
| パーティション設計 | クエリコスト（スキャン量） | スキャン量を〜80%程度削減できる実践例あり*2 | テーブル再作成が必要な場合、 既存データ移行コストが発生します |
| クラスタリング | クエリコスト（スキャン量） | 特定列でのフィルタリングが多い場合に有効 | パーティションと組み合わせることで 効果が高まります |
| SELECT *回避・列指定 | クエリコスト（スキャン量） | 不要列が多いほど削減効果が大きくなります | 既存クエリの書き換えが必要です |
| クエリ結果キャッシュ | クエリコスト（再スキャン防止） | 同じクエリを繰り返す場合、 24時間以内は無料で再利用できます*1 |
テーブルへの更新があるとキャッシュは無効化されます |
| マテリアライズドビュー | クエリコスト（集計の事前計算） | 繰り返し集計クエリのコストを 大幅に抑えられます |
ビューの更新コストとのバランスを確認します |
| Editions（スロット予約） | クエリコスト（固定費への切替） | 定常ワークロードでオンデマンドより 安くなる損益分岐点を超えると有利 |
baselineを0にすればアイドル課金は ゼロにできます*1 |
| ストレージ課金方式選択 | ストレージコスト | 圧縮率の高いデータでは 物理バイト課金が有利な場合あり |
プロジェクト単位の切替のため、 全データへの影響を事前確認します |
Editions vs オンデマンドの損益分岐
BigQuery Editionsの採用可否は、月次クエリ量の安定性によって判断します。クエリ量がバラつく場合はオンデマンドが有利で、月次で一定量のクエリが継続的に発生するワークロードではEditionsの方が総コストを抑えられる傾向があります。
Autoscalerのbaselineを0スロットに設定すれば、低負荷時間帯の無駄な課金を排除できます。スロット使用量のメトリクスを2〜4週間分モニタリングしてから切替判断をするのが実務上の定石です。
外注で進める最適化：5ステップの手順
BigQueryのコスト最適化を外部パートナーに委託する場合、以下の5ステップで進めると手戻りを抑えられます。
- 現状のコスト構造の可視化（社内で実施）
INFORMATION_SCHEMAビューやBigQueryのコスト分析ダッシュボードを使い、どのプロジェクト・データセット・クエリがコストの上位を占めているかを整理します。これは外注先への依頼情報として必須です。 - スコープの定義
「既存テーブルのパーティション再設計」「クエリ棚卸しと最適化」「Editions移行検討」など、委託する範囲を具体的に決めます。スコープが曖昧だと見積りが大きくぶれます。 - RFPの作成・パートナー選定
現状のデータ量・クエリ頻度・目標削減率の目安をRFP（提案依頼書）に記載して複数社に打診します。GCPの認定資格（Professional Data Engineer等）の有無や、BigQuery最適化の実績を確認します。 - テスト環境での検証
本番データのサブセットを使ったテスト環境で、パーティション設計変更や列指定の書き換えを実施してコスト削減効果を計測します。本番への適用前に確認することで、予期しないコスト増やクエリエラーを防ぎます。 - 本番適用・モニタリング体制の構築
承認後に本番適用し、コスト予算アラートを設定します。Cloud Billingのバジェットアラートを活用して、想定外の課金増を早期に検知できる体制を整えます。
外注でコスト最適化を進める際、テスト環境での検証を省略して本番直適用した場合、既存クエリの破壊やデータの不整合が発生するリスクがあります。特にパーティション再設計はテーブルの再作成を伴うため、段階的な移行計画を事前に立てておくことが大切です。
依頼前に確認すべき4つのポイント
外注先への依頼前に社内で確認しておくべき項目があります。これらが未整理だと、委託後に手戻りが発生し、追加費用につながります。
GCPプロジェクトのIAM権限設計
外注先にどの範囲のアクセス権を付与するかを事前に決めます。BigQuery Data Viewer・Job User・Data Editor など、最小権限の原則に基づいた役割設計が必要です。権限設計は社内のセキュリティポリシーと照合して決定します。
現状のコストデータの共有可否
INFORMATION_SCHEMAや請求レポートのエクスポートデータを外注先と共有できるか確認します。コスト内訳が共有できない場合、パートナー側での現状診断が困難になります。
社内ステークホルダーの合意形成
BigQueryを利用している部署（データ分析チーム・開発チームなど）に対して、テーブル設計変更やクエリ書き換えが発生する可能性を事前に伝えます。合意なく変更が行われると、業務影響が生じるリスクがあります。
契約形態とスコープの明文化
「コスト削減率〇%を目標とする」という成果報酬型か、「作業工数単価×時間」の準委任型かによって、リスク分担が変わります。スコープ外の追加作業の取り扱いも契約書に明記します。
外注先の選び方：3つの評価軸
BigQueryのコスト最適化を委託するパートナーを選ぶ際、以下の3軸で評価すると失敗を避けやすくなります。
GCP認定資格と実績の確認
Google Cloud認定資格（Professional Data EngineerやCloud Architect）の保有者がプロジェクトに参加するかを確認します。加えて、BigQueryのコスト最適化や大規模データ基盤の構築実績を具体的に示せる先を優先します。実績は社名や規模ではなく、扱ったデータ量・削減率の実績値で判断します。
元請（プライムベンダー）か再委託かの確認
発注先が実際に作業をするのか、あるいは別の会社に再委託するのかを確認します。再委託が発生する場合、コミュニケーションコストが増し、品質管理のラインが不明確になります。元請（プライムベンダー）として直接作業する体制かどうかを確認することが大切です。
コスト監視・継続サポートの有無
最適化は一度実施して終わりではありません。クエリの追加・データ量の変化に伴い、定期的な見直しが必要です。Cloud Billingアラートの設定支援や、最適化後のモニタリングレポートを提供するパートナーを選ぶと、長期的な費用対効果が高まります。
内製でBigQueryの最適化を進める場合、Google Cloud認定資格レベルのデータエンジニアリング知識が必要です。パーティション設計・スロット管理・IAM設計を兼ねた人材を確保するには、採用・育成に相応のリードタイムが見込まれます。外部パートナーへの委託は、その間のコスト流出を抑える手段として機能します。
まとめ：外注を成功させる3つの判断軸
本稿では、BigQueryのコスト最適化を外注で進める手順と判断ポイントを整理しました。要点を3つに集約すると次のとおりです。
第一に、クエリとストレージという2軸の課金を別々に把握し、フルスキャン・SELECT *・過剰スロットという典型的な無駄を特定することが出発点です。第二に、パーティション・クラスタリング・Editions切り替えはデータ量やクエリパターンによって効果が異なるため、テスト環境での計測を経てから本番適用することが手戻りを防ぎます。第三に、外注先の選定では認定資格・元請体制・継続サポートの3軸で評価し、依頼前にIAM権限とスコープを明文化しておくことで、追加費用リスクを抑えられます。
よくある質問
BigQueryのオンデマンドとEditionsはどちらを選べばよいですか？
月次クエリのスキャン量が安定していてまとまった量がある場合はEditionsが有利になる傾向があります。逆に、クエリ量が月によって大きく変動する場合や小規模な利用ではオンデマンドの方がコストを抑えられます。Autoscalerのbaselineを0に設定するとアイドル時の課金をゼロにできるため、まずは2〜4週間スロット使用量をモニタリングしてから移行を検討することをお勧めします*1。
パーティション設計は既存のテーブルに後から適用できますか？
BigQueryでは既存のテーブルにパーティションを後付けすることはできません。新しいパーティション済みテーブルを作成して既存データをコピーする移行作業が必要です。データ量が大きい場合はBigQuery Data Transfer Serviceや分割コピーを活用します。移行作業を伴うため、スコープとコストをパートナーと事前に合意することが大切です。
コスト最適化の外注にはどのくらいの期間がかかりますか？
現状診断からテスト環境での検証・本番適用まで含めると、一般的に数週間から数か月程度の期間が見込まれます。テーブル数やクエリの複雑さによって工期は変わります。まず現状のコスト構造を可視化するフェーズだけ依頼し、その結果を見てから最適化実装フェーズに進む段階的な発注方法も有効です。
Long-termストレージへの自動切り替えはどのように機能しますか？
BigQueryでは、テーブルまたはパーティションが90日間連続で更新されない場合、自動的にLong-term（長期）ストレージのレートが適用されます*1。追加の設定は不要で、更新があった時点でアクティブストレージのレートに戻ります。アーカイブ目的のデータや参照専用の履歴テーブルは、Long-termの恩恵を受けやすい傾向があります。
クエリ結果キャッシュはどのような条件で利用できますか？
BigQueryのクエリ結果キャッシュは、同じクエリ文字列・同じテーブル・テーブルへの変更なしの条件を満たす場合に、24時間以内であれば追加課金なしで再利用できます*1。ただし、テーブルへの書き込みが発生するとキャッシュは無効化されます。また、非決定的な関数（CURRENT_TIMESTAMPなど）を含むクエリはキャッシュされません。定期レポートや繰り返し参照クエリへの適用が有効です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google Cloud「BigQuery の料金」（2024年）
- *2 出典：Google Cloud「BigQuery コストのベストプラクティス」（2024年）
