2026.10.20 ERP

流通BMSとは：XMLメッセージの構造とJX手順・ebXML MS・AS2の違い、JCA手順からの移行を実装目線で解説

流通BMS（流通ビジネスメッセージ標準）とは、スーパーやドラッグストアなどの小売と、卸・メーカーの間でやり取りする発注・出荷・受領・返品・請求・支払のデータを、XMLの書式とインターネットの通信手順で標準化したEDIの規格です。この記事では、SBDH・メッセージ層・業務データ層からなるXMLの構造、JX手順・ebXML MS・AS2の違いと推奨パラメータ、JX手順のクライアントをPythonで書く例、データ量が増えるといったデメリット、JCA手順からの移行までを、流通BMS協議会の公開資料をもとに整理します。

まとめ：流通BMS対応で先に決める通信手順・メッセージの版・変換の置き場所

流通BMSへの対応で決めることは3つです。1つ目は通信手順で、サーバーを常時動かすebXML MSかAS2か、小売のサーバーへ取りに行くJX手順のクライアントかを、小売の指定に合わせて決めます。2つ目は使うメッセージの種類と版で、基本形Ver2.2系のどの資料に合わせるかを書面で取り決めます。3つ目はXMLと自社の受発注データを変換する処理の置き場所です。

接続先の小売が数社で、1回の取引データが10MBに届かない規模なら、ASP・SaaS型のサービスへ接続すれば足ります。接続先が増え、受注を基幹システムへ直接流したくなった段階で、JXクライアントと変換処理を受発注システムの一部として作ります。

流通BMSの定義と、メッセージ・通信手順・業務運用の3層で決まっている範囲

流通BMSは1つの仕様書ではなく、データの書式、通信のやり方、業務の進め方をまとめた標準群です。

流通BMSが標準化する範囲：卸・メーカーと小売の間の6業務と28種のメッセージ

流通BMS協議会の標準仕様ページによれば、流通BMSは消費財流通の標準となることを目標に策定された、メッセージと通信プロトコル・セキュリティのEDI標準仕様です。現在の対象は卸売（またはメーカー）と小売の間の取引で、2007年4月の基本形Ver1.0は、発注・出荷・受領・返品・請求・支払の6業務を8種のメッセージで定義するところから始まりました。

その後、値札・出荷梱包・発注予定・納品提案などのメッセージが加わり、協議会の流通BMS入門講座の資料（2020年版）では、基本形が28種、百貨店版が27種と数えられています。標準化の対象は、XMLのメッセージ、通信手順（ebMS・AS2・JX）、インターネットのTCP/IPを使う通信基盤、商品のGTINと企業・事業所のGLNというコード体系、そして運用ガイドラインに書かれた業務プロセスの5つです。

基本形Ver1.0から2025年のVer2.2.2まで、版ごとに追加された機能の差分

版は業界の要望（チェンジリクエスト）を受けて上がります。実装で押さえるべき差分は次のとおりです。

版	公開	主な変更
基本形Ver1.0	2007年4月	6業務・8種で開始
基本形Ver1.3	2009年10月	基本形と生鮮を統合
基本形Ver2.0	2018年11月	軽減税率・請求鑑を追加
基本形Ver2.1	Ver2.0の後	インボイス制度に対応
基本形Ver2.2	2025年4月	値引・値引依頼を新設

Ver2.2の値引メッセージは、2025年2月に日本加工食品卸協会が出したチェンジリクエストから生まれたと、協議会の「V2.2関連資料の改訂について」に書かれています。それまでは返品メッセージを流用する非標準の運用が散見されていました。協議会のトップページでは、再訂正版の基本形Ver2.2.2が2025年7月15日に公開され、2026年10月20日時点でこれが最新の掲載です。「Ver2.2」と言われたら、どの訂正版に合わせるかまで確認します。

卸・メーカーの導入企業数21,600社以上という推計の読み方と社名公開227社の差

普及の度合いは、協議会が半年ごとに出す推計で追えます。第28回の導入企業数推計では、2025年6月1日時点で流通BMSを導入している卸・メーカーは21,600社以上で、半年で700社以上増えました。推計は、通信ソフトのベンダー4社の出荷本数と、ASP・SaaS事業者4社の接続数から重複を引いて出した下限値です。同じ資料は、社名を公開している卸・メーカーが227社にとどまり、この数を導入企業数として紹介すると普及を実際より少なく見せる、と注意しています。

流通BMSのフォーマット：SBDH・メッセージ層・業務データ層のXML構造を読む

流通BMSのフォーマットはXMLで、XMLスキーマは「SecondGenEDI XMLスキーマ」と呼ばれます。スキーマ本体は協議会のXMLスキーマ関連ページから利用登録をして入手する仕組みで、2026年10月時点の受付は基本形Ver2.2・商品マスタVer1.0・百貨店版Ver2.2です。

発注メッセージの入れ子構造と、統一伝票の見出し・取引・明細との対応関係

筑波大学のディスカッションペーパー No.1255（2010年3月）は、協議会のXMLテクニカルガイドを引用しながら、メッセージが3つの層に分かれると説明しています。最上位のSBDH（Standard Business Document Header）は国連CEFACTの標準ヘッダーで、送受信に必要な情報を格納する層です。その下のメッセージ層には取引の件数など整合性の確認に使う情報が入り、さらにその下に業務ごとに異なる業務データ層が入ります。発注メッセージの骨格は次のようになります。

<sh:StandardBusinessDocument>
  <sh:StandardBusinessDocumentHeader>   SBDH層：送信者・受信者・文書種別
  <common:message>                       メッセージ層：取引の件数などの整合性情報
    <order:listOfOrders>                 業務データ層：発注ヘッダー（発注企業・支払企業）
      <order>                            取引ヘッダー（取引番号・取引先・合計金額）
        <lineItem>                       取引明細（明細番号・商品コード・数量・単価）
        <lineItem> …                     明細を繰り返す
      <order> …                          取引（伝票）を繰り返す

発注ヘッダーが伝票の束、取引ヘッダーが伝票1枚、取引明細が伝票の行にあたり、チェーンストア統一伝票の見出しと明細をそのまま入れ子にした形です。

名前空間urn:SecondGenEDIと約70ファイルのXMLスキーマ管理

同じ論文によれば、発注メッセージのスキーマは名前空間urn:SecondGenEDI:order:Japan:1に属し、共通部品はurn:SecondGenEDI:common:Japan:1から取り込みます。1つのメッセージには約200の項目があり、その定義に約70個のスキーマファイルが関わります。実装で詰まりやすいのは、SBDH層を定義するStandardBusinessDocumentHeader.xsdと、メッセージ層以下を定義するListOfOrders.xsdが互いに参照し合わず、ルートスキーマが2つある点です。

論文は解決策として、SBDH側からもう一方を取り込むスキーマを作る方法と、2つのスキーマで順に検証する方法を挙げています。受信処理は、SBDHを外してから業務データ側を検証する2段構えにしておくと、エラーがどちらの層で起きたかを切り分けられます。

コードリストの値を独自に変えられない項目と、処理種別など3つの例外項目

入門講座の資料は、コードリストがある項目は値の意味を変えたり独自の値を入れたりできず、例外は項目番号184「処理種別」、187「返品・値引理由コード」、191「照合結果」の3項目だけだと明記しています。処理種別に定番と特売の区別や返品の指示を入れるのも標準外です。変換処理では、自社コードへの読み替え表を取引先ごとではなく、標準のコードリストに対して1本だけ作ります。

JX手順・ebXML MS・AS2の違い：プル型とプッシュ型で変わるサーバーの持ち方

3つの通信手順で、運ぶXMLは同じです。協議会の通信基盤関連の標準ページで配布している「インターネットを利用した通信プロトコル利用ガイドライン第2.0版」（平成20年度経済産業省委託事業）に、3手順の仕様と推奨パラメータがまとまっています。

3つの通信手順を方式・起点・向く規模・証明書で比べた一覧表と選び方の基準

手順	方式	向く規模	証明書
ebXML MS 2.0	サーバー同士・プッシュ	取引量の多い企業	サーバーとクライアント
AS2（RFC 4130）	サーバー同士・プッシュ	海外取引もある企業	サーバーと署名用
JX手順	クライアント起点・プル	取引量の少ない企業	サーバー側のみ

ebXML MSはOASISのebXML Message Service 2.0、AS2はIETFのRFC 4130が元の仕様で、受け手もサーバーを常時動かします。JX手順はクライアントが小売のサーバーへ取りに行く方式で、ガイドラインは「取引量が少なく、低コストでインターネットEDIを実現したい企業向け」と位置づけています。第28回の推計資料が示す、サーバー同士で接続する形の目安は「1取引明細が10MB（約1万明細）を超える場合」という条件です。

ebXML MSとAS2の推奨パラメータ：同期応答・再送2回・3分間隔・重複検出

ガイドラインの「EDI通信パラメータ参考情報」は、取引先ごとに相談していた設定値をできるだけ固定する目的で作られています。

応答：ebXML MSは受領確認を同期応答で返し、AS2は受信確認のMDNを同期で返す。応答への署名はどちらも無し
再送：再送回数2回・再送間隔3分が推奨値。ebXML MSは重複検出時間15分も推奨値として示す
重複検出：ebXML MSは必須、JX手順はあり、AS2は推奨とする
識別子：通信プロトコル情報IDは「調達側GLN-供給側GLN-連番3桁-ptc」の形式
文書形式：ebXML MSとJX手順はSecondGenEDIを指定し、AS2では設定しない

AS2の署名アルゴリズムはRSA-SHA-1と書かれていますが、2009年前後の値なので、署名方式やTLSの版は相手と現在の値で取り決め直します。AWSでAS2のサーバーを持つ場合の設定は、AWS Transfer FamilyのSFTP・AS2の料金とエンドポイント設計の記事で扱っています。

JX手順の3メソッドの役割：文書の送信・受信・受信確定の処理の違い

JX手順は、SOAP-RPCをHTTPで送る、3つのメソッドだけの単純な手順です。PutDocumentは文書を1つサーバーへ送り、GetDocumentはサーバーにある自分宛ての未取得文書のうち最も古いものを1つ取り、ConfirmDocumentは取得した文書のmessageIdを返して受け取ったことを通知します。ガイドラインに載っている送信要求の例は次の形です（dataはBase64の文書本体で、ここでは省略しています）。

POST /SOAP-RPC HTTP/1.1
Host: edi.seller.co.jp
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server/PutDocument"

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Header>
  <MessageHeader xmlns="http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server">
   <From>cliuri.co.jp</From><To>svruri.co.jp</To>
   <MessageId>[email protected]</MessageId>
   <Timestamp>2004-03-13T12:38:14</Timestamp>
  </MessageHeader>
 </soap:Header>
 <soap:Body>
  <PutDocument xmlns="http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server">
   <messageId>[email protected]</messageId>
   <data>（Base64の文書本体）</data>
   <senderId>4912345000019</senderId><receiverId>4969951110016</receiverId>
   <formatType>SecondGenEDI</formatType><documentType>Order</documentType>
  </PutDocument>
 </soap:Body>
</soap:Envelope>

documentTypeには、発注ならOrder、請求ならInvoiceのように決まった名前が入ります。同じmessageIdを2回送るとサーバーはPutDocumentResultにfalseを返し、これが二重送信の防止になります。

JX手順クライアントの実装：文書の受信から保存後の受信確定までの処理順序

卸・メーカー側で最も多いのは、小売のJXサーバーから発注を取りに行くクライアントです。市販の通信ソフトを使う場合も、仕組みを知っていれば障害時のログを読めます。

PythonのJX実装例：SOAPヘッダとSOAPActionの組み立て

次は、標準ライブラリだけでGetDocumentを呼び、文書を保存してからConfirmDocumentを返すPythonの例です。MessageIdは「ドメイン内で一意の文字列@ドメイン名」、Timestampは協定世界時の「YYYY-MM-DDThh:mm:ss」というガイドラインの形式に合わせています。

import base64, datetime, urllib.request, uuid
import xml.etree.ElementTree as ET

NS = "http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server"
SOAP = "http://schemas.xmlsoap.org/soap/envelope/"

def envelope(method, body, me, server):
    now = datetime.datetime.now(datetime.UTC).strftime("%Y-%m-%dT%H:%M:%S")
    mid = f"{uuid.uuid4().hex}@{me}"
    return f"""<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="{SOAP}">
<soap:Header><MessageHeader xmlns="{NS}">
<From>{me}</From><To>{server}</To>
<MessageId>{mid}</MessageId><Timestamp>{now}</Timestamp>
</MessageHeader></soap:Header>
<soap:Body><{method} xmlns="{NS}">{body}</{method}></soap:Body>
</soap:Envelope>""".encode("utf-8")

def call(url, method, body, me, server, auth):
    req = urllib.request.Request(url, data=envelope(method, body, me, server), headers={
        "Content-Type": "text/xml; charset=UTF-8",
        "SOAPAction": f'"{NS}/{method}"',
        "Authorization": "Basic " + base64.b64encode(auth.encode()).decode(),
    })
    with urllib.request.urlopen(req, timeout=60) as r:
        return ET.fromstring(r.read()).find(f".//{{{NS}}}{method}Response")

def pull_one(url, me, server, gln, auth):
    res = call(url, "GetDocument", f"<receiverId>{gln}</receiverId>", me, server, auth)
    if res.findtext(f"{{{NS}}}GetDocumentResult") != "true":
        return None  # 未取得の文書が無い
    f = lambda k: res.findtext(f"{{{NS}}}{k}")
    doc = {k: f(k) for k in ("messageId", "senderId", "receiverId", "documentType", "compressType")}
    doc["xml"] = base64.b64decode(f("data"))
    save(doc)  # 自社DBへ保存してから受信確定を返す
    body = (f"<messageId>{doc['messageId']}</messageId>"
            f"<senderId>{doc['senderId']}</senderId><receiverId>{gln}</receiverId>")
    ok = call(url, "ConfirmDocument", body, me, server, auth)
    return doc, ok.findtext(f"{{{NS}}}ConfirmDocumentResult")

saveは自社の受注テーブルへ書き込む関数で、実装は省略しました。pull_oneをNoneが返るまで繰り返すと、未取得の文書を古い順に取り込めます。TLSのクライアント証明書を使う取り決めなら、Basic認証の代わりにSSLコンテキストを渡します。

受信確定を保存の後に送る理由と、取りこぼしと二重取り込みを防ぐ順序

ConfirmDocumentを送った文書は、次のGetDocumentでは返ってきません。確定を先に送ってDB書き込みが失敗すると、その発注は二度と取れなくなります。だから順序は「取得→保存→確定」です。

逆に、保存後に確定の通信だけが失敗すると、同じ文書が次回もう一度返ってきます。受注テーブルにはJXのmessageIdを一意キーとして持たせ、2回目は保存を飛ばして確定だけを送り直します。同じmessageIdの確定が重複するとサーバーはConfirmDocumentResultにfalseを返す決まりなので、falseを異常として止める実装にすると、この再送の場面で処理が止まるので注意してください。

流通BMSのデメリット：データ量23倍・取引先別の協定・暗号の追随という負担

標準である分、導入の前に見積もっておく負担もあります。

固定長128バイトからXMLへ移ると500KBが11.5MBになるデータ量の増え方

入門講座の資料には、JCA手順で500KBだった発注データが、流通BMSのXMLにすると11.5MBになった事例が載っています。固定長からXMLへ変えるとデータ量は23倍です。それでも通信時間は、JCA手順の9600bpsで35分かかっていたものが、光回線で2分34秒（XMLへの変換時間を含む）になり、93%減ったとされています。

通信時間は縮んでも、保存するデータは20倍以上に増えます。受信したXMLを電子取引データとして原本のまま残すなら、ストレージの見積もりの基準はXMLにした後の容量です。保存要件はEDI取引の流れと電子帳簿保存法の対応を解説した記事が扱っています。

協定シートとマッピングシートで取引先ごとに詰める項目が残る運用負担

標準になっても、取引先ごとの取り決めは残ります。協議会の通信パラメータ協定シート、メッセージ情報協定シート、マッピングシートに、使うメッセージ・圧縮の有無・使う任意項目を取引先ごとに書き込むからです。

入門講座の資料にある日用品卸の事例では、新規接続の開発工数をJCA手順の100としたとき、流通BMSは60〜80、Web-EDIは120〜150でした。半分以下にはなりません。

SSL3.0前提の旧ガイドラインのまま設定するとTLSで接続できない落とし穴

通信プロトコル利用ガイドライン第2.0版の推奨パラメータ表は、セキュリティプロトコルを「SSL3.0」と書いたままです。協議会は2015年6月8日付の「SSLver3.0脆弱性対応のお願い（改訂版）」で、TLSへの移行と再ネゴシエーションの脆弱性対策を求め、SSL3.0の対応期限を2015年10月1日としました。

古い表をそのまま協定シートに写すと、現在のOSやライブラリでは接続できません。TLSの版と暗号スイートは、相手サーバーの現在の設定に合わせて取り決めます。

JCA手順から流通BMSへの移行：固定長レイアウトをXMLへ写すマッピングの手順

1980年に日本チェーンストア協会が定めたJCA手順は、公衆回線やINSネットの上でモデムを使う通信手順です。入門講座の資料は、電話網のIP網への移行で、JCA手順などの通信に遅延が出るおそれを挙げています。

INSネット補完策の2028年12月31日終了から逆算する移行の着手時期

INSネットのディジタル通信モードは2024年1月に終わり、INSネットでJCA手順を使ってきた企業は補完策のデータ通信でつないでいます。NTT東日本・西日本は2024年に、補完策を含むINSネットの提供を2028年12月31日で終えると発表しました。経緯と移行先の比較はEDIの仕組みと2024年問題後の移行判断の記事にまとめています。

移行の期間は、小売との接続テストの順番待ちで決まります。取引先の小売が5社以上あるなら、2027年中には最初の1社の接続テストを終える計画にしておきます。

JCA手順の固定長レコードを流通BMSの項目へ写すマッピング作業の進め方

JCA手順のデータは、伝票の明細行を128バイトの固定長レコードで表す形式です。入門講座の資料が指摘するとおり、固定長の方式は細部まで統一するのが難しく、実際には企業ごとのレイアウトになっています。移行の作業は、この個別レイアウトの各桁を流通BMSの項目へ対応づけることです。

小売ごとのJCA手順のレイアウト定義書を集め、桁位置・桁数・意味を一覧にする
小売から流通BMSのマッピングシートを受け取り、使うメッセージと任意項目を確認する
JCA手順の項目を流通BMSの項目番号へ対応づけ、対応先の無い項目を洗い出す
対応先の無い項目を、処理種別などの例外項目に入れてよいかを小売と協議する
新旧の両方でデータを受け、変換結果を突き合わせる並行期間を置く

手順3で対応先の無い項目が多いのは、独自運用が標準の外にある印です。値引が典型で、基本形Ver2.2の値引メッセージを使えるかを先に確認します。

流通BMSを自社開発で受けるべき企業と、ASP・SaaS接続で済ませる企業の判断基準

対応方法は、ASP・SaaS型のサービスへの接続、市販の通信ソフトの導入、受発注システムの一部として作る形の3つです。

ASP・SaaS接続で済ませてよい条件：接続先の小売が数社で取引明細10MB未満

接続先の小売が数社で、1回の取引データが10MBに届かず、受信した発注を担当者が画面で確認してから販売管理システムへ取り込む運用なら、ASP・SaaS型の流通BMSサービスで足ります。費用の構造はEDIシステムの初期費用と月額の内訳を解説した記事、製品の選び方はEDIシステムを4タイプで比較した記事を参照してください。

この規模でJXクライアントや変換を自前で作るのは過剰です。小売がTLSや版を変えるたびに追随する保守が残るだけです。

自社でJXクライアントや変換を作るべき条件と、受発注システムとの一体設計

自社で作るのは、接続先の小売が10社を超えて接続数課金が月額を押し上げている場合、受信した発注を人手を介さず在庫引当と出荷指示まで流したい場合、Web-EDIやFAXの取引先と受注の入口を1つにまとめたい場合です。

この段階では、JXクライアントと変換を単独の部品にせず、受注の一意キー・取込エラーの差し戻し・コード読み替えまで含めて設計します。流通BMSの受信から社内の受注・出荷・請求までを一本の流れで作る受発注システム開発では、要件定義の最初に棚卸しする対象は、どの小売のどの版のメッセージを受けるかです。小売の発注とWeb-EDI・FAXが並走する接続経路の設計は、小売業界の受発注管理システムでEDI接続を判断する記事が詳しく扱っています。

よくある質問

流通BMSの仕様と導入について、検索の多い質問に答えます。

流通BMSとJCA手順は何が違いますか？

回線と書式の両方が違います。JCA手順は公衆回線と2400bpsまたは9600bpsのモデムを使い、データは企業ごとにレイアウトの異なる128バイトの固定長レコードです。流通BMSはインターネット上のebXML MS・AS2・JX手順で、標準化されたXMLを送ります。INSネットでJCA手順を使っている場合、補完策が終わる2028年12月31日までに移行が必要です。

流通BMSとWeb-EDIはどう違いますか？

流通BMSはシステム同士がデータを直接やり取りし、Web-EDIは担当者がブラウザで小売の画面を開いて発注を見る方式です。Web-EDIは小売ごとに画面が異なり、自社システムへの取り込みが手作業になりがちです。協議会は2012年3月に「流通BMSにおけるWeb-EDIガイドライン」を出し、項目を流通BMSのメッセージにそろえる方針を示しています。

流通BMSのXMLスキーマや仕様書はどこで入手できますか？

メッセージ項目一覧、運用ガイドライン、マッピングシートは、流通BMS協議会のサイトからダウンロードできます。XMLスキーマ本体は利用登録制で、申込フォームから登録すると事務局からダウンロード用のURLが届きます。通信プロトコル利用ガイドラインとebXML MSのCPAのひな型は、通信基盤関連の標準ページから入手できる資料です。

流通BMSのメッセージは何種類ありますか？

2007年の基本形Ver1.0は6業務・8種で始まり、協議会の入門講座の資料（2020年版）では基本形28種・百貨店版27種と数えています。2025年4月の基本形Ver2.2で値引と値引依頼が加わりました。実装するのは、取引先の小売が指定するメッセージだけで足ります。

中小の卸・メーカーでも流通BMSへの対応は必要ですか？

流通BMSへの対応が必要になるのは、取引先の小売から流通BMSを指定された時点です。第28回推計も、小売の導入が進んだことで取引先の中小企業にも対応が求められた点を、導入拡大の背景に挙げています。中小企業なら、自社にサーバーを持たずに済むJX手順のクライアント型か、ASP・SaaS型のサービスへの接続で始めます。