2026.10.14 AI

TimesFMとは：BigQueryのAI.FORECASTで試す時系列予測とTimesFM 3.0の多変量・共変量【2026年10月時点】

Q: 何点くらいの履歴があれば予測できますか？

AI.FORECAST が動く最小のデータ点数は3です。ただし、これは計算できる下限であって、精度の目安ではありません。週ごとの曜日の波を拾わせたい日次データなら、少なくとも数か月分は渡します。TimesFM 3.0が読む上限は2,048点、2.5は15,360点で、それより古いデータは予測に使われない仕様です。長すぎる細かい粒度のデータは、集計して点数を減らしてから渡します。

Q: TimesFMで販促や天気などの外部要因を予測に入れられますか？

TimesFM 3.0なら可能です。販促の予定や週末フラグのように先の値が分かっている要因は future_covariate_cols 、アクセス数のように過去にしか値が無い要因は past_covariate_cols に指定します。未来の要因は、予測したい期間の行にも値を埋めておくのが条件です。2.5の場合、BigQueryの AI.FORECAST では共変量を指定できず、Pythonパッケージ側のXRegを使います。

TimesFMとは：BigQueryのAI.FORECASTで試す時系列予測とTimesFM 3.0の多変量・共変量【2026年10月時点】

TimesFMは、Google Researchが公開している時系列予測の基盤モデルです。売上や来客数の過去データを渡すだけで、学習の工程を挟まずに先の値と予測区間を返します。2026年10月13日には、複数の系列と外部要因を同時に扱えるTimesFM 3.0がBigQueryでプレビュー提供されました。この記事では、版ごとの違いとライセンスの線引きを一次情報で確かめたうえで、BigQueryのAI.FORECASTをSQLで動かす手順、Pythonでの実行、精度の測り方とProphetとの使い分けをコード付きで説明します。

まとめ：TimesFMは学習不要の時系列基盤モデルで本番はBigQuery経由が前提

TimesFMを試すなら、BigQueryのAI.FORECASTから始めるのが近道です。CREATE MODELが要らず、テーブルと列名を渡す1本のSQLで予測が出ます。

注意点はライセンスです。最新のTimesFM 3.0の事前学習済み重みは非商用・非本番に限られ、自社のサーバーへダウンロードして業務で動かすことはできません。3.0を業務で使うならBigQuery ML経由、自前でホストするならApache-2.0のTimesFM 2.5まで、と分けて考えます。

精度はAI.EVALUATEで直近の実績と突き合わせて判断します。祝日や販促の効果を説明する必要がある予測はProphetやARIMA_PLUSを残し、系列が多く個別に調整しきれない予測をTimesFMへ寄せるのが現実的な分担です。

TimesFMの仕組みと2.5・3.0の版ごとのパラメータ数と対応範囲

TimesFMの論文はICML 2024で発表され、コードはGitHubのgoogle-research/timesfmで公開されています。2026年10月時点の最新版は3.0です。

デコーダーのみのTransformerで学習なしに予測するゼロショットの仕組み

TimesFMは、大量の時系列で事前に学習したデコーダーのみのTransformerです。系列を32時点ずつの「パッチ」に区切って読み込み、続きのパッチを出力します。文章の続きを予測する言語モデルと同じ考え方を、数値の列に当てはめた構成です。

利用者は自社データで学習させる必要がありません。これをゼロショット予測と呼びます。Google Researchの3.0の発表記事によると、事前学習には実データと合成データを合わせて1兆時点を超える系列が使われています。出力は点予測に加え、10%から90%までの9つの分位点です。

TimesFM 2.5と3.0の違いを比較表で確認するパラメータ数と共変量

項目	TimesFM 2.5	TimesFM 3.0
公開	2025年9月	2026年8月
パラメータ数	2億	3億3,000万
予測対象	単変量のみ	単変量と多変量
共変量	XRegで後付け対応	過去のみ・過去と未来の両方に標準対応
重みのライセンス	Apache-2.0	非商用ライセンス
BigQueryでの扱い	AI.FORECASTの既定モデル	プレビュー

数値はGitHubのREADMEと発表記事の記載です。3.0は、関連する複数の系列をまとめて読み、系列どうしの関係も予測に使える点が2.5との最大の差です。READMEによると、3.0はfev-benchとTIMEの2つのベンチマークで総合1位、GIFT-Evalで基盤モデル中の1位とされています。

TimesFM 3.0の重みは非商用ライセンスで本番はBigQuery経由になる理由

Hugging Faceの3.0のモデルカードには、ライセンスとしてtimesfm-non-commercial-license-v1.0が指定されています。READMEも、ダウンロードした3.0の重みを商用・本番で使うことは認めていません。

一方で、BigQuery MLなどGoogle Cloudの正規のサービスを通す場合は、Google Cloudの利用規約のもとで商用利用できると明記されています。ソースコードと2.5までの重みはApache-2.0のままです。業務システムに組み込む前提なら、使える経路は「BigQueryで3.0」か「自前ホストで2.5」の2つに絞られます。

AI.FORECASTでTimesFMの単変量予測をSQLだけで実行する手順

BigQueryのTimesFMの概要ページによると、TimesFMはBigQueryの全リージョンで使え、モデルの作成や管理は不要です。

AI.FORECASTで商品別の日次売上を30日先まで予測するSQL

商品ごとの日次売上を持つテーブルがあるとします。id_colsに商品IDを渡すと、商品の数だけ系列を分けて一度に予測します。

-- 商品別の日次売上を30日先まで予測する
WITH daily AS (
  SELECT
    DATE(ordered_at) AS sales_date,
    product_id,
    SUM(quantity) AS units_sold
  FROM `myproject.sales.orders`
  WHERE ordered_at >= '2025-10-01'
  GROUP BY sales_date, product_id
)
SELECT
  product_id,
  forecast_timestamp,
  forecast_value,
  prediction_interval_lower_bound,
  prediction_interval_upper_bound,
  ai_forecast_status
FROM AI.FORECAST(
  TABLE daily,
  data_col => 'units_sold',
  timestamp_col => 'sales_date',
  id_cols => ['product_id'],
  horizon => 30
);

modelを省略すると、単変量ではTimesFM 2.5が使われます。forecast_valueは分位点の50%、つまり中央値です。ai_forecast_statusが空なら成功で、データ点が3つ未満の系列には「The time series data is too short.」が入ります。過去の実績も同じ表に並べてグラフにしたいときは、output_historical_time_series => TRUEを足します。

欠損日がある系列は、先に日付を埋めてから渡すと結果が安定します。補間の方法は時系列データの前処理と欠損補間の手順にまとめています。

horizonとcontext_windowの既定値と2.5・3.0で異なる上限

AI.FORECASTのリファレンスに載っている上限は、モデルによって大きく違います。

引数	TimesFM 2.5	TimesFM 3.0
horizon	1〜10,000（既定10）	1〜1,024（既定10）
context_window	64〜15,360の9段階	32の倍数で64〜2,048（既定2,048）
読み込む最大点数	15,360	2,048
confidence_level	既定0.95	既定0.95

実務で効くのは読み込む点数の差です。日次データなら、2.5は約42年分、3.0は約5年半分を文脈として読めます。分単位のセンサー値を長期間渡すと、3.0では直近の2,048点だけが使われ、それより前は使われない仕組みです。長い履歴が効く系列は、日次や時間単位に集計してから渡します。

TimesFM 3.0の多変量予測と過去・未来の共変量をSQLで渡す書き方

多変量予測はmodel => 'TimesFM 3.0'の指定が必須で、2026年10月時点ではプレビューです。

予測期間の行に未来共変量だけを埋めてtargetをNULLにする入力表

共変量は2種類あります。過去にしか値が無い「過去共変量」と、販促の予定や週末フラグのように先の値も分かっている「未来共変量」です。Google Cloudの発表記事の例を、受注データに置き換えると次の形になります。

-- 予測期間（2026-11-01以降）の行は、予測対象と過去共変量をNULLにする
WITH data AS (
  SELECT
    c.dt,
    IF(c.dt < '2026-11-01', s.web_orders, NULL)   AS web_orders,
    IF(c.dt < '2026-11-01', s.store_orders, NULL) AS store_orders,
    IF(c.dt < '2026-11-01', s.sessions, NULL)     AS sessions,       -- 過去共変量
    IF(c.promo_flag, 1.0, 0.0)                     AS is_promo,       -- 未来共変量
    IF(EXTRACT(DAYOFWEEK FROM c.dt) IN (1, 7), 1.0, 0.0) AS is_weekend -- 未来共変量
  FROM `myproject.sales.calendar` AS c
  LEFT JOIN `myproject.sales.daily_summary` AS s USING (dt)
  WHERE c.dt BETWEEN '2025-11-01' AND '2026-11-14'
)
SELECT *
FROM AI.FORECAST(
  TABLE data,
  model => 'TimesFM 3.0',
  timestamp_col => 'dt',
  target_cols => ['web_orders', 'store_orders'],
  past_covariate_cols => ['sessions'],
  future_covariate_cols => ['is_promo', 'is_weekend']
);

要点は、予測したい期間の行もあらかじめ表に入れておくことです。その行では予測対象と過去共変量をNULLにし、未来共変量だけを埋めます。未来共変量の列はcontext_windowとhorizonを足した長さの値を持つ必要がある、というのがリファレンスの記載です。販促カレンダーのような日付の台帳を軸にLEFT JOINすると、この形を作りやすくなります。

target_colsで複数系列を同時に予測しSTRUCTの結果を展開するクエリ

多変量の出力は、予測対象の列ごとにSTRUCTで返ります。中身はvalue、prediction_interval_lower_bound、prediction_interval_upper_boundの3つです。BIツールへ渡すときは、次のように列へ展開します。

SELECT
  FORMAT_DATE('%Y-%m-%d', dt) AS forecast_date,
  web_orders.value                           AS web_orders,
  web_orders.prediction_interval_lower_bound AS web_lb,
  web_orders.prediction_interval_upper_bound AS web_ub,
  store_orders.value                         AS store_orders
FROM AI.FORECAST(
  TABLE `myproject.sales.forecast_input`,
  model => 'TimesFM 3.0',
  timestamp_col => 'dt',
  target_cols => ['web_orders', 'store_orders'],
  horizon => 14
);

複数の店舗や商品を別々の系列として扱いたい場合は、ここにid_colsを足します。target_colsはひとつの系列の中で連動する指標、id_colsは互いに独立した系列、と覚えておくと使い分けを誤りません。

PythonのtimesfmパッケージでTimesFMを手元のGPUやMacで動かす手順

BigQueryを使わない検証環境では、Pythonのパッケージで同じモデルを動かせます。PyPIの最新は2026年10月14日時点で3.0.2、対応はPython 3.10以上です。

pip installとpredict_batchで12ステップ先を予測する最小コード

pip install "timesfm[torch]"
# Apple siliconでPyTorchを使わない場合
pip install "timesfm[mlx]"

READMEに載っている3.0の単変量予測は次のとおりです。長さの違う2つの系列を、まとめて12ステップ先まで予測します。

import numpy as np
from timesfm3 import TimesFM3Evaluator, ModelConfig

config = ModelConfig(
    checkpoint_path="google/timesfm-3.0-pytorch",
    per_core_batch_size=32,
    device="cuda",
)
forecaster = TimesFM3Evaluator(config)

ts1 = np.linspace(0, 1, 100).astype(np.float32)
ts2 = np.sin(np.linspace(0, 24, 72)).astype(np.float32)

outputs = list(forecaster.predict_batch(
    [ts1, ts2], horizon=12, return_quantiles=True, use_symmetric_averaging=False
))
print(outputs[0].forecast.shape)   # (12,)
print(outputs[0].quantiles.shape)  # (12, 9)

Apple siliconではfrom timesfm3.mlx import TimesFM3ForecasterからTimesFM3Forecaster.from_pretrained("google/timesfm-3.0-pytorch")で読み込めます。READMEの計測では、M4 Max・文脈512点・予測64点で、1系列あたり11.1ミリ秒です。共変量はpredict_batchのpast_only_covariatesとpast_future_covariatesに配列で渡します。

自前ホストで商用に使えるのはApache-2.0のTimesFM 2.5までという制約

このコードが読み込むgoogle/timesfm-3.0-pytorchは、前章のとおり非商用ライセンスです。社内の検証やモデル比較には使えますが、業務システムの予測処理として常時動かすことはできません。

自社のサーバーやコンテナで商用に動かすなら、Apache-2.0の2.5を選びます。2.5は文脈16,000点・予測1,000点まで扱え、2025年10月の更新でXRegによる共変量にも対応しました。多変量や3.0の精度が必要なら、BigQueryのSQLから呼び出す構成に切り替えます。どちらを選んでも、予測結果をどの業務画面へ返すかの設計は同じです。

AI.EVALUATEで精度を測りProphet・ARIMA_PLUSと使い分ける判断基準

基盤モデルは学習しない分、自社データで当たるかどうかを先に測る必要があります。

直近の実績を切り出してAI.EVALUATEで誤差を測る検証クエリ

AI.EVALUATEのリファレンスの形に合わせ、1つ目の引数に過去、2つ目に答え合わせ用の実績を渡します。

WITH daily AS (
  SELECT DATE(ordered_at) AS sales_date, product_id, SUM(quantity) AS units_sold
  FROM `myproject.sales.orders`
  GROUP BY sales_date, product_id
)
SELECT *
FROM AI.EVALUATE(
  (SELECT * FROM daily WHERE sales_date <  '2026-09-01'),
  (SELECT * FROM daily WHERE sales_date >= '2026-09-01'),
  data_col => 'units_sold',
  timestamp_col => 'sales_date',
  id_cols => ['product_id']
);

結果には、商品ごとにMAE・RMSE・MAPE・sMAPE・MASEの5つの誤差が並びます。見るべきはMASEです。前の時点の値をそのまま使う単純な予測と比べた比率で、1を下回ればそれより当たっています。model => 'TimesFM 3.0'を足して同じクエリを流せば、2.5と3.0の差も同じ表で比較可能です。急な落ち込みを見つけたい用途は、同じ系列でAI.DETECT_ANOMALIESを使います。しきい値の考え方は時系列データの異常検知の手法と運用が参考になります。

TimesFMを採用する場面とProphet・ARIMA_PLUSを残す場面の線引き

条件	向く手段
系列が数百〜数万あり、個別に調整できない	TimesFM（AI.FORECAST）
履歴が短い新商品・新店舗	TimesFM
祝日や販促の効果量を説明する必要がある	Prophet・ARIMA_PLUS_XREG
季節性や変化点を細かく調整したい	ARIMA_PLUS・Prophet
BigQuery外で3.0を商用に動かしたい	採用しない（ライセンス上不可）

TimesFMが弱いのは「なぜその値になったか」の説明です。分解した傾向や祝日効果を会議資料に載せたいなら、Prophetの仕組みと使い方や、BigQuery上で完結するBigQuery MLのARIMA_PLUSを残します。逆に、全商品の発注量を毎日出すような用途では、モデルの数だけ学習と保守が発生する従来手法よりTimesFMのほうが運用が軽くなります。

実務では、まずAI.EVALUATEで既存の予測とTimesFMのMASEを並べ、差が小さい系列から置き換えていけば十分です。予測を発注や人員配置の業務画面にどう組み込むかまで含めて検討する場合は、AI予測分析開発・需要予測開発で対応範囲を確認できます。

2026年12月からのトークン課金とプレビュー段階を踏まえた本番投入の時期

料金の根拠はリファレンスの記載です。プレビュー中のTimesFM 3.0は、オンデマンドならスキャンしたバイト数、Enterprise以上のエディションならスロットで課金されます。2026年12月1日からは、これに3.0のトークン数に応じた課金が加わります。単価は10月14日時点で未公表です。BigQuery自体の課金の分岐はBigQueryのオンデマンドとEditionsの比較で確認できます。

3.0の多変量予測は、プレビューのため提供条件が変わる可能性があります。本番の発注処理を3.0の多変量に依存させるのは、GAとトークン単価の公表を待ってからにします。それまでは単変量の2.5で本番を組み、3.0はAI.EVALUATEでの比較に使う、という段階分けが安全です。

TimesFMとBigQueryのAI.FORECASTについてよくある質問

2026年10月14日時点の公式ドキュメントをもとに答えます。

TimesFMは無料で使えますか？

ソースコードとTimesFM 2.5までの重みはApache-2.0で、無料で商用にも使えます。TimesFM 3.0の重みも無料でダウンロードできますが、使えるのは非商用・非本番の用途だけです。BigQueryのAI.FORECASTから使う場合は、BigQueryのクエリ料金がかかり、2026年12月1日からは3.0のトークン数に応じた課金も加わります。BigQueryのサンドボックスや無料枠で試すときは、スキャン量の上限を超えないよう入力を絞ってください。

TimesFMとProphetの違いは何ですか？

Prophetは、系列ごとにトレンド・季節性・祝日効果を学習して当てはめるライブラリです。成分に分けて説明できる反面、系列の数だけ学習が要ります。TimesFMは事前学習済みのモデルなので、自社データでの学習は不要です。系列が多い場合や履歴が短い場合はTimesFM、予測の理由を説明したい場合はProphetが向きます。どちらが当たるかは、自社データで誤差を比べて決めます。

TimesFM 3.0はどこで使えますか？

商用・本番で使えるのは、BigQuery MLなどGoogle Cloudの正規のサービス経由です。BigQueryではAI.FORECAST、AI.DETECT_ANOMALIES、AI.EVALUATEのmodelに'TimesFM 3.0'を指定します。GitHubのREADMEは、BigQuery ML以外のGoogle製品としてGoogle スプレッドシートのコネクテッドシートとVertex AIのModel Gardenも挙げていますが、そちらで使える版は明記されていません。Hugging Faceの重みを自前で動かすのは、検証用途に限られます。

何点くらいの履歴があれば予測できますか？

AI.FORECASTが動く最小のデータ点数は3です。ただし、これは計算できる下限であって、精度の目安ではありません。週ごとの曜日の波を拾わせたい日次データなら、少なくとも数か月分は渡します。TimesFM 3.0が読む上限は2,048点、2.5は15,360点で、それより古いデータは予測に使われない仕様です。長すぎる細かい粒度のデータは、集計して点数を減らしてから渡します。

TimesFMで販促や天気などの外部要因を予測に入れられますか？

TimesFM 3.0なら可能です。販促の予定や週末フラグのように先の値が分かっている要因はfuture_covariate_cols、アクセス数のように過去にしか値が無い要因はpast_covariate_colsに指定します。未来の要因は、予測したい期間の行にも値を埋めておくのが条件です。2.5の場合、BigQueryのAI.FORECASTでは共変量を指定できず、Pythonパッケージ側のXRegを使います。