Web-EDIの比較基準とは？個社仕様・発注側/受注側の違いと選び方を整理

◆監修・編集責任者　小園 将隆　2026年9月22日

B2B EC-COLUMN

取引先からWeb-EDI対応を求められたら最初に確認すること

取引先から「今後の発注はWeb-EDIでお願いしたい」と連絡が来た、あるいは電話とFAXと手入力の往復に限界を感じて調べ始めた。
そこで最初に決めるのは製品ではなく、自社が発注側としてこの話に関わっているのか、受注側として関わっているのかという立場です。
Web-EDIは取引先ごとに画面もデータ項目も異なる個社仕様のものが中心で、この仕様差こそが比較で差の出るところだからです¹。
発注側なら取引先にどれだけ個別対応を強いるか、受注側なら並んだ違いをどこで吸収するかが基準になります。
ISDN(INSネット)回線を使った従来型のEDIを利用しているなら、通信サービスの終了予定という期限も条件に加わります³。

「Web-EDIに対応してほしい」という一文は、受け取る側によって意味が変わります。
発注側にとっては自社が用意した受発注の画面を取引先にも使ってもらうという意味ですし、受注側にとっては相手の画面をもう一つ覚えるという意味になります。
同じ言葉で話しているのに、負担のかかる場所が正反対にあるわけです。

比較の資料を読んでも話が噛み合わない感じが残るのは、多くの場合ここが原因です。
発注側向けに書かれた説明は自社の業務がどれだけ楽になるかを中心に据えますし、受注側向けの説明は取引先の画面をどう捌くかを中心に据えます。
自分がどちらの読み手なのかを決めないまま読み進めると、どの軸を重く見ればよいかが最後まで定まりません。

発注側であれば、どの仕組みを使うかを決める側に立っています。
取引先の数だけ影響が広がるので、選択の自由度は高い代わりに、決めた結果が社外にも及びます。
受注側であれば、仕組みそのものは相手が決めてしまっているので、選べるのは「相手の仕組みをどう受けるか」の部分に限られます。
比較対象が製品ではなく自社側の受け方になる、という違いは早い段階で押さえておくと迷いが減ります。

次に、取引先が求めているものが取引先独自のWeb-EDIなのか、業界で共通化された仕様に沿ったものなのかを確かめます。
この区別が要るのは、現状のWeb-EDIには個社ごとの仕様が中心という事情があるからです。
流通BMS協議会は、個社仕様のWeb-EDIが広がることを抑える狙いでWeb-EDIのガイドラインを策定しています¹。
業界団体が抑制のための手当てを置いているということは、裏返せば、取引先ごとに違う画面と違うデータ項目が並ぶ状態が前提になっているということです。

三つ目は、いま自社が受発注に使っている回線と手順です。
担当者がブラウザでログインして注文を見ているのか、それとも事務所の機器が電話回線を通じてデータを受け取っているのか。
後者であれば、あとで触れるとおり通信サービスの終了予定という期限が比較条件に加わります。
期限の有無は、選び方そのものより先に日程を決めてしまうので、影響の大きい確認事項です。

自社の立場、取引先の要求の中身、現行の通信方式。
この三つが決まると、これから見ていく比較軸のうちどれを重く見るかがかなり絞られます。

Web-EDIとは何か、比較対象になる範囲

Web-EDIは、インターネットを使いWebブラウザーの操作で受発注のやり取りを実現するEDIと説明されています²。
EDIは企業間で注文や納品のデータをデータのままやり取りする仕組みのことで、その通信にインターネットとブラウザを使うものがWeb-EDIにあたります。
ただし、この呼び名は公的に統一された定義が告示されているものではなく、媒体や事業者の説明として使われている言葉です。
比較資料を読むときに、相手が何をWeb-EDIと呼んでいるのかを確かめておくと、後の話が噛み合いやすくなります。

対になるのが、専用の通信手順を使う従来型のEDIです。
JCA手順や全銀手順といった決められた方式で、電話回線を通じてシステム同士がデータを送り合ってきました。
この形は人が画面を開く必要がなく、受注データがそのまま自社のシステムへ入ります。
一方でWeb-EDIは、人がブラウザを開いて注文を確認する形が基本になります。
ここに、比較で見落とされやすい差が潜んでいます。

ブラウザで見えるということは、見た内容を自社の販売管理システムなどへ移す作業が残りうるということです。
画面からデータを書き出せる場合もありますが、その形式が自社側で読める形かどうかは仕組みによって異なります。
「電子化されている」ことと「自社のシステムへ自動で入る」ことは別の話で、比較のときはこの二つを分けて聞く必要があります。
同じWeb-EDIという名前でも、注文を画面で確認できるところまでを想定したものと、データの受け渡しまでを想定したものでは、導入後に残る作業がまるで違います。

そのうえで、比較対象になる範囲を整理しておきます。
取引先が自社用に用意しているWeb-EDIは、そもそも選べる対象ではなく、使うか使わないかの判断になります。
業界標準に沿ったサービスは、対応している事業者の中から選ぶ余地があります。
そして自社の受発注システムそのものや、取引先から受けたデータを取り込む自社側の仕組みも、実務上は同じ検討の中に入ってきます。

つまり「Web-EDIを比較する」と言いながら、実際に自社で選べるのは後ろ二つだけ、という場合があります。
これは検討が進んでいないという意味ではなく、受注側に立てば自然に起こることです。
選べない部分を比べようとして時間を使うより、選べる部分の条件を詰めたほうが判断は早く進みます。

Web-EDIの比較で差が生まれる理由(個社仕様の壁)

流通BMSのような業界標準に準拠しているか

流通BMSは流通ビジネスメッセージ標準の略で、消費財の流通における企業間のデータのやり取りを共通化するために整備された標準です。
この標準を扱う流通BMS協議会が、個社仕様のWeb-EDIが蔓延することを抑える狙いでWeb-EDIのガイドラインを策定しています¹。
抑制という言葉を使って手当てが置かれている点に、この問題の性格が表れています。

標準に沿った仕組み同士であれば、データの項目名や意味、やり取りの手順が揃います。
取引先が一社増えても、同じ考え方で受け取り方を組み立てられます。
逆に標準に沿っていない仕組みは、その取引先のためだけの覚え方と手順が必要になります。
比較の一番目の判定は、ここに置くのが分かりやすいところです。

ただし、流通BMSは流通業を中心に整備された標準であり、どの業界にも同じ形の標準が用意されているわけではありません。
自社の業界に共通の仕様があるかどうかは、取引先や業界団体に確認して初めて分かる部分です。
共通の仕様がない領域では、次に述べる個社仕様の負担をどう抑えるかが、そのまま比較の実質になります。

独自仕様のWeb-EDIを使う場合に生じる負担

独自仕様の負担は、一つひとつを見ると小さく見えます。
ログインするURLとIDが取引先ごとに違う、注文番号の呼び方が違う、数量がケース単位かバラ単位かで表記が違う、書き出せるファイルの形式が違う、締め時間が違う。
どれも単体なら覚えれば済む差です。

効いてくるのは数が増えたときです。
たとえば受注担当が朝に三社の画面を開いて注文を確認するとします。
一社目は一覧を書き出せて自社の形式に近い、二社目は書き出せるものの項目の並びが違うので手で並べ替える、三社目は画面を印刷して自社システムへ手入力する。
こうなると、注文を受けるという仕事そのものより、社ごとの違いを吸収する仕事のほうに時間が向きます。

さらに厄介なのは、その違いの覚え方が担当者の頭の中にしかない状態になりやすいことです。
どの画面をいつ開くか、どの項目を読み替えるか、締め時間を過ぎた注文をどう扱うか。
手順書に落とすほどでもない細かい判断が積み上がっていて、担当者が休んだ日に別の人が同じ手順を再現できません。
新しい取引先が増えたときも、その人の負荷だけが上がっていきます。

比較のときは「機能が多いほうが良い」と考えたくなりますが、個社仕様の世界ではそこが本筋になりません。
自社が抱える取引先の組み合わせに対して、違いを吸収する手作業がどれだけ残るか。
差の出どころはここにあります。

発注側として比較する場合の基準

発注側でWeb-EDIを選ぶとき、判断材料になりやすいのは自社の画面の使いやすさや、自社の基幹システムとのつながりです。
ただ、実際に毎日その画面を開いて注文を受け取るのは取引先です。
ここに、発注側の比較に特有の見落としがあります。

流通BMS協議会が個社仕様の広がりを抑えようとしているのは、標準化されていない仕組みが増えると、受け取る側に個別対応が生じるからです¹。
発注側がどの仕組みを選ぶかは、自社の業務だけでなく、取引先が何社ぶんの個別対応を抱えるかにも関わっています。
取引先の側から見れば、自社の発注画面は「対応しなければならない画面のうちの一つ」として数えられているわけです。

そう考えると、発注側の比較軸には自社の使い勝手と並べて次のような点が入ります。

・業界で共通化された仕様に準拠しているか
・取引先が注文データを自社システムへ取り込める形で受け取れるか
・専用ソフトの導入や特定の環境を取引先に求めていないか
・操作の手順書や問い合わせ先が、取引先に対して用意されているか

取引先の規模差も考慮に入ります。
受注担当が一人か二人という規模の取引先では、システム同士を接続する対応まで求められると、そもそも動けません。
その場合はブラウザの画面だけで注文の確認から返信まで完結できるかどうかが分かれ目になりますし、逆に規模の大きい取引先はデータで受け取れることを求めます。
取引先の顔ぶれが幅広いほど、どちらか一方だけを想定した仕組みは無理が出ます。

これは相手への配慮というより、自社の業務を守る話でもあります。
取引先が対応しきれなければ、その分だけ電話やFAXでのやり取りが残ります。
一部の取引先だけ別経路のまま残ると、発注側の業務も二本立てで続きますし、締めや納期の把握も経路ごとに分かれたままです。
導入して何が変わるかは、取引先がどれだけ乗れるかで決まる部分が大きい。

受注側として複数取引先のWeb-EDIに対応する場合の基準

受注側の事情は発注側と対称ではありません。
取引先がそれぞれ別のWeb-EDIを指定してくる以上、どの仕組みを使うかという選択自体が手元にないからです。
比較の対象になるのは、取引先が用意した画面の良し悪しではなく、それらをまとめて受けるための自社側の仕組みになります。

流通BMS協議会の説明でも、標準化されていないことによって卸、つまり受け取る側に個別対応が発生することが問題として挙げられています¹。
受注側が感じている負担は、個々の取引先の仕組みが劣っているから生じているというより、違うものが並ぶことから生じている。
したがって比較で見るべきは、その違いの吸収をどこで行うかです。

具体的には、次のような点が判断の分かれ目になります。

・各取引先の画面から注文データを書き出せるか、書き出せる場合はどの形式か
・書き出したデータを自社の受注管理へ取り込む経路があるか、人が並べ替えてから取り込むのか
・取り込めない取引先が残る場合、その分の手入力が続く前提で運用を組めるか
・どの取引先の画面を誰がいつ開くかが決まっていて、担当者以外へ引き継げる状態か

最後の点は軽く見られがちですが、実務では効きます。
取引先ごとに締め時間が違えば、画面を開く順番にも意味が出てきます。
その順番と判断が一人の記憶に依存していると、仕組みを入れ替えるときにも、何を再現すればよいのかが分からないまま検討することになります。
比較の段階で現在の手順を書き出しておくと、どの部分が新しい仕組みに置き換わり、どの部分が人の判断として残るのかが見えます。

ここで大事なのは、全部を自動でつなげないと意味がないと考えないことです。
三社のうち二社ぶんの転記がなくなるだけでも、残る一社の確認に手をかけられます。
逆に、すべての取引先へ一律に対応できる仕組みを最初から求めると、検討そのものが止まりやすい。
いま手作業になっている部分のうち、どれが最初に減るのか。
受注側の比較は、この順で見ると判断が進みます。

ISDN回線終了などの期限がある場合の考慮点

ISDN(INSネット)を使った従来型EDIが対象になる条件

比較にじっくり時間をかけられるかどうかは、自社が期限を抱えているかで変わります。
NTT東日本は、INSネット(ISDN)のディジタル通信モードを2024年1月より段階的に終了し、関連するサービスを2028年12月末をもって終了する予定としており、EDIのシステムなどが影響を受ける可能性があるとしています³。
これは通信サービス側の予定なので、こちらの検討の進み具合とは関係なく日程が決まっています。

ただし、この話がすべての企業に当てはまるわけではありません。
対象になるのは、ISDN回線を使った従来型の通信手順でEDIを利用している場合です。
すでにインターネット回線を経由してブラウザからWeb-EDIを使っているなら、この終了予定が直接効いてくる話ではありません。
比較の前提が変わるので、自社が該当するかどうかは先に確かめておきたいところです。

自社がどちらか判断しづらいときは、受発注のデータがどこを通って届いているかを見ます。
担当者がブラウザでログインして注文を見ているのか、事務所に置かれた機器が回線を通じて夜間にデータを受け取っているのか。
後者であれば、どの通信方式と契約回線を使っているかを、社内の情報システム担当や保守を受けている事業者に確認する対象になります。
なお、この終了予定はNTT東日本が案内しているINSネットの関連サービスについてのものなので、契約している回線事業者とサービス名に照らして確認する必要があります。

2028年12月末までに確認すべきこと

期限があるとき、比較の性格が変わります。
「もっとも良いものを選ぶ」から「期限までに動いている状態を作る」へ目的が移るからです。
切替は契約して終わりではなく、データの移し替え、テスト、現場が慣れるまでの期間を含めて時間を使います。
そのため、選定にかけられる期間が実際にどれだけ残っているのかを先に見積もることになります。

逆算の仕方はそう複雑ではありません。
終了予定の時期から、現場が新しい手順で動けるようになるまでの期間を引き、その前に置く並行運用の期間を引き、さらにデータの整備とテストの期間を引く。
残ったところが選定と契約に使える期間です。
この引き算をしておくと、比較を続けてよい時期と、決めに行く時期の区切りが付きます。

もう一つ確認したいのが、取引先側の方針です。
従来型のEDIでつながっている相手も同じ通信方式を使っているので、同じ期限を抱えています。
相手がどの方式へ移るかによって、自社が選べる選択肢も変わります。
自社だけで決めて用意しても、相手の移行先と噛み合わなければつながりません。
この確認は早いほど選択肢が残ります。

終了に伴う対応としては、システムの刷新を含む複数の方策が挙げられています³。
どれを採るかは、取引先の数、やり取りしているデータの性格、社内システムの状況によって変わるので、一つの正解があるわけではありません。
比較の段階では、候補それぞれについて、切替に必要な作業と期間の見通しを聞いておく。
期限のある検討では、機能の差よりも日程の実現性が先に効きます。

切替・導入時の負担に備えるチェックポイント

期限の有無にかかわらず、切替のときには似た作業が発生します。
まず、いまの受発注の流れを書き出すところから始まります。
誰が、どこから注文を受け取り、どの画面やノートに転記し、どこで在庫や出荷とつないでいるか。
この棚卸しがないと、新しい仕組みを入れたあとで「その処理は誰がやるのか」が宙に浮きます。

次に効いてくるのがコード類の突合です。
取引先が使う商品コードと自社の品番が一対一で対応していなければ、データが流れてきても受け側で止まります。
取引先ごとに違うコードを使っている場合は、その対応表をどこで持ち、誰が更新するのかが運用の分かれ目になります。
ここは導入作業の中でも時間の読みにくい部分なので、比較の段階で「対応表の整備は誰の作業になるのか」を聞いておくと見通しが立ちます。

テストと並行運用も日程に入れます。
受発注は止められない業務なので、切替当日にすべてを移すのではなく、しばらく従来のやり方と並べて動かす期間を取る形が考えられます。
この期間は一時的に作業が増えます。
期限がある場合は、増える期間を終了予定より前に収める必要があるので、先ほどの逆算に組み込んでおきます。

費用の見方も、比較の段階で揃えておきたいところです。
初期にかかる費用、毎月かかる費用、取引の量に応じて変わる費用では、性格が違います。
取引先が増えたとき、データの量が増えたときに何が増えるのかを聞いておくと、運用を始めてから想定と違ったという事態を避けやすくなります。
金額そのものを並べるより、何に対して課金されるのかを揃えて比べるほうが判断しやすい。

既存システムとのつなぎ方も同じです。
販売管理や会計のシステムへ受注データをどう渡すのか、渡す作業は自動で行われるのか人が操作するのか、その形式は自社側で受けられるのか。
ここは提供元によって前提が違うので、一般的な説明で確かめたつもりにならず、自社が使っているシステムの名称と版を出したうえで、つなぎ方と必要な作業を確認する場面になります。

最後に、現場の人が使えるかどうかです。
操作の手順書、分からないときの問い合わせ先、繁忙期に人が増えたときの教えやすさは、比較資料の機能欄には出てきにくい部分です。
切替後に定着するかどうかは、ここで決まる部分があります。

ここまでを一本の線にすると、Web-EDIの比較は自社の立場を決めるところから始まり、仕様差をどこで吸収するかに行き着きます。
発注側なら取引先に何社ぶんの個別対応を持たせるか、受注側なら並んだ違いのうちどれから減らすか。
そこに通信方式の期限と移行の日程が重なれば、選定に使える時間も決まります。
この順で見ていくと、機能欄を眺めているだけでは決まらなかった部分が、自社の条件に置き換えられるようになります。

比較軸そのものは整理できても、自社の取引先の組み合わせでどこから手作業が減るのかは、いまの受注の流れを見ないと判断しづらい部分です。

どの取引先のデータがどこで手入力に変わっているかを一緒に洗い出すと、最初に減らせる作業と、当面は人の確認として残る作業の切り分けが分かります。無料相談で要件を整理する

Web-EDIを比較するときの判断軸

比較検討で判断が分かれる場面(仕様差、自社の立場、データの受け渡し、通信方式の期限、移行の負担)ごとに整理した軸です。

• 業界で共通化された仕様に準拠しているか(仕様差をどこまで減らせるか)

• 自社が発注側か受注側かで、選べる範囲と見るべき負担が変わること

• 発注側の選択が取引先に生じさせる個別対応の量

• 注文データを書き出せる形式と、自社システムへ渡す経路の有無

• 現行の通信方式と、終了予定による期限の有無

• 切替に必要な作業(コードの突合、テスト、並行運用)と日程の実現性

• 費用が何に対して発生し、取引先やデータが増えたときに何が増えるか

• 手順書や問い合わせ先があり、担当者以外へ引き継げるか

取引先の仕組みを自社で選べない受注側は、標準準拠の有無を確かめるより先に、いま手作業として残っている箇所から見ると判断が進みます。

要点の整理

軸	確認する基準
自社の立場	発注側は仕組みを決める側、受注側は受け方を決める側。どちらとして検討しているかで見る軸が変わる
仕様の共通化	業界で共通化された仕様に準拠しているか。準拠していない場合、覚え直しと読み替えがどれだけ残るか
発注側の影響	取引先に専用の環境や個別対応を求めていないか。手順書と問い合わせ先が用意されているか
受注側の吸収	各取引先の画面からデータを書き出せるか、自社の受注管理へ取り込む経路があるか
通信方式と期限	ISDN回線の従来型EDIに該当するか。該当するなら終了予定から逆算した日程
移行の負担	コードの対応表の整備、テストと並行運用の期間、誰の作業になるか
費用の見方	何に対して課金されるか。取引先やデータ量が増えたときに増えるもの

通信方式の期限がある場合は、選定にかけられる期間そのものが判断材料になり、取引先側の方針とも噛み合わせる必要があります。 現在の受発注の経路と取引先の状況を踏まえて、切替に必要な作業と日程の見通し、比較を続けてよい時期の目安を確認できます。

よくある質問

流通BMSに対応していないWeb-EDIを使い続けても問題ないか

標準に準拠していないからといって、その仕組みが使えなくなるわけではありません。
流通BMS協議会が個社仕様のWeb-EDI蔓延の抑制を図ってガイドラインを策定しているという事実は¹、標準に沿わない仕組みが現に広く使われていることの裏返しでもあります。
判断の分かれ目は、対応している取引先の数と、そこで残っている手作業の量です。
一社だけで、注文の件数も落ち着いているなら、当面そのままでも運用は回ります。
取引先が増えるたびに覚えることと転記が積み上がっているなら、そこが切替を検討する理由になります。

複数の取引先ごとにWeb-EDIの画面が異なる場合、まとめて処理する方法はあるか

取引先が用意している画面そのものを一つに統一することはできません。
現実的に手が届くのは、各画面から注文データを書き出し、自社側で受ける形を揃えるところです。
そのため確認する順番は、まず各取引先の画面がデータを書き出せるか、次にその形式を自社の受注管理で読めるか、になります。
書き出せない取引先が残る場合は手作業が続く前提で運用を組むことになりますが、全社まとめて解決しようとするより、書き出せる取引先から先に手を付けるほうが検討は進みます。

ISDN(INSネット)を使っていない場合、通信方式の終了は関係ないか

直接には関係しません。
NTT東日本が案内している段階的な終了と2028年12月末の終了予定は、INSネットのディジタル通信モードとその関連サービスについてのもので、EDIのシステムが影響を受ける可能性があるとされています³。
すでにインターネット回線でブラウザからWeb-EDIを使っているなら、この期限に追われる立場ではありません。
ただし、従来型のEDIでつながっている取引先が該当していれば、相手から切替の相談や仕様変更の連絡が来ることは考えられます。
自社が該当しない場合でも、取引先の状況は確認しておくと慌てずに済みます。

発注側と受注側の両方の立場がある場合、比較の優先順位はどう決めればよいか

二つを一度に決めようとせず、切り分けて考えます。
受注側の負担は、取引先ごとに異なる画面を自社で吸収する話なので、相手の合意を待たずに自社側の受け方から着手できます。
発注側の見直しは、取引先すべてに影響が及ぶぶん、周知や手順書の用意を含めて相手側の時間も必要になります。
どちらを先にするかは、いま手作業が積み上がっているのがどちらの側か、そして通信方式の期限を抱えているのがどちらの取引かで決まります。
期限のある側があれば、そちらが日程を持っているので先に動かすことになります。

Web-EDIの費用や既存システムとの連携方式は何を基準に確認すればよいか

費用は、金額を横に並べる前に何に対して発生するのかを揃えます。
初期にかかるもの、毎月かかるもの、取引の量に応じて変わるものでは性格が違い、取引先が増えたときに何が増えるかも変わるからです。
連携については、自社が使っている販売管理や会計のシステムの名称と版を示したうえで、受注データをどう渡すのか、その作業は自動なのか人が操作するのか、渡された形式を自社側で読めるのかを確認します。
一般的な説明では判断できない部分なので、自社の現在の環境を前提にした回答をもらうことが確認の中身になります。

1. 1　出典：一般財団法人流通システム開発センター(流通BMS協議会)「流通ＢＭＳにおけるWeb-EDI」
2. 2　出典：日経クロステック「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）
3. 3　出典：NTT東日本「ISDN(INSネット)とは？2028年12月終了の影響と企業が取るべき対応」