PLCデータ収集2026｜取れない原因は通信規格ではなく点数と周期

「この設備、PLCからデータ収集できますか」という質問に、そのまま「できます」「できません」で答えられたことがありません。PLC データ収集で実際に決まっているのは可否ではなく、4つある経路のどれを通るかだからです。経路が決まれば、費用も、取れる値の限界も、装置メーカーに何を確認すべきかも、ほぼ自動的に決まります。そして見積が桁で割れる真因は、OPC UAかModbusかという通信規格の選択ではありません。タグ点数、収集周期、装置メーカーの保証。この3つです。

PLCデータ収集で本当に決まっているのは「経路」である

見積を並べたときに、同じ工場・同じ台数なのに金額が2倍3倍違う。この現象は珍しくありません。原因を通信規格の違いだと説明されることが多いのですが、内訳を開くとたいてい違います。各社が想定している経路が違うのです。

経路は4つしかありません。既設のEthernet対応PLCを直接読む、PLCに内蔵されたOPC UAサーバ機能を使う、シリアルしか持たない旧型PLCに変換器を足す、そしてPLCにいっさい触らずに外から測る。この4つです。1つの工場の中に4経路すべてが混在するのが普通で、だから「うちの工場はデータ収集できますか」という問いは、そもそも粒度が合っていません。設備1台ごとに経路が決まり、経路ごとに単価と限界が決まります。

工場IoT全体の進め方や、どこから手を付けるかという順序については工場IoTモニタリング導入の全体像で整理しています。本記事はその中の「PLCから値を取り出す」という一点を、経路と費用の粒度まで掘り下げるものです。

経路1 既設Ethernet PLCを直読みする（MCプロトコル／FINS／S7／EtherNet/IP）

いま国内外の工場で最も本数が多いのがこの経路です。すでにEthernetポートを持っているPLCに対して、IoTゲートウェイやエッジ機器が各社固有のプロトコルで話しかけ、PLCのデバイスメモリを直接読みます。

• 三菱電機のMELSECシリーズならMCプロトコル
• オムロンならFINS
• シーメンスならS7（S7comm）
• ロックウェル・オートメーションならEtherNet/IP（CIP）

いずれも「Dレジスタの100番から10ワード読む」「タグ名を指定して読む」といった形で、PLCが持っている値をそのまま取り出します。

この経路の最大の利点は、ラダープログラムに手を入れずに始められることです。読み出しは基本的にPLC側から見れば外部からのアクセス要求なので、既存の制御ロジックを1行も変えずに、いま動いている設備から値を持ち出せます。稼働中のラインを止めずに着手できる、という意味でも実務的な価値が大きい。

欠点は、タグの意味が機械可読でないことです。D100に何が入っているかは、PLCのどこにも書かれていません。設計書か、ラダーのコメントか、あるいは古参の保全担当者の記憶の中にあります。ゲートウェイから見れば、D100は単なる16ビットの整数です。単位がミリ秒なのか秒なのか、生産数の累計なのか当直分なのか、値が0のときは「停止中」なのか「通信できていない」のかを、機械が判断できません。

この「意味の対応表」を作る作業が、経路1の実質的な作業量です。見積書に「設定費」と1行で書かれている部分の中身はここで、設備1台あたり4つの変数を取るなら、4つのアドレスについて意味・単位・型・更新タイミングを人が確認して台帳に落とす必要があります。設備が違えばアドレスも違い、同じメーカーの同じ機種でも装置メーカーごとに割り付けが違います。ここを省略すると、収集は成功しているのにダッシュボードの数字が誰にも解釈できない、という状態になります。

なお、この経路ではPLCが工場ネットワークに接続されていることが前提になります。制御用のネットワークが情報系から分離されている工場では、どこに境界を置いてゲートウェイを配置するかという設計が必要です。ネットワーク側の設計は産業用ネットワークと工場の無線LANで扱っています。

経路2 PLCのOPC UAサーバ機能を使う

近年の中位機・上位機のPLCには、OPC UAサーバ機能が内蔵されています。オプションユニットやライセンスキーで有効化する形が多く、有効化するとPLC自身がOPC UAサーバとして振る舞い、外部のクライアントからアドレス空間を参照できるようになります。OPC UAはIEC 62541として国際標準化されている仕様です。

経路1との決定的な違いは、値だけでなくメタ情報が一緒に付いてくることです。

経路1で人が台帳に書き写していた情報の一部が、機械可読な形でサーバ側に載っている。これがOPC UAを選ぶ最大の理由です。特に品質（status）は運用に効きます。値が0のときに「本当に0なのか」「読めていないのか」を受信側が区別できるためです。経路1ではここを区別できず、通信断がそのまま「生産数0」としてグラフに描かれてしまうことがあります。

もう1つ、OPC UAはサブスクリプションを持ちます。クライアントが「この変数がデッドバンドを超えて変化したら通知して」と登録しておくと、変化がない間はトラフィックが発生しません。ポーリングのように一定間隔で問い合わせ続ける方式に比べ、静かなタグがネットワークとCPUを消費しない構造になっています。タグ点数が増えたときに効いてくる差です。

欠点は3つあります。1つめはCPU負荷です。OPC UAサーバはPLCのCPU上で動くため、制御スキャンと資源を分け合います。稼働中のラインでは、有効化前後でスキャンタイムがどう変わるかの確認が要ります。2つめはライセンス費用です。多くの機種で有効化に有償ライセンスが必要で、これは設備台数ぶん積み上がります。3つめは機種が限られることです。10年前、20年前に導入したPLCには、そもそもこの機能がありません。

フィールドレベルの標準化については、OPC FoundationがOPC UA FX（Field eXchange）を進めています。公開されている情報では、Controller-to-Controller（C2C）の仕様は完成済みで、2026年6月時点でController-to-Device（C2D）拡張のリリース候補を準備している段階です。C2Dはモーション機器、リモートI/O、センサ、アクチュエータの統合を対象としており、2026年2月16〜19日にはベッコフのベルリンオフィスで相互接続（IOP）イベントが実施され、SPS 2026 に向けてマルチベンダーのデモウォールが準備されていると報告されています。正式リリースの時期や版番号は公表されていませんので、いま計画中の案件でC2Dを前提に設計を組むのは避けてください。現時点で確実に使えるのは、既存のOPC UAサーバ機能のほうです。

経路3 シリアルのみの旧型PLCに変換を足す

Ethernetポートを持たず、RS-232CやRS-485しか出ていないPLC。稼働中の工場には相当数が残っています。この場合は、シリアルをModbus TCPなどに変換するユニットを盤内に追加します。

Modbusは実装が単純で、対応機器が多く、変換ユニットも安価です。その代わり、性質上の制約が3つあります。

1つめはポーリング専用であること。 マスタが問い合わせ、スレーブが答える。この往復の繰り返しでしか値を取れません。変化があったときに機器側から知らせてくる仕組みがないため、「変化を見逃さないためには短い周期で問い合わせ続ける」しかありません。

2つめは読み方の設計で速度が桁で変わること。 連続するレジスタを1リクエストでブロック読み出しするのと、1点ずつ単発で読むのを繰り返すのとでは、効率がまったく違います。ブロックにまとめるほうが圧倒的に速い。RS-485のようなシリアルバスでは、1回の往復にかかる時間とバス上の競合が速度の上限を作るため、リクエスト回数そのものを減らすことが唯一の高速化手段になります。「Modbusは遅い」と言われる案件の多くは、プロトコルが遅いのではなく、読み方が単発読みの繰り返しになっているだけです。この設計は、レジスタが連番で並んでいるかどうかに左右されるので、経路1と同じく「どのアドレスに何が入っているか」の台帳が先に要ります。

3つめは素のModbusに認証・認可・暗号化が無いこと。 ネットワークに到達できる誰もが、レジスタを読めますし、実装によっては書けます。制御ネットワークから情報系に橋を架ける以上、この点は必ず設計に含めてください。ゲートウェイを読み出し専用に構成する、VLANで区画を分ける、変換ユニットから先を一方向にする、といった対策が要ります。工場のOT側をどう守るかはタイ工場のOTセキュリティで整理しています。

経路4 PLCに触らず外から測る

PLCが無い単独機、手動機、そして「装置メーカーの保証の都合でPLCに触れない設備」。この3つに対しては、外から測るしかありません。

代表的な手段は3つです。

• 三色灯（シグナルタワー）の信号分岐 — 緑・黄・赤の点灯信号を分岐して読み取り、稼働／停止／異常を判定します。既存の配線を分岐するだけなので、PLC側には何の変更も生じません。
• 光電センサでのカウント — 完成品やワークが通過する位置にセンサを置き、通過回数を生産数として数えます。
• 電流センサ — 主軸やモータの電流を測り、しきい値を超えている時間を稼働時間とみなします。クランプ式なら結線を切らずに取り付けられます。

この経路で取れるのは、稼働／停止と生産数までです。停止要因コードは取れません。三色灯が赤になったことは分かっても、それがワーク詰まりなのか材料切れなのか、ヒータ異常なのかは判別できません。サイクルタイムの内訳、つまり「加工に何秒、搬送に何秒」といった分解もできません。外から見えるのは結果だけで、装置の内部状態は見えないからです。

したがって経路4は、他の経路の劣化版ではなく、取れる変数の集合そのものが違うと考えるべきです。後述するモデル工場で、D群4台の変数を4つではなく2つとしているのはこのためです。この経路の具体的な部材選定や設置の勘所は古い設備のIoT化・レトロフィットに、生産数カウントに絞った話は生産数カウントの自動化にまとめています。

4経路を並べると、こうなります。

通信規格を変えても取れないもの、3つ

経路を決めたあとで、それでも「取れない」という結論になる場面があります。ここが本記事のいちばん実務的な部分です。以下の3つは、プロトコルを変えても、ゲートウェイを高性能にしても、解決しません。

理由1 欲しい値がラダーの中に無い

いちばん多い行き止まりがこれです。

「不良の理由コードが欲しい」という要望があったとします。作業者がタッチパネルで理由を選び、その値がPLCのどこかのデバイスに入っている——そう想定して探すのですが、無い。なぜ無いかというと、誰もラダーで作っていないからです。装置は不良品を検知して止まることはできても、その理由を分類してコード化する処理は、要求されていなければ実装されていません。

存在しない値は、どのプロトコルでも読めません。これは通信の問題ではなく、設計の問題です。したがって解決策も通信側にはなく、ラダーへの機能追加になります。自社設備なら自社の技術者が、装置メーカー納入設備なら装置メーカーへの改造依頼が必要です。当然、費用と期間と、稼働中の設備であれば停止調整が発生します。

見積の場では、ここが「できます／できません」を分ける最初の分岐点です。データ収集の引き合いをいただいた時点で、私たちが最初に確認するのも「その値は、いまラダーの中にありますか」です。無い場合、それはデータ収集の案件ではなく、PLCプログラム改修の案件を含んだ案件になります。改修を外部に出す場合の進め方はPLCプログラム開発の外注で扱っています。

実務上の回避策として、「無い値は取らない」と割り切るのも正当な選択です。停止要因コードが無くても、稼働／停止と生産数とサイクルタイムが取れていれば、停止の発生時刻と長さは分かります。理由の入力は当面タブレットからの手入力に回し、データが溜まってから改修の要否を判断する。この順序のほうが、改修費を先に払って「結局そのコードは使われなかった」という結末を避けられます。

理由2 収集周期がスキャン周期より粗い

2つめは周期の話です。ここは数字で見ないと感覚がつかめません。

PLCは、入力読み込み・演算・出力更新を高速に繰り返しています。この1周がスキャン周期で、規模にもよりますが10ms程度で回っている設備は珍しくありません。一方、収集側のポーリング周期は、タグ点数とネットワークの都合から1,000ms（1秒）に設定されることがよくあります。

1,000ms ÷ 10ms = 100倍。収集側は、PLCが100回スキャンする間に1回しか値を見ていない計算になります。

この粗さが何をもたらすか。サイクルタイム30秒の工程を1秒周期で測る場合を考えます。工程の開始と終了のタイミングは、それぞれ最大1秒ぶんの取りこぼしを含みます。つまり測定値の誤差は最大±1秒で、30秒に対して3.33%です。日々の傾向を見るには十分ですが、1サイクルあたり1秒に満たない改善の効果を検証する、という用途には足りません。

さらに深刻なのが短時間の停止です。

20秒の停止は、1秒周期なら停止状態を何度もサンプリングできるので確実に記録されます。しかし3秒の停止は、サンプリングのタイミング次第で「停止状態を1度も観測しないまま復帰する」ことがありえます。チョコ停が見たいという要望に対して、1秒周期の汎用構成をそのまま提案すると、いちばん見たかった短時間停止だけが落ちる、という結果になります。

対策は2つしかありません。収集周期を上げるか、PLC側でカウントさせるかです。前者はタグ点数×周期でトラフィックとサーバ負荷が決まるため、点数が多いと現実的でなくなります。後者は理由1と同じくラダー改修になりますが、PLCのスキャン周期で停止回数と停止時間を積算させ、収集側はその積算値を1秒周期で読むだけにすれば、周期の粗さが問題になりません。測る場所をPLC側に寄せるという考え方です。チョコ停をOEEにどう反映させるかという運用側の設計はチョコ停とOEEの考え方にまとめています。

理由3 装置メーカーの保証と改造可否

3つめは技術ではなく契約の問題です。そして、稼働中の工場ではこれが最も強い制約になります。

装置メーカーから納入された設備には、たいてい改造制限が付いています。問題は、その範囲が「ラダーの書き換え」だけとは限らないことです。読むだけのつもりでも、実際には次のような作業が必要になる場合があります。

• 通信ユニットの増設（盤内スロットの使用）
• PLCの通信パラメータ変更（局番、IPアドレス、ポート開放）
• OPC UAサーバ機能の有効化とライセンス投入
• 盤内への配線追加と、盤扉への穴あけ

これらのどこまでが保証の範囲内かは、契約と装置メーカーの方針によります。「読み出しだけなら問題ない」というメーカーもあれば、「通信ユニットの増設は自社作業に限る」というメーカーもあります。

技術的にも、確認すべき点があります。外部からの通信要求はPLCのスキャンタイムに乗ります。制御に余裕がない設備で、多数のタグを短周期でポーリングすると、スキャンタイムが伸びて制御周期に影響が出る可能性があります。これは装置メーカーでなければ判断できない領域です。

したがって実務では、装置メーカーへの確認を工程表の最初に置くことになります。回答に数週間かかることも珍しくありませんし、「自社の作業員が現地対応する」という回答であれば、その作業費が見積に載ります。後述のモデル試算で経路2に「装置メーカー作業費 35,000 THB/設備」を計上しているのは、この現実を反映したものです。この1行があるかないかで、経路2の設備単価は25,000 THBから60,000 THBに変わります。

見積が桁で割れる3変数（タグ点数・収集周期・保証）

ここまでの内容を、見積の観点から3つの変数にまとめます。ベンダー各社の金額が揃わないとき、たいてい原因はこの3つのどれかです。

変数1 タグ点数。 収集する変数の総数です。設備台数ではありません。同じ8台でも、1台あたり1変数なら8点、4変数なら32点です。そして多くの収集ソフト・可視化ソフトのライセンスは、この点数の階層で価格が決まります。

本記事のモデル条件では、次の階層を置いています。

境目は50と51の間にあります。50タグなら180,000 THB、51タグなら250,000 THB。1タグ増えただけで70,000 THB上がるという不連続がここにあります。

これは机上の話ではありません。後述する案Aのタグ点数は8台×4変数＝32点で50タグ以下の階層に収まりますが、案Bは20台×4変数＋4台×2変数＝80＋8＝88点となり、51〜250タグの階層に上がります。設備を16台増やしたことによる直接の増分（ゲートウェイや工事）とは別に、ソフトのライセンス階層だけで70,000 THBの差が発生する構造です。

したがって、要件定義の段階で確認すべきなのは「何台に付けますか」ではなく「1台あたり何変数取りますか、合計何点になりますか」です。この質問に答えられないまま相見積を取ると、各社が違う点数を想定した金額を出し、比較が成立しません。

変数2 収集周期。 理由2で述べたとおり、周期は精度を決めます。同時に費用も決めます。周期を10倍細かくすれば、単位時間あたりのデータ量は10倍になり、サーバのストレージとネットワークと処理負荷に効きます。経路3のシリアル系では、バスの速度上限に直接ぶつかります。

実務的には、全タグを同じ周期にしない設計が有効です。稼働／停止のように短時間の変化を捉えたい変数は短周期、生産数の累計のように積算値で足りる変数は長周期、というように変数ごとに周期を割り当てます。OPC UAのサブスクリプションを使えるなら、変化しないタグはそもそも通信を発生させません。

変数3 装置メーカーの保証と作業費。 理由3のとおりです。自社設備なら自社で完結する作業が、装置メーカー納入設備ではメーカー作業費として乗ります。モデル条件では設備あたり35,000 THB。この費目が計上されている見積と、されていない見積を並べれば、当然桁が違って見えます。

3つとも、通信規格の話ではありません。OPC UAを選んでもModbusを選んでも、タグ点数は変わりませんし、装置メーカーの保証条項も変わりません。見積の差は規格ではなくこの3変数から生まれている、というのがここでの結論です。工場IoTの費用構造をより広く5つの層に分けて見る整理は工場IoTの費用を5層に分解するで扱っています。

費用と回収をモデル工場で分解する

ここから金額の話に入ります。以下の数値はすべて本記事のモデル条件での試算値であり、実績値ではありません。 単価も効果も工場ごとに大きく違うため、自社の条件に置き換えて読んでください。示したいのは金額そのものではなく、計算の組み立て方です。

モデル工場の前提

群分けがそのまま経路に対応します。A群は経路1、B群は経路2（装置メーカー納入のため保証確認と作業費が発生）、C群は経路3、D群は経路4です。10＋6＋4＋4で24台。

停止の実態は次のとおりです。

最後の行が、この記事のいちばん重要な前提です。非ボトルネック工程の停止は、逸失利益になりません。 その工程が1時間止まっても、仕掛在庫と他工程の余力で吸収され、最終的な出荷数量が変わらないからです。残り16台の停止時間は380−240＝140時間ありますが、これを金額に換算していないのはそのためです。

参考までに、タイ製造業の足元の統計を挙げます。タイ工業省・産業経済局（OIE）の発表として、2026年6月の製造業生産指数（MPI）は前年同月比 −3.10% で2025年11月以来の下落幅、2026年第2四半期は −1.79%、平均設備稼働率は 57.47% と報じられています。自動車と石油が押し下げ、砂糖・洗剤・石鹸・化粧品などの生活必需品は回復傾向とされています。

この稼働率57.47%という数字を「設備が半分空いているからデータ収集が要る」と読むのは短絡です。ここで意味があるのは別の点で、稼働に余裕がある局面では、非ボトルネック設備の停止はいっそう吸収されやすいということです。つまり、フル稼働で受注を積んでいる時期に成立した「全台監視」の投資判断が、稼働率が下がった局面では成立しなくなることがある。逸失利益をゼロと置く工程がどれかは、需要環境によって動きます。統計から自社の数字を推定するのではなく、自社の工程で確認してください。

効果の見積り（両案で共通）

データが取れると何が変わるか。効果の中身は「停止時間そのものが短くなる」ことです。内訳は2つあります。

検知は、設備が止まったことに誰かが気づくまでの時間です。現状の12分は、作業者が別工程にいる、監視室から見えない、といった理由で発生します。収集して通知を出せば2分に縮みます。ここは通知の設計次第で結果が変わる部分で、宛先とエスカレーションの組み方は設備異常の通知設計で扱っています。

原因特定は、駆けつけてから何が起きたかを判断するまでの時間です。停止要因コードとサイクルタイムの履歴があれば、直前に何が起きていたかを画面で確認できるため、18分が8分になります。逆に言うと、この短縮は停止要因コードが取れていることが前提です。経路4しか使えない設備では、この10分の短縮は期待できません。

合計で1件あたり20分の短縮。これをボトルネックの停止件数に掛けます。

• 320件 × 20分 ＝ 6,400分/年
• 6,400分 ÷ 60 ＝ 106.67時間/年
• 106.67時間 × 3,200 THB ＝ 341,333 THB/年
• 5年間で 1,706,667 THB

ここで意識的に計上していないものがあります。非ボトルネック16台の停止短縮です。 これも同じように20分短縮するはずですが、その工程の停止1時間あたり逸失利益を0 THBと置いている以上、金額はゼロです。効果額に足しません。

足したくなる気持ちは分かります。24台ぶん計上すれば効果額は大きくなり、稟議は通りやすくなります。しかし、その数字は「止まっても出荷が減らない工程の停止を、減らした」ことに対して金額を付けたものです。稼働後に実績と突き合わせたとき、必ず合いません。将来ボトルネックが移動する可能性がある、改善のネタが増える、という定性的な価値はあります。ただし本試算では金額化しません。

案A ボトルネック8台に絞る

対象はA群5台・B群2台・C群1台の計8台、1台あたり4変数です。

タグ点数は8台 × 4変数 ＝ 32点。50タグ以下の階層に収まります。

ゲートウェイが1台で済んでいるのは、この機種が1台で最大8ノードを収容するためです。A群5台なら1台で足ります。5台でも8台でも45,000 THBは変わらず、9台目で2台目が必要になるという段差がここにあります。台数を1台増やすかどうかを議論するときは、この段差のどちら側にいるかを確認してください。

年間運用費は次のとおりです。

5年の集計です。

• 5年総費用 ＝ 542,000 ＋ 90,000×5 ＝ 992,000 THB
• 5年効果 ＝ 1,706,667 THB
• 5年純便益 ＝ 1,706,667 − 992,000 ＝ 714,667 THB
• 単純回収 ＝ 542,000 ÷（341,333 − 90,000）＝ 2.16年（25.9ヶ月）

もう1つ、費用の内訳で見ておきたい比率があります。

現場でPLCから値を取り出す部分は、初期費用の半分にしかなりません。 残りの半分は、サーバとネットワークという「現場の外」です。ここを知らずに「ゲートウェイの単価を下げてほしい」という交渉に時間をかけると、効く幅は限られます。実際、経路1のゲートウェイ本体は45,000 THBで、初期542,000 THBに対して1割にも届きません。

案B 全24台に付ける

全台に付ける案です。A群10台に経路1、B群6台に経路2、C群4台に経路3、D群4台に経路4を適用します。

タグ点数は、A〜C群の20台 × 4変数 ＝ 80点、D群4台 × 2変数 ＝ 8点、合わせて 88点。50タグ以下の階層を超えるため、収集サーバ／可視化は250,000 THBになります。案Aとの差70,000 THBは、この階層をまたいだことによるものです。

ゲートウェイはA群10台に対して2台。8ノードの収容上限を超えるためです。

年間運用費です。

5年の集計です。

• 5年総費用 ＝ 1,203,000 ＋ 123,000×5 ＝ 1,818,000 THB
• 5年効果 ＝ 1,706,667 THB（案Aと同額）
• 5年純便益 ＝ 1,706,667 − 1,818,000 ＝ −111,333 THB（赤字）
• 単純回収 ＝ 1,203,000 ÷（341,333 − 123,000）＝ 5.51年（66.1ヶ月）

効果額が案Aと同じである点に注目してください。追加した16台は非ボトルネックであり、その停止1時間あたり逸失利益は0 THBです。費用だけが増えて、金額化できる効果は1バーツも増えていません。

差は826,000 THB。分けているのは通信規格ではない

2案を並べます。

5年純便益の差は 714,667 −（−111,333）＝ 826,000 THB。

この826,000 THBは、5年総費用の差 1,818,000 − 992,000 ＝ 826,000 THB と一致します。当然です。効果額が両案で同額だからです。 効果が変わらず費用だけが増えるなら、純便益の差は費用の差そのものになります。

稟議に書くべき一行は、これです。

案Aと案Bを分けているのは、通信規格でもPLCメーカーでもありません。「その設備が止まったとき、それが本当に売上の損失になるか」だけです。

見積の場では、OPC UAにするかModbusにするか、どのゲートウェイを選ぶかに議論が集中しがちです。しかしモデル条件で最も金額を動かしたのは、対象設備の選び方でした。ゲートウェイ本体の単価45,000 THBに対して、対象の絞り込みが動かした金額は826,000 THBです。

感度3本

前提が変わると結論がどう動くかを、3本だけ見ます。作為的に本数を増やして「どの前提でも成立します」と見せることはしません。むしろ成立しなくなる条件を先に出します。

感度1 停止1時間あたり逸失利益が 3,200 → 1,600 THB になった場合。

• 年間効果 ＝ 106.67時間 × 1,600 THB ＝ 170,667 THB/年
• 案Aの回収 ＝ 542,000 ÷（170,667 − 90,000）＝ 6.72年（80.6ヶ月）

案Aでも成立しなくなります。5年で評価する投資判断の枠に収まりません。逸失利益の単価は、稼働率、受注残、代替生産の可否によって上下します。フル稼働時の単価で計算した回収年数を、需要が落ちた局面にそのまま持ち込まないでください。前掲のMPIや稼働率の動きは、この単価が固定値ではないことの傍証です。

感度2 検知・原因特定の短縮が 20分 → 10分にとどまった場合。

• 年間効果 ＝ 320件 × 10分 ＝ 3,200分 ＝ 53.33時間、53.33時間 × 3,200 THB ＝ 170,667 THB/年

感度1とまったく同額です。効果額は「時間単価 × 短縮分」の積なので、どちらの因子が半分になっても着地点は同じになります。裏を返すと、この2つの前提は独立に議論する意味が薄いということでもあります。稟議で前提を検証するなら、片方ずつ議論するより、積の値そのものを問うほうが早い。

短縮が10分にとどまる原因として現実的なのは、原因特定側です。停止要因コードがラダーに無い設備（理由1）や、経路4しか使えない設備では、原因特定の18分→8分が実現しません。理由1の確認を怠ると、効果が半分になるという関係がここにあります。

感度3 ボトルネックが8台ではなく4台だった場合。

前提を並べ替えます。ボトルネックの停止は120時間、件数は160件、短縮は 160件×20分＝3,200分＝53.33時間、効果は 53.33時間 × 3,200 THB ＝ 170,667 THB/年。

対象4台の内訳をA群3台・B群1台・C群0台とすると、初期費用は次のとおりです。

年間運用費は 70,000 THB。

• 単純回収 ＝ 390,000 ÷（170,667 − 70,000）＝ 3.87年（46.5ヶ月）

ここが逆説です。案A（8台）の回収は2.16年、この案（4台）の回収は3.87年。対象を半分に減らしたのに、回収は遅くなりました。

理由は固定費です。収集サーバ／可視化は、16タグでも32タグでも同じ180,000 THB。ネットワーク工事も台数に完全比例はしません。一方、効果は件数にほぼ比例して半減します。分子（効果）が半分になり、分母（費用）は半分にならない。だから効率が落ちます。

したがって、「絞れば絞るほど得」ではありません。正しくは、固定費を薄めるのに十分な件数のボトルネックが集まる範囲まで絞るです。案Aの8台は、32タグで50タグ以下の階層（180,000 THB）に収まる範囲で、固定費に対して効果を最も詰め込めている点でした。1台減らすと効果だけが減ります。逆に対象を広げていくと、タグ点数が50を超えた時点で収集サーバが250,000 THBの階層に上がり、経路1の接続台数が8を超えた時点でゲートウェイが2台目に増える。この段差を意識して線を引いてください。

タイの工場で先に確認する5点

設計に入る前に、現地で確認しておくべき項目を5つ挙げます。日本の工場と同じ前提で計画を組むと、ここで止まります。

1. 電源。 ゲートウェイと変換ユニットは盤内の制御電源から取るのが基本ですが、既存盤に余裕があるとは限りません。DC24V電源ユニットの容量、ブレーカの空き、そして瞬停対策をどうするかを確認します。工場側の電源品質が安定しない立地では、収集機器だけが落ちて「設備は動いているのにデータが欠測している」状態になります。欠測はグラフ上では停止と区別がつかないため、稼働率の集計を狂わせます。UPSを入れるか、収集側で欠測と停止を区別できるようにするか、どちらかの手当てが要ります。

2. 盤内スペース。 変換ユニットもゲートウェイも、物理的に置く場所が要ります。DINレールの空き、盤扉を閉めたときのクリアランス、そして盤内温度。タイの工場では、空調のない建屋に置かれた盤の内部温度が機器の定格上限に近づくことがあります。機器の使用温度範囲を仕様書の最初に確認してください。増設の余地がない盤では、隣に小型の増設盤を立てる工事が発生し、これは見積の「工事費」に効きます。

3. ネットワーク分離。 制御系（OT）と情報系（IT）をどこで分けるかは、収集を始める時点で決めておく必要があります。経路3のModbusには認証も暗号化も無く、経路1の各社プロトコルも同様に、ネットワークに到達できれば読める設計のものが多い。ゲートウェイを境界に置き、上流へは必要な情報だけを送る構成にするのが基本です。既存の無線LANを使う場合は、電波環境の実測と、生産系トラフィックとの共存も確認事項になります。

4. 装置メーカーの保証。 理由3のとおりです。B群のように装置メーカー納入の設備がある場合、確認の依頼と回答に時間がかかります。工程表の最初に置いてください。回答内容によっては、その設備だけ経路2から経路4に落とす（外から測る）という判断もありえます。取れる変数は減りますが、保証を維持したまま稼働／停止と生産数は取れます。

5. depaの200%損金算入が使えるか。 タイには、中小企業のデジタル化支出に対する200%損金算入の措置があります。条件を整理します。

正直に書きます。タイに進出している日系工場の多くは、この中小企業要件を満たしません。 払込資本金500万THB以下かつ年間収入3,000万THB以下という水準は、本記事のモデル工場（従業員220名）の規模では通常満たせません。また、BOI恩典を受けている事業の支出には使えないという制約も、日系製造業では該当することが多い条件です。

そのうえで、上限は300,000 THBです。案Aの初期542,000 THBに対して、仮に適用できたとしても対象は一部にとどまります。投資判断の前提に組み込むのではなく、要件を満たす場合にのみ確認する項目という位置づけが適切です。適用可否の最終判断は、必ず会計事務所または税務の専門家に確認してください。本記事で示せるのは、公表されている要件の範囲までです。

なお、費用の水準に影響する周辺情報として、タイの最低賃金は2025年7月1日からバンコク都およびチョンブリー・ラヨーンなどの工業地帯で日額400バーツ（改定前372バーツ）に引き上げられ、2026年に入っても据え置かれています。全国では337〜400バーツの幅があります。人が現場を回って停止を発見し、原因を聞き取り、紙に書いて後から入力するという運用は、この賃金水準の上昇分だけ毎年重くなります。データ収集の投資判断は、この人件費のトレンドと合わせて見る性質のものです。

より広い産業政策の文脈としては、世界銀行が2026年2月の Thailand Economic Monitor で「Advanced Green Manufacturing for Growth」を掲げています。設備の高度化とデジタル化が政策側の関心事になっていることは、社内の説明資料で背景として使える材料です。

90日で進める順序

対象を絞ることを前提にした、現実的な進め方です。

第1〜2週 停止の実績を数える。 過去12か月の停止記録を集め、設備別に停止時間と件数を集計します。次に、その停止が出荷数量の減少につながったかどうかで2つに分けます。この分類が、ボトルネックの特定そのものです。記録が「調整」「修理完了」で終わっていて分類できないなら、そこを直すのが先です。この段階の成果物は表1枚で構いません。ここで金額化できる停止がほとんど無いという結果が出たら、データ収集への投資は保留してよい。この分岐を許容できる進め方にしておくことが重要です。

第3〜4週 設備を群に分ける。 対象候補の設備を、PLCの有無、Ethernetの有無、OPC UAサーバ機能の有無、装置メーカー納入か自社設備かで分類します。これがそのまま経路の割り当てになります。同時に、装置メーカーへの確認依頼をこの週に出してください。回答を待つ時間が最も長い工程です。

第5〜6週 変数を確定し、タグ点数を出す。 設備ごとに「何を取るか」を決めます。ここで理由1の確認を行います。欲しい変数がラダーの中に存在するかを、設計書またはPLCの中身で1つずつ確認する。存在しないものは、改修するか、当面取らないかを決めます。この作業が終わると、タグ点数の合計が確定し、ソフトのライセンス階層が決まります。見積の精度が桁で変わるのはこの週です。

第7〜8週 周期を割り当て、構成を決める。 変数ごとに収集周期を決めます。チョコ停を見たい変数があれば、周期を上げるかPLC側でカウントさせるかをここで判断します。並行して、ゲートウェイの台数と設置位置、ネットワークの区画、盤内スペースと電源を現地で確認します。この段階で初めて、見積が実態に合います。

第9〜11週 設置と疎通確認。 取り付け、通信を確認し、値が期待どおりに動くかを見ます。ここでの検証は「通信が成立したか」ではなく「値の意味が合っているか」です。設備を手動で動かし、生産数が1増えるか、停止させたときに稼働フラグが落ちるか、サイクルタイムが実測と一致するかを1台ずつ突き合わせます。経路1では、この突き合わせでアドレスの取り違えが見つかることが珍しくありません。

第12〜13週 運用ルールを決める。 通知の宛先とエスカレーション、停止要因コードの入力ルール、欠測が出たときの扱い、データの保存期間。ここを決めずに可視化画面だけ立ち上げると、3か月で誰も見なくなります。画面を作ることが目的ではなく、45分の停止を短くすることが目的です。誰が、何分以内に、何をするかを文章にしてください。

90日で全台を終える必要はありません。絞った台数で1周させ、効果が実測できてから次の群に広げるほうが、2周目の見積精度も運用ルールの質も上がります。案Aで想定した8台は、まさにこの「1周目」の規模です。

よくある質問

PLCのデータ収集にラダーの改造は必要ですか？

経路1（既設Ethernet PLCの直読み）と経路3（シリアル変換）であれば、既存の値を読むだけなら原則としてラダーの改造は不要です。経路2（OPC UAサーバ機能）は機能の有効化とライセンス投入が必要ですが、制御ロジック自体は変えません。改造が必要になるのは、欲しい値がそもそもラダーの中に存在しない場合です。典型は停止要因コードで、誰かがラダーで分類してデバイスに書き込んでいなければ、どのプロトコルでも読めません。また、収集周期より短いチョコ停を確実に拾いたい場合も、PLC側でカウントさせる改修が現実的な解になります。装置メーカー納入設備の改造は、保証条項の確認が先です。

OPC UAとModbus、どちらを選ぶべきですか？

多くの場合、選ぶものではなく設備側の機種で決まります。OPC UAサーバ機能は近年の中位機・上位機にしか載っておらず、シリアルしか出ていない旧型PLCにはそもそも選択肢がありません。1つの工場の中で、設備ごとに違う経路が同居するのが普通です。

そのうえで両者の性格の差を整理すると、OPC UAは値に型・単位・タイムスタンプ・品質が付き、サブスクリプションで変化時のみ通知できます。Modbusはポーリング専用で、連続するレジスタをブロックで読む設計にしないと速度が出ず、素の仕様には認証・暗号化がありません。

なお、MQTT Sparkplugと比較されることがありますが、OPC UAとSparkplugは競合というより役割分担の関係です。SparkplugはEclipse Foundationの仕様で、平文のMQTTの上にトピック名前空間の標準化、型付きペイロード、そしてbirth/death証明書（機器がオンラインかどうかを受信側が常に判別できる仕組み）を足すものです。OPC UA PubSub over MQTT という組み合わせも存在します。「どちらか一方」ではなく、現場から取り出す層と、上位へ配る層で使い分ける、という整理が実務に近い考え方です。

古い設備からもデータ収集できますか？

できます。ただし取れる変数の範囲が変わります。シリアルポートを持つPLCがあれば経路3（変換ユニット追加）で、PLCが無い単独機・手動機なら経路4（三色灯の信号分岐、光電センサ、電流センサ）です。

経路4で取れるのは稼働／停止と生産数までで、停止要因コードやサイクルタイムの内訳は取れません。これは機器の性能ではなく、外から見ているという構造上の限界です。本記事のモデル工場でD群4台の変数を4つではなく2つとしているのも、この理由によります。「古い設備からも取れます」という提案を受けたときは、取れる変数のリストを明示してもらってください。台数ではなく変数の粒度で確認するのが要点です。

IoTゲートウェイは何台必要ですか？

設備台数ではなく、収容ノード数とネットワークの区画で決まります。本記事のモデル条件では1台あたり最大8ノードを収容する機種を前提としており、案Aの経路1対象5台には1台（45,000 THB）、案Bの経路1対象10台には2台（90,000 THB）を計上しています。5台でも8台でも1台で足り、9台目で2台目が必要になるという段差があります。

実際にはこれに加えて、盤の位置が離れている、ネットワークの区画が分かれている、といった物理的な理由で台数が増えることがあります。逆に、ゲートウェイの単価は初期費用全体に対する比率としては大きくありません。案Aでは初期542,000 THBのうちゲートウェイ本体は45,000 THBで、それより収集サーバ／可視化の180,000 THBやネットワーク工事の95,000 THBのほうが効いています。台数の議論より、タグ点数がライセンス階層のどちら側にあるかを先に確認してください。

チョコ停はPLCデータ収集で見えますか？

収集周期次第です。ポーリング周期を1秒とした場合、20秒の停止は複数回のサンプリングにまたがるため確実に記録されますが、3秒の停止はタイミング次第で1度も観測されないまま復帰することがあります。PLCのスキャンが10msで収集が1,000msなら、収集側は100倍粗い解像度でしか見ていません。サイクルタイム30秒の工程を1秒周期で測れば、誤差は最大±1秒、率にして3.33%です。

短いチョコ停を確実に拾いたいなら、方法は2つです。収集周期を上げるか、PLC側で停止回数と停止時間をカウントさせて、収集側はその積算値を読むか。後者はラダー改修になりますが、周期の制約から解放されるため確実です。「チョコ停が見たい」という要望は、通信規格ではなく周期の要件として伝えてください。 拾ったチョコ停をOEEにどう反映するかは、別途の設計になります。

まとめ

PLCのデータ収集は、「取れる／取れない」の二択ではありません。決まっているのは4つの経路のどれを通るかです。既設Ethernet PLCの直読み、OPC UAサーバ機能、シリアル変換の追加、そしてPLCに触らない外付け。経路が決まれば、単価も、取れる変数の範囲も、装置メーカーに確認すべきことも決まります。1つの工場に4経路が混在するのが普通なので、「うちは収集できますか」ではなく設備1台ごとに判定してください。

通信規格を変えても解決しないものが3つあります。ラダーの中に存在しない値は、どのプロトコルでも読めません。収集周期がスキャン周期より粗ければ、短い停止は原理的に落ちます。装置メーカーの保証条項は、技術ではなく契約の問題です。この3つが、見積が桁で割れる真因であるタグ点数・収集周期・保証という3変数に直結しています。

費用の話をモデル条件で試算しました。ボトルネック8台に絞る案Aは、初期542,000 THB、5年総費用992,000 THB、5年純便益は＋714,667 THB、回収2.16年。全24台に付ける案Bは、初期1,203,000 THB、5年総費用1,818,000 THB、5年純便益は−111,333 THBで赤字、回収5.51年。差は826,000 THBです。効果額は両案とも1,706,667 THBで同じなので、この差はそのまま費用の差です。

分けているのは通信規格でもPLCメーカーでもなく、その設備が止まったときに、それが本当に売上の損失になるかどうかだけでした。非ボトルネック16台の停止短縮を効果額に足さなかった理由も同じです。足せば稟議は通りやすくなりますが、稼働後の実績と合いません。

同時に、絞れば絞るほど良いわけでもありません。ボトルネックが4台だった場合、初期390,000 THBに対して回収は3.87年で、8台の2.16年より遅くなります。収集サーバの180,000 THBという固定費が残るためです。固定費を薄めるのに足る件数が集まる範囲まで絞る、というのが正確な言い方になります。

前提が変われば結論も変わります。停止1時間あたりの逸失利益が3,200 THBから1,600 THBになれば、案Aの回収も6.72年に伸びて成立しなくなります。短縮が20分ではなく10分にとどまった場合も、効果は同じ170,667 THB/年に着地します。だからこそ、最初にやるべきは見積を3社から取ることではなく、過去12か月の停止記録を設備別に集計し、そのうちどれが出荷数量の減少につながったかを分けることです。この表1枚があれば、どの設備に付けるかは機械的に決まります。

どの経路を通るか、どの設備を対象にするかは、盤の中身と停止の実績を見ないと判断できません。TOMAS TECHはバンコクを拠点に、日系製造業の工場IT・OT/IoT・FA領域を支援しています。PLCの機種選定や見積の前段階、つまり「どの設備がどの経路になり、欲しい変数がラダーの中にあるのか」を1台ずつ切り分けるところからご相談いただけます。装置メーカーへの確認事項の整理や、既設盤のスペース・電源の下見も含めて、現場の状況に合わせて進めます。ご相談はお問い合わせページからどうぞ。

参考情報

1. OPC Foundation「Field Level Communications Corner（2026年6月）」— OPC UA FX の C2C 完成と C2D 拡張の準備状況、IOPイベントとSPS 2026 に向けた動き

https://opcconnect.opcfoundation.org/2026/06/field-level-communications-corner-june-2026/

1. EMQ「A Comparison of IIoT Protocols — MQTT Sparkplug vs OPC UA」／ HiveMQ「IIoT Protocols — OPC UA, MQTT, Sparkplug Comparison」— Sparkplug のトピック名前空間・型付きペイロード・birth/death 証明書と、OPC UA との役割分担

https://www.emqx.com/en/blog/a-comparison-of-iiot-protocols-mqtt-sparkplug-vs-opc-ua ／ https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/

1. Trout Software「Real-time PLC Data Streaming — OPC UA, Modbus and Modern Integration Patterns」— Modbus のポーリングとブロック読み出し、シリアルの速度上限、OPC UA のサブスクリプション

https://www.trout.software/blog/real-time-plc-data-streaming-opc-ua-modbus-and-modern-integration-patterns

1. Xinhua（2026年7月27日）— タイ製造業生産指数（MPI）2026年6月 −3.10%、第2四半期 −1.79%、平均設備稼働率 57.47%（出所はタイ工業省・産業経済局）

https://english.news.cn/20260727/f8b7ceb202d04b1f8facbcbf44ed60ce/c.html

1. Mahanakorn Partners Group「Thailand Approves New Tax Incentive to Accelerate SME Digital Transformation」— depa 200%損金算入の対象者・上限300,000 THB・depa登録要件・2027年12月31日の期限

https://mahanakornpartners.com/thailand-approves-new-tax-incentive-to-accelerate-sme-digital-transformation/

1. JETRO ビジネス短信（2025年7月）— タイの最低賃金、バンコク都および工業地帯で日額400バーツ

https://www.jetro.go.jp/biznews/2025/07/b21007a1ac8f7fca.html

1. World Bank「Thailand Economic Monitor February 2026 — Advanced Green Manufacturing for Growth」

https://www.worldbank.org/en/country/thailand/publication/thailand-economic-monitor-february-2026-advanced-green-manufacturing-for-growth

1. タイ産業経済局（OIE）Industrial Indices — MPI の一次配信元

https://www.oie.go.th/view/1/industrial_indices/EN-US