はじめに — モデル選択という沼
時系列予測に取り組むと、誰もが一度は次のような壁にぶつかります。「PatchTST と FlowState、どちらを使うべきか」。産業系の滑らかな信号に強いモデルが、ノイズの多い小売需要や長い季節性ホライズンでは振るわない、ということは珍しくありません。結局のところ最適なモデルは系列とタスクに依存し、それを一つひとつ検証するコストは馬鹿になりません。
IBM Research が公開した Granite Timeseries Ensemble は、この「選択の苦痛」を解消することを目的としています。アーキテクチャの異なる4つの Granite モデルを1つのレシピにまとめ、追加学習やアンサンブル重みのフィッティングなしで中央値と分位点の予測を返す構成です。気象予報で複数モデルをアンサンブルして予測レンジを見るのと同じ発想ですね。
インストールから実行まで5分
まず granite-tsfm をインストールし、Hugging Face から推奨4モデルレシピを読み込みます。
pip install "granite-tsfm>=0.3.11"
import pandas as pd
from tsfm_public.models.ensemble.modeling_ensemble import QuantileEnsembleForecaster
# ETT データセットを読み込み（サンプル用時系列データ）
df = pd.read_csv(
"https://raw.githubusercontent.com/zhouhaoyi/ETDataset/main/ETT-small/ETTh1.csv",
parse_dates=["date"],
)
# 事前学習済みアンサンブルレシピをロード（重み統合ではなく設定のみ保存）
ensemble = QuantileEnsembleForecaster.from_pretrained(
"ibm-granite/granite-timeseries-ensemble-r1",
)
# 予測を実行
result = ensemble(
df.tail(1024),
timestamp_column="date",
target_columns=["OT"],
context_length=1024,
prediction_length=24,
)
print(result.prediction_outputs) # ポイント予測
print(result.quantile_outputs) # 分位点予測（デフォルト 0.1〜0.9）
ここで重要なポイントがあります。このレシピはモデル重みを統合したものではなく、設定のみを保存しています。実行時に4つのメンバーチェックポイントをランタイムでダウンロードするため、初回実行は時間がかかる点にご注意ください。
result.prediction_outputs は中心予測値、result.quantile_outputs は分位点予測値です。0.1 と 0.9 の分位点を使えば、名目上80%カバレッジの予測区間を構成できます。
デフォルトレシピに含まれる4モデル
| モデル | アーキテクチャ |
|---|---|
| Granite PatchTST-FM-r1 | Patched Transformer |
| Granite PatchTST-FM-r2 | Patched Conformer |
| Granite FlowState-r1.1 | State-space model |
| Granite TTM-r3 | Tiny Time Mixers (MLP mixer) |
4つのアーキテクチャがトレンド・季節性・局所変動をそれぞれ異なる方法で捉えるため、誤差が重複しにくいのがアンサンブルの要点です。
Probabilistic と IQR — どちらを使うべきか
2つのレシピの違いは重みの付け方にあります。
Probabilistic Ensemble（推奨デフォルト）
- 4メンバーに均等な影響力を付与
- 確率空間で分位点をプーリングし、要求された分位点を抽出
- 重みが固定のためフィッティング工程も、チューニングすべきハイパーパラメータもなし
「予測結合パズル（forecast combination puzzle）」として知られる現象があり、ポイント予測では推定重みを使う複雑な手法よりも単純な等重み結合のほうが堅牢なケースが多いとされています。このレシピはその考え方を確率予測に適用したものです。
IQR Ensemble（適応型の代替）
- 各メンバーの**予測分布の広がり（spread）**に応じて重み付け
- 区間が狭いメンバーほど影響力が大きい
- サンプル・ターゲット・予測ホライズンごとに重みが変化
- Isotonic regression により結合分位点の交差を防止
# IQR レシピに切り替えるには subfolder のみ変更
ensemble = QuantileEnsembleForecaster.from_pretrained(
"ibm-granite/granite-timeseries-ensemble-r1",
subfolder="recipes/granite-iqr",
)
⚠️ 注意点: 区間が狭いからといって、必ずしも正確あるいは適切にキャリブレーションされた予測とは限りません。IQR 重み付けは過信（overconfident）なメンバーを優遇するリスクがあります。実験する場合は temperature（値が高いほど均等重みに近づく）と、単一メンバーの重み上限（cap）を調整してください。
GIFT-Eval ベンチマーク結果（97構成、2026年10月20日時点）
| Forecast | MASE ↓ | MASE Rank ↓ | CRPS/MWQL ↓ | CRPS Rank ↓ |
|---|---|---|---|---|
| Granite Ensemble R1 — Prob | 0.683★ | 47.175★ | 0.471 | 50.948 |
| Granite Ensemble R1 — IQR | 0.684 | 48.773 | 0.471 | 47.619★ |
| Granite PatchTST-FM-r2 | 0.685 | 51.371 | 0.467★ | 48.918 |
| Granite FlowState-r1.1 | 0.701 | 66.474 | 0.490 | 69.485 |
| Granite PatchTST-FM-r1 | 0.717 | 74.794 | 0.488 | 68.134 |
| Granite TTM-r3 | 0.724 | 83.062 | 0.520 | 88.959 |
★ は各指標の最良値。低いほど良い。
結果を見ると、両アンサンブルとも4つの個別モデルより集計 MASE と平均 MASE Rank で優れています。Prob アンサンブルは MASE 0.683 で PatchTST-FM-r2（0.685）をわずかに上回ります。ただし CRPS/MWQL では PatchTST-FM-r2 が依然として最小であり、IQR アンサンブルは CRPS Rank で最良という点が興味深いところです。集計誤差と平均順位が異なる選択を示唆しているわけです。
本質は「リーダーボード1位」ではなく、**どのようなデータが来ても事前にモデルを選ばずに済む堅牢性（robustness）**にあります。MASE の差が小さいということは、裏を返せば「最適メンバーを事前に知らなくても同等以上の精度が得られる」という実務的価値が大きいということです。
実務適用前に必ず確認したいポイント
1. 日本国内の開発現場での適用文脈
日本の SI・金融系の現場では、推論コストとレイテンシに特に敏感です。このアンサンブルは4つのチェックポイントを同時にロードするため、単一モデルと比較してメモリと推論時間が概ね4倍程度に増加します。バッチ処理の予測パイプラインであれば問題ありませんが、リアルタイムダッシュボードや API レスポンスに組み込む場合は、必ずランタイムとメモリを測定した上で導入可否を判断してください。オンプレミス環境であれば、モデルキャッシュのパスを事前に確保しておくことも忘れずに。
2. この技術の限界と注意事項
- チャネル独立予測: 現行レシピは多変量チャネルを互いに独立に予測します。チャネル間の相関（例: 電力需要と気温）を活用できないという意味です。
- メンバースペックの不一致: メンバーごとに context limit、予測ホライズン、前処理、欠損値処理の方式が異なります。
- キャリブレーションの保証なし: どちらの集計方式も分布シフト（distribution shift）下でのキャリブレーションを保証しません。デプロイ後も継続的なモニタリングが必須です。
- ライセンス: デフォルトの4メンバーは permissive ライセンスですが、リポジトリの拡張レシピには IBM Research のチェックポイントが含まれ、非商用・研究用途の制限が付きます。各モデルカードを必ず確認してください。
3. 自社データでバックテストする方法
GIFT-Eval は広範なベンチマークですが、集計的な改善がすべての時系列に当てはまる保証はありません。実務では次の順序で検証してください。
- ユースケースとの整合性: 各予測時点で実際に利用可能なデータのみで履歴ウィンドウを構成
- 同一条件での比較: Prob アンサンブル、IQR アンサンブル、強力な単一メンバー（PatchTST-FM-r2 など）を同じウィンドウで比較
- ポイント誤差以外の評価: MASE に加えて分位点損失、0.1〜0.9 区間の実測カバレッジ（名目80%）を確認
- コスト測定: ランタイムとメモリを記録し、4モデル統合の利得がコストを正当化するか判断
4. 次の学習ステップ
- Forecaster インターフェースの拡張: デフォルトの4つの Granite モデル以外に、ドメインに合った互換モデルをメンバーとして追加してみてください。ダウンストリームの予測フォーマットはそのまま維持されます。
- 時系列の基礎固め: アンサンブルを理解するには、MASE、CRPS、分位点回帰の概念を先に押さえるのがおすすめです。
- 実践的なコード感覚: ターミナルでの高速プロトタイピングに慣れたい方は、Gemini 3 Flash CLI 活用記事も参考になります。
- フロントエンド可視化: 予測結果をダッシュボードで見せる予定なら、CSS rotateX() 3D 変形ガイドのような UI 表現手法も押さえておきましょう。
まとめ
Granite Timeseries Ensemble は、「どのモデルを選べばいいのか」という問いを「まずこれで始めて、必要ならチューニングしよう」に変えてくれる実用的なツールです。リーダーボード首位を狙うモデルではなく、どのようなデータに投げてもまずまずの結果を返すデフォルト値という点にこそ真価があります。導入前のバックテストとコスト測定、この2点だけは忘れないようにしてください。