推論レイヤー:LLM、エージェント、MCP

システムインテグレーター、OEM、オートメーションエンジニア向けの実践ガイド-パート 2

In partnership Thomas Strigl, CEO, realvirtual.io

著者について:トーマス・ストリグルはrealvirtual.ioのCEOであり、シミュレーションおよび自動化ソフトウェア分野で18年以上の経験があります。

この電子書籍シリーズの1 部「可視化からアクションへ」については、ここをクリックしてください。Unity、マシン情報システム、AI エージェント、産業用デジタルツイン

この電子書籍シリーズの1 部では、最新の機械情報システムの背後にあるアーキテクチャの基礎、つまりライブマシン信号、MESコンテキスト、構造化されたドキュメント、空間3Dインターフェースを単一の操作面に統合する方法を紹介しました。また、新しいEU機械規制やアセット管理シェル（AAS）などの新しい標準が、どのように機械ドキュメントを構造化された機械可読形式へと押し進めているかについても調査しました。コンポーネントにリンクされたデータ、バージョン管理されたドキュメント、コンテキスト化されたマシンの状態といった同じ基盤が、AIエージェントと大規模な言語モデルを産業環境で使用できるようにしているのです。

この電子書籍シリーズの最後となるこの第2部では、このアーキテクチャに基づいて、「グラウンディングレイヤー」、つまりAIシステムが信頼性の高い運用およびドキュメントコンテキストにアクセスする方法と、MCPなどのプロトコルがマシン情報システムスタックにどのように適合するかを調べます。

グラウンディングの問題

産業環境で大規模な言語モデルを組み込むための一般的な最初のアプローチは、既存のシステム（Webサイト、サポートポータル、またはHMI）にチャットボットを追加することです。実際には、この方法には限界があります。

言語モデル自体では、マシンの実際の状態、現在の製造オーダー、またはメーカー固有のドキュメントにアクセスすることはできません。そのコンテキストがないと、その応答は一般的なトレーニングデータに基づいており、古くなっている可能性があり、問題の特定のマシンが含まれる可能性はほとんどありません。

これは一般にグラウンディング問題と呼ばれます。LLMが産業分野で有用な出力ットを生み出すためには、通常、機械の稼働状態、関連する企業状況、製造元のドキュメントという3つの要素への体系的なアクセスが必要です。

第 1 回で説明した 4 レイヤーアーキテクチャは、この要件に十分対応しています。シグナルは現在の状態を提供します。MES は操作コンテキストを提供します。ドキュメンテーションは信頼できる参考マテリアルを提供します。3Dシーンは、これらすべてを表現できる空間フレームを提供します。

インテグレーションパターンとしての MCP

モデルコンテキストプロトコル (MCP) は、ツールとデータを一貫した方法で言語モデルに公開する方法を定義するオープンスタンダードです。クライアントがサーバーに接続する方法、サーバーがその機能をアドバタイズする方法、およびモデルがそれらを呼び出す方法を指定します。MCPはもともと一般的な開発者ツール向けに設計されていましたが、このパターンは産業インテグレーションにかなりよく反映されます。根本的な問題、つまり基盤となるさまざまなシステムへの一貫したアクセスの提供という根本的な問題も同様です。

ほとんどの工場は、さまざまなベンダーのPLC、MESシステム、文書管理プラットフォーム、およびヒストリアンを組み合わせています。標準レイヤーがなければ、新しいクライアントはそれぞれこれらのシステムに対して個別に統合する必要があります。MCPを使用すると、基盤となる各システムをMCPサーバーに一度ラップするだけで、準拠しているすべてのクライアントが使用できる統一されたインターフェース介して公開できます。

産業用デジタルツインでは、MCPサーバーの3つのカテゴリが特に重要です。

• 既存の信号レイヤー（OPC UA、Beckhoff ADS、MQTT、S7、またはWebSocketベースのストリーミングレイヤー）に支えられて、ライブ信号値、アラーム状態、ドライブ位置、および最近の履歴を公開するマシンステートサーバー。
• 注文、バッチ、KPI、品質記録を公開する MES サーバーです。REST API、メッセージブローカー、またはダイレクトデータベースクエリによってサポートされています。
• 構造化されたデジタル文書セット（操作説明書、回路図、適合宣言、ソフトウェアバージョン、メンテナンス手順）を公開するドキュメントサーバーは、コンポーネントID、障害コード、または自然言語で検索および取得できます。

これら3つのサーバーに接続されたLLMには、グラウンデッドレスポンスの基盤があります。「なぜ3行目が停止の？」などの質問アラームの状態を読み取り、影響を受けるコンポーネントを特定し、マニュアルから関連するトラブルシューティングセクションを検索し、3D HMI で強調表示された影響を受けるコンポーネント結果を表示することで解決できます。出力は、モデルのトレーニングデータではなく、実際のシステムに基づいています。

この電子書籍シリーズのパート1で説明したセクション6のリファレンスアーキテクチャは、このレイヤーに直接引き継がれています。ここで説明されている信号、MES、ドキュメントサービスは MCP サーバーによってラップされ、一貫したインターフェース通じて公開されます。LLMまたはエージェントランタイムは、お客様のデータポリシーに応じて、ローカル、エッジサーバー、またはプライベートクラウドで実行され、これらのサーバーに接続します。結果として得られる回答は、現在の状態、現在の状況、および信頼できるドキュメントに基づいています。

3D HMI はスタックの一番上にあり、オペレーターとAIベースのツールという2つのコンシューマーに役立ちます。AIツールは、これをプレゼンテーションサーフェス（応答に関連するコンポーネントを強調表示）と確認サーフェス（人間によるレビューのために提案されたアクションを表示する）の両方として使用します。HMI は Unity で作成され、ランタイムが使用する CAD インポート、キネマティクス、信号マッピング、コンポーネントメタデータを網羅しています。デスクトップ、タブレット、AR/VR、または産業用 PC 向けの Unity ネイティブビルドとして、または WebGL デプロイメント用の Three.js 上に構築されたブラウザーベースの 3D HMI として提供されます。Unityが作成した同じシーンファイルが、一貫したコンポーネントIDを使用してGLBにエクスポートされ、両方の配信ターゲットに対応します。

Unity のオープン C# 環境は、電子書籍「設計、シミュレーション、デプロイ」で説明されているように、Sentis と ONNX を介したホスティング推論の両方を直接サポートしています。Unity が産業用Digital Twins にとって重要な理由と、外部ランタイムのフロントエンドとしての役割を果たす理由ほとんどのインテグレータープロジェクトでは、エージェントランタイムをHMI から分離する方が簡単なアプローチであり、MCPがインテグレーションの境界となります。

ドキュメンテーションとグラウンディング

規制の方向性とグラウンデッドLLM出力の技術的要件との間には、顕著な重複点があります。

これまで、ドキュメントは成果物としてのコストでした。必要であるために作成され、参照されることは比較的まれでした。規制（EU）2023/1230では、ドキュメントをデジタルで配信することもできますが、その場合は、文書を構造化し、オンラインで作成し、少なくとも10年間、または機械の動作寿命ライフサイクル管理を行う必要があります。産業機械が規制の最低限度で廃止されることはめったにないことを考えると、通常は後者です。この形式のドキュメントは、構造化され、コンポーネントや障害コードで識別可能であること、製造元の権限を持つことなど、言語モデルの基礎マテリアルとして適した特性も備わります。

メーカーが実際に納入したドキュメントに基づくLLMでは、その回答が特定のドキュメントセクションにさかのぼることができるため、不正確な手順や発明された部品番号が生成される可能性は低くなります。これは、監査可能性や、安全関連ソフトウェアについて規制が導入しているロギングおよび意思決定記録義務とのインテグレーションにも関連している可能性があります。

インテグレーターにとって、構造化されたデジタルドキュメントを作成する作業は（いずれにせよ必要となります）、LLMベースのツールの基盤となるアーティファクトも生み出されるというのが実際的な見方です。この2つの取り組みは、別々の予算をめぐって競合するのではなく、重複しています。

開発アクセラレーターとしてのLLM

インテグレーション作業のコスト削減

これまでの議論では、LLMはデジタルツインデータ、つまり現在の状態を読み取り、ドキュメントをクエリし、オペレーターに応答するツールとして扱われてきました。インテグレーターの経済にさらに直接的な影響を与える2つ目の役割があります。ツイン自体の開発におけるアクセラレーターとしてのLLM。

統合デジタルツインの構築には、技術的には簡単ですが、かなりの作業量が必要ですが、時間がかかります。信号レイヤーと 3D シーンの間のアダプターコード。MES 用の REST クライアントまたは OPC UA クライアント。PLC 変数とコンポーネント ID 間のマッピングテーブル。HMI のプロジェクト固有のチャート、ダッシュボード、および小さな UI コンポーネント。ドキュメントセクションをシーン内のコンポーネントに合わせるためのスキーマワーク。これらのタスクはどれも特に難しいものではありません。手動で、反復的で、プロジェクト固有のものです。

LLM 支援のコーディングツールを使えば、新しい MES API 用のアダプターの生成、チャートコンポーネントのスキャフォールディング、信号テーブルとキネマティック階層間のマッピングの作成など、この種の作業に必要な労力を軽減できます。その効果は、インテグレーターがコードを書くの停止ということではなく、日常的なインテグレーション作業にかかる時間が短くなることです。これまで、インテグレーションプロジェクトが高額になる主な理由の 1 つは、小規模でプロジェクト固有のグルーコードロングテールが原因であったため、これは産業環境では重要です。

標準化されたインターフェースが重要な理由

この効果は、基礎となるインターフェースが標準化されるとさらに悪化します。マシンの状態、MESデータ、およびドキュメントを公開するMCPサーバーは、アドホックな特注APIよりもLLM支援開発のターゲットになりやすいです。標準化されたインターフェースとLLM支援開発の組み合わせにより、統合デジタルツインを構築するためのしきい値が低くなります。

LLM 生成コード限界

注意すべき制限が 2 つあります。LLMで生成されたコードはドラフトであり、成果物ではありません。安全関連コードや制御システムコードには、他のコードと同じレビューおよび検証プロセスが適用されます。また、アクセラレーションは主にインテグレーションと可視化作業に適用され、基盤となる制御ロジックには適用されません。制御ロジックは、既存のツールを使用する自動化エンジニアの責任です。

オーサリングとランタイム配信の分離

このコンテキストで役立つアーキテクチャパターンは、オーサリング環境配信されたアーティファクトから分離することです。オーサリング環境はUnity です。Unityは産業用デジタルツイン向けの確立されたプラットフォームで、機械メーカーがCADをインポートしたり、運動学を定義したり、動作モデルを設定したり、ドキュメントをコンポーネントにリンクしたりするエディターとして使用されています。Unity は、産業プロジェクトに必要な高度なツール、CAD インポートパイプライン、運動学と物理学のサポート、マルチプラットフォームビルドターゲットを提供します。ただし、提供されたアーティファクトは、マシンの生存期間中お客様の環境で実行され、オープンでセルフホストできるという利点があります。つまり、標準のシーン形式（GLB）を使用する標準のウェブテクノロジー（Three.js、TypeScript）上に構築されたブラウザーベースのビューアーです。Realvirtual.io ウェブビューアーは、UnityベースのオーサリングスタックにAGPL ライセンスのソースウェブランタイムをフィードし、現在運用されているこのパターンの一例です。

インダストリー4.0への幅広い影響

まとめると、これらの影響はインダストリー4.0に幅広い影響を及ぼします。インテグレーションプロジェクトにおける一般的な障害物は、異種システムをつなぎ合わせるコストでした。そのコストが下がるにつれて、デジタルツインはインテグレーションプラットフォームとしてより魅力的になります。単なる可視化製品ではなく、シグナル、企業データ、ドキュメント、可視化が集まるレイヤーです。システムインテグレーターにとって、これはデジタルツインのより永続的な役割です。成果物そのものではなく、他のすべてが出会う場所が多いということです。

製造現場のエージェント — スペクトラム

「エージェント」という用語は、リスクプロファイルがまったく異なるさまざまな行動を対象としています。どちらが意味するのかを具体的に説明しておくと便利です。

• 最も制約があるのは読み取り専用の診断ツールです。彼らは状態を観察し、ドキュメントを読み、質問に答えます。制御システムには書き込みません。オペレーターがなぜ回線が止まったのかと尋ねると、システムはアラーム状態を読み取り、マニュアルのコード調べて説明します。これは妥当な出発点であり、多くのユースケースでは妥当な終点でもあります。
• 真ん中にはアドバイザリーツールがあります。状態を観察し、セットポイントの変更、メンテナンススタスク、パラメーター調整などのアクションを提案しますが、実行はしません。オペレーターは各提案を確認または拒否します。3D HMI は確認画面として機能し、書き込みが発生する前に、影響を受けたコンポーネントと提案されている変更を空間コンテキストに表示できます。このパターンでは、診断に AI アシストを使用しながら、意思決定ループにおける人間の判断力を維持できます。
• 最も制約の少ないのは、アクションごとの人間の承認なしに、PLCへの書き込み、レシピの変更、または注文の発送を行うアクション実行システムです。これは状況によっては技術的に実現可能ですが、新しい機械規制では追加の考慮事項が導入されます。サイバーセキュリティは現在、附属書IIIに基づく重要な健康と安全の要件であり、 AIベースの安全機能は明らかに規制の高リスク機械リスト対象であり、より厳格な適合性評価が必要です。LLM 駆動のシステムが制御システムに書き込むことを可能にするパスは、いずれも潜在的な攻撃パスです。このようなシステムは、一般に、安全関連ソフトウェアに対して規制で導入されているロギングとデータ記録の義務を含め、書き込み権限を持つ他の制御システムコンポーネントと同様に注意して設計する必要があります。

初期のプロジェクトでよく見られるのは、デフォルト読み取り専用にし、オペレーターの明示的な確認を伴うアドバイザリーに拡張し、アクションを取る機能はすべてPLCコードと同じレビューと検証の対象となる制御システムコンポーネントとして扱うというものです。

インテグレーターにとっての実用的な出発点

どこから始めればよいかを検討しているインテグレーターにとって、野心的なアプローチよりも漸進的なアプローチの方が効果的である傾向があります。

実践的な最初の実装としては、次のようなものが考えられます。

• 既存のマシンプロジェクトを使用する:まず、規制（EU）2023/1230に基づいて作成中の3D HMI と構造化ドキュメントパッケージが既に搭載されているマシンから始めます。
• MCP サーバーを介したドキュメント公開:コンポーネントIDによる検索をサポートする単一のMCPサーバーにドキュメントセットをラップします。
• 3D HMI とドキュメントサービスの接続:コンポーネントを選択すると関連するマニュアルセクションが自動的に取得されるように、既存の3D HMI を設定します。
• グラウンデッド AI インターフェース追加:ドキュメント MCPサーバーに対応した汎用LLMを使用して、3Dビュー横にチャットパネルを導入します。

期待される成果

結果、オペレーターが質問をしたり、製造元のドキュメントを引用した回答を受け取ったり、関連するコンポーネントを3Dビューで強調表示したりできるマシンができあがりました。制御状態も、自律的なアクションも、新しい自動化インフラストラクチャもありません。サポートへの問い合わせの減少、初回修正率の向上、メーカー知識へのアクセスの容易化といったメリットは目に見えますが、リスクは限定的です。

このようなシステムが実際にどのように見えるかを知りたいインテグレーター向けに、ライブ信号データ消費するブラウザーベースの3D HMI の公開デモンストレーションがweb.realvirtual.io/demoにあります。基盤となるアーキテクチャ、つまりオーサリング環境としてのUnity、配信用のオープンウェブスタック、配信されたパッケージを規制対象の 10 年間にわたって保存するための Gitea などの標準バージョン管理システムは、インテグレーターが採用して独自のプロジェクトに適応できるパターンです。

この開始点から、さらにステップを段階的に追加できます。シグナルレイヤー MCPサーバーでは、ライブステートに関する質問が可能です。MES接続により、現在の注文に関する質問が可能になります。3D HMI でのオペレーター確認を伴う勧告は、基本的なリスクプロファイルを変えることなくシステムをさらに拡張します。各ステップはそれ自体でテスト可能で、元に戻すことができます。

コンプライアンスとAIの両方をサポートするアーキテクチャ

前回の電子書籍では、デジタルツインは技術的な投資であると同時に組織的な投資でもあるという見解で締めくくられました。例えば、バーチャルコミッショニングは、周囲のプロセスが変化しても構わないと思って初めて価値をもたらすというものでした。ここでも同様の観察結果が当てはまります。

現在、インテグレーターに関する2つのタイムラインが収束しつつあります。機械規制は2023年以来知られていますが、2027年1月20日のアプリケーション日に向けて準備を進めるための実際的な作業（必須となる新しいサイバーセキュリティ規定、およびライフサイクルメンテナンス含む構造化されたデジタルドキュメント化という現在では明確なオプション）は、計画から実行に移っています。それと並行して、AI ツールは構造化された根拠のあるデータへの需要を生み出しています。これらは個別のプロジェクトとして扱うこともできますが、基礎となる作業はかなり重複しています。第 1 回で説明した 4 レイヤーアーキテクチャは、オペレーターと後で追加されるあらゆる AI ツールの両方をサポートします。規制遵守のために作成された構造化されたデジタルドキュメントは、基礎マテリアルとしても役立ちます。3D HMI は、これらすべてを統合したサーフェスとして機能します。

1 部で説明した運用上のメリット（診断の迅速化、専門知識の基準の低下、状況に応じた情報提供、有意義なリモートサポート）は、規制の状況に関係なく適用されます。EU外のインテグレーターや、機械規制の対象とならないシステムを開発しているインテグレーターは、同じアーキテクチャから同じ運用上の利点を得ることができ、強制的な機能としての規制期限はありません。このアーキテクチャは運用上の理由のみに基づいており、規制はヨーロッパ市場におけるタイミングを明確にしているだけです。

自律運転は最初の成果としては適切ではありません。より現実的な出発点は、オペレーターがクエリることができ、インテグレーターサポートでき、メーカーが規制対象の10年間にわたって最新の状態に保つことができるマシンです。このような機械ビルドするのに必要なツールや標準はすでに入手可能であり、基盤のほとんどはインテグレーターが行う必要のある作業です。