ペポルは，単一の中央サーバーに全ての文書を集める仕組みではない。

ペポルの基本構造は，4コーナーモデルである。

この構成では，送信者と受信者は，それぞれ自分が選択したAccess Pointに接続する。そして，Access Point間の相互接続により，送信者は受信者が契約しているAccess Pointを個別に意識せずに文書を送信できる。

したがって，ペポルは，標準化された相互接続ネットワークである。

一方，日本国内の既存EDI連携で必要となるのは，単なる配送だけではない。

JP PINT，中小企業共通EDI，流通BMS，業界EDI，Web-EDI，ERP，会計，販売管理では，それぞれ項目名，コード体系，データ粒度，業務上の意味が異なる。これらを単純に項目変換するだけでは，Seller，Buyer，Supplier，Customer，Payee，Tax Representative，EndpointID，適格請求書登録番号，取引先コード等の意味を正しく対応させることができない。

このため，日本版コアインボイス（構造化CSV）は，国内既存EDIとペポル/JP PINTをつなぐ「同時通訳モデル」として位置付けるのが適切である。

ここで，日本版コアインボイス（構造化CSV）は，単なる中間ファイルではない。

それぞれのEDIや業務システムが持つ項目を，請求書としての共通の意味に対応付けるためのセマンティックモデルである。

すなわち，日本版コアインボイス（構造化CSV）は，次の役割を担う。

この意味で，ペポルは文書を届ける相互接続ネットワークであり，日本版コアインボイス（構造化CSV）は，国内既存EDIとペポル/JP PINTの間で意味を通訳する共通モデルである。

流通BMSは，流通業における受発注，出荷，受領，返品，請求等の取引メッセージを標準化してきた重要な仕組みである。

しかし，ペポルのように，任意のAccess Point間で相互接続し，相手先のペポル IDをもとに到達性を解決するネットワークモデルとは異なる。

したがって，流通BMS利用企業が契約しているEDIサービスと，相手先が利用しているEDIサービスが異なり，そのプロバイダー間に中継又は相互接続の取り決めがない場合には，個別接続が必要となる可能性がある。

この課題は，次のように整理できる。

このため，流通BMSを直ちにペポルへ置き換えるのではなく，まずは請求書，仕入明細書，支払通知，消込参照等の領域からペポルと連携させるのが現実的である。

流通BMS:
　受発注，出荷，受領，返品，検収等

ペポル / JP PINT:
　請求書，仕入明細書，請求関連参照

日本版コアインボイス（構造化CSV）:
　流通BMSとJP PINTの間の同時通訳モデル

ZEDI:
　支払，入金消込，請求書番号・支払通知番号等の決済連携

中小企業共通EDIは，流通BMSよりも明確に，プロバイダー間連携を意識している。多プロバイダー問題を防止し，複数の共通EDIプロバイダー間を多対多に接続することを目指している。

この点では，中小企業共通EDIは，ペポルの4コーナーモデルに近い問題意識を持つ。

しかし，中小企業共通EDIのプロバイダー間連携は，ペポルとは別のネットワーク及び連携方式である。したがって，ペポルと同様の国際的なAccess Point制度，Participant ID，SMP/SML，認定Service Provider制度，統一的な到達性管理がそのまま整備されているわけではない。

このため，中小企業共通EDIとペポルの関係は，次のように整理するのがよい。

中小企業共通EDIが抱えていた「多プロバイダー問題」は，ペポルが解決しようとしている問題に近い。したがって，中小企業共通EDIをペポルと競合する別ネットワークとして見るのではなく，ペポルへ接続する国内業務ゲートウェイとして位置付けることが考えられる。

その際，日本版コアインボイス（構造化CSV）は，中小企業共通EDIとJP PINTの間で，項目，意味，コード，ID，業務文脈を通訳する役割を担う。

国内でしばしば見られるプロバイダー接続モデルは，実質的に3+1モデルである。

この構成では，一見するとプロバイダー間接続があるように見える。しかし，実際には，プロバイダーXとYの間に個別契約，個別設定，個別ID対応，個別フォーマット変換が必要となることが多い。

この構造は，20世紀のBBS型ネットワークに近い。各BBSの内部では標準的に利用できても，隣のBBSにメッセージを届けるには，個別のゲートウェイ又は相互接続対応が必要となる。

これに対して，ペポル型の4コーナーモデルでは，次の原則が重要である。

この違いは，中小企業にとって特に重要である。

中小企業が取引先ごとに別々のWeb-EDI，別々のEDIプロバイダー，別々のポータルに対応し続けるのであれば，デジタル化の効果は限定的である。ペポルを共通配送基盤として使えば，中小企業は自社が選択したプロバイダー又は業務アプリケーションを通じて，多様な取引先と接続できる可能性がある。

ただし，配送だけでは十分ではない。異なるEDIや業務システムの意味を通訳する共通モデルが必要である。その役割を担うのが，日本版コアインボイス（構造化CSV）である。

欧州のViDA（VAT in the Digital Age）は，日本でペポルを国内既存EDI連携基盤として検討するうえで重要な参考事例である。

ViDAは，単に電子インボイスのファイル形式を定めるものではない。電子インボイスとデジタル報告要件（Digital Reporting Requirements, DRR）を組み合わせ，VAT報告のリアルタイム化又は準リアルタイム化を進める制度的枠組みである。

ここで重要なのは，欧州全体で単一の中央EDIシステムを作るのではなく，次のような多層構造で進んでいることである。

EU ViDA:
　VAT制度，電子インボイス，デジタル報告要求

EN 16931:
　電子インボイスの共通セマンティック標準

ペポル:
　事業者・サービスプロバイダー間の相互接続ネットワーク

各国制度・国内プラットフォーム:
　国内税務報告，既存制度，認定プラットフォーム，政府ポータル等

企業側ERP・会計・既存EDI:
　実務処理，取引先固有業務，業界慣行

ペポル ViDA Pilotでは，ペポル eInvoice仕様及びペポル Networkが，ViDA下のeInvoicing及びDRRに対応できることを実証することが目的とされている。

ここから得られる示唆は，次の点である。

日本においても，ペポルを単なる請求書XMLの送信手段として扱うのではなく，既存EDI，税務，決済，監査証跡を接続する相互運用基盤として考えるべきである。

欧州のEN 16931の重要な点は，電子インボイスを特定のXML構文として定義しているのではなく，まず「core invoice model」というセマンティックデータモデルを定義していることである。

すなわち，

を，特定のファイル形式に先立って定義している。

そのうえで，UBL，CII等の構文に対してsyntax bindingを定義する。

この考え方は，日本国内の既存EDI連携にもそのまま適用できる。

日本では，JP PINT，流通BMS，中小企業共通EDI，業界EDI，Web-EDI，販売管理システム，会計システム等がそれぞれ異なる構文，項目名，コード体系，データ粒度を持っている。これらを個別に相互変換しようとすると，組合せの数だけ変換定義が必要になる。

しかし，日本版コアインボイスを中間の意味モデルとして定義すれば，各システムは相互に直接変換するのではなく，日本版コアインボイスへのbindingを定義すればよい。

日本版コアインボイスは，JP PINTの代替仕様ではない。

むしろ，JP PINTをペポルネットワーク上の正式な配送仕様としつつ，その前後，すなわちC1-C2間及びC3-C4間の業務システム連携で利用する共通論理モデルとして位置付けるべきである。

ペポルの標準が直接規定するのは，主としてC2-C3間の文書交換である。一方，C1-C2及びC3-C4間では，各国，各業界，各サービスプロバイダー，各業務アプリケーションの実装差異が残る。

この差異を吸収するために，日本版コアインボイスを定義し，その標準実装形式として構造化CSVを用いる。

ここで重要なのは，日本版コアインボイス（構造化CSV）を単なる中間ファイル形式としてではなく，国内電子インボイス連携の共通論理モデルとして位置付けることである。

この構成では，JP PINT，中小企業共通EDI，流通BMS，業界EDI，Web-EDI，ERP，会計，販売管理を相互に総当たりで変換する必要はない。

各形式は，日本版コアインボイス（構造化CSV）との対応関係だけを定義する。

JP PINTはペポルネットワークで配送するための標準構文であり，日本版コアインボイス（構造化CSV）は，ペポルの前後で既存EDI及び業務システムと接続するための国内共通データ表現である。

日本版コアインボイスゲートウェイは，ペポル Access Pointと，利用者向けパッケージ，業務アプリケーション，業界EDIサービス，Web-EDI等との間を接続するための仕組みである。

ここで対象となるのは，主としてC1-C2間及びC3-C4間のメッセージ交換である。この領域はペポルネットワークそのものの標準配送範囲ではなく，国内の業務システム，EDIサービス，パッケージベンダー，サービスプロバイダーが実装する接続領域である。

日本版コアインボイスゲートウェイでは，構文バインディングを用いて，各構文を日本版コアインボイスのセマンティックモデルに対応付ける。

この構成では，日本版コアインボイス（構造化CSV）は，単なるファイル変換の中間形式ではない。各構文に含まれる項目を，請求書としての共通概念に対応付けるための意味モデルである。

また，日本版コアインボイスのsyntax bindingをXBRLタクソノミで定義し，構造化CSVをxBRL-CSVとして表現することで，構造，意味，データ型，コード，検証規則をタクソノミとして管理できる。

これにより，システムごとの個別変換を積み上げるのではなく，変換仕様の維持管理をタクソノミの維持管理と連動させることができる。

中小企業や既存業務システムとの連携を考えると，XMLやJSONだけでは十分ではない。

多くの中小企業では，依然としてCSV，Excel，販売管理ソフト，会計ソフト，業務パッケージ，RPA，簡易データ連携ツールが実務の中心である。このため，ペポル/JP PINTの普及には，XMLを直接扱うだけでなく，CSVとして読み書きできる標準的な入出力形式が有効である。

ただし，ここでいう構造化CSVは，従来のように正規化された複数のテーブルをCSVとして出力し，必要に応じてJOIN操作で再構成する方式ではない。

従来の正規化モデルでは，例えば請求書ヘッダー，売手，買手，税率別内訳，明細行，支払条件，参照文書を，それぞれ別々のテーブルとして保持する。

invoice.csv
party.csv
tax_breakdown.csv
invoice_line.csv
allowance_charge.csv
document_reference.csv
payment.csv

この方式では，データベースとしては正規化されていても，利用者が請求書全体を扱うには，各テーブルをキーで結合する必要がある。すなわち，請求書ID，明細ID，税内訳ID，当事者ID等を用いたJOIN操作が必要となる。

これは，中小企業，Excel利用者，Pandas利用者，業務アプリケーション間のファイル連携にとっては重い。

本稿でいう構造化CSVは，この方式ではない。

構造化CSVは，請求書の階層構造を保持したまま，1枚のCSVとして表現する。ヘッダー，税率別内訳，明細行，支払情報，参照文書等は別テーブルに分割するのではなく，同一CSV内の行として表現し，階層を示すディメンション又は連番によって関連付ける。

日本版コアインボイス（構造化CSV）= 1枚のCSVに，請求書ヘッダー，税率別内訳，明細行，支払情報，参照文書等を保持する形式

この形式であれば，Pandas等のライブラリで1つのCSVファイルを読み込み，record_type，dInvoice，dTaxBreakdown，dInvoiceLine 等の列を条件として抽出するだけで，必要なデータを取得できる。

JOIN操作を前提にした正規化データではなく，階層構造を持ったままフラットな表として処理できる点が，構造化CSVの特徴である。

構造化CSVの考え方は，Ledger Explorerのデモにも表れている。

https://www.sambuichi.jp/ledger/?view=tidy&month=2021-04&lang=ja&mode=server

Ledger Explorerでは，構造化CSV，すなわち階層型のtidy dataを基礎データとして位置付けている。仕訳帳，総勘定元帳，試算表，貸借対照表，損益計算書などの表示は，別々の意味を持つデータを再作成しているのではなく，同じ構造化CSVデータから導出される表示である。

この考え方は，請求書データにもそのまま適用できる。

すなわち，日本版コアインボイス（構造化CSV）をsource of truthとし，そこから必要に応じて次の表示又は構文を生成する。

ここで重要なのは，表示形式や出力形式が複数あっても，意味の基礎は同一の構造化CSVにあるという点である。

Ledger Explorerでは，Structured CSV viewが基礎となり，Journal，General Ledger，Trial Balance，Balance Sheet，Profit and Loss等の表示は同じデータセットから導出される。この方式により，複雑なJOINで意味を再構成するのではなく，構造化CSVに保持された文脈をもとに複数の表現を生成できる。

請求書でも同様に，日本版コアインボイス（構造化CSV）を基礎データとすれば，JP PINT，既存EDI，ERP，会計，支払，消込，監査データを，同じ意味モデルから生成又は受入れできる。

日本版コアインボイスを構造化CSVとして表現する場合，重要なのは，請求書データを正規化された複数テーブルに分解しないことである。

従来のデータベース設計では，請求書を次のような複数テーブルとして管理することが多い。

この方式では，請求書全体を再構成するために，請求書番号，明細番号，税内訳番号，当事者番号等をキーとしてJOIN操作を行う必要がある。

しかし，構造化CSVの目的は，このような正規化テーブル群をCSVとして外部出力することではない。

構造化CSVは，請求書が本来持っている階層構造を保持したまま，1枚のCSVにフラットに展開する形式である。

この階層を，複数のCSVファイルに分割するのではなく，1枚のCSVの中で，ディメンション列と連番によって表現する。

構造化CSVは，xBRL-CSVの考え方に基づく。

CSV本体には，請求書番号，明細番号，税内訳番号などのディメンション列と，金額，日付，コード，名称，数量などの事実列を記録する。

JSONメタデータには，CSV列の意味，データ型，ディメンション，タクソノミ上のコンセプトとの対応を定義する。

CSV:
実データを記録する1枚の表

JSONメタデータ:
列の意味，ディメンション，データ型，タクソノミ対応を定義

XBRLタクソノミ:
概念，ラベル，定義，コード，検証規則を定義

この構成により，CSVは単なる文字列の表ではなく，意味を持った構造化データとなる。

次は，日本版コアインボイスを1枚の構造化CSVとして表現した簡略例である。

構造化CSVでは，1行に1つの事実又は観測値を記録する。

各行は，その事実が請求書ヘッダーに属するのか，税率別内訳に属するのか，明細行に属するのか，支払情報に属するのかを，ディメンション列で示す。

例えば，次のような列を用いる。

このように，階層を表す列と，値を表す列を同じCSV内に保持する。

このCSVでは，請求書ヘッダー，売手，買手，税率別内訳，請求明細，明細税情報，参照文書，支払情報が，すべて1枚のCSVに記録されている。

重要なのは，空欄を許容している点である。すべての行がすべての列に値を持つ必要はない。

例えば，請求書ヘッダー行では，invoiceNumber，issueDate，invoiceTypeCode，currencyCode に値が入る。一方，明細行では，lineID，itemName，invoicedQuantity，unitPriceAmount，lineExtensionAmount に値が入る。

それぞれの行は，dInvoice，dInvoiceLine，dTaxBreakdown 等のディメンションによって，どの階層に属するかが示される。

この形式であれば，Python Pandas等の一般的なライブラリで，1枚のCSVをそのまま読み込むことができる。

この処理では，複数CSVを読み込んでJOINする必要はない。
請求書全体が1枚のCSVに保持されており，必要な部分を列とディメンションで抽出するだけでよい。

構造化CSVでは，請求書ヘッダー表と明細表をJOINして請求書を復元するのではない。

すでに1枚のCSVの中に，請求書と明細の関係が保持されている。

例えば，明細行は dInvoice と dInvoiceLine で識別できる。

税率別内訳は dTaxBreakdown で抽出できる。

このように，構造化CSVでは，JOINではなく，フィルタ，グループ化，ピボット，集計によってデータを扱う。

これは，Excel，Pandas，R，BIツール，ETLツールとの相性がよい。

構造化CSVでは，請求書ヘッダー，税率別内訳，請求明細が1枚のCSVに含まれている。

そのため，請求明細の金額を税区分・税率別に集計し，文書に記載されている税率別内訳と比較する処理を，Pandasで簡潔に記述できる。

ここでは，上記の構造化CSVを対象とする。

このCSVでは，税率別内訳は dTaxBreakdown を持つ行として記録され，請求明細は dInvoiceLine を持つ行として記録されている。

したがって，1枚のCSVから次の二つを抽出すればよい。

次のPythonプログラムは，構造化CSVを1枚読み込み，明細行を税区分・税率別に合計し，文書に記載された税率別内訳と比較する。

この処理の流れは，次の4段階である。

税額については，実務上，端数処理として切捨て，切上げ，四捨五入のいずれもあり得る。

そのため，この例では，次のいずれかに一致すれば税額は正しいものと判定している。

実行結果は，次のようになる。

税区分 AA，税率 8% の明細行合計は 3010 であり，文書に記載された課税対象額 3010 と一致している。

税額は，3010 × 8% = 240.8 である。
この場合，切捨てでは 240，切上げ及び四捨五入では 241 となる。文書に記載された税額は 240 であり，切捨て計算と一致するため，OK は True となる。

税区分 S，税率 10% についても，明細行合計 12320，記載課税対象額 12320，記載税額 1232 が一致している。

この例で重要なのは，請求書ヘッダー，税率別内訳，請求明細が，別々のCSVファイルに分かれていないことである。

従来の正規化モデルでは，例えば次のような複数テーブルを用意し，請求書IDや明細IDでJOINして検証する必要がある。

これに対して，構造化CSVでは，すべての情報が1枚のCSVに記録されている。

そのため，処理は次のように単純になる。

このように，構造化CSVは，複数の正規化テーブルをJOINして請求書を復元する方式ではない。

1枚のCSVの中に階層構造を保持したまま，Pandas等の一般的なライブラリで簡単に検証，集計，変換できることが特徴である。

構造化CSVと正規化CSVの違いは，次のように整理できる。

したがって，請求書の構造化CSVは，RDBの外部出力ではない。

請求書の階層構造を保持したまま，1枚のCSVとして交換し，Pandas等で簡単に読み書きできる形式である。

ペポルネットワークでは，JP PINT UBLを送信構文として使用する。

一方，C1-C2間及びC3-C4間，すなわち利用者の業務システムとペポル Access Pointとの間では，日本版コアインボイス（構造化CSV）を使用できる。

この場合，日本版コアインボイス（構造化CSV）からJP PINT UBLへのsyntax bindingを定義する。

例えば，次のような対応である。

このように，日本版コアインボイス（構造化CSV）は，JP PINTを置き換えるものではない。
JP PINTへ変換する前段，及びJP PINTから受信した後段で，既存業務システムが扱いやすい共通形式として機能する。

請求書の構造化CSVは，正規化された複数CSVファイル群ではない。

また，単なる明細一覧CSVでもない。

請求書ヘッダー，売手，買手，税率別内訳，明細，支払，参照文書といった階層構造を，1枚のCSVに保持する形式である。

この形式であれば，中小企業の業務システム，Excel，Pandas，販売管理，会計ソフト，ペポル Access Pointが，同じ請求書データを扱いやすくなる。

日本版コアインボイス（構造化CSV）は，JP PINT，中小企業共通EDI，流通BMS，業界EDI，Web-EDI，ERP，会計，販売管理をつなぐ同時通訳モデルとして有効である。

ペポルを国内既存EDI連携の共通相互接続ネットワークとして使う場合，いきなり全ての業務文書をペポル化するのは現実的ではない。

段階的には，次の順序が考えられる。

最初に取り組むべきは，請求書及び仕入明細書等である。

通常の売手発行請求書はJP PINT Invoiceとして扱う。買手作成の仕入明細書等については，通常のJP PINT Invoiceに無理に当てはめるのではなく，JP BIS Self Billing Invoiceの適用を検討する。

この段階では，既存EDIの受発注，出荷，検収，返品等はそのまま残してよい。

受発注・出荷・検収:
　既存EDI

請求書:
　JP PINT Invoice

仕入明細書等:
　JP BIS Self Billing Invoice

C1-C2 / C3-C4:
　日本版コアインボイス（構造化CSV）

支払・消込:
　ZEDI又は会計システム連携

次に，ペポル Invoice又はSelf Billing Invoiceから，既存EDI文書への参照を明確にする。

例えば，次の参照である。

この方式では，ペポル Invoiceに全ての業界EDI明細を詰め込むのではなく，ペポル文書を基準文書として，既存EDI文書又は構造化CSV等の補助データを参照する。

請求書だけでなく，注文，注文応答，出荷案内，受領，検収，インボイス応答，支払通知等について，必要な国内プロファイルを整備する。

ペポルには，Billingだけでなく，Post Award領域の文書仕様が存在する。したがって，日本国内でも，将来的には次の文書を検討対象にできる。

ただし，この段階では，単なるXML変換では不十分である。日本の商慣行，締め請求，返品，値引，リベート，検収差異，仕入明細，媒介者交付特例，卸売市場特例等を，ペポルのsemantic modelとどう対応させるかを検討する必要がある。

欧州ViDAでは，電子インボイスは単なる取引文書ではなく，デジタル報告要件，税務，監査証跡と結び付く基盤となる。

日本でも，将来的に電子インボイス，支払情報，消込情報，監査データ，税務報告が連携していく場合，個別XML仕様だけでは不十分である。

必要なのは，次の三層である。

セマンティック層:
　日本版コアインボイス

構文層:
　JP PINT, Self Billing, 流通BMS, 中小企業共通EDI, 構造化CSV, XBRL-CSV

配送層:
　ペポル, 既存EDI, API, ファイル連携, ZEDI

この三層を分けることで，制度変更，税率変更，業界固有項目追加，ペポル仕様変更，CSV項目変更に柔軟に対応できる。

ペポルを国内既存EDI連携基盤として利用するには，次の課題を整理する必要がある。