BigQuery、fluid scalingを一般提供に

Google Cloud は BigQuery の 2026年6月3日リリースノートで、BigQuery fluid scaling が一般提供になったと案内しました。autoscaling reservations に対して、最小利用時間なしの秒単位課金を提供する更新です。

要点

• BigQuery fluid scaling が一般提供になった
• autoscaling reservations で秒単位課金と最小利用時間なしを使える
• 短時間のピーク、突発的な分析、AI/BI 系ワークロードの費用設計に関係する
• 予約容量とオンデマンドの使い分け、予算監視、ジョブ設計を見直すきっかけになる

今回のリリースノートで語られていること

BigQuery の fluid scaling は、autoscaling reservations の使い方をより細かい時間単位に寄せる更新です。従来、予約容量や自動スケールを使う場合、ピークに合わせて余裕を持たせるか、短時間の需要増に対して費用効率が悪くなるかが論点になりがちでした。今回の一般提供では、秒単位課金と最小利用時間なしが示されているため、短いピークに対して必要な分だけ容量を伸ばす設計を取りやすくなります。

データ基盤チームにとって重要なのは、これは単なる課金方式の変更ではなく、ワークロード分離と予算管理の設計に影響する点です。たとえば、定常的な日次集計、突発的なアドホック分析、生成 AI や BI の裏側で走る探索的クエリ、キャンペーンや月末締め処理のような短時間ピークでは、必要容量の読み方が異なります。fluid scaling が使える場合、ピークだけのために大きな余剰を持つより、reservation と autoscaling の境界を細かく設計する選択肢が増えます。

一方で、秒単位課金になったからといって費用管理が自動で簡単になるわけではありません。クエリの並列度、BI ツールからの再実行、スケジュールジョブの集中、AI エージェントやノートブックからの探索的実行が重なると、短時間でも利用量が膨らみます。一般提供になったことで本番利用しやすくなる分、どのプロジェクトや部門にどの reservation を使わせるか、autoscaling の上限をどう置くか、費用アラートをどう設計するかがより重要になります。

実務で確認したいポイント

まず、既存の BigQuery reservations で、短時間ピークのために過剰な容量を持っている領域がないか確認したいところです。fluid scaling の対象にできる workloads を洗い出し、日次・月次処理、BI、機械学習、データ準備、アドホック分析を分けて評価します。

次に、費用監視の粒度を確認します。秒単位で伸び縮みする容量は柔軟ですが、部門別の chargeback、プロジェクト別予算、ジョブ種別ごとの上限が曖昧だと、予想外の費用増につながります。reservation assignment、ラベル、監査ログ、課金エクスポートを合わせて見直す必要があります。

結局、この更新をどう見るべきか

BigQuery fluid scaling の一般提供は、ピークに合わせて容量を硬く確保する設計から、短時間の需要変動をより細かく吸収する設計へ寄せる更新です。データ基盤チームは、性能改善だけでなく、予約容量、autoscaling 上限、費用配賦、BI/AI ワークロードの使い方をセットで見直すべきです。