EDI(電子データ交換)とは？和訳の意味とやり取りするデータ、紙・FAX・EOSとの違い

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

B2B EC-COLUMN

EDI(電子データ交換)とは何か

取引先から届いた案内に「EDIでのお取引に切り替えます」とあり、調べても「電子データ交換」という和訳しか出てこない。
それでは、毎朝FAXで受け取っている注文書や、月末に突き合わせている請求の明細が、明日から何に置き換わるのかまでは掴めません。
EDIは、あらかじめ通信手順とデータの形式を取り決めたうえで、発注や出荷、請求といった取引のデータをコンピュータ同士で直接やり取りする仕組みです。
人が紙やメールを読んで入力し直すことを前提にした手順とは、そこが分かれます。
まず決まるのは、自社が注文を出す側なのか受ける側なのか、そしてどの業務のデータが対象なのかという点です。
ここを押さえると、取引先の案内に書かれた言葉が自分の作業のどこに当たるのかを読み分けられるようになります。

EDIはElectronic Data Interchangeの頭文字をとった略語で、和訳はそのまま「電子データ交換」です²。
ところが、この四文字を見て業務の中身まで思い浮かぶ人は多くありません。
注文書をPDFにしてメールで送るのも、表計算ファイルを添付して送るのも、字面のうえでは電子的なデータの交換だからです。
和訳が落としてしまうのは、「誰と誰が、どんな形式で送り合うかを先に取り決めてある」という条件のほうです。

公的な定義を二つ並べると、その条件がはっきりします。
通商産業省の「電子計算機相互運用環境整備委員会」が平成元年に示した定義では、EDIは「異なる組織間で、取引のためのメッセージを、通信回線を介して標準的な規約(可能な限り広く合意された各種規約)を用いて、コンピュータ(端末を含む)間で交換すること」とされています¹。
日本産業規格のJIS X 7011は「トランザクション又はメッセージデータを構成することを目的に合意された規約を用いた、商業上又は行政上のトランザクションの電子計算機適用業務から電子計算機適用業務への電子的な転送」と定めています¹。

言い回しは硬いのですが、取り出せる要素は共通しています。
異なる組織の間であること、やり取りするのが取引のためのメッセージであること、通信回線を通ること、合意された規約に沿うこと、そしてコンピュータとコンピュータの間で渡ることです。
とくに効いてくるのが最後の二つで、JISの定義にある「電子計算機適用業務から電子計算機適用業務への」という言い方は、業務アプリケーション同士でデータが渡ることを指しています¹。
取引先の受注システムが出したデータが、人の目と手を経由せずに自社の販売管理システムへ入る。
この経路が成り立つように規約を先に合わせてあるものを、EDIと呼んでいます。
なお通商産業省の定義はコンピュータについて「端末を含む」と書き添えているので¹、大がかりな基幹システム同士でなければ成り立たない、という意味ではありません。

定義が「異なる組織間」と言っている点にも意味があります。
同じ会社の中で、受注システムから在庫システムへデータを渡すような連携は、社内のシステム連携であってEDIとは呼び分けられます。
EDIが相手にするのは、自社では仕様を決められない、別の会社のシステムです。
相手の都合を自分の判断で変えられないからこそ、どんな形式で送り合うかを先に合意しておく必要が出てきます。
業界ごとに標準が用意されているのも、取引先が増えるたびに一社ごとの取り決めをやり直さずに済むようにするためです。

では、先に取り決めておくものは何でしょうか。
流通システム開発センターの説明では、EDIを行うには事前に通信手順(プロトコル)とメッセージ標準(データ形式)を取り決めておく必要があるとされています²。
通信手順は、どのしくみでつなぎ、どちら側が取りに行くのかという運び方の約束です。
メッセージ標準は、送られてくるデータのどこに商品のコードが入り、どこに数量や納品日が入るのかという、中身の書式の約束にあたります。
手紙にたとえるなら、封筒の送り方と便箋の書式を先に揃えておくようなものです。
どちらか一方でも食い違うと、データは届いているのに読めない、あるいは項目の意味を取り違えるという状態になります。

「標準的な規約」という言葉の幅にも触れておきます。
平成元年の定義は、規約について「可能な限り広く合意された各種規約」と書いています¹。
できるだけ多くの企業が使えるものが望ましい、という考え方が最初から入っているわけです。
とはいえ実務では、業界の標準に沿う場合もあれば、二社の間の取り決めとして形式を合わせる場合もあります。
取引先の案内を読むときは、示されているのが業界で共有されている標準なのか、その取引先との間だけの仕様なのかで、社内での準備の重さが変わってきます。

もう少し日常の言葉に近い説明もあります。
中小企業庁は、EDIについて「電子データ交換」のことであり、とくに企業間においては受発注などの商取引をネットワークを通じて電子的に行うことを指す、と説明しています⁴。
ここまでが業界や規模を問わない共通の土台です。
裏を返すと、定義からは「自社が実際にどのデータをやり取りしているか」までは決まりません。
取引先の案内を自分の作業に結びつけるには、何のデータが誰から誰へ動くのかという話が要ります。

EDIでやり取りするデータと、発注側・受注側の関係

発注から支払までの6つの業務

「取引のためのメッセージ」という言い方のままでは、手元の書類と結びつきません。
日本の流通業界で国内標準として位置づけられている流通BMSを見ると²、対象になる業務が具体的に並んでいます。
流通BMSは、発注、出荷、受領、返品、請求、支払の6業務について、8種の標準メッセージを定めています³。
対象とされているのは、卸売(またはメーカー)と小売の間の取引業務です³。

並び順は、そのまま取引の進み方に沿っています。
注文を出す段階が発注、注文に対して商品を送り出したことを知らせる段階が出荷、届いた側が中身を確かめて受け取った内容を返す段階が受領です。
受け取れないものを戻す場合が返品、代金を請求する段階が請求、その支払の内容を知らせる段階が支払にあたります。
注文から代金のやり取りまでの一続きが、標準の範囲に入っているということです。

この並びを知っておくと、取引先の案内に出てくる言葉の出どころが分かります。
EDIという言葉から注文のデータだけを思い浮かべていると、「出荷予定を返してほしい」「受領数と請求を突き合わせる」と書かれたときに、急に話が広がったように感じます。
実際には発注の前後にある業務まで標準が用意されているので、どこまでを自社の取引で使うかという選び方の問題になります。
ただし、これは流通BMSという特定の標準が定めている範囲の話です³。
業界が変われば、メッセージの種類も、やり取りする当事者の組み合わせも違ってきます。

業務の数とメッセージの数が一致していない点も、案内を読むときの手がかりになります。
定められているのは6業務に対して8種の標準メッセージなので³、一つの業務がひとつのデータで完結するとは限りません。
取引先から「この業務については二種類のデータをやり取りします」と説明されても、標準の作りとして不自然なことではない、という見方ができます。
どの業務にどのメッセージが割り当てられているかは、取引先が使う標準の仕様で決まるので、実際の組み合わせは案内や仕様書で確かめることになります。

自分の業務に当てはめるには、いま紙やFAX、メールで受け取っている書類を並べてみるのが早道です。
注文書、出荷の案内、受領書や検収の控え、返品の連絡、請求書、支払の明細。
これらが6つの業務のどれに当たるかを見ていくと、取引先の案内が触れているのがどの書類の話なのかが見えてきます。
すべてが一度に置き換わるとは限らず、注文だけが先に接続されて、請求は紙のまま残るという組み合わせもあります。

自分は発注側か受注側か

流通BMSが想定している当事者は、卸売またはメーカーと、小売です³。
同じEDIという言葉を使っていても、このどちら側に立つかで日々の作業はほぼ裏返しになります。
最初に決めるべきなのは、用語の細かい定義より、自社がどちらの側なのかという点です。

注文を出す側であれば、発注のデータを送り、相手から出荷や請求のデータを受け取ります。
注文を受ける側であれば、発注のデータを受け取り、出荷や請求のデータを自分から送ります。
それぞれの業務は、その行為を行う側から相手へ渡ると考えると、方向を取り違えにくくなります。
商品を出すのは受注側なので出荷の知らせは受注側から、検品して受け取るのは発注側なので受領の知らせは発注側から、という具合です。

立場が決まると、取引先から届く案内の読み方が変わります。
「発注データを取り込んでください」と書かれていれば、それは注文を受ける側に向けた依頼です。
「出荷予定日を入力して返信してください」であれば、商品を出す側に求められている作業です。
取引先が用意する資料は相手の立場から書かれていることがあり、主語が自社なのか相手なのかを取り違えると、必要のない準備を始めてしまうこともあります。

準備するものも、立場によって置き場所が違います。
注文を出す側は、何をいくつ発注するかを決める元になる情報を自社側で用意し、それを発注のデータとして送り出す流れを作ることになります。
注文を受ける側は、届いたデータを受注として取り込む先を決め、取り込んだあとに出荷の情報を返せるようにしておく必要があります。
同じ「接続する」という言葉でも、手を入れる場所が送り出し側なのか受け入れ側なのかで、社内で相談する相手も変わります。

同じ会社が両方の立場になることもあります。
小売から注文を受けつつ、メーカーへ自社の注文を出している卸売であれば、受注側としての接続と発注側としての接続を同時に持つことになります。
片方の取引だけがEDIで、もう片方は電話やFAXのまま、ということも起こります。
社内で「うちはEDIをやっている」と言われたときに、人によって思い浮かべる画面が違うのは、この重なりが理由になっていることがあります。

立場が同じでも、取引先ごとに条件が違う場合もあります。
ある取引先とは発注と出荷までを接続し、別の取引先とは請求まで含む、という状態は珍しくありません。
そうなると、同じ受注担当者が、相手によって違う手順を使い分けることになります。
手順の違いがどこから来ているのかを説明できないまま運用が始まると、引き継ぎのたびに確認が振り出しに戻ってしまいます。

立場と対象業務が分かると、変わらない部分も見えてきます。
たとえば注文を受ける側で、発注と出荷までは接続しているが請求は対象外という取り決めであれば、請求書は従来どおり自社で作って送ることになります。
この場合、月末に請求内容を突き合わせる作業は残り、その相手になるのは接続で受け取った発注や受領のデータです。
どこまでが自動で渡り、どこから先が手元の作業として残るのかは、対象業務の線引きで決まります。

出典：流通システム開発センター(流通BMS協議会)「流通BMS | EDI(電子データ交換)」(発注・出荷・受領・返品・請求・支払の6業務・8種の標準メッセージ。対象は卸売(またはメーカー)〜小売間の取引業務)

EDIは紙・FAX・メールでのやり取りと何が違うのか

ここまでで、EDIが「先に合わせた規約に沿って、コンピュータ同士でやり取りする仕組み」であることを確認しました。
では、紙の注文書やFAX、メールでのやり取りとは何が違うのでしょうか。
違いは「電子かどうか」ではありません。
受け取ったデータを、相手のシステムがそのまま処理できる形にしてあるかどうかです。

紙やFAXで注文を受けている場面を思い浮かべてみます。
届いた注文書を担当者が読み、自社の受注画面を開いて、商品名を自社のコードに置き換え、数量と納品日を入力します。
取引先が使っている商品の呼び方が自社の呼び方と違えば、そこに読み替えの判断が入ります。
FAXの文字がかすれていれば電話で確かめ、届いたかどうか不安なら受信の控えを探します。
この一連の読み取りと入力が、人の手と目に依存している部分です。

メールに表計算ファイルやPDFを添付する方法は、紙よりは手間が減るように見えます。
それでも様式が取引先ごとに違えば、結局は開いて内容を確かめ、自社の画面へ移すことになります。
定義の言葉に戻すと、合意された規約がないので、適用業務から適用業務への転送にはなっていない状態です¹。
電子的に送っていればEDIだ、とは言えないのはこのためです。

EDIでは、通信手順とメッセージ標準を先に揃えてあります²。
どの位置に何が入っているかが決まっているので、届いたデータを自社のシステムがそのまま取り込めます。
減るのは、読み取って打ち直すという転記そのものです。
読み間違いや入力漏れは、その転記を起点にして生まれることが多いので、起点が一つ減るという言い方もできます。

紙やメールでのやり取りが負担になりやすいのは、取引先ごとに様式が違うときです。
A社の注文書とB社の注文書で項目の並びが違えば、読む側はそのたびに見る場所を切り替えます。
担当者が慣れてしまえば回りますが、その慣れは個人に溜まるので、休みや異動のたびに引き継ぎが要ります。
先に形式を取り決めておくという考え方は、この読み替えの負担を、担当者個人ではなく接続の設定側へ移すという意味でもあります。

ただし、人の作業がなくなるわけではありません。
取引先の商品コードと自社の商品コードを対応づけておく準備は必要ですし、その対応が抜けていれば取り込みでエラーになったデータの確認が残ります。
標準のメッセージに収まらない特別な依頼は、別の連絡手段で来ることもあります。
むしろ、先に取り決めてあることが前提の仕組みである以上、商品やコードが変わったときに取り決めた内容へ反映していく作業は、新しく発生します。
「EDIにすれば全部が自動になる」と社内へ説明してしまうと、この維持の手間を誰が持つのかという話が抜け落ちます。

接続したあとに残る作業は、担当を決めておかないと宙に浮きます。
取り込みでエラーになったデータを誰が見るのか、商品コードの対応を誰が直すのか、標準に載らない依頼が来たときに誰が判断するのか。
この三つが決まっていれば、切り替えた直後の問い合わせにも落ち着いて対応できます。
逆に、仕組みの説明だけで運用の担当が決まっていないと、エラーの件数が少ないうちは気づかれず、月末の突き合わせで初めて表に出るということも起こります。

受け渡しのタイミングも、紙やFAXとは考え方が変わります。
紙やFAXでは、届いた書類をいつ入力するかが担当者の手順しだいでした。
EDIでは、どのように受け渡すかが通信手順の取り決めに含まれるので²、いつ取りに行くか、いつまでに返すかといった約束を、接続を始める前に相手と決めることになります。
締め時刻の決め方が社内の段取りに直結するのは、この部分です。

どのくらい楽になるのかは、気になるところだと思います。
定義から言えるのは、人が読み取って入力する工程を挟まない、という仕組みの違いまでです。
実際に減る時間は、扱う注文の件数、いまの入力のやり方、接続する業務の範囲によって変わります。
他社が公表している削減の事例は、対象や条件が自社と揃っているとは限らないので、そのまま自社の見込みに置き換えないほうが安全です。

EDIとEOSなど似た略語は何が違うのか

現場では、EDIのほかにEOS、流通BMS、あるいは取引先ごとのサービス名が混ざって出てきます。
同じものを別の名前で呼んでいるのか、指している範囲が違うのかが分からないまま話が進むと、あとになって食い違いが表に出ます。

EOSは、発注のやり取りを指す呼び名として使われることが多い言葉です。
ただし、この語が指す範囲は会社や業界によって揺れがあり、名前だけを見て対象業務を決めつけるのは避けたほうがよいところです。
先に見たとおり、流通BMSは発注から支払までの6業務を対象にしています³。
一方で、注文のやり取りだけを電子化している状態を、社内では略語ひとつで呼んでいることもあります。
言葉の広さと、実際に接続している範囲は別のものだと考えておくと安全です。

EDIという言葉自体も、かなり広い傘です。
中小企業庁の説明でも、企業間においては受発注などの商取引をネットワークを通じて電子的に行うことを指す、という言い方になっています⁴。
「など」が付いているとおり、受発注に限った言葉ではありません。
だからこそ、「EDIに対応しています」という一言では、どの業務のデータを、どの形式で、どちら向きにやり取りしているのかまでは分かりません。

食い違いが表に出る場面を想像してみます。
取引先から「EDIでのお取引に切り替えます」という案内が届き、社内では「うちはもうEDIで注文を受けている」と認識していたとします。
ところが案内をよく読むと、出荷予定の返信と受領数の照合まで含まれていました。
既存の接続が注文のデータを受け取るだけのものだった場合、同じ「対応済み」という言葉でも足りていません。
必要な準備は新しい回線ではなく、これまで送っていなかった業務のデータを出せるようにすることだった、という順番が見えてきます。

もう一つ紛らわしいのが、名称の種類です。
案内に出てくる言葉には、標準そのものの名前と、それを使ったサービスや社内システムの名前が混ざります。
日本の流通業界では流通BMSが国内標準として位置づけられているので²、標準の名前が出てきているのか、提供元の商品名が出てきているのかを分けて読むと、質問すべき相手も決めやすくなります。

切り替えの案内を受けたときに見落とされやすいのは、接続の範囲から外れる業務のほうです。
接続する業務は案内に書かれていますが、書かれていない業務は「これまでどおり」なのか「別の方法に変わる」のかが曖昧なまま残ります。
たとえば請求が対象外であれば、請求書の送り方そのものは変わらないはずです。
ただし、請求の根拠になる数字を受領のデータから取るようになるなら、突き合わせの手順は変わります。
接続の対象に入っているかどうかと、作業が変わるかどうかは、必ずしも一致しません。

自社のシステムがどちらを指すか確認する方法

確認しましょう、と言われても、何を聞けばよいのか分からないまま連絡するのは気が重いものです。
迷いどころは、だいたい決まっています。
略語が同じでも対象業務が違うこと、対象業務が同じでもデータの形式が違うこと、そして取引先ごとに条件が違うことです。
いずれも相手に聞かなければ分からない一方で、聞き方を業務の言葉に直すだけで答えが返ってきやすくなります。

「EDIに対応していますか」という聞き方では、相手も略語の意味を自分の運用に引き寄せて答えるので、話が噛み合いません。
「発注のデータはどの形式で受け取れますか」「出荷の返信は必要ですか」「請求はこの接続に含まれますか」というように業務名で尋ねると、対象の範囲がそのまま返ってきます。
通信手順とメッセージ標準は接続の前に取り決めておく必要があるものなので²、この二点については相手側に必ず答えがあります。

聞く相手は、案内を出してきた取引先の担当部署が基本です。
自社側の条件は、いま使っている業務システムの提供元や、既存の接続を担当している社内の人が把握しています。
取引先ごとに使っている標準や運用が違うことがあるので、一社に確認した内容をそのまま他社にも当てはめないほうがよいところです。

確認した内容は、口頭のまま置かないほうが後が楽になります。
対象になる業務、データの形式、自社が送る側か受け取る側か、いつから切り替わるのか。
この四点を書き留めておくと、社内で別の担当者から同じ質問が出たときに、最初から聞き直さずに済みます。
取引先が複数ある場合は、相手ごとに同じ項目を並べておくと、条件の違いがそのまま比較できる形になります。

確認が取れると、次に決められることが増えます。
接続の対象になる業務が分かれば、そこから外れる業務は従来の手順が続くと判断できます。
自社が送る側の業務があれば、その情報を誰がいつ入力するのかという社内の段取りが決まります。
受け取ったデータをどの画面で見て、どの項目を確かめるのかが決まれば、日々の作業として引き継げます。
用語の意味をひととおり押さえる目的は、最終的にはこの段取りを組めるようにすることです。

取引先から示された条件を自社の受注や請求の流れに当てはめる段階では、どの業務が接続の対象で、どこから先が手元の作業として残るのかを切り分ける必要があり、案内の文面だけでは判断が付きにくいところです。

いま扱っている注文や請求のデータの流れを一緒に見ながら、どの転記が接続で減り、どの確認が残るのかを整理できます。無料相談で要件を整理する

取引先の案内を自社の作業に当てはめる四つの観点

取引先の案内を自社の作業に当てはめるとき、答えが変わると段取りそのものが変わる観点として、当事者・対象業務・データ形式・対象外の扱いの四つで整理しています。

• 自社は注文を出す側か、受ける側か(取引先によって立場が変わることもある)

• 接続の対象になる業務はどこまでか(発注だけか、出荷・受領・返品・請求・支払まで含むか)

• 通信手順とメッセージ標準は何を使うか(業界の標準の名称か、取引先との個別の仕様か)

• 対象から外れる業務は、これまでどおりなのか、突き合わせの手順が変わるのか

取引先が複数ある場合は、この四点を相手ごとに並べると条件の違いが見比べられます。

要点の整理

軸	確認の基準
言葉の意味	電子データ交換。通信手順とデータ形式を先に取り決め、コンピュータ間で取引データを渡す
対象データ	流通BMSでは発注・出荷・受領・返品・請求・支払の6業務。業界が違えば範囲も変わる
自社の立場	注文を出す側か受ける側かで、送るデータと受け取るデータが入れ替わる
紙・FAXとの違い	電子かどうかではなく、そのまま処理できる形式を合意しているかどうか
略語の扱い	EOSなどは指す範囲が揺れる。略語ではなく業務名と形式で確認する

注文を受ける側と出す側の両方を持っていたり、取引先ごとに対象業務が違ったりすると、社内の手順を一本にまとめられず、担当者ごとに運用が分かれてしまいます。 取引先ごとの条件の違いを並べたうえで、受け取ったデータをどの画面で扱い、誰がエラーとコードの対応を見るのかという段取りの組み方を確かめられます。

よくある質問

EDIとEOSは同じ意味ですか？

同じとは言い切れません。
EDIは、標準的な規約に沿って企業間で取引のデータをコンピュータ間でやり取りすること全般を指す言葉で、中小企業庁も受発注「など」の商取引を電子的に行うことと説明しています⁴。
EOSは発注のやり取りを指して使われることが多い呼び名ですが、指す範囲は会社や業界によって揺れます。
略語の突き合わせで判断せず、発注だけなのか出荷や請求まで含むのかを業務名で確認するほうが確実です。

EDIで交換するデータの形式(メッセージ標準)は業界共通ですか？

一つに決まっているわけではありません。
EDIを行うには通信手順(プロトコル)とメッセージ標準(データ形式)を事前に取り決める必要があり、日本の流通業界では流通BMSが国内標準として位置づけられています²。
ただし業界が変われば、扱うメッセージの種類も当事者の組み合わせも異なります。
取引先が使っている標準の名称と、その標準で自社が扱うメッセージを、案内や仕様書で確かめてください。

EDIは受発注データだけを指しますか、請求書もEDIの対象ですか？

請求も対象になり得ます。
流通BMSは、発注、出荷、受領、返品、請求、支払の6業務について8種の標準メッセージを定めています³。
つまり標準の作りとしては、代金の請求や支払までが範囲に入っています。
もっとも、実際にどの業務まで接続するかは取引ごとの取り決めで決まるので、自社の場合に請求が含まれるかは取引先への確認事項です。
対象外であれば、請求書はこれまでの方法で作って送ることになります。

取引先が使っているEDIが流通BMSかどうかはどう確認すればよいですか？

まず案内の文面に標準の名称が書かれていないかを見ます。
サービス名しか書かれていない場合は、案内の差出人である取引先の担当部署に、通信手順とメッセージ標準を尋ねてください。
この二つは接続を始める前に取り決めておく必要があるものなので²、相手側には必ず答えがあります。
あわせて、自社で使っている業務システムの提供元にも同じ内容を伝えておくと、対応できるかどうかの判断が早くなります。

1. 1　出典：一般財団法人日本情報経済社会推進協会（JIPDEC）「EDIとは」（1989年）
2. 2　出典：一般財団法人流通システム開発センター（GS1 Japan）「EDIとは？」
3. 3　出典：一般財団法人流通システム開発センター（GS1 Japan、流通BMS協議会）「流通BMS｜EDI（電子データ交換）」
4. 4　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（ミラサポplus）」