旭化成、製品不良を発見するAIの精度をMLOpsで確保

推論処理をサーバーレス化しムダなリソースを不要に

　MLOpsのシステム基盤として旭化成が最終的に選んだのがAWS（Amazon Web Services）である。その理由を弥生氏は、「AWSが各システムに必要な機能を『Amazon SageMaker』を中心に、ほぼ網羅していたことが第1だ。加えて、AWS上にデータを格納する当社工場がすでに10以上あり、MLOpsの知見の円滑な横展開が見込めたことも大きい」と説明する。

　システムの構築に向けては、「AWSが勉強会などで紹介している基本構成をベースに、独自の工夫を凝らしつつ作業を進めていった」（弥生氏）という。その1つに、AWSにデータを転送する際に、工場内の制御LANとは別に設けたDMZ（De-Militarized Zone：非武装地帯）を中継してアップロードする方式を採用したことがある（図2）。

図2●工場内の制御LANからAWSへのデータ転送ではDMZ（非武装地帯）を経由する方式を採用した

　織機の稼働状況を判断するための基データとなる原糸データと糸の軌道データは、工場内に設置しているサーバーで収集／管理している。だが、旭化成のセキュリティルールでは、「制御LANとAWSとの通信は非推奨」（弥生氏）になっている。このルールに従いながらクラウドと通信するためにDMZを経由することにしたわけだ。

　併せて、DMZとのAWSの接続にAWSの専用線サービス「AWS Direct Connect」を採用することで、データがインターネットに一度も出ない仕組みにしている。

　AIモデルの推論処理にはサーバーレス技術を採用した。織機を対象にしたデータによる推論頻度は「1台当たり数分に1度」（弥生氏）である。織機の稼働台数は変動するため、「ピーク時に合わせて推論のためのリソースを確保すると無駄が生じざるを得ない」（同）。

　そこで推論処理にあたっては、AWS Lambdaから都度、Amazon SageMaker ServerlessInferenceで推論エンドポイントを呼び出す手法を採用した。弥生氏は、「仮想サーバーが不要な構成のため、リソースの確保の最適化が図れ、すべての織機が止まっている間はコストを一切負担しなくて済む」と、そのメリットを話す。

　予測精度自体は、推論エンドポイントでの推論結果と、制御LANから送られてくる実績（正解）データを突き合わせて監視・可視化している。監視に対する現場の心理的なハードルを下げるために、可視化ツールには「あえてAWSのDB可視化サービスの採用を見送り、慣れ親しんだ既存ツールを使い続けている」（弥生氏）という（図3）。

図3●予測精度は、推論結果と実績を突き合わせて監視する

廃棄量の削減に貢献するMLOpsの自動化を視野に

　織機の異常検知システムを整備したことで旭化成では、「ガラスクロスの廃棄量が大きく削減できた」（弥生氏）。今後は、モデルを運用していくMLOpsの仕組みが、「モデルの陳腐化を防止するうえで大きな役割を果たすことになる」（同）。そこで視野に入れるのが「MLOpsの自動化」（同）だ。

　弥生氏は、「現段階では予測精度の監視など、人手に頼る作業が多分に残っており、それらを自動化したい。当面は、予測精度の低下をトリガーにした再学習と、複数アルゴリズムやパラメータによる新データを基にした複数モデルの作成、最も性能の良いモデルの本番システムの実装までの自動化が目標だ」と話す。

　旭化成では、DXの一環として他領域にもAI技術の活用を進めている。そこでも、織機の異常検知のために構築したMLOpsと同様の仕組みを展開することで、「せっかく導入しても管理・運用ができず使われなくなってしまう“野良”機械学習の一掃も目指す」と弥生氏は力を込める。