Views: 6
共通EDIとOpenPeppolをSBDHで接続する:Sender/Receiver と originalSender/finalRecipient の指定
2025-12-01
共通EDIとPeppolを連携させるゲートウェイ接続において、電子メッセージの送受信に使われる各種識別子の設計原則を体系的に解説します。複数のAS4通信区間を経由する際に混乱しがちな識別子の役割分担を整理するため、情報が格納される業務層(SBDH)と輸送層(AS4)の役割を明確に分離することを主眼として解説します。
具体的には、SBDHのSender/Receiverは、輸送を担うアクセスポイントではなく、常に業務当事者(C1とC4)のIDを指す必要があります。その一方で、AS4のeb:From/eb:Toは、メッセージを中継するアクセスポイント(C2とC3)同士の接続を識別します。
さらに、ゲートウェイが両ネットワークの役割を兼ねる場合でも、AS4のoriginalSender/finalRecipientプロパティを利用することで、取引当事者のIDを一貫して維持する設計パターンを推奨します。
注:Google NotebookLMで作成したこの記事の解説動画です。
目的
共通EDI(SME EDI)とPeppolをゲートウェイ接続してメッセージ送信する際に、次の関係を整理する。
-
SBDH(Standard Business Document Header / Peppol Envelope)で指定する Sender / Receiver
-
AS4ヘッダで指定する sender / receiver(eb:From / eb:To)
-
4コーナーモデルモデル(4-corner)向けの originalSender / finalRecipient(AS4 MessageProperties)
-
「C3sme と C2peppol がゲートウェイであり、同じ endpoint ID を持つ」ケースでの矛盾の回避
-
SME区間では UN/CEFACT CII(
<rsm:Invoice>)を搬送し、ゲートウェイで UBL(<ubl:Invoice>)へ構文変換して Peppol 区間へ送る
はじめに
共通EDIとPeppolをゲートウェイ(C3sme=C2peppol)で接続する場合、同じ業務文書を
-
共通EDI側のAS4区間
-
Peppol側のAS4区間
で中継する構造になりやすい。
このとき混乱しやすいのが、AS4ヘッダ上の送受信(sender/receiver)と、4コーナーモデルモデル(4-corner)向けの originalSender / finalRecipient、さらにSBDHの Sender / Receiver の役割分担である。
さらに本稿では、次の実装前提を置く。
-
SME区間(C2sme→C3sme)では、SBDH の本文書は UN/CEFACT CII(
<rsm:Invoice>)である -
ゲートウェイ(C3sme/C2peppol)で CII→UBL に構文変換し、Peppol区間(C2peppol→C3peppol)では、SBDH の本文書は UBL(
<ubl:Invoice>)になる
Peppol AS4 Profileでは、Peppolネットワーク内の送信は SBDH(Peppol Envelope)を統合した形で必須であり、スタンドアロンSBDHは使わない。また、CEF eDelivery AS4 の該当節(4.2.1, 4.2.5, 4.2.6)として originalSender / finalRecipient の使用に言及している。
Peppol AS4 Profileの位置づけ(引用)
この文書は、PeppolネットワークにおけるAS4の実装方法について記述する。 AS4の実装は、[CEFeDeliveryAS4](CEF eDelivery AS4 Profile v1.14)および、本文書で定義・制限される要素に従わなければならない。これらは、CEF仕様で定義されていない、あるいはオプションでありPeppolネットワークで使用されない機能や属性をさらに定義・制限するものである。 要約すると、PeppolネットワークにおけるAS4は、4コーナーモデル・トポロジーにおいてコーナー2とコーナー3間の非同期メッセージ伝送に用いられます。AS4メッセージレベルでの署名・暗号化にはPeppol PKIを、動的ディスカバリにはSMP/SMLを採用します。 (翻訳:DeepL)
用語整理(誰が誰か)
4コーナーモデルモデル(概念)
-
C1:元の送信者(業務当事者。請求書を発行する企業など)
-
C2:送信Access Point(送信側プロバイダ)
-
C3:受信Access Point(受信側プロバイダ)
-
C4:最終受信者(業務当事者。請求書を受ける企業など)
今回の接続(共通EDI ↔ Peppol)
-
C1smeからC4peppolにメッセージを送信する。
-
共通EDI側:C1sme → C2sme → C3sme
-
ゲートウェイ:C3sme と C2peppol が同一(同一エンドポイントID/同一実装)になり得る
-
Peppol側:C2peppol → C3peppol → C4peppol(受信事業者)
共通EDIとPeppolをゲートウェイ(C3sme=C2peppol)で接続する場合、同じ業務文書を
-
共通EDI側のAS4区間
-
Peppol側のAS4区間
で中継する構造になりやすい。
前提:4コーナーと「業務層」と「輸送層」
4コーナーの役割(層の考え方)
Peppolの4コーナー概念では、C1/C4が取引当事者(End User)、C2/C3がサービスプロバイダ(Access Point)となる。
ここで重要なのは、SBDHは「業務メッセージの封筒(Business Message Envelope)」であり、AS4などの輸送プロトコルは「輸送の封筒」である、という層の分離である。
このとき混乱しやすいのが、AS4ヘッダ上の送受信(sender/receiver)と、4コーナーモデルモデル(4-corner)向けの originalSender / finalRecipient、さらにSBDHの Sender / Receiver の役割分担である。
Peppol AS4 Profileでは、Peppolネットワーク内の送信は SBDH(Peppol Envelope)を統合した形で必須であり、スタンドアロンSBDHは使わない。また、CEF eDelivery AS4 の該当節(4.2.1, 4.2.5, 4.2.6)として originalSender / finalRecipient の使用に言及している。
層の分離(結論)
-
SBDH(業務層): Sender/Receiver は「取引当事者(C1/C4)」を表す
-
AS4(輸送層): sender/receiver(eb:From/eb:To、PartyIdなど)は「Access Point(C2/C3)」を表す
-
AS4(4コーナー拡張): originalSender/finalRecipient は「取引当事者(C1/C4)」を表す
何をどこに書くか(結論)
ここが本稿の中心である。SBDHとAS4の役割を分けて書く。
1) SBDH(Peppol Business Message Envelope)の Sender / Receiver
SBDHの Sender / Receiver は「業務文書(Invoice等)の送信者/受信者」を表す。
Peppol Envelopeでは、受信者識別子はSML/SMPに登録されたParticipant(C4)に対応するものを要求し、送信者識別子(C1)も要求する。
また、Peppol Envelopeは「Envelope+業務文書が1つのXMLインスタンスになる」前提であり、Envelopeの入れ子(別Envelopeの包含)は禁止される。
2.1 Party identifiers
The required Receiver party identifier in the Message Envelope header is the one that corresponds to a Peppol Participant registered in the SML/SMP. Also, the Sender party identifier is required. The structure of the identifier MUST follow the “Peppol Policy for use of Identifiers v4.x” [Peppol_Policy4].
In cases where the sender is not registered in SML/SMP the identifier of the sender MUST be used as if the sender would be registered.
2) AS4の sender / receiver(eb:From / eb:To)
AS4区間の sender / receiver は「そのAS4区間で実際に通信する Access Point 同士(内側の角)」を指す。
-
共通EDI側AS4区間:sender=C2sme、receiver=C3sme
-
Peppol側AS4区間:sender=C2peppol、receiver=C3peppol
この sender/receiver は「業務当事者(C1/C4)」ではなく「AP(C2/C3)」である点が重要である。
3) AS4 MessageProperties の originalSender / finalRecipient
CEF eDelivery AS4 の4コーナーモデル・トポロジ拡張では、payload形式に依存せずC1/C4を識別するために、ebMS3のプロパティ機構で originalSender / finalRecipient を追加する。
-
originalSender:C1(元の送信者)を識別するプロパティ
-
finalRecipient:C4(最終受信者)を識別するプロパティ
重要なのは次の点である。
-
4コーナーモデル構成でAS4が担うのは「内側(C2↔C3)の相互接続」であり、外側(C1↔C2、C3↔C4)にAS4は必須ではない。
-
そのため、AS4レベルの sender/receiver(eb:From/To)と、業務当事者を表す originalSender/finalRecipient は区別される。
ゲートウェイが同じendpoint IDの場合の設計パターン
パターンA(推奨):SBDHはC1/C4、ゲートウェイはAS4で表す
輸送層(AS4)で「このメッセージを運ぶAP(ゲートウェイ)は誰か」を表す。
-
AS4 From(Initiator PartyId): 送信側AP(例:POPxxxxxx)
-
AS4 To(Responder PartyId): 受信側AP(例:POPyyyyyy)
一方、SBDHは次のようにする。
-
SBDH Sender: 取引当事者(共通EDI側の送信者=C1)
-
SBDH Receiver: 取引当事者(Peppol側の受信者=C4)
パターンB(トレース用途):SBDHに「経路情報」を追加属性として保持する
ゲートウェイの経路情報(C2sme/C3sme/C2peppol/C3peppol)を、SBDHのBusinessScopeに「追加属性(key-value)」として持たせることは可能である。
ただし、Peppolでは追加属性キーに予約語があり、予約語を他目的に流用してはならない(例:COUNTRY_C1、COUNTRY_C4、DOCUMENTID、PROCESSID、TECHNICAL_VALIDATION_URL、TECHNICAL_VALIDATION_REQUIRED 等)。
従って、経路情報を入れるなら、予約語と衝突しない独自キー(例:SME_C2、SME_C3、PEPPOL_C2、PEPPOL_C3 等)を用いる。
Peppol AS4におけるSBDHの配置(MIME)
Peppol AS4 Profileでは、SBDH(業務文書を含むEnvelope)はAS4メッセージのペイロードとして扱われ、MIME添付として配送される(SBDH統合が前提でスタンドアロンSBDHは使わない)。
実装の要点(共通EDI→Peppol ゲートウェイ接続)
1) 共通EDI識別子とPeppol識別子のマッピング
ゲートウェイは、共通EDI側の参加者ID(例:gBizID等)を、Peppol Participant ID(例:iso6523-actorid-upis の形式)へマッピングする。
2) Peppol Envelope(SBDH)の必須要素(整理)
-
Sender/Receiver(Participant ID。必要に応じて Authority を付与)
-
BusinessScopeに DOCUMENTID / PROCESSID(Typeコードで区別)
-
必要に応じて、Identifier(docid/procidのscheme)を付与
3) 二重封筒を避ける
共通EDI側で既にSBDH相当の封筒を持っている場合は、Peppolへ出す段階で「Peppol Envelopeとして正規化」し、SBDHを二重化しない設計とする。
(Peppol Envelopeは入れ子禁止、という制約に合わせる。)
SBDHのSender/Receiverは誰を指すのか(再確認)
したがって、ゲートウェイIDをSender/Receiverに入れない
C3smeやC2peppolは「輸送の担い手(サービス提供者)」であり、SBDHのSender/Receiverに入れる対象ではない。
「C3sme と C2peppol が同じ endpoint ID」という事実は、輸送層(AS4)では自然に成立する(同一実体のゲートウェイが両ネットワーク側の役割を兼ねる)一方、SBDHのSender/Receiverとは別問題として扱うのが整合的である。
CII→UBL 構文変換ゲートウェイの位置づけ
ゲートウェイ(C3sme/C2peppol)は、SME区間で受信した SBDH の本文書(CII)を、Peppol区間で要求される本文書(UBL)へ構文変換して再送する。
-
入力(Hop#1):
SBDH + <rsm:Invoice>… -
出力(Hop#2):
SBDH + <ubl:Invoice>…
このとき推奨される扱いは次のとおり。
-
維持:SBDH Sender/Receiver(C1/C4)、AS4 originalSender/finalRecipient(C1/C4)
-
差し替え:SBDH本文書(CII→UBL)、(必要に応じ)SBDHのDocumentIdentification/BusinessScope(PeppolのDOCUMENTID/PROCESSID)
-
変化:AS4のeb:From/eb:To(ホップの通信当事者APが変わるため)
AS4にSBDHが含まれた電文例(Hopごとに本文書が変わる)
ここでは「AS4(SOAP)にSBDH本文を含めて送る」形を例示する。
(実運用ではMIME添付でpayload化することもあるが、理解しやすさを優先してBody直入れの形で示す。)
Hop#1(SMEネットワーク):C2sme → C3sme(AS4 + SBDH + CII)
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
<soap:Header>
<eb:Messaging soap:mustUnderstand="true">
<eb:UserMessage>
<eb:MessageInfo>
<eb:MessageId>uuid:HOP1-11111111-1111-1111-1111-111111111111</eb:MessageId>
<eb:Timestamp>2025-12-01T10:00:00Z</eb:Timestamp>
</eb:MessageInfo>
<!-- このホップのAP同士(SME):C2sme → C3sme -->
<eb:PartyInfo>
<eb:From><eb:PartyId type="urn:example:sme:ap-id">SMEAP-C2-0001</eb:PartyId></eb:From>
<eb:To><eb:PartyId type="urn:example:sme:ap-id">SMEAP-C3-0099</eb:PartyId></eb:To>
</eb:PartyInfo>
<!-- 外側当事者(C1/C4)は維持 -->
<eb:MessageProperties>
<eb:Property name="originalSender">C1sme-Participant-12345</eb:Property>
<eb:Property name="finalRecipient">C4peppol-Participant-67890</eb:Property>
</eb:MessageProperties>
<eb:CollaborationInfo>
<eb:Service>urn:example:sme:as4</eb:Service>
<eb:Action>SubmitCIIInvoice</eb:Action>
</eb:CollaborationInfo>
</eb:UserMessage>
</eb:Messaging>
</soap:Header>
<soap:Body>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<StandardBusinessDocumentHeader>
<HeaderVersion>1.0</HeaderVersion>
<!-- 業務当事者(C1/C4) -->
<Sender><Identifier Authority="iso6523-actorid-upis">C1sme-Participant-12345</Identifier></Sender>
<Receiver><Identifier Authority="iso6523-actorid-upis">C4peppol-Participant-67890</Identifier></Receiver>
<!-- SME区間では CII を搬送 -->
<DocumentIdentification>
<Standard>UN/CEFACT CII</Standard>
<TypeVersion>1.0</TypeVersion>
<InstanceIdentifier>INV-20251201-0001</InstanceIdentifier>
<Type>Invoice</Type>
<CreationDateAndTime>2025-12-01T19:00:00+09:00</CreationDateAndTime>
</DocumentIdentification>
</StandardBusinessDocumentHeader>
<!-- 本文書:CII(例示として <rsm:Invoice> を使用) -->
<rsm:Invoice xmlns:rsm="urn:example:cii:rsm" xmlns:ram="urn:example:cii:ram" xmlns:udt="urn:example:cii:udt">
<ram:Document>
<ram:ID>INV-20251201-0001</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime><udt:DateTimeString format="102">20251201</udt:DateTimeString></ram:IssueDateTime>
</ram:Document>
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceCurrencyCode>JPY</ram:InvoiceCurrencyCode>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>10000</ram:LineTotalAmount>
<ram:TaxTotalAmount>1000</ram:TaxTotalAmount>
<ram:GrandTotalAmount>11000</ram:GrandTotalAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
</rsm:Invoice>
</StandardBusinessDocument>
</soap:Body>
</soap:Envelope>
Hop#2(Peppolネットワーク):C2peppol → C3peppol(AS4 + SBDH + UBL)
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
<soap:Header>
<eb:Messaging soap:mustUnderstand="true">
<eb:UserMessage>
<eb:MessageInfo>
<eb:MessageId>uuid:HOP2-22222222-2222-2222-2222-222222222222</eb:MessageId>
<eb:Timestamp>2025-12-01T10:00:05Z</eb:Timestamp>
</eb:MessageInfo>
<!-- このホップのAP同士(Peppol):C2peppol → C3peppol
ネットワークが変わるため eb:From/eb:To が Hop#1 と違う -->
<eb:PartyInfo>
<eb:From><eb:PartyId type="urn:example:peppol:ap-id">PEPPOLAP-C2-0456</eb:PartyId></eb:From>
<eb:To><eb:PartyId type="urn:example:peppol:ap-id">PEPPOLAP-C3-0789</eb:PartyId></eb:To>
</eb:PartyInfo>
<!-- 外側当事者(C1/C4)は維持 -->
<eb:MessageProperties>
<eb:Property name="originalSender">C1sme-Participant-12345</eb:Property>
<eb:Property name="finalRecipient">C4peppol-Participant-67890</eb:Property>
</eb:MessageProperties>
<eb:CollaborationInfo>
<eb:Service>urn:example:peppol:as4</eb:Service>
<eb:Action>SubmitUBLInvoice</eb:Action>
</eb:CollaborationInfo>
</eb:UserMessage>
</eb:Messaging>
</soap:Header>
<soap:Body>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<StandardBusinessDocumentHeader>
<HeaderVersion>1.0</HeaderVersion>
<!-- 業務当事者(C1/C4)はそのまま -->
<Sender><Identifier Authority="iso6523-actorid-upis">C1sme-Participant-12345</Identifier></Sender>
<Receiver><Identifier Authority="iso6523-actorid-upis">C4peppol-Participant-67890</Identifier></Receiver>
<!-- Peppol区間では UBL を搬送(CII→UBL変換結果) -->
<DocumentIdentification>
<Standard>UBL</Standard>
<TypeVersion>2.1</TypeVersion>
<InstanceIdentifier>INV-20251201-0001</InstanceIdentifier>
<Type>Invoice</Type>
<CreationDateAndTime>2025-12-01T19:00:00+09:00</CreationDateAndTime>
</DocumentIdentification>
<!-- Peppol側のディスカバリに必要な DOCUMENTID/PROCESSID をここで設定する想定 -->
<BusinessScope>
<Scope>
<Type>DOCUMENTID</Type>
<InstanceIdentifier>urn:peppol:bis:billing:3::Invoice##...</InstanceIdentifier>
<Identifier>busdox-docid-qns</Identifier>
</Scope>
<Scope>
<Type>PROCESSID</Type>
<InstanceIdentifier>urn:peppol:bis:billing:3</InstanceIdentifier>
<Identifier>cenbii-procid-ubl</Identifier>
</Scope>
</BusinessScope>
</StandardBusinessDocumentHeader>
<!-- 本文書:UBL(例示として <ubl:Invoice> を使用) -->
<ubl:Invoice xmlns:ubl="urn:example:ubl:Invoice" xmlns:cac="urn:example:ubl:cac" xmlns:cbc="urn:example:ubl:cbc">
<cbc:ID>INV-20251201-0001</cbc:ID>
<cbc:IssueDate>2025-12-01</cbc:IssueDate>
<cbc:DocumentCurrencyCode>JPY</cbc:DocumentCurrencyCode>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount>10000</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount>10000</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount>11000</cbc:TaxInclusiveAmount>
<cbc:PayableAmount>11000</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:TaxTotal><cbc:TaxAmount>1000</cbc:TaxAmount></cac:TaxTotal>
</ubl:Invoice>
</StandardBusinessDocument>
</soap:Body>
</soap:Envelope>
注記:
* DOCUMENTID/PROCESSIDはSML/SMPディスカバリに必要な値であり、BusinessScope/Scopeにマッピングされる。
* 追加属性はkey-valueとして表現できるが、予約語キーは流用しない。
「ネットワークが違うと From/To が違う」理由(このケース)
eb:From/eb:To は「そのAS4送信で実際に通信する相手(AP↔AP)」を指す。
-
Hop#1(SME区間)では、通信相手は C2sme と C3sme であるため
From/Toは SME 側 AP の識別子になる。 -
Hop#2(Peppol区間)では、通信相手は C2peppol(=ゲートウェイ)と C3peppol であるため
From/Toは Peppol 側 AP の識別子になる。
したがって、ネットワーク境界(ホップの切替)で eb:From/eb:To が変わるのは自然である。
一方で、originalSender/finalRecipient と SBDH Sender/Receiver は「業務当事者(C1/C4)」を表すため、CII→UBLに構文変換しても原則として維持する。
チェックリスト
-
SBDHのSender/Receiverは取引当事者(C1/C4)のParticipant IDになっているか(Authority含む)
-
SBDHにDOCUMENTID/PROCESSIDがBusinessScopeとして入っているか
-
追加属性で予約語キーを流用していないか
-
二重SBDHになっていないか(Envelopeの入れ子禁止)
-
AS4の sender/receiver(eb:From/eb:To)がAP(C2/C3)識別子になっているか
-
AS4の originalSender/finalRecipient が業務当事者(C1/C4)を指し、区間を跨いでも不必要に書き換えられていないか
まとめ
「C3sme と C2peppol が同じ endpoint ID」でも、SBDH(業務層)とAS4(輸送層)を分離し、さらに4コーナーモデル拡張(originalSender/finalRecipient)を正しく位置づけ、ゲートウェイで本文書を CII→UBL に変換すれば矛盾は生じない。
-
SBDH Sender/Receiver = 取引当事者(C1/C4)
-
AS4 sender/receiver(eb:From/eb:To)= Access Point(C2/C3)であり、ホップで変わる
-
AS4 originalSender/finalRecipient = 取引当事者(C1/C4)であり、原則維持
-
SME区間の本文書:
<rsm:Invoice>(CII)→ ゲートウェイで変換 → Peppol区間の本文書:<ubl:Invoice>(UBL)
参考(図・仕様)
Peppol Business Message Envelope (SBDH):
Peppol Business Message Envelope (SBDH) Version: 2.0.1
UN/CEFACT SBDH(原仕様):
UN/CEFACT STANDARD BUSINESS DOCUMENT HEADER Technical Specification Version 1.3
Peppol AS4 Profile:
Peppol AS4 Profile
CEF eDelivery AS4 Profile 1.14:
eDelivery AS4 – 1.14
- 目的
- はじめに
- Peppol AS4 Profileの位置づけ(引用)
- 用語整理(誰が誰か)
- 前提:4コーナーと「業務層」と「輸送層」
- 何をどこに書くか(結論)
- ゲートウェイが同じendpoint IDの場合の設計パターン
- Peppol AS4におけるSBDHの配置(MIME)
- 実装の要点(共通EDI→Peppol ゲートウェイ接続)
- SBDHのSender/Receiverは誰を指すのか(再確認)
- CII→UBL 構文変換ゲートウェイの位置づけ
- AS4にSBDHが含まれた電文例(Hopごとに本文書が変わる)
- 「ネットワークが違うと From/To が違う」理由(このケース)
- チェックリスト
- まとめ
- 参考(図・仕様)

コメントを残す