Views: 4
JP PINT eDelivery を中核にした国内 EDI 連携と MLS / ViDA の位置づけ（統合版）
2025-10-24
本稿は、JP PINT eDelivery を軸に 国内の既存 EDI（流通BMS 等） と OpenPeppol を連携させる実用アーキテクチャを提示し、その中で Message Level Status（MLS） の役割を解説する。あわせて EU の ViDA（VAT in the Digital Age） の最新動向と、Peppol／MLS が実運用をどう下支えするかを俯瞰する。
1. MLS 解説（C2↔C3 の“共通言語”）
|
Note
|
MLS は、受信側 Service Provider（C3） が 送信側 Service Provider（C2） に対し、交換されたビジネス文書の「配送・処理ステータス」を 標準形式 で返す仕組み。AP（確認あり受領）/AB（確認なし受領）/RE（拒否）の ResponseCode と、SV（構文）/BV（ビジネス致命）/BW（ビジネス警告）/FD（配送不能）の StatusReasonCode を用いる（UBL ApplicationResponse の構造・コードリストは仕様で定義）。([docs.peppol.eu][1])
|
|
Note
|
MLS は eDelivery の公式仕様群（eDEC） に位置付けられ、v1.0.0 が公開済み（2025-05 公開）。同一覧には Reporting（統計報告）等も並び、ネットワーク運用の標準化を支える。([docs.peppol.eu][2]) |
|
Note
|
マルチ構成への対応は、SPIS（Service Provider Identification Scheme） と SBDH 拡張（MLS_TO/MLS_TYPE）の組合せで実現される。参加者が複数 SP を使う／SP が複数 AP を運用する場合でも、MLS の宛先や送信方針を明示できる。([docs.peppol.eu][3])
|
1.1. 監視ログ → MLS 応答ひな型
| 監視層 | 典型イベント（例） | MLS ResponseCode |
StatusReasonCode |
Description（例） |
|---|---|---|---|---|
|
構文/XSD |
XML パース失敗、XSD 違反、UBL バージョン不整合 |
RE |
SV |
|
|
EN16931/JP PINT 適合 |
必須 BT 欠落、Schematron 致命（fatal） |
RE |
BV |
|
|
警告のみ |
Schematron 警告（致命なし） |
AP/AB |
BW（付記可） |
|
|
封筒/SBDH |
SBDH と本文値の齟齬、EndpointID 不整合 |
RE |
BV |
|
|
サイズ/MIME/添付 |
添付サイズ超過、MIME 不一致、PDF 破損 |
RE |
BV |
|
|
マルウェア |
ウイルス/マルウェア検知 |
RE |
BV |
|
|
C4 配送不能 |
取引先不明、恒久障害、回線遮断 |
RE |
FD |
|
|
C4 受領（確認あり） |
API/ACK 取得、受領署名あり |
AP |
（任意） |
|
|
C4 受領（確認なし） |
メール転送、保管型（ポーリング） |
AB |
（任意） |
|
|
Note
|
AP/AB の分岐は 「C4 の受領確認を検証可能に取得できたか」。RE には原因追跡に足る説明を必ず添付。([docs.peppol.eu][1])
|
2. 欧州の動向（ViDA と Peppol）
ViDA（VAT in the Digital Age） は、EU の 電子インボイス＋デジタル報告（DRR） などを段階導入する法制度パッケージ。2025-03-11 採択、2035 年まで順次実装の方針が示されている。Peppol では ViDA パイロット を立ち上げ、EN16931 準拠の e インボイス＋Peppol ネットワーク（5 コーナーモデル拡張）で DRR の期待に応えられるかを検証中。([Taxation and Customs Union][4])
国家体制面でも動きがある。フランスは 2025-07-08 に税務当局（DGFiP）が Peppol National Authority に就任し、国内制度と Peppol の連携を推進する方針を公表している。([OpenPeppol][5])
位置づけ: MLS は税データ提出の経路ではない。しかし C2↔C3 の配送・検証の証跡標準として、DRR/CTC の“前段”における 再送制御・責任分界・監査を強化し、実運用の信頼性を底上げする（Peppol Reporting と役割を分担）。([docs.peppol.eu][2])
3. 日本で異なる EDI をつなぐ中核としての JP PINT
3.1. コンセプト
日本では、流通BMS をはじめ業界 EDI と JP PINT が並走する。現実的には「発注＝既存 EDI（例：流通BMS）」「請求＝JP PINT」の役割分担が多いが、相手先や版が増えるたびに C4 側がEDIごとの XML を実装・回帰するのは非現実的。
解：C3（PINT プロバイダ） に “コアインボイス・ゲートウェイ” を置き、構造化 CSV（xBRL-CSV ベース） を コアインボイス・ゲートウェイ に据える。
-
構文 → コアインボイス・ゲートウェイ → 構文 の二段変換で、流通BMS ⇄ JP PINT ⇄ 他 EDI を橋渡し。
-
C4 は 構造化 CSV のみ を受ければよい（EDI ごとの XML 実装負担を撤廃）。
-
MLS（C2↔C3） で配送・検証の結果を可視化／標準化。
3.2. 概念図（PlantUML）
3.3. 導入チェックリスト（要点のみ）
-
中立モデル：構造化 CSV の列定義（必須/任意、型、コード表リンク）と 日本版の論理コアモデル（EN16931＋日本要件/インボイスに限らない）を整備。
-
二段変換：
流通BMS XML → 構造化CSV → JP PINT UBL
逆方向（JP PINT → 構造化CSV → 流通BMS）も用意（双方向ブリッジ）。 -
適合検証：XSD / EN16931 / JP PINT / Schematron、サイズ、MIME、マルウェア。
-
可観測性：ログカテゴリ→MLS（AP/AB/RE＋SV/BV/BW/FD） のマッピング表、AS4 ログと Message-ID/ConversationID で突合。
-
SBDH/運用：
MLS_TO（宛先 SP/AP）・MLS_TYPE（ALWAYS_SEND/FAILURE_ONLY）を規程化。([docs.peppol.eu][6]) -
ガバナンス：スキーマ／コード表レジストリ、版管理と回帰テスト（Golden データ）。
4. まとめ
-
MLS は C2↔C3 の配送・検証の共通言語。eDEC 公式仕様として、運用の可視化・責任分界・監査性を標準化する。([docs.peppol.eu][2])
-
ViDA では DRR/CTC が進展中。MLS は提出経路ではないが、前段の運用品質（再送・証跡・監査）を底上げし、Peppol 経由の連携実装を安定させる。([Taxation and Customs Union][4])
-
JP PINT を中核に、C3(C2) に“構造化 CSV コアインボイス・ゲートウェイ”を置く二段変換で、既存 EDI（例：流通BMS） と JP PINT/他 EDI を現実的に橋渡しできる。MLS＋SPIS＋SBDH 拡張を運用に落とし込めば、相手先増加・版改訂にも耐える。
5. 参考
-
Peppol MLS v1.0.0：概要・本文・取引仕様・コード・ルール／スキーマトロン。([docs.peppol.eu][1])
-
eDEC 仕様一覧（必須群）：MLS と Reporting 等の位置づけ。([docs.peppol.eu][2])
-
SPIS（OpenPeppol Service Provider ID Scheme）：MLS 受信の差別化例を含む。([docs.peppol.eu][3])
-
ViDA 採択（2025-03-11） と実装ロードマップの概説。([Taxation and Customs Union][4])
-
Peppol ViDA パイロット（公式説明／資料）。([OpenPeppol][7])
-
フランス：Peppol National Authority 設置（2025-07-08）。([OpenPeppol][5])
[1] “Peppol Message Level Status”
[2] “OpenPeppol eDEC Specifications”
[3] “OpenPeppol Service Provider Identification Scheme (SPIS)”
[4] “Adoption of the VAT in the Digital Age package”
[5] “OpenPeppol welcomes the Peppol Authority for France”
[6] “Peppol Message Level Status – v1.0.0”
[7] “Peppol ViDA Pilot”
コメントを残す