2026年6月16日、名古屋コンベンションホールにて「AI博覧会 Nagoya 2026」が開催された。株式会社メロン 取締役CTOの本田 崇人氏は「設備の異常を未然に防ぐ～異常予兆検知AIの開発事例～」と題して登壇した。

本レポートでは、同講演とその後の本田氏への取材をもとに、製造現場における異常予兆検知AIの基本を紹介する。生成AIの普及によって「AIをどう使うか」への関心が高まるなか、異常検知や時系列解析では、どのようなデータを扱い、どのような考え方で異常を捉える必要があるのか。LLMとの違いを入口に、時系列解析の基本、異常の種類、そしてメロン社が公開する時系列予測アルゴリズム「FLAIR」までを整理する。

LLMで異常検知は変わるのか？

「AIと雑にくくってしまうのは嫌いなんです」

時系列解析を専門とする本田氏は、講演の中でそう語った。AIという言葉は便利だが、その中には性質の異なる技術が含まれている。

生成AIの台頭によって、この分野に詳しくない人のなかには「LLMで異常検知もできるのではないか」と考える人もいるかもしれない。筆者自身も、取材前にはそうした期待を持っていた。

しかし、LLMに異常検知そのものを任せることは難しい。

LLMが主に扱うのは、単語やトークンのような離散的なデータである。一方、製造設備の異常検知で扱うのは、センサーから得られる連続的な数値データ（センサー情報）だ。同じように「AI」と表現されていても、対象とするデータが違えば、適した手法も変わる。

一方で、LLMが異常検知にまったく使えないわけではない。分析プログラムを書く、実験コードを整える、手法の候補を洗い出すといった用途では、LLMは有効な支援ツールになる。

本田氏自身も、以前に比べてコードをゼロから書く機会は減ったという。たとえば「Zスコア法で閾値を設定する」といった方針を与え、LLMに実装させるようになったとのこと。

生成AIによって、分析や実装のハードルは下がっている。だからこそ重要になるのは、どのようなデータに対して、どのような考え方や手法を使うべきかを判断するための前提知識だ。

以降では、本田氏の講演をもとに、時系列解析と異常検知の基礎を紹介する。

時系列解析でできること

時系列データとは、時間の経過に沿って記録されたデータを指す。工場設備の温度や振動、店舗の売上、日々の気温などが代表例だ。これらは単なる数値の集合ではなく、「⁠過去の値が未来に影響する」という時間的なつながり、つまり構造を持っているのが特徴である。

時系列解析では、これらのデータを「トレンド（長期的な傾向⁠）⁠」⁠「⁠季節性（周期的なパターン⁠）⁠」⁠「⁠残差」などに分解し、複雑なデータ変動の背後にある構造を読み解いていく。

本田氏によれば、時系列解析とは「過去を理解し、未来を見通し、現在を最適化する」ための技術だという。その領域は大きく5つに整理できる。データの動きやパターンをグループ化する「分類（クラスタリング⁠）⁠」⁠、将来の値を推定する「予測⁠」⁠、正常な状態からの逸脱を見つける「異常検知⁠」⁠、データの変動や予測値に応じて機器やシステム等の動きを調整する「制御⁠」⁠、そして予測結果から現在の判断をよりよいものにする「最適化」である。

その応用範囲は製造設備の異常検知にとどまらない。たとえば、自動車のセンサーデータから走行パターンを自動抽出したり、POSレジの購買履歴から消費者の行動グループを予測して広告効果の測定に生かしたりと、幅広い課題に使われている。

これら5つの領域は別々の問題に見えるが、実際には密接に関係している。たとえば、正常時の数値を「予測」し、実測値がその予測区間から大きく外れた場合に「異常」と判断する方法がある。この場合、予測モデルの精度が異常検知の性能にも直結する。

現場の実務において時系列解析が重要になる理由の一つが、「⁠解釈性の高さ（説明可能性⁠）⁠」である。すべてを深層学習モデルに任せてしまうと、結果がブラックボックス化し、「⁠なぜ異常と判断されたのか」がわかりにくくなる。一方、時系列解析であれば、異常と判断した根拠を波形や数値で示しやすい。現場では「どのタイミングで設備を止めて点検するか」といった決断や合意形成が必要になるため、この説明可能性は重要な意味を持つ。

異常は「大きな値」とは限らない

異常検知と聞くと、数値が急激に跳ね上がる状態を想像しやすい。そのようなケースを念頭に置くと、単に閾値を設定するだけで機能すると考えがちである。しかし、時系列データに現れる異常はそれだけではない。本田氏によると、現場の実務では主に4つのパターンがある。

1つ目は、瞬間的に値が急上昇・急降下する「スパイク」だ。センサーの一時的なノイズである場合もあり、誤報の原因になりやすい。

2つ目は、データの基準値が段差のように変わる「シフト」である。定期メンテナンス後や連休明けなど、設備や運用条件が変わったタイミングで起こることがある。

3つ目は、数値がじわじわと上昇または下降していく「ドリフト」だ。たとえばドリルの摩耗のように、時間をかけて状態が変わっていくケースでは、この緩やかな変化を捉えることが予兆検知につながる。

4つ目は、繰り返されていた波形や周波数の特徴が変化する「周波数の乱れ」だ。ベアリングのクラックなど、機械的な状態変化が波形に現れることがある。

単純に上限値や下限値を決めるだけでは、こうした変化をうまく捉えられない。だからこそ、単なる閾値の設定ではなく、時系列解析が重要になる。

「故障データがないとAIは作れない」は誤解

製造現場で異常検知を検討すると、「⁠過去の故障データがないためAIを作れない」と考えられることがある。しかし本田氏は、そもそも品質良く稼働している現場では、故障時のデータが大量にあるほうが珍しいと指摘する。

必ずしも大量の故障データが必要なわけではない。正常に稼働しているデータの特徴を学習し、そこから外れたズレを予兆として捉える方法があるためだ。教師なし学習などを用いれば、過去に観測されていない故障パターンの兆候を検知できる可能性もある。

ただし、「⁠正常から外れた状態」が、必ず故障を意味するとは限らない。連休明けや定期保全の後など、業務上は問題がなくてもデータの傾向が大きく変わることはある。アルゴリズムを動かすだけではなく、現場の運用状況と照らし合わせることが欠かせない。

CPUだけで動く時系列予測モデル「FLAIR」

本田氏がCTOを務めるメロン社は、時系列解析を専門とする企業である。同社はその知見をもとに、独自の時系列予測アルゴリズム「FLAIR」をOSSとして公開している。FLAIRは「Factored Level And Interleaved Ridge」の略で、深層学習や基盤モデルに頼らず、NumPyとSciPyを中心とした約1000行のコードで実装された時系列予測モデルだ。

製造現場では、インターネット接続が難しい環境も多い。また、設備の近くに置いたエッジ端末で、軽く、速く処理したいというニーズも根強い。GPUや膨大なパラメータを持つ事前学習済みモデルを必要とせず、CPU上で高速に動作するFLAIRは、そうした実務のニーズに応えるモデルと言える。

特徴の一つは、ハイパーパラメータの調整が不要である点だ。モデルの性能を引き出すために複雑なチューニングを繰り返すのではなく、手元の時系列データに対してすぐに予測を試せるよう設計されている。

内部では、時系列データを「何が起きるか（Level⁠）⁠」と「どのような形で起きるか（Shape⁠）⁠」に分解する。LevelはRidge回帰で予測し、Shapeには学習パラメータを持たせず、構造的な平均を用いる。これによって、ノイズの削減と過学習の防止を同時に図っているという。深層学習のようにブラックボックス化しすぎず、統計に基づく解釈性を保っている点も、現場への導入を考えるうえでは重要になる。

予測精度の高さも注目されている。予測誤差の小ささを競うベンチマーク「GIFT-Eval」では、統計モデル部門および計算速度対精度で世界1位を記録したという。

FLAIRはPythonパッケージとして公開されており、次のコマンドでインストールできる。

pip install flaircast

GitHubではソースコードが公開されているほか、Google ColabでQuick Startも試せる。実際に試すと、ColabのCPUランタイム上でも短時間で結果が返ってくる。

• GitHub: https://github.com/Mellon-Inc/FLAIR
• Quick Start: https://colab.research.google.com/github/Mellon-Inc/FLAIR/blob/main/examples/quickstart.ipynb

小さく始める⁠、地に足の着いたデータ活用へ

異常検知の導入では、最初から大規模なシステムを作る必要はないと本田氏は語る。まずは手元にあるデータを確認し、どのような周期や傾向があるのか、どの変化を異常として検出したいのかを整理する。そのうえで、小規模な診断やPoCを行い、効果を確認しながら本開発へ進めていく。

検出精度だけでなく、誤検知が発生した場合の運用負荷や、異常を検知した後の対応方法まで検証することが重要だ。

現場のデータと運用に向き合いながら、使えるところから小さく始めることが、実用につなげるための第一歩になる。