JP PINTの請求書はUBLのXML形式を利用する。UBL 2.1のXMLスキーマ（XSD）は、要素の構造、出現順序、型、構文上の出現回数などを検証する。たとえば cbc:LineExtensionAmount が正しい構造に置かれ、規定されたデータ型で表現されているかを確認できる。

しかし、その金額が数量・単価・値引きなどから正しく計算されているか、同じ税率の明細金額が正しく集計されたかは、通常のXSDだけでは判定できない。

また、UBLで使用可能な要素が、すべてJP PINTで業務上の意味を持ち、使用を許されるとは限らない。「UBL XMLとして妥当」と「JP PINTに適合」は同義ではない。

論理モデルは、請求書に必要な業務情報をBusiness Term（IBT）とBusiness Group（IBG）として定義する。構文バインディングは、それらの情報をUBLのどのXML要素や属性で表現するか、必要に応じて要素を識別する条件とともに規定する。

たとえばIBT-131は請求明細の cbc:LineExtensionAmount、IBT-146は cac:Price/cbc:PriceAmount と対応する。こうしてXMLの値に「明細正味金額」「品目正味単価」という業務上の意味が与えられる。

ここで重要なのは、UBLスキーマには存在するが、JP PINTの論理モデルや構文バインディングには対応しない要素 をどう扱うかである。それを許すのか、無視するのか、禁止するのかが適合性の規定として明確でなければ、機械的に一貫した判定ができない。

「構文バインディングにない要素はスキーマトロンでは検証できない」という意味ではない。スキーマトロンはXPathにより任意の要素を選択し、その出現や値を検査できる。しかし、未対応要素の使用を禁止する条件が規定・実装されていなければ、その問題を検出できない。

従来のPeppol BIS Billing 3.0には、UBL XMLスキーマでは使用可能でも業務仕様では不要・制限対象となるUBL独自要素を確認する UBL-CR 規則群が用意されている。ここでは、筆者が2021年から問題提起してきたBasic Rulesに相当する検証の具体例として取り上げる。公式文書では UBL-CR という規則IDや構文規則の区分で確認できる。

例えば、UBLのバージョン情報を表す cbc:UBLVersionID はUBL 2.1のXMLスキーマで使用可能な要素である。BIS Billing 3.0およびPINT EUでは、UBL-CR-002 として次の規則が掲載されている。

この条件は、要素を省略するか、記載する場合は値を 2.1 とすることを求める。違反時の重大度はwarningである。 2.1 という値を含むこと自体は違反でなく、値が異なる場合でもこの警告だけを根拠にMLSの RE を返すことはできない。

BIS Billing 3.0およびPINT EUには、UBLVersionID 以外にも、UBLExtensions、ProfileExecutionID、CopyIndicator、UUID、IssueTime などの使用を制限する規則がある。ただし、規則の内容や重大度は項目ごとに異なり、すべての要素を一律に禁止しているわけではない。

ここで重要なのは、PINT EUの規則群をそのままJP PINTにすべて適用すべきだ、ということではない。PINT EUにはEN 16931との対応を前提とする規則もある。JP PINTで採用する制約と重大度を日本の仕様として明示し、共通の検証資産に反映する必要がある、ということである。

この問題を具体的に示すのが、JP PINTの配布ZIPに収録されたサンプルインボイスの変化である。今回は実際の配布物を照合した。ZIP名の括弧付き番号はダウンロード時のローカル名であり、正式な版番号ではない。正式な版は各ZIPの common/docs/release-notes.pdf に記された見出しで識別した。

1.1.1に収録された9件のサンプルは、いずれも次の要素を含んでいた。

一方、1.1.3の配布サンプル9件には、この要素は存在しない。すなわち、以前の公式サンプルには含まれていたが、1.1.3の配布サンプルからは削除されている。ただし、削除理由はこの差分からは確定できない。

cbc:UBLVersionID は、JP PINTの構文バインディングには業務項目として記載されていない。UBL 2.1 XMLスキーマでは使用できるため、正しい位置と構造であればXSDによる構文検証を通過する。しかし、それだけではJP PINTでの扱いは決まらない。

従来のBIS Billing 3.0とPINT EUで提供される UBL-CR-002 では、UBLVersionID は省略するか値を 2.1 とする条件であり、違反時の重大度はwarningである。したがって、1.1.1のサンプルが記載していた 2.1 はこの条件を満たす。しかし、この規則がそのままJP PINTに適用されるわけではない。

今回調べた1.1.1、1.1.3両方の配布ZIPには UBL-CR-002 に相当するIDも、UBLVersionID を直接参照する同梱Schematron・XSLTルールも見つからなかった。サンプルの修正と、受信文書の適合性を判定する共通ルールの整備は別の問題 である。

C3プロバイダが UBLVersionID=2.1 を含むインボイスを受信した場合、要素の存在だけで拒否すべきなのか、許容されるのかについて、適用するJP PINTの規範的な規定と検証条件を確認する必要がある。構文バインディングに対応がないという事実だけで、自動的に拒否できるとはいえない 。一方、旧版の公式サンプルに記述があったことだけを根拠に恒久的な使用許可があるともいえない。

この事例は、UBLスキーマ検証だけでは解決できない適合性の問題を示す。2021年から訴えてきたBasic Rulesに相当する共通ルールの必要性が、MLSの導入によって一層明確になる。

スキーマトロンはXPathに基づき、要素間の条件、相互関係、計算、コードの組合せなどを検証する。assert の test が真なら条件成立、偽なら違反となる。重要なのは、スキーマトロンがBIS本文を自動解釈してすべての規則を検証するわけではない点である。規定されたBusiness Ruleを実行可能なルールとして実装して初めて検証できる。

10%税率に属する明細が 10,000円 と 5,000円 であり、該当する値引き・追加料金がないとする。正しい課税対象額は 15,000円 である。

ところが請求書に課税対象額（IBT-116）20,000円、税額（IBT-117）2,000円、税率（IBT-119）10%が記載されていれば、報告済みの課税対象額と税額の計算関係だけは整合する。

実際の課税対象額の算出には、同じ税カテゴリー・税率の文書レベルの値引き・追加料金なども含め、BIS本文の条件を適用する必要がある。上記は二つの計算規則が独立していることを示す単純化した例である。

明細正味金額（IBT-131）には数量、基準数量、単価、明細値引き・追加料金との計算関係がある。品目正味単価（IBT-146）には総額単価や値引きとの関係がある。また、基準額と率による値引き・追加料金の計算も別の検証対象である。

今回のヘルプデスク回答が確認したのは、この4領域の計算規則が現行スキーマトロンで検証されていないという点である。JP PINTのすべてのスキーマトロン規則が存在しないという意味ではない。 公開資産には共有PINT規則および日本固有の規則がある。どの要件がどの検証ルールで保証されるかの全件対応表を作らなければ、実装の網羅性は断定できない。

さらに、計算規則の欠落とは別に、論理モデルや構文バインディングに対応しないUBL要素の扱い、要素の出現回数、条件付き必須、使用可能なコードなども、規定と検証実装を照合する必要がある。

前稿「https://www.sambuichi.jp/?p=17232[MLR（旧）からMLS（新）へ：Peppolのメッセージ応答は何が変わるのか]」では、両者が単なる名称変更ではないことを説明した。以下は、本稿の論点に関係する相違の要約である。

MLR（旧）の業務上の応答は論理的にはC4からC1へ向かう。ただしネットワーク上の逆方向の配送はC3、C2を経由する。MLS（新）では、C3自身が応答の送信主体となる。この違いが重要である。

MLS 1.1.0は、C3がメッセージ処理とC4への配送状況を通知するための仕様である。C3が適合性違反を理由に拒否する場合の RE と、C4への配送失敗を理由とする RE は、同じ応答コードであっても原因が異なる。拒否理由の特定と相手方への通知を混同してはならない。

MLSで認められる拒否理由には、XMLスキーマ違反、標準への適合性違反、致命的なスキーマトロン違反、文書バージョン等の不整合、配送失敗などが含まれる。warningのみを根拠とする拒否は認められない。

ここで問題なのは、MLSが状態通知の手順を整えても、JP PINTの仕様要求と検証資産との不整合は自動的には解決しない ことである。C3に検証・拒否の判断を求めるなら、その根拠と重大度が各プロバイダで再現できる形で定義されなければならない。

従来、仕様に適合する業務文書を作成する基本的な責任は送信企業（C1）にある。MLS導入によってその責任がC3へ全面的に移譲されるわけではない。また、従来のMLRでも受信側での適合性検証は想定されていたため、C3の検証がMLSによって初めて生まれたと表現するのも正確ではない。変更の核心は、従来はC4からC1への業務文書として通知されていた検証結果に代わり、C3自身がプロバイダ間のMLSで処理・配送状態を通知する点である。

しかしMLSでは、C3が適合性や配送結果を判断し、必要な場合は*RE*を送信する役割を担う。MLS 1.1.0は、RE の結果、メッセージに関する責任がC1/C2側へ戻ると説明している。文書作成責任と、受信側で適合性を判定し拒否理由を通知する役割を区別する必要がある。

ここで問われるのは、C3に判定を求めるのであれば、その根拠となる適合性基準を誰が、どの粒度で、どのような検証資産として提供するのか ということである。

公開スキーマトロンにBISの計算規則が実装されていなければ、C3 がそれを正しく実行しても違反を検出できない。一方、各 C3 が独自に BIS の規則を補えば、同一のメッセージがある C3 では受理され、別の C3 では拒否される可能性がある。

ただし、独自検証で誤りを発見したことと、それをMLS仕様上の正当な RE 理由として扱えることは同じではない。MLSには拒否理由の範囲が定められており、プロバイダの判断で無条件に拒否条件を拡張できるとは解釈すべきでない。

もし適合性判定の対象と方法が不明確なまま、各プロバイダに「利用可能な手段で最善の努力をする」とだけ求めるのであれば、共通の適合性を保証することはできない。2021年から指摘してきたBasic Rulesの問題は、MLSにおいてC3が受信・拒否の判断を担うことにより、実際の運用責任の問題となる。

必要なのは、どのJP PINT版と検証資産を適用するか、BIS本文・論理モデル・構文バインディングのどこまでが必須検証対象か、未対応UBL要素をどう扱うか、どの違反がMLSの RE を正当化するかを明確にすることである。

この問題は、現場のプロバイダが独自に努力すれば解決する類いのものではない。適合性を要求する仕様策定主体が、客観的・再現可能な判断基準を示さなければならない。

C3には、受信メッセージの識別、適用すべき版に応じた検証、C4への配送結果の把握、MLSの作成・送信、拒否理由の明示が関係する。C2にはMLSの受信、元メッセージとの対応付け、送信側への結果伝達等が関係する。MLSの送信条件についてはSBDHの MLS_TYPE 、送信先については MLS_TO、既定の動作についてはPeppol Network Policyとの整合が必要である。

品質保証上は、使用したXSD・スキーマトロン・JP PINTの版、実施した検証範囲、検出したルールIDと対象要素、配送失敗と規則違反の区別を追跡できる形で記録することが望ましい。ただし、これらを一律に新しい義務とみなすのではなく、MLS仕様で定められた必須事項と筆者の運用上の提案を区別しておきたい。