Web-EDIとは？受注側の作業の変化と、取引先指定型・データ連携型の選び方

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

B2B EC-COLUMN

取引先からWeb-EDIでの受注を求められたとき、FAX・メール受注と何が変わるのか

取引先から「Web-EDIで発注したい」と依頼が来ても、FAXやメールで受けている今の注文処理のどこが変わるのかは見えにくいものです。
Web-EDIは、ブラウザの画面で受発注をやり取りするEDIです。
注文の入口は画面に移ります。
ただし、その内容を自社の販売管理へ打ち直す作業が残るかどうかは、取引先の画面によって決まります。
流通BMSなど標準のデータを受け渡す方式なら、基幹へ取り込める範囲が広がります。
選ぶ目安は、取引先の数、基幹へ流したい範囲、取引先が方式を指定しているかの三つです。
費用の優劣は一概に言えないため、取引先と確かめる事項と始める順序をもとに判断します。

Web-EDIとは何か

EDIは、企業同士が注文などの取引情報を、紙ではなく電子データでやり取りする仕組みの総称です。
Web-EDIはその一つで、「インターネットを使い、Webブラウザーの操作で受発注のやり取りを実現するEDI」と説明されています²。
同じ説明には「様々なプロトコルがある」とも添えられています²。
つまりWeb-EDIは、一つの決まった製品や規格の名前ではありません。
ブラウザで操作するという使い方に着目した呼び方です。

受注側の担当者から見ると、まず変わるのは注文の入口です。
FAXなら機械から紙が出てきますし、メールなら受信箱に届きます。
取引先が指定するWeb-EDIでは、発注する取引先が用意した画面に注文が載ります。
担当者はブラウザでその画面を開き、内容を確かめます。
画面の項目の並び、操作の手順、締め時間は、その画面を用意した側が決めるものです。
取引先Aと取引先Bがどちらも「Web-EDI」を使っていても、同じ操作で済むとは限りません。

なお、仕入れを担当していて、仕入先が指定するWeb-EDIで発注する立場の方もいるでしょう。
その場合も「画面を誰が決めるか」という構図は同じです。
違うのは、画面に入力する側が自社になる点です。
以下では、注文を受ける側の作業を中心に説明します。

受注・転記・納期回答・請求の流れで比べる

たとえば、毎朝FAXで届く注文を販売管理システムへ入力している担当者を考えます。
流れは次のとおりです。
紙を読み取り、品番と数量を打ち込み、在庫を見て納期を決め、FAXや電話で回答し、出荷後に請求書を出します。
このうちWeb-EDIで確実に変わるのは、注文を受け取る場所です。
FAXでは、手書きの数字が読みにくい、印字がかすれているといった読み取りの迷いがありました。
画面に文字として表示されれば、こうした迷いは起きにくくなります。

一方、画面に表示された注文を販売管理へ移す作業が残るかどうかは、Web-EDIという名前だけでは決まりません。
取引先の画面から注文をデータとして取り出し、自社のシステムへ読み込めるなら、転記は減ります。
画面を見ながら打ち直すしかないなら、読み取る元が紙から画面に変わっただけです。
入力の手間はほとんど変わりません。
取引先が増えて画面が増えれば、ログインして確かめる先がかえって増えることもあります。

納期回答や出荷の案内、請求も同じように考えます。
回答を画面に入力する仕組みなら、回答の手段は取引先側にそろいます。
その一方で、自社の販売管理に記録した納期と画面に入れた納期を、両方持つことになります。
Web-EDIで扱う範囲が受注だけなのか、回答や請求まで含むのかは、画面を用意する取引先が決めます。
どこまでが画面の中で完結するかは、取引先ごとに違います。
下の表は、工程ごとに変わる所と残る所を並べたものです。

現行手順の棚卸しで見る点

Web-EDIで何が楽になり、何が残るかを見積もりたいときは、取引先の画面を見る前に、今の受注の流れを書き出しておくと判断しやすくなります。
見る点は次のとおりです。

• 受け方ごとの件数：FAX、メール、電話、すでに使っている取引先の画面ごとに、1日や1か月に何件の注文が来ているか
• 転記先：注文を販売管理、在庫、出荷、請求のどのシステムや表に入れているか
• 転記にかかる時間：入力そのものと、入力後の読み合わせや確認にかかる時間
• 回答の方法と期限：納期回答を誰が、いつまでに、何で返しているか
• ミスが起きる箇所：品番の読み違い、数量の打ち間違い、二重入力など、どの工程で直しが発生しているか

この書き出しがあれば、依頼されたWeb-EDIがどの行を減らし、どの行を残すのかを具体的に比べられます。
たとえば、転記時間の大半を、取引先の品番を自社コードへ置き換える作業に使っているとします。
この場合、注文が画面で届くようになっても、置き換えの作業は残ります。
反対に、FAXの読み取りの確認や、電話での問い合わせに時間を取られているなら、画面化だけでも減る部分があります。
同じWeb-EDIでも、自社のどこに手間があるかで評価が変わるのです。

▼ 図の内容を文字で読む

• 確実に変わる所
  • 注文を受け取る場所がFAXやメールから画面に移る
  • 手書きの読みにくさなど、読み取りの迷いが起きにくくなる
• 取引先の画面で決まる所
  • 画面からデータを取り出せれば転記は減る
  • 取り出せなければ、読み取る元が紙から画面に変わるだけ
  • 回答や請求まで画面に含むかは取引先ごとに違う
• 自社に残る所
  • 取引先の品番を自社コードへ置き換える作業
  • 画面と販売管理の両方に納期を持つ手間

Web-EDIとデータ連携型EDI・流通BMSの違い：転記・確認・回答の作業はどう変わるか

流通BMSはメッセージと通信規約の標準

Web-EDIが「ブラウザで操作する」という使い方を指すのに対し、流通BMSは「何を標準にするか」で定義されています。
GS1 Japanは流通BMSを、消費財流通業界で唯一の標準となることを目標に策定している、メッセージ（電子取引文書）と通信プロトコル／セキュリティに関するEDI標準仕様と説明しています³。
メッセージは、取引文書のどの項目をどの形でデータにするかという決まりです。
通信プロトコルとセキュリティは、そのデータを相手へどう送り、どう安全に届けるかという決まりです。

受注側にとってこの違いは、注文を読むのが人なのか、システムなのかという違いとして現れます。
Web-EDIでは、担当者が画面に表示された注文を見て判断し、必要なら自社システムへ移します。
標準のメッセージでデータを受け渡す方式は、決まった項目と形式で届いたデータを、自社側のシステムが受け取ることを前提にしています。
ただし、流通BMSは消費財流通業界の標準です。
部品や資材など他の業種の取引で、同じ標準が使われているとは限りません。

中小企業共通EDIの仕組みと実証値の読み方

中小企業の受発注を想定したデータ連携の例として、中小企業庁が紹介する中小企業共通EDIがあります。
受注側と発注側の双方がこの標準に対応したプロバイダーと契約すれば、統一したデータをやり取りできるとされています¹。
ここでいうプロバイダーは、標準に沿ったデータの受け渡しを担うサービス事業者のことです。
発注側は自社の独自システムを使い続けられます¹。
受注側は、標準に対応したプロバイダーと業務アプリケーションを利用するだけで済み、大きな費用はかからないと説明されています¹。

業務アプリケーションとは、受注側が日々使う販売管理などのソフトのことです。
中小企業共通EDIでは、業務アプリケーションに対応を求める最低限必要な項目を13項目としており、例として注文書番号や注文書発行日が挙げられています¹。
受注側は画面を読んで打ち直すのではありません。
項目の決まったデータが手元のアプリケーションに届くので、自社システムへの取り込みを前提に運用を組めます。
手入力によるミスの削減が期待されるとも述べられています¹。

効果について、中小企業庁は、2018年の12の実証プロジェクトで中小企業の受発注業務時間が平均して51.4%削減されたと紹介しています¹。
大企業より中小企業のほうが削減率が高かったという記述もあります¹。
ただし、この数字は中小企業共通EDIの標準を使った実証の平均であり、Web-EDIを使った場合の効果ではありません。
測定した期間や、何を基準に時間を比べたかも示されていません。
そのため、自社で同じ割合だけ減ると見込む材料にはなりません。
読み取れるのは、注文がデータとして業務アプリケーションへ届く構成にしたとき、受発注の作業時間が大きく縮んだ実証がある、というところまでです。

手入力が残る範囲と取り込める範囲

ここまでを、受注担当者の作業に戻して整理します。
Web-EDIでは、注文の受け取りが画面に移ります。
ただし、画面から自社システムへ移す工程が減るかどうかは、取引先の画面がデータを出せるかに左右されます。
データ連携型では、注文が決まった項目のデータとして届きます。
そのため、販売管理への登録まで、手入力を挟まずにつなげられる余地が大きくなります。
二つの方式の違いが出るのは、注文を受け取ってから自社システムに入るまでの区間です。

反対に、どちらの方式でも残る作業があります。
一つ目は、在庫や生産の状況を見て納期を決める判断です。
二つ目は、数量や納品先が普段と違うなど、注文内容に不自然な点がないかの確認です。
三つ目は、取引先の品番と自社の品番が一致しないときに使う対応表の管理です。
データ連携で転記は減らせても、こうした判断までは代わりにしてくれません。
方式を比べるときは、読み取りと転記の時間と、判断と例外対応の時間を分けて考えると、期待しすぎずに比べられます。

▼ 図の内容を文字で読む

1. 発注側の独自システム
   • 発注側は継続して利用できる
2. 標準対応のプロバイダー
   • 受注側・発注側の双方が契約する
   • 統一したデータをやり取りする
3. 受注側の業務アプリケーション
   • 最低限必要な13項目に対応する
   • 手入力ミスの削減が期待される

取引先指定のWeb-EDIに入る場合と、自社で受注の仕組みを用意する場合の違い

比較表：画面の決定者・データ取込み・変更対応

前の節で見た違いは、もう一つの問いにつながります。
それは、誰が仕組みを決めるのかという問いです。
取引先から依頼が来たとき、受注側には二つの道があります。
一つは、取引先が指定するWeb-EDIにそのまま参加する道です。
もう一つは、自社側で受注の仕組みを用意し、取引先に送り方を合わせてもらう道です。
下の表は、この二つを4つの観点で比べた編集部の整理です。

判断が分かれるのは、取り込みと変更対応の行です。
取引先指定のWeb-EDIでは、画面を取引先が用意するので、受注側は参加の手続きを済ませて操作を覚えれば始められます。
その代わり、画面の項目、締め時間、データを取り出せるかどうかは、取引先の設計で決まります。
仕様が変われば、受注側が合わせることになります。
取引先が1社だけで件数も少なければ、この依存は大きな負担になりにくいでしょう。

ただし、取引先が1社でも注意したい場合があります。
受注件数が多く、販売管理への登録を毎日まとめて行っているような場合です。
このとき画面からデータを取り出せないと、件数の分だけ打ち直しが続きます。
参加するかどうかより先に、画面から何を取り出せるかを確かめておく価値があります。

自社で受注の仕組みを用意する場合は、自社の基幹に合わせて、受け取る形を決められます。
その一方で、取引先に送り方の変更を受け入れてもらう必要があり、相手のシステムや手順にも影響します。
中小企業共通EDIの説明には、発注側が独自システムを使い続けたまま、双方が標準対応のプロバイダーと契約してデータをやり取りする構成が示されています¹。
受注側の都合で仕組みを提案する場合でも、相手の既存システムを置き換えさせない形を示せれば、相手の負担を説明しやすくなります。
なお、どちらか一方に決める必要はありません。
取引先ごとに使い分けることもできます。

費用を断定できない理由と確かめ方

どちらが安いかは、一般論では決められません。
取引先指定のWeb-EDIの利用条件や、データ連携のプロバイダーの料金は、提供者や契約ごとに異なります。
公的な資料で比べられる相場も示されていません。
中小企業共通EDIについては、受注側の導入に大きな費用はかからないとされています¹。
ただし、具体的な金額は示されておらず、Web-EDIと比べた記述でもありません。
そこで、金額ではなく、それぞれの道で何に費用と時間がかかるかを並べて比べます。

• 取引先指定のWeb-EDIに参加する場合：利用料の有無と負担者、画面を開く端末や回線、画面の確認と転記にかかる担当者の時間
• 自社で受注の仕組みを用意する場合：プロバイダーとの契約、業務アプリケーションの対応や設定、取引先との調整とテストにかかる時間

見落としやすいのは、担当者の時間が費用として表に出にくいことです。
利用料のかからない画面でも、取引先ごとにログインして転記する時間が毎日積み重なれば、それは自社の負担になります。
最初に書き出した件数と転記時間を、それぞれの道で残る作業に当てはめてみてください。
金額を断定しなくても、負担の大小を比べられます。

▼ 図の内容を文字で読む

• 取引先指定のWeb-EDIに参加
  • 画面の項目・締め時間は取引先が決める
  • データを取り出せるかは取引先の設計しだい
  • 仕様が変われば受注側が合わせる
• 自社で受注の仕組みを用意
  • 受け取る形を自社の基幹に合わせて決められる
  • 取引先に送り方の変更を受け入れてもらう必要がある
• 取引先ごとの使い分け
  • どちらか一方に決める必要はない

取引先が増え画面がばらばらになるとき：運用負荷と基幹システム連携をどう見るか

切り替えを考える自社の指標

取引先が1社のうちは、指定された画面に入るのが手早い方法になりがちです。
問題になるのは、2社目、3社目からも別々のWeb-EDIを指定されたときです。
取引先ごとに、ログインする先、画面の操作、締め時間、品番やコードの体系が違えば、確かめる画面と転記の手順はその数だけ増えます。
担当者が覚えることも増えるため、担当者が休んだ日に代わりの人が対応しにくくなります。

何社になったら切り替えるべきか、という決まった基準はありません。
代わりに、自社の数字で次の指標を見ていくと判断しやすくなります。
判断したいのは、個別の画面対応を続けるか、データを取り込む運用へ寄せるかです。

• Web-EDIで受けている取引先の数と、今後増える見込み
• 1日の受注件数と、そのうち画面から転記している件数
• 画面の確認と転記にかかる時間の合計
• 転記が原因の入力ミスや訂正の件数
• 受注を基幹のどこまで流したいか（在庫引当、出荷指示、請求）

件数が少なく、基幹へ流すのが受注登録だけなら、画面対応を続けても負担は限られます。
件数が多く、出荷指示や請求まで一続きで流したいのに途中に転記が挟まっているなら、そこが切り替えを考える場所です。
その場合は、まず主要な取引先について二つの点を確かめます。
画面からデータを取り出せるか、標準のデータでの連携に応じてもらえるか、です。
使える手段がある取引先から順に移していくのが現実的です。

取引先の移行状況の事例の読み方

取引先の側も、一度に方式をそろえるわけではありません。
2016年の日経クロステックの記事で、ピップグループは「すでに10％強の取引先はIP網に対応した流通BMSやWeb-EDIなどに移行している」と述べています²。
この記事は、ISDN回線の終了に伴うEDIの対応を扱ったものです。
10％強という数字は1社の発言で、いつ時点の値かも示されていません。
業界全体の普及率として読める数字ではありません。

受注側にとって参考になるのは、割合そのものより、一つの会社の取引先の中に、流通BMSやWeb-EDIなど複数の方式が並んでいたという点です。
自社の取引先も、それぞれの事情で違う方式を求めてくる可能性があります。
取引先ごとに、今の方式と今後の予定を聞いておくとよいでしょう。
画面が増えていく見通しなのか、データ連携へ寄せていく見通しなのかがつかめれば、自社の切り替え時期を考えやすくなります。

導入前に取引先と何を確認し、どの順で始めるか

取引先への確認項目

方式の向き不向きが見えてきたら、依頼してきた取引先と具体的な条件を詰めます。
確認しないまま始めると、締め時間を過ぎた注文の扱いや回答の期限をめぐって、後から食い違いが出やすくなります。
次の項目は、受注側の作業の流れに沿って編集部が整理したものです。
取引先から資料や取り決めが示されている場合は、そちらを優先してください。

• 対象範囲：受注だけか、納期回答、出荷案内、請求まで含むか
• 締め時間：何時までの注文が当日扱いか、締め後の注文はどうなるか
• 納期回答：回答の期限と、画面で返すのか従来の手段で返すのか
• 受け取り方：画面での確認だけか、データとして取り出す手段があるか、その形式は何か
• コード体系：商品コードや取引先コードは相手の体系か、自社コードとの対応表が要るか
• 障害時の代替手段：画面が使えないときの受注方法と連絡先
• 費用負担：利用料の有無と、どちらが負担するか
• 問い合わせ窓口：操作や不具合を誰に聞くか
• 開始時期とテスト：試験運用の期間と、本番に切り替える条件

このうち判断を特に左右するのは、受け取り方とコード体系です。
データを取り出せれば、その後の転記を減らす道が開けます。
取り出せない画面なら、取引先が増えた時点で、前の節で見た切り替えの検討が必要になります。
コードが相手の体系で届く場合は、データで受け取っても自社コードへの置き換えが残ります。
対応表を誰が更新するかまで決めておくと、運用が安定します。

始め方の順序と並行できる作業

進め方は、現行手順の棚卸し、取引先への確認、テスト、段階的な開始の順にすると無理がありません。
棚卸しで自社の手間がどこにあるかを押さえておけば、取引先に何を聞くべきかが絞れます。
テストでは、実際に近い注文を画面やデータで受け取ります。
そのうえで、販売管理への登録、納期回答、出荷までを一通り流し、途中で止まる所がないかを確かめます。

取引先ごとの確認は、1社ずつ順番を待つ必要はなく、並行して進められます。
一方で本番の開始は、取引先や注文の種類を絞って始めると、問題が出たときの影響を小さくできます。
開始直後は、FAXやメールで届いた注文と画面の注文が混ざりやすくなります。
どの注文をどの手段で受けたかを記録しておくと、二重登録に気付きやすくなります。

障害時の代替手段

Web-EDIでは、画面を開いて初めて注文が見えます。
そのため、取引先のシステムや自社の回線に障害があると、注文が来ているのかどうかも分からなくなります。
データ連携でも、データが届かなければ同じことが起きます。
障害が起きたときにFAXやメールで受注する手順を、開始前に取引先と取り決めておくことを勧めます。

取り決めで大事なのは、代わりの手段で受けた注文を、復旧後にどう扱うかです。
障害中にFAXで受けた注文が、復旧後に画面にも表示されると、同じ注文を二度出荷するおそれがあります。
どちらを正式な注文とするか、注文番号でどう照合するか、連絡先は誰かまで決めておきましょう。
そうすれば、例外の日にも担当者が迷わずに済みます。

▼ 図の内容を文字で読む

1. 現行手順の棚卸し
   • 受け方ごとの件数と転記先
   • 転記時間とミスが起きる箇所
2. 取引先への確認
   • 取引先ごとに並行して進められる
   • 受け取り方とコード体系を優先して確かめる
3. テスト
   • 登録・納期回答・出荷まで一通り流す
   • 障害時の代替手段も試す
4. 段階的な開始
   • 取引先や注文の種類を絞って始める
   • 受けた手段を記録して二重登録を防ぐ

取引先から依頼を受けた段階では、自社の受注のどこに手間があり、指定された方式でどこまで減るのかを社内だけで見積もるのは難しいためです。

現行の受注手順と取引先の条件を並べて、指定のWeb-EDIに入った場合に残る転記と、データの取り込みを考えるべき範囲を確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
方式の違い	画面で操作するWeb-EDIか、標準のデータを受け渡す方式か
転記	画面から自社システムへ打ち直す作業が残るか
取引先数	画面・締め時間・コードの違いが何社分あるか
基幹連携	受注を在庫引当・出荷指示・請求のどこまで流したいか
主導権	画面・仕様・変更を誰が決め、誰が合わせるか
開始前	範囲・期限・受け取り方・コード・障害時の手段・費用負担を取引先ごとに確認

取引先ごとに方式や条件が違うと、確認項目の整理と切り替えの順序づけに手間がかかるためです。 取引先別の確認項目と始める順序を整理し、どの取引先から試すと無理がないかを確かめられます。

よくある質問

Web-EDIと流通BMSは併用できますか。取引先ごとに方式が違っても問題ありませんか

併用できます。
2016年の記事では、ピップグループの取引先の中で、流通BMSやWeb-EDIなどへの移行が進んでいると語られています²。
一つの会社の取引先に、複数の方式が並ぶことは起こり得ます。
受注側で気を付けたいのは、方式ごとに受注の入口と締め時間が分かれることです。
取引先ごとに、方式、締め時間、回答の方法、障害時の手段を一覧にしておくと、担当者が替わっても受け漏れを防ぎやすくなります。

取引先指定のWeb-EDIの内容を、自社の基幹システムに取り込むにはどんな方法を検討すればよいですか

最初に確かめるのは、取引先の画面から注文をデータとして取り出す手段があるか、その形式は何かです。
手段があれば、自社の販売管理などが読み込める形に合うかを見ます。
手段がない場合は、標準のデータでの連携に応じてもらえるかを取引先に相談する道があります。
中小企業共通EDIでは、発注側が独自システムを使い続けたまま、双方が標準対応のプロバイダーと契約してデータをやり取りする構成が示されています¹。
どの方法も取引先の対応が前提になるため、件数の多い取引先から順に聞いていくと効率的です。

Web-EDIを導入したあとも、障害時にFAXやメールで受注を続ける取り決めは必要ですか

取り決めておくことを勧めます。
画面を開けない、データが届かないといった状態では、注文があるかどうかも分からなくなるためです。
代わりの手段を決めるだけでなく、復旧後に画面にも同じ注文が出たときにどちらを正式とするか、注文番号でどう照合するかまで決めておきましょう。
そうしておくと、二重出荷を避けやすくなります。

取引先が小規模な場合、Web-EDIとデータ連携型のどちらを提案する側になりますか

どちらが提案するという決まりはありません。
受注側から提案する場合、受け入れやすさは相手によって変わります。
小規模な取引先が画面での発注に慣れているのか、自社のシステムを持っているのかが分かれ目です。
データ連携型を提案するなら、中小企業共通EDIのように発注側が独自システムを使い続けられる構成があることは、説明の材料になります¹。
ただし、双方が標準対応のプロバイダーと契約する前提があるため、相手の負担も含めて話し合う必要があります。

納期回答や出荷案内も、Web-EDIで返す必要がありますか

取引先の指定と、Web-EDIの対象範囲によります。
画面で扱うのは受注だけで、納期回答や出荷案内は従来どおりFAXやメールで返すという取り決めもあり得ます。
画面で返す場合は、自社の販売管理に入れた納期と画面に入れた納期がずれないようにする必要があります。
どちらを先に更新するかを社内で決めておくと、確認の手間が減ります。

1. 1　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
2. 2　出典：日経BP（日経クロステック）「ISDN移行に伴うEDIの対応（ピップグループ／フジモトHDの発言を含む記事）」（2016年）
3. 3　出典：GS1 Japan「流通BMS（流通ビジネスメッセージ標準）」（2026年閲覧）