機器点検のスケジューリングを人に代わってAIエージェントが実行
2025/02/01に開催された第21回FA設備技術勉強会で発表した内容です。
ロボホンは愛嬌ある表情をします。歌って踊ることもできます。
なんたって可愛い！可愛いは最強なんです。
ロボホンのアプリもたくさん作りました。
コロッケそばの魅力は私の周囲に伝わりません笑。
それは名古屋圏に立ち食いそば文化がないためだと思います。
多くは「そばにコロッケ乗せて何が嬉しいの？」ってことになります。
体験がないためイメージできないのです。
首都圏に行くと必ず馴染みの立ち食いそば屋さんで私のレギュレーションに適合したコロッケそばを食べます。
1.本日のお話
2.LLMが知っていることは限定的
まずLLMの特徴ですね。LLMは大規模言語モデルのことでインターネット上の大量のテキストデータで訓練されたモデルです。
このLLMは知っていることが限られています。
例えば最後の学習時期が2023年4月だとすると
このLLMに2024年MLBワールドシリーズで優勝したチームを聞いても答えることができません。
LLMは知っていることが限定的というわけです。
3.LLMが知らない情報を与える方法
このLLM、知ってることが限定的では実用範囲も狭くなります。
そこでLLMが知らない情報を外部から与える方法があります。
１点目はIn-context Learningの活用です。
２点目はRAGという技術の活用
３点目はLLM自身が必要とする情報をAgentという手足を使って取得するというものです。
（１）In-context Learning （文脈学習）
In-Context Learningは、文脈学習といいます。
これはLLMが元々持っている機能です。
LLMを利用するにはプロンプトいう器に質問を入れる必要があります。
通常は質問や依頼事項だけ書くのですが、文脈という形でLLMが本来知らないだろう情報をプロンプトに書き込むことでLLMは自身の学習内容で答えられない場合この文脈の情報を使って回答してくれます。
（２） RAG（ Retrieval Augmented Generation）
次にRAGという方法です。
これは文脈学習と基本的には同じです。文脈として与える情報を外部データベースから検索するというものです。
元データの例は社内文章、社内規定などLLMが知らない情報を扱うことに向いています。
ここでは、質問内容に関連する情報、つまり似ている文章を見つけて取得する必要があります。
文章のようなデータは定性的なデータです。
よって検索は、「似たようなデータかどうか？」が大事になります。この似たようなデータかどうかをベクトル検索と言う空間の座標が近いか遠いかで似ている、似ていないと判断することができます。
RAGの場合、
・質問に類似した情報をベクトル検索という形で質問の回答になりそうな
データを複数個取ってきます。これをRetrievalと言います。ラブラドール
リトリーバーやゴールデンリトリーバーは元々は狩猟犬ですね。
獲物を取って戻ってくる、これがRetrievalですね。
・取ってきた情報はプロンプトに質問と一緒に書き込みます。ユーザの質問
だけが書き込まれたプロンプト内容にRetrievalで取得した情報を加えて
拡張する、これをAugmentedと言います。
・質問と関連情報を使って回答生成するのでGenerationと言います。
このRetrieval、Augmented、Generation頭文字をとってRAGと呼んでいます。
（３） LLM自身が必要とする情報を「Agent」を使って取得する
そしてAgentですね。
LLMが知らいない情報をLLMの手足となるAgentに取得してもらいます。
これはプロンプトエンジニアリングのReactという手法でAgentとLLMが会話のキャッチボールをしながら目的を果たすというものになります。
Agentですが何かの「コト」を行う特定のプロンプトを持ったLLMをおんぶしているイメージですね。
またAgentは複数のAgent同士が連携してある目的を果たすこともできます。
（４） LLMは、プロンプトの内容次第
ここまでLLMについておさらいしました。
LLMはプロンプトの内容次第で色々コントロールできます。
こういった仕掛けは「AIオーケストレーション」と呼ばれています。
そしてこのAIオーケストレーションを実現できるライブラリにLangChainというものがあります。
今回はこのLangChainを使ってAIエージェントを作ってみました。
従来、生成AIは何かを聞いて回答を得る、というチャット型が多かったのですが今後は業務タスクを生成AIを使って実行や複数のタスクの実行を自動化できるAIエージェント型がビジネスシーンで活用されると言われています。
４. 作成したAIエージェントのイメージ
次に今回作ったAIエージェントのイメージです。
このような依頼内容をします。
・機器稼働状況を調べてね
・アラームあれば点検スケジュールしてね
・既存の点検スケジュールを調べて考慮してね新しい点検スケジュールを
考えて候補を３つ提案してね
LLMは外部情報を知る術がありません。そこでAgentが代わりに情報を得てLLMに与えます。
AIオーケストレータがLLMと会話しながらAgentをハンドリングして目的を果たします。
・IoT機器稼働データはLangChain Agents のToolを使って取得しています。
Toolの中でIoT機器稼働データ取得のAPIを利用します。
・点検スケジュール、保守チーム情報の検索やデータ抽出などのデータ操作
はLangChain Pandas Dataframe Agentでやっています。
LangChain Pandas Dataframe Agentを使うことでデータの操作を行うpythonコードをLLMが生成してAgentがコードを実行できる、という特徴があります。
LLMは、Agentにデータ操作のプログラムコードを与えて必要なデータだけもらって分析する、ということになります。まさしくLLMがAgentを自分の手足のように使っている様子が浮かびますね。
次にシステム構成です。
現場に設置された機器環境をOT環境と呼びます。
機器の稼働状況がクラウドに定期的にアップロードされます。OT環境のデータはインタネットを利用しない閉塞網を使うことが望ましいですね。
一方、AIエージェントが動く環境がIT環境になります。
AIエージェントは現場機器の稼働状況を監視してアラームがあれば、点検チームのスケジューリングを行います。
LLMとAgentが連携してタスクを実行する、ということです。
５. AIエージェントの説明
次に内容を説明をします。
AIエージェントが期待通り動いているか？をLnagSmithという可視化ツールを使って確認しています。プロンプトを通したAgentとLLM間の会話のキャッチボールを確認できます。
まずは既存のスケジュールの取得です。
この既存の点検スケジュールに新しいスケジュールの候補を割り当てることになります。
これは保守チーム情報の取得です。
どのチームがどんな点検内容を担当するかが分かります。
例えばアラームが「温度異常」とだと、このデータから「温度異常」は
Dチームが担当だ、とLLMが判断できます。
この画面は、現場機器の稼働状況をIoT監視装置から取得したものです。
温度異常が発生しています。温度異常が発生していることをLLMに伝えます。
つぎは保守チームのスケジュール割当てを行なった結果です。
３つの候補がスケジューリングされた様子がわかります。
温度異常に対応できるDチームが割り当てられています。
最終的にどれにするかは人がやったほうがいいね、というストーリーです。
次に点検スケジュールの提案が正しいかを見てみます。
左側が依頼内容です。プロンプトテンプレートを用意してユーザの依頼内容を取り込んでいます。
主な条件は、この４つですね。
・作業時間は10:00から17:00の間の1時間です
・割当候補は必ず３個です
・１個目の割当候補は必ず2024年11月05日に割当てて下さい
・割当候補は各々、同じ年月日に割当てず、適当にバラバラにしてください
提案されたスケジュール候補はこの条件を満たしていることがわかります。
つぎに、発生した機器アラームがLLMに伝わっているか？をLangSmithで確認します。温度異常がプロンプトに反映されてLLMに伝わっていることがわかります。
これは、LangChainのPandas Dataframe Agentが依頼内容に合った、データ操作用のpythonコードを生成した様子の一部になります。
依頼内容の各ステップのコードが生成されています。
Pandas Dataframeというのはpythonのメモリデータベースのようなものです。
６. AIエージェントは、期待通り動くとは限らない
AIエージェントですが必ず期待通りに動くか、というとそうは限らないですね。
例えば、今回はLLMにデータ操作のためのpythonコード生成をしてAgentが実行するわけですがPythonコードにエラーがあってループするってことがあります。また最終回答が間違っているっていう場合もあります。
７. Agentic workflowによる結果の改善
AIエージェントが間違いを起こすのですがその対策にはAgentic workflowという手法があります。
各Agentの役割とか指示事項を定義してあとはお任せ！では間違いが発生した場合の対策ができません。
Agentic workflowはAgentの実行順序をワークフローで定義します。
・Agentの途中の挙動や結果監視する
・LLMが反復的にタスクを実行して出力結果を改善する
ということができます。
8. まとめ
それではまとめにはいります。
・「自動化」はLLMとAgent間のキャッチボールの話
・AIは確率で挙動を決めているだけ。間違える場合があります
そのため自動化を行う場合は間違えるリスクを考えるべき
・反面、生産性向上にLLMとAgentは間違いなく貢献する
Agentによる業務タスクの自動化はリスクに対応できるAgentic workflowの
採用が有効です。
このワークフローの中に「人がデシジヨンできる」
「Human-in-the-Loop」という仕掛けが有効であり、実装が望ましいですね。Agentが判断できないケースは人に指示してもらうってことです。
そして「LLM-as-a-judge」というLLM自身で結果を評価する仕掛けが今後普及するでしょう。でも「Human-in-the-Loop」と組み合わせて利用した方がよさそうです。
最終的にはAIエージェントが抱える、現状の様々な課題を乗り越えて完全自立型Agentに辿り着くのではないでしょうか？
そう考えると2045年に訪れると言われるシンギュラティはもっと早く訪れるかもしれませんね。
9. Xでの反応
Xからコメントを頂きまして今後の励みになります。ありがとうございました。
no+eにいただいたコメントです。ありがとうございました。
10. 発表を終えて
いつもはIT系の技術コミュニティに参加していますが今回は場違いな
FA系の技術コミュニティに参加しました。現場機器の稼働状況を取得、
って部分のみFAに関係してるだけでした。
他の皆さんの発表内容は私には新鮮でとても勉強になりました。
私はマイコンやラズパイ、IoTセンサーなど諸味で使っていてハードウエアに
多少の馴染みがあります。
今回の勉強会はPLC制御設計など興味深いものもあって有益でした。
今回も色々な識者の方々の知見に刺激を受けました。技術コミュニティは
最高です！
発表スライド
用語
LLM:大規模言語モデル（Large Language Models:LLM）
大量のテキストデータをディープラーニングを用いて構築された言語モ
デル。人間の言語を理解、生成できるAI。
React（ReasoningとActingを組合せた用語）
プロンプトエンジニアリングの一つ。言語モデルで推論とタスクを遂行
するための手法。
LangChain
LLMに基づいてアプリケーションを構築するためのオープンソースフレ
ームワーク。
Agent
LLMに代わって、タスクを自律的に実行する生成AIの仕組み。
Agentic Workflow
あるタスクを1つのLLMとAgentですべて行うのではなく、そのタスクを
細分化して、複数のLLMとAgentで行う。この時、各Agentの実行順序や
内容の検証をワークフローで表現すること。
Human-in-the-Loop
AIエージェントのワークフローで人とコミュニケーションできるように
する仕掛け。人をワークフローに組込むことでAgentic workflowの強化に
繋がる。Agentが判断に困った時、購買などのように審査承認が
必要なケースに有効。
LangSmith
LangChainの開発元がリリースした、LLMアプリ開発支援サービス。
LLMアプリケーションデータの保存、編集、再実行、管理が可能。
Streamlit
Pythonで作ったデータ分析のコードを、Webアプリケーションとして
簡 単に公開できるライブラリ。機械学習モデルの可視化、データの探
索、インタラクティブなダッシュボードの作成など、幅広い用途に利用
できる。
FA
Factory Automationは、生産工程を自動化するシステムを示します。
OT
Operational Technologyは、工場などの設備、生産現場でに使われる、
システムや設備を動かすための制御/運用技術のことです。