Amazon Web Services ブログ
生成 AI を活用して工場の稼働率低下の原因分析を行う
みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田と新澤です。
AWS Summit Tokyo が 2024 年 6 月 20 日（木）、21 日（金）の 2 日間、幕張メッセにて開催されました！
大盛況のまま無事イベントを終えることができました！
製造業向け展示ブースでどのようなデモが披露されたかについては以下の予告ブログもご参照ください。
AWS Summit Japan 製造業向け展示の見どころ紹介！
今回はその中から、「製造現場の IoT データをパートナーとともに 小さく早く製造 DX を実現」というタイトルのブースの一部をご紹介します。このブースでは、ミニチュア組立工場を動かしながら AWS を活用したスマート工場の複数のユースケースのデモを行いました。この中から「生成 AI を活用して工場の稼働率低下の原因分析を行う」というユースケースにフォーカスして解説させていただきます。
デモ全体像
図1~3にミニチュア組立工場外観図や、全体における生成 AI を活用した工場の稼働率低下原因分析の位置付けを示しました。
図1 ミニチュア組立工場外観図
図2 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのユースケースオーバービュー
図3 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのアーキテクチャオーバービュー
生成 AI を活用して工場の稼働率低下の原因分析を行うユースケースシナリオ
図4 には生成AIを活用して工場の稼働率低下原因分析を行う際の想定ユースケースシナリオを示しました。
データを取得することはできているものの、統合的に組み合わせて有効な分析に繋げることができておらず、宝の持ち腐れになってしまっているといった課題はよくあるのではないかと思います。
既に取得できている他の関連データを Amazon S3 に集約して、そういった大量の実データをソースとして、生成 AI の RAG （検索拡張生成）技術で稼働率の低下原因を分析することで、あるものを活用して小さく早く改善していこうというシナリオになっています。
図4 生成 AI を活用して工場の稼働率低下の原因分析を行う際の構成図とユースケース
図5 には、分析対象となる各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションのイメージの全体像を示しました。
4M とは、製造業での品質管理において重要な、Man（人）、Machine（機械）、Material（材料）、Method（方法）の4つの要素を指します。
4M 分析のフレームワークは、製造に関わる変更点を洗い出し、把握する手法の一つです。装置が計画外停止した際、その原因が装置そのものの不具合による場合もあれば、材料や部品の投入ミス、急なシフト変更に起因する作業者のオペレーションミス、工程変更が伝わっていなかったなどの情報伝達に起因するミス、厳しすぎる検査規格値など、様々な要因が考えられます。原因分析の際には、これらのどれかに固執することなく、抜け漏れなく要因を検証する必要があります。その際に有効なフレームワークです。
それぞれ、
- Man : ERPから取得した作業者情報の csv ファイル
- Machine : タブレットから取得した日常設備点検簿の excel ファイル
- Material : 在庫管理システムから取得した csv ファイル
- Method : 工程管理システムから取得した csv ファイル
として Amazon S3 にデータが集約されています。また、AWS IoT Greengrass 、AWS IoT SiteWise を介して取得されたデータを ”工場設備の稼働率 CSV” に変換し、それも S3 に格納します。これらの一連の CSV ファイルを RAG の分析対象として扱います。
図5 各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションイメージ
各種データ
図6~11では各種データの拡大画像およびデータの特徴を示しています。
図6 AWS IoT SiteWise からエクスポートされた raw データを csv に変換した設備稼働率ファイルイメージ
図7 Machine : タブレットから取得した日常設備点検簿の excel ファイル(正常な日)イメージ
図8 Machine : タブレットから取得した日常設備点検簿の excel ファイル(異常な日)イメージ
図9 Material : 在庫管理システムから取得した 4 月分の csv ファイルイメージ
図10 Method : 工程管理システムから取得した 4 月分の csv ファイルイメージ
図11 Man : ERPから取得した 4 月分の作業者情報の csv ファイルイメージ
各種データを見ると、まず設備稼働率 csv ファイルから、4/5 15:00 に稼働率が異常に低下していることがわかります。その日時の少し前に何か異変が見当たらなかったかを 4M ファイルで調べたところ、日常設備点検簿において、該当日時の少し前に空調設備異常があったことがわかります。その他のファイルでは特に異変はありませんでした。
取り扱うデータ量が多いほどこういった様々な事象を人間が分析するのは難しくなります。生成 AI のRAG 技術で効率的に分析してみましょう。
分析
Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションは、AWS が GitHub で提供しているこちらの Generative AI Use Cases JP よりデプロイしました。Generative AI Use Cases JP は、すぐに業務活用できるビジネスユースケース集付きの安全な生成 AI アプリ実装サンプルです。OSS として無償提供しており、生成AIの様々なユースケースを試すことができます。
図12 Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションでの RAG チャットの様子
このアプリケーションを用いて、 Knowledge base for Amazon Bedrock と連携した Agents for Amazon Bedrock で RAG を実行します。
RAG （検索拡張生成）とは、ユーザーからの問い合わせに対して、例えば社内のデータソースなどから関連情報を検索し、取得された関連情報も含めてモデルに入力し回答を得るものになります。信頼できる情報源から知識を取り入れることで、生成される応答の事実性と正確性が向上します。単にモデルの出力に頼るのではなく、根拠となる情報を参照できます。
Knowledge base for Amazon Bedrock は、基盤モデルと自社データソースを組み合わせた RAG をフルマネージドで実現可能にします。Knowledge Bases for Amazon Bedrock の仕組みや操作方法の詳細についてはこちらのブログをご参照ください。
あらかじめドキュメントデータ(今回の場合は CSV や EXCEL)を DB に検索可能な形（ベクトル表現）で格納しておきます。そして、ユーザーからの問い合わせから、内容の似たドキュメントを検索し、そのドキュメントの内容に基づいて基盤 Text モデルに回答させます。
図13 Knowledge base Amazon Bedrock の RAG のしくみ
Amazon Bedrock は様々な種類・数のモデルを提供しており、お客様はユースケースに適したものを選択いただくことができます。今回はそんなモデルの中から、図13 の③、⑤の Embedding モデルには Amazon Titan Text Embeddings v2 を、Text モデルには Claude 3 Sonnet を選択して RAG を実行しています。
Agents for Amazon Bedrock は、API を呼び出しタスクを実行する Agent 機能をフルマネージドで提供しています。基盤モデルを使ってユーザのクエリを理解し、登録された情報を Knowledge Base から検索したり、タスク完了に必要なアクションを実行することができます。
分析を始めます。まず、図12 における一つ目の質問で稼働率が極端に低くなっている日時を抽出してもらいました。すると、図6 を見ても分かる通り、22.0 % と異常に低下した日時が的確に抽出されました。
次に、その日時よりも少し過去に発生した事象から、稼働率が極端に低くなった原因について考察をしてもらいました。参照するファイルについても明確に指定をしています。生成 AI プロンプトエンジニアリング（モデルに入力・指示する文字列であるプロンプトを工夫して書いて、望ましい出力を得るための工夫）について、なるべく曖昧にならないように、簡潔に、明確に、十分な情報を与えることが重要です。
その際、4M 変換点フレームワークを意識してMan（人）、Machine（機械）、Material（材料）、Method（方法）の４種類のデータを網羅的に参照するように指示をすることで 、より精度の高い返答を得られる可能性が高まります。
すると、日常設備点検簿から空調設備にエラーコード 123 が発生したことが原因だという考察を返してくれました。他に大きな異変が確認できないため、この回答も妥当であることがわかります。
ただし、質問内容や検索対象の情報が複雑になるほど RAG で得られる回答の品質は低下する傾向があります。期待通りの回答が得られない場合は、こちらのブログで紹介されているようなRAG のパフォーマンスを改善するための手法を試すなどして応答品質の向上を図りましょう。
まとめ
このデモのように装置から生成される稼働情報が示す稼働率低下や、生産現場で日々発生する品質問題というのは、あくまで’結果’です。しかし、再発防止策を検討する際には、それらを引き起こした’原因’を突き止める必要があります。その原因は4M（人、機械、材料、方法）のどこかに含まれているだろうという考え方が、このデモの前提となっています。
一方で、実際の製造現場において、このデモのように綺麗に 1 ファイルごとに 4M のそれぞれの M が情報としてまとめられているケースは少ないかもしれません。それでも従来からのフレームワークである 4M 変化点を意識して、プロンプトに参照先を指定することで、より早く原因に辿り着けるのではないか、というのがこのデモの主旨になります。
生成 AI の RAG 技術を活用すれば、PDF や Word ファイルのような様々なデータを対象に、データに基づいて対話的に分析できます。今回は稼働率が極端に低くなっている日時を手動のプロンプト打ち込みで抽出しましたが、稼働率に閾値を設けて、それを下回った場合に自動的にアラートメールを流すようにして、それをキックに Amazon Bedrock に分析依頼をかけるようなパイプラインを構築して自動分析することも可能です。
AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、本デモブースのテーマである「小さく早く製造 DX を実現」することを目標に、対象を小さく絞って PoC (概念実証)を実施し、小さな成功体験を積み重ねて大きな業務変革に繋げていただけますと幸いです。
著者プロフィール
山田 航司 (Koji Yamada)
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト
製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。
愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。
新澤 雅治 (Niizawa Masaharu)
アマゾン ウェブ サービス ジャパン合同会社
IoT スペシャリスト ソリューションアーキテクト
製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。