Google Research、TimesFM-3を公開。ただし最高性能モデルには商用利用上の制約

Google Researchは2026年8月31日、従来は単一系列の予測に限られていたモデル群に、ネイティブな多変量予測を加えたTimesFM-3を公開した。3億3,000万パラメータのこのモデルは、関連する系列、過去のシグナル、既知の将来イベントを含むより多くの情報を、一度の処理で扱う。

実際の予測が単一の履歴だけに依存することはほとんどないため、この変更は重要だ。小売需要は販促施策や天候に反応する。エネルギー消費は気温、スケジュール、活動量に左右される。インフラ指標は、共通サービスで障害が起きると連動して変動する。

Googleによると、TimesFM-3はタスク固有のファインチューニングを必要とせず、この隔たりに対応する。ただし、このリリースには重要な矛盾もある。コードはApache 2.0のもとでオープンなままである一方、新しい事前学習済み重みは商用利用および本番環境での利用を禁じている。

その結果、これは単なるモデル更新以上の意味を持つ。Google Researchは、より強力な汎用予測アーキテクチャを生み出す一方で、公開実験と制限のないデプロイを切り分けた。これはAmazonのChronos-2、DatadogのTotoファミリー、そして特化型予測パイプラインを維持するチームに圧力をかける。

Google ResearchがTimesFM-3で変更した点

TimesFM-3はTimesFMファミリーを、単一系列の予測器から、つながりのある変数群を横断して推論できるモデルへと変えた。

Googleは2024年2月に初代TimesFMを発表した。このモデルはデコーダー専用Transformerを採用し、先行するパッチから将来の時系列パッチを予測した。2億のパラメータは、1,000億の実世界の時点データで学習されている。

初代モデルはゼロショット予測を実行した。これは、特定のデータセット向けに学習することなく、未知のデータセットで予測を行うことを意味する。Googleはforecasting model paperで、統計的手法や教師あり深層学習モデルに対して競争力のある結果を報告した。

後のTimesFM-2.0ではモデルサイズが5億パラメータへ拡大された。TimesFM-2.5では2億パラメータに戻しつつ、対応コンテキストを2,048から16,384時点へと拡張した。また、最大1,000ステップの予測期間に対応する連続的な分位点予測も追加した。

しかし、これらのリリースは根本的には単変量のままだった。外部回帰変数を別の仕組みで利用できたとしても、各予測は主として、予測対象である単一のターゲット系列を扱っていた。

TimesFM-3はこの設計を変更する。3億3,000万のパラメータは、1兆を超える実データおよび合成データの時点で事前学習された。この学習コーパスは、初代モデルで公開されたコーパスの10倍を超える。

モデルは複数の異なる情報タイプを受け取る。複数ターゲットは、ユーザーがまとめて予測したい関連系列を表す。過去共変量は、観測期間内でのみ既知の変数を提供する。過去・将来共変量には、予測期間全体ですでに判明している値が含まれる。

たとえば小売業者は、アイスクリーム、コーン、シロップの需要を同時に予測できる。過去の来店客数は過去共変量として利用できる。計画済みの販促施策や天気予報は、過去・将来共変量になり得る。

この構成により、モデルは単変量予測では捨てられてしまう関係性を利用できる。販売急増は、販促施策と同時に起きたことをモデルが確認できれば、解釈しやすくなる。関連商品の需要変化も、共通する行動についての証拠を提供できる。

公式のTimesFM-3 releaseによると、このモデルはすべてのターゲットについて点予測と分位点予測の両方をサポートする。点予測は1つの期待値を提供する。分位点は可能な結果の範囲とその不確実性を示す。

TimesFM-3は、第10パーセンタイルから第90パーセンタイルまでの9つの分位点を出力する。これは、1つの予測だけでは不十分な意思決定にとって重要だ。在庫チームは、予想需要だけでなく、欠品と過剰在庫のリスクも理解する必要がある。

Googleによると、このモデルは単変量モードでも動作する。そのため開発者は、完全な多変量データパイプラインを構築する前に、新しいチェックポイントを既存の単一系列ワークロードでテストできる。

このリリースはすでに公開Google ResearchリポジトリとHugging Faceチェックポイントを通じて利用可能だ。Googleによると、BigQuery統合は今後数週間で提供される予定であり、リポジトリの注目度が再び高まった背景となる検証済みイベントの日付は8月31日である。

したがってGitHubでのトレンドは、2024年プロジェクトの再発見ではなく、現在のリリースに結び付いている。TimesFM-3はこのリポジトリの最新モデルであり、新しい多変量アーキテクチャが注目を集める要因となっている。

多変量予測が競争の構図を変える理由

重要な変化は、単に精度が向上したことではない。TimesFM-3は、本番環境で予測が機能するかを左右する複雑な関係性を対象としている。

運用上の予測の大半は、相互接続されたシステム内にある。倉庫の需要は、価格、販促、天候、休日、近隣在庫から独立して発生するわけではない。データセンターも、CPU、メモリ、トラフィック、レイテンシについて孤立したシグナルを生み出すわけではない。

単変量モデルは、こうした関係性を単純化する。1つのターゲットの履歴の中にある季節性、トレンド、反復パターンを検出できる。しかし、別の仕組みを通じて情報を入力しない限り、予定された販促施策を直接解釈することはできない。

多変量予測は複数の系列を共同で扱う。ある変数が別の変数とどのように連動するか、外部シグナルがターゲットをどう変えるかをモデル化できる。このアプローチは、そうした関係が履歴コンテキスト全体で繰り返される場合に特に有用だ。

Googleの例示的な小売事例は、その理由を示している。単変量予測は、過去の週次販売パターンを延長する。販促スケジュールはターゲットの過去の値に現れないため、販促日を予測することはできない。

TimesFM-3は、そのスケジュールを既知の将来共変量として受け取る。モデルは過去の販促と販売変化を関連付け、その関係を予定日へ適用する。Googleの例では、各販促日に約20％の販売増加が予想されている。

この数値は例示であり、モデルが小売業者全体で同じ販売増加予測を生み出すことを示す証拠ではない。販促効果は価格、商品、顧客、タイミング、データ品質に依存する。この例はむしろ、将来情報が予測にどのように入るかを示している。

この機能は、ほかの時系列基盤モデルに直接的な圧力をかける。AmazonのChronosファミリーは、言語モデル型の事前学習が実行可能な予測アプローチであることの確立に寄与した。Chronos-2は後に、多変量および共変量対応タスクへと競争を拡大した。

DatadogのTotoファミリーも、多変量ワークロードを含む汎用予測を対象としている。SalesforceのMoiraiファミリーとIBMのTiny Time Mixersも、個別のタスク固有モデルを再利用可能な事前学習済みシステムに置き換えようとする試みだ。

競争はますますデプロイ可能な範囲をめぐるものになっている。クリーンな公開ベンチマークでしか機能しない基盤モデルは、運用チームにとっての価値が限定的だ。勝つシステムは、不規則なビジネス文脈、不確実性、変化する関係性、許容可能な推論コストを扱わなければならない。

TimesFM-3により、Googleはすでに単変量予測を越えたライバルに対する信頼できる回答を得た。また、研究を既存の配布チャネルにつなげている。以前のTimesFM機能はBigQuery、AlloyDB、Google Sheets、Vertex AI環境に提供されていた。

Googleは、TimesFMが2025年にBigQueryとAlloyDBを通じ、すでに月間数億件のクエリを処理していたと報告している。この数値はTimesFM-3ではなく以前のモデルバージョンに関するものだが、研究から日常利用へ至る確立された経路を示している。

配布はベンチマーク順位と同じくらい重要になる可能性がある。データウェアハウス内の予測モデルにより、アナリストはガバナンスの効いたビジネスデータの近くで作業できる。各チームが予測を試す前に個別の推論サービスを構築する必要もなくなる。

圧力は特化型予測パイプラインにも及ぶ。多くの組織はいまも、商品、地域、指標ごとに異なるモデルを学習している。各モデルには特徴量エンジニアリング、検証、監視、継続的な保守が必要だ。

ゼロショットの汎用モデルは出発点を変える。チームは、特化学習が依然として価値を持つ領域を判断する前に、多くの系列にわたって1つのモデルを評価できる。これはカスタムモデルを不要にするものではないが、それらが上回るべき基準を引き上げる。

このため、「ファインチューニング不要」という表現にも慎重な解釈が必要になる。ユーザーは依然として、ターゲットを選び、共変量を準備し、リークを防ぎ、予測期間を決め、ビジネスコストを評価しなければならない。このモデルが取り除くのは1つの学習ステップであり、予測を取り巻く規律そのものではない。

単一パスモデルが予測メカニズムを書き換える

TimesFM-3は、系列間アテンションと単一パスのデコーディングを組み合わせ、欠落した文脈と誤差の蓄積の両方に対処する。

従来のTimesFMバージョンと同様に、このモデルは隣接する観測値を32タイムステップのパッチにグループ化する。パッチは言語モデルのトークンのように機能し、複数の連続値を1つの内部表現に圧縮する。

パッチ化は系列長を短縮し、長い履歴を処理しやすくする。また、Transformerが各測定値を無関係な項目として扱うのではなく、繰り返される局所パターンを処理できるようにする。

TimesFM-3はこれらのトークンを2つの次元に配置する。1つは時間を表す。もう1つは、リクエストに含まれる異なるターゲット系列と共変量系列を表す。

Transformerは2種類のアテンション操作を交互に実行する。因果的な時間アテンションは、1つの系列内のより前のパッチを調べる。「因果的」とは、モデルが予測を形成する際に、未知の将来ターゲット値を参照できないことを意味する。

完全な変量アテンションは、同じ時間位置にある系列間で機能する。これにより、あるターゲットは他のターゲットや共変量から情報を取り込める。これが、販促スケジュールが対応する販売予測に影響を与えられる仕組みだ。

過去・将来共変量には、特別な先読み処理が適用される。各トークンは、現在のパッチと、すでに分かっている情報を含む将来パッチを組み合わせる。したがってモデルは、将来のターゲット結果を見せられることなく、予定イベントを確認できる。

この区別は不可欠だ。将来の祝日カレンダーは日付がすでに分かっているため、有効な入力となる。明日の実際の売上は、示せば答えを漏らすことになるため、有効な入力ではない。

Google Researchはデコーディングプロセスも変更した。従来のTimesFMモデルは予測パッチを順番に生成していた。各予測パッチは、次のパッチを生成するためのコンテキストになった。

順次生成には2つの弱点がある。各ステップが前のステップを待つため、レイテンシが増加する。また、初期の予測誤差が後続のすべてのパッチに影響を及ぼし得る。

TimesFM-3は代わりに、連続パッチマスキングを用いる。システムは予測期間全体を覆うマスク済みプレースホルダーを追加し、その位置を1回の順伝播で予測する。

既知の将来共変量は可視のまま保たれ、ターゲット値はマスクされたままとなる。時間アテンションと変量アテンションを交互に実行し、結合されたコンテキストを処理する。モデルは反復的な生成ループなしに予測期間を埋める。

この非自己回帰設計、すなわち予測期間を一度に1部分ずつ生成しない方式は、Googleの性能主張の中心にある。長い予測期間でも、デコーディング回数が比例して増える必要はなくなる。

この仕組みは、ユーザーが測定すべき項目も変える。生のモデルレイテンシーは重要になるが、メモリ使用量や多数の変数にまたがるスケーリングも同様に重要だ。共同予測では、各リクエストにより多くの系列を含められるため、アテンション計算の量が増加する可能性がある。

公開されているTimesFM repositoryには、可変長の単変量入力と多変量配列の例が含まれている。また、過去のみの共変量と、過去・未来の共変量を別々に入力する方法も示している。

これらの例は、実務上の要件を明らかにしている。ユーザーは、すべてのターゲットと共変量を一貫したタイムラインに整合させなければならない。欠損観測、報告の遅延、頻度の不一致は、推論が始まる前に結果を損なう可能性がある。

オブザーバビリティのワークロードを考えてみよう。CPU使用率は毎分届く一方、請求データは毎時、デプロイメントのマーカーはリリース時にのみ発生する可能性がある。これらを組み合わせるには、リサンプリングと欠損値に関する判断が必要になる。

ヘルスケアや金融のユースケースでは、より厳しい制約が加わる。チームは、外部変数が予測時点で本当に利用可能だったかを判断しなければならない。そうでなければ、将来の情報を偶然使用したために、ベンチマークが正確に見えてしまう可能性がある。

TimesFMを単により大きなトランスフォーマーとして説明するだけでは、要点を見落とす。そのサイズはTimesFM-2.5から控えめに増加した一方で、事前学習コーパスは1兆ポイントを超える規模に拡大した。より深い変化は、アーキテクチャが関係性をどう表現し、予測ホライズンをどう生成するかにある。

この設計により、Google TimesFM modelは運用計画との関連性をより高めている。同時に、評価はより難しくなる。成功は、与えられた関係性が実在し、安定しており、適切なタイミングで提供され、意思決定に有用かどうかに左右されるようになった。

ベンチマークだけでは本番環境の問いに答えられない

Googleは3つの公開ベンチマークで首位の結果を報告しているが、ライセンスと独立検証の問題により、採用者が現時点で導ける結論には限界がある。

GoogleはTimesFM-3をGIFT-Eval、FEV-Bench、TIMEで評価した。これらのスイートは、異なるデータセット、予測タスク、ホライズン、評価設定を対象としている。

同社は、TimesFM-3が点予測と確率的予測の両方で、事前学習済み基盤モデルの中で1位にランクしたと報告している。また、100の実世界タスクにわたるFEV-Bench、および50のドメインから抽出した98タスクにわたるTIMEベンチマークでも、このモデルが首位だったとしている。

GIFT-Evalは、ゼロショット予測を幅広くテストするもう1つの評価だ。Googleによれば、TimesFM-3はこの比較に含まれた基盤モデルの中で1位にランクした。

このモデルは、共変量や系列間情報を活用できない単変量モードでも競争力を維持したとされる。完全な多変量モードを有効にすると、平均順位はさらに向上した。

これらは、1つの事前学習済みモデルが多様なデータセットへ転移できるかをテストするため、有意義なシグナルである。また、TimesFM-3をChronos-2、Toto 2.0、TimesFM-2.5を含む最近のシステムと比較している。

しかし、平均順位は多くの結果を1つの数値に圧縮している。特定の組織にとって重要な系列、ホライズン、誤差コストでモデルが勝つかどうかは明らかにしない。

食料品のプランナーは、祝祭日の需要ピーク前の誤差を最も重視するかもしれない。キャパシティエンジニアは、極端なトラフィックイベントを見逃すことを懸念するかもしれない。金融チームは、小幅な平均的改善よりも、較正された不確実性を重視する可能性がある。

公開ベンチマークは、本番データと異なる場合もある。ビジネス系列には、欠品、方針変更、報告の欠落、製品ローンチ、一過性のショックが含まれる。過去から学習した関係性は、こうした条件が変化した際に機能しなくなる可能性がある。

最も強い懐疑的な論点はアクセスに関するものだ。repositoryのソースコードにはApache 2.0ライセンスが適用され、TimesFM-2.5までのモデル重みも同ライセンスを維持している。TimesFM-3の重みには、別の非商用ライセンスが適用される。

このライセンスは、デフォルトのTimesFM-3事前学習済み重みを非商用かつ非本番用途に制限している。企業はアーキテクチャを研究し、許可された実験を実施できるが、ダウンロードしたcheckpointを収益を生むワークフローにデプロイできると想定することはできない。

これは、技術的な利用可能性と運用上の利用可能性の間に明確な隔たりを生む。モデルは公開されているが、最も直接的な本番導入経路は依然としてGoogleの管理下にある。

repositoryも、そのオープン版はGoogleが公式にサポートする製品ではないと警告している。したがって開発者は、コミュニティがアクセス可能なコードと、エンタープライズサポートのコミットメントを伴うサービスを区別すべきだ。

BigQuery integrationは、デプロイメントに関する問題の一部を解決する可能性がある。Googleは、そのintegrationがリリース後数週間で提供されるとしている。その条件、地理的な提供状況、クォータ、サポートされる入力、本番時の挙動が重要になる。

以前のTimesFM supportは、すでにBigQueryのAI.FORECAST functionを通じて存在している。このインターフェースはSQLユーザーの障壁を下げるが、TimesFM-3 supportについてはロールアウト後に確認する必要がある。

今回のリリースには、時間とともに蓄積される種類の独立した本番環境での証拠も欠けている。公開ユーザーが多変量の挙動、メモリ要件、障害モード、共変量の選択に対する感度をテストできたのは、まだ数日間にすぎない。

Googleの1兆ポイントという学習規模の数値にも、未解決の疑問が残る。リリースでは実データと合成時系列の混合について説明しているが、コーパスの完全な内訳は示していない。ユーザーは、規模だけからドメインカバレッジを十分に判断することはできない。

初期モデルでは、公開ソースの一部としてGoogle TrendsとWikipediaのページビュー・データが使用された。これらのデータセットには有用な時間的パターンが含まれるが、そのパターンと企業の内部業務との類似性を前提にすることはできない。

分位点予測にも検証が必要だ。9つの不確実性推定値を生成しても、新しいドメインでその区間が較正されている保証にはならない。チームは、実際の結果が各予測範囲内にどの程度の頻度で収まるかを確認すべきである。

したがって、実務上のテストは比較によるものとなる。組織は、同じ時系列ベースの分割を用いて、TimesFM-3をTimesFM-2.5、Chronos-2、Toto、統計的ベースライン、そして現在の本番モデルと比較すべきだ。

また、各予測が生み出す意思決定も評価すべきである。推論がより困難であったり、共変量が信頼できなかったり、ライセンスがデプロイメントを妨げたりする場合、小さな統計的改善はほとんど価値を持たない可能性がある。

Googleのベンチマークは、本格的な評価を行う根拠を提供する。しかし、ローカルテスト、運用上の安全策、明確な利用権なしに本番システムを置き換えることを正当化するものではない。

Google Researchのリリース後に注目すべき点

TimesFM-3が広く利用される予測レイヤーになるのか、それとも影響力のある研究上のcheckpointにとどまるのかは、3つのシグナルによって決まる。

第1のシグナルは、予定されているBigQuery integrationだ。SQLを通じて利用可能になれば、アナリストは既存のwarehouseデータの近くで多変量予測を実行する直接的な手段を得られる。

実装の詳細によって、TimesFM-3のどの程度がマネージドユーザーに届くかが明らかになる。購入者は、複数ターゲット、過去の共変量、既知の将来共変量、分位点出力、現実的な予測ホライズンをカバーするサポートに注目すべきだ。

価格条件も重要だが、初期評価では見出し上のコストよりもワークロードへの適合性に注目すべきである。レイテンシー、クォータ、リージョン別の提供状況、データガバナンスの制御が、チームがサービスを繰り返し利用できるかどうかを左右する。

BigQueryの幅広いsupportは、研究リリースを利用しやすいインフラへ転換するため、Googleの立場を強化するだろう。integrationが遅延または限定的なものにとどまれば、競合他社や独立系の予測ベンダーに余地を残すことになる。

第2のシグナルは、独立したベンチマーク再現だ。研究者と実務家は、固定されたデータセット、同一の評価ルール、比較可能な計算条件の下で、報告された順位を確認する必要がある。

特に注目すべきは、有用な将来共変量が利用可能な多変量タスクだ。これらのケースは、後方互換性のある単変量パフォーマンスではなく、TimesFM-3の中心的な主張を検証する。

評価者は、平均順位だけでなく、タスクレベルの結果も公開すべきである。その詳細により、TimesFM-3が苦戦する領域や、その改善が特定のドメインまたはホライズンに集中しているかどうかが分かる。

欠損値、レジーム変化、ノイズの多い共変量、多数の関連系列を含むテストは、より高い本番環境での関連性を提供するだろう。パフォーマンスが異例なほどクリーンな入力に依存するなら、Googleの主張を弱める可能性がある。

第3のシグナルは、事前学習済み重みの商用上の扱いだ。より広範なライセンスがあれば、より多くの組織が自社インフラを通じてcheckpointをデプロイできる。制限が継続すれば、商用採用はマネージドGoogle servicesへと向かうことになる。

この選択は競争地図に影響する。Chronos-2、Toto、Moirai、およびより小規模な予測モデルは、そのアクセス条件がプライベートデプロイメントの要件により適合する場合、勢いを得ることができる。

開発者は、checkpointを中心に製品を構築する前に、model licenseを確認すべきだ。公開されていることは、明記された制限を無効にするものではない。

チームは、それでも今回のリリースを使って、より良い技術的な問いを立てられる。厳格なリーク制御の後でも、系列間情報は精度を向上させるか。既知の将来イベントは妥当な変化を生むか。異常な期間に分位点予測は較正されているか。

有用な評価では、時系列ベースのホールドアウトを維持し、単純なベースラインと比較し、意思決定固有のコストを計算すべきである。チームは、すべての過去の予測時点でどの共変量が本当に既知だったかを文書化すべきだ。

また、最も単純で信頼に足るモデルを維持すべきである。季節性ベースラインが同程度の性能を示すなら、基盤モデルは十分な便益なしに複雑さを加えることになる。TimesFM-3が一貫して勝つなら、それは異なる予測ワークフローを採用する根拠となる。

Google Researchは、汎用予測モデルが接続された変数を理解し、完全なホライズンを効率的に生成すべきだという主張を示した。しかし、その最も強力な重みがどの程度オープンに本番環境へ届くのかは、まだ決着していない。

今後数か月で、マネージドでの利用可能性、独立した結果、ライセンスが収束するかどうかが明らかになるだろう。それまでは、TimesFM-3は重要なアーキテクチャのリリースであり、慎重に範囲を限定したデプロイメント候補として扱うのが最善だ。

開発者とデータチームにとって、直近の行動は明快である。重要な予測課題を1つ選び、リークを防いだ評価を構築し、すでに意思決定を担っているシステムとモデルを比較する。TimesFM-3は、あなたの組織が実際に重視する成果を改善するだろうか。