専門家一覧
製造業における「TinyMLを活用したAI異常検知」と専用チップの導入

クラウド不要の予知保全：STM32とEdge Impulseで実装する振動異常検知の完全ワークフロー

約15分で読めます
文字サイズ:
クラウド不要の予知保全：STM32とEdge Impulseで実装する振動異常検知の完全ワークフロー
目次

エッジコンピューティングの実装現場では、「工場の全モーターに振動センサーを付けたいが、クラウドへの通信コストで予算が消える」「異常発生から通知までの数秒の遅延が致命的な故障につながる」といった課題に直面することが少なくありません。DX推進でAI導入を検討しても、クラウドの「コスト」「レイテンシ」「セキュリティ」の壁に阻まれ、PoC止まりになるケースが後を絶ちません。

しかし、わずか数千円のマイコンチップ内でAIモデルの実装が完結し、異常検知から0.1秒以内にラインを停止できるとしたらどうでしょうか。外部へのデータ送信も一切不要です。

これが、TinyML（タイニー・エムエル）の世界です。

今回は製造業でニーズの高い「回転機器の振動異常検知」をテーマに、STM32マイコンとEdge Impulseを用いて、実稼働する予知保全システムを構築する技術的ワークフローをコードレベルで解説します。センサーデータ解析の知見を活かし、手元のマイコンボードで未来の故障を予知する技術の扉を開けましょう。

1. クラウド依存からの脱却：製造現場におけるTinyMLの技術的優位性

なぜリッチな計算資源を持つクラウドではなく、制約の多い「エッジ」でAIを動かす必要があるのか、データ分析とシステム実装の観点から紐解きます。

レイテンシと帯域幅：クラウドAIが現場で通用しない理由

製造ラインの異常検知には「リアルタイム性」が求められます。高速回転するスピンドルモーターに異変が生じた際、即座に制御信号を送らなければ製品不良や設備破損を招きます。

クラウドAIでは、センサーデータがゲートウェイとインターネットを経由してサーバーへ送られ、推論結果が返るまでに数百ミリ秒から数秒のラグが発生します。これは「推論レイテンシ」だけでなく「通信レイテンシ」が支配的だからです。

一方、TinyMLはセンサー直結のマイコン内で推論が完結します。Cortex-M4F搭載マイコンで単純なニューラルネットワークを実行した場合、推論時間は数ミリ秒から数十ミリ秒です。通信遅延は物理的にゼロであり、この圧倒的なレスポンス速度がエッジコンピューティングの現場でTinyMLが選ばれる理由です。

また、振動データは高周波（数kHz）でサンプリングするため、生データをすべてクラウドに送ると膨大なデータ量になります。常時アップロードは通信帯域を圧迫し、ネットワークインフラへの過度な負荷となります。

プライバシーとセキュリティ：データ外出しリスクの排除

製造業にとって生産設備の稼働データや製造パラメータは極めて機密性の高い情報であり、「工場のデータを外部クラウドに置きたくない」という要件は実務で頻出します。

TinyMLはデータをデバイス内で処理し、即座に破棄するか推論結果（「正常」「異常」などのメタデータ）のみを出力します。生の波形データが工場外に出ないため、情報漏洩リスクを根本から排除できます。これはセキュリティ要件の厳しい防衛産業や半導体製造装置などの分野で高く評価されています。

消費電力とコスト：常時監視を可能にするマイクロワット級の運用

クラウドAIでは推論回数に応じた従量課金や、常時接続のための通信SIM費用（月額数百円〜数千円/台）が発生し、数千台のモーターを監視する場合のランニングコストは莫大です。

対してTinyMLデバイスは、推論時の消費電力が数ミリワットから数マイクロワットです。電池駆動で数ヶ月から数年の稼働が可能になり、配線工事不要で既存設備に後付けできます。ハードウェアコストも数百円〜数千円の汎用マイコンで済むため、初期投資を大幅に抑えられます。

近年のマイコンの進化とアルゴリズムの軽量化技術（量子化など）の組み合わせにより、安価なマイコンでも驚くほどの精度が出ます。次章から具体的な実装準備に入ります。

2. ハードウェア選定と開発環境のセットアップ

異常検知プロジェクトの成功は適切なハードウェア選定から始まります。リソース制約の厳しいエッジ環境において、「とりあえず手元にある開発ボード」を選ぶと後工程のボトルネックになりかねません。

MCU vs 専用AIチップ：異常検知に最適なプロセッサの選び方

振動データの解析にはFFT（高速フーリエ変換）などのデジタル信号処理（DSP）が不可欠です。選定するマイコン（MCU）には、浮動小数点演算ユニット（FPU）やDSP命令セットが含まれていることが重要です。

  • 推奨アーキテクチャ: Arm Cortex-M4F, M33, M7
    • これらはDSPライブラリ（CMSIS-DSP）が最適化されており、信号処理を効率的に行えます。
  • メモリ要件:
    • RAM: 振動データのバッファリングと推論実行用エリアとして、最低でも32KB、できれば96KB以上を推奨します。
    • Flash: モデルの重みパラメータとファームウェア全体を格納するため、128KB以上を推奨します。

2026年時点の最新トレンドとして、Intel Core Ultra Series 3 (Panther Lake)のNPU 5（最大50TOPS）や、AMD Ryzen AI 400シリーズのXDNA 2強化版（最大60TOPS）などが登場しています。これらはPCや高性能ゲートウェイでの大規模モデルローカル実行用に設計されています。

しかし、数mWの電力で動作させるセンサーノードにおいて、これらの高性能チップは消費電力の観点からオーバースペックです。導入ハードルやコスト、バッテリー駆動の要件を考慮すると、汎用的なSTM32シリーズやnRF52840などを搭載したマイコンボードから始めるのが実務的に賢明です。

推奨開発ボードのスペック比較

異常検知の開発に適したボードは以下の通りです。

  1. STMicroelectronics B-L475E-IOT01A (Discovery kit for IoT node)

    • MCU: STM32L475 (Cortex-M4F, 80MHz)
    • RAM: 128KB / Flash: 1MB
    • センサー: 高性能な加速度センサー、ジャイロ、磁気センサーなどをオンボード搭載。
    • 特徴: 産業用途での実績が多く、技術資料も豊富です。

  2. Arduino Nicla Sense ME

    • MCU: nRF52832 (Cortex-M4F, 64MHz)
    • センサー: Bosch製のAI機能付きセンサー（BHI260AP）を搭載。
    • 特徴: 切手サイズで非常に小さく、実機への取り付けテストに最適です。

本ガイドでは、汎用性と入手性のバランスが良いSTM32 B-L475E-IOT01Aを例に進めます。

開発環境のインストール手順

AIモデルの実装を効率化するため、データの収集からモデル変換までをブラウザ上で完結できる統合開発環境Edge Impulseを使用します。

  1. Edge Impulseアカウント作成: 公式サイトで無料アカウントを作成します。
  2. Edge Impulse CLIのインストール: PC側でデバイスと通信するためのコマンドラインツールです。Node.js環境が必要です。
    npm install -g edge-impulse-cli
  3. ST CubeIDE / CubeProgrammer: STM32の開発と書き込みに必要です。ST公式サイトから最新版をダウンロードします。
  4. ファームウェアの更新: Edge Impulseが提供する専用ファームウェアをボードに書き込み、ブラウザから直接センサーデータを取得できるようにします。

準備完了後、コマンドプロンプト（またはターミナル）で edge-impulse-daemon を実行し、ボードをプロジェクトに接続します。これで物理世界の振動をデジタルに取り込むパイプラインが開通します。

3. 高品質なデータセットの構築とデジタル信号処理（DSP）

ハードウェア選定と開発環境のセットアップ - Section Image

「Garbage In, Garbage Out」はAIの鉄則ですが、リソースの限られたエッジ環境では特に顕著です。限られたモデルサイズで性能を出すには、データ分析の知見を活かした前処理（DSP）が鍵を握ります。

正常データと異常データの収集戦略：不均衡データの扱い方

予知保全モデル構築の最大の課題は「異常データが集まらない」ことです。機械は基本的に正常稼働するため、データセットは正常データに偏ります（不均衡データ）。実務の現場では以下の戦略がよく用いられます。

  1. 正常データの網羅: 様々な運転モード（高速、低速、負荷あり、なし）での正常データを徹底的に集め、「ベースライン」とします。
  2. 擬似異常の作成: 安全が確保できる範囲で意図的に異常を作り出します。
    • モーターの固定ネジを少し緩める（緩み）
    • 回転軸に偏心荷重（テープで重りをつけるなど）を与える（アンバランス）
    • ファンに異物を接触させる（異音・接触）
  3. 転移学習の活用: 異常データが少ない場合、異常検知（Anomaly Detection）アルゴリズム（K-meansやGMMなど）を使用し、「正常の分布から外れたもの」を検知するアプローチをとります。

サンプリングレートと周波数解析の最適化

センサーデータ解析においてサンプリング周波数は非常に重要です。ナイキストの定理により、サンプリング周波数の半分の周波数までしか解析できません。

  • 例: 3000rpm（50Hz）で回転するモーターのベアリング傷を検知したい場合、その特徴は回転数の数倍〜数十倍の高周波域（数kHz）に現れることが多いです。
  • 設定: したがって、サンプリングレートは最低でも100Hz、できれば400Hz〜1kHz程度に設定します。STM32の加速度センサーなら十分対応可能です。

特徴量抽出：生波形からスペクトログラムへの変換設定

マイコンに生の時系列データをそのまま入力するのは計算リソースの無駄です。DSP処理で「特徴量」に変換します。

Edge Impulseの「Spectral Analysis」ブロックを使用する場合、以下のパラメータが重要です。

  • Filter type: Low-pass filter（高周波ノイズカット）またはHigh-pass filter（重力加速度成分カット）。振動解析ならHigh-passが有効な場合が多いです。
  • FFT length: 周波数分解能を決めます。128, 256, 512などが一般的です。大きくすると細かい周波数の違いが見えますが、計算負荷が増えます。STM32L4なら256あたりから調整を始めます。

DSP処理後の出力は周波数ごとのパワー（スペクトログラム）になります。これにより、AIは「どの周波数帯が強く震えているか」という明確な指針を持って学習できます。

4. TinyMLモデルの設計・学習と量子化

データが整ったらモデルの構築です。限られたリソースに収まるコンパクトなモデル設計と、モデル最適化の核心技術である「量子化」について解説します。

異常検知に適したモデルアーキテクチャ

製造業の異常検知では、2つのアプローチを組み合わせるのが一般的です。

  1. ニューラルネットワーク分類器 (Classifier):

    • 「正常」「緩み」「アンバランス」など、ラベル付けされた既知の異常を分類します。
    • アーキテクチャ: 振動スペクトログラムを入力とする場合、Dense（全結合）層の多層パーセプトロン、または1次元のConv1D（畳み込み）層を用います。2〜3層で十分な精度が出ることが多いです。

  2. 異常検知ブロック (K-means / GMM):

    • 「未知の異常」を検知します。学習データのクラスタからどれだけ離れているか（距離）をスコア化します。
    • ニューラルネットワークの手前、DSP出力の特徴量に対して適用します。

Edge Impulseなどのプラットフォームではこれらを並列配置できます。既知の故障モードは分類器で特定し、未知の挙動は異常スコアで拾う二段構えのアプローチが有効です。

リソース制約下でのニューラルネットワーク設計

マイコンのRAMは非常に貴重です。モデル設計時は以下のトレードオフを意識する必要があります。

  • パラメータ数: 層を増やせば表現力は上がりますが、推論時間が延び、モデルサイズが肥大化します。
  • 入力サイズ: FFTのビン数やウィンドウサイズを調整して入力次元を削減し、計算負荷を下げます。

STM32L475（RAM 128KB）をターゲットにする場合、モデルと作業領域（テンソルアリーナ）を合わせてRAM使用量を50KB以下に抑えるのが目安です。残りの領域は通信スタックやセンサー制御、メインアプリケーション処理のために確保します。

モデルの軽量化：Post-training quantization（量子化）の実践

ここでモデル最適化における最も重要な工程を行います。AIモデルのパラメータ（32ビット浮動小数点: float32）を8ビット整数（int8）等の低ビット表現に変換するのが量子化（Quantization）です。

  • サイズ削減: モデルサイズを大幅に（一般的に1/4程度に）圧縮できます。
  • 高速化: 多くのMCUは浮動小数点演算よりも整数演算の方が高速に処理できます。
  • 精度維持: 適切なキャリブレーションを行えば、精度低下を最小限（多くの場合1%未満）に抑えられます。

Edge Impulse等では、学習完了後のデプロイメント設定でint8量子化を選択するのが標準的です。これにより、Flashメモリ使用量が20KBから5KBに減り、推論時間が15msから4msに短縮されるといった劇的な効果が期待できます。

極端に小さなモデルや複雑なモデルで精度が大きく落ちる場合は、学習段階から量子化の影響を考慮するQAT（Quantization Aware Training）の導入や、モデルアーキテクチャの見直しを検討してください。この量子化ステップが、実験室のAIを現場で使えるレベルへと昇華させる鍵です。

5. 実機へのデプロイとC++コード実装

TinyMLモデルの設計・学習と量子化 - Section Image

ブラウザ上でモデルができたら、マイコンのファームウェアに組み込みます。ここからはC++の世界です。

C++ライブラリのエクスポートとプロジェクトへの統合

Edge Impulseの「Deployment」タブからC++ Libraryを選択してビルドします。学習済みモデル、DSPコード、推論エンジンが含まれたソースコード一式がzipでダウンロードされます。

これをSTM32プロジェクト（CubeIDEなど）のフォルダ構成に組み込みます。主に edge-impulse-sdk, model-parameters, tflite-model フォルダが必要です。

推論エンジンの初期化とバッファ管理

マイコン側で推論を実行するには、センサーデータをバッファに溜め込み、推論エンジンに渡す必要があります。

まず、必要なヘッダーをインクルードします。

#include "edge-impulse-sdk/classifier/ei_run_classifier.h"

次に、センサーからデータを取得するコールバック関数を定義します。

// 生データを格納するバッファ
static float features[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE];

// 推論エンジンがデータを読み出すためのコールバック関数
int raw_feature_get_data(size_t offset, size_t length, float *out_ptr) {
    // バッファからデータをコピー
    memcpy(out_ptr, features + offset, length * sizeof(float));
    return 0;
}

リアルタイム推論ループの実装コード例

メインループ内での実装イメージは以下のようになります。

void loop() {
    ei_impulse_result_t result = { 0 };
    
    // 1. センサーから加速度データを取得し、features配列に格納
    // (ここでは実装省略：DMAやFIFOを使って高速にサンプリングすること)
    fill_buffer_from_sensor(features);

    // 2. 信号ラッパーを作成
    signal_t signal;
    signal.total_length = EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE;
    signal.get_data = &raw_feature_get_data;

    // 3. 推論実行
    EI_IMPULSE_ERROR res = run_classifier(&signal, &result, false);
    if (res != EI_IMPULSE_OK) {
        printf("ERR: Failed to run classifier (%d)\n", res);
        return;
    }

    // 4. 結果の処理
    printf("Predictions (DSP: %d ms., Classification: %d ms., Anomaly: %d ms.): \n",
        result.timing.dsp, result.timing.classification, result.timing.anomaly);

    // 異常スコアの判定
    if (result.anomaly > 1.0) { // 閾値は調整が必要
        printf("WARNING: Anomaly detected! Score: %.2f\n", result.anomaly);
        HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_SET); // 赤LED点灯
    } else {
         // クラス分類結果の確認
        for (size_t i = 0; i < EI_CLASSIFIER_LABEL_COUNT; i++) {
            if (result.classification[i].value > 0.8) {
                printf("%s: %.2f\n", result.classification[i].label, result.classification[i].value);
            }
        }
    }
    
    HAL_Delay(100); // 次の推論まで待機
}

このコードにより、センサーが振動を捉え、DSPが周波数を解析し、量子化されたニューラルネットワークが判断を下す一連の処理が、マイコン内でミリ秒単位で行われます。

6. 運用テストとパフォーマンス検証

5. 実機へのデプロイとC++コード実装 - Section Image 3

実装後は現場投入に向けた検証です。ラボ環境と実際の製造現場ではノイズ環境が異なります。

実環境での推論精度検証と誤検知（False Positive）対策

現場に持ち込むと、隣の装置の振動や台車の通過による床振動などを拾い、誤検知（False Positive）が頻発する課題によく直面します。

  • 混同行列（Confusion Matrix）の確認: テストデータに対する正解率を確認します。特に「正常」を「異常」と間違える率を下げることが重要です。
  • 閾値（Threshold）の調整: デフォルトの異常スコア閾値が適切とは限りません。現場で数日間データをログし、正常稼働時のスコア分布を見て、誤検知しないギリギリのラインに閾値を調整する泥臭い作業が実運用では不可欠です。

推論速度と消費電力のベンチマーク測定

コード内の result.timing 構造体を見ることで、処理時間を正確に把握できます。

  • DSP処理時間: FFT計算などにかかる時間。ここが長い場合、FFT長を小さくするか、より高速なMCUが必要です。
  • 推論時間: モデルの計算時間。量子化やモデル構造の見直しで改善できます。

消費電力については、電流計を使って1サイクルあたりの平均電流を測定します。必要に応じて推論間隔を広げたり、マイコンの低電力モード（Sleep Mode）を活用してバッテリー寿命を延ばす設計を行います。

継続的な学習（MLOps）に向けたデータ収集フロー

AIモデルは経年劣化や環境変化に対応するため更新が必要です。

エッジデバイスに「確信度が低い判定結果が出たときだけ、その波形データをSDカードや低帯域無線（LoRaWANなど）で送信する」機能を組み込むアプローチが有効です。集めた「現場の生きたデータ」でモデルを再学習させることで、システムはより堅牢に進化します。

まとめ：PoCから実装フェーズへ踏み出すために

ここまで、エッジコンピューティング環境における振動異常検知の実装フローを解説してきました。

  1. クラウド依存からの脱却: レイテンシゼロ、通信費ゼロの価値。
  2. 適切なハードウェア: Cortex-M4Fと加速度センサーの選定。
  3. DSPと量子化: 信号処理とモデル圧縮による最適化。
  4. C++実装: ライブラリを活用した組み込み開発。

これらは今、手元にある数千円のマイコンボードで実現可能です。実際の製品やラインに適用する際は、個別のセンサー選定や特定の異常パターンに対するモデルチューニングなど、データ分析やモデル最適化の観点から新たな壁にぶつかることもあるでしょう。しかし、本記事のワークフローをベースに試行錯誤を重ねることで、確実に実用化へと近づくはずです。

クラウド不要の予知保全：STM32とEdge Impulseで実装する振動異常検知の完全ワークフロー - Conclusion Image

参考リンク

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...