異常検知
読み: 異常検知
異常検知とは不正や故障を早期発見
過去の膨大なデータから通常のパターンを学習しそこから外れた特異な事象や未知の振る舞いをAIが見つけ出す技術。
かんたんに言うと
熟練の整備士がエンジンのわずかな異音を聞き分けて故障の予兆を察知する感覚を数理モデルに置き換えたもの。
閾値ベースの監視が限界を迎えた現場で求められる異常検知の基本概念
製造業のモーター振動や物流倉庫の温度管理。これまで現場は閾値を決めてルールベースで監視してきた。だが温度が30度を超えたらアラートを鳴らすという単純な設定では季節変動や設備の経年劣化に対応しきれない。
閾値の調整だけで現場の担当者は疲弊していく。
ここで機械学習やディープラーニングの出番となる。正常時の膨大なデータを読み込ませて通常の状態を定義しそこから外れたものを異常とみなす。ルールを人間が書くのではなくデータからシステムに推論させるアプローチ。
正常を定義する技術的アプローチ
異常検知の厄介なところは異常なデータが極端に少ないこと。不良品や不正アクセスのデータが豊富に揃っている現場など存在しない。だから教師あり学習は早々に壁にぶつかる。
必然的に正常データだけを学習させる教師なし学習が主役になる。
決定木を応用して孤立したデータポイントを見つけ出すIsolation Forestや入力データを圧縮して復元する際の誤差で判定するオートエンコーダ。これらは現場のデータ特性に合わせて使い分ける必要があるがどれを選ぶかは常に悩ましい。
経理や製造現場での実運用とツール群
ITインフラの監視ならSplunkやDatadogを入れれば済む話である。だが経理部門の不正経費申請や製造ラインの歩留まり低下を見つけるとなると話は変わる。
Amazon CloudWatch Anomaly Detectionを使って売上データの不自然な落ち込みを検知したりDataRobotで独自の予測モデルを組んだりする。
ツールを導入したからといってすぐに使えるわけではない。現場の業務フローにどう組み込むか。アラートが出たときに誰がどう動くのか。システムよりも人間のオペレーション設計のほうがはるかに重い。
偽陽性と偽陰性のトレードオフ
現場を最も苦しめるのが誤検知である。
異常を見逃す偽陰性を恐れて検知感度を上げると今度は何でもないデータに反応する偽陽性が爆発する。毎日数百件の偽アラートが飛んでくれば現場は狼少年のようにシステムを無視し始めるだろう。
逆に過学習を起こしたモデルは未知の異常に全く反応しなくなる。感度のチューニングはどこまでいっても正解がなく運用者の判断が分かれるところである。
現場に定着させるための泥臭い道のり
AIに異常を見つけさせること自体は難しくない。本当に難しいのはその結果を現場が信じて行動できる状態を作ること。
小さく始めて検証を重ねるなどと綺麗な言葉を並べるベンダーは多いが実際の現場はもっと泥臭い。
アラートの理由がブラックボックスでは経理担当者も工場長も納得しない。説明可能性をどこまで担保するか。運用を続ける中で変化する正常の定義をどうモデルに再学習させていくか。導入を決めるのは技術の優劣ではなく現場がこの面倒な運用に耐えきれるかどうかにかかっている。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。