AI ShellとGeminiでサーボを操作する
はじめに
本記事は、主にPLC(Programmable Logic Controller)向けのソフトウェア開発に従事、または関心のある方、AI ShellやGeminiの変わった使い方に興味がある方が対象です。OMRON社のSysmac Studioを使用します。また、PowerShellとAI Shell、Google Geminiを使用します。
今回は、サーボ操作インターフェースをOPC UAで公開し、AI Shellを介してGeminiと対話的にそのインターフェースを操作してサーボを動かします。運転操作には使用できませんが、試運転や調整時のイレギュラーで軽微な操作の負担を減らすことができます。単にGeminiと自然言語でやり取りしながら操作するのが面白いというのもありますが、周囲とやり取りしながら作業する際の思考切り替えの負荷やメンテナンスのためのコードを減らすことができます。
以下のように操作します。失敗もしますが、自分のミスを見つける手がかりになることもあります。

AI ShellとGeminiによるサーボ操作
サーボ操作について、サーボ操作インターフェースを使用するPowerShellクライアントのコードを生成させて実行するという形式をとっているため、柔軟性がある反面、不確かさも十分にあります。これについては、サーボ操作機能をMCPサーバとして提供することで、大きく軽減することが見込まれます。
今回は、サーボ操作を対象としましたが、それに限るものではありません。基本的なインターフェース公開ライブラリをコントローラに導入するだけで、センサーパラメータの設定やモニタリングにもAIチャットボットのような一般的な手段を簡潔に適用することがユーザーレベルで可能です。数百のセンサーに数十のパラメータがあり、数千の設定項目があったとしても問題なく設定でき、その変更と検証も容易です。IDE経由でも可能ですが、柔軟性が大きく異なります。
リモートIOがHTTPあるいは、MQTT経由のセンサー設定インターフェースを持っていることも多いですが、使用可能な状態に構成しなければなりません。一方、フィールドバスを介して接続しているコントローラ経由での操作は常に可能です。また、制御状態に対して協調的なパラメータ変更も行いやすくなります。
PLCを使用するような領域では、制御を目的にフィジカルAIとしてロボティクスやプロセス最適化が華やかですが、実際にはそれらを適用可能な状態にする地味なセットアッププロセスが存在します。自動化のための構成や、自動化しきれなかった要素のセットアップであり、人の関与が大きいプロセスです。このようなプロセスにもAIを利用していくことは可能であり、ユーザーが自律的に計画、実装して適用することも可能な状態にあります。
Sysmacプロジェクト
サーボ操作インターフェース(UAMotionLinkLib)のSysmacプロジェクトは、以下にあります。
AI Shellを介したサーボ操作については、以下にあります。実行にはリポジトリ全体が必要です。
環境
AI Shellを介したサーボ操作を試すには、以下の環境が必要です。
- Windows ターミナル
- PowerShell
- AI Shell
- AIチャットボット
- Sysmac Studio
以下の環境で確認をしています。
| Item | Version |
|---|---|
| Windows ターミナル | 1.22.12111.0 |
| PowerShell | 7.5.3 |
| AI Shell | 1.0.0-preview.7 |
| AIチャットボット | Gemini 2.5 Flash |
| Sysmac Studio | Ver. 1.63 |
構築
AI Shellを介したAIチャットボットを使用してのサーボ操作には、以下の状態を構築します。
-
使用するソフトウェアにサーボ操作インターフェースライブラリを組み込みOPC UAサーバで公開する
-
AIチャットボットに操作指示をドメイン固有の用語を含む自然言語で与え、サーボ操作インターフェースを適切にを使用するコードを生成するようにコンテクストを構成する
-
プロンプトで操作指示を与えてコード生成、実行、結果を評価する
1は、SysmacプロジェクトへのUAMotionLinkLibの組み込みとOPC UAサーバの設定なので、リポジトリのSysmacプロジェクトとメーカーのマニュアルを参考に構築できます。
2は、AIチャットボットに装置固有の情報と、サーボ操作インターフェースを適切に使用するのに必要な情報をドキュメントとして参照させます。AIチャットボットがサーボ操作インターフェースを直接に使用することは困難なので、対人用に作成したクライアントライブラリの主要クラスに追加的なコメントを加えたソースコードも参照させます。
3は、2が適切になされていれば曖昧な指示でもそれなりのコードを生成するようになりますが、マズいものを生成することもあるので、対話者の確認が必要な場合もあります。UAMotionLinkLibは、モーションFBのラッパーとして提供するのでSysmac StudioのモーションFBについての知識が必要です。自分が使うことが前提だったので、少しハードルが高いかもしれません。これらは、サーボ操作をAIチャットボットにMCPサーバとして提供し、別途ナレッジを提供する環境を整えることで、改善すると思われます。
実装
実装と呼べるものは、サーボ操作インターフェースライブラリであるUAMotionLinkLibとクライアントライブラリであるSingleMCControllerしかありません。
UAMotionLinkLibは、モーションFBのラッパーをOPC UAサーバで公開しているだけで、コンセプトは"OPC UAで公開したファンクションブロックを疑似UA Methodとして使う"と同じです。SingleMCControllerも"OPC UAでRingBufferを公開する"のクライアントと同様のコンセプトで構築したものです。
いずれも、過去の作成物のコンセプトを模倣して構築したものなので特に新しいことはありませんが、以下を追加しています。
-
疑似UA Method呼び出しの実行完了クリアの確認
同一の疑似UA Methodを間隔を開けずに呼び出すことがあるため、実行完了(Done)クリアの確認を含めています。実行完了クリアを確認して呼び出し処理を終了しないと、コントローラのタスク周期によっては、次の呼び出し時に即座に完了と判断してしまうことがあります。 -
Enable型メソッドの呼び出し
Enable型メソッドは、Enable型FBのラッパーか、Enable型FBとして構築した疑似UA Methodです。Enable型メソッドは、それが実行中である間、処理を継続します。そのため、処理に失敗するか、終了させない限り完了しません。実行フラグを単なるプロパティとして公開してもよかったのですが、処理の失敗という要素があるため、メソッドとしました。クライアントは、Enable型メソッドを継続的な非同期プロセスのようなものとして扱うようにしました。
Sysmac Studioという特殊な環境で、さらに特殊な用途についての事柄なので、自作したい場合を除いて確認する必要はありません。気になる場合は、リポジトリのコードを確認してください。
実行手順
UAMotionLinkLibリポジトリのexamples/ControlWithAIShellをカレントディレクトリとしての手順です。
1. AI Shellのセットアップ
AI ShellのインストールとAIチャットボットを設定します。AIチャットボットは、Google Geminiを使用するので、Google AI StudioでAPIキーを生成してAI Shellの構成ファイルで指定します。以下を参考にしてください。
2. Geminiに提供する資料の準備
Geminiに提供する資料を用意します。AIチャットボットに適したものではなく、適当に準備できる程度がよいと思います。その程度で使用できることに意味があるからです。ディレクトリには、以下のドキュメントがあります。
-
context.md
作業全般について記したドキュメントです。作業前にGeminiに参照させます。 -
machine.md
操作対象とする装置と軸について記したドキュメントです。Geminiにドメイン固有の情報を提供するのに使用します。
3. クライアントライブラリのセットアップ
以下を実行します。
../../SingleMCController/PwshOpcUaClient/setup.ps1
Windows環境以外での使用はないと思いますが、他の環境ではsetup.ps1と同ディレクトリのLoadAssembly.ps1の修正が必要です。
4. .envの用意
クライアントライブラリの設定は環境変数で渡すので、.envを用意します。ディレクトリにある.env.templateを.envに改名します。シミュレータでの実行であれば、内容の変更は不要です。
5. シミュレータの起動
Sysmacプロジェクト(ExampleControlWithAIShell.smc2)をSysmac Studioで開き、シミュレータとシミュレータ用OPC UAサーバを起動します。OPC UAサーバに.envの内容に一致するユーザーとパスワードを登録します。
6. AI Shellを起動
Windowsターミナルを起動し、examples/ControlWithAIShellをカレントディレクトリとしてAI Shellを起動します。
7. Geminiにコンテクストを認識させる
2で用意した資料をGeminiに参照させ、サーボ操作をスムーズに実行できるようにします。また、PowerShellセッションにクライアントライブラリをインポートするといった環境整備も行わせます。
8. サーボ操作の指示
プロンプトでサーボ操作の指示を出します。Geminiに上手くコンテクストができていれば、調子よく使えます。
リスクについて
AI ShellとAIチャットボットによるサーボ操作は、リモートからのアクチュエータ操作なので、通常考慮する以外のリスクがあるのは間違いありません。まして、生成AIが生成したコードを実行して操作するのですから、尚更リスクがあると考えるかもしれません。 しかし、そのリスクは、生成AIの不確かさが直接に反映されるものではありません。 開発者が適切な振る舞い実装することでコントロールできるものです。 操作指令は、物理的な操作盤か否か、ヒトか否かによらず同等に検査する必要があります。 不備があれば拒絶する必要があります。 また、どのような操作を可能にするかは開発者がコントロールする事項です。
AI ShellとAIチャットボットからのサーボ操作は、サーボ操作インターフェースであるUAMotionLinkLibの実装によってリスク程度を調整することが可能です。もし、現行のUAMotionLinkLibのサーボ操作インターフェースの有するリスクが許容できないものであれば、許容できる水準に改修すればよいことになります。あるいは、よりリスクを許容して既存のインターフェースを参考にサーボレディや継続動作を可能とする機能を追加することもできます。 全ては開発者次第です。
まとめ
ツールが揃いつつあるので、AIチャットボットを使ってみました。それほど準備をしなくても仕事をしてくれるのはよかったのですが、想像以上によく仕事をしてくれたので本格的なツール整備の必要性に悩まされています。コントローラのソフトウェアに仕込むライブラリとそれに対応したMCPサーバを整えることで、ユーザーが自身の要求に合わせて使用できる環境を構築できるのではないかと考えています。
OPC UAというチャネルにこだわる必要はないので、MQTTでも懐かしのプロトコルでもAIチャットボットやエージェントを関与させることは可能ですが、コントローラのソフトウェアでリスク程度を調整する必要があります。命令の発生源の信頼性によらず、最終的にどう振る舞うかは、コントローラのソフトウェアが決定するようにするのがよいです。命令の失敗は、AIチャットボットやエージェントにとって負の要素ではありません。AIチャットボットやエージェントは失敗に寛容であり、適切な失敗理由を提示すれば好ましい対応をしてくれます。
Discussion