EDI（電子データ交換）とは｜定義・仕組み・標準規約

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

B2B EC-COLUMN

EDI（電子データ交換）とは何かを定義から整理します

EDI（電子データ交換）とは、企業間の受発注や請求といった取引データを、あらかじめ定めた規約に従って計算機同士で直接やりとりする仕組みです。人が読む前提の書面や画面入力と分かれる境界は、データの形式と送受信の手順を取引の当事者が事前に取り決めている点にあります。この取り決めは、情報伝達規約・情報表現規約・業務運用規約・取引基本規約という4階層で整理されます^*1。定義を押さえておくと、方式の選定でも判断の軸がぶれません。

電子データ交換という訳語は、交換する対象がデータそのものである点を示しています。書面を画像として送っても、受け手の側には読み取りや入力の作業が残ります。EDIでは項目の並びと意味を双方が同じ約束で解釈するため、受け取った側の業務システムがそのまま処理できます。交換の相手は人ではなく相手の業務システムだと考えると、理解が早まるでしょう。

メールやFAX、取引先の画面への手入力とEDIが分かれる境界は、処理を自動で続けられるかどうかにあります。添付ファイルを人が開いて転記する運用は、電子化されていても交換の自動化には届きません。項目の桁数や区分の値まで事前に定めてあれば、受信から在庫の引き当てまで人の判断を挟まずに進みます。境界を意識せずに電子化だけを進めると、画面が増えるのに作業量が減らない結果になりがちです。

境界の見極めを誤ると、受注の転記の誤りが出荷や請求の誤りへ連鎖します。取引データは発注・出荷・受領・請求・支払の5つの局面でつながっており、前の局面の誤りは後ろの局面すべてに波及します。誤った請求は取引先の検収差異として戻り、照合のやり直しが発生します。電子取引の取引情報は法令上の保存対象でもあるため、誤りの記録も保存し直す手間が生じます^*5。

EOS（電子発注方式。発注業務に絞った受発注の仕組み）との違いは、扱う範囲の広さです。EOSは発注データの送信を中心に据えますが、EDIは出荷や受領、請求までの一連のメッセージを対象にします。発注だけを電子化しても、後続の照合が紙のままであれば効果は限られます。範囲の違いを社内で共有しておくと、要件の抜けを防げます。

電子契約や電子帳票との違いは、誰が読むために作られた仕組みかという点にあります。電子契約は合意の意思表示を、電子帳票は人が読む書式を電子化する手段です。EDIが運ぶのは業務システムが処理する項目の集合であり、帳票の見た目は運びません。請求書を人が確認する場面では帳票が要り、明細を突き合わせる場面ではデータが要ります。両者は競合せず、役割を分けて併用する対象と言えます。

定義を短く言い直すと、EDIは取引の約束事をデータの形式まで落とし込んだ企業間の連携手段です。社内で説明するときは、電子化の度合いではなく、相手のシステムがそのまま処理できるかを判断の軸に置いてください。この軸があれば、次に見る4階層の規約も、決めるべき事項の一覧として読み解けます。

EDIを成り立たせる取り決めと基本の仕組み

EDIを成り立たせているのは4階層の取り決めです。回線と通信手順を決める情報伝達規約、データの表し方を決める情報表現規約、締めや訂正の扱いを決める業務運用規約、責任の範囲を決める取引基本規約の4つで構成されます^*1。技術寄りに見える前の2つだけを決めても、運用と契約の取り決めが欠けると、締め日の差異や訂正の扱いで現場が止まります。4階層をそろえて設計してください。

情報伝達規約は、どの回線とどの通信手順でデータを運ぶかを定めます。流通業界向けの標準仕様では、インターネット回線を前提とした2種類の通信手順が定められています^*2。情報表現規約は、項目の順序・桁数・コード体系といったデータの表し方を担います。同じ発注でも、税区分の持ち方や単位の刻み方が違えば、受け手はそのまま処理できません。

業務運用規約では、送受信の時刻、締めの単位、訂正や取消の手順、障害時の代替手段を決めます。取引基本規約では、データが到達した時点で注文が成立するのかといった法的な扱いを定めます。この2つは書面の取引条件と重なるため、情報システム部門だけでは決められません。営業・購買・経理を含めた合意の場が欠かせません。

受発注データが相手システムに届くまでの流れは、4つの段に整理できます。まず発注データの作成が購買や販売管理の側で進み、次にデータ形式の変換で相手と合意した表現に直します。続く回線経由の送信で相手の受信箱まで運び、最後に相手システムへの取り込みで受注として登録されます。どの段で止まったかを切り分けられる記録を残しておくと、障害からの復旧が早まります。

変換の設計は、稼働後の負荷を左右する工程です。自社のコードと取引先のコードの対応表を持たずに始めると、商品や納入先の読み替えが人の手作業として残ります。対応表の維持には、商品の改廃や取引先の組織変更を反映する運用が要ります。項目の対応関係は表として管理し、変更の履歴を追える形にしておきましょう。

仕組みを理解しておくと、外部からの提案も評価できます。通信手順の選択、文字コードの扱い、対応表の設計、再送や重複の防止は、それぞれ独立した検討課題です。4階層のどこを自社で担い、どこを委ねるのかを先に決めると、見積の前提が揃います。前提を決めずに相見積を取ると、金額の差が範囲の差なのか品質の差なのか判別できません。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

EDIの主な方式と種類ごとの違い

方式の選び方は、取引先の数と相手からの要求で決まります。取り決めを相手ごとに結ぶ個別EDIは、相手が少ないうちは早く始められますが、相手が増えるほど手順と対応表の組み合わせが積み上がります。業界や地域の共通仕様に揃える標準EDIは、初期の調整に手間がかかる代わりに、2社目以降の追加負荷を抑えられます。中小企業向けの共通仕様も整備が進み、標準はVer.4.3として公開されています^*3。

個別EDIと標準EDIの違いは、取り決めを誰と誰の間で閉じるかという点にあります。個別EDIでは項目名も桁数も相手ごとに決めるため、相手の都合に細かく合わせられます。反面、取引先が増えるたびに設計と接続確認が繰り返され、変更のたびに影響範囲の調査が必要になります。標準EDIでは共通仕様に準拠する分、自社の特殊な運用を仕様の側へ寄せる判断が求められます。

Web-EDIは、相手が用意した画面に接続して発注を受け取ったり、出荷の予定を入力したりする方式です。自社の件数が少なければ人の操作で回りますが、取引先ごとに画面と操作手順が異なる点が負荷になります。ファイル連携型EDIは、定めた形式のファイルを回線で送受信し、基幹システムと直結させる方式です。件数が多い業務では、画面操作を挟まないこちらのほうが人の作業を減らせます。

業界標準EDIは、流通や製造といった業界の慣行に合わせて項目とメッセージを定めた仕組みです。取引先が同じ業界内に集まっている場合は、準拠するだけで接続の前提が揃います。API連携は、都度の要求に応じて即時にデータを受け渡す方式で、在庫や納期の照会が多い取引に向きます。方式ごとにデータの受け渡しの方法が異なり、向いている場面も分かれます。

実務では、5つの方式のどれか1つに統一できる例は少なく、併存が前提になります。大手の取引先は自社の標準EDIを求め、小口の取引先はWeb-EDIや電話のまま残るという分かれ方が起こります。併存を前提にすると、社内側の受け口を1本にまとめる設計が判断の分かれ目になります。受け口が方式ごとに分かれていると、在庫や与信の残高が方式別に散り、締めのたびに突き合わせが要ります。

方式の優劣を先に決めず、取引先ごとの要求を並べてから選んでください。相手が指定する通信手順、求められる応答の速さ、扱う件数の3点を書き出すと、候補は自然に絞られます。特定の製品の善し悪しではなく、自社の件数と取引先の分布に対する向き不向きで比べるほうが、後戻りを避けられます。

EDIでやり取りする代表的な業務データと流れ

EDIでやり取りするデータは、発注・出荷・受領・請求・支払という5つの局面のメッセージが中心です。発注に対して出荷の予定が返り、納品後に受領の実績が返り、それを踏まえて請求と支払が進みます。この往復が揃って初めて、伝票の突き合わせを人が担わずに済みます。どれか1つだけを電子化しても、前後の局面で紙や電話が残れば作業は残ります。

発注のメッセージには、品目・数量・納期・納入先といった項目が並びます。出荷のメッセージは、実際に何をいつ送ったかを伝え、入荷側の検品の予定に使われます。受領のメッセージは、検品の結果として確定した数量を返すもので、請求の根拠になります。数量が発注と受領で食い違ったとき、どちらを正とするかは業務運用規約で定めておく事項です^*1。

請求と支払のメッセージは、経理の締めと直結します。受領の実績と請求の明細が同じデータで突き合わせられれば、差異の確認は例外分だけに絞られます。逆に請求だけが紙やPDFで届くと、明細を人が入力してから照合する作業に戻ります。電子で受け取った取引情報は保存の対象にもなるため、経理の側の保管の運用と合わせて設計してください^*5。

基幹システムや販売管理との連携では、どちらが在庫と与信の正を持つかを先に決めます。EDIの受信をそのまま受注として登録すると、与信の判定を通らない注文が入り込むおそれがあります。受信したデータを一度仮の状態で受け、与信と在庫の引き当てを経て確定させる流れにすると、例外の扱いが追えます。仮の状態のまま滞留する件数を日次で見る運用も要ります。

連携の設計で見落とされやすいのが、締め時刻と再送の扱いです。相手の送信が自社の締めに間に合わなかったとき、翌日の受注として扱うのか当日に含めるのかで、在庫の数字が変わります。同じデータが二重に届いたときに重複を弾く仕組みがなければ、二重出荷につながります。再送・重複・欠落の3つの例外は、稼働前に手順まで決めておきましょう。

取引先ごとのフォーマット差異は、稼働後も残り続ける負荷です。同じ発注でも、商品コードの体系や納入先の呼び方は相手ごとに違います。読み替えの対応表は取引先の数だけ増え、商品の改廃や組織変更のたびに保守が発生します。差異を吸収する場所を1か所に集め、そこだけを保守の対象にする設計にしておくと、変更の影響を追いやすくなります。

データの流れを整理すると、EDIが減らすのは入力そのものより照合の手間だと分かります。発注と受領、受領と請求が同じ項目で結び付いていれば、差異は例外として浮かび上がります。照合の自動化まで届かない設計では、電子化の効果は限られたものにとどまるでしょう。

EDI導入で見直しが必要になる通信基盤と法制度

既存のEDIを持つ企業では、通信基盤と法制度の2方向から見直しが迫られています。固定電話網のIP移行は2024年に始まり、従来のディジタル通信モードを用いた接続は期限付きの補完的な手段での継続となりました⁶。電子取引の取引情報はデータのまま保存する扱いとなり、保存と検索の要件が運用に組み込まれます5。どちらも先延ばしにすると、稼働中の取引に影響します。

回線のIP移行は、EDIの接続方式そのものに関わります。従来のディジタル通信モードを前提とした手順は、移行後も補完的な手段で継続できますが、提供には期限が示されています^*6。手順の変更は自社だけで完結せず、相手側の設備と接続確認の日程調整が必要になります。取引先の数が多いほど、調整の期間が全体の工程を決めます。

電子取引データの保存では、取引情報を電子のまま保存し、後から確認できる状態を保つことが前提です。公表されている要件では、真実性の確保と可視性の確保の2区分に沿った措置が求められます^*5。検索については、取引年月日・取引金額・取引先の3項目で探せる状態が基本です。法人の帳簿書類は原則7年間の保存が求められるため、EDIの送受信の記録も同じ期間を見込んでおきましょう。

規模による緩和も設けられています。基準となる期間の売上高が5,000万円以下の事業者では、検索機能の確保が不要とされる扱いがあります^*5。ただし、求めに応じてデータを提示できる状態は残ります。要件は改正が続く領域ですので、施行の時期や経過措置は原典の最新版に当たり、税務上の判断は所轄官庁の資料と専門家への確認を前提にしてください。

請求データの整合は、EDIと経理の接点で問題になります。受領の実績と請求の明細が別の経路で届くと、突き合わせが人の作業として残ります。国内のデジタルインボイスの標準仕様は、適格請求書の要件を満たす項目を含む形で定められています^*4。請求の電子化を検討するなら、EDIの受領データと同じ鍵で結び付けられるかを確認してください。

3つの論点は別々の担当に分かれがちですが、期限は同時に効いてきます。回線の切り替えを機に方式を見直し、保存と請求の要件を同じ工程で満たすほうが、接続確認の回数を減らせます。担当が分かれたまま個別に進めると、同じ取引先へ別々の依頼を出すことになり、相手の負担も増えます。

標準化とデジタルインボイスに向かうEDIの動き

EDIの動きは、相手ごとの個別の取り決めから共通仕様への準拠へと向かっています。流通業界向けの標準仕様はインターネット回線を前提とした2種類の通信手順を定め²、中小企業向けの共通仕様はVer.4.3として公開されています3。請求の領域では、国際的な仕様を土台にした国内の標準仕様が整えられました^*4。共通仕様に寄せるほど、取引先の追加にかかる作業が軽くなります。

国内の業界標準は、業界の慣行を前提に項目とメッセージを定めています。同じ業界の取引先が多い企業では、準拠を決めるだけで項目の設計の大半が済みます。中小企業向けの共通仕様は、規模の小さい事業者でも接続の負担を抑えられるよう、共通の項目と手順を提供する考え方で整備されました^*3。準拠の範囲と自社の運用の差は、業務運用規約の側で埋める設計になります。

標準仕様は固定されたものではなく、版を重ねて更新されます。準拠を決めるときは、現在の版と改定の見通しを確認し、自社の改修の周期と合わせておく必要があります。版が上がるたびに全面的な改修が要る作りにしてしまうと、保守の負担が積み上がります。差異を吸収する層を分けておくと、版の更新を局所的な改修で収められます。

デジタルインボイスは、請求のデータを共通の仕様でやりとりする取り組みです。国内の標準仕様は国際的な仕様を土台としており、送り手、送り手側の接続点、受け手側の接続点、受け手の4者を経由してデータが届く考え方が採られています^*4。相手ごとに接続を結ぶ必要がなく、接続点に一度つなげば同じ仕組みの相手と交換できる点が、個別の取り決めとの違いです。

請求の標準化は、EDIの受領データと組み合わせたときに効いてきます。受領の実績と請求の明細が同じ項目で結び付けば、差異の確認は例外だけに絞られます。請求書を人が読む書式として受け取る運用では、この照合が自動化できません。請求の電子化を帳票の配信で済ませるか、データの交換まで進めるかは、照合の手間をどこまで減らしたいかで決まります。

標準化が取引先の拡大に持つ意味は、追加の1社にかかる作業量の違いに現れます。個別の取り決めでは、相手が増えるたびに項目の設計と接続確認が繰り返されます。共通仕様に準拠していれば、2社目以降は差異の確認が中心になります。取引先の入れ替わりが続く事業では、この差が年間の工数の差として蓄積します。

標準への準拠は、それ自体が目的ではありません。自社の取引先がどの仕様を求めているかを確認し、準拠する範囲を決めるところから始めてください。求められていない仕様に先回りして合わせても、効果は現れません。

EDI導入の進め方と検討時に確認したいこと

導入は、現状の棚卸し、方式の選定、稼働後の運用設計という3段階で進めると手戻りが減ります。棚卸しでは受発注業務の可視化と取引先の一覧化を行い、件数と相手の要求を数字で把握します。選定では比較観点の設定と見積の前提合わせを済ませ、4階層の規約のどこを委ねるかを決めます。運用設計では保守体制の確保と取引先展開の計画を先に描いておきましょう。

受発注業務の可視化では、業務ごとの件数、締めの時刻、訂正の頻度、人の手作業が残る箇所を書き出します。取引先の一覧化では、相手が求める方式と通信手順、扱う品目の範囲を並べます。この2つが揃うと、個別EDIと標準EDIのどちらへ寄せるかの母数が見えます。逆に、可視化を飛ばして製品の比較から入ると、要件が後から膨らみます。

比較観点の設定では、自社開発・パッケージ・クラウド利用の3つを同じ軸で並べます。軸に置くのは、対応できる取引先の範囲、通信手順の追加のしやすさ、保守を誰が担うか、法令要件への追随の3点です。自社開発は要件に合わせやすい一方で、通信手順の更新や法令の改正に自力で追随する必要があります。クラウド利用では追随を提供側に委ねられますが、自社の特殊な運用を仕様に合わせる判断が要ります。

内製で完結させる場合に必要な知見は、狭くありません。通信手順の選択と設定、文字コードとコード体系の対応表の設計、再送と重複の防止、電子取引データの保存要件への対応、障害時の切り分けが揃って求められます¹5。担当が1人に集中すると、その人の不在時に受注が止まります。見積の前提合わせでは、これらのどこまでを自社で担うかを文書にしてから金額を比べてください。

外部の専門パートナーに委ねる場合との差は、追随と切り分けの負担に現れます。回線のIP移行や標準仕様の版の更新は、自社の都合とは無関係に発生します²6。内製では、その都度の調査と改修を自社の工程に割り込ませることになります。委託では、追随の範囲と障害時の一次切り分けを契約で定められるため、稼働中の取引が止まる場面を減らせます。

保守体制の確保では、障害の一次受けと切り分けの手順、再送の判断基準、連絡の経路を決めます。取引先展開の計画では、相手ごとの接続確認と並行運用の期間を見込み、繁忙期を避けた日程に置きます。稼働の日を先に決めてから相手に依頼すると、相手側の都合で全体が遅れます。展開は取引先の件数の多い順ではなく、要求の近い相手からまとめると、確認の手数を抑えられます。

よくある質問

EDIの費用はどのような要素で決まりますか

費用は、対応する方式の数と取引先の件数、そして保守を誰が担うかで大きく変わります。通信手順ごとの設定、取引先ごとの対応表の作成と維持、接続確認の回数が作業量の中心です。公表された相場の数値は業種や規模で条件が異なるため、まず4階層の規約のどこを自社で担うかを決め、同じ前提で見積を並べてください。

取引先が数社だけでもEDIを検討する意味はありますか

意味があるかどうかは、件数よりも照合の手間で判断できます。取引先が少なくても、発注・出荷・受領・請求の突き合わせを人が担っていれば、誤りが後の局面へ波及します。相手が少ないうちは個別EDIでも回りますが、取引先の追加が見込まれる場合は、最初から共通仕様に寄せておくほうが後の作業を抑えられます。

Web-EDIだけで対応を続けると何が起こりますか

取引先ごとに画面と操作手順が異なるため、相手が増えるほど人の操作と転記が積み上がります。画面から取り出したデータを基幹システムへ手入力する運用が残ると、在庫や与信の残高が方式別に散り、締めのたびに突き合わせが必要になります。件数が増えた段階で、ファイル連携型EDIやAPI連携への切り替えを検討する余地があります。

EDIとBtoB EC・Web受発注はどう役割を分ければよいですか

定型の取引で件数が多い相手はEDI、少量多品種や新規の相手はWeb受発注に寄せる分け方が実務的です。どちらを使っても、社内側の受け口を1本にまとめ、与信と在庫の引き当てを同じ流れで通す設計にしてください。受け口が分かれると、同じ取引先の注文が二重に登録される場面が生じます。

既存のEDI回線が使えなくなる場合、何から確認すればよいですか

まず現在の接続がどの通信手順に依存しているかを確認してください。固定電話網のIP移行後、従来のディジタル通信モードを用いた接続は期限付きの補完的な手段での提供となっています^*6。手順の変更は相手側の設備と日程の調整を伴うため、取引先の一覧化を先に済ませ、要求の近い相手からまとめて切り替える計画を立てると調整の手数を抑えられます。

1. *1　出典：一般財団法人日本情報経済社会推進協会（JIPDEC）「EDIとは」（2026年閲覧時点）　経路
2. *2　出典：一般財団法人流通システム開発センター 流通BMS協議会「流通ビジネスメッセージ標準（流通BMS）標準仕様」（2018）　経路
3. *3　出典：つなぐITコンソーシアム（事務局：特定非営利活動法人ITコーディネータ協会）「中小企業共通EDIとは／中小企業共通EDI標準 Ver.4.3_r0」（2026）　経路
4. *4　出典：デジタル庁「デジタルインボイス（Peppol／JP PINT）」（2026年最終更新）　経路
5. *5　出典：国税庁「電子取引データ保存の義務化サイト（電子帳簿保存法関係）」（2026年閲覧時点）　経路
6. *6　出典：東日本電信電話株式会社（NTT東日本）「固定電話（加入電話・INSネット）のIP網移行／INSネットをご利用の事業者さまへ」（2026年閲覧時点）　経路