[レポート]「Build Agentic AI Solutions for Industrial Predictive Maintenance」というセッションに参加しました #IND310 #AWSreInvent

概要

こんにちは、クラスメソッド製造ビジネステクノロジー部の田中聖也です。
re:Inventのセッション「Build Agentic AI Solutions for Industrial Predictive Maintenance」に参加しました！
僕自身、設備保全業務の経験があり、設備保全の業務プロセスや大変さを知っているので、非常に気になっているセッションではありました。
実際に受けてみて実務で使用できそうかという少し厳しめの目線で見た結果をまとめます。

セッション概要

タイトル

Build Agentic AI Solutions for Industrial Predictive Maintenance

概要

This hands-on workshop demonstrates how to leverage Amazon Bedrock and Agentic AI to transform industrial maintenance from reactive to predictive. Participants will learn how to implement a predictive maintenance solution by bulk importing historical operational logs into AWS IoT SiteWise, performing deep pattern analysis with Anthropic Claude Haiku 4.5 on Amazon Bedrock based on anomalies raised by AWS IoT SiteWise, and deploy real-time monitoring and alert systems.

本ハンズオンワークショップでは、Amazon BedrockとエージェンティックAI（自律型AI）を活用し、産業現場における保全業務を「事後対応型」から「予知保全型」へと変革する方法を実演します。参加者は、過去の運用ログをAWS IoT SiteWiseへ一括インポートし、そこで検知された異常データをもとに、Amazon Bedrock上のAnthropic Claude Haiku 4.5を用いて詳細なパターン分析を行います。さらに、リアルタイム監視とアラートシステムを構築することで、実践的な予知保全ソリューションの実装方法を学びます。

スピーカー

• Chris Azer, Principal GenAI Labs Solutions Architect, AWS
• Roberto Catalano, Solutions Architect, AWS
• Raju Gottumukkala, Senior Worldwide IoT Solutions Architect, AWS

セッション情報

• Type: Workshop
• Level: 300 – Advanced
• Topic: Industry Solutions

構築したアーキテクチャ

下画像のアーキテクチャをセッション時間中に構築します。
※必要なソースコード類はすでに実装済みであったので参加者は手順を確認しんがらAWSコンソールとコマンドの実行だけでよいという感じです。

なにができるようになるのか？

このアーキテクチャを組みことで以下のようなことができるようになります

閾値定義と異常検出ルールの自動作成

• 設備仕様に関する資料を自動で読み解いて重要な閾値を定義する
• 過去のセンサーデータから自動で閾値を定義する
• 自動でパターン分析を行って異常検出ルールを作成する

異常検出後の自動ワークフロー

異常検出後に以下のワークフローが実行される

1. 在庫管理フロー: 設備の予備品の在庫情報と金額をチェックする
2. 技術者一覧リストから修理に適したスキルをもった人材を確認すう
3. どのように修理すべきかの手順をまとめる

出力される成果物

センサーデータの解析

かなりの量のレポートが出力されるので、以下にレポートの概要を載せます。

1. 設備と現在の状況
   対象設備: MashTun100（醸造用マッシュタン）
   分析日時: 2025年12月2日 23:52:25Z
   現在の状態:
   State（状態）: Running（稼働中）
   Status（ステータス）: Holding2（待機・保持フェーズ）
   総合評価: 3つの異常（Anomaly）が検出されていますが、制御自体は正確に行われています。

2. 検出された3つの異常（Anomaly）
   レポートでは、以下の3つの異常がハイライトされています。
   ① 異常2：稼働率の最大化（重要度：HIGH）
   内容: 稼働率（Utilization）が**100%に達し、それが継続しています。
   リスク: 休息サイクルがなく、機器が常に最大能力で稼働しているため、部品の摩耗や熱による劣化が加速するリスクがあります。ストレス警告閾値（>98%）を超えています。
   ② 異常1：基準以下の動作温度（重要度：MEDIUM）
   内容: 現在温度（171.24°F）が、通常の動作範囲（180-220°F）よりも低いです。
   分析: ただし、設定温度（Setpoint）も「171°F」に設定されており、現在値と一致しています。これは故障ではなく、「意図的な冷却、または保持フェーズ（Holding）」**である可能性が高いと分析されています。
   ③ 異常3：バルブ位置の整合性（重要度：LOW）
   内容: 「稼働中（Running）」にもかかわらず、蒸気・水の両方のバルブが「閉（Closed）」になっています。

分析: これは「Holding2（保持）」ステータス特有の挙動であり、断熱機能によって温度が維持されているため、バルブを閉じること自体は正常な動作であると判断されています。

3. パターン分析と相関関係
   AIは単なる数値異常だけでなく、以下の「複雑なパターン」を特定しています。
   ストレス最適化モード: 稼働率100% ＋ OEE（設備総合効率）94.09% ＋ 正確な温度維持。これは**「短期的には生産効率が最大化されているが、長期的には持続不可能（故障リスク増）」**な状態を示唆しています。
   制御の正確性: 温度は設定値（171°F）に対して非常に正確に制御されており（偏差±0.24°F）、加熱素子の故障などは見られません。

4. 設定されているルール
   システムは以下のルールに基づいて監視を行っています。
   緊急停止: >230°F または <160°F
   ストレス警告: 稼働率 >98% が15分以上継続した場合
   OEE低下警告: <60% が15分以上継続した場合

まとめ・推奨されるアクション
このレポートの結論は、**「設備は設定通り（171°Fの保持モード）に極めて正確に動作しているが、稼働率が限界（100%）に達しており、過負荷による摩耗リスクが高い」**というものです。

在庫管理レポートの概要

ご提示いただいたファイル「在庫管理結果.html」は、産業用機器（MashTun100）で発生した重大な温度異常に対する在庫状況の分析レポートです。

1. 異常の状況

• 対象機器: MashTun100
• 異常の種類: 温度スパイク（Temperature Spike）
• 現在値: 235°F（閾値 220°F を超過）
• 重要度: CRITICAL（重大）
• 原因コンポーネント: 撹拌モーター（agitator_motor）

2. 在庫評価結果: ✅ すべて在庫あり
   修理に必要な部品はすべて在庫があり、即時の対応が可能です。発注による遅延はありません。

主要部品:

• 撹拌モーター (Agitator Motor): 3個 利用可能
• 温度センサー: 12個 利用可能
• 蒸気制御バルブ: 5個 利用可能
• その他（圧力逃し弁、ガスケットシールなど）も十分な在庫あり

3. 修理見積もり

• 推定部品コスト: $1,960
• 推定修理時間: 45分 〜 90分
• 対応優先度: 即時（0-15分以内の対応が必要）

技術者手配レポートの概要

1. 分析ステータスと対象

• ステータス: 🔴 STATUS.COMPLETED（分析完了）
• 対象資産: MashTun100（醸造用マッシング容器）
• 分析フェーズ: 第1.1フェーズ（LLM分析）まで完了し、エージェント3体が関与しました。
• データ状況: 指定期間（2025年11月8日～13日）の履歴データが存在しなかったため、現在のリアルタイム値に基づいて分析が行われました。

2. 検出された主な異常（計3件）
   現在、設備は稼働中（Running）ですが、以下の異常または注意点が検出されました。

• ⚠️ 稼働率が100%（重要度：高）
  • 稼働率が最大値の100%に達しており、休憩サイクルなしで連続運転されている可能性があります。部品の摩耗やストレス負荷のリスクがあります。
• ⚠️ 設定温度以下の動作（重要度：中）
  • 現在値 171.24°F（正常範囲は180-220°F）。
  • ただし、設定値（Setpoint）も171°Fであるため、意図的な「保温（Holding）」工程である可能性が高いと分析されています。
• バルブ閉鎖状態（重要度：低）
  • 稼働中（Running）でありながら蒸気・水バルブが閉じていますが、これは保温工程（Holding2）における正常な断熱状態と判断されました。

3. 現在の設備の健全性

• OEE（総合設備効率）: 94.09% と非常に高く、効率的に稼働しています。
• 温度制御: 設定値との誤差がわずか（±0.24°F）であり、制御システムは正常に機能しています。

実務で使えそうか

かなり限定的ではあるが使えそうな気はします。ただ、プロセス系製造に限られる感じです。
セッションのユーザーシナリオもプロセス製造になっていました。

実務で使用できそうなユースケース

※どれも大量生産系の設備に限ります

• 大型設備の予兆保全(モーターなどの一定の回転を維持する部品が大量)
• 品質管理に関係するような値(温度や湿度)の監視からメンテナンス計画の立案

実際のところ

設備設計書や修理履歴データ、予備品リスト、保全者のスキルリスト、業務の空き時間など様々な情報が必要であり、更新がされている必要があります。
設備設計書や修理履歴データ、予備品リストはあるかもしれませんが、更新がされていないや重要な部分が記載されていないなどの問題もありそうです。特に修理履歴データなどは「電磁弁を交換した」だけが記載されていることが多く、「なぜ電磁弁を交換したのか」が記載されていないことが多いため、そのデータだけでAIが学習できるかは疑問が残ります(ここは個別で検証してみます)
また、修理の優先度は生産計画と大きく関係しているので、そこらのデータを結びついて「緊急度」とかも出せるようになればいいなと思いました。

さいごに

受けてみて非常に楽しいセッションでした！！
設備のメンテナンスは工場内でみても、属人化や高年齢化が顕著な分野でもあるのでAIが学習できるデータを集めて活用して「誰でも設備保全可能な」状態にできたらいいなと思いました。

参考資料

• AWS IoT SiteWise を使用したデータ基盤の構築
• AWS IoT SiteWise Anomaly Detection を使用した ML ベースの異常検出を有効にする
• 構築するためのオープンソースフレームワークであるStrands Agents向け
• Amazon Bedrock でエージェントを構築およびデプロイする
• Amazon Bedrock AgentCore を使用して、エージェントアプリケーションを本番環境対応のシステムに拡張します
• 利用可能なすべてのAWS MCPサーバーを探索するため
• AWSスペシャリストやコミュニティエキスパートに質問する