【Anomalib検証】製造業の異常検知はOSSでどこまで戦えるか？導入の壁と現実解

製造現場におけるAI活用のテーマとして、外観検査の自動化に関する課題は頻繁に議論されています。

専用のハードウェアとセットになった商用検査システムは高額なため、導入をためらうケースは珍しくありません。しかし、本格的な導入の前に、手元のデータとオープンソースソフトウェア（OSS）を活用し、小さく始めて成果を可視化するアプローチは非常に有効です。

近年、Intelが主導して開発している異常検知ライブラリ「Anomalib」が注目を集めています。ディープラーニングの専門知識がなくても、比較的手軽に最新の異常検知アルゴリズムを試せる点が魅力です。

本記事では、Anomalibを製造現場のデータセットに適用する際のポイント、セットアップにおける注意点、そしてオートエンコーダ（AutoEncoder）系モデルの限界について、データドリブンな視点から定量的な効果を交えて解説します。

検証対象：異常検知特化型ライブラリ「Anomalib」の概要

数あるAIライブラリの中でAnomalibを取り上げる理由は、これが単なる「学習モデルの寄せ集め」ではなく、製造業の異常検知プロセス全体をカバーしようとしている特化型フレームワークだからです。

通常、Pythonで異常検知AIを構築する場合、PyTorchやTensorFlowでモデルを記述し、データの前処理パイプラインを自作し、学習ループを回し、結果を可視化するコードを記述する必要があります。Anomalibは、この準備段階の作業を効率化します。

汎用フレームワークではなく特化型であることのメリット

Anomalibの最大の特徴は、「良品画像のみ」から学習する教師なし学習（正確には半教師あり学習に近いアプローチ）に特化している点です。

製造現場では「不良品データ」を集めるのが難しい場合があります。不良率が低いラインほど、AIに学習させるための「異常データ」が不足します。一般的な画像分類モデルで「良品 vs 不良品」を分類しようとすると、圧倒的なデータ不足に直面します。例えば、2015年の登場以来PyTorchの ResNet50_Weights.DEFAULT 等で現在も標準的に広く使用され続けているResNetであっても、そのまま良否判定モデルとして用いるには、現場のデータ事情と合致しないケースが多々あります。

Anomalibは、正常な製品の画像だけを大量に読み込ませ、「そこから外れたもの」を異常として検知するアプローチを前提に設計されており、現場のデータ事情に合致しています。

オートエンコーダ(AE)を含む主要アルゴリズム

このライブラリには、異常検知の主要なアルゴリズムが搭載されています。

• AutoEncoder (AE) 系: 入力を圧縮して復元する過程で、学習していない「異常」を復元できずにエラーとして検知する手法。
• GAN (敵対的生成ネットワーク) 系: 偽物を生成するAIと見破るAIを戦わせる手法。
• 特徴量バンク系 (PatchCore, Padim): 最新のトレンド。正常画像の特徴量をメモリに記憶し、それとの距離で異常を測る手法。

これらのアルゴリズムを、設定ファイル（config.yaml）を切り替えるだけで比較検証できるのが強みです。例えば、「まずはAEで試して、だめならPatchCore」といった試行錯誤を迅速に行い、段階的に精度を向上させるアプローチが可能です。

製造現場が注目すべき「良品学習」のアプローチ

ライブラリ全体の設計思想として、「画像のどの部分が異常か」をヒートマップで可視化すること（セグメンテーション）に重点を置いている点が重要です。

単に「NG」と判定するだけでは、現場の作業者は納得しない可能性があります。「どこが、なぜNGなのか」を定量的に示すことができれば、AIはブラックボックス扱いされにくくなり、現場のカイゼン活動にも直結します。Anomalibは、推論結果として元画像に異常箇所を赤くオーバーレイ表示する機能が標準で備わっており、PoC（概念実証）の段階で成果を可視化する際に役立ちます。

セットアップと学習コスト

実際にインストールして動作させる手順と注意点について説明します。

環境構築と依存関係

公式ドキュメントには pip install anomalib でインストールできると記載されていますが、実際にはもう少し複雑な場合があります。

特に注意が必要なのが、OpenVINOやPyTorchのバージョン依存関係です。Anomalibは開発が活発なため、アップデートによって過去の解説記事の手順では動作しないことがあります。

ローカル環境を汚染しないために、Dockerでの環境構築が推奨されます。公式リポジトリにDockerfileが含まれているため、それをビルドするのが効率的です。ただし、最新のDocker Engine（v29.1など）環境下では一部の古い機能が廃止されている可能性があるため、既存のワークフローや設定ファイルを使用する際は、最新バージョンとの互換性を確認し、必要に応じて設定を更新する手順を追加することが重要です。これにより、工場のオフライン環境にあるPCへ展開する際も、イメージを配布するだけでスムーズな導入が可能になります。

コンフィグファイルベースの管理による再現性

Anomalibの操作は、基本的に yaml 形式のコンフィグファイルを編集することで行います。

dataset:
  format: folder
  path: ./datasets/metal_nut
  category: metal_nut
  image_size: 256
  train_batch_size: 32
model:
  name: patchcore
  backbone: wide_resnet50_2

上記のように、モデルの種類、バックボーン（特徴抽出に使う事前学習モデル）、画像サイズ、バッチサイズなどを記述します。実験条件がコードの中に埋もれず、ファイルとして残るため、過去の設定を正確に再現し、継続的な改善サイクルを回す基盤となります。

独自の製造データセット読み込み

Anomalibは標準で「MVTec AD」というベンチマークデータセットを自動ダウンロードして試せるようになっていますが、実際の製造ラインの画像で検証したい場合は、ディレクトリ構造をAnomalibの期待する形式（Folder形式など）に合わせる必要があります。

• dataset/train/good/ (学習用良品)
• dataset/test/good/ (テスト用良品)
• dataset/test/defect_type_a/ (テスト用不良品A)

製造現場で取得される画像は、日付ごとやロットごとのフォルダに入っていることが多いため、学習用に整理するスクリプトを作成しておくと、データ準備の工数を定量的に削減できます。

精度検証：オートエンコーダモデルの検出能力と限界

金属部品の表面傷検知を想定し、古典的な「オートエンコーダ(AE)」と、現在注目されている「PatchCore」を比較したケースについて解説します。

MVTec ADデータセットを用いたベンチマーク結果

ベンチマークデータ（MVTec AD）での結果は、どちらも良好です。特にPatchCoreは、AUROC（予測精度の指標）で高いスコアを示します。ただし、ベンチマークで高得点が出るのは当然の結果と言えます。重要なのは、照明条件が一定でなく、背景が変化する実際の現場データにおいて、どの程度の精度を維持できるかという点です。

微細なキズ・異物の検出精度（ヒートマップ可視化）

オートエンコーダには限界が見られるケースがあります。

オートエンコーダは、入力を圧縮して復元する際に、学習していない「キズ」を復元できずに消えるため、入力画像と復元画像の差分を取ればキズが浮かび上がると考えられます。しかし実際には、良品部分の微細なテクスチャ（金属のヘアライン加工など）まで「復元ミス」として差分に出てしまうことがあります。

その結果、背景全体が異常判定され、本当に検知したい微細なスクラッチ傷がノイズに埋もれてしまう場合があります。

一方、PatchCore等の特徴量バンク系モデルは、この点において優れています。事前学習済みの特徴抽出器を使用しているため、テクスチャの違いを認識できます。微細なキズだけが、ヒートマップ上で明確に示される傾向にあります。

過検出（偽陽性）の発生頻度と調整難易度

製造ラインで問題となるのが「過検出（偽陽性）」です。良品を不良品として誤って判定すると、歩留まりが低下し、再検査の工数が増加します。

Anomalibには、検証データに基づいて最適な「しきい値」を自動計算する機能があります（F1AdaptiveThresholdなど）。この機能は便利ですが、自動計算されたしきい値をそのまま使用するのは推奨されません。

自動計算されたしきい値は「見逃しを減らす」方向に調整されることが多く、過検出が増える傾向があります。実際の運用では、自動計算された値を参考に、現場の品質基準（許容できるキズのレベル）に合わせて手動で調整し、歩留まりとのバランスを最適化する必要があります。

実運用への展開：推論速度とエッジデバイス対応

精度が高くても、検査に時間がかかると、高速な製造ラインには導入できません。タクトタイム（1個あたりの製造時間）内に判定を完了させる必要があります。

OpenVINO連携による推論高速化

Anomalibの開発元がIntelであるため、学習完了後のモデルを、コマンド一つでOpenVINO形式（IR形式）にエクスポートできます。

一般的なCore i7搭載の産業用PC（IPC）における推論速度の計測例では、OpenVINO最適化推論は約 40ms / 枚 (約25 FPS) という結果が報告されています。

40msであれば、多くのコンベアラインの速度に対応可能です。高価なGPUボードを搭載したPCをラインごとに設置しなくても、既存のIPCでAI検査を実行できる可能性があります。これはハードウェア投資を抑え、段階的なスケールアップを図る上で大きなメリットとなります。

工場内PC（非GPU環境）での動作検証

モデルの種類によって処理速度は異なります。PatchCoreは精度が高いものの、正常特徴量のメモリバンクを持つため、メモリ消費量が大きく、推論に時間がかかる傾向があります。FastFlowやSTFPMといったモデルは、精度と速度のバランスが良いとされています。

Anomalibを使用すれば、これらのモデルを同じデータセットで学習させ、「精度」と「推論速度」を定量的に比較して、現場の要件に最適なモデルを選定できます。

デプロイメントと運用コスト

OpenVINO形式にしたモデルは、PythonだけでなくC++からも呼び出せます。既存の検査ソフトがC++やC#で記述されている場合でも、DLLとして組み込みやすいという利点があります。

一方で、照明環境の変化や新製品の導入時に「再学習」が必要になる場合があります。商用SaaSではボタン一つで再学習できることが多いですが、OSSの場合はデータの再配置や学習コマンドの実行といった作業が必要です。導入にあたっては、これらの運用工数も定量的に見積もり、総合的なコストを考慮する必要があります。

まとめ：商用SaaS導入前に試すべきこと

Anomalibが適しているケースとそうでないケースをまとめます。

推奨するケース:

• Pythonの知識を持つエンジニアがいる: Anomalibは完全なノーコードツールではありません。
• 検査対象の品種が多く、専用装置のコストが高い: モデルを量産できるOSSの強みが活かせます。
• PoCで可能性を探りたい: 初期投資を抑え、小さく始めて成果を可視化するアプローチに最適です。

推奨しないケース:

• すぐにラインを稼働させたい: GUIやPLC連携機能の開発が必要です。
• メンテナンス要員がいない: 継続的な改善や運用が困難になる可能性があります。

商用ライセンス料や専用ハードウェアのコストを考慮すると、Anomalibを用いた内製化はコストを大幅に削減できる可能性があります。ただし、運用にかかる工数も定量的に評価する必要があります。

Anomalibは活発に開発されているものの、OSSであるため、バグがあってもメーカー保証はありません。GitHubのIssueなどを参照して自己解決する体制が求められます。

Anomalibは「AI異常検知の民主化」を促進する可能性を秘めています。高額な契約を結ぶ前に、まずは手元のPCで git clone して、自社のデータでAIの動作を確認し、段階的な導入戦略を描いてみてはいかがでしょうか。