2026.08.17 インフラ

BigQuery MLとは：CREATE MODELで学習するモデル種別とVertex AIとの分担・推論コスト

需要予測や解約予測をやりたいが、データはすでにBigQueryにあり、Pythonの学習基盤を別途立てるほどの体制はない。この状況で候補に挙がるのがBigQuery MLです。SQLのCREATE MODELでモデルを作り、ML.PREDICTで推論する。データを外へ出さないぶん、部品も権限設計も減るのが利点です。ただし何でも作れるわけではなく、学習の実体がVertex AI側へ出る種別もあれば、学習だけが通常クエリの50倍の単価で課金される点も見逃せません。この記事では2026年8月17日時点の公式ドキュメントの実測をもとに、構文、モデル種別の切り分け、評価と推論の関数、Vertex AIとの役割分担、費用の見積もりを実装の解像度で整理しました。土台となるDWHの仕組みはBigQueryの仕組みと採用判断をまとめた解説に譲ります。

まとめ：定型の予測はSQLで完結し、作り込みと低遅延の推論だけを外へ出す

BigQuery MLは、学習データの抽出から学習、評価、バッチ推論までを一つのSQL方言で完結させる仕組みです。線形回帰、ロジスティック回帰、K平均法、行列分解、ARIMA_PLUSといった種別はBigQueryのスロットだけで学習が終わり、モデルはデータセット内のオブジェクトとして残ります。TRANSFORM句に書いた前処理は推論時にも同じ変換が自動で適用されるため、学習時と推論時で特徴量がずれる事故を構造的に防げます。

一方で、ディープニューラルネットワークやブーストツリー、AutoMLは外部トレーニングと呼ばれ、学習の実体はVertex AI側で走ります。SQLの見た目は同じでも、走る場所も請求先も変わる。ここを混同したまま見積もると金額が合いません。

費用構造も一点だけ特殊です。内蔵モデルの作成は1TiBあたり312.50ドルで、通常クエリの6.25ドルに対して50倍。逆にML.PREDICTやML.EVALUATEは通常クエリと同じ単価です。費用は「何回学習し直すか」でほぼ決まる、と考えてください。

BigQuery MLがCREATE MODELの一文で学習を完結させる仕組み

BigQuery MLは独立したサービスではなく、BigQueryのSQLに追加されたDDLと関数群です。モデルはテーブルと同じくデータセットの下に作られ、IAMもデータセット単位の権限がそのまま効きます。

OPTIONSのmodel_typeとAS SELECTで設定と学習データを同時に渡す

CREATE MODELの構造は単純です。OPTIONSでモデルの種類と学習の設定を指定し、AS以下のSELECTで学習データを渡します。ラベル列はinput_label_colsで名指しするか、labelという名前の列を用意しておけば自動で拾われます。

CREATE OR REPLACE MODEL `myproject.mydataset.churn_model`
OPTIONS(
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['churned'],
  data_split_method = 'AUTO_SPLIT'
) AS
SELECT
  churned,
  months_since_signup,
  monthly_orders,
  support_tickets,
  plan_name
FROM `myproject.mydataset.customer_features`
WHERE signup_date < '2026-01-01'

注目したいのは、学習データの指定がそのままSQLである点です。特徴量テーブルを事前に物理化する必要はなく、JOINやウィンドウ関数を含むSELECTをそのまま渡せます。特徴量の作り方を変えて試すサイクルが、クエリの書き換えだけで回るわけです。カテゴリ列の文字列は内部でワンホットエンコードされます。

TRANSFORM句に書いた前処理は推論時も同じ変換が自動で適用される

実務で効くのがTRANSFORM句です。標準化やバケット化、対数変換といった前処理をここに書いておくと、その定義がモデルに保存されます。ML.PREDICTを呼ぶときは生の列をそのまま渡せばよく、同じ変換が内部で再適用されます。

CREATE OR REPLACE MODEL `myproject.mydataset.churn_model`
TRANSFORM(
  churned,
  ML.STANDARD_SCALER(months_since_signup) OVER() AS tenure_scaled,
  ML.BUCKETIZE(monthly_orders, [1, 5, 20]) AS order_band,
  plan_name
)
OPTIONS(model_type = 'LOGISTIC_REG', input_label_cols = ['churned']) AS
SELECT * FROM `myproject.mydataset.customer_features`

学習時と推論時で前処理コードが二重管理になる問題は、機械学習の運用でよく壊れる箇所です。BigQuery MLではその二重管理が構文レベルで消えます。特徴量を複数のモデルで共有したい規模になってきたら、Vertex AI Feature Storeの仕組みと現在の提供状況もあわせて検討してください。

学習・評価・推論はCREATE MODELとML関数を使い分けて回す

作ったモデルは、テーブルを参照するのと同じ感覚で関数に渡します。評価はML.EVALUATE、推論はML.PREDICT。どちらも第一引数にMODEL付きのモデル名、第二引数にデータのTABLEまたはサブクエリを渡す形です。

SELECT * FROM ML.EVALUATE(MODEL `myproject.mydataset.churn_model`);

SELECT customer_id, predicted_churned, predicted_churned_probs
FROM ML.PREDICT(
  MODEL `myproject.mydataset.churn_model`,
  TABLE `myproject.mydataset.customer_features_current`
);

ML.EVALUATEを引数なしで呼ぶと、学習時に確保された評価用データでの指標が返る仕様です。出力列は種別ごとに決まっていて、ロジスティック回帰ならprecision、recall、accuracy、f1_score、log_loss、roc_aucが並びます。推論結果はpredicted_という接頭辞が付いた列で返り、分類では各クラスの確率も同時に得られます。

対応するモデル種別を内部トレーニングと外部トレーニングで切り分ける

種別は数が多く、一覧で眺めても選べません。実装の判断で効く軸は「学習がどこで走るか」の一点で、ここが変わると所要時間も課金の出方も変わります。

内部トレーニングはBigQueryのスロットだけで学習が完結する

次の種別は、学習がBigQueryの中で完結します。追加のサービスを有効にする必要がなく、モデル作成のクエリが終わればそのまま推論に移れます。

model_type 用途 典型的な適用先
LINEAR_REG 数値の回帰 受注金額や所要時間の予測
LOGISTIC_REG 二値・多クラス分類 解約予測、成約可否の判定
KMEANS クラスタリング 顧客セグメントの抽出
MATRIX_FACTORIZATION 推薦 購買履歴からの商品推薦
PCA 次元削減 特徴量の圧縮、異常検知の前処理
ARIMA_PLUS 時系列予測 需要予測、来店数の予測
ARIMA_PLUS_XREG 外部変数つき時系列 気温や販促を加味した予測
TimesFM 時系列の基盤モデル 学習なしでの時系列予測
CONTRIBUTION_ANALYSIS 貢献度分析 指標の増減要因の分解

この範囲で足りるかどうかが最初の分岐点です。表形式データに対する回帰・分類・時系列・クラスタリングという典型的な課題は、ほぼここに収まります。ARIMA_PLUSは季節性や祝日効果の扱いが組み込まれており、時系列モデルを自前で組むより手間が小さいでしょう。

外部トレーニングでは学習処理の実体がVertex AI側へ移る

ディープニューラルネットワーク、ワイド&ディープ、オートエンコーダ、ブーストツリー（XGBoost基盤）、ランダムフォレスト、AutoMLは外部トレーニングに分類されます。SQLの書き方は内部トレーニングと変わりませんが、学習ジョブはVertex AI側で実行されます。

押さえるべき差は三つあります。学習時間の桁が変わること、請求がBigQueryだけで閉じないこと、必要なAPIとサービスアカウントの権限が増えることです。検証では内部トレーニングだけを試し、本番でブーストツリーに切り替える計画なら、権限設計を先に確認しておきましょう。

インポートモデルとリモートモデルは学習をBigQueryの外に置く

すでに学習済みのモデルがあるなら、持ち込む道もあります。ONNX、TensorFlow、TensorFlow Lite、XGBoostの各形式はインポートでき、ML.PREDICTから同じように呼び出せます。Pythonで作り込んだモデルの推論だけをBigQuery側に寄せる構成が取れるわけです。

もう一つがリモートモデルで、Vertex AIのエンドポイントを参照する定義だけをBigQueryに置く形です。生成AIのモデルをSQLから呼ぶ構成もこの型に含まれ、推論の実体は向こう側にあるため応答時間も課金もVertex AIの条件に従います。プラットフォーム側の全体像はVertex AIの機能と料金を実装者目線で整理した記事にまとめてあります。

回帰・分類・時系列で使う評価指標と推論関数の選び方をモデル別に押さえる

分類はML.EVALUATEと混同行列・ROC曲線で指標を確かめる

分類でaccuracyだけを見て判断するのは危険です。解約予測のように陽性が数パーセントしかない不均衡データでは、全件を陰性と答えるだけで高いaccuracyが出ます。ML.CONFUSION_MATRIXで内訳を確認し、ML.ROC_CURVEでしきい値ごとの再現率と偽陽性率の推移を追ってください。

SELECT * FROM ML.CONFUSION_MATRIX(
  MODEL `myproject.mydataset.churn_model`,
  TABLE `myproject.mydataset.holdout_set`,
  STRUCT(0.3 AS threshold)
);

しきい値は業務側の損得で決める値であって、既定の0.5が正解とは限りません。解約対策のクーポンを配るなら、見逃しのコストと配りすぎのコストを比べて決めます。この一点を業務側と握るところまでが実装者の仕事です。

時系列はARIMA_PLUSから予測と異常検知の両方を引ける

時系列で使うのはML.FORECASTです。horizonで何期先まで予測するか、confidence_levelで予測区間の幅を指定します。同じモデルからML.DETECT_ANOMALIESを呼べば、予測区間から外れた点を異常として拾えます。予測と監視を別々のモデルで組む必要がありません。

SELECT * FROM ML.FORECAST(
  MODEL `myproject.mydataset.demand_model`,
  STRUCT(30 AS horizon, 0.9 AS confidence_level)
);

ARIMA_PLUSはtime_series_timestamp_colとtime_series_data_colの指定が必須で、time_series_id_colを足せば店舗別や商品別のモデルを一度に作れます。数百系列を一括で学習できる点は、系列ごとにスクリプトを回す構成に対する利点です。

寄与はML.EXPLAIN_PREDICTと特徴量重要度で説明する

予測値を業務部門に渡すとき、ほぼ必ず「なぜこの顧客が解約すると出たのか」を聞かれます。ML.EXPLAIN_PREDICTは行ごとに各特徴量の寄与を返し、ML.FEATURE_IMPORTANCEはモデル全体での特徴量の効き方を返します。前者は個別の説明に、後者は特徴量設計の見直しに使う、と役割を分けて覚えておくと迷いません。

Vertex AIとの役割分担をモデルの登録先とデプロイ先で決める

MODEL_REGISTRYでModel Registryへ登録して管理を集約する

CREATE MODELのOPTIONSにMODEL_REGISTRY = ‘VERTEX_AI’を書くと、作成したモデルがVertex AI Model Registryに登録されます。VERTEX_AI_MODEL_IDで登録名を、VERTEX_AI_MODEL_VERSION_ALIASESでバージョンの別名を指定できます。

CREATE OR REPLACE MODEL `myproject.mydataset.churn_model`
OPTIONS(
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['churned'],
  model_registry = 'vertex_ai',
  vertex_ai_model_id = 'churn_model',
  vertex_ai_model_version_aliases = ['staging']
) AS
SELECT * FROM `myproject.mydataset.customer_features`

登録すると、エンドポイントへのデプロイ、予測の取得、バージョンの比較、モニタリング、評価の表示、特徴ベースの説明の取得がVertex AI側の機能として使えます。SQLで作ったモデルとPythonで作ったモデルを同じ台帳で管理できるため、両方が混在する組織ではこのオプションを既定にしておくと運用が揃うでしょう。

バッチ推論はBigQuery側・オンライン推論はエンドポイント側に置く

推論の置き場所は要求される応答時間で決まります。夜間バッチで全顧客のスコアを更新し、翌朝ダッシュボードで見るという使い方なら、ML.PREDICTの結果をテーブルへ書き出すだけで足ります。

これに対し、アプリの画面内で1件ずつ数十ミリ秒で返す必要があるなら、クエリ実行を挟む構成は向きません。Model Registryに登録してエンドポイントへデプロイし、オンライン予測として受けてください。判断の順序は「まずバッチで足りるかを確認し、足りないときだけエンドポイントを立てる」です。エンドポイントは常時稼働ぶんの費用が発生するため、先に立てると固定費だけが残ります。

登録できないモデル種別とデプロイできない種別を設計前に把握する

ここには例外があり、設計の後半で気づくと手戻りが出ます。リモートモデルはModel Registryに登録できません。またインポートしたXGBoostモデル、ARIMA_PLUS、ARIMA_PLUS_XREGは登録はできるものの、エンドポイントへのデプロイができません。

つまり時系列モデルをオンライン推論で提供する構成は、標準機能だけでは組めません。予測結果を低遅延で返したいなら、バッチで予測テーブルを作り、アプリ側のデータストアへ配る形に落とすのが現実的でしょう。

学習と推論のコストを1TiBあたりの単価と実行頻度から見積もる

内蔵モデルの学習は通常クエリの50倍で1TiBあたり312.50ドル

オンデマンド課金の場合、内蔵モデルのCREATE MODELは処理したバイト数1TiBあたり312.50ドルです。通常のクエリが6.25ドルですから、ちょうど50倍。ここを知らずに全期間・全列のSELECTをそのまま学習データに渡すと、一回の実行で想定外の金額が出ます。

裏を返せば対策は明快です。学習データのSELECTで列を絞り、期間をパーティションで限定する。この二つだけで学習の課金バイト数は桁で落ちます。学習データをBigQueryへ用意するまでの操作はBigQueryの使い方をまとめた解説で扱っています。日次の請求をジョブ履歴から追う方法はBigQueryの料金を費目に分解して監視する手順に整理してあり、statement_typeがCREATE_MODELの行だけを単価50倍で計算する集計式もそちらに載せています。

推論と評価は通常クエリと同じ単価でスキャン量が費用を左右する

ML.PREDICTやML.EVALUATEは通常のクエリと同じ1TiBあたり6.25ドルです。日次で数百万行にスコアを付ける程度なら、読む列が絞られている限り費用は小さく収まります。学習済みモデル自体の保管はBigQueryのストレージ料金に従い、サイズは通常テーブルに比べれば無視できる規模です。

ここから導ける運用方針は一つで、毎日作り直す必要があるかを疑うことです。精度の劣化を監視し、しきい値を割ったときだけ再学習する構成にすれば、学習の課金は必要なときだけ立ちます。

外部トレーニングとリモートモデルはVertex AI側の請求が別に立つ

DNNやブーストツリー、AutoMLといった外部トレーニングは、学習の実体がVertex AI側で走るぶんの費用がそちらで発生します。リモートモデルの呼び出しも同様で、公式ドキュメントは追加でVertex AIの料金が発生すると明記しています。BigQueryのコンソールで見える金額だけを追うと請求の全体が見えません。

見積もりは、内部トレーニングで完結する構成と外部トレーニングを含む構成を分けて出してください。前者はBigQueryの請求だけで閉じるため精度の高い試算ができますが、後者はVertex AI側の実行時間に依存するため、PoCでの実測なしに数字を出すのは避けましょう。

精度検証をSQLで回すためのデータ分割とハイパーパラメータ探索

DATA_SPLIT_METHODで分割方法を指定し時系列は時刻で切る

既定値はAUTO_SPLITで、行数によって挙動が異なる仕様です。500行未満なら全行を学習に使い、500行から50,000行なら20%をランダムに評価用へ回し、50,000行を超える場合は10,000行だけを評価用とします。件数が多い環境では評価データの割合が相対的に小さくなります。

明示指定はRANDOM、SEQ、NO_SPLIT、CUSTOMから選び、RANDOMとSEQではDATA_SPLIT_EVAL_FRACTIONで割合を指定できます。注意したいのが時系列性のあるデータで、ランダム分割で評価すると未来の情報が学習側に混ざり指標が実力より良く出ます。日付列を基準にSEQまたはCUSTOMで前後に切り、過去で学習して直近で評価する形にしてください。

NUM_TRIALSで探索を回しML.TRIAL_INFOで試行の結果を読む

ハイパーパラメータの調整はNUM_TRIALSの指定で起動します。探索したいパラメータに範囲を与えると、指定した試行回数のぶんだけ学習が繰り返され、最良の試行が採用されます。

費用の観点では、この機能は「学習単価50倍のクエリを試行回数ぶん走らせる」ことと同義です。全期間のデータで20試行を回す前に、直近ぶんの小さなデータで当たりを付け、範囲を絞ってから本番データで確定させる。この二段構えにするだけで検証の金額は大きく変わります。ML.TRIAL_INFOで各試行の設定と指標を控えておけば、次回の探索範囲もそこから決められるでしょう。

BigQuery MLを採用してよい条件と別の構成へ切り替える判断軸

採用してよいのはデータがBigQueryにあり定型の予測を定期実行する場面

採用してよい条件は三つそろったときです。第一に、学習に使うデータがすでにBigQueryにあること。別基盤へ移す工程が入るなら利点は半分消えます。第二に、課題が表形式データの回帰・分類・時系列・クラスタリングに収まること。第三に、推論がバッチで足り、日次または週次の更新で業務が回ること。

この条件下では、学習パイプラインのためのコンテナもワークフローエンジンも不要で、スケジュールクエリ一つで運用が完結します。SQLが書ける人材で保守できる点も、専任のデータサイエンティストを置けない組織では効いてくるでしょう。分析基盤の層構成に組み込む形は5層アーキテクチャでの分析基盤の構築手順で扱っています。

見送るべきはモデルの作り込みと低遅延のオンライン推論が要る場面

逆に見送るべき場面もはっきりしています。画像や自然言語を扱う課題、独自の損失関数やネットワーク構造を試したい課題は、SQLの表現力の外側です。ここはPythonの学習環境で組み、必要ならインポートモデルとして推論だけを持ち込む構成にしてください。

数十ミリ秒での応答が要件に入る場合も、BigQuery単体では組めません。時系列モデルはデプロイできない制約もあるため、要件定義の段階で応答時間を確認しておきましょう。Snowflake側にもデータがあるなら、SnowflakeのML関数でSQLだけで予測を実装する方法と並べ、どちらに寄せるかを先に決めたほうが無難です。

外部委託では見積書の四つの確認項目を事前に読み運用の手戻りを防ぐ

構築を外部に委託するなら、見積書で確認すべき箇所は決まっています。使用するmodel_typeが内部トレーニングか外部トレーニングか、再学習の頻度と学習データの範囲、評価指標としきい値を誰が決めるか、Model Registryへの登録とバージョン管理が納品物に含まれるか。この四点が書かれていない見積書は、運用開始後に費用と精度の責任範囲が曖昧になります。

とくに再学習の頻度は、学習単価が通常クエリの50倍である以上そのまま月額に跳ね返る項目です。機械学習モデル開発では、モデルの設計から評価設計、再学習の運用移管までを前提に構成を組んでいます。PoCから本番へ移す進め方と体制の作り方はBigQuery導入の手順と外注の判断を参照してください。

よくある質問

BigQuery MLを使うのに機械学習の知識は必要ですか？

モデルを動かすだけなら、既定の設定とCREATE MODELの構文で足ります。ただし結果を業務判断に使うなら、評価指標の読み方は必要です。とくに不均衡データでのaccuracyの扱いと、しきい値を業務の損得から決める考え方は避けて通れません。

学習のコストが想定より膨らむのを防げますか？

三点で防げます。学習データのSELECTで列を絞ること、パーティション分割された列で期間を限定すること、再学習の頻度を必要最小限にすること。内蔵モデルの学習は通常クエリの50倍の単価なので、読むバイト数を減らす対策がそのまま効きます。

作ったモデルをアプリからリアルタイムに呼べますか？

Model Registryに登録してVertex AIのエンドポイントへデプロイすれば可能です。ただしリモートモデルは登録できず、インポートしたXGBoostとARIMA_PLUS、ARIMA_PLUS_XREGは登録できてもデプロイできません。時系列の予測を即時に返す要件があるなら、バッチで予測テーブルを作って配る構成を検討してください。

Vertex AIとBigQuery MLはどちらを選ぶべきですか？

二者択一ではなく工程で分けます。表形式データの定型的な予測をバッチで回すならBigQuery ML、独自のモデル構造や低遅延の推論が要るならVertex AI。まずSQLで作り、必要が出てから向こうへ寄せる順序が扱いやすいはずです。

学習時と推論時で特徴量の作り方がずれる事故は防げますか？

TRANSFORM句を使えば構造的に防げます。標準化やバケット化をここに書いておくと定義がモデルに保存され、ML.PREDICTの実行時に同じ変換が自動で適用されるためです。推論バッチ側に前処理コードを書き写す必要がなくなり、二重管理に起因するずれが起きません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る