Summary

  • Googleは2026年10月30日からTabFMのモデル・トークンを別途課金し、クエリの非モデル部分にはスロット・処理バイト料金を適用する予定だ。
  • 公開された式では行数、列数、n_ensemblesがトークン量を決める。同じデータならアンサンブル数を2倍にするとモデル分も2倍になる。

便利なSQLに二つの料金計器

BigQueryのAI.PREDICTなら、ラベル付きの表と予測対象の表を渡し、分類や回帰の結果を一つのSQL文で受け取れる。別のモデルを配備する手間がない。その便利さの費用構造が変わる。Googleの関数説明は、2026年10月30日からTabFMのモデルが消費するトークンを課金し、クエリのうちモデル推論以外の処理には引き続きスロットまたは処理バイトの料金を適用すると記す。執筆時点は10月28日。発効予定の料金を、すでに届いた請求書として扱うことはできない。

プレビュー期間の利用は、EnterpriseとEnterprise Plusではスロット、オンデマンドでは処理バイトに応じて請求される。新しい仕組みでは、非モデル部分の計器にモデル用の計器が加わる。開発者が見るのは一つの関数でも、経理が追うべき単位は二つになる。データベースにモデルを収めたことが、モデルの費用を消したわけではない。

倍率を決めるのは小さな引数

公式料金表の単価は入力100万トークン当たり0.05ドル、出力100万トークン当たり0.20ドル。入力数は「（学習行数×列数＋予測行数×（列数−1））×n_ensembles」、出力数は「予測行数×n_ensembles」だ。列数には計算に使う特徴量と目的ラベルを含む。アンサンブル数は、順序を変えたデータで複数回予測し平均する回数を表す。入力と出力の両式に乗るため、同じデータでもこの値を2倍にすればモデル料金は2倍になる。モデル説明では特徴量列の上限を50とする。

たとえば、ラベル付き100万行、20列、予測10万行、アンサンブル4なら入力8760万、出力40万トークンとなり、モデル分の定価は4.46ドル。アンサンブル8なら8.92ドルだ。これは公式の式を使った試算で、顧客の実際の請求ではない。クエリのスロット・処理バイト、ストレージ、個別契約の条件も含めていない。重要なのは合計の小ささより、性能を求める設定変更が費用を正確に押し上げる点である。

誰が費用を決めるのか

基盤チームがBigQueryの計算枠を管理していても、n_ensemblesを変えるのは分析者やアプリの開発者かもしれない。対象行を増やす、列を広げる、実行頻度を上げる。どれもモデル料金に響き、既存の計算枠の契約はその判断を代わりにしてくれない。SQLの採用審査に、行数、列数、アンサンブル、実行間隔を含める必要がある。

一回数ドルの試験なら軽い。しかし毎時間走るサービスでは、小さな差が繰り返される。アンサンブルを増やして精度が上がるなら、その改善を測って追加料金と並べればよい。測らずに設定を増やすなら、予算権限は静かにクエリの書き手へ移る。Googleは少なくとも価格と数式を公表した。顧客側に残る仕事は、予測の価値を同じ粒度で測ることだ。

実際の影響を確かめるには、10月30日以降の請求と、その対象になったクエリの設定が要る。それまでも商売の構図は読める。一文で呼べる予測が、二つの単位で売られる。

出典