センサー x LLM でのマルチモーダル化 〜 センサーデータを LLM に入力し異常検知レポート作成させてみた
本文の状態
日本語全文を表示中
詳細モードで約33分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
ABEJA Tech Blog
ABEJA の坂井氏は、物理世界の情報を扱うフィジカル AI 実現に向けて必須となるセンサーデータと LLM のマルチモーダル化を研究し、時系列データを直接入力する手法や画像変換・TSFM を介した手法の精度を実証比較している。
AI深層分析を開く2026年7月31日 23:11
AI深層分析
キーポイント
フィジカル AI とセンサー x LLM の重要性
ABEJA は、温度や振動などの物理世界情報を基盤モデルが扱えるようになり、AGI やフィジカル AI 実現に向けた「知覚」部分の汎用化が必須であると主張している。
センサーデータ入力の多様な系統
研究では、時系列データをプロンプトで直接入力する手法や、画像化して VLM で処理する手法、さらに TSFM（Chronos や TSPulse）を介して LLM に渡す手法の 3 つの系統を定義している。
NAB データを用いた精度検証
坂井氏は Numenta Anomaly Benchmark (NAB) のセンサーデータを使用し、前述した各入力方式における異常検知レポート作成の精度を実際に比較検証している。
実用化に向けた実験的アプローチ
この研究は ABEGA Platform 開発の一環として行われた個人的な勉強の手始めであり、異なる方式のメリット・デメリットを明らかにすることで実装指針を示すことを目的としている。
センサー×LLMのマルチモーダル化手法分類
センサーデータをLLMに入力する方法は、プロンプト直接入力、画像化してVLMへ入力、TSFMを介した間接入力、特化型モデル、およびエージェントによるツール統合の5系統に分類される。
重要な引用
LLM のマルチモーダル化は、この数年で テキスト → 画像 → 動画 → 音声 という風に扱えるモダリティをどんどん広げてきました。
個人的には、この流れの次に重要になるのはセンサーデータも含めたマルチモーダル化だと考えています。
物理世界の情報」を基盤モデルが直接あるいは間接的に扱えるようになると、現実世界を観測して物理世界での意思決定・行動するタイプの AI ——いわゆるフィジカル AI—— の中核である「知覚」の部分を、汎用モデルで一気通貫に扱える可能性が出てきます。
今回の記事では(a), (b), (c) それぞれの方式で実際に動かしてみて方式毎の精度比較しようと思います。(d) の特化型 LLM に関しては別記事で別途取り扱う予定です。
編集コメントを表示
編集コメント
ABEJA が示すように、テキストや画像だけでなくセンサーデータを扱う能力は、AI が物理世界と相互作用する上で不可欠な要素となっている。本記事で提示された多様な入力手法の比較は、実務レベルでのシステム設計において貴重な知見となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
こんにちは！ABEJA で ABEJA Platform 開発や AI 関連の研究開発業務を行っている坂井（@Yagami360）です。
LLM のマルチモーダル化は、この数年で テキスト → 画像 → 動画 → 音声 という風に扱えるモダリティをどんどん広げてきました。個人的には、この流れの次に重要になるのはセンサーデータも含めたマルチモーダル化だと考えています。温度・振動・電力・加速度・生体信号などのような「物理世界の情報」を基盤モデルが直接あるいは間接的に扱えるようになると、現実世界を観測して物理世界での意思決定・行動するタイプの AI ——いわゆるフィジカル AI—— の中核である「知覚」の部分を、汎用モデルで一気通貫に扱える可能性が出てきます。そしてこのことは、AGI（汎用人工知能）やフィジカル AI 実現に向けて必須の流れだと思ってます。
またフィジカルAIと聞くとまずロボティクスをイメージするかと思いますが、さらにその先にヘルスケア・農業・自然など人間や世界環境を含めた物理世界の AI 化が進んでいくと思っており、そのファーストステップとしてセンサー x LLM でのマルチモーダル化が必須になると思ってます。
この記事では、センサー x LLM でのマルチモーダルの個人的な勉強の手始めとして、まずは様々な方式でセンサーデータを LLM に入力してみて、方式毎の精度比較してみます。
- センサーデータ × LLM でのマルチモーダル化の系統
- 各方式の精度検証
使用するセンサーデータ：NAB [Numenta Anomaly Benchmark]
- 系統 (a)：センサー時系列データをプロンプトで直接入力
- 系統 (b)：センサー時系列データを画像化 → VLM
- 系統 (c-1)：センサー時系列データを TSFM（Chronos）に入力 → LLM
- 系統 (c-2)：センサー時系列データを TSFM（TSPulse）に入力 → LLM
- 各系統の精度比較
- まとめ
- We Are Hiring!
センサーデータ × LLM でのマルチモーダル化の系統
センサーデータを LLM に「入力」する方法やセンサー × LLM でのマルチモーダル化のやり方は、主に以下の系統に分類できるかと思っています。*1
系統
センサーを LLM にどう渡すか
代表手法
位置づけ
(a) センサー時系列データをプロンプトで直接入力
センサーデータの時系列をテキスト化してプロンプトに入れる
SigLLM / LLMAD / LLMTime
最軽量だが長い時系列データに弱い。厳密にはマルチモーダル化とは呼ばないことが多い認識
(b) センサー時系列データを画像化 → VLM
折れ線グラフ画像にして、vLLM などの画像でのマルチモーダル化したモデルに入力する
TAMA / AnomLLM / ChatTS
画像のマルチモーダル能力（vLLM）をそのまま転用。
(c) センサー時系列データを TSFM に入力 → LLM
TSFM（時系列基盤モデル）がセンサーデータの時系列を処理し、LLM にはその結果だけを渡す（間接入力）
Chronos, TSPulse など
センサー時系列データは TSFM、言語は LLM と役割分担。LLM 自体はセンサーを見ていない
(d) 特化型 LLM
モデル側をセンサー用に改良（学習用データセット特化 / 入出力層の改良・ファインチューニング / 内部モデル構造改良・損失関数の改良など）
SensorLLM / GPT4TS / TriP-LLM / MADLLM / AXIS / SensorLM
最も本格的なマルチモーダル化。精度は高いが学習（GPU）が必要。モデルによっては特定タスクには精度が高くなるが、その他のタスクの汎化性能は逆に低下するといったことがあるケースも多い
(e) エージェント／ツール統合
LLM にセンサーを入力せず、LLM 自身が統計ツールや既存検出器を Function calling などで呼び、その出力（テキスト）を読んで推論する
ZARA / LLM エージェント＋時系列ツール
学習不要で根拠を示しやすい。ただし LLM はセンサーを一切見ておらず、厳密にはマルチモーダル化ではない
今回の記事では (a), (b), (c) それぞれの方式で実際に動かしてみて方式毎の精度比較しようと思います。(d) の特化型 LLM に関しては別記事で別途取り扱う予定です。
各方式の精度検証
センサーデータを LLM が理解できていることをわかりやすく確認するために、今回の記事では異常データを含むセンサーデータを入力 → LLM に異常検知レポートを作成するフローで各方式を検証してみることにします。公正な比較のため、LLM は全て gemini-3.5-flash を使用して検証します。
使用するセンサーデータ：NAB [Numenta Anomaly Benchmark]
今回の検証では、実世界のセンサー異常検知ベンチマーク NAB の公開データ（timestamp,value 形式・既知異常区間ラベル付き）を使います。
NAB_KEY
センサー
内容
データ数（RAW）
入力波形例（■ 帯＝既知異常区間）
machine-temp
産業機械の温度
実機の温度センサー。既知の故障あり
22,695
image
ambient-temp
室温
室温センサー
7,267
image
cpu
サーバ CPU 使用率
AWS EC2 の CPU 使用率メトリクス
4,032
image
network
サーバ受信ネットワーク量
EC2 の network-in メトリクス
4,730
image
traffic-speed
道路の車速
交通センサーの速度
1,127
image
traffic-occupancy
道路の占有率
交通センサーの占有率
2,380
image
系統 (a)：センサー時系列データをプロンプトで直接入力
まずは、もっとも単純な「系統 (a)：センサー時系列データをプロンプトで直接入力」の方式で精度検証してみます。
実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは次のとおりです。
- NAB のセンサー時系列データを読み込み、間引く
プロンプト直接入力方式では、生データをそのまま入力するとデータ量が多く token 爆発する問題があるので一定間隔で間引くようにします
- 系列を index,timestamp,value のテキストにし、システムプロンプトとともに LLM に渡す
- LLM は異常点を [{"index":.., "reason":".."}, ...] の JSON 配列で返す。
- index を点フラグに変換しNAB ラベルで評価し、異常検知の自然言語レポートを生成する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。（LLM での検知結果）
- 青線=センサー値
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
数値だけを見て 4 区間中 2 区間を検出しました。精密だが検出は疎 という傾向が出ています。
全センサーデータでの結果をまとめると以下のようになりました
センサー（データ数）
**検知結果
（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）**
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
image
50%
0.06%
ambient-temp (606)
image
100%
0.00%
cpu (672)
image
50%
0.00%
network (789)
image
100%
1.15%
traffic-speed (564)
image
75%
0.51%
traffic-occupancy (1190)
image
100%
0.28%
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
検出は総じて疎でそのぶん誤検知率が全センサーで 低く、代償として異常見逃しが多い結果になりました。
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
数値直接入力によるセンサー異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv（946 点）
- 検知モデル: gemini-3.5-flash
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.5, 'precision': 1.0, 'f1': 0.667, 'tp': 2, 'fp': 0, 'fn': 2, 'false_alarm_rate': 0.0, 'false_alarms': 0, 'n_pred': 3}
検出した異常点
- 2013-12-16 17:15（値=6.44）: 周囲の温度水準（約45〜93度）から極端に逸脱した一時的なスパイク低下（6.44度）
- 2014-02-08 04:15（値=39.27）: 通常水準（約80〜100度）から30度台へと持続的に低下し始めるレベルシフトの開始点
- 2014-02-09 10:15（値=29.54）: 異常な低温状態（約30度）から通常水準への急激な復帰点
自然言語レポート（LLM: gemini-3.5-flash）
サマリ（重要度: 高、件数: 3件、対象時間帯: 2013-12-16 17:15 ～ 2014-02-09 10:15）
本期間において、設備温度センサー（machine_temperature_system_failure）にて計3件の異常値が検知されました。特に2013年12月に検知された極端な低温（6.44）は、設備の致命的な停止やセンサー不具合の可能性があり、重要度「高」として分類しています。また、2014年2月には約30時間の間隔で連続して異常な温度変動が検知されています。
検知イベント（重要度順）
- 重要度: 高
- 検知時刻: 2013-12-16 17:15
- 検知値: 6.44
- 概要: 通常の設備稼働温度としては極端に低い数値が検知されました。
- 重要度: 中
- 検知時刻: 2014-02-08 04:15
- 検知値: 39.27
- 概要: 深夜時間帯において、相対的に高い温度、または急激な温度変化が検知されました。
- 重要度: 中
- 検知時刻: 2014-02-09 10:15
- 検知値: 29.54
- 概要: 前日の異常検知に続き、翌日の午前中にも異常な温度変動が検知されました。
根本原因の仮説（確度付き）
- 仮説1: 2013-12-16の極端な低温（6.44）は、設備の予期せぬ完全停止またはセンサーの物理的脱落・故障である。
- 確度: 中
- 理由: 12月中旬の夕方に一桁台の温度を記録しており、稼働中の熱源を持つ設備としては不自然な低温であるため。
- 仮説2: 2014-02-08～09の温度変動（39.27および29.54）は、冷却システムの不調、または設備負荷の急激な変動に伴う過熱・不安定化である。
- 確度: 中
- 理由: 冬期において、深夜（04:15）に39.27まで上昇し、その約30時間後にも29.54という異常値を継続して検知しているため。
推奨アクション（優先度順 P1/P2/P3）
- P1: 2013-12-16 17:15 前後の設備稼働ログおよび電源ステータスの確認
- 対象時間帯に設備が計画停止していたのか、あるいは予期せぬトリップ（強制停止）が発生していたのかを、設備本体のシステムログから確認します。
- P2: 2014-02-08 ～ 02-09 の設備負荷状況および冷却ファン/冷却水の動作ログ確認
- 連続して発生した温度異常の原因を特定するため、当該時間帯の設備負荷（スループットや電流値）および冷却システムの動作履歴を調査します。
- P3: 温度センサー自体のキャリブレーションおよび断線チェック
- 異常値がセンサーの経年劣化や接触不良によるノイズである可能性を排除するため、現地またはリモートでのセンサー健全性確認を計画します。
補足・限界
本レポートは、提供された3点の異常値（時刻と数値）のみに基づいて作成された一次推測です。実際の設備仕様、通常稼働時の基準温度範囲、および前後の詳細な時系列データは含まれていないため、原因の断定には至っていません。正確な状況把握には、実機のシステムログや周辺センサーデータとのクロスリファレンス（裏取り）が必須です。
系統 (b)：センサー時系列データを画像化 → VLM
次に「系統 (b)：センサー時系列データを画像化 → VLM」の方式で精度検証してみます。実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは次のとおりです。
- NAB のセンサー時系列データを読み込む。
- 時系列データの折れ線グラフを PNG にレンダリング。
- その画像を base64 data URI にし、システムプロンプトとともに VLM に渡す。
- VLM は異常な時間帯を、開始・終了・理由を含む JSON 配列で返す。
- 点フラグに変換し NAB ラベルで評価し、異常検知の自然言語レポートを生成する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。
全センサーデータでの異常検知結果です。（VLM での検知結果）
センサー（データ数）
**検知結果
（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）**
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
image
80%
2.98%
xxx
xxx
ambient-temp (606)
image
100%
0.00%
xxx
xxx
cpu (672)
image
50%
13.72%
xxx
xxx
network (789)
image
50%
11.43%
xxx
xxx
traffic-speed (564)
image
75%
7.42%
xxx
xxx
traffic-occupancy (1190)
image
100%
2.71%
xxx
xxx
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
(a) 方式のセンサー時系列データを直接入力する方法と比べて密に異常検知できているものの、反面誤検知率も高い傾向になっています。
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
画像化→VLM によるセンサー異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv（946 点）
- 検知モデル(VLM): gemini-3.5-flash
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 1.0, 'precision': 0.444, 'f1': 0.615, 'tp': 4, 'fp': 5, 'fn': 0, 'false_alarm_rate': 0.0106, 'false_alarms': 9, 'n_pred': 86}
検出した異常時間帯
- 2013-12-10 15:00 〜 2013-12-11 15:00: 一時的な温度の急激な低下（約50まで下落）
- 2013-12-15 08:45 〜 2013-12-17 08:45: 値がほぼゼロ近く（約10以下）まで急落する極端な異常スパイク
- 2014-01-27 14:15 〜 2014-01-29 14:15: 温度が約50まで低下し、不安定な挙動を示す期間
- 2014-02-07 14:15 〜 2014-02-09 14:15: 温度が約30まで持続的に低下する大規模なシステム異常
自然言語レポート（LLM: gemini-3.5-flash）
サマリ
- 重要度: 高
- 検知件数と対象時間帯: 2013年12月10日 15:15 から 2014年2月9日 14:15 までの期間において、計86件の異常点を検知しました。
検知イベント（重要度順）
- 2013-12-16 17:15 / 値=6.44 / 急激な下降スパイク
- 直前（15:15）の 45.55 から 6.44 まで急落し、直後（19:15）には 93.82 まで急反発している極端な外れ値です。
- 2013-12-16 19:15 〜 23:15 / 値=93.82 〜 102.05 / 急激な上昇スパイク・レベルシフト
- 17:15 の極端な低値（6.44）から、わずか数時間で 100 を超える高値（23:15 に 102.05）まで急激に上昇しています。
- 2013-12-11 01:15 〜 13:15 / 値=87.23 〜 100.91 / 高値レベルシフト
- 12月10日の50台から急上昇し、12月11日05:15に最大値 100.91 を記録する高値状態が継続しました。
- 2013-12-15 09:15 〜 19:15 / 値=97.49 〜 100.89 / 高値レベルシフト
- 97〜100台の極めて高い値が約10時間にわたり継続して発生しました。
- 2014-02-09 12:15 〜 14:15 / 値=74.70 〜 89.88 / 急激な上昇スパイク
- 同日10:15の 29.54 から、わずか4時間で 89.88 まで急上昇しています。
- 2014-02-08 00:15 〜 2014-02-09 10:15 / 値=26.44 〜 44.89 / 低値レベルシフト
- 2月7日の50台から徐々に低下し、30前後（最小値 26.44）の低値状態が約34時間にわたり継続しました。
- 2014-01-27 14:15 〜 2014-01-29 14:15 / 値=51.78 〜 75.97 / 頻繁な変動（不安定状態）
- 50台〜70台の間で細かな上下変動を繰り返す異常が検知されています。
根本原因の仮説（確度付き）
- [確度: 中] センサーの一時的な異常、または測定対象の瞬間的な停止と急再起動
- 根拠: 2013-12-16 17:15 に「6.44」という極端な低値を記録した直後、2時間後には「93.82」へ急激に跳ね上がっています。この極端かつ短時間の往復は、測定機器自体の瞬間的な不具合（瞬断や接触不良）か、対象の急激な状態変化を示唆しています。
- [確度: 中] 対象機器の動作モード変更、または負荷変動による段階的な状態遷移
- 根拠: 2013-12-10から11日にかけての段階的な上昇（51.17 → 100.91）、および2014-02-07から08日にかけての段階的な下降（58.93 → 26.44）など、数時間〜数十時間かけて値が大きくシフトし、その水準を維持する挙動が見られるためです。
推奨アクション（優先度順）
- [P1] 2013-12-16 17:15 前後の実機ログおよびセンサー動作状況の確認
- 値が「6.44」まで急落した後に「102.05」まで急騰した時間帯において、センサーの通信途絶、電源瞬断、または測定対象機器の異常停止・再起動ログが発生していないか確認します。
- [P2] 100超えの高値期間（2013-12-11、12-15、12-16）における対象機器のステータス確認
- 値が100を超えていた時間帯に、対象機器で過負荷や異常高温などのアラートが別途発生していなかったか、関連する監視システムで裏取りを行います。
- [P3] 測定対象の仕様および閾値の確認
- 検知された数値（最大 102.05、最小 6.44）が、対象機器において物理的・仕様的に許容される範囲内であるか、管理部署またはメーカーの仕様書を確認します。
補足・限界
- 本レポートは、提供された「時刻と数値」のデータのみに基づいて作成された推定です。
- 監視対象の具体的なメトリクス名（温度、圧力、回転数など）、設置環境、機器構成、および正常時の基準値（しきい値）はすべて不明です。そのため、実際の機器やシステムログ、構成図を用いた現地・現物での裏取り調査が必ず必要となります。
系統 (c-1)：センサー時系列データを TSFM（Chronos）に入力 → LLM
次に、センサー時系列データを TSFM [Time Series Foundation Model]（時系列基盤モデル）に入力し異常検知し、その検知結果だけを LLM に渡してサポート作成する方式を試してみますTSFM（時系列基盤モデル）とは、大量かつ多様なドメインの時系列データで事前学習され追加学習なし（ゼロショット） で未知の時系列にも予測・異常検知を適用できる時系列版の基盤モデルです。代表的なモデルとして、amazon/chronos（時系列をトークンに量子化して T5 で学習）/ google/timesfm（decoder-only）/ Salesforce/moirai（多変量対応、ただし CC-BY-NC で商用不可）/ ibm-granite/granite-timeseries-tspulse（異常検知を公式サポート）などがありますが、今回の記事では Amazon の Chronos（Chronos-Bolt）を使用します。
実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは、以下の通りです。
- NAB のセンサー時系列データを読み込み、CPU 実行を軽くするため間引く。
- スライディング窓で、各時刻の直前 W 点を文脈に 次の 1 点を Chronos で確率予測し、分位点 q0.1 / q0.5 / q0.9 を得る。
- 実測値が予測区間 [q0.1, q0.9] から逸脱した分を区間幅で正規化して異常スコアとし、しきい値超えを異常点とする。
- 異常点だけの数値サマリをシステムプロンプトとともに LLM に渡し、異常検知の自然言語レポートを生成する。
- 検知結果と NAB の既知異常区間ラベルを重ねて可視化し画像保存する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。（Chronos-Bolt での検知結果）
- 青線=センサー値
- 淡い青線帯=Chronos 予測区間
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
全センサーデータでの結果をまとめると以下のようになりました（スコアは N=10 の平均値で記載）
センサー（データ数）
検知結果（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
image
50%
0.59%
ambient-temp (606)
image
0%
0.00%
cpu (672)
image
50%
0.60%
network (789)
image
100%
4.65%
traffic-speed (564)
image
50%
0.20%
traffic-occupancy (1190)
image
100%
2.33%
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv
- 検知モデル: amazon/chronos-bolt-base
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.75, 'precision': 0.231, 'f1': 0.353, 'tp': 3, 'fp': 10, 'fn': 1, 'false_alarm_rate': 0.0029, 'false_alarms': 10, 'n_pred': 14}
検知結果（Chronos-Bolt）
系列長: 3783 点 / 検知しきい値(スコア): 1.5 / 検知された異常点数: 14
逸脱スコア上位 14 点（時刻, 実測値, 期待中央値, 期待区間[q0.1,q0.9], スコア）:
- 2013-12-09 00:45:00: 実測=80.59, 期待中央=67.34, 期待区間=[65.29, 69.27], スコア=2.85
- 2013-12-09 21:45:00: 実測=76.37, 期待中央=56.77, 期待区間=[54.32, 59.22], スコア=3.50
- 2013-12-15 20:45:00: 実測=88.19, 期待中央=98.00, 期待区間=[96.22, 100.19], スコア=2.02
- 2013-12-16 17:45:00: 実測=41.16, 期待中央=-0.53, 期待区間=[-9.98, 8.27], スコア=1.80
- 2013-12-23 10:45:00: 実測=79.83, 期待中央=86.03, 期待区間=[84.80, 87.51], スコア=1.83
- 2013-12-27 19:45:00: 実測=82.21, 期待中央=63.97, 期待区間=[60.16, 67.57], スコア=1.98
- 2014-01-05 11:15:00: 実測=78.54, 期待中央=83.02, 期待区間=[81.98, 84.23], スコア=1.52
- 2014-01-12 08:15:00: 実測=87.94, 期待中央=96.47, 期待区間=[95.11, 97.73], スコア=2.73
- 2014-01-12 09:45:00: 実測=93.57, 期待中央=82.07, 期待区間=[79.60, 84.78], スコア=1.70
- 2014-01-27 17:45:00: 実測=71.02, 期待中央=62.78, 期待区間=[60.77, 64.68], スコア=1.62
- 2014-01-30 23:45:00: 実測=70.57, 期待中央=55.81, 期待区間=[52.36, 58.99], スコア=1.75
- 2014-02-03 00:15:00: 実測=75.77, 期待中央=86.32, 期待区間=[84.02, 88.77], スコア=1.74
- 2014-02-03 12:15:00: 実測=82.77, 期待中央=40.60, 期待区間=[36.27, 44.19], スコア=4.87
- 2014-02-09 12:15:00: 実測=74.70, 期待中央=30.47, 期待区間=[28.31, 32.79], スコア=9.36
自然言語レポート（LLM: gemini-3.5-flash）
サマリ
- 重要度: 高（最大スコア 9.36 を含む、しきい値 1.5 を超過した異常点を計 14 件検知しているため）
- 検知件数と対象時間帯: 2013-12-09 00:45:00 から 2014-02-09 12:15:00 までの期間において、計 14 件の異常点を検知。
検知イベント（重要度順）
- 2014-02-09 12:15:00 / 実測=74.70（期待区間=[28.31, 32.79]）/ スコア=9.36 / 種別: スパイク（大幅な上振れ）
- 2014-02-03 12:15:00 / 実測=82.77（期待区間=[36.27, 44.19]）/ スコア=4.87 / 種別: スパイク（大幅な上振れ）
- 2013-12-09 21:45:00 / 実測=76.37（期待区間=[54.32, 59.22]）/ スコア=3.50 / 種別: スパイク（上振れ）
- 2013-12-09 00:45:00 / 実測=80.59（期待区間=[65.29, 69.27]）/ スコア=2.85 / 種別: スパイク（上振れ）
- 2014-01-12 08:15:00 / 実測=87.94（期待区間=[95.11, 97.73]）/ スコア=2.73 / 種別: スパイク（下振れ）
- 2013-12-15 20:45:00 / 実測=88.19（期待区間=[96.22, 100.19]）/ スコア=2.02 / 種別: スパイク（下振れ）
- 2013-12-27 19:45:00 / 実測=82.21（期待区間=[60.16, 67.57]）/ スコア=1.98 / 種別: スパイク（上振れ）
- 2013-12-23 10:45:00 / 実測=79.83（期待区間=[84.80, 87.51]）/ スコア=1.83 / 種別: スパイク（下振れ）
- 2013-12-16 17:45:00 / 実測=41.16（期待区間=[-9.98, 8.27]）/ スコア=1.80 / 種別: スパイク（大幅な上振れ）
- 2014-01-30 23:45:00 / 実測=70.57（期待区間=[52.36, 58.99]）/ スコア=1.75 / 種別: スパイク（上振れ）
- 2014-02-03 00:15:00 / 実測=75.77（期待区間=[84.02, 88.77]）/ スコア=1.74 / 種別: スパイク（下振れ）
- 2014-01-12 09:45:00 / 実測=93.57（期待区間=[79.60, 84.78]）/ スコア=1.70 / 種別: スパイク（上振れ）
- 2014-01-27 17:45:00 / 実測=71.02（期待区間=[60.77, 64.68]）/ スコア=1.62 / 種別: スパイク（上振れ）
- 2014-01-05 11:15:00 / 実測=78.54（期待区間=[81.98, 84.23]）/ スコア=1.52 / 種別: スパイク（下振れ）
根本原因の仮説（確度付き）
- [確度: 中] 測定対象の突発的な状態変化（過熱または冷却不全）
- 根拠: 2014-02-09 12:15:00（スコア 9.36）および 2014-02-03 12:15:00（スコア 4.87）において、期待区間の上限を 40 近く上回る極端な実測値が検知されているため。
- [確度: 低] 期待値モデルの学習不足、または季節性・周期性の急激な変化
- 根拠: 2013-12-16 17:45:00 において、期待中央値がマイナス（-0.53）に設定されているのに対し、実測値は 41.16 となっており、モデルの予測基準自体が実際の運用状態と乖離している可能性があるため。
- [確度: 低] センサーの故障または通信異常
- 根拠: 期待区間から上下双方への逸脱（上振れ・下振れ）が約2ヶ月の間に不規則に繰り返されているため。
推奨アクション（優先度順）
- [P1] 2014-02-09 および 2014-02-03 の実機ログ確認
- スコアが極めて高い（9.36、4.87）2014年2月上旬の該当時間帯において、対象機器（詳細は不明）に過熱や異常停止などの物理的トラブルが発生していなかったか、システムログや現地ログを確認する。
- [P2] 2013-12-16 前後の期待値算出ロジックの確認
- 期待中央値がマイナス（-0.53）を記録している原因について、異常検知エンジン側のモデルパラメータや入力データに不備がないか確認する。
- [P3] 監視対象の特定と担当部署へのエスカレーション
- 本データ（machine_temperature_system_failure）が示す具体的な監視対象機器および環境が不明であるため、アセット管理台帳等から対象を特定し、担当部署へ状況を共有する。
補足・限界
- 本レポートは、提供された数値要約（実測値、期待値、スコア等）のみに基づく推定です。
- 監視対象の具体的な機器種別、設置環境、測定されている物理量（温度等と推測されるが断定不可）などのメタデータが不足しているため、正確な原因特定には実機ログや構成情報の裏取りが不可欠です。
系統 (c-2)：センサー時系列データを TSFM（TSPulse）に入力 → LLM
最後に、(c-1) と同じ TSFM + LLM の 2 段構成のまま、検知層を Chronos から異常検知特化の TSPulse に差し替えたもので精度検証します。
TSPulse は異常検知そのものを学習しており、公式パイプラインが 0〜1 の異常スコアを直接返します。実装コードは以下のレポジトリに保管しています。
大まかな処理の流れは、以下の通りです。
- NAB のセンサー時系列データを読み込む
- TSPulse のパイプラインに時系列データを渡し、時間軸・周波数軸の再構成誤差から異常スコア（0〜1、値が高いほど異常）を直接得る。
- 異常点だけの数値サマリをシステムプロンプトとともに LLM に渡し、異常検知の自然言語レポートを生成する。
- 検知結果と NAB の既知異常区間ラベルを重ねて可視化し画像保存する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。
- 青線=センサー値
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
全センサーデータでの結果をまとめると以下のようになりました（スコアは N=10 の平均値で記載）
センサー（データ数）
検知結果（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）
異常区間の検出率
誤検知率
適合率
F1
machine-temp (22,695)
image
25%
0 %
ambient-temp (7,267)
image
0%
0.12 %
cpu (4,032)
image
100%
5.51 %
traffic-speed (1,127)
image
50%
0.69%
traffic-occupancy (2,380)
image
100%
2.52%
network (4,730)
image
100%
0 %
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv
- 検知モデル: ibm-granite/granite-timeseries-tspulse-r1
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.25, 'precision': 1.0, 'f1': 0.4, 'tp': 1, 'fp': 0, 'fn': 3, 'false_alarm_rate': 0.0, 'false_alarms': 0, 'n_pred': 8}
検知結果（TSPulse）
系列長: 22695 点 / 検知された異常点数: 8 / 系列全体の中央値: 89.41
異常スコア上位 8 点（時刻, 実測値, 中央値との差, 異常スコア）:
- 2013-12-16 16:25:00: 実測=22.98, 中央値との差=-66.42, 異常スコア=0.668
- 2013-12-16 16:30:00: 実測=21.74, 中央値との差=-67.67, 異常スコア=0.745
- 2013-12-16 16:35:00: 実測=19.28, 中央値との差=-70.13, 異常スコア=0.771
- 2013-12-16 16:40:00: 実測=18.59, 中央値との差=-70.82, 異常スコア=0.775
- 2013-12-16 16:45:00: 実測=16.46, 中央値との差=-72.95, 異常スコア=0.759
- 2013-12-16 16:50:00: 実測=14.67, 中央値との差=-74.74, 異常スコア=0.724
- 2013-12-16 16:55:00: 実測=12.41, 中央値との差=-76.99, 異常スコア=0.672
- 2013-12-16 17:00:00: 実測=9.63, 中央値との差=-79.77, 異常スコア=0.603
自然言語レポート（LLM: gemini-3.5-flash）
サマリ
- 重要度: 高
- 検知件数と対象時間帯: 2013-12-16 16:25:00 から 17:00:00 までの35分間にわたり、計8件の異常点を連続して検知しました。
検知イベント（重要度順）
異常スコアの高い順に列挙します。
- 2013-12-16 16:40:00 / 実測値: 18.59（中央値との差: -70.82）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.775
- 2013-12-16 16:35:00 / 実測値: 19.28（中央値との差: -70.13）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.771
- 2013-12-16 16:45:00 / 実測値: 16.46（中央値との差: -72.95）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.759
- 2013-12-16 16:30:00 / 実測値: 21.74（中央値との差: -67.67）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.745
- 2013-12-16 16:50:00 / 実測値: 14.67（中央値との差: -74.74）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.724
- 2013-12-16 16:55:00 / 実測値: 12.41（中央値との差: -76.99）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.672
- 2013-12-16 16:25:00 / 実測値: 22.98（中央値との差: -66.42）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.668
- 2013-12-16 17:00:00 / 実測値: 9.63（中央値との差: -79.77）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.603
根本原因の仮説（確度付き）
- [確度: 高] 対象設備・システムの停止、または測定プロセスの異常
- 根拠: 系列全体の中央値（89.41）に対し、16:25を境に実測値が22.98へと急激に低下し、その後も17:00（実測値: 9.63）にかけて5分刻みで連続して低下し続けています。中央値から最大で -79.77 も乖離しており、一時的なスパイク（ノイズ）ではなく、システムの状態が完全に変化（レベルシフト）しているためです。
推奨アクション（優先度順）
- [P1] 対象設備・システムの稼働ステータスの確認
- 16:25以降に、対象設備が意図的にシャットダウンされたか、あるいは予期せぬ停止（トリップ等）が発生していないか、稼働ログや管理コンソールで確認してください。
- [P2] センサー自体の故障・脱落、または通信経路の確認
- 設備自体が稼働している場合、センサーが測定対象から脱落したか、あるいはセンサー自体の故障により異常な低数値を送り続けている可能性があるため、物理的な状態および電気信号を確認してください。
- [P3] 17:00以降の最新データの確認とエスカレーション
- 17:00時点で実測値が 9.63 まで低下し続けており、現在も低下または異常な低値が継続しているか最新のデータを確認の上、関係各所へ状況を報告してください。
補足・限界
- 本レポートは、提供された数値要約（実測値、中央値、異常スコア、時間）のみに基づく推定です。
- メトリクスの具体的な物理量（温度、圧力、回転数など）や、監視対象の具体的な機器構成、および17:00以降のデータは「不明」であるため、実際の機器やシステムログを用いた裏取りが必ず必要です。
各系統の精度比較
最後にこれら方式毎の精度比較をしてみました。3 系統（a,b,c）を同一正解（NAB ラベル）・同一指標・同一 LLMで比較しました。各セルは「異常区間の検出率 / 誤検知率 / F1」の N=10 回での平均値で記載しており、各行の最良検出率を太字にしています。
センサー（点数）
(a) 数値直接入力
(b) 画像→VLM
(c-1) TSFM by Chronos
(c-2) TSFM by TSPulse
machine-temp
50% / 0.06% / 0.619
80% / 2.98% / 0.529
50% / 0.59% / 0.364
25% / 0.00% / 0.40
ambient-temp
100% / 0.00% / 1.00
100% / 0.00% / 1.00
0% / 0.00% / 0.000
0% / 0.12% / 0.00
cpu
50% / 0.00% / 0.667
50% / 13.72% / 0.584
50% / 0.60% / 0.400
100% / 5.51%/ 0.308
network
100% / 1.15% / 0.400
50% / 11.43% / 0.400
100% / 4.65% / 0.114
100% / 0.00%/ 1.000
traffic-speed
75% / 0.51% / 0.627
75% / 7.42% / 0.513
50% / 0.20% / 0.571
50% / 0.69%/ 0.571
traffic-occupancy
100% / 0.28% / 0.400
100% / 2.71% / 0.500
100% / 2.33% / 0.080
100% / 2.52% / 0.667
今回のスコア上では (a) の方式が全体的に精度比較よく見えそうですが、(a) 方式では検出は総じて疎でそのぶん誤検知率が全センサーで 低く、代償として異常見逃しが多い結果になっており、一概に (a) がよいというわけではないです。（別の品質スコアでも評価すべきかと思いますが、今回の記事では雰囲気掴むだけなのでこれらスコアのみで比較しています）
- machine-temp での plot 図比較
- network での plot 図比較
これら比較結果から、今回の試行範囲では１つの万能手法があるというわけではなくセンサーデータの特性やドメインなどに応じて一長一短であることがわかりました。
まとめ
本記事では、様々な形式で LLM にセンサーの時系列データを入力し精度比較してみました。厳密にはマルチモーダル化と言わない方式も記載していますが、広い意味でのセンサー x LLM でのマルチモーダル化の個人的な勉強の手始めとして雰囲気掴むには良かったです。
センサー入力に最適化した専用の LLM でのマルチモーダル化に関しては、別記事で取り上げようと思います。
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！ （新卒の方やインターンシップのエントリーもお待ちしております！）
*1:一般的にマルチモーダル化は、モデル側の入出力層に特定の入力データ（画像・動画・音声など）用の構造を追加したり置き換えしたりファインチューニングしたりしているものの認識で、プロンプトで直接センサーデータを入力する方法は、一般的にセンサー x LLM でのマルチモーダル化とは言わないケースが多いと思いますが、今回の記事ではセンサーデータを LLM に入力して認識させるという広い意味でマルチモーダル化として記載しています。
原文を表示
こんにちは！ABEJA で ABEJA Platform 開発や AI 関連の研究開発業務を行っている坂井（@Yagami360）です。
LLM のマルチモーダル化は、この数年で テキスト → 画像 → 動画 → 音声 という風に扱えるモダリティをどんどん広げてきました。個人的には、この流れの次に重要になるのはセンサーデータも含めたマルチモーダル化だと考えています。温度・振動・電力・加速度・生体信号などのような「物理世界の情報」を基盤モデルが直接あるいは間接的に扱えるようになると、現実世界を観測して物理世界での意思決定・行動するタイプの AI ——いわゆるフィジカル AI—— の中核である「知覚」の部分を、汎用モデルで一気通貫に扱える可能性が出てきます。そしてこのことは、AGI（汎用人工知能）やフィジカル AI 実現に向けて必須の流れだと思ってます。
またフィジカルAIと聞くとまずロボティクスをイメージするかと思いますが、さらにその先にヘルスケア・農業・自然など人間や世界環境を含めた物理世界の AI 化が進んでいくと思っており、そのファーストステップとしてセンサー x LLM でのマルチモーダル化が必須になると思ってます。
この記事では、センサー x LLM でのマルチモーダルの個人的な勉強の手始めとして、まずは様々な方式でセンサーデータを LLM に入力してみて、方式毎の精度比較してみます。
- センサーデータ × LLM でのマルチモーダル化の系統
- 各方式の精度検証
使用するセンサーデータ：NAB [Numenta Anomaly Benchmark]
- 系統 (a)：センサー時系列データをプロンプトで直接入力
- 系統 (b)：センサー時系列データを画像化 → VLM
- 系統 (c-1)：センサー時系列データを TSFM（Chronos）に入力 → LLM
- 系統 (c-2)：センサー時系列データを TSFM（TSPulse）に入力 → LLM
- 各系統の精度比較
- まとめ
- We Are Hiring!
センサーデータ × LLM でのマルチモーダル化の系統
センサーデータを LLM に「入力」する方法やセンサー × LLM でのマルチモーダル化のやり方は、主に以下の系統に分類できるかと思っています。*1
系統
センサーを LLM にどう渡すか
代表手法
位置づけ
(a) センサー時系列データをプロンプトで直接入力
センサーデータの時系列をテキスト化してプロンプトに入れる
SigLLM / LLMAD / LLMTime
最軽量だが長い時系列データに弱い。厳密にはマルチモーダル化とは呼ばないことが多い認識
(b) センサー時系列データを画像化 → VLM
折れ線グラフ画像にして、vLLM などの画像でのマルチモーダル化したモデルに入力する
TAMA / AnomLLM / ChatTS
画像のマルチモーダル能力（vLLM）をそのまま転用。
(c) センサー時系列データを TSFM に入力 → LLM
TSFM（時系列基盤モデル）がセンサーデータの時系列を処理し、LLM にはその結果だけを渡す（間接入力）
Chronos, TSPulse など
センサー時系列データは TSFM、言語は LLM と役割分担。LLM 自体はセンサーを見ていない
(d) 特化型 LLM
モデル側をセンサー用に改良（学習用データセット特化 / 入出力層の改良・ファインチューニング / 内部モデル構造改良・損失関数の改良など）
SensorLLM / GPT4TS / TriP-LLM / MADLLM / AXIS / SensorLM
最も本格的なマルチモーダル化。精度は高いが学習（GPU）が必要。モデルによっては特定タスクには精度が高くなるが、その他のタスクの汎化性能は逆に低下するといったことがあるケースも多い
(e) エージェント／ツール統合
LLM にセンサーを入力せず、LLM 自身が統計ツールや既存検出器を Function calling などで呼び、その出力（テキスト）を読んで推論する
ZARA / LLM エージェント＋時系列ツール
学習不要で根拠を示しやすい。ただし LLM はセンサーを一切見ておらず、厳密にはマルチモーダル化ではない
今回の記事では (a), (b), (c) それぞれの方式で実際に動かしてみて方式毎の精度比較しようと思います。(d) の特化型 LLM に関しては別記事で別途取り扱う予定です。
各方式の精度検証
センサーデータを LLM が理解できていることをわかりやすく確認するために、今回の記事では異常データを含むセンサーデータを入力 → LLM に異常検知レポートを作成するフローで各方式を検証してみることにします。公正な比較のため、LLM は全て gemini-3.5-flash を使用して検証します。
使用するセンサーデータ：NAB [Numenta Anomaly Benchmark]
今回の検証では、実世界のセンサー異常検知ベンチマーク NAB の公開データ（timestamp,value 形式・既知異常区間ラベル付き）を使います。
NAB_KEY
センサー
内容
データ数（RAW）
入力波形例（■ 帯＝既知異常区間）
machine-temp
産業機械の温度
実機の温度センサー。既知の故障あり
22,695
ambient-temp
室温
室温センサー
7,267
cpu
サーバ CPU 使用率
AWS EC2 の CPU 使用率メトリクス
4,032
network
サーバ受信ネットワーク量
EC2 の network-in メトリクス
4,730
traffic-speed
道路の車速
交通センサーの速度
1,127
traffic-occupancy
道路の占有率
交通センサーの占有率
2,380
系統 (a)：センサー時系列データをプロンプトで直接入力
まずは、もっとも単純な「系統 (a)：センサー時系列データをプロンプトで直接入力」の方式で精度検証してみます。
実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは次のとおりです。
- NAB のセンサー時系列データを読み込み、間引く
プロンプト直接入力方式では、生データをそのまま入力するとデータ量が多く token 爆発する問題があるので一定間隔で間引くようにします
- 系列を index,timestamp,value のテキストにし、システムプロンプトとともに LLM に渡す
- LLM は異常点を [{"index":.., "reason":".."}, ...] の JSON 配列で返す。
- index を点フラグに変換しNAB ラベルで評価し、異常検知の自然言語レポートを生成する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。（LLM での検知結果）
- 青線=センサー値
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
数値だけを見て 4 区間中 2 区間を検出しました。精密だが検出は疎 という傾向が出ています。
全センサーデータでの結果をまとめると以下のようになりました
センサー（データ数）
**検知結果
（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）**
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
50%
0.06%
ambient-temp (606)
100%
0.00%
cpu (672)
50%
0.00%
network (789)
100%
1.15%
traffic-speed (564)
75%
0.51%
traffic-occupancy (1190)
100%
0.28%
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
検出は総じて疎でそのぶん誤検知率が全センサーで 低く、代償として異常見逃しが多い結果になりました。
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
# 数値直接入力によるセンサー異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv（946 点）
- 検知モデル: gemini-3.5-flash
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.5, 'precision': 1.0, 'f1': 0.667, 'tp': 2, 'fp': 0, 'fn': 2, 'false_alarm_rate': 0.0, 'false_alarms': 0, 'n_pred': 3}
## 検出した異常点
- 2013-12-16 17:15（値=6.44）: 周囲の温度水準（約45〜93度）から極端に逸脱した一時的なスパイク低下（6.44度）
- 2014-02-08 04:15（値=39.27）: 通常水準（約80〜100度）から30度台へと持続的に低下し始めるレベルシフトの開始点
- 2014-02-09 10:15（値=29.54）: 異常な低温状態（約30度）から通常水準への急激な復帰点
## 自然言語レポート（LLM: gemini-3.5-flash）
## サマリ（重要度: 高、件数: 3件、対象時間帯: 2013-12-16 17:15 ～ 2014-02-09 10:15）
本期間において、設備温度センサー（machine_temperature_system_failure）にて計3件の異常値が検知されました。特に2013年12月に検知された極端な低温（6.44）は、設備の致命的な停止やセンサー不具合の可能性があり、重要度「高」として分類しています。また、2014年2月には約30時間の間隔で連続して異常な温度変動が検知されています。
---
## 検知イベント（重要度順）
1. **重要度: 高**
* **検知時刻**: 2013-12-16 17:15
* **検知値**: 6.44
* **概要**: 通常の設備稼働温度としては極端に低い数値が検知されました。
2. **重要度: 中**
* **検知時刻**: 2014-02-08 04:15
* **検知値**: 39.27
* **概要**: 深夜時間帯において、相対的に高い温度、または急激な温度変化が検知されました。
3. **重要度: 中**
* **検知時刻**: 2014-02-09 10:15
* **検知値**: 29.54
* **概要**: 前日の異常検知に続き、翌日の午前中にも異常な温度変動が検知されました。
---
## 根本原因の仮説（確度付き）
* **仮説1: 2013-12-16の極端な低温（6.44）は、設備の予期せぬ完全停止またはセンサーの物理的脱落・故障である。**
* **確度**: 中
* **理由**: 12月中旬の夕方に一桁台の温度を記録しており、稼働中の熱源を持つ設備としては不自然な低温であるため。
* **仮説2: 2014-02-08～09の温度変動（39.27および29.54）は、冷却システムの不調、または設備負荷の急激な変動に伴う過熱・不安定化である。**
* **確度**: 中
* **理由**: 冬期において、深夜（04:15）に39.27まで上昇し、その約30時間後にも29.54という異常値を継続して検知しているため。
---
## 推奨アクション（優先度順 P1/P2/P3）
* **P1: 2013-12-16 17:15 前後の設備稼働ログおよび電源ステータスの確認**
* 対象時間帯に設備が計画停止していたのか、あるいは予期せぬトリップ（強制停止）が発生していたのかを、設備本体のシステムログから確認します。
* **P2: 2014-02-08 ～ 02-09 の設備負荷状況および冷却ファン/冷却水の動作ログ確認**
* 連続して発生した温度異常の原因を特定するため、当該時間帯の設備負荷（スループットや電流値）および冷却システムの動作履歴を調査します。
* **P3: 温度センサー自体のキャリブレーションおよび断線チェック**
* 異常値がセンサーの経年劣化や接触不良によるノイズである可能性を排除するため、現地またはリモートでのセンサー健全性確認を計画します。
---
## 補足・限界
本レポートは、提供された3点の異常値（時刻と数値）のみに基づいて作成された一次推測です。実際の設備仕様、通常稼働時の基準温度範囲、および前後の詳細な時系列データは含まれていないため、原因の断定には至っていません。正確な状況把握には、実機のシステムログや周辺センサーデータとのクロスリファレンス（裏取り）が必須です。
系統 (b)：センサー時系列データを画像化 → VLM
次に「系統 (b)：センサー時系列データを画像化 → VLM」の方式で精度検証してみます。実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは次のとおりです。
- NAB のセンサー時系列データを読み込む。
- 時系列データの折れ線グラフを PNG にレンダリング。
- その画像を base64 data URI にし、システムプロンプトとともに VLM に渡す。
- VLM は異常な時間帯を、開始・終了・理由を含む JSON 配列で返す。
- 点フラグに変換し NAB ラベルで評価し、異常検知の自然言語レポートを生成する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。
全センサーデータでの異常検知結果です。（VLM での検知結果）
センサー（データ数）
**検知結果
（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）**
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
80%
2.98%
xxx
xxx
ambient-temp (606)
100%
0.00%
xxx
xxx
cpu (672)
50%
13.72%
xxx
xxx
network (789)
50%
11.43%
xxx
xxx
traffic-speed (564)
75%
7.42%
xxx
xxx
traffic-occupancy (1190)
100%
2.71%
xxx
xxx
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
(a) 方式のセンサー時系列データを直接入力する方法と比べて密に異常検知できているものの、反面誤検知率も高い傾向になっています。
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
# 画像化→VLM によるセンサー異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv（946 点）
- 検知モデル(VLM): gemini-3.5-flash
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 1.0, 'precision': 0.444, 'f1': 0.615, 'tp': 4, 'fp': 5, 'fn': 0, 'false_alarm_rate': 0.0106, 'false_alarms': 9, 'n_pred': 86}
## 検出した異常時間帯
- 2013-12-10 15:00 〜 2013-12-11 15:00: 一時的な温度の急激な低下（約50まで下落）
- 2013-12-15 08:45 〜 2013-12-17 08:45: 値がほぼゼロ近く（約10以下）まで急落する極端な異常スパイク
- 2014-01-27 14:15 〜 2014-01-29 14:15: 温度が約50まで低下し、不安定な挙動を示す期間
- 2014-02-07 14:15 〜 2014-02-09 14:15: 温度が約30まで持続的に低下する大規模なシステム異常
## 自然言語レポート（LLM: gemini-3.5-flash）
## サマリ
- 重要度: 高
- 検知件数と対象時間帯: 2013年12月10日 15:15 から 2014年2月9日 14:15 までの期間において、計86件の異常点を検知しました。
---
## 検知イベント（重要度順）
1. **2013-12-16 17:15 / 値=6.44 / 急激な下降スパイク**
- 直前（15:15）の 45.55 から 6.44 まで急落し、直後（19:15）には 93.82 まで急反発している極端な外れ値です。
2. **2013-12-16 19:15 〜 23:15 / 値=93.82 〜 102.05 / 急激な上昇スパイク・レベルシフト**
- 17:15 の極端な低値（6.44）から、わずか数時間で 100 を超える高値（23:15 に 102.05）まで急激に上昇しています。
3. **2013-12-11 01:15 〜 13:15 / 値=87.23 〜 100.91 / 高値レベルシフト**
- 12月10日の50台から急上昇し、12月11日05:15に最大値 100.91 を記録する高値状態が継続しました。
4. **2013-12-15 09:15 〜 19:15 / 値=97.49 〜 100.89 / 高値レベルシフト**
- 97〜100台の極めて高い値が約10時間にわたり継続して発生しました。
5. **2014-02-09 12:15 〜 14:15 / 値=74.70 〜 89.88 / 急激な上昇スパイク**
- 同日10:15の 29.54 から、わずか4時間で 89.88 まで急上昇しています。
6. **2014-02-08 00:15 〜 2014-02-09 10:15 / 値=26.44 〜 44.89 / 低値レベルシフト**
- 2月7日の50台から徐々に低下し、30前後（最小値 26.44）の低値状態が約34時間にわたり継続しました。
7. **2014-01-27 14:15 〜 2014-01-29 14:15 / 値=51.78 〜 75.97 / 頻繁な変動（不安定状態）**
- 50台〜70台の間で細かな上下変動を繰り返す異常が検知されています。
---
## 根本原因の仮説（確度付き）
- **[確度: 中] センサーの一時的な異常、または測定対象の瞬間的な停止と急再起動**
- 根拠: 2013-12-16 17:15 に「6.44」という極端な低値を記録した直後、2時間後には「93.82」へ急激に跳ね上がっています。この極端かつ短時間の往復は、測定機器自体の瞬間的な不具合（瞬断や接触不良）か、対象の急激な状態変化を示唆しています。
- **[確度: 中] 対象機器の動作モード変更、または負荷変動による段階的な状態遷移**
- 根拠: 2013-12-10から11日にかけての段階的な上昇（51.17 → 100.91）、および2014-02-07から08日にかけての段階的な下降（58.93 → 26.44）など、数時間〜数十時間かけて値が大きくシフトし、その水準を維持する挙動が見られるためです。
---
## 推奨アクション（優先度順）
- **[P1] 2013-12-16 17:15 前後の実機ログおよびセンサー動作状況の確認**
- 値が「6.44」まで急落した後に「102.05」まで急騰した時間帯において、センサーの通信途絶、電源瞬断、または測定対象機器の異常停止・再起動ログが発生していないか確認します。
- **[P2] 100超えの高値期間（2013-12-11、12-15、12-16）における対象機器のステータス確認**
- 値が100を超えていた時間帯に、対象機器で過負荷や異常高温などのアラートが別途発生していなかったか、関連する監視システムで裏取りを行います。
- **[P3] 測定対象の仕様および閾値の確認**
- 検知された数値（最大 102.05、最小 6.44）が、対象機器において物理的・仕様的に許容される範囲内であるか、管理部署またはメーカーの仕様書を確認します。
---
## 補足・限界
- 本レポートは、提供された「時刻と数値」のデータのみに基づいて作成された推定です。
- 監視対象の具体的なメトリクス名（温度、圧力、回転数など）、設置環境、機器構成、および正常時の基準値（しきい値）は**すべて不明**です。そのため、実際の機器やシステムログ、構成図を用いた現地・現物での裏取り調査が必ず必要となります。
系統 (c-1)：センサー時系列データを TSFM（Chronos）に入力 → LLM
次に、センサー時系列データを TSFM [Time Series Foundation Model]（時系列基盤モデル）に入力し異常検知し、その検知結果だけを LLM に渡してサポート作成する方式を試してみますTSFM（時系列基盤モデル）とは、大量かつ多様なドメインの時系列データで事前学習され追加学習なし（ゼロショット） で未知の時系列にも予測・異常検知を適用できる時系列版の基盤モデルです。代表的なモデルとして、amazon/chronos（時系列をトークンに量子化して T5 で学習）/ google/timesfm（decoder-only）/ Salesforce/moirai（多変量対応、ただし CC-BY-NC で商用不可）/ ibm-granite/granite-timeseries-tspulse（異常検知を公式サポート）などがありますが、今回の記事では Amazon の Chronos（Chronos-Bolt）を使用します。
実装コードは以下のレポジトリに保管しています。使い方等は README を参照してください。
大まかな処理の流れは、以下の通りです。
- NAB のセンサー時系列データを読み込み、CPU 実行を軽くするため間引く。
- スライディング窓で、各時刻の直前 W 点を文脈に 次の 1 点を Chronos で確率予測し、分位点 q0.1 / q0.5 / q0.9 を得る。
- 実測値が予測区間 [q0.1, q0.9] から逸脱した分を区間幅で正規化して異常スコアとし、しきい値超えを異常点とする。
- 異常点だけの数値サマリをシステムプロンプトとともに LLM に渡し、異常検知の自然言語レポートを生成する。
- 検知結果と NAB の既知異常区間ラベルを重ねて可視化し画像保存する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。（Chronos-Bolt での検知結果）
- 青線=センサー値
- 淡い青線帯=Chronos 予測区間
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
全センサーデータでの結果をまとめると以下のようになりました（スコアは N=10 の平均値で記載）
センサー（データ数）
検知結果（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）
異常区間の検出率
誤検知率
適合率
F1
machine-temp (946)
50%
0.59%
ambient-temp (606)
0%
0.00%
cpu (672)
50%
0.60%
network (789)
100%
4.65%
traffic-speed (564)
50%
0.20%
traffic-occupancy (1190)
100%
2.33%
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
# 異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv
- 検知モデル: amazon/chronos-bolt-base
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.75, 'precision': 0.231, 'f1': 0.353, 'tp': 3, 'fp': 10, 'fn': 1, 'false_alarm_rate': 0.0029, 'false_alarms': 10, 'n_pred': 14}
## 検知結果（Chronos-Bolt）
系列長: 3783 点 / 検知しきい値(スコア): 1.5 / 検知された異常点数: 14
逸脱スコア上位 14 点（時刻, 実測値, 期待中央値, 期待区間[q0.1,q0.9], スコア）:
- 2013-12-09 00:45:00: 実測=80.59, 期待中央=67.34, 期待区間=[65.29, 69.27], スコア=2.85
- 2013-12-09 21:45:00: 実測=76.37, 期待中央=56.77, 期待区間=[54.32, 59.22], スコア=3.50
- 2013-12-15 20:45:00: 実測=88.19, 期待中央=98.00, 期待区間=[96.22, 100.19], スコア=2.02
- 2013-12-16 17:45:00: 実測=41.16, 期待中央=-0.53, 期待区間=[-9.98, 8.27], スコア=1.80
- 2013-12-23 10:45:00: 実測=79.83, 期待中央=86.03, 期待区間=[84.80, 87.51], スコア=1.83
- 2013-12-27 19:45:00: 実測=82.21, 期待中央=63.97, 期待区間=[60.16, 67.57], スコア=1.98
- 2014-01-05 11:15:00: 実測=78.54, 期待中央=83.02, 期待区間=[81.98, 84.23], スコア=1.52
- 2014-01-12 08:15:00: 実測=87.94, 期待中央=96.47, 期待区間=[95.11, 97.73], スコア=2.73
- 2014-01-12 09:45:00: 実測=93.57, 期待中央=82.07, 期待区間=[79.60, 84.78], スコア=1.70
- 2014-01-27 17:45:00: 実測=71.02, 期待中央=62.78, 期待区間=[60.77, 64.68], スコア=1.62
- 2014-01-30 23:45:00: 実測=70.57, 期待中央=55.81, 期待区間=[52.36, 58.99], スコア=1.75
- 2014-02-03 00:15:00: 実測=75.77, 期待中央=86.32, 期待区間=[84.02, 88.77], スコア=1.74
- 2014-02-03 12:15:00: 実測=82.77, 期待中央=40.60, 期待区間=[36.27, 44.19], スコア=4.87
- 2014-02-09 12:15:00: 実測=74.70, 期待中央=30.47, 期待区間=[28.31, 32.79], スコア=9.36
## 自然言語レポート（LLM: gemini-3.5-flash）
## サマリ
- 重要度: 高（最大スコア 9.36 を含む、しきい値 1.5 を超過した異常点を計 14 件検知しているため）
- 検知件数と対象時間帯: 2013-12-09 00:45:00 から 2014-02-09 12:15:00 までの期間において、計 14 件の異常点を検知。
## 検知イベント（重要度順）
1. **2014-02-09 12:15:00** / 実測=74.70（期待区間=[28.31, 32.79]）/ スコア=9.36 / 種別: スパイク（大幅な上振れ）
2. **2014-02-03 12:15:00** / 実測=82.77（期待区間=[36.27, 44.19]）/ スコア=4.87 / 種別: スパイク（大幅な上振れ）
3. **2013-12-09 21:45:00** / 実測=76.37（期待区間=[54.32, 59.22]）/ スコア=3.50 / 種別: スパイク（上振れ）
4. **2013-12-09 00:45:00** / 実測=80.59（期待区間=[65.29, 69.27]）/ スコア=2.85 / 種別: スパイク（上振れ）
5. **2014-01-12 08:15:00** / 実測=87.94（期待区間=[95.11, 97.73]）/ スコア=2.73 / 種別: スパイク（下振れ）
6. **2013-12-15 20:45:00** / 実測=88.19（期待区間=[96.22, 100.19]）/ スコア=2.02 / 種別: スパイク（下振れ）
7. **2013-12-27 19:45:00** / 実測=82.21（期待区間=[60.16, 67.57]）/ スコア=1.98 / 種別: スパイク（上振れ）
8. **2013-12-23 10:45:00** / 実測=79.83（期待区間=[84.80, 87.51]）/ スコア=1.83 / 種別: スパイク（下振れ）
9. **2013-12-16 17:45:00** / 実測=41.16（期待区間=[-9.98, 8.27]）/ スコア=1.80 / 種別: スパイク（大幅な上振れ）
10. **2014-01-30 23:45:00** / 実測=70.57（期待区間=[52.36, 58.99]）/ スコア=1.75 / 種別: スパイク（上振れ）
11. **2014-02-03 00:15:00** / 実測=75.77（期待区間=[84.02, 88.77]）/ スコア=1.74 / 種別: スパイク（下振れ）
12. **2014-01-12 09:45:00** / 実測=93.57（期待区間=[79.60, 84.78]）/ スコア=1.70 / 種別: スパイク（上振れ）
13. **2014-01-27 17:45:00** / 実測=71.02（期待区間=[60.77, 64.68]）/ スコア=1.62 / 種別: スパイク（上振れ）
14. **2014-01-05 11:15:00** / 実測=78.54（期待区間=[81.98, 84.23]）/ スコア=1.52 / 種別: スパイク（下振れ）
## 根本原因の仮説（確度付き）
- **[確度: 中] 測定対象の突発的な状態変化（過熱または冷却不全）**
- 根拠: 2014-02-09 12:15:00（スコア 9.36）および 2014-02-03 12:15:00（スコア 4.87）において、期待区間の上限を 40 近く上回る極端な実測値が検知されているため。
- **[確度: 低] 期待値モデルの学習不足、または季節性・周期性の急激な変化**
- 根拠: 2013-12-16 17:45:00 において、期待中央値がマイナス（-0.53）に設定されているのに対し、実測値は 41.16 となっており、モデルの予測基準自体が実際の運用状態と乖離している可能性があるため。
- **[確度: 低] センサーの故障または通信異常**
- 根拠: 期待区間から上下双方への逸脱（上振れ・下振れ）が約2ヶ月の間に不規則に繰り返されているため。
## 推奨アクション（優先度順）
- **[P1] 2014-02-09 および 2014-02-03 の実機ログ確認**
- スコアが極めて高い（9.36、4.87）2014年2月上旬の該当時間帯において、対象機器（詳細は不明）に過熱や異常停止などの物理的トラブルが発生していなかったか、システムログや現地ログを確認する。
- **[P2] 2013-12-16 前後の期待値算出ロジックの確認**
- 期待中央値がマイナス（-0.53）を記録している原因について、異常検知エンジン側のモデルパラメータや入力データに不備がないか確認する。
- **[P3] 監視対象の特定と担当部署へのエスカレーション**
- 本データ（machine_temperature_system_failure）が示す具体的な監視対象機器および環境が不明であるため、アセット管理台帳等から対象を特定し、担当部署へ状況を共有する。
## 補足・限界
- 本レポートは、提供された数値要約（実測値、期待値、スコア等）のみに基づく推定です。
- 監視対象の具体的な機器種別、設置環境、測定されている物理量（温度等と推測されるが断定不可）などのメタデータが不足しているため、正確な原因特定には実機ログや構成情報の裏取りが不可欠です。
系統 (c-2)：センサー時系列データを TSFM（TSPulse）に入力 → LLM
最後に、(c-1) と同じ TSFM + LLM の 2 段構成のまま、検知層を Chronos から異常検知特化の TSPulse に差し替えたもので精度検証します。
TSPulse は異常検知そのものを学習しており、公式パイプラインが 0〜1 の異常スコアを直接返します。実装コードは以下のレポジトリに保管しています。
大まかな処理の流れは、以下の通りです。
- NAB のセンサー時系列データを読み込む
- TSPulse のパイプラインに時系列データを渡し、時間軸・周波数軸の再構成誤差から異常スコア（0〜1、値が高いほど異常）を直接得る。
- 異常点だけの数値サマリをシステムプロンプトとともに LLM に渡し、異常検知の自然言語レポートを生成する。
- 検知結果と NAB の既知異常区間ラベルを重ねて可視化し画像保存する。
まずは、機械温度センサー（machine-temp）での異常検知結果です。
- 青線=センサー値
- オレンジ帯=異常区間（正解データ）
- 赤点=検知点
全センサーデータでの結果をまとめると以下のようになりました（スコアは N=10 の平均値で記載）
センサー（データ数）
検知結果（■ 帯＝NAB が定義する異常区間／●＝LLM の検知点）
異常区間の検出率
誤検知率
適合率
F1
machine-temp (22,695)
25%
0 %
ambient-temp (7,267)
0%
0.12 %
cpu (4,032)
100%
5.51 %
traffic-speed (1,127)
50%
0.69%
traffic-occupancy (2,380)
100%
2.52%
network (4,730)
100%
0 %
- 異常区間の検出率：NAB の正解異常区間のうち区間内に 1 点以上を異常と判定できた区間の割合。高いほど良い（1.00 = 全区間を検出）
- 誤検知率：正常点のうち誤って異常と判定した割合。低いほど良い（0% が最良）
- 適合率: 検知した区間のうち、本当に異常だった割合。高いほど良い
- F1: 異常区間の検出率と適合率の調和平均
次に、機械温度センサー（machine-temp）で、LLM が出力した異常検知レポート例は以下のようになりました。
# 異常検知レポート
- データ: NAB: realKnownCause/machine_temperature_system_failure.csv
- 検知モデル: ibm-granite/granite-timeseries-tspulse-r1
- 評価（NAB 既知異常区間ラベル基準）: {'windows_total': 4, 'window_recall': 0.25, 'precision': 1.0, 'f1': 0.4, 'tp': 1, 'fp': 0, 'fn': 3, 'false_alarm_rate': 0.0, 'false_alarms': 0, 'n_pred': 8}
## 検知結果（TSPulse）
系列長: 22695 点 / 検知された異常点数: 8 / 系列全体の中央値: 89.41
異常スコア上位 8 点（時刻, 実測値, 中央値との差, 異常スコア）:
- 2013-12-16 16:25:00: 実測=22.98, 中央値との差=-66.42, 異常スコア=0.668
- 2013-12-16 16:30:00: 実測=21.74, 中央値との差=-67.67, 異常スコア=0.745
- 2013-12-16 16:35:00: 実測=19.28, 中央値との差=-70.13, 異常スコア=0.771
- 2013-12-16 16:40:00: 実測=18.59, 中央値との差=-70.82, 異常スコア=0.775
- 2013-12-16 16:45:00: 実測=16.46, 中央値との差=-72.95, 異常スコア=0.759
- 2013-12-16 16:50:00: 実測=14.67, 中央値との差=-74.74, 異常スコア=0.724
- 2013-12-16 16:55:00: 実測=12.41, 中央値との差=-76.99, 異常スコア=0.672
- 2013-12-16 17:00:00: 実測=9.63, 中央値との差=-79.77, 異常スコア=0.603
## 自然言語レポート（LLM: gemini-3.5-flash）
## サマリ
- **重要度**: 高
- **検知件数と対象時間帯**: 2013-12-16 16:25:00 から 17:00:00 までの35分間にわたり、計8件の異常点を連続して検知しました。
## 検知イベント（重要度順）
異常スコアの高い順に列挙します。
1. **2013-12-16 16:40:00** / 実測値: 18.59（中央値との差: -70.82）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.775
2. **2013-12-16 16:35:00** / 実測値: 19.28（中央値との差: -70.13）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.771
3. **2013-12-16 16:45:00** / 実測値: 16.46（中央値との差: -72.95）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.759
4. **2013-12-16 16:30:00** / 実測値: 21.74（中央値との差: -67.67）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.745
5. **2013-12-16 16:50:00** / 実測値: 14.67（中央値との差: -74.74）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.724
6. **2013-12-16 16:55:00** / 実測値: 12.41（中央値との差: -76.99）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.672
7. **2013-12-16 16:25:00** / 実測値: 22.98（中央値との差: -66.42）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.668
8. **2013-12-16 17:00:00** / 実測値: 9.63（中央値との差: -79.77）/ 種別: 急激なレベル低下（レベルシフト）/ 異常スコア: 0.603
## 根本原因の仮説（確度付き）
- **[確度: 高] 対象設備・システムの停止、または測定プロセスの異常**
- **根拠**: 系列全体の中央値（89.41）に対し、16:25を境に実測値が22.98へと急激に低下し、その後も17:00（実測値: 9.63）にかけて5分刻みで連続して低下し続けています。中央値から最大で -79.77 も乖離しており、一時的なスパイク（ノイズ）ではなく、システムの状態が完全に変化（レベルシフト）しているためです。
## 推奨アクション（優先度順）
- **[P1] 対象設備・システムの稼働ステータスの確認**
- 16:25以降に、対象設備が意図的にシャットダウンされたか、あるいは予期せぬ停止（トリップ等）が発生していないか、稼働ログや管理コンソールで確認してください。
- **[P2] センサー自体の故障・脱落、または通信経路の確認**
- 設備自体が稼働している場合、センサーが測定対象から脱落したか、あるいはセンサー自体の故障により異常な低数値を送り続けている可能性があるため、物理的な状態および電気信号を確認してください。
- **[P3] 17:00以降の最新データの確認とエスカレーション**
- 17:00時点で実測値が 9.63 まで低下し続けており、現在も低下または異常な低値が継続しているか最新のデータを確認の上、関係各所へ状況を報告してください。
## 補足・限界
- 本レポートは、提供された数値要約（実測値、中央値、異常スコア、時間）のみに基づく推定です。
- メトリクスの具体的な物理量（温度、圧力、回転数など）や、監視対象の具体的な機器構成、および17:00以降のデータは「不明」であるため、実際の機器やシステムログを用いた裏取りが必ず必要です。
各系統の精度比較
最後にこれら方式毎の精度比較をしてみました。3 系統（a,b,c）を同一正解（NAB ラベル）・同一指標・同一 LLMで比較しました。各セルは「異常区間の検出率 / 誤検知率 / F1」の N=10 回での平均値で記載しており、各行の最良検出率を太字にしています。
センサー（点数）
(a) 数値直接入力
(b) 画像→VLM
(c-1) TSFM by Chronos
(c-2) TSFM by TSPulse
machine-temp
50% / 0.06% / 0.619
80% / 2.98% / 0.529
50% / 0.59% / 0.364
25% / 0.00% / 0.40
ambient-temp
100% / 0.00% / 1.00
100% / 0.00% / 1.00
0% / 0.00% / 0.000
0% / 0.12% / 0.00
cpu
50% / 0.00% / 0.667
50% / 13.72% / 0.584
50% / 0.60% / 0.400
100% / 5.51%/ 0.308
network
100% / 1.15% / 0.400
50% / 11.43% / 0.400
100% / 4.65% / 0.114
100% / 0.00%/ 1.000
traffic-speed
75% / 0.51% / 0.627
75% / 7.42% / 0.513
50% / 0.20% / 0.571
50% / 0.69%/ 0.571
traffic-occupancy
100% / 0.28% / 0.400
100% / 2.71% / 0.500
100% / 2.33% / 0.080
100% / 2.52% / 0.667
今回のスコア上では (a) の方式が全体的に精度比較よく見えそうですが、(a) 方式では検出は総じて疎でそのぶん誤検知率が全センサーで 低く、代償として異常見逃しが多い結果になっており、一概に (a) がよいというわけではないです。（別の品質スコアでも評価すべきかと思いますが、今回の記事では雰囲気掴むだけなのでこれらスコアのみで比較しています）
- machine-temp での plot 図比較
- network での plot 図比較
これら比較結果から、今回の試行範囲では１つの万能手法があるというわけではなくセンサーデータの特性やドメインなどに応じて一長一短であることがわかりました。
まとめ
本記事では、様々な形式で LLM にセンサーの時系列データを入力し精度比較してみました。厳密にはマルチモーダル化と言わない方式も記載していますが、広い意味でのセンサー x LLM でのマルチモーダル化の個人的な勉強の手始めとして雰囲気掴むには良かったです。
センサー入力に最適化した専用の LLM でのマルチモーダル化に関しては、別記事で取り上げようと思います。
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！ （新卒の方やインターンシップのエントリーもお待ちしております！）
*1:一般的にマルチモーダル化は、モデル側の入出力層に特定の入力データ（画像・動画・音声など）用の構造を追加したり置き換えしたりファインチューニングしたりしているものの認識で、プロンプトで直接センサーデータを入力する方法は、一般的にセンサー x LLM でのマルチモーダル化とは言わないケースが多いと思いますが、今回の記事ではセンサーデータを LLM に入力して認識させるという広い意味でマルチモーダル化として記載しています。
AI算出
導入事例ainew評価標準
記事は AI モデルの発表や新機能ではなく、既存技術を組み合わせた特定のユースケース（異常検知レポート作成）の実証実験を報告しており、新規性よりも実装知見に重点がある。また、ABEJA という日本企業の技術ブログであり、日本の開発者にとって具体的なアーキテクチャ参考になるため日本関連性は高いが、世界初の新事実ではない。
6つの評価軸を見る
- AI関連度
- 75
- 情報源の信頼性
- 100
- 新規性
- 25
- 調べる価値
- 25
- 重複の少なさ
- 100
- 日本での有用性
- 75
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み