Web-EDIとBtoB ECの違い｜受発注の形と取引先の負担から選ぶ判断軸

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

B2B EC-COLUMN

注文がFAX・メール・電話に分かれて手間が膨らむとき、まず何を決めるか

FAXで届く注文、メールに添付された発注書、電話で受けた追加注文。
受注担当者がそれぞれを基幹システムへ打ち直しているところへ、取引先から「Web-EDIで受発注を」と求められると、BtoB ECとどちらを選ぶべきか迷います。
Web-EDIは、Webブラウザーの操作で受発注のやり取りを行うEDIです¹。
選び分けを決めるのは名称ではありません。
取引先ごとに誰が注文の形式を決めているか、注文がどう届くか、価格と掛け売りの条件、基幹システムへの取り込み、取引先の操作負担で決まります。
取引先を型に分け、提供元へ確かめる質問と切り替えの順序を整えれば、併用も含めて判断できます。

取引先ごとの注文の受け方を棚卸しする

仕組みを選ぶ前に決めておくのは、取引先ごとに「いま注文がどう届き、届いた後に社内で何をしているか」です。
Web-EDIもBtoB ECも、取引先の注文を画面経由で受ける点では似て見えます。
違いが効いてくるのは、どの取引先の、どの注文を置き換えるかが決まってからです。

棚卸しでは、取引先ごとに次の点を書き出します。

• 注文の経路：FAX、メール添付、電話、取引先が指定する画面など
• 形式を決めている側：取引先の発注書式や画面に合わせているか、自社の注文書式を使ってもらっているか
• 注文の頻度と中身：毎週ほぼ同じ品目の継続発注か、その都度品目が変わるか
• 扱う商品点数と、取引先ごとの単価・掛け率の有無
• 支払条件：掛け売りか、締め日や請求書の扱いはどうか
• 受けた後の転記先：基幹システム、在庫表、請求の仕組みなど

最後の転記先まで書いておくと、仕組みを替えた後に何の作業が残るかが見えます。
たとえばFAXの注文を基幹システムへ手入力している場合を考えます。
取引先が画面で注文するようになっても、その注文データを基幹システムへ取り込む方法がなければ、打ち直しの元がFAXから画面に変わるだけです。
注文の受け口を替えることと、社内の転記を減らすことは、別々に確かめる必要があります。

一覧ができたら、取引先を数えて終わりにせず、注文件数や品目数の多い取引先に印を付けておきます。
後で取引先を型に分けるときも、切り替えの順序を決めるときも、この印が手掛かりになります。

受注側か発注側かで論点が変わる

同じ「Web-EDIを入れる」でも、自社が注文を受ける側か出す側かで、自社で決められる範囲が違います。
受注側として取引先から「この画面で受けてほしい」と指定された場合、画面や項目を自社で選ぶ余地は小さくなります。
論点は、指定された画面に入った注文をどう自社の基幹システムへ移すかに移ります。

反対に、受注側が自ら受け口を用意して取引先に使ってもらう場合は、どの仕組みにするかを自社で選べます。
その代わり、取引先の担当者が新しい画面に慣れるまでの問い合わせや、IDの発行・管理を自社が引き受けることになります。
導入を決めるのは自社でも、日々注文を入力するのは取引先の担当者です。

発注側として仕入先へ注文を出す立場なら、仕入先ごとに受け口が違うと、自社の購買担当が複数の画面を使い分けることになります。
以降は受注側の判断を中心に進めます。
発注側の方は、棚卸しの一行目に「自社が形式を指定する側に回れるか、指定される側か」を加えておくと、同じ比較を読み替えられます。

Web-EDIとBtoB ECは何が違うのか：ブラウザで受発注するEDIと、取引先が商品を選んで注文する店舗型

Web-EDIが指すもの

EDIは、企業間の受発注などの取引データを、あらかじめ取り決めた形式でやり取りする仕組みです。
日経クロステックの用語解説は、Web-EDIを「インターネットを使い、Webブラウザーの操作で受発注のやり取りを実現するEDI」と説明しています¹。
同じ解説は、Web-EDIには様々なプロトコル（通信の手順）があるとも述べています¹。

ここから読み取れるのは、Web-EDIはまず「EDIの一つ」だということです。
取引先とのあいだで注文の項目や手順を取り決め、そのやり取りをブラウザの画面から行う、という順で理解すると、BtoB ECとの違いを考えやすくなります。
また「様々なプロトコルがある」という点は、Web-EDIという名前が一つの統一された製品や規格を指すわけではないことを示しています。
取引先Aと取引先BがどちらもWeb-EDIを求めてきても、画面も手順も別々ということは起こり得ます。

なお、この解説は2016年の記事に載ったもので、ISDN（電話回線を使うデジタル通信）からの移行を扱う文脈にあります¹。
定義の骨格は用語として使えますが、個々の製品がいまどんな機能を持つかまでは、この解説からは分かりません。

BtoB ECが指すものと、用語が揺れる点

BtoB ECは、企業間の取引をインターネット上で行うことを広く指す言葉として使われます。
受発注の仕組みの話では、取引先が商品一覧から品目を探し、数量を入れて注文する、通販サイトに近い画面を企業向けに用意した形を指して使われることがあります。
ただ、この「店舗型」という見方は公的な定義ではなく、提供元によって呼び方も範囲も違います。
BtoB ECを名乗る仕組みに定型の注文受付が含まれていることも、Web-EDIと呼ばれる仕組みに商品を探す画面があることもあり得ます。

そのため、名前で選ぶより次の二つを見るほうが、判断を誤りにくくなります。
一つは、注文の形式（項目・単位・手順）を誰が決めているかです。
取引ごとに取り決めた形式に沿って注文が流れるのか、受注側が用意した商品一覧と画面に取引先が合わせて注文するのか、という違いです。
もう一つは、注文が何を起点に始まるかです。
品目と数量がほぼ決まっている継続発注を送る使い方か、取引先が品目を探して選ぶ使い方かで、画面に求めるものが変わります。

前者に近ければEDI的な使い方、後者に近ければ店舗型の使い方と考えると、棚卸し表のどの取引先がどちらに寄るかの見当が付きます。
これは見分けるための整理で、製品の分類ではありません。
実際の候補が両方の使い方にどこまで対応するかは、提供元の仕様で確かめることになります。

自社の取引条件でどちらが向くか：取引先の数・継続発注・商品点数・取引先別の価格

取引先を3つの型に分ける

棚卸し表を前の節の二つの観点で見直すと、取引先は次の三つの型に寄せられます。
分け方は判断のための仮の例で、実際の取引先の割合を示すものではありません。

• 型A：取引先が注文の形式を指定し、品目・数量がほぼ決まった継続発注が多い。
  取引先側にすでにEDIや指定の画面がある。
• 型B：自社が受け口を用意でき、継続発注が中心。
  品目は限られるが、取引先ごとの単価や掛け率がある。
• 型C：自社が受け口を用意でき、注文のたびに品目が変わる。
  商品点数が多く、取引先が探して選ぶ場面がある。

型Aは、仕組みを選ぶというより、指定に合わせる話です。
取引先から「Web-EDIで」と求められた場面は、この型に当たります。
決める論点は、指定された画面に入った注文を、自社の基幹システムへどう移すかです。

型Bは選べる余地がある一方で、取引先別の価格を間違いなく出せるかが要になります。
継続発注が中心なので、取引先の担当者にとっては、前回と同じ注文を少ない操作で出せるかどうかが使い続けるかの分かれ目になりやすいところです。
EDI的な使い方でも店舗型の使い方でも、その操作が用意されているかを見ることになります。

型Cは、商品を探して選ぶ画面の出来が取引先の負担を左右します。
商品点数が多いのにFAXの注文書で受けていると、取引先は品番を調べて書き写し、自社はそれを読み取って打ち直すという作業が両側で起きます。
店舗型の使い方が合いやすいのはこの型ですが、取引先別の価格や掛け売りが絡むなら、次の節の確認と組み合わせて判断します。

型の違う取引先を一つの仕組みで受けようとすると、どこかの型に無理が出ます。
型Aには指定の画面があり、型Cには商品を探す画面が要る、という状態なら、型ごとに受け口が分かれる併用を前提に考えたほうが筋が通ります。

確認項目表

型ごとに見るべき点を、取引先の数・継続発注か都度発注か・商品点数・取引先別の価格という同じ軸に並べたのが次の表です。
表は候補の仕組みについて提供元へ尋ね、答えを書き込むためのもので、どちらの仕組みが対応しているかをあらかじめ示すものではありません。

表の中で判断が分かれやすいのは、取引先別の価格の行です。
同じ品目でも取引先によって単価が違う取引で、画面が一律の価格を表示すれば、取引先は表示と請求の食い違いに戸惑い、自社は注文のたびに単価を直すことになります。
商品点数の行も同じ構図です。
商品マスタ（品番・品名・単位・価格などの基本情報）を画面へ手で登録し直す必要があるなら、品目の改廃のたびに二重の更新が残ります。

取引先の数の行は、取引先の数が増えるほど効いてきます。
取引先が数社なら、画面の作り込みより個別の調整で済む場合もあります。
数十社、数百社になると、ID発行や操作説明を一社ずつ行う手間そのものが導入の負担になるため、その作業を誰がどう行えるかが選ぶ理由になります。

▼ 図の内容を文字で読む

• 型A（取引先が指定）
  • 指定された画面に入った注文を基幹システムへどう移すか
• 型B（継続発注・取引先別価格）
  • 取引先別の単価を間違いなく出せるか
  • 前回と同じ注文を少ない操作で出せるか
• 型C（商品点数が多く都度選ぶ）
  • 商品を探して選ぶ画面の出来が取引先の負担を左右する
  • 取引先別の価格や掛け売りが絡む場合は次の節の確認と組み合わせる

掛け売り・与信・請求・納品書をどこまで扱えるか：契約前に確かめる項目

提供元へ確かめる質問

企業間取引では、注文の時点で代金を受け取らず、締め日でまとめて請求する掛け売りが広く使われます。
注文の受け口を替えても、締めと請求の流れが別の場所に残れば、注文は画面で受けたのに請求書は手作業で作る、という分断が起こります。
受け口の仕組みが請求までのどこを担い、どこから先を基幹システムや会計の仕組みに渡すのか、その境目を契約前に決めておく必要があります。

確かめる質問を、注文を受けてから請求するまでの順に並べます。

1. 注文時の支払方法：掛け売りを選べるか。
   取引先ごとに掛け売りの可否を設定できるか。
2. 与信：取引先ごとの与信限度（掛けで売ってよい上限額）を持てるか。
   限度を超えた注文を止めるのか、通して社内で確認するのか。
3. 納品書：出荷のたびに納品書を出力できるか。
   書式を自社の様式に合わせられるか。
4. 締め処理：取引先ごとの締め日でまとめられるか。
   月の途中の返品・値引きをどう反映するか。
5. 請求書：請求書を発行するのは受け口の仕組みか、基幹・会計の仕組みか。
   発行した請求データをどこへ渡せるか。

与信の質問は、答えによって社内の運用が変わります。
限度を超えた注文を仕組みが止めるなら、営業担当が事情を聞いて解除する手順が要ります。
止めずに通すなら、受注担当が注文ごとに残高を見る作業が残ります。
どちらが良いかは取引先との関係や与信の考え方で変わり、仕組みの側に正解があるわけではありません。

請求書を発行する場所も、二重に作らないために決めておきたい点です。
受け口の仕組みでも基幹システムでも請求書を出せる場合、両方から出すと金額や番号の照合が必要になります。
どちらを正とし、もう一方には何のデータを渡すのかを決めておけば、締めのたびに二つの数字を突き合わせる作業を避けられます。

型Aの取引先のように相手が指定した画面で受ける場合は、これらの質問を受け口の提供元ではなく、自社の基幹システム側の運用として考えることになります。
指定の画面から受けた注文を掛け売りとしてどう締めるかは、画面の中ではなく、自社の請求の手順で決まるためです。

▼ 図の内容を文字で読む

1. 注文時の支払方法
   • 取引先ごとに掛け売りの可否を設定できるか
2. 与信
   • 与信限度を超えた注文を止めるか、通して社内で確認するか
3. 納品書
   • 出荷のたびに出力でき、書式を自社の様式に合わせられるか
4. 締め処理
   • 取引先ごとの締め日でまとめ、月途中の返品・値引きを反映できるか
5. 請求書
   • 発行元を受け口の仕組みか基幹・会計かのどちらかに決める

基幹システム・在庫・会計との連携と、取引先側の負担

連携方式を確かめる

注文処理の重さの多くは、受けた注文を基幹システムへ打ち直す作業から来ています。
画面で注文を受けるようにしても、その注文データが基幹システムに入らなければ、FAXを読んで打っていた作業が、画面を見て打つ作業に変わるだけです。
連携で確かめるのは、注文データがどの形で、どのタイミングで、どこへ渡るかです。

• 注文データの受け渡し方：ファイル（CSVなど）を出力して取り込むのか、仕組みどうしを直接つなぐのか
• タイミング：注文のたびか、一日に何回かまとめてか
• 逆方向：在庫数・出荷状況・商品マスタを基幹システムから受け口へ戻せるか
• 会計への流れ：売上・請求のデータを会計の仕組みへどう渡すか

逆方向の項目は、取引先からの問い合わせに関わります。
受け口の画面に在庫や出荷状況が出なければ、取引先は「入荷はいつか」「出荷されたか」を電話やメールで確かめることになり、注文を画面化しても問い合わせの電話は残ります。
どこまでの情報を画面に戻すかで、残る電話の種類が変わります。

ファイルでの取り込みは、手入力に比べて打ち間違いが減る一方、取り込み作業そのものと、取り込み時のエラー（品番の不一致など）を直す作業が残ります。
直接つなぐ方式はその作業が減る代わりに、基幹システム側の改修や設定が要ることがあります。
どちらが合うかは注文件数と基幹システムの事情で変わるので、提供元には自社の基幹システム名を伝え、どの方式でつないだ例があるかを尋ねると話が早く進みます。

取引先のID・操作・複数社対応

取引先側の負担は、自社からは見えにくいところにあります。
受け口を自社で用意すると、取引先の担当者はログインIDを受け取り、新しい画面の操作を覚えることになります。
その取引先が他の仕入先からも別々の画面を指定されていれば、担当者は仕入先ごとにIDと操作を使い分けています。
自社の画面がそこに一つ増えることをどう受け止めるかは、取引先の事情次第です。

受注側の自社が型Aの立場で取引先から画面を指定される場合、負担は逆向きに自社へ来ます。
取引先ごとに別のWeb-EDIを指定されると、受注担当は取引先の数だけ画面にログインして注文を確かめ、それぞれから基幹システムへ移すことになります。
取引先ごとに対応方式が分かれるほど、自社に残る作業は増えます。
業界で形式をそろえた標準のEDIは、こうした一対一の個別対応を減らす方向の考え方です。

医薬品や健康食品の製造・販売や卸事業を手掛けるピップグループは、2016年の記事で、約500弱の小売店との取引にEDIを利用し、そのうち10％強の取引先がIP網（インターネットなどの通信網）に対応した流通BMSやWeb-EDIなどへすでに移行していると紹介されています¹。
流通BMSは流通業界で使われる標準のEDIの一つです。
記事はISDNからの移行を扱っており、取引先によって移行の進み具合が違っていたことが分かります¹。

一社の、しかも2016年時点の状況なので、ここからWeb-EDIの普及率や現在の傾向は言えません。
それでも、数百の取引先を抱える企業で移行が一斉ではなく取引先ごとに進み、その間は移行済みの取引先と未移行の取引先が並んでいた、という点は読み取れます。
受注側として仕組みを入れ替える場合も、全取引先が同じ日に切り替わる前提より、新旧の受け口がしばらく並ぶ前提で社内の作業を組み立てるほうが、現実に合います。

▼ 図の内容を文字で読む

• 注文データが基幹システムへ渡らない
  • 画面を見て基幹システムへ打ち直す作業が残る
• 在庫・出荷状況が受け口の画面へ戻らない
  • 取引先からの電話・メールでの問い合わせが残る
• 注文データをファイルで取り込む
  • 取り込み作業と、品番の不一致などのエラーを直す作業が残る

併用・段階導入と、取引先への案内の進め方

取引先を型別に切り替える順序

併用が現実的になるのは、型Aの取引先には指定の画面があり、型B・Cの取引先には自社の受け口を用意したい、というように、型ごとに求められる受け口が違うときです。
この場合、受け口が複数になること自体は避けられません。
併用してよいかの判断には、受け口ごとの注文が最後に一つの基幹システムへ集まるかどうかを使います。

切り替えの順序は、棚卸しで印を付けた取引量の大きい取引先から試すのが一つの方法です。
注文件数の多い取引先ほど、手入力が減ったかどうかの差が見えやすく、問題があれば早く表に出ます。
ただ、取引量が大きい取引先は止まったときの影響も大きくなります。
最初は注文の一部や特定の品目に限り、FAXや従来の経路を残したまま並行して受ける進め方が考えられます。

1. 試す取引先を一〜数社選び、型と現在の注文経路、転記先を記録する
2. 取引先の担当者へ、変わる点（注文の出し方、ID、問い合わせ先）と、従来の経路をいつまで残すかを伝える
3. 並行期間を置き、新しい受け口と従来の経路の両方で注文を受ける
4. 並行期間の記録を見て、従来の経路を閉じるか、運用を直すかを決める
5. 同じ型の取引先へ広げ、次の型へ進む

取引先への案内で伝えるのは、操作方法より先に「なぜ変えるのか、取引先にとって何が変わるのか」です。
注文の締め時刻が変わる、電話で受けていた追加注文の扱いが変わる、といった点は、取引先の担当者の日々の作業に直接響きます。
導入を決めたのは自社でも、慣れない画面で注文を入力するのは取引先の担当者です。
問い合わせ先を一つに決めて伝えておくと、迷ったときの行き先がはっきりします。

切り替え後の確かめ方

切り替えで手間が減ったかどうかは、記録を取らなければ分かりません。
製品の説明に効果の目安が書かれていても、自社の注文の中身と基幹システムの事情で結果は変わります。
並行期間の前後で、次の点を同じ方法で記録しておくと比較ができます。

• 注文を受けてから基幹システムへ入れ終えるまでの入力時間
• 取引先からの問い合わせ件数と、その内容（操作、在庫、出荷、価格など）
• 注文内容の訂正・差し戻しの件数
• 締め・請求で手直しが必要になった件数

問い合わせを内容で分けて数えるのは、何を直せばよいかが内容によって変わるためです。
操作の問い合わせが多ければ、案内の資料や画面の設定を見直します。
在庫や出荷の問い合わせが多ければ、前の節で見た逆方向の連携が足りていない可能性があります。
価格の問い合わせが多いなら、取引先別の価格が画面に正しく出ているかを疑います。

入力時間が思ったほど減らない場合は、受け口の画面ではなく、その後の転記に原因があることがあります。
画面で受けた注文を基幹システムへ移すところに手作業が残っていないか、取り込みエラーを直す時間が増えていないかを、記録と照らして確かめます。
記録を見て次の型へ進むか、いまの型で運用を直すかを決めていけば、切り替えを一度で決め切る必要はありません。

▼ 図の内容を文字で読む

1. 試す取引先を選び、現在の経路と転記先を記録する
2. 変わる点と従来の経路を残す期間を取引先へ伝える
3. 新しい受け口と従来の経路で並行して注文を受ける
4. 記録を見て、運用を直すか従来の経路を閉じるかを決める
5. 同じ型の取引先へ広げ、次の型へ進む

取引先を型に分けても、自社の取引先別価格や掛け売りの条件、基幹システムの事情に照らしてどの質問が決め手になるかは、自社だけでは見極めにくいところです。

棚卸しした取引先の注文経路と転記先をもとに、型の分け方と、提供元へ確かめる質問の優先順位を一緒に整理できます。無料相談で要件を整理する

Web-EDIとBtoB ECを選び分ける判断軸

注文が届く入口から、社内の転記、取引先の負担へと、注文の流れに沿って判断の軸を並べた。

• 注文の形式を誰が決めているか（取引先の指定か、自社の受け口か）

• 継続発注が中心か、その都度品目を選ぶ注文が多いか

• 商品点数と、商品マスタを受け口へ流し込めるか

• 取引先別の単価・掛け率と、掛け売り・与信・請求の扱い

• 注文データが基幹システムへ渡り、在庫・出荷状況が受け口へ戻るか

• 取引先の担当者のID・操作の負担

型ごとに求められる受け口が違う場合は、一つに絞らず、注文が一つの基幹システムへ集まる形での併用を考える。

要点の整理

軸	基準
最初に決めること	取引先ごとの注文経路・形式を決める側・頻度・転記先を棚卸しする
使い方の見分け方	名称ではなく、注文の形式を誰が決め、注文が何を起点に始まるかで見る
取引先の型	型A：取引先が指定／型B：継続発注と取引先別価格／型C：商品点数が多く都度選ぶ
取引条件	取引先別の単価・掛け率、掛け売り・与信・締め・請求の発行元を提供元に尋ねる
連携	注文データが基幹システムへ渡るか、在庫・出荷状況・商品マスタが受け口へ戻るか
切り替え	取引量の大きい取引先から並行期間を置いて試し、入力時間と問い合わせの内容を記録する

併用や段階導入では、受け口が並ぶ期間に社内のどこへ作業が残るかを、切り替えの前に見通しておく必要があります。 どの取引先から試すか、並行期間に何を記録すれば判断できるかを、自社の取引条件に合わせて相談できます。

よくある質問

Web-EDIとBtoB ECは併用できますか。併用するなら、取引先をどう分けますか。

併用は、型ごとに求められる受け口が違うときに現実的です。
取引先が画面を指定してくる型Aはその指定に合わせ、自社が受け口を用意できる型B・Cには、継続発注の多さや商品点数に合う使い方を選びます。
判断の決め手は、受け口が複数になっても、注文が最後に一つの基幹システムへ集まるかどうかです。
集まらない場合、受け口が増えた分だけ転記の作業も増えます。

取引先から指定されたWeb-EDIが複数あるとき、自社の入力負担をどう減らしますか。

取引先ごとに画面が分かれると、受注担当は画面の数だけログインして注文を確かめ、それぞれを基幹システムへ移すことになります。
負担を減らす糸口は、各画面から注文データをファイルなどで取り出せるか、その形式を自社の基幹システムへ取り込めるかにあります。
取り出せる形式や項目は画面ごとに違い得るので、指定してきた取引先に、注文データの出力方法と項目を一社ずつ尋ねて記録しておくと、どこに手入力が残るかが分かります。

取引先がITに不慣れな場合、どちらを優先して案内しますか。

どちらの仕組みかより、取引先の担当者の作業がどれだけ変わるかで考えます。
継続発注が中心の取引先なら、前回と同じ注文を少ない操作で出せる画面のほうが受け入れやすく、品目を探して選ぶ取引先なら、検索のしやすさが効きます。
いずれの場合も、従来のFAXや電話の経路をしばらく残し、問い合わせ先を一つに決めて伝えておくと、慣れるまでの間に注文が止まる心配を減らせます。

導入前に提供元へ確認すべき、請求・掛け売りの質問は何ですか。

注文から請求までの順に、掛け売りを取引先ごとに設定できるか、与信限度を持てるか、限度を超えた注文を止めるか通すか、納品書を自社の様式で出せるか、取引先ごとの締め日でまとめられるか、請求書をどの仕組みから発行し、そのデータをどこへ渡せるかを尋ねます。
特に請求書の発行元は、受け口と基幹システムの両方から出せる場合に、どちらを正とするかを決めておかないと、締めのたびに突き合わせが必要になります。

1. 1　出典：日経BP（日経クロステック）「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）