EUDI Wallet連携：統合ルートの選び方（2026年版ガイド）
EUDI Wallet連携を比較。4つのルート、第5b条(10)に基づき仲介者ができることとできないこと、2026/1730以降の証明書モデル、ベンダーへの質問、自社に残る責任を解説します。
要点
EUDI Wallet の統合は、技術プロジェクトである前に一つの判断です。ウォレットに対して依拠当事者として立つのは誰か。自社か、自社のために行動する仲介者か、という判断です。[1][6]
- 登録は常に自社の加盟国で行います。登録した範囲を超えて要求することはできません。[1]
- 仲介者は依拠当事者とみなされ、取引内容に関するデータを保存できません。このため、その役割を担うベンダーが自社のために保持できる情報は限られます。[1]
- 強力な認証義務を負う民間企業は、2027年12月24日までにウォレットを受け入れます（当社の計算）。零細企業と小企業は免除されます。[1]
European Digital Identity（EUDI）Wallet は、この冬に実際の期限を迎えます。各加盟国は2026年12月24日までにウォレットを提供する義務を負い、ウォレットを受け入れる企業向けの登録規則も同じ日に適用されます。[1][2] 多くのチームにとって、問いは「それは何か」から「どう接続するか」に移りました。
本ガイドは、EUDI Wallet 統合の4つのルートを比較し、委託できることと自社に残ることを区別し、各機能をその根拠となる規則に対応付けます。現行法と、技術的な設計図である Architecture and Reference Framework（ARF）バージョン 3.0.0 を、仲介者に関する2026年7月の変更も含めて読み解きます。[3][6]
まず基本を確認したい場合は、EUDI Wallet の依拠当事者：登録、証明書、義務とOpenID4VP verifier ガイドをお読みください。法律についてはeIDAS 2 の解説をご覧ください。
判断を進める間もユーザー確認を続ける
Didit は現在、各国の eID と書類確認を一つのワークフローで実行しています。EUDI Wallet の受け入れは近日対応予定です。無料で始めるか、欧州のユーザー基盤についてご相談ください。
EUDI Wallet 統合が実際に担うべきこと
仕事は5つあります。誰かがサービスを登録する。誰かが要求者を証明する鍵を保持する。誰かが署名付きリクエストを送る。誰かが返ってきたものを検証する。誰かが記録を保管する。ルートごとに、この分担が異なります。
ARF は、ウォレットとやり取りするシステムを Relying Party Instance と呼びます。ARF では、このシステムはアクセス証明書で認証を行い、その秘密鍵は「Relying Party Instance のハードウェア内に安全に保存される」とされています。[6] 二つ目のオブジェクトである登録証明書は、一つの利用目的と、そのために登録された属性を記載します。[1][6] 依拠当事者は、すべての提示要求にこれらのいずれかを値として含めます。[7]
エコシステムにおける依拠当事者の位置。出典：EUDI Wallet Architecture and Reference Framework、European Commission、CC BY 4.0。
2026年の二つの変更が、調達の判断を変えます。2026年7月15日の実施規則（EU）2026/1730 は登録規則を改正しました。加盟国は登録証明書を発行する認証局を少なくとも1つ認可しなければならず、発行は自動化されなければなりません。[3] また、附属書I第16項として、仲介者がサービスを提供する依拠当事者へのリンクが追加されました。附属書IIにより、アクセス証明書はこれを含まなければなりません。[3]
計画を左右する日付
- 2026年8月11日規則改正2026/1730 発効。当社の計算：7月22日の公布から20日後。
- 2026年12月24日ウォレット提供期限2025/848 の登録規則が適用。
- 2027年7月10日AMLR 適用外部委託と記録の規則が大半の義務主体に適用。
- 2027年12月24日受け入れ第5f条(2)の民間依拠当事者（当社の計算）。
- 2028年8月11日証明書確認ウォレットは登録証明書を認証し、検証しなければならない。
日付の出典は Regulation (EU) No 910/2014、2025/848、2026/1730、2026/1731 および AMLR です。2027年12月24日は当社の計算です。実施法令の発効から36か月後です（2024年12月4日公布、その20日後に発効）。[1][2][3][4][5][9]
法的な発動要件は第5f条(2)にあります。対象は、法律または契約によりオンライン本人確認で強力な利用者認証の使用を求められる民間の依拠当事者で、銀行、エネルギー、医療などの分野を含みます。この規定は「利用者の任意の要求があった場合に限り」適用されます。[1] 超大規模オンラインプラットフォームは第5f条(3)に基づく別の義務を負い、条文上に別個の日付はありません。[1] 全体の日程はEUDI Wallet のすべての期限をご覧ください。
EUDI Wallet 統合の4つのルート
この表は、誰がどの法的役割でウォレットとやり取りするかでルートを分類しています。工数と管理度は当社の評価であり、法的な基準ではありません。
| ルート | ウォレットに対面する者 | 証明書 | 管理度 | 負担 | 適した事業者 |
|---|---|---|---|---|---|
| 自社で検証者を構築する | 自社（依拠当事者として） | 自社がアクセス証明書と登録証明書を保有する | 最も高い | 最も高い：鍵、トラストリスト、ウォレットのテスト | セキュリティエンジニアリング体制を持つ銀行や大規模プラットフォーム |
| 依拠当事者仲介者 | 仲介者が自社に代わって | アクセス証明書は仲介者が保有し、登録証明書は自社のものとなる | 中程度：契約で定まる | プロトコル面は低いが、新たなベンダー監督が必要 | ウォレットのみを必要とする事業者 |
| 本人確認またはオーケストレーションのプラットフォーム | 製品による：どの役割に当たるかを確認する | 通常、ウォレット部分については仲介者と同様 | 中程度：複数の手段にまたがる | 導入の負担は最も低いが、依存度は最も深い | ウォレット、eID、本人確認書類のルートを1つのフローで必要とする事業者 |
| ウォレットプロバイダーまたはトラストサービス向けツール | 場合による：ツールは製品であり、役割ではない | さまざま | 用途によって異なる | ユースケースによる | 署名、属性証明の発行、検証と並行するニーズ |
ルート1：自社で検証者を構築する
自社がRelying Party Instanceを運用します。欧州委員会はリモート検証者と近接検証者を構築するためのガイド付きのリファレンス実装を公開しており、その検証者エンドポイントはApache 2.0でライセンスされています。[14][15] それでも、ハードウェアで保持する鍵、インスタンスとサービスごとの証明書、トラステッドリストのダウンロード、仕様変更時のアップグレードは自社の責任です。[6][7]
ウォレットの取扱量が多い場合や、提示された属性を第三者に見せることをリスク管理チームが認めない場合に適しています。
ルート2：依拠当事者仲介者
Article 5b(10)がこのモデルの法的な枠組みを定め、残りはARFが具体化しています。仲介者とは、依拠当事者に代わってその業務を行う「依拠当事者の特別な類型」であり、顧客は「アクセス証明書を必要としない」とされています。[6]それでも登録は必要です。仲介者は、各顧客がその顧客の設立地である加盟国で登録されていることを確保しなければならないためです。[7]
ルート3：本人確認プラットフォームまたはオーケストレーションプラットフォーム
「プラットフォーム」は商業上の用語であり、Article 5b(10)には出てきません。ウォレットの部分では、プラットフォームは仲介者としてそれに伴うあらゆる制約を負うか、自社のインスタンスのホスティング事業者となるかのいずれかです。その価値は、複数の手段を1つの統合で振り分けられる点にあります。リスクは、プラットフォームが本人確認書類について行うこと、例えば証跡を何年も保管することが、ウォレットにもそのまま当てはまると考えてしまう点です。当てはまらない可能性があります。
未解決の論点
自社のアクセス証明書のもとで自社のインスタンスをホスティングするだけのベンダーは、仲介者に当たるのでしょうか。ARFの定義である「依拠当事者に代わってWallet Unitとやり取りする」者という文言は広く読めますが、この点を決着させる条文は見つかりませんでした。[6]契約を締結する前に、顧問弁護士と登録機関に確認してください。
ルート4：ウォレット提供者またはトラストサービス提供者のツール
ウォレット提供者やトラストサービス提供者もソフトウェアを販売しており、適格署名が必要な場合や属性証明を発行したい場合に役立ちます。登録規則では、これらの活動を個別の資格として定めており、通常の事業者向けのService_Providerと並んで、QEAA_ProviderやQCert_for_ESig_Providerなどがあります。[2]ツールが自社に代わってウォレットとやり取りする場合は、仲介者に関する規則に照らして確認してください。
自社に残る責任と委託できる業務
Article 5b(10)Regulation (EU) No 910/2014
「依拠当事者に代わって行動する仲介者は、依拠当事者とみなされ、取引の内容に関するデータを保存してはならない。」
出典：EUR-Lex、統合版テキスト[1]
仲介者が依拠当事者と「みなされる」からといって、自社の義務がなくなるわけではありません。Article 5b(9)は、依拠当事者に対し、自らが要求する本人識別データおよび属性証明の認証・検証手続を実施する責任を課しています。[1]ARFは役割分担を契約に委ねており、「仲介者とそのサービスを利用する依拠当事者は、仲介者がどの検証を実施するかについて合意しなければならない」としています。[6]登録機関は、署名済みの契約書や委任状など、関係を示す証拠の提出を求めることがあります。[6]
| 業務 | ベンダーに委託できるか | 規定 |
|---|---|---|
| 利用目的とデータを決定する | 不可：自社の判断事項 | Art. 5b(2)(c)、5b(3)[1] |
| 自社の加盟国で登録を受ける | 登録機関が認めれば書類作成は可。登録は自社のものとして残る | Art. 5b(1)[1]、RPI_03[7] |
| 登録内容を正確に維持する | 支援は可。義務は自社に残る | Art. 5b(6)[1] |
| アクセス証明書を保有し、要求を送信する | 可：仲介者として | ARF §6.6.5[6] |
| 真正性、失効、デバイスおよび利用者との紐付けを検証する | 可：合意した場合 | RPI_09[7] |
| リクエストごとに登録証明書を選択する | お客様が指定する | RPI_05[7] |
| ユーザーの削除要求に対応する | 支援のみ。お客様の連絡先は登録証明書に記載されており、ウォレットは消去要求をお客様に送る | RPRC_11[7]、2024/2982 第6条[4] |
| リスクプロファイルと取引関係を判断する | AMLRの義務主体については不可。ただしファンドに関する適用除外が1つある | AMLR 第18条(3)、18(7)[9] |
規制対象事業者には、さらに3つの層があります。マネー・ローンダリング防止規則（AMLR）は、義務主体が業務を外部委託することを認めていますが、事前に監督当局へ通知し、「全面的な責任」を負い続けなければなりません。[9] デジタル・オペレーショナル・レジリエンス法は、ICT契約の下でも金融事業体が「全面的な責任」を負うものとしています。[11] 一般データ保護規則（GDPR）は、十分な保証を提供する処理者を求めています。[10] 当社が確認した条文には、仲介者が処理者か管理者かを定めたものはありません。そのため、お客様の分析内容を契約に記録してください。
仲介者の仕組みと、証明書の数が重要な理由
両方の識別子を照合する
お客様の名称をユーザーに表示する
合意したチェックを実行する
提示データを削除する
仲介者を介した提示。ARF §6.6.5およびTopic 52を簡略化したもの。[6][7]
第一に、ユーザーに表示されるのはベンダーの名称ではなくお客様の商号です。ただしウォレットは仲介者を記録するため、ユーザーは後から仲介者を確認できます。[6] 第二に、ウォレットは登録証明書の識別子とアクセス証明書の識別子を照合し、不一致時の処理によって取引が停止されることがあります。[6] 第三に、お客様と仲介者の間のインターフェースはARFの対象外であり、ARFは属性のエンドツーエンド暗号化を求めていません。そのため、ベンダーがすべての属性を閲覧できる可能性は十分にあります。[6]
要点はARFの計算にあります。施行規則2026/1730は、サービス提供先の依拠当事者との紐付けを登録データに追加します。ARF v3.0.0ではアクセス証明書がその紐付けを保持するため、仲介者は「仲介する依拠当事者ごとに別個のアクセス証明書一式を受け取る」ことになります。[3][6] 2026年7月より前に共有証明書モデルを説明していたベンダーは、新しい設計をお客様に示す必要があります。規模はリスクを集中させます。仲介者のアクセス証明書認証局が停止されると、その証明書は失効し、お客様は「登録がまだ有効であるにもかかわらず」属性を要求できなくなります。[7] 別の仲介者に移行するか待つしかないため、出口計画は運用上の統制です。
依拠当事者の認証。どのルートでも実施しなければならない手順です。出典：EUDI Wallet Architecture and Reference Framework、European Commission、CC BY 4.0。
証跡の問題：削除か保存か
削除を求める規定
仲介者と検証者
- 取引内容に関するデータを保存しない（第5b条(10)）
- 転送後に「完全かつ直ちに」削除する（RPI_10）
- 不要になった時点で署名値、ソルト、ハッシュおよびタイムスタンプを破棄する（OIA_16）
規則およびARF Annex 2[1][7]
保存を求めるルール
義務主体
- 電子的識別手段により取得した情報を保存する（第77条(1)(a)）
- 5年間保存する
- 外部委託した業務がリスクを軽減していることを監督当局に示す（第18条(2)）
AMLR、2027年7月10日から[9]
OIA_16は、Relying Party Instanceに対し、すべての固有要素を破棄し、それらを「Relying Partyまたはその他のいかなる当事者にも」伝達しないよう求めています。この固有要素には、アテステーション提供者の署名が含まれます。[7] したがって、署名付きウォレット応答を監査証跡として保存するという約束は、どのベンダーによるものであっても検証が必要です。ARFはフレームワークであり、法令ではありません。また、5年間の保存義務との関係で「不要になった」の意味を定めていません。顧問弁護士に確認し、規制対象であれば監督当局にも確認してください。
以下は当社が提案する設計です。ルールではなく、検証が必要です。
| 記録 | 保有者 | 根拠 |
|---|---|---|
| デューデリジェンスに必要な属性 | 貴社（自社システム内） | AMLR 第77条[9] |
| 確認ログ：日時、方法、実施した確認、結果、使用した証明書 | 貴社（固有要素を除く） | AMLR 第18条(2)、当社の提案[9] |
| 顔写真（要求する場合のみ） | 必要な場合または法令に定めがある場合を除き保存しない | ARF Annex 2[7] |
| 署名、ソルト、ハッシュ | 貴社にとって未解決の法的論点 | OIA_16[7] |
| 仲介者における取引内容 | 誰も保有しない：直ちに削除 | 第5b条(10)[1]、RPI_10[7] |
ベンダーが示すべき機能と、それぞれの根拠となる規則
この表は、提案依頼書（RFP）の技術付属書として、または自社開発の際に使用してください。
| 段階 | 機能 | 規則または標準 |
|---|---|---|
| 設定 | 登録データ（仲介者との紐付けを含む） | 2025/848 附属書I 第14点から第16点[2][3]、TS5 usesIntermediaries[8] |
| 設定 | インスタンス、サービス、顧客ごとのアクセス証明書、ハードウェアで保持する鍵 | ARF §3.11.3[6]、2026/1730 を通じた ETSI TS 119 411-8[3] |
| 設定 | Trusted Lists および Lists of Trusted Entities から取得し、更新されるトラストアンカー | OIA_12、OIA_15a[7] |
| 要求 | 登録された用途外の属性を確実にブロック | 第5b条(3)[1]、2025/848 第9条(2)(c)[2] |
| 要求 | 現在の用途に対応する登録証明書を、各要求に値として含めること | RPRC_19[7] |
| 要求 | 推奨: OpenID4VC-HAIP と ISO/IEC mdoc の両プロトコルプロファイル | 2024/2982 に対する 2026/1731 の附属書[5] |
| 検証 | 発行者署名（アテステーションの種類別） | OIA_12 から OIA_15[7] |
| 検証 | 失効確認、およびステータスが不明な場合の書面による方針 | VCR_13、VCR_14[7] |
| 検証 | デバイスバインディングと選択した利用者バインディングの方法 | OIA_17、ARF §6.6.3.9[6][7] |
| 事後 | 固有要素の廃棄 | OIA_16[7] |
| 事後 | 削除請求と、データ保護監督機関への連絡先 | RPRC_11、RPRC_12[7]、2024/2982 第6条、第7条[4] |
| 保証 | 公開済みのテスト結果 | OpenID Foundation の自己認証[12] |
OpenID Foundation は2026年8月7日、OpenID for Verifiable Presentations (OpenID4VP) の適合性テストを自己認証向けに公開しました。検証者は無料で実行できます。自己認証の公開には料金がかかります。[12] 欧州委員会の Functional Conformance Assessment Framework は依然として「活発に開発中」であり、最初のテスト対象システムは Wallet Solution です。したがって、現時点で同フレームワークから依拠当事者向けのバッジを得られるとは考えないでください。[13] 形式については、本人識別データ (PID) のクレデンシャルは mdoc と SD-JWT VC の両方で発行しなければなりません。ただし、その他の属性証明は一つずつ確認してください。違いは当社の形式比較で解説しています。[7]
各国のウォレットではなく、デザインガイドの説明用画面です。共有前に利用者が確認する内容を示しています。EUDI Wallet Architecture and Reference Framework, Annex 5(欧州委員会、CC BY 4.0)から改変(トリミング)。[16]
ウォレット経路と非ウォレット経路の振り分け
第5a条(15)は、ウォレットの利用は「任意とする」と定め、「既存の他の識別・認証手段によって公共及び民間のサービスにアクセスすることが引き続き可能でなければならない」としています。[1] したがって、ウォレットを唯一の入口にすることはできません。AMLR 第22条(6)も同様に、本人確認書類、または保証レベル substantial もしくは high の電子識別を認めています。[9]
1その国で利用できる方法を提示する
利用者が選択します。ウォレットへのリクエストは、利用者が求めた場合にのみ開始します。
ウォレットでの提示が成功し、自社のチェックを通過したか
続行
ウォレットから得られない情報を補完します。
自社のポリシーを適用
書面によるリスク分析に基づき、受け入れるか拒否するかを決定します。
別経路へ振り分け
各国の eID、次に生体検知付きの本人確認書類。
2スクリーニング、リスク評価、判断
どの方法を使っても同じ記録を残します。
すべての入口を開いたままにする振り分け設計です。ステータス不明の経路は VCR_14 に従います。[1][7]
顔写真がPIDの必須データになり得るのは2028年8月11日以降であり、加盟国は利用者がその提供を拒否できるようにすることができます。そのため、ウォレットとの顔照合に依存する設計は常に機能するとは限りません。[5] ウォレットだけで足りる場合とライブネス検知を追加すべき場合については、holder bindingに関する記事で解説しています。項目や識別子の国ごとの違いは27以上の各国ウォレットの受け入れに、導入状況は国別トラッカーにまとめています。規制対象のオンボーディングについては、AMLRとEUDI Walletをお読みください。
ウォレットの登場前にルーターを設計する
この経路は、現在ある手段で今すぐ構築できます。Diditによる本人確認は、書類撮影、NFCチップ読み取り、ライブネス検知、顔照合に対応し、国や結果に応じた分岐を設定できます。[18][19]
企業の種類別の経路の選び方
第5f条(2)：強固な利用者認証の使用が義務付けられており、零細企業または小企業に該当しない
受け入れ義務
2027年12月24日までの稼働開始を計画してください。
任意
超大規模オンラインプラットフォームとして第5f条(3)が適用される場合を除きます。受け入れる場合は登録が必要です。
鍵の管理、トラストリスト、ウォレットのテストを自社で運用できる
自社構築
または、ベンダーからの移行手段として自社構築を残しておきます。
ベンダーを利用
仲介事業者のみ。他の手段も必要な場合はプラットフォーム。
出発点として示すものです。最終判断は顧問弁護士と取扱量によります。[1]
| 貴社の種類 | 初期の経路 | 注意点 |
|---|---|---|
| 銀行または決済事業者 | 自社構築、または自社構築の選択肢を残した仲介事業者 | AMLR第18条およびDigital Operational Resilience Act[9][11] |
| フィンテックまたは暗号資産事業者 | プラットフォームまたは仲介事業者 | 第5f条(2)が適用されるかを確認。データ保存期間[1][9] |
| 超大規模オンラインプラットフォーム | 自社構築または仲介事業者 | 第5f条(3)、最小限のデータ[1] |
| 年齢制限のあるサービスまたは小規模事業者 | 受け入れる場合はベンダー | 必要な情報のみを求める。本人確認が求められない場面では仮名を拒否しない[1] |
| 複数の加盟国にまたがるグループ | 設計は1つ、登録は複数 | 各事業体が、設立されている加盟国で登録する[1] |
| EU域内に拠点を持たない事業者 | まず専門家の助言を受ける | 当社が確認した条文には該当する手続が記載されていない。第5b条(1)は拠点を基準としている[1] |
ベンダーに書面で確認すべき事項
登録簿に関する規定は2026年12月24日から適用される。登録済みサービスであるとの主張には、その根拠となる登録簿の記載を求めること。[2]
| 項目 | 書面で取得すべき内容 | 警告サイン |
|---|---|---|
| 法的な役割 | ウォレット側での役割、どの登録機関にいつ届け出るか | 「当社はプラットフォームなので該当しない」 |
| 自社の登録 | 誰がどの権限で届け出て、誰が更新するか | 登録簿の記載がベンダー名義になる |
| 証明書 | 2026/1730以降の顧客ごとのモデル | 全顧客で1つの証明書を共有 |
| 認証局 | どの認証局を利用し、いずれかが停止された場合にどう対応するか | 代替の調達先がなく、離脱手段もない |
| 実施する検証 | 一覧:真正性、失効、デバイスとの紐付け、利用者との紐付け | 「当社がウォレットを検証します」 |
| データの可視性 | 属性を平文で閲覧できるか | 回答なし |
| 削除 | 転送後の削除方法とその証明 | 「お客様の監査のため」に保持されるプレゼンテーション |
| 自社の記録 | 自社のシステムに何がどのような形式で届くか | 証跡はベンダーのポータル内のみ |
| 範囲の制限 | 未登録の属性に対する技術的なブロック | 慎重に設定するという約束 |
| テスト | 公開された結果、およびウォレット名とバージョンを明示したテスト | 「すべてのウォレットで動作」 |
| 移行 | 利用者への新たな影響なしに別の仲介者へ移行できる | ベンダーに紐づいた登録 |
今月やるべきこと
- 各法人に第5f条(2)と第5f条(3)のどちらが適用されるかを書面で確認する。[1]
- ユースケースごとに、必要最小限の属性を一覧にする。
- 自社の登録機関と、その国の登録ポリシーを確認する。[2]
- OIA_16と自社の保存義務との関係について、法律顧問に確認する。[7][9]
- 失効ステータスが不明な場合のポリシーを策定する。[7]
- 義務主体が外部委託を行う場合は、監督当局への届出案を作成する。[9]
- 現在利用できる手段でフォールバック経路を構築する。
関連記事のEUDI Walletのポリシーと統制では、これらの手順を担当者と証跡を明記した統制マトリクスに落とし込んでいます。
DiditによるEUDI Wallet連携の支援
EUDI Walletの受け入れは近日対応予定で、時期と価格はまだ決まっていません。[17]当社の取り組みはEUDI Walletソリューションページをご覧ください。同ページの文言は「今日統合し、ウォレットが届いてもそのまま使い続ける」です。
現在提供しているのは、本ガイドで説明したフローのそれ以外の部分です。DiditはMitID、BankID Sweden、Finnish Trust Network、Smart-ID、Mobile-IDを本人確認書類の撮影と併せて運用し、書類によるフォールバックを設定済みです。[18]詳しくはeID verificationをご覧ください。ワークフローは国と結果によって分岐し、Webhookには署名が付き、保存期間は1か月から10年まで設定できます。[19][20][21]Diditはデータ処理者として機能し、お客様は引き続き管理者となります。[22]DiditはSOC 2 Type 1およびType 2の報告書、ISO/IEC 27001:2022認証、iBeta Level 1のプレゼンテーション攻撃検知テストを取得しています。[23]料金は料金ページをご覧ください。
Diditが提供するもの
- 国のeIDと本人確認書類チェックを1つのワークフローで
- ルーティングの分岐と本人確認書類によるフォールバック
- 署名付きWebhookと設定可能な保存期間
貴社に残る責任
- 依拠当事者としての登録と利用目的
- リスク評価、方針、顧客に関する判断
- 保存に関する判断と法的分析
要点
- 本当の選択は、ウォレットに対して誰が依拠当事者として向き合うかです。貴社か、仲介者かです。
- 第5b条(10)により、仲介者は依拠当事者とみなされ、取引の内容に関するデータを保存することはできません。
- 2026/1730は、サービスを受ける顧客をアクセス証明書に記載します。ARF v3.0.0は、仲介者に顧客ごとに別個のセットを付与します。
- 削除ルールと保存義務は衝突します。OIA_16とAMLR第77条の関係は弁護士と整理してください。
- 第5a条(15)は他の手段を引き続き認めています。まずルーティングを設計してください。
よくある質問
EUDI Wallet統合プラットフォームとは何ですか。
アプリケーションをEUDI Walletに接続するサービスで、他の本人確認手段と併せて提供されることが多いものです。この用語に法的な意味はありません。ウォレットとのやり取りにおいて、ベンダーは仲介者か、貴社専用インスタンスのホストのいずれかです。どちらの役割に当たるかを確認してください。[1][6]
EUDI Walletを自社サービスに統合するにはどうすればよいですか。
自国の加盟国で登録し、各利用目的とその属性を定義したうえで、経路を選びます。自社の検証者、仲介者、プラットフォーム、専門ツールのいずれかです。リクエストはアクセス証明書で署名され、登録証明書を伴います。[2][7]
依拠当事者の仲介者とは何ですか。
依拠当事者に代わってウォレットとやり取りする個人または企業です。第5b条(10)はこれを依拠当事者とみなし、取引の内容に関するデータの保存を禁じています。[1][6]
仲介者を利用する場合でも登録は必要ですか。
必要です。ARFは、各顧客がその設立地である加盟国で登録されていることを確保するよう仲介者に求めています。登録方法は登録機関が決定し、関係を証明すれば仲介者に届出を任せることも認められる場合があります。[6][7]
ベンダーは署名付きのウォレット応答を証跡として保持できますか。
未解決の問題として扱ってください。仲介者は取引内容を保存できず、ARF要件OIA_16は、検証者に対し不要になった署名値を破棄するよう求めています。規制対象事業者は、AMLR第77条との関係を弁護士と整理すべきです。[1][7][9]
民間企業はいつまでにEUDI Walletを受け入れる必要がありますか。
36か月を当社で計算すると2027年12月24日までです。対象は、法令または契約によりオンラインの本人確認に強力な利用者認証を用いることが求められる企業です。零細企業と小規模企業は適用除外で、受入れは利用者の任意の要求があった場合にのみ適用されます。[1]
EUDI Walletは本人確認書類の確認に代わるものになるか
個々の顧客については、要件を満たすウォレットで本人確認書類の確認を代替できます。ただし、それを唯一の手段にはできません。ウォレットの利用は任意であり、第5a条(15)により他の手段も引き続き利用可能にしておく必要があります。AMLRは電子的本人確認と並んで本人確認書類も認めているため、両方を用意しておくべきです。[1][9]
Diditは現在EUDI Walletを受け付けていますか
いいえ。EUDI Walletの受付は近日対応予定ですが、時期と価格はまだ決まっていません。現在、Diditは国のeIDと本人確認書類の確認を1つのワークフローで実行しています。[17][18]
出典
- Regulation (EU) No 910/2014、2024年10月18日時点の統合版、EUR-Lex。
- Commission Implementing Regulation (EU) 2025/848、ウォレット依拠当事者の登録、EUR-Lex。
- Commission Implementing Regulation (EU) 2026/1730(2026年7月15日)、EUR-Lex。
- Commission Implementing Regulation (EU) 2024/2982、プロトコルおよびインターフェース、EUR-Lex。
- Commission Implementing Regulation (EU) 2026/1731(2026年7月15日)、EUR-Lex。
- Architecture and Reference Framework v3.0.0、European Commission、2026年7月。
- ARF v3.0.0、Annex 2、トピック別の高水準要件、European Commission。
- Technical Specification 5、依拠当事者の登録フォーマットおよびAPI、European Commission。
- Regulation (EU) 2024/1624 (AMLR)、EUR-Lex。
- Regulation (EU) 2016/679 (GDPR)、EUR-Lex。
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act)、EUR-Lex。
- OpenID4VPおよびOpenID4VCIの適合性テストが完成し、自己認証の受付を開始、OpenID Foundation、2026年8月7日。
- Functional Conformance Assessment Framework、EUDI Walletプロジェクト。
- EUDI Wallet Reference Implementationのドキュメント、European Commission。
- EUDI verifierエンドポイントのリポジトリ、Apache License 2.0。
- ARF v3.0.0、Annex 5、データ共有シナリオの設計ガイド、European Commission。
- EUDI Wallet、Diditソリューションページ。
- デジタルIDウォレット、Diditドキュメント。
- ワークフロービルダー、Diditドキュメント。
- Webhook、Diditドキュメント。
- データ保持、Diditドキュメント。
- セキュリティとコンプライアンス、Diditドキュメント。
- 認証、Diditドキュメント。
今日選ぶルートは、ベンダーの変更、国のウォレットの遅れ、保存期間の監査に耐えられるものであるべきです。展開の状況とDiditの受入れへの取り組みは、EUDI Walletソリューションページでご確認ください。