PLC連携の開発会社を選ぶ前に確かめたい5つの改札 ― 「動くコード」と「現場で壊れないコード」は別物です

「PLC 連携もできます」と謳う開発会社は何社も見つかりますが、その一文だけでは、現場で壊れずに動くソフトを作れるかどうかは判断できません。見極められるのは、通信の異常系まで踏み込んだ実装経験と、納品後も現場で壊れない設計判断が、打ち合わせの言葉の端々に具体的に出ているかどうかです。私たちは製造ラインの PLC 連携ソフトを要件整理から exe 納品まで手がけてきた実務の中で、発注前に確認できる観点を5つの改札としてまとめています。

「PLCまで対応できます」と、現場で壊れないことは別の話です

Web 開発や AI 活用を掲げる会社は数多くありますが、その先にある三菱 PLC の MC プロトコルを直接扱い、現場の設備と会話するソフトまで実装できるかどうかは、会社ごとに大きく差があります。私たちは Web/AI 開発の会社でありながら、三菱 PLC(MC プロトコル 3E/ASCII)と直結する製造ライン向けソフトを、要件整理から実装、現場への exe 納品まで手がけています。

実績は3件あります。1つ目は、大手自動車メーカーの製造ライン向けの生産指示・品質履歴システムです(PyQt5 の GUI で PLC と常時接続し、exe で納品後も保守・機能追加を続けています)。2つ目は、同じラインの画像仕様検査装置の PLC↔PC 中継ソフトです(他社が開発した既存資産を引き継ぎ、保守・改善しています)。3つ目は、Excel⇔PLC(ZR)の一括設定書込みソフトです(構築中です)。この3件を裏で支えているのが、実機と同じワイヤ形式でしゃべる、社内で内製した疑似 PLC です。

この3件の実務から見えてきたのが、発注前に確認できる5つの改札です。技術力を測る改札が2つ、現場に届けてからの実務を測る改札が2つ、そして最後に設計思想を測る改札が1つあります。

技術の改札 ― 通信の罠を踏んだ経験と、実機なしで確かめる環境

最初の改札は、通信ライブラリを呼び出したことがあるかではなく、型・桁・再接続といった現場特有の罠を実際に踏んだことがあるか、です。

三菱 PLC の MC プロトコルには、コードを書いただけでは気づきにくい罠がいくつもあります。文字列項目は ASCII、数値項目は符号付き BIN といった型の使い分けを間違えても、例外は出ずに PLC が誤解釈するだけです。桁数がずれれば後続のデータを壊しますし、通信ライブラリは製品ごとに微妙な実装差があるため「前の案件と同じはず」という思い込みも危険です。こうした罠を、見積りの打ち合わせで具体的な言葉として語れるかどうかは、実装経験の深さを測る手がかりになります。

もう一つの改札は、実機の PLC が手元になくても開発・テストできる環境を、その会社が自前で持っているかどうかです。私たちは、実際の通信ライブラリと同一のワイヤ形式で応答する疑似 PLC を社内に持ち、複数の製造ライン向けシステムをこの環境で開発・テストしています(関連記事: PLC実機なしで上位ソフトを開発・テストする)。実機が現場に据え付けられるまで検証の手が止まる会社と、開発の初期段階から異常系まで確かめられる会社とでは、納品までに潰せる不具合の数が違うと私たちは考えています。

実務の改札 ― 納品して終わりにしない体制

ここまでの2つの改札は技術力を測るものでした。ところが、技術力があるだけでは、納品してからの実務まで安心できるとは限りません。

3つ目の改札は、納品形態への対応力です。オフィスで動く Web システムと、工場のライン脇に置かれる制御用 PC で動くソフトでは、求められるものが違います。私たちが手がけている生産指示・品質履歴システムは、PLC と常時接続する PyQt5 の GUI アプリケーションとして exe 納品し、納品後も保守・機能追加を続けています。ソースコードを渡して終わりではなく、現場に据え付けたところから運用が始まる前提で対応できるかどうかが、この改札の見どころです。

4つ目の改札は、既存ソフトの引き継ぎ・保守にどう向き合うかです。私たちが引き継いだ画像仕様検査装置の PLC↔PC 中継ソフトは、もともと他社が開発した既存資産でした。前任者から受け取ったソースコードと、現場で実際に稼働している exe が同じ世代とは限りません。まず両者を突き合わせ、稼働ログを保全してから原因を特定するという、「動いているものを壊さない」進め方を私たちは徹底しています。この地道な手順を語れるかどうかが、引き継ぎ案件での信頼につながります。

設計の改札 ― 止まる勇気を持っているか

最後の改札は、失敗が物理ラインを止める領域だと理解した設計をしているか、です。オフィス向けのシステムなら、多少あいまいな値でも動かしながら直すという判断がありえます。ですが PLC への誤書込みは、製造設備そのものを止めかねません。

私たちが Excel⇔PLC の設定書込みソフトで採用しているのは、番地が確定していない項目や、書き込むデータが割り当てられた領域からはみ出す場合に、動かし続けるのではなく処理を止めて知らせる設計です(関連記事: fail loud 設計の解説記事)。不確かな値のまま処理を進めて後から気づくより、止まって気づく方が安全だという判断です。

この設計判断を打ち合わせの中で語れるかどうかは、見積書の項目だけでは見えてきません。ですが、ラインを止めるかもしれない領域を扱う相手として、地味でも欠かせない確認点です。

まとめ

次の商談でこの5つの改札をそのまま質問してみることが、今日からできる確認方法です。通信の異常系についてどんな具体例を語れるか、実機なしでどこまで検証できるか、納品後の保守体制はどうなっているか、既存資産の引き継ぎでは何を最初に確認するか、そして不確かな値をどう扱う設計にするか。その答え方の速さと具体性の差が、そのまま現場に出た後のトラブル対応の速さの差になります。

出典:

• 私たちが手がける PLC 連携ソフト3製品の実装レビュー記録(社内一次情報)
• 私たちが採用した fail loud 設計・疑似 PLC 内製の設計判断記録(社内一次情報)

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)