時系列基盤モデルがカスタム学習を不要にする

5年前にこんなことを言ったら、どの予測チームでも笑われていたはずです。でも今では、ほとんどの時系列問題について、自分のデータでモデルを学習させるのは時間の無駄になりつつあります。自分では一度も見ることのないドメインの、数百万本もの系列で事前学習された時系列基盤モデルは、CPU上で一回フォワードパスを回す間に、丹念にチューニングしたパイプラインをゼロショットで上回ることが多いのです。今週、5Mから209Mパラメータまでのサイズで公開されたMistralのTimestralは、この分野がどこに落ち着いたのかを示す最新かつ最強の証拠です。ただ、多くの実務者は、もっともらしい理由からこの結論に抵抗するでしょう。もっとも、その理由のほとんどは間違っていると思います。

時系列基盤モデルとは何か

LLMとのアナロジーは役に立ちますが、表面をなぞるだけでは不十分です。大規模言語モデルは、膨大なテキストコーパスで事前学習されることで、見たことのないタスクや言い回しにも汎化できるようになります。時系列基盤モデル（TSFM）は、連続的な信号に対して同じことをします。実データと合成データを含む大規模で多様な系列群で事前学習され、時系列データに繰り返し現れる文法を学習するのです。トレンド、季節性、レジーム変化、平均回帰、あらゆる種類のノイズ。センサーのストリームでも売上履歴でも、モデルに渡すとゼロから学習するわけではなく、「認識」するのです。

この「認識する」というのが全体の仕掛けであり、初めて読んだとき私を混乱させた点も、これで説明がつきます。主に合成データで学習されたモデルが、どうして実データで学習したモデルを上回れるのか。それは、合成データの生成器が、トレンド、季節性、ノイズの現実的な組み合わせや、系列間の非線形な依存関係を含む、一貫した動的特性を持つプロセスを作るように設計されているからです。モデルは、時系列の振る舞いがどのようなものになりうるかについての巨大な事前分布を学習します。あなたの実データがどれほど特異に見えても、それは、モデルが百万回も見てきたパターンの何らかの組み合わせである可能性が高いのです。

Timestralの学習レシピを見ると、このことがより具体的になります。まず、8,192タイムステップのコンテキストで、純粋な合成データを使った大規模な事前学習を行います。その後、実データと合成データの混合でポストトレーニングを行い、コンテキストを32,768ステップまで伸ばします。目的関数は21分位点に対するピンボール損失です。つまり、モデルは点推定値を出力するのではなく、不確実性の分布全体を出力するため、単一の自信ありげな数字ではなく、誠実な誤差範囲を伴う予測が得られます。

メンタルモデルとして取り入れる価値のあるアーキテクチャ上の工夫があります。Timestralは、Mistralが「decoupled horizon forecasting」と呼ぶ方式を採用しています。TimesFMのような従来の因果デコーダでは、予測対象の値をマスクしますが、これはシンプルなものの無駄が多い方法です。マスクされた値はコンテキストとして見えなくなり、予測のたびに後続の予測のための入力が劣化してしまいます。Timestralは履歴全体をシーケンス内に保持し、その履歴を読む学習可能な予測トークンを追加します。観測された各値は、学習時の目的変数とコンテキストの両方の役割を果たします。派手には聞こえない小さな構造的改善ですが、スケールすると非常に大きな意味を持つ類のものです。

ゼロショット予測：系列ごとのパイプラインを上回る理由

TSFMへの最大の論拠は、ベンチマークのリーダーボードではなく、実際の予測業務の形にあります。一つの系列だけを予測することはほとんどありません。一万本を予測するのです。小売業者は店舗ごと・SKUごとの需要を予測しますし、プラットフォームチームはサービスごと・リージョンごとのレイテンシを予測します。産業プラントには、数百台の設備にまたがる数千のセンサーがあります。従来の選択肢はどれも問題を抱えています。系列ごとにARIMAを当てはめると、履歴が少なくて大半が失敗します。あるいは、一つのグローバルな勾配ブースティングモデルを学習させると、特徴量エンジニアリングと系列間のスケールの不一致に溺れることになります。

TSFMはこのジレンマを回避します。チェックポイントは一つで、系列ごとのフィッティングも不要です。さらに、系列横断的な知識は、データだけから発見する必要はなく、事前学習の段階で組み込まれています。大規模に予測を実際に運用している実務者が、これらのモデルに最も懐疑的でないことが多いのはこのためです。代替案は、何か洗練された手作業のモデルではなく、数時間かかり、最も重要な系列の5%ほどで静かに壊れるAutoARIMAジョブの山なのです。

私が最も驚いたのは効率性の話です。Timestralの最大モデルは209Mパラメータで、LLMの基準では極めて小さく、推論にGPUも不要です。標準的な8スレッドのサーバーCPU上で、3週間分の15分間隔データから1日先を予測するのに、5Mモデルでは10ミリ秒、209Mモデルでは140ミリ秒しかかかりません。123Mモデルは、ベンチマークスコアで大型モデルとの差が0.2%以内に収まりながら、レイテンシは4分の3で済みます。これはLLMで起きたことと重なります。注目が小型で高速な階層に移っているのです。これはフラッシュ階層のLLMについて書いた記事で取り上げた動きと同じです。見出しを飾るのはフロンティアモデルですが、実際に業務を回しているのは小型で効率的なモデルなのです。

そして、そのコストメリットは積み重なります。一万本の系列を、それぞれ数十ミリ秒で日次予測するなら、予測ワークロード全体は、ごく普通のCPUマシン一台でランチタイムの間に終わります。GPUクラスターも、分散学習ジョブも、MLOpsの大立ち回りも不要です。5年前には、まともな予測モデルの構築とデプロイに数か月かかっていました。今では午後一つで済みます。そして、その午後の大部分はモデリングではなく、データの配管作業に費やされるのです。

共変量こそが本当の特徴量であり、本当の落とし穴

ここで懐疑派に譲歩せざるを得ません。TSFMに対する最も鋭い批判は正しいからです。多くの問題では、対象系列の履歴は情報の一部にすぎません。電力需要をモデル化するなら、天気予報、祝日カレンダー、料金体系は予測の味付けではなく、それ自体が予測なのです。丁寧に整備された共変量を、予測の品質をわずかに上げる程度のものとして扱うモデルは、まさにレジームが変わったときに恥をかかせるモデルです。そして、そのときこそ、そのモデルが必要になる場面なのです。

Timestralの答えは、共変量を考慮したアテンションです。その設計は、聞こえよりも原理に則っています。各入力系列には役割が割り当てられます。ターゲット、過去のみの共変量、既知の未来の共変量のいずれかです。生産スケジュール、計画停止、天気予報といった既知の未来の共変量は、ウィンドウ全体から見える一方で、ターゲットは因果的に保たれ、情報は共変量からターゲットへの方向にだけ流れます。この最後の制約が重要です。これにより、モデルはターゲット自身の未来を予測に漏らすことなく、来週の予定された負荷増加を条件にできます。共変量を介したデータリークは、予測システムにおける典型的な静かな故障の一つであり、情報の流れの向きをアテンションマスクに組み込むことは、それを防ぐ明快な方法です。

カテゴリ型の共変量も、きちんと扱われています。「稼働中」「待機中」「保守中」といった機器の状態は、任意の整数に押し込まれて偽の順序を押し付けられるのではなく、カテゴリとして入力されます。決定木モデルが「状態3」は「状態2」より大きいと学習してしまうのを見たことがある人なら、この点のありがたみがわかるでしょう。

ただ、これが実際に何を意味するかに注意してください。TSFMの導入の品質は、もはやモデルではなく、共変量パイプラインの品質によって決まります。天気フィードが古く、祝日カレンダーに地域の祝日が欠けており、保守スケジュールを機械可読な形式にエンコードした人が誰もいないなら、モデルはあなたを救えません。モデリングはコモディティ化しましたが、データエンジニアリングはそうなっていないのです。それに応じて工数を配分してください。

ベンチマークと、自分の信号でテストすべき理由

主要な三つの公開ベンチマーク、GIFT-Eval、TIME、fev-benchにおいて、Timestralの209Mモデルは、アンサンブルなしの単一チェックポイントでも、事前学習済みのゼロショットモデルの中で首位にランクされています。報告によれば、28Mモデルは約4倍の大きさのChronos-2を上回るそうです。これらは本当に強い結果ですし、このファミリーのすべてのモデルサイズが、精度とサイズのパレート・フロンティア上に位置していることから、効いているのはスケールだけでなく、レシピそのものだと示唆されます。

さて、必要な但し書きです。予測ベンチマークには、深刻な方法論上の問題があります。そこに含まれる多くの系列は、ノイズが多く信号の少ないプロセスであり、捉えるべき信号がほとんどないため、どんな妥当なモデルでもほぼ同じ性能になります。こうした系列を数百本平均すると、実際の差は極小の差に圧縮されます。そうして、0.03の改善が5倍の差に見えるようなマーケティング用のグラフができあがるのです。これは、以前に書いた一般的な病気の具体例です。ベンチマークは、実際に重要な仕事を体系的に取りこぼします。予測ベンチマークも、特に定量的に測れる形でそれを取りこぼしているのです。

より良いテストは、自分で実行できるものです。信号対雑音比が既知で高い評価用の系列を構築します。経験的条件付き分布のような単純な手法で、信号の大部分を捉えられる系列です。そのうえで、基盤モデルも同じ信号を捉えられるかを確認します。次に、ノイズのレベルを上げていき、どこで性能が劣化するかを観察します。ノイズの多いベンチマークではSOTAに見えても、クリーンな領域では明らかな信号を取り逃しているモデルは、リーダーボードが教えてくれないことを教えてくれています。

ノイズの多いデータでは、どのモデルもほとんど同じに見えます。モデル間の差が出るのは、捉えるべき本物の信号があるときだけです。だから、信号がある場所でテストしてください。

古典的手法がまだ勝つ場面

冒頭の主張には正直な限界が必要なので、それを挙げておきます。基盤モデルに手を伸ばすべきではない現実的なケースがあります。

• 方程式が必要で、出力だけでは足りない場合。 系統運用者や制御エンジニアであれば、解釈可能な動的モデルが必要になることが多いでしょう。推論し、ストレステストし、規制当局に渡せるような物理的意味を持つパラメータです。TSFMはブラックボックスで、y = F(x, params)のような読める構造がありません。当てはめた状態空間モデルやSINDy系のモデルは、ニューラルネットでは決して得られないものを与えてくれます。
• 長く豊かな履歴と強いドメイン構造を持つ、重要な系列が一つだけある場合。 数十年分のデータがある国の電力負荷のように、よく理解された単一の系列は、ドメイン知識で組んだ専用モデルに報いてくれます。問題が一つだけで、その分野に深い専門知識があるなら、ゼロショットの汎用性は無駄になります。
• 共変量が支配的で、関係が安定して既知の場合。 適切な特徴量に対する線形回帰は透明でデバッグしやすく、問題の物理が本当に線形であれば、打ち負かすことはできません。利得がないのに複雑さのコストを払う必要はありません。
• 依存関係を完全に自前で管理しなければならない場合。 Timestralは、制限付きの修正MITライセンスで提供されています。予測が基幹インフラ、たとえば前日エネルギー市場などであれば、ベンダーのサーバーや、完全にはコントロールできないライセンスに依存することについて、よく考える必要があります。オープンウェイトの代替案や社内モデルは、まさにこうしたケースのために存在します。
• 厳密なバックテストの規律が求められる場合。 事前学習済みモデルでは、ベンダーが学習データの構成を管理させてくれない限り、バックテスト期間が学習コーパスに含まれていなかったと完全に確信することはできません。Mistralは、そのためのForgeパイプラインを提供していますが、想定するのではなく検証してください。

パターンに注目してください。基盤モデルは、幅広さ、速度、疎なデータに強い一方で、解釈性、単一系列への深さ、依存関係のリスクでは劣ります。これは実用的な判断基準であり、よくある「ケースバイケース」よりもずっと鋭いものです。

誰もが飛ばしているアーキテクチャの問題

TSFMの流れがすでに決着をつけた点のうち、もっと注目されてよいものがあります。トランスフォーマーは連続信号にもうまく機能し、トークン化の問題は予想よりずっと怖くないということです。鍵はパッチ化です。各タイムステップをトークンとして扱うと（シーケンス長が爆発的に増えます）、あるいは生の浮動小数点数を素朴に埋め込むのではなく、系列をパッチに分割してそれを埋め込みます。パッチ長は、解像度とコンテキストをトレードオフする調整可能なツマミになり、LLMの語彙サイズとまったく同じ役割を果たします。状態空間モデルとトランスフォーマーの論争を追ってきた人にとって注目すべきは、これまで勝ち残ったTSFMがほとんどアテンションベースだという点です。入力表現さえ固定すれば、時系列データの長距離構造は、アテンションによく合うようです。

合成データファーストの戦略も、同等に評価されるべき貢献です。Timestralの学習データのほとんどは、収集されたものではなく生成されたものです。まず、一貫した動的特性を持つ単変量プロセスを作り、次に多変量シンセサイザーで、それらの間に非線形な依存関係を重ねています。これは、時系列機械学習を長年悩ませてきたデータの問題を見事に回避しています。センサーデータのCommon Crawlは存在せず、既存のデータはサイロ化され、独占的で、形式もばらばらです。適切な帰納バイアスを持つ合成データがこれほどうまく転移するなら、分野全体の経済性が変わります。世界中のテレメトリを囲い込む必要はなく、必要なのは良い生成器なのです。

予測からシステムへ

最も興味深い長期的な影響は、モデルそのものではなく、それが下流で可能にすることにあります。指標に対して継続的に動く、安価で確率的な多変量予測器は、誠実な不確実性を持つ異常検知器になります。値が静的な閾値を超えたら警告するのではなく、現実が予測された分位点の外に出たら警告するのです。これにより、季節性や計画イベントを尊重したアラートになります。予定された負荷増加は、驚きとしてフラグを立てられるのではなく、想定どおりとして扱われます。それだけで、多くの組織で当直のアラートノイズのうち、うんざりするほどの割合が消えるはずです。

その上にLLMエージェントを載せると、Mistralが描いているワークフローが得られます。数値モデルがポンプの異常を検知し、エージェントが信号を過去の故障の埋め込みと比較し、保守記録やオペレーターのメモを対象に根本原因分析を走らせ、工場長には裸のアラートではなく、根拠付きの診断を渡します。その具体的なビジョンを買うかどうかは別として、方向性は妥当です。これは意思決定モデルのための制約付きデコーディングで見てきたパターンと同じです。速く専門化されたモデルを、得意な役割でループに残し、汎用モデルにその周囲のオーケストレーションを任せるのです。

そこで、私の結論を述べます。個別最適化の予測は死んだわけではなく、デフォルトの手段から専門家向けのツールへと格下げされたのです。系列が一つだけで、深いドメイン知識があり、解釈可能な動的特性が必要なら、状態空間モデルを当てはめ続けて安心して眠ってください。しかし、系列が数千あり、系列ごとの履歴は少なく、チームは三人しかいないなら、立証責任は逆転しています。基盤モデルから始めない理由を示す必要があるのです。自分の高信号データでテストし、共変量を適切に組み込み、ライセンスをリスク許容度に照らして確認してください。そして、節約できた数か月を、データの配管作業に充ててください。予測プロジェクトは、結局のところそこで勝負が決まってきたのですから。