ULP（Universal Ledger Protocol）とは：請求書をシステム間で安全にやり取りする仕組み
ULPとは
ULP（Universal Ledger Protocol） は、請求書などのビジネス文書を、異なる2つのシステムの間でHTTPを使って交換するためのオープンなプロトコルです。株式会社グリッドワークスが仕様とリファレンス実装を公開しています（MITライセンス）。
文書は「エンベロープ」という入れ物に包まれ、前のエンベロープのハッシュ値と連鎖します。これにより、やり取りした文書があとから書き換えられていないかを確認できます。現在の仕様はバージョン1.0.0（Draft）で、最初に対応している文書は請求書です。
なぜ請求書の交換が問題になるのか
請求書のやり取りは、いまも次のような方法が混在しています。
- PDFをメールで送る：人が読むには便利ですが、受け取った側のシステムに自動で取り込めません。
- CSVで出力して取り込む：システムごとに列の並びや名前が違うため、そのたびに変換（マッピング）が必要です。
- EDI：標準化されていますが、導入や運用の費用が大きく、中小企業には負担になりがちです。
さらに、電子で受け取った請求書は、2024年1月から電子データのまま保存する義務があります（電子帳簿保存法）。データが改ざんされていないことを示す手段も必要です。
ULPの仕組み
エンベロープ
ULPでは、請求書のデータ（ペイロード）を、次のような項目を持つエンベロープで包んで送ります。
| 項目 |
内容 |
envelope_id |
エンベロープの一意なID |
envelope_type |
文書の種類（現在の仕様で定義済みなのは invoice） |
payload |
文書の本体（請求書のデータ） |
sender / receiver |
送信者・受信者の組織 |
parent_hash |
直前のエンベロープのハッシュ値（最初は null） |
hash |
このエンベロープのハッシュ値 |
timestamp |
タイムゾーン付きの日時 |
ハッシュチェーン
ハッシュ値は、次の式で計算されます。
hash = SHA-256( canonical_json(payload) + parent_hash )
canonical_json は、キーの順序や空白を一意に揃えたJSONです。同じ内容なら、誰が計算しても同じハッシュ値になります。こうして各エンベロープが前のエンベロープのハッシュ値を含むため、途中の文書を1つ書き換えると、それ以降のハッシュ値がすべて合わなくなります。Gitのコミット履歴に近い考え方です。
ノードには全体を検証する監査（audit）の機能があり、チェーンを先頭から再計算して、改ざんされた位置を特定できます。
ブロックチェーンとの違い
ULPはブロックチェーンではありません。マイニングも合意形成もなく、手数料（ガス代）もかかりません。ノードの運営者が分かっている前提で、「合意」ではなく**「改ざんの検知」**を目的にしています。
請求書のデータ（INVOICEスキーマ）
請求書のペイロードは、JSONで次のように定義されています。
- 請求書番号、状態（下書き・発行済み・支払済み・取消）、発行日、支払期限、通貨
- 送信者・受信者の名称と住所、送信者の適格請求書発行事業者登録番号（任意項目）
- 明細（品名・数量・単価・金額・税区分・税率）
- 税率ごとの合計額と税額（標準税率10%・軽減税率8%・非課税など）
- 小計・消費税額・合計、振込先の口座情報
人が読む帳票ではなく、システムがそのまま取り込める構造化データであることが、PDFやCSVとの大きな違いです。
インボイス制度・Peppol・電子帳簿保存法との関係
ULPの仕様は、これらの制度に対応できるように設計されています。ただし、仕様に書かれている範囲は次のとおりです。
- インボイス制度：発行者名称、登録番号、取引年月日、取引内容、税率ごとの合計額、消費税額、受領者名称を、請求書のスキーマに対応づけています。登録番号は任意項目のため、記載するかどうかは送信側の運用になります。
- Peppol：請求書の主な項目（請求書番号、発行日、支払期限、通貨、合計など）をPeppol BIS Billing 3.0の項目に対応づけています。ただし、これは「対応づけられる」ことを示すもので、Peppolのネットワークに直接つながるものではありません。
- 電子帳簿保存法：ハッシュチェーンによる改ざんの検知と、任意のタイムスタンプ（RFC 3161に対応した時刻認証局への定期送信、標準では無効）を備えています。一方、同法の要件（真実性・可視性・検索性）を項目別に満たすことを示す対応表は、仕様にはありません。
つまり、ULPを使えば電子帳簿保存法の要件をすべて満たせるわけではありません。ULPは、データの真実性を支える技術の一部として位置づけ、保存や検索の要件は、受け取った側のシステムと運用で満たす必要があります。
ULPの限界
仕様自身が、ULPを「改ざんを検知できる（tamper-evident）が、改ざんを防げる（tamper-proof）わけではない」と説明しています。
- 悪意のあるノード運営者は、台帳全体を書き換えることができます。より強い保証が必要な場合は、送信者の署名（Ed25519）を併用します。
- ハッシュチェーンだけでは、文書の作成時刻を証明できません。時刻の証明が必要な場合は、任意のタイムスタンプ機能を有効にします。
- ペイロードは暗号化されません。通信の保護はTLSに依存します。
WORKSの請求書でのULP
WORKSの請求書機能は、ULPに対応しています。
- 請求書の詳細画面の**「ULP送信」**ボタンを押すと、請求書の内容（請求書番号、発行日、明細、税区分、振込先、発行者の登録番号など）がエンベロープとして送信されます。
- 送信すると、エンベロープのIDとハッシュ値が請求書に記録されます。
- 受け取る側は、ULP受信箱で、自分宛てのエンベロープを一覧し、内容を確認できます。
請求書を確定すると内容は変更できず、訂正は「差替」で別番号の請求書として起票する仕組みと、ULPの「改ざんを検知できる」仕組みは、同じ方向を向いています。
試してみる
ULPの仕様書、APIリファレンス、TypeScriptのリファレンス実装は、GitHubで公開されています。サインアップ不要で試せる公開ノードもあります。
よくある質問
ULPとは何ですか？
Universal Ledger Protocolの略で、請求書などのビジネス文書を、異なる2つのシステムの間でHTTPを使って交換するためのオープンなプロトコルです。文書はエンベロープに包まれ、前のエンベロープのハッシュ値と連鎖するため、あとからの書き換えを検知できます。株式会社グリッドワークスが仕様を公開しています。
ULPはブロックチェーンですか？
いいえ。マイニングも合意形成もなく、手数料もかかりません。ノードの運営者が分かっている前提で、合意ではなく改ざんの検知を目的にしたハッシュチェーンです。
ULPを使えば電子帳簿保存法に対応できますか？
ULPだけで要件をすべて満たすわけではありません。ULPはハッシュチェーンによる改ざんの検知と、任意のタイムスタンプを備えますが、同法の要件を項目別に満たすことを示す対応表は仕様にありません。保存や検索の要件は、受け取った側のシステムと運用で満たす必要があります。
ULPはPeppolと同じものですか？
いいえ。別のプロトコルです。ULPの請求書スキーマは、主な項目をPeppol BIS Billing 3.0の項目に対応づけられますが、Peppolのネットワークに直接つながるものではありません。
他の記事
Markdown版