Web EDIとは？仕組みとレガシーEDIとの違い・多画面運用の判断を解説

取引先から「今後の受注はWeb EDIでお願いします」と案内され、何を準備すればよいのか判断がつかない。Web EDI（ウェブEDI）は、インターネット回線とWebブラウザを使って企業間の受発注データをやり取りするEDIの一形態です。発注側が用意したサイトに受注側がログインし、画面上で注文を確認したりデータをダウンロードしたりする方式を指します。この記事では、Web EDIの仕組みと画面入力型・ファイル授受型・API連携型という3類型、専用線やISDNを使うレガシーEDIとの違い、受注側に残る多画面運用と手入力の負担、そして画面運用のまま続けるか自動連携に投資するかの判断基準を、2026年8月時点の情報で整理します。

まとめ：Web EDIの仕組みと対応判断の結論

Web EDIはインターネットEDIの一形態で、発注側が用意したWebサイトに受注側がIDとパスワードでログインし、ブラウザ画面から受注データを扱う方式です。専用の通信装置もISDN回線の契約も要らないため、受注側は初期費用をほとんどかけずに接続できます。その代わり、システム同士がデータを自動で交換するわけではなく、画面を開いて確認し、CSVを落として自社システムに入れ直す作業が受注側に残ります。発注側がシステム費用を負担し、受注側が入力工数を負う——この費用構造の非対称がWeb EDIの本質です。

対応の分かれ目は取引件数と接続社数に置いてください。Web EDIを指定してくる取引先が3社以内で、その経由の受注が月100件に届かないなら、画面運用のまま続けて構いません。指定が5社を超える、または月300件を超えるなら、複数サイトからのデータ収集と基幹システムへの取り込みを自動化する側に投資した方が回収できます。判断に使う類型の見分け方と、件数ごとの損益分岐を本文で順に示します。

Web EDIの定義とブラウザで受発注データをやり取りする仕組み

はじめに、Web EDIが何をどう動かしているのかを操作の流れから確認します。呼び名の定義より、受注側の手元で何が起きるかを押さえた方が、後半の投資判断に直結します。

Web EDIの意味と受注側がブラウザで行う操作の流れと確認項目

Web EDIとは、Webブラウザを画面インターフェースにしてEDI（電子データ交換）を成立させる方式です。発注側の企業が自社の受発注サイトを用意し、取引先である受注側にログイン用のIDを配ります。受注側はブラウザでそのサイトを開き、届いている注文データを一覧で確認し、受注の意思表示（受領登録や注文請書の返信）を画面上で行います。

その後の流れも同じ画面の中で進みます。出荷したら出荷案内を入力し、納品が済めば納品データを登録し、月末には請求データを送る、という具合です。受注側に必要なのはインターネット回線とブラウザ、そして配布されたIDだけで、専用ソフトの購入もサーバーの構築も伴いません。この手軽さが、Web EDIが企業間取引の入り口として広く採られてきた理由になります。

画面入力型・ファイル授受型・API連携型に分かれる3類型の選定基準

ひとくちにWeb EDIといっても、受注側の作業量は方式によって大きく変わります。実務では次の3類型で見分けてください。

画面入力型は、注文の確認から出荷登録まで人が画面を操作する方式です。ファイル授受型は、注文データをCSVなどでダウンロードし、返送データをアップロードする方式で、ダウンロード後の取り込みを自社側で自動化する余地があります。API連携型は発注側がWeb APIを公開し、受注側のシステムが直接データを取りに行く方式で、人の操作が要りません。

取引先から接続を求められたときに最初に聞くべきは、この3点です。画面操作しかできないのか、CSVの入出力があるのか、APIが提供されているのか。同じ「Web EDIに対応してください」という依頼でも、答えによって自社にかかる工数は10倍以上変わります。取引としてのEDIの流れや、受け取ったデータに生じる電子帳簿保存法上の保存義務はEDI取引とは？発注から支払までの流れ・具体例と電子帳簿保存法の対応を解説で整理しています。

インターネットEDIとWeb EDIの関係と呼称を使い分ける判断基準

インターネットEDIは、インターネット回線を通信基盤にするEDI全般を指す総称です。流通BMSで使われるJX手順やebXML MS、AS2といった通信手順でシステム同士が自動的にデータを交換する方式も、この総称に含まれます。Web EDIはインターネットEDIの一部であり、ブラウザ画面を介する方式に限った呼び方だと理解してください。

表記は「Web-EDI」「WebEDI」「ウェブEDI」などが混在しますが、指しているものは同じです。注意すべきなのは、社内や取引先との会話で「インターネットEDIに移行する」と言ったとき、話し手が自動連携を想定しているのか、ブラウザ画面での運用を想定しているのかがずれる場面があること。導入検討の初期に、この2つを言葉として分けておくと、後工程での認識違いを防げます。受発注のシステム化全体の選択肢は受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準で整理しています。

レガシーEDIとWeb EDIの通信手段・費用・期間の違いと選定基準

Web EDIの位置づけは、それ以前のEDIと並べると輪郭がはっきりします。何が変わり、何が受注側に残ったのかを3つの軸で比べます。

通信回線と通信手順の違いと接続開始までにかかる期間の実務比較

レガシーEDIと呼ばれる旧来方式は、電話回線やISDN回線（INSネット）の上で、1980年制定のJCA手順や1983年制定の全銀協標準通信プロトコル（全銀手順）を使ってデータを送受信してきました。接続には通信回線の契約に加え、EDI専用の通信装置やモデム、受け取ったデータを自社形式に直す変換ソフト（トランスレータ）が要ります。取引先ごとの仕様確認とテストを含めると、接続開始まで数週間から数カ月かかるのが通例でした。

Web EDIはこの前提を取り払います。通信は既存のインターネット回線とHTTPSで賄われ、受注側に必要な機材はPCとブラウザだけです。発注側にIDの発行を申請すれば、早ければ即日から数日で受注が始められます。接続までの期間が桁で縮む点が、レガシー方式との最も分かりやすい差になります。

受注側と発注側で非対称になる導入費用と運用負担の実務比較と判断軸

費用の見え方も逆転します。レガシーEDIでは、受注側にも回線・装置・変換ソフトの初期投資が発生しました。Web EDIでは、システムを用意するのは発注側で、受注側の負担は実質ゼロというケースが大半です。ここだけ見ると受注側に有利な変化に映ります。

ただし、消えたのは初期費用であって作業ではありません。レガシーEDIが変換ソフトで機械的に処理していた「受け取ったデータを自社システムに入れる」工程が、Web EDIでは人の手入力に置き換わる構造です。発注側から見れば取引先ごとの個別接続をやめて自社サイトに集約できた合理化ですが、受注側から見れば毎日の画面操作という運用コストを引き受けたことになります。この非対称を認識しないまま「無料で使えるから」と受け入れると、取引先が増えた時点で人手が足りなくなります。

INSネット終了後にWeb EDIが移行先へ選ばれる背景と対応期限

レガシーEDIからの移行が全国規模で進んだ引き金は、通信インフラ側の変更です。NTT東日本・西日本の告知によれば、INSネットの「ディジタル通信モード」は2024年1月から地域ごとに段階的なサービス終了を迎えました。切替後もデータ通信を続けられる補完策は用意されているものの、提供終了予定日は2028年12月31日と案内されており、従来より伝送遅延が生じて処理時間が増大する場合があるとも説明されています（2026年8月時点）。

この期限に対して、受注側が最も軽く着手できる移行先がWeb EDIでした。自社に装置を持たず、発注側の画面に合わせるだけで取引を継続できるためです。一方で、期限を機に自動連携まで作り直す選択肢もあります。2024年問題の全体像、対象業務の棚卸し手順、標準EDIや業界VANまで含めた移行先の比較はEDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説で扱っているため、本記事はWeb EDIを選んだ後に何が起きるかへ話を進めます。

受注側に生じる多画面運用と手入力の実務コストを測る条件と判断基準

Web EDIで最も見落とされるのが、取引先が増えたときの運用の膨らみ方です。1社なら問題にならない負担が、社数に比例せず跳ね上がります。

取引先ごとにIDと画面が増える多画面運用の発生条件と管理負担

Web EDIは発注側がそれぞれ自前で用意する仕組みのため、共通の窓口がありません。大手取引先5社と接続すれば、URLが5つ、IDとパスワードが5組、画面の操作手順が5通り生まれます。締め時刻も発注側の都合で決まるので、午前10時締めの会社と午後3時締めの会社が混在します。

結果として担当者は、毎朝5つのサイトを順に開いて新着注文を拾い、それぞれの締めに合わせて返信するという巡回作業を負います。これが多画面運用と呼ばれる状態です。手順が属人化しやすく、担当者が休んだ日に受注漏れが起きる、パスワードの更新期限を1社分だけ逃してログインできなくなる、といった事故がここから生まれます。社数が増えるほど、確認漏れの確率は掛け算で悪化します。

CSVダウンロードと手入力が残る場合に削減効果が出ない失敗パターン

EDIの導入効果は、転記入力という工程そのものが消える点にありました。ところが画面入力型のWeb EDIでは、注文内容を見て自社の販売管理システムに打ち直す作業が残ります。ファイル授受型でCSVを落とせても、そのファイルを自社形式に直して取り込む仕組みがなければ、Excelを開いて貼り付ける手作業に落ち着きます。

数字にすると輪郭が出ます。1日30件の注文を1件3分で転記していれば毎日1.5時間、月20営業日で30時間が入力に消える計算です。人件費を時給2,500円で換算すれば月7万5,000円、年間では90万円規模です。加えて、打ち間違いによる誤出荷が起きれば、返品・再配送・謝罪の対応工数が別途乗ります。Web EDIに切り替えたのに省力化を実感できないという声の大半は、この残存工数を測っていないことに原因があります。

Web EDIの画面運用を続けるか自動連携へ投資するかの判断

ここからは判断を言い切ります。分かれ目は接続社数と月間件数、そして誤出荷の発生頻度の3つです。

画面運用のまま維持してよい取引件数と社数を決める具体的な判断基準

次の3条件をすべて満たすなら、投資は見送って構いません。第一に、Web EDIを指定してくる取引先が3社以内であること。第二に、その経由の受注が月100件に届かないこと。第三に、受注業務を担当できる人が社内に2人以上いて、締め時刻にも余裕があることです。この規模なら、自動化の開発費や集約サービスの月額を払っても、削減できる工数が費用を下回ります。

「いずれ件数が増えるから今のうちに」という理由での前倒し投資は勧めません。Web EDIの仕様は発注側の都合で変わり、画面改修に合わせて自動化の作り込みも直す必要が出るためです。件数が閾値に届くまでは画面運用で受け、その間に注文の件数と所要時間を記録しておくと、投資判断の根拠がそのまま手に入ります。

収集と取り込みの自動化に投資すべき条件と回収を決める判断基準

逆に、次のいずれかに当てはまるなら着手してください。Web EDIを指定する取引先が5社以上に増えた、経由する受注が月300件を超えた、転記ミスによる誤出荷が月1件以上発生している、のいずれかです。この段階では、削減できる工数が開発費を上回ります。前節の試算で年間90万円規模の入力工数が発生している場合、200万円弱の連携開発でも2年強で回収できる計算になります。

打ち手は3つあります。発注側サイトからのCSVダウンロードを自動実行し、変換して基幹システムに取り込む仕組みを作る。複数のWeb EDIをまとめて受信する集約型のEDIサービスを契約する。取引先にAPI連携型への切り替えを交渉する。現実には、取引先ごとに提供機能が違うため、この3つを組み合わせた設計になります。複数のWeb EDIから集めたデータを自社の販売管理や在庫システムへ流し込む部分は既製品で埋まりにくく、変換ルールと業務フローに合わせた個別開発になりがちです。一創ではAPI開発・システム連携として、外部サービスとのデータ連携基盤の設計・構築を受託しています。

次世代EDIやAPI連携へ寄せる判断と見送ってよい場面の選定基準

次世代EDIと呼ばれる方向性は、画面を介さずデータで直接つなぐ流れを指します。中小企業向けには2018年3月に初版仕様が公開された中小企業共通EDIがあり、流通業界では2007年運用開始の流通BMSが標準として動いています。発注側がこれらに対応済みなら、標準準拠の製品を選ぶだけで自動連携に届くため、迷わず寄せてください。

見送ってよい場面も明示します。取引先がいずれも独自のWeb EDIしか提供しておらず、標準規格やAPIに対応する予定もないなら、自社だけが標準化を進めても接続先が生まれません。この場合に効くのは、外部規格を追うことではなく、自社側の受け口を1本にまとめることです。取引先ごとに異なる入り口を、社内では単一の受注データ形式に正規化してから基幹システムに渡す。この設計にしておけば、将来どの取引先がAPIに対応しても、変換部分を1本足すだけで済みます。標準化を待つより、自社の取り込み口を先に整える方が費用対効果は高い、というのが結論です。取り込み口を整えたうえで製品選定に進む段階では、EDIシステムの比較で4タイプの適性と連携方式を確かめる手順が判断材料になります。

よくある質問

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

Web EDIと従来のEDIは何が違いますか？

通信の土台と、人が介在するかどうかが違います。従来のEDIは専用線やISDN回線の上で通信手順を取り決め、システム同士が自動でデータを交換していました。Web EDIはインターネット回線とブラウザを使い、受注側が画面を操作する前提で設計されています。データを交換するという目的は同じでも、受注側に手作業が残る点が実務上の最大の差です。

Web EDIの導入に受注側の費用はかかりますか？

多くの場合、受注側の初期費用と月額費用は発生しません。発注側が用意したサイトにログインするだけで始められるためです。ただし無料なのはシステム利用料であって、日々の画面確認や転記入力の人件費は自社負担になります。この隠れ費用を含めた総額の考え方はEDIシステムの費用を整理した記事で扱っています。接続社数と件数が増えたときに人手が追いつくかを、費用として見積もっておいてください。

Web EDIのデータを自社の販売管理システムに取り込めますか？

発注側がCSVなどのファイル出力かAPIを提供していれば取り込めます。画面表示しかできない場合は、そのままでは自動連携できないため、発注側へファイル出力の可否を確認するのが先です。取り込みには自社形式への変換処理が必要で、取引先ごとに項目名やコード体系が異なるため、変換ルールの設計が実装作業の中心になります。

Web-EDIとWebEDI、インターネットEDIは同じ意味ですか？

「Web-EDI」「WebEDI」「ウェブEDI」は表記の違いだけで、同じものを指します。インターネットEDIは範囲が広く、インターネット回線を使うEDI全般の総称です。JX手順やAS2でシステム間を自動連携する方式もインターネットEDIに含まれるため、Web EDIはその中のブラウザ方式に限った呼び方だと整理してください。

INSネットの終了後もWeb EDIならそのまま使えますか？

Web EDIはインターネット回線を使うため、INSネットの終了による直接の影響を受けません。注意が必要なのは、社内にISDN回線を使う別の業務（ファームバンキングやPOSデータ伝送など）が残っている場合です。Web EDIへ移行済みでも、それ以外の経路が補完策で延命している可能性があるため、回線契約と業務の棚卸しを一度実施しておくことを勧めます。

関連記事

• EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説：Web EDIの上位概念にあたるEDI全体の定義・種類・移行判断を整理しています。
• 購買管理システムとは？機能・5原則から選び方とERP連携の判断まで解説：発注側でWeb EDIとつながる購買業務のシステム化を扱っています。
• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：Web EDIで受け取ったデータを流し込む社内側の全体像です。