メールが届く基本はシンプルです。

自分の契約プロバイダは、主に「自分がログインして送る送信口（MSA）」を提供します。
その先は、相手ドメインのDNSに従い、SMTPで“サーバ対サーバ”配送します。
ここに相手側プロバイダとの個別契約は不要で、相互運用はインターネット標準に委ねられています。

利用者（PCや送信サーバ）が毎回、ルートから順に辿って権威DNSに到達するのは非効率です。
そこで、実務では 再帰DNS（Recursive Resolver） が代理で探索します。

利用者 → 再帰DNS:
「example.co.jp のMXを教えて」

再帰DNS（キャッシュがない場合）の探索手順は次のとおりです。

この「代理探索＋キャッシュ」により、世界規模でも高速に“宛先解決”ができます。

メールの成功要因は次の三点です。

EDIでも同じ構造が欲しいのですが、EDIは文書種（doc_type）やプロファイル（仕様版）で受信能力が変わります。
したがって、メールのMXよりも多い「能力（capability）」が必要になります。

今回の議論で整理した最適形は、次の二段階です。

Peppolは、これをほぼそのまま実装しています。

ただし、Peppolネットワークから外部ネットワーク（共通EDI／流通BMS等）へ“橋渡し”する場合、
PeppolのSMLだけでは完結しないことがあります。
次節のシナリオは、その典型です。

ここでは、Peppolネットワークから外部へ連携サービスを提供するB社が“出口”になり、
その先は共通EDI／流通BMSの提携経路で最終宛先Y社へ届ける、という前提を置きます。

下記のルートで「インボイス」を届けたい、という前提です（S2C：Sales to Cash）。

ここで重要なのは次の二点です。

このため、PeppolのSMLだけで「Y社へどう届けるか」を解決できません。
B社がPeppolネットワークから外部へ連携サービスを提供する以上、B社は別途、

を提供しておくことが必要になります。

本モデルの核心は、「物理的な配送先（プロバイダ）」と「論理的な宛先（最終受領者）」の分離です。

A社：Peppolサービス事業者（X社の契約先）
A社は、Peppol（OpenPeppol）ネットワークでの送受信サービス（AP相当の機能）を、契約顧客であるX社に提供します。
具体的には、Peppolの仕組み（SML/SMP）を用いて宛先解決を行い、Peppol上の配送（到達）を担保し、証跡（ログ）や再送制御を提供します。
B社が公開している宛先情報サービスに基づいてY社向けのメッセージを4コーナーモデルを用いてB社に送付します。

B社：Peppolサービス事業者（Y社宛の中継）
本シナリオでは、B社は共通EDIサービス事業者C社と提携し、Peppolで受領した電文をC社へ個別APIで転送する「相互サービス連携」を提供します。
言い換えると、B社は「Peppol側の入口」と「国内連携の起点」を兼ねます。

C社：共通EDIプロバイダ（Peppol接続のブリッジ事業者）
C社も中小企業共通EDIのサービス事業者として、参加者向けに送受信・運用サービスを提供します。
本シナリオでは、C社がPeppolサービス事業者B社と提携し、B社から個別APIで受け取った電文を、共通EDIのESP間連携で国内側（D社）へ引き渡す「相互サービス連携」を提供します。
つまりC社は、国際側（Peppol）と国内側（共通EDI）をつなぐ中継事業者です。

D社：共通EDIプロバイダ（流通BMS接続のブリッジ事業者）
D社は、中小企業共通EDIのサービス事業者として、共通EDIの参加者（企業）向けに送受信・運用サービスを提供します。
加えて本シナリオでは、D社が流通BMSプロバイダE社と提携し、D社→E社間の個別API転送（および必要な変換）により、共通EDI側から流通BMS側へ届ける「接続サービス（ブリッジ）」を提供します。
つまりD社は、国内側で「次ホップを決めてE社に引き渡す」中継事業者です。

E社：流通BMSプロバイダ（Y社の契約先）
E社は、流通BMSのネットワーク／運用の中で、Y社向けに受信・配送（配下配信）サービスを提供します。
具体的には、流通BMSのルールに従い、取引先から届いた電文をY社の受信環境（EDI/基幹取込）へ確実に届け、到達確認や再送、監査ログ等を提供します。
本シナリオでは、E社は「最終配送（Y社への到達）」を担う事業者です。

この多段を壊さず成立させる鍵は五つです。

「Y社向けの情報がPeppolのSMLには無いのに、B社/C社/D社はどうやってY社に届けるのか？」という点が、今回の方式のいちばん重要なポイントです。
結論から言うと、Y社の情報は SML（公開ディスカバリ） ではなく、Peppol外の連携網における “閉じた情報提供（ディレクトリ／アドレス帳）” として、段階的に共有されます。

この仕組みはメールで言えば「ドメインのMXは公開DNSで引けるが、企業内の配布先（部署・担当）や付加条件は社内アドレス帳で管理する」に近い構造です。

区間が分かれるほど、SBDHの価値が上がります。
ここで重要な設計原則は「業務層（SBDH）と輸送層（AS4/API）の分離」です。

したがって、たとえPeppol区間の宛先がB社であっても、SBDHは次で固定します。

一方、輸送ヘッダ（AS4/API/ESP）は区間の通信相手（A→B、B→C…）を表し、都度付け替えます。

SBDHが“論理封筒”として機能するためには、通信アプリケーションが「論理→物理」の解決を担う必要があります。

今回のシナリオでは「Peppol外の宛先解決」をB社が担うため、処理の要点は次のようになります。

二段階問い合わせを成立させるため、サービス事業者は次を提供します。

現実的なビジネスモデルは複数あり、重畳してよいです。

多段配送では、trace_id を全区間で貫通させることが不可欠です。B社はPeppol側の「受領証（Message Level Response）」と、後段ネットワークからの「到達確認（ACK-2）」を紐付け、送信者に最終的な配送ステータスをフィードバックする役割を担います。

本来、宛先探索の「根（Root）」は、国が提供する 統合SML（共通探索基盤） であることが望ましいといえます。具体的には、以下のアーキテクチャへの移行を提言します。

gBizIDとSMLが統合されることで、事業者は一度gBizIDの管理画面で自社の利用プロバイダを登録するだけで、あらゆるネットワークからの電文を受け取ることが可能になります。

民間の創意工夫（SBDHによる論理解決）で「分断」をほどきつつ、最終的には国がgBizIDを核とした強力な探索基盤を提供することで、日本のEDIは初めて「真の相互運用性（Connect Once, Connect to Everyone）」を達成します。これこそが、デジタルインボイス普及の決定打であり、サプライチェーン全体の生産性を引き上げる鍵となります。