課題：トラブル復旧の「属人化」を防ぐ
製造現場で設備トラブルが発生した際、復旧のスピードを左右するのは「熟練者の経験」です。しかし、過去の対応記録はMES（製造実行システム）の中に埋もれており、必要な時にすぐに引き出すことが困難でした。
本プロジェクトは、AWSの高いセキュリティと最新の生成AIを組み合わせることで、誰もが「熟練者の知恵」にアクセスできる環境を作る試みです。
現場で実際に起きていたボトルネック
設備停止が起きたとき、必要になるのは「一般論」ではなく、そのライン、その設備、そのアラームに近い対応履歴です。 ところが実際には、過去トラブルの記録がMESや日報、個別ファイルに分散しており、ベテランがいれば早いが、いない時間帯は調査からやり直しになることが少なくありません。
この差が、復旧までの時間だけでなく、対応品質のばらつきにもつながります。 そのため本プロジェクトでは、生成AIそのものよりも、現場の知識をどう検索可能な形に整えるかを重要な設計テーマにしました。
解決へのアプローチ
単にAIを導入するのではなく、以下の2つのデータを RAG（検索拡張生成） によってAIに認識させています。
- 過去のトラブル履歴: MESで集約された、実際の事象と処置の記録。
- 専門知識の集約: マニュアルなどのドキュメントを言語化したテキストデータ。
これにより、AIが現場特有のコンテキストを理解した上で最適な復旧ステップを提案します。
システム構成で意識したこと
このトラブル対応AIは、単純なチャットボットではなく、検索と回答を分けて設計しています。 まず関連するトラブル履歴や技術文書を検索し、その結果をもとにAIが回答を組み立てることで、現場に関係ない一般論が混ざりにくい構成を目指しました。
- 検索対象の整理: トラブル履歴、設備名、アラーム、処置内容を再利用しやすい単位で整形
- 回答の根拠づけ: 参照した履歴や手順を追いやすくし、現場判断の補助に徹する
- 運用しやすい構成: AWS Bedrock を軸にしつつ、将来的なモデル差し替えにも耐えられるよう疎結合に設計
実装のこだわり（PoCフェーズ）
現在はPoC（概念実証）として、AWS Bedrock上で複数モデルの検証を行っています。 特に、現場の人間が使いやすいインターフェースと、誤情報の少なさを重視してプロンプトの調整を重ねています。
また、回答を長く作り込みすぎるよりも、
- まず最初に確認すべき点
- 安全上の注意
- 次に見るべき過去履歴
がすぐ分かる形を優先しています。 現場では「読む時間」も限られるため、AIの賢さ以上に、返答の短さと順序が重要やと考えています。
この仕組みで狙っている効果
- ベテラン不在時でも、過去ナレッジにすぐ当たれる状態をつくる
- 復旧時の初動を早め、調査のやり直しを減らす
- 対応品質のばらつきを抑え、教育コストを下げる
- 現場に残った知識を次のトラブル対応へ循環させる
今後の展開
解決の提案だけでなく、処置が完了した後に「今回の対応を新しいナレッジとして蓄積する」という、自律的な知識循環の仕組みを構築していきます。 将来的には、設備やラインごとの傾向分析、よくある停止要因の可視化、保全教育向けのナレッジベース整備にもつなげていく想定です。