# 時系列基盤モデルのクラウド運用応用サーベイ ## 設問 時系列基盤モデル(time series foundation model, TSFM)をクラウドの運用へ応用した論文と事例を網羅し、サーベイ論文の体裁で体系的に整理する。 ## 本サーベイのスコープ 対象は、**クラウド・IT 運用のテレメトリに対して事前学習済みモデルを適用した研究と産業事例**である。TSFM 自体の設計空間(トークン化・アーキテクチャ・目的関数・スケーリング則)は [[時系列基盤モデルの教科書]] が扱っているため、本ページでは繰り返さない。ここで問うのは「運用というドメインに持ち込んだとき何が起こったか」であり、具体的には次の4点になる。 1. どの運用タスクに適用されたか。 2. モデルはどう供給されたか(汎用モデルの転用か、運用データでの専用事前学習か)。 3. 評価に使われたデータは本番のものか。 4. 何を「良い」と測ったか。 マルチモーダル基盤モデルの**設計提案**は [[multimodal-observability-foundation-model]]、TSFM と視覚言語モデル(VLM)統合の**機構論**は [[TSFM単体とVLM統合の本質的差異]] と [[TSFM-TSMLLM-TotoQwen3VL-比較と基礎]] に譲り、本ページはそれらを参照点として引く。 --- ## 第1章 なぜクラウド運用が TSFM の応用先として選ばれたのか ### 1.1 系列数の爆発という構造的動機 本番の観測システムは数百万から数十億の異なる時系列を生成するため、系列ごとの教師あり学習は現実的でない。単一モデルを水平にスケールして低遅延・低コストの推論を提供できる TSFM が有力視されるのは、この一点に集約される([[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]])。個別業務向けモデルから TSFM への移行は、モデルと応用の関係を一対一から一対多へ変える([[時系列基盤モデルのバイアスと失敗モード]])。 ### 1.2 前史が残した運用課題 — 初期化時間 TSFM 以前、深層学習による多変量異常検知の実運用を阻んでいたのは精度ではなく**初期化時間**だった。[[@2021__USENIX-ATC__Jump-Starting Multivariate Time Series Anomaly Detection for Online Service Systems]](JumpStarter)は、圧縮センシングによって初期化 **20分**で平均 F1 **94.12%**(D1 92.29%、D2 93.26%、D3 96.79%)を達成し、OmniAnomaly の **86.51%**・MSCRED の **59.64%** を上回った。対比されたのは、OmniAnomaly と MSCRED が初期化に **86,400分**(60日)を超えて要するという事実である。8億ユーザー超のコンテンツプラットフォームを含む本番環境で、ネットワーク障害のデータベース箇所特定とソフトウェア変更のコンフィグエラー検出という2事例が報告されている。 ![[_attachments/atc21-ma/table1-comparison.png]] **表1-1**:多変量異常検知手法の比較。教師なしか、訓練データを要するか、初期化時間がどれだけかかるかという3軸で並べたもの。学習ベース手法の初期化時間が10〜100日規模になるという本文の数値がこの列に対応する。 (Source: [[@2021__USENIX-ATC__Jump-Starting Multivariate Time Series Anomaly Detection for Online Service Systems]], 表 1) 「訓練データなしで即日使える」という要求が先に立っていたことは重要である。後続の TSFM 研究とゼロショット LLM 研究が掲げる「訓練不要」という価値は、この運用要求の直系の後継として読める。 ### 1.3 文献の年代分布 本 wiki に取り込まれた交差領域の文献は、2021年の前史を除けば **2023年から2026年**に集中する。2023年に CloudOps ドメインの大規模事前学習(Salesforce)と観測データ向け予測ワークフロー(IBM)が現れ、2025年に観測ネイティブ TSFM(Datadog、Cisco/Splunk)と否定的評価(Huawei)が同時に出て、2026年に評価軸の再定義(意思決定・質問応答)とエージェント層が加わる、という三段の推移をたどる。 --- ## 第2章 分類の4軸 ### 軸A 運用タスク | タスク | 具体例 | 代表文献 | |---|---|---| | A1 需要・利用率予測 | VM/クラスタの CPU・メモリ利用率、サーバーレス関数のリクエスト需要 | Woo+2023、Toner+2025 | | A2 キャパシティ・スケジューリング判断 | HPC ジョブのランタイム推定、ISP 帯域プロビジョニング | Centile | | A3 異常検知 | KPI 多変量異常検知、性能退行検知、無線 AP 劣化検知 | ViTSD、Di Menna+2026、APEX | | A4 根本原因分析・診断 | マイクロサービスのコンポーネントランキング、伝播経路説明 | FoundRoot、TRACER | | A5 質問応答・トリアージ | インシデント対応時の時系列質問応答、アラート優先順位付け | ARFBench、TelecomTS | | A6 監視設定・アラート運用 | モニタ設定の推薦、アラート要約 | MonitorAssistant | ### 軸B モデル供給形態 | 形態 | 内容 | 代表 | |---|---|---| | B1 汎用 TSFM のゼロショット転用 | 既存の公開 TSFM をそのまま運用データへ | Toner+2025、Di Menna+2026 | | B2 運用テレメトリでの専用事前学習 | 観測メトリクスを事前学習コーパスの主成分にする | Toto、Cisco TSM、APEX、Centile | | B3 CloudOps 公開トレースでの事前学習 | クラスタトレースから構築したベンチマークで事前学習 | Woo+2023 | | B4 他ドメイン事前学習の転用 | 画像・言語で事前学習した重みを時系列へ流用 | ViTSD、VisionTS | | B5 LLM/VLM 経由 | 時系列をテキスト・画像・埋め込みとして言語モデルへ渡す | LLMAD、ChatTS、ARFBench | | B6 蒸留・軽量化 | 大モデルの知識を制約環境向けに圧縮 | RefinedEdge、APEX-Edge | | B7 エージェント層 | TSFM を行動空間の1ツールとして束ねる | ATSF、Google SRE | ### 軸C データ出自 **C1 本番テレメトリ**、**C2 公開クラスタトレース**、**C3 研究室構築・合成**の3種に分かれる。この軸は結論の外部妥当性を直接左右するため、第8章で改めて集計する。 ### 軸D 評価軸 **D1 点予測誤差**(sMAPE・MASE・CRPS)、**D2 検知性能**(F1・AUPRC)、**D3 下流の意思決定結果**(bounded slowdown・違反率)、**D4 質問応答精度**の4種。D3 と D4 は 2026年に現れた新しい軸である。 --- ## 第3章 予測とキャパシティ判断への応用 ### 3.1 CloudOps 事前学習の先駆 — Woo+2023 [[@2023__arXiv__Pushing the Limits of Pre-training for Time Series Forecasting in the CloudOps Domain]](Gerald Woo・Chenghao Liu・Akshat Kumar・Doyen Sahoo、Salesforce AI Research / Singapore Management University)は、公開クラスタトレースを予測タスクへ整形した [[CloudOps時系列予測データセット]] を導入し、そこで masked encoder Transformer を事前学習した。データ規模は azure2017 が **1,082,965,986** 観測点、borg2011 が **667,657,472**、ali2018 が **141,762,617** で、予測ホライズン **H=48**・ルックバック **L=480**、いずれも5分間隔である。 中心的な結果は、**同一コレクション内(in-collection)のゼロショットが fine-tuning と同等**という点にある。azure2017 で fine-tuning が sMAPE **0.100±0.001** / CRPS **0.095±0.001**、ゼロショットが **0.100±0.001** / **0.095±0.000**、事前学習なしが **0.140±0.011** / **0.129±0.007** だった。最大構成の Ours-xLarge(**85.1M** パラメータ)は azure2017 で sMAPE **0.080** / CRPS **0.077** に達し、次点 DeepAR の **0.110±0.001** / **0.101±0.001** に対し sMAPE で **27%**、CRPS で **24%** の削減となる。 ただし主張の範囲は狭い。ここでのゼロショットは「同一システムが生成する未知系列への転移」であり、TimeGPT-1・Chronos・TimesFM が掲げる異ドメイン汎化とは別物である。さらに Wasserstein 距離による分布シフトの定量では、pre-train と train-test の距離が azure2017 で **5.26**、borg2011 で **1.69**、ali2018 で **9.81** と、ランダム二分割の **0.077〜0.802** を一桁以上上回る。同一システム内でも分布は一致しないため、転移が効く場合それは分布の一致ではなく事前学習データの多様性による汎化と解すべきである。データセット間の距離は azure2017–borg2011 が **42.86**、borg2011–ali2018 が **10.77** に達する。 ![[_attachments/arxiv-2310.05063/fig08-pca-dataset-diversity.png]] **図3-1**:3つのクラスタトレースの統計的特徴を主成分空間へ射影したもの。azure2017 は数個のクラスタに凝集し、borg2011 は広く散り、ali2018 は薄く分布する。Wasserstein 距離で測ったデータセット間の隔たりは、この形状の違いとして現れる。 (Source: [[@2023__arXiv__Pushing the Limits of Pre-training for Time Series Forecasting in the CloudOps Domain]], 図 8) スケーリングの結論もデータセット規模に依存する。azure2017 では観測点数・モデルサイズの双方で sMAPE が単調改善する一方、borg2011 と ali2018 では事前学習の進行に伴う過学習が観察された。「スケーリングが有効」という主張は azure2017 に強く依存している。 ![[_attachments/arxiv-2310.05063/fig05-scaling-observations.png]] **図3-2**:観測点数を横軸にとった sMAPE の推移(Base / Large / xLarge)。azure2017 だけが右下がりに単調改善し、borg2011 は非単調、ali2018 は増加に転じる。スケーリングの主張が azure2017 に依存するという本文の指摘はこの3枚の差である。 (Source: [[@2023__arXiv__Pushing the Limits of Pre-training for Time Series Forecasting in the CloudOps Domain]], 図 5) ### 3.2 汎用ゼロショット TSFM の失敗 — Toner+2025 [[@2025__arXiv__Performance of Zero-Shot Time Series Foundation Models on Cloud Data]](William Toner・Thomas L. Lee ほか、Huawei Edinburgh Research Centre、ICLR 2025 の "I Can't Believe It's Not Better" ワークショップ)は、本サーベイで最も重要な否定的結果を提供する。Huawei Cloud のサーバーレス関数リクエスト需要4データセット(D1〜D4)に対し、VisionTS・TTM・TimesFM・Chronos(tiny)・Moirai(small)・Mamba4Cast の6モデルをゼロショットで評価したところ、**全12設定(4データセット × H ∈ {30, 96, 336})で基盤モデルはオンライン線形回帰またはナイーブ季節性予測器に劣った**。 最悪例は D1・H=336 の TimesFM で MASE **7.225**、対するナイーブ季節性は **2.809** であり、約2.6倍の差になる。計算コストも逆転しており、D1・H=336 で TTM が **202秒**、線形が **39秒**だった。 失敗の内訳が示す病理は2つある。第一に **Moirai の突然の崩壊**で、D2 において t-1 / t / t+1 とコンテキストが1ステップずれるだけで、t ステップの予測が「ランダムに見える」ものへ切り替わる。 ![[_attachments/arxiv-2502.12944/fig01-moirai-pathology.png]] **図3-3**:Moirai が Huawei Cloud D2 に対して出した連続3ステップ(t-1、t、t+1)の予測。コンテキストが1点ずれた t のみ予測形状が崩れる。連続性が保たれないという本文の指摘はこの並びに対応する。 (Source: [[@2025__arXiv__Performance of Zero-Shot Time Series Foundation Models on Cloud Data]], 図 1) 第二に **VisionTS のナイーブ季節性模倣**で、D1 における正規化ゼロラグ相互相関の中央値が **0.9992** に達する。クラウドデータで相対的に好成績なのは、実質的にナイーブ季節性予測器を再現しているためだと分析された。 ![[_attachments/arxiv-2502.12944/fig03-visionts-vs-seasonal.png]] **図3-4**:VisionTS の予測とナイーブ季節性予測器の重ね描き。両者がほぼ一致しており、VisionTS が直前コンテキストを写して返していることが見て取れる。相互相関中央値 0.9992 という本文の数値はこの一致度である。 (Source: [[@2025__arXiv__Performance of Zero-Shot Time Series Foundation Models on Cloud Data]], 図 3) 著者は付録で、時系列のゼロショット汎化には「no free lunch」が成り立つ——同一コンテキストに複数の妥当解がある——と論じている。この2つの失敗モードは [[時系列基盤モデルのバイアスと失敗モード]] に整理されている。 ### 3.3 評価軸の移動 — Centile と決定志向評価 [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]](Zifan Zhang ほか、North Carolina State University)は、点予測誤差が単純な last-value ベースラインに近い水準で頭打ちになりやすいという観察から出発し、[[決定志向予測評価]] を評価プロトコルとして持ち込む。**決定再生(decision replay)** は、記録された意思決定プロセスを再実行し、評価対象モデルの推定値だけをデプロイ済みの値に置き換え、到着・真の値・その他の条件は固定してスコアリングする。 ![[_attachments/arxiv-2608.01725v1/fig01-overview.png]] **図3-5**:Centile の全体像。テレメトリのエンティティが Centile に入り、その条件付き分位点出力が再生される意思決定(スケジューリング・プロビジョニング)へ流れる。評価対象が予測値そのものではなく最終的な意思決定の結果である点がこの経路に表れる。 (Source: [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]], 図 1) Centile 自体は **1.32M** パラメータ・成果物 **2.5 MiB**(bf16)という小さなモデルで、intensity-preserving attention と Student-t 混合ヘッドを持つ。富岳の本番ジョブログ F-DATA での HPC スケジューリング(EASY バックフィリングのランタイム推定)では、20,000ノード条件の平均 bounded slowdown が Centile **22.2±2.1** に対し、ユーザー見積もり **94.8**、History q90 **56.6**、Tsafrir last-2 **24.3**、GBM quantile **25.4** となった。ユーザー見積もり比で最大約 **77%** の改善である。 ここで最も示唆的なのは、23,000ノード条件で Centile が **15.5±1.1** に対し**真のランタイムを使ったスケジューリングが 28.9** だったという点である。点予測として最適であることがスケジュールとして最適であることを意味しない。 ![[_attachments/arxiv-2608.01725v1/fig02-slowdown-vs-capacity.png]] **図3-6**:キャパシティを振ったときの平均 bounded slowdown。Centile が全キャパシティで最下位(最良)にあり、真のランタイムによる参照を下回る区間が存在する。正確さと運用上の望ましさが一致しないという本文の指摘がこの交差である。 (Source: [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]], 図 2) ISP バックボーンのキャパシティプロビジョニング(CESNET-TimeSeries24)では、τ=0.9 の違反率が Centile **9.0%** に対し Chronos-Bolt のゼロショットが **13.1%**、EWMA ルールと同等の過剰供給水準で **20.5% から 9.0%** へ半減した。MASE h=1 は Centile **0.928** 対 GRU **0.958** と差が小さく、点予測指標が意思決定品質の差を隠していたことになる。キャリブレーション監査では名目カバレッジと経験カバレッジの乖離が Centile **0.07**、GRU **0.17** だった。 ![[_attachments/arxiv-2608.01725v1/fig04-provisioning-frontier.png]] **図3-7**:CESNET のプロビジョニングフロンティア。横軸の過剰供給量に対し縦軸の違反率をとると、同一の供給水準で違反率が下がる位置に Centile が乗る。点予測誤差(MASE 0.928 対 0.958)の僅差が意思決定側では倍近い差になるという本文の主張は、この曲線の間隔として読める。 (Source: [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]], 図 4) クロスドメイン転移(ネットワークとクラウド VM のテレメトリで事前学習し HPC へ)では、6時間予算での平均 bounded slowdown が scratch **83.0 ± 36.0** に対し transfer **35.9 ± 1.3** となる。推論はバッチ **4.2ms**・単発 **7.7ms**(4コア CPU)で、学習は A30 1基で約5分である。 ### 3.4 隣接する解法 — 予測せずに生成する [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production]](Peking University / Alibaba Group)は TSFM 論文ではないが、プロビジョニング問題への別解として対比に値する。Alibaba Cloud Model Studio の4か月・12モデル・**35.4億**リクエストを特性化し、到着過程と入出力長分布のパラメトリック生成でベンチマークを構成する。P99 TTFT=2.25s・TBT=0.5s の条件で、素朴な生成が **12インスタンス**(必要数の50%過小)と見積もるのに対し ServeGen は **25**(4%過剰)だった。需要を予測するのではなく、需要の統計構造を再現してキャパシティを検証する路線である。 ### 3.5 観測データ向け予測ワークフローの先行例 [[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]](IIT Bombay / IBM Research、IAAI-24 採録)は、AutoEncoder によるチャネル圧縮の事前学習と TSMixer の fine-tuning を組み合わせ、Biz-KPI と IT イベントの混在した多変量系列を予測する。 ![[_attachments/arxiv-2310.20280/fig01a-automixer-framework.png]] **図3-8**:AutoMixer の二段階ワークフロー。Step 1 でチャネル圧縮 AutoEncoder を事前学習し、Step 2 でその重みを TSMixer backbone へ引き継いで end-to-end に微調整する。データセットごとに AutoEncoder を作り直すという本文の制約は、この Step 1 が個別に置かれている構造に対応する。 (Source: [[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]], 図 1a)SOTA 比で平均 MSE **11%** 改善、全ベースライン比で **15%** 改善、PCC は **2倍**向上した。下流タスクでは Application の Biz-KPI 予測 MSE **0.0937**(TSMixer-CC 比 **19.2%** 改善)、IT イベント分類 **77.82%**(TSMixer-CC **33.92%**)である。 ただし評価データは4種すべて合成の BizITObs であり、実運用検証は結論部で今後の課題とされている。またデータセットごとに AutoEncoder を個別に事前学習する構成のため、自然言語・画像の基盤モデルのような単一モデルの多用途転用にはなっていない。「基盤モデル的なワークフロー」と「基盤モデル」の区別が必要な例として位置づけられる。 --- ## 第4章 観測ネイティブ TSFM — 産業界による専用事前学習 ### 4.1 観測データはなぜ一般の時系列と違うのか 3社の技術報告が挙げる特性を統合すると、次の7点になる。 1. **非定常性・裾の重さ・スパース性・スパイク**(Datadog) 2. **数桁にわたる値域スパン** — arcsinh 変換の動機(Datadog Toto 2.0) 3. **高カーディナリティの多変量性** — BOOM の系列あたり variates 中央値は **60** 4. **年齢依存の多解像度保持** — 細かいデータは期限切れで粗い要約へ集約される(Cisco/Splunk) 5. **長期に持続する過去パターン** — 既存 TSFM の 512〜4,096点というコンテキスト制約が「観測のようなドメインでは致命的」(Cisco/Splunk) 6. **バースト性とゼロ過剰、プロトコル層をまたぐ結合**(Cisco APEX) 7. **ヒストグラム型・分布型データ、複合季節性、不規則ステップ、非均一サンプリング** — 汎用時系列の鋳型に押し込むと情報が失われる(Datadog Toto 2.0) この差は統計量の分布として測れる。 ![[_attachments/arxiv-2505.14766/fig5-comparison.png]] **図4-1**:観測ベンチマーク BOOM と汎用ベンチマーク GIFT-Eval・LSF の統計量分布の比較(First-Lag ACF、ARCH-LM 統計量、スペクトルエントロピー、KPSS 統計量、Flat Spots、歪度)。BOOM だけが広く裾を引いた形になる。上記1〜3で挙げた非定常性・裾の重さ・スパイクは、この6枚の裾の伸びとして現れる。 (Source: [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]], 図 5) ### 4.2 Toto と BOOM — 観測データを主成分にした最初の公開 TSFM [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]](Datadog AI Research と Carnegie Mellon University、計19名、NeurIPS 2025)は、[[Toto]](**151M** パラメータ)と観測ドメインベンチマーク [[BOOM]] を同時に提示した。 事前学習コーパスは約 **2.36兆**点(非重複・非合成では **1.59兆**点)で、そのうち **43%** が Datadog プラットフォームの匿名観測メトリクスである。ここで重要なのは**顧客データを除外し自社内部監視のみを使う**という制約で、BOOM の評価データも同様に自社内部監視に限られ、さらに訓練データとの汚染を避けるため別のステージング環境から取得されている。BOOM は **2,807系列**・**32,887 variates**・約 **3.5億**点である。 アーキテクチャは decoder-only transformer、パッチサイズ **P=64**、コンテキスト **L=4096**、埋め込み次元 **D=768**。観測データ向けの工夫は4点で、パッチ単位の causal instance normalization(Welford 法、クリッピング κ=10)、proportional factorized attention(time-wise ブロック11個に variate-wise ブロック1個の 11:1 構成)、Student-T 混合ヘッド、そして複合ロバスト損失(λ=0.57)である。 BOOM では MASE **0.617** / CRPS **0.375** / Rank **2.369** と全指標で首位に立ち、次点 Moirai-Base 比で MASE **13.1%**・CRPS **12.4%** の改善、Rank は **2.369 対 4.328** となった。汎用ベンチマーク GIFT-Eval でも MASE **0.673** で首位、CRPS **0.437** で TEMPO の **0.434** に次ぐ2位である。観測特化が汎用性能を犠牲にしていないことを示す点でこの2つ目の数値が効いている。 限界として、固定間隔の仮定、欠損点のヒューリスティック補完、カレンダー特徴の未組み込みが挙げられている。異常検知機能は持たず予測専用である。 ### 4.3 Toto 2.0 — スケーリングと公開データの完全排除 [[@2026__arXiv__Toto 2.0 - Time Series Forecasting Enters the Scaling Era]] と [[@2026__Datadog__Toto-2.0-Time-Series-Forecasting-Enters-the-Scaling-Era]] は、4M / 22M / 313M / 1B / 2.5B の5サイズ構成へ拡張する。コーパスの変化が示唆的で、総点数が **2.36兆 → 5.04兆**、内部観測データが **1.00兆(42.4%) → 2.14兆(42.5%)** と比率を保つ一方、合成データが **33% → 57.5%** に増え、**公開予測データセットは 24.6% から 0% へ完全に排除**された。時間スケールの多様化として、5分以上間隔の比率が **5.0% → 35.3%** に上がっている。 BOOM の CRPS rank は 2.5B **3.88**、1B **3.96**、313M **4.26**、22M **5.53**、4M **7.17** で、Toto 1.0 が **6.94**、Chronos-2 が **7.39** である。**22M が Toto 1.0(151M)の7分の1のパラメータで同等性能**という結果は、観測ドメインでのスケーリング則の存在を裏づける。汚染耐性ベンチマーク TIME でも 2.5B **3.43** / 1B **3.51** / 313M **4.38** と上位3位を占めた。 ![[_attachments/arxiv-2605.20119/fig1-model.png]] **図4-2**:主要 TSFM の CRPS rank とパラメータ数の関係(左が BOOM、右が GIFT-Eval)。Toto 2.0 ファミリーの5点だけが右下へ単調に下り、他モデルは規模に対して順位が乱れる。「すべてのサイズが1つ下のサイズを上回る」という本文の主張はこの単調性である。 (Source: [[@2026__arXiv__Toto 2.0 - Time Series Forecasting Enters the Scaling Era]], 図 1) 設計変更は Student-T 混合ヘッドから **9分位ピンボール損失**への切り替え、Contiguous Patch Masking(c_max=16、p_max=0.4)、NorMuon オプティマイザ、robust arcsinh 正規化である。 ![[_attachments/arxiv-2605.20119/fig2-architecture.png]] **図4-3**:Toto 2.0 のアーキテクチャと学習・推論プロトコル。左が Contiguous Patch Masking を適用する学習側、右がモデル本体の構成である。上記の設計変更のうち可変長の連続パッチマスクと分位点ヘッドが、この2枚の対応関係として示される。 (Source: [[@2026__arXiv__Toto 2.0 - Time Series Forecasting Enters the Scaling Era]], 図 2)著者らは今後の課題として、古典的手法とのギャップ(外挿整合性・不確実性の較正)、データキュレーションの体系化(事前学習では公開データ 0% が最適だが fine-tuning では 45% が最適という直感に反する結果)、メトリクスを独自モダリティとして扱うこと、マルチモーダル統合を挙げる。 ### 4.4 Cisco Time Series Model — 多解像度で長期構造を掴む [[@2025__arXiv__Cisco Time Series Model Technical Report]](Cisco / Splunk)は **500M** パラメータの decoder-only モデルで、TimesFM 2.0 からの継続事前学習(CPT)として構築される。学習データ **300B** 点超のうち **51.5%** が観測ドメイン由来(1分解像度 35% + 5分解像度 16.5%)で、供給元は Splunk Observability Cloud のメトリクスサブシステム、約 **4億系列**・**13か月**分である。 特徴は**多解像度入力**で、粗い解像度(512時間・1時間解像度)と細かい解像度(512分・1分解像度)を比 **K=60** で同時に受け取り、細かい解像度で **128分**先を出力する。特殊トークンと解像度埋め込みで両者を区別する。「直近の詳細(timeliness)と長期構造(accuracy)のトレードオフ」を取るという設計思想が、観測メトリクスの年齢依存ロールアップという実装事情に直接対応している。 ![[_attachments/arxiv-2511.19841/fig3-architecture.png]] **図4-4**:解像度埋め込みと特殊トークンの配置。粗い解像度と細かい解像度のパッチ列が1本の入力に連結され、どちらに属するかを埋め込みとトークンが示す。単一解像度モデルへ単に連結する CONCAT との違いはこの区別の有無である。 (Source: [[@2025__arXiv__Cisco Time Series Model Technical Report]], 図 3) 観測データ(1分解像度・コンテキスト512)では MAE **0.4788**(次点 Chronos-2 **0.6023**)、MASE **0.4569**(次点 TimesFM-2.0 **0.6722**)、CRPS **0.4126**(Chronos-2 **0.4878**、Toto 1.0 **0.4932**)である。GIFT-Eval の non-leaking サブセットでも MAE **0.6980** 対 TimesFM-2.0 **0.7119**、CRPS **0.5508** 対 **0.5680** と上回る。限界としては、遅い変化点・短コンテキスト・高揮発性系列での劣化、3解像度以上への未拡張が挙げられている。公開重みは preview 版である。 ### 4.5 APEX — 「専用が転用に勝る」のデータ効果としての証明 [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations]](Cisco Systems)は、約 **4,500** の実運用無線ネットワーク、約 **10万件**の AP 時系列(AP あたり **34** メトリクス)から DHCP 因果連鎖の **10チャネル**多変量テレメトリのみを使い、30分間隔で decoder-only transformer を事前学習する。APEX-Large が **269M**、APEX-Edge が **10.5M** パラメータである。 192ステップ(4日間)の DHCP 劣化予測では、APEX-Large が MAE **2.98** / RMSE **4.61** / MAPE **3.1%** で、最強の汎用ベースライン Toto の **3.64** / **5.52** / **3.8%** に対し MAE で **12〜18%** の改善、SARIMA の **4.82** に対し **38%** の削減となる。 論文がこの差を「アーキテクチャの違いではなく、ネットワークネイティブな事前学習というデータ効果」に帰する根拠は明快で、**APEX と Toto はいずれも decoder-only transformer** だという点にある。汎用 TSFM の事前学習コーパスにはエンタープライズネットワークテレメトリが含まれていない。[[Centile]] が HPC・ネットワークプロビジョニングで示した知見に、無線ネットワーク運用という別ドメインでの定量的な追認が加わったことになる。 もう1つの貢献は**予測と異常検知の単一チェックポイント統合**である。推論時にも dropout を有効にしたまま **N=50** 回の確率的フォワードパスでアンサンブルを構成し、P5/P95 分位点で予測区間と異常フラグの両方を同一モデルから得る。多変量設定の F1 は APEX-Large **0.93**(適合率 0.93 / 再現率 0.94)、APEX-Edge **0.89**、Toto の P5/P95 **0.85** で、線形手法 VAR-Mahalanobis の **0.94** に迫る。追加パラメータなしで不確実性が得られるため、リソース制約下のエッジで「予測モデル + 別の検知モデル」という二重配備を避けられる。 ![[_attachments/arxiv-2606.11553/fig01-apex-pipeline.png]] **図4-5**:APEX のパイプライン。クラウド側のオフライン事前学習と AP 上でのエッジ推論という2フェーズに分かれ、後者が生テレメトリを送らずアラートだけを返す。単一チェックポイントで予測と異常検知を兼ねるという設計は、この推論側が1つのモデルで済んでいる点に対応する。 (Source: [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations]], 図 1) 配備設計も具体的で、約 **40MB** の APEX-Edge を AP 上に置き、生テレメトリ約 **130MB/日**の伝送を約 **1KB/日**のアラートへ置き換える。ただしエッジレイテンシは Raspberry Pi 5 を代理とした実測(96ステップ予測で約 **202ms**)であり、量産 AP SoC 上でのサブ秒推論は「成立する可能性を示唆する」という留保つきの主張である。異常ラベルも人手アノテーションではなく3手法以上の多数決によるコンセンサス擬似正解である。 ### 4.6 Falcon-X — 異種多変量の汎用モデルという別路線 [[@2026__arXiv__Falcon-X - A Time Series Foundation Model for Heterogeneous Multivariate Modeling]](Ant International)は **591M** パラメータの encoder-only モデルで、Unified Prototype Diff-Attention と Variate Reassembly Router により異種物理量の意味的アライメントを狙う。GIFT-Eval 全体で **0.666 MASE / 0.453 CRPS** と首位、fev-bench では **0.652 / 0.490** で Chronos-2 の **0.645 / 0.485** に僅差の2位である。 事前学習の web ドメインに alibaba_cluster_trace・azure_vm_traces・borg_cluster_data といったクラウド運用系列を含み、fev-bench には BOOM の部分集合 BOOMLET が入る。ただし観測特化の論証はなく、SRE/AIOps の下流タスクへの寄与は未評価である。「クラウド運用データを学習に含む汎用モデル」と「運用のために設計されたモデル」の中間に位置する。 ### 4.7 理論側からの裏づけと緊張 [[@2026__arXiv__Position - The Inevitable End of One-Architecture-Fits-All-Domains in Time Series Forecasting]](Tsinghua University / Princeton University)は、ドメイン特化への転回を理論と実務の両面から正当化する。近似誤差の下界 **O(1/√T)**(Kuznetsov & Mohri 2014)により自然言語・画像のスケーリング則は時系列予測へ適用できず、追加ドメインデータが性能を却って悪化させうると論じる。TFB のデータセットでは交通・電力が約 **200,000** タイムスタンプに達する一方、株式・医療など4ドメインは **2,500以下**にとどまる。 ![[_attachments/arxiv-2602.01736/fig2-dataset.png]] **図4-6**:TFB(左)と ModernTCN が使う一般的な予測タスク(右)のドメイン別タイムスタンプ総数。対数軸に GPT-1(約10.7億トークン)と GPT-2(約100億トークン)の学習データ量が水平線で重ねられており、どのドメインも数桁下にある。言語のスケーリング則をそのまま持ち込めないという本文の論拠がこの隔たりである。 (Source: [[@2026__arXiv__Position - The Inevitable End of One-Architecture-Fits-All-Domains in Time Series Forecasting]], 図 2) Optiver(3,225チーム)・Jane Street(4,085チーム)の上位解法はいずれも特徴量エンジニアリングと伝統的機械学習の組み合わせで、汎ドメインの時系列ニューラルネットワークを使っていない。 ただしこの主張は Toto 2.0 が観測ドメイン内で示したスケーリング則の実証と部分的に緊張する。両者を整合的に読むなら「ドメインをまたぐスケーリングは効かないが、ドメイン内のスケーリングは効く」という限定になるが、この読み方を明示的に検証した研究は本 wiki にはまだない。 --- ## 第5章 異常検知への応用 ### 5.1 汎用 TSFM のゼロショットは最良にならない [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]](University of L'Aquila)は、Chronos と TSPulse をゼロショットで運用メトリクスの異常検知に適用した。データは AIOPS(29系列、長さ 17,568〜299,053点、実インシデントラベル)と MSCloud(Microsoft、67系列、レイテンシ・可用性・クラッシュ率)で、いずれも本番由来である。著者は訓練シーケンスを一切使わないという基盤モデルに不利な設計を明示的に選んでいる。 検知の仕組みは予測残差の閾値判定である。 ![[_attachments/2026_Unknown_Leveraging_Time_Series_Foundation_Models/fig01-chronos-residual-example.png]] **図5-1**:Chronos の予測を残差ベース検知器として使う例。予測区間から外れた区間が異常候補として立ち上がる。ゼロショット TSFM が異常検知器になるのは「予測して残差を見る」というこの一段を挟むためである。 (Source: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]], 図 1) 閾値調整後の AIOPS では最良が LSTM-AD の F1 **0.78** で、Chronos が **0.76** の2位、TSPulse は **0.42** と大きく劣る。MSCloud では最良が Isolation Forest の **0.79** で Chronos が **0.68**。調整前では AIOPS の最良が VAE(AUC-PR **0.33** / F1_best **0.41**)、Chronos が **0.25** / **0.31** である。推論コストは TSPulse が約 **3 ms/点**、Chronos が **1.1 ms/点**超に対し、ベースラインはいずれも **0.1 ms/点**未満だった。 ![[_attachments/2026_Unknown_Leveraging_Time_Series_Foundation_Models/table02-adjusted-f1best.png]] **表5-1**:閾値調整後の F1_best・適合率・再現率(AIOPS と MSCloud)。基盤モデル行(Chronos・TSPulse)が訓練済みベースライン群の中位から上位に入るが最上位には届かない。「同等の域には入るが最良にはならない」という本文の結論はこの順位である。 (Source: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]], 表 2) 結論は明快である。**ゼロショット TSFM は訓練済み手法と同等の域には入るが、最良にはならない**。ゼロショットというハンデを考えれば注目に値するが、精度と推論コストの両面で置き換えを正当化する水準にはない。 ### 5.2 他ドメイン事前学習の転用 — ViTSD [[@2024__OJCS__Large Pretrained Foundation Model for Key Performance Indicator Multivariate Time Series Anomaly Detection]](Xu Wang・Kele Xu ほか、National University of Defense Technology)は、画像で事前学習した ViT-B/16 を [[KPI異常検知]] へ転用する。時系列とコンピュータビジョンで共通する**パッチ化**を接点に Transformer エンコーダをほぼそのまま流用し、次元ごとの特徴抽出ヘッドを個別に持ちながらバックボーンを共有する構成を採る(パッチ長10・stride 10・窓100、時間領域と FFT 振幅のパッチを連結)。 ![[_attachments/Large-Pretrained-Foundation-Model-for-Key-Performance-Indicator-Multivariate-Time-Series-Anomaly-Detection/fig02-vitsd-architecture.png]] **図5-2**:ViTSD の構成。時間領域のパッチと FFT 振幅のパッチを次元ごとの線形射影で埋め込んで連結し、重みを凍結した ViT-B/16 の Transformer エンコーダへ通して再構成する。画像モデルを転用できる接点がパッチ化であるという本文の説明は、この入力側の変換に集約される。 (Source: [[@2024__OJCS__Large Pretrained Foundation Model for Key Performance Indicator Multivariate Time Series Anomaly Detection]], 図 2) F1 は SMD **89.04**、PSM **98.06**、MSL **94.84**、SMAP **96.47**、SWaT **96.78** で、PSM と SWaT では最高だが SMD・MSL・SMAP では2位である。SMD では Anomaly Transformer の **90.33** に僅差で及ばない。事前学習の有無で SMD・PSM の F1 が約 **4ポイント**改善するという内訳は、転用の効果自体は実在することを示す。 ![[_attachments/Large-Pretrained-Foundation-Model-for-Key-Performance-Indicator-Multivariate-Time-Series-Anomaly-Detection/fig05-reconstruction-error.png]] **図5-3**:事前学習パラメータを読み込んだ場合と読み込まない場合の再構成誤差。SMAP を除く全データセットで読み込んだ側が低く、SWaT では約46%の差になる。画像で得た重みが時系列の再構成にも効くという主張の直接の証拠である。 (Source: [[@2024__OJCS__Large Pretrained Foundation Model for Key Performance Indicator Multivariate Time Series Anomaly Detection]], 図 5)著者自身がこの研究を「予備的な探索」と位置づけている。MSL のような55次元の高次元 KPI で伸び悩む現象は、チャネル独立特徴抽出の次元数スケーラビリティに起因するのか別要因なのか分離されていない。 ### 5.3 蒸留によるエッジ配備 — RefinedEdge [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]](Nankai University / Alibaba Cloud / Microsoft / Tsinghua University)は基盤モデルを使わないが、「大きなモデルの知識を制約環境へ運ぶ」という点で本サーベイの射程に入る。クラウドで TimesNet(**7M**)を集約訓練し、アンサンブルプルーニングと知識蒸留を経てエッジ用の **0.12M** 学生モデルへ落とし、さらにエッジ側で個人化 fine-tuning を行う。 ![[_attachments/Bridging_Edge_and_Cloud_A_Knowledge-Enhanced_Framework_for_Efficient_Time_Series_Anomaly_Detection/fig01-refinededge-overview.png]] **図5-4**:RefinedEdge の全体構成。集約圧縮・知識精製・エッジとクラウドの相互更新の3モジュールが、N 台のエッジデバイスとクラウドの間を24時間周期で循環する。概念ドリフトへの追随はこの逆方向の矢印(エッジ→クラウド)が担う。 (Source: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]], 図 1) F1 は産業パートナーの EdgeNode(200エッジ × 25メトリクス)で **0.9588**、SMD **0.9274**、MSL **0.8827**、SMAP **0.8580**。エッジのみで訓練した場合の **0.5534** / **0.8591** / **0.8291** / **0.6480** を大きく上回り、SMD では**パラメータ 1.7% で 7M のクラウド訓練モデルを超える**。エッジ推論は **220〜310 ms/窓**で、エッジ訓練モデルの **2,013〜2,701 ms/窓**より速い。24時間周期の逆方向知識蒸留により概念ドリフトへ追随する。 ### 5.4 LLM 経路 — 推論時に使うか、訓練時だけ使うか **推論時に使う設計**の代表が [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]](LLMAD、Microsoft 中心)である。GPT-4 を fine-tuning せずに用い、FastDTW ベースの文脈内学習(正例2件・負例1件)と AnoCoT(判定ルール・異常タイプ・アラーム定義を組み込んだ3段推論)で、KPI・WSD・Yahoo の3データセット平均 Best F1 **0.759** を達成し、TFAD の **0.725** を上回った。文脈内学習の効果は大きく、WSD が **0.512 → 0.711**、KPI が **0.711 → 0.843**、Yahoo が **0.574 → 0.724** と改善する。説明の正解率(any-hit)は WSD **0.900** / KPI **0.790** / Yahoo **0.930**。コストは年間 **$65.70** だが1リクエスト **14.91秒**を要し、著者自身が限界として「リアルタイム要件には適さない」と明記する。 ![[_attachments/Liu-et-al.-2024---Large-Language-Models-can-Deliver-Accurate-and-Interpretable-Time-Series-Anomaly-Detection/fig2-overview.png]] **図5-5**:LLMAD の全体像。系列検索で選んだ正例・負例を文脈内事例として与え、AnoCoT の3段推論を経て異常判定・異常タイプ・アラームレベルを JSON で返す。推論のたびに LLM を呼ぶという構造が、14.91秒という応答時間の由来である。 (Source: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]], 図 2) **訓練時だけ使う設計**が [[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models]](Microsoft Research)である。Detection / Repair / Review の3エージェントが訓練時に Python の検知ルールを生成し、**推論時には LLM を一切呼ばない**。 ![[_attachments/arxiv-2501.14170/fig2-dataset.png]] **図5-6**:KPI データセットの2メトリクス(da403 と 1c35d)と、それぞれに対する手動ルール・LLM 生成ルールの F1。単一の手動閾値では一方を合わせるともう一方が崩れる(threshold=3 で 0.99 と 0.17)のに対し、メトリクスごとに生成したルールは 0.99 と 0.91 を両立する。ルールをメトリクス単位で書き起こす動機がこの非両立性である。 (Source: [[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models]], 図 2・表 1)Event-F1(PA)は KPI **0.897**(LSTMAD **0.819**、**+9.5%**)、Yahoo **0.810**(TFAD **0.773**、**+4.8%**)、Microsoft 社内 AI 訓練プラットフォームの実データで **0.936**(LSTMAD **0.724**、**+28.3%**)である。推論レイテンシは最良ベースライン比で KPI **3.0倍**、Yahoo **34.3倍**、社内 **1.5倍**速く、訓練50反復の合計費用は **$10未満**にとどまる。 ARGOS のもう1つの要点は **Aggregator による退行の封じ込め**である。Aggregator なしでは KPI の3メトリクス・Yahoo の2メトリクスで最大 **32%** の精度退行が生じるのに対し、既存の本番検知器と LLM 生成ルールを融合することで**退行ゼロを保証**する。既存検知器を置き換えず補完するという設計判断が、本番投入の敷居を下げている。また推論時に LLM を使う方式(LLMAD・SigLLM)が10試行で一致ゼロだったのに対し、ARGOS は決定論的である。 ### 5.5 物理接地とゼロショット推論の型 — TRACER [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]](Peking University)は都市交通が対象でクラウド運用ではないが、**方法論の型としては転用可能**である。運動学的波理論による双方向トレースと Granger 検定で構造化された証拠を先に構築し、そこへ訓練不要の LLM(Gemini-3)の並列推論とコンセンサス融合を重ねる。 型としての要点は、生の系列をそのまま LLM へ渡さず、物理と統計で証拠を構造化してから推論させる順序にある。 ![[_attachments/2026_Unknown_TRACER_Physics_Guided_Causal_Evidence/fig01-paradigm-comparison.png]] **図5-7**:診断パラダイムの比較。既存手法が観測から直接診断へ飛ぶのに対し、TRACER は物理接地した因果証拠の構築を中間層として挟む。訓練不要の LLM でゼロショット診断が成立する理由はこの中間層である。 (Source: [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]], 図 1)Hit@1 **83.98%**、Hit@3 **95.98%**、MRR@3 **90.21%** で、Granger-Agent の **63.30%** に対し相対 **32.7%** の改善である。推論時間は **23.93秒**(Granger-Agent **167.50秒**、**85.7%** 削減)、1診断 **$0.041**。ルールベースのみ(LLM なし)では MRR@3 **79.40%** にとどまり、LLM 融合が必要だと示される。ノイズ σ=0.20 での劣化は Hit@1 最大 **-9.8%** で、Granger-Agent の **-31.9%** より頑健である。定量評価はシミュレータ構築のベンチマークに限られ、実測データ(PeMS-BAY-2022)は定性的ケーススタディ4件のみである。 ### 5.6 事前学習表現が常に効くわけではない — アラートトリアージ [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]](École Polytechnique de Montréal)は Mozilla Firefox の性能テストアラート(5,655系列、17,989生アラートから 3,912サマリ、陽性 633件)を対象に、CatBoost と141特徴で AUPRC **0.851**、P@50 **0.920** を達成する。注目すべきは否定的結果で、**事前学習済み fastText 埋め込みを加えた構成は 0.831 にとどまり、非テキストのハイブリッド 0.851 を上回らなかった**。運用テキストへの事前学習表現の投入が自明に効くわけではないことを示す小さな反例である。 ![[_attachments/2026_Unknown_Performance_Alert_Triage_Time_Aware/fig02-feature-importance.png]] **図5-8**:最終モデルの特徴量重要度。上位を占めるのは多スケールの時系列統計量とアラートのメタデータであり、テキスト由来の特徴は寄与が小さい。事前学習済み埋め込みを足しても AUPRC が上がらなかったという結果は、この重要度の偏りと整合する。 (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]], 図 2) --- ## 第6章 診断・質問応答・エージェント層 ### 6.1 根本原因分析の基盤モデル化 — FoundRoot [[@2026__ICSE__FoundRoot - Towards Foundation Model for Root Cause Analysis via Structured Deep Thinking]](Tsinghua University / ByteDance / Nankai University)は DeepSeek-R1-Distill-Qwen2.5-14B を初期化として、構造化された深層思考でゼロショット [[根本原因分析]] を行う。MRR は held-out 4データセットで **0.569**(+48.6%)、**0.610**(+43.2%)、**0.858**(+2.9%)、**0.931**(+4.5%)、Top-1 の改善は **+68.9%** と **+116.5%** に達し、古典手法の Top-1 は最大 **15.9%** にとどまる。 ![[_attachments/foundroot_camera_ready/fig05-structured-deep-thinking.png]] **図6-1**:FoundRoot の入出力形式。`<think>` タグに構造化深層思考の推論トレースが、`<answer>` タグにコンポーネントのランキングと伝播経路の説明が入る。入力側のメトリクスがテキストとして並んでいる点が、次段落で述べる制約の実装上の表れである。 (Source: [[@2026__ICSE__FoundRoot - Towards Foundation Model for Root Cause Analysis via Structured Deep Thinking]], 図 5) 本サーベイの文脈で重要なのは、**FoundRoot がメトリクス値をテキスト形式に変換して LLM へ入力し、時系列エンコーディングを明示的にスコープ外としている**点である。TSFM を使わずに RCA の基盤モデルを名乗る構成であり、時系列表現の改善が RCA 精度にどう効くかは空白のまま残る。失敗33件の内訳では **45.5%** がメトリクススキャンで、**51.5%** が伝播分析で最初の誤りを起こしており、前者は時系列理解の弱さに直結する。著者は絶対精度の低いデータセットがあることから、これを完全自動化ではなく意思決定支援と位置づけている。 ### 6.2 インシデント対応の質問応答 — ARFBench [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]](Carnegie Mellon University / Datadog AI Research / AWS)は、**本 wiki 内で最も本番性の高い評価データ**を持つ。Datadog 内部テレメトリの **63件の本番インシデント**(2025年3月7日〜30日)、**142系列**、**538万点**から **750問**の多肢選択問題を構成する。 ![[_attachments/arxiv-2604.21199/fig2-model.png]] **図6-2**:ARFBench の Tier 別の問題例。Tier I が異常の有無、Tier II が期待挙動からの逸脱量、Tier III が2系列間の先行・遅行関係を問う。系列にはデータセンターや Kubernetes デプロイメントといったタグ由来の名前が付き、キャプションとして与えられる。 (Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], 図 2) 結果は3つの層で読める。第一に、最強の汎用モデル GPT-5 が精度 **62.7%** / macro-F1 **51.9%** にとどまる。第二に、Toto の埋め込みを variate embedding MLP で時間集約し VLM 空間へ射影した **Toto-1.0-QA-Experimental** が精度 **63.9%** / F1 **48.9%** で全モデル中最良となり、GPT-5 を **1.2ポイント**上回る。第三に、各問題で最良のモデルを選べる Model-Expert Oracle が精度 **87.2%** / F1 **82.8%** に達し、単一モデルとオラクルの間に **20ポイント**超の余地が残る。 検証可能報酬による強化学習(RLVR)は SFT 後の **48.4%** から精度 **+15.4ポイント**を積んだ。最難関は複数系列の因果推論を要する Tier III で、最良でも F1 **48.4%** である。 ![[_attachments/arxiv-2604.21199/fig3-figure.png]] **図6-3**:多変量として見ないと異常が成立しない例。1本だけを文脈から切り離すと平坦で異常に見えないが、構造化された多変量のまとまりの中では異常と判定される。Tier III が全モデルで最難となる理由はこの相対性にある。 (Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], 図 3)この「予測ヘッドを捨てて中間表現を VLM へ差し出す」設計の含意は [[TSFM単体とVLM統合の本質的差異]] に整理されている。制約としては、緩和推奨や自由形式の問いがなくシングルターン質問応答に限られること、単一ベンダのテレメトリであることが挙げられる。 ### 6.3 マルチモーダル観測データセット — TelecomTS [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]](Johns Hopkins University / Yale University)は **32,000**サンプル × **128**ステップ × **18** KPI、**11**種の異常タイプ、**2,210,185** の質問応答インスタンスを提供する。ただしデータは研究室構築の 5G ネットワーク(OpenAirInterface・USRP・Pixel UE)で、実ジャマーと合成異常の混成であり本番テレメトリではない。 ![[_attachments/arxiv-2510.06063/fig1-overview.png]] **図6-4**:TelecomTS のデータ収集から下流タスクまでの流れ。アクセスネットワーク上のアプリケーションとジャマーから、カテゴリ変数・高頻度・低頻度・バースト性という異なる性質の測定値が集まり、ネットワーク記述とログを併せて異常検知・RCA・質問応答へ供給される。異なるスケールの共変量が混在するというデータ特性は、この測定値の4分類に対応する。 (Source: [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]], 図 1) 3つの知見が本サーベイに効く。第一に**絶対スケールの保持が効く**。非正規化メトリクス埋め込み(NME)の追加で Autoformer の RCA 精度が **0.280 → 0.584**(**+30.4ポイント**)、Informer の異常検知 F1 が **0.451 → 0.852**(**+0.401**)と改善した。第二に **LLM は適合率で崩れる**。再現率 0.84〜1.0 に対し適合率 0.17〜0.26 で、正常な急変動を偽陽性として拾う。第三に**マルチモーダル統合が単純には効かない**。異常検知 F1 は Mantis **0.800**、Toto **0.615** に対し Toto+Qwen-3-4B が **0.487** で、統合したことでかえって下がる。RCA 精度では Toto **0.848** 対 Toto+Qwen-3-4B **0.826** と拮抗する。タスクによって統合の損得が逆転することになる。 ### 6.4 時系列と言語のアライメント — ChatTS [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]](Tsinghua / ByteDance / BizSeer)は Qwen2.5-14B-Instruct に5層 MLP のパッチ埋め込みを差し込み、値を保持する正規化(min-max にスケールとオフセットをテキストで併記)を採る。訓練は完全合成で **44,802** の質問応答である。 ![[_attachments/p2385-xie/fig3-overview.png]] **図6-5**:ChatTS の全体像。属性から系列を合成する経路と、パッチ埋め込みを言語モデルのトークン列へ差し込む経路が示される。テキスト化せず埋め込みで渡す構成が、入力トークンを40分の1に抑えるという本文の数値の由来である。 (Source: [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]], 図 3)AIOps・気象・NAB・Oracle DB の実データ525問では categorical **0.889** / numerical **0.788** で、GPT-4o の画像入力(**0.609** / **0.436**)を上回り、推論タスク全体で **0.667** 対 GPT-4o テキスト **0.530**。入力トークンは **0.08M** 対 GPT-4o テキスト **1.3M** で約 **40分の1**、コストは **$0.02** 対 **$3.25** である。テキストのみの版は多変量でほぼ回答不能だった。 ### 6.5 推論としての異常診断 — Time-RA [[@2026__ACL Findings__Time-RA - Towards Time Series Reasoning for Anomaly Diagnosis with LLM Feedback]] は約 **40,000** サンプル・**10ドメイン**(AIOps を含む)の RATs40K を構築し、検知・カテゴリ分類・因果推論テキストを一体で扱う。fine-tuning した Qwen2.5 は多変量 F1 が約 **0.85**、単変量が約 **0.90** で、専門家評価は単変量 **4.04〜4.58**/5.0、多変量 **4.08〜4.28**/5.0。ただし SFT は複雑な多変量シナリオで停滞または微後退し、視覚表現の分類への寄与はモデル依存だった。 ### 6.6 マルチモーダル LLM の限界 [[@2025__arXiv__Can Multimodal LLMs Perform Time Series Anomaly Detection]](WWW 2026 採択)は、粒度が細かくなるほどマルチモーダル LLM が崩れることを示す。 ![[_attachments/arxiv-2502.17812/fig1-workflow.png]] **図6-6**:VisualTimeAnomaly の評価手順。数値系列を画像へ変換し、点別・範囲別・変量別それぞれのプロンプトとともにマルチモーダル LLM へ渡す。粒度ごとに問い方を変えているため、次に述べる粒度別 F1 の差がそのまま比較可能になっている。 (Source: [[@2025__arXiv__Can Multimodal LLMs Perform Time Series Anomaly Detection]], 図 1) 最大 F1 は点別 **4.09%**、範囲別 **50.33%**、変量別 **63.40%**。数値推論の限界として **9.11 > 9.9** という誤判定が観察された。一方でエージェント構成(TSAD-Agents)は点別 F1 **65.4%** で Isolation Forest の **62.1%** を上回る。ハルシネーションは入力形式に強く依存し、LLaVA でテキスト入力 **98.3件**が画像入力 **21.7件**へ減る。従来手法が汚染率上昇で点別 F1 を **38.86 → 20.57**(**47%** 低下)と落とすのに対し、Gemini は範囲別 F1 が **30.34 → 30.39** とほぼ不変で、頑健性という別の価値軸を示す。 ### 6.7 エージェント層 — TSFM を道具として束ねる [[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting]](University of Science and Technology of China)は [[エージェント型時系列予測]] を提唱し、予測を知覚・計画・行動・省察・記憶の反復プロセスとして再定義する。既存 TSFM は行動空間の1ツールに格下げされる。 ![[_attachments/arxiv-2602.01776/fig1-workflow.png]] **図6-7**:エージェント型時系列予測のワークフロー。知覚で入力を取り込み、計画・行動・省察が記憶を介して循環し、予測結果が意思決定支援へ流れる。予測モデルは下段の外部ツール群のうち Predictive Modeling Tools として置かれ、系の中心ではない。 (Source: [[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting]], 図 1)定量的な実験を持たないポジションペーパーだが、モデル中心の予測が抱える4限界(静的性・閉鎖的動作・シングルパス・経験蓄積の欠如)の指摘は、運用の文脈では特に重い。運用では予測が単発で終わらず、アラート・調査・緩和という後続の行動へ連鎖するためである。 ### 6.8 産業事例 — Google SRE における TimesFM [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]] は、[[TimesFM]] を異常検知に使い**静的閾値からの脱却**を図ると述べる。適用範囲は RCA に閉じず、(1) 信頼性設計のプレイブック改善、(2) 異常検知とアラート(TimesFM + 自律アラートハンドラ)、(3) IMAG へのエージェント的オーケストレーション層、(4) インシデント調査と緩和、(5) AI Insights によるリスク管理の5領域に及ぶ。定量的な性能数値は公開されていない。原則として「AI ベースの自律システムは強力だが非決定的」であるため自律度(L0〜L4)で測る必要があるとし、既存の自動化で十分な領域は置き換えないと明示している。この5領域の広がりは [[agentic SRE]] に整理されている。 ### 6.9 AIOps サーベイ側からの視点 [[Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations]](Nankai University / Tsinghua University ほか)は、ログ・メトリクス・イベントにわたる12の AIOps タスクを70本の代表論文で整理する。重要なのは3つの留保である。第一に **Transformer は万能ではなく**、低遅延の異常検知では畳み込みネットワークや再帰型ネットワークが実用的である。第二にトレースはグラフ構造のため Transformer と相性が悪く研究が手薄である。第三にベンチマークにはデータリーク・主観的採点・静的データセットの実運用乖離という問題がある。AIOPSLAB では GPT-3.5-TURBO の正解率が **15.25%** にとどまる。 同論文は Transformer の役割を自律度の階段として整理する。 ![[_attachments/TOSEM26-WhyTransformer/fig08-evolving-roles.png]] **図6-8**:AIOps における Transformer の役割の3段階。低自律性の Intelligent Pattern Modeler、意思決定支援の Context-Aware Task Solver、閉ループ自律の Autonomous Ops Agent と上がる。第6章で扱った予測・質問応答・エージェント層は、それぞれこの3段に対応づけて読める。 (Source: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 8 Open Challenges and Future Directions]], 図 8) ### 6.10 隣接する応用 — 監視設定の推薦 [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] は TSFM を使わないが、時系列と言語を結ぶ別の設計を示す。Fast Shapelet Discovery で抽出した代表的時系列断片の形状類似度(Shape-Based Distance)と、LLM が出力する記述情報の類似度を平均した統一類似度でモニタ設定を推薦する。時系列類似度で上位 N に絞ってから LLM を呼ぶ2段構成が、呼び出しコストの制御という実用性を担保している。 --- ## 第7章 組織別の実配備状況 | 組織 | 成果物 | 運用データ | 配備の段階 | |---|---|---|---| | Datadog | [[Toto]] 1.0/2.0、[[BOOM]]、Toto-1.0-QA-Experimental | 自社内部監視のみ(顧客データ除外)、訓練は本番・評価はステージング | 重みとベンチマークを Apache 2.0 で公開。製品への本番配備の明示的記述はない | | Cisco / Splunk | Cisco TSM(500M) | Splunk Observability Cloud 約4億系列・13か月 | preview 版の重みを公開 | | Cisco | APEX-Large / APEX-Edge | 約4,500の実運用無線ネットワーク | AP へのエッジ配備を設計。レイテンシは代理ハードウェアでの実測 | | Salesforce AI Research | CloudOps 事前学習モデル、[[CloudOps時系列予測データセット]] | Azure/Borg/Alibaba の公開クラスタトレース | 研究成果としてデータセットを公開 | | Huawei | 否定的評価 | Huawei Cloud サーバーレス関数の需要4データセット | 評価のみ。基盤モデル採用を支持しない結論 | | Microsoft | ARGOS、LLMAD、MSCloud データ | 社内 AI 訓練プラットフォームの実メトリクス | ARGOS は既存の本番検知器を補完する設計 | | Google | TimesFM を用いた異常検知、AI Insights、IMAG のエージェント層 | Google 内部本番 | 本番運用中と表明。定量値は非公開 | | ByteDance | FoundRoot、ChatTS | 公開ベンチマークと合成 | 研究成果を公開 | | Ant International | [[Falcon-X]] | 汎用7ドメイン(クラウド運用系列を含む) | コード公開、重みは未公開 | | Alibaba Cloud | RefinedEdge(共同)、ServeGen | EdgeNode 200エッジ(非公開)、Model Studio 35.4億リクエスト | 産業パートナー環境で検証 | | IBM Research | AutoMixer | 合成 BizITObs のみ | 実運用検証は今後の課題 | --- ## 第8章 横断的な発見 ### 発見1 「専用が転用に勝る」は3組織で独立に確認された Datadog(Toto の BOOM 首位)、Cisco/Splunk(観測データで Chronos-2・TimesFM-2.0 を上回る)、Cisco(APEX が Toto に MAE で12〜18%差)が、それぞれ別のドメインで同じ結論に到達している。決定的なのは APEX の論証で、**APEX と Toto がいずれも decoder-only transformer** であるため、差はアーキテクチャではなくデータに帰せられる。Centile も HPC とネットワークで同方向の結果を出した。運用テレメトリを事前学習コーパスの主成分に据えるという選択が、現時点で最も確実な性能源である。 ### 発見2 汎用ゼロショット TSFM はクラウド需要予測で単純ベースラインに負けうる Toner+2025 の **12設定全敗**は、この分野で最も重い否定的結果である。VisionTS が相互相関 **0.9992** でナイーブ季節性を模倣し、Moirai がコンテキスト1ステップのずれで崩壊するという内訳は、集約指標の順位表からは決して見えない。TSFM を運用に持ち込む前に、対象ドメインでナイーブ季節性とオンライン線形回帰を測ることが最低限の作法になる。 ### 発見3 異常検知における TSFM 優位は未確立 予測では専用事前学習の利得が明確なのに対し、異常検知では様相が異なる。ゼロショット TSFM は「訓練済み手法と同等だが最良ではない」(Di Menna+2026)、画像事前学習の転用は「概ね優位だが常に最高ではない」(ViTSD)。一方で最も高い本番数値を出したのは、**推論時に LLM を使わない** ARGOS(社内データで **+28.3%**)であり、次が **GPT-4 を推論時に使う** LLMAD(3データセット平均 Best F1 **0.759**)である。TSFM の予測残差を検知に流用する路線が、専用検知器や LLM 生成ルールを置き換える段階には来ていない。 ### 発見4 評価軸が点予測から意思決定と質問応答へ移った 2026年の2本が評価軸そのものを問い直している。Centile の決定再生は、MASE h=1 で **0.928 対 0.958** という僅差が bounded slowdown では **22.2 対 56.6** の差になることを示し、さらに**真のランタイムを使ったスケジューリングが最適でない**(23,000ノードで **28.9** 対 Centile **15.5**)という反直観的な事実を掘り出した。ARFBench は「予測精度」ではなく「エンジニアの問いに答えられるか」を測り、最良でも **63.9%**、オラクルとの差が **20ポイント**超残ることを明らかにした。運用における TSFM の価値は、予測誤差の小ささでは測りきれない。 ### 発見5 本番テレメトリで評価された研究はごく少数 本サーベイが扱った文献のうち、本番テレメトリで評価したものは ARFBench(Datadog の63インシデント)、BOOM(Datadog 内部監視)、ARGOS(Microsoft 社内)、LLMAD と ViTSD の一部データ(KPI・WSD・SMD・PSM)、Di Menna+2026(AIOPS・MSCloud)、RefinedEdge(EdgeNode)、Cisco TSM(Splunk)、APEX(実運用 AP)、Centile(富岳・CESNET)、Toner+2025(Huawei Cloud)にとどまる。TelecomTS は研究室構築、FoundRoot と TRACER の定量評価は公開ベンチマークと障害注入・シミュレーション、AutoMixer と ChatTS の訓練データは合成である。ベンチマーク上の順位が本番の運用改善にどう写るかという問いは、依然として開いている。 ### 発見6 予測ヘッドを捨てる設計が質問応答で最良となった ARFBench の Toto-1.0-QA-Experimental は、**予測ヘッドの手前の埋め込みを VLM へ差し出す**という構成で、汎用最強モデルを **1.2ポイント**上回った。TelecomTS の NME(非正規化メトリクス埋め込み)が RCA を **30.4ポイント**押し上げた事実と合わせると、鍵は**絶対スケールを含む数値構造の保持**にある。値を文字列化すればトークナイザが桁構造を壊し、画像化すれば解像度が潰れる。ただし TelecomTS の異常検知では統合がかえって性能を下げており(**0.615 → 0.487**)、タスク依存の損得が残る。 ### 発見7 予測と検知の統合か分離か APEX は MC-dropout で単一チェックポイントから予測区間と異常フラグの両方を得て、エッジでの二重配備を避けた。多変量 F1 **0.93** は線形の VAR-Mahalanobis **0.94** に迫る。一方で Toto・Cisco TSM・Falcon-X はいずれも予測専用である。リソース制約が厳しい環境では統合の価値が大きく、中央集約型では専用検知器との併用が優勢という分岐が見える。 ### 発見8 集中リスクという新しい運用課題 一対一だったモデルと応用の関係が一対多になることで、TSFM のバイアスと失敗モードは単一の応用に留まらず全ての下流応用へ波及する **集中リスク(concentration risk)** を持つ([[時系列基盤モデルのバイアスと失敗モード]])。ベンチマークの集約指標は個々の系列パターンに対する挙動を示さないため、体系的な特定にはパラメータ化された合成生成器への介入という因果的検証が要る。運用の文脈では、単一の TSFM が予測・検知・キャパシティ判断を同時に支えたとき、その失敗モードが同時に複数の運用判断を誤らせる形になる。 --- ## 第9章 未解決の問い 1. **ドメイン内スケーリングとドメイン間スケーリングの分離。** Toto 2.0 が観測ドメイン内で示したスケーリング則と、Position ペーパーが理論的に否定するドメイン横断のスケーリングは、「ドメイン内では効く」という限定で整合するはずだが、これを明示的に検証した研究はない。 2. **決定志向評価の一般化。** [[決定志向予測評価]] のプロトコルを汎用 TSFM(Chronos・TimesFM・[[Toto]])へ適用した研究はまだない。オートスケーリング・障害対応の優先度付けといった、HPC スケジューリングとネットワークプロビジョニング以外の意思決定への拡張も未着手である。 3. **クラウド需要スパイクへの脆弱性の範囲。** Toner+2025 が観測した脆弱性が、観測メトリクスで事前学習した Toto や Cisco TSM でも成立するかは未検証である。同論文はサーバーレス関数需要という単一ドメインしか扱っていない。 4. **CloudOps データセットのコレクション間転移。** azure2017・borg2011・ali2018 の3データセット間 Wasserstein 距離(最大 **42.86**)を踏まえると、単純な混合事前学習では負の転移が生じる可能性がある。原論文が今後の課題として明示的に対象外としている。 5. **異常検知で TSFM が最良になる条件。** ゼロショットでは最良にならないことが示されたが、fine-tuning・コンテキストの与え方・多変量化のいずれが効くかは切り分けられていない。Di Menna+2026 は訓練データ50%を意図的に未使用とした。 6. **時系列表現の改善が RCA 精度へどう効くか。** FoundRoot はメトリクスをテキスト化し時系列エンコーディングをスコープ外とした。失敗の **45.5%** がメトリクススキャン段階で起きているため、TSFM 埋め込みの導入が効く余地がある。 7. **マルチモーダル統合の損得の条件。** TelecomTS では Toto+Qwen-3-4B が異常検知で Toto 単体に劣り(**0.487 対 0.615**)、RCA では拮抗した(**0.826 対 0.848**)。一方 ARFBench では統合が最良である。どのタスク特性が統合の利得を決めるかは未整理である。 8. **オラクルギャップの縮小。** ARFBench の Model-Expert Oracle **87.2%** と単一最良 **63.9%** の差は、モデル選択・アンサンブル・ルーティングのいずれで埋まるのか。 9. **エッジ配備の実測。** APEX-Edge のレイテンシは Raspberry Pi 5 を代理とした値であり、量産 AP SoC 上での検証が残る。異常ラベルもコンセンサス擬似正解である。 10. **本番運用改善の因果的証拠。** ベンチマーク順位と本番の運用改善(MTTR・アラート疲れ・オンコール負荷)を結ぶ研究は本 wiki にない。Google SRE の事例は定量値を公開していない。 --- ## 第10章 文献一覧 | 文献 | 年 | 会議・刊行物 | 組織 | タスク(軸A) | 供給形態(軸B) | データ(軸C) | 評価(軸D) | |---|---|---|---|---|---|---|---| | [[@2021__USENIX-ATC__Jump-Starting Multivariate Time Series Anomaly Detection for Online Service Systems\|JumpStarter]] | 2021 | USENIX ATC | Tsinghua / Nankai | A3 | 前史(事前学習なし) | C1 | D2 | | [[@2023__arXiv__Pushing the Limits of Pre-training for Time Series Forecasting in the CloudOps Domain\|Woo+2023]] | 2023 | arXiv | Salesforce / SMU | A1 | B3 | C2 | D1 | | [[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data\|AutoMixer]] | 2023 | arXiv / IAAI-24 | IIT Bombay / IBM | A1 | B2 相当(個別事前学習) | C3 | D1 | | [[@2024__OJCS__Large Pretrained Foundation Model for Key Performance Indicator Multivariate Time Series Anomaly Detection\|ViTSD]] | 2024 | IEEE OJCS | NUDT | A3 | B4 | C1 | D2 | | [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models\|MonitorAssistant]] | 2024 | ESEC/FSE | — | A6 | B5 | C1 | D2 | | [[@2025__arXiv__Performance of Zero-Shot Time Series Foundation Models on Cloud Data\|Toner+2025]] | 2025 | ICLR 2025 Workshop | Huawei | A1 | B1 | C1 | D1 | | [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models\|Toto / BOOM]] | 2025 | NeurIPS | Datadog / CMU | A1 | B2 | C1 | D1 | | [[@2025__arXiv__Cisco Time Series Model Technical Report\|Cisco TSM]] | 2025 | arXiv | Cisco / Splunk | A1 | B2 | C1 | D1 | | [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection\|LLMAD]] | 2025 | KDD | Microsoft | A3 | B5 | C1 | D2 | | [[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models\|ARGOS]] | 2025 | arXiv | Microsoft Research | A3 | B5(訓練時のみ) | C1 | D2 | | [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection\|RefinedEdge]] | 2025 | IEEE TSC | Nankai / Alibaba Cloud | A3 | B6 | C1 | D2 | | [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning\|ChatTS]] | 2025 | VLDB | Tsinghua / ByteDance | A5 | B5 | C3 | D4 | | [[@2025__arXiv__Can Multimodal LLMs Perform Time Series Anomaly Detection\|MLLM-TSAD]] | 2025 | arXiv / WWW 2026 | IIT / Emory ほか | A3 | B5 | C3 | D2 | | [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives\|Centile]] | 2026 | arXiv | NC State | A2 | B2 | C1 | D3 | | [[@2026__arXiv__Toto 2.0 - Time Series Forecasting Enters the Scaling Era\|Toto 2.0]] | 2026 | arXiv | Datadog / CMU | A1 | B2 | C1 | D1 | | [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations\|APEX]] | 2026 | arXiv | Cisco | A1 + A3 | B2 + B6 | C1 | D1 + D2 | | [[@2026__arXiv__Falcon-X - A Time Series Foundation Model for Heterogeneous Multivariate Modeling\|Falcon-X]] | 2026 | arXiv | Ant International | A1 | B2(汎用) | C2 | D1 | | [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems\|Di Menna+2026]] | 2026 | ICPE Companion | L'Aquila | A3 | B1 | C1 | D2 | | [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features\|Alert Triage]] | 2026 | ICPE Companion | Polytechnique Montréal | A5 | B5(否定的) | C1 | D2 | | [[@2026__ICSE__FoundRoot - Towards Foundation Model for Root Cause Analysis via Structured Deep Thinking\|FoundRoot]] | 2026 | ICSE | Tsinghua / ByteDance | A4 | B5 | C2 + C3 | D2 | | [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response\|ARFBench]] | 2026 | arXiv | CMU / Datadog / AWS | A5 | B5 + B2 | C1 | D4 | | [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis\|TelecomTS]] | 2026 | ICML | JHU / Yale | A3 + A4 + A5 | B1 + B5 | C3 | D2 + D4 | | [[@2026__ACL Findings__Time-RA - Towards Time Series Reasoning for Anomaly Diagnosis with LLM Feedback\|Time-RA]] | 2026 | ACL Findings | Oxford ほか | A3 + A4 | B5 | C1 + C3 | D2 | | [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis\|TRACER]] | 2026 | KDD | Peking University | A4 | B5 | C3 | D2 | | [[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting\|ATSF]] | 2026 | arXiv | USTC | A1 | B7 | — | — | | [[@2026__arXiv__Position - The Inevitable End of One-Architecture-Fits-All-Domains in Time Series Forecasting\|Ma+2026]] | 2026 | arXiv | Tsinghua / Princeton | — | — | — | — | | [[Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations|Why Transformers]] | 2026 | ACM TOSEM | Nankai / Tsinghua | 全般 | 全般 | 混在 | 全般 | | [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations\|Google SRE]] | 2026 | Google Cloud Blog | Google | A3 + A4 + A5 | B7 | C1 | 非公開 | | [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production\|ServeGen]] | 2026 | NSDI | Peking / Alibaba | A2(隣接) | 該当なし | C1 | D3 相当 | --- ## 付録 数値引用時の注意 - 本ページの数値はすべて各ソースページの記載に依拠する。原論文の版差(arXiv v1 と最終版)で数値が変わる場合があるため、論文へ引用する際は必ず原典を確認する。 - ベンチマーク間で指標の定義が揃っていない。BOOM と GIFT-Eval の CRPS、異常検知の F1(point-adjust 有無)、Event-F1(PA)はいずれも直接比較できない。特に point-adjust を伴う異常検知の F1 は値が大きく出る傾向がある。 - 「TSFM が SOTA」という表現は、対象ベンチマークと評価軸を明示しない限り意味を持たない。発見3と発見4がその理由である。 ## 関連 - [[時系列基盤モデルの教科書]] — TSFM の設計空間・アーキテクチャ・スケーリング則。本ページはその応用面を担う。 - [[時系列基盤モデル]] — 定義と横断的知見。 - [[時系列基盤モデルのバイアスと失敗モード]] — 発見2と発見8の根拠。 - [[CloudOps時系列予測データセット]] — 第3章1節の詳細。 - [[決定志向予測評価]] — 発見4の評価プロトコル。 - [[KPI異常検知]]・[[時系列異常検知ベンチマーク]]・[[異常検知]] — 第5章の周辺。 - [[時系列質問応答]] — 第6章2節の周辺。 - [[エージェント型時系列予測]] — 第6章7節の枠組み。 - [[multimodal-observability-foundation-model]] — 本サーベイの発見6を踏まえた設計提案。 - [[TSFM単体とVLM統合の本質的差異]]・[[TSFM-TSMLLM-TotoQwen3VL-比較と基礎]] — 発見6の機構論。 - [[AIOps]]・[[agentic SRE]] — 運用側の枠組み。