EDIの障害切り分け：注文が届かない・取り込めないときの確認手順（中小企業の運用担当者向け）

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

B2B EC-COLUMN

EDI障害の切り分けは、注文データが流れのどこで止まったかから始める

出荷準備を始めたのに、いつもの取引先の注文データが届いていない。
受信はしたのに基幹システムへ取り込めない。
送った注文に返事が来ない。
原因が自社の設定か、通信経路か、取引先やEDIサービス提供元の側かが分からないと、電話をかける先も決まりません。
まず、注文データが作成・送信・通信・受信・取り込み・基幹連携のどこで止まったかを見極めます。
止まった地点が分かれば、疑う相手を絞れます。
問い合わせには日時・伝票番号・エラー内容・ログを添えます。
再送は相手が受け取っていないと確かめてから行えば、二重取り込みの危険を減らせます。

作成・送信・通信・受信・取り込み・基幹連携の6地点

EDI（電子データ交換）は、注文書や納品の連絡を、紙やFAXではなく決まった形式のデータで企業間に受け渡す仕組みです。
障害に気づくのは、たいてい結果の側からです。
販売管理の受注一覧に今日の注文が無い、取り込みの画面にエラーが出ている、送った注文に取引先からの返事が無い。
どれも「EDIが止まった」ように見えますが、実際に止まった場所は一つとは限りません。

注文データは、おおむね次の地点を順に通ります。

1. 作成：発注側の業務システムで注文データがつくられる
2. 送信：送信の処理や予約が動き、データが自社の外へ出る
3. 通信：インターネットや回線、EDIサービス提供元（プロバイダー）の中継を通る
4. 受信：受注側のEDIソフトや受信の仕組みにデータが届く
5. 取り込み：届いたデータを自社の形式に変換し、受注データとして読み込む
6. 基幹連携：販売管理・在庫・出荷の仕組みに注文が反映される

この6地点のどこで止まったかが分かれば、疑う相手はかなり絞れます。

たとえば受注側の担当者が、出荷前に販売管理の画面で注文が無いと気づいたとします。
取引先に電話する前にEDIソフトの受信履歴を開き、そこに今朝の受信記録があれば、データは受信の地点までは来ています。
止まったのは取り込みか基幹連携で、取引先にも通信経路にも問い合わせる必要はありません。
反対に受信履歴にも記録が無ければ、作成から通信までのどこかが疑わしく、ここで初めて相手に聞く理由が生まれます。
同じ「注文が無い」という症状でも、どの地点まで記録が残っているかで、次にかける電話の相手が変わるのです。

地点の間には、自社の外の事業者が入ることがあります。
中小企業庁が紹介する中小企業共通EDIは、取引先ごとにばらばらだったデータの形式を国際標準に準拠して共通化する取り組みで、受注側も発注側も対応するプロバイダーと契約し、プロバイダーが情報を変換してやり取りする構図が示されています¹。
この場合、通信と形式の変換の一部は提供元の側で行われ、その記録も提供元が持ちます。
ただし、これは共通EDIの標準に対応した場合の構図です。
取引先のWebサイトに入って注文を見るWeb-EDIや、VAN（付加価値通信網）を経由する方式、電話回線を使う方式では、地点の並びは同じでも、誰の設備を通るかが違います。
自社の方式に合わせて、6地点を読み替えて使います。

地点ごとに自社で見える情報と見えない情報

6地点を並べたら、次はそれぞれの地点について、自社の画面やログで確かめられるのか、相手に聞かないと分からないのかを分けます。
受注側の場合、受信・取り込み・基幹連携は自社の仕組みの中にあり、受信履歴、取り込みエラーの記録、販売管理の受注一覧などで状態を見られます。
一方、作成と送信は取引先の社内で起きることで、受注側からは見えません。
通信の途中にプロバイダーやVANが入っていれば、その中継の記録は提供元が持っています。

発注側の場合は、見える範囲が逆になります。
注文データを作成した記録と送信の結果は自社の手元にあり、相手の受信や取り込みは見えません。
「送ったのに返事が来ない」というとき、自社の送信記録が正常に終わっていても、それは自社の出口までを示すだけです。
取引先が受け取って取り込んだことまでは示していない、という点が判断の分かれ目になります。

切り分けの基準として持っておきたいのは、自社のログで最後に確認できた地点です。
受信記録はあるが取り込みでエラーが出ている、送信は成功しているがその先は分からない、というように、自社で確かめられる範囲の端を一文で言えるようにしておくと、その先が誰の領域かがはっきりします。
この見える・見えないの区分は問い合わせの順番を決めるための整理で、仕組みによっては提供元の管理画面で中継の状況まで見られることもあります。
自社の契約でどこまで見られるかは、提供元の資料で確かめておく必要があります。

そもそも受信履歴やエラーの記録がどこにあるか分からない、という場合もあるでしょう。
専任のIT担当がいない会社では、導入時の担当者や保守会社しか画面の場所を知らないことがあります。
障害の最中にそれを探し始めると時間を失うので、記録の見方を提供元に聞くこと自体を、最初の問い合わせにしてかまいません。

▼ 図の内容を文字で読む

1. 作成・送信
   • 取引先の社内で起きる
   • 受注側からは見えない
2. 通信
   • プロバイダーやVANが中継する
   • 中継の記録は提供元が持つ
3. 受信
   • 受信履歴で確かめる
4. 取り込み
   • 取り込みエラーの記録で確かめる
5. 基幹連携
   • 販売管理の受注一覧で確かめる

止まった地点と症状から、自社・通信経路・取引先・提供元のどこを疑うかを分ける

未着・エラー応答・取り込み失敗・項目不整合の症状別の疑い先

止まった地点が見えてきたら、症状の種類を重ねて疑う先を絞ります。
ここでは症状を、届いていない（未着）、送信時にエラーが返る（エラー応答）、届いたが読み込めない（取り込み失敗）、読み込めたが内容が欠けたりずれたりする（項目不整合）の四つに分けて考えます。

未着は、自社の受信履歴に記録が無い状態です。
取引先がまだ送っていない、送ったが通信の途中で止まっている、自社の受信の仕組みが動いていない、のいずれかが考えられます。
どれから確かめるかは、データを自社から取りに行く方式か、相手から送られてくる方式かで変わるため、次の項で扱います。

エラー応答は、送信した側にエラーが返ってくる状態です。
エラーには、相手の設備までたどり着けなかった種類と、たどり着いたうえで受け付けられなかった種類があり、どちらかで疑う先が変わります。
前者なら自社のネットワークや宛先の設定、通信経路を、後者なら相手側の受信設定や認証の情報を疑います。
エラーの文言は、要約せずにそのまま控えておきます。
担当者が読んで意味が分からなくても、提供元や相手の技術者には手がかりになるからです。

取り込み失敗は、受信の記録はあるのに受注データとして読み込めない状態です。
データは自社の手元に着いているので、まず疑うのは自社の変換や取り込みの設定と、届いたデータの中身です。
取引先が商品コードを変えた、新しい納品先コードを使い始めた、といった相手側の変更で読めなくなることもありますが、その場合も最初の確認は自社の取り込みエラーの記録から始まります。

項目不整合は、取り込みはできたのに、備考や納品指定日などの項目が空になっている、値がずれている、という状態です。
ここで手がかりになるのが、データの全項目と、業務アプリが扱う項目は同じではないという点です。
中小企業共通EDIの標準仕様書は、業務アプリケーションに対応を求める最低限の項目として注文書番号や注文書発行日など13項目を、プロバイダーに対応を求める注文メッセージの全項目として135項目を定めています¹。

つまりこの標準では、提供元はメッセージの全項目を受け渡せる前提でも、自社の業務アプリが読み込む項目はその一部である場合があります。
取引先が送った項目が自社の画面に出てこないとき、通信の障害ではなく、自社のアプリがその項目を扱う設定になっていないだけ、ということもありえます。
確かめる順は、提供元に受信したメッセージにその項目が入っていたかを聞き、入っていれば自社のアプリ側の設定や対応状況を見る、という流れです。
なお13項目と135項目は中小企業共通EDIの標準の話で、流通業界の標準や取引先独自の形式では項目の構成が異なります。

Pull型とPush型で変わる確認の順

未着のときにどこから確かめるかは、データの動き方で変わります。
小売・卸・メーカーの間で使われる流通業界のEDI標準である流通BMSには、インターネット経由の通信手順が三つ規定されています。
ベンダーの比較ページでは、JX手順がクライアント（利用者側の端末やソフト）を起点にデータを取りに行くPULL方式、AS2とebXMLがサーバー同士で送り届けるPUSH方式と整理されています²。

Pull型では、取りに行く側が動かなければデータは届きません。
自社が取りに行く側なら、まず自社の取得処理が予定の時刻に実行されたか、実行結果が成功か、取りに行ったときに「データ無し」だったのかを確かめます。
取得処理そのものが動いていなければ、原因は自社の端末やソフト、ネットワークにある可能性が高まります。
取得は成功したのにデータが無かったなら、相手のサーバーにまだデータが置かれていなかった可能性があり、ここで初めて取引先や提供元に聞く順番になります。

Push型では、送る側のサーバーが受け手のサーバーへデータを送り届けます。
受け手の側でできることは、自社の受信サーバーが動いていて受け付けられる状態かを確かめることまでで、送ったかどうかは送り手の記録にしかありません。
そのため受信側は、自社の状態を確かめたら早めに取引先へ送信の時刻と結果を聞くことになります。
送り手の側は、送信記録とエラーの有無を見て、次の節で扱う再送の設定がどうなっているかを確かめます。

この違いは、流通BMSのインターネットEDIを使う場合の通信手順に基づく整理で、すべてのEDIに当てはまるわけではありません。
また流通BMSと中小企業共通EDIは別の標準なので、前の項の項目数の話と混ぜて考えないようにします。
自社がどの手順を使い、Pull型ならクライアントとサーバーのどちらの役割なのかは、契約時の資料や提供元への確認で把握できます。

▼ 図の内容を文字で読む

• 未着
  • 取引先がまだ送っていない
  • 通信の途中で止まっている
  • 自社の受信の仕組みが動いていない
• エラー応答
  • 相手の設備に届かない：自社のネットワーク・宛先の設定・通信経路
  • 届いたが受け付けられない：相手側の受信設定・認証の情報
• 取り込み失敗
  • 自社の変換や取り込みの設定
  • 届いたデータの中身
• 項目不整合
  • 提供元に、受信したメッセージにその項目があったかを聞く
  • 入っていれば自社アプリ側の設定や対応状況を見る

▼ 図の内容を文字で読む

• Pull型（JX手順）
  • 取りに行く側が動かなければデータは届かない
  • まず自社の取得処理が予定の時刻に実行されたか、結果が成功かを見る
  • 取得は成功でデータ無しなら、取引先や提供元に聞く
• Push型（AS2・ebXML）
  • 送る側のサーバーが受け手のサーバーへ送り届ける
  • 受け手は自社の受信サーバーが受け付けられる状態かを見る
  • 早めに取引先へ送信の時刻と結果を聞く
• どちらの場合も
  • 自社が使う手順と役割を、契約時の資料や提供元への確認で把握する

自力で確認してよい範囲と、問い合わせ時に渡す情報

自社側で確認できる設定とログ

疑う先が自社の中にありそうなとき、どこまで自分で触ってよいかに迷います。
線を引く目安は、見るだけで済むか、データや設定を変えるかです。
社内のネットワークがつながっているか、EDIソフトや取得処理が動いているか、受信履歴に記録があるか、取り込みエラーの内容、販売管理の受注一覧に何件入っているか。
これらは見るだけで確かめられ、何度確かめても取引先の側に影響しません。

送信側の設定のうち、確かめておきたいのが再送の設定です。
先のベンダーの比較ページには、AS2とebXMLについて、送信エラー時の再送回数や再送間隔などを設定できると記載されています²。
自動の再送が設定されていれば、送信エラーが出たあとも、仕組みが決められた間隔で送り直している途中かもしれません。
その状態で担当者が手で送り直すと、自動の再送と手動の再送の両方が相手に届くおそれがあります。
エラーを見つけたら、まず再送の回数と間隔の設定、そしてすでに何回送り直したかの記録を見ておくと、手で動くべきかどうかを判断できます。
同じページではJX手順について再送設定の記載はなく、実際に設定できる内容は製品と方式ごとに違うため、自社の製品の設定画面か提供元の資料で確かめます。

一方で、宛先や認証情報の書き換え、取り込みの変換設定の変更、受信データの削除や取り込み直しは、見るだけの範囲を越えます。
原因が分からないまま設定を変えると、元の状態が分からなくなって提供元の調査が難しくなり、取り込み直しは同じ注文を二重に登録するきっかけにもなります。
こうした操作は、問い合わせ先と相談してから行うほうが安全です。

問い合わせ先に渡す情報の整理

問い合わせを受けた提供元や取引先は、日時や伝票番号を手がかりに自分たちの記録を探します。
「注文が届かない」だけでは、相手はまず、いつ・どの取引先・どの注文かを聞き返すところから始めることになり、そのやり取りの分だけ原因に届くのが遅れます。
最初の連絡に、次の情報をまとめて添えるとよいでしょう。

• 発生日時と、最後に正常に処理できた日時
• 取引先の名前と取引先コード
• 対象の伝票番号・注文番号と件数
• 使っている方式（JX手順、AS2、Web-EDIなど）と自社の役割
• エラーメッセージの全文、または画面の写し
• 自社のログで最後に確認できた地点
• すでに行った操作（送り直した、取り込み直した、など）とその時刻

この並びは、相手が記録を探すのに使う手がかりから考えた整理で、提供元ごとに求める項目は異なります。
契約時の資料に問い合わせの様式があれば、それに合わせます。

とくに見落としやすいのが、すでに行った操作です。
送り直したことを伝えずに問い合わせると、相手の記録に同じ注文が二つ見えたとき、障害なのか再送なのかの見分けがつきません。

連絡先は、前の節で絞った疑い先に合わせます。
取り込みや基幹連携で止まっているなら自社の業務アプリの保守窓口、通信の途中が疑わしいなら提供元、取引先がまだ送っていない様子なら取引先です。
どこか決めきれないときは、通信の途中に入っている提供元に、両側の受け渡しの記録が残っていないかを聞くと、止まった地点を外から確かめられる場合があります。

原因が分かる前に出荷・納期を止めない暫定対応と、再送・二重取り込みの判断

電話・FAX・メールでの代替連絡

原因の調査には時間がかかることがあり、その間も出荷の締め時刻は近づきます。
受注側なら、取引先に注文内容を電話・FAX・メールで送ってもらい、それをもとに出荷の準備を進める、という暫定対応が考えられます。
発注側なら、EDIで送れなかった注文を同じ注文番号のまま、FAXやメールで取引先に送ります。

注意したいのは、代替で注文を受けた時点で、同じ注文が二つの経路に存在するようになることです。
EDIが復旧すると、止まっていた注文データがあとから届く場合があります。
代替で受けた注文を販売管理に手入力していれば、そのまま取り込むと同じ注文が二重に登録されます。
代替で受けた注文には取引先の注文番号を必ず控え、販売管理側でも「代替受付」と分かる印を付けておきます。
EDIの取り込みの前に、その注文番号が既に登録されていないかを突き合わせれば、二重登録に気づけます。

あとからEDIでも同じ注文を送るのか、代替で送った分で済ませるのかは、取引先と決めておく必要があります。
受注側と発注側で思い込みが違うと、片方は「EDIでも届くはず」と待ち、もう片方は「FAXで送ったから済んだ」と考えます。
代替連絡を頼む電話の中で、この扱いまで一言で確かめておくと、復旧後の突き合わせで迷わずに済みます。

再送の前に確かめること

送信側にとって、エラーが出た注文を送り直すのは自然な対応に見えます。
ただ、エラーが表示されても、実際には相手に届いていることがあります。
相手の受信は完了していたのに、受け取ったという返事が自社に戻る途中で止まった場合、自社の画面では失敗に見えるからです。
その状態で送り直せば、相手には同じ注文が二回届きます。

そこで再送の前に、次の順で確かめます。

1. 自社の送信記録で、どの注文がいつ、どんな結果で終わったかを見る
2. 自動の再送が設定されていて、まだ送り直しの途中でないかを見る
3. 取引先か提供元に、その注文番号を受信済みか、取り込み済みかを聞く
4. 未受信と確かめられたら再送し、再送した時刻と注文番号を相手に伝える
5. 再送後、受信側の件数と注文番号を突き合わせる

相手がすぐに受信状況を確かめられないときは、再送した注文を相手がどう見分けるかを先に決めておきます。
注文番号が同じなら二回目は取り込まない、と取り決められれば、受信側は件数と番号で重複を見つけられます。

受信側にも、二重取り込みを防ぐ確認が残ります。
同じ注文番号のデータが二度届いたとき、業務アプリが自動で重複を止めるかどうかは製品と設定によって違います。
止める仕組みがあるかが分からないうちは、復旧後に届いたデータを取り込む前に、件数と注文番号を代替受付の記録と並べて見るほうが確実です。
ここで示した順序は判断の目安であり、再送や重複の扱いは取引先との取り決めや契約で変わります。

▼ 図の内容を文字で読む

1. 自社の送信記録を見る
   • どの注文がいつ、どんな結果で終わったか
2. 自動の再送が途中でないかを見る
   • 再送の回数と間隔の設定
   • すでに送り直した回数の記録
3. 取引先か提供元に受信状況を聞く
   • 受信済み・取り込み済みなら再送しない
   • 未受信と確かめられたら次へ
4. 再送して相手に伝える
   • 再送した時刻と注文番号
5. 件数と注文番号を突き合わせる
   • 受信側の件数と注文番号

再発させないための連絡体制・手順・取引先との取り決め

連絡先と手順書

障害の最中に時間を取られやすいのは、原因の調査よりも、誰に連絡するかを探すことです。
専任のIT担当がいない会社では、EDIを導入した人や普段操作している人が不在のとき、問い合わせ先の電話番号さえ見つからないことがあります。

平時に用意しておきたいのは、取引先ごとの連絡先の一覧です。
取引先の障害時の窓口と担当者、使っている方式、提供元の問い合わせ窓口と契約番号や利用者ID、自社の業務アプリの保守窓口を一つの表にまとめます。
問い合わせ先の整理で見た、地点ごとの疑い先と連絡先が一対一で対応していれば、止まった地点が分かった時点で電話をかける先が決まります。

手順書は、長くする必要はありません。
6地点それぞれの記録をどの画面で見るか、問い合わせに添える情報、再送の前に確かめることの三つが一枚にまとまっていれば、普段の担当者以外でも最初の切り分けに手を付けられます。
障害が起きたら、日時・症状・止まった地点・原因・対応を記録に残し、手順書に足りなかった点を書き足します。
あわせて、提供元との契約や通信の設定のうち期限があるものを一覧にし、何に期限があるかを提供元に確かめておくと、更新の時期を見落とさずに済みます。

取引先との障害時の取り決め

暫定対応の節で見たように、代替連絡と再送は、取引先と扱いがそろっていないと二重受注や連絡の行き違いを生みます。
障害が起きる前に、取引先と次の点を話しておくと、当日の判断が減ります。

• EDIが使えないときの代替手段（電話・FAX・メールのどれを使うか）
• 代替で送った注文を、復旧後にEDIでも送るかどうか
• 再送する前に、相手へ連絡するかどうか
• 障害時の連絡窓口と、連絡がつく時間帯

取引先が多い場合、すべてと一度に取り決めるのは負担が大きいでしょう。
注文の件数が多い取引先や、受注から出荷までの時間が短い取引先ほど、止まったときの影響が大きいので、そこから始めるのが現実的です。
取り決めといっても契約書を作り直す必要があるとは限らず、メールで合意内容を残しておくだけでも、当日の確認の電話で何を聞けばよいかがはっきりします。

こうした備えで障害そのものがなくなるわけではありません。
減るのは、連絡先を探す時間、相手と事実を確かめ合う往復、復旧後の突き合わせで迷う場面です。
止まった地点を早く特定し、出荷を止めずに注文を二重にしない、という目的に照らして、自社の体制に合う範囲から整えていけます。

どの地点で止まりやすいか、自社の契約でどこまでログを見られるかは、使っている方式と取引先の組み合わせで変わり、社内だけでは整理しにくいためです。

自社の受発注の流れを6地点に当てはめ、どこまで自社で確かめられ、どこから先を誰に聞くかを相談の中で確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
最初の確認	注文データが6地点のどこまで進んだかを、自社のログで最後に確認できた地点から見る
疑う先	止まった地点と症状（未着・エラー応答・取り込み失敗・項目不整合）で決める
方式の違い	Pull型は取得する側の実行記録から、Push型は送り手の送信記録と受信サーバーの状態から
自力の範囲	見るだけの確認は自社で行い、設定変更・削除・取り込み直しは相談してから
問い合わせ	日時・取引先・注文番号・方式・エラー全文・確認できた地点・実施済みの操作
再送	自動再送の途中でないか、相手が未受信かを確かめてから
平時	連絡先の一覧、一枚の手順書、取引先との代替手段と再送の取り決め

取引先ごとの代替手段や再送の扱いは、取引先の数が増えるほど担当者一人では決めにくくなるためです。 優先して取り決める取引先と、連絡先の一覧や手順書に入れる項目を、自社の受発注の実態に沿って確かめられます。

よくある質問

再送してよいかどうか、どう判断すればよいですか。

相手がその注文を受信していないと確かめられた場合に再送します。
エラーが表示されていても相手に届いていることがあるため、自社の送信記録と自動再送の設定を見たうえで、取引先か提供元に注文番号を伝えて受信状況を聞きます。
すぐに確かめられないときは、同じ注文番号で再送し、二回目は取り込まないという扱いを相手と合意してから送ると、重複に気づきやすくなります。

取引先に確認の電話をするとき、何を伝えればよいですか。

自社の会社名と担当者名に続けて、どの注文が、いつ届く予定だったかを伝えます。
そのうえで、自社の側でどこまで確かめたかを具体的に話します。
たとえば「受信履歴には今朝8時以降の記録がありません」と伝えれば、相手は自社の送信記録と照らし合わせられます。
相手に聞くのは、送信したか、その時刻と件数、送信時にエラーが出ていないかの三点です。
あわせて、出荷に間に合わせるための代替の送り方、復旧後にEDIでも送るかどうか、どちらも相手に連絡せずに再送しないことを、その電話で確かめておきます。

EDIサービス提供元に問い合わせるとき、どんな情報を用意すればよいですか。

日時・取引先・注文番号・方式・エラー全文・自社のログで最後に確認できた地点・すでに行った操作に加えて、契約番号や利用者IDなど、提供元が契約者を特定するための情報を用意します。
提供元は中継の記録を持っていることがあるので、どの時刻に、どの取引先からのデータが中継を通過したかを具体的に聞くと、止まった地点が通信の途中か、その前後かを判断しやすくなります。
問い合わせの様式が決まっている場合は、それに従います。

電話回線型のEDIが使えなくなったとき、何を確認すればよいですか。

まず、使っている回線のサービスが現在も提供されているか、提供条件が変わっていないかを、NTT東日本・西日本の案内で確かめます。
回線側に変更があった場合は、自社の設備を直しても元に戻らないことがあります。
あわせて、提供元と取引先に、その方式を今後も使えるか、インターネットを使う方式への切り替えの予定があるかを聞いておくと、一時的な不具合なのか、方式の見直しが必要なのかを判断できます。

1. 1　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
2. 2　出典：インターコム（Biware）「流通BMS規定のインタネットEDI通信プロトコル比較」（掲載年不明）