まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

EDI導入で取引先の要求どおりに進めて困らないために:最初の確認5項目と方式の選び方

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • EDI対応の依頼は、帳票・通信手順・開始時期・費用負担・テストの5項目に分けて取引先へ確認すると、選べる方法と自社の負担が見える
  • 受注側は取引先ごとの方式に合わせる負担、発注側は相手の受け口につなぐ役割というように、立場で負担の現れ方が違う
  • 方式は取引先の指定を確かめたうえで、転記の手間・連携・費用の構成・取引先が増えたときの対応・利用条件で比べ、金額は見積で確かめる
  • 確認できたつまずきは通信手順の変更、取引先1社ずつの日程調整、切替時期の集中で、早めの着手と取引先ごとの確認表が備えになる
  • 費用や方式の指定に納得できないときは、取適法の対象取引かを相談窓口などで確かめ、協議や段階導入を申し出る

Businesswoman in office writing notes with documents and laptop, focused on analysis and productivity.
▽ 写真の出典元

取引先からEDI対応を求められたら、最初に確かめる5つのこと

取引先から期限付きで「EDIで受発注してほしい」と依頼が来ると、何を決めればよいか分からないまま、指定された方式にそのまま合わせてしまいがちです。
まず依頼を帳票・通信手順・開始時期・費用負担・テストの5項目に分けて取引先へ確認すると、自社に選べる方法の幅と負担の中身が見えてきます。
EDI導入でつまずきやすいのは、通信手順の変更、取引先1社ずつの日程調整、切替時期の集中です。
費用や方式の指定に納得できないときは、取適法の対象取引かを確かめたうえで、協議や段階導入を申し出る道があります。

依頼文を分解する:帳票・通信手順・時期・費用負担・テスト

EDI(電子データ交換)は、注文や出荷、請求の連絡を、紙やFAXではなく決まった形式のデータで企業間に受け渡す仕組みです。
取引先からの依頼が「EDIで受発注してほしい」という一文で届いた場合でも、その中には、どの書類をデータにするのか、どの方法で送受信するのか、いつから始めるのか、費用を誰が持つのか、本番前にどう確かめるのか、という別々の問いが含まれています。
これらをひとまとめにして「対応します」と返すと、あとから自社の作業や費用の範囲が広がっても、どの時点で何が決まったのかを振り返れません。

そこで、依頼をまず5つの項目に分け、項目ごとに取引先の答えを書き留めておくことを提案します。
決まった様式があるわけではありませんが、項目を分けておくと、取引先の答えが曖昧なところと、自社で決めればよいところの区別がつきます。

5項目のうち、最初に答えをそろえたいのは帳票です。
受注だけをデータにして出荷や請求の連絡は従来どおりにするのか、受注から請求までを一続きでデータにするのかによって、自社の中で手順が変わる部署が違ってくるからです。
たとえば受注データだけが届く形なら、変わるのは主に注文を受け付ける担当の作業です。
出荷の連絡や請求までデータで返すことになれば、出荷を担う担当や経理の手順にも話が及びます。

通信手順は、自社にどんな仕組みが必要になるかを左右する項目です。
取引先が自社のシステムと直接データをやり取りしたいのか、取引先が用意したWeb画面で注文を確認してほしいのかで、自社が準備するものはまったく違います。
依頼文に手順の名前が書かれていれば、それが何を意味するのかを次の項で見分けます。

開始時期とテストは、別々に聞くより組にして確かめると、無理のある日程に気づきやすくなります。
ある企業グループの事例では、EDIの切り替えを小売店1社ずつとスケジュールを合わせて進める必要があったと報じられています1。
依頼する側が多くの相手と切り替えを進めていれば、自社との接続確認もその予定の中に組み込まれます。
「○月開始」とだけ聞いて準備を始めるのではなく、その前のどの時期にテストの枠があり、誰が相手の窓口になるのかまで聞いておくと、自社の準備をいつまでに終えればよいかが決まります。

費用負担は、聞きにくさから後回しにされやすい項目です。
しかし、取引先が用意する画面を使うだけなのか、自社側にも送受信の仕組みや設定が要るのかが分からないうちは、見積を取る範囲も決まりません。
ここでは金額そのものより、何を自社で用意し、何を取引先が用意するのかという分担を先に確かめておくことが、あとで条件を相談するときの土台になります。

通信手順の違い(ebMS・AS2・JX手順・旧手順)を見分ける

通信手順とは、データを送る側と受け取る側が、接続の仕方や送受信の順番をそろえるための約束事です。
小売・卸・メーカーの間では、受発注のプロセスやメッセージを共通化したEDIの標準仕様として流通BMSがあります1。
依頼文に流通BMSの名前があれば、次に確かめるのは、その中のどの手順が指定されているかです。

流通BMSでは、インターネットを使う通信手順が二つの形に分かれています4。
サーバー間(S-S)の手順はebMSとAS2で、送る側と受け取る側がそれぞれサーバーを持ってやり取りする形です。
クライアント・サーバー間(C-S)の手順はJX手順で、SOAP-RPCという方式を使い、旧来のJ手順が持っていた基本的な通信制御の機能をインターネット上で使えるように設計されています4。

依頼文にJ手順やH手順が書かれている場合は、旧来の標準手順を指していると読めます。
J手順(JCA手順)は日本チェーンストア協会が開発し、1982年に通商産業省が標準通信手順として制定したもので、H手順は1992年に命名され、のちにTCP/IPが追加されました4。
こうした旧来の手順を今回の依頼でもそのまま使うのか、インターネットを使う手順へ移す予定があるのかは、手順の説明だけからは判断できません。
過去には、ISDNの終了に向けて通信手順の変更を迫られた企業の事例も報じられています1。
旧来の手順の名前を見たら、そのまま続けるのか、切り替えの予定があるのかを取引先に聞いておくと、一度用意した仕組みをすぐに作り直す事態を避けやすくなります。

サーバー間とクライアント・サーバー間のどちらを指定されたかによって、自社側に用意するものが変わります。
検討しているEDIの製品やサービスが指定の手順に対応しているかは、流通BMS協議会が公開している機能確認シートで確かめられます5。
このシートは、AS2・ebMS・J手順に接続するために必要な機能をEDI製品が備えているかを確認するためのもので、あわせて公開されている通信プロトコル利用ガイドラインには、インターネットで送受信する際の通信プロトコルとセキュリティの標準仕様、推奨パラメータがまとめられています5。

反対に、取引先が「当社のWeb画面から注文を確認してください」と言う場合、自社側で通信手順を選ぶ場面はほとんどありません。
確認表の通信手順の欄には「ブラウザで利用」と書き、その代わりに、画面で見た注文を自社の中でどう扱うかを、方式を選ぶ段階で考えることになります。

確認結果を社内に説明するときの整理

確認した結果を社内に持ち帰ると、話を聞く相手によって気にするところが違います。
導入を決める人は費用と開始時期を、毎日注文を扱う担当者は画面の操作や受け取ったデータの扱いを、システムを預かる担当者は自社の仕組みに何が加わるかを、それぞれ知りたいはずです。
EDIを導入すると決める立場の人と、実際に注文の画面や受信データに日々向き合う人が別であることもあります。

そのため、5項目の確認表に「取引先の回答」「未回答」「自社で決めること」の三つの欄を付け、誰に何を判断してもらうのかを分けて示すと、説明が噛み合いやすくなります。
未回答の欄が残ったまま導入の可否を決めると、決めた人が想定していなかった負担が、あとから現場に回ってきます。
未回答の項目は、そのまま取引先へ聞き返す内容として使えます。

確認する項目 取引先に聞くこと 答えで変わること
帳票 受注・出荷・請求などのどのやり取りをデータにするか 手順が変わる自社の部署と担当
通信手順 ebMS・AS2・JX手順などのどれか、またはWeb画面を使うだけか 自社側に用意する仕組みと選べる方式
開始時期 いつから、どの帳票から切り替えるか 準備に使える期間と従来の方法との並行の有無
費用負担 自社で用意するものと取引先が用意するもの 見積を取る範囲と協議の要否
テスト 接続確認の時期・相手の窓口・確認の方法 本番前に誰が何を確かめるか
5項目を確かめる目的ごとに分けた整理(模式図)
帳票と通信手順は作業の範囲、開始時期とテストは日程、費用負担は分担を決める確認として分けた図帳票と通信手順は作業の範囲、開始時期とテストは日程、費用負担は分担を決める確認として分けた図自社の作業の範囲を知る帳票:どのやり取りをデータにするか通信手順:自社にどんな仕組みが必要か日程を組む開始時期:いつから、どの帳票からかテスト:接続確認の時期と相手の窓口分担を確かめる費用負担:自社で用意するものと取引先が用意するもの

▼ 図の内容を文字で読む
  • 自社の作業の範囲を知る
    • 帳票:どのやり取りをデータにするか
    • 通信手順:自社にどんな仕組みが必要か
  • 日程を組む
    • 開始時期:いつから、どの帳票からか
    • テスト:接続確認の時期と相手の窓口
  • 分担を確かめる
    • 費用負担:自社で用意するものと取引先が用意するもの
依頼文に出てくる通信手順の見分け方(模式図)
ebMSとAS2はサーバー間、JX手順はクライアント・サーバー間、J手順とH手順は旧来の手順、Web画面は手順を選ばない場合として分けた図ebMSとAS2はサーバー間、JX手順はクライアント・サーバー間、J手順とH手順は旧来の手順、Web画面は手順を選ばない場合として分けた図サーバー間(S-S)ebMSとAS2双方がサーバーを持ってやり取りするクライアント・サーバー間(C-S)JX手順SOAP-RPCを使い、J手順の基本的な通信制御の機能をインターネット上で使えるようにした旧来の標準手順J手順(JCA手順)とH手順そのまま続けるのか、切り替えの予定があるのかを取引先に聞くWeb画面で確認する場合確認表の通信手順の欄は「ブラウザで利用」と書く通信手順を選ぶ場面はほとんどない

▼ 図の内容を文字で読む
  • サーバー間(S-S)
    • ebMSとAS2
    • 双方がサーバーを持ってやり取りする
  • クライアント・サーバー間(C-S)
    • JX手順
    • SOAP-RPCを使い、J手順の基本的な通信制御の機能をインターネット上で使えるようにした
  • 旧来の標準手順
    • J手順(JCA手順)とH手順
    • そのまま続けるのか、切り替えの予定があるのかを取引先に聞く
  • Web画面で確認する場合
    • 確認表の通信手順の欄は「ブラウザで利用」と書く
    • 通信手順を選ぶ場面はほとんどない

受注側か発注側かで、負担と選べる方法はどう変わるか

EDIは1社だけ導入しても効果が出ない理由

中小企業庁のミラサポplusは、EDIは1社だけが導入しても効果を得られず、取引先の状況や環境を考えて、共通認識を持ちながら連携して進める必要があると説明しています2。
受発注は送る側と受け取る側がそろって初めて成り立つので、片方だけがデータにしても、もう片方が紙やFAXのままなら、結局どこかで人が読み取って入力し直すことになります。

同じ記事は、発注側の企業が独自のシステムを使っているために、受発注のIT化が進みにくい構造があることにも触れています2。
ここから読み取れるのは、EDIの負担が立場によって同じ形では現れないということです。
どちらの立場に費用がどれだけかかるかは一律には言えないため、ここでは金額の大小ではなく、負担がどんな作業として現れるかを立場ごとに見ていきます。

受注側:取引先ごとの方式に合わせる負担

自社が注文を受ける側で、取引先から「当社の方式で」と依頼された場合を考えます。
発注側がそれぞれ独自の仕組みを持つ構造のもとでは、受注側は取引先ごとに異なる画面、データの形式、通信手順に合わせる立場に置かれやすいと考えられます。

たとえば、すでに1社の取引先とはWeb画面で受注していて、別の取引先からはデータの送受信を求められた場合、受注担当者は一方の画面を確認し、もう一方からは受信データを受け取るという二通りの流れを抱えることになります。
取引先が3社、4社と増えれば、確認する場所も、データの形式の違いも増えていきます。
依頼を1社分だけで判断すると、この積み重なりが見えにくくなります。

この負担を減らそうとする取り組みとして、中小企業共通EDIがあります。
2018年4月に仕様が策定され、取引先ごとにばらばらだったEDIのデータの形式を、国際標準に準拠した形で共通化し、導入の手間とコストを減らすことを目指しています2。
ただし、どの標準を使うかは相手との合意で決まるため、受注側だけの判断で採用できるわけではありません。
依頼を受けた時点で、他の取引先と共通の方式で応じられないかを尋ねることは、受注側から出せる相談の一つです。

発注側:取引先が使える形を用意する役割

反対に、自社が注文を出す側で、仕入先などの取引先から「注文をEDIで送ってほしい」と依頼される場合もあります。
このとき求められるのは、取引先が受け付けられる形で注文データを送ることです。
自社の発注の仕組みが社内向けに作られていれば、その出力を相手の受け口に合わせて変える必要が出てきます。

発注側にはもう一つの面があります。
自社が多くの仕入先へ注文を出しているなら、今回の依頼に合わせた方式が、他の仕入先との取引にも広げられるかどうかを考えておく必要があります。
1社の求めに合わせて特別な形を作ると、自社が独自の方式を持つ発注側になり、今度は別の仕入先にその方式への対応をお願いする立場になりえます。
EDIが1社だけでは効果を生まない以上、取引先が無理なく使える形を選ぶことは、発注側である自社の効果にも関わります。

比べる点 受注側として依頼を受けた場合 発注側として依頼を受けた場合
依頼の中身 取引先から届く注文データを受け取り、出荷や請求を返す 取引先が受け付ける形で注文データを送る
負担が出やすいところ 取引先ごとに異なる画面・形式・手順に合わせること 社内向けの発注の仕組みを相手の受け口につなぐこと
取引先に確かめたいこと 他の取引先と共通の方式で応じられるか 他の仕入先にも同じ方式を広げられるか
受注側と発注側で異なる負担と相談の内容(模式図)
受注側は取引先ごとの方式に合わせる負担と共通方式の相談、発注側は相手の受け口につなぐ役割と他の仕入先への展開を示した図受注側は取引先ごとの方式に合わせる負担と共通方式の相談、発注側は相手の受け口につなぐ役割と他の仕入先への展開を示した図受注側として依頼を受けた場合取引先から届く注文データを受け取る取引先ごとに異なる画面・形式・手順に合わせる負担が出やすい他の取引先と共通の方式で応じられないかを尋ねる発注側として依頼を受けた場合取引先が受け付ける形で注文データを送る社内向けの発注の仕組みを相手の受け口につなぐ必要が出る他の仕入先にも同じ方式を広げられるかを考える

▼ 図の内容を文字で読む
  • 受注側として依頼を受けた場合
    • 取引先から届く注文データを受け取る
    • 取引先ごとに異なる画面・形式・手順に合わせる負担が出やすい
    • 他の取引先と共通の方式で応じられないかを尋ねる
  • 発注側として依頼を受けた場合
    • 取引先が受け付ける形で注文データを送る
    • 社内向けの発注の仕組みを相手の受け口につなぐ必要が出る
    • 他の仕入先にも同じ方式を広げられるかを考える

Web-EDI・基幹システム連携・サービス/代行は何で選ぶか

3つの方法を同じ軸で比べる

取引先の手順や画面の指定が分かったら、自社としての応じ方を選びます。
主な方法は三つです。
Web-EDIは、インターネットを使い、Webブラウザーの操作で受発注のやり取りを行うEDIです1。
基幹システム連携は、自社の販売管理や受発注のシステムに取引先とのデータ送受信をつなぎ、受け取った注文を自社の仕組みに直接取り込む形を指します。
EDIサービスや代行は、送受信やデータの変換を外部の事業者の仕組みに任せる形です。

どの方法が使われているかについては、流通BMS協議会の調査を報じた記事が手掛かりになります。
2024年12月時点の調査で、卸・メーカーの流通BMS導入企業数は推計2万800社以上とされ、大手小売が流通BMSを採用していることが取引先の導入を後押ししていると報じられています3。
一方で、システムの導入や改修に費用をかけにくい中小零細企業でWeb-EDIが増えていることが、課題として挙げられています3。
費用の面から始めやすい方法が選ばれている一方で、その状態がそのまま望ましいとは見られていない、ということです。

課題とされる理由は報道からは確かめられませんが、仕組みから考えると、ブラウザの画面で注文を扱う方法は、人が画面を見て操作することを前提にしています。
画面で受け取った注文を自社の販売管理などに入れる作業は、別に残る可能性があります。
この点を含めて、三つの方法を同じ軸で並べたのが次の表です。
金額は提供元や契約によって異なるため表には載せず、見積で確かめる項目として扱っています。

表で判断が分かれるのは、主に「入力・転記の手間」と「取引先が増えたときの対応」の二つの行です。
取引先が1社で注文の件数も限られるなら、画面で確認して手で入力する作業が大きな負担にならないこともあります。
一方で、同じ注文を画面から自社のシステムへ打ち直す作業が毎日続く場合や、同じような依頼が別の取引先からも来そうな場合は、最初の方式選びがその後の手間を左右します。

なお、取引先がWeb-EDIしか認めていない場合、この比較はそもそも成り立ちません。
そのとき検討することは方式の選択ではなく、画面で受け取った注文を自社の中でどう扱うかに移ります。

Web-EDIが向く場合と、後から困りやすい場合

たとえば、受注担当者が毎朝、取引先のWeb画面にログインして新しい注文を確認し、品名と数量を自社の販売管理に入力し、出荷が決まったら画面に戻って出荷の連絡を入れる、という流れを考えます。
FAXで注文を受けていたときと比べると、紙の文字を読み取る手間はなくなり、注文の内容が画面上に残るという変化があります。
ただ、販売管理への入力そのものは残ったままです。

この形でも困りにくいのは、取引先が限られ、注文の件数も手で扱える範囲に収まっている場合です。
反対に困りやすいのは、取引先ごとに別々の画面があってログイン先が増えていく場合や、画面の内容を販売管理へ転記するときの見比べに時間がかかっている場合です。
画面から注文データをファイルとして取り出せるか、その形式を自社の仕組みに読み込めるかによって、転記がどこまで減るかが変わります。
この点は取引先が提供する仕組みによって異なるため、依頼を受けた段階で取引先に尋ねておきたいところです。

基幹システム連携やサービスを使えば、受信したデータを自社の仕組みに取り込めるため、注文内容を打ち直す作業は減らせます。
それでも、取り込んだ注文の内容に誤りがないか、在庫や納期に無理がないかを確かめる作業は人の手に残ります。
どの方法を選んでも確認がなくなるわけではなく、減るのは主に転記の作業だと考えておくと、導入後の期待と実際との差が小さくなります。

見積時に確認する項目

基幹システム連携やサービス・代行を検討する場合、見積を依頼する前に、取引先から聞いた5項目の答えを手元にそろえておくと、提供元ごとに比べる条件がそろいます。
そのうえで、提供元には次の点を確かめます。

  • 取引先が指定した通信手順に対応しているか(機能確認シートの項目に沿って説明を受けられるか)
  • 取引先が求める帳票に対応しているか
  • 受信したデータを自社のシステムへどの形式で渡せるか
  • 費用の内訳(初めにかかるもの、継続してかかるもの、取引先を追加したときの扱い)
  • 取引先との接続確認やテストを、どこまで支援するか

機能確認シートは、AS2・ebMS・J手順への接続に必要な機能を製品が備えているかを確かめるための資料なので5、提供元の説明をこのシートの項目に当てはめて聞くと、対応の有無を同じ物差しで比べられます。
費用の内訳は、取引先が今後増えたときの扱いまで含めて聞いておくと、表の「取引先が増えたときの対応」の行を自社の条件で埋められます。

比べる点 Web-EDI 基幹システム連携 EDIサービス・代行
入力・転記の手間 画面で見た注文を自社の販売管理などへ移す作業が残りやすい 受信データを自社システムへ取り込めれば転記が減る 自社システムへの受け渡し方しだいで転記の残り方が変わる
自社システムとのデータ連携 画面からデータを取り出せるかは取引先の仕組みしだい 取引先の帳票と手順に合わせた取り込みの作り込みが要る 渡されるデータの形式と取り込み方法を確かめる
費用の構成 自社システムの改修を伴わずに始めやすい。利用条件は取引先に確認 自社システムの改修や接続の仕組みと、その保守。見積時に確認 初めにかかるもの・継続してかかるもの・取引先追加時の扱い。見積時に確認
取引先が増えたときの対応 取引先ごとに画面が異なれば確認先が増える 取引先ごとの帳票と手順への対応を追加する 追加の取引先に対応できるかとその扱いを確かめる
利用条件 取引先がWeb画面を提供していること 自社側の仕組みが取引先の通信手順に対応していること 提供元が取引先の手順と帳票に対応していること
画面で確認して手で入力する運用が向く条件と困りやすい条件(模式図)
取引先が1社で件数が限られる場合は困りにくく、毎日の打ち直しや他の取引先からの依頼が見込まれる場合は最初の方式選びが効き、Web-EDIしか認められない場合は社内の扱いを考えることを示した図取引先が1社で件数が限られる場合は困りにくく、毎日の打ち直しや他の取引先からの依頼が見込まれる場合は最初の方式選びが効き、Web-EDIしか認められない場合は社内の扱いを考えることを示した図困りにくい場合取引先が1社で注文の件数も限られる画面で確認して手で入力する作業が大きな負担にならないこともある最初の方式選びが効く場合同じ注文を画面から自社のシステムへ打ち直す作業が毎日続く同じような依頼が別の取引先からも来そうWeb-EDIしか認められない場合方式の選択は成り立たない画面で受け取った注文を自社の中でどう扱うかを考える

▼ 図の内容を文字で読む
  • 困りにくい場合
    • 取引先が1社で注文の件数も限られる
    • 画面で確認して手で入力する作業が大きな負担にならないこともある
  • 最初の方式選びが効く場合
    • 同じ注文を画面から自社のシステムへ打ち直す作業が毎日続く
    • 同じような依頼が別の取引先からも来そう
  • Web-EDIしか認められない場合
    • 方式の選択は成り立たない
    • 画面で受け取った注文を自社の中でどう扱うかを考える

EDI導入のつまずきはどの作業で起きるか

通信手順の変更

EDI導入の失敗やつまずきについて、具体的な作業の名前まで確かめられるのは、ある企業グループの事例です。
2016年の日経クロステックの記事によると、この企業グループは約500弱の小売店とEDIで取引しており、ISDNの終了に向けて通信手順を変更しなければならず、それが「とても大変」だと述べています1。
2020年度後半の切り替えを前提にした当時の話であり、いま届いている依頼の事情とそのまま同じとは限りません。
それでも、どの作業で手間が生じたかは、これから依頼に応じる側にとっての手掛かりになります。

通信手順の変更が重いのは、送る側と受け取る側の双方で、同じ約束事にそろえ直さなければならないからです。
自社だけで設定を変えても、相手の準備が終わっていなければデータは届きません。
手順によって自社側に用意するものも変わるため、指定された手順が後から変わると、それに合わせて準備をやり直すことになります。

取引先1社ずつの日程調整

同じ記事では、EDIの切り替えは小売店1社ずつとスケジュールを合わせて取り組まなければならず、事前調整から利用開始までに1か月ほどかかると述べられています1。
この1か月は、この企業グループで取引先1社あたりにかかった目安であり、EDI導入一般の所要期間ではありません。
それでも、相手ごとに担当者と予定を合わせ、調整を終えてから使い始めるまでの時間を見込む必要があることは読み取れます。

依頼を受ける側に置き換えると、自社が複数の取引先から依頼を受けていれば、それぞれの相手との日程が別々に動くことになります。
相手ごとに手順や帳票が違えば、確認する中身も同じにはなりません。
ある取引先とのテストで済ませた確認を、別の取引先との間でもう一度行う必要が出てくるのは、このためです。

切替時期の集中

記事は、移行が切替の直前に集中すると、間に合わない取引先が出てくるとも述べています1。
当時この企業グループで、すでにIP網に対応した流通BMSやWeb-EDIなどへ移行していた取引先は10%強で、多くの相手との切り替えがこれからという段階でした1。
1社ずつ時間がかかる作業が期限の前に重なれば、調整の枠が足りなくなります。

依頼を受けた側から見ると、取引先が多くの相手と同時に切り替えを進めている場合、期限が近づくほど接続確認の日程は取りにくくなると考えられます。
期限付きの依頼が届いたときに、まだ先の話だと後回しにすると、自社の番が来るころには取引先側の予定が詰まっている、ということが起こりえます。

防ぎ方の提案

三つのつまずきは、いずれも技術の選び方そのものより、相手との調整と時期の管理の中で起きています。
ミラサポplusが、取引先と共通認識を持って連携して進めることを求めているのも2、同じ方向の指摘として読めます。
そこから考えられる防ぎ方を、つまずきごとに並べると次のようになります。

通信手順については、5項目の確認で手順の名前だけでなく今後の切り替え予定まで聞いておくことで、準備のやり直しが起きる可能性を減らせます。
日程調整については、取引先ごとに確認表を1枚ずつ作り、テストの日程と相手の窓口を書き込んでおくと、複数の相手と並行して進めるときに、どの相手の何が終わっていないかが見えます。
時期の集中については、依頼が届いた時点で着手し、テストの枠を早めに押さえておくことが、直前の混み合いを避ける手立てになります。

いずれも、つまずきを確実になくす方法ではありません。
減らせるのは、手順の変更に気づくのが遅れることや、どの相手との調整が残っているかを見失うことであり、取引先の都合で日程が動く余地は残ります。

つまずき 起きる作業 防ぎ方の提案
通信手順の変更 送る側と受け取る側で約束事をそろえ直す 手順の名前と今後の切り替え予定を最初に確認する
取引先1社ずつの日程調整 相手ごとに担当者と予定を合わせ、調整してから利用を始める 取引先ごとに確認表を作り、テストの日程と窓口を書き込む
切替時期の集中 期限前に複数の相手との調整が重なる 依頼が届いた時点で着手し、テストの枠を早めに押さえる
ある企業グループの事例(2016年)の数値と読み方(模式図)
約500弱の小売店との取引、1社あたり1か月ほどの調整期間、10%強の移行済みという事例の数値と、EDI導入一般の目安ではないという読み方の注意を示した図約500弱の小売店との取引、1社あたり1か月ほどの調整期間、10%強の移行済みという事例の数値と、EDI導入一般の目安ではないという読み方の注意を示した図事例の前提約500弱の小売店とEDIで取引する企業グループISDNの終了に向けて通信手順の変更が必要だった事例の数値事前調整から利用開始まで、取引先1社あたり1か月ほどIP網対応の流通BMSやWeb-EDIなどへ移行済みの取引先は10%強読むときの注意1か月はこの企業グループの目安であり、EDI導入一般の所要期間ではないいま届いている依頼の事情とそのまま同じとは限らない

▼ 図の内容を文字で読む
  • 事例の前提
    • 約500弱の小売店とEDIで取引する企業グループ
    • ISDNの終了に向けて通信手順の変更が必要だった
  • 事例の数値
    • 事前調整から利用開始まで、取引先1社あたり1か月ほど
    • IP網対応の流通BMSやWeb-EDIなどへ移行済みの取引先は10%強
  • 読むときの注意
    • 1か月はこの企業グループの目安であり、EDI導入一般の所要期間ではない
    • いま届いている依頼の事情とそのまま同じとは限らない

断る・条件交渉・段階導入を選ぶ判断基準

取適法の禁止行為と、確認できる範囲・できない範囲

取引先が求める方式や費用の分担に納得できないとき、知っておきたいのは、こうした相談を持ち出す手掛かりが法律の側にもありうるということです。
公正取引委員会は、取適法で委託事業者に禁じられる行為として、自己のために金銭や役務などの経済上の利益を提供させて中小受託事業者の利益を不当に害すること、協議に応じず一方的に代金を決めること、指定した物や役務を強制して購入・利用させることなどを示しています6。

ただし、EDIへの対応を求められたことや、その費用を負担するよう言われたことが、そのままこれらの禁止行為に当たるとは言えません。
取適法が適用されるのは、対象となる取引の種類と事業者の規模の区分に当てはまる場合に限られます。
EDIの費用負担がこれらの行為に当たるかどうかも、取引の内容に照らして個別に判断される事柄です。

自社の取引が対象になるかどうか、求められている負担がどう評価されうるかは、公正取引委員会や中小企業庁の相談窓口などで確かめられます。
対象に当たらない取引であれば、話は法律ではなく、取引の条件をめぐる通常の交渉になります。
どちらの場合でも、協議を申し出ること自体は、取引先に負担の中身を伝える出発点になります。

協議の申し出で整理しておくこと

協議を申し出るときに伝わりやすいのは、「負担が大きい」という感想ではなく、どの項目の何が自社にとって難しいのかを具体的に示した説明です。
最初に作った5項目の確認表がそのまま使えます。
たとえば、通信手順の指定によって自社側に新しい仕組みが必要になる、開始時期までにテストの準備が間に合わない、費用の分担が決まっていない、といった形で、項目ごとに困る点を書き出します。

あわせて代わりの案を添えると、取引先にとっても判断しやすくなります。
開始時期をずらす、対象の帳票を絞って始める、他の取引先と共通の方式で応じる、しばらくは従来のFAXやメールと併用する、といった案です。
受注側であれば取引先ごとに方式が増えていく負担を、発注側であれば他の仕入先にも同じ方式を広げられるかという点を、それぞれ添えると話の筋が通ります。

協議の内容は口頭だけで済ませず、確認表と一緒に書面やメールで残しておくと、後で条件を見直すときの拠り所になります。

段階導入の進め方

EDIの切り替えが1社ずつ日程を合わせて進むものである以上1、すべての帳票、すべての取引先を一度に切り替えることだけが進め方ではありません。
段階導入は、範囲を区切って先に始め、うまく回ることを確かめてから広げる進め方です。
帳票で区切るなら、受注のデータから始め、出荷や請求の連絡は後に回すといった順番が考えられます。
取引先で区切るなら、先に準備が整った数社から始め、その経験をもとに残りの相手との手順を整えます。

段階導入の利点は、最初の範囲で見つかった確認漏れや手順の食い違いを、次の範囲に持ち越さずに済むことです。
一方で、切り替えの途中は、EDIで受ける注文と従来の方法で受ける注文が並ぶため、どの取引先がどちらなのかを社内で取り違えない工夫が要ります。
取引先ごとの確認表に、いまどちらの方法で受けているかを書いておくだけでも、取り違えに気づきやすくなります。

受ける、条件を交渉する、段階的に進める、断る、のどれを選ぶかは、ここまでの確認を順に当てて考えます。
5項目の答えがそろい、自社の立場での負担が見え、方式ごとの負担を比べられた段階で、そのまま受けられるのか、条件の調整が要るのかが判断できます。
断るという選択はEDIの話にとどまらず取引全体に影響するため、他の選択肢を検討したうえで社内で決める事柄です。

EDI対応の依頼への応じ方を決める順番
依頼を5項目に分けて確認し、自社の立場での負担を見て、方式ごとの負担を比べたうえで、受ける・条件を交渉する・段階的に進める・断るのいずれかを決める流れ1帳票・通信手順・開始時期・費用負担・テストの5項目の答えをそろえる2受注側か発注側かで、自社の負担の種類を見る3方式ごとの負担を比べる4受ける・条件を交渉する・段階的に進める・断るのいずれかを社内で決める

▼ 図の内容を文字で読む
  1. 帳票・通信手順・開始時期・費用負担・テストの5項目の答えをそろえる
  2. 受注側か発注側かで、自社の負担の種類を見る
  3. 方式ごとの負担を比べる
  4. 受ける・条件を交渉する・段階的に進める・断るのいずれかを社内で決める

取引先の依頼文だけでは、自社の帳票や受発注の流れのどこが変わるのか、どの方式なら比較が成り立つのかを社内だけで見極めにくいためです。

依頼文と現在の受発注の流れを並べ、5項目のうち未確認の点と、取引先に聞き返す内容を一緒に洗い出せます。無料相談で要件を整理する

要点の整理

軸 基準
最初の確認 帳票・通信手順・開始時期・費用負担・テストの5項目を取引先に確認する
通信手順 ebMSとAS2はサーバー間、JX手順はクライアント・サーバー間。旧手順なら切り替え予定を聞く
立場 受注側は取引先ごとの方式に合わせる負担、発注側は相手の受け口につなぐ役割
方式選び 転記の手間・連携・費用の構成・取引先が増えたときの対応・利用条件で比べ、金額は見積で確かめる
つまずき 通信手順の変更、取引先1社ずつの日程調整、切替時期の集中
条件交渉 取適法の対象取引かを相談窓口などで確かめ、協議・段階導入を申し出る

協議や段階導入を申し出るには、自社の負担と代わりの案を、取引先に伝わる形でまとめておく必要があるためです。 協議で示す負担の中身と代案を整理し、自社で判断できる点と、公的な相談窓口などで確かめるべき点を切り分けられます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

取引先がWeb-EDIしか認めない場合、自社の基幹システムと連携させることはできますか

Web-EDIはブラウザの画面で受発注を行う仕組みなので、連携できるかどうかは、画面から注文データをファイルなどで取り出せるか、取り出したデータを自社のシステムに読み込めるかで決まります。
取り出せるかどうかや形式は取引先が提供する仕組みによって異なるため、まず取引先に、受注データを出力できるか、できる場合の形式は何かを尋ねます。
取り出せない場合は、画面の内容を自社のシステムへ入力する作業が残ります。

流通BMSとWeb-EDIと中小企業共通EDIは、何が違い、どれを選べばよいですか

流通BMSは、小売・卸・メーカーが受発注のプロセスやメッセージを共通化したEDIの標準仕様です1。
Web-EDIは、Webブラウザーの操作で受発注を行うEDIの方式です1。
中小企業共通EDIは2018年4月に仕様が策定され、取引先ごとにばらばらだったデータの形式を国際標準に準拠した形で共通化し、導入の手間とコストを減らすことを目指しています2。
どれを使うかは相手との合意で決まるため、まず取引先の指定を確かめ、そのうえで他の取引先とも共通の方式で応じられないかを相談するのが現実的な順番です。

JX手順・ebMS・AS2のどれに対応すればよいか、取引先に何と聞けばよいですか

対応すべき手順は取引先の指定によって決まるため、「どの通信手順で接続するのか」「サーバー間の手順か、クライアント・サーバー間の手順か」を具体的に尋ねます。
流通BMSでは、サーバー間の手順がebMSとAS2、クライアント・サーバー間の手順がJX手順です4。
あわせて、今後手順を切り替える予定があるかも聞いておくと、準備のやり直しを避けやすくなります。
検討中の製品やサービスが指定の手順に対応しているかは、機能確認シートの項目に沿って提供元に確かめられます5。

取引先1社ごとの事前調整から利用開始まで、どのくらい見ておけばよいですか

一般的な所要期間を示せる資料はありません。
参考になるのは、約500弱の小売店とEDIで取引するある企業グループが、2016年時点で事前調整から利用開始まで1社あたり1か月ほどかかると述べている例です1。
手順や帳票、相手側の予定によって変わるため、取引先にテストの時期と窓口を確認し、そこから逆算して自社の準備期間を決めます。

EDI対応を一時的にFAXやメールと併用して続けたい場合、取引先にどう相談しますか

併用を求める理由を、5項目の確認表に沿って具体的に示すと伝わりやすくなります。
たとえば、テストの準備が開始時期に間に合わない、対象の帳票を絞って始めたい、といった事情と、併用をいつまで続け、どの段階でEDIへ移すかの見通しを一緒に伝えます。
併用の期間中は、どの注文をどちらの方法で受けているかを取り違えないよう、取引先ごとに受け方を記録しておきます。

取適法の対象かどうかは、どこで確かめられますか

取適法は、対象となる取引の種類と事業者の規模の区分に当てはまる場合に適用されます。
自社の取引が対象になるか、EDIの費用負担などがどう評価されうるかは、公正取引委員会や中小企業庁の相談窓口などで確かめられます6。
対象に当たらない場合は、取引条件をめぐる通常の交渉として協議を申し出ることになります。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:日経BP(日経クロステック)「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」(2016年)
  2. 2 出典:中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する!」(2020年)
  3. 3 出典:LOGISTICS TODAY「流通BMS導入企業数の調査(2024年12月時点)」(2025年)
  4. 4 出典:流通システム開発センター(GS1 Japan)「通信制御手順」
  5. 5 出典:流通システム開発センター(流通BMS協議会)「通信基盤関連の標準」
  6. 6 出典:公正取引委員会「委託事業者の禁止行為」(2026年)

画像の出典元

  1. Businesswoman in office writing notes with documents and laptop, focused on analysis and productivity./Photo by Tima Miroshnichenko on Pexels

Photos provided by Pexels

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top