Views: 107
Peppol NAPTR移行とAPプロバイダーの対応
2025-05-25
Peppolネットワークでは、SMLとDNSを用いたParticipant解決方式が2025年より大きく変わりました。この変更は、2025年5月1日から移行期間が開始されており、すでにその初日を過ぎています。2025年11月1日の実装完了目標までに、PAと調整し、EIPAを中心とした運用テストを完了させることが、デジタルインボイスの安定的な稼働の前提条件となります。
重要:eDeliveryの技術仕様が改訂されています。
2025年の改訂により、SMPのアクセス方式、DNSレコード構成、Participant Identifierの扱いなどに重大な変更があります。
特に、APプロバイダーは、CNAME[1]方式からNAPTR[2]方式への移行に伴い、Access Point(AP)プロバイダーにはHTTPS対応、SMP問い合わせ手順の変更、DNS構成の理解など、多方面の技術的対応が求められます。
eDeliveryの技術標準文書が改訂されています。次のページを確認してください。
このページのLinkで示される https://docs.peppol.eu/edelivery/ は次の詳細ページへのリンクです。
OpenPeppol eDEC Specifications
CNAMEからNAPTRへの移行についての解説が次の文書です。
Peppol CNAME to NAPTR Migration Process v1.0
2025-11-01から有効になるSML(v1.3.0)及び SMP(v1.4.0)で変更後の方式が規定されています。
本記事では、移行による主な変更点、NAPTRレコードの技術仕様、SMLとDNSの関係、公式仕様文書からの引用を交えて解説します。
1. 主な変更点:CNAMEからNAPTRへ
1.1. POLICYの変更
2.1.1 Changes to POLICY 1
The maximum length of Participant Identifiers and Party Identifiers was increased from 50 to 130 characters.
Participant IdentifierおよびParty Identifierの最大長が50文字から130文字に拡張されましたAdditionally, it was clarified that the identifier length excludes the numerical identifier scheme.
この長さには数値識別スキームは含まれないことが明確にされましたExample: iso6523-actorid-upis::9930:de162463073
The change affects solely the green part of the above Identifier. Other parts of the Identifier are not impacted.
例:上記識別子の緑色部分(de162463073)のみが変更対象であり、他の部分は影響を受けませんThis change is not directly related to the CNAME to NAPTR changes but primarily focuses on French participant identifier requirements.
この変更はCNAMEからNAPTRへの移行とは直接関係なく、主にフランスにおける参加者識別子の要件への対応です(翻訳はChatGPT)
Page 3 of 13 §2.1.1
2.1.2 Changes to POLICY 7
The algorithm used to lookup Peppol Participants in the DNS was adopted.
Peppol参加者のDNSルックアップに使用されるアルゴリズムが変更されましたThe old algorithm looks like this (in pseudo code):
旧アルゴリズム(擬似コード):
“B-” + hexstring(md5(lowercase(ID-VALUE))) + “.” + ID-SCHEME + “.” + SML-ZONE-NAME`The new algorithm looks like this (in pseudo code):
新アルゴリズム(擬似コード):
strip-trailing(base32(sha256(lowercase(ID-VALUE))),”=”) + “.” + ID-SCHEME + “.” + SML-ZONE-NAME`The most important thing is, that the required parameters have not changed between the old and the new algorithm.
重要なのは、旧方式と新方式で使用されるパラメータは変わっていないという点ですExample for Participant Identifier (Peppol参加者IDの例) iso6523-actorid-upis::0088:123abc on the production SML:
Old algorithm creates(旧方式):
B-f5e78500450d37de5aabe6648ac3bb70.iso6523-actorid-upis.edelivery.tech.ec.europa.euNew algorithm creates(新方式):
Y7DZFXAF3D4CJZ4KCGRXTEC6TWVCGA4KY7ZWA5BOIF6MSWD4TDRQ.iso6523-actorid-upis.edelivery.tech.ec.europa.euAs shown, the ID-SCHEME (in red) and SML-ZONE-NAME (in blue) are unchanged.
ご覧のとおり、スキーム識別子(赤色部分 iso6523-actorid-upis)とSMLゾーン名(青色部分 edelivery.tech.ec.europa.eu)は変更されていませんNote: All parts of URL domain names are case insensitive.
注:URLドメイン名のすべての部分は大文字小文字を区別しませんNote: This particular change only refers to the domain name algorithm but makes no statement on the DNS record type to query.
注:この変更はドメイン名生成アルゴリズムに関するものであり、使用するDNSレコード種別については影響を与えません(翻訳はChatGPT)
Page 3 of 13 §2.1.2
1.2. DNS解決方式の変更
-
旧方式:MD5ハッシュに基づきCNAMEレコードを参照
-
新方式:SHA-256 + base32に基づきNAPTRレコードを取得。スキーム(https)とポート(443)が明示可能
Page 3 of 13 §2.1.2
従来同様にC2は、SMLにC4について問い合わせますが、CNAMEではなくNAPTRレコードを取得します。
1.3. HTTPSの強制
SMPはhttpではなくhttps限定で提供されなければならなくなりました。
Requirement to operate an SMP only using the scheme “https” and not anymore via “http”.
– This is a breaking change.
– This implies, that servers running a Peppol SMP also need a TLS certificateSMPは「https」スキームのみで運用され、「http」はもはや許可されないという要件です。
– これは互換性を破る変更です
– これは、Peppol SMPを運用するサーバーにもTLS証明書が必要であることを意味しますRequirement to operate an SMP only using port 443 and not anymore on port 80.
– This is a breaking change and consistent to the change in URL schemeSMPをポート443のみで運用し、ポート80での運用はもはや認められないという要件です。
– これは互換性を破る変更であり、URLスキーム(https)への変更と一貫しています(翻訳はChatGPT)
Page 5 of 13 §2.3.1
送信先の情報を参照する手順が次の形に変更されます。
SMP v1.4.0では、
P.9 §2.1
注1:この図で示されているSender Clientが、C2のAPプロバイダーです。
注2:この図で示されているDNSは、Open Peppolが管理しています。
注3:この図で示されているSMPは、送信先のC4の情報を登録しているC3に対応したSMPです。
SML v1.3.0では、より詳細な図が提供されています。
Page 11 of 31 §2.1
SML v.1.2.0では、次の図が示されていました。
ディスカバリ処理は、DNSのCNAMEレコードを使った設計に基づいています。
<受信者IDのハッシュ値>.<スキームID>.<SMLドメイン>という形式のドメインにCNAMEが設定されており、その参照先がSMP(サービスメタデータ発行者)です。
そのため、送信者がこのドメインを名前解決すると、自動的に対応するSMPが得られます。
このようなURL解決はWeb技術の基本であり、すべての利用者に共通する標準技術です。
Page 10 §2.1
2. APプロバイダーに求められる対応
2.1. NAPTRレコード対応
Peppol専用のDNSゾーンに対するNAPTRクエリによってSMPを特定する機能が必要です。
Prepare to handle longer Participant Identifier Values. This could imply enlengthening fields in a database schema as well as adopting local validation rules when dealing with Participant Identifier Values. The usage of longer Participant Identifier Values needs coordination, as it requires sender and receiver to be capable of dealing with it.
より長いParticipant Identifier値への対応を準備してください。これは、データベーススキーマのフィールドを拡張する必要や、Participant Identifier値を扱う際のローカルな検証ルールを採用する必要を意味する可能性があります。長いParticipant Identifierの使用には、送信者と受信者の両方が対応可能である必要があるため、調整が必要です。
Please remember to test the usage of longer Participant Identifier Values in all processing steps, including at least: Document validation, SMP lookup, SBDH creation and Document transmission
Participant Identifierが長くなった場合の利用については、少なくとも文書バリデーション、SMPルックアップ、SBDH作成、文書送信などすべての処理ステップでテストを行うことを忘れないでください。
Prepare to use the U-NAPTR based SMP URL resolution instead of the CNAME based SMP URL resolution. This is one of the few activities that may be initiated very early in the migration process.
CNAMEベースのSMP URL解決の代わりに、U-NAPTRベースのSMP URL解決を使用する準備をしてください。これは、移行プロセスのかなり早い段階から開始できる数少ない活動の一つです。
Note: initially, the resulting SMP URL MUST still be using the http protocol. Any SMP returning a URL using the https protocol is non-compliant.
注:初期段階では、取得されるSMP URLは依然としてhttpプロトコルを使用していなければなりません。httpsプロトコルを返すSMPは非準拠となります。
Later in the process, a Peppol AP must be able to deal with SMPs that are operated using the https protocol. This includes, but is not limited to, the following considerations:
プロセスの後半では、Peppol APはhttpsプロトコルで運用されるSMPに対応できる必要があります。これには、以下の考慮事項が含まれますが、これらに限定されるわけではありません:
– Make sure that any check on the “http” protocol as well as on the usage of port 80 is adopted accordingly. During a migration phase it will be required to handle http and https in parallel.
– 「http」プロトコルのチェックやポート80の使用に関するロジックを、適切に更新してください。移行期間中は、httpとhttpsを並行して処理する必要があります。
– Use a TLS trust store like the one used for AP-to-AP communication
– AP間通信で使用されているものと同様のTLSトラストストアを使用してください。
– Note: No additional firewall rules are needed, as APs already need to open TCP port 443 to any IP address.
– 注:APは既に任意のIPアドレスに対してTCPポート443を開放している必要があるため、追加のファイアウォールルールは不要です。)
– Note: Don’t close the firewall for http port 80 too early, as it depends on the availability of all other SMPs under https.
– 注:すべてのSMPがhttps対応を完了するまで、httpポート80のファイアウォールを早期に閉じないでください。
– Note: Don’t forget that Port 80 (http) is still needed to download CRL (Certificate Revocation Lists) or to access the Peppol-required OCSP server.
– 注:ポート80(http)は、CRL(証明書失効リスト)のダウンロードや、Peppolが必要とするOCSPサーバーへのアクセスに依然として必要です。(翻訳はChatGPT)
page 7 of 13 §2.1
A service implementing the REST profile MUST use TLS (Transport Layer Security) and MUST be operated on port 443.
RESTプロファイルを実装するサービスは、TLS(トランスポート層セキュリティ)を使用し、ポート443で運用されなければなりません。(翻訳はChatGPT)
p.21 §5.1
3. Peppol APプロバイダーの移行準備ポイント
Peppol APプロバイダーは、以下の点について段階的に対応する必要があります:
-
長いParticipant Identifier(最大130文字)へのスキーマ設計と検証対応
-
CNAMEからU-NAPTRへのSMP URL解決方式への早期移行
-
HTTPからHTTPSへの段階的な移行(TLS必須)
-
ポート80および443における通信要件とファイアウォールの柔軟な対応
-
OCSP・CRLの通信確保(http通信の一部継続)
これらの要件は、相互運用性の確保とセキュリティ強化の両立を図る上で重要です。
3.2 Peppol AP Providers
The following list of activities is specific to Peppol AP Providers. Please also refer to specific migration guidelines of your AP and/or AS4 solution provider.
以下の活動項目は、PeppolのAPプロバイダーに特有のものです。使用しているAPまたはAS4ソリューションプロバイダーが提供する移行ガイドラインも参照してくださいPrepare to handle longer Participant Identifier Values.
長いParticipant Identifier値への対応を準備してください
This could imply enlengthening fields in a database schema as well as adopting local validation rules when dealing with Participant Identifier Values.
これは、データベーススキーマのフィールド長を拡張したり、ローカルなバリデーションルールを採用したりする必要があることを意味します
The usage of longer Participant Identifier Values needs coordination, as it requires sender and receiver to be capable of dealing with it.
長いParticipant Identifierを使用するには、送信者と受信者の両者が対応可能である必要があり、協調が求められます
Please remember to test the usage of longer Participant Identifier Values in all processing steps, including at least:
Document validation, SMP lookup, SBDH creation and Document transmission
Participant Identifierの使用は、文書バリデーション、SMPルックアップ、SBDH作成、文書送信など、すべての処理ステップでテストすることを忘れないでくださいPrepare to use the U-NAPTR based SMP URL resolution instead of the CNAME based SMP URL resolution.
CNAMEベースではなく、U-NAPTRベースのSMP URL解決方式への移行を準備してください
This is one of the few activities that may be initiated very early in the migration process.
これは移行プロセスの初期段階から始められる数少ない作業の1つです
Note: initially, the resulting SMP URL MUST still be using the http protocol.
Any SMP returning a URL using the https protocol is non-compliant.
注:初期段階では、生成されたSMP URLは依然としてhttpプロトコルである必要があります。
httpsを返すSMPは非準拠とされますLater in the process, a Peppol AP must be able to deal with SMPs that are operated using the https protocol.
移行後期には、Peppol APはhttpsプロトコルで運用されるSMPに対応できる必要があります
This includes, but is not limited to, the following considerations:
以下の考慮事項を含みますが、これらに限定されるものではありません
Make sure that any check on the “http” protocol as well as on the usage of port 80 is adopted accordingly.
During a migration phase it will be required to handle http and https in parallel.
httpプロトコルやポート80の使用をチェックしているロジックは、移行フェーズ中はhttpとhttpsの両方に対応できるように調整してくださいUse a TLS trust store like the one used for AP-to-AP communication
AP間通信で使用されているものと同様のTLSトラストストアを使用してくださいNote: No additional firewall rules are needed, as APs already need to open TCP port 443 to any IP address.
注:APは既に任意のIPアドレスに対してTCPポート443を開いている必要があるため、追加のファイアウォールルールは不要ですNote: Don’t close the firewall for http port 80 too early, as it depends on the availability of all other SMPs under https.
注:すべてのSMPがhttps対応を完了するまでは、httpポート80のファイアウォールを早期に閉じないようにしてくださいNote: Don’t forget that Port 80 (http) is still needed to download CRL (Certificate Revocation Lists) or to access the Peppol-required OCSP server.
注:ポート80(http)は、CRL(証明書失効リスト)のダウンロードやPeppol指定のOCSPサーバーへのアクセスに今後も必要です(翻訳はChatGPT)
p.8 §3.2
4. SMLとDNS登録の構成と管理権限
4.1. SMLはPeppol専用DNSゾーンにNAPTRを登録
Peppolが管理するDNSゾーン例:
iso6523-actorid-upis.edelivery.tech.ec.europa.eu.
The sender (or their Access Point provider) achieves this by searching the Service Metadata Locator (SML)-filled DNS to find the relevant SMP … that can identify the endpoint URL.
送信者(またはそのアクセスポイントプロバイダー)は、SML(サービスメタデータロケーター)によって登録されたDNS情報を検索することで、受信側APのエンドポイントURLを特定できる適切なSMPを見つけ出します。(翻訳はChatGPT)
p.11 §2.1.2
DNS用の参加者識別子はSHA-256およびbase32エンコーディングに基づき、SML運営者によって定義されたDNSゾーンに公開されなければなりません。
Participant Identifiers for DNS Participant identifiers – consisting of scheme and value – are encoded as follows into a DNS name:
<hash-of-value>.<scheme>.<SML-zone-name>
DNSで使用するParticipant Identifierは、スキームと値で構成されており、次の形式でDNS名にエンコードされます:
<ハッシュ値>.<スキーム>.<SMLゾーン名>(翻訳はChatGPT)
p.17 POLICY 7
この規定の説明文中では、DNSで使用するParticipant Identifierは、UTF-8でエンコードされた元の値からSHA-256でハッシュ化され、RFC 4648に基づいてBase32でエンコードされ、その後SMLオペレーターが定めるDNSゾーン内に公開されなければならないことを示しています。
5. NAPTR方式への移行スケジュールと各期間の対応詳細
PeppolネットワークにおけるNAPTR方式への切り替えは、以下のマイルストーンに従って段階的に実施されます。
Page 9 of 13 §4
5.1. T1:開始時点(2025年5月1日)
移行プロセスの開始。APおよびSMPプロバイダーは以下の準備を進めます。
-
長いParticipant Identifier(最大130文字)への対応準備
-
NAPTRレコードベースのSMPルックアップの実装
-
HTTPSによるSMP提供への備え(証明書取得、URL設計)
-
Peppolテストネットワークでの動作検証(任意)
5.2. T2:実装完了目標(2025年11月1日)
この時点で以下の実装が完了している必要があります:
-
APはNAPTRベースのSMPルックアップを実装済みであること
-
SMPは、HTTPS運用の準備が整っていること
-
HTTPS構成の整備
-
ベースURLの切替準備
-
HTTP/HTTPS 両対応の並行運用ロジックを準備
5.3. T3:移行完了時点(2026年2月1日)
この時点以降は以下が義務付けられます:
-
SMPはHTTPSでのみ提供されること(HTTPは禁止)
-
APはHTTPS URLでのSMPルックアップ結果を前提とすること
-
(任意)APは柔軟性維持のため、最大6ヶ月間はHTTP URLの受信も許容することが推奨
また、T3以降は以下の措置が推奨されます:
-
古いHTTPベースのDNSレコードの削除(クリーンアップ)
-
SMP実装でHTTPサポートを完全に無効化
5.4. 注意事項(SMPが10,000件超を保有する場合)
-
10,000件以上のService Groupsを持つSMPは、SMLオペレーターとの事前調整が必要です(メール:EC-EDELIVERY-SUPPORT@ec.europa.eu)
-
NAPTRでは中間ドメイン(publisher名)が使えないため、すべてのParticipantレコードを個別更新する必要があり、DNSSECとの併用により負荷が大きくなることが理由です。
6. SMLとDNS登録の構成と管理権限
6.1. SMLはPeppolが運用し、Peppol専用DNSゾーンにNAPTRを登録
Peppolが管理するDNSゾーン例:
iso6523-actorid-upis.edelivery.tech.ec.europa.eu.
The sender (or their Access Point provider) achieves this by searching the Service Metadata Locator (SML) filled DNS to find the relevant Service Metadata Publisher (SMP) … that can identify the endpoint URL.
送信者(またはそのアクセスポイントプロバイダー)は、サービスメタデータロケーター(SML)によって構成されたDNSを検索し、適切なSMPを見つけてエンドポイントURLを特定します。(翻訳はChatGPT)
p.11 §2.1.2
7. NAPTRレコードの例と構文
POLICY 7 Participant Identifiers for DNS
Participant identifiers – consisting of scheme and value – are encoded as follows into a DNS name:
<hash-of-value>.<scheme>.<SML-zone-name>POLICY 7 DNS用のParticipant Identifier
スキームと値から構成されるParticipant Identifierは、次の形式でDNS名にエンコードされます:
<ハッシュ値>.<スキーム>.<SMLゾーン名>(翻訳はChatGPT)
p.17 POLICY 7
この規定は、SMLにより次のようなDNS名が生成される構造を意味します:
例:Y7DZFX…Y7ZWA.iso6523-actorid-upis.edelivery.tech.ec.europa.eu.
Y7DZFX…Y7ZWA:Participant Identifier のSHA-256 + Base32ハッシュ値
iso6523-actorid-upis:スキーム識別子(例:GLN)
edelivery.tech.ec.europa.eu:PeppolのSMLが管理するグローバルなDNSゾーン
つまり、NAPTRは企業独自のDNS(例:example.com)の下に登録されるのではなく、SMLが統一的に管理するPeppol専用のゾーンに登録される構造です。
以下は、NAPTRレコードの記述例です。
IN NAPTR 100 10 "u" "SMP+https" "" "https://smp.example.com/smpquery/{participant-id}"
u: URI型
SMP+https: SMPプロファイルとhttpsスキームの組み合わせ
URIテンプレートとしてパーティシパントIDを展開
8. 補足検討:NAPTR方式はSMLの集中構造のボトルネックを解消するか?
NAPTR方式の導入によってHTTPSスキームやポート番号の明示的な指定が可能となり、セキュアなルックアップや運用上の柔軟性が向上します。しかしながら、次の理由からSML(Service Metadata Locator)の集中的構造そのものを解消する仕組みとはなっていません:
SMP情報の登録・更新は依然としてSMLに集中しており、すべてのレコード登録はSMLインターフェースを経由する必要があります。
NAPTRレコードの登録先は企業独自のDNSサーバー(例:AWS Route53、Google Cloud DNSなど)ではなく、SMLが管理するPeppol専用のDNSゾーンです。
DNSクエリ自体はグローバルに分散処理されるものの、登録更新時の負荷は集中したままであるため、大規模SMP(Service Group数が1万件を超える場合など)ではSMLへの負荷が依然として課題です。
8.1. SMLドメインにおけるDNS負荷分散の可能性
技術的には、SMLが管理するDNSゾーン(例:edelivery.tech.ec.europa.eu)に対して、複数のDNSネームサーバー(NSレコード)を用意することで名前解決における負荷分散は可能です。これにより:
クライアントは地理的に最も近いネームサーバーから応答を得ることができ、応答遅延の軽減が期待されます。
DNSサーバーの冗長構成により、単一障害点を排除できます。
ただし、これはあくまでも名前解決の負荷分散であり、SMP登録・更新処理自体の集中性は残ったままである点に注意が必要です。真にSML集中構造を解消するには、登録処理を委任または分散できる構造(例:Federated SMLなど)が求められます。
NAPTR方式の導入によってHTTPSスキームやポート番号の明示的な指定が可能となり、セキュアなルックアップや運用上の柔軟性が向上します。しかしながら、次の理由からSML(Service Metadata Locator)の集中的構造そのものを解消する仕組みとはなっていません:
SMP情報の登録・更新は依然としてSMLに集中しており、すべてのレコード登録はSMLインターフェースを経由する必要があります。
NAPTRレコードの登録先は企業独自のDNSサーバー(例:AWS Route53、Google Cloud DNSなど)ではなく、SMLが管理するPeppol専用のDNSゾーンです。
DNSクエリ自体はグローバルに分散処理されるものの、登録更新時の負荷は集中したままであるため、大規模SMP(Service Group数が1万件を超える場合など)ではSMLへの負荷が依然として課題です。
したがって、NAPTR移行の主目的は「httpsスキーム運用の強制」「URIのスキーム解決の柔軟性向上」であり、SMLの構造的集中や登録ボトルネックの根本的な解消には至っていないことに留意する必要があります。
9. まとめ
-
CNAME方式は廃止され、NAPTR方式に一本化されました。
-
SMPアクセスはhttps強制となり、NAPTRレコードでそのスキーム指定が可能になりました。
-
APプロバイダーはNAPTRクエリ、TLS検証、SMPのhttps対応、長いParticipant Identifier(最大130文字)への対応が求められます。
-
これらの構造はPeppol SMLと専用DNSゾーンにより統制され、外部DNSとは異なる管理下にあります。
コメントを残す