売上予測をLLMに聞いても当たらない｜TimesFM 3.0が実務に効く場面と、本番投入を止めるライセンスの線引き

来月の売上見込みをChatGPTやClaudeに貼り付けて聞いてみた、という話をよく聞きます。もっともらしい数字と、もっともらしい理由が返ってきます。ただ、実際に月が明けてから答え合わせをすると、当たっていないことのほうが多いはずです。

2026年8月31日、Google Researchが時系列基盤モデルの新版TimesFM 3.0(公式ブログの表記はTimesFM-3、公開チェックポイント名はtimesfm-3.0)を発表しました。これはチャット型のLLMではなく、数値の系列だけを入力して先の値を出すことに特化した別種の基盤モデルです。今回の版で多変量と共変量に正式対応しました。

当メディアではこれまでチャット型LLMの新モデルを業務目線で検証してきましたが、今回扱うのはその系譜ではありません。文章を書かず、数値の系列だけを扱う基盤モデルという別カテゴリの道具です。したがって「どのLLMを選ぶか」ではなく「そもそもこの仕事をLLMに任せるべきか」という前段の判断が論点になります。

一方で、この記事でいちばん伝えたいのはモデルの性能ではありません。事前学習済みの重みが非商用・非本番利用に限定されている、という点です。ライセンス原文を読むと、検証はできるが本番には入れられない、という線が明確に引かれています。ここを見落としたまま社内PoCを走らせると、成果物の行き場がなくなります。

チャット型LLMに数値予測をやらせても当たらない理由#

まず、道具の性質の違いを押さえます。以下は道具の設計上の性質からの整理で、特定の測定結果にもとづくものではありません。

チャット型のLLMは、テキストをトークンに分けて次に来るトークンの確率を予測します。数値を渡すと、数値も文字列としてトークン化されます。桁の区切り方はモデルの語彙に依存し、系列としての周期性や水準感がそのまま保たれる保証はありません。加えて、出力は言語としてもっともらしい方向へ引っ張られます。「先月より少し伸びる」という文脈が作られれば、その文脈に整合する数字が出ます。言語として自然な出力を返す設計の道具であることを踏まえると、数値の当否が第一の最適化対象ではない、と考えると分かりやすいはずです。

もう一つの問題は再現性です。サンプリングの設定やモデル側の更新によって、同じ表を渡しても違う数字が返ってくることがあります。モデルのバージョンを固定し、温度を0にするといった手当てをすれば出力は揃えやすくなりますが、業務の現場でチャット画面にそのまま貼り付けている使い方では、その条件は満たされていません。予測を業務プロセスに組み込む場合、数字が動くこと自体より、動いた理由を説明できないことのほうが困ります。

これは失敗談としてよく聞く形です。そして重要なのは、比較対象を置いたからこそ「当たっていない」と分かった、という点です。比較対象がないと、それらしい数字はそのまま通ります。

時系列基盤モデルは、この土俵を最初から変えます。入力は数値の系列そのもので、出力は各時点の予測値と分位点です。文章を書く能力はありません。代わりに、系列の水準・周期・トレンドを扱う前提で設計されています。

TimesFM 3.0で確認できたこと#

公式ブログ、GitHubのREADME、Hugging Faceのモデルカードとconfig.jsonから確認できた事実を整理します。

過去のTimesFMは2.5まで単変量専用で、共変量は外部回帰(XReg)を後付けする形でした。3.0では、複数系列と共変量を同じモデルの入力として扱う設計に変わっています。

実務に引き寄せると、この2種類の共変量の区別が効きます。来店客数や関連商品の販売数は、予測時点では過去の値しか手元にありません。これが過去のみ既知の共変量です。一方、販促キャンペーンの実施日、祝日カレンダー、数日先までの天気予報は、未来の値が先に分かっています。これが未来まで既知の共変量です。

公式ブログはアイスクリームの販売数を例に、販促スケジュールを未来まで既知の共変量として渡した場合、単変量モデルが捉えられない販促日の売上増を予測が織り込む様子を示しています。販促のたびに実績が跳ねるカレンダーを持っている業務では、この差が効く場面があります。

もう一つ、地味ですが設計段階で効いてくる数字があります。config.jsonのmax_variatesが32であることです。ただし、ここで数えられるvariateは対象系列だけではありません。公開されている推論コードでは、対象系列・過去のみ既知の共変量・未来まで既知の共変量を連結したものがvariate次元になっているため、32はこの3種類の合計に対する枠と読むのが自然です。

なおmax_variatesは、公開コードの中で入力数を検証したり切り詰めたりしている値ではなく、事前学習時の設定値として置かれているものです。ハードな上限だと断定はできませんが、数百SKUを一度に並べる使い方は想定されていないと読めます。系列をどうグルーピングするかを先に考えておいてください。

ゼロショットで動く、が「何もしなくていい」ではない#

TimesFMは、対象業務のデータでファインチューニングしなくても予測を出せます。これは導入のハードルを大きく下げます。学習パイプラインも、GPUでの訓練も、ハイパーパラメータ探索も不要です。

ただし、前処理と検証設計は残ります。むしろ、学習の工程がない分だけ、そこにしか手を入れられません。

• 欠測の扱い(欠測日を0で埋めるのか、そもそも行がないのか)は結果を大きく変えます。売上0の日と、データが取れていない日は別です
• 粒度の決定(日次か週次か)は予測の当たり方を左右します。ノイズの多い日次をそのまま入れて外れる場合、週次に集約したほうが実務の意思決定にも合うことがあります
• 系列の切り方(店舗別か、商品別か、その掛け合わせか)によって、多変量にする意味があるかどうかが変わります
• 履歴の長さが足りない系列(新商品、新店舗)は、そもそもどの手法でも厳しい領域です
• 株価や為替のように、過去の系列から先の値を当てること自体が原理的に難しい領域は、モデルを変えても解決しません。この記事が想定しているのは、販売数・来店客数・トラフィックのように反復的な構造があるデータです

ゼロショットが省いてくれるのは学習であって、データ整理ではありません。ここは従来の予測業務と変わりません。

ベンチマークの読み方#

公式ブログとREADMEは、GIFT-Eval、fev-bench、TIMEの3つのベンチマークで、点予測と確率予測の両方の指標において、事前学習済み基盤モデルの中で最上位だと述べています。READMEはfev-benchで100タスク横断の総合1位、TIMEで50ドメインデータセット・98評価タスク横断の総合1位、GIFT-Evalで基盤モデル中1位と記載しています。

この数字を社内資料に転記する前に、3点を確認してください。

第1に、これは開発元による自己申告です。ベンチマーク自体は第三者が運用しているものですが、順位の主張はGoogleの発表に基づきます。fev-benchのリーダーボードはHugging Face Spacesで公開され、モデルが追加されるたびに順位が動きます。「現在1位」ではなく「発表時点で開発元が1位と述べている」と書くのが正確です。

第2に、比較対象の範囲です。「事前学習済み基盤モデルの中で」という限定が付いています。個別タスクに合わせて調整した統計モデルや、業務データで訓練した専用モデルとの比較ではありません。

第3に、ベンチマークの平均順位は、あなたのデータでの当たり方を保証しません。これは他のどのモデル比較でも同じですが、時系列では特に効きます。系列の性質(季節性の強さ、イベント依存、スパース性)によって、得意不得意がはっきり分かれるためです。

本番に入れられない、というライセンスの線#

ここが本題です。Hugging Faceのモデルカードは、ライセンス名をtimesfm-non-commercial-license-v1.0と明示しています。GitHubのREADMEにも、リポジトリのコードはApache-2.0、2.5までの重みもApache-2.0のままだが、3.0の重みは別ライセンスで非商用・非本番に限定される、という注記が入っています。この注記は「for the time being(当面のところ)」という留保付きの書き方で、恒久的な条件として宣言されているわけではありません。裏を返せば、以下の線引きは時点の情報として扱う必要があります。

ライセンス原文で確認できる主な点は次のとおりです。

この設計は、モデルの良し悪しとは別の話です。適用範囲の条項が「このライセンスはモデルをダウンロードする個人・法人にのみ適用され、APIを通じてアクセスする顧客には別の条件が適用される場合がある」と書き分けていることを踏まえると、Googleは研究・評価のための重み公開と、商用提供のチャネル(後述するBigQuery側)を意図的に分けている、と読めます。ただ、利用者側の意思決定としては「精度が良いから使う」で完結せず、「どのチャネルから使うか」が先に来ます。

なお、前版までとの差分は明確です。google/timesfm-2.5-200m-pytorchのモデルカードはライセンスをapache-2.0と表記しており、READMEの注記も2.5までの重みはApache-2.0のままだと明言しています。3.0で初めて、重みのライセンスが分かれました。

商用でやるなら何を選ぶか#

一次情報で確認できた範囲で、選択肢を整理します。

BigQuery MLのTimesFMは、AI.FORECASTのほか、異常検知のAI.DETECT_ANOMALIES、予測値と実績の突き合わせに使うAI.EVALUATEからも利用できると公式ドキュメントに記載があります。SQLだけで予測を出せるため、データがすでにBigQueryにあるチームには入口として現実的です。さらに、2026年2月にはConnected Sheets経由でBigQuery MLのTimesFMによる予測をスプレッドシートから実行できる機能が案内されており、SQLもPythonも書かずに試す道も用意されています。なお、このドキュメントは組み込みTimesFMを「単変量モデル」と呼んでおり、組み込みTimesFM側に共変量を渡す記述はありません。そのうえで「TimesFMより多くのチューニングの選択肢が欲しい場合はARIMA_PLUSまたはARIMA_PLUS_XREGを作成して使う」と案内しています。ARIMA_PLUS_XREGは外部回帰(共変量)に対応したモデルなので、共変量が要る用途はそちらへ寄せる構成になっている、と読めます。ただしこれは記載の並びからの編集部の解釈で、原文が明示的にそう述べているわけではありません。

SQLの外に出る経路もあります。AlloyDB for PostgreSQLの公式ドキュメントは、時系列予測の手順としてTimesFMをModel Gardenからエンドポイントへデプロイし、データベース側のai.forecast関数から呼ぶ流れを説明しています。同ドキュメントはTimesFMのバージョンとして1.0・2.0・2.5を挙げていますが、実際の手順では、Model GardenのResource IDのドロップダウンでgoogle/timesfm-2.0を選ぶよう指示されています。手動でデプロイする場合も、Model Gardenのモデルカードから開くTimesFM 2.0向けのColab Enterpriseのリンクをたどる流れです。BigQuery以外のデータ基盤を使っているチームには、この経路のほうが現実的な入口になる場合があります。なお、GoogleCloudPlatform/vertex-ai-samplesにも同種のデプロイ用ノートブックが置かれていますが、そちらはnotebooks/community/配下のコミュニティ提供で、見出しは「Vertex AI Model Garden - TimesFM 1.0 (CPU/GPU Deployment)」、Version Historyの最新も2024年8月28日のgoogle/timesfm-v20240828と、TimesFM 1.0を対象にしたものです。AlloyDBのドキュメントが案内しているのはこのファイルではないため、混同しないでください。

TimesFM 3.0そのもののBigQuery統合については、公式ブログが「今後数週間のうちに提供予定」と書き、それまでは単変量タスクでTimesFM 2.5をAI.FORECASTから試すよう案内しています。上のAlloyDB向けドキュメントにも3.0は登場せず、Model Garden経由の提供も本稿執筆時点では確認できません。つまり、3.0の商用利用可能な提供形態はどの経路でも確認できていない状態です。ここは今後の発表待ちです。

業務で試すときの進め方#

ここからは、モデルが何であっても共通する検証設計です。時系列予測は、評価の切り方を間違えると簡単に「よく当たっている」ように見えてしまいます。

LLMと時系列基盤モデルの役割分担#

両方使う前提で、置き場所を分けるのが現実的です。

LLMを予測器として使うのではなく、予測の前後にある「読む・書く・整理する」に置く、という分担です。予測値の生成をLLMから外すと、数字の説明責任が明確になります。どの数字がどのモデルから出たのかが追えるようになるためです。

社内で試す前の確認手順#

検証を始める前に、データとライセンスの2方向で確認を通します。特に売上・受注・在庫のデータは、社外に出す想定になっていないことが多いはずです。

まとめ#

TimesFM 3.0は、多変量と共変量に正式対応し、ホライズン全体を1回の順伝播で出す設計に変わった、時系列専用の基盤モデルです。販促や祝日のように未来が分かっているイベントを予測に織り込める点は、小売や運用監視の実務と噛み合います。

同時に、事前学習済み重みは非商用・非本番に限定され、出力の商用利用にも制限がかかります。「試せるが、そのまま本番には入れられない」というのが、2026年9月時点の正確な状態です。

だからといって試す価値がない、という話ではありません。時系列基盤モデルが自社データでベースラインに勝てるかどうかを知っておくこと自体に価値があります。勝てるなら、商用で使える提供形態が整った時点で動けます。勝てないなら、前年同月比と季節ナイーブで足りていた、という結論が手に入ります。どちらに転んでも、ベースラインを置いた比較表は残ります。

本記事は2026年9月4日時点で公開されている一次情報(Google Research公式ブログ、google-research/timesfmのREADMEとライセンス、Hugging Faceのモデルカードおよびライセンス原文とconfig.json、Google Cloud公式ドキュメント(BigQuery ML・AlloyDB)、Google Workspace Updates)にもとづく整理です。ベンチマーク順位は開発元の発表によるもので、第三者が運用するリーダーボードの内容は時点により変動します。ライセンスの解釈は法的助言ではありません。実際の利用可否は原文と自社の法務の確認のうえで判断してください。