画像AIをレガシーな機械につなぐとき、モデルより先にプロセスを分ける理由
木村 優志
画像AIのモデルが高い精度で動いても、それだけでは現場の機械で使えるシステムにはなりません。
実際の装置では、カメラから画像を取得し、GPUで推論し、結果を判定し、CANやシリアル通信で既存の機械へ渡します。カメラ、AI、通信、制御は、それぞれ異なる速度と失敗の仕方をします。
このとき、すべてを一つのアプリケーションやプロセスにまとめると、画像AIの問題が機械側の通信まで止める原因になります。
画像AIをレガシーな機械につなぐときに大切なのは、モデルを選ぶことだけではありません。何を、どのプロセスに分け、どの情報だけを渡すかを先に設計することです。
画像AIと機械制御は、求められる性質が違う
画像AIの推論には、処理時間のばらつきがあります。
入力画像によってGPUの処理時間が変わることがあります。モデルの更新時には再起動も必要です。カメラが一時的に切断されることもあります。メモリ不足やドライバの問題で、推論プロセスだけを再起動したい場面もあります。
一方、CANやシリアル通信でつながる機械側では、一定の周期で状態を送る、決められた時間内に応答する、通信が途切れたときに安全な状態へ戻る、といった振る舞いが求められます。
画像AIと機械制御を同じプロセスへ入れると、次のような問題が起きます。
- 推論が遅れ、通信処理の周期まで遅れる
- カメラ入力が詰まり、機械への送受信が止まる
- モデルやGPUの障害で、通信プロセスまで巻き込んで再起動される
- 通信エラー、AIの誤判定、画面表示のどこに原因があるか追いにくい
AI側に起きる一時的な問題を、既存機械の制御や監視まで広げないことが重要です。
まず分けるべき五つの役割
システムの規模によって実装は変わりますが、少なくとも次の役割は分けて考えると整理しやすくなります。
カメラ取得
→ AI推論
→ 判定・業務ロジック
→ CAN／シリアル通信
→ 監視・ログ1. カメラ取得
カメラから画像を取り込み、撮影時刻、カメラID、フレーム番号とともに渡します。
ここでは、推論が遅いからといって画像取得が止まらないようにします。全フレームを必ず処理するのか、最新フレームを優先して古いフレームを捨てるのかも、この段階で決めます。
2. AI推論
画像を受け取り、検出結果、分類結果、信頼度などを返します。
モデルの入れ替え、GPUの再初期化、推論プロセスの再起動は、できるだけこの役割の中に閉じます。推論側が止まっても、通信プロセスや機械側の安全処理まで一緒に止めない構成にします。
3. 判定・業務ロジック
AIの出力を、そのまま機械へ渡すとは限りません。
たとえば「異常らしい」という検出結果を、何フレーム連続で検出したら通知するのか。信頼度が低いときは保留するのか。装置の現在状態で、その判定を受け取ってよいのか。こうしたルールは、モデルとは別に扱います。
モデルを更新しても、現場の業務ルールまで意図せず変わらないようにするためです。
4. CAN／シリアル通信
既存の機械やPLCとの通信を担当します。
CANならメッセージID、送信周期、タイムアウト、受信できなかったときの状態を管理します。RS-232CやRS-485などのシリアル通信なら、フレームの区切り、チェックサム、再送、接続断への対応を管理します。
このプロセスは、AIの内部表現を知る必要がありません。「検査結果」「時刻」「装置ID」「有効期限」のように、機械側との契約として決めた情報だけを受け取ります。
5. 監視・ログ
各プロセスが動いているか、最後に正常なデータを受け取ったのはいつか、通信エラーや推論エラーが起きていないかを集めます。
AIの精度低下と、カメラ切断や通信断は別の問題です。あとから原因を追えるよう、画像取得、推論、判定、送受信の時刻と結果を分けて記録します。
プロデューサー・コンシューマーパターンと相性がよい
このような構成では、プロデューサー・コンシューマーパターンが有効です。
カメラ取得プロセスは画像を作るプロデューサーです。AI推論プロセスは画像を受け取って判定結果を作る、次のプロデューサーでもあります。CAN／シリアル通信プロセスは、判定結果を受け取り、既存機械へ送るコンシューマーになります。
それぞれの間にキューやメッセージングの境界を置くことで、処理速度の違いを直接ぶつけずに済みます。
カメラ → [画像キュー] → 推論 → [判定キュー] → 通信ゲートウェイ → 機械たとえば、カメラは毎秒30フレームで画像を取得していても、推論が毎フレーム処理する必要がない場合があります。検査対象の通過に合わせて最新フレームだけを使うなら、推論待ちの古い画像を捨てる設計にできます。
反対に、すべての画像を記録・検査する必要があるなら、キューの上限、滞留したときの扱い、処理遅延の監視を先に決めなければなりません。キューを無制限に増やすと、メモリを消費するだけでなく、古い画像に対する判定が遅れて届く原因になります。
プロデューサー・コンシューマーパターンの価値は、単に並列処理することではありません。画像を捨ててもよい条件、待たせてよい時間、処理が止まったときにどこまで影響を閉じ込めるかを、役割ごとに決められることです。
プロセス間で渡すのは、画像ではなく判定に必要な情報
プロセスを分けるとき、AI推論プロセスから機械側へ生画像を渡す必要は通常ありません。
たとえば、機械側へ渡すメッセージは次のように絞れます。
装置ID: camera-02
撮影時刻: 2026-09-18T20:15:32.418+09:00
フレーム番号: 184029
判定: NG
信頼度: 0.97
判定の有効期限: 500msここで重要なのは、結果に時刻と有効期限を付けることです。
推論が遅れた結果を、そのまま機械へ送ると、すでに対象物が通り過ぎた後かもしれません。通信は正常でも、古い判定を使えば誤動作につながります。
機械側と通信するプロセスでは、「一定時間を過ぎた判定は送らない」「最新のフレーム番号より古い結果は捨てる」といったルールを持たせます。
AIの判定を、直接制御にしない
安全性や設備への影響が大きい機械では、AIの出力をそのまま制御信号にすることには注意が必要です。
AIが出すのは、検出結果や異常の候補です。それを受けて何をするかは、既存の安全回路、PLC、インターロック、運転状態の確認と組み合わせて決めます。
たとえば、画像AIが異常を検出した場合でも、通信プロセスは次のような条件を確認できます。
- 判定が有効期限内か
- 装置が検査を受け付ける状態か
- 同じ異常を連続して検出しているか
- 停止や排出を行うための既存安全条件を満たしているか
AIは、現場の判断を補助する重要な入力になります。しかし、AIの障害や誤判定だけで安全設計が崩れないよう、制御の責任を分けておく必要があります。
分離すると、更新と障害対応がしやすくなる
プロセスを分ける利点は、性能だけではありません。
推論モデルを更新しても、CANやシリアル通信の実装を変えずに済みます。カメラを入れ替えても、判定結果のインターフェースを守れば機械側への影響を抑えられます。推論プロセスが停止しても、通信プロセスは機械へ「現在はAIの判定を送れない」という状態を明示できます。
現場でAIを使い続けるなら、モデルはいつか更新されます。カメラやGPUも交換されます。既存機械は、より長く使われるかもしれません。
変わる部分と、簡単には変えられない部分の境界を設けることが、長く運用できるシステムにつながります。
画像AIを機械へつなぐのは、モデル統合ではなくシステム統合
画像AIの導入では、モデルの精度や推論速度に目が向きます。それらはもちろん重要です。
ただし、既存の機械とつなぐ仕事では、AIを正しく動かすことと同じくらい、AIが止まったときに機械をどう動かし続けるかが重要になります。
カメラ取得、推論、判定、通信、監視を分ける。プロセス間のデータに時刻と有効期限を持たせる。AIの判定と安全制御の責任を分ける。
こうした設計によって、画像AIは単体のデモから、レガシーな機械と共存できる現場の仕組みになります。
