製造業 ERP-MES 連携エラー監視・再送管理｜導入と検収

製造業のERP-MES連携エラー監視・再送管理システムを導入するとき、最初に決めるべきことは「失敗したAPIを何回呼び直すか」ではありません。生産指図、材料消費、完工、品質保留などの取引が止まったとき、誰が影響範囲を見つけ、何を直し、どの条件で安全に再送し、ERPとMESの双方で一致を確認するかです。タイ工場の製造、品質、経理、IT/OTの責任者に向けて、例外キューと照合台帳を中心にした導入要件、RFP、FAT/SATの作り方を説明します。既存システムの接続方式に依存しない設計論であり、製品固有の機能や効果を保証するものではありません。

ERP-MES連携の「通信成功」と「業務完了」を分ける

ERPからMESへ生産指図を送る。MESで作業を実行し、出来高や材料消費をERPへ戻す。この往復は一見単純です。しかし、HTTP 200やキューへの投入成功は、相手の業務台帳に正しい取引が確定したことを意味しません。受信後の検証で品目コードが拒否されることもあれば、受信側が確定した直後に応答だけが失われることもあります。前者はマスタ修正、後者は重複計上を防ぐ照合が先です。同じ「送信失敗」という表示で扱えば、現場は誤った再送を選びます。

対象となる業務事実を、少なくとも生産指図の発行・変更・取消、材料の払出・消費・返却、良品・不良品・手直しの実績、完工と入庫、品質保留と解除、月次締め後の訂正に分けます。各取引について、発生元、確定権限、送信先、最終的な帳票または伝票、取消方法を記録してください。日付や工場コードで集計する前に、個々の取引IDを追える状態が必要です。ERPと生産管理システムの責任境界を先に整理したい場合は、ERP・生産管理連携のデータ契約とRFPも参照できます。本稿はその後の運用例外に絞ります。

監視対象はインターフェースだけではない

監視画面に「成功率」と「失敗件数」だけを置いても、当日の出荷や月末締めへの影響は判断できません。生産指図がMESに存在するか、MESの完工実績がERPの製造伝票につながったか、材料消費の数量と単位が対応したか、保留ロットが誤って利用可能在庫になっていないかを見る必要があります。技術イベントを工場の仕事に翻訳するのが監視設計です。アラートの単位も単なるAPI名ではなく、工場、ライン、指図、品目、ロット、影響取引、最後の確認時刻を基本にします。

例外キューは「再送ボタン」ではなく作業台帳にする

例外キューの一行は、障害ログの複製ではなく、担当者が終結まで扱う案件です。最低限、元システムと先システム、インターフェース名、取引種別、業務キー、相関ID、初回発生時刻、最終試行時刻、回数、エラー分類、影響数量、現在の状態、担当部署、処置期限、承認者、再送結果と相手側の確定伝票IDを持たせます。原文ペイロードをそのまま全員に見せるのではなく、業務判断に必要な項目と、権限付きで閲覧する技術情報を分けます。

状態は「新規」「原因調査中」「業務データ修正待ち」「接続復旧待ち」「再送承認待ち」「再送中」「照合待ち」「終結」「隔離」を例として定義できます。ただし名称そのものより、各状態へ移れる条件と権限を決めることが重要です。「終結」は再送要求を受け付けた時点ではなく、相手側の確定結果と照合してから付けます。別途、問題を修正せず廃棄したケースは、取消理由、承認、後続取引の扱いが監査で見える状態に残します。

Microsoft Dynamics 365のBusiness eventsにはエラー表示とResend操作があり、再処理が失敗すればエラーログに残ると公式文書にあります。一方、Oracle Integrationの公式文書では失敗メッセージの再投入は自動ではなく、対象のフロー種別などに条件があります。つまり「製品に再送機能がある」だけで、自社取引の業務確認や責任分担が完成するわけではありません。RFPでは採用候補製品の実機で、どの時点から再開し、どのメッセージを保持し、誰が実行できるか確認します。

エラーを「再試行可能性」と「業務影響」で二軸に分類する

タイムアウト、接続断、相手サービスの一時停止、レート制限などは、条件を満たせば再試行候補になります。未登録品目、無効な工場コード、単位変換の欠落、締め済み期間への計上、必要な先行伝票の不在は、同じデータを何回送っても成功しない可能性が高いものです。受信側で確定済みなのに応答が消えた場合は、再試行の前に相手の業務キーで照会します。判断不能なら自動再送を停止し、人が照合する経路へ置きます。

もう一つの軸は影響です。翌日の分析用レポート更新失敗と、当日の出荷可否を左右する品質保留解除の欠落は、同じ技術エラーでも優先度が異なります。例外に紐づく製造指図とロット、金額への影響、後続工程の待機、締め時刻までの残りを評価します。通知先と期限はこの業務影響から決め、再試行回数だけで決めません。Microsoftの設計指針も、一時的な障害に限って再試行を行い、繰り返しても解決しない障害を区別するよう求めています。

この表は導入時のたたき台です。ERP、MES、ミドルウェアのエラーコード体系に合わせ、実際の応答と取引結果をFATで検証してから自動化範囲を確定します。特に4xxや独自エラーを一律に「恒久障害」と見なすと、製品固有の再試行指示を見落とすことがあります。逆に5xxであっても、相手で取引が確定した可能性は残ります。

取引IDと相関IDを分け、同じ案件を往復で追えるようにする

連携メッセージには技術的なメッセージID、業務取引ID、相関IDを分けて持たせます。メッセージIDは送信試行を区別するため、再送ごとに変わる構成もあります。業務取引IDは「同じ材料消費の計上依頼」を再送しても変えず、重複防止の基準にします。相関IDは指図発行から材料消費、完工、入庫まで関連する複数イベントを検索するために使います。さらに、工場、指図、工程、ロット、行番号、業務版数、発生時刻、送信時刻、送信元の状態を契約に含めます。

例えば同じ指図の完工数量が訂正された場合、「同一取引の通信再送」と「新しい業務版の訂正」は違います。前者は同じ業務取引IDと同じ内容で冪等に処理し、後者は新しい版・理由・承認・取消元を明示します。単にJSONを上書きして再送すると、初回の実績と訂正後の実績を監査で区別できません。自社のERPが取消伝票を要求するのか、調整伝票を受け付けるのかは製品設定と業務ルールで確認してください。

Dynamics 365 Business eventsの公式文書は、消費側が重複配信を検知するための制御番号をペイロードに含むと説明します。ただし制御番号があることと、自社のMES・ERP間で完工が二重計上されないことは別です。受信側の保存処理と業務伝票作成をどの境界で一体に扱うか、障害時の再開位置をどうするかまで決めます。

安全な再送は「送ったか」より「確定したか」を確認する

自動再試行は一時障害に限定し、回数、間隔、全体の期限を有限にします。相手が復旧中なら間隔を広げ、同時に大量の送信元が再試行しないよう調整します。回数を増やすほど成功率が上がると決めつけず、重複や後続処理への影響を試験します。Microsoftの一時障害対策では冪等性、指数的な待機、再試行の予算、記録を考慮するよう説明されています。これを製品の初期値として写すのではなく、自社の締め時刻と取引量に合わせて設定します。

手動再送は、①相手側の確定状態を照会、②原因を修正、③元ペイロードと修正版の差分を表示、④承認、⑤同一業務キーで投入、⑥相手の確定伝票を取り込み、⑦差分照合、⑧案件を終結、という順序にします。「再送成功」は通信応答と業務照合を別の指標として記録します。照合が未了なら例外を閉じません。変更可能なフィールドを限定し、業務データを画面で勝手に書き換えた場合は誰が何を変えたか残します。

Azure Service Busの重複検知は、送信側が指定するMessageIdを一定の保持窓内で照合する仕組みです。公式文書は設定可能な時間窓と利用条件を示しています。これは有用ですが、窓外の再送や別の経路からの重複、相手アプリでの二重業務計上まで防ぐ万能策ではありません。購買や在庫の取引に必要な冪等性は、業務キーと受信側の確定記録で検証します。

順序・部分成功・締め処理を例外として先に設計する

ERPから送る指図発行が失敗したまま、MESの完工実績だけを送ると、受信側には参照する指図がありません。材料返却が消費より先に到着しても、残量を正しく計算できない場合があります。全メッセージを一列にして順序を守ると処理が詰まるため、どの業務キー単位で順序が必要かを決めます。指図単位、ロット単位、在庫ロケーション単位のどれかは取引の依存関係によります。失敗した前件に後続をぶら下げ、前件が解決したら再評価する設計が現実的です。

「ERPは材料消費を確定したがMESへの応答が消えた」「MESは完工を確定したがERPの入庫だけが拒否された」という部分成功は、単純なロールバックでは戻せません。各システムの確定点、補償取引、取消伝票、再投入可能な期限を契約化します。月末締め後に過去日の実績を修正する場合も、締め済み期間を黙って書き換えるのではなく、承認された訂正または翌期調整の方式を経理と合意します。ここは技術チームだけで決められません。

SAP Integration SuiteのJMSを用いた公式リトライ例では、一時的な外部障害時にメッセージを保持し、後で処理し直す流れを示します。SAPのキュー管理文書には状態、再試行回数、次回試行時刻、手動Retryの表示もあります。ただしこれらは同製品の機能例です。自社の連携基盤でも同等の保存期限、順序、再開条件、権限が設定できるか確認し、できない場合はアプリケーション側に補完策を置きます。

日次照合で「静かな欠落」を見つける

連携エラーだけを見ていると、送信処理自体が起動しなかった取引を見逃します。例えばMES上に完工実績があるのに送信対象に抽出されず、エラーログには一行も出ない場合です。このため、例外キューとは別に、ERPとMESの業務台帳を定期照合します。指図ごとに計画数量、MES完工、ERP受入、材料消費、仕損、保留、取消を突き合わせ、件数・数量・単位・状態・更新時刻の差を抽出します。日次だけでなく、出荷前や締め前に重要取引を再照合する選択肢もあります。

照合には許容差、単位換算、時差、遅延到着、締め境界を明記します。差があったとき「どちらを正とするか」は取引種類で違い、ERPの在庫残を常に正とすると現場の未反映実績を消してしまう可能性があります。差異は修正前の元値、修正案、承認者、適用先、再照合結果を残し、片側の帳票だけを手作業で合わせて終わりにしません。仕掛や在庫の現物と台帳の関係を整理したい場合は、仕掛品棚卸管理システムの導入設計も参考になります。

照合ジョブ自身の停止も監視対象です。「差異ゼロ」が照合未実行を意味していないか、最終実行時刻、入力件数、対象期間、除外件数を表示します。システム導入時には正常な一日だけでなく、休日、夜勤、日付またぎ、複数工場、ネットワーク切断後の追いつき処理を試します。

役割分担と承認線を工場の実態に合わせる

ITは連携基盤の稼働、証跡、技術原因を扱い、製造は指図と実績の妥当性、品質は保留と解除、倉庫は在庫移動、経理は締めと原価影響を判断します。この役割の境目で例外が放置されやすくなります。案件種別ごとに一次受付、修正担当、再送実行者、承認者、照合完了者を定義してください。同じ人が原データを修正し、そのまま無承認で再送し、終結できる権限構成は避けます。緊急時の代行と翌営業日の事後確認もルールに含めます。

タイ工場では現地運用担当、地域IT、日本側ERP管理者が時差と休日をまたぎます。画面上の時刻はタイ現地時間とUTCの対応を明示し、作業依頼には画面キャプチャだけでなく業務キーと相関IDを付けます。日本語、英語、タイ語の用語が違っても状態コードは共通にし、「完工」「入庫」「伝票確定」がどの時点を指すか用語集で揃えます。通知は大量の個別メールではなく、優先度、経過時間、担当部署で集約して引き継げる形にします。

運用シナリオと統制を具体化する

具体例：完工実績の応答が消えた場合

一件の流れで考えます。タイ工場のMESで指図Aの完工を承認し、ERPへ業務取引ID Tを送った直後にネットワークが切れました。送信元にはタイムアウトが返り、ERP側の処理結果は不明です。この段階でTを新しいIDとして自動再送してはいけません。例外キューには「結果不明」として載せ、ERPの指図A、業務取引ID T、送信した品目・ロット・数量・版に一致する伝票を照会します。伝票があれば、その数量・状態・承認済み時刻をMESの元取引と比較し、一致した場合に通信エラーを業務上の終結として扱います。伝票が見つからなくても、検索範囲やERPの遅延処理を確認するまでは「未処理」と断定しません。

照会してもTに対応する伝票がなく、ERPの処理ログにも受付がないと確かめたら、元の業務キーと内容で再送する候補になります。再送後にERPから伝票番号Dが返っても、MES上の完工数量とDの入庫数量が合うまで「照合待ち」です。Dが別のロットに計上された場合は、APIの応答が正常でも業務異常として残します。反対に、Tと似た指図・数量の伝票があるが同一性を示すキーがない場合は、担当者が伝票作成履歴と発生時刻を確認し、二重計上の危険がなくなるまで再送を保留します。これが、業務キーを最初から契約に含める理由です。

この例外が夜勤に発生したら、現場は完工品の現物ラベルとロットを保持し、倉庫は入庫確定前に出荷可能と扱わず、翌朝のERP管理者へ相関IDと証跡を渡します。ただし現物移動を停止するかどうかは品目と安全・品質要件で変わるため、自社の暫定運用を決めます。障害が長引いた場合に紙や表計算で代替記録したなら、それにもTを記載し、復旧後に同じ実績を二重入力しないチェック欄を設けます。ITだけでなく製造・倉庫が同じ例外台帳を見る利点はここにあります。

通知とエスカレーションは復旧手順と結び付ける

通知には「失敗しました」ではなく、取引種別、影響する指図・ロット、最終確定地点、再試行予定、担当部署、次の判断時刻を含めます。同一の根本原因で数百件が失敗した場合は、各行を残しつつ一件の親インシデントに束ね、原因修正を優先します。ただし親インシデントを終結しても子取引の照合は個別に必要です。通知の抑制が未処理取引の隠蔽にならないよう、総件数と最古案件の経過時間を見せます。

エスカレーションは技術的なアラートだけでなく業務期限に合わせます。たとえば出荷判断の前に保留解除が必要なら品質責任者へ、月末締めを越えそうな消費差異なら経理へ上げます。しきい値は各工場の稼働時間と通常の連携遅延を測って決め、一般的な「五分以内」のような数字を根拠なく設定しません。夜勤で対応できない部署への通知は、代行権限と暫定処置をあわせて定義します。エスカレーション後も例外の所有者を空欄にしないことが重要です。

データ契約の粒度を「再現できる取引」まで下げる

障害後に再送できるかどうかは、平時のデータ契約で決まります。項目名と型だけを定義した仕様書では不十分です。必須・任意、桁数、単位、丸め、タイムゾーン、ヌルの意味、コード表、版の適用開始、同一取引を判定するキー、訂正と取消の表現、送信順序、相手側の受領確認、保存期限まで記載します。たとえば生産実績の数量が小数を取る場合、ERPが三桁、MESが四桁の精度なら、どの時点で丸めるかによって日次照合の差が変わります。これは再送のたびに新しい値を計算してよいかという問題にもつながります。原取引に記録した値を保持し、変換規則の版も保存しなければ、障害時に同じ結果を再現できません。

コード変換では、ERP品目とMES品目の対応だけでなく、代替品、旧品番、工場固有の別名、単位換算の有効期間を扱います。マスタ変更日をまたいで滞留したメッセージを再送するとき、送信当時の対応表で処理するのか、最新表へ変換し直すのかを決めます。どちらが正しいかは業務の意味に依存します。過去の材料消費を最新の品目へ黙って付け替えることは避け、必要なら明示的な訂正取引として承認します。契約を変更した後も古いペイロードを読める期間、読めない場合の隔離と人手修復の手順を用意します。

相手側の確認応答は段階を分けます。「受信した」「検証した」「業務伝票を作った」「後続システムへ反映した」が同じ成功コードなら、障害時の所在が分かりません。すべての製品が各段階の応答を出せるとは限らないので、利用できる応答、照会API、業務帳票を組み合わせて確認点を設計します。受領番号と伝票番号が別なら両方を保持します。RFPでは代表的な取引一件を選び、各確認点で止めたときに誰が何を見られるか、時系列で回答してもらうと、実装後の運用像が比較しやすくなります。

導入の境界を工場設備まで確認する

MESに取り込まれる元データがハンディ端末、計量器、PLC、検査機のどこから来たかも、結果不明を調べるときに重要です。設備からの計数が二度上がったのか、MESで一度記録した実績がERPへの送信で二度計上されたのかで、修正先が違います。設備側には業務取引IDを載せられない場合があるため、MESで設備イベントを受ける時点にイベントID、設備ID、採取時刻、製造指図、ロットとの対応を保存します。センサーの生データと承認済み生産実績を同一視せず、担当者による補正や品質判定の段階も区別します。

設備停止やネットワーク断では、現場端末が一時保存した実績を復旧後にまとめて送ることがあります。ここで現地時刻だけをキーにすると、端末時計のずれ、日付またぎ、同時刻の複数件で衝突します。端末内の連番や発生IDを採り、MES側で受信時刻と業務承認時刻を別々に記録する方法を検討します。ただし設備ごとの制約があるので、全装置に同じ方式を強制するのではなく、対象ラインで再現試験をします。現場での「実績が見える」とERPへの「確定が終わった」の間にある状態を明示すると、作業者が復旧待ちの実績をもう一度入力する事故を減らせます。

権限、保存、個人情報を同じ設計表で扱う

再送や削除、ペイロード閲覧には異なる権限が必要です。生産担当者には業務キーと原因分類が見えても、個人情報や認証ヘッダーを含む生の通信内容は不要なことがあります。監査担当には変更前後と承認履歴が必要ですが、運用者の秘密鍵は見せません。ログにアクセストークンを残さず、技術的な診断に必要な内容だけを権限付きで保持する方針をRFPに記載します。権限変更を行った管理者自身の操作も証跡に含めます。

保存期間は「長いほど安全」ではありません。短すぎれば月次締め後に未解決案件の原文が消え、長すぎれば保管費とアクセス管理の負担が増えます。連携キュー、例外台帳、監査ログ、業務伝票、バックアップで保持期間が異なり得るため、どの証拠がいつ失効するか一覧にします。キューの有効期限切れを自動削除する前に、案件が終結したか、隔離領域へ移したか、責任者へ通知したかを確認します。復元試験はバックアップが存在することだけではなく、取引IDを指定して特定案件の経緯を再現できるかで行います。

変更管理と継続改善を契約後の仕事に含める

ERPの品目コード体系、MESの工程マスタ、APIのスキーマ、工場の締め時刻が変わると、それまで正常だった連携が翌日から例外を生みます。変更申請には影響インターフェース、既存メッセージの扱い、変換規則の版、切替日、切戻し、担当者の教育を含めます。テストでは新しいデータだけでなく、旧版で作られて滞留しているメッセージが新ルールで誤処理されないか確認します。画面の項目が一つ増えるだけでも、既存の再送手順や照合帳票へ影響する場合があります。

週次の運用レビューでは、個別エラーを人手で閉じ続けるだけでなく、同じ品目で単位不一致が繰り返されるならマスタ登録の入口を直します。承認待ちが多いなら権限設計や代行ルールを見直します。順序待ちが多いなら抽出順または依存関係の設計を検証します。変更後には、対象期間の例外件数、未照合件数、再発率、担当者の作業時間を同じ定義で比較し、改善を確認します。小さな定例でも、根本原因と対策の期限を残すことで、例外キューを単なる滞留リストから改善の入力へ変えられます。

RFPに記載すべき仕様と比較の視点

提案依頼書には「ERPとMESを連携する」とだけ書かず、取引別の失敗シナリオと期待する証拠を添えます。最低限、対象インターフェース、データ契約、業務キー、発生元と確定先、保存期間、例外分類、状態遷移、自動再試行、手動再送の権限、二重計上防止、順序、照合、訂正、監査ログ、運用時間、障害連絡、バックアップと復旧の範囲を書きます。既製品の標準機能、設定、追加開発、外部サービス、人手運用を見積書で分けさせると、初期費用だけでなく運用負担を比べられます。

ベンダーには「エラー画面がありますか」ではなく、実データに近い指図と材料消費を使い、通信成功後の業務拒否、応答喪失、同一取引の再投入、先行取引の未到着、締め後の訂正をデモしてもらいます。画面、ログ、API応答、ERP伝票、MES実績の五つを一件の相関IDでつなげられるかを見ます。製品資料のスクリーンショットだけでは、復旧に必要なデータが実際に保持されるか分かりません。

受入基準は自社の処理量と業務期限で決めます。「平均何秒」だけではなく、ピーク時の投入、処理遅延、未解決案件の経過時間、照合完了までを測ります。外部事例の数字を保証値として借りず、対象ラインの実測値と試験結果を契約上の基準にします。MESそのものの選定も並行するなら、タイMES選定のRFP・PoC・受入ガイドと役割を分けて読み進められます。

FAT/SATで「壊れたときの振る舞い」を検収する

FATでは、テスト環境で正常取引だけでなく障害注入を行います。例えばMESが指図を受信した直後に応答を遮断し、送信側が結果不明として扱うか。材料消費の単位を不正にして、無限再送せずデータ修正待ちに移るか。同じ業務取引IDを二回投入して、受信側伝票が一件に保たれるか。指図変更より前に完工を到着させ、順序待ちとタイムアウト後の扱いが見えるか。作業者が修正版を承認なしに投入できないか。試験の期待結果を先に書き、画面と双方の台帳を保存します。

SATでは実工場のネットワーク、夜勤、現物スキャン、ERP運用時間、担当者交代を含めます。瞬断時に現場入力をどう保持するか、回復後に同じロットが二回計上されないか、翌朝の担当者が未解決案件を引き継げるかを確認します。ERP側のテスト環境が本番と異なる制約も記録し、本番初期監視で補う試験を明示します。FATを通っても、実際の時刻境界やユーザー権限、マスタ差でSATが失敗することがあります。

試験ケースの証跡は、入力ペイロード、送信ログ、例外キューの状態遷移、承認履歴、受信側伝票ID、照合差異、最終結果を一組にします。合否は「画面で成功表示」ではなく、重複伝票なし、未処理案件の追跡可能性、差異解消、監査の再現可能性で判定します。結果不明を「成功」とみなす運用を残さないことが受入の核心です。

小さく導入して運用負債を測る

最初から全インターフェースを一度に置き換えると、障害原因と費用の切り分けが難しくなります。まず一つの工場、一つの製品群、指図発行と完工報告など連続する二方向の取引を選びます。現在の失敗件数だけでなく、手作業照合に使う時間、未発見差異、締め時の調整件数、再送に必要な承認時間を基準値として記録します。これらは工場ごとに違うため、本稿では一般的な削減率や投資回収期間を断定しません。

導入の順序は、①業務キーと確定点を定義、②ログと相関IDを収集、③例外キューの分類と担当を設定、④自動再試行の適用範囲を限定、⑤手動再送と承認を実装、⑥日次照合を追加、⑦FAT/SATで障害ケースを検収、⑧運用指標を見ながら他の取引へ広げる、です。各段階の出口に「例外を誰が終結できたか」という実績を置くと、機能だけ完成して案件が溜まる状態を避けやすくなります。

費用はライセンス、基盤、接続開発、データ契約、マスタ整備、画面、監査保存、テスト、現地教育、保守、変更対応に分けます。例外キューをゼロから作るか、既存の統合製品の監視を拡張するかは、既存契約、保存要件、ERP/MESの改修権限に左右されます。特定アーキテクチャが普遍的に安いとは言えません。見積比較では、障害一件を調査から終結まで追うシナリオを全提案先に共通で渡します。

本番切替では旧連携と新連携が同じ取引を二重に送らないよう、切替点の未処理メッセージを一覧化します。停止時刻を決め、旧系の送信済み・未確定・未送信を業務キーで分け、移行後に一件ずつ照合します。切戻し手順にも同じ台帳を使い、切戻した瞬間に新系の再試行が再開しないよう制御します。障害が起きてから慌ててキューを空にする方法は、原因と影響の証跡を失うため受入対象にしません。保存期限を越えた案件をどこに退避し、どの権限で再投入するかも運用手順に書きます。

運用開始後は、失敗件数の減少だけで成果を判定しないでください。自動再試行で成功した割合、手動介入までの時間、原因別の滞留件数、未照合件数、同一障害の再発、月末に持ち越した差異を同じ定義で追います。エラー通知が減っても、照合未実行やログ欠落が増えていれば改善ではありません。定例では個別担当者を責めるより、変換規則、マスタ登録手順、エラー分類、承認待ちのボトルネックを修正する判断につなげます。こうした運用指標は初期のFAT/SATで収集可能性を確認しておくと、公開後に追加開発をせず改善を始められます。

よくある質問

ERP-MES連携エラー監視システムはミドルウェアのログだけで足りますか？

ログは原因分析に必要ですが、業務取引が相手側で確定したか、担当者が修正と承認を終えたかは別の情報です。ログに業務キーと相関IDを付け、例外キューとERP/MESの台帳照合へつなぐ構成を検討します。既存製品に必要な運用機能があるなら活用し、不足分だけ補います。

ERP-MES連携の再送を自動化できる範囲はどこまでですか？

一時障害で、相手の結果確認と冪等性が検証でき、業務的な承認を要しない取引が候補です。締め後訂正、品質保留解除、金額や在庫に影響する修正は、システム固有の承認ルールに従います。製品の再送ボタンがあることだけを自動化の根拠にしません。

二重計上を防ぐにはメッセージIDを付ければ十分ですか？

十分とは限りません。メッセージIDの重複検知には保持期間や経路の範囲があり、業務取引の訂正と通信再送も区別する必要があります。業務取引ID、版、受信側の確定伝票、取消元を合わせて設計し、同一取引を複数回投入するFATで確認します。

例外キューの導入費用を見積もる前に何を揃えるべきですか？

対象取引と件数、現在の障害パターン、必要な保存期間、運用時間、担当部署、ERP/MESのAPI・データアクセス権、照合対象帳票、受入試験のシナリオです。これがなければ、同じ「監視・再送」でも提案範囲が変わり、価格だけを比較できません。

まとめ：止まった取引を説明できる状態にする

ERP-MES連携の導入成果は、インターフェースが稼働したことだけでは測れません。止まった取引を特定し、業務影響を示し、担当者が原因を直し、安全に再送し、双方の確定結果を照合して終結できることが運用上の完成です。そのために、例外キュー、業務キー、冪等性、順序、照合、権限、監査を取引ごとに定義し、FAT/SATで結果不明と部分成功を試してください。

TOMAS TECHは、タイ工場で稼働するERP・MES・現場端末の現状整理から、例外運用の要件表、RFP、障害注入を含む受入試験まで検討段階から相談を受けています。まず一つの指図が往復する経路と、現在の未解決案件を一緒に可視化したい場合は、お問い合わせをご利用ください。

参考情報

• Microsoft Learn: Business events overview for Dynamics 365 Finance and Operations — エラーログ、再送、制御番号の製品仕様。
• SAP Help Portal: Apply the Retry Pattern with JMS Queue — 一時障害時の保存と再試行の構成例。
• SAP Help Portal: Managing Messages Stored in Queues — キュー状態、Retry、監視項目。
• Microsoft Learn: Azure Service Bus duplicate message detection — MessageIdと重複検知の範囲。
• Microsoft Azure Well-Architected Framework: Recommendations for handling transient faults — 再試行設計と冪等性。
• Oracle Help Center: Resubmit Failed Messages — 手動再投入の条件と再開位置。