（日本ラッド株式会社 DXソリューション本部 IoTソリューション第一事業部 事業部長）
本記事は、工場IoTの推進担当として「PLCのデータをどのように収集し、活用するか」を短期間で学習したい方に向けた実務ガイドです。
IoTゲートウェイを使ったPLCデータ収集の目的整理から、製品選定の勘所、ネットワーク要件、実装手順、運用・セキュリティ、トラブル対応までを一気通貫で解説します。
既存設備の改造を最小化しつつ、複数メーカーのPLCデータを収集・統合し、クラウドやオンプレのIoTプラットフォームに安全に連携するための具体的なポイントを整理しています。
IoTゲートウェイでPLCデータを収集する目的と期待できる効果
PLCは設備制御の中核を担っていますが、現場の稼働・停止・品質・エネルギーなどの情報が「見える化」されていなければ、改善は経験則に頼る形となり、継続的なカイゼン活動に繋げていくことが難しくなります。
IoTゲートウェイを介してPLCデータを収集することにより、既存設備の設定変更・ラダー改修を最小限にしながら、稼働率・停止要因・段取り時間・不良傾向などをリアルタイムに可視化するとともに時系列に把握することも可能となります。
さらに、複数ライン・複数メーカーのPLCを同一プラットフォームに集約することで、工場全体のKPIを統合的に管理しやすくなります。
期待効果は「現状把握の高速化」「改善サイクルの短縮」「遠隔監視による保全効率化」「データ連携による自動レポート化」などで、スモールスタートから本番展開までの道筋も描きやすくなります。
PLCとIoTゲートウェイの役割
PLCは「制御のためのリアルタイム機器」で、I/Oを読み書きし、ラダー等のロジックで設備を動かします。
一方、IoTゲートウェイは「データ収集と橋渡しのための機器」で、PLCやセンサーのデータを吸い上げ、必要に応じて変換・蓄積し、上位（サーバ／クラウド／DB）へ送ります。
重要なのは、PLCの制御を乱さず、通信負荷やセキュリティリスクを抑えながら、運用可能な形でデータを外に出すことです。
ゲートウェイはプロトコル変換、エッジ処理、バッファ、遠隔管理などを担い、工場ネットワークとIT側の境界（DMZ的役割）にもなります。
IoTゲートウェイとPLCの違い
PLCは設備を止めないことが最優先で、決められた周期で確実に制御する設計思想です。
対してIoTゲートウェイは、データの収集・整形・送信を安定運用することが主目的で、通信断時の再送やバッファ、暗号化、デバイス管理などIT寄りの機能が求められます。
PLCの基本機能と入出力
PLCはCPUユニットがプログラムを実行し、I/Oモジュールを介して現場信号を扱います。
デジタル入力は近接センサーやリミットスイッチのON/OFF、デジタル出力はソレノイドやリレー駆動などが典型的な例となります。
アナログI/Oは温度・圧力・流量などの連続値を扱い、分解能やスケーリング（工学値変換）が重要になります。拡張ボードや通信モジュール（Ethernet、シリアル、フィールドバス）で外部機器と接続し、内部メモリ（レジスタ、デバイス）に状態やカウンタ、アラームを保持します。
IoTゲートウェイで扱うのは、この内部デバイス値やI/O状態を「読み出して時系列化する」ことが中心です。
IoTゲートウェイの機能と搭載ソフトウェア
IoTゲートウェイは、PLC通信ドライバを持ち、収集したデータを上位へ送るためのソフトウェアスタックを搭載しています。
代表機能は、プロトコル変換（例：MC→MQTT、Modbus→HTTP）、データマッピング（レジスタ→タグ）、時刻付与、フィルタリング、しきい値判定、ローカルバッファ（通信断対策）、リモート管理です。
製品によってはOPC UAサーバ/クライアント、MT Connect、Node-REDのようなフロー処理、Docker等のコンテナ実行、ローカルDB保存に対応しているものもあります。
工場IoT推進担当としては「現場で増える運用作業」を減らすため、GUI設定、テンプレート、集中管理、ログ取得のしやすさを重視すると失敗しにくいです。
準備フェーズ・要件定義
準備フェーズでの要件定義が甘いと、現場工事後に「取れないデータがある」「ネットワークに繋げない」「セキュリティ審査で止まる」が起きます。
最初に、対象設備（PLC型式、通信モジュール、空きポート、既存ネットワーク）と、目的（可視化、保全、品質、エネルギー）を紐づけて、必要データと更新周期を決めます。
次に、接続方式（工場LANかLTEか、オンプレかクラウドか）を決め、IP設計・セグメント・FW・DMZ・リモート保守の方針を固めます。
最後に、現場設置条件（盤内スペース、電源、温度）と、運用体制（誰が監視し、誰が復旧するか）を明文化すると、PoCから本番への移行がスムーズです。
対応PLC機種・インターフェース確認
まずPLCの型式と、搭載している通信インターフェースを棚卸しします。
Ethernetが使えるなら、Modbus/TCP、EtherNet/IP、MC/SLMPなどの選択肢が広がり、配線も簡素です。
一方で、古い設備ではRS-232C/RS-485のシリアル通信のみ、独自プロトコルのみというケースもあり、ゲートウェイ側のドライバ対応が成否を分けます。
また、同一PLCに既に上位機器（HMI、SCADA）が接続されている場合、同時接続可否、コネクション数、ポート競合、通信負荷を確認する必要があります。
収集するデータ項目の設計
「何を取るか」を先に決めないと、タグが増えすぎて通信負荷や運用負担が膨らみます。
基本は、稼働状態（運転/停止/異常）、停止理由（アラームコード）、生産数（良品/不良）、サイクルタイム、段取り、主要アナログ値（温度・圧力等）から始めるのが定石です。
PLC内部のどのアドレスに必要な値が保持されているか、スケーリング、符号、エンディアン、更新タイミング（ラダー内でいつ更新されるか）も合わせて確認します。
物体検出カウンタのように高速で変化する値は、ポーリング周期だけでなく、変化点送信やイベント送信、PLC側での状態保持なども検討すると欠損を減らせます。
- 必須KPI：稼働/停止、アラーム、良品数、不良数、サイクルタイム
- 品質系：温度、圧力、トルク、電流、レシピ番号、ロットID
- 保全系：異常履歴、警報回数、モータ負荷、振動（別センサー）
- データ定義：単位、スケール、符号、更新周期、欠損時の扱い
ネットワーク設計
ネットワークは「繋がる」だけでなく「運用できる」設計が必要です。
工場LAN接続なら、OTセグメント分離、固定IP、DNS/NTP、FWルール、上位サーバの配置（オンプレ/クラウド）を整理します。
無線LANは配線工事を減らせますが、電波環境とセキュリティ（WPA2/3、証明書、鍵管理）を厳密にしないと不安定化しやすい点に注意します。 LTEを使う場合は、SIMの契約・在庫管理、APN設定、閉域網/VPN、電波調査、アンテナ引き回し、通信量の見積りが重要です。
IoTゲートウェイでPLCデータを収集する具体的なステップ
PLCとIoTゲートウェイの接続
多くのケースでは、PLCのI/O配線に割り込むのではなく、PLCの通信ポート（Ethernet/シリアル）からデータを読み出します。
I/Oに直接接続する方式は、PLC改造が難しい設備や、信号を独立に取りたい場合に有効ですが、配線工事・絶縁・ノイズ・安全回路への影響評価が必要です。
Ethernet接続なら、産業用スイッチ経由でゲートウェイを接続するのが一般的です。
シリアル接続では、RS-232C/485の結線、終端抵抗、通信条件（ボーレート、パリティ、ストップビット）を揃え、ケーブル長とノイズ対策を確認します。
通信プロトコル設定とデータマッピング
プロトコル設定では、まず「最小の1点」を読める状態にしてからタグを増やします。
Modbus/TCPなら、ユニットID、ファンクションコード、アドレス体系（0/1起点）、レジスタ種別（Holding/Input）、エンディアンを確認します。
Modbus/RTUや独自プロトコルでは、タイムアウト、リトライ、インターバルといったインターフェース仕様を詰めないと、通信が詰まって全点欠損することがあります。
データマッピングは、PLCデバイス名→タグ名→単位→スケール→欠損時の扱いを定義し、命名規則（ライン/設備/信号）を統一すると後工程（可視化・分析）が楽になります。
また、ポーリング周期は短くしすぎるとPLC負荷やネットワーク負荷が上がるため、KPIに必要な粒度から逆算して設計します。
クラウド／オンプレミスサーバへの送信とネットワーク設定
上位送信は、MQTT/HTTPS/OPC UA/ファイル（CSV等）など方式を決め、自社のネットワーク制約（アウトバウンドのみ許可等）に合わせます。
工場では通信断が起きる前提で、ゲートウェイ側のバッファリング（ローカル保存、再送、重複排除）を確認します。
送信間隔は、リアルタイム監視なら秒〜分、日報用途なら分〜時など目的で分け、全点を同周期にしない設計が通信量削減に効果的です。
ファイル連携の場合は、ファイルローテーション、転送失敗時の再送、容量上限、文字コード、区切り文字の標準化まで決めておくと運用が安定します。
動作確認・監視設定
動作確認は、疎通→データ取得→上位送信→欠損時挙動の順で行い、正常系だけでなく異常系（LAN断、LTE圏外、PLC停止、電源瞬断）を試験します。
現場で頼りになるのはLEDとログなので、LEDの意味（通信、エラー、送信）を手順書に落とし、ログの取得方法（期間、レベル、エクスポート）を決めます。
アラートは「通知が多すぎる」と形骸化するため、まずは通信断・バッファ逼迫・再起動・ディスク逼迫など致命的イベントに絞るのが現実的です。
現場に行かずに一次切り分けできる状態を作れるよう、リモート監視が可能な状態にすることで運用コストが大きく下がります。
三菱PLCと組み合わせた導入パターンと事例
三菱PLC中心の工場では、MCプロトコルでのデータ収集が定番です。
導入パターンとしては、
- PLCのEthernetポートにIoTゲートウェイを接続してレジスタを読み出す
- 既存の上位機器・システム（GOT/SCADA）と同居させて読み出す
- ライン単位でゲートウェイを置き、上位にMQTT等で集約する
というパターンが多いです。
事例的には、稼働/停止とアラームコード、カウンタ、品番等を収集し、停止要因や段取り時間の見える化に繋げるケースが成果に直結します。
LTEを使ったクラウドIoTプラットフォーム連携パターンの利点
LTEを使った工場IoTでは、データ収集と可視化だけではなく、デバイス管理を一体で運用できる点も効果的です。リモートアクセスなどをオプション機能として扱えるため、拠点や台数が増えても運用が破綻しにくくなります。
連携パターンは、ゲートウェイから
- MQTTでクラウドに送信
- HTTPSでAPI送信
- 閉域/VPNでセキュアに送信
などが代表的です。
利点は、現場LANに手を入れずに始められること、セキュリティ境界を作りやすいこと、通信断時の状況把握がしやすいことです。
一方で、電波品質とアンテナ設計、通信量見積り、SIM管理の権限設計は事前に詰める必要があります。
運用・保守とセキュリティ
工場IoTは「入れた後」の運用コストも重要です。通信断、機器故障、設定変更、証明書更新、OS/ファーム更新、アカウント管理など、運用タスクを見積もらずに始めると、現場負担が増えて継続できません。
運用設計では、監視項目とアラート基準、一次対応フロー、現場対応が必要な条件、予備機・交換手順、設定バックアップを決めます。
セキュリティは、ネットワーク分離、認証、暗号化、SIM管理、脆弱性対応を「できる範囲で標準化」することが重要です。
また、メーカー/SI/社内の役割分担（どこまでが保守範囲か）を契約・手順に落とし込むと、障害時の復旧が速くなります。
遠隔運用とリモート管理
遠隔運用の目的は、現場に行かずに「状況把握」と「一次復旧」をできるようにすることです。
最低限、オンライン/オフライン、最終送信時刻、バッファ滞留、CPU/メモリ/ディスク、再起動履歴を見える化しておきましょう。
アラートは、メール/チャット/監視ツール連携など運用に合う経路を選び、夜間対応の要否も含めて設計します。
運用フローは、(1) アラート受信、(2) ログ確認、(3) ネットワーク疎通確認、(4) 再起動/設定反映、(5) 現場依頼、のように段階化すると属人化を防げます。
リモートアクセスは便利ですが、権限と監査ログがないとリスクになるため、VPN/ゼロトラスト/踏み台など会社の標準に合わせます。
保守・サポート体制と納期・価格の見積りポイント
見積りでは、本体価格だけでなく「導入作業」と「運用保守」を分けて考えると判断しやすくなります。
導入作業には、現地調査、盤内工事、ネットワーク設定、タグ設計、試験、手順書作成が含まれます。
運用保守には、監視、障害一次対応、予備機、交換作業、ファーム更新、設定変更、問い合わせ窓口が含まれます。
納期は、ゲートウェイ本体だけでなく、アンテナ、SIM、スイッチ、電源部材、盤改造部材の調達も含めて確認します。
メーカーサポートを使う場合は、対応時間、オンサイト可否、ログ提出要件、代替機手配の条件を事前に押さえると、障害時に揉めません。
日常運用で注意する項目
日常運用では、通信やソフトだけでなく、電源・温度・物理劣化にも注意が必要です。
電源は瞬停や電圧降下で再起動が起きるため、必要ならUPSや電源系統の見直しを行います。
温度は盤内の季節変動が大きく、夏場にだけ不安定になることがあるため、温度ログやファンの点検をルーチン化すると効果的です。
定期点検では、配線の緩み、アンテナ固定、腐食、フィルタ詰まり、ラベル剥がれなど、地味な項目が障害予防に直結します。
導入後の活用と効果測定
データ収集はゴールではなく、改善のスタートです。
導入後は、KPIを定義し、現場が毎日見て意思決定できる形（ダッシュボード、日報、アラート等）に落とし込みます。
効果測定は、稼働率や停止時間のような結果指標だけでなく、停止理由入力率、アラート対応時間、保全の計画化率などプロセス指標も併用すると、改善活動が継続します。
IoT推進担当として、まず1ラインで成果が出る「使われる画面・使われる指標」を作り、横展開のテンプレにするのが最短ルートです。
ダッシュボードでの可視化とKPI設計
可視化は、見る人（現場班長、保全、製造管理、経営）ごとに粒度を変えるのがコツです。
現場側はリアルタイムの稼働/停止と停止理由、当日目標との差分が重要ですので、そういった情報を大型モニタなどに常時表示するのが効果的です。
管理側は日次・週次の稼働率、停止要因、品質傾向、ライン間比較が重要ですので、様々な視点で分析することができるダッシュボードが必要になります。
KPIは、OEE（稼働率・性能・品質）をベースにしつつ、最初は「停止時間」「停止回数」「トップ停止理由」など改善に直結する指標に絞ると定着します。
タグ命名と設備階層（工場→ライン→設備→ユニット）を揃えることで、画面作成や横展開が速くなります。
生産・設備監視で期待できる効果
効果が出やすいのは、停止の見える化と、保全の効率化です。
停止理由がデータで揃うと、対策の打ち手が感覚的ではなく明確になります。
また、アラーム履歴や負荷データを蓄積すると、突発停止の前兆を捉えやすくなり、計画保全に活用することができます。
コスト面では、現場巡回の削減、報告書作成の自動化、部品交換の適正化、エネルギーのムダ削減が積み上がります。
重要なのは、効果を「時間」「金額」「品質」のどれで評価するかを事前に決め、導入前のベースライン（現状値）を取っておくことです。
データ分析・機械学習による異常検知への展開
異常検知に進む前に、まずはデータの整備が必要です。
時刻同期、欠損処理、センサー校正、運転条件（レシピ、品種、速度）のラベル付けがないと、モデルが誤検知しやすくなります。
進め方としては、
- しきい値・ルールベースでアラート
- 統計的手法で外れ値検知
- 機械学習で多変量の異常検知
の順に段階化すると現場受け入れが進みます。
PLCデータだけで足りない場合は、振動・電流・温度など追加センサーをゲートウェイに取り込み、設備状態を多面的に捉えると精度が上がります。
推進担当としては、モデル精度よりも「検知→対応→結果記録」の運用ループを先に作ると、投資対効果が出やすくなります。
よくあるトラブルと対処法
トラブルは大きく「物理接続」「ネットワーク」「プロトコル/データ定義」「上位連携」「運用」の5系統に分かれます。
現場ではまず切り分けが重要で、闇雲に設定を触ると復旧が遅れます。
LED状態、疎通（ping/ポート）、ログ、最終送信時刻、PLC側の通信エラーを順に確認し、どの層で止まっているかを特定します。
データ不整合は、エンディアン、符号、スケール、アドレス起点、更新タイミング、時刻ズレが原因になりやすいです。
メーカーサポートに頼る場合も、必要情報（構成、ログ、設定ファイル）を揃えると解決が速くなります。
接続トラブルのチェックリスト
接続トラブルは、まず物理層から潰すのが鉄則です。
LANならリンクアップ、ケーブル種別、スイッチポート設定、VLAN、IP重複を確認します。
シリアルなら結線（Tx/Rx/GND）、終端抵抗、通信条件不一致が多発原因です。
I/O直結の場合は、電圧レベル、絶縁、接点チャタリング、ノイズ混入、共通GNDの取り方が影響します。
現場で再現性のない不具合は、配線の緩みや盤内温度上昇が原因のこともあるため、点検とログの突合が有効です。
- LAN：リンクLED、ケーブル断線、VLAN/ポート設定、IP重複、FW遮断
- LTE：アンテナ位置、電波強度、APN、SIM状態、通信量制限
- シリアル：結線、終端、ボーレート/パリティ、ケーブル長、ノイズ
- I/O：電圧レベル、絶縁、接点チャタリング、シールド/接地
通信・データ欠損が発生したときの原因切り分け
欠損が出たら、(1) PLC→ゲートウェイ間、(2) ゲートウェイ内部処理、(3) ゲートウェイ→上位間、のどこで欠けているかを確認し、原因を切り分けます。
PLC→ゲートウェイ間なら、ポーリング過多、タイムアウト、同時接続競合、PLC側負荷が疑わしいです。
上位側で欠けるなら、回線断、DNS/NTP不良、TLS失敗、サーバ側の受信制限、レート制限が候補です。
ゲートウェイ内部では、バッファ容量不足、ディスク逼迫、プロセス再起動、時刻ズレが起きます。
LEDとログで「いつから」「どの通信が」「どのエラーコードで」止まったかを押さえ、再起動で直るか、設定変更が必要かを判断します。
プロトコル不整合やレジスタ誤設定の対処法
データが取れているのに値がおかしい場合、プロトコル不整合やレジスタ定義ミスが多いです。
典型は、アドレス起点の違い（0/1）、ワード順序（エンディアン）、符号付き/符号なし、32bit値の結合順、BCD/ASCII混在、スケール係数の誤りです。
対処は、PLC側のモニタ（GX Works等）で実値を確認し、ゲートウェイ側の生データ（受信フレームやレジスタ値）と突合します。
また、更新タイミングの問題で「瞬間値を取り逃す」こともあるため、PLC側でラッチする、変化時のみ送る、差分で送るなどの設計変更も検討します。
タグ追加時は、少数追加→確認→展開の手順を守ると、原因箇所を特定しやすくなります。
PoCから本番までの進め方と支援依頼のポイント
PoCは、(1) 目的とKPI、(2) 最小データ項目、(3) 可視化、(4) 欠損時の挙動、(5) 運用フロー、までを1セットで作ると効果の確認がしやすく、本番・横展開への道筋が立ちやすくなります。
日本ラッドでは、IoTゲートウェイとIoTプラットフォームをワンストップで提供しているため、スモールスタートを最速で開始することが可能となります。また、横展開が可能な機器構成・システム構成となっているため、スモールスタートから本番・横展開までをシームレスに実現可能です。
支援依頼時は、現場制約（停止可否、ネットワーク方針、クラウド可否）、対象PLC一覧、欲しいKPI、既存システム（SCADA/DB）の有無を提示いただくと、見積りと提案が具体化しやすいです。
本来、工場IoTは登場人物が多く、役割分担も縦割りとなり、導入に時間が掛かることも多いですが、製品仕様と不具合切り分けに強く、要件定義・ネットワーク・運用設計・可視化まで含めたトータルシステムインテグレーションが可能な日本ラッドにぜひご相談いただければと思います。
