流通BMS仕様のメッセージ｜種類と通信手順の全体像

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

B2B EC-COLUMN

流通BMSとは｜消費財流通のEDI標準としての位置づけ

流通BMSとは、消費財の流通における企業間の受発注データについて、メッセージの形式と通信の手順を定めたEDIの標準です¹。仕様はメッセージ仕様と通信仕様の2つの層に分かれ、通信手順は3種類が用意されています⁷。標準仕様は基本形・商品マスタ・百貨店版という系列で公開され、導入ガイドラインは概要編・業界編・システム編の3編にまとめられています³⁵。まず押さえたいのは、この二層と系列の関係です。

従来のEDIは、業界や取引先ごとの個別仕様が積み上がってきました。データは固定長で、通信は電話回線を前提とした手順が中心でした。取引先が増えるほど、送受信の窓口と変換処理を別々に抱える負担が生じます。受発注の締め時刻に合わせて回線を占有する運用も、負担として残りました。標準化の出発点は、この個別対応の重さにあります。

標準の対象は加工食品や日用品の取引から始まり、生鮮や百貨店の取引へ広がってきました。標準仕様は基本形・商品マスタ・百貨店版の3系列で公開され、業界の事情に応じた追加が重ねられています³。自社の取引がどの系列に当たるのかを、最初に確かめておきたいところです。

レガシーEDIとの違いは、データ形式と通信の土台の両方に及びます。メッセージはXML（項目名で意味を示す文書形式）で表現され、通信はインターネット回線を用いる手順へ置き換わりました⁷。固定長の桁位置を数えて項目を切り出す読み方から、項目名で意味を追う読み方へ変わったと言えます。

回線側の事情も移行の判断に関わります。従来のEDIが依存してきた回線については、新規申込受付の終了と提供終了の予定が2024年の報道発表で示されました¹²。回線の切り替えとEDIの刷新を同時に迫られると、受発注が止まる期間を短く抑えることが難しくなります。

策定と改訂は、流通の標準化を担う団体が業界の参加者とともに進めています¹。原典では、消費財流通の企業間取引で唯一の標準となることを目標に策定した、と述べられています¹。標準に準拠した企業とメッセージの一覧も公開されており、引用する際は参照した時点を添えるのが安全でしょう⁶。

対応の要否や時期は、取引先の方針によって異なります。取引先が採用していない系列やバージョンを先に作り込むと、手戻りが発生します。接続先ごとの採用状況を確かめ、そのうえで自社の設計を決める順序が現実的です。数の少ない接続先から着手すれば、確認の負荷も分散できます。

流通BMS仕様の全体構成｜メッセージ仕様と通信仕様の二層

流通BMS仕様は、メッセージ仕様と通信仕様という2つの層で構成されています²。メッセージ仕様が取引文書の項目と形式を定め、通信仕様が接続の手順とセキュリティを定めます⁷。層が分かれているため、同じメッセージ設計のまま、取引先ごとに異なる通信手順を選べます。読む順序としては、標準仕様の系列を確かめ、メッセージ仕様、通信仕様、導入ガイドラインへ進む流れが分かりやすいでしょう⁵。

メッセージ仕様が定めるのは、業務ごとの電子取引文書の中身です。XMLスキーマ（文書の構造を機械が検証できる定義）と、メッセージ別の項目定義が対になっています²。項目には必須と任意の2つの区分があり、任意項目の使い方は取引先との取り決めに委ねられます。取り決めの範囲を先に決めておくと、設計の判断が速くなります。

通信仕様が定めるのは、接続の手順と守るべきセキュリティの要件です。サーバ間の手順は2種類、クライアントとサーバの手順は1種類が示されています⁷。サーバ間手順の基になる仕様は、片方が2005年、もう片方が2007年に公表されたもので、証跡の残し方に違いがあります⁹¹⁰。

標準仕様は1つの文書ではなく、系列と版に分かれて公開されています。基本形・商品マスタ・百貨店版といった系列ごとに版が並び、それぞれをダウンロードして参照できます³。版によって対象業務と項目が異なるため、社内の設計書には引用した系列と版を必ず書き残してください。

仕様書だけでは埋まらない判断は、導入ガイドラインが補います。概要編・業界編・システム編の3編に分かれ、標準に沿った使い方の考え方もまとめられています⁴⁵。仕様の条文と運用上の勘所を、別の文書で読み分ける前提と考えてよいはずです。

層をまたいだ独自の取り決めは、後の負担として跳ね返ります。通信手順の都合でメッセージの項目を削る設計にすると、取引先が増えるたびに個別の変換が積み上がります。二層の役割を保ったまま、どちらの層で解決すべき課題かを切り分けてください。切り分けの記録が残れば、次の接続先では同じ検討を繰り返しません。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

業務プロセス別にみる標準メッセージの種類

標準メッセージは、発注・出荷・受領・返品・請求・支払という6つの業務に対応する形で整理されています²。基本形がこの並びを担い、生鮮や百貨店の取引では業界版で追加のメッセージが用意されます³。メッセージの種数は版によって異なるため、自社が引用する版を明示したうえで数えることが前提です。まずは業務の流れとメッセージの対応を押さえるところから始めましょう。

発注から受領までは、3つのメッセージが順に動きます。発注で注文の内容を伝え、出荷で入荷前に明細を渡し、受領で入荷の実績を返す流れです²。出荷のメッセージが先に届くため、入荷検品は明細との突き合わせから始められます。

受領のメッセージを使うかどうかで、後工程の手間が変わります。受領の実績が電子で戻らない場合、請求の照合は人手の突き合わせに残ります。差異の調査が月次の締めに集中し、支払の期日に間に合わない事態も起こり得ます。

請求・支払・返品のメッセージは、代金の確定に関わります。請求で代金の内容を伝え、支払で支払の金額を示し、返品で戻す商品の明細を渡します²。受領の実績を基に請求を組む運用であれば、差異は発生した時点で見つけられます。

業界版の追加は、その業界の商習慣を写したものです。生鮮の取引では計量や値決めに関わる情報が、百貨店の取引では固有の取引形態に対応する記述が加わります³。自社の取引がどちらに当たるかで、読むべき仕様の範囲が変わります。

メッセージの種類を数えるときは、出典の版と参照時点をそろえてください。標準に準拠した企業とメッセージの一覧も公開されており、掲載の件数は時点によって変わります⁶。社内資料へ転記する際に参照した時点を併記しておけば、後の確認が楽になります。

メッセージの構造とデータ項目の読み解き方

メッセージを読み解く作業は、XMLスキーマとメッセージ別の項目定義を往復する作業です²。スキーマが文書の構造を規定し、項目定義が個々の項目の意味と桁、必須か任意かの区分を示します。自社の基幹システムとの対応は、マッピングシートに1項目ずつ落とし込みます⁴。ここを曖昧にしたまま接続すると、照合の合わない明細が本番で表面化します。

スキーマと項目定義の役割は重なりません。スキーマは要素の並びと繰り返しの回数を機械が検証できる形で示し、項目定義は業務上の意味を言葉で示します²。形式が通っても意味が違えば、相手のシステムでは別の値として扱われます。

必須項目と任意項目の2区分は、設計の分かれ目になります。必須は取引先を問わず埋める前提で、任意は取り決めに応じて使う項目です。任意項目に自社独自の意味を持たせると、標準に沿った使い方から外れます。結果として、取引先側で個別の読み替えが必要になります⁴。

マッピングシートは、標準項目と自社項目の対応を1対1で確かめる道具です。桁数・区分値・単位の3点は、取り違えが起きやすい箇所でしょう。基幹側の桁が足りない項目は、切り捨てではなく設計の見直しで対応してください。

商品と事業者を識別するコードの扱いも、早い段階で決めておきたい論点です。事業者の識別には13桁のコードが用いられ、商品にも共通のコード体系が使われます²。社内の独自コードを併用している場合は、変換表とその維持の担当を決めておく必要があります。

この読み解きを内製で進めるには、3つの領域の知識がそろっている必要があります。XMLスキーマを読める技術者、基幹システムの項目定義を把握している担当者、取引先との商習慣を知る業務側の担当者です。どれか1つが欠けると、設計の判断が止まります。

取り違えの代償は、本番稼働の後に現れます。区分値の解釈が違えば受領の照合が合わず、請求差異の調査に人手が割かれます。差異の原因が仕様の読み違いだと分かるまで、取引先との往復が続くことになります。

通信手順の種類と選び分けの考え方

通信手順は3種類が示されており、選び分けは接続の形と向く場面の2点で整理できます⁷。サーバ間の接続にはebMSとAS2の2つ、クライアントとサーバの接続にはJX手順が当たります。ebMSの基になる仕様は2007年、AS2の基になる仕様は2005年に公表されたものです⁹¹⁰。取引先の指定と自社のデータ量から、どれを備えるかを決めます。

サーバ間の手順は、常時稼働する受信の窓口を前提とします。相手からの送信をいつでも受け取れる状態を保つため、サーバの運用と証明書の管理が欠かせません。AS2では受信の通知を電子署名付きで返す仕組みが定められており、届いたことの証跡を残せます⁹。

JX手順は、クライアント側から接続を起こす形の手順です。受信の窓口を常時開けておく必要がないため、取引先の数が少なく送受信の頻度が低い場面に向きます⁷。その代わり、送受信の起動を自社側で管理する運用が必要になります。

選び分けの判断材料は、取引先の指定、データ量、運用体制の3点です。取引先が手順を指定している場合は、その指定が出発点になります。指定がない場合は、送受信の頻度と1回あたりの明細件数から、サーバ間の接続が必要かを見極めます。

手順を後から追加する場合の手間は小さくありません。証明書の発行と交換、接続先の情報の申請、テストの実施が、取引先ごとに繰り返し発生します。最初の設計で2つ目の手順を足す余地を残しておけば、後の追加は軽くなるでしょう。

個別の取引先がどの手順を指定しているかは、公開資料では確かめられません。指定の内容は見直されることもあるため、取引先からの案内を都度確認してください。伝聞で手順を決めると、テストの段階で作り直しになります。

標準外運用とWeb-EDIで生じる注意点

標準外の運用は、相手方の手間として現れます。標準に沿った使い方では、項目の意味を変えずに用いることが前提とされています⁴。Web-EDIを併用する場合の考え方は、第1.0版として2012年に示されました⁸。加えて、電子取引データの保存では、取引年月日・取引金額・取引先の3項目で検索できる状態が求められます¹¹。

独自解釈が生まれる場所は、任意項目と区分値の周りです。空いている項目に自社の管理情報を詰める運用は、受け手に個別の読み替えを強います。取引先が同じことを別の相手からも求められれば、標準化の効果はその分だけ薄まります。

標準外の取り決めは、担当者の交代で引き継ぎが難しくなります。仕様書に書かれていない約束は、口頭やメールに散らばりやすいものです。取り決めを残す場所と、更新の担当を決めておくことが備えになります。

Web-EDIは、画面から入力できる手軽さと引き換えに、受け手の手作業を残します。画面の入力だけに寄せると、相手方の基幹システムへ自動で取り込む余地がありません。併用する場合は、標準のメッセージをファイルとしてやり取りできる道を残す考え方が示されています⁸。

取引データの保存要件も、仕様の一覧には書かれていない論点です。電子で受け取った取引情報は電子のまま保存し、検索できる状態を保つ扱いになります¹¹。要件は改正が入るため、参照する際は最新版の取扱いを確かめてください。

保存の設計は、EDIの設計と切り離せません。受領や請求のデータを基幹システムの中だけに持つと、保存の要件を満たす検索が組めない場合があります。どのデータをどこに保存するかを、接続の設計と同時に決めておきたいところです。

標準外運用の代償は、取引先の数に比例して増えます。相手ごとの変換と例外処理が積み上がれば、改修のたびに影響範囲の確認が必要になります。標準の範囲で収める判断が、後年の改修費を抑えます。

流通BMS対応を進める手順とチェックポイント

流通BMS対応は、取引先の棚卸し、項目マッピング設計、接続テストの3段階で進めます。棚卸しでは採用メッセージの確認と通信手順の確認を先に済ませます³⁷。設計では基幹システムの項目定義とコード変換表の整備が中心になります⁴。最後の接続テストでは、疎通の確認から本番切替の並行稼働へ進みます。

取引先の棚卸しは、接続先ごとに1枚の台帳を作る作業です。採用メッセージの確認では、対象の業務と引用する版を控えます。通信手順の確認では、指定された手順と証明書の要件を控えます⁷。

項目マッピング設計では、標準項目と自社項目の対応を確定させます。基幹システムの項目定義を洗い出し、桁数と区分値の差を1件ずつ埋めます。コード変換表の整備では、独自コードと標準のコード体系を突き合わせます²。

接続テストは、2段構えで考えると漏れが減ります。疎通の確認では、送受信と再送、異常時の戻りの動きを確かめます。本番切替の並行稼働では、従来の手順と併走させ、明細の差異が出ないことを見ます。

この3段階を内製で回すには、3者の関与が要ります。仕様を読む技術者、基幹システムの改修を担う担当者、取引先の窓口に立つ業務側の担当者です。工数の目安は取引先の数と手順の数で変わるため、公表資料から一律の数値は示せません。

外部の支援を使う場合との違いは、経験の蓄積の差に表れます。内製では、版の読み分けや証明書の運用を初回から学ぶ必要があります。支援を受ければ、取引先ごとの差異の吸収と切替の段取りを、既に整った手順に載せられます。[要追加：FSOL実績]

段取りで避けたいのは、回線の終了とEDIの刷新を同時に迎える事態です。従来の回線は、新規申込受付の終了と提供終了の予定が2024年の報道発表で示されています¹²。受発注が止まるリスクを下げるには、切替の順序を先に決めておく判断が要ります。

よくある質問

流通BMSへの対応には、どのくらいの期間を見ておけばよいですか

期間の目安を示した公表資料は確認できないため、一律の数値は示せません。作業量は、取引先の棚卸し、項目マッピング設計、接続テストの3段階それぞれで、接続先の数と通信手順の数に応じて変わります。まず接続先ごとの採用メッセージと版を台帳にまとめ、そのうえで自社の体制に合わせて工程を積み上げる進め方が確実です。

既存のレガシーEDIと流通BMSを併存させることはできますか

併存は可能ですが、変換処理を二重に持つ運用の負担が残ります。従来の回線については、新規申込受付の終了と提供終了の予定が2024年の報道発表で示されています¹²。併存の期間をあらかじめ区切り、どの取引先をいつ切り替えるかを決めておくと、回線側の期限に追われずに済みます。

取引先ごとに指定される通信手順が違う場合はどうなりますか

仕様がメッセージ仕様と通信仕様の2層に分かれているため、メッセージ設計を共通にしたまま複数の手順を備えられます²。ただし、サーバ間の接続を増やすほど証明書の管理と受信窓口の運用が増えます。1つ目の手順を作る段階で2つ目を足す余地を残しておくと、追加の負担が軽くなります。

Web-EDIの画面だけで取引先とやり取りしても問題ありませんか

画面入力に寄せると、受け手側に手作業が残り、基幹システムへ自動で取り込む余地がなくなります。併用する場合の考え方は、第1.0版として2012年に示されています⁸。標準のメッセージをファイルとしてやり取りできる道を残しておけば、相手方の選択肢を狭めずに済みます。

請求や支払のデータは、どのように保存すればよいですか

電子で受け取った取引情報は電子のまま保存し、検索できる状態を保つ扱いになります¹¹。検索の要件として、取引年月日・取引金額・取引先の3項目が挙げられています。要件は改正が入るため、参照する際は最新版の取扱いを確かめ、保存先の設計を接続の設計と同時に決めてください。

1. 1　出典：GS1 Japan（一般財団法人流通システム開発センター）「標準化活動｜EDI（電子データ交換）｜流通BMS」（参照時点）　経路
2. 2　出典：流通BMS協議会（流通システム標準普及推進協議会）「流通ビジネスメッセージ標準（流通BMS）｜流通BMS標準仕様」（参照時点）　経路
3. 3　出典：流通BMS協議会（流通システム標準普及推進協議会）「流通BMS標準仕様（基本形・商品マスタ・百貨店版の各版とダウンロード）」（参照時点）　経路
4. 4　出典：流通BMS協議会（流通システム標準普及推進協議会）「標準仕様に沿って使う」（参照時点）　経路
5. 5　出典：流通BMS協議会（流通システム標準普及推進協議会）「導入ガイドライン（概要編・業界編・システム編）」（参照時点）　経路
6. 6　出典：流通BMS協議会（流通システム標準普及推進協議会）「標準準拠企業・メッセージ一覧」（参照時点）　経路
7. 7　出典：GS1 Japan（一般財団法人流通システム開発センター）「標準化活動｜EDI（電子データ交換）｜通信制御手順」（参照時点）　経路
8. 8　出典：流通BMS協議会（流通システム標準普及推進協議会）「流通BMSにおけるWeb-EDIガイドライン 第1.0版」（2012）　経路
9. 9　出典：IETF（Internet Engineering Task Force）「RFC 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)」（2005）　経路
10. 10　出典：OASIS「OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features（OASIS Standard）」（2007）　経路
11. 11　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（参照時点）　経路
12. 12　出典：東日本電信電話株式会社（NTT東日本）「INSネットの新規申込受付終了・提供終了について（報道発表）」（2024）　経路