Views: 2
OpenPeppol Service Desk への問題提起：JP PINT 1.1.3 Syntax Binding の曖昧な Selector と機械処理上の課題
2026-10-29
1. はじめに：問題は「人間に読めること」と「機械が実行できること」の違い
デジタルインボイスでは、XML 文書の値を意味モデル上の Business Group（IBG）や Business Term（IBT）に正しく対応付ける必要がある。この対応関係を定義するのが Syntax Binding（構文結合）である。
オープンペポルの JP PINT 1.1.3 を確認したところ、同じ XML 要素を異なる業務概念に振り分ける Selector（選択条件）について、 XPath 2.0 として実行すると意図した結果にならない記述が存在する。また、公開された Selector の言語、文法、評価コンテキスト、型の扱い等を規範的に定義した資料を確認できなかった。
これは単なる表記の修正にとどまらない。実装者が個別に「本来はこういう意味だろう」と解釈し直さなければならないとすれば、異なるソフトウェアの間で同じインボイスを異なる意味に変換する可能性がある。
この問題をオープンペポルの Service Desk に報告した。最初は日本の Peppol Authority への連絡を求める回答だったが、共通 PINT にも問題があることを説明したところ、案件は再オープンされた。
|
Note
|
再オープンは技術的な是正や共通 PINT 担当チームへの正式な移管が決まったことを意味しない。 |
2. Selector の具体的な問題
2.1. 返金と追加請求：Boolean 値の比較
JP PINT の Invoice Syntax Binding では、文書レベルの返金と追加請求を同じ cac:AllowanceCharge から選択する。
| 意味モデル | 公開Selector | 想定される区別 |
|---|---|---|
|
IBG-20：文書レベルの返金 |
|
false の場合 |
|
IBG-21：文書レベルの追加請求 |
|
true の場合 |
人間には意図を推察できる。しかし XPath 2.0 では、false と true を括弧なしで記述すると、Boolean 定数ではなく名前テストとして解釈される。XPath 2.0 の Boolean 関数を呼び出すには false() と true() が必要である。
cbc:ChargeIndicator = false()
cbc:ChargeIndicator = true()2.2. 追加添付資料：DocumentTypeCode が存在しない場合
JP PINT の IBG-24（ADDITIONAL SUPPORTING DOCUMENTS）には、次の Selector が掲載されている。
cbc:DocumentTypeCode != 130ところが、次のように DocumentTypeCode がない追加資料参照を考えてみよう。
<cac:AdditionalDocumentReference>
<cbc:ID>DOC-001</cbc:ID>
</cac:AdditionalDocumentReference>上記の XPath 比較では、左辺の要素が存在しないため、一般比較の結果は false となり、DocumentTypeCode が 130 ではないけれど対象とはならない。130 ではない文書を選びたいという意図であれば、この書き方では要素欠落の場合を拾えない。
「コード130以外を含め、コード自体がない場合も選択する」という要求なら、例えば次の表現となる。
not(cbc:DocumentTypeCode = '130')一方、「コードがないものだけを選択する」なら次のようになる。
not(cbc:DocumentTypeCode)この二つは同義ではない。 どちらが正しいかは XPath の書き方だけでは決定できず、まず PINT の Business Group の意味的な選択条件を明確にする必要がある。
2.3. 共通 PINT の Credit Note にも存在する問題
問題は JP PINT だけではない。共通 PINT の Credit Note Syntax Binding では、IBG-24 に次の Selector が記載されている。
cbc:DocumentTypeCode != 130 or 50共通PINTでは、コード 130 は請求対象オブジェクトの識別、50 はプロジェクト参照との区別に用いられている。ところが XPath 2.0 では、上記の式は概念上、次のように評価される。
(cbc:DocumentTypeCode != 130) or 50数値 50 の実効 Boolean 値（Effective Boolean Value）は true である。したがって式全体は常に true となり、参照の種類を振り分ける条件として機能しない。
もし両コードを除く意図であれば、例えば次のように定義できる。
not(cbc:DocumentTypeCode = ('130', '50'))ただし、DocumentTypeCode が欠落している場合だけを対象とするのであれば not(cbc:DocumentTypeCode) になる。ここでも、業務上の意味を確定しなければ適切な Selector は決まらない。
3. 以前に報告した Selector の問題と先行記事
今回の報告に先立ち、JP PINT の Syntax Binding における Selector の問題について、オープンペポルの Service Desk に以下の3件を報告している。
-
PEPPOL-22903：
cac:TaxTotalの Selector における要素名、属性名、参照位置の問題 -
PEPPOL-22907：
cac:PartyTaxSchemeの Selector における複合要素と子要素の値の混同 -
PEPPOL-23055：SEPA 識別子の Selector における要素名の不整合
これらの指摘と Help Desk からの回答については、次の記事で詳しく紹介している。
また、Selectorの不正確な記述については、今回のHelp Deskへの報告以前から問題を指摘してきた。
これらの記事では、公開された Selector を XPath として実行した場合に、意図した XML 要素を選択できない問題を具体的に解説している。
特に、同じXML要素が複数の Business Term に対応する場合には、選択条件を正確に定義しなければ、XML構文から意味モデルへの対応関係を一意に特定できない。
今回の報告は、これらの先行案件について重複した是正要求を行うものではない。
問題が繰り返し現れている背景として、PINT Syntax Binding における Selector の記述言語と評価意味論が規範的に定義されていないことに着目したものである。
個別の Selector を修正するだけでは、同種の問題が再発する可能性が残る。
そのため、今回は共通 PINT において XPath 2.0 を正式な Selector 言語として採用し、その評価規則を明確化するとともに、親階層から継承される選択条件を含めた完全な XPath を提供することを提案している。
4. なぜ共通 PINT の仕様問題なのか
Syntax Binding は、構文データと意味モデルとの対応を、実装間で共有するための仕様である。Selector が XPath ではなく独自の簡略記法であるとしても、その場合は文法と評価規則を正式に定義しなければならない。
例えば cbc:DocumentTypeCode != 130 or 50 を、人間は「130 でも 50 でもない」と読み替えられるかもしれない。しかし、それは公開された式そのものから一意に決まる意味ではない。また、cbc:ChargeIndicator = false を Boolean の比較だと理解できても、XPath プロセッサが同じように解釈するとは限らない。
したがって論点は、既存の表現を人間が理解できるかどうかではない。公開仕様だけを根拠に、独立した実装が同じ XML 要素を同じ Business Term へ対応付けられるか である。
JP PINT と共通 PINT の両方で例が確認できる以上、日本だけで修正しても共通仕様側の問題は残る。各国のPINTへの展開も考えれば、共通 PINT の定義を改訂し、影響する各仕様へ整合的に反映する必要がある。
5. 改善提案：XPath 2.0 の正式採用と完全 XPath の提供
5.1. Selector の意味を規範的に定義する
第一に、Selector の表現言語として XPath 2.0 を正式に採用することを提案した。少なくとも、次を規定する必要がある。
-
評価対象となるコンテキストノード
-
cbc、cac、ubl等の名前空間の割当て -
値の型、文字列・数値・Boolean の比較方法
-
任意要素が存在しない場合の扱い
-
論理演算子、比較演算子、括弧の優先順位
XPath 2.0 以外を採用する場合でも、同等の規範的な定義が不可欠である。
5.2. 親の条件を継承した完全 XPath を提示する
現行の Syntax Binding は階層ごとに要素名と条件を分けて記載する。そのため末端の Business Term を抽出する際、実装者は上位の Selector を自ら組み立て直す必要がある。
例えば、IBT-018（Invoiced object identifier）は、親の cac:AdditionalDocumentReference に対する cbc:DocumentTypeCode = '130' という条件を引き継ぐ。
/ubl:Invoice/cac:AdditionalDocumentReference[
cbc:DocumentTypeCode = '130'
]/cbc:IDIBT-018-1（Identification scheme identifier）では、さらに @schemeID を選択する。
/ubl:Invoice/cac:AdditionalDocumentReference[
cbc:DocumentTypeCode = '130'
]/cbc:ID/@schemeIDここで ubl は UBL Invoice の名前空間に束縛する。XPath 式を実行する際には、各接頭辞の正しい名前空間割当てが必要である。
各 IBG・IBT について、このような完全 XPath を階層的な定義から生成して公開すれば、人間とソフトウェアが同一の選択条件を参照できる。個別に維持する第二のマッピング表を作るのではなく、既存の階層的 Syntax Binding から自動生成する方式が望ましい。
5.3. 2022年に作成した参考実装
筆者は2022年に、JP PINT 1.0 の Syntax Binding を、上位 Selector を含む完全 XPath として参照できる表示を作成した。意味モデルから UBL への参照と、UBL から意味モデルへの参照の両方を提供している。
これは現行の PINT 仕様の正規仕様ではなく、完全 XPath の表示が実現可能であることを示す参考実装である。
6. Help Deskとのやり取りと現在の状況
今回の問題は、オープンペポルの Service Desk に「JP PINT 1.1.3: Ambiguous Syntax Binding Selectors and Missing Formal Selection Semantics」として報告した。
報告では、JP PINT の誤った Boolean Selector、DocumentTypeCode の欠落時の扱い、共通 PINT の Credit Note の or 50 の問題に加え、Selector 言語の規範的な定義と完全 XPath の提供を提案した。
Service Desk からの最初の回答は、日本の Peppol Authority に連絡するよう求めるものだった。案件は一旦 Done になった。
これに対し、問題の原因は日本独自の拡張に限定されず、共通 PINT の Syntax Binding にも存在するため、共通 PINT の仕様担当側で検討すべきだと説明し、再検討を依頼した。
2026年10月29日には、案件の状態が Reopened に変更されたことを確認した。これは再検討の入り口であり、現時点で修正方針、担当チームへの移管、改訂版への反映時期が確定したことを示すものではない。
なお、以前にも Selector に関して次の問題を報告している。今回の報告は、これらについて重複した是正要求を行うものではなく、問題が繰り返し現れている背景として参照したものである。
-
PEPPOL-22903：
cac:TaxTotalの Selector -
PEPPOL-22907：
cac:PartyTaxSchemeの Selector -
PEPPOL-23055：SEPA識別子のSelector
7. おわりに：PINTの機械処理可能性をさらに高めるために
オープンペポルの PINT は、標準化された意味モデル、構文結合、検証規則を組み合わせた、先進的な機械処理可能インボイスの枠組みである。
その強みを一層生かすには、仕様書の選択条件が人の解釈に依存せず、ソフトウェアから直接評価できることが重要である。XPath 2.0 の意味論を正式に規定し、親要素の選択条件を継承した完全 XPath を提供すれば、XML と意味モデルの対応を、より正確かつ再利用可能なものにできる。
今回の要望は、JP PINT のみの表記修正ではない。共通 PINT を含め、「人間が理解するBusiness Term」と「ソフトウェアが選択するXML要素」が常に一致する仕様 へと進化させるための提案である。
7.1. 参考資料
|
Note
|
この記事の Help Desk の状態および日時は、2026年10月29日までに受け取った通知に基づく。今後の回答・是正方針を確認したものではない。公開仕様のページは更新される可能性があるため、参照時には版と公開日を確認していただきたい。 |
コメントを残す