gBizID を用いたユーザ ID 統一と SML/SMP 管理方式への移行ステップ

はじめに

本節では、現行の EPS 連携方式（username@ESPドメイン を用いた連携アドレス）を前提としつつ、
gBizID（＋部署拡張）を共通のユーザ ID（参加者 ID）として採用し、
SML および SMP で管理する方式へ段階的に移行する手順を示す。

あわせて、現行方式の概要と、SML/SMP 自体の実装方法およびプロバイダ（ESP）と SMP の対応関係を整理する。

現状と課題

現行 EPS 連携方式の概要

レイヤ構造

現行の EPS 仕様では、おおむね次のレイヤ構造で ESP 間のメッセージ交換が行われている。

HTTP(S)
SOAP 1.2
- frttp:ForwardRequest / frttp:ForwardResponse
  - 共通ヘッダ要素：Action / To / From / MessageID など
  - ペイロード：Data（添付ファイル本体。Base64 等）

連携アドレス（To／From）

To／From には、次の形式の「連携アドレス」が設定される。
- username@domain
username:
- 各 ESP（プロバイダ）内で一意となるローカルユーザ名（部署・窓口など）
domain:
- グローバルに一意となる ESP のドメイン名
- ドメイン部分によって、どの ESP 宛てかを特定する

ESP 間中継

ESP には「中継機能」があり、
- To のドメイン部から宛先 ESP を特定し、
- 自 ESP 宛てでなければ、該当 ESP へメッセージを転送（Relay）する。
他 ESP の所在（エンドポイント URL 等）は、
- 仕様付録の「連携アドレス一覧」や
- 各 ESP 内部の設定テーブル
  により管理されており、中央ディレクトリは存在しない。

業務 ID との関係

メッセージ内には法人番号や gBizID といった事業者 ID は登場せず、
- 「企業＋部署などの宛先」は連携アドレス（username@domain）そのものに埋め込まれている。
そのため、
- 「どの企業か」「どの部署か」と
- 「どの ESP を利用しているか」
  が一体化した ID となっている。

現状の課題

連携アドレスが username@ESPドメイン であるため、
- 利用企業が別の ESP に乗り換えると、
- @old-esp.jp から @new-esp.jp へのアドレス変更が必要となる。
取引先マスタやアドレス帳には連携アドレスが直接登録されているため、
- プロバイダ乗り換えのたびに全取引先情報の更新が必要となる。
中央ディレクトリ（SML）や SMP に相当する仕組みが存在せず、
- 「この企業（この部署）は現在どの ESP に紐付いているか」
- 「どの文書種別・プロセスでどのアドレス／証明書を使うか」
  をネットワーク上で解決する手段がない。
その結果、事業者 ID とプロバイダが技術的に結合しており、
- 実質的にプロバイダ・ロックインに近い状態となっている。

目指す姿（ゴール）

ビジネス上の宛先は、gBizID を基盤とした「参加者 ID」で統一する。
参加者 ID は「企業＋部署」の粒度まで拡張可能とし、企業内の部署／拠点ごとの宛先を区別できるようにする。
どの ESP が担当しているかは中央ディレクトリ（SML）経由で解決し、プロバイダ乗り換え時も参加者 ID は変更せずに済む。
EPS の輸送レベル（FRRTP：To／From に username@domain を格納）との互換性を確保しつつ、上位レイヤ（SBDH 等）で参加者 ID（gBizID＋部署）を扱う。
将来的には、Peppol 等の国際的な SML/SMP 方式との親和性も確保する。

ステップ 1：gBizID ベースの参加者 ID（部署拡張）の設計

企業 ID

法人／企業そのものの ID として gBizID を採用する。
例：GBIZ-1234-5678-ABCD（形式は gBizID の仕様に準拠）

参加者 ID（URN 化）

gBizID を URN 形式に変換し、「参加者 ID」として用いる。

例

urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD

部署／拠点拡張

同一法人内の部署・拠点ごとの宛先を区別するため、gBizID に部署コードを付与する。
例：
- 経理・支払部門: dept:AP
- 売掛金管理部門: dept:AR

参加者 ID の例：

urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP
urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AR

部署コード自体は各社で定義しつつ、共通 EDI として
urn:jp:gov:gbizid:<GBIZID>:dept:<部署コード> 形式を推奨する。

SBDH との対応（将来）

SBDH 導入時には、次のように対応させることを想定する。
- Sender/Partner/Identifier = 上記 URN（参加者 ID）
- Sender/Partner/Authority = JP:GBIZID
- Receiver/Partner/Identifier / Authority も同様

ステップ 2：既存連携アドレスとの対応表の整備

ESP 内部でのマッピング表

各 ESP は、自社が管理する利用者について次のようなマッピング表を保持する。

参加者 ID（gBizID＋部署）	連携アドレス（現行 EPS）
urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP	ap_accounting@esp-a.jp
urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AR	ar_billing@esp-a.jp

参加者 ID（gBizID＋部署）

連携アドレス（現行 EPS）

urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP

ap_accounting@esp-a.jp

urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AR

ar_billing@esp-a.jp

初期段階では、このマッピングは ESP 内のローカル情報として管理し、SML への公開は後続ステップで行う。

利用企業側マスタの拡張

利用企業（C1/C4）の取引先マスタには、次の項目を保持することを推奨する。
- 取引先コード
- gBizID 参加者 ID（新）
- 連携アドレス（username@domain）（旧・互換用）
将来的には「旧」列を徐々に非推奨とし、参加者 ID を主キーとした管理に移行する。

SML/SMP 実装パターンの概要

前節までで、gBizID ベースの参加者 ID と EPS の既存連携アドレスの関係を整理した。
ここでは、この参加者 ID を用いたディレクトリ機能をどのように実装するかについて、
代表的な 2 つのパターンを整理する。

独自方式（簡便法：一段階解決）

中央のディレクトリサービス（SML API 相当）が、
- 参加者 ID → providerId / providerEndpoint / networkAddress（username@domain）
  を一括で返す方式。
SMP を別サーバとして公開せず、各 ESP 内部のマスタをそのまま利用し、
- ディレクトリ API から「連携アドレス」まで直接取得できるようにする。
実装例：
- GET /participants/{participantId} に対して、次のような JSON を返す。

{
  "participantId": "urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP",
  "providerId": "esp-a.jp",
  "providerEndpoint": "https://gw.esp-a.jp/eps",
  "networkAddress": "ap_accounting@esp-a.jp",
  "status": "ACTIVE"
}

C2 はこの応答だけを見て、FRRTP の To に networkAddress を設定し、
宛先 URL として providerEndpoint を用いてメッセージを送信できる。
- 利点：
実装が単純で、既存の EPS 仕様との親和性が高い。
各 ESP が持つ「参加者 ID ↔ 連携アドレス」のマスタを、そのままディレクトリ API 経由で公開するだけで運用を開始できる。
初期段階では SMP サーバを別途構築する必要がない。
- 留意点：
文書種別・プロセスごとにネットワークアドレスや証明書が変わるような高度な利用は想定していない（必要になった段階で 2 の方式へ拡張する）。
国際的な SML/SMP 仕様（OpenPeppol 等）との互換性は限定的となる。
将来的に OpenPeppol 互換方式へ移行する場合は、
「ディレクトリ API 内部で持っている情報」を SMP に切り出す移行設計が必要になる。

OpenPeppol 互換方式（二段階解決）

参加者 ID 解決を
- 「SML：どのプロバイダの SMP を参照すべきか」
- 「SMP：文書種別・プロセスごとの networkAddress をどうするか」
  に分離する方式。
この文書で後続に詳述する「SML の最小実装」「SMP の API 構成例」は、この 2 段階モデルを前提としている。
概要：
- SML は、参加者 ID に対して少なくとも次を返す。
  - providerId（ESP ドメイン）
  - providerEndpoint（当該 ESP の EPS ゲートウェイ URL）
  - smpBaseUrl（当該 ESP の SMP ベース URL）
- SMP は、(participantId, documentTypeId, processId) に対して次を返す。
  - networkAddress（username@providerId）
  - transportProfile や TLS 証明書等のセキュリティ情報
利点：
- 文書種別／プロセスごとに networkAddress やセキュリティ条件を柔軟に設定できる。
- Peppol の SML/SMP モデルと整合的であり、将来的な国際連携に適合しやすい。
- 「参加者 ID ↔ プロバイダ（ESP）」と、「参加者 ID ↔ サービスエンドポイント（networkAddress）」を論理的に分離できる。
留意点：
- 簡便法に比べてコンポーネント数が増える（SML＋各 ESP の SMP）。
- 初期実装コストは高くなるが、長期的な運用・拡張性の点で優れる。

選択と移行の考え方

国内の共通 EDI においては、
- 短期的には「独自方式（簡便法）」でディレクトリ API を実装し、
- 中長期的には「OpenPeppol 互換方式」に近づけていく、
  という段階的な移行も現実的な選択肢となる。
本稿の「ステップ 3 以降」は、基本的に OpenPeppol 互換方式（二段階解決）の考え方に沿って記述しているが、
- 実装の初期フェーズでは、SML のレスポンスに networkAddress を含める等、
  簡便法とのハイブリッド構成も考えられる。

ステップ 3：SML の最小実装

SML の役割

SML（Service Metadata Locator）は、次の対応を担う。

キー：参加者 ID（gBizID＋部署）
値：少なくとも次の情報を保持する。
- providerId：当該参加者 ID を現在担当しているプロバイダ ID（ESP ドメイン）。
- providerEndpoint：当該プロバイダ（ESP）の EPS ゲートウェイ URL（C2→C3 で FRRTP を送信する宛先）。
- smpBaseUrl：当該参加者 ID のメタデータを公開する SMP のベース URL。
  
  例
  
  participantId = urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP
  providerId = esp-a.jp
  providerEndpoint = https://gw.esp-a.jp/eps
  smpBaseUrl = https://smp.esp-a.jp/smp/

実装方式（最小構成）

初期段階では DNS/NAPTR ではなく、HTTPS API として実装してもよい。

エンドポイント例

ベース URL：https://sml.sme-edi.example.jp/
API 例：

GET /participants/{url-encoded-participantID}

例：
GET /participants/urn%3Ajp%3Agov%3Agbizid%3AGBIZ-1234-5678-ABCD%3Adept%3AAP

レスポンス例（JSON：MVP 版）

{
  "participantId": "urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP",
  "providerId": "esp-a.jp",
  "providerEndpoint": "https://gw.esp-a.jp/eps",
  "smpBaseUrl": "https://smp.esp-a.jp/smp/",
  "status": "ACTIVE",
  "lastUpdated": "2025-11-01T12:34:56Z"
}

Table 1. SML 内部データモデル例
項目	内容
participant_id	参加者 ID（gBizID＋部署 ID の URN）
provider_id	プロバイダ ID（ESP ドメイン）。FRRTP の `To`／`From` に用いる `username@domain` の `domain` と一致する。
provider_endpoint	当該プロバイダ（ESP）の EPS ゲートウェイ URL（C2→C3 で FRRTP を送信する宛先）。
smp_base_url	当該参加者 ID のメタデータを公開する SMP のベース URL。
status	`ACTIVE` / `SUSPENDED` / `RETIRED` など。
effective_from / effective_to	有効期間（将来の移行／廃止計画を見据えたオプション）。
last_updated	最終更新日時。

認証・認可

読み出し（GET）は原則として公開（オープンディレクトリ）とし、
- 改ざん防止のため HTTPS/TLS を必須とする。
登録・更新 API は ESP 管理者のみが利用し、
- クライアント証明書や OAuth2 等による認証を行う。

ステップ 4：SMP による「参加者 ID → 連携アドレス」の公開

SMP の役割

SMP（Service Metadata Publisher）は、各参加者 ID について、

文書種別（Document Type）
取引プロセス（Process）
ネットワークアドレス（username@domain）
必要なセキュリティ情報（TLS 証明書、署名ポリシ等）

を公開する。

プロバイダ（ESP）と SMP の対応関係

本仕様におけるプロバイダ（ESP）と SMP の関係は、次のように整理する。

プロバイダ（ESP）:
- EPS（FRRTP）によるメッセージ送受信を行うアクセスポイント事業者。
- FRRTP の To／From に含まれる username@domain の domain 部分が、当該 ESP を一意に識別する「プロバイダ ID（ESP ドメイン）」となる。
SMP:
- 各プロバイダが運営する「参加者ごとのサービスメタデータ公開サーバ」。
- 原則として「1 プロバイダ = 1 SMP インスタンス」とし、その SMP は当該プロバイダ配下の参加者 ID のみを掲載する。

このとき、SML と SMP、プロバイダ（ESP）の対応関係は次のようになる。

SML レコード
- キー：参加者 ID（gBizID＋部署拡張の URN）
- 値：少なくとも次の情報を保持する。
  - providerId：プロバイダ ID（ESP ドメイン）。FRRTP の To／From の @domain と一致する。
  - providerEndpoint：当該プロバイダ（ESP）の EPS ゲートウェイ URL。
  - smpBaseUrl：当該参加者 ID のメタデータを公開する SMP のベース URL。
    
    例
    
    participantId = urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP
    providerId = esp-a.jp
    providerEndpoint = https://gw.esp-a.jp/eps
    smpBaseUrl = https://smp.esp-a.jp/smp/
SMP レコード
- キー：（participantID, documentTypeID, processID）
- 値：少なくとも次の情報を保持する。
  - networkAddress：EPS で用いる連携アドレス（username@domain）。この domain 部分は providerId と一致する。
  - transportProfile：FRRTP 等の輸送プロトコル区分。
  - 必要に応じて TLS 証明書、署名ポリシ等。
    
    例
    
    participantId = urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP
    documentTypeId = urn:japan:sme-edi:doc:invoice:4.3
    processId = urn:japan:sme-edi:process:billing:1.0
    networkAddress = ap_accounting@esp-a.jp // domain = providerId = esp-a.jp
    transportProfile = FRRTP-HTTPS-SOAP12

この構造により、送信側 ESP（C2）は次の手順で宛先を決定する。

ペイロード（SBDH 等）から受信側参加者 ID（ReceiverParticipantID）、文書種別（DocumentTypeID）、プロセス ID（ProcessID）を取得する。
中央ディレクトリ（SML）に問い合わせ、ReceiverParticipantID から
providerId（C3 ESP のドメイン）、
providerEndpoint（EPS ゲートウェイ URL）、
smpBaseUrl（当該 ESP の SMP ベース URL）
を取得する。
smpBaseUrl 上の SMP に問い合わせ、
(ReceiverParticipantID, DocumentTypeID, ProcessID) に対応する
networkAddress（username@providerId）および必要なセキュリティ情報を取得する。
取得した networkAddress を FRRTP の To に設定し、
宛先 URL として providerEndpoint を用いて EPS（FRRTP/SOAP over HTTPS）で送信する。

このとき、

プロバイダ ID（ESP ドメイン）は SML レコードおよび SMP の networkAddress に明示され、
参加者 ID とプロバイダ（ESP）の対応関係は SML 上で一元管理される。

したがって、参加者 ID の所属プロバイダを変更する場合には、
SML の providerId と smpBaseUrl／providerEndpoint を更新し、
SMP 側に新たな networkAddress を登録するだけでよい。
参加者 ID 自体および各利用企業の取引先マスタに記録された ID を変更する必要はない。

SMP の API 構成例

ベース URL

例：https://smp.esp-a.jp/smp/

サービス一覧取得

GET /participants/{url-encoded-participantID}/services

レスポンス例（JSON）

{
  "participantId": "urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP",
  "services": [
    {
      "documentTypeId": "urn:japan:sme-edi:doc:invoice:4.3",
      "processId": "urn:japan:sme-edi:process:billing:1.0",
      "networkAddress": "ap_accounting@esp-a.jp",
      "transportProfile": "FRRTP-HTTPS-SOAP12",
      "tlsRequired": true,
      "signaturePolicy": "NONE"
    },
    {
      "documentTypeId": "urn:japan:sme-edi:doc:order:4.3",
      "processId": "urn:japan:sme-edi:process:order2invoice:1.0",
      "networkAddress": "ap_order@esp-a.jp",
      "transportProfile": "FRRTP-HTTPS-SOAP12",
      "tlsRequired": true,
      "signaturePolicy": "NONE"
    }
  ]
}

特定サービス詳細取得

GET /participants/{url-encoded-participantID}/services/{url-encoded-documentTypeID}/{url-encoded-processID}

レスポンス例（JSON）

{
  "participantId": "urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP",
  "documentTypeId": "urn:japan:sme-edi:doc:invoice:4.3",
  "processId": "urn:japan:sme-edi:process:billing:1.0",
  "networkAddress": "ap_accounting@esp-a.jp",
  "transportProfile": "FRRTP-HTTPS-SOAP12",
  "tlsRequired": true,
  "signaturePolicy": "NONE",
  "certificate": {
    "subject": "CN=ap.esp-a.jp, O=ESP-A, C=JP",
    "fingerprint": "15:2F:AA:...:9C",
    "validFrom": "2025-01-01T00:00:00Z",
    "validTo": "2027-12-31T23:59:59Z"
  }
}

ステップ 5：SBDH による「業務 ID」のメッセージ埋め込み

SML/SMP が参照する参加者 ID や文書種別・プロセス ID をメッセージ内に明示するため、
SBDH（Standard Business Document Header）を導入する。

SBDH に格納する情報の例

Sender/Partner/Identifier = 送信側参加者 ID（gBizID＋部署 URN）
Sender/Partner/Authority = JP:GBIZID
Receiver/Partner/Identifier = 受信側参加者 ID
Receiver/Partner/Authority = JP:GBIZID
DocumentIdentification.Standard = SME-EDI 等
DocumentIdentification.Type = Invoice 等
BusinessScope/Scope[Type="PROCESSID"]/InstanceIdentifier =
対応するプロセス ID（注文〜請求／請求〜支払等）

ディレクトリ層との関係

C2 は、ペイロード内の SBDH を読み取り、
ReceiverParticipantID + DocumentTypeID + ProcessID をキーとして SML/SMP を問い合わせる。
得られた networkAddress を FRRTP の To に反映する。
FRRTP はあくまで「連携アドレス（username@domain）宛てにメッセージを輸送する」役割に限定される。

ステップ 6：デュアル運用と完全移行

デュアル運用期間

一定期間、次の 2 方式を併存させる。

旧方式：
- アプリが直接 username@domain を指定。
- C2 は従来どおり「ドメイン→ESP」のローカルテーブル等でルーティングする。
新方式：
- アプリは gBizID 参加者 ID を指定。
- C2 は SBDH（またはアプリ指定）から参加者 ID／文書種別／プロセス ID を取得し、
  SML/SMP を経由して username@domain を解決する。

C2 実装のフォールバック例

gBizID 参加者 ID が指定されていれば、SML/SMP を用いて username@domain を決定する。
参加者 ID が指定されていない場合は、従来どおりの username@domain をそのまま用いる。

これにより、既存システムを段階的に新方式へ移行できる。

完全移行後

アプリケーションやマスタは「取引先＝gBizID 参加者 ID」を前提とし、
連携アドレス（username@domain）は内部実装詳細として扱うことが可能になる。
取引先マスタから連携アドレス列を非表示または自動設定とし、
業務ユーザは gBizID ベースの ID のみを意識すればよい。

ステップ 7：プロバイダ乗り換え時の運用

企業 A が ESP-X から ESP-Y に乗り換えるシナリオを例示する。

前提

企業 A の参加者 ID：urn:jp:gov:gbizid:GBIZ-1234-5678-ABCD:dept:AP

必要な作業

SML レコードの更新：
- 旧：A-ID → providerId=esp-x.jp, smpBaseUrl=https://smp.esp-x.jp/smp/
- 新：A-ID → providerId=esp-y.jp, smpBaseUrl=https://smp.esp-y.jp/smp/
ESP-Y の SMP における登録：
- (A-ID, Invoice, billing-process) → ap_accounting@esp-y.jp

送信側から見た影響

送信側アプリは引き続き「取引先＝A-ID（gBizID 参加者 ID）」で送信する。
C2 は SML/SMP を参照した結果として、
ap_accounting@esp-x.jp から ap_accounting@esp-y.jp に自動的に切り替える。
取引先マスタ中の ID は変更不要であり、
プロバイダ乗り換えに伴うマスタメンテナンス負荷を大幅に削減できる。

まとめ

現行の EPS 仕様は、username@ESPドメイン 形式のアドレス設計により、
事業者 ID とプロバイダが一体化しており、実質的なプロバイダ・ロックインを招いている。
gBizID を基盤とした参加者 ID（＋部署拡張）を定義し、SML/SMP で
「参加者 ID → providerId / smpBaseUrl → networkAddress（username@domain）」を段階的に導入することで、
EPS の輸送仕様を維持しつつロックインを解消できる。
SBDH に Sender/Receiver の参加者 ID、文書種別、プロセス ID を明示することで、
異なるメッセージ構文（共通 EDI、JP-PINT、CII 等）を跨いだルーティングや変換も一貫して扱える。

Table of Contents

はじめに
現状と課題
- 現行 EPS 連携方式の概要
- 現状の課題
目指す姿（ゴール）
ステップ 1：gBizID ベースの参加者 ID（部署拡張）の設計
ステップ 2：既存連携アドレスとの対応表の整備
SML/SMP 実装パターンの概要
ステップ 3：SML の最小実装
ステップ 4：SMP による「参加者 ID → 連携アドレス」の公開
- プロバイダ（ESP）と SMP の対応関係
- SMP の API 構成例
ステップ 5：SBDH による「業務 ID」のメッセージ埋め込み
ステップ 6：デュアル運用と完全移行
ステップ 7：プロバイダ乗り換え時の運用
まとめ

三分一技術士事務所

gBizID を用いたユーザ ID 統一と SML/SMP 管理方式への移行ステップ

gBizID を用いたユーザ ID 統一と SML/SMP 管理方式への移行ステップ

はじめに

現状と課題

現行 EPS 連携方式の概要

現状の課題

目指す姿（ゴール）

ステップ 1：gBizID ベースの参加者 ID（部署拡張）の設計

ステップ 2：既存連携アドレスとの対応表の整備

SML/SMP 実装パターンの概要

ステップ 3：SML の最小実装

ステップ 4：SMP による「参加者 ID → 連携アドレス」の公開

プロバイダ（ESP）と SMP の対応関係

SMP の API 構成例

ステップ 5：SBDH による「業務 ID」のメッセージ埋め込み

ステップ 6：デュアル運用と完全移行

ステップ 7：プロバイダ乗り換え時の運用

まとめ

コメント

コメントを残すコメントをキャンセル

2025年11月
月	火	水	木	金	土	日
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

gBizID を用いたユーザ ID 統一と SML/SMP 管理方式への移行ステップ

gBizID を用いたユーザ ID 統一と SML/SMP 管理方式への移行ステップ

はじめに

現状と課題

現行 EPS 連携方式の概要

現状の課題

目指す姿（ゴール）

ステップ 1：gBizID ベースの参加者 ID（部署拡張）の設計

ステップ 2：既存連携アドレスとの対応表の整備

SML/SMP 実装パターンの概要

ステップ 3：SML の最小実装

ステップ 4：SMP による「参加者 ID → 連携アドレス」の公開

プロバイダ（ESP）と SMP の対応関係

SMP の API 構成例

ステップ 5：SBDH による「業務 ID」のメッセージ埋め込み

ステップ 6：デュアル運用と完全移行

ステップ 7：プロバイダ乗り換え時の運用

まとめ

コメント

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル