【EDI 2024年問題】製造業のEDIツール完全ガイド｜選定5観点とAI連携まで情シス向けに徹底解説

はじめに：なぜ今、製造業の情シスがEDIを見直すべきか

EDI（Electronic Data Interchange／電子データ交換）は、企業間の受発注・出荷・請求といった取引データを、人手を介さずシステム同士でやり取りする仕組みです。1970年代から続く古い領域でありながら、2026年現在、製造業の情報システム部門にとって最も「待ったなし」のテーマのひとつになっています。

業界で「EDI 2024年問題」と呼ばれているのが、その引き金です。NTT東日本／西日本のINSネット（ディジタル通信モード）は2024年1月に本サービスが終了し、現在は「補完策」（メタルIP電話上のデータ通信）で延命中ですが、その補完策も2028年12月31日で提供終了することが両社から公表されています。出典：NTT東日本 JCA手順・全銀手順（ベーシック）といったレガシーEDIの通信回線そのものが、遅くとも2028年末で完全に消滅するということです。一方で移行先候補（全銀TCP/IP、ebMS、JX手順、流通BMS、AS2／AS4、Web-EDI など）が乱立しており、自社にとって何が最適か判断しづらいのが現状です。

このまま手を打たなければ、ある日突然「取引先からのEDI注文が届かなくなり、生産ラインが止まる」事態が現実に起こります。受注が止まれば数日で在庫が枯渇し、納期遅延がサプライチェーン全体に波及していきます。サプライヤから「動かなくなりました」と連絡が入ってからでは、もう間に合わないテーマなのです。

弊社が製造業の情シス様からご相談を受ける際にも、次のような声が圧倒的多数を占めます。

「取引先から『Web-EDIに移行してほしい』と通知が来ているが、取引先ごとに違う画面が増えるばかりで、現場の事務作業が逆に増えている。」
「自社からEDIサーバを更改したいが、20年前に決めた手順がどの取引先で動いているのか棚卸できていない。」
「EDIで取り込んだ受注データを、結局Excelで突き合わせている。AIで例外処理を自動化したい。」

本記事では、製造業の情シス／DX推進担当の皆さまに向けて、次の論点を一気通貫で整理します。

• そもそもEDIとは何か、レガシーEDIと現代EDIで何が違うのか
• なぜ製造業ほどEDIへの依存度が高いのか（構造的な理由）
• EDI 2024年問題（INSネット本サービス終了と、補完策の2028年12月末提供停止）と移行先プロトコルの選択肢
• Web-EDI「多画面問題」と、その現代的な解決アプローチ
• 主要なEDIツール／サービスの整理（クラウド型・パッケージ型・業界EDI）
• EDI × AI／Difyで、例外処理と社内連携をどう変えるか
• EDI刷新を情シスが主導するときの実務チェックリスト

1. EDIとは：基礎から押さえる

1.1 EDIの定義

EDI（Electronic Data Interchange）とは、取引先と自社の業務システム間で、注文書・出荷案内・請求書などのビジネス文書を「合意された形式」で電子的に交換する仕組みです。FAXやメール添付ではなく、システム同士が直接やり取りする点が本質です。

EDIには次の4つのレイヤがあります。EDIツールを比較するときは、この4階層のどこをカバーしているかを必ず確認してください。

1.2 レガシーEDIと現代EDIの違い

「EDI」と一言で言っても、現場では大きく2世代が併存しています。

• レガシーEDI：JCA手順・全銀手順をベースに、INSネット（ISDN）や専用線を用いて、固定長のCSVデータを送受信する方式。1980〜90年代に大量導入され、いまも自動車・電機・流通の根幹に残っています。
• 現代EDI（インターネットEDI）：全銀TCP/IP、ebMS（ebXML Messaging Service）、JX手順、AS2、HTTPS／SFTPといったインターネット系プロトコル上で、XML や JSON、流通BMS のような業界標準メッセージをやり取りする方式。

INSネット終了（2024年1月本サービス停止／2028年12月補完策終了）の本質は、レガシーEDIの「通信手段」だけが先に消えることにあります。データ形式や業務運用規約はそのまま生き残るため、情シスは「通信手順だけ差し替えれば良いケース」と「データ形式ごと刷新したほうが良いケース」を見極める必要があります。

2. なぜ製造業でEDIが使われやすいのか：3つの構造的理由

EDIは流通業や金融でも使われていますが、製造業はとりわけ依存度が高い業界です。これは偶然ではなく、製造業の業務構造そのものがEDIを要請するためです。

2.1 取引点数と明細数が桁違いに多い

完成品メーカー1社の背後には、Tier1（一次サプライヤ）、Tier2、Tier3…と多層のサプライチェーンが広がります。自動車を例にとれば、1台あたりの部品点数は約3万点と言われ、車両1台を生産するために数百社が関わるとされています。

こうした構造下では、月次の発注明細件数も桁外れに大きくなります。電話・FAX・メールでの運用は現実的ではなく、EDIなしには日々の生産が止まることが、製造業のEDI依存を強くしている第一の理由です。

2.2 内示発注とJIT（ジャストインタイム）が前提

製造業の発注は、流通業のような「都度発注」だけでは成り立ちません。

• 内示：今後3〜6か月の生産計画に基づく見込み発注情報
• 確定発注：直近の確定数量・納期
• 納入指示：JITに基づく日次〜時間単位の納入タイミング

これらを段階的に取引先と共有する必要があり、データ項目は受発注フォーマットでも数十〜100項目を超えます。FAXやメールでの運用では精度・速度ともに耐えられず、必然的にEDI化が進みます。

2.3 業界EDI／業界ガイドラインが整備されている

製造業では、業界全体でEDIの標準化を進めてきた歴史があり、業界別の標準が今も現役で動いています。

業界EDIに自社が組み込まれている場合、EDIツールの選定基準として「その業界EDIに対応しているか」が最優先項目になります。汎用EDIツールでも、自動車JNXや流通BMSへの対応オプションの有無で導入難易度が大きく変わります。

3. EDIプロトコル／規格の全体像

EDIツールを比較する前に、自社で動いているEDIが「どの層」で構築されているかを把握する必要があります。情シスとして必ず棚卸すべき主要プロトコルを整理します。

3.1 通信手順（情報伝達規約）

• JCA手順：1982年に日本チェーンストア協会と当時の通商産業省が制定したコンピュータ間データ交換手順。長らく流通EDIの基本として広く使われてきました。公衆回線・INSネット上で稼働してきたものが多く、INSネット終了で最も影響を受ける手順です。
• 全銀手順／全銀TCP/IP：銀行向け資金決済EDIで使われてきた手順。全銀手順（ベーシック手順）はISDN／公衆回線ベース、全銀TCP/IPはその後継としてインターネット／広域IP網上で稼働します。
• JX手順：流通BMSで採用される、SOAP-RPC／HTTPS ベースのEDI通信手順。インターネット環境でセキュアにEDIを行うためのプロファイルで、JCA手順の現代的な後継として位置づけられます。
• ebMS（ebXML Messaging Service）：OASISと国連UN/CEFACTが共同で立ち上げた、XMLベースのB2Bメッセージング標準（ISO 15000として国際標準化）。電力業界の広域連系システムや政府系B2B基盤でも採用されています。
• AS2／AS4：グローバル標準のEDI通信プロトコル。AS2はIETFが策定（RFC 4130、2005年）したHTTPS上のセキュア交換手順で、北米・欧州の小売・製造業で広く使われています。AS4はOASISの「ebMS 3.0」をベースとした後継プロファイル（2013年OASIS標準）で、Webサービス／SOAPベース、大容量・多様なペイロード（XML／バイナリ等）への対応が強化されています。海外取引のある製造業は対応必須になるケースが多い領域です。
• SFTP／HTTPS：汎用ファイル転送やWeb-EDIの基盤として使われる、現代的な選択肢。

3.2 メッセージ規約（情報表現規約）

• 固定長CSV：レガシーEDIの主流。1バイト単位で項目位置が決まり、取引先ごとにフォーマット仕様書が存在する。
• EDIFACT：国連が策定した国際EDI標準。欧州・グローバルサプライチェーンで多用。
• ANSI X12：北米標準。米国子会社・現地サプライヤとのやり取りで頻出。
• 流通BMS（流通ビジネスメッセージ標準、XMLプロファイル）：流通システム開発センター／流通BMS協議会が普及推進する小売／流通の業界標準。インボイス制度対応の基本形 Ver.2.1を経て、2025年5月に Ver.2.2.1、2025年7月15日に再修正版 Ver.2.2.2 が公開（執筆時点での最新）。消費財メーカーは事実上対応必須。
• 業界個別XML：自動車（JAMA／JAPIA）や電機（ECALGA）など、業界団体が定義するXMLメッセージ。

3.3 補足：ZEDI（全銀EDIシステム）

ZEDI（全銀EDIシステム）は、全国銀行資金決済ネットワーク（全銀ネット）が運営する仕組みで、総合振込のEDI情報欄を従来の固定長20桁から、XML形式に拡張することで、振込電文に請求書番号・支払通知番号など商流情報を添付できるようにしたものです。EDI本体というよりは、EDIで送った請求情報と銀行振込を突合する金融EDIと理解してください。製造業の経理部門と連携した請求消込の自動化を考える場合、ZEDI対応の有無は重要な論点になります。

4. EDI 2024年問題：INSネット本サービス終了と「2028年12月」のリアル

4.1 何が起きるのか

NTT東日本／西日本のINSネット「ディジタル通信モード」は、2024年1月に本サービスとしては段階的に提供を終了しました。とはいえ移行が間に合わない事業者向けに、メタルIP電話回線上でディジタル通信モード相当の通信を行う「補完策」（メタルIP電話上のデータ通信）が提供されています。

そして、この補完策の提供終了日も「2028年12月31日」と公表されています。つまり、JCA手順や全銀ベーシック手順をINSネット上で運用してきた事業者は、遅くとも2028年12月31日までに、通信レイヤを別の経路に移行しないと、EDIそのものが停止します。これが本稿で「2028年問題」と呼ぶ事象です。

INSネットのディジタル通信モード上で稼働してきた典型例は、次のようなものです。

• JCA手順を使った、メーカー・卸・小売間の受発注EDI
• 全銀手順（ベーシック手順）を使った、銀行向け振込・口振データ伝送
• 専用機（EDI端末）を介した、自動車部品メーカー向け納入指示

これらは通信手段としてのINSが消えた瞬間に動かなくなります。データ形式は維持できても、通信レイヤだけ別の経路に乗せ替える必要があります。

4.2 主な移行先プロトコル

4.3 情シスが先に手を打つべき3点

1. EDI回線・手順の棚卸：「どの取引先と、どの拠点で、どの手順を、どのモデム／機器で運用しているか」を一覧化する。社外ベンダー任せにせず、自社で台帳を持つ。
2. 取引先別の移行スケジュール把握：大手取引先ほど早めに方針を出すため、文書ベースで一次情報を集める。自社よりも取引先側が遅れているケースも多い。
3. EDIゲートウェイ製品の検討開始：複数の現代プロトコルを束ねられるゲートウェイ（後述のHULFT／ACMS Apex／ASTERIA Warp 等）の選定を始め、PoC段階に入る。

5. Web-EDI「多画面問題」とその解決アプローチ

5.1 多画面問題とは

取引先（特に大手バイヤー）が自社専用のWeb-EDIを提供し、自社（サプライヤ側）はそのWeb画面にログインして発注書を確認し、納期回答や出荷案内を入力する、というスタイルが急速に広がっています。

個別の取引先1社だけなら何の問題もありませんが、サプライヤ側からすると、取引先10社あればWeb-EDI画面も10種類、IDも10個、操作手順も10通りになります。これが製造業の現場で「多画面問題」と呼ばれている事象です。

症状としては以下が典型です。

• 取引先ごとに違う画面に毎日ログインしなければならず、事務担当が疲弊する
• Web-EDI画面の発注情報をExcelに転記し、社内基幹に再入力する二重作業が発生する
• 納期回答が画面操作頼みになり、回答遅延・抜け漏れがクレーム化する

5.2 解決アプローチの選択肢

1. EDIゲートウェイ製品で「受信側」を統合する
   HULFT Square／ACMS Apex／ASTERIA Warp といったEDI／連携ハブ製品で、取引先別のWeb-EDIや各種プロトコルを集約し、社内システムには共通フォーマットで渡す。情シス主導の王道アプローチ。
2. Web-EDI自動化サービス／RPAを活用する
   どうしてもWebログイン操作が必要な取引先には、RPAやWeb-EDI自動取得サービスを使い、ブラウザ操作の自動化でデータを抜き出す。短期で効果が出るが、Web画面変更時の保守コストが論点。
3. 業界共通EDIプラットフォームに乗る
   中小企業共通EDIや、業界横断のEDIプラットフォーム（CO-NECT、BtoBプラットフォーム受発注 など）に取引先と一緒に乗ることで、画面そのものを統一する打ち手。取引先の同意が前提となるが、本質的な解決策。
4. AI／Difyで「画面操作後の処理」を自動化する
   Web-EDIから取得したデータの「ゆらぎ吸収」「例外検知」「社内問い合わせ」をAIで自動化する。データ取得そのものをなくすのではなく、取り込んだ後の人手作業を減らす方向の解決策（次章で詳述）。

6. 主要EDIツール／サービスの整理

ここでは、製造業情シスが選定候補に挙げやすい主要EDIツールを、性格別に整理します。各製品の詳細仕様は公式情報をご確認いただく前提で、「どの役割を担う製品か」に絞って整理します。

6.1 EDI／連携ハブ（オンプレ／クラウド両対応）

• HULFT Square／HULFT（セゾンテクノロジー）：富士キメラ総研「ソフトウェアビジネス新市場」においてファイル転送ツール分野で21年連続国内市場シェア1位のファイル転送／連携基盤。HULFT Squareはクラウド版（iPaaS）で、AS2／SFTP／全銀TCP/IP／JX手順など現代EDIのプロトコルを広くカバー。
• ACMS Apex（データ・アプリケーション）：EDIに特化した連携ハブ。全銀TCP/IP、JX手順、ebMS、AS2／AS4、流通BMS など国内主要規格への対応が手厚い。HULFT Multi Connect Service の基盤としても採用されています。
• ASTERIA Warp（アステリア）：EAI／ESB領域で国内シェア上位のデータ連携ツール。EDI／システム連携／API化をノーコードで扱え、情シスの少人数体制と相性が良い。
• DataSpider Servista（セゾンテクノロジー）：データ連携／ETLツール。基幹系とEDI／クラウド／DBの間を繋ぐ用途。

6.2 受発注クラウドEDI／業界向けサービス

• BtoBプラットフォーム 受発注／請求書（インフォマート）：食品・外食を中心に普及し、製造業にも広がる業界クラウドEDI。
• CO-NECT：中小製造業・卸・小売向けのクラウド受発注。FAX／メール／Excelから抜け出したい初期段階に向く。
• EOS名人.NET（ユーザックシステム）：流通EDIに強いパッケージ。流通BMS（JX手順）、JCA手順、全銀TCP/IP（広域IP網）に対応し、量販店・スーパー・ドラッグチェーン等のオンライン受注を一元管理できます。
• EDI－Master B2B（キヤノンITソリューションズ）：JX手順クライアント／AS2／全銀TCP/IPなどに対応する国産EDI製品群。
• EDIアウトソーシングサービス／TWX-21 連携（インテック・日立製作所）：製造業向け調達Web-EDIに強みを持つマネージドEDIサービス。

6.3 グローバル／海外取引向け

• IBM Sterling B2B Integrator：大企業の北米・欧州取引で標準的に使われるEDIプラットフォーム。AS2／EDIFACT／X12 対応。
• OpenText Trading Grid／GXS：グローバル取引網に乗るためのVAN／EDIサービス。
• Cleo Integration Cloud：北米サプライチェーン向けに強いクラウド型EDI／統合プラットフォーム。

6.4 業界ネットワーク／業界EDI標準

• JNX（Japanese automotive Network eXchange）：日本自動車研究所（JARI）が運営する自動車業界の閉域ネットワーク。2000年10月稼動、2,300社超が利用。商取引データに加え図面など機密データもセキュアに送受信。
• ECALGA（旧 EIAJ-EDI 標準を内包）：JEITA／ECセンターが推進する電機・電子業界の次世代EC標準。受発注に加え、製品仕様情報・環境情報・需給計画までスコープに含む。

6.5 選定のときに見るべき5観点

1. 対応プロトコルの幅：現行JCA手順・全銀手順からの移行を想定し、全銀TCP/IP、JX手順、ebMS、AS2／AS4、SFTP のうち自社で必要なものをどこまでカバーしているか。
2. 業界EDI対応：自動車JNX、流通BMS、ECALGA など、自社が属する業界の標準に対応しているか。
3. 運用形態：オンプレ／クラウド／マネージドサービスのどれを選べるか。情シスの体制と整合するか。
4. 社内システム連携：基幹（ERP／生産管理／販売管理）との連携が、ノーコード／ローコードで作れるか。アダプタが揃っているか。
5. セキュリティ・監査要件：通信暗号化（TLS1.2／1.3）、相手認証、ログ保管、内部統制要件（J-SOX）への適合。

7. EDI × AI／Difyで例外処理と社内連携を変える

EDIは「データを正しく送受信する」までしか解決してくれません。製造業の現場では、EDIで取り込んだ後の「人手による突合・例外処理・問い合わせ対応」こそが、情シス／管理部門の負荷になっています。

ここに、近年のLLM／AIエージェント（Difyなど）が刺さります。製造業全般でのAI活用事例は「製造業AI×活用事例を8選でまるわかり｜現場のコスト削減と導入方法を徹底解説」でも整理していますが、本章ではEDI領域に絞って、弊社がご支援している典型ユースケースを整理します。

7.1 受注データの「ゆらぎ吸収」

取引先からのEDI受注で、商品コードが取引先側マスタで表現されていたり、品名が略称だったりするケースは日常茶飯事です。従来は、社内のマスタ管理担当が目視で突合していました。

DifyベースのワークフローにLLMを組み込むことで、過去の突合実績と社内マスタを参照しながら、「この略称はおそらく自社マスタの◯◯」と候補提示し、確信度が高いものは自動で確定、低いものだけ人間にエスカレーションする運用が現実的になっています。

7.2 納期回答の自動ドラフト

Web-EDIで届いた発注に対する納期回答は、生産計画／在庫／部品手配の状況を踏まえて作成する必要があり、属人化しやすい業務です。

基幹システム・生産管理から在庫／計画データを取得し、DifyのワークフローでLLMに回答案を生成させ、担当者は確認・微修正だけを行う、という運用に変えるだけで、回答リードタイムを1日単位で短縮できます。

7.3 例外検知とアラート

内示と確定発注の差異、急なロット減、過去にない取引先・商品コードの出現など、「ヒトが見れば気づくが、ルールベース監視では拾いきれない例外」を、LLMで検知してSlack／Teamsに通知する仕組みが作れます。

7.4 EDI関連の問い合わせ対応RAG

製造業の情シスには「EDIが繋がらない」「フォーマットが違う」「過去の発注履歴を確認したい」といった問い合わせが日々入ってきます。EDIの仕様書・運用ガイドライン・過去のFAQをRAG（検索拡張生成）に載せておくことで、一次受けをAIに任せ、本当に人間が必要なケースだけ情シスに上げる運用に再設計できます。

7.5 設計上の留意点

• EDIデータは取引そのもの。LLMに丸ごと判断させるのではなく、「候補提示＋人間の確定」をワークフローに組み込み、監査ログを必ず残す設計にする。AIワークフローへの人間介在パターンは、別記事「Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を防ぐ安全設計を構築する」で詳述しています。
• 個社特有のコード体系はマスタとして外出しし、LLMはあくまで突合の候補出しに使う。マスタなしのLLM単独運用は事故のもと。
• 例外時の人間エスカレーション経路を最初に決める。SLAと責任分界点を明確にしないと、AI導入は「責任の押し付け合い」になる。具体的な運用パターンは「Human-in-the-Loopの活用事例　Difyでの具体的な運用パターン9選」もあわせてご参照ください。

8. EDI刷新を情シスが主導するときの実務チェックリスト

1. 現行棚卸：取引先別の手順／回線／フォーマット／月間トランザクション数を一覧化（最低でも上位80%カバー）。
2. 2028年問題影響度の評価：JCA手順・全銀手順（ベーシック）・INSネット補完策で稼働している取引のリスト化と、取引額／生産影響度のランキング。
3. 取引先方針の確認：大手取引先のWeb-EDI／プロトコル方針を一次情報で集める（営業経由ではなく文書ベース）。
4. 移行先プロトコル戦略：自社で標準化するインターネットEDIプロトコル（全銀TCP/IP・JX手順・AS2 など）を1〜2本に絞る。
5. EDIゲートウェイ製品の選定：HULFT／ACMS／ASTERIA／DataSpiderなどでPoC。社内連携アダプタの有無を必ず検証。
6. セキュリティ・統制設計：TLS・相手認証・鍵管理・監査ログ要件をRFP段階で固める。
7. 運用体制：監視・障害一次対応・取引先連絡の窓口設計。社内SLAを明文化。
8. AI／自動化レイヤの初期計画：受注ゆらぎ吸収・納期回答・例外検知のうち、効果が見えやすい1ユースケースを並走でPoC開始。
9. ロードマップ：2028年12月末を逆算した24〜30か月計画と、毎四半期のマイルストーン設定。
10. 経営報告：「EDI更改＝コスト」ではなく、「サプライチェーン継続性＋AI活用基盤」として経営層に説明する資料を整備。

9. 読者の方が今日、自社に持ち帰る5つの問い

EDI刷新は他社事例をなぞるだけでは進みません。「自分たちが何をすべきか」は、他社事例ではなく自社の取引構造のなかにしかないからです。本章を読み終わる前に、次の5つの問いに対する「今わかっている答え」と「分からない部分」を、5分でメモに書き出してみてください。経営報告資料の骨子になります。

このうち2問以上「No」「分からない」になった企業は、自社単独でロードマップを描く前に、外部の知見を入れて壁打ちすることをおすすめします。

まとめ

• EDIは古い領域に見えて、製造業の情シスにとって最優先テーマのひとつ。INSネット本サービス終了（2024年1月）と補完策終了（2028年12月31日）により、レガシーEDIは強制的に刷新を迫られている。
• 製造業がEDIに強く依存するのは、取引点数・内示／JIT・業界EDIという3つの構造的な理由による。
• 選定の軸は、対応プロトコル／業界EDI対応／運用形態／社内連携／セキュリティの5観点。HULFT、ACMS Apex、ASTERIA Warp、流通BMS／JNX対応サービスを横並びで評価する。
• Web-EDIの多画面問題は、EDIゲートウェイによる集約と、AI／Difyによる「取り込んだ後の人手作業」自動化の2段構えで解く。
• EDI更改を「通信手順の差し替え」で終わらせず、AI／自動化レイヤを並走で設計することが、製造業情シスにとっての本丸。

弊社からのご案内

弊社ノーコードソリューションズは、Dify／AIエージェントを中核としたエンタープライズAIの受託開発・伴走支援を行っています。EDI領域では、「EDIゲートウェイ製品の選定・PoC支援」から、「受注データのゆらぎ吸収」「納期回答ドラフト生成」「Web-EDI多画面の自動取得＋例外検知」など、EDIで取り込んだ後の業務をAIで再設計する領域を得意としています。

当社の支援領域は次の3つです。

• EDI現状棚卸・EDI 2024年問題（2028年12月補完策終了）影響度評価
• EDIゲートウェイ／クラウドEDIの選定支援
• Dify／LLMを活用した受発注業務のAI自動化PoC