EDI（電子データ交換）とは？

EDI（電子データ交換）の基本仕組みと4つの階層構造

EDI（Electronic Data Interchange：電子データ交換）とは、受発注書や納品書、請求書などの商取引データを、企業間のコンピュータ同士で標準化された形式を用いて自動送信・処理する仕組みです。従来のFAXや電子メール添付によるPDF送付と異なり、人の手によるデータ転記や内容の目視確認を挟まない「システム間（M2M）の直接連携」を可能にします。

JIPDECが定義するEDIの「4つの階層構造」

JIPDEC（一般財団法人日本情報経済社会推進協会）の定義によると、企業間で円滑にEDI取引を行うためには、通信やデータ形式に関する規約を4つの階層（レイヤー）に分けて整理する必要があります。どれか1つでも互換性が欠けると、データの正常な自動処理は成立しません。

• 情報伝達階層（通信プロトコル）：ネットワーク接続やデータの送信方法を定める通信レベルのルールです。通信回線を介してどのようにデータを届けるかを規定します。従来型の固定電話網で使われてきた「全銀手順」や「JCA手順」から、インターネット回線を利用する「JX手順」や「EDIINT AS2」といった現代的な規格への移行が進んでいます。
• 識別コード階層：取引先企業や取り扱う商品をシステム上で一元的に特定するための識別コードのルールです。自社システム内で独自に使用している商品番号をそのまま送信しても相手側のシステムでは判別できません。そのため、企業コード（GLN等）や商品コード（JANコード、GTIN等）といった共通化された識別体系を利用して、品目や拠点を正確に特定します。
• 情報表現階層（データフォーマット・構造）：データの並び順、文字コード、項目数、構文規則（シンタックスルール）を定める階層です。発注日・品番・数量・単価などの並び順や区切り文字を統一することで、受信側のプログラムがデータを誤認識することなく解析できます。小売・流通業界で広く普及している「流通BMS」や「CII標準」、XML形式などがこの階層の標準規格に該当します。
• 業務運用規約階層：システム上のデータ仕様だけでなく、実際の業務処理のタイミングや例外発生時の対応手順を規定する階層です。具体的には「当日発送分の発注データは毎日15時までに送信する」「回線障害やフォーマットエラーが発生した場合は30分以内に指定窓口へ連絡する」といった、実業務の取り決めや法的効果の明確化を含みます。

EDIとWeb EDI・B2B EC・基幹システム（ERP）の根本的な違い

企業間取引のデジタル化を進める際、データ連携の自動化範囲やデータ入力主体、適用対象によってシステムの役割は明確に異なります。

システム種別	データ入力・通信方式	主な役割	標準EDIとの違い
標準EDI	システム間（M2M）の自動データ連携	企業間の商取引データを標準形式で自動交換	取引基盤の標準（データ入力を自動化）
Web EDI	取引先がWebブラウザで手動入力・CSV送付	小口取引先との簡易的な発注・納品データ送信	取引先側でWeb画面の閲覧・手入力操作が発生する
B2B EC	発注者がWeb画面上のカタログから手動注文	新規・不特定多数の取引先からの受発注受付	ECサイト形式の受注窓口であり連携範囲が限定的
基幹システム（ERP）	自社従業員の入力または内部データ連携	自社内部の全業務・資産データの一元管理	社内システムであり企業間接続にはEDIを介する

基幹システム（ERP）が社内データを統合管理する役割を担うのに対し、標準EDIは自社と相手方の基幹システム同士を繋ぎ、手作業を挟まずデータを自動連携させるパイプラインとして機能します。

受発注・請求業務の自動化による定量的導入メリット

EDIの導入により、受発注や請求業務における手作業を削減し、業務スピードと処理精度を向上させることが可能です。

• 誤発注・入力ミスの排除による修正工数削減：紙伝票やFAXから基幹システムへデータを再入力する作業を撤廃します。月間3,000件の受発注伝票を手入力で処理している製造業の拠点では、約1〜2%（30〜60件）の転記ミスが発生し、確認や返品処理に月間約20時間を費やす場合があります。EDIによるM2M連携を行えば、データがそのまま自社ERPに反映されるため、手入力に起因する転記ミスを0件に抑えられます。
• ペーパーレス化に伴う直接コスト削減：紙伝票の出力・送付・保管にかかるコストを圧縮できます。月間5,000枚の伝票（注文書・納品書・請求書）を郵送・FAX処理する場合、紙代・トナー代・郵送費・回線費で年間約120万〜180万円の直接経費が発生します。EDI化によりデータを電子化することで、これらの経費を大幅に短縮可能です。
• 処理速度の高速化とリードタイムの短縮：FAX受信後の確認や手動入力によるタイムラグを解消します。16時の注文締め切りから基幹システムへの入力完了までに2時間を要していた業務が、EDI受信後数秒でERPに自動取り込みされるため、物流拠点での出荷準備作業に即座に着手できます。

固定電話網のIP化に伴い、従来のINSネットを利用した全銀手順などのレガシーEDIはサービスが縮小・終了傾向にあります。そのため、インターネットプロトコルを用いたJX手順や流通BMSへの移行を図り、処理速度の向上と安定した通信基盤の確保を実現させることが円滑な運用の鍵となります。

EDIの主要4タイプと通信プロトコル（JX手順・全銀手順・流通BMS）徹底比較

「従来型EDI」「インターネットEDI」「Web EDI」「クラウドEDI」の機能比較

EDIシステムは、通信基盤やシステム構造の違いによって主に4つのタイプに分かれます。自社のインフラ環境や取引先の状況に合わせて最適な方式を選択します。

EDIタイプ	通信基盤・方式	システム連携・構築形式	適合する取引規模・用途
従来型EDI	固定電話網（PSTN/ISDN） 専用回線	基幹システム個別開発 （バッチ処理中心）	既存レガシー環境の維持 （順次移行が推奨）
インターネットEDI	インターネット回線 （IP網/暗号化通信）	オンプレミスサーバー （API/ファイル間連携）	中〜大規模取引 基幹システム間の自動連携
Web EDI	インターネット回線 （HTTP/HTTPS）	Webブラウザ操作 （手入力/個別CSV入出力）	小規模取引先 個別受注・出荷情報の管理
クラウドEDI	クラウド基盤（SaaS/PaaS） （IP網/マルチプロトコル）	クラウドサービス （標準API/FTP連動）	全社統合型取引 多極間サプライチェーン全体

Web EDIは取引先がブラウザ上で操作できるため小規模企業との取引に適していますが、発注元ごとに画面仕様が異なると受注側での手作業が増加します。例えば、月間1,000件の出荷を処理する3PL事業者が複数の荷主から個別のWeb EDI画面経由で指示を受ける場合、画面操作やデータ抽出だけで毎日1〜2時間の工数が発生することがあります。このような運用負荷を軽減するため、複数プロトコルを一元管理できるクラウドEDIへの集約が有効な手段となります。

主要通信プロトコルの特徴（JX手順・全銀TCP/IP手順・ebXML・AS2）

インターネットEDIで採用される主な通信プロトコルごとの仕様と適用シーンは以下の通りです。

• JX手順: HTTP/HTTPSをベースとした通信プロトコルです。受注側から発注側へアクセスしてデータを受信する構造を持ちます。従来のJCA手順の運用イメージを継承しているため、既存の作業手順を大きく変えずにインターネット化へ移行できます。1取引あたり10MB（約1万明細）未満の処理に適しており、中小規模の卸売業やメーカーで広く利用されています。
• 全銀TCP/IP手順: 金融機関や企業間取引で使われてきた全銀協標準通信プロトコルを、TCP/IP環境に対応させた規格です。固定長フォーマットを維持したままIP網へ移行できます。現在はセキュリティを強化した広域IP網手順への置き換えが進んでいます。
• ebXML MS（Message Service）: 国際標準規格に基づき、サーバー間でのPUSH型通信により大容量データをリアルタイムに送受信します。到達保証や重複検知機能を備えており、大量の取引データを扱う大規模流通チェーンや総合スーパーの基幹通信に用いられます。
• AS2（Applicability Statement 2）: HTTP/HTTPS上でS/MIME暗号化やデジタル署名を行い、受領通知を用いて確実なデータ到達を証明する国際規格です。グローバルサプライチェーンや自動車産業、大手外資系ECプラットフォームとの連携で標準的に導入されています。

流通業界の標準規格「流通BMS」が主流となった背景とメリット

日本の流通業界において標準規格として定着しているのが、流通ビジネスメッセージ標準である流通BMSです。

流通BMSが主流となった要因には、従来の「JCA手順」における通信速度（2,400bps）の低さや、半角カナ・数字のみに限られるデータ構造の制限がありました。また、公衆電話網のディジタル通信モード終了に伴い、従来型の回線接続の継続が困難になったことがインターネット網を前提とした流通BMSへの移行を加速させました。

流通BMSでは通信手順にebXML MS、JX手順、AS2などを採用し、データフォーマットをXML形式に統一することで以下の利点をもたらします。

• 通信速度の向上と伝送時間の短縮: 光回線などのブロードバンドを利用することで、1万件（約10MB）の発注データ受信にかかる時間が、従来の1時間以上から数秒〜十数秒程度まで短縮されます。
• データフォーマット標準化による開発負荷軽減: 発注・出荷・受領・請求などの基本メッセージが統一化され、企業ごとの個別変換プログラム（トランスレータ）を作成するコストを抑えられます。
• 漢字表記や詳細データの送受信対応: XMLフォーマットにより漢字情報やGTIN（JANコード）、有効期限などの詳細なメタデータを扱えるため、文字化けや伝票読み替えによるミスを防止できます。

ISDN終了（2024年問題）に伴う従来型EDIの停波とインターネットEDI移行手順

固定電話網IP化（2024年〜2026年移行期）がEDI通信に与える影響

公衆交換電話網（PSTN）のIP網移行に伴い、INSネットの「ディジタル通信モード」は2024年1月にサービス提供が終了しました。現在は移行猶予措置として「メタルIP電話上のデータ通信（補完策）」が2028年12月末までの期限付きで提供されています。

ただし、補完策の通信環境では電話信号とIPパケットの相互変換処理が入るため、データ送信時間が従来の1.1倍から4倍程度に延伸することが確認されています。特にJCA手順や全銀手順などの固定長フォーマットは遅延の影響を受けやすい構造を持ちます。

例えば、日々の出荷指示データ（約5,000件）を全銀手順で受信する場合、従来は約15分で完了していた処理が補完策下では1時間近くまで延びることがあります。受信の遅れは倉庫でのピッキングや集荷時間の押し出しに直結するため、業務上の大きなリスクとなります。

レガシーEDIからインターネットEDI・Web EDIへの段階的移行4ステップ

通信の遅延リスクを排除し安定運用を確保するためには、インターネット回線網を基盤とする方式への移行が必要です。段階的な手順は以下の通りです。

移行ステップ	主な実施内容	実務上の留意点
Step 1：現行環境の棚卸しと切り替え対象の特定	自社で利用中の回線種別（INS64等）、通信プロトコル（JCA手順・全銀手順等）、相手先企業の通信方式をすべて抽出・整理する。	NTTからの請求書明細（INS通信料の有無）や端末の接続インターフェースを確認し、隠れたレガシー回線を漏れなく確認する。
Step 2：移行先プロトコル・システム規格の選定	取引規模や業界標準に合わせ、JX手順、流通BMS、Web EDIなど適切な移行先を定義する。	受発注データの容量や更新頻度に応じて方式を分ける。データ量の多い主要取引先には流通BMS、中小取引先にはWeb EDI等を適用する。
Step 3：データ変換テストおよび取引先との接続検証	データフォーマット（固定長データからXML/CSV等への変換）のマッピング設定を行い、検証環境でテスト送受信を実施する。	ピーク時と同等のデータサイズを用いた総合テストを行い、伝送エラーやフォーマットの定義漏れがないか確認する。
Step 4：本番切り替えと並行運用の停止	新旧システムの切り替えを実施し、一定期間の監視を経て旧回線の契約解除・設備撤去を行う。	切り替え初期の通信障害に備え、旧環境への一時的な切り戻し手順と連絡体制をあらかじめ準備しておく。

流通BMSやJX手順への切替により、データ伝送が数秒レベルで完了する環境を整えることで、後続の出荷準備業務に十分な余裕を確保できます。

移行プロジェクトで発生しやすいトラブルと事前回避策

インターネットEDIへの切り替えでは、取引先との調整や設定検証に関するトラブルを防ぐための対策があらかじめ必要となります。

• 取引先におけるシステム改修の遅れ
  取引先側でITリソースが不足している場合、通信プロトコルの変更に対応できず移行が滞る場合があります。この場合、相手側の改修作業が不要な「Web EDI」を閲覧・入力用として提供することで、相手側にシステム開発を強いずに移行を完了できます。
• データフォーマット不一致による伝送エラー
  文字コードの相違（シフトJISからUTF-8への変換など）や必須項目のマッピング漏れによりエラーが発生するケースがあります。単体テスト時に商品コード・数量・特殊文字の検証パターンを含めた差分チェックシートを作成し、漏れなく確認を行います。
• 接続テストの集中によるスケジュール遅延
  複数社とのテストが同時期に集中すると検証作業が滞ります。取引量や相手方の準備状況に応じて優先度を設定し、段階的に切り替え日程を分散させます。

自社に最適なEDI手法を選ぶための4つの比較判断軸とチェックリスト

EDI手法の選定では、「取引先数とデータ量」「導入・運用コスト」「既存システム（ERP・WMS等）との連携性」「セキュリティ・運用の容易性」の4軸で評価を行います。

自社開発（オンプレミス）の場合、仕様変更や通信手順改定のたびに改修コストが発生します。一方でSaaSやクラウド型サービスを利用する場合、プロトコルの規格更新やセキュリティ対応がベンダー側で維持されるため、運用負担の軽減に繋がります。

取引規模・データ量・コストに応じた最適なEDI方式の選定マトリクス

レガシーEDIからの移行先は、取引規模やデータ送信頻度によって適した選択肢が異なります。

EDI方式	主な通信プロトコル	対象となる取引規模・データ量	構築形態とコストの傾向
Web EDI	HTTPS	取引先数が数社〜数十社程度。画面での手動入力またはファイル（CSV等）の送受信が中心	SaaS/クラウド型が主流。初期費用を低く抑えられ、月額数万円程度から利用可能
流通BMS（標準EDI）	JX手順、ebXML MS	スーパー・ドラッグストア等の流通・小売業界との日次大量データ取引（数千〜数万件/日）	SaaS型または統合ミドルウェア。フォーマット標準化により取引先追加時の開発コストを抑制可能
個別EDI（専用手順）	全銀TCP/IP手順、SFTPなど	取引量が極めて大きく、取引先指定の独自フォーマットや厳格な伝送制御を求められる取引	自社開発（オンプレミス）または専用ゲートウェイ。初期開発費・維持費共に高額化しやすい

小売業界との受発注が多い場合、JX手順に対応した流通BMSのSaaS型サービスを導入することで、インフラ構築費用を圧縮しながら安定したデータ交換環境を整備できます。

基幹システム（ERP）および倉庫管理システム（WMS）連携時の注意点

EDIの導入効果を高めるには、自社のERPや倉庫管理システム（WMS）とのデータ連携を自動化することが重要です。

例えば1日あたり3,000件の受発注データを扱う食品卸売業において、Web EDIの画面から手動でCSVファイルをダウンロード・アップロードする運用では、毎朝約2時間の作業時間と入力ミスのリスクが残ります。この手作業を排除するため、以下の設計を実施します。

• コードマッピングの自動化: 自社と取引先で異なる商品コード（JANコード、品番）や拠点コードを自動変換する機能をEDIサーバーまたは連携ミドルウェア上で処理します。
• エラーハンドリングとバリデーション: フォーマットエラーや桁数オーバーが発生した際、WMSへデータが取り込まれる前に自動チェックを行ってエラーログを出力し、現場の出荷作業が止まるのを防ぎます。
• API・FTPによるデータ同期: SFTPやWeb APIを用いて、EDIシステムとERP・WMS間のデータ取り込み・出力を自動スケジュール実行します。

社内稟議・ベンダー選定で活用できる「EDI導入チェックリスト」

導入検討時に活用できる確認項目です。

• 1. 通信プロトコル・業界標準への対応
  • 主要取引先が要求する通信プロトコル（JX手順、ebXML MS、全銀TCP/IP手順等）をカバーしているか
  • 流通BMS等の標準フォーマット（XML構造）への変換機能が備わっているか
• 2. システム連携（ERP/WMS）とデータ変換機能
  • 自社のERPやWMSとAPI、FTP、CSVファイル等で自動接続できるか
  • 取引先ごとの固有データ項目やコード差分をノーコード/ローコードで設定変更できるか
• 3. コスト構造と保守運用体制
  • 取引先の追加や仕様変更の際、定額範囲内で対応できるか、あるいは個別改修費が発生するか
  • 通信障害・システムアップデート・セキュリティパッチの適用がベンダー側で管理されるか
• 4. 運用モニタリングとセキュリティ対策
  • 送信エラーや変換エラーが発生した際、管理画面で検知して再送やデータ修正を即座に行えるか
  • 通信路の暗号化（SSL/TLS）、アクセス権限管理、操作ログの保存などセキュリティ基準を満たしているか

サプライチェーン全体を最適化するEDI活用と次世代DX推進アクション

EDI活用を受発注データの送信のみにとどめず、受発注から出荷指示、入荷・検品、請求・決済に至る一連のデータを一気通貫で自動連携させることで、物流プロセス全体の効率が向上します。

月間5,000件の出荷を扱う3PL事業者やメーカーの場合、受注データが基幹システムに入力された直後にWMSへ自動送信され、同時に出荷案内（ASNデータ）が納品先へ送信される仕組みを構築します。これにより、納品先での入荷検品時にバーコードをスキャンするだけで現物照合が完了し、検品時間を従来比で約50%削ることができます。

流通業界では、通信プロトコルとしてJX手順やebXML MSを用いる流通BMSへの集約が進んでおり、受発注・出荷・受領・請求のデータフォーマットを統一することでシステム間のデータ変換負荷を軽減できます。

API連携・クラウドネイティブEDIによる拡張性とデータ活用の未来

クラウドネイティブEDIやiPaaSをはじめとするAPI連携基盤を採用することで、システム連携の柔軟性とデータ処理のリアルタイム性が向上します。

小規模な取引先に対してはWeb EDIを活用してFAXやPDFでのやり取りを排出しつつ、クラウドEDIをハブとして各種データを一元化します。

蓄積された受発注データや出荷データを配送位置情報や車両GPSデータと組み合せることで、需要予測や配送ルートの最適化に活用する構成が可能となります。また、国際物流や多層なサプライチェーンにおいては、ブロックチェーン技術を併用することで原産地証明や出荷データの改ざん防止と追跡の自動化を図ることができます。

自社のEDI環境刷新に向けてまず着手すべき「初期診断ステップ」

ISDN回線（INSネットディジタル通信モード）の段階的終了に伴う「2024年問題」の補完策提供期間にある現在、自社のレガシー通信環境の残存状況を確認し、計画的な移行を進めることが求められます。

初期診断における具体的な手順は以下の通りです。

ステップ	実施内容	具体的な確認項目・作業	確認すべき相手・相談先
1. 現状棚卸し	自社で使用している通信プロトコルと回線の抽出	INSネット利用の全銀手順、JCA手順、全銀TCP/IP手順の残存有無、回線契約の確認	社内情シス部門・ネットワーク管理者
2. 接続仕様調査	接続先ごとの移行方針および受け入れ可能手順の調査	相手方の流通BMS（JX手順等）対応状況、Web EDIへの切替可否、API連携の対応有無	主要取引先の発注・物流担当窓口
3. 業務マッピング	一気通貫連携に向けた受発注〜請求データのフォーマット確認	基幹システム・WMSとのデータ連携仕様、ASNや請求データの自動化要件	社内物流部門・経理部門
4. ベンダー選定	クラウドEDIベンダー等への相談と見積もり・検証の実施	クラウドEDIサービス（Web EDI機能含む）の選定、PoC（概念実証）の計画立案	EDIベンダー・システムインテグレーター

現状の課題と接続環境を整理した上で適切な通信手順・連携手法を選定し、システム移行とサプライチェーンのデータ連携をスムーズに推進します。

よくある質問（FAQ）