EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説

取引先から「発注書のやり取りを今後はEDIに切り替えたい」と要請され、何から確認すべきか整理したい。EDI（Electronic Data Interchange＝電子データ交換）は、受発注・出荷・請求といった企業間の取引データを、決められた規格と通信手順でシステム同士が直接やり取りする仕組みです。この記事では、EDIの意味と仕組み、個別EDI・標準EDI・業界VANという種類の違い、FAXやメールと比べた導入効果をわかりやすく整理します。さらに、INSネット終了に伴う「EDIの2024年問題」の現在地と補完策の期限、自社の基幹システムとどう連携させるかという導入判断まで、2026年7月時点の情報で解説します。

まとめ：EDIの要点と導入・移行判断の結論

EDIは企業間取引の書類（注文書・納品書・請求書など）を電子データとして交換する仕組みの総称です。取引先ごとに仕様を決める個別EDI、規格を共通化した標準EDI、業界団体が運営する業界VANの3方式があり、通信手段では専用線・ISDN前提のレガシーEDIと、光回線を使うインターネットEDI・Web-EDIに分かれます。導入すると、紙とFAXの受発注で発生していた転記入力・照合・保管の手作業が削減され、入力ミスと処理リードタイムが同時に減ります。

判断の期限が迫っている点が2026年時点の特徴です。レガシーEDIが使っていたINSネットのディジタル通信モードは2024年1月に終了し、代替の補完策も概ね2027年頃までの時限提供と案内されています。旧方式を使い続けている企業に残された移行期間は約1年です。取引先が少なく発注頻度も低いならWeb-EDIの受注画面対応で足り、月数百件以上の取引データを基幹システムに流し込むなら、変換・連携まで含めたインターネットEDIの設計が要ります。本文で順に根拠を示します。

EDI（電子データ交換）の定義と受発注データを交換する仕組み

最初に「EDIとは何か」を、対象になるデータと処理の流れから確認します。略語の意味だけでなく、どの業務がシステム間通信に置き換わるのかで理解すると判断に直結します。

EDIの意味と読み方、対象になる受発注・出荷・請求のデータ範囲

EDIはElectronic Data Interchangeの略で、読み方はそのまま「イーディーアイ」、日本語では電子データ交換と訳されます。企業間の商取引で発生する定型書類、具体的には見積書・注文書（発注データ）・注文請書・出荷案内・受領書・検収通知・請求書・支払通知までが交換対象です。1回の売買に紙なら7〜8種類の帳票が動く計算になり、この一連をデータで往復させるのがEDIの守備範囲です。

混同しやすい用語にEOS（Electronic Ordering System）があります。EOSは発注業務に絞ったオンライン受発注の仕組みを指し、EDIはその上位概念です。発注だけでなく請求・支払まで含めて電子化するかどうかが両者の分かれ目で、小売業の店舗発注ではEOS、製造業のサプライチェーン全体ではEDIという使われ方が定着しています。受発注のシステム化全般の選択肢は受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準で整理しています。

フォーマット変換と通信プロトコルによるデータ交換の流れと構成要素

EDIの仕組みは「フォーマット（データ形式）」「通信プロトコル（送受信の手順）」「変換処理」の3要素で成立します。送信側は自社の販売管理システムから出力した発注データを、取引で合意したフォーマット（固定長・CSV・XMLなど）に変換して送信し、受信側は届いたデータを自社システムが読める形式に再変換して取り込む、という流れです。この変換処理を担うソフトウェアがEDIツール（トランスレータ）です。

通信プロトコルには歴史的な系譜があります。1980年に日本チェーンストア協会が制定したJCA手順、1983年制定の全銀協標準通信プロトコル（全銀手順）が長くISDN回線とともに使われ、2007年には流通BMSの運用開始に合わせてインターネット前提のJX手順・ebXML MS・AS2が登場しました。どの手順を使うかは取引先との合意事項で、自社だけでは決められません。この「相手と合わせる」性質がEDIの設計を左右します。

FAX・メール・電子契約との違いとEDIに置き換わる業務の範囲

FAXやメール添付のExcel注文書も「電子的なやり取り」に見えますが、受け取った側が自社システムへ手入力し直す点で本質が違います。EDIはシステム間でデータが直接流れるため、転記という工程そのものが消える点が決定的な差です。誤入力の発生箇所がなくなり、着信確認や照合の待ち時間も削減される、という効果の源泉はここにあります。

電子契約サービスとの違いは対象文書です。電子契約は契約書という単発・非定型の文書に電子署名を付す仕組みで、EDIは反復発生する定型取引データの交換に向きます。実務では「基本契約は電子契約、日々の受発注はEDI」と併用する形が自然です。なお、EDIで受け取った注文データや請求データは電子帳簿保存法上の電子取引に該当し、2024年1月からは電子データのまま保存することが完全義務化されています。紙に印刷して保管する運用は認められないため、保存要件（改ざん防止措置・検索性）への対応もEDI導入と同時に設計する必要があります。

個別EDI・標準EDI・業界VANに分かれる種類と業界標準の規格

「EDIの種類」は、取り決めの範囲による分類（個別・標準・業界VAN）と、通信手段による分類（レガシー・インターネット）の2軸で整理すると迷いません。順に見ていきます。

個別EDI・標準EDI・業界VANの3方式の特徴と採用される場面

取り決めの範囲で分けると、EDIは次の3方式に整理できます。

個別EDIは大手企業が自社仕様を取引先に提示する形で使われ、受注側は取引先の数だけ仕様を抱え込みます。標準EDIはフォーマットと通信手順を規格化して多対多の接続を成立させる方式です。業界VAN（Value Added Network）は、酒類・加工食品のFINETや日用品のプラネットのように、業界団体系の事業者がデータ交換の中継と変換を担う形態を指します。新規に導入するなら、まず自社の業界に標準EDIか業界VANが存在するかを確認するのが順路です。

レガシーEDIとインターネットEDI・Web-EDIの通信手段の違い

通信手段の軸では、電話回線・ISDN回線（INSネット）を使うレガシーEDIと、光回線などのインターネット回線を使う方式に大別されます。レガシーEDIはJCA手順・全銀手順とともに約40年使われてきましたが、回線側のサービス終了で移行対象になりました（詳細は次章）。インターネットEDIはJX手順やAS2などの手順で従来型と同じシステム間自動連携を実現し、通信速度も回線費用もレガシー型より有利です。

Web-EDIはインターネットEDIの一形態で、発注側が用意したWebサイトに受注側がブラウザでログインし、画面上で受注確認やデータダウンロードを行う方式です。受注側は導入費用がほぼ不要という利点の裏で、取引先ごとに別々の画面へログインする「多画面運用」が発生し、システム間の自動連携にはならないという限界があります。自社が受注側で取引先が数社ならWeb-EDIで足り、件数が多いならAPI・自動連携型を交渉する価値があります。この差は同じ「インターネット経由」でも導入効果を左右する分かれ目です。

流通BMS・全銀EDI・中小企業共通EDIなど業界標準規格の現在地

日本の代表的な標準EDIには系譜があります。流通業界では2007年に運用が始まった流通BMS（流通ビジネスメッセージ標準）が、スーパー・ドラッグストアと卸・メーカーの間で使われる標準です。金融では全銀協が2018年12月に稼働させたZEDI（全銀EDIシステム）が、振込電文に商流情報（どの請求に対する支払いか）を添付できるXML電文を提供し、入金消込の照合作業を減らします。

中小企業向けには、2018年に仕様公開された中小企業共通EDIがあります。業界をまたぐ共通仕様として設計され、対応製品を使えば小規模企業でも受発注データの交換を始められます。製造業ではこのほか自動車業界のJNX、電子部品業界のECALGAのような業界ネットワーク・規格が現役です。自社が属する業界の標準が既にあるなら、個別仕様を新設するより標準準拠の製品・サービスを選ぶ方が、取引先拡大時の再交渉を減らせます。

EDI導入で得られる受発注コストの削減効果と事前に押さえる制約

導入効果は「何が消えるか」で見積もると具体化します。同時に、EDIには導入前に知っておくべき構造的な制約があり、ここを見落とすと効果が半減します。

紙・FAX処理と比べた入力工数・誤入力・リードタイムの削減効果

紙・FAXベースの受発注では、注文書の作成・送信・受信確認・自社システムへの転記入力・内容照合・原本保管という工程が1件ごとに発生します。EDI化で消えるのは転記入力と照合、そして紙の保管です。例えば1日50件の注文をFAXで受け、1件3分で転記していた場合、入力だけで毎日2.5時間が消えています。この時間がゼロになり、入力ミスによる誤出荷・返品対応も発生源から断てます。

時間短縮の効果は社内工数だけにとどまりません。郵送やFAXの往復で1〜3日かかっていた注文確定までのリードタイムが、データ交換では数分〜数時間に縮みます。発注側は発注から納品までの期間を短縮でき、受注側は生産・出荷の計画を早く確定できます。取引データが構造化されて蓄積されるため、月次の取引実績集計や需要分析にそのまま使える点も、紙帳票との実務差として大きい部分です。

取引先との調整負担や多画面運用など導入前に想定しておく制約条件

最大の制約は、EDIが相手のある仕組みだという点です。フォーマット・通信手順・運用ルールはすべて取引先との合意で決まるため、自社の都合だけで進められません。取引先がEDIに対応していなければFAX運用が残り、紙とデータの二重管理になります。導入効果は「取引データ量の多い相手から順に接続する」ことで最大化するため、全取引先の一斉切替を狙わず、上位2割の取引先から始めるのが現実的です。

受注側の立場では、前章で触れた多画面運用が代表的な負担です。大手取引先が各社別々のWeb-EDIを指定してくると、担当者は毎朝5画面・6画面を巡回して受注を拾い集めることになります。この状態を解消するには、複数のWeb-EDIからデータを収集して自社システムへ取り込む連携基盤の構築が必要で、単にEDIツールを1本入れるだけでは解決しません。初期費用・月額費用に加えて、こうした接続先追加のたびの改修費まで見込んで予算を組んでください。

EDIの2024年問題とINSネット補完策終了までの移行期限

2026年時点でEDIを検討・運用する上で外せないのが、通信インフラ側の期限です。「EDIの2024年問題」と呼ばれた事象は終わっておらず、最終期限がこれから来ます。

2024年1月のINSネット・ディジタル通信モード終了の影響範囲

NTT東日本・西日本は固定電話網のIP網移行に伴い、ISDNサービス「INSネット」のディジタル通信モードを2024年1月に終了しました。影響を受けたのは、JCA手順や全銀手順（ベーシック手順・TCP/IP手順のISDN利用分）でデータ交換していたレガシーEDI全般です。EDIの通信そのものが規制されたのではなく、通信の土台だった回線サービスが消えた、という構図です。

対象企業は受発注EDIだけでなく、金融機関との全銀手順によるファーム・バンキング、POSデータ伝送、本部・店舗間のデータ交換など、ISDN回線に載っていた業務全般の棚卸しが必要になりました。自社が直接ISDNを契約していなくても、取引先やVAN事業者経由の経路にISDN区間が残っているケースがあり、「自社契約の有無」だけで影響なしと判断できない点が厄介な部分です。

補完策「メタルIP電話上のデータ通信」の期限と残された移行期間

NTT東西は激変緩和のため、切替後もデータ通信を継続できる補完策（メタルIP電話上のデータ通信）を提供していますが、これは概ね2027年頃までの時限措置と案内されています。2026年7月時点で、残された期間は約1年です。しかも補完策はIP網経由となるため、方式によって従来より通信時間が延びる場合があることが確認されており、大量データを夜間バッチで伝送していた企業では処理時間の逸脱が起きえます。

ここから導ける判断は明確です。補完策で延命中の企業は、2027年を待たずにインターネットEDIへの切替を完了させる必要があります。取引先との仕様合意・テスト・並行稼働に通常3〜6カ月、接続先が多ければ1年単位かかるため、2026年中の着手が事実上の締切です。「まだ動いているから」という理由での先送りは、期限直前の駆け込みで移行ベンダーの確保が難しくなるリスクまで含めて、選ばない方がよい選択肢です。

インターネットEDI・Web-EDIへの移行先候補と切替の進め方

移行先の第一候補は、流通BMS（JX手順・ebXML MS・AS2）や中小企業共通EDIなど、業界標準に準拠したインターネットEDIです。標準準拠なら移行を機に他の取引先との接続も同じ仕様に寄せられ、レガシー時代の個別仕様を整理する機会になります。取引先が指定するWeb-EDIへの参加で済む場合もありますが、前述の多画面問題を抱え込まないか、受注データを自社システムへ取り込めるか（CSVダウンロードやAPIの有無）を確認してから受け入れてください。

切替の進め方は、現状把握から始めます。手順としては次の流れが標準です。

1. ISDN・レガシー手順を使う回線と業務（EDI・ファームバンキング・POS等）を棚卸しする
2. 取引先・VAN事業者に移行方針と対応時期を確認する
3. 移行先方式（標準EDI・業界VAN・取引先指定Web-EDI）と自社側ツールを決める
4. フォーマット変換・社内システム連携を設計し、テストと並行稼働を経て切り替える

この過程で費用対効果が合わない少量取引先については、無理にEDI接続せずメール添付＋自動取込などの簡易手段に落とす判断も成り立ちます。全件EDI化を目的化しないことが、移行プロジェクトを期限内に収めるコツです。

自社にEDIを導入する判断基準とパッケージ・個別開発の使い分け

最後に、これからEDIを導入する（または移行を機に作り直す)企業向けに、判断基準を言い切ります。分かれ目は取引データの量と、社内システムとの連携の深さです。

EDI導入に踏み切る取引量・業界の条件と見送ってよい場面の判断

導入に踏み切る条件は3つのうちいずれかに該当することです。第一に、主要取引先からEDI対応を要請されている場合。取引継続の前提条件であり、対応方式の選択だけが論点になります。第二に、受発注が月300件を超え、転記入力に毎日1時間以上を割いている場合。工数削減だけで費用回収の目算が立ちます。第三に、流通・製造など業界標準EDIが確立した業界で、今後取引先を広げたい場合です。標準対応が営業上の参加資格として働きます。

逆に、見送ってよい場面も条件付きで明示します。取引先が10社未満で受発注が月数十件、かつ取引先からの要請もないなら、EDI基盤への投資は過剰です。メールとクラウド受発注サービスで足ります。また、取引の大半が単発・非定型（都度見積のスポット取引）の事業も、定型データの反復交換というEDIの前提に合いません。この場合は電子契約と案件管理の整備が先です。「どの企業もいずれ必要」という一般論で導入すると、使われない接続だけが残ります。

基幹システム・購買管理システムとのEDI連携設計と開発の選択肢

EDIの効果は、受信したデータが社内システムに自動で流れて初めて出ます。受注データが販売管理に、発注データが購買管理システムとは？機能・5原則から選び方とERP連携の判断まで解説で整理した購買管理の発注・検収データに、請求データが会計にそれぞれ連携される設計です。EDIツール単体を入れても、社内側の受け皿と変換ルールがなければ「ダウンロードして手入力」が残り、FAX時代と工数が変わりません。

実装の選択肢は2段階あります。標準的な取引形態なら、EDIパッケージ・クラウドEDIサービスの標準連携機能で足りるケースが大半です。一方、複数のWeb-EDI・業界VAN・個別EDIが混在する、独自の受注承認フローや在庫引当ロジックを挟みたい、既存の基幹システムが古く標準コネクタがない、といった条件では、変換・連携部分の個別開発が必要です。一創では基幹システム開発として、EDIを含む外部データ連携と業務システムの設計・構築を受託しています。パッケージの適合率が7割を切るようなら、連携基盤を含めた開発の見積もりを取り、運用工数込みの総コストで比較することを推奨します。

よくある質問

EDIの検討時に問い合わせの多い疑問を、ここまでの内容を補う形で5つまとめます。

EDIとは何の略で、どう読みますか？

Electronic Data Interchangeの頭文字で、読み方は「イーディーアイ」です。日本語では電子データ交換と訳されます。IT用語としてのEDIは、企業間の商取引データ（注文・出荷・請求など）を、合意したフォーマットと通信手順でシステム間交換する仕組み全般を指します。医療分野の栄養指標など同じ略語の別用語もあるため、文脈で区別してください。

EDIとEOSはどう違いますか？

EOS（Electronic Ordering System）は発注業務に特化したオンライン受発注の仕組みで、EDIはより広い概念です。EOSが扱うのは主に発注・受注データですが、EDIは出荷・検収・請求・支払まで取引の一連を対象にします。小売チェーンの店舗発注ではEOSという呼び方が残っており、実務上は「EOSはEDIの発注特化型」と理解すれば取引先との会話で齟齬が出ません。

Web-EDIとインターネットEDIは同じものですか？

Web-EDIはインターネットEDIの一形態ですが、同義ではありません。インターネットEDIはインターネット回線を使いJX手順・AS2などでシステム間の自動連携を行う方式の総称です。Web-EDIはその中でも、ブラウザで発注側のサイトにログインして操作する画面ベースの方式を指します。人の操作が前提になるため、取引件数が多い場合は自動連携型との違いが工数に直結します。

EDIでやり取りしたデータは電子帳簿保存法の対象になりますか？

対象になります。EDI取引の注文データ・請求データなどは電子帳簿保存法第7条の電子取引に該当し、2024年1月以降は電子データのまま保存することが義務です。真実性の確保（タイムスタンプまたは訂正削除の防止規程など）と、取引年月日・金額・取引先で検索できる状態の維持が要件になります。EDIシステム側の保存機能で要件を満たせるか、導入時に確認してください。

中小企業でも取引先が少なければEDIは不要ですか？

取引先が10社未満・受発注が月数十件で、取引先からの要請がなければ、急いで導入する理由はありません。ただし大手との取引開始時にEDI対応が条件になる業界（流通・自動車部品など）では、対応可否が受注機会を左右します。その場合も自前で基盤を持つ必要はなく、中小企業共通EDI対応のクラウドサービスや業界VANを月額利用する形で、小さく始める選択肢があります。

関連記事

• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：EDIが連携する社内側の中核、基幹システムの全体像を整理しています。
• ERPとは？基幹システム・CRMとの違いと主な機能・導入の進め方を解説：受発注・会計データの統合管理を担うERPとEDI連携の前提知識に。
• 業務システムとは？種類・基幹システムとの違いと開発・導入形態の選び方：EDIで受け取ったデータを処理する業務システム全般の分類と選び方です。