検索
特集

製造業のAI導入で最重要な「MLOps」、機械学習モデルができたら終わりじゃないエッジコンピューティング(2/2 ページ)

アマゾン ウェブ サービス(AWS)のオンラインユーザーイベント「AWS Summit Online」に、東大発のAI(人工知能)ベンチャー・アイデミー 社長の石川聡彦氏が登壇。「製造業におけるIoT×AI/ML基盤の構築とその運用事例」をテーマに講演を行った。

Share
Tweet
LINE
Hatena
前のページへ |       

製造業におけるAIプロジェクト特有の3つの課題

 多くの製造業企業がAI活用に取り組んでいるが、なかなか成功に結び付かないという話も聞かれる。製造業へのAI導入でさまざまな経験を積んできた石川氏は、製造業特有の課題として「本社(研究所など)と現場(工場など)のステークホルダーの変化」「Windows-Linuxおよびオンプレ-クラウド技術選定」「エッジデバイスとその通信手段の選定」の3つを挙げる。

 例えば、ステークホルダーの変化では、初期のPoC(概念実証)の制作はトップダウンの組織であるRD(研究開発)/DX(デジタルトランスフォーメーション)のチームが担当する一方で、実運用への意向に向けたプレ運用システムの担い手については、外注になる場合もあれば、内製する場合もRD/DXチームが引き続き中心になったり、現場が中心になったりすることもある。「あるべき姿としては、競争優位を規定するMLモデルの作成は現場が改善に集中し、運用システムは既存プラットフォームなどを流用してインフラを構築してできるだけ低コストにすべきだろう」(石川氏)。

ステークホルダーの変化
ステークホルダーの変化(クリックで拡大) 出典:アイデミー

 一定の成果が出ている製造業の取り組みとしては、基本的にRD/DXチームが現場に合わせるとともに、現場へのAIやIoTの啓発活動を推進して理解者を増やし、さらにはRD/DXチームのモデル開発者が現場に転籍して、運用までシームレスに担当するという選択肢もあるとした。石川氏は「RD/DXチームと現場は対立しやすい構造だが、現場側に理解者を増やすことで現場で運用のサイクルを回せるようにし、しっかり利益に結び付けられるようにすべきだ」と強調する。

 解決が難しい問題が、Windows-Linuxおよびオンプレ-クラウド技術選定だ。RD/DXチームはLinuxとクラウドを、現場はWindowsとオンプレを志向するため、AIプロジェクトの当初は対立することが多い。この問題の解決はケースバイケースになるという。「例えば、技術的制約としてセンサーのドライバーがWindowsしか対応しない場合もある。また、保守運用コストの面では、慣れないLinuxの採用をためらうこともあるが、人材育成で対応している企業もある」(石川氏)。

Windows-Linuxおよびオンプレ-クラウド技術選定
Windows-Linuxおよびオンプレ-クラウド技術選定。RD/DXチームと現場が対立しやすい問題だ(クリックで拡大) 出典:アイデミー

 クラウドとオンプレミスの対立についても、最近はハイブリッド型で対応することが多いようだ。以前のように現場へのクラウド導入を最初から否定されることはなく、メンテナンスコストの低減などで明確に効果が出ることから、採用には以前よりははるかに前向きだ。石川氏は「それでも、機械メーカーだとクラウドにデータを収集することが難しかったり、サプライヤーがOEMとのデータのやりとりに制限があったり、ビジネスモデル的な制限はある。そして、『もし何かあったらどうしよう……』という心理的な制限もまだまだ大きい。これらは啓発活動で解決していくしかない」と述べる。

 エッジデバイスとその通信手段の選定も導入の課題になっている。PoCのエッジデバイスとしても広く採用されている「Raspberry Pi」や「Jetson Nano」などは、Pythonのバージョンライブラリなどによって制約が出てしまう。

 例えば、Jetson NanoでAWSのエッジコンピューティングフレームワーク「AWS IoT Greengrass」を利用しようとすると、Jetson Nanoがオフィシャルサポートする「TensorFlow」がPython3.6をサポートするのに対し、AWS IoT GreengrassはPython3.7をサポートするというズレが生じてしまう。「Pythonのサブプロセスを利用して、AWS IoT GreengrassデーモンはPython3.7を実行するという対応法があるが、センサーやローカル環境によっては一律的な対応ができるわけではない。開発手法としてはウオーターフォールではなく、アジャイルでなければ、こういった事態に機動的に対応できない」(石川氏)という。

エッジデバイスによって規定される環境の制約
エッジデバイスによって規定される環境の制約。「Jetson Nano」と「AWS IoT Greengrass」の場合(クリックで拡大) 出典:アイデミー

AWSベースの「Modeloy」は月額30万円から

 アイデミーが対応した製造業のAI/IoTプロジェクトでは、先述のAWS IoT Greengrassの他、エッジデバイスを管理する「AWS IoT Core」や、エッジデバイス上でMLモデルに基づく推論などさまざまな処理を行う「AWS Lambda」、ストリームデータ収集を行う「Amazon Kinesis」、データストレージとなる「Amazon S3」、可視化のツール「Amazon QuickSight」、MLモデルの再訓練などに活用できるマネージドサービス「Amazon SageMaker」などだ。

アイデミーが製造業に提案したAI/IoTプロジェクトにおけるAWSアーキテクチャの全体像
アイデミーが製造業に提案したAI/IoTプロジェクトにおけるAWSアーキテクチャの全体像(クリックで拡大) 出典:アイデミー

 石川氏は「IoTは考えることがたくさんあるが、AWS IoT Greengrassを活用すればエッジデバイスの管理がかなり楽になる。Amazon Kinesisは製造現場の大量データ収集を二アリアルタイムで対応できる。そしてAmazon SageMakerは、MLOpsの基本的な機能を楽に実装できる」と語る。

 アイデミーは、これらのAWSのさまざまなサービスをベースに、機械学習の実運用フェーズの工数をさらに削減するプラットフォームとして提供しているのがModeloyだ。月額利用料も、ストレージ1TBと1000個までのIoTデバイス接続のプランで月額30万円からと導入を検討しやすい価格に設定。モデル構築に必要な初期のデータ収集についても、約3カ月で約500万円で対応している。「Modeloyによって、現場がMLモデルの構築、改善に集中できる手助けができれば」(石川氏)という。

MLモデルの構築における「Modeloy」のカバー範囲
MLモデルの構築における「Modeloy」のカバー範囲(クリックで拡大) 出典:アイデミー

⇒その他の「モノづくり最前線レポート」はこちら

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る