需要予測・在庫最適化・KPI 予測といった業務で、ARIMA や Prophet といった従来手法から一歩踏み込みたい局面が増えています。ここ数年で「事前学習済みの時系列予測基盤モデル（Time Series Foundation Model）」が複数登場し、追加学習なしでゼロショット予測できる選択肢が現実的になりました。
その一方で、Google の TimesFM、Amazon の Chronos、Salesforce の Moirai、そして Lag-Llama など、選択肢が増えるほど「どれを PoC の対象にすべきか」の判断に迷いやすくなります。それぞれアーキテクチャも訓練データも異なり、公式ドキュメントを個別に読み比べるコストは無視できません。
本記事では、Google Research が公開する google-research/timesfm を題材に、TimesFM のアーキテクチャ・最新バージョン 2.5 での変更点・Google プロダクトとの統合・類似 OSS との差分を、公式ドキュメントと README を根拠にまとめます。「TimesFM を採用すべきか、それとも他を選ぶべきか」という初見エンジニアの判断を支援することを目的とし、動作検証は行わずドキュメントベースで整理します。
TimesFMとは何か
TimesFM（Time Series Foundation Model）は、Google Research が開発した「時系列予測に特化した事前学習済み基盤モデル」です。追加学習なしのゼロショット予測を主眼としており、需要予測・金融・製造・医療・自然科学など幅広い領域を単一モデルでカバーすることを目指しています。詳細は Google Research のブログ記事 A decoder-only foundation model for time-series forecasting で公開されています。
リポジトリの基本情報
執筆時点（2026 年 7 月）のリポジトリメタデータは以下の通りです。
項目 | 値 |
|---|---|
owner/name | google-research/timesfm |
主要言語 | Python |
ライセンス | Apache-2.0 |
Star 数 | 26,487 |
Fork 数 | 2,568 |
最終 push | 2026-07-02 |
archived | false |
fork | false |
private | false |
このリポジトリは archived / fork のいずれにも該当せず、独立した本家リポジトリとしてアクティブに更新されています。最終 push は執筆時点の 2 日前であり、時系列予測 OSS の中では最大級の Star 数（26,487）を持つため、コミュニティ規模とメンテナンス状況の両面で利用検討の土台は整っていると読み取れます。ライセンスは Apache-2.0 のため、商用利用にも制約が少ない設計です。
なお、README にも記載がある通り、TimesFM 自体は「officially supported Google product」ではない研究成果物として公開されている点に留意してください。ただし後述する BigQuery ML や Vertex AI Model Garden など、Google Cloud 側では正式なマネージド機能として組み込まれています。
「時系列予測基盤モデル」とは何か
従来の時系列予測は、系列ごとに ARIMA や Prophet、あるいは LSTM などを個別に学習する運用が主流でした。時系列予測基盤モデルは、大量の時系列データで一度だけ大規模な事前学習を行い、その後は未知の系列に対して追加学習なしで予測を返す「ゼロショット予測」を狙う点が特徴です。個別モデル運用の手間を削減し、幅広い業種・粒度のデータに対して同じモデルを流用できる可能性がある、というのが基盤モデル路線の狙いになります。
TimesFMの技術的な特徴
TimesFM のアーキテクチャと訓練データの詳細は、ICML 2024 で発表された論文 A decoder-only foundation model for time-series forecasting にまとまっています。ここではその要点を整理します。
デコーダーのみTransformerとパッチ化
TimesFM はデコーダーのみ（decoder-only）の Transformer をベースにしています。時系列を連続した時点のグループ「パッチ」に分割してトークン化し、自己回帰的に将来のパッチを生成する仕組みです。ここでのポイントは、入力パッチ長と出力パッチ長を分離している点にあります。一般的な自己回帰予測では 1 ステップずつ将来を生成しますが、TimesFM は 1 回のデコードで複数時点をまとめて出力できるため、長期ホライゾンでの誤差累積を抑制しやすい設計です。
Google Research のブログでは、この設計により Monash や ETT といったベンチマークで「ほとんどの統計手法を上回り、教師あり深層学習手法と同等以上」のゼロショット性能を示した、と説明されています（出典: Google Research Blog）。
ゼロショット予測とベンチマーク性能
TimesFM は約 100 億時点の実世界データ（Google Trends・Wikipedia ページビューなどの公開データ）と合成データを組み合わせて事前学習されています。これによって、追加学習なしで新規系列に対して予測を返す「ゼロショット」運用が現実的になりました。
コンパクトさも特徴の 1 つで、最新の 2.5 系ではパラメータ数を 200M まで削減しています。基盤モデルとしてはかなり小さい部類であり、推論コスト・レイテンシ・可搬性の面で扱いやすいサイズ感になっています。
TimesFM 2.5で何が変わったか
執筆時点の最新バージョンは TimesFM 2.5（2025 年 9 月 15 日リリース）です。README に記載された主な変更点は以下の通りです（出典: google-research/timesfm README）。
- パラメータ数の削減: 2.0 の 500M から 200M へダウンサイズ。推論効率が向上
- コンテキスト長の拡張: 2.0 の 2048 から 最大 16k へ拡張。長い履歴を活用した予測が可能に
- 連続分位数予測ヘッドの追加: 1k ホライゾンまでの連続分位数予測に対応（オプションで 30M の quantile head を追加）
frequencyインジケータの廃止: 頻度指定が不要になり、API がシンプル化- XReg による共変量サポート: 2025-10-29 に 2.5 へ再追加され、外部説明変数（プロモーション・気象など）を扱えるように
- Flax バックエンド: PyTorch と Flax の双方をサポート
- LoRA fine-tuning サンプル: 2026-04-09 に HuggingFace Transformers + PEFT (LoRA) を用いた fine-tuning サンプルを追加
旧バージョン（1.0 / 2.0）はリポジトリの v1 サブディレクトリと pip install timesfm==1.3.0 などのバージョン固定でアクセス可能です。ただし新規に採用検討する場合は、パラメータ削減とコンテキスト長拡張の恩恵を受けられる 2.5 系を出発点にするのが自然です。
TimesFMの使い方（セットアップとコード例）
導入コストを見積もるうえで最小限必要な情報を、README から引用します。動作の確認は本記事の範囲外のため、以下は公式ドキュメントの記載内容をそのまま整理したものです。
インストール（PyPI／ローカル）
PyPI から用途に応じたエクストラを指定してインストールできます。
pip install timesfm[torch] # PyTorch バックエンド
pip install timesfm[flax] # Flax バックエンド
pip install timesfm[xreg] # 共変量サポートが必要な場合
出典: google-research/timesfm README
ローカルからインストールする場合、README では uv を用いた手順が推奨されています。詳細な手順は google-research/timesfm README を参照してください。
Hugging Face経由でモデルをロード
TimesFM 2.5 のチェックポイントは Hugging Face 上で配布されています。モデルカードは google/timesfm-2.5-200m-pytorch にあり、ライセンス（Apache-2.0）や訓練データ（GiftEvalPretrain / Wikimedia ページビュー・Google Trends の上位クエリ / 合成・拡張データ）も同ページに明記されています。全チェックポイントは Hugging Face の TimesFM コレクションから参照できます。
予測コード例（README引用）
README には以下の最小構成のコード例が示されています。
import torch
import numpy as np
import timesfm
torch.set_float32_matmul_precision("high")
model = timesfm.TimesFM_2p5_200M_torch.from_pretrained("google/timesfm-2.5-200m-pytorch")
model.compile(
timesfm.ForecastConfig(
max_context=1024,
max_horizon=256,
normalize_inputs=True,
use_continuous_quantile_head=True,
force_flip_invariance=True,
infer_is_positive=True,
fix_quantile_crossing=True,
)
)
point_forecast, quantile_forecast = model.forecast(
horizon=12,
inputs=[
np.linspace(0, 1, 100),
np.sin(np.linspace(0, 20, 67)),
],
)
# point_forecast.shape # (2, 12)
# quantile_forecast.shape # (2, 12, 10): mean, then 10th to 90th quantiles.
出典: google-research/timesfm README
ForecastConfig に指定した各種フラグ（分位数ヘッドの利用・入力正規化・正値制約・分位数の交差修正など）で挙動を細かく制御できる設計です。inputs に複数の系列を渡すことで、系列ごとに独立した予測をバッチ処理できる点も特徴で、多店舗・多商品の需要予測など「多系列同時予測」を想定した API になっています。
Googleプロダクトとの統合（BigQuery ML・Sheets・Vertex AI）
TimesFM を選ぶ大きな理由の 1 つが、Google Cloud エコシステムとの統合の広さです。「モデル管理を自前で持ちたくない」「SQL やスプレッドシートから直接呼び出したい」といった運用者向けの選択肢が用意されています。
BigQuery MLからSQLで予測
BigQuery ML では TimesFM をマネージド機能として利用でき、SQL クエリのみで時系列予測が完結します。公式ドキュメント The TimesFM model - BigQuery によると、以下の 3 つの関数が用意されています。
AI.FORECAST— 時系列予測AI.DETECT_ANOMALIES— 異常検知AI.EVALUATE— 予測精度の評価
いずれもモデルの学習・チェックポイント管理・推論エンドポイント運用が不要で、既存の BigQuery データセットからそのまま呼び出せます。Google Sheets の Connected Sheets からも BigQuery ML 経由で TimesFM 予測を利用できるようになっており、非エンジニアが表計算上で予測列を追加する用途にも対応します。
Vertex AI Model Gardenでの本番デプロイ
より柔軟な制御が必要な場合は、Vertex AI Model Garden で Docker 化されたエンドポイントとしてデプロイできます。エージェント連携や外部システムからの API 呼び出しを想定するケースで扱いやすい構成です。
BigQuery ML と Vertex AI のどちらを選ぶかは、「SQL で完結させたいか / 独立した API として持ちたいか」で判断すると整理しやすい選び方になります。
類似の時系列予測OSSとの比較
TimesFM を採用検討する際に必ず比較対象になるのが、Amazon の Chronos、Salesforce の Moirai、そして Lag-Llama です。それぞれ設計思想が異なるため、単純な性能比較ではなく「どのシナリオで強みを発揮するか」の観点で棲み分けを整理します。
Chronos（Amazon）— エンコーダーのみ・トークン化アプローチ
amazon-science/chronos-forecasting は Amazon Science が開発する時系列予測基盤モデルです。最新版の Chronos-2（2025-10-20 リリース）は約 120M パラメータで、エンコーダーのみ（T5 派生）のアーキテクチャを採用しています。時系列の値を離散化してトークン列に変換し、sequence-to-sequence の言語タスクとして扱うアプローチが特徴です。単変量・多変量・共変量つき予測を単一アーキテクチャでカバーし、fev-bench / GIFT-Eval などのベンチマークで高い成績を示しています。蒸留版の Chronos-Bolt は 250 倍高速・20 倍メモリ効率と報告されており、Amazon SageMaker との統合が強い点も含めて AWS 中心の環境で選ばれやすい設計です。
Moirai（Salesforce）— 多変量・不規則データ向け
SalesforceAIResearch/uni2ts は Salesforce AI Research が公開する Moirai / Moirai-2 系列の実装で、パッチベースの universal encoder アーキテクチャを採用します。特筆すべきは、多変量時系列とサンプリング頻度が不揃いなデータをネイティブサポートしている点です。プロモーション・気象・経済指標といった共変量が絡む予測や、IoT センサーストリームのように不規則な間隔でサンプリングされたデータを扱う場面で強みを発揮します。
Lag-Llama — 単変量特化・遅延特徴の明示
time-series-foundation-models/lag-llama は ServiceNow らのグループが主導する OSS で、デコーダーのみ（LLaMA 派生）のアーキテクチャです。単変量時系列に特化し、lagged values（遅延値）と暦特徴（曜日・月など）を明示的に入力トークンに含める設計を採っています。周期性・季節性が強く効くデータで、モデルにその構造を直接埋め込みたい場合に選択肢となります。出力は確率的（probabilistic）で、予測分布が必要な用途に向いています。
比較表と「どれを選ぶか」の判断軸
以下の比較表は各 OSS の公式リポジトリ・公式ブログの情報を整理したものです。
観点 | TimesFM | Chronos-2 | Moirai | Lag-Llama |
|---|---|---|---|---|
開発元 | Google Research | Amazon Science | Salesforce | ServiceNow ほか |
アーキテクチャ | デコーダーのみ Transformer | エンコーダーのみ（T5派生） | パッチベース universal encoder | デコーダーのみ（LLaMA派生） |
パラメータ数 | 200M（2.5） | 120M（Chronos-2） | 数億級（用途別バリエーション） | 数千万〜1億 |
単変量/多変量 | 多系列同時予測（共変量は XReg で対応） | 単変量/多変量/共変量を単一で | 多変量ネイティブ | 単変量特化 |
クラウド統合 | BigQuery / Google Sheets / Vertex AI Model Garden | SageMaker JumpStart | — | — |
主な強み | Google エコシステム統合 / ゼロショット精度 | zero-shot 汎化性能 / 蒸留版の高速性 | 多変量 / 不規則データ | 季節性・遅延特徴の明示 |
判断軸として整理すると、次のような棲み分けになります。
- Google Cloud 中心の環境で BigQuery / Sheets / Vertex AI から呼び出したい → TimesFM
- AWS 中心の環境で SageMaker JumpStart に載せたい → Chronos
- 多変量・不規則タイムスタンプのデータを扱いたい → Moirai
- 単変量で季節性・遅延特徴を明示的にモデル化したい → Lag-Llama
「どれが一番強いか」ではなく「データ形状とクラウド環境の相性」で選ぶ、と割り切ると迷いにくいはずです。
なお、金融市場のように独自の時系列特性（K線データなど）を持つドメイン特化型の基盤モデルを検討している場合は、清華大学の研究チームが公開する Kronos とは？金融市場向けのOSSファンデーションモデルを解説も合わせて検討対象になります。ドメイン特化 vs 汎用ゼロショットという観点で TimesFM との棲み分けを整理しやすくなります。
TimesFMの採用可否を判断するチェックリスト
これまでの整理を踏まえ、TimesFM の採用を検討する際のチェックリストとしてまとめます。
TimesFM が向くケース
- Google Cloud（BigQuery / Sheets / Vertex AI）中心のデータ基盤を持っている
- 多店舗・多商品など多系列を同一モデルで予測したい
- ゼロショット予測性能を優先し、系列ごとの追加学習コストを避けたい
- 200M パラメータのコンパクトなモデルで、推論コスト・可搬性を確保したい
- SQL のみで予測フローを完結させ、モデル管理を Google Cloud に委ねたい
- 分位数予測（quantile forecast）を用いた不確実性の可視化が要件に含まれる
他 OSS を検討すべきケース
- 多変量・不規則タイムスタンプ（IoT センサーなど）がメイン → Moirai を優先検討
- AWS / SageMaker が既に運用の中心 → Chronos が統合面で有利
- 単変量で強い季節性・遅延特徴を明示的にモデル化したい → Lag-Llama を検討
- ライセンス上、Apache-2.0 相当が困難で、より緩やかなライセンスを要求する（各 OSS のライセンスを個別に確認）
採用前に確認しておくべき点
- 公式製品ではない旨（README 明記）を組織内で許容できるか
- BigQuery ML / Vertex AI から利用する場合、対象リージョン・料金体系を Google Cloud のドキュメントで確認する
- 共変量が必須要件の場合、
timesfm[xreg]エクストラを含めたインストール・API 制約を README で確認する - 業務データの特性（多変量／不規則サンプリング／強い季節性）が TimesFM の強みと合致するかを PoC で見極める
まとめ
TimesFM は、Google Research が公開する 200M パラメータのデコーダーのみ Transformer による時系列予測基盤モデルです。ゼロショット予測を主眼としつつ、BigQuery ML・Google Sheets・Vertex AI Model Garden と深く統合されている点が、他の時系列予測 OSS に対する明確な差別化ポイントになっています。Star 数 26,487・最終 push が執筆時点の 2 日前という更新頻度の高さも、採用検討時の安心材料といえます。
一方で、多変量ネイティブサポートや不規則タイムスタンプ対応が要件なら Moirai、AWS 中心の環境なら Chronos、単変量で季節性・遅延特徴を明示したいなら Lag-Llama、といった棲み分けが自然です。「どれが最強か」ではなく「自社のデータ形状と運用インフラの相性で選ぶ」という判断軸で臨むと、PoC 対象を絞り込みやすくなります。
次のステップとして、まずは以下の一次情報を参照することをおすすめします。
- リポジトリと README: google-research/timesfm
- 設計思想・ベンチマーク: Google Research Blog
- モデルカード（全チェックポイント）: TimesFM Hugging Face Collection
- BigQuery ML からの利用: The TimesFM model - BigQuery
自プロジェクトのデータで PoC を進める際は、まず 1〜2 系列の代表データで AI.FORECAST を試すか、Hugging Face の google/timesfm-2.5-200m-pytorch からロードして予測 API の応答形式を確認するところから始めると、実装への見通しが立てやすくなります。
