◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 流通BMSは、発注から支払までの6つの節目のメッセージと、JX手順など3種類の通信手順をそろえた業界標準です。
- 1980年に制定されたJ手順は伝送速度が2,400bps級で、固定電話網のIP化により前提としてきた環境が変わりつつあります。
- 移行の作業量は取引先ごとの運用差異と商品マスタの整備の状況で決まり、標準の項目と自社の項目の対応づけが中心の工程になります。
- 検討は、現状の把握、方式の比較、取引先への確認、体制の決定という4段階で進めると社内の合意が取りやすくなります。
目次

流通BMSとはどのような標準か
流通BMSとは、消費財の流通に関わる企業どうしが交わす発注や出荷、請求といったメッセージの形式と、その送受信の方法をそろえた業界標準です。取引先ごとに異なっていた仕様を共通の形へ寄せ、接続のたびに個別開発が発生する状態を減らす狙いがあります*2。対象となるのは、小売と、その取引先である卸売やメーカーとの間の取引が中心です。移行を考えるときは、自社のどの業務がこの標準の範囲に入るのかを見極めるところから始まります。
この呼び名は、やり取りする伝票の中身と、それを運ぶ道の両方を含みます。中身だけをそろえても、道が従来のままでは移行とは呼べません。逆に回線だけを新しくしても、項目の定義が取引先ごとに違えば個別開発は残ったままです。2つを同時にそろえる点が、この標準の要点にあたります。
標準が定めるメッセージは、取引の節目ごとに分かれています。発注、出荷、受領、返品、請求、支払という6つの節目が基本にあり、業態に応じた追加の仕様もあわせて公開されています*2。1つのメッセージには日付や数量、コードといった項目が定義されており、意味の取り違えが起きにくい形になっています。導入の作業は、この定義済みの項目に自社の項目を当てはめるところが中心になります。
従来のEDI(電子データ交換。企業間で伝票データをやり取りする仕組み)で長く使われてきたJ手順は、1980年に制定された通信手順です*3。伝送速度は2,400bps級にとどまり、件数が増えるほど1回の伝送に要する時間が延びます。回線は公衆電話網の交換接続を前提としており、つなぐたびに通信の料金が発生します。データ形式は固定長のテキストで、項目を1つ増やすだけでも送り手と受け手の双方に改修が生じます。
流通BMSはインターネット回線を前提に設計されています。通信手順としてはJX手順、ebXML MS、AS2の3種類が標準として整理されており、取引の規模や相手先の構成に応じて選びます*5。データ形式はXMLで、項目の意味が仕様書の側に定義されています。同じ回線で複数の取引先とつなげるため、相手が増えるたびに回線を足す形にはなりません。
仕様の管理が1か所に集まっている点も、従来との違いです。基本形の仕様と導入ガイドラインは継続して改訂され、対応づけに使うマッピングシートもあわせて公開されています4。導入した企業の数は半期ごとに公表されるため、社内で共有する際はどの時点の値かを添えると誤解が避けられます1。版が動くことを前提に、確認の手順を決めておくと後の負担が軽くなります。
従来の手順と流通BMSの違いは、回線、伝送速度、データ形式、仕様の管理という4つの観点で整理できます。稟議の場では、この4点を並べて示すと論点が絞れます。
| 観点 | 従来の通信手順 | 流通BMS |
|---|---|---|
| 回線 | 公衆電話網の交換接続 | インターネット回線 |
| 伝送速度 | 2,400bps級 | ブロードバンド回線に依存 |
| データ形式 | 固定長のテキスト | XML形式のメッセージ |
| 仕様の管理 | 取引先ごとの個別仕様 | 業界標準の版で管理 |
移行の検討で先に押さえる5点(順位の根拠:着手の順序と後工程への依存関係)
- 接続している取引先の一覧と、相手ごとの切替の希望時期をまとめます。相手先の予定が自社の計画の前提になるためです。
- 拠点ごとの回線の契約と、利用中の通信手順を1件ずつ確かめます。1980年に制定されたJ手順を使う接続が残っていれば、影響の範囲が広がります。
- 標準の項目と自社の項目の対応づけを作ります。対応づけに用いるマッピングシートは導入ガイドラインとあわせて公開されています。
- 商品と取引先のコード体系を整えます。ここが崩れていると受領の照合が止まり、請求と支払の突き合わせまで影響します。
- 並行稼働の期間と担当を決めます。2つの手順を同時に動かす間は確認の作業が二重になり、通常業務に上乗せされます。
移行が進む背景にある通信基盤と業務の変化
移行が進む背景には、通信基盤、取引先の都合、制度という3つの変化があります。固定電話網のIP化により、従来手順が前提としてきた交換接続の環境が変わりつつあります6。取引先から切替の打診が届く例も増えています。加えて、電子で授受した取引データの保存についても取扱いが定められています8。ただし移行の要否と時期は、取引先の方針と自社の回線構成によって変わる点に注意が要ります。
通信事業者は、固定電話網をIP網へ移行する取り組みを2024年に実施したと公表しています6。この移行にあわせて従来のディジタル通信モードは提供の形が変わり、当面の利用を続けるための補完策が用意されました。補完策の終了時期は「2027年頃を目途」という幅のある表現で示されており、確定した期日として扱うことはできません7。回線の契約内容によって影響の出方が異なるため、自社の契約を1件ずつ確かめる必要があります。
新規の申し込みの受付についても、2024年に終了した旨が公表されています*6。拠点を新たに増やす場合、従来と同じ構成で回線を追加できるとは限りません。拠点の統廃合や新設の予定がある企業ほど、検討を前倒しする理由を持ちます。回線の見直しと受発注の仕組みの見直しは、同じ時期に重なりやすい課題と言えます。
取引先からの要請という外圧も、移行の引き金になります。小売側が接続方式をそろえる方針を採ると、取引を続ける卸売やメーカーは相手の方式に合わせる判断を迫られます。1社との取引のために従来の手順を残せば、2つの仕組みを並行して抱えることになります。運用の負担は接続する取引先の数に比例して増えていきます。
制度の面では、電子取引でやり取りしたデータを電子のまま保存する取扱いが定められています8。受発注のデータを電子で授受している場合、その保存の方法が問われる場面があります。所管の官庁が公開する一問一答では、電子取引に該当する範囲と保存の要件が問答の形で整理されています8。税務上の判断は個別の事情で変わるため、原典の記述を確かめたうえで社内の方針を決めるのが安全です。
3つの変化はそれぞれ別の理由で起きていますが、対応の時期は重なります。回線の切替、接続方式の変更、保存方法の見直しを別々に進めると、同じ担当者に3回の負荷がかかります。移行の計画を立てる段階で、3つをひとまとまりの案件として扱うと重複した確認が減ります。予算の申請も1本にまとめられるため、社内の説明が通りやすくなります。
動かないという判断も選択肢の1つですが、その場合に起きることを整理しておく必要があります。取引先が切替を終えた後に自社だけが従来の手順を残せば、相手側に個別の仕組みを維持してもらう形になります。回線の構成が変われば、従来手順そのものが使えなくなる可能性もあります。判断の材料をそろえたうえで、時期を選ぶという構えが現実的です。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。
移行によって変わる業務範囲とシステム構成
移行で変わるのは、通信の部分だけではありません。発注データの受信から、出荷と受領の照合、請求と支払の突き合わせまで、受発注に連なる業務の全体が影響を受けます。データの形式が変われば、同じ画面で扱っていた項目の並びや桁数も変わります。基幹システムとの接続の作り方によって改修の範囲が決まるため、業務側とシステム側を同じ図の上で確かめる必要があります。
発注データの受信は、移行の入口にあたります。取引先から届いた発注を基幹システムへ取り込む部分で、従来は固定長のテキストを読み込んでいた処理を、XML形式の受け取りへ置き換えます。項目の意味が仕様の側に定義されているため、受け取った値の解釈を社内で決め直す手間は減ります。自社にしかない項目の扱いだけは、取引先と個別に決める作業が残ります。
出荷と受領の照合は、差異が表に出やすい部分です。出荷の実績と受領の実績を同じ項目でつき合わせることで、数量の違いや欠品の扱いが早い段階で分かります。従来は電話や紙で調整していた差異を、メッセージの上で処理する形へ変わります。運用そのものの変更を伴うため、現場の担当者への説明が欠かせません。
請求と支払の突き合わせでは、請求の明細と支払の消し込みを同じ番号でたどれるかが要点になります。伝票番号の付け方が取引先ごとに違えば、照合の自動化はそこで止まります。電子で授受したデータの保存の方法についても、制度上の取扱いを確かめておく必要があります*8。経理部門が関わる範囲であるため、情報システム部門だけで設計を決めることはできません。
基幹システムとの接続は、費用に直結する部分です。既存の受注システムと項目単位で連携させるため、内部のデータ構造に手が入ります。連携用の中間の仕組みを置く構成にすると、基幹側の改修を抑えられる代わりに、運用する部品が1つ増えます。どちらを選ぶかは、既存システムの保守の状況と改修の可否によって変わります。
通信手順の選択も構成に影響します。標準として整理されているのはJX手順、ebXML MS、AS2の3種類で、取引の件数や相手先の要求によって使い分けます*5。複数の取引先が別々の手順を求める場合、2つ以上の手順に対応する構成が要ります。自社に必要な構成は、取引先の一覧が固まってから決めると無駄がありません。
受発注に連なる業務の流れと、基幹システムとの接続点を整理すると次のとおりです。改修の見積もりは、この4か所のどこに手が入るかで大きく変わります。
流通BMS移行の進め方と社内で決めること
移行の進め方は、現行EDIの棚卸し、標準仕様と自社項目の対応づけ、本番切替までの段取りという3つの段階に分けられます。段階ごとに決めることが異なり、情報システム部門だけでは完結しません。取引先の選定と切替の時期は営業の部門、コードの整備は商品の部門というように、決める人を先に割り当てる必要があります。3つを同時に走らせると手戻りが増えるため、順序を守るほうが結果として早く終わります。
最初の段階は現行EDIの棚卸しです。取引先の一覧化から着手し、どの相手とどの手順でつないでいるかを1件ずつ並べます。続く回線と手順の確認では、拠点ごとの契約の内容と利用中の通信手順を突き合わせます。この2つが終わらないうちは、影響を受ける範囲も費用の見当も立ちません。
次の段階が標準仕様と自社項目の対応づけです。マッピングシートの作成では、標準の項目と自社の項目を1対1で並べ、対応しない項目の扱いを決めます*4。あわせてコード体系の整理を進め、商品と取引先のコードの持ち方をそろえます。ここで妥協すると、後の照合で合わない伝票が残り続けます。
3つめが、接続確認から本番切替までの段取りです。接続確認では取引先ごとに送受信と例外の動きを確かめ、想定どおりに届かない場合の手順も決めます。並行稼働では従来の手順と新しい手順を同時に動かし、双方の結果を突き合わせます。切替の当日については、元へ戻す判断の基準を先に決めておくと現場が迷いません。
進め方でつまずきやすいのは、棚卸しを省いて対応づけから始める形です。取引先の数と手順の種類が確定していない状態で項目の対応を決めると、後から例外が出て設計をやり直すことになります。1件でも見落とした接続があれば、切替の当日に伝票が止まります。棚卸しに時間をかけるほど、後の工程の見通しが立ちます。
社内で決めることは、大きく4点あります。対象とする取引先の範囲、切替の時期、費用を負担する部門、そして障害が起きたときの責任の分担です。いずれも情報システム部門の一存では決められません。稟議に上げる前にこの4点の合意を取っておくと、差し戻しが減ります。
3つの段階と、それぞれで進める作業を整理すると次のとおりです。社内の説明では、今どの段階にいるかを示すと議論が噛み合います。
移行でつまずきやすい論点とその備え
つまずきやすい論点は3つに絞られます。取引先ごとの運用差異、商品マスタとコード体系の不一致、そして並行稼働の期間に生じる体制の負荷です。いずれも標準の仕様を読むだけでは見えず、自社の取引の中身に踏み込んで初めて表に出ます。前の節が「何を決めるか」を扱ったのに対し、本節は「決めきれていないと何が起きるか」を対で扱います。
取引先ごとの運用差異は、標準に沿っていても残ります。標準は項目の意味と並びを定めますが、任意の項目をどこまで使うか、締めの時刻を何時に置くか、返品をどのメッセージで扱うかは相手の運用によって変わります。3社と接続すれば3通りの運用が並ぶ前提で設計する必要があります。相手の数だけ確認の往復が発生するため、聞き取りの様式を先に作っておくと手戻りが減ります。
差異の吸収先を決めないまま個別の分岐を足していくと、保守が重くなります。取引先が1社増えるたびに条件分岐が増える作りでは、改修のたびに全件の確認が要ります。自社側で吸収する範囲と、取引先へ合わせてもらう範囲を先に線引きしておくと、後の追加が軽く済みます。線引きの結果は文書に残し、次の担当者が同じ判断をたどれるようにします。
商品マスタとコード体系の整備は、移行の成否を分ける部分です。商品の識別コードや取引先コードの持ち方がそろっていないと、受領の照合で合わない伝票が積み上がります。照合が止まれば請求と支払の突き合わせも止まり、入金の遅れとして表に出ます。1件の不一致を人手でたどる作業は、件数が増えるほど現場の時間を奪います。
切替の当日に受発注が止まると、影響は自社にとどまりません。発注が届かなければ出荷が遅れ、店頭の欠品という形で取引先の売上にも及びます。この状態が長引くほど、取引の条件の見直しとして跳ね返ります。元へ戻す判断の基準と、電話や別の手段で受発注を続ける代替の手順を、切替の前に決めておく必要があります。
並行稼働の期間は、2つの手順を同時に動かすため確認の作業が二重になります。従来の手順で受けた発注と新しい手順で受けた発注が同じ内容かを突き合わせる作業が、通常業務に上乗せされます。担当者が1名の体制でこの期間を乗り切ろうとすると、休暇も取りにくくなります。期間の長さは取引先の数と社内の余力で決まるため、他社の例をそのまま当てはめることはできません。
備えとして効くのは、合意した内容を文書に残す習慣です。取引先とのやり取りで決めた項目の扱いや締めの時刻は、口頭のままだと担当者の交代で失われます。決めた内容、決めた相手、決めた時期という3点を1つの表にまとめておくと、後から入った担当者でも判断できます。
移行後の運用定着と体制づくり
移行は切替の日で終わりません。標準の版の改訂への追随、障害時の連絡経路と再送の判断、担当の分担とナレッジの引き継ぎという3つを、運用の仕事として定める必要があります。切替の直後は関わった担当者が事情を覚えていますが、1年もすれば人は入れ替わります。誰が見ても同じ判断ができる状態にしておくことが、移行の成果を保つ条件になります。
標準の版は改訂が続いており、基本形の仕様と導入ガイドラインが更新されます4。年に1度は公開されている資料を確認し、自社の運用に関係する変更があるかを見る担当を決めておきます2。導入した企業の数も半期ごとに公表されるため、取引先の動向を測る材料として使えます*1。改訂の内容が自社に無関係だと確かめた事実も、記録として残す価値があります。
障害時の連絡経路は、取引先ごとに1本決めておきます。送ったのに届かない、届いたが読めない、二重に届いたという3つの状況では、対応する相手も手順も変わります。夜間や休日にも受発注がある場合は、連絡が取れる時間帯もあわせて取り決めておきます。経路が決まっていないと、原因の切り分けより先に連絡先を探す時間が発生します。
再送の考え方は、事前に基準を決めておくべき部分です。同じ伝票番号のデータを再び送る場合、相手側で上書きになるのか2件として登録されるのかで結果が変わります。重複の受信を検知する仕組みを持たないと、二重の計上が請求まで残ります。送信の記録を保存し、いつ何を送ったかをたどれるようにしておきます。
担当の分担とナレッジの引き継ぎでは、対応づけの資料を最新の状態で残すことが要になります。マッピングの内容、取引先ごとの運用差異、過去に起きた不具合と対処という3点は、文書として残す価値が高い情報です。個人の記憶に依存した運用は、担当者が1人抜けただけで止まります。引き継ぎの時期を待たず、日々の対応の中で更新する形にしておくと負担が分散します。
運用の負担を測る目安として、取引先の数と扱うメッセージの種類の数を掛け合わせた組み合わせの数が使えます。この数が増えるほど、確認の手間と障害時の切り分けに要する時間が延びます。年に1度は数え直し、増減を記録しておくと体制の見直しの根拠になります。数字で示せると、増員や委託の判断も社内で通りやすくなります。

自社の状況に合わせた移行の検討ステップ
自社の状況に合わせた検討は、現状の把握、方式の比較、取引先への確認、体制の決定という4つの段階で進めます。順序を入れ替えると、決まっていない前提の上で方式を選ぶことになり、後から覆ります。とりわけ取引先への確認は、方式を決める前に済ませておくほど選択肢が絞れます。移行の要否と時期は取引先の方針と自社の回線構成で変わるため、一律の答えを外から持ち込むことはできません。
現状の把握では、取引先と手順を数え上げます。接続している相手の数、利用中の通信手順の種類、拠点ごとの回線の契約という3点を並べると、影響の範囲が見えます。1980年に制定されたJ手順を使っている接続が残っていれば、通信基盤の変化の影響を受けやすい部分です*3。数え上げた結果は一覧の形にして、後の工程で何度も参照できるようにします。
方式の比較では、自社構築と外部サービスの利用を同じ軸で並べます。自社構築は仕様の自由度が高い代わりに、通信手順の実装と保守の責任を自社が持ちます。外部サービスの利用は接続の共通の部分を任せられますが、標準の項目と自社の項目の対応づけは自社に残ります。どちらが向くかは、社内に通信とデータ変換の知見があるかどうかで分かれます。
取引先への確認では、時期と条件を先に聞きます。確認しておきたいのは、切替の希望する時期、利用する通信手順、扱うメッセージの種類、コード体系の指定、接続確認の進め方という5点です。相手ごとに回答が違う前提で聞き取りの様式を設計すると、後の設計が楽になります。回答が集まる前に方式を固めると、条件に合わずに選び直すことになります。
体制の決定では、担当と責任を割り当てます。内製で進める場合に要る知識は、通信手順とセキュリティ、XML形式のデータ変換、基幹システムの改修、商品マスタとコード体系の運用、受発注から請求までの業務理解という5つの領域にわたります。1人でこの5領域を賄える人材は限られ、専任を置けない企業では通常業務との兼務になります。兼務のまま切替の時期を迎えると、障害への対応が後回しになります。
外部のパートナーに任せる場合との違いは、失敗したときの戻し方にも表れます。内製では、切替の当日に伝票が止まったときの切り分けを自社だけで進めることになります。委託する場合は、標準の版の改訂への追随や取引先ごとの差異への対応を、あらかじめ役割として決められます。難しいから任せるのではなく、止まったときの影響を小さくするための選択として比べるのが実務的です。
検討の順序を整理すると次のとおりです。4つの段階のどこまで進んだかを示せると、社内の議論が前に進みます。
よくある質問
流通BMSへの移行はいつまでに終える必要がありますか
一律の期限は定まっていません。移行の時期は取引先の方針と自社の回線構成によって変わります。従来のディジタル通信モードの補完策については「2027年頃を目途」という幅のある表現で終了時期が示されており、確定した期日として扱うことはできません。自社の回線の契約内容を1件ずつ確かめ、取引先の切替の予定とあわせて時期を決めるのが現実的です。
移行にはどのような費用が発生しますか
費用は大きく4つに分かれます。インターネット回線と通信の仕組みにかかる費用、基幹システムの改修の費用、標準の項目と自社の項目の対応づけにかかる工数、そして接続確認と並行稼働の期間の運用の費用です。金額は接続する取引先の数と、対応づけが必要な項目の数によって変わります。見積もりの前に現行EDIの棚卸しを終えておくと、金額の幅が狭まります。
取引先が1社だけの場合でも移行は必要ですか
接続先が1社であっても、その相手が切替を進めるなら検討の対象になります。1社のために従来の手順を残すと、相手側に個別の仕組みを維持してもらう形になります。回線の構成が変われば、従来手順そのものが使えなくなる可能性もあります。相手の予定を聞き取ったうえで、自社の回線の契約とあわせて判断するとよいでしょう。
既存の基幹システムは入れ替えが必要ですか
入れ替えが前提になるわけではありません。既存の受注システムと項目単位で連携させる方法のほか、連携用の中間の仕組みを置いて基幹側の改修を抑える構成も選べます。中間の仕組みを置く場合は、運用する部品が1つ増える点が負担になります。既存システムの保守の状況と、改修が可能かどうかで選び方が変わります。
移行後も続く運用の作業にはどのようなものがありますか
主なものは3つあります。標準の版の改訂への追随、障害が起きたときの連絡と再送の判断、そして対応づけの資料の更新と引き継ぎです。基本形の仕様と導入ガイドラインは改訂が続くため、年に1度は公開資料を確認する担当を決めておきます。取引先の数と扱うメッセージの種類の数を掛け合わせた組み合わせの数が、運用の負担の目安になります。
- *1 出典:一般財団法人流通システム開発センター(GS1 Japan)流通システム標準普及推進協議会「流通BMS協議会 公式サイト(導入企業数・標準仕様の最新版の告知)」(2025年) 経路
- *2 出典:一般財団法人流通システム開発センター(GS1 Japan)「標準化活動『流通BMS』(定義および基本形の版の公開履歴)」(公表年の記載なし) 経路
- *3 出典:一般財団法人流通システム開発センター(GS1 Japan)「EDI(電子データ交換)通信制御手順(J手順・H手順および現行手順の解説)」(公表年の記載なし) 経路
- *4 出典:一般財団法人流通システム開発センター(GS1 Japan)流通BMS協議会「流通BMS標準仕様 導入ガイドライン(マッピングシート等)」(2025年) 経路
- *5 出典:一般財団法人流通システム開発センター(GS1 Japan)流通BMS協議会「流通BMS標準仕様 通信基盤関連の標準(通信プロトコル利用ガイドライン等)」(公表年の記載なし) 経路
- *6 出典:東日本電信電話株式会社「INSネットの新規申込受付・提供終了について」(2024年) 経路
- *7 出典:西日本電信電話株式会社「固定電話(加入電話・INSネット)のIP網移行『INSネット』をご利用の事業者さまへ」(公表年の記載なし) 経路
- *8 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】」(公表年の記載なし) 経路
画像の出典元
- Abstract view of a digital circuitry with glowing multicolor/Photo by Pachon in Motion on Pexels
- Detailed shot of Ethernet cables connected to server ports h/Photo by Brett Sayles on Pexels
- Modern server rack with blue lighting in a secure data cente/Photo by panumas nikhomkhai on Pexels