EDIで発注データが届かない・応答がない障害、発注側はどう原因を切り分けるか

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

B2B EC-COLUMN

障害に気づいたときの状況整理と切り分けの大枠

送信したはずの発注データについて、受注側から「届いていない」と連絡が入る。
あるいは送信処理を実行したまま、完了表示も応答も返ってこない。
こういうとき、自社の回線を疑うのか、VAN事業者や相手先に連絡するのかで迷い、その迷っている時間だけ出荷が遅れます。
切り分けの入り口になるのは、自社が使っている通信手順です。
電話回線と専用モデムを使う旧来のJCA手順か、インターネット回線を使う流通BMS系のプロトコルかで、疑うべき機器も連絡先も変わります。
さらに契約しているVANサービスに送受信状況の照会機能があれば、相手に問い合わせる前に、自社の送信が届いているかどうかまで自分で確かめられます。

「送信済み」の表示が出ているのに受注側から発注データが来ていないと電話が入る。
あるいは送信処理を走らせたまま、完了の表示も応答ファイルも返ってこない。
どちらも「EDIの障害」と一括りにされますが、担当者が次に取るべき行動は同じではありません。
前者は、少なくとも自社の送信処理は最後まで動いています。
後者は、そもそも通信が始まっているのかどうかすら分かっていません。
最初にやるべきなのは原因の特定ではなく、いま目の前で起きている事実をこの粒度まで言葉にすることです。

控えておきたいのは、発生した時刻、相手先、送ろうとしたデータの種類と件数、そして画面に出ているエラーの文言やコードです。
これらは後でVAN事業者や受注側へ問い合わせるときにそのまま必要になります。
自分の記憶だけで「さっき送ったはずなのですが」と話し始めると、相手側でも該当するログを探しようがありません。
特にエラーコードは、数字や記号の並びを正確に写しておくかどうかで、その後の調査の速さが変わります。
画面を閉じてしまうと二度と同じ表示に戻せないこともあるため、分からないコードほど先に控えておくほうが安全です。

次に見たいのは、症状が出ているのが一社だけなのか、複数の取引先にまたがっているのかです。
一社だけで止まっているなら、その相手との接続設定や、相手側の受信環境に目が向きます。
複数社で同時に起きているなら、個々の相手先よりも、自社の回線・機器・EDIアプリケーション、あるいは経由しているVANサービス側を先に疑うほうが筋が通ります。
もちろん偶然が重なることはありますし、これだけで原因が決まるわけでもありません。
それでも、限られた時間の中でどちらから当たるかを決める材料にはなります。

もう一つ、意外と見落とされるのが「誰が最初に気づいたか」です。
自社の画面のエラーで気づいたのか、受注側からの連絡で気づいたのかによって、すでに経過している時間がまるで違います。
相手からの連絡で知った場合、その時点で発注はかなり前に止まっている可能性が高く、原因の切り分けと並行して、当日分をどう通すかを考え始める必要が出てきます。

ここまでの事実が揃うと、原因の所在を大きく二つに分けて考えられます。
一つは自社内、つまり端末とEDIアプリケーション、通信に使う機器、そして回線です。
もう一つは自社外で、VAN事業者、受注側、通信事業者が入ります。
ただし、この二分は業界で定められた標準的な切り分け手順というわけではなく、本記事が説明のために置いている整理です。
実際の対応は、契約しているEDIシステムやVANサービスの案内に従ってください。
それでもこの分け方を先に置いておくと、以降で扱う事実——自社が使っている通信手順の違いや、VANサービスに備わっている照会機能——が、それぞれどちら側を確かめるための材料なのかを見失わずに済みます。

利用している通信手順によって、疑うべき機器と確認ポイントが変わる

自社内を確認するといっても、見るべき機器は会社によって違います。
その違いを決めているのが、EDIで使っている通信手順です。
流通業界のEDIには、電話回線と専用モデムを使う旧来のJCA手順と、インターネット回線を使う流通BMS系のプロトコルという、成り立ちの異なる二つの系統があります。
自社がどちらを使っているかが分かれば、疑う機器と、最終的に連絡する相手先がかなり絞り込めます。
「うちはEDIを使っている」という認識だけで、手順の名前までは把握していないという状況は珍しくありません。
障害の最中に調べるには重い情報なので、平常時に一度、接続の仕様書や申込書を確認しておく価値があります。

JCA手順（電話回線・専用モデム）の場合

JCA手順は、BSC伝送制御手順に準拠した標準制御手順として、1982年7月に通商産業省により流通業界全般の標準通信手順（J手順）として制定されたものです¹。
制定にあたったのは日本チェーンストア協会と通商産業省（当時）で、受発注データをやりとりするためのプロトコルとして定められました²。
四十年以上前の仕組みが今も現役で動いているというのは、それだけ取引の土台として定着したということでもあります。
ただし障害対応の観点では、当時の技術的な前提をそのまま引きずっているという意味にもなります。

前提の一つが回線の速度です。
JCA手順が使う電話回線の速度は2400bpsまたは9600bpsで、流通BMSが使うブロードバンド回線の速度は遅くても1Mbpsとされています²。
桁がいくつも違うので、「送信が始まっているのに終わらない」「時間内に処理しきれない」といった症状は、機器の故障ではなく手順そのものの上限に当たっている可能性があります。
つまり、故障を疑って機器を見る前に、その日に送ったデータの件数が普段より多くなかったかを確認する意味があります。
月末や特売前など、発注量が跳ね上がる日と症状が重なっていないかは、簡単に確かめられる手がかりです。

もう一つの前提が機器です。
JCA手順には専用のモデムが必要ですが、生産する企業が少なくなっており、故障したときに新しいモデムを入手するのが非常に困難だと指摘されています²。
この点は、他の障害と性格が違います。
多くの機器トラブルは「交換すれば直る」ものですが、専用モデムの故障は交換品が手に入るかどうかから考えなければならない障害です。
したがって、モデムのランプの状態や電話回線側の状況を確認する作業と並行して、予備機があるか、なければ当面どうやって発注を通すかを早い段階で考え始めることになります。
切り分けが終わってから復旧手段を探し始めると、その間ずっと発注が止まります。

なお、JCA手順には後継にあたる仕組みもあります。
OSIモデルの一つであるMHSを採用した取引先データ交換標準手順（JCA-H手順）が開発されており、ISDN回線や専用回線を利用します¹。
社内で「うちはJCA手順だ」と言われていても、実際にどの世代の手順で、どの回線を使っているかは契約によって異なります。
回線の種類が違えば、障害時に連絡する通信事業者の窓口も変わります。
ここは自社のEDIサービスの仕様書や接続の案内で確かめるしかない部分で、一般論では代えられません。

流通BMS系プロトコル（JX手順・AS2・ebXML MS／インターネット回線）の場合

インターネット対応のEDIである流通BMSでは、サーバー間通信にebMSとAS2、クライアント-サーバー通信にJX手順が、国際標準技術として採用されています¹。
押さえておきたいのは、この二つで通信の形が違うということです。
サーバー間通信は、自社のサーバーと相手のサーバーが直接やりとりします。
クライアント-サーバー通信は、クライアント側から相手のサーバーへ接続しにいきます。
どちらの形なのかで、障害が起きたときに「自社側が動いていないのか」「相手が受け付けていないのか」の見え方が変わります。
自社が接続を出しにいく形であれば、少なくとも接続を試みた記録が自社側に残っているはずだからです。

専用モデムと電話回線に依存しない代わりに、確認の対象はインターネット回線とネットワーク機器、それに接続設定の側へ移ります。
この点について、業界共通の確認手順として示せる資料は今回見つけられませんでした。
そのため具体的な確認の進め方は本記事の提案になりますが、直前に自社側で行われた変更——ネットワーク機器の入れ替え、ファイアウォールの設定変更、EDIアプリケーションやサーバーの更新——を洗い出すところから当たると、原因に近づきやすくなります。
何も変えていないのに突然止まったのか、変更の後から止まったのか。
この違いは、自社内と自社外のどちらを先に疑うかを決める情報になります。

回線速度の桁が違う分、JCA手順で起きていた「データ量が増えると時間内に収まらない」という種類の症状は、流通BMS系では起きにくくなります²。
ただしこれは通信速度の話であって、接続そのものが確立しない、相手のサーバーが応答しないといった障害がなくなるわけではありません。
疑う場所が移るのであって、障害の可能性が消えるわけではない、と捉えておくほうが実務に合います。
移行を検討している段階の担当者ほど、この区別は持っておいたほうがよいところです。

EDIアプリケーション・ログでどこまでデータが届いているかを確認する

回線も機器も見たかぎり異常がない。
それなのに送れない。
このとき次に見るのがEDIアプリケーションのログです。
ログは「エラーが出ているかどうか」を見る場所だと思われがちですが、実際にはどこまで進んだかを教えてくれる記録でもあります。

JCA手順を使っている場合、ログの読み方に手がかりになる構造があります。
JCA手順では、伝票データを表す「データ電文」と、通信を制御するための「制御電文」が分けて定義されており、「開始要求電文」によって配信（送信）や集信（受信）が始まります²。
ここで効いてくるのが、送信が始まる前に止まっているのか、データを送り終えた後で応答が返らないのか、という区別です。
同じ「送れない」でも、この二つは意味がまったく違います。

開始要求電文の段階で止まっているなら、相手に届く前の問題である可能性が濃くなります。
接続そのものが確立していない、つまり回線や機器、接続設定の側に目を戻すことになります。
一方、データ電文を送り切った後で止まっているなら、送信自体は通っていて、相手側の処理や応答の返却で詰まっている可能性が出てきます。
この場合、自社内をいくら探しても原因は見つかりません。
電文の段階ごとに処理が分かれている構造を踏まえてログを読むと、この見当がつけやすくなります。

ただしこれは、JCA手順の電文構造に基づく見方です。
流通BMS系のプロトコルではメッセージの構造が異なるため、同じ電文の区分でログを追うことはできません。
その場合に確かめておきたいのは、自社のEDIサービスが出力するログやステータス表示が、どの段階までを「完了」として記録しているのかという点です。
送信処理の完了と、相手の受信完了は同じ意味とは限りません。
画面が「送信済み」になっていても、それが自社のアプリが送信処理を終えたという意味なのか、相手から受領の応答を受け取ったという意味なのかで、次に確認する場所は変わります。
ここは仕様書で一度確かめておくと、障害のたびに悩まずに済みます。

エラーコードについても同じことが言えます。
コードが出ているなら、それが自社アプリの出したものなのか、通信の相手から返ってきたものなのかを見分けるだけで、問い合わせ先が変わります。
ここを曖昧にしたまま「エラーが出ました」とだけ伝えると、受け取った側は何から調べればよいか分かりません。
逆に、コードの出所まで添えて連絡できれば、相手はいきなり該当箇所のログを探せます。

自社に問題がなければ、VANサービスの機能で相手側・通信状況を確認する

自社側に明らかな異常が見つからなければ、次に知りたいのは、自社の送信が相手先に届いているかどうかです。
とはいえ、いきなり受注側の担当者に電話をかけて調べてもらうのは、時間の面でも関係の面でも後の手段にしたいところです。
相手にも相手の業務があり、調査を依頼すれば相手の時間を使うことになります。
契約しているVANサービスによっては、それを自分で確かめられる機能が用意されています。

たとえば、ある流通向けVANのサービスでは、Web運用照会として、自社の送受信状況や振分状況（振分エラーの有無）に加えて、送信先での受信状況をセミリアルタイムで照会できます³。
送信先での受信状況まで自分で見られるなら、「自社からは出ている」「相手のところまで届いている」という二つを、問い合わせなしで確認できます。
原因の所在を自社外に移してよいかどうかの判断が、ここで一段はっきりします。
届いていないことが確認できた場合も、少なくともどの区間までは通っていたかが分かるので、問い合わせの内容が具体的になります。

同じサービスには、チェックリストメール連絡サービスとして、振分エラー、FAX配信状況、送信先での未受信状況、メーカーからのエラー通知を電子メールで知らせる機能もあります³。
障害に気づくきっかけが相手からの電話なのか、こうした通知メールなのかは、対応に使える時間の差になります。
ここで確認しておきたいのは、通知を受け取れる仕組みがあるのに、宛先が担当者個人のままになっていないかという点です。
受け取る人が休みだった日に通知だけが届いていた、という状態は運用のずれで、平常時に見直せます。

さらに、緊急時用アップロード／ダウンロードサービスとして、システムトラブルで正常に送受信できない場合に、Web画面からEDIデータをアップロード・ダウンロードできる機能も案内されています³。
原因の切り分けと復旧は本来別の作業です。
ただ、発注業務のほうは原因が分かるまで止めておけるとは限りません。
代替手段があるなら、切り分けを続けながら当日分の発注だけは通す、という並行した動き方ができます。
逆にこうした手段がないと、切り分けが終わるまで発注が完全に止まり、担当者は原因究明と納期の心配を同時に抱えることになります。

ただし、ここで挙げた機能は特定の事業者が自社サービスとして案内しているものです。
VAN事業者やEDIサービスごとに、機能の有無も呼び名も異なります。
自社の契約にこうした照会・通知・代替手段が含まれているかどうかは、障害が起きてから探したのでは間に合いません。
含まれていない場合はサポート窓口へ連絡することになりますが、そのときに伝える内容は、最初に控えた事実——発生時刻、相手先、データの種類と件数、エラーの文言、症状が一社だけか複数社か、自社側でどこまで確認したか——がそのまま使えます。
自社で確認した範囲を添えるかどうかで、相手が同じ確認を繰り返す時間を省けます。

切り分けた結果を記録し、再発時に備える

障害が復旧すると、原因が分かった安心もあって、記録は後回しになりがちです。
ただ、EDIの障害は同じ組み合わせで繰り返すことがあります。
残しておきたいのは、発生日時と症状、確認した順番とその結果、最終的に判明した原因、そして実際に対応してくれた窓口です。
特に窓口の連絡先は、次に同じ症状が出たときに探し直す手間が丸ごと消える情報です。

記録の効き目は、確認の順番を省略できるという一点に集約されます。
前回、複数社で同時に送信できず、原因が自社側のネットワーク機器だったと分かっていれば、次に同じ症状が出たときは同じ場所から見始められます。
逆に前回が一社だけの症状で、相手側の受信環境が原因だったなら、他の取引先への送信が通っているかを先に確かめることになります。
どちらも、ゼロから切り分け直す時間を削る話です。

これは、記録があれば障害が起きなくなるという話ではありませんし、対応時間がどれだけ短くなるかを示せる調べもありません。
あくまで実務上の提案です。
それでも、担当者が一人しかいない体制で、その人が不在のときに障害が起きる場面を想像すると、書いてあることの価値は変わってきます。
EDIの運用を業務担当者が兼務している場合、知識がその人の頭の中にしかないという状態は珍しくありません。
様式や保管場所は自社の情報システムの管理規程に合わせれば十分で、共有フォルダの表計算ファイル一枚でも、次の人が同じ道をたどれるなら役目は果たします。

もう一つ、平常時にやっておけることがあります。
自社が使っている通信手順、接続の仕様書の置き場所、VANサービスの照会機能や緊急時の代替手段が契約に含まれているか、サポート窓口の連絡先と受付時間。
これらは障害の最中に調べるには重すぎる情報です。
しかも、調べている間も発注は止まったままです。
切り分けの速さを決めているのは、技術的な知識よりも、障害が起きる前に手元に揃っていた情報の量だったりします。
今回の障害対応が一段落したところが、それを揃える良いタイミングです。

最後に、通信手順ごとに確認の入り口がどう変わるかを一覧にしておきます。

切り分けの順番は整理できても、自社の接続がどの通信手順で、どこを経由しているのかは、契約書や仕様書を突き合わせないと分からないことが多い部分です。

現在の受発注の流れと接続の構成をうかがったうえで、障害が起きたときにどこから確認すればよいか、いま手元にない情報は何かを一緒に洗い出せます。無料相談で要件を整理する

JCA手順と流通BMS系プロトコルで確認すべき機器の違い

自社が使っている通信手順ごとに、障害時にまず見る設備と、その先で連絡する相手の系統で並べています。

• JCA手順：通信は電話回線と専用モデムを経由するため、まず見るのはモデムの状態と電話回線側になる。モデムは故障時の入手が困難とされており、切り分けと並行して代替手段の検討を進める必要がある

• JCA手順：回線速度は2400bps／9600bpsで、発注件数が普段より多い日に「送信が終わらない」という症状が出た場合は、故障よりも手順の上限を先に疑う余地がある

• JCA手順：ログは制御電文（開始要求電文）とデータ電文のどちらの段階で止まったかで読み分けられ、前者なら接続の確立、後者なら相手側の処理や応答の返却へ目が向く

• 流通BMS系（ebMS・AS2）：自社サーバーと相手サーバーが直接通信する形のため、確認の対象はインターネット回線・ネットワーク機器・接続設定の側へ移る（具体的な確認項目は本記事の提案）

• 流通BMS系（JX手順）：クライアント側から相手サーバーへ接続しにいく形のため、自社側から接続を出せているかが最初の確認点になる（本記事の整理）

• 共通：VANを経由している場合、送受信状況の照会や未受信の通知といった機能が契約に含まれているかどうかで、相手に問い合わせる前に自分で分かる範囲が変わる

要点の整理

軸	基準
症状の区別	「送信できない」のか「応答が返らない」のかを先に言葉にし、発生時刻・相手先・データ種別と件数・エラーの文言を控える
影響の範囲	一社だけか複数社かで、相手先側と自社側のどちらから当たるかを決める
通信手順	JCA手順なら専用モデムと電話回線、流通BMS系ならインターネット回線・ネットワーク機器・接続設定を見る
ログの読み方	JCA手順は開始要求電文で止まったかデータ電文の後かで読み分け、流通BMS系は「送信済み」が何を指すかを仕様書で確認する
自社外の確認	VANの送受信状況照会・エラー通知・緊急時の代替送信が契約に含まれるかを平常時に確認しておく
記録	原因・確認した順番・対応した窓口を残し、次回の確認順を短縮する

障害のたびに担当者が一人で切り分けている状態は、記録を残しても知識がその人に留まったままになりがちです。 復旧までの動き方と、平常時に揃えておきたい情報の範囲を、自社の体制と取引先の構成に合わせて確かめられます。

よくある質問

JCA手順を使っていて専用モデムが故障した場合、どう対応すればよいか

JCA手順専用のモデムは生産する企業が少なくなっており、故障時に新しいモデムを入手するのが非常に困難だとされています²。
そのため、交換品を探しながら復旧を待つという前提では発注が長く止まる可能性があります。
まず社内に予備機があるかを確かめ、なければ、契約しているVANサービスに緊急時の代替送信手段が用意されていないかを確認することになります。
あわせて、取引先へは復旧の見通しが立たない段階でも状況を伝えておくと、相手側で受注の準備を進めてもらえる場合があります。
どこで機器を調達できるか、どれくらいの期間がかかるかは今回の資料では示せません。
契約しているEDIシステムの提供元に、代替機の貸与や別の接続方式への一時的な切り替えができるかを聞くのが現実的な入り口です。

流通BMSに移行すると障害は起きにくくなるか

起きなくなるわけではなく、疑うべき場所が移ると考えるほうが実務に合います。
移行によって当てはまらなくなるのは、電話回線の速度に由来する制約と、専用モデムの調達の問題です。
流通BMSが使うブロードバンド回線は遅くても1Mbpsとされており、電話回線の2400bps／9600bpsとは桁が違うため²、データ量が増えた日に時間内に収まらないという種類の症状は起きにくくなります。
一方で、サーバー間通信にebMSやAS2、クライアント-サーバー通信にJX手順を使う構成では¹、接続そのものが確立しない、相手のサーバーが応答しないといった障害は残ります。
確認の対象がインターネット回線やネットワーク機器、接続設定の側へ移るぶん、障害時に連絡する社内の担当者も変わることがあります。

VAN事業者を切り替えると、障害時の確認方法も変わるか

変わります。
送受信状況をWeb画面で照会できるか、エラーや未受信をメールで通知してくれるか、システム障害時にWeb画面から代替で送受信できるかといった機能は、事業者が自社サービスとして提供しているものです³。
名称も提供範囲も事業者ごとに異なります。
そのため切り替えを検討する際は、料金や対応フォーマットだけでなく、障害が起きたときに自分で確認できる範囲がどこまでかを確かめておくと、運用開始後の対応の速さが変わります。
具体的には、送信先での受信状況まで見えるのか自社の送信状況までなのか、通知の宛先を複数登録できるのか、サポート窓口の受付時間が自社の発注業務の時間帯を覆っているか、といった点です。

受注側に確認を依頼する場合、何を伝えるとスムーズに調査してもらえるか

相手が自分たちのログを探せるだけの情報が揃っているかどうかで、返答までの時間が変わります。
伝えたいのは、送信した日時、送信先のコードや取引先の識別情報、送ったデータの種類と件数、自社側の画面に出ているエラーの文言やコード、そして自社でどこまで確認したかです。
最後の一点が抜けていると、相手は自社側で済んでいる確認を最初からやり直すことになります。
あわせて、他の取引先への送信は通っているかどうかも添えると役に立ちます。
他社へは問題なく送れているなら、自社の回線や機器ではなく、その相手との接続や相手側の受信環境を見てもらえばよい、という見当が相手側にも共有できます。

1. 1　出典：一般財団法人流通システム開発センター（GS1 Japan）「通信制御手順」（2026年参照）
2. 2　出典：TISI株式会社「JCA手順とは？流通BMSへの移行が迫られる流通業界の実情」（2026年参照）
3. 3　出典：株式会社プラネット「EDIサポート機能」（2026年参照）