EUDI Walletの国境を越えた受け入れ：1つの統合でEU全域に対応
1つの統合で各国のEUDI Walletをすべて受け入れる方法。実際のトラストリスト、国ごとに異なるPID属性、氏名の正規化、本人照合、フォーマット、テスト、導入が遅れている国への対応を解説します。
要約
EUDI Walletを国境を越えて受け入れるために必要なのは、27件の個別連携ではなく、共通ルールに基づく1つの検証者（verifier）の構築です。どのウォレットも同じ本人識別データ（PID）スキーマを同じ2つの形式で保持し、その署名者は欧州委員会が公表するリストと照合されます。[2][8] 各国ごとに異なるのは中身です。任意項目、氏名の表記方法、各ウォレットの提供開始時期がこれにあたります。
- 現時点で必須の属性は5つです。住所と国民識別番号は任意です。顔写真は2028年8月11日に必須項目に加わります。[2]
- 2026年10月31日時点で、欧州委員会による最初のPIDプロバイダーの一覧はまだ作成中でした。[12]
- EUの本人照合ルールが拘束するのは公的機関です。民間企業はこれを設計の参考として取り入れるべきであり、自社に適用されると考えるべきではありません。[5]
EUDI Walletの国境を越えた受け入れは27か国にまたがるプロジェクトに見えます。しかし、規則(EU) 2024/1183とその実施法令が、すべての加盟国に共通するデータモデル、形式、トラストリストを定めています。難しいのは自社システムの側です。フランスの顧客のPIDはポーランドの顧客のものとは見た目が異なり、再来顧客にはEU共通の識別子がなく、一部の国は提供が遅れます。
本ガイドは、依拠当事者が行うべきこととOpenID4VP検証者の仕組みを理解していることを前提としています。接続方法の選択については、EUDI Wallet連携ルートのガイドをご覧ください。以下のルールは、2026年7月の改正およびArchitecture and Reference Framework（ARF）3.0.0を含む一次資料に基づいています。
| 概要 | 簡潔な回答 |
|---|---|
| ウォレットの数 | 各加盟国に少なくとも1つ、つまり27以上[1] |
| 登録先 | 自社が設立された加盟国で1回のみ[1] |
| 検証の照合先 | 欧州委員会が公表する信頼されたエンティティのリスト（Lists of Trusted Entities、LoTEs）[8] |
| クレデンシャルの形式 | ISO/IEC mdocおよびSD-JWT VC[2] |
| EU共通の顧客ID | なし。照合は属性で行います[2][5] |
| 主な日付 | 2026年12月24日、2027年12月24日、2028年8月11日[1][2] |
今すぐ使えるルートが必要な場合
DiditでのEUDI Walletの受け入れは近日提供予定です。国民eIDと本人確認書類によるルートは、現在すでに同じワークフロー内で利用できます。無料で始めるか、対象国についてお問い合わせください。
EUDI Walletの国境を越えた受け入れが法的に意味すること
各加盟国は「少なくとも1つの欧州デジタルアイデンティティウォレット」を提供しなければなりません。提供方法は、直接、委任による提供、または独立して提供されその国が認めたもののいずれかです。したがって、1つの国に複数のウォレットが存在し得ます。[1] 依拠当事者は「設立された加盟国で登録しなければならない」とされ、登録は1回です。ウォレットは「EU域内のどこで設立されたかにかかわらず」その依拠当事者を認証できなければなりません。[1][6] また、依拠当事者は要求するデータについて「認証および検証の手続を実施する責任を負う」とされています。[1]
民間企業については、第5f条(2)が零細企業と小企業を除外しており、「利用者の任意の要求があった場合にのみ」適用されます。[1] 対象となる事業者については期限に関するガイドで解説しています。
- 2026年8月11日PIDルールの更新7月22日に公布された規則2026/1731が発効し、PIDの附属書を置き換えます。
- 2026年12月24日ウォレットの提供期限本人照合ルールと登録ルールも適用されます。
- 2027年第1四半期テストの基準適合性リリース候補の目標時期（目安）です。
- 2027年12月24日民間事業者による受入れ対象事業者に対する第5f条(2)の期限。
- 2028年8月11日顔写真、証明書顔写真が必須データセットに加わる。ウォレットが登録証明書を検証する。
国境を越えた導入を左右する日付。2026年12月24日と2027年の日付は、2024年12月24日の実施法令の発効日から算出しています。[1][2][5][15]
トラストモデル:単一の大きなリストではなくLoTE
PIDについて「EUのトラステッドリスト」と考えるのは誤りです。ARF 3.0.0は「Trusted ListsはQEAA Providersについてのみ存在する」と定めています。これは適格属性証明の発行者で、各国のリストには欧州委員会のList of Trusted Lists(LOTL)を通じてアクセスします。[8] それ以外はすべて信頼されたエンティティのリストに掲載されます。これは加盟国がエンティティを通知した後、「欧州委員会が署名し公表する」ものです。[8]
| リスト | 公表者 | 規格 | 必要な理由 |
|---|---|---|---|
| PID Providers LoTE | 欧州委員会 | ETSI TS 119 602 | PIDの署名を検証する |
| Wallet Providers LoTE | 欧州委員会 | ETSI TS 119 602 | 主に発行時にPIDプロバイダーが使用する |
| 公的機関の属性証明(PuB-EAA)プロバイダーのLoTE | 欧州委員会 | ETSI TS 119 602 | 公的機関の属性証明を検証する |
| アクセス証明書認証局、登録証明書プロバイダーの各LoTE | 欧州委員会 | ETSI TS 119 602 | ウォレットはこれらに照らして貴社を確認する |
| 各国のトラステッドリスト(LOTL経由) | 加盟国 | ETSI TS 119 612 | 適格属性証明を検証する |
各リストの役割。ARF第3.5節および規則2024/2980第5条に基づく。[4][8] 依拠当事者自体はどのリストにも掲載されない。[8]
EUDI Wallet のトラストモデル（原図のまま）。出典：EUDI Wallet Architecture and Reference Framework、European Commission、CC BY 4.0。
ウォレットが応答すると、検証者は1つのチェーンをたどります。どの加盟国の PID でも手順は同じです。
1リストを更新する
最新のリストをダウンロードし、欧州委員会が公開する証明書で署名を検証し、トラストアンカーを種類別に保存します。[4][9]
2PID の署名を検証する
プロバイダーのトラストアンカーまでの証明書パスを構築します。中間署名証明書が使われる場合があります。[9]
3失効を確認する
PID の有効期間が24時間を超える場合は、ステータスリストを確認します。[9]
4デバイスバインディングを検証する
ウォレットが、PID に紐付けられた鍵でチャレンジに署名したことを確認します。[9]
すべてのチェックに合格し、属性が自社のポリシーを満たしている
照合に進む
証跡を保存して続行します。
別の手段を使う
本人確認書類か国民eID を選択肢として提供します。
すべての発行国に共通する1つの検証チェーン。ARF のセクション 6.6.3.6 から 6.6.3.9 を要約したものです。[9]
注意
2026年10月31日時点で、eIDAS Dashboard には「The first compiled list of PID Providers is being prepared by the European Commission from the information notified by the Member States.」（PIDプロバイダーの最初の統合リストは、加盟国から通知された情報をもとに欧州委員会が作成中です）と記載されていました。[12] Wallet Provider、および Registrar と Register についても同じ記載です。リストの読み込み処理は今から構築してください。ただし、URL をハードコードしたり、現在のテストデータが本番環境と一致すると想定したりしないでください。
ARF は、失効チェックとデバイスバインディングのチェックを一般に「recommended but not mandatory」（推奨だが必須ではない）としています。一方で、ウォレットのユーザー認証を信頼することは「implies that Relying Parties must verify device binding」（依拠当事者がデバイスバインディングを検証しなければならないことを意味する）としています。[9] オンボーディングでは、両方を必須として扱うことをお勧めします。デバイスバインディングで証明できないことは別の論点です。
ウォレット自体は確認できません。PIDプロバイダーに依拠することになり、ウォレットユニットが失効すると PIDプロバイダーが PID を失効させます。したがって、PID のステータス確認でウォレットも確認できます。[9] エンティティはリストから削除されることはなく、Invalid に設定されるだけです。そのため、ステータスを確認してください。[8]
登録は一度だけ、要求は登録した範囲に限る
登録は自国でのみ行い、どのウォレットでも認証を受けられます。ウォレットは、リクエストを登録証明書と照合します。[1][6][9]
ウォレットが依拠当事者の登録を確認する仕組み（原図のまま）。出典：EUDI Wallet Architecture and Reference Framework、欧州委員会、CC BY 4.0。
欧州委員会のリストと照合
リクエストを登録内容と照合
自国で一度登録すれば、どこでも提示できます。ARF第6.6.3節および規則2025/848を簡略化したものです。[6][9]
国境を越えた場面での落とし穴は、その結果です。登録した範囲を超えて要求すると、ウォレットは「開示の前にウォレット利用者に明確に警告しなければならない」とされています。ただし、利用者に続行を認めるか、登録済みの範囲だけを共有するか、リクエストを拒否するかは、各ウォレット提供者が自らのリスク分析に基づいて判断します。[2] そのため、過剰なリクエストを1件送るだけで、3つの国で3通りの異なる結果になり得ます。[2] ウォレットが登録証明書の検証を義務付けられるのは2028年8月11日からです。1つの結果に頼らず、ウォレットごとにこの挙動をテストしてください。[2]
どの国で必要になり得る属性もすべて登録し、そのうえでジャーニーごとに必要な属性だけを要求してください。加盟国は登録証明書を「求めることができる」とされているため、登録機関の方針を確認してください。[6] 当社のポリシーと統制に関するガイドでは、これを責任者の明確な統制に落とし込んでいます。
PID属性：スキーマは同じでも中身は異なる
規則2024/2977のPID附属書は、2026年7月に規則2026/1731によって置き換えられました。そのため、古い表は最新ではありません。[2] 属性名も2つの形式の間で異なります。
| データ識別子 | ステータス | mdoc名 | SD-JWT VC名 | 異なる点 |
|---|---|---|---|---|
| family_name, given_name | 必須 | 同じ | 同じ | 文字体系、氏名の順序、前置詞・冠詞類 |
| birth_date | 必須 | birth_date | birthdate | 不明な場合の加盟国ごとの値 |
| birth_place | 必須 | place_of_birth | place_of_birth | 国、地域または市区町村 |
| nationality | 必須 | nationality | nationalities | 1つまたは複数。QU、QS |
| portrait | 2028年8月11日から | portrait | picture | 認められる場合はユーザーによるオプトアウト |
| resident_address および構成要素 | 任意 | resident_* | address.* | 全文、構成要素、またはなし |
| personal_administrative_number | 任意 | 同上 | 同上 | 存在の有無とそのポリシー |
| family_name_birth、given_name_birth | 任意 | 同上 | birth_family_name、birth_given_name | 発行の有無 |
| sex、email_address、mobile_phone_number | 任意 | 同上 | sex、email、phone_number | 発行の有無 |
2026年7月に置き換えられた自然人のPID。[2] メタデータ: issuing_authority と issuing_country は必須です。expiry_date、issuance_date、document_number、issuing_jurisdiction は任意です。[2]
以下の各項目をテストしてください。
- 国籍不明と無国籍。国籍不明は値 QU、無国籍は QS です。[2] 厳格な ISO 国コードパーサーはどちらも拒否します。
- 出生地。国、地域、市区町村のうち「少なくとも1つを含まなければならない」とされています。[2]国の記載がなく町名だけが届く場合があります。
- 複数の国籍。プロバイダーはそのすべてを「含めることができる」とされています。Rulebookでは、2つ目の国籍を国内属性に入れることも認めています。[2][11]
- 番地。resident_streetに家屋番号が含まれるようになり、独立した家屋番号の属性は廃止されました。[2][3]
- 国内独自の追加属性。各国は、eu.europa.ec.eudi.pid.[country]などの名前空間や国内独自のタイプで属性を追加でき、これらは規則2025/1569に基づいて公表されます。[2]
マネー・ローンダリング防止規則（AMLR）の対象事業者にとって、1つのウォレットでは足りなくなるのがこの点です。EUマネー・ローンダリング防止機関（AMLA）が2026年9月30日に公表した最終ドラフト基準（まだドラフトの段階です）は、ある手段がすべての属性を保持していない場合、事業者は「不足する属性を他の手段により取得し、検証するための措置を講じなければならない」としています。[14]
| AMLR第22条(1)のデータ | PIDの取得元 | 国境を越えた場合の不足 |
|---|---|---|
| 氏名 | family_name、given_name | データセット上はなし |
| 出生地と生年月日 | birth_place、birth_date | 出生地は一部のみの場合あり |
| 国籍 | nationality | 他の国籍を保有しているか顧客に確認する[14] |
| 国民識別番号（該当する場合） | personal_administrative_number | 任意、国により異なる |
| 住所 | resident_*の各フィールド | 任意のため、別の経路で収集する |
| 納税者番号（入手可能な場合） | PIDには含まれない | 他の属性または情報源 |
AMLAのドラフト基準の附属書Iに基づいています。[13][14]このドラフトには、2026年7月のPID附属書で削除されたresident_house_numberがまだ記載されているため、対応関係は変わる見込みです。[2][14]全体の見解はAMLRガイドをご覧ください。
氏名、住所、地名の正規化
PIDのテキストはUnicodeの全範囲を使うUTF-8で、mdocのテキストフィールドには150文字の上限があります。[2]ラテン文字への翻字を持つPID属性はありません。附属書もRulebook 1.7も翻字を定義していません。[2][11]そのため、制裁スクリーニングや既存の記録がラテン文字を使っていても、顧客の情報がギリシャ文字やキリル文字で届くことがあります。AMLAのドラフトは、氏名を「元の文字体系で、および／またはラテン文字に翻字して」スクリーニングするよう事業者に求めています。[14]
最も近い法的基準は公的機関向けに書かれたもので、照合の結果は「可能な限り、翻字、空白、ハイフネーション、連結その他これに類する正書法上の差異の影響を受けないものとする」としています。[5]法的要件ではなく技術上の助言として、推奨する設計は次のとおりです。
- 原本を保持する。署名済みの値は証拠として保存し、照合用のキーは別に導出します。
- 正規化は1か所で行う。Unicode正規化（NFC）を適用し、大文字・小文字を統一し、空白をまとめ、ハイフンとアポストロフィは区切り文字として扱います。
- 段階的に照合する。まず完全一致、次に発音区別符号を除いた形、次に語順を変えた形を試し、どの段階で一致したかを記録します。
- 文字体系の違いは証拠として扱う。単一の翻字表ではなく、顧客自身の書類にあるラテン文字表記を使います。
例
架空の顧客の例です。自社の記録は「Garcia Nunez, Maria」です。PIDではfamily_nameが「García-Núñez」、given_nameが「María José」です。第1段階では一致しません。発音区別符号とハイフンを除くと姓は一致します。追加の名がまだ異なるため、生年月日を補強材料としてレビューに回します。
言語の扱いは自社の責任です。言語やロケールを持つPID属性はないため、自社のフローから取得してください。[2][11] ウォレットは独自の画面を表示しますが、自社のリクエスト、利用目的の説明文、エラーメッセージは翻訳が必要です。顔写真については、規則上、利用目的を「明確かつ分かりやすい言葉で」示すことが求められます。[2]
住所にも同様の注意が必要です。resident_addressは自由記述ですが、構成要素は別々の属性であり、いずれも欠けている可能性があります。[2] AMLAの草案は国、市町村、通りの要素を求めており、その前文は属性を「構造化されたデータ項目」で扱うことを求めています。[14] 両方の形式を受け入れてください。
本人照合とリピーター顧客
EU全体で共通の顧客番号はありません。personal_administrative_numberは任意項目で、一意であるのは「当該提供者が発行したすべての個人行政番号の中で」に限られます。[2] 要求した形式のPIDが複数ある場合、状況から決まらない限りウォレットが利用者に選択を求めます。また技術的なPIDの有効期間は通常、数日から数週間です。[10][11] したがって、アカウントをPIDの署名、公開鍵、document_numberで紐付けてはいけません。
規則(EU) 2025/846は、2026年12月24日から適用される国境を越えた本人照合の手続を定めています。同規則は「公的機関または［...］公的機関に代わって行動する機関」を拘束します。[5] 民間の依拠当事者がこれらの仕組みを利用できるかは加盟国が決め、利用する場合は手続が「該当する場合」に適用されます。[5]
第2条(7)規則(EU) 2025/846
「照合が完全に一致しない場合、もしくは複数の自然人に該当する場合、または本人照合を行う当事者が照合の一義性を保証できない場合、本人照合の手続は不成功とみなされる。」
1データセットを収集する
必須のPID属性に加え、データセットを一意にするために必要な任意データ。[5]
2自社の記録と照合する
可能な範囲で表記上の揺れは無視します。[5]
ちょうど1人と完全一致
成功
利用者に通知し、このアカウントについて照合結果の保存を提案します。[5]
新規利用者
規則上認められる場合は新規として登録します。[5]
不成功
理由を説明し、別のウォレット、データの更新、または追加情報の提供を提案します。[5]
3手続を記録する
使用した値、日時、結果、関連する識別子。[5]
規則2025/846のプロセスを簡略化して示します。公的機関はこれに従う必要があります。民間事業者にとっては、国内規則がこれを拡張しない限り、ひな形にとどまります。[5]
ログは「セキュリティ目的のため最低6か月、最長12か月」保存され、その他の目的での長期保存は、EU法または国内法が要求する場合に限られます。[5] ログはAML記録とは分けて管理してください。最初の照合の後は、本人とアカウントとの紐付けを自社で保存してください。これは列挙された再利用の選択肢の1つです。こうすれば、PIDが再発行されても同じ作業を繰り返さずに済みます。[5]
Diditで国別ルーティングを計画する
DiditでのEUDI Walletの受け入れは近日提供予定です。現在は、国ごとに受け入れる国民eIDと、失敗時の処理を選択できます。失敗時の処理には書類撮影へのフォールバックも含まれます。[21] 対象とする国についてお問い合わせください。
フォーマット、プロトコル、ウォレットのバージョン
PIDプロバイダーは「いかなるPIDも両方の」フォーマットで「発行しなければならない（SHALL）」とされています。そのため、PIDのみを扱う検証者はどちらか一方を要求することもできますが、テストで別の結論が得られない限り、両方に対応してください。[10] 違いについてはSD-JWT VCとmdocの比較で解説しています。提示には2つのプロファイルがあり、それぞれにウォレットへ到達する方法が2つあります。[2]
| プロファイル | フォーマット | API仲介型 | 非API仲介型 |
|---|---|---|---|
| ISO/IEC-mdoc | mdoc | ISO/IEC 18013-7 Annex C | ISO/IEC 18013-5 |
| OpenID4VC-HAIP | SD-JWT VC、mdoc | HAIP 第5節、第5.2節、第5.3節、第7節、第8節 | HAIP 第5節、第5.1節、第5.3節、第7節、第8節 |
規則2024/2982附属書II。2026年7月に追加。[2][7]
規則は日付付きの仕様を指定しており、改正法によって変更される可能性があります。また、ISOのサーバー取得方式はすべての者について禁止されています。[2][7] オペレーティングシステムも変動要因です。ウォレットは仲介APIに対応しなければなりませんが、端末やブラウザが両方のプロトコルに対応していない場合があることを規則は記載しており、その場合をウォレットの管理外にある不適合として扱っています。[2]
認証の状況は、プロトコル適合性とは別に確認してください。加盟国は、第5d条に基づき、欧州委員会のリストのために認証済みウォレットを報告します。[1] 欧州委員会の機能適合性フレームワークはまだ0.x系です。「暫定的」と明記されたそのロードマップは、「2027年第1四半期のリリース候補」を目指しており、バージョン1.0.0を「認証に適した最初のフルスコープのベースライン」と位置付けています。[15]
各国のウォレットが登場する前にテストする
欧州委員会のリファレンス実装には、サンプルウォレット、テスト用検証者、テスト用発行者が含まれ、検証者エンドポイントとトラスト検証のオープンなリポジトリも公開されています。[19] 合格はプロトコルへの適合を示すものであり、各国のウォレットの挙動を示すものではありません。
Launchpad 2026のテストトラックは、「ローンチに先立ち、実環境の条件下でソリューションがどのように連携するかを検証する」段階に移行し、eIDAS DashboardでLoTEへのテストアクセスが提供されています。[16] 依拠当事者はLarge Scale Pilotsまたは国からの招待を通じて参加し、ソリューションプロバイダーも参加しています。[16] これまでに6つのパイロットが実施され、その中には越境認証に関するPOTENTIALがあります。[18] APTITUDEとWE BUILDは引き続き活動中で、後者はビジネスと決済のユースケースを扱っています。[17]
| テストケース | 入力 | 期待される結果 |
|---|---|---|
| 両方のフォーマット | 同一人物、mdocとSD-JWT VC | 同一の内部レコード |
| 住所なし | resident_* フィールドのない PID | 住所は別の経路で取得 |
| 出生地が一部のみ | 市区町村のみ | 受信したとおり受け入れて保存 |
| 無国籍または不明 | QS, QU | パーサーの障害ではなく、ポリシー上の判断 |
| 非ラテン文字の氏名 | ギリシャ文字またはキリル文字 | 原文のまま保存し、スクリーニングにはラテン文字表記を使用 |
| プロバイダーによる無効化 | ステータスが Invalid に設定 | リスト更新後に拒否 |
| 失効した PID | ステータスリストで失効と表示 | 拒否し、別の経路を提示 |
| 過剰な要求 | 登録されていない属性 | 自社のリリース前チェックで検出 |
| 既存顧客の再訪 | 新しい技術的 PID、同一人物 | 同じアカウント |
国の対応が遅れている場合の対処
当社のEUDI Wallet トラッカーで国別の状況を確認できます。ドイツとイタリアには個別のガイドがあります。各国を3つの状態のいずれかを持つ設定として扱い、報道ではなくリストに基づいて切り替えてください。
状態A
掲載済みかつテスト済み
- LoTE に掲載された PID Provider
- 自社のテストケースに合格
- ウォレットを他の手段と並べて提供する
期限が到来した時点で第5f条(2)が適用される
状態B
アプリは稼働中だが、リスト未掲載
- 国のアプリが存在する
- 検証できるトラストアンカーがない
- 無効のままにするか、別個のスキームとして扱う
そのスキーム独自の規則を確認する
状態C
ウォレットはまだない
- 受け入れる対象がない
- 国民eIDまたは本人確認書類を使う
- リストが変わったら再確認する
AMLR第22条(6)の手段は引き続き利用できる
展開に向けた国別の状態モデル。これは当社の提案であり、法令はこれらの状態を定義していません。
いずれにせよ他の手段は必要です。ウォレットの利用は「任意とする」ものとされ、ウォレットを持たない人のアクセスを「制限し、又は不利にしてはならない」とされ、他の手段の利用は「引き続き可能でなければならない」とされています。[1] AMLRの下では、本人確認書類と、保証レベル「substantial」または「high」の電子識別が、検証手段として並列に位置付けられています。[13] 統合の手段は、対応が遅れる国を設定項目の1つとして扱えるようにしておくべきです。
今月のクロスボーダー対応チェックリスト
- 第5f条(2)の対象となる事業体と国を洗い出す。[1]
- 自社の本拠加盟国の登録機関と登録方針を確認する。[6]
- いずれかの国で必要になり得る属性をすべて列挙する。
- mdocとSD-JWT VCの属性名を対応付ける社内スキーマを1つ作る。[2]
- 旧PID表を2026年7月の附属書に置き換える。[2]
- QU、QS、出生地の一部欠落についてテストケースを追加する。[2]
- ETSI TS 119 602とETSI TS 119 612に対応するリストローダーを作る。[8]
- 照合失敗時のメッセージを顧客の各言語で作成する。[5]
- 照合のログ保存期間を設定し、AMLの保存期間と比較する。[5]
- パイロット、Launchpad、または欧州委員会のプログラムへの参加について、自国のナショナルコーディネーターに問い合わせる。[16][20]
Diditによるクロスボーダー受け入れの支援
DiditでのEUDI Walletの受け入れは近日提供予定です。最新情報はEUDI Walletのページでご確認いただけます。現時点では、その周辺の手段を構築できます。国民eID(MitID、BankID Sweden、Finnish Trust Network、Smart-ID、Mobile-ID)はウォレットサインインで利用でき、「ウォレットの属性名は異なる」ため、結果は正規化されます。[21] 受け入れるウォレットを国ごとに選択でき、失敗時に本人確認書類へフォールバックするか拒否するかも選べます。[21] 書類による手段は14,000+種類の書類に対応しています。[22] 上記の氏名と住所の欠落については、顧客の書類を読み取ります。また、AMLスクリーニングは1,300+の制裁、PEP、ウォッチリストの情報源と照合して実行されます。[23]
Diditが提供するもの
- 利用可能と記載されている国民eIDによるサインイン
- 書類撮影、ライブネス検知、顔照合
- 国ごとの国民eIDの選択とフォールバック
- AMLスクリーニング
- 1か月から10年までの保存期間設定[24]
貴社に残る責任
- 依拠当事者（relying party）としての貴社の登録
- 貴社のリスク評価とポリシー
- オンボーディングの判断
- 貴社の自社記録との照合ルール
- 記録の保管と監督当局との関係
重要なポイント
- 1つの検証者（verifier）ですべてのウォレットに対応できます。ただし、データの取扱いは国ごとの違いを前提にする必要があります。
- PIDプロバイダーは国のトラステッドリストではなく、信頼されたエンティティのリスト（Lists of Trusted Entities）に掲載されます。
- 現時点で必須の属性は5つだけです。住所と国民識別番号は任意です。
- EU共通の顧客識別子は存在しません。照合は属性と、貴社側でのアカウントとの紐付けに依存します。
- 規則2025/846は公的機関を拘束します。民間企業にとっては、国内規則が適用範囲を広げない限り、参考にする設計です。
- 対応の遅い国はルーティング上の一つの状態として扱い、本人確認書類と国民eIDを用意しておきます。
よくある質問
各国のEUDI Walletごとに個別の統合が必要ですか。
いいえ。ウォレットは1つのPIDスキーマ、2つの形式、共通の提示プロファイルを共有しているため、1つの検証者で対応できます。[2] それでも、ウォレットごとにテストしてください。
検証者はPIDをEUのList of Trusted Listsと照合しますか。
いいえ。ARF 3.0.0によれば、トラステッドリストはQEAAプロバイダーについてのみ存在します。PIDプロバイダーは、欧州委員会が署名・公表する信頼されたエンティティのリスト（List of Trusted Entities）に掲載されます。[8]
すべてのウォレットから必ず受け取れるPID属性はどれですか。
family_name、given_name、birth_date、birth_place、nationalityです。2028年8月11日からはportraitが加わります。[2] ただし、利用者は個々の属性の共有を拒否できます。[2]
ウォレットには常に顧客の住所が含まれますか。
いいえ。住所属性はすべて任意のため、住所を含まないPIDを想定してください。[2] AMLAの基準案では、欠けている属性は他の手段で取得し、検証しなければならないとされています。[14]
再来顧客の照合に使える欧州共通の識別子はありますか。
ありません。personal_administrative_number は任意項目で、一意性はその提供者の範囲内に限られます。[2] 属性で照合し、本人とアカウントの紐付けは自社で保持してください。[5]
本人照合に関する規則2025/846は、銀行その他の民間企業に適用されますか。
直接には適用されません。対象は公的機関であり、民間の依拠当事者に適用されるのは、加盟国がその民間事業者に本人照合の実施を認めた場合に限られます。[5] いずれの場合も、設計の雛形として活用してください。
ギリシャ文字やキリル文字の氏名はどう扱えばよいですか。
署名済みの値は受領したまま保存し、別途照合キーを導出してください。PID にはラテン文字の翻字属性がありません。[2][11] 当社の推奨は、比較用のラテン文字表記を顧客の本人確認書類から取得することです。
ウォレットの提供開始が遅れた国のウォレットも受け入れなければなりませんか。
受け入れられるのは実在するウォレットだけです。対象となる事業者には2027年12月24日の期限があります。[1] 他の手段も維持してください。ウォレットの利用は任意であり、他の手段も引き続き利用可能でなければなりません。[1]
各国のウォレット提供開始前に、国境を越えた受け入れをテストできますか。
一部は可能です。欧州委員会のリファレンスツールは公開されており、Launchpad のテストではテスト用 LoTE を使用します。[16][19] リファレンスツールで確認できるのはプロトコルの適合性であり、各国ウォレットの挙動ではありません。
Didit は現在 EUDI Wallet を受け入れていますか。
Didit での EUDI Wallet の受け入れは近日提供予定です。国民eID と本人確認書類によるルートは、同じワークフローの中で現在利用できます。[21][22]
出典
- Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183、統合版、EUR-Lex。
- Commission Implementing Regulation (EU) 2026/1731、規則2024/2977、2024/2979、2024/2980 および 2024/2982 を改正、EUR-Lex、2026年7月15日。
- Commission Implementing Regulation (EU) 2024/2977、本人識別データ、EUR-Lex、原文。
- Commission Implementing Regulation (EU) 2024/2980、通知、EUR-Lex。
- Commission Implementing Regulation (EU) 2025/846、国境を越えた本人照合、EUR-Lex。
- Commission Implementing Regulation (EU) 2025/848、ウォレット依拠当事者の登録、EUR-Lex。
- Commission Implementing Regulation (EU) 2024/2982、プロトコルおよびインターフェース、EUR-Lex。
- Architecture and Reference Framework 3.0.0, chapter 3, Roles、欧州委員会。
- Architecture and Reference Framework 3.0.0, chapter 6, Trust model、欧州委員会。
- ARF Annex 2, High-level requirements by topic、欧州委員会。
- PID Rulebook, version 1.7、欧州委員会、2026年7月17日。
- Compiled list of PID Providers、eIDAS Dashboard、欧州委員会、2026年10月31日閲覧。
- Regulation (EU) 2024/1624 (AMLR)、EUR-Lex。
- AMLR 第28条(1)に基づく規制技術基準案に関する最終報告書、AMLA、2026年9月30日。
- Functional conformance roadmap、EUDI Wallet 機能適合性フレームワーク、2026年10月31日閲覧。
- Launchpad Testing 2026、欧州委員会、2026年10月23日更新。
- What are the Large Scale Pilots、欧州委員会、2026年7月22日更新。
- PID Identification Manual、欧州委員会、2026年2月11日更新。
- EUDI Wallet Reference Implementation documentation、欧州委員会。
- Relying Party Engagement Programme、欧州委員会、2026年9月18日更新。
- Digital ID Wallet Verification API and Coverage、Didit ドキュメント。
- ID Verification overview、Didit ドキュメント。
- AML Screening overview、Didit ドキュメント。
- Data retention、Didit ドキュメント。
導入の進捗は EUDI Wallet ページで確認できます。現在利用できるルートは eID 認証ページで、各オプションの比較は料金ページでご覧ください。