現場からクラウドまで
─産業用プロトコルとIoTプロトコルの役割
・PLCとIoTゲートウェイの間で使われる「産業用プロトコル」の種類と特徴
・IoTゲートウェイとクラウドの間で使われる「IoTプロトコル」の種類と特徴
・2つの区間のプロトコルがなぜ違うのか——設計思想の違い
・プロトコル選定で最初に確認すべきこと
前回（#3）では、PLCからIoTゲートウェイを経由してクラウドにデータを届ける構成を解説しました。その中で、Modbus、SLMP、FINS、MQTT、HTTPSといったプロトコル名が登場しました。
これらのプロトコル名を見ると、「種類が多くてよくわからない」と感じるかもしれません。しかし、すべてを覚える必要はありません。重要なのは、通信経路を大きく2つの区間に分けて考えることです。
▼ 今回扱う代表的な構成
産業用プロトコル
IoTプロトコル
PLC ↔ IoTゲートウェイ間は「産業用プロトコル」、IoTゲートウェイ ↔ クラウド間は「IoTプロトコル」です。この2つの区間では、まったく異なる設計思想のプロトコルが使われています。本記事では、それぞれの区間を分けて整理します。
1. PLC ↔ IoTゲートウェイ間：産業用プロトコル
PLCからデータを読み取るとき、IoTゲートウェイはPLCが対応している通信プロトコルで接続する必要があります。PLCのメーカーや機種によって対応プロトコルが異なるため、「どのPLCが現場にあるか」がプロトコル選択の出発点になります。
主な産業用プロトコル
| プロトコル | 概要 | 対応するPLCメーカー（代表例） |
|---|---|---|
| Modbus（TCP/RTU） | 元はModicon社が1979年に策定。現在はModbus Organizationが仕様を管理するオープンプロトコル。シンプルで多くの機器が対応 | メーカー問わず幅広く対応 |
| SLMP（MC Protocol） | 三菱電機が策定・管理するメーカー固有プロトコル（仕様書は公開）。Ethernet経由でデバイスメモリを直接読み書きできる | 三菱電機（MELSEC iQ-R、iQ-Fなど） |
| FINS | オムロンが策定・管理するメーカー固有プロトコル。Ethernet・シリアル通信の両方に対応 | オムロン（NJ/NXシリーズ、CJシリーズなど） |
| EtherNet/IP | ODVAが策定・管理する産業用Ethernet規格。CIP（Common Industrial Protocol）をベースとしたオープン規格 | ロックウェル・オートメーション、オムロンなど |
| OPC UA | OPC Foundationが策定・管理するメーカー非依存の国際標準（IEC 62541として国際規格化済み）。セキュリティ（暗号化・認証）を標準搭載 | 対応機種が増加中（三菱電機、オムロン、シーメンスなど） |
※PROFINET（PI International管理のオープン規格、主にシーメンス系で普及）など上記以外のプロトコルも存在しますが、上記は日本の物流現場で見かけることが多い代表例です。なお、これらの産業用プロトコルはインターネットプロトコル（HTTP等）を管理するIETFとは別の、FA業界固有の標準化団体やメーカーが管理しています。
産業用プロトコルの設計思想
産業用プロトコルは、現場の設備間で安定してデータをやり取りすることを重視して設計されています。通信相手は同じネットワーク内のPLCやI/O機器であり、インターネットを経由する前提で作られていません。
そのため、Modbusのように古くからあるプロトコルには暗号化や認証の仕組みがありません。OPC UAは、セキュリティやメーカー間の相互運用性も考慮して設計された規格で、暗号化・認証・メーカー非依存を特徴としていますが、対応していないPLCもまだ多くあります。
2. IoTゲートウェイ ↔ クラウド間：IoTプロトコル
IoTゲートウェイがPLCからデータを取得した後、そのデータをクラウドに送信します。ここで使われるのが「IoTプロトコル」です。産業用プロトコルとはまったく異なる設計思想で作られています。
主なIoTプロトコル
| プロトコル | 概要 | 適したユースケース |
|---|---|---|
| MQTT | 軽量なメッセージングプロトコル。Publish/Subscribe（発行/購読）モデルで、送信側と受信側が直接接続しない。データサイズが小さく、通信帯域が限られた環境でも安定動作する | センサーデータの定期送信、大量デバイスからの一括収集 |
| HTTPS | Webで広く使われるプロトコル。Request/Response（要求/応答）モデル。既存のWebインフラをそのまま活用できる | データ送信頻度が低い場合、既存のWebサーバー環境を活用したい場合 |
※AMQP（Advanced Message Queuing Protocol）なども存在しますが、IoTゲートウェイからの送信ではMQTTとHTTPSが一般的です。
MQTTとHTTPSの使い分け
物流現場のセンサーデータ収集では、MQTTが選ばれるケースが多くなっています。その理由は3つあります。
第一に、データサイズが小さいこと。センサーの計測値（温度、カウンタ値、ON/OFFなど）は数バイト〜数十バイト程度であり、HTTPSのヘッダオーバーヘッドに対してMQTTの方が効率的です。
第二に、通信頻度が高いこと。数秒〜数分おきにデータを送信し続ける場合、MQTTは接続を維持したまま軽量にメッセージを送れるため、継続的に小さなデータを送信する用途に適しています。
第三に、通信断への耐性です。MQTTにはQoS（Quality of Service）レベルがあり、メッセージ配送の保証レベルを設定できます。IoTゲートウェイ側のローカルバッファ機能と組み合わせることで、通信断時のデータ欠損リスクを低減できます。
一方、HTTPSは、既存のWeb/API基盤を利用したい場合や、HTTPベースのAPIとの連携が必要な場合などに選ばれます。
3. なぜ2つの区間に分かれているのか
「1つのプロトコルでPLCからクラウドまで直接つなげないのか？」という疑問は自然です。しかし、2つの区間に分かれている理由は、それぞれの通信に求められる要件がまったく異なるからです。
| 比較項目 | 産業用プロトコル（PLC ↔ GW） | IoTプロトコル（GW ↔ クラウド） |
|---|---|---|
| 主な要件 | 設備間で安定してデータをやり取りすること | 通信品質が変動する環境でもデータを届けること |
| 通信環境 | 同一ネットワーク内（工場LAN） | インターネット経由（回線品質が不安定な場合あり） |
| セキュリティ | 暗号化・認証機能を持たないプロトコルも多い（ネットワーク分離やファイアウォールで保護する設計が一般的） | TLSなどによる暗号化・認証を組み合わせて利用 |
| データ表現 | デバイス・レジスタ・タグ等の設備側データ | JSON等の構造化データ |
IoTゲートウェイは、この2つの異なる世界を橋渡しする装置です。現場のPLCからレジスタ値を産業用プロトコルで読み取り、タイムスタンプやデバイスIDを付与してJSONに変換し、MQTTやHTTPSでクラウドに送信する——この「翻訳」こそがIoTゲートウェイの中核的な役割です。
IoTプロトコルは「インターネット越しに確実に届けること」を重視している。
目的が違うから、プロトコルも違います。
4. プロトコル選定で最初に確認すべきこと
プロトコルの選定といっても、現場担当者がゼロから選ぶ必要はほとんどありません。実際の選定は、以下の順序で決まることが多いです。
Step 1：現場のPLCが何に対応しているかを確認する
PLCのメーカーと機種が決まれば、使えるプロトコルはほぼ自動的に決まります。三菱電機のMELSECならSLMP、オムロンならFINS、複数メーカーが混在する現場ならModbusやOPC UAが候補になります。
Step 2：IoTゲートウェイの対応プロトコルを確認する
IoTゲートウェイ製品は、対応するPLCプロトコルの一覧を公開しています。現場のPLCに対応した製品を選べば、プロトコルの組み合わせは自動的に決まります。
Step 3：クラウド側の受信プロトコルを確認する
AWS IoT Core、Azure IoT Hubなどの主要なクラウドIoTサービスはMQTTとHTTPSの両方に対応しています。IoTゲートウェイからクラウドへの継続的なデータ送信では、MQTTがよく利用されます。
まとめ：プロトコルは「区間で分けて理解する」
現場からクラウドまでのデータ通信には、産業用プロトコル（PLC ↔ IoTゲートウェイ）とIoTプロトコル（IoTゲートウェイ ↔ クラウド）という2つの区間があります。それぞれの区間で求められる要件が異なるため、使われるプロトコルも異なります。
現場担当者にとって重要なのは、個々のプロトコルの仕様を覚えることではなく、「現場のPLCが何に対応しているか」を起点にして、IoTゲートウェイ・クラウドとの接続構成を確認することです。
現場のPLCとクラウドの組み合わせから「決まる」ものです。
重要なのは、プロトコルやゲートウェイを選ぶことではなく、最終的にどのKPIを改善するために、どのデータを収集するかを決めることです。Nexa Warehouse-Optimizerは、収集したデータをKPIとして可視化し、改善サイクルにつなげる分析基盤です。データ収集の構成設計からご相談いただけます。
お問い合わせはこちら