EDI障害の切り分け方法｜自社・回線・取引先のどこが原因かを見極める手順

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

B2B EC-COLUMN

EDI障害が起きたら最初に何を確認するか

送信ジョブがエラーで止まり、取引先からは「発注データがまだ届いていない」と電話が入る。
回線なのか、自社のサーバーやEDIソフトなのか、それとも相手側なのか。
この場面で自分の手で変えられるのは、原因を勘で当てにいくことではなく、いま画面に残っている情報を消さずに押さえることです。
エラーの文言、発生した日時、もう一度やると同じことが起きるか、通信ログとエラーログが手元にあるか。
これらが揃うと、接続できない・応答がない・データの中身を弾かれた、という現象の違いから、自社側・回線側・取引先側のどこを先に疑うかの見当がつきます。
そして疑う先が決まれば、回線事業者の故障受付、EDIの運用窓口、取引先の担当者のうち、誰に何を渡せば話が前に進むかも決まります。

「送信が失敗しました」と出た直後、多くの場合まず手が伸びるのは再送ボタンです。
通ればそれで終わりですし、実際それで片づく回数のほうが多いかもしれません。
厄介なのは、何度か試しても通らず、そのあいだに画面を閉じてしまったときです。
手元に残るのが「何回か試したが駄目だった」という記憶だけになると、そこから先の切り分けは、誰に相談しても同じところを堂々巡りします。

切り分けに使えるのは記憶ではなく、そのとき表示されていた文言と、いつ起きたかという記録です。
航空機業界向けのEDI運用センターでは、システムエラーの問い合わせを受けるにあたって、エラーの発生日時、再現性、エラーの内容、エラーが発生した操作手順、利用しているクライアントのバージョンを本文に記載したうえで、通信ログ（communicationlog.csv）とエラーログ（errorlog.csv）を添付するよう案内しています²。
これは特定の業界センターと、そこで使う受注側クライアントに向けた運用なので、ログのファイル名や保存場所がそのまま他のEDIソフトに当てはまるわけではありません。
それでも、相手に調べてもらうために最低限どんな材料が要るのか、という観点では、自社の手順を組み立てる下敷きになります。

障害に気づいた時点で押さえておきたいのは、おおむね次のような情報です。
<ul><li>エラーメッセージの文言そのもの（要約ではなく、画面やログに出ている文字列とエラーコード）</li><li>発生した日時と、その前後に成功した通信の日時</li><li>どの操作をしたときに起きたか（定時の自動送信か、手動の再送か、受信の取り込みか）</li><li>同じ操作をもう一度すると同じ結果になるか</li><li>対象の取引先と、送受信しようとしたデータの種類・件数</li><li>EDIクライアントやパッケージのバージョン</li><li>通信ログとエラーログの所在</li></ul>

この中で後から取り返しがつかなくなりやすいのが、文言とログです。
エラーの画面は閉じれば消えますし、ログの保存方式は製品によって違うので、古いものが残り続ける保証はありません。
だからこそ、原因を考え始める前に画面を撮っておく、ログの該当時刻あたりを別のフォルダへ退避しておく、という一手が効いてきます。
ここで確保した材料は、このあと自分で切り分けるときにも、回線事業者や取引先へ問い合わせるときにも、そのまま使えます。

もうひとつ、同じタイミングでしか確かめられないことがあります。
それは「他はどうか」という比較です。
同じEDIで別の取引先とは送受信できているか、同じ回線で社内から外部のサイトが見られるか、別の端末や別の経路からでも同じエラーになるか。
障害が収まってから思い出そうとしても再現できないので、止まっている最中に一度だけ手を動かしておく価値があります。

現象から自社・回線・取引先のどこが疑わしいかを見分ける

データ形式エラーが出たとき

集めた材料のうち、切り分けの入口になるのはエラーの文言です。
自動車部品業界向けのEDIパッケージであるu-diEXのエラーコード一覧では、エラーが「転送ファイルのデータ内容に誤りがある」データ形式エラー、「指定時間待ったが受信できない」通信タイムアウト、「ゲートウェイとの接続に失敗した」接続エラー、そしてシステムやハードウェアの障害、といった形で分類されています⁴。
文言そのものはベンダーごとに違いますが、大きくどこで引っかかったのかという見方は、ほかのEDIでも共通して使えます。

データ形式エラーは、送ったファイルの中身が受け取る側の決まりに合っていない、という知らせです。
ここで一度立ち止まって考えたいのは、このエラーが出たということは、少なくともファイルは相手のところまで運ばれている、という点です。
通信そのものが成立していなければ、中身を検査してもらうところまで進みません。
つまりデータ形式エラーが出ている時点で、回線や経路を疑う優先度は下がり、自社側でファイルを作っている工程や、送信パラメータの設定を先に見るほうが早い、というのが本記事の見立てです。

具体的には、基幹システムから吐き出したファイルの項目桁数やコード値、ヘッダーの取引先コード、改行コードや文字コードの指定、ファイル名の命名規則あたりが候補になります。
直前に成功していた通信があるなら、そのときのファイルと今回のファイルを見比べるのがもっとも近道です。
マスタを更新した、新しい商品や新しい出荷先を扱い始めた、システムを更新した——そうした変化が直前にあれば、そこが起点になっている可能性を先に潰せます。

通信タイムアウトが出たとき

通信タイムアウトは、指定した時間だけ待ったけれど受信できなかった、という状態です⁴。
データ形式エラーと違い、相手まで届いたのかどうかがこの文言だけでは分かりません。
途中の経路で止まっているのか、相手のサーバーが受け付けはしたが応答を返していないのか、どちらもあり得ます。

ここで手がかりになるのが、前の節で押さえた「他はどうか」と「いつ起きたか」です。
同じ時間帯に別の取引先とは問題なくやり取りできているなら、自社から外へ出るところまでは動いている可能性が高く、疑いは相手側か、その相手との経路に寄ります。
逆に、どの取引先へもタイムアウトしているなら、自社の出口側——ファイアウォールやプロキシ、回線そのもの——を先に見るほうが理にかないます。

時刻の偏りも見ておく価値があります。
毎日同じ時刻の定時送信だけが失敗する、月初や締め日だけ失敗する、といった偏りがあるなら、瞬間的な断線よりも、その時間帯に集中する処理や相手側のバッチ処理と重なっている可能性を考えられます。
一方で、時間帯に関係なく不規則に起きているなら、経路上のどこかで断続的に切れている疑いが残ります。
この段階ではまだ確定できませんが、どちらの筋で問い合わせるかが変わるので、分かる範囲で記録しておきます。

接続エラー・応答なしが出たとき

接続エラーは、ゲートウェイとの接続に失敗した、つまり通信を始める段階で相手に取り付く島がなかった状態です⁴。
タイムアウトが「待ったが返ってこない」なら、接続エラーは「そもそも繋がらない」。
自社のネットワーク機器の設定変更、名前解決、接続先のアドレスやポートの変更、証明書の期限切れ、送信元IPアドレスの制限といったあたりが、実務でよく引っかかる場所です。

ここで効いてくるのが、自社がどの通信手順でつないでいるかという前提の把握です。
流通BMSでは、AS2、ebMS、JX手順といった複数の通信プロトコルが規定されていて、プロトコルごとに接続に必要な機能が定められています¹。
これは小売・卸・メーカー間のBtoB受発注のための標準なので、金融や他業界のEDIでは別の手順が使われますが、「手順によって、接続の成立に何が必要かが違う」という構図はどこでも変わりません。
証明書を使う手順なのか、固定IPでの接続許可が前提の手順なのかが分かっていなければ、接続エラーの原因候補を絞りようがないからです。

システムやハードウェアの障害として通知される場合は、自社で打てる手がほとんどありません⁴。
この分類に当たるメッセージが出ているなら、切り分けを続けるより、運用センターやベンダーの障害情報を確認し、窓口へ連絡するほうが早く進みます。

出典：トヨタシステムズ「u-diEX パッケージ エラーコード一覧」（確認時点／自動車部品業界向けEDIパッケージのエラー分類。「先に見る範囲」は本記事の見立て）

回線側が原因と疑われるときの連絡と対応の目安

故障通知までの目安

どの取引先とも通信できず、社内から外部への通信も怪しい——そこまで来たら回線側を疑う段階です。
ここで知っておきたいのは、回線事業者への連絡が「原因を突き止めてもらうための依頼」であると同時に、契約上の時間の物差しに乗る行為でもある、ということです。

NTT西日本のサービス品質保証制度では、同社が故障を知ってから30分以内に、あらかじめ指定されたメールアドレスへ故障を通知できなかった場合に、月額料金の一部を返還すると定めています³。
ここで基準になっているのは「事業者が故障を認知してから」の時間です。
つまり、自社のほうが先に異常に気づいている場面は普通に起こり得ますし、その場合に待っていても通知は来ません。
気づいた側から故障受付へ連絡することが、結果的に早いことになります。

この通知先は事前に指定しておくものなので、担当者の異動や退職でメールアドレスが生きていない、という状態が起こり得ます。
障害の最中に気づくとどうにもならないため、平時に見ておく対象のひとつです。

故障復旧までの目安

復旧までの時間についても、同じ制度の中に基準があります。
ただし一律ではなく、契約しているサービスによって免責となる時間が異なります。
ビジネスイーサ ワイド（デュアル）では故障の継続が10分未満であれば免責、10分以上で返金の対象となり、Interconnected WANでは30分未満が免責、30分以上で返金の対象とされています³。
あわせて、月間の稼働率が99.99%を下回った場合に返還の対象となる基準も置かれています³。

これらはNTT西日本の特定の法人向けサービスについての規定であり、他社の回線や専用線、クラウド型のサービスにそのまま当てはまる数値ではありません。
自社が実際にどの事業者のどのプランを使っていて、その契約ではどう書かれているかは、個別に確認する必要があります。
ここで読み取ってほしいのは金額のことよりも、時間の設計のほうです。

免責の時間が設けられているということは、その程度の短い停止は起こり得るものとして契約上扱われている、ということでもあります。
数分から数十分の停止が業務上まったく許されない作りになっているなら、返金を受けるかどうかより、その時間を再送や待ち受けで吸収できるようにしておくほうが実務的な備えになります。
逆に、EDIの送受信に数時間の猶予がある業務なら、短い停止は許容し、復旧を待つ判断もできます。
切り分けの最中にこの見極めができていると、取引先へ「何時までに復旧しなければ代替手段に切り替える」と伝える線引きがしやすくなります。

取引先側が原因の可能性を確認する問い合わせの仕方

自社側のファイルにも設定にも思い当たる変更がなく、回線も正常に見える。
他の取引先とは問題なくやり取りできている。
そこまで絞り込めたとき、残るのは相手側で何かが起きている可能性です。
ただ、この確認はやり方を間違えるとまったく進みません。

「そちらで障害は出ていませんか」とだけ尋ねても、相手が返せるのは「特に報告は上がっていません」で終わりがちです。
相手が調べられるのは自分たちの受信記録なので、いつ、どのデータを、どの手順で送ったのかが分からないと、探しにいく場所が定まらないからです。
逆にいえば、こちらが渡すべきなのは推測ではなく、照合できる事実のほうです。

この点で参考になるのが、業界のEDI運用センターが実際に求めている項目です。
航空機業界向けのEDIセンターでは、システムエラーの問い合わせをメールのみで受け付けたうえで、エラーの発生日時、再現性、エラーの内容、発生した操作手順、クライアントのバージョンを本文に記載し、通信ログとエラーログを添付する運用としています²。
これは一つの業界センターの例であり、他の業界や他のベンダーでは、電話の可否を含めて受付方法も求める項目も違います。
自社の取引先や運用センターが公開している窓口案内を確認したうえで、足りない項目を足していくのが実際の進め方になります。

項目の並びをそのまま真似するよりも、なぜその項目が要るのかを押さえておくと応用が利きます。
発生日時は相手の受信ログを引き当てるための鍵で、ここがずれていると探しても見つかりません。
再現性は、一度きりの事象として様子を見るのか、継続して調査するのかという相手の判断を分けます。
操作手順とクライアントのバージョンは、相手側で同じ条件を再現できるかどうかに関わります。
そしてログは、こちらの主張の裏づけであると同時に、相手のログと突き合わせる材料になります。

もうひとつ、技術的な問い合わせとは別に伝えておきたいことがあります。
それは業務としての影響です。
届いていない発注データが何件分で、いつまでに処理できなければ出荷や納期に響くのか。
技術の窓口と業務の担当者は別の人であることが多く、技術側の調査が進んでいても、業務側が代替手段を判断できていないという行き違いが起こります。
切り分けの連絡と並行して、業務への影響を業務の担当者へ伝えておくと、復旧を待つか、当日分だけ別の手段で回すかの判断が早くなります。

切り分け結果を回線事業者・EDIベンダー・取引先へどう伝えるか

ここまでで、現象の分類から疑わしい箇所の見当をつけ、回線事業者と取引先それぞれに何を伝えるかを見てきました。
実際の障害では、これらを順番に一つずつ潰していく余裕がないことも多いはずです。
そこで最後に、連絡先ごとに用意しておく材料を並べておきます。

注意したいのは、同じ「障害の連絡」でも、相手によって知りたいことが違う点です。
回線事業者が扱えるのは回線の区間であって、EDIのファイルの中身ではありません。
EDIのベンダーや運用センターが見られるのは自社のクライアントと相手のセンター側の記録であって、回線の物理的な状態ではありません。
取引先の業務担当者が判断できるのは納期と代替手段であって、どちらも原因の特定ではありません。
相手の守備範囲に合わない情報を大量に送ると、切り分けはかえって遅くなります。

連絡の順番に唯一の正解はありませんが、判断が分かれやすいのは、EDIベンダーと取引先の窓口のどちらを先にするかという場面です。
自社のクライアントにエラーコードが出ていて、そのコードの意味が自社では読み切れないなら、ベンダーや運用センターが先です。
コードの意味は分かっていて、自社側の設定にもデータにも変更がないと言い切れるなら、相手側の受信記録を突き合わせるほうが早いので、取引先の窓口が先になります。
回線を疑う根拠がある場合は、回線事業者への連絡だけは並行して進めて差し支えありません。
回線側の調査は自社の作業を止めないからです。

そして、どの窓口に連絡する場合も、最初の節で確保した材料がそのまま使えます。
逆にいえば、最初にそこを押さえていないと、連絡のたびに「その時刻はいつでしたか」「ログはお持ちですか」と聞き返され、そのやり取りのあいだ業務は止まったままになります。
切り分けの手順が結局は初動の記録に戻ってくるのは、このためです。

再発時の切り分けを早めるための平時の準備

障害が収まったあと、たいていは通常業務に戻って終わります。
ただ、ここまで見てきたとおり、問い合わせの入口では通信ログとエラーログの提出が前提になっている場面があります²。
その場で探し回らずに済む状態にしておくと、次に同じことが起きたときの時間の使い方が変わります。
以下は、確認できた一次資料の範囲を超えて基準が定まっているものではないため、編集部としての提案として読んでください。

まず、自社で使っているEDIソフトについて、ログがどこに出力され、どのくらいの期間または件数分が残るのかを一度確かめておく。
保存方式は製品によって違うので、「何日分残るのか」は自社の環境で確認するしかありません。
もし障害の調査に使いたい期間より短いなら、退避の仕組みを用意するか、保存設定を見直す余地があります。

次に、連絡先を一つの場所にまとめておく。
回線事業者の故障受付、EDIソフトのベンダーの窓口、取引先ごとの運用センターと業務担当、そして社内で判断できる人。
受付の方法もあわせて書いておくと迷いません。
先に触れた業界のEDIセンターのように、問い合わせをメールのみで受け付けている窓口もあります²。
電話が通じないことを障害の最中に知るのと、事前に知っているのとでは、初動の落ち着きが違います。

あわせて、自社がどの取引先とどの通信手順でつないでいるかの一覧も、同じ場所に置いておく価値があります。
接続の成立に必要な条件は手順によって異なるため¹、証明書の期限やIPアドレスの許可設定など、期限や設定変更で切れる可能性のあるものが見える形になっていると、接続エラーが出たときの候補をすぐ絞れます。

そして、自社が契約している回線のサービス品質保証の内容です。
通知先として登録してあるメールアドレスが今も有効か、復旧の基準がどうなっているか。
本記事で挙げた数値は特定の事業者の特定サービスのものなので、自社の契約書や約款で読み替える必要があります³。

これらを揃えても、障害そのものが起きなくなるわけではありませんし、復旧が早まると約束できるものでもありません。
減らせるのは、障害が起きてから「どこに何があるか」を探す時間と、窓口とのあいだで往復する確認のやり取りです。
止まっている最中の数十分は、その分だけ業務の判断に回せます。

ここまでが、障害に気づいてから連絡までを一続きに進めるための型です。
あとは自社の契約内容と、取引先ごとの窓口の作法に合わせて、項目を置き換えていくことになります。

現象の分類までは自社で進められても、自社のEDIがどの手順でどこと繋がっていて、どのログにどこまで残っているかは、構成を把握していないと当日に辿れません。

現在の受発注データの流れと、止まったときに手元へ残る記録の範囲を一緒に確認し、どこまでを自社で切り分けられる状態にできるかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
最初に押さえる材料	エラーの文言とコード、発生日時、再現性、操作手順、クライアントのバージョン、通信ログとエラーログ
データ形式エラー	相手まで届いている前提で、自社のファイル生成と送信パラメータを先に見る
通信タイムアウト	他の取引先との通信可否と時間帯の偏りから、経路側か相手側かを寄せる
接続エラー	自社の出口設定と回線、通信手順ごとの接続条件（証明書・IP許可など）を確認する
回線事業者への連絡	契約しているサービスのSLAで、通知と復旧の基準がどう定められているかを自社の契約で確認する
取引先への連絡	送信日時・データの種類と件数・再現性・ログを揃え、技術窓口と業務担当へ内容を分けて伝える

平時の準備は項目を並べるだけなら難しくありませんが、取引先ごとに手順も窓口も違うため、自社の取引構成に合わせて落とし込む段階で手が止まりがちです。 取引先ごとの通信手順と窓口、ログの保存状況を棚卸しして、次の障害でどこから手を付ければよいかを決めておく形に落とせます。

よくある質問

EDIの通信ログと、取引先側の運用センターに提出するログは何が違うのですか

別物というより、提出するのは自社のクライアントが記録しているログです。
航空機業界向けのEDIセンターの案内では、通信ログ（communicationlog.csv）とエラーログ（errorlog.csv）をメールに添付するよう求めています²。
通信ログは、いつどの相手とどのやり取りを行ったかという記録、エラーログはそのうち失敗した事象の記録にあたります。
センター側は自分たちの受信記録を持っているので、こちらのログと突き合わせることで、どちらまで届いていたかを判断できます。
ファイル名や出力場所は使っているEDIクライアントによって異なるため、自社の製品の仕様で確認してください。

回線事業者のSLAによる返金を受けるには、何が必要ですか

返還の条件は契約している事業者とサービスごとに定められているため、まずは自社の契約内容を確認することになります。
たとえばNTT西日本のサービス品質保証制度では、故障を知ってから30分以内に指定のメールアドレスへ通知できなかった場合や、月間稼働率が99.99%を下回った場合に、月額料金の一部を返還するとされています³。
故障の継続時間についてはサービスごとに免責の線が異なり、ビジネスイーサ ワイド（デュアル）は10分未満、Interconnected WANは30分未満が免責とされています³。
いずれも同社の特定の法人向けサービスに関する規定なので、他社の回線には当てはまりません。
実務としては、障害の発生と復旧の日時を自社でも記録しておくことと、通知先のメールアドレスが有効な状態になっていることが前提になります。

EDIベンダーと取引先の運用窓口、どちらに先に連絡すべきですか

手元にある情報で分かれます。
エラーコードや文言の意味が自社で判断できないなら、その製品を作っているベンダーや運用センターに先に当たったほうが早く進みます。
コードの意味は分かっていて、自社側の設定やデータに変更がないと言い切れる状態なら、相手の受信記録と突き合わせるために取引先の窓口を先にするほうが近道です。
なお、回線を疑う根拠がある場合の故障受付への連絡は、他の調査を止めないので並行して構いません。

障害の再発に備えて、平時にどんな連絡先リストを整えておくとよいですか

確認できた一次資料の範囲で書式が定まっているものではないため、編集部としての提案になります。
回線事業者の故障受付、EDIソフトのベンダー窓口、取引先ごとの運用センターと業務担当、社内で判断できる人、という四つの宛先を一覧にし、それぞれ受付方法（電話が使えるのか、メールのみか）を添えておく形です。
業界のEDIセンターの中には問い合わせをメールのみで受け付けているところもあるため²、受付方法を事前に把握しておくと初動で迷いません。
あわせて、取引先ごとの通信手順と、証明書の期限やIP許可など接続条件に関わる情報も同じ場所にまとめておくと、接続エラー時の候補を絞りやすくなります。

1. 1　出典：一般財団法人流通システム開発センター（流通BMS協議会／GS1 Japan）「流通ビジネスメッセージ標準（流通BMS）標準仕様」（確認時点）
2. 2　出典：株式会社中電シーティーアイ（航空機業界EDI運用センター運営）「航空機業界EDIセンター EDIシステムエラーに関する問い合わせ」（確認時点）
3. 3　出典：西日本電信電話株式会社「サービス品質保証制度（SLA）」（確認時点）
4. 4　出典：トヨタシステムズ株式会社「u-diEX パッケージ エラーコード一覧」（確認時点）