EDI運用の監視をどう仕組み化する?監視対象・検知タイミング・対応体制の整理

◆監修・編集責任者　小園 将隆　2026年10月1日

B2B EC-COLUMN

目視確認頼みのEDI運用が招くリスクと、監視を仕組み化する最初の切り口

毎朝EDIの管理画面を開き、前日の送受信を担当者が目視で確かめる。
その運用でも日々は回りますが、確認した人が休んだ日や、受信は成功しているのに取り込みで止まっていたような場面では、気づくのが遅れるという不安が残ります。
監視を仕組みにするには、ツールを探す前に「何を見るのか」を通信疎通・データ内容・処理結果・処理期限という四つの系統へ切り分けるところから始めます。
そのうえで、どの異常に即座に気づく必要があるのか、検知した後に誰が最初に動くのか、取引先への連絡と再送をどの順で行うのかを決めていけば、自社の体制に合った監視の形が見えてきます。

「見ている」ことと「気づける」ことは別のこと

目視確認が危ういのは、担当者の注意力が足りないからではありません。
画面に出ている情報が「正常なら何も変わらない」形式になっていることが多いためです。
受信一覧に取引先名と件数が並んでいても、本来そこにあるはずの取引先が抜けている状態は、普段の並びを覚えている人にしか見えません。
異常が「表示されるもの」ではなく「表示されないこと」として現れるとき、目視は急に頼りなくなります。

属人化も、能力ではなく確認の設計に根があります。
どの取引先が何時までに何を送ってくるのか、何件なら妥当なのかという基準が手順書ではなく頭の中にあると、代わりの人が同じ画面を見ても同じ判断に至りません。
さらに、確認したという事実そのものが残らないため、後から「あの日は見たのか、見て問題ないと判断したのか」を追えなくなります。
障害の原因を調べる段になって、確認の履歴がないことが調査の壁になることもあります。

社内システムの監視と違う点もあります。
EDIは相手のある仕組みなので、異常の原因が自社の処理にあるのか、通信の経路にあるのか、そもそも取引先がまだ送っていないのかに分かれます。
原因の所在がこの三つに分かれる以上、検知してから最初にすべきことも、連絡する相手も、自社だけで直せるかどうかも変わってきます。
監視を設計するときは、この前提を最初から織り込んでおく必要があります。

仕組み化は「何を見るか」を分けるところから始まる

監視を自動化しようとして最初にツールを探すと、たいてい手が止まります。
通知の条件を設定する画面まで進んだところで、何をもって異常とするのかが決まっていないことに気づくためです。
条件を決めるには、監視する対象を性質ごとに分解しておく必要があります。
逆に言えば、対象さえ分かれていれば、自動化するかどうかは後から選べます。

分け方の手がかりは、業界標準の整備のされ方にもあります。
流通BMSでは、電子取引文書のメッセージ仕様とは別に、通信プロトコル利用ガイドライン、流通業界共通認証局証明書ポリシー、セキュリティ基盤に関する調査報告書といった通信・セキュリティ関連の文書が、独立した仕様書として整備されています¹。
データの中身を定める文書と、そのデータを運ぶ経路を定める文書が別建てになっている、という構成です。
各文書の本体にどこまで具体的な監視項目や監査ログの仕様が書かれているかまでは確認できていないため、中身を前提にした説明はできませんが、少なくとも「データの正しさ」と「通信の成立」が別の管理対象として扱われていることは読み取れます。

この記事では、そこからさらに踏み込んで、通信疎通・データ内容・処理結果・処理期限という四つの系統で監視対象を考えます。
この四分割は業界標準が定めた共通基準ではなく、異常が現れる場所と、気づいた後に取れる対処が系統ごとに違うという理由で分けた整理です。
次の節から、それぞれで何を見るのか、どこが見落としやすいのかを順に見ていきます。

監視対象は4系統に分けて考える:通信疎通・データ内容・処理結果・処理期限

通信疎通の確認

最初の系統は、取引先とのやり取りが物理的・論理的に成立しているかどうかです。
接続が確立したか、認証が通ったか、予定していたファイルが届いたか、こちらから送ったファイルが相手に渡ったか。
ここは通信ログやジョブの結果として記録が残るため、監視の入口としては比較的手を付けやすい領域です。

ただし、この系統には一つだけ性質の違う異常が混ざっています。
相手がまだ送っていない場合、自社側のログには何も残りません。
エラーが出ないので、エラーを拾う監視では永久に検知できないということです。
「今日は0件だった」のか「本来あるはずのものが来ていない」のかを区別するには、ログを見るのとは別の仕掛けが要ります。
この点は検知のタイミングの話に直結するので、次の節で改めて扱います。

認証情報や証明書の期限も、この系統に含めて考えておくほうが安全です。
流通BMSで認証局の証明書ポリシーが独立した文書として整備されている¹ことからも分かるとおり、証明書の扱いは通信の成立条件の一部です。
期限切れの厄介さは、前日まで何の兆候もなく正常に動き、期限を過ぎた瞬間に接続が一斉に止まる点にあります。
日々の送受信を見ているだけでは予兆が出ないため、期限そのものを管理対象として別に持つ必要があります。
どの接続でどの証明書や認証情報を使っているかは接続方式によって変わるので、自社の構成に合わせた棚卸しが前提になります。

もう一つ、監視の単位にも注意が必要です。
取引先が複数あり、接続方式も相手ごとに違う場合、「EDIは動いている」という全体の状態は、一社だけ繋がらない状況を覆い隠します。
見る単位は全体ではなく、取引先ごと、かつ受信と送信の方向ごとに分けておくほうが、異常の見落としが減ります。

データ内容の妥当性確認

二つ目は、届いたデータの中身が受け取れる形になっているかどうかです。
レコードの形式、必須項目の有無、桁数、商品コードや取引先コードといったコード体系の整合。
この層の異常はシステムがエラーとして弾いてくれることが多いため、エラーが出ている限りは検知自体に困りません。
問題になるのは、エラーとして弾かれた後、そのレコードがどこへ行くのかが運用上あいまいな場合です。

むしろ監視として難しいのは、形式としては正しいのに業務としてあり得ない値が通ってしまう場合です。
単価が0で届く、数量の桁が一つ多い、前月と同じ内容が再び送られてくる、同じ伝票が二重に届く。
これらは形式チェックを通過するため、気づくのは業務部門が現物を見た時点になりがちです。
どこまでを機械的なチェックの対象にするかは、自社の商材や取引条件で変わります。

自社のマスタ側に原因がある異常も、この系統で拾っておくと切り分けが早くなります。
取引先が新しい商品コードで発注してきたのに自社の変換テーブルに登録がない、といった状況です。
データとしては正しく届いているので通信の監視には引っかからず、変換処理のエラーレコードが保留のまま溜まっていきます。
保留分を誰も見ない仕組みになっていると、滞留した件数が増えてもどこにも表示されません。

チェックを厳しくしすぎると、業務が止まるという逆の問題も出ます。
異常として処理を中断させるものと、記録して警告を出すだけのものを分けておくと、現場が止まらずに済みます。
この線引きは、誤ったまま後工程へ流れたときの手戻りの大きさで決めるのが実務的です。

処理結果の確認

三つ目は、受け取ったデータが自社の業務システムに入りきったかどうかです。
通信が成功していることと、受注データが基幹システムに登録されていることは別の事実です。
取り込みジョブが「正常終了」と表示していても、実際には0件しか処理していなかった、という状態は起こり得ます。
ジョブの戻り値だけを見ていると、この種の異常は正常として通過します。

そのため、結果の監視では件数の突合が軸になります。
受信ファイルに記録されている明細の件数、取り込み処理が登録した件数、業務システム側で見える受注の件数。
この三つが一致しているかを見れば、途中で落ちたレコードの存在に気づけます。
一致していない場合に差分がどこで生まれたかを追えるよう、処理の各段階で件数を記録しておくことが前提になります。

部分的に成功した場合の扱いも、あらかじめ決めておく必要があります。
届いた明細のうち一部だけがエラーになり、残りが取り込まれた状態です。
取り込まれた分は業務が進んでしまうため、残りを後から追加するのか、いったん全体を取り消して再取り込みするのかで、現場の作業がまったく変わります。
どちらを選ぶかはシステムの作りによりますが、決めていないと担当者ごとに対応が割れます。

受け取る側だけでなく、自社が送る側に回る処理も同じ系統で見ます。
受領の返信、出荷予定の送信、請求データの送信など、相手が待っているデータをこちらが作れているか、送信まで終わっているかです。
受信の監視だけを整えて送信側が手薄になると、相手から催促を受けて初めて気づくことになります。

処理期限の管理

四つ目は、取引先ごとの締切に間に合っているかどうかです。
前の三つが「起きたこと」を見る監視であるのに対し、これは「起きるはずのことが起きていない」ことを見る監視になります。
性質が違うため、同じ仕組みでは拾えません。

見る対象は、受注データが届くはずの時刻、受領や出荷予定を返す期限、請求データを送る締切などです。
これらは取引先との取り決めで決まっているので、相手ごとに時刻も曜日も違います。
全社で一つの時刻を決めて監視すると、早い相手には遅すぎ、遅い相手には無駄な警告が出ます。

厄介なのは、この期限が一覧になっていないことが多い点です。
契約書や運用の取り決め書に書かれていることもあれば、立ち上げ時のやり取りのまま慣行として続いていることもあります。
監視を仕組みにする過程で、取引先ごとの期限を書き出して突き合わせる作業がどうしても一度必要になります。
この棚卸しは手間がかかりますが、検知のタイミングを決める材料がここにしかないため、省くと後の設計が進みません。

すべてを即時検知にする必要はない:検知タイミングの考え方

すぐ気づくべき異常と、翌営業日でよい異常を分ける

監視対象が決まると、次に「いつ気づくか」を決めることになります。
ここで全部を即時通知にすると、夜間や休日に誰かが反応できる体制が前提になり、通知の量も増えます。
通知が多すぎれば見なくなり、見なくなった通知は無いのと同じです。
即時性は、監視の精度ではなく運用コストを決める設定だと考えたほうが設計しやすくなります。

分けるときの一つ目の見方は、期限までの猶予です。
異常に気づいてから復旧までに必要な時間は、原因の切り分け、取引先への連絡、相手の対応、再送、取り込みと確認の合計になります。
この合計が期限までの残り時間に収まらないなら、その異常は発生から間を置かずに気づく必要があります。
逆に、翌営業日の午前に対応しても十分間に合う処理であれば、日次のまとめ確認で足ります。

二つ目は、後工程への影響の大きさです。
出荷の指示や請求の締めに直結するデータは、遅れがそのまま外部への影響になります。
一方、参照用のデータや、後からまとめて取り込んでも業務が成立するものは、扱いを下げられます。
同じ取引先のデータでも、種類によって重みが違うという点は見落とされがちです。

三つ目は、自社だけで直せるか、相手が動かないと直らないかです。
自社の処理で止まっているなら、気づいた時点から自分たちのペースで復旧できます。
取引先の送信待ちや相手システムの不具合であれば、相手の営業時間内に連絡が届かないと何も進みません。
相手待ちになる種類の異常ほど、早く気づく価値が大きいということです。

ここで挙げた猶予・影響・対処の主体という見方は、編集部として整理したものです。
どの異常を何分以内に検知すべきかという線引きを示す公的・業界の資料は、今回確認できませんでした。
実際の基準は、自社の処理期限と取引先との取り決めに照らして決めることになります。

検知の手段と、未着を見つけるための時刻設計

即時性の区分が決まれば、手段は三段階で考えられます。
その場で担当者へ通知するもの、当日の決まった時刻にまとめて確認するもの、日次や週次の突合レポートで振り返るものです。
対象ごとにどの段階に置くかを決めておけば、通知の量は自然と絞られます。

このうち、仕掛けを別に用意しなければならないのが未着の検知です。
「届かなかったこと」はログに残らないため、受信予定時刻と、そこからどれだけ過ぎたら異常とみなすかという定義を、こちら側に持たせる必要があります。
取引先ごとに期限を棚卸ししておく意味はここにあり、この定義がないと監視の自動化はそもそも設定できません。
手動で続ける場合も同じで、「何時までに来ていなければおかしい」という基準が共有されていなければ、確認する人によって判断が割れます。

通知の届け先も設計の一部です。
特定の担当者のメールにだけ飛ぶ設定は、その人が不在の日にそのまま止まります。
複数名が受け取る宛先にしておく、業務時間外は別の経路にするなど、誰が受けても同じ対応に入れる形にしておくことで、属人化の解消につながります。

通知の粒度も実務では効いてきます。
一つの障害で数十件のレコードがエラーになると、レコードごとに通知が飛んで本来の異常が埋もれます。
取引先と事象の単位でまとめる、同じ事象の繰り返しは抑えるといった調整を入れておくと、通知が見られ続ける状態を保てます。

検知後の一次対応と体制:内製で担うか、自動化・ベンダー委託に委ねるかの判断軸

エラー発生時に誰が動くか:内製運用とベンダー委託の違い

検知の次に決めるのは、通知を受けて最初に動く人です。
内製で運用している場合、ここが実質的に特定の一人になっていることは珍しくありません。
手順が整っていても、受ける人が一人なら、不在の時間帯はその人が戻るまで止まります。
体制の設計とは、要するにこの最初の受け手を誰にするかと、その人がいないときにどう代替するかを決めることです。

委託という選択肢では、この最初の受け手を外に置けます。
たとえばJSOLは、自社のEDIサービスについて、取引先との通信でエラーが発生した際に同社が一次対応を実施し、エラーの内容によっては取引先へ直接連絡を取ってリトライなどの対応をすると説明しています²。
ただし同社はこれに「運用の取り決めによる」と付記しており、委託契約を結び、かつ両社間で運用の取り決めがある場合の話です²。
どこまでを任せられるかは契約内容で変わるため、サービスとして一次対応があるかどうかではなく、自社の取引先・自社の異常についてどこまで動いてもらえるかを個別に確認することになります。

同社は24時間365日稼働の運用を提供し、安定した運用によって不具合対応の工数を削減するとも説明しています²。
具体的な稼働率や削減工数の数値は示されていないため、効果の程度を見積もる材料にはなりませんが、内製で夜間休日の受け手を確保しようとすると当番体制が必要になる、という比較の対象にはなります。

人が動く体制とは別に、そもそも止まりにくい基盤に載せるという方向もあります。
TISIは自社のEDIプラットフォームサービスについて、「遠隔、分散、並列」の環境で最上級のレジリエンスを標準性能として提供するとしています³。
これも同社が自社サービスについて説明している内容で、稼働率などの数値の記載はなく、他のベンダーや内製環境に当てはめられるものではありません。
基盤が止まりにくいことと、止まったときに誰かが切り分けて取引先に連絡することは別の役割なので、どちらか一方で監視の設計が完結するわけではない点には注意が要ります。

委託を考えるときに整理しておきたいのは、移せる役割と移せない役割の境目です。
通信エラーの一次対応や再送の実行は、手順が決まっていれば外に出せます。
一方、届いた受注が業務として妥当かどうか、この単価や数量で処理を進めてよいかという判断には、自社の商流と取引条件の知識が要ります。
データ内容の妥当性に関わる部分は、委託していても自社に残る前提で体制を考えておくほうが現実に合います。

手動確認を続けられる条件と、自動化・委託を検討する条件

手動の確認を続けてよいのか、自動化やツール導入に進むべきなのかは、多くの担当者が迷うところです。
取引先が何社を超えたら、処理が何件を超えたら切り替えるべきだという閾値を示した一次資料は、今回の調査では見つかりませんでした。
そのため数値の基準は示せませんが、判断に使える観点であれば自社の状況に当てはめられます。

手動のまま続けられるかどうかを見るとき、次のような点が目安になります。

<ul><li>毎日の確認が、他の業務を圧迫せずに業務時間内で終わっているか</li><li>確認の基準が手順として書かれ、担当者以外でも同じ判断ができるか</li><li>異常を見つけてから復旧するまでの時間が、処理期限までの猶予に収まるか</li><li>確認した事実と対応した内容が、後から追える形で残っているか</li><li>取引先が増えるたびに確認の手数が比例して増える構造になっていないか</li></ul>

このうち複数が崩れているなら、仕組みに移す検討に入る段階だと言えます。
ただし、移すといっても全部を一度に自動化する必要はありません。
人が目で見ても気づけない未着の検知や、件数の突合のように機械が得意な部分から先に自動化し、検知した後の判断は自社で行う、という切り分け方が取りやすい形です。
どの対象をどの段階に置くかは、前の節で整理した即時性の区分がそのまま使えます。

委託に踏み込むかどうかは、少し違う条件で考えます。
夜間や休日にも受け手が必要になる、基盤の冗長な構成を自前で設計して維持し続けるのが難しい、接続方式の異なる取引先が増えて自社だけでは対応が追いつかない、といった状況では、外に出す選択肢の重みが増します。
一方で、委託しても自社から消えない仕事はあります。
どこまでを任せるかの運用の取り決めを作ること、業務部門への連絡と業務影響の判断、そして委託した範囲と残った範囲を自社で把握し続けることです。
この把握が曖昧なまま任せると、障害時に「相手がやっていると思っていた」という空白が生まれます。

障害発生時の対応フロー:切り分け・取引先連絡・再送の流れ

異常の切り分け

通知を受けた時点では、まだ原因は分かっていません。
最初にすることは復旧ではなく、原因がどこにあるのかを絞り込むことです。
ここを飛ばして取引先へ連絡すると、自社側の設定が原因だったときに手戻りになり、相手の信頼も損ないます。

順序としては、自社の内側から外へ向かって見ていくのが効率的です。
まず自社の取り込み処理やジョブの記録を見て、処理が動いたのか、動いて失敗したのか、そもそも起動していないのかを確かめます。
次に通信の記録を見て、接続自体が成立していたか、ファイルが到着していたかを確認します。
そこまでで異常が見つからなければ、相手がまだ送っていない可能性が残る、という順番です。

自社の内側で完結する異常は、連絡せずに直せます。
マスタに未登録のコードがあった、ジョブが起動していなかった、変換処理でエラーレコードが保留になっていたといった場合です。
この種の異常は復旧の見通しも立てやすいので、業務部門に影響の有無だけ伝えて自社で片付けるのが基本になります。

通信の経路に原因がある場合、自社でできることは接続設定や証明書の確認までで、その先はネットワークやサービスの提供側の領域に入ります。
運用を委託しているなら、ここは委託先に調べてもらう範囲です。
相手側のシステムに原因がある場合は、こちらでどれだけ調べても復旧しません。
期限までの猶予が短いときは、切り分けの完了を待たずに「現時点で未着であること」だけを先に伝え、調査と並行して相手にも確認してもらうという判断もあり得ます。

取引先への連絡

連絡で最初に決めておくべきは、誰が連絡するかです。
情報システム部門が技術的な確認として連絡するのか、業務部門が普段のやり取りの窓口として連絡するのかが曖昧だと、同じ件で二重に連絡が入ったり、逆に互いに相手がやっていると思って誰も連絡しなかったりします。
運用を委託している場合はさらに注意が必要で、エラーの内容によっては委託先が取引先へ直接連絡してリトライまで行うと説明している例もあります²。
これも運用の取り決めによるものなので、どの種類のエラーで委託先が動き、どこからが自社の連絡になるのかを取り決めの段階ではっきりさせておかないと、現場で重複します。

連絡先そのものの整備も、平時にしかできない準備です。
相手の窓口が営業の担当者なのか、情報システムの担当者なのかは取引先によって違います。
どちらに最初に入れるか、相手の受付時間は何時までか、締切直前で時間外になったときの連絡手段があるかを、取引先ごとに持っておくと、障害時に探す時間がなくなります。

伝える内容は、相手が動けるだけの情報に絞ります。
何のデータが、いつの分から来ていない（または処理できていない）のか、こちらの業務にどんな影響が出るのか、こちらでどこまで確認したのか、相手に何をしてほしいのか。
特に最後の依頼事項が曖昧だと、相手も調査に入れず往復が増えます。
原因が自社側だった場合も同じで、影響の範囲と復旧の見込みを先に伝えておくと、相手の後工程の判断材料になります。

再送の判断

再送はもっとも手数の少ない復旧手段ですが、同時に二重取り込みを招きやすい操作でもあります。
一度目の送信が本当に取り込まれていないのか、一部だけ取り込まれているのかを確定させないまま再送すると、同じ受注が二重に登録され、出荷や請求まで波及します。
そのため、再送の前に処理結果の確認が入ります。
前の節で件数の突合を監視対象に挙げたのは、障害時にこの判断を素早く行うためでもあります。

部分的に取り込まれていた場合は、再送する範囲を決める必要があります。
全件を送り直すのか、不足分だけを送ってもらうのかで、自社側の準備も変わります。
全件を送り直すなら、既に取り込んだ分を取り消してから受け入れるのか、重複を検知して自動的に除外できるのかを事前に把握しておくことが前提です。
伝票番号やデータ管理番号を鍵にした重複チェックが自社のシステムにあるかどうかで、取れる選択肢が変わります。
仕組みとして持っていない場合は、誰が、どの権限で、どの手順で取り消すのかを決めておかないと、障害の最中に判断することになります。

再送の後も、送った時点で終わりにはしません。
再送されたデータが届き、取り込まれ、件数が想定どおりになったかを確認して初めて復旧です。
さらに、受領の返信や出荷予定の送信といった後続の処理が、遅れた分も含めて走りきっているかまで見ておくと、翌日に別の形で問題が出るのを防げます。

最後に、一連のやり取りを記録として残します。
いつ検知し、原因は何で、誰が連絡し、どう復旧したか。
この記録は、同じ異常が繰り返されたときに即座に対処するための手順の種になりますし、監視の条件を見直す材料にもなります。
検知できずに業務部門から指摘を受けた異常があれば、それは監視対象か検知タイミングのどちらかに穴があったということなので、四つの系統のどこに足りなかったのかを見直す起点になります。

ここまでの流れを自社に当てはめると、取引先ごとの期限や既存システムの作りによって、決めきれない点がいくつか残るはずです。

監視対象の分け方や検知のタイミングは整理できても、自社のEDIがどんな記録を残していて、その記録から何を自動で拾えるのかは、既存システムの作りを見ないと判断できません。

現在の受発注の流れと、取引先ごとの期限や確認の手順をお聞かせいただければ、どの確認が仕組みに移せて、どこまでが人の判断として残るのかを一緒に切り分けられます。無料相談で要件を整理する

要点の整理

軸	判断の基準
監視対象の分け方	通信疎通・データ内容・処理結果・処理期限の四系統に分け、取引先ごと・方向ごとの単位で見る
未着の検知	受信予定時刻と、過ぎたら異常とみなす猶予を自社側に定義として持つ
検知の即時性	期限までの猶予、後工程への影響、自力で直せるかどうかで段階を分ける
一次対応の担い手	内製は受け手と代替者を決める。委託では一次対応の範囲が運用の取り決めで変わる
取引先への連絡	自社が連絡するのか委託先が連絡するのかを事前に決め、窓口と受付時間を平時に整備する
再送	未取り込みの範囲を確定させてから送り、重複を除外できるかを先に把握する

手動の確認を続けるか、一部を自動化するか、運用ごと外に出すかは、取引先の増え方や後工程のつながり方によって答えが変わり、一般的な基準では決めきれない部分が残ります。 いま起きているエラーの種類と、復旧までにかかっている時間を具体的に伺えば、優先して仕組みにすべき対象と、当面は手順の整備で足りる対象を区別してお伝えできます。

よくある質問

EDI監視を内製で行う場合、最低限どのような役割分担が必要ですか。

最低限そろえたいのは、通知を最初に受ける窓口、原因を切り分ける担当、取引先へ連絡する担当とその権限、業務部門へ影響を伝える担当、そして自社だけで判断できないときのエスカレーション先です。
人数が少ない場合、一人が複数の役割を兼ねること自体は問題ありませんが、その人が不在のときに誰が代わるかまで決めておかないと、実質的に属人化したままになります。
特に取引先へ連絡する権限は、技術的な確認と商取引上の説明が混ざるため、情報システム部門と業務部門のどちらが行うのかを事前に決めておくと、障害時の迷いが減ります。

流通BMS以外の個別EDI（専用線や独自フォーマット）でも、同じ整理の考え方は使えますか。

通信疎通・データ内容・処理結果・処理期限という分け方自体は、特定のプロトコルや標準に依存していないため、個別EDIでも当てはめられます。
変わるのは、各系統を確認するための手段です。
標準化された受領確認や応答の仕組みがない場合、処理結果を相手と確認し合う方法そのものを取り決めとして作る必要があり、データ内容のチェック項目も自社で定義することになります。
つまり、分けて考えること自体は共通で、確認の手段を自前で用意する分だけ設計の手数が増える、という違いになります。

監視の自動化ツールを導入する場合、既存のEDIシステムとどう連携させればよいですか。

出発点は、既存のEDIシステムが持っている情報を外から取り出せるかどうかの確認です。
通信ログやエラーの記録がシステム内部に存在することと、それを他の仕組みから読める形で出力する機能があることは別なので、ログの出力形式、保存場所と保持期間、取得の方法を先に確かめる必要があります。
また、未着の検知は時刻を起点にした判断になるため、取引先ごとの受信予定時刻と猶予をツール側に定義として持たせられるかも確認点になります。
具体的にどの製品がどこまで対応しているかは本記事では確認できていないため、導入時に自社の構成に即して個別に確かめてください。

取引先側のシステム障害が原因のエラーは、自社の対応フローでどう扱えばよいですか。

原因が相手側にあっても、自社の処理期限が動くわけではないので、監視の対象から外さず、検知した時点で自社の業務影響を見積もるところまでは同じ流れで進めます。
そのうえで、復旧を待つのか、暫定的に別の手段でデータを受け取るのかを判断します。
暫定手段を使う場合は、後でEDIによる正式なデータが再送されてきたときに二重に取り込まないよう、どちらを正とするかを決めておくことが欠かせません。
また、相手側の障害は自社では復旧させられないため、相手の連絡窓口と、復旧の見込みを確認する頻度を事前に決めておくと、待っている間の対応が整理されます。

1. 1　出典：一般財団法人流通システム開発センター（流通BMS協議会）「流通BMS標準 通信基盤関連の標準」（発行年不明）
2. 2　出典：株式会社JSOL「JSOL-EDIサービス」（発行年不明）
3. 3　出典：TISI株式会社「EDIプラットフォームサービス紹介コラム」（発行年不明）