Timestralとは：Mistralの時系列基盤モデルをCPUで動かす手順と月商2,000万ドルのライセンス条件【2026年10月時点】

Timestralは、Mistral AIが2026年10月15日に公開した時系列予測の基盤モデルです。売上やセンサー値の過去の並びを渡すと、自社データで学習させなくても先の値と21段階の分位点を返します。GPUを使わずCPUだけで推論できる点と、重みを自社サーバーに置ける点がTimesFMとの大きな違いです。この記事では、4サイズの仕様を一次情報で確かめたうえで、Pythonで日次売上を予測するコード、販促予定を共変量として渡す書き方、CPUでの速度と精度の測り方、そして月商2,000万ドルを境にしたライセンス条件までを順に説明します。

まとめ：TimestralはCPUで動く時系列基盤モデルで商用可否は月商で分かれる

Timestralを試すなら、GitHubのパッケージを入れてTimestralForecasterに過去の配列を渡すだけで足ります。学習の工程は無く、CPUのノートPCでも動きます。

先に確かめるべきはライセンスです。推論コードはApache-2.0ですが、重みは別のModified MITで、前月の連結月商が2,000万ドルを超える企業は使えません。この条件に当たらない企業なら、社内サーバーや閉じたネットワークで商用に動かせます。

サイズは、自社のCPUで5Mと209Mの速度を測り、直近期間のMASEで精度を比べてから決めます。予測の理由を説明する必要がある用途はProphetを残し、系列が多く個別調整しきれない予測をTimestralへ寄せる分担が現実的です。

Timestralの4サイズとコンテキスト長・分位点・共変量の仕様を一次情報で確認

仕様の出所は、Mistral AIの公式発表とGitHubのmistralai/timestralのREADMEです。数値はいずれも2026年10月30日時点の記載です。

5M・28M・123M・209Mの重みサイズとCPU推論の速さを比べる表

4サイズは同じ構造と学習手順で作られ、パラメータ数だけが違います。Hugging Faceのリポジトリ名は、いずれもmistralai/の後ろにモデル名を付けた形です。

速度は公式発表の条件で、8スレッドのサーバーCPUで、15分間隔・3週間分の履歴から1日先を予測した値です。123Mは209Mとのスコア差が0.2%以内とされています。精度をほぼ落とさずに速くしたいなら、最初の候補は123Mです。

最大32,768点の文脈と1回1,024ステップの予測で読み書きする範囲

Hugging Faceのモデルカードによると、文脈として読めるのは最大32,768時点で、1回の推論で出せるのは1,024時点です。それより長い予測期間は、1,024時点ずつ区切り、各区間の中央値を文脈に足して続きを出します。

日次データなら約90年分を一度に読めるので、文脈の長さで困ることはまずありません。15分間隔のセンサー値でも約341日分です。超えた分は古い側から切り捨てられます。出力は0.01から0.99までの21分位点で、分位点どうしが交差しないよう作られています。

GIFT-Eval・TIME・fev-benchの1位とMistral自身の公表値の前提

モデルカードには、他社モデルと並べた次の数値が載っています。MASEとCRPSは小さいほど、skill scoreは大きいほど良い指標です。

差は1〜2%前後で、自社の売上データで同じ順位になる保証はありません。数値はMistral自身の公表で、評価に使ったfev-benchの評価コードは公開されています。採否は、後述の手順で自社データの誤差を測って決めます。

pip installからforecastまでTimestralで日次売上を予測する手順

READMEによると、動作条件はPython 3.10以上とPyTorch 2.4以上です。依存はPyTorch、NumPy、safetensors、huggingface_hubだけです。

GitHubからtimestralを入れてコミットを固定するインストール手順

2026年10月30日時点でPyPIの配布は無く、GitHubから直接入れます。

python -m venv .venv
source .venv/bin/activate
pip install "git+https://github.com/mistralai/timestral.git" pandas

リポジトリにはリリースタグが付いていません。本番に組み込むときは、URLの末尾に@とコミットIDを付けてコードの版を固定します。重みもfrom_pretrainedのrevision引数で固定でき、local_files_only=Trueを指定すればネットワークに出ずにキャッシュから読み込みます。閉じたネットワークで動かすときは、この2つをそろえる手順が必要です。

pandasの日次売上をNumPy配列に直して30日先を予測するPythonコード

店舗ごとの日次売上を持つCSVを、店舗×日付の表に直してから渡します。

import numpy as np
import pandas as pd
from timestral import TimestralForecaster

df = pd.read_csv("daily_sales.csv", parse_dates=["date"])

# 店舗×日付の表にする。記録の無い日はNaNのまま残す
days = pd.date_range(df["date"].min(), df["date"].max(), freq="D")
wide = (
    df.pivot_table(index="store_id", columns="date", values="sales", aggfunc="sum")
      .reindex(columns=days)
)
context = wide.to_numpy(dtype=np.float32)   # (店舗数, 日数)

forecaster = TimestralForecaster.from_pretrained("mistralai/Timestral-28M")
fc = forecaster.forecast(context, prediction_length=30)

median = np.asarray(fc.median)        # (店舗数, 変量, 30)
upper = np.asarray(fc.quantile(0.9))  # 発注量の上振れ側の目安

入力は(系列, 時間)の2次元でも、(系列, 変量, 時間)の3次元でも受け付けます。出力は(系列, 変量, 予測期間)の並びです。欠品を避けたい発注量なら中央値ではなく0.9分位点を基準にする、というように分位点を業務の判断に合わせて選べます。

欠損日をNaNで渡しobservation_maskで欠測を明示する入力の作り方

TimestralはNaNを欠損として扱います。補間せずに渡せる点は便利ですが、意味の違う2種類の空白を混ぜない注意が要ります。

休業日や集計漏れのように値が分からない日はNaNにします。一方、営業して売上が0だった日は0です。ここを取り違えると、売れなかった日を「不明」として扱ってしまい、需要を高めに見積もります。値は入っているが信用できない区間を欠損扱いにする方法は、入力と同じ形のobservation_maskでFalseを指定することです。欠損の見分け方と補間の比較は時系列データの前処理と欠損補間の手順にまとめています。

販促予定と曜日を既知の未来共変量として渡す多変量予測の書き方

共変量は2種類です。アクセス数のように過去にしか値が無い「過去のみの共変量」と、販促予定や曜日のように先の値も分かっている「既知の未来共変量」があります。

known_covariatesの長さを文脈＋予測期間にそろえる配列の組み立て

形をそろえる規則はREADMEに書かれています。過去のみは(系列, 共変量数, T)、既知の未来は(系列, 共変量数, T + 予測期間)です。

H = 30
B, T = context.shape
dates = pd.date_range(days[0], periods=T + H, freq="D")

# 既知の未来共変量：週末フラグと販促予定（予測期間の分まで値を持つ）
is_weekend = dates.dayofweek.isin([5, 6]).astype(np.float32)
promo = promo_calendar.reindex(dates, fill_value=0).to_numpy(np.float32)
known = np.stack([np.tile(is_weekend, (B, 1)), np.tile(promo, (B, 1))], axis=1)  # (B, 2, T + H)

# 過去のみの共変量：サイト訪問数（文脈の期間だけ）
past = sessions_wide.to_numpy(np.float32)[:, None, :]  # (B, 1, T)

fc = forecaster.forecast(
    context[:, None, :],          # (B, 1, T)
    prediction_length=H,
    past_covariates=past,
    known_covariates=known,
)

promo_calendarは日付を索引に持つ0と1の系列、sessions_wideは売上と同じ店舗×日付の表を想定しています。値がすべて0か1の既知の未来共変量は、指標として扱われる仕様です。共変量は予測の条件として読まれるだけで、共変量そのものは予測されません。

店舗区分などのカテゴリ変数をpandas.factorizeで数値コードにする手順

カテゴリは数値コードにしてcategorical_known_covariatesなどに渡します。店舗の業態のように期間中に変わらない属性なら、時間方向に同じ値を並べれば足ります。

codes, labels = pd.factorize(store_master.loc[wide.index, "format"])
cat_known = np.repeat(codes[:, None, None], T + H, axis=2).astype(np.float32)  # (B, 1, T + H)

fc = forecaster.forecast(
    context[:, None, :],
    prediction_length=H,
    categorical_known_covariates=cat_known,
)

予測対象が1変量のとき、カテゴリは系列ごとに目的変数の平均で置き換えられます（ターゲットエンコーディング）。文脈に一度も出てこないカテゴリは、その系列の平均として扱われます。新業態の店舗のように、過去に例の無い区分の効果はこの方法では拾えません。

CPUで5Mと209Mの推論時間を自社データで測りサイズを選ぶ検証手順

公式の113ミリ秒は特定のサーバーCPUでの値です。自社の環境で同じ条件を再現して測ります。

8スレッドのCPUで1日先予測のレイテンシを計測するベンチマークコード

15分間隔の3週間分は2,016点、1日先は96点です。公式発表と同じ条件で、2つのサイズを比べます。

import time
import numpy as np
import torch
from timestral import TimestralForecaster

torch.set_num_threads(8)
ctx = np.random.default_rng(0).standard_normal((1, 1, 2016)).cumsum(-1)

for repo in ["mistralai/Timestral-5M", "mistralai/Timestral-209M"]:
    model = TimestralForecaster.from_pretrained(repo)
    model.forecast(ctx, prediction_length=96)   # 初回は計測から外す
    start = time.perf_counter()
    for _ in range(20):
        model.forecast(ctx, prediction_length=96)
    ms = (time.perf_counter() - start) / 20 * 1000
    print(repo, round(ms, 1), "ms")

系列が数千本あるなら、1系列ずつではなく(系列, 変量, 時間)にまとめて渡し、全体の処理時間で比べます。夜間バッチで翌日分を出す用途なら209Mでも余裕があり、画面の操作に合わせて即時に返す用途なら5Mか28Mが候補です。

直近期間を切り出しMASEで精度を比べて採用サイズを決める基準

基盤モデルは学習しない分、自社データで当たるかを先に測ります。最後の30日を答えとして隠し、その前までで予測させます。

def mase(y_true, y_pred, y_train):
    scale = np.nanmean(np.abs(np.diff(y_train)))   # 前日の値をそのまま使う予測の誤差
    return np.nanmean(np.abs(y_true - y_pred)) / scale

train, test = context[:, :-30], context[:, -30:]
pred = np.asarray(forecaster.forecast(train, prediction_length=30).median)[:, 0, :]
scores = [mase(test[i], pred[i], train[i]) for i in range(len(train))]
print("MASE中央値:", np.nanmedian(scores))

MASEが1を下回れば、前日の値をそのまま使う単純な予測より当たっています。判断の順序は、まず5Mと209Mの差を見ることです。差が小さければ速いほうを採り、大きければ123Mを挟んで落としどころを探します。いま使っている予測があるなら、同じ30日で並べて比べます。

月商2,000万ドルの条件とTimesFM 3.0・Prophetとの使い分けの判断基準

技術的に動くことと、業務で使ってよいことは別の問題です。最後にライセンスと他の手段との線引きを整理します。

Modified MITの重みライセンスで月商2,000万ドル超が使えない条件

Hugging Faceに置かれたライセンス本文は、自社または雇用主の前月の連結月商（全世界ベース）が2,000万ドルを超える場合、このライセンスの権利を行使できないと定めています。年換算で2億4,000万ドルの規模です。制限は重みを改変・結合した派生物にも及びます。

超える企業には、Mistralへ商用ライセンスを申し込むか、Mistralのホスト型サービスを使う道が示されています。受託開発で顧客の業務システムに組み込む場合は、条文が「雇用主」に触れている以上、開発会社だけでなく運用する発注企業の月商も確認の対象と考えるのが安全です。判断がつかないときは、組み込む前にMistralへ確認します。

TimesFM 3.0・Prophetとの比較によるTimestralの採否判断

TimesFM 3.0の重みは非商用ライセンスで、商用はBigQueryなどGoogle Cloud経由に限られます。その使い方はTimesFMとBigQueryのAI.FORECASTの記事で扱いました。自社で重みを持って動かせる点では、条件を満たす企業にとってTimestralのほうが選択肢が広くなります。

見送るべきなのは、予測値の理由を分解して示す必要がある場面です。Timestralは傾向や季節性を成分に分けて返しません。その用途はProphetの仕組みと使い方を残します。予測を発注や人員配置の業務画面に組み込み、ライセンスの確認まで含めて検討する場合は、AI予測分析開発・需要予測開発で対応範囲を確認できます。

Timestralの使い方と商用利用のライセンスについてよくある質問

2026年10月30日時点の公式発表・README・モデルカードをもとに答えます。

Timestralは無料で使えますか？

推論コードはApache-2.0、重みはModified MITで、どちらも無償で入手できます。ただし重みは、自社または雇用主の前月の連結月商（全世界ベース）が2,000万ドルを超える場合は使えません。その規模の企業は、Mistralと商用ライセンスを結ぶか、Mistralのホスト型サービスを使う必要があります。月商がこれを下回る企業であれば、社内サーバーでの商用利用もライセンス上は可能です。迷う場合は、組み込む前にMistralの営業窓口へ確認してください。

TimestralはGPUがなくても動きますか？

動きます。READMEは推論にGPUは不要と明記しています。公式発表の計測では、8スレッドのサーバーCPUで1日先を予測するのに、5Mが17ミリ秒、209Mが113ミリ秒でした。GPUがある環境では、from_pretrainedにdevice="cuda"を渡すと使われます。系列が数万本あり処理時間が問題になる場合だけ、GPUを検討すれば十分です。

TimestralとTimesFMの違いは何ですか？

どちらも学習なしで予測する時系列の基盤モデルです。主な違いを比べる判断軸は、モデルを動かす場所とライセンスの条件です。TimesFM 3.0の重みは非商用で、商用はBigQueryなどGoogle Cloud経由に限られます。Timestralは月商条件を満たせば重みを自社で持って商用に動かせ、CPUだけでの推論も可能です。モデルカードの公表値ではTimestral-209MがTimesFM-3をわずかに上回りますが、差は1〜2%前後なので、自社データで誤差を比べて決めます。

Timestralは何点くらいの履歴を読めますか？

文脈として読めるのは最大32,768時点です。日次なら約90年分、15分間隔でも約341日分に相当する文脈の長さです。これを超えた分は古い側から切り捨てられます。予測は1回の推論で1,024時点まで出せ、それより長い期間は1,024時点ずつ中央値を継ぎ足して出します。短い履歴でも動きますが、曜日の波を拾わせたい日次データなら数か月分は渡したいところです。

TimestralをAPIで呼び出せますか？

2026年10月30日時点で、Mistralのモデル説明ページはTimestralを「Public Preview」としており、APIのエンドポイントや料金の記載は見当たりません。公式発表は、カスタマイズや自社環境への導入の窓口としてMistral Forgeを挙げています。現時点で手元から使う方法は、GitHubのパッケージとHugging Faceの重みでPythonから動かす形です。提供形態は変わる可能性があるため、本番の設計前に公式の案内を確認してください。

関連記事

• TimesFMとは：BigQueryのAI.FORECASTで試す時系列予測とTimesFM 3.0の多変量・共変量：BigQueryで完結させる場合の選択肢として比べるときに。
• 需要予測アルゴリズムの選び方と実装手順｜時系列・機械学習・Python：基盤モデル以外の手法も含めて選ぶときに。
• 時系列データの異常検知｜手法の選び分けとしきい値・評価・アラート運用を実装目線で解説：予測の分位点を外れ値の検知に使うときに。
• Mistral Large 4とは：1.05T MoEの仕様・API呼び出し手順・料金と自社運用の判断：同じMistralのLLMを自社運用する判断の参考に。
• 需要予測とは？AI・機械学習による手法とシステム導入の進め方を解説：予測を業務システムへ導入する進め方の全体像に。