IoTとERPの連携とは？階層で決める接続点とERPに入れないデータの線引き

IoTとERPの連携を検討すると、最初に出てくる絵はたいてい「センサー → クラウド → ERP」の三段です。ところが実際に設計を始めると、1秒周期で届く温度や振動をERPのテーブルに書き込む先が無いことに気づきます。ERPが扱うのは作業指示や入出庫といった業務イベントで、単位も周期も保持年数もセンサーデータとは別物だからです。IoTとERPをつなぐ仕事の中身は、データを全部流し込むことではなく、どこで集約してどの粒度でERPへ渡すかを決めることにあります。ISA-95（IEC 62264）の階層定義、OPC UAとMQTTの役割分担、ERP側の受け口が今どこまで実装されているかを一次情報で確かめながら、その線引きを組み立てます。

まとめ：IoTとERPの連携で先に押さえる結論

• ISA-95（ANSI/ISA-95、国際規格ではIEC 62264）はレベル4を「Business planning and logistics（事業計画と物流）」＝ERPの領域、レベル3を「Manufacturing operations management（製造オペレーション管理）」＝MESの領域と定義しています。IoTとERPの間にはレベル3という層が最初から想定されています。
• センサーの生データをERPへ直接書き込む設計は避けます。ERPへ渡すのは判定済みのイベント（停止の発生、検査の合否、完成数量）で、波形や時系列そのものは時系列データベース側に残します。
• 現場データの連携では、OPC UAによる情報モデルの共有と、MQTTによるメッセージ配信を組み合わせる構成があります。OPC UAはIEC 62541シリーズで、Pub/Sub方式を定めるPart 14は2026年1月12日発行の第2版（IEC 62541-14:2026）が現行です。仕様上、MQTTは3.1.1と5.0の両方をトランスポートとして扱えます。
• MQTTはOASIS標準で、バージョン5.0が2019年3月7日にOASIS Standardとして発行されています。ISO/IEC 20922:2016として国際規格化されているのは3.1.1です。
• ERPベンダー純正のIoT機能に全面依存しないでください。Dynamics 365 Supply Chain ManagementのSensor Data Intelligenceは2026年9月時点でもプレビュー扱いで、Azureコンポーネントは利用者自身のサブスクリプションへ配置する方式です。
• IT側とOT側をつなぐ以上、セキュリティは境界の設計が先です。IEC 62443はシステム要件を62443-3-3、機器コンポーネントの要件を62443-4-2に分けて規定し、セキュリティレベルをSL 1からSL 4の4段階で定義しています。

IoTとERPのデータ特性の違い：発生周期・整合性・保存要件

接続点を決める前に、データの発生周期・用途・保存要件を整理します。

右の列は監査に耐える必要があり、左の列に同じ厳密さを求めるとコストだけが増えます。逆に左の列の周期で右の列を更新すれば、在庫や原価の締め処理が追いつきません。連携とは2つを混ぜることではなく、間に変換の層を置いて役割を分けることです。センサー側の保存設計は時系列データベースとは？RDBとの違いと圧縮・保持設計から製品選定までを実装目線で解説で扱っています。

ISA-95の機能階層で見るIoTとERPの役割分担

ISAはISA-95を「ANSI/ISA-95またはIEC 62264としても知られる、物流システムと製造制御システムを統合することを目的とした国際規格群」と説明しており、規格は8つのパートで構成されています。工場を0から4の5階層で整理し、ERPの置き場所を名指ししている点が重要です。

ERPはレベル4、MESはレベル3です。ISA-95はレベル1からレベル4への直接通信を禁じる規格ではありませんが、整理しているのはレベル間でやり取りする情報の中身です。レベル1の測定値がそのままレベル4の業務データになるわけではなく、「どの作業指示に対する実績か」「良品か不良か」という意味づけがどこかで必要になります。中間層を置かない構成を選ぶなら、その意味づけを誰が実装して誰が保守するのかを先に決めてください。IoTとERPの連携が止まる現場は、この担当が決まらないまま、クラウドに貯めた生データをERPの追加テーブルへ書き込もうとしていることが多いです。

階層の番号を使うときは、参照するモデルを明記してください。ISAの解説ページはレベル2を「プログラマブルロジックコントローラ（PLC）、分散制御システム（DCS）その他の制御機器」、レベル3を「製造実行システム（MES）と、製造オペレーションを管理するSCADA等のシステム」と説明しています。一方、OTセキュリティで使われるPurdueモデルでは監視制御（SCADA）をレベル2に置く整理が一般的です。置き場所がモデル間でずれるので、構成図に番号を振るときはどちらに沿ったかを注記しないと、責任分界点の議論が噛み合いません。レベル3側の機能定義はMESシステムとは：製造実行システムの11機能とISA-95レベル3の実装要件、階層ごとのインタフェース設計は製造業のデータ連携｜設備・MES・基幹の階層別インタフェース設計と段階導入で詳しく扱っています。

IoTとERPの連携方式3パターンと選定条件

階層の話を実装に落とすと、ERPへ届けるまでの経路は大きく3つです。選定軸は、変換処理を誰が保守するかと、ERPへ返したい実績の粒度です。

ERP直結：変換処理と保守範囲を限定できる場合の構成

稼働と停止だけを取り、ERPの設備カウンタを更新する、といった用途であれば中間層を作らずに済みます。判断の基準は台数ではなく、ERPのAPIの制約内で更新頻度をさばけること、そして再送・重複排除・単位変換の責任範囲を明確にできることです。これが曖昧なまま接続すると、変換ロジックがERPのアドオンとして増殖し、バージョンアップのたびに回帰テストの対象になります。ERP直結は安いのではなく、後から高くつきやすい選択肢です。

IoTゲートウェイ経由：既設設備のプロトコル変換

既設設備には、シリアル通信やフィールドバス、接点信号など接続方式の異なるものが混在します。プロトコル変換をゲートウェイへ外出しすると、ERP側は変換の事情を知らずに済みます。現場からクラウドへの経路では、OPC UAとMQTTを組み合わせる構成が標準的です。OPC UAのPub/Sub方式はIEC 62541のPart 14が定めており、現行は2026年1月12日発行の第2版（IEC 62541-14:2026）です。IECの規格情報には「この第2版は2020年に発行された初版を取り消して置き換える」と明記されているので、ベンダー資料が初版の内容のままになっていないか確認してください。OPC Foundationの仕様本文はトランスポートとしてのMQTTについて、現在使われているのは3.1.1と5.0の2つのバージョンだと記しています。それぞれの採用判断はOPC UAとは？情報モデルとOPC Classicとの違い・採用判断を実装目線で解説とMQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装からHTTPとの使い分けまで実装者向けに解説、機器選定はIoTゲートウェイとは？プロトコル変換の役割とクラウド直結との使い分けを参照してください。

MQTTの版を選ぶときは、5.0が2019年3月7日にOASIS Standardとして発行されている一方、国際規格ISO/IEC 20922に対応するのは3.1.1である点を押さえます。MQTT 5.0の理由コードや共有サブスクリプションが必要なら、「ISO規格準拠」だけで済ませず、MQTTの版と必要機能を明記します。

MES経由：作業指示と製造実績の照合

ERPへ返すのが完成数量・不良数量・工数といった実績なら、MESを通すのが標準ルートです。ERPが出した製造オーダーに対して、どの設備でいつ何個できたかを紐づける処理はレベル3の役割そのもので、ここを自作するとMESの再実装になります。すでにMESがあるなら、IoTデータはMESへ入れ、ERPとはMESが持つ既存のインタフェースでつなぐのが最短です。

ERPへ連携する業務データと、外部に保存する生データの線引き

ここが連携設計の分かれ目です。結論から言えば、センサーの生データをERPに入れてはいけません。理由は3つあります。

第一に、ERPのデータベースは業務トランザクションの量で見積もられています。1台の設備が1秒周期で値を出せば1日で8万6,400件、20台なら170万件を超えます。このデータ量が締め処理やMRP計算へ与える影響は、DB構成・索引・保持期間によって異なるため、想定負荷で確認します。第二に、ERPのライセンスやストレージ課金は業務データを前提に設計されていることが多く、桁の違うレコードを入れると想定外の費用になります。第三に、ERPのデータは訂正履歴を残す前提で作られているため、後から間引いたり再集計したりする操作と相性が悪いです。

ERPへ渡すのは、値ではなく判断が終わったイベントです。具体的には次の4種類に絞ります。

• 状態の変化：設備が停止した、復旧した。設備ID・イベントID・状態・時刻・理由コードを渡します。
• 数量の確定：完成数、不良数。カウント値そのものではなく、検収ロジックを通した後の数字です。
• 判定結果：検査の合否と不良区分。しきい値や画像は渡しません。
• 閾値超過のアラート：保全オーダーを起票する必要がある事象だけです。

逆に、波形・画像・1分粒度の時系列・デバイスの死活情報はERPへ入れません。これらは時系列データベースやデータレイクに置き、ERPからはキーで参照できるようにしておけば十分です。判断の軸は3つあります。その値が仕訳・在庫・原価を動かすか。品質管理や設備保全の業務画面で日常的に参照するか。証跡として保存年限の要件がかかるか。1つ目に当たるものは必ずERPへ入れ、2つ目はERPの品質管理・設備管理モジュールに受け皿があるかを確認してから決め、3つ目は改ざん防止・検索・監査対応まで含めた総費用で保存先を比べます。

この線引きを最初に決めておかないと、PoCで作った「全部ERPに入れる」構成がそのまま本番に残ります。保持期間や容量上限を超えたときに、性能低下や書き込み停止につながるおそれがあります。PoCの範囲設計についてはスマートファクトリーのIoT構成｜測る・運ぶ・ためる・返すの4ブロックと発注仕様の決め方が具体的です。

ERP側の受け口の実態：Dynamics 365のIoT連携シナリオと提供条件

「ERPがIoTに対応している」という説明は、実際には何を指すのか。一次情報で確認できる例として、Microsoft Dynamics 365 Supply Chain ManagementのSensor Data Intelligenceを見ます。公式ドキュメントはこれを、IoT Intelligence機能がバージョン2.0へ更新されると同時に改称されたものと説明し、旧IoT Intelligenceを基盤にした新規プロジェクトを始めないよう推奨しています。用意されているシナリオは6つです。

並べてみると、ERPが受け取っているのは前節で挙げた状態変化・数量確定・判定結果・アラートと、センサー値に基づく設備カウンタの更新です。センサーの値そのものを貯める機能はここに含まれていません。ERPベンダーが実装しているのも、生データの受け皿ではなく業務イベントの受け口だと確認できます。

もう1つ、導入計画に直結する事実があります。この機能は2026年9月時点でもプレビュー扱いで、公式ドキュメントには「これはプレビュー機能です。プレビュー機能は本番利用を意図したものではなく、機能が制限されている場合があります」と明記されています。Azureコンポーネントも利用者自身のサブスクリプションへ配置する方式です。ERPの標準機能だけでIoT連携が完結する前提で稟議を書くと、Azure側の設計・運用・課金が丸ごと自社負担で残ります。なお削除・非推奨機能の一覧（2026年6月24日付）にこの機能の記載はなく、廃止が決まったわけではありません。

ここから導ける設計方針は1つです。データの集め方と貯め方はERPベンダーに依存しない層で作り、ERPとの接点はイベントを渡すインタフェース1枚に絞る。製品名や提供条件が変わったときに、作り直す範囲を接点だけに限定できます。ただし分離しておけば移行がただになるわけではないので、認証方式・データモデル・運用手順の移行範囲と、契約終了時にデータをどう取り出すかは導入前に確認してください。

IoTとERPをつなぐときのセキュリティ境界とゾーン設計

IT側とOT側を接続するときは、インターネット接続の有無にかかわらず、ネットワーク境界と許可する通信を設計します。IEC 62443は要件を対象ごとに分けており、IECの解説ではシステム全体の技術要件を規定するのが62443-3-3、組込み機器・ネットワーク機器・ホスト・ソフトウェアといったコンポーネントの技術要件を規定するのが62443-4-2（IEC 62443-4-2:2019）とされています。到達目標となるセキュリティレベルは、想定する攻撃者の能力で4段階に分かれます。

IoTとERPをつなぐ案件で最初に決めるのは、どのゾーンをどのSLで守るかです。IEC 62443-3-2はゾーンとコンジットを定義してリスクを評価し、目標セキュリティレベル（SL-T）を割り当てる手順を規定しています。全体を一律SL 3にすると機器の選択肢が狭まるため、ゾーンごとに評価を分けます。ただし閉じたライン内だからといって自動的に低くてよいわけではなく、侵害されたときの影響が大きい工程は高いSL-Tになります。

設計上の要点は、ERP側の認証情報が現場ネットワークに落ちない構成にすることです。ゲートウェイから開始する外向き接続を基本とし、宛先・ポート・受信メッセージの権限を絞ります。ERPからPLCへ直接書き込む経路は作りません。どうしても指示を返す必要があるなら、MESを経由させて書き込み権限をレベル3に閉じ込めます。IT部門の対策がそのまま効かない理由と工程別の打ち手は制御システムセキュリティ対策とは？IT対策が効かない理由と工程別の打ち手を解説、IT/OTの境界の考え方はOTとは？ITとの違い・Purdueモデル・OTセキュリティ実装まで解説にまとめています。

業務別に見る連携の効果と、成立に必要な前提

設備保全：既存の保全業務への異常検知の接続

停止時間と保全履歴はもともとERPの設備管理モジュールが持つ情報です。IoTで稼働・振動・温度を取り、閾値超過で保全オーダーを起票する流れは、ERPの既存伝票にそのまま乗るため、他の用途より着手が軽い領域です。ただし検知時刻を保全履歴へ結びつけるには、設備IDの対応づけと異常判定条件の整備が先に必要です。故障予知まで踏み込むかどうかは別の判断で、費用対効果の見方は予知保全とは？仕組みと予防保全との違いから費用対効果・導入判断まで解説で整理しています。

品質・検品：ERPへ返す項目と外部保存する検査データ

検品工程にカメラやセンサーを入れると、まず大量の画像と測定値が出ます。ERPへ渡すのは不良数量・不良区分と、ロット・製造オーダーとの紐づけです。ERPの品質管理モジュールには検査結果を記録できるものもあるので、業務で参照する検査成績表はそこへ入れる判断もあります。一方、画像の原本と高頻度の測定値は保存量が桁違いなので、外部保存にしてERPからキーで参照します。合否のしきい値をどう決めるかは外観検査の自動化とは？目視検査を置き換える工程設計としきい値の決め方を解説の領域で、ERP連携とは切り離して検討します。この切り分けを曖昧にしたまま「検品システムとERPを連携」と要件に書くと、ベンダー間で責任範囲が空きます。

生産実績・在庫：自動計上に必要な対応づけの整備

設備からの完成数を自動計上するには、センサー信号を対象のリソース・工程・製造オーダーへ対応づける必要があります。同じラインで複数品目を流す場合は、品目の切替時にどの製造オーダーへ計上するかを識別する仕組みが要ります。対応づけが未整備なら、その設定が先です。効果が出ないのではなく、前提が終わっていないだけです。着手前に、ERPのリソースマスタと現場の設備台帳を突き合わせる作業と、維持担当・更新手順を工数に入れておきます。

原価：標準原価の更新と差異分析への反映条件

実績工数が自動で取れれば原価精度が上がる、という説明はよく見かけますが、標準原価を設定している場合に実績の粒度を上げてまず変わるのは、原価差異の分析精度です。標準原価そのものの改定は年度単位で運用していることが多く、実績が細かくなっても自動では動きません。着手前に、取得した実績を標準原価の更新に使うのか差異分析に使うのかを決めてください。決めないまま導入すると、精度の高い実績が集まったのに使い道が無い状態になります。ERPと所要量計算の関係はERPとMRPの違いとは？JIS Z 8141の定義と所要量計算でみる役割分担で扱っています。

よくある質問

IoTとERPを直接つなぐことはできますか？

技術的には可能です。ERPのAPI制約、更新頻度、再送・重複排除、変換処理の保守範囲を確認して判断します。これらを整理しないまま接続を増やすと、変換ロジックがERPのアドオンとして増え、バージョンアップのたびに検証対象になります。接続先が増える見込みがあるなら、最初からゲートウェイかMESを間に置いてください。

MESが無い工場でもIoTとERPを連携できますか？

できます。ただしMESが担っていた「どの作業指示に対する実績か」を紐づける処理を、どこかが持つ必要があります。クラウド側の連携基盤に持たせるのが現実的です。その場合も、設備とERPのリソースの対応表を誰が維持するかを先に決めてください。維持担当と更新手順が未定のままだと、品目追加時に対応づけが漏れて実績を計上できなくなります。

設備保全のDXでIoTはどこまでの役割を持ちますか？

IoTが担うのは異常の検知までで、保全計画の更新・部品の引当・費用の計上はERPの設備管理モジュールの仕事です。IoT単体では保全業務は回りません。ERPに設備管理モジュールがない場合は、専用の保全管理システムや既存の作業手順へアラートをつなぎ、対応担当と処置記録を定めます。

検品データはERPに入れるべきですか？

在庫と原価を動かす不良数量・不良区分は入れます。ERPの品質管理機能には検査結果を記録できるものもあるので、業務で参照する証跡はそこへ入れる判断もあります。一方で検査画像や測定値の時系列は保存量が桁違いなのでERPの外に置き、キーで参照します。保存年限の要件がある場合は、改ざん防止・検索・監査対応を含む総費用で保存先を比較します。

ERPのIoT機能を使えば自前で作らずに済みますか？

2026年9月時点では、そう考えない方が安全です。Dynamics 365 Supply Chain ManagementのSensor Data Intelligenceはプレビュー扱いで、必要なAzureコンポーネントは利用者自身のサブスクリプションに配置する方式です。クラウド側の構築と運用が自社に残る前提で見積もり、ERPとの接点はイベントを渡すインタフェース1枚に絞っておいてください。

関連記事

• 製造業のデータ連携｜設備・MES・基幹の階層別インタフェース設計と段階導入
• MESシステムとは：製造実行システムの11機能とISA-95レベル3の実装要件
• OPC UAとは？情報モデルとOPC Classicとの違い・採用判断を実装目線で解説
• 制御システムセキュリティ対策とは？IT対策が効かない理由と工程別の打ち手を解説
• スマートファクトリーとは？定義と5階層の構成要素・投資判断の線引きを解説