公開2026.08.04更新2026.09.20 20 人が閲覧（直近 30 日）プロトコル

Modbusとは？RTUとTCPの違い・レジスタとファンクションコードを実装目線で解説

Modbusは、PLCや電力計、温調器といった現場機器から値を読み書きするための産業用プロトコルです。仕様が無償で公開されていて実装に許諾が要らないため、1979年の登場から今も新製品に載り続けています。この記事では、マスタ・スレーブの要求応答モデル、コイルと保持レジスタという四つのデータモデル、ファンクションコードと例外コード、RTU・ASCII・TCPの通信仕様の違い、RS-485の配線とタイムアウト設計、RTU-TCP変換ゲートウェイの選定、OPC UAやMQTTとの棲み分け、IoTゲートウェイでのポーリング設計までを、収集システムを設計できる粒度で整理しました。数値はModbus Organizationの公開仕様と実装ライブラリの公開情報から取っています。

まとめ：Modbusの守備範囲とRTU・TCPの選び分け、OPC UAとの併用境界

Modbusが決めているのは「どのアドレスの16ビット値を読むか書くか」だけです。単位も型もスケールも仕様には含まれません。1.5という値がkPaなのか℃なのか、100倍された整数なのかは、機器メーカーのレジスタマップ側にあります。この非対称が、Modbus案件の工数を決めます。

RTUとTCPの選び分けは、機器側が持っている口で決まります。RS-485しか出ていない既設機器はRTU、Ethernetポートを持つ機器はTCP。両方を持つなら収集点数が多い側をTCPに寄せると周期の余裕が出ます。Modbus/TCPの既定ポートは502です。既設のRS-485機器をEthernet側へ載せたいときは、機器を入れ替える前にRTU-TCP変換ゲートウェイを挟む案を先に検討してください。

設計で先に固めるのは、スレーブアドレスの割り当て、終端抵抗と極性バイアスの入れ方、応答タイムアウトとターンアラウンド遅延の二つの時間、この三点です。ここが決まっていないと、机上で成立した周期が現場で崩れます。

OPC UAとの併用は、層で切ると迷いません。現場機器との1対1はModbus、ゲートウェイから上位への送信は情報モデルを持つOPC UAかMQTT。センサー側を軽い要求と応答で読みたいなら、CoAP（IoTプロトコル）の仕組みとMQTTとの違いも並べて比べられます。Modbusを広域ネットワーク越しに直結させる設計は、認証も暗号化も仕様に無いため取りません。収集した先で何を作るかまで含めて相談したい場合は、AI/IoTソリューションで扱っている構成例が判断材料になります。

Modbusの定義とマスタ・スレーブ方式で1往復ごとに完結する通信の仕組み

Modbusは、OSI参照モデルの第7層に位置するアプリケーション層のメッセージングプロトコルです。物理層を規定しないため、RS-232でもRS-485でもEthernetでも同じ命令体系が通ります。工場で使われる通信規格全体の中でModbusがどこに位置するかは、産業用ネットワークとは？フィールドバスと産業用Ethernetの分類・規格選定を実装目線で解説で分類軸ごとに整理しています。国内の製造業で通信標準化がどう進んだかという流れは、ORiNの誕生と歩み：製造業界の通信標準化の起源と変遷にまとめました。

1979年のModicon製PLC由来という出自と仕様公開による普及の経緯

Modicon社が自社PLC向けに定めた通信手順が原型です。仕様書が誰でも入手でき、実装にライセンス料が発生しない状態が続いたため、PLCメーカー以外の計測器・インバータ・電力量計メーカーが自社製品に載せました。仕様の管理は現在 Modbus Organization が担っています。

中心となる MODBUS Application Protocol Specification は V1.1b3（2012年4月26日）、シリアル線向けの MODBUS over Serial Line Specification and Implementation Guide は V1.02（2006年12月20日）が最新版です。Ethernet側の実装指針は MODBUS Messaging on TCP/IP Implementation Guide V1.0b が担当します。10年以上更新が止まっているのは放置ではなく、追加すべき機能が無い状態を示します。

問い合わせた側だけが発話権を持つ半二重の要求応答モデルと設計制約

通信を始められるのはマスタ（クライアント）だけです。スレーブ（サーバ）は聞かれたときにしか答えません。センサ側で異常を検知しても、自分から通知を送る手段がプロトコルに存在しない、ということです。

この制約が設計に効きます。異常検知の遅れは、そのままポーリング周期の長さになる。5秒周期の系で瞬間的なアラーム接点が0.5秒だけONになれば、その事象は取りこぼされます。イベントを確実に拾いたいなら、機器側のラッチ機能（一度立ったビットを読み出すまで保持する設定）を使うか、Modbus以外の経路を併設するかの二択です。なお Modbus Organization は2020年7月に master/slave 表記を client/server 表記へ改めています。本記事では機器マニュアル側の表記に合わせ、マスタ・スレーブで通します。

コイル・入力ステータス・入力レジスタ・保持レジスタの4種類の使い分け

Modbusのデータモデルは四つだけです。ビット単位が二つ、16ビット単位が二つ、それぞれ読み出し専用と読み書き可能に分かれます。

種別	単位	アクセス	典型的な割り当て
入力ステータス	1ビット	読み出しのみ	接点入力・稼働状態
コイル	1ビット	読み書き	出力接点・運転指令
入力レジスタ	16ビット	読み出しのみ	測定値・カウンタ
保持レジスタ	16ビット	読み書き	設定値・しきい値

実務で触る割合は保持レジスタが圧倒的です。読み出し専用のはずの測定値まで保持レジスタに載せている機器が多く、種別から用途は判断できません。設計時はレジスタマップの記載を正とし、種別を推測で決めないでください。32ビットの積算値は16ビットレジスタ2本にまたがるため、上位ワードと下位ワードのどちらが先に並ぶか（ワードオーダ）の確認も必要になります。

ファンクションコードと例外コード・アドレス指定でつまずく実装上の規則

要求フレームの2バイト目に入る1バイトの数値が、その通信で何をするかを決めます。ここを間違えると、例外応答が返るか、無言でタイムアウトします。

実装で使う主要ファンクションコード8種と読み書き対象の対応表

公開ファンクションコードは20種類ほどありますが、収集システムで実際に使うのは次の8種類に収束します。

コード	名称	対象	数量上限
01	Read Coils	コイル	2,000点
02	Read Discrete Inputs	入力ステータス	2,000点
03	Read Holding Registers	保持レジスタ	125本
04	Read Input Registers	入力レジスタ	125本
05	Write Single Coil	コイル1点	1点
06	Write Single Register	保持レジスタ1本	1本
15	Write Multiple Coils	コイル	1,968点
16	Write Multiple Registers	保持レジスタ	123本

まず押さえるのは03と04の2種類です。監視だけの案件はこの2つで完結します。書き込みを含む案件では、単発の06と一括の16を使い分けます。複数の設定値が同時に切り替わらないと機器が中途半端な状態になるケースは、06を並べずに16で一括送信してください。

PDU253バイトと保持レジスタ125個という1トランザクションの上限

Modbusのプロトコルデータユニット（PDU）は253バイトが上限です。シリアル線上のフレーム全体（ADU）はスレーブアドレス1バイトとCRC2バイトが付いて256バイト、TCPではMBAPヘッダが付いて260バイトになります。

この253バイトから逆算した結果が、FC03の125レジスタという上限です。300点を一度に読む要求は仕様上作れません。実装側では読み出し範囲を125本以内のブロックに区切り、連続要求を投げます。分割数がそのまま往復回数になるため、必要な値が飛び飛びに配置されている機器ほど収集周期が伸びます。

例外コード02・03が返る原因と4xxxx表記と0始まりアドレスのずれ

例外応答は、ファンクションコードの最上位ビットを立てた値（03なら0x83）と1バイトの例外コードで返ります。現場で遭遇するのはほぼ02と03です。

02（Illegal Data Address）は、要求したアドレス範囲が機器の持つ範囲を外れたときに返ります。原因の大半はアドレス表記のずれです。機器マニュアルの「40001」という表記は保持レジスタの1本目を指す伝統的な記法で、通信フレームに載せる番号は0になります。40001を指定して02が返るのは正常な動作です。マニュアルが0始まりか1始まりかは製品ごとに違います。03（Illegal Data Value）は、数量が上限を超えた場合や、書き込む値が機器の許容範囲外の場合に返ります。

Modbus RTU・ASCII・TCPの通信仕様の違いと物理層から決める選定

命令体系は共通で、変わるのは包み方だけです。RTUはバイナリ、ASCIIは文字列、TCPはEthernetフレームに載せます。

RTUの3.5文字サイレントインターバルとCRC16によるフレーム区切り

RTUにはフレームの開始を示す記号がありません。3.5文字分の無通信時間が空いたら次のフレームが始まる、という時間ベースの区切りです。文字間の間隔は1.5文字時間以内に収める規定もあります。

ここで実装者が取り違えやすいのが、この2つの時間を常に計算で出すという思い込みです。Serial Line 仕様 V1.02 は、19200 Bps 以下では t1.5 と t3.5 を厳密に守り、19200 Bps を超える速度では固定値を使うことを推奨しています。固定値は t1.5 が750マイクロ秒、t3.5 が1.750ミリ秒。高速側で文字時間から計算し続けると割り込みが増えてCPUを食うため、規格側が上限を切った格好です。

この時間依存が、USBシリアル変換器で問題を起こします。USBは転送をまとめてバッファリングするため、送信側で意図した3.5文字の無通信が受信側で潰れ、隣接する2フレームが1つに見えることがあります。長時間の連続収集で「たまにCRCエラーが出る」現象の典型的な原因です。産業用のシリアルボードを使うか、変換器のレイテンシタイマ設定を詰めるかで対処します。誤り検出はCRC16（多項式0xA001）です。

スレーブアドレス0と1〜247・RTUフレーム構成をバイト単位で追う

RTUのフレームは、先頭1バイトのスレーブアドレス、1バイトのファンクションコード、可変長のデータ部、末尾2バイトのCRC16という並びです。アドレス空間は256個ありますが、全部が使えるわけではありません。

アドレス	用途	応答
0	ブロードキャスト	返らない
1から247	スレーブ個別	返る
248から255	予約	割り当て不可

アドレス0は全スレーブ宛の一斉送信で、書き込み系のファンクションコードだけに意味があります。応答が返らない設計なので、送った側は成功も失敗も知りません。複数台の設定値を同時に揃えたい場面以外では使わないでください。個別アドレスは1から247で、248以降は予約されています。設計時に250や255を割り振ると、機器によっては無視されます。

読み出し要求の実バイト列は、スレーブ1番の保持レジスタ0番から20本を読む場合で「01 03 00 00 00 14 CRC下位 CRC上位」の8バイトです。応答は「01 03 28 データ40バイト CRC2バイト」の45バイト。要求8バイト、応答は3バイト＋レジスタ数×2バイト＋CRC2バイト、という形で数えると周期の見積りが機械的にできます。ブロードキャストとユニキャストの違い、アドレス範囲の規定はいずれも Serial Line 仕様 V1.02 の記述です。

TCPのMBAPヘッダとポート502・トランザクション識別子の扱い

Modbus/TCPでは、TCP層の再送と検査を使うためフレーム末尾のCRCが消え、先頭へ7バイトのMBAPヘッダが付きます。内訳はトランザクション識別子2バイト、プロトコル識別子2バイト、長さ2バイト、ユニット識別子1バイトです。

実装で効くのはトランザクション識別子です。RTUと違い応答を待たずに次の要求を送れる（パイプライン化できる）ため、どの応答がどの要求に対応するかをこの2バイトで突き合わせます。ただし機器側の同時受け付け数は製品ごとに違い、4接続や8接続で頭打ちになるものが珍しくありません。既定ポートは502、TLSで包む Modbus Security Protocol は802を使います。

RS-485の1セグメント32台・終端抵抗という物理層側の制約

RTUで使うRS-485は、1本のペア線に複数のスレーブをぶら下げるマルチドロップ構成です。リピータ無しで32台までは仕様上つねに許容され、超えるならリピータかセグメント分割が要ります。ユニット負荷の小さい受信器を使う機器なら32台を超える構成も組めますが、混在させると計算が合わなくなるため、初期設計では32台を上限に置くほうが安全です。

観点	Modbus RTU	Modbus ASCII	Modbus TCP
物理層	RS-485・RS-232	RS-485・RS-232	Ethernet
区切り	3.5文字の無通信	コロンとCR・LF	MBAPヘッダ長
誤り検出	CRC16	LRC	TCP層に依存
効率	高い	約半分	高い
並列要求	不可	不可	可能

ASCIIモードは1バイトを16進2文字で送るため、実効速度がRTUの半分になります。選ぶ理由は、文字間に最大1秒の遅延が許容される点だけです。遅延が読めない経路でのみ検討し、通常はRTUを選んでください。ケーブル長は、AWG24のツイストペアで最大1000m、Cat5ケーブルなら600mが仕様上の目安になります。

Modbus RTUの配線設計と2種類のタイムアウト値の決め方・CRCエラーの切り分け

Modbus RTUで最も時間を溶かすのは、プロトコルの誤解ではなく配線とタイムアウトです。ここは仕様書に数値が書いてあるので、勘で決める必要がありません。

終端抵抗150Ωと極性バイアス450〜650Ωを1箇所で入れる配線規定

RS485-MODBUSは、幹線（トランク）の両端に終端を入れ、機器は短い分岐（スタブ）でぶら下げます。Serial Line 仕様が示す終端抵抗は、D0とD1の間に入れる150Ω・0.5Wです。極性バイアスを併用する構成では、1nF・10V以上のコンデンサと120Ω・0.25Wの抵抗を直列にしたほうが良い、という書き方になっています。現場で「120Ωを入れる」と言われるのはこの後者の形で、単体の120Ω抵抗とは別物です。

極性バイアス（ラインポラライゼーション）は、誰も送信していない無通信時に受信器の状態を固定するための仕掛けです。D1側を5Vへプルアップ、D0側をコモンへプルダウンし、抵抗値は450Ωから650Ωの範囲に収めます。650Ω寄りにすると接続できる台数が増えます。押さえるべきは入れる場所で、バス全体で1箇所だけに入れる規定です。機器ごとにDIPスイッチでバイアスを有効化できる製品が多く、複数台でONにしてしまうと合成抵抗が下がって信号が潰れます。通信が不安定な既設系を引き継いだときは、まず全機のバイアス設定を見て回ってください。

配線側でもう一点、RS-485のA・B表記は製品間で逆になっていることがあります。仕様上の名称はD0とD1で、D1が非反転側です。A・Bと書かれた端子を信じて結線し、無応答が続くなら2本を入れ替えて試すのが早道になります。

応答タイムアウトとターンアラウンド遅延を分けて初期値を決める

RTUで設定する時間は二つあり、役割が違います。応答タイムアウト（Response time-out）はマスタが応答を待つ上限、ターンアラウンド遅延（Turnaround delay）はブロードキャスト送信後に次の要求を出すまでマスタが空ける間隔です。

Serial Line 仕様が挙げる典型値は、9600bpsで応答タイムアウトが1秒から数秒、ターンアラウンド遅延が100から200ミリ秒。そしてターンアラウンド遅延は応答タイムアウトより短く、という関係が明示されています。ブロードキャストには応答が返らないぶん、スレーブが処理を終える時間だけ待てば足りるためです。

項目	初期値の目安	詰めすぎた場合
応答タイムアウト	1秒	遅い機器を取り逃す
ターンアラウンド遅延	100ミリ秒	一斉設定が抜ける
リトライ回数	2回	一過性ノイズで欠測
フレーム間ギャップ	t3.5準拠	フレーム結合が起きる

実装では、この値をクライアント生成時に渡します。Python側の事実上の標準である pymodbus は、既定でタイムアウト3秒・リトライ3回なので、そのままだと不調な1台が系全体の周期を3秒単位で引き延ばします。台数が多い系では明示的に短くしてください。

from pymodbus.client import ModbusSerialClient

client = ModbusSerialClient(
    port="COM3",
    baudrate=19200,
    bytesize=8,
    parity="E",
    stopbits=1,
    timeout=1.0,
    retries=2,
)
client.connect()

rr = client.read_holding_registers(address=0, count=20, device_id=1)
if rr.isError():
    print("例外応答またはタイムアウト:", rr)
else:
    print(rr.registers)

client.close()

パリティは既定でNoneのライブラリが多い一方、機器側の出荷時設定はEven（偶数パリティ）であることが珍しくありません。ボーレート・バイト長・パリティ・ストップビットの4点は、機器の設定画面を見て一つずつ合わせます。

CRCエラーが続くときにボーレートと配線のどちらから疑うかの順序

CRCエラーは「フレームは届いたが中身が壊れている」という状態です。無応答とは切り分けの手順が別になります。無応答ならアドレスと通信パラメータ、CRCエラーなら物理層とタイミング、という振り分けから入ってください。

順序としては、まず発生頻度を見ます。特定の1台だけで出るなら、その機器の分岐線が長すぎるか、バイアス設定が重複しているかのどちらか。全台でまばらに出るなら、終端抵抗の欠落、ケーブル長の超過、インバータなど強いノイズ源との並走を疑います。時間帯によって出方が変わるなら、動力系の稼働との相関を取ると当たりが早いです。

頻度に偏りが無く、ボーレートを下げると消える場合は、USBシリアル変換器のバッファリングかt3.5の扱いが原因である公算が高くなります。19200bpsを超える設定なら、固定値（t3.5は1.750ミリ秒）を使う実装になっているかを確かめてください。切り分けには、アプリケーションを止めてコマンドライン側から素の要求を投げるのが確実です。

# 1台だけを対象に、保持レジスタ0番から20本を連続で読む
mbpoll -m rtu -b 19200 -P even -d 8 -s 1 /
       -a 1 -t 4 -r 1 -c 20 -l 500 /dev/ttyUSB0

# ボーレートを落として再現するかを見る
mbpoll -m rtu -b 9600 -P even -a 1 -t 4 -r 1 -c 20 /dev/ttyUSB0

この2本で結果が変われば速度側、変わらなければ配線側という切り分けになります。アプリケーション側のログにも、スレーブアドレス・ファンクションコード・レジスタ先頭番号・例外コードの4点を残しておくと、後からの突き合わせが速くなります。

Modbus RTUとTCPをつなぐ変換ゲートウェイの選定基準と設定の実際

既設のRS-485機器をEthernet側の収集基盤へ載せる案件では、機器の入れ替えより変換器を挟むほうが安く済みます。ただし製品の呼び名が近く、中身が違うものが混ざっているため、選定を間違えると後から詰みます。

プロトコル変換型とシリアルデバイスサーバ型の違いと選び分け方

市場にある変換器は、大きく二系統に分かれます。ひとつはModbus RTUのフレームを解釈してModbus/TCPへ組み直すプロトコル変換型（Modbusゲートウェイ）。もうひとつはシリアルポートをTCPソケットへそのまま橋渡しするシリアルデバイスサーバ型で、こちらはModbusの中身を見ません。

観点	プロトコル変換型	デバイスサーバ型
フレーム	MBAPへ組み直す	素通し
上位の実装	Modbus/TCPで書く	RTUのまま書く
同時接続	複数マスタを調停	基本1接続
CRC	変換器が付け外し	上位が計算
t3.5の扱い	変換器が担保	上位任せで崩れる

収集基盤を新しく作るならプロトコル変換型を選んでください。上位のコードがModbus/TCPの素直な実装で済み、t3.5のタイミングを変換器側が引き受けます。デバイスサーバ型が向くのは、既存のWindowsアプリが仮想COMポート経由でRTUを話していて、その資産を変えられない場面に限定した選択肢です。この場合、フレーム間の時間がEthernet経由で崩れやすく、前述のCRCエラーが出やすくなる点は織り込んでおく必要があります。

スレーブIDとユニット識別子の対応づけをゲートウェイ側で設計する

プロトコル変換型で最初に決めるのが、Modbus/TCPのMBAPヘッダにあるユニット識別子1バイトと、シリアル側のスレーブアドレスをどう結ぶかです。設計は二通りあります。

ひとつは素直にユニット識別子＝スレーブアドレスとする対応づけ。シリアル1系統に対して変換器1台という構成なら、これが一番わかりやすい形になります。もうひとつは、変換器が複数のシリアルポートを持つ場合に、IPアドレスとポート番号で系統を分け、ユニット識別子はポート内のスレーブアドレスに割り当てる方式です。後者は1台の変換器に32台を超える機器をぶら下げるときに使います。

from pymodbus.client import ModbusTcpClient

# 変換ゲートウェイのIPへ接続し、ユニット識別子で機器を切り替える
gw = ModbusTcpClient("192.168.10.20", port=502, timeout=1.0, retries=2)
gw.connect()

for unit in (1, 2, 3):
    rr = gw.read_input_registers(address=100, count=10, device_id=unit)
    if rr.isError():
        print("unit", unit, "応答なし", rr)
        continue
    print("unit", unit, rr.registers)

gw.close()

注意点はユニット識別子0の扱いです。Modbus/TCPでは、経路上に変換器が無い機器に対して0や255を指定する運用が混在しており、製品ごとに解釈が割れます。変換器を挟む構成では0を避け、1から247の範囲で明示的に割り当ててください。取得できるかどうかは実機で1台ずつ確認するのが確実です。

変換を挟んだ後に遅延と同時接続数で詰まる箇所への現実的な対処

変換器を入れた直後は動くのに、点数を増やすと破綻する。これが最も多い失敗です。原因は二つに絞られます。

ひとつめは遅延の積み上がりです。Modbus/TCPは応答を待たずに次の要求を出せますが、変換器の先はシリアル1本なので、結局は順番待ちになります。上位から10本の要求を同時に投げても、シリアル側では1本ずつ処理されるため、10本目の応答は9往復分遅れて返る。上位のタイムアウトを1秒に詰めていると、後ろの要求から順に落ち始めます。対処は、上位側で同時発行数を1か2に制限し、タイムアウトはシリアル側の往復時間×同時発行数から逆算することです。

ふたつめは同時接続数です。変換器のTCP接続上限は4や8で頭打ちになる製品が多く、収集サーバと保守用PCとSCADAが同時につなぐと枯渇します。監視制御層をどう組むかはSCADAとは？スキャダの仕組みとPLC・DCS・MESとの役割分担を実装目線で解説で整理していますが、Modbus側の結論としては、収集経路を1本に集約してゲートウェイから先へ配る構成が安全です。複数の上位が直接ポーリングする形は、台数が増えた時点で必ず詰まります。

意味情報を持たないModbusとOPC UA・MQTTの棲み分けの決め方

Modbusを何に置き換えるか、という問いは立て方が違います。置き換えではなく、どの層で使うかの切り分けです。

レジスタ番号だけが渡るModbusと型と単位を運ぶOPC UAの差

Modbusのフレームが運ぶのは、アドレスと16ビットの生値だけです。受け取った側は、そのレジスタが何を意味するかを知りません。機器を1台追加するたびに、レジスタマップから係数と単位を書き写す作業が発生します。

OPC UA（IEC 62541）はここが違います。ノードごとに型・単位・アクセス権・親子関係を情報モデルとして持ち、クライアントは接続後にサーバをブラウズして構造を取得できます。機器追加時の実装が減るのは、この自己記述性によるものです。ただしサーバ実装を持つ機器は限られ、既設のインバータや電力計はまずModbusしか話しません。現実解は、現場側をModbusで読み、ゲートウェイでOPC UAサーバとして再公開する構成になります。

現場側はModbus・上位はMQTTという層で分ける収集構成の型

クラウドへ値を上げる案件では、ゲートウェイから先をMQTTにする構成が定番になっています。中継する機器そのものの要否や産業用と汎用の選び分けはIoTゲートウェイとは？プロトコル変換の役割とクラウド直結との使い分けにまとめました。Modbusのポーリングで集めた値を、変化があったときだけMQTTでPublishする形です。

この構成の利点は通信量です。1秒周期で100点をポーリングしても、変化した点だけを上位へ送れば、上りの帯域は実際の変動量に比例します。しきい値超過の瞬間だけQoS 1で送り、定常値はQoS 0で間引く制御もできます。ゲートウェイから上の設計はMQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装からHTTPとの使い分けまで実装者向けに解説を参照してください。どこまでを現場側で処理するかの線引きは、エッジコンピューティングとは？仕組み・クラウドとの違いから導入判断までわかりやすく解説の判断軸が使えます。小規模な試験導入で可視化だけ先に立ち上げたいなら、Ambient（アンビエント）とは？IoTセンサーデータを可視化するクラウドサービスの使い方を解説のような既成サービスへ送る手もあります。

IoTゲートウェイでのModbus収集実装とポーリング設計の注意点

Modbus案件が失敗する箇所は、プロトコルの理解ではなく周期設計に偏ります。机上で1秒周期と決めた系が、現場では3秒かかる、という形で出ます。

1秒周期が成立するかをボーレートとレジスタ本数から見積もる手順

RTUの1トランザクションに必要な時間は、要求と応答のバイト数から計算できます。9600bpsで8データビット・パリティ無し・ストップ1なら、1バイトは約1.04ミリ秒です。

1トランザクションのバイト数を数える（要求8バイト＋応答は3＋レジスタ数×2バイト）
バイト数×10ビット÷ボーレートで伝送時間を出す
3.5文字分の待ち時間（9600bpsで約4ミリ秒）を前後に加える
スレーブの応答遅延（機器仕様値・数ミリ秒から数十ミリ秒）を足す
ブロック数×台数を掛け、目標周期の7割以下に収まるか確認する

9600bpsで20レジスタを読む1往復は、待ち時間と応答遅延を含めて100ミリ秒前後です。20台をぶら下げれば2秒。この時点で1秒周期は成立しません。対処は、ボーレートを19200や38400へ上げる、レジスタを連続配置して読み出しブロック数を減らす、系統を分けてシリアルポートを増やす、の3つになります。余裕を7割に置くのは再送1回分を吸収するためです。

pymodbus 3.15系での実装とタイムアウト・リトライの初期値

Python実装では pymodbus が事実上の標準で、PyPI上の最新版は 3.15.0（2026年8月13日公開・Python 3.10以上）です。同期版と非同期版の両方のクライアントを持ち、シリアルとTCPを同じインタフェースで扱えます。バージョン間で引数名が変わっており、スレーブ指定は現行系で device_id、旧系では slave でした。公式ドキュメントの該当ページで引数名を確かめてから書いてください。

初期値として置くのは、タイムアウト1秒・リトライ2回・リトライ間隔は指数的に伸ばす、という組み合わせです。短く詰めすぎると応答の遅い機器で正常な応答を取りこぼし、長すぎると1台の不調が全体の周期を引き延ばします。連続失敗が一定回数を超えた機器はポーリング対象から一時的に外し、間隔を空けて復帰確認する仕組みを入れてください。これが無いと、電源を落とした1台のために系全体の周期が崩れます。ログにはスレーブアドレス・ファンクションコード・レジスタ先頭番号・例外コードの4点を残します。

認証も暗号化も持たない仕様を前提にしたネットワーク分離の設計方針

Modbusには、認証の仕組みも暗号化も定義されていません。ポート502に到達できる者は、誰でもコイルを書き換えられます。TLSで包むModbus Security（ポート802）は仕様として存在しますが、対応機器は限られます。

現実的な防御はネットワーク分離です。制御系セグメントをOAネットワークから分け、ゲートウェイだけを両側に足を持つ位置に置き、上りはMQTTやHTTPSの片方向に寄せる。Modbus/TCPを外部から直接叩ける経路は作らない、という設計になります。VPN越しにポート502を通す構成は、経路が暗号化されていても機器側に認証が無いため、内部に入られた時点で守るものが残りません。書き込み系ファンクションコード（05・06・15・16）をゲートウェイ側でブロックする運用も併せて有効です。

Modbusを採用してよい条件と、載せ替えを選ぶべき場面の切り分け

ここは判断を言い切ります。Modbusは古いから避けるべき、という結論にはなりません。条件を満たすなら第一候補です。

既設機器がModbusしか持たない場合に採用を決めてよい三つの条件

次の三つが揃えば、Modbusで組んで問題ありません。収集点数が1系統あたり数百点以内であること、要求される周期が秒オーダーであること、収集が読み出し中心で書き込みが設定変更程度に留まること。

この範囲なら、実装コストは他の選択肢より確実に低く収まります。仕様が枯れていて実装スタックが安定しており、機器メーカー側のサポートも厚い。ライセンス費用も発生しません。既設機器がModbusしか持たない状況で、OPC UA対応のゲートウェイ機器へ入れ替える判断は、点数と周期が上の条件に収まる限り過剰です。RS-485のままEthernet側へ出したいだけなら、変換ゲートウェイで足ります。

イベント駆動と数千点規模でModbus直結を見送るべき典型的な失敗例

逆に、次の場面ではModbus直結を採りません。ミリ秒単位のイベントを取りこぼせない要件、1系統で数千点を超える規模、機器ごとの型情報をシステム側で自動認識したい要件、そしてインターネットや広域網を越える経路。

典型的な失敗は、点数が増えた後に周期が破綻するパターンです。試験導入では5台20点で快調に動き、本番で60台600点に増やした途端に周期が10秒を超え、アラーム検知が用をなさなくなる。往復回数は台数に比例して増えるため、この破綻は必ず起きます。導入時点で最終台数を前提に周期を計算し、成立しないならシリアル系統の分割かTCP機器への置き換えを設計へ織り込んでください。「まず小さく始めて後で拡張」という進め方が、Modbusでは最も危険です。

収集基盤の設計と実装を外部に任せるかを分ける社内体制の判断目安

内製で回せるかは、レジスタマップを読める人が社内にいるかで決まります。プロトコル自体は半日で理解できる規模ですが、機器ごとのスケール係数・ワードオーダ・ラッチ仕様を読み解く作業は台数だけ発生します。

目安として、対象機器が3メーカー以内で点数が100点程度なら内製で足ります。メーカーが5社を超える、既設機器の仕様書が散逸している、収集した先でダッシュボードや異常検知まで作る。いずれかに当てはまるなら外部の設計を入れたほうが速く済みます。当社のAI/IoTソリューションでは、現場機器からの収集経路の設計と、集めたデータを扱うシステムの開発を一続きで請け負っています。

よくある質問

Modbusの実装検討でよく挙がる質問を、判断に直結する順で並べました。

Modbus通信とは何ですか？普通のTCP通信と何が違いますか？

Modbus通信は、産業機器のメモリ上のアドレスを指定して16ビット値を読み書きする、1往復で完結する通信です。一般的なTCP通信がバイト列を運ぶ土管であるのに対し、Modbusは「どのアドレスを何本読むか」という意味づけまでを規定します。ただし規定はそこまでで、読んだ値の単位や型は含まれません。Modbus/TCPはこの命令体系をEthernet上のポート502で運ぶ形式で、シリアル線を使うModbus RTUと命令の中身は共通です。

Modbus RTUとModbus TCPはどちらを選べばよいですか？

機器側が持っているインタフェースで決まります。RS-485端子しか無ければRTU、Ethernetポートがあるならその機器はTCPです。TCPは応答を待たずに次の要求を送れるため、多点収集で周期を詰められます。Modbus TCPの通信仕様で押さえるのは、CRCが無くなり先頭に7バイトのMBAPヘッダが付くこと、そのうち1バイトがユニット識別子であることの2点。既設のRS-485機器をEthernet側へ載せたい場合は、Modbus RTU-TCP変換ゲートウェイを挟む方法があり、機器の入れ替えより費用を抑えられます。

Modbusの通信ができないとき、まず何を確認すべきですか？

確認は上位から下位の順で進めます。まずスレーブアドレスが機器の設定値と一致しているか（1から247の範囲か）、次にボーレート・パリティ・ストップビットの3点が完全一致しているか。ここまでで大半が解決します。例外コード02が返る場合は、アドレス表記のずれ（40001と0の関係）を疑ってください。無応答が続くならRS-485のD0・D1の極性反転と終端抵抗の有無を確認します。CRCエラーだけが出るなら、極性バイアスの重複設定と分岐線の長さが先に疑う対象です。

Modbusは古いプロトコルですが、今から新規採用しても問題ないですか？

数百点・秒周期・読み出し中心という条件に収まるなら問題ありません。仕様の更新が2012年で止まっているのは、フィールドバス層として必要な機能が揃っているためです。装置内部の機器間配線そのものを減らしたい場面では、CAN通信のバス構造とID優先度の設計が比較対象になります。国内で流通する計測機器・インバータ・電力量計の多くが今もModbusを標準搭載しており、機器選定の幅が広い点も利点になります。新規に情報モデルを持つ機器群を組む案件なら、最初からOPC UA対応機器を選ぶほうが後の拡張は楽です。

Modbusのセキュリティ対策はどうすればよいですか？

プロトコル側に認証も暗号化も無いため、ネットワーク側で守ります。制御系セグメントを情報系から分離し、ポート502へ到達できる範囲をゲートウェイだけに限定してください。上位への送信はMQTTやHTTPSで片方向に寄せます。TLSを使うModbus Security（ポート802）は対応機器が限られるため、当面はこの分離設計が守りの主軸です。変換ゲートウェイを置く構成なら、書き込み系ファンクションコードを変換器かその手前で落とす運用も併用できます。