Views: 0
SMK を使った相互接続テストと 2026 移行テストの進め方（AP 視点）
2026-01-25
本記事は、Peppol のテスト用 SML である SMK（SML Acceptance / Test）を使って、
-
相互接続テスト（AP↔AP：DNS→SMP→AS4 の動的ディスカバリ経由で疎通）
-
2026 年の移行テスト（CNAME 依存の廃止、U-NAPTR 参照、SMP lookup の https 化）
を、AP 事業者の実務手順として整理したものです。主に日本（Japan PA）での手続きを想定していますが、手順の構造は他国でも概ね同じです。 ([デジタル庁][1])
1. 用語整理（最小限）
- SMK
-
SML（Service Metadata Locator）の テスト環境。AP はここ（DNS）を起点に SMP を発見し、受信者の Endpoint 情報に到達します。 ([Peppol Documentation][2])
- SMP
-
受信者の ServiceGroup / ServiceMetadata（DocType、Process、Endpoint、証明書など）を公開するサーバ。 ([Peppol Documentation][3])
- AP
-
AS4 によりメッセージ送受信を行う Access Point。
- PA
-
Peppol Authority。国・地域ごとに、認定（Accreditation）や運用ルールを管理します（日本はデジタル庁が Japan PA）。 ([デジタル庁][1])
2. この記事の前提：対象は「相互接続」と「移行」
相互接続テストでは、相手 AP が SMK（DNS）→ SMP → あなたの AS4 endpoint を動的に引いて送れること／あなたも同様に相手へ送れること、を確認します。
2026 移行テストでは、特に以下を “仕様どおりにできているか” を確認します。
-
CNAME ではなく U-NAPTR で SMP を発見する（CNAME 依存が残っていない）
-
SMP lookup が段階的に http→https へ移行する期間を正しく扱える
-
（運用上）移行期の落とし穴（過早な 80/tcp 閉塞など）を踏まえた構成になっている
移行のマイルストーン（T1/T2/T3）と要件は、公式の移行手順書で明確化されています。 ([Peppol Documentation][4])
3. AP からの申請・手続き（PA との関係を含む）
3.1 いちばん大事：証明書（Test PKI）が “入口”
SMK を使った相互接続／移行テストを現実に回すには、通常 Test PKI（AP Test 証明書） が必要です（Testbed へのログイン、テスト環境での AP 運用などに使うため）。 ([OpenPeppol][5])
日本の Guidance Note では、Test PKI 証明書を申請する前に Japan PA へ連絡して承認を得ることが明記されています（＝PA が関与するポイント）。 ([デジタル庁][1])
また、同 Guidance Note では OpenPeppol メンバーでないと手続きを開始できない旨も明記されています。 ([デジタル庁][1])
3.2 日本（Japan PA）での基本フロー（要点）
AP 観点では、ざっくり次の順番で考えると迷いにくいです。
-
OpenPeppol メンバーシップ（前提） ([デジタル庁][1])
-
Japan PA に連絡し、Test PKI 申請の事前承認を得る ([デジタル庁][1])
-
OpenPeppol の Service Desk（Jira）から Test PKI（AP Test）を申請
-
SMK（acc 環境）に向けた相互接続テスト／移行テストを実施
-
（認定も目的なら）テスト結果を用いて PA 面談等へ進む（日本ではテスト合格後に Japan PA interview が要件） ([デジタル庁][1])
|
Note
|
本記事は「相互接続／移行テスト」中心のため、認定（Accreditation）全体の詳細は割愛しますが、日本は「テスト合格→Japan PA interview→Agreement→Production 証明書」の流れが整理されています。 ([デジタル庁][1]) |
4. テスト環境の利用方法（相互接続テスト編）
ここからは「SMK を使って AP↔AP の相互接続をテストする」手順です。
前提として、SML のテスト向けドメイン（SMK 側）を指す必要があります。Testbed/Onboarding ガイドでも、SML 設定に acc 側を使うことが言及されています。 ([OpenPeppol][5])
4.1 構成パターン（SMP を自社で持つか／持たないか）
相互接続テストは必ず SMP が絡みます。AP が SMP を持たない場合は “依頼先（SMP 運用者）” が増えるだけで、やることの本質は同じです。
- パターン A（AP のみ運用）
-
-
SMP は外部サービスを利用
-
SMP 側に「SMK publish 用の Participant 作成」「サービスメタデータ登録」を依頼
-
- パターン B（AP + SMP を運用）
-
-
自社で SMP を運用し、SMK に publish する
-
SML/SMP 仕様に沿った運用（管理インタフェース、証明書、更新手順）まで自社責任
-
SML/SMP の仕様書（および関連資料）は eDelivery documentation から辿れます。 ([OpenPeppol][6])
4.2 相互接続テストの標準手順（実務）
以下は “あなたの AP を受信者として公開し、相手 AP から送ってもらう” 例です（逆方向も同様）。
手順 1：テスト用 Participant ID を決める
-
scheme（例：
iso6523-actorid-upis）と value を決める -
テスト用と本番用を混同しない（運用上の事故防止）
手順 2：SMP に ServiceGroup / ServiceMetadata を登録
少なくとも次を SMP に設定します。
-
Participant（ServiceGroup）
-
DocType / Process
-
Endpoint（あなたの AS4 受信 URL）
-
証明書（SMP が返す endpoint 証明書情報など）
SMP のデータモデルと公開インタフェースは SMP 仕様に従います。 ([Peppol Documentation][3])
手順 3：SMK（SML）へ publish する
SMP 運用者が、SML の管理インタフェース経由で SMK へ登録します（SML 仕様で discovery/management の考え方が定義されています）。 ([Peppol Documentation][2])
手順 4：DNS（U-NAPTR）で SMP が引けることを確認
Linux なら、概ね次の形になります（<hash>.<scheme>.<zone> の <hash> は参加者 ID から導出）。
# 例：NAPTR を引く（実際の FQDN は参加者IDから生成）
## dig -t naptr +short <participant-hash>.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.euこの段階で「NAPTR の戻りから SMP URL（base）に到達できる」ことが確認できれば、動的ディスカバリの入口が成立しています。移行後は “NAPTR lookup が前提” になるため、相互接続テストがそのまま移行テストの一部になります。 ([Peppol Documentation][4])
手順 5：相手 AP から送信 → あなたの AP で受信確認
相手 AP は次の流れであなたの endpoint を発見して送ってきます。
-
SMK（DNS）で NAPTR → SMP URL
-
SMP で service metadata → endpoint
-
endpoint に AS4 送信
受信後は、AS4 レベルの ACK／エラー、必要なら MLS 等の運用要件も含めて確認します（ここは相互接続の本丸）。
5. テスト環境の利用方法（2026 移行テスト編）
2026 移行（CNAME→NAPTR、SMP lookup の https 化）については、公式の移行手順書に T1/T2/T3 の節目が定義されています。 ([Peppol Documentation][4])
5.1 マイルストーン（テスト観点に直結する部分）
移行手順書の定義（例示）：
-
T1 = 2025-05-01
-
T2 = 2025-11-01
-
T3 = 2026-02-01
（※正確な日付・条件は必ず原典で確認してください） ([Peppol Documentation][4])
5.2 AP 側の必須テスト項目（移行要件）
(A) “CNAME に頼らない” ことの証明
-
T2 以降、SMP lookup は U-NAPTR ベースである必要があり、CNAME 参照は禁⽌（＝実装・設定・依存ライブラリに CNAME 前提が残っていないこと）。 ([Peppol Documentation][4])
テスト方法（実務）：
-
AP のログに「DNS で NAPTR を問い合わせた痕跡」が残るか
-
監視側で DNS クエリを観測し、NAPTR クエリのみになっているか
-
CNAME を切った環境でも discovery が成立するか
(B) SMP lookup の http→https を段階的に扱える
移行文書では、SMP URL の取り扱いが段階的に変わります（期間中は並走もあり得ます）。 ([Peppol Documentation][4])
テスト方法（実務）：
-
SMK 上の登録（または相手の SMP）を http / https で切り替え、AP が正しく追随するか
-
https のみになった後も、失敗時のエラーハンドリングが適切か（リトライ、フォールバック方針など）
© 移行期の “80/tcp を早く閉じる” 事故を避ける
移行手順書では、移行後もしばらく http が必要になる可能性（例：周辺の通信要件）に触れており、運用設計がテスト項目になります。 ([Peppol Documentation][4])
テスト方法（実務）：
-
ファイアウォールで 80/tcp を閉じた場合に、証明書検証や関連通信で副作用が出ないか
-
段階的閉塞（計画・監視・例外）をどうするかを決め、手順化する
6. 仕上げ：証跡（ログ）と “相互接続＋移行” 統合チェックリスト
6.1 最低限残すと強いログ
-
どの SML ドメインを参照したか（acc か prod か）
-
DNS クエリ（NAPTR を引いていること）
-
NAPTR 応答から導いた SMP base URL
-
SMP へのアクセス結果（HTTP ステータス、TLS、レスポンスの要点）
-
取得した endpoint と、実際に送った AS4 宛先
-
AS4 の結果（ACK、エラー、再送）
6.2 統合チェックリスト（そのまま試験項目にできる）
-
❏ SMK（
acc.edelivery.tech.ec.europa.eu）を参照している（相互接続テスト時） ([OpenPeppol][5]) -
❏ DNS は NAPTR を引いて SMP を発見している（CNAME 依存なし） ([Peppol Documentation][4])
-
❏ SMP URL が http/https 切替されても、期間要件どおりに discovery できる ([Peppol Documentation][4])
-
❏ 相手 AP が SMK→SMP→endpoint であなたの AP へ送れる（受信確認）
-
❏ あなたも同様に相手へ送れる（送信確認）
-
❏ 移行期のネットワーク運用（http 閉塞など）で副作用が出ない構成になっている ([Peppol Documentation][4])
7. 参考資料
-
[1]: Japan PA Guidance Note（Test PKI 申請前の PA 承認、面談など）[デジタル庁]
-
[2]: Peppol Service Metadata Locator (SML) 1.3.0（discovery/management の仕様）[Peppol Documentation]
-
[3]: Peppol Service Metadata Publishing (SMP) 1.4.0（SMP の仕様）[Peppol Documentation]
-
[4]:Peppol CNAME to NAPTR Migration Process（移行要件とマイルストーン）[Peppol Documentation]
https://docs.peppol.eu/edelivery/changelog/2025-04/Peppol%20CNAME%20to%20NAPTR%20Migration%20Process%20v1.0.0%202025-04-17.pdf?utm_source=chatgpt.com["Peppol CNAME to NAPTR Migration Process"]
-
[5]: OpenPeppol Testbed and Onboarding guide（テストベッド利用の前提）[OpenPeppol]
-
[6]: eDelivery documentation（関連仕様・一覧）[OpenPeppol]
コメントを残す