2026.08.22 業務システム

PLCのデータ収集｜四方式の選び分けとタグ設計・欠測対策を実装目線で解説

PLCからデータを取ると決めた瞬間に、選択肢は四つへ絞られます。メーカー独自プロトコルで直接読むか、OPC UAサーバを挟むか、接点とパルスを外から数えるか、ゲートウェイ製品に変換を任せるか。どれを選ぶかは技術の好みではなく、設備にEthernetポートと上位通信の口があるか、タグが何点あるか、誰が10年保守するかで機械的に決まる。現場で詰まるのはむしろその後で、周期を短くしたのに値が増えない、通信が数分切れただけで日報が合わない、時刻がずれて工程の前後関係が逆転する、という形で表面化します。上位へ届けるまでの経路を、方式比較から周期とタグ設計、欠測対策、受け渡し粒度まで順に整理しました。

まとめ：PLCデータ収集の方式選定と設計で先に決めるべき三つの軸

先に結論を置きます。方式は設備側の口で決まる。Ethernetポートと上位通信機能を持つPLCなら、独自プロトコルの直読みが費用と工数の両面で最も軽い選択です。複数メーカーが混在しタグ名で保守したい規模になったら、OPC UAサーバを挟む構成へ移ります。通信機能のない設備は接点とパルスを外から数える以外に道がなく、取れる情報も生産数と稼働停止とアラームの三つに限られる前提で計画してください。

設計側で先に決める軸は三つ。第一に収集周期で、PLCのスキャンタイムより短くしても情報量は増えません。第二にタグの分類で、積算値と瞬時値と状態値では欠測時の復旧方法が違う。第三にタイムスタンプの打刻位置で、ここを決めずに集めたデータは後から工程の前後関係を追えません。装置としてのPLCの動き方はPLCとは？シーケンサの仕組みとスキャン方式・PLC制御の基本を実装目線で解説で押さえたうえで、収集経路の設計に入る順序が手戻りを減らします。

PLCから稼働データを取り出す四つの方式と現場構成での選び分け

四方式は排他ではなく、1つの工場で併用されるのが普通。ラインごとに設備の年代が違うためです。

三菱のSLMPなどメーカー独自プロトコルで直接読む方式と確認手順

PLCのEthernetポートへ収集側から接続し、デバイス番号を指定してレジスタの値を読む方式。三菱電機のPLCならMCプロトコル、あるいはCC-Link協会が策定したSLMPを使います。SLMPはMCプロトコルのQnA互換3Eフレームおよび4Eフレームと同じフォーマットをTCPまたはUDP上で用いる仕様で、認定は同協会のコンフォーマンス試験による。オムロンならFINS、キーエンスなら上位リンク通信と、メーカーごとに名前と電文が変わる構図は同じです。

導入前の確認は四項目。Ethernetポートが内蔵か増設ユニットが要るか、同時接続できるコネクション数の上限、読み出せるデバイス種別と1電文あたりの点数、そして収集用にどの領域を使ってよいかという現場との合意です。最後が抜けやすく、制御で使う領域を勝手に読みに行くと、保全担当が改造したときに収集側が静かに壊れる。収集専用の領域をPLC側で確保し、制御プログラムから値を転記してもらう構成にしておくと、以後の改造に強くなります。汎用プロトコルで揃えるならModbus TCPが選択肢で、電文仕様とレジスタの数え方はModbusとは？RTUとTCPの違い・レジスタとファンクションコードを実装目線で解説に整理しました。

OPC UAサーバを挟んで型付きのタグとして読む方式の構成と条件

デバイス番号ではなく、意味のある名前と型を持つノードとして値を扱う方式。PLC本体がサーバ機能を持つ場合と、隣にゲートウェイやソフトPLCを置いてサーバを立てる場合があります。OPC UAはIEC 62541シリーズとして標準化され、PubSub通信を規定するPart 14は第2版が EN IEC 62541-14:2026 として発行済みです。

効くのは、設備メーカーが複数に分かれ、上位アプリ側で機種差を吸収したくない構成です。読み出す側はタグ名だけ知っていればよく、PLCを更新してデバイス番号が動いても上位を直さずに済む。代わりに払うのはサーバ側のライセンス費用と、名前設計およびセキュリティ設定の工数です。産業用PC上でサーバを立てる構成の前提はソフトウェアPLCとは？ソフトPLCの仕組みとリアルタイム性・ハードPLCとの使い分けを参照してください。

接点とパルスをIOユニットで数える通信機能のない設備への後付け

通信機能を持たない設備、メーカーのサポートが終わって設定を触れない設備が対象。運転中を示すランプの端子、完成品が1個出るたびに1パルス出る信号、異常を示す接点。これらを外付けのIOユニットで拾い、収集側で数えます。

取れる情報は少なく、生産数と稼働停止とアラームの有無が中心。ただし設備稼働率を出すだけならこの三つで足ります。制約は工事で、端子台への配線には設備の停止が要り、電気工事の資格とメーカーの改造許諾も絡む。改造を避けたいなら電流センサーを電源線にクランプする方法もあり、非接触のため停止時間を短く抑えられます。後付けセンサー側の構成は予知保全のIoT構成における物理量の選び分けで扱っています。

ゲートウェイ製品に変換を任せる方式と自社実装との分界点の引き方

各社プロトコルの解釈を製品に任せ、こちら側は上位のインターフェースだけを受け取る方式。データコレクタやIoTゲートウェイと呼ばれる製品群がこれにあたります。分界点の目安は単純で、対象メーカーが三社を超えるなら製品、二社以内で機種も固定なら自社実装。三社を超えると電文仕様の読み込みと試験の工数が製品費用を上回るためです。

方式	適する構成	主な工数	取れる粒度
独自プロトコル直読み	単一メーカーで機種固定	電文実装と割付表の突合	デバイス単位で任意
OPC UAサーバ経由	複数メーカーの混在	ノード設計と証明書設定	型付きタグ単位
接点とパルス	通信機能のない設備	配線工事と設備停止調整	数量と稼働停止のみ
ゲートウェイ製品	三社以上が混在する構成	製品設定と保守契約	製品の対応範囲まで

収集周期とタグ設計をPLCのスキャンタイムから逆算して決める手順

ここを飛ばすと、集めた量のわりに使えるデータが残りません。

スキャンタイムより短い周期で読んでも値が増えない理由と周期の目安

PLCは入力の取り込み、演算、出力の書き出しを繰り返しています。1周に要する時間がスキャンタイムで、内部のデバイス値はこの周期でしか更新されない。スキャンタイムが50ミリ秒の設備を20ミリ秒周期で読みに行っても、同じ値を続けて受け取るだけです。通信量と収集側の負荷が増え、情報は1ビットも増えません。

周期は上限と下限から挟み込みます。下限はスキャンタイムで、これより短くしても意味がない。上限は見たい現象の持続時間の半分で、2秒で終わる短時間停止を検出したいなら1秒以下が要ります。実務の落としどころは、稼働監視や生産数の集計が1秒から10秒、品質分析用の温度や圧力の波形が100ミリ秒前後、振動のような高速現象は専用のデータロガーへ分離。迷ったら1秒から始め、要求が出た系統だけ短くするほうが後戻りの費用は小さくなります。

周期が決まったら通信量を掛け算で確認します。タグ数×1タグあたりのバイト数×1秒あたりの読み出し回数が下限で、500タグを4バイトで毎秒1回読むならデータ部だけで毎秒2,000バイト、ヘッダと応答を加えた実効はその2倍から3倍。総量を削るなら、収集対象を連続番地へまとめて1電文で読むか、周期を階層化する。SCADA製品を挟む場合の帯域設計はSCADAとは？スキャダの仕組みとPLC・DCS・MESとの役割分担を実装目線で解説にも整理があります。

収集タグの棚卸しと積算値・瞬時値・状態値という三つの分類の付け方

タグ表に名前と型だけ書いて終わりにしないでください。三分類を1列足すと、後工程の設計が決まります。

積算値は生産数のように増え続ける値。欠測しても差分で復元できる反面、カウンタが上限で0へ戻る挙動を知らないと日報にマイナスが出ます。上位では常に差分へ変換するのが安全策。瞬時値は温度や電流のようにその時点を表す値で、平均を取ると異常が消えるため最大値と最小値を併せて持たせます。状態値は運転と停止、アラーム番号のように変化点だけが意味を持つ値。一定周期のサンプリングだけで拾うと、隙間で起きた短い停止が丸ごと消えます。状態値は変化検知で拾い、周期サンプリングと併用する構成が落としどころです。

変化検知で送る構成ではデッドバンドの設定が要ります。幅を広く取りすぎると閾値をまたいだ瞬間の値が届かず、警報が出た理由を後から追えない。離散値である状態値には掛けず、瞬時値は計測器の分解能と同程度、積算値は周期読み出しへ寄せる割り当てが扱いやすい形です。値が動かなくても一定間隔で1回送る設定を入れておくと、欠測判定を兼ねられます。送信側の仕組みはMQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装からHTTPとの使い分けまで実装者向けに解説を参照してください。

タイムスタンプを打つ場所で変わる分析側の解釈と時刻同期の要否判断

時刻を打てる場所は三つ。PLCの内部時計、収集側のゲートウェイ、クラウドの受け口です。ポーリングで読む構成では、収集側が時刻を打つと最大で1周期分の遅れが乗り、複数のPLCを順に回るなら台数分の差も加わる。単一設備の稼働率なら誤差は無視できますが、前後工程を突き合わせて滞留時間を出すなら、この差がそのまま分析結果の誤りになります。

基準は、工程をまたいだ前後関係を見るかどうか。見るならPLC側またはゲートウェイ側で時刻同期を入れ、打刻位置を全設備で揃えます。見ないなら受け口側の時刻で足りる。PLC内部時計は同期の仕組みを入れない限り月に数秒から数十秒ずれる前提で扱ってください。日報の締め時刻がずれる原因の多くは、ここにあります。

通信断でも欠測しないエッジ側の蓄積と上位への受け渡し構成の作り方

工場の回線は落ちます。停電、機器の再起動、上位側の保守。落ちる前提で設計してあるかどうかが、日報の信頼性を分けます。

通信断でも取りこぼさないための現場側バッファの持ち方と容量の決め方

現場側でいったんファイルまたは組み込みデータベースへ書き、上位への送信が成功したら消す。こうしておけば回線が切れている間も収集は続き、復旧後にまとめて送られます。容量はタグ数×1秒あたりのレコード数×1レコードのバイト数×耐えたい断絶時間で計算。500タグを毎秒1回、1レコード20バイトで24時間耐えるならおよそ864メガバイトで、圧縮が効いて実際は数分の一に収まるものの、記憶媒体はこの生の値で見積もっておくと安全です。

あわせて決めるのが、バッファが溢れたときの振る舞い。稼働率の日報が目的なら古いデータを残す価値が高く、警報の即時通知が目的なら新しいデータを優先する。この判断を製品の既定値へ任せたまま運用に入ると、断絶が長引いたときに欲しかったほうが消えます。

再送で順序が入れ替わる前提に立った時系列データベースへの書き込み

復旧後の再送では、ためていた過去データと現在の値が入り混じって届きます。受け口が到着順に追記する作りだと時系列が前後した行が並び、後段の集計が壊れる。避け方は書き込みを冪等にすること。設備の識別子とタグ名と計測時刻の組を一意キーとして扱い、同じ組が来たら上書きする設計にしておけば、二重送信でも順序の入れ替わりでも結果は変わりません。

時系列データベースの多くはこの考え方を前提に作られており、キー設計と保持期間の設定が要点になります。書き込み設計の詳細はInfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説にまとめました。送信側の到達保証も要り、MQTTで少なくとも1回届く設定では重複が起こり得るため、受け口側の冪等性とセットで初めて成立する。産業用の名前空間まで揃えるならEclipse Sparkplugが選択肢で、2022年10月21日に投票が完了した3.0.0が現行版です。

MESや生産管理システムへ渡すデータの粒度と受け渡し周期の決め方

集めたデータを全部そのまま上へ流す設計は破綻します。受け手ごとに要る粒度が違うためです。

生データのまま渡す範囲と現場側で丸めてから渡す範囲の線引きの基準

基準は、受け手がその値で何を判断するか。MESや生産管理システムが要るのは実績で、着手と完了の時刻、良品数、不良数、停止時間です。秒単位の温度推移は要りません。一方、品質の原因分析や予知保全のモデル学習に使う系統は、丸めた瞬間に情報が失われます。

実務では二経路に分けます。実績系は現場側で集計してから分単位またはロット単位で上位業務システムへ、分析系は生データのままデータ基盤へ。出口を二つ作っておけば、後から分析要件が増えても収集側は作り直さずに済む。上位で実績を受ける側の機能定義はMESシステムとは：製造実行システムの11機能とISA-95レベル3の実装要件、計画側との関係は生産管理システムとは？機能・ERP／MESとの違いから種類・選び方と内製化の判断まで解説で確認できます。

設備の稼働率を計算できるデータの持ち方と停止理由の付け方の設計

稼働率を出すには、稼働と停止の区間、そして停止の理由が要ります。前者はPLCから取れますが、後者はほぼ取れない。段取り替えか、材料待ちか、故障か。設備は自分が止まった理由を知りません。

取り方は二つ。アラーム番号が出ている停止は、番号と理由の対応表で自動割り当てします。番号が出ない停止は現場の端末から作業者に選んでもらう形になり、選択肢を10個以上並べると入力されなくなる。実務で回るのは5個前後までです。加えて、計画停止と非計画停止を最初から別扱いにしておくこと。昼休みや段取り替えを非稼働に含めるかどうかで稼働率は大きく動き、後から定義を変えると過去データと比較できなくなります。

現場ネットワークを分離しPLCへ書き込ませない収集構成の作り方

収集の追加は、外とつながっていなかった設備に経路を作る行為でもあります。読むだけの機能でも、経路自体は双方向に使えてしまう点が起点。

収集を読み取り専用に閉じるための機器側の設定と接続経路の作り方

読み取り専用は層ごとに手立てを用意します。PLC側では、収集用のコネクションに書き込みを許可しない設定があるならそれを使い、なければ収集専用のデバイス領域だけを公開範囲にする。OPC UAサーバを挟む場合は収集用アカウントの権限を読み取りだけに絞り、ゲートウェイ製品なら上位から下位への転送機能を無効にしておきます。

あわせて、収集経路と保守経路を分けてください。プログラムの書き換えに使う経路とデータを読む経路が同じだと、収集用に開けた口が保守用の口を兼ねます。現地でラダーを改造する運用がある現場ほど、この分離は後から効く。記法と改造の実務はラダー図の読み方と書き方｜PLCの接点・コイル・自己保持と保守しやすい回路設計に整理しています。

制御系と情報系の境界に置く機器の選び方と通信方向を決める基準

境界には中継点を1つ置き、制御系と情報系のネットワークを直接つながせない構成が基本形。中継点はゲートウェイでもサーバでも構いませんが、条件は二つ。制御系側の機器から見てその1台以外とは通信しない状態にできること、そして情報系側から制御系側へ向かう接続を開始できないことです。

通信方向は、現場側から上位側へ送り出す向きに揃えるのが安全。上位から読みに行く構成だと情報系から制御系への接続を許す必要が生じ、境界に穴を開けることになります。送信側から接続を張るMQTTが工場で選ばれるのは、通信量の軽さだけでなくこの方向性の理由が大きい。ゾーンとコンジットの分割やセキュリティレベルの考え方は、前述のSCADAの記事に譲ります。

PLCデータ収集を内製する条件と製品調達へ寄せるべき場面の線引き

この設計を誰が引き受けるか。判断を条件で言い切ります。

内製で回せるチームの条件と、製品の調達へ寄せるべき場面の線引き

内製で回せるのは、次の四つが揃ったときだけです。対象PLCが単一メーカーで機種が固定されていること。デバイス割付表が改造のたびに更新されていること。収集タグが200点程度までに収まること。収集機器とソフトウェアの更新を年次で引き受ける担当が社内にいること。揃えば自前のプログラムでも回ります。

逆に製品調達か外部委託へ寄せるべきなのは、メーカーが三社以上混在する構成、タグが1,000点を超える規模、切り替えを無停止で行う案件、収集の停止が出荷の停止へ直結する運用。どれかに当てはまるなら、内製の試算が安く見えても追いつきません。工数の大半が電文の実装ではなく、現地での実機確認と割付表の突合せ、設備ごとの例外処理へ消えるからです。

工数が積み上がる箇所とEdgecross終了を踏まえた製品選定の注意

見積もりで過小評価されやすいのは四か所。デバイス割付表と実機の突合せ、停止理由コードのマッピング表の作成、設備ごとの例外処理、立ち上げ後に数週間かけて行う値の妥当性確認です。最後は省かれがちですが、実際の生産と突き合わせて数字が合うと確認しない限り、そのデータは使われず放置されます。

製品選定では、供給とサポートの継続年数を要件に入れてください。実例として、FAとITを協調させる日本発のエッジ向けソフトウェア基盤であるEdgecrossは、コンソーシアムが2025年1月31日付のお知らせで活動終了を告知しています。新規会員入会受付は2024年11月末で終了、基本ソフトウェアの新規受注は2025年10月末で停止、購入済みソフトウェアへの有償技術サポートは2026年度に終了し、以降は開発担当の三菱電機が対応するとされる。設備は10年以上動く一方、収集基盤はこの周期で状況が変わります。収集経路を1製品に固定せず、上位への出口を標準仕様で持っておくと乗り換えの費用が下がる。収集から上位連携までを含む設計と開発を外部へ出す場合はAI/IoTソリューションで対応しています。

PLCデータ収集の対応機種・費用・既存設備についてよくある質問

通信機能のない古い設備からもデータは取れますか？

取れます。ただし内容は生産数と稼働停止とアラームの有無が中心。接点信号を外付けIOユニットで拾う方法は計数の精度が高い反面、配線工事のため設備を止める必要があり、メーカーの改造許諾も要ります。電流センサーを電源線にクランプする方法は非接触で停止時間を短くできるものの、判定はしきい値の調整しだい。可視化までが目的なら後者から試す順序が扱いやすい形です。

収集周期は1秒と1分のどちらから始めるとよいですか？

1秒から始めるほうが後戻りは小さくなります。周期を短くする変更には負荷試験と回線の見直しが伴う一方、長くする変更は設定値の書き換えだけで済むためです。ただし対象PLCのスキャンタイムが1秒より長ければそちらに合わせる。短時間停止の検出や品質分析の要求が明確な系統は、100ミリ秒前後を選ぶべき場面です。全タグを同じ周期にせず階層化すると、通信量を抑えたまま分解能を確保できます。

OPC UAとMQTTはどちらを選べばよいですか？

択一ではなく、担当する層が違います。OPC UAはデータの意味と型を決める仕組みで、どのタグが何を表しどんな単位を持つかをサーバ側で定義できる点に価値がある。MQTTは軽量に運ぶ仕組みで、送信側から接続を張るため境界を越えやすい。実務では現場側でOPC UAサーバから型付きのタグとして読み、上位へMQTTで送る構成がよく採られます。単一メーカーで機種が固定されタグ数も少ないなら、独自プロトコルの直読みで足ります。

PLCへの書き込みは収集と同じ経路でやってよいですか？

分けることをおすすめします。収集は読み取り専用に閉じ、書き込みが要る用途は別の経路と別の権限で扱ってください。同じ経路にすると上位システムの不具合が設備の誤動作へ直結しかねず、障害時に責任を切り分けられない。生産指示の書き込みが要る場合は、書き込み専用のデバイス領域を確保し、PLC側で値の範囲と受け入れ条件を検査したうえで反映する構成にします。上位から来た値をそのまま制御に使わせない設計が基本です。

Edgecrossは今から採用してよいですか？

2026年8月時点で、新規採用の選択肢からは外れます。コンソーシアムが2025年1月31日付で活動終了を告知しており、基本ソフトウェアの新規受注は2025年10月末で停止、有償技術サポートも2026年度で終わるためです。導入済みのものを急いで置き換える必要はないものの、新規ラインや後継案件では別の構成を前提に計画してください。