工場の異常音検知AI導入｜マイク配置からFAT・SATまで

工場の異常音検知AI導入を検討するとき、最初に決めるべきことはモデル名ではない。「どの設備の、どの運転状態で、どの音の変化を拾い、誰が何を確認するか」である。機械の音は、回転速度、加工材料、周囲の装置、マイクの向き、扉の開閉でも変わる。録音した音をAIに入れるだけでは、現場が対応できる警報にはならない。本稿はタイの工場でモーター、搬送機、ファン、減速機などの音響監視を導入する担当者向けに、測定からRFP、FAT、SATまでを一続きの設計として示す。特定のポンプのキャビテーション診断や汎用的な予知保全の概説ではなく、空気を伝わる音を使う場合の実装判断に絞る。

結論：異常音検知は「音の差」と「現場の行動」を同時に設計する

異常音検知AIは、正常と見なした運転音から外れた音を知らせることができる。一方、その逸脱だけで故障部位、残寿命、停止の要否まで断定できるとは限らない。DCASEの異常音検知課題も、異常データを網羅しにくい現実と、運転状態や環境音が変わる「ドメインシフト」を中心課題に据えている。したがって発注仕様は「AI精度」の一語でまとめず、対象とする設備・運転状態、マイクの設置位置、正常音の採取範囲、通知先、確認手順、受入条件を分けて書く。ISO 17359は設備状態監視プログラムを組み立てる一般的な手順を示しており、測定と保全判断をひとつの運用として扱う考え方に沿う。

実務では最初から設備全体を対象にしない。停止や不良につながる機械を一つ選び、観測できる音、確認できる保全記録、担当者が取れる行動を一枚の表にする。これを基に小さく録音し、警報に値する音の変化かどうかを人がレビューする。検証で使う設置条件と閾値を記録し、FATでは持込みデータとインターフェースを、SATでは実設備と作業シフトを確かめる。設備や工程が変われば正常の定義も更新する。これが導入の骨格である。

工場の異常音検知AIが向く設備、向かない設備

音が外へ出る回転機、ファン、コンベヤ、減速機、空圧機構、周期的に接触する搬送機構は候補になる。摩擦、衝突、空気漏れ、緩みなどが可聴域または測定対象帯域の変化として表れる場合、非接触のマイクを使う意味がある。ただし音が出ることと、故障を確実に識別できることは別である。音源が密集したラインでは隣の機械が大きく聞こえる。カバーや防音箱があるとマイク位置で音が大きく変わる。設備内部の変化が空気中の音に出にくければ、振動、電流、温度などの別信号が適している場合もある。

最初の現場確認では、設備ごとに「故障・異常モード」「期待する音の変化」「現場で取れる基準音」「背景騒音」「検出後の確認方法」を並べる。例えば搬送機のガイド接触音を狙うなら、製品が異なる通常ロット、起動停止、隣の機械の稼働を含めた音を採る。ベルトの蛇行を疑う音が出ても、現場ではガードを安全手順に従って確認し、張力やアライメントを点検して初めて判断できる。AIが安全機能やインターロックの代わりに自動停止を判断する、という前提は置かない。

向かないケースも先に明記する。警報を受ける人がいない設備、騒音源が頻繁に変わる仮設ライン、音がほとんど漏れない密閉設備、保全イベントの時刻が記録されていない設備では、PoCの前に運用またはデータ基盤を整える。音で異常が分かると主張する前に、同じ条件で人が聞き分けられるか、波形や周波数帯で差が観測できるかを確かめる。この事前判定で対象を絞るほうが、全設備へマイクを設置してから警報を減らすよりも合理的である。

設置前に決める「何を正常と呼ぶか」

正常音は一種類ではない。アイドル、立ち上がり、定常運転、速度変更、段取り替え、品種切替、清掃、短時間停止、隣接設備の起動を同じ「正常」に混ぜると、モデルが本当に区別すべき差を見失う。反対に各条件を細かく分けすぎると、条件ごとの学習サンプルが不足する。まずPLCやMESから取得できる運転モード、速度、品番、シフトなどを列挙し、音に影響が大きい条件を優先して記録する。取得できない条件は、現場の作業日誌や製造指図の時刻と突き合わせる計画を作る。

DCASE 2024の課題説明は、異常音のサンプルがまれで多様なこと、運転状態や環境騒音の変化を考慮すべきことを明示している。工場のPoCでも「正常音だけで学習し、逸脱を検出する」方法を検討できる。ただし正常音の採取期間を固定の日数だけで決めず、運転条件の網羅で判断する。複数シフト、主な品種、速度帯、段取り、隣接設備の稼働を採れたかを記録する。異常が記録されていない期間を無条件に「正常」とみなさず、保全日誌と作業者の聞き取りで混入を点検する。

正常の定義には更新日と承認者も必要だ。摩耗部品の交換、据付位置の移動、ガード交換、機種変更、ソフト更新、マイク交換があれば、同じ設備名でも音響条件が変わる。旧基準との差をレビューし、必要なら新基準を作る。旧データを消さず、どのモデルと設置条件でどの警報が出たかを追えるようにする。これはモデルの改良だけでなく、誤報の原因究明や受入結果の説明にも役立つ。

マイク配置：音源、背景騒音、保全作業を一枚の図で確認する

マイクの仕様表だけでは、現場で拾う音を決められない。対象部位との距離、向き、ガードや筐体の遮蔽、床や壁の反射、隣接設備、空調、エアブロー、作業者の通行を確認する。候補位置を二、三カ所に絞り、同じ運転条件で短い比較録音を行う。固定設備に取り付ける場合は、清掃、水、切粉、熱、振動、ケーブル引き回し、保守時の交換アクセスも見る。録音のしやすさだけで、生産中に手が届かない位置を選ばない。

OSHAの騒音測定技術資料は、測定者の身体や周囲の装置が音を遮り得ること、マイクの向きが測定に影響することを説明している。これは労働者の騒音ばく露を測る文脈であり、設備の異常音検知にそのまま受入基準を与えるものではない。ただし「位置と向きが音を変える」という物理的な注意は有用だ。固定治具に位置・高さ・角度を記し、写真を撮り、移設後に同じ条件で比較できるようにする。マイクの向きを試験中に動かして精度を比べても、モデル差と設置差を切り分けられない。

モーター、減速機、搬送面など複数の音源が近いときは、単一マイクで無理に原因を特定しない。必要に応じてマイクを分け、ライン停止時と稼働時、隣接設備だけが動く時を比較する。周囲音を監視する参照マイクを置く案もあるが、追加配線と同期が必要なのでPoCで価値を確かめる。狙った異常音が背景音に埋もれるなら、マイク増設よりセンサー種類の変更が適切なこともある。

録音データは「音」と「その時の設備状態」を組にする

保存する単位は音声ファイルだけではない。設備ID、マイクID、設置位置と向き、時刻とタイムゾーン、運転モード、品番または作業条件、モデル版、警報スコア、保全判定を結びつける。音声を長期間丸ごと保存する必要があるかは用途と社内ルールで決める。通常の音は特徴量と短い確認用クリップで足りるかもしれない。警報の根拠、後日の再学習、個人の声が入る可能性を踏まえ、保存対象・アクセス権・保持期間を設計する。音響監視を「何でも録音する」仕組みにしない。

推論時刻とPLC・MESの時刻がずれると、音の変化と停止イベントを誤って結びつける。収集端末の時刻同期、通信断時のローカル保存、回復後の再送、ファイル破損の検知をRFPに含める。生産実績の連携方法には設備や上位システムによって選択肢がある。OPC Foundationの機械工具向けOPC UA仕様は、機械の監視情報をMES、SCADA、ERP、分析システムへ交換するための共通インターフェースを示す。ただし既存設備がその情報モデルを実装していると決めつけず、実機のタグと時刻品質を事前に確認する。

タイ工場では日本語、タイ語、英語の運転記録が混じることがある。分類名だけを翻訳しても運用は揃わない。警報の確認画面には設備ID、時刻、運転状態、直前の音クリップ、担当者が選ぶ判定候補を共通の意味で表示する。作業指示や保全チケットに渡す際は、元音への参照と人の判定を残す。音から故障名を生成した文面が独り歩きしないよう、「音の変化を検知」と「原因を確認済み」は明確に区別する。

エッジ推論かクラウドか：通信断でも必要な処理を先に決める

エッジ端末で推論すると、設備近くで音を処理し、短いイベントや特徴量だけを上位へ送る構成を取れる。通信が不安定でもローカルで検出を続ける設計が可能だ。一方、端末の設置環境、電源、熱、更新、故障交換、モデル配布、ログ回収まで現場で運用する必要がある。クラウド処理は横断分析やモデル管理をまとめやすいが、音声の転送帯域、遅延、通信断、保存先と権限を決めなければならない。どちらが常に優れるという話ではない。

判断はアラームの応答時間とデータの扱いから始める。保全員が次の巡回で確認すれば足りる警報と、工程中に直ちに確認する警報では要件が違う。録音に作業者の会話が入る場所と、密閉機械室で機械音だけを採る場所でも設計が異なる。RFPには「ネットワーク断の間、どの処理が続き、どのイベントを後送し、画面にはどう表示するか」を書く。エッジを選んだ場合も、本番更新を勝手に端末へ押し込まず、版管理とロールバック手順を決める。

初期PoCでは、重いモデルを先に選ぶより、音の収集条件と人が確認できる警報単位を確立する。スペクトログラム、特徴量、埋め込み、再構成誤差など複数の方法があり、DCASEの研究課題にも多様な実装がある。ベンチマークの順位をそのまま自社ラインの検出率とは読めない。対象機械、背景騒音、マイク位置、誤報コストが違うからだ。選定会議ではモデル名より、同じ現場データで比較した結果と改善余地を示す。

誤報と見逃しをどう評価するか

「正解率99％」だけでは設備監視の受入にならない。大部分が正常なデータなら、常に正常と答えるシステムでも見かけの正解率は高くなる。測るべきものは、対象と定義した異常イベントを何件拾ったか、警報から現場確認までどのくらいか、正常運転でどれだけ不要な呼出しが出たか、警報の原因をレビュー可能か、である。評価の分母と観測期間を明記する。異常サンプルが少ないなら、検出率を確定的な数字として約束せず、試験で確認できた範囲と未検証の異常を分ける。

誤報は一日当たりの件数だけでなく、設備・運転モード・シフト・品番で層別する。段取り替え時だけ多い警報は、そのモードを正常の別区分にするか監視を抑制する選択肢がある。ただし、何でも抑制すると本当に必要な警報を消す。警報を「通知」「要確認」「緊急確認」のように分ける場合も、各段階の根拠、通知先、最大待機時間を作業手順に落とす。現場の負荷を無視した低い閾値は、警報が無視される結果を招く。

見逃しは過去の停止事例をすべて再生すれば分かるわけではない。故障前音が残っていない事例、修理後に条件が変わった事例、マイク設置前の事例は比較対象にできない。危険な故障を試験のために発生させない。録音済みの実事例、現場承認の模擬音、設備メーカーが許可する安全な試験条件を区別して結果を記す。異常音を検知しなかった場合に、巡回点検や振動計測など既存の監視がどう補うかも決める。

人の確認を警報フローに組み込む

AIの警報を受けた担当者には、対象設備、音の発生時刻、運転状態、比較対象の正常音、直近の保全作業を見せる。スコアだけを赤く表示しても調査は進まない。一次確認では、まず安全な場所から設備の状態と他の計測値を確認する。現物点検やガード開放は工場の安全手順に従う。音が変わった原因が作業条件なら「正常な条件変更」、機械的な不具合が疑われるなら「要点検」、判断できなければ「保留」とし、その理由を記録する。

警報後の結果をモデル改善に戻す際、「警報が誤り」と「現場で原因をまだ特定できない」を混同しない。前者は閾値や学習データの課題かもしれない。後者は追加のセンサーや保全記録が必要かもしれない。交換部品、点検結果、停止時間、品質影響などを保全チケットへ紐づけ、翌月のレビューで警報の有用性を判断する。人がラベルを付ける作業量もPoCの費用に含める。検知件数が増えるだけで保全判断が速くならないなら、設計を見直す。

ライン長や設備重要度によって、通知先は保全、製造、品質のいずれか、または複数になる。RACIのように、受信、一次確認、停止判断、原因判定、モデル変更承認を分けて指名する。特に「誰が設備を止めるか」はAIベンダーの設定画面で決める事項ではない。現場の安全・品質・生産手順に沿って決め、AIはその判断材料を渡す。ISO 13374-1は状態監視情報のデータ処理、通信、提示に関するソフトウェア仕様の一般指針を示すが、実際の権限設計は各工場の責任である。

PoCは一台・一つの検出目的から設計する

PoCを始める前に、対象設備と異常モードを一行で書く。「何かおかしい音を見つける」では評価できない。「コンベヤのガイド接触が疑われる音の変化を、定常搬送中に検出し、保全員が当日確認できる」など、観測条件と行動まで定める。故障名を確定できるかが分からない場合は「異常候補の通知」として試す。対象設備の保全履歴と作業者ヒアリングから、比較可能な過去事例があるかを確認する。

PoCの流れは、現場測定、位置比較、正常条件の採取、初期モデルまたはルール、現場での警報レビュー、改善、受入判定とする。各段階で残す証拠は異なる。位置比較では配置図と録音、正常採取では運転条件表、モデル比較では固定した評価データ、現場レビューでは警報への判断履歴を残す。事前に評価期間や閾値候補を記し、結果を見てから評価条件を変えない。データを見ながら改善する期間と、改善を凍結して受入する期間を分ける。

PoC費用はマイクと端末だけではない。取付治具、配線、防塵・防水、停止して施工する時間、PLCやMES連携、音声保存、現場レビュー、モデル更新、教育、保守が入る。見積では初期費用と継続費用を分け、工場側の作業時間も明示する。設備を増やす場合に共用できる部分と一台ごとに増える部分を分ける。早期検知による便益は、過去停止件数と確認後の処置能力が分かってから試算する。根拠のない削減率や回収年数を最初から置かない。

RFPに書くべき要求事項

RFPでは「異常音AI一式」よりも、測定から判断までの入出力を定義する。機械名と対象部位、対象異常、運転モード、背景騒音、設置場所、必要な通知時間、想定利用者、既存の保全システムを列挙する。ベンダーにはマイク候補位置と、その理由、比較録音の方法を示してもらう。音声のサンプリング条件、同期、欠測時の扱い、録音保存範囲、ローカルとクラウドのデータ経路、機器交換時の再設定も要求する。設計の自由度を残しつつ、評価可能な成果物を指定する。

AI部分は、正常音の定義、運転条件の扱い、閾値設定、モデルの版管理、再学習のきっかけ、警報根拠の表示を記載する。異常音の名称を自動表示するなら、その分類を裏付ける学習・検証データを求める。未知の異常に対しては名称の推定より保留と確認導線を優先する。評価指標は、実際に得られる正解データの範囲に応じて決める。過去の故障音がないのに「全故障の検出率」を契約上保証させる仕様は検証不能である。

運用部分は、警報の送信先、確認画面、保全チケット化、応答責任、権限、教育、ログ、障害時対応を含める。工場にネットワーク境界や外部接続の規則があれば、事前に情報システム部門と確認する。端末とモデルの保守責任も決める。マイク清掃、設置角度の点検、端末更新、ログ容量、機器交換、ライン改造後の再評価の担当が曖昧だと、本番後に性能低下を見逃す。相見積もりの比較表には機能名だけでなく、この運用範囲を入れる。

RFPに添付する最小の情報表

FATとSATで何を分けて確認するか

FATは工場据付前に、合意した音声データと構成で機能を確認する。録音ファイルの入力、運転モードの識別、異常スコアと警報の出力、画面表示、モデル版の記録、権限、データの欠落と再送、通知先、障害ログを試す。異常サンプルがあるなら再生し、ないなら「試していない異常」と明記する。模擬音や合成データは接続試験に役立つが、現場の検出性能の証明とは分ける。受入資料には試験データの出典と使用許可を残す。

SATは実際の工場で、固定されたマイク位置、現場の背景騒音、複数の運転条件、通信品質、シフト間の作業手順を確認する。試験開始前に位置とモデル版を凍結し、変更した場合は記録する。工程の通常イベントで警報が連発しないか、警報から担当者の確認まで流れるか、設備停止やネットワーク断後に復帰するかを検証する。SAT中に見つけた誤報をその場で閾値だけ上げて消すと、見逃しが増えたか分からなくなる。変更は理由と前後の評価を残す。

FAT・SATの合格は単一の「精度」ではなく、合意した試験表で判定する。各試験には前提条件、入力、期待結果、実結果、証拠、判定者、未解決項目を記す。異常音の実例が不足する場合は条件付き合格として、運用開始後に追加事例を集める再判定時点と責任者を決める。受入後のモデル更新が自動で合格扱いにならないよう、変更管理と再試験範囲も契約で定める。ここまで決めて初めてPoCから本番へ移せる。

受入後の再評価条件も試験表に残す。例えば設備を移設した、モーターや減速機を交換した、防音カバーを追加した、マイクの治具を外して付け直した、搬送品の材質や速度帯が変わった、といった変更は音の通り道や正常音を変え得る。変更のたびに全モデルを再学習するという意味ではない。まず設置図と運転条件を照合し、基準音を同じ条件で再録音して差を見る。差が小さければ監視継続を記録し、差が大きければ閾値とモデルの再評価を承認者に回す。変更前後の警報件数だけで判断せず、保全員が確認したイベントの内訳も見る。これにより「警報が減った」ことが性能向上なのか、見逃しを増やしただけなのかを調べられる。初期契約には、再評価に必要なデータの所有権、モデルと設定の引渡し形式、ベンダーへの依頼窓口、現場が自分で変更してよい範囲を明記する。担当者が異動しても根拠を追えるよう、判定履歴と設定変更を同じ設備IDで保存する。

タイ工場での運用：設備保全と現場の言語をつなぐ

タイで日本本社、現地製造、保全外注先が関わる工場では、警報の説明が言語をまたぐ。通知文は短く、設備ID、時刻、対象音源、現場の一次行動を固定項目にする。日本語の技術者向けレポートとタイ語の作業指示で、同じイベントIDを使う。翻訳された「異常」という語だけで停止指示を出さない。現場の設備名や部品名の表記をそろえ、保全記録との照合ができるようにする。

導入前に、マイクと作業者の位置関係、会話が入る可能性、工場の録音ルールを確認する。目的を設備監視に限定し、個人評価へ転用しない運用範囲を文書化する。音声の取り扱いに関する社内規程や適用法令は個別に確認する。クラウドへ転送する場合は、データの置き場所、委託先、アクセス権、削除方法を情報システム部門と決める。システムの価値は長く録音することではなく、必要な音の変化と確認結果を追えることにある。

既存設備の連携では、PLCに音声を入れ込む必要はない。音声処理端末がイベントを作り、PLCやMESから運転状態を受け、保全システムへ確認結果を渡す構成を検討する。機械監視を扱うOPC UAの仕様はデータをシステム間で交換する設計の参考になるが、実設備が対応しているかは別途確認が必要だ。手入力の工程情報から始める場合も、どの時刻の音とどの運転状態を結んだかを残す。連携方式よりも、現場の意思決定に必要な文脈が失われないことを優先する。

異常音検知AIの導入で避けたい五つの失敗

第一は、マイク位置を記録しないこと。初期録音と本番録音の条件が違えば、モデルの比較が意味を失う。第二は、異なる運転モードを同じ正常音に混ぜること。起動時の音を故障と誤認し、現場の信頼を失う。第三は、ベンチマーク成績を自社ラインの保証値として扱うこと。DCASEは研究比較に有用だが、設備と環境が違う。第四は、警報後の作業を決めないこと。通知が増えても点検や修理につながらない。第五は、変更管理なしにモデルと設備を更新すること。設置角度、部品、速度が変わっても古い基準を使い続ける。

これらは高度なAI技術がなくても防げる。設置図、運転条件表、警報レビュー表、FAT・SAT試験表、変更履歴という普通の管理資料を一貫させることが先決だ。設備の状態監視一般については異常検知AIの対象領域の選び方を参照できる。既にPLCなどに記録された警報の分析は設備アラーム分析AIの導入で扱う。本稿は、その手前でマイクから音を測るときの実装条件である。

FAQ：工場の異常音検知AIを導入する前の疑問

異常音検知AIは故障原因まで特定できますか？

故障原因を推定できる場合はあるが、音の変化を検出しただけで原因が確定するわけではない。例えば同じ金属音でも接触、落下物、隣接設備、作業条件の変化があり得る。原因名を表示するには、その分類の学習データと現場での検証が必要だ。初期導入では「いつもと違う音を知らせ、現場が他の情報と合わせて確認する」と定義するほうが受入しやすい。

既存の振動センサーがあるならマイクは不要ですか？

測りたい現象で判断する。振動は筐体や軸受の機械的な動きを捉えやすく、音は空気漏れ、接触、製品と機械の相互作用などを離れた位置から観測できる場合がある。両者が同じ故障に同じ時間差で反応するとは限らない。既存信号で十分ならマイクを追加する必要はない。逆に現場の異音が先行する事例が確認できるなら、比較PoCを行う意味がある。追加のセンサーが情報を増やすかを検証する。

異常音の録音がないとAIは作れませんか？

正常音だけから外れ値を知らせる方法は検討できる。DCASEの研究課題も正常音だけを使う設定を扱う。ただし、その方法で現場の重要な故障をどの程度拾えるかは、実際の異常例がないと十分に評価できない。異常の種類を言い切らず、正常条件の網羅と警報レビューを優先する。運用後に保全結果を蓄積し、対象異常ごとの性能を更新していく。

マイクは何台必要で、どこに置きますか？

設備の大きさや背景騒音だけで一律に決められない。狙う音源と周辺の音源を描き、候補位置で比較録音する。ガード、反射、清掃、配線、交換作業まで含めて決める。単一マイクで対象音が分離できないときだけ増設や別センサーを検討する。必要台数を先に固定して見積もるより、位置比較をPoCの成果物に入れる。

AI異常音検知の費用と回収期間はどう見積もりますか？

マイク、取付、端末、通信、データ保存、モデル開発、既存システム連携、警報レビュー、保守を分ける。費用は対象設備数、設置難度、既存データ、必要な応答時間によって変わる。回収期間は、過去の停止・品質損失の実績と、検知後に実際に回避できる範囲から計算する。公開された別工場の削減率をそのまま当てはめない。最初のRFPでは価格総額とともに、運用負担と未検証範囲を比較する。

FATだけで本番受入にできますか？

FATで機能、データ経路、模擬入力は確認できるが、実工場の背景騒音、複数シフト、固定マイク位置、通信、現場の対応はSATで確認する必要がある。異常例が少ない場合はSATでも性能の全範囲は証明できない。条件付き受入と追加評価の時点を決め、モデルや設備条件が変わったら再試験する。

まとめ

工場の異常音検知AI導入は、機械にマイクを付ける案件ではなく、対象音を測り、正常条件を管理し、AIの警報を人の保全判断につなぐ案件である。狙う異常を一つに絞り、位置を固定して比較録音し、運転モードと音を結び、誤報と未検証範囲を明示する。RFPで運用とデータ経路まで要求し、FATとSATを分けて受け入れる。これならPoCで検証したことと、本番で約束できることを区別できる。

タイ工場で対象設備やマイク位置の候補を整理する段階なら、TOMAS TECHへご相談ください。異常音の録音がまだ少なくても、測定計画、現場レビュー、RFPと受入条件から検討できます。

参考情報

• DCASE 2024 Task 2: First-Shot Unsupervised Anomalous Sound Detection for Machine Condition Monitoring — 正常音学習、未知異常、運転条件や背景騒音によるドメインシフトの説明。
• DCASE 2024 Task 2 description and discussion — 課題設定と研究結果の論文。
• ISO 17359:2018 — 設備状態監視プログラムの一般指針。
• ISO 13374-1:2003 — 状態監視情報の処理、通信、提示に関する一般指針。
• OPC UA for Machine Tools, Part 1 — 機械監視情報と上位システムとの交換に関する仕様。
• OSHA Technical Manual, Section III, Chapter 5 — 騒音測定におけるマイク位置、向き、遮蔽の注意点。労働者のばく露測定の資料であり、設備異常検知の合格値を規定するものではない。