国際標準？DX政策？ Peppol Service Provider開発の裏側！

こんにちは！弥生でエンジニアをしている宮崎です。
この記事は弥生 Advent Calendar 2025 の20日目の記事です。

今回は私が携わっているPeppol Service Provider（以下Peppol SP）の開発業務についてご紹介します。
少し変わった開発現場の様子をお届けしますので、Peppolってなに？という方も最後までお読みいただければ幸いです。

デジタルインボイス&Peppolとは？

デジタルインボイスとは、請求書を紙やPDFではなく構造化されたデータとして送受信する仕組みです。
手入力や転記を減らし、経理処理を自動化できるのが大きな特徴です。

このデジタルインボイスを支える共通基盤として、Peppolという国際標準仕様が採用されています。
Peppolのネットワーク上であれば、世界中で同じルールに基づいて請求書データをやり取りできるように定められています。
メールを利用する際、相手のメールアドレスさえわかっていれば、使用しているメールソフトに関わらずメッセージをやり取りできますね。
Peppolもこれと似た仕組みを実現している考えると理解しやすいかもしれません。

このやり取りを仲介する役割を担うのがPeppol Service Provider（Peppol SP）です。
簡単に言うとメールサーバーのような役割で、デジタルインボイスをPeppolネットワーク上で安全・確実に送受信できるように運用しています。

より詳しく知りたい方は以下をご覧ください。

www.yayoi-kk.co.jp www.yayoi-kk.co.jp

ここが違うよPeppol SP

ここからは、Peppol SP開発の特徴、一般的なソフトウェア開発のプロジェクトではなかなか経験しないかも？と思うポイントをご紹介します！

国際標準仕様への対応

Peppolは国際的に運用されている仕組みのため、世界中の事業者が同じ仕様に則ってシステムを動かすことが求められます。
そのため、仕様が更新された場合は、全てのService Providerが足並みをそろえて対応する必要があります。
例えば通信方式や請求書フォーマットに変更があれば、各社が同時期に改修・検証を行い、ネットワーク全体の整合性を保ちます。
定められた期間中に仕様変更に対応しないと送受信ができなくなってしまうため、責任の大きい仕事です。

また、当然ながら仕様は全て英語で公開されています。
私はこれまでAWSやOSSのドキュメントを英語で読むことはありましたが、英語の仕様書に沿った開発の経験はほとんどありませんでした。
始めの頃は英文を読むのにかなり時間がかかっていましたが、少しずつ慣れてきたように思います。
AI翻訳（最近精度が上がってとても嬉しい）も活用しつつ、「この仕様はこういう解釈でいいのか？」などメンバー同士で相談しながら開発を進めています。

行政との関わり

Peppolの日本版規格であるJP PINTはデジタル庁が管轄しています。
そのため、ときには開発者としてデジタル庁からのヒアリングを受けたり会議に出席することも。
技術者が直接やり取りすることで、新しい仕様案の実現可能性や必要な対応期間などを行政に直接フィードバックすることができます。
正直かなり緊張しますが、政策渉外*1の方々にもサポートしていただきながら対応しています。
行政とのやり取りを通して、国の政策としてデジタルインボイスの普及を目指していることを実感でき、貴重な経験だと感じます。

社内事例の少ない技術要素

使用している技術要素も社内の他プロジェクトとは少し異なる部分があります。
例えばPeppol SPでは、送受信に関する情報の保管のためにAWSのDocument DBを使用しています。
使用しているOSSライブラリとの互換性を重視しMongoDB互換のDocument DBを採用したのですが、社内ではほとんど使用実績がなく、一から調査や検証が必要になることもしばしば。
個人的に印象に残っている業務は、DR（災害復旧）を実現するためDocument DBのバックアップやレプリケーション方法を検討し実現させたことです。
Amazon RDSのようにバックアップから他リージョンへのレプリケーションまでを実現する仕組みが確立されていないため、自分たちで設計する必要がありました。
参考にできる情報が少なく大変でしたが、試行錯誤する面白さや完成したときの達成感を味わうことができました。

チームメンバーの声

ここでは、一緒に開発してきたメンバーから見たPeppol SPについてご紹介します。
技術的な面白さや今後の展望についてコメントいただきました。

エンジニア Uさん

Peppol SPの開発では、一般的なアプリケーション開発ではあまり触れることのない技術領域に関わる機会が多くあります。
例えば、PeppolネットワークではSMP（Service Metadata Publisher）とSML（Service Metadata Locator）という仕組みを通じて、デジタルインボイス送信先のエンドポイント情報を動的に取得します。
この仕組みの裏側では、DNSベースの名前解決や証明書の信頼チェーンなど、基盤技術に依拠した動作が行われています。
通常のアプリケーション開発では、抽象化されたライブラリやフレームワークを通じて扱われるため意識されにくい部分ですが、Peppol SPの開発では、通信・認証・標準仕様がどのように機能するかを構造的に理解しながら設計していくことが求められます。
こうしたシステムの奥深さや技術標準の構造そのものに向き合える点は、開発者としてとても興味深いと感じています。

エンジニア Iさん

EUではViDAパッケージ*2により、今年から加盟国の電子インボイスの義務化（紙、PDFはNG）が可能になり、2030年には国境をまたぐ取引での電子インボイス利用と、税務当局へのデジタル報告（ほぼリアルタイム）が必須となります。
グローバルなデータ標準化が進む中、Peppolはその実装の中心的な役割を担うことになる…かも？
弥生としても、こうした技術動向をしっかりキャッチアップしていきます。