EDI障害はどこで起きている？自社・通信経路・取引先を切り分ける手順

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

B2B EC-COLUMN

EDI障害の三層モデル：送れない・届かない・処理できないをまず区別する

「昨日送った発注データが届いていません」と取引先から連絡が入り、自社の画面を見ると送信済みの表示になっている。
受注側なら、いつも朝には入っているデータが、いつまで待っても入ってこない。
どちらの場面でも、再送ボタンを押す前に決めなければならないのは、止まっているのが自社なのか、通信経路なのか、取引先なのかという切り分けです。
自社のEDIソフトの送信ログ、VANの運用照会やエラー通知・エラーコード、そして取引先の受信・取り込み状況という順に見ていくと、原因がどの層にあるかを絞り込めます。
層が決まれば、社内で直せるのか、VAN事業者や取引先へ連絡すべきなのかが決まり、連絡するときに何を伝えればよいかも決まります。

三層のどこで止まっているかを判断する考え方

「データが無い」という症状は一つでも、その裏で起きていることは大きく三つに分かれます。
自社のEDIソフトが送信処理そのものを終えられていない「送れない」、送信は終わっているのに相手の受信箱まで行き着いていない「届かない」、相手のところには着いているのに基幹システムへ取り込まれていない「処理できない」です。
取引先から「届いていません」と言われた時点では、この三つのどれなのかは、まだ何も分かっていません。

切り分けを先にする理由は、層ごとに打ち手がまったく違うからです。
自社で止まっているなら自社で直せますが、経路や相手先で止まっているものを自社でいくら再送しても状況は変わりません。
それどころか、原因が分からないまま再送を繰り返すと、後から相手側で同じ伝票が二重に取り込まれ、受注の重複という別の問題を生みます。
最初の数分を「どこから見るか」に使うほうが、結果として復旧は早くなります。

切り分けに入る前に、そもそも障害ではない可能性を一つ外しておくと無駄足が減ります。
相手がまだ送信していない時間帯だった、自社の受信ジョブの実行時刻が来ていなかった、締め処理が終わっていないので当日分がまだ出力されていない、といった時刻のずれは珍しくありません。
受注側で「いつもの時間に入ってこない」ときは、いつもの時間が相手の送信時刻なのか自社の受信ジョブの時刻なのかを確かめると、待てばよいのか調べるべきなのかが分かれます。

層を切り分ける手掛かりは、自社のログだけでは足りないことが多く、間に立つVANが何を見せてくれるかに左右されます。
たとえばプラネットのEDI-VANでは、Web運用照会で自社の送受信状況と振分状況(振分エラーの有無)に加えて、送信先での受信状況までセミリアルタイムで照会できるとされています¹。
自社が送れたのか、相手に届いたのかという二つの層を、同じ画面で横断して確かめられる形です。

ただしこれは同社のサービスを契約している場合の機能で、利用しているVANやEDIソフトによって見える範囲は変わります。
そこで、原因そのものより先に確かめたいのが「自社は今どこまで自力で見えるのか」です。
相手の受信状況まで見えるなら三つの層を自分で追えますし、自社の送信ログしか見えないなら、二層目から先は問い合わせで埋めるしかありません。
この見通しがあるだけで、電話をかける相手と順番が変わります。

自社の送信ログとVAN振分エラーを確認する

送信ログ・振分エラーの確認

最初に見るのは自社のEDIソフトの送信履歴です。
確かめたいのは「送った」かどうかではなく、送信処理がどこまで進んで終わったのかという点です。
送信対象のファイルが作られているか、送信ジョブが起動しているか、通信セッションが確立したか、相手センターへ渡したところまで記録が残っているか。
ログの名称や画面の位置は製品ごとに違うので、操作そのものは自社が使っているソフトのマニュアルで確かめることになりますが、見たい情報の順番はどの製品でも変わりません。

ここでファイルが出力されていない、あるいは送信ジョブが起動した記録がないなら、原因は自社側です。
基幹システムからのデータ出力が失敗している、当日分の締め処理が終わっていない、送信スケジュールが止まっている、といった社内で手を打てる範囲に絞り込めます。
この段階で分かれば、VANにも取引先にも連絡せずに済みます。

もう一つ、症状の広がりを見ておくと層の見当がつきます。
複数の取引先向けのデータがまとめて出ていないなら自社の出力や送信の仕組みが疑わしく、一社分だけ、あるいは特定の伝票だけが届いていないなら、宛先の設定やデータの中身に目を向けることになります。
これは確定診断ではなく当たりの付け方ですが、最初にどのログを開くかを決めるには十分な材料です。

注意したいのは、送信ログが正常でも安心はできないことです。
VANは受け取ったデータを宛先ごとに振り分けており、その段階で宛先コードやデータ種別が設定と合っていないと弾かれます。
これが振分エラーで、自社から見れば送信は成功しているのに、相手には何も届きません。
プラネットのWeb運用照会では、送受信状況と併せてこの振分状況(振分エラーの有無)まで照会できるとされています¹。

新しい取引先を追加した直後や、扱うデータ種別を増やした直後の不達は、この振分の設定が原因になっていることがあります。
同社には、自社がどの取引先とどのデータ種でデータ交換しているかを確かめるWeb個別通信状況照会もあります¹。
そもそもその取引先・そのデータ種の通信が設定されていたのかが分かると、初めから設定が抜けていたのか、昨日まで動いていたものが今日だけ止まったのかを区別できます。
後者なら、設定ではなく当日の経路や相手側を見にいくことになります。

製品によって自動通知の有無が異なる点

切り分け以前の問題として、障害に気づくのが遅れるという壁があります。
EDIの送受信は夜間や早朝のバッチで動いていることが多く、失敗しても画面の前には誰もいません。
取引先からの電話で初めて知る、という発見の仕方になりがちなのはこのためです。

検知を自社のEDIソフトに任せられるかどうかは、製品のグレードによって変わります。
TOKAIコミュニケーションズのJFT/Lite Netでは障害通知機能は搭載されておらず、サイクル管理・スケジューリング・障害通知は上位のJFT/Serverが備える機能とされています²。
同じ製品系列でも、失敗を自動で知らせてくれる構成とそうでない構成があるということです。
自社が後者なら、朝いちばんに人が送受信結果を目で見るまで、障害は見つからないままになります。

もう一つの検知手段は、VAN側からの通知です。
プラネットのチェックリストメール連絡サービスでは、EDIデータの振分エラー、FAX配信状況、送信先での未受信状況、メーカーからのエラー通知が電子メールで知らされます¹。
なかでも「送信先での未受信」は、自社のログをいくら眺めても出てこない情報です。

今回の障害対応が一段落したら、自社ソフトで検知しているのか、VANの通知で検知しているのか、人の目視に頼っているのかを契約内容と照らして確かめておくと、次の一件の発見が早まります。
通知が一つ増えれば事故が起きなくなるわけではありませんが、気づくまでの時間と、その間に積み上がる未処理の受発注は減らせます。
どの層の異常を誰が最初に知るのかが決まっていない状態からは抜け出せます。

通信経路(回線・プロトコル・VAN)側の問題を見分ける症状

無通信タイムアウト・ACK未達のサイン

自社の送信ログは正常、振分エラーも出ていない。
それでも相手に届いた形跡がないときは、経路の途中で応答が返っていない可能性を見ます。

通信手順には、相手が受け取ったことを知らせる応答の仕組みがあり、その応答が決められた時間内に返らないとエラーとして記録されます。
JFT/Lite Netの「論理ACK受信待ちエラー」は、設定された無通信監視タイムアウトの値を過ぎても通信相手から応答がないことを示し、通信相手先やネットワークに問題が発生している可能性があるとされています²。
自社は送り出しているのに、その先で応答が途絶えている、という形の記録です。

この種のエラーが出ているときに疑うのは、回線やVPNの断、相手センターの停止やメンテナンス、受信側の混雑による処理遅延です。
いずれも自社の中では直せません。
同じ時間帯に複数の取引先との通信が同様に止まっているなら自社の回線側、一社との通信だけが止まっているならその相手先または相手までの経路、という見当も立てられます。
断定はできませんが、最初にどちらへ電話するかを決める手掛かりにはなります。

気をつけたいのは、エラーの名称が製品や通信手順ごとに違うことです。
論理ACK受信待ちエラーはJFT/Lite Netでの表示であり、全銀TCP/IP手順やJX手順、AS2手順を使っている環境では、同じ「応答が返らない」状況が別の名前で記録されます。
自社が使っている手順と製品のマニュアルで、応答待ちやタイムアウトに当たるエラーがどう表示されるのかを平時に一度引いておくと、障害の最中に名前の意味で迷わずに済みます。

AS2のMDN(受信確認)が返らない場合

インターネットEDIで使われるAS2手順には、受信側が送信側へ開封通知であるMDNを返信する仕組みがあり、これによって送信否認・受信否認を防止するとされています³。
もともとは「送った・送っていない」の水掛け論を避けるための証跡ですが、障害の最中には切り分けの材料として使えます。

MDNが返っていれば、データは少なくとも相手のEDIサーバまで届いています。
この場合、経路の問題は考えにくく、次に見るのは相手側の取り込みです。
逆にMDNが返っていなければ、経路か相手の受信サーバのどちらかで止まっていることになり、確認の相手はVAN事業者や回線側へ向かいます。

ここで混同しやすいのが、MDNは受信された証跡であって、相手の基幹システムに取り込まれた証拠ではないという点です。
受信はできていても、そこから先の取り込み処理でフォーマットや商品コードの不一致になっていれば、相手の担当者の画面に発注は現れません。
「MDNは返っているのに相手は届いていないと言う」という状況は矛盾ではなく、三層目で止まっているサインとして読めます。
この読み方ができると、相手に確認する内容も「届いたか」から「取り込みまで進んだか」へ変わります。

自社送信・VAN到達を確認済みでも応答がない場合、取引先要因を疑う

到達済みなのに応答がないときの見分け方

ここまでで、自社の送信ログが正常であること、VANの照会やMDNで相手への到達が確認できていることが揃ったとします。
それでも相手から受領確認や出荷データといった応答が返ってこないなら、相手側の処理段階で止まっている可能性が高いと考えられます。
これは確認済みの機能から編集部が導いた見立てであって、相手のシステムを直接見た結果ではありません。
ただ、自社と経路の二つの層を潰した後に残る場所は、そこだけです。

この判断ができるかどうかは、到達確認の手段を持っているかにかかっています。
プラネットのサービスでは送信先での受信状況をセミリアルタイムで照会でき、送信先での未受信状況を電子メールで通知する仕組みもあるとされています¹。
こうした機能がない契約では、二層目と三層目の境目が自社からは見えないため、この切り分けは成立しません。
その場合は経路と相手側をまとめて「自社より先」と捉え、取引先に直接聞いて埋めることになります。

取引先へ確認するとき、「届いていますか」とだけ尋ねると「届いていません」で会話が終わります。
発注側であれば、何時に送ったどの伝票が相手の受信ログに記録されているか、そこから基幹システムへの取り込みがどこまで進んでいるかを分けて聞くと、相手の担当者も調べる場所が決まります。
相手のところにも、受信・取り込み・業務処理という層があるからです。

相手の受信ログにはあって取り込みで止まっているなら、フォーマットの不一致、商品コードや取引先コードの未登録といった中身の問題が疑われます。
このときに決めておきたいのが、相手側で修正して取り込み直すのか、自社がデータを直して再送するのかです。
合意しないまま自社が再送すると、相手が取り込み直した分と重なって同じ発注が二重に入ります。
再送の要否と時刻は、必ず相手と合わせてから動かします。

切り分け後、誰に連絡し何を伝えれば復旧が早まるか

連絡先の判断基準とサポート対応時間

層が決まれば、連絡先も決まります。
自社の出力処理や送信スケジュールで止まっているなら社内の担当とEDIソフトのサポート、応答待ちエラーや振分エラーなど経路側の異常が疑われるならVAN事業者の窓口、到達済みで応答が返らないなら取引先の担当者です。
裏を返せば、切り分けができていない状態で三者に同時に連絡すると、それぞれから「こちらでは異常ありません」という回答が返ってきて、時間だけが過ぎます。

社内への連絡も忘れられがちです。
受注データが入らない間は出荷や在庫引当が止まり、営業は納期の回答ができません。
復旧の見通しが立たない段階でも、いつ時点までのデータが処理済みで、どこから先が未処理なのかを共有しておくと、後から手作業で埋める範囲が分かります。

もう一つ、窓口の対応時間という制約があります。
JFT/Lite Netの製品サポートはメール・電話で平日の日中に対応し、別途の保守契約はないとされています²。
EDIの送受信は夜間や早朝に動いているのに、問い合わせ先が開くのは営業日の日中という組み合わせは珍しくありません。
自社が契約しているソフトとVANのそれぞれについて、いつ・どの手段で連絡できるのかは別々に確かめておく必要があります。

時間外に障害が起きたとき、できることは復旧を待つだけではありません。
締め時間の延長を取引先に依頼する、当日分だけ電話やメールで受発注の内容を伝えて後からデータを突き合わせる、といった業務側の回避を並行して動かせます。
どの取引先ならその運用が許されるのかは相手との取り決め次第なので、平時のうちに緊急時の連絡手段と代替手段を確かめておくと、当日の判断が速くなります。

伝えると調査が早まる情報

連絡した後の調査時間は、最初に渡す情報でかなり変わります。
相手の担当者は自社のログを時刻とキーで検索するので、そこに入れる材料を揃えて渡すのが近道です。
編集部の提案として、送信または受信した日時、対象の伝票番号とデータ種別、件数、画面に出ているエラーコードとメッセージの文言、相手先コードと自社の企業コード、そしてすでに再送したかどうかを併せて伝える形をおすすめします。

「今日の発注データが届かない」という伝え方では、相手はその日の全取引を見ることになります。
時刻と伝票番号があれば該当の一件を引けますし、エラーコードと文言があれば、相手は自社の製品マニュアルを引いて意味を確かめられます。
再送の有無を伝えていないと、相手が取り込み直した後に自社からも再送してしまい、同じ発注が二重に入ります。

これで調査が必ず短く済むと言い切れるものではありませんが、少なくとも「どのデータの話ですか」「いつのことですか」という往復のやり取りは減らせます。
障害連絡のメールに書く項目をあらかじめ定型にしておけば、慌てている当日でも抜けません。
切り分けの結果と、そのときに渡す情報の対応は次のように整理できます。

三つの層のどこで止まっているかが決まれば、当日の動き方も連絡先も決まります。
手を動かしながら潰していけるように、確認項目をまとめておきます。

切り分けの手順そのものより、自社の契約とEDI環境でどの層まで自力で見えるのかが分からないと、当日の一手目が決まらないためです。

現在の受発注とEDIの構成を一緒に見ながら、送信ログ・到達確認・相手側の応答のうち、どこが自社で確認でき、どこが問い合わせでしか埋まらないのかを整理できます。無料相談で要件を整理する

障害発生時に確認する三層チェックリスト

自社・通信経路・取引先という確認対象の層の順に並べており、症状によってはどこから見ても構いません。

• 自社のEDIソフトで送信処理が完了しているか、ログにエラーや未完了の記録が残っていないか

• 出力対象のファイルが作られ、送信ジョブが予定どおり起動しているか

• VAN側で振分エラーが出ていないか、宛先コードやデータ種別の設定に漏れがないか

• 送信先での受信状況が照会できるか、未受信の通知が届いていないか

• 応答待ちや無通信監視タイムアウトに当たるエラーが記録されていないか(名称は手順と製品で異なる)

• AS2手順を使っている場合、MDNが返っているか

• 相手からの受領確認・出荷データなどの応答が返っているか

• 連絡先と対応時間、伝える情報(送信日時・伝票番号・エラーコード・再送の有無)が手元に揃っているか

VANに到達確認や未受信通知の機能がない契約では、経路の項目を自社では埋められないため、その分を取引先への確認内容に振り替えます。

要点の整理

確認したいこと	見る場所・伝える先
自社で送信できているか	EDIソフトの送信履歴(ファイル出力・ジョブ起動・セッション・送信完了の記録)
相手に届いているか	VANの運用照会と未受信通知、AS2手順ならMDNの有無
宛先の設定が合っているか	VANの振分状況と、取引先・データ種の通信設定の照会
経路で応答が止まっていないか	応答待ち・無通信監視タイムアウトに当たるエラー(名称は手順と製品で異なる)
誰に連絡するか	自社起因は社内とソフトのサポート、経路はVAN事業者、到達済みは取引先の担当者
何を伝えるか	送信日時／伝票番号とデータ種別／エラーコードと文言／再送の有無

復旧の次に残るのは、同じ障害に早く気づき、再送や手作業の後始末を減らす体制をどう作るかという課題だからです。 検知の手段が空白になっている層と、障害時に手作業へ切り替える範囲を洗い出し、通知や運用のどこに手を入れると当日の判断が速くなるかを確かめられます。

よくある質問

EDIのエラーコード一覧はどこで確認できるか

業界共通の一覧を引くというより、使っている通信手順とEDI製品のマニュアルを見ることになります。
たとえば「論理ACK受信待ちエラー」はJFT/Lite Netでの表示で、無通信監視タイムアウトの値を過ぎても通信相手から応答がないことを示すと説明されています²。
同じ状況でも、全銀TCP/IP手順やJX手順、AS2手順を使う環境では別の名称で記録されます。
障害の最中に探し始めると時間を取られるので、自社が使う手順と製品のエラー説明の在りかを、平時に確認しておくのが現実的です。

取引先都合で発生した障害の対応費用はどちらが負担するのか

費用負担のルールが業界横断で決まっているわけではないため、自社の取引基本契約やEDIの利用規約、VAN事業者との契約に定めがあるかを確認するのが出発点になります。
実務上の順番としては、原因がどの層にあるかが確定する前に負担の話へ進むと切り分けが止まりがちです。
まず復旧と業務への影響を止めること、次に送受信の記録や連絡の経緯を残しておくこと。
記録が残っていれば、後から当事者間で事実に基づいて話ができます。

EDIデータは障害復旧後に自動で再送信されるのか

自動で再送されるかどうかは、使っている製品と設定によって変わります。
障害の通知機能ですら製品のグレードで有無が分かれる例があり、JFT/Lite Netには障害通知機能がなく、上位のJFT/Serverがサイクル管理・スケジューリング・障害通知を備えるとされています²。
再送の扱いも同じように製品ごとに違うので、自社の設定を確かめないまま「自動で送られているはず」と考えるのは危険です。
加えて、相手側が既に手作業で取り込んでいるところへ自動再送が重なると二重取り込みになります。
再送の要否と時刻は取引先と合わせてから動かしてください。

VAN事業者のサポート窓口は夜間・休日も対応しているのか

事業者と契約内容によって異なるため、自社の契約書や窓口案内で確かめる必要があります。
参考になるのは、EDIソフト側のサポート条件です。
JFT/Lite Netの製品サポートはメール・電話で平日の日中に対応し、別途の保守契約はないとされています²。
EDIソフトの製品サポートとVAN事業者の運用窓口は別の連絡先なので、それぞれの受付時間と手段を分けて控えておくと、時間外に障害が起きたときに迷いません。

1. 1　出典：株式会社プラネット「EDIとは：EDIサポート機能」（2026年）
2. 2　出典：TOKAIコミュニケーションズ「JFT/Lite Net よくある質問」（2026年）
3. 3　出典：株式会社UNILINK「AS2手順」（2026年）