特売予定を、過去の売上だけで予測できるか
仮想の小売店で、翌週の商品需要を予測する場面を考えます。発注担当者は欠品と余剰在庫を減らしたいものの、過去の売上を延長するだけでは、来週の特売や関連商品の動きを十分に織り込めない場合があります。Googleも、関連商品の売上、来店客数、販促や祝日などが重なる小売予測を、複数の変数を同時に扱う多変量予測が必要となる例として挙げています1。
Google Cloudの2026年10月12日付の紹介記事は、BigQuery（Google Cloudの分析用データ基盤）で利用できるTimesFM 3.0のPreview（正式提供前の試験提供）を解説しています2。
TimesFMは、時系列データ（時間順に記録した数値）で事前学習したモデルです。BigQueryではSQL（データを検索・操作する言語）のAI.FORECASTから呼び出せるため、利用者が自社専用のモデルを作成・追加学習・管理する工程を省けます3。TimesFM 3.0は複数の商品を共同で予測し、過去の来店客数や、将来の販促予定などの補助情報も入力に使えます4。
ただし、入力を増やすだけで自社の予測精度が上がるとは限りません。特売予定は予測締切時点で用意できるものだけを渡し、履歴と予測期間の両方に行をそろえます。本稿では、その入力条件と比較・評価の進め方を整理します。
既存手法との違いは、入力と学習の持ち方
BigQueryのTimesFM 2.5によるAI.FORECASTは、各系列（商品など一つの対象の時間順データ）の履歴から一つのターゲットを予測する単変量、つまり一つの予測対象を扱う方式です5。店舗IDなどで複数の系列を指定できることと、関連商品のターゲットを共同で予測することは別です。
外部要因を扱う既存の選択肢には、ARIMA_PLUS_XREGがあります。これは時間に沿う変化を予測するモデルに、線形回帰の説明変数（予測に使う要因）を組み合わせる方式です。線形回帰は、説明変数の重み付き和で目的値を見積もります。過去の特徴量（モデルへ入力する項目）で学習し、予測時には将来の特徴量を渡します6。系列ごとのモデル訓練が必要な点は、事前学習済みのTimesFMと異なります7。
TimesFM 3.0では、未来値が分からない過去専用の共変量（予測対象を補助する説明変数）も、履歴と予測期間の両方で値を用意できる未来共変量も扱えます4。
| 方式 | 利用者による追加学習 | 予測対象と補助入力 |
|---|---|---|
| TimesFM 2.5のBigQuery機能 | 不要 | 各系列の単一ターゲットの履歴 |
| ARIMA_PLUS_XREG | 系列ごとの訓練が必要 | 単一ターゲットと説明変数。予測時にも将来の特徴値を用意 |
| TimesFM 3.0 Preview | 不要 | 単一または複数ターゲット、過去専用・既知の未来共変量 |
この比較のTimesFM 2.5はBigQueryの機能を指します。Python側の補助機能まで含めて「3.0以前は共変量を使えなかった」と括りません。
複数系列の指定では、TARGET_COLSとID_COLSも区別します。前者は同じ店舗・時刻で共同予測する商品Aと商品Bなどの列、後者は店舗ごとに行を分ける識別子です。両方を併用できます8。店舗IDを増やすだけで、ターゲット同士の共同予測になるわけではありません。
時間方向と変数方向を交互に見る仕組み
TimesFM 3.0は、注意機構（アテンション）を二つの方向へ交互に適用します。注意機構は、入力のどの部分を重視するかを計算する仕組みです。時間方向では同じ系列の過去を参照し、変数方向では同時刻の他の系列を参照します9。商品ごとの時間的な推移と、商品間の関係の両方を扱う構造です。
予測期間では、未来のターゲットと過去専用共変量をマスクし、未知の値を見せません。一方、既知の未来共変量は、未来区間を含む先読みトークン（モデルが参照する情報のまとまり）として見せます。モデルはその情報を使い、一回の順伝播、つまりモデルを一度通す計算で、予測区間全体をまとめて出力します10。
時間方向の「causal」は、後の時点を参照させない計算上の制約です。この予測値だけを、販促による売上の純増の証拠として扱わないようにします。利用者はSQL結合や評価データの締切を点検し、入力作成時の未来情報の混入を防ぐ方針を取ります。
後輩販促予定を入れて予測値が上がれば、販促の効果が証明されたのでしょうか。
先輩予測値の差だけから、販促による純増とは判断できないよ。需要を予測する目的と、施策の因果効果を調べる目的を分けよう。
日次の64日分の履歴と、7日分の予定を用意する
ここからは、店舗ごとに商品Aと商品Bの翌週需要を予測する仮想例です。日次で等間隔、欠損のない64日分の履歴と、その後7日分の予定行を、一つの入力テーブルへまとめます。64日と7日はこの例の設定値で、すべての業務に適した長さという意味ではありません。
公式仕様では、履歴行のタイムスタンプ（日時を示す値）、ターゲット、過去専用共変量は非NULL（値がある状態）にします。未来行では、ターゲットと過去専用共変量をNULL（値が未知の状態）にし、タイムスタンプと既知の未来共変量に値を入れます11。未来共変量を使う場合、入力は履歴点数CONTEXT_WINDOWと予測点数HORIZONを合わせた全期間をカバーする必要があります12。
| 列 | 履歴64日 | 予測7日 |
|---|---|---|
date、store_id | 日付・店舗ID | 日付・店舗ID |
| 商品A・Bの売上 | 実績値 | NULL |
historical_traffic | 過去の来店客数 | NULL |
| 販促予定・祝日 | 履歴期間の情報 | 締切時点で用意した予定・カレンダー情報 |
この例の販促と祝日のフラグは、0または1の数値列で用意します。
未来共変量の「既知」は、予測時点で入力を用意できるという意味です。予定の実現や予報の的中を保証する意味ではありません。販促の変更や予報誤差も評価に含めます。後から判明した実際の天気、売上、来店客数を、当時の未来入力へ戻し入れません。
SQLの既定モデルはTimesFM 2.5なので、3.0を使うにはMODEL => 'TimesFM 3.0'を明示します。タイムスタンプにはTIMESTAMP、DATE、DATETIME型を使えます13。次は公式構文に照合した、未実行の構成例です。
SELECT *
FROM AI.FORECAST(
TABLE `project.dataset.store_demand_input`,
MODEL => 'TimesFM 3.0',
TARGET_COLS => ['sales_item_a', 'sales_item_b'],
ID_COLS => ['store_id'],
TIMESTAMP_COL => 'date',
HORIZON => 7,
CONTEXT_WINDOW => 64,
PAST_COVARIATE_COLS => ['historical_traffic'],
FUTURE_COVARIATE_COLS => ['is_promotion_planned', 'is_holiday']
);
HORIZONはデータ点数です。この例は日次なので7点が7日に対応します13。店舗ごとに、履歴と予測期間の全71行で未来共変量を準備します。
後輩過去の検証で、後から確定した販促計画を使ってもよいですか。
先輩その締切で持っていた計画を再現しよう。実績や修正後の計画を混ぜると、本番では得られない情報で評価することになるよ。
本稿の運用案：同じ締切で比較する
ここからは、サービスが自動で実施する機能ではなく、本稿が提案する評価手順です。まず過去の締切を複数設定し、それぞれ当時の履歴と予定だけで予測します。予測後の実績は検証用に留保し、商品・店舗・予測ステップ別に照合します。締切をずらして繰り返す評価が、rolling-origin評価です。
比較基準には、各商品の7日前の売上をそのまま予測値とする方法を置きます。TimesFM 2.5、ARIMA_PLUS_XREG、TimesFM 3.0も、共通する売上履歴と評価期間をそろえ、各方式が受け取れる説明変数を記録して比較します。平均だけでなく、販促のある週とない週、売上の小さい商品も分け、どこで改善・悪化するかを確認します。
誤差は、例えば予測と実績の差の絶対値を平均するMAEで集計します。売上数量と同じ単位で読めるため、発注判断へつなげやすくなります。MAPEは、誤差を実績値で割る割合の指標です。予測精度の一次解説は、実績ゼロでは未定義または無限大になり、ゼロに近い値でも極端な割合になり得ると説明しています。誤差が残る場合、実績がゼロに近いほど割合が大きくなり得る点を確認します。この例ではMAPEだけで判断せず、数量の誤差と欠品・余剰在庫への影響を併せて見ます。
予測区間は、実績が区間に収まった割合と区間幅の両方を見ます。幅を広げただけの区間を高精度と判断しないためです。公開ベンチマークの順位や、自社で未実施の数値結果を、この運用の精度保証には使いません。
公式紹介のAI.EVALUATEの説明は単変量評価を扱っています2。多変量の全ターゲットや未来共変量、区間の評価が一括で済むと想定せず、この例ではAI.FORECASTの結果と留保した実績を比較します。適用範囲は公式AI.EVALUATE仕様を確認します。
制約、契約、費用を採用判断に含める
TimesFM 3.0のCONTEXT_WINDOWは32点刻みの64〜2,048点です。各系列には最低3点の履歴が必要という条件もあります14。HORIZONは1〜1,024点、既定値は10点です15。短い試験例の設定と、サービスの許容範囲を区別します。
モデル内部の系列ごとの正規化は、数値のスケールを調整する処理です。欠損補完や時刻の再サンプリング（一定の間隔にそろえ直す処理）をBigQueryが自動で代行するという根拠にはなりません16。本稿の例では、入力の間隔、欠損、重複時刻を前処理で確認する方針を取ります。
内蔵TimesFMはBigQuery MLがサポートするロケーションで利用できます17。ただしTimesFM 3.0はPreviewです18。Google CloudのPre-GA（一般提供前）条項は、変更・停止の可能性を示しています。SLA（サービス水準の保証）の対象外という条件もあります。また、明示的な書面や公式文書の例外がない限り、データ処理条項やデータ所在地の扱いも通常と異なり、個人情報や規制対象データを処理しないよう求めています19。これは当該Previewの条件で、BigQuery全体の契約条件を一律に取り消す意味ではありません。本稿の例は個人情報を使わない架空の集計需要です。
BigQuery経由のTimesFM利用はCloudの契約条件で商用利用が認められています20。一方、自分で取得した3.0の重み（学習で決まった数値パラメータ）はTimesFM Non-Commercial License v1.0で、非商用かつ非本番の利用に限定されます。コード用ライセンスだけを見て、重みも同じ条件だと判断しません。
費用は、2026年10月13日に公式SQL仕様のPricingを確認しました。Preview中は、Enterprise / Enterprise Plusではスロット（BigQueryの計算資源）に基づき、オンデマンドでは処理バイト数に基づいて課金されます13。
2026年12月1日からは、モデルが消費したトークンと、残りのクエリ部分のスロットまたは処理バイト数を組み合わせる課金へ移行する予定です13。
この関数を呼び出すための自社専用モデルの追加学習は不要です。採用前に公式SQL仕様のPricingで、利用するエディションと実行時点の適用条件を確認します。予測の誤差、入力を準備する負荷、実行費用を合わせて判断します。
