ホームブログ用語集電子データ交換（EDI）

電子データ交換（EDI）

17TRACK

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

電子データ交換（EDI）とは、合意された標準を使用して、組織間で構造化されたビジネス文書をコンピューター同士で交換することです。物流、eコマース、国際貿易では、購入者、サプライヤー、倉庫、運送業者、その他の取引先が運用するシステム間で、発注書、出荷通知、輸送指示書、請求書などの情報を、人が各文書を再入力することなく交換できます。

電子データ交換 EDI

EDIの特徴は、単に情報が電子的に送信されることではありません。情報はフィールド、セグメント、メッセージに整理され、受信側のソフトウェアが合意された仕様に従って解釈できるようになっています。そのため、メールにPDFで添付された請求書は、それだけではEDI請求書ではありません。業務システムで利用できるようにするには、人または文書処理ツールがその内容を抽出する必要がある場合があります。

EDIは、特定のソフトウェア製品、ネットワーク、ファイル形式ではなく、業務情報を交換する方法を指します。実際に機能する仕組みには、互換性のある文書定義、通信方法、識別子、業務ルールが必要です。

物流とeコマースにおけるEDI

EDIは、組織の境界を越える業務活動を接続します。小売業者の購買システムが注文を作成し、サプライヤーのシステムがそれを確認し、倉庫が商品の準備指示を受け取る場合があります。その後、出荷情報や請求書が個別のメッセージとして関係するシステム間を移動します。

eコマースでは、EDIは消費者向け店舗の背後にある企業間プロセスを支援できます。例えば、オンライン小売業者はEDIを利用してサプライヤーに在庫を発注したり、倉庫とフルフィルメント情報を交換したりできます。消費者のチェックアウト取引と、その後に小売業者が送信するEDIメッセージは関連する業務イベントですが、必ずしも同じ取引であるとは限らず、同じ技術インターフェースを使用するとも限りません。

国境を越える取引では、EDIは国際輸送や商業文書に必要な情報を伝送できます。税関当局も、独自の仕様に基づく構造化された電子メッセージを使用する場合があります。ただし、サプライヤーや運送業者とEDIメッセージを交換しただけで、税関申告を行ったこと、規制遵守を確立したこと、または商品のリリースが承認されたことにはなりません。

一般的な業務文書

以下の例は、文書の機能を示すものであり、必須の順序を示すものではありません。使用されるメッセージは、取引関係や適用される実装ガイドによって異なります。

文書またはメッセージ業務上の目的物流またはeコマースの例
発注書購入者が商品またはサービスを注文することを伝える。小売業者がサプライヤーに補充在庫を発注する。
注文回答または注文確認サプライヤーの注文への回答を伝える。合意されたメッセージが対応している場合、サプライヤーが数量を確認したり変更を提案したりする。
事前出荷通知または出荷案内到着前の出荷について説明する。倉庫が予定されているカートン、品目、数量の情報を受け取る。
輸送指示輸送サービスに関する指示を伝える。荷送人が合意された輸送詳細を輸送パートナーに送信する。
出荷状況メッセージ輸送イベントまたは状況を伝える。運送業者が出荷に関連するイベントを報告する。
請求書請求情報を伝える。サプライヤーが納品した商品の代金を小売業者に請求する。

事前出荷通知は、一般にASNと略され、予定されている出荷を説明するものです。商品が到着したことを証明するものではありません。同様に、出荷状況メッセージも自動的に配達証明になるわけではありません。その意味は、報告されたイベントと補足情報によって決まります。

標準、形式、通信方法

EDI標準は、業務メッセージの構造とデータ要素の意味を定義します。確立された標準ファミリーには、X12と、電子データ交換（行政、商業、輸送）のための国際連合規則であるUN/EDIFACTがあります。GS1も、UN/EDIFACTを基盤とするEANCOMやGS1 XMLなどのEDI標準を維持しています。

X12の例には、850発注書、856出荷通知／マニフェスト、810請求書があります。UN/EDIFACTには、発注書のORDERS、出荷案内のDESADV、請求書のINVOICなどのメッセージがあります。これらの例は標準間で関連する業務目的を持ちますが、構造や実装要件は互換性がありません。

標準だけでは、取引関係の詳細すべてを定義できません。取引先は、適用するバージョンと実装ガイド、必須フィールド、許可されるコード、識別子、検証ルールについても合意する必要があります。同じ標準ファミリーに対応している2つの組織でも、利用可能なメッセージを交換する前にマッピング作業が必要になる場合があります。

構成要素決定する内容例
メッセージ標準業務メッセージの構造と意味。X12請求書またはUN/EDIFACT出荷案内。
実装ガイド取引関係における特定のメッセージの使用方法。必須の出荷識別子と許可される数量単位。
通信方法システム間でメッセージを転送する方法。AS2または合意された安全なファイル転送の仕組み。
変換とマッピング外部メッセージのフィールドを内部アプリケーションのデータに対応付ける方法。受信した注文行を注文管理レコードにマッピングする。

AS2は、セキュリティと受領通知の仕組みを備え、HTTP経由で業務データを交換するための通信仕様です。発注書や請求書の形式ではありません。付加価値通信網（VAN）は、仲介メッセージ交換サービスを提供できますが、業務文書標準とは別のものです。

EDI交換の仕組み

  1. 業務イベントがデータを生成する。例えば、購入者がERPまたは注文管理システムで発注書を承認する。
  2. データがメッセージにマッピングされる。変換ソフトウェアが内部フィールドを、合意された標準と実装ガイドで必要とされる構造に変換する。
  3. 送信メッセージがチェックされる。検証では、構文、必須フィールド、コード値、取引先固有の要件などを確認する場合がある。
  4. メッセージが送信される。合意された通信チャネルを通じて、受信者または仲介者へ送られる。
  5. 受信者が検証と変換を行う。受信システムがメッセージを確認し、受け入れた情報を内部アプリケーション形式にマッピングする。
  6. 業務処理が続行される。受信アプリケーションが注文を作成したり、入荷予定を記録したり、例外を確認のために振り分けたりする場合がある。
  7. 応答が照合される。技術的な受領通知、確認応答、業務上の回答により、送信者は交換で何が起きたかを判断できる。

これらの手順によって、すべての取引が自動処理されるとは限りません。メッセージの構造が有効であっても、未知の商品識別子、無効な配送先、重複した文書番号、未対応の測定単位などにより、介入が必要になる場合があります。

受領、検証、業務上の受け入れ

EDI確認応答は、異なるレベルで動作します。輸送受領通知は、メッセージが通信エンドポイントに到達したことを示します。機能確認または実装確認は、構造チェックの結果を報告します。業務上の回答は、注文やその他の依頼が受け入れられたか、拒否されたか、変更されたかを伝えます。

これらの信号を同じものとして扱ってはいけません。送信が成功したからといって、注文が受け入れられたことや商品が出荷されることを必ずしも意味しません。確認応答の具体的な意味は、関連する仕様と取引先間の合意に基づいて解釈する必要があります。

注文から出荷までの例

小売業者がEDIを通じて海外のサプライヤーに発注書を送る場合があります。サプライヤーのシステムは、商品識別子、数量、希望配送情報を確認します。取引の仕組みに注文回答が含まれている場合、サプライヤーは別のメッセージで受け入れや変更案を伝えられます。

商品が準備されると、サプライヤーは出荷とその内容を特定する事前出荷通知を発行できます。受け取り倉庫はその情報を使って入荷に備え、予定数量と実際に受け取った商品を比較できます。サプライヤーは、小売業者の財務システムで処理するための請求書を送信することもできます。

この例は、EDIが組織間の記録をどのように接続するかを示しています。すべての関係者が同じソフトウェアを使用すること、各メッセージがリアルタイムで配信されること、商業文書が輸送や税関の要件に取って代わることを意味するものではありません。発注書、出荷参照情報、請求書を一致させるには、一貫した識別子と合意された業務ロジックが必要です。

EDIと関連技術

関連概念EDIとの関係重要な違い
アプリケーション・プログラミング・インターフェース（API）ソフトウェアがリクエストとデータを交換するためのインターフェース。EDIは標準化された業務メッセージを重視し、APIはソフトウェアサービスとの相互作用を定義する。両者は併用できる。
XMLデータの構造化に使用されるマークアップ言語。XML構文だけでは、合意された業務メッセージ標準は確立されない。
電子請求書請求書を電子的に発行・交換すること。EDIは電子請求書を支援できるが、法的・技術的要件は管轄区域によって異なる。
ERPまたは倉庫管理システム業務情報を作成または利用するアプリケーション。これらのシステムは業務を管理し、EDIは他の組織と情報を交換する手段を提供する。
出荷追跡出荷イベントを報告・解釈すること。EDIは状況情報を伝送できるが、それ自体が追跡ウェブサイトや完全な追跡サービスではない。

EDIとAPIは、すべてのアーキテクチャにおいて相互排他的な選択肢ではありません。組織は、取引先との取引にEDIメッセージを使用し、それらの取引を内部アプリケーションに接続するためにAPIを使用できます。適切な構成は、技術名だけでなく、文書要件、取引先の能力、タイミングの要件、運用管理によって決まります。

導入時の考慮事項と制限

システムが互換性のあるメッセージを正常に交換・処理できれば、EDIは手作業によるデータの再入力を減らせます。ただし、不正確な元データを修正したり、商業上の意見の相違を解決したり、例外処理の必要性をなくしたりするものではありません。自動化は、技術的な互換性と交換される業務情報の品質の両方に依存します。

EDI接続を確立する前に、取引先は次の運用上の事項を明確にする必要があります。

  • 文書の範囲：どのメッセージが必要で、どの業務イベントがそれらを発生させるのか。
  • 識別子：商品、場所、関係者、注文、出荷をどのように識別し、照合するのか。
  • メッセージ要件：どのバージョン、必須フィールド、コードリスト、マッピングルールを適用するのか。
  • 通信とセキュリティ：どの接続方法、認証方式、アクセス制御が必要なのか。
  • 確認応答：どの応答が配信、検証、業務上の受け入れを示すのか。
  • 例外処理：拒否されたメッセージ、応答の欠落、不整合なデータを誰が調査するのか。
  • 重複防止：再送を新しい業務取引とどのように区別するのか。
  • テストと変更管理：変更を本番環境に導入する前に、マッピングと取引先要件をどのようにテストするのか。

運用監視では、通信障害、データ検証エラー、業務上の例外を区別する必要があります。メッセージの再送は転送失敗には対処できますが、無効な商品コードは修正できません。重複管理がなければ、正常に処理された注文を再送することで、意図しない2件目の取引が作成される可能性もあります。

よくある質問

物流におけるEDIとは何ですか？

EDIは電子データ交換を意味し、システム間で業務文書を構造化して交換することです。物流では、出荷通知、輸送指示書、請求書、出荷状況メッセージなどが含まれます。

メールで送られたPDFはEDI文書ですか？

それだけでは違います。PDFは業務文書を電子的に提示できますが、EDIには、合意された仕様に従って受信システムが解釈できる構造化情報が必要です。

EDIはAPIと同じですか？

いいえ。EDIは標準化された業務文書の交換に関するものであり、APIはソフトウェアが別のサービスとどのように相互作用するかを定義します。統合では両方を使用できます。

EDI確認応答は、注文が受け入れられたことを意味しますか？

必ずしもそうではありません。確認応答は、業務上の受け入れではなく、送信や構造検証を確認する場合があります。その意味は、メッセージの種類と取引先間の合意によって決まります。

出典