卸売業のWeb-EDI比較｜入力・データ受渡し・連携で確認するポイント

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

B2B EC-COLUMN

取引先指定の画面で残る作業を洗い出す

「来月からこちらのWeb-EDI画面で受注を確認してください」と取引先から連絡が来たとき、まず気になるのは、その画面を使い始めたあと自分の手元に何が残るのかという点ではないでしょうか。
画面が一つ増えても、注文内容を見て自社の販売管理システムへ入れ直す作業が変わらなければ、負担はむしろ増えます。
比較の起点になるのは候補の製品名を並べた一覧ではなく、取引先から届いた注文を自社で処理し終えるまでの手順です。
入力をどこで行うのか、データをどの形で受け渡すのか、社内システムへどこまで取り込めるのか。
この三つを取引先ごとに書き並べると、候補のどれが自分の作業を減らすのかが見えてきます。

「Web-EDI対応」の依頼だけでは決まらないこと

取引先から届く案内は、たいてい「弊社のWeb-EDIへの切り替えをお願いします」という一文から始まります。
Web-EDIは、ブラウザで開く画面を通して注文や出荷の情報をやり取りする仕組みを指す言い方で、専用の通信ソフトを入れずに使えるところから広がりました。
ただし、この言葉が指す中身は一つに決まっていません。
取引先の画面に注文が並び、それを見ながら自社で入力し直すこともあれば、画面からファイルを取り出して自社システムへ取り込むこともあります。
同じ「Web-EDI対応」でも、担当者の手元に残る作業はここで大きく分かれます。

流通BMS協議会がまとめたガイドラインでも、Web-EDIはファイル転送型とブラウザ型に分けて説明されています¹。
これは2012年版の資料での整理であり、いま取引先が使っている画面がそのどちらかにきれいに収まるとも、現在提供されている製品すべてがこの二つで説明できるとも言えません。
それでも、比較を始めるときの見方としては役に立ちます。
画面で人が扱うのか、データとして機械が扱うのかという分かれ目が、受注担当者の一日の作業量に直接効いてくるからです。

なお、Web-EDI全般の話と、流通BMSという業界標準に沿った取引の話は、重なる部分はあっても同じではありません。
取引先から求められているのが標準に準拠した接続なのか、その取引先が独自に用意した画面の利用なのかで、これから並べる候補の範囲が変わります。
案内文に書かれていなければ、先方の担当者に確かめておく価値があります。

受注1件が終わるまでを、いまのやり方で書き出す

比較の材料をそろえる一番早い方法は、いま自社で起きていることを一度書き出すことです。
注文が届いてから出荷の手配が済み、受注データが確定するまでに、誰が何回、どの画面や紙に触れているか。
頭の中では「FAXを見て入力するだけ」と思っていても、実際には単価の確認、在庫の照会、数量が合わないときの電話、出荷日の差し替えといった作業が挟まっているはずです。

たとえば、朝に届いたFAXの注文書を見ながら販売管理システムへ品番と数量を入力し、在庫が足りない行に印を付けて営業へ回し、午後に取引先から「1行取り消してください」と電話が入って入力済みのデータを直す。
こうした流れを一本の線として書き出すと、Web-EDIの画面が加わったときに変わる部分と、変わらない部分を分けて見られるようになります。
注文の入り口が紙から画面に変わっても、その先の入力と訂正が同じ手順のままなら、減るのは紙をめくる手間だけです。

書き出す単位は細かすぎなくて構いません。
受け取る、内容を確かめる、自社システムへ入れる、在庫を引き当てる、訂正を反映する、くらいの粒度で並べ、それぞれに誰がどの道具を使っているかを添えれば十分です。
この一本の線が、以降の比較で候補を当てはめるための下敷きになります。

減らしたいのは入力か、確認か、訂正の反映か

書き出した流れを眺めると、負担の中身が一つではないことに気づきます。
同じ「受注業務が大変」でも、単純な入力の量が多くて残業になっている場合と、入力そのものは短いのに確認と問い合わせで時間が細切れになっている場合では、選ぶべき方向が違います。

入力の量が問題なら、注文データを自社システムへそのまま取り込めるかどうかが比較の中心になります。
一方、確認や問い合わせが問題なら、在庫や納期を取引先がどこまで自分で見られるか、訂正の連絡がどの経路で届くかのほうが効いてきます。
取引先の画面を開くところまでは同じでも、そのあと自分の手が動く場所が違うためです。

減らしたい作業を一つか二つに絞っておくと、候補の説明を聞くときの質問が具体的になります。
「便利になりますか」ではなく「この転記はどうなりますか」と聞けるようになると、返ってくる答えも比べられる形になります。

ブラウザ入力とファイル受渡しの違い

画面に打つのか、データとして受け取るのか

減らしたい作業が決まったら、次は取引先とのあいだで何がどう渡されるのかを見ます。
候補ごとに最も分かれるのがここです。

ブラウザの画面で注文を見て、そのまま画面へ出荷数や出荷日を入力していく形は、始めるのが早い代わりに入力の手が残ります。
自社の販売管理システムにも同じ情報が要るなら、画面と自社システムの両方へ同じ数字を入れることになります。
注文の件数が少ないうちは気にならなくても、取引先が増えれば、この二重の入力もそのまま増えていきます。

ファイルとして受け取る形では、注文の内容がまとまったデータで届きます。
自社システムがその形式を読めるなら、画面を見ながら打ち直す作業は減ります。
ただし「減る」と「なくなる」は別で、そこを確かめないまま切り替えると、期待していたほど作業が軽くならないことがあります。

ファイルで受け取っても、人の操作は残ることがある

ガイドラインでは、ファイル転送型であっても、人によるアップロードなどの操作が必要になる場合があると説明されています¹。
これも2012年版の資料での記述で、現在のすべての製品がそうだという話ではありません。
けれども、比較のときに見落としやすい場所をよく指しています。

ファイルのやり取りが自動で進むのか、担当者が毎朝画面を開いてダウンロードし、別の画面へアップロードするのかで、日々の作業はまったく違います。
前者なら担当者は結果を確かめるだけで済み、後者なら決まった時刻に人が席にいる前提になります。
締め時刻の直前に注文が集中する取引先があるなら、その時間帯に人を置く形で組み立てることになります。

さらに、受け取ったファイルをそのまま取り込めるとも限りません。
項目の並びや文字コード、数量の桁の扱いが自社システムの取り込み形式と違えば、あいだで変換が要ります。
その変換を候補の仕組みが持つのか、表計算ソフトで担当者が整えるのか、社内の情報システム部門が仕掛けを作るのか。
ここが決まらないまま進むと、切り替えたあとに誰の担当でもない作業として残ります。

取引先ごとに方式が違うとき

卸売業では、取引先が一社とは限りません。
小売各社がそれぞれ別の画面を用意していれば、担当者は朝のうちに複数の画面へログインし、それぞれの手順で注文を取り出すことになります。

このとき、方式の違いは「画面が増える」だけでは終わりません。
ログイン情報の管理、画面ごとの操作手順、注文が届く時刻、訂正の連絡方法。
それぞれの覚え直しが積み上がり、担当者が休んだ日に代わりの人が同じ作業をたどれるかどうかにも関わってきます。

ですから、候補を見るときは一社との接続だけで判断しないほうが安全です。
いま取引のある相手と、これから増えそうな相手を並べ、それぞれの方式を書き添えたうえで、候補がどこまでを同じ手順にまとめられるのかを見ます。
まとめられない部分は、残る作業として最初から数えておきます。

取引先の指定がなく、自社から持ちかける場合

ここまでは取引先から方式を指定された場面を前提にしてきましたが、紙やFAX、電話での受注を自社の判断で減らしたい場合もあります。
このときは立場が入れ替わり、自社が相手に新しいやり方を使ってもらう側になります。

相手が小規模な小売店や飲食店であれば、ブラウザの画面から注文を入れてもらう形が受け入れられることがあります。
一方、相手側にも受発注の仕組みがあるなら、画面への入力をお願いすることは相手の手作業を増やす提案になります。
同じ電子化でも、頼む相手によって現実的な方式が変わる、ということです。

自社から持ちかける場合に効いてくるのは、相手が迷わずに使えるかどうかです。
ログインの手順、商品の探し方、注文履歴の見え方、間違えたときの直し方。
ここが分かりにくいと結局電話で問い合わせが来て、電子化する前より手間が増えることもあります。
候補を試すときは、自社の担当者だけでなく、注文する側の操作も一度たどってみると判断しやすくなります。

連携できる範囲と手作業を比較する

「連携できます」が指している範囲を分ける

候補の説明を聞いていると、多くの場合「自社システムと連携できます」という言葉が出てきます。
この一言が指す範囲は広く、そのままでは比べられません。

データを取り出せることと、そのデータを自社システムが受け取れる形にすることと、受け取ったあとに処理が自動で進むことは、それぞれ別の話です。
注文の一覧を画面から書き出せるという意味の連携もあれば、決められた形式で自社システムへ渡すところまでを含む連携もあります。
どちらも誤りではないので、聞く側が範囲を切って質問することになります。

質問の仕方を変えるだけで、答えの精度は上がります。
「連携できますか」ではなく、「当社の受注データはどの形式で出せますか」「取り込みの実行は誰が行いますか」「取り込めなかった行はどこに表示されますか」と聞くと、残る作業の場所が輪郭を持ちます。

コードの読み替えを誰が持つか

連携の話で必ず出てくるのが、商品コードと取引先コードの読み替えです。
取引先の注文データに載っているのは先方の商品コードで、自社システムが使うのは自社の品番、という状態はよくあります。

この対応表をどこで持つかで、日々の手間の出方が変わります。
受け取る仕組みの側で変換するなら、担当者の作業は新商品が出たときに対応表へ1行足すことに寄ります。
変換の仕掛けがなければ、届いたデータを見ながら担当者が品番を読み替えて入力することになり、件数の分だけ手が動きます。

新商品の登録、廃番、同じ商品の規格違い。
対応表は一度作って終わりにはなりません。
誰が更新し、更新が漏れたときにどこでエラーとして気づけるのか。
ここを先に確かめておくと、切り替えたあとに「取り込めない注文が毎日数行出るが原因が分からない」という状態に陥りにくくなります。

個社ごとの違いが積み上がる

ガイドラインは、個社ごとの仕様への対応が卸側の負担になるという問題を挙げています¹。
取引先ごとに項目の並びや呼び方、運用の決まりが違えば、その差を吸収する役回りは注文を受ける側に寄りやすい、という指摘です。

実務で見ると、この負担は一度に来るのではなく少しずつ増えます。
新しい取引先との取引が始まるたびに、画面の操作を覚え、取り込みの設定を足し、例外の扱いを決める。
一件ずつは小さくても、担当者の頭の中にある「この取引先だけの決まりごと」が増えていきます。

候補を比べるときは、いまの取引先に対応できるかだけでなく、次の取引先が増えたときに何を足すことになるのかを聞いておくと、あとで効いてきます。
設定で足せるのか、開発を伴うのか、そのとき自社側で用意する情報は何か。
取引先が増える見込みがあるなら、ここは比較の重い項目になります。

残る作業を候補ごとに数える

ここまでの見方をそろえると、候補の比較は機能の有無を並べた表ではなく、自社の作業がどう変わるかの比較になります。
最初に書き出した受注1件の流れに、候補ごとの答えを重ねていきます。

受け取りは自動か、人が操作するか。
取り込みの前に加工が要るか。
コードの読み替えはどこで行うか。
訂正が来たとき、どの画面を直すか。
この四点に答えが入れば、切り替えたあとの一日がおおよそ想像できます。

埋まらない欄が残ったなら、それは比較で決着していない部分です。
そのまま導入すると、切り替え後に担当者の手作業として現れます。
埋まらない理由が「取引先との取り決め次第」であれば、候補への質問ではなく取引先へ確認する事項として分けておきます。

本番移行前に取引データで確かめる

説明で分かることと、動かして分かること

候補が絞れたところで、説明だけでは決まらない部分が残ります。
自社の商品コードの桁数、単位の扱い、端数のある数量、長い商品名、同じ商品が複数行に分かれた注文。
こうした細かい条件は、動かしてみないと分かりません。

以下は編集上の考え方として書きますが、試す内容を決めるときは、自社で実際にやり取りしているデータを使うのが近道です。
整えられた見本のデータで通しても、確かめられるのは手順が存在することまでです。
直近の実際の注文を何件か持ち込み、取引先から届く形に近い状態で流してみると、どこで止まるのかが具体的に出てきます。

正常な注文だけを試さない

試す内容が正常な注文だけになると、切り替え後の困りごとを先に見つけられません。
受注業務で時間を取られるのは、たいてい例外のほうだからです。

数量の訂正、行の取り消し、締め時刻を過ぎてからの追加、出荷できない分の連絡、単価が合わないときのやり取り。
こうした場面で、どの画面を開き、誰が何を直し、取引先にはどう伝わるのかを一通りたどります。
訂正が自社システムへ自動で反映されるのか、担当者が手で直すのかは、日々の負担にそのままつながります。

取り込めなかったデータの扱いも同じです。
エラーになった行がどこに出るのか、気づける場所にあるのか、直して再度取り込めるのか。
ここが曖昧なまま運用に入ると、注文を落としていないかを人が目視で確かめ続ける形になりかねません。

誰が何をするかを決めてから切り替える

試したあとに残るのは、手順そのものより担当の割り振りです。
毎日決まった時刻に操作が要るなら、その時刻に誰がいるのか。
休んだ日の代わりは誰か。
対応表を更新するのは誰か。
取引先からの問い合わせはどこへ来るのか。

この割り振りを書き出しておくと、切り替えたあとに誰の仕事でもない作業が生まれにくくなります。
とくに、情報システムの担当者が設定し、受注の担当者が毎日操作するという分かれ方をする場合は、あいだに落ちる作業が出やすいところです。

並行期間の置き方も決めておきます。
従来のFAXや電話を残したまま新しい方式を動かすのか、取引先ごとに順に切り替えるのか。
並行させれば確認の手間は一時的に増えますが、注文の取りこぼしに気づく余地は残ります。
どちらを選ぶかは、取引の量と、止まったときに手で受けられるかどうかで決まります。

切り替えても残るものを見込んでおく

電子化しても、すべての作業がなくなるわけではありません。
注文の内容を確かめる判断、在庫が足りないときの連絡、取引先ごとの取り決めの記憶は、形を変えて残ります。

比較で確かめたいのは、それらがゼロになるかどうかではなく、どの転記が減り、どの確認が残るのかです。
減る作業をはっきり言えるなら、切り替えの判断はしやすくなります。
言えないまま進めれば、開く画面が一つ増えただけ、という結果になることもあります。

ここまでの見方を、候補を並べるときの確認項目としてまとめておきます。

取引先ごとに方式が違う状態は社内の資料だけでは並べにくく、どの作業が減るのかは自社の受注の流れに当てはめないと見えてこないためです。

いまの受注1件の流れと取引先ごとの方式をお持ちいただければ、どこに入力や転記が残るのか、比較で何を確かめるべきかを一緒に整理できます。無料相談で要件を整理する

候補を並べるときの確認項目

取引先から届いた注文が自社システムで処理し終わるまでの作業の流れに沿って並べています。

• 注文内容をどの画面へ、誰が何回入力するか

• 注文データを画面で見るのか、ファイルとして受け取るのか

• 受け取りに担当者の操作が要るか、決まった時刻に人が必要か

• 自社システムの取り込み形式で渡せるか、前に加工が要るか

• 商品コード・取引先コードの対応表を誰が持ち、誰が更新するか

• 訂正・取消の連絡がどこに届き、どの画面を直すことになるか

• 取引先が増えたときに設定で足せるか、開発を伴うか

取引先ごとに方式が違う場合は、この項目を取引先の数だけ用意して見比べます。

要点の整理

軸	確かめる基準
入力	注文内容をどの画面へ、誰が何回入力することになるか
受渡し	画面で見るのか、ファイルで受け取るのか。受け取りに人の操作が要るか
取り込み	自社システムの形式で渡せるか、取り込み前に加工が要るか
コード	商品・取引先コードの対応表を誰が持ち、誰が更新するか
例外	訂正・取消・締め後の追加と、取り込めなかった行の直し方
取引先の追加	新しい相手が増えたとき、設定で足せるか開発を伴うか
体制	毎日の操作を誰が行い、休んだ日は誰が代わるか

候補を絞ったあとに残るコードの読み替えや訂正の扱い、担当の割り振りは、製品の説明を聞くだけでは決まらない部分だからです。 自社の取引データを前に、どこまでを自動で受け渡し、どの操作を担当者に残す形にするのか、本番前に試す項目とあわせて確認できます。

よくある質問

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

EDIは企業間で受発注などのデータをやり取りする仕組み全般を指す言葉で、Web-EDIはそのうちブラウザの画面を使うものを指す言い方です。
専用の通信ソフトを入れずに始めやすい一方、画面を人が操作する前提の使い方になると、注文内容を自社システムへ入れ直す作業が残ります。
名前だけで判断せず、注文が自社システムに入るまでに誰が何をするのかで見てください。

取引先から流通BMSへの対応を求められました。Web-EDIと同じものと考えてよいですか。

分けて考えたほうが安全です。
流通BMS協議会のガイドラインではWeb-EDIをファイル転送型とブラウザ型に分けて説明していますが¹、これは2012年版の資料での整理で、取引先が用意している画面が業界標準に沿っているかどうかは個別に確かめる必要があります。
求められているのが標準に準拠した接続なのか、その取引先の画面を使うことなのかを、先方に確認してから候補を探すと手戻りが減ります。

ファイルで受け取れれば、手入力はなくなりますか。

なくなるとは限りません。
同じガイドラインでも、ファイル転送型であっても人によるアップロードなどの操作が必要になる場合があると説明されています¹。
受け取りが自動なのか担当者の操作なのか、受け取ったファイルを自社システムがそのまま読めるのか、読めない場合に誰が変換するのかまで確かめると、残る手作業の量が見えてきます。

取引先ごとに違う画面を使い続けるしかないのでしょうか。

ガイドラインは、個社ごとの仕様への対応が卸側の負担になる問題を挙げています¹。
どこまで一本化できるかは取引先との取り決めにも左右されるため、自社だけでは決め切れません。
現実的には、いまの取引先と今後増えそうな相手の方式を並べ、候補がどこまで同じ手順にまとめられるのか、まとめられない部分は誰がどう扱うのかを比較の項目として持っておくことになります。

取引先からの指定はありませんが、FAXと電話の受注を減らしたい場合はどう考えますか。

自社から相手に新しいやり方を使ってもらう話になるので、相手の手間が増えないかを先に見ます。
相手側に受発注の仕組みがなければ、ブラウザの画面から注文を入れてもらう形が現実的なこともありますが、操作が分かりにくいと電話での問い合わせが戻ってきます。
候補を試すときは、自社の担当者の操作だけでなく、注文する側の画面も一度たどっておくと判断しやすくなります。

導入前の試験では、どのくらいの件数を流せばよいですか。

件数の目安を一般に示すのは難しく、むしろ内容のばらつきのほうが判断に効きます。
直近の実際の注文から、桁数や単位、端数のある数量、同じ商品が複数行に分かれたもの、長い商品名などが混ざるように選び、あわせて訂正・取消・締め後の追加といった例外を試します。
正常な注文だけを増やしても、切り替え後に困る場面は出てきません。

1. 1　出典：流通BMS協議会「流通BMSにおけるWeb-EDIガイドライン 第1.0版」（2012年）