デジタルIDウォレットとVC。eKYCの次の形

Q: デジタルIDウォレットとeKYCはどう関係しますか？

現在のeKYCはサービスごとに毎回ゼロから本人確認をやり直す構造です。デジタルIDウォレットとVCは、一度確認した結果を本人が持ち歩いて別サービスで再利用する「次の形」にあたります。ただし日本ではVCを犯収法上の本人確認として使う制度整備が済んでいないため、当面はeKYC基盤をVCに接続しやすい設計にしておくことが実務の正解です。

Q: VCは日本の犯収法上の本人確認に使えますか？

現時点では、VCを犯収法上の本人確認方式として使うための法令上の位置づけは整備されていません。誰の発行するVCを信頼するか・事故時の責任をどう分配するかというトラストフレームワークは制度の問題として別に定める必要があり、VCが使えるようになるには法令レイヤーの整備が必要です。

Q: eKYCシステムを今つくる場合、VCに向けて何を準備すべきですか？

3点あります。確認結果を属性+証拠+確認手法+確認時点のセット（verified_claims相当の構造）で保存すること、本人確認方式をプロバイダとして抽象化し将来VC受け入れを追加できる構造にすること、署名検証・nonce・鍵ローテーションといったOIDC実装の基本品質を確保することです。特定ウォレット製品への深いコミットは制度が固まるまで待つのが安全です。

本人確認のたびにカードを読み取り、同じ属性情報を提出し直す。この「サービスごとに毎回ゼロからやり直すeKYC」の次の形として国際標準化が進んでいるのが、デジタルIDウォレットとVC（Verifiable Credentials）です。本記事は、「VCとは何か」「eKYCとどう関係するのか」「自社のシステムはいま何を準備すべきか」を、eKYC基盤の刷新・新規構築を検討している事業会社の開発責任者が判断できるレベルまで整理します。現行制度での本人確認方式の全体像はeKYC完全マップ2026を参照してください。法令確認日: 2026年8月23日。

この記事の要点

VC（Verifiable Credentials）は「発行者が署名したデジタルの資格情報」を利用者本人がウォレットに保有し、サービスへ必要な部分だけ提示する三者モデルの仕組みです

標準部品は出揃いつつあります。データモデルはW3C VC、発行はOpenID4VCI、提示はOpenID4VP、確認済み属性の表現はOIDC4IDAのverified_claimsが担います

プロトコルが標準化されても、「そのVCを犯収法上の本人確認として認めるか」というトラストフレームワークは別問題で、制度の整備はこれからです

事業者がいま打てる手は、確認結果の構造化保存・確認手段のプロバイダ抽象・OIDC実装品質の3つです。VCが普及しても、しなくても損をしない設計にできます

毎回やり直すeKYCが抱える構造問題

現在の本人確認は、サービス単位で完結しています。銀行の口座開設でマイナンバーカードを読み取り、証券会社でまた読み取り、通信契約でまた読み取る。利用者は同じ操作を繰り返し、事業者はそのたびに確認コストを負担し、確認で取得した個人情報の保管リスクを個別に抱え込みます。事業者側に個人情報が蓄積される構造自体がリスクの源泉になっている点は、eKYCは危険なのかで整理したとおりです。

「一度きちんと確認した結果を、本人が持ち歩いて別のサービスでも再利用できないか」。この問いに対する国際標準の答えが、デジタルIDウォレットとVCです。発注者の立場では、「いま構築するeKYC基盤が、この次の形に接続できる設計になっているか」が仕様判断のポイントになります。

VCの基本構造: Issuer・Holder・Verifierの三者モデル

VCのエコシステムは、3つの役割の分離で成り立っています。

役割	何をするか	具体例
Issuer（発行者）	属性を確認し、署名付きの資格情報（VC）を発行する	行政、銀行、大学、eKYC実施済みの事業者
Holder（保有者）	VCを自分のウォレット（スマホアプリ）に保管し、いつ・誰に・何を提示するかを制御する	利用者本人
Verifier（検証者）	提示された資格情報の署名と失効状態を検証して受け入れる	サービス事業者

現行のeKYCと決定的に違うのは、確認のタイミングと利用のタイミングが分離され、その間を本人（Holder）が仲介する点です。VerifierはIssuerに問い合わせることなく署名を検証できる設計が基本形であり、これは「発行者が、誰がどこでその資格情報を使ったかを知らない」ことを意味します。プライバシーの構造が、現行の集中型の本人確認とは根本から異なります。

選択的開示というもう1つの鍵

VCを特徴づけるもう1つの概念が選択的開示（Selective Disclosure）です。たとえば年齢確認の場面で、「20歳以上である」という事実だけを、氏名も住所も生年月日そのものも渡さずに証明できます。免許証の画像を丸ごと提出させ、確認目的に不要な属性まで事業者が受領している現在の実務と比べると、データ最小化の到達点がまったく違います。取得する個人情報が減れば、事業者側の保管リスクと漏えい時の影響も小さくなります。

標準仕様の部品表

VC関連の仕様は乱立しているように見えますが、役割ごとに並べると整理できます。

部品	仕様	担う役割
データモデル	W3C Verifiable Credentials Data Model	VCの構造と署名の表現形式
発行プロトコル	OpenID4VCI	IssuerからウォレットへVCを発行する手順
提示プロトコル	OpenID4VP	ウォレットからVerifierへVCを提示する手順
確認済み属性の表現	OIDC4IDA（verified_claims）	「どの証拠で・どの手法で・いつ確認した属性か」をOIDCで運ぶ形式
相互運用プロファイル	HAIP（High Assurance Interoperability Profile）	高保証用途での仕様の組み合わせ方

実務上とくに重要なのは、OpenID4VCI/VPがOAuth・OIDCの延長線上に設計されていることです。OIDCのRP実装（署名検証・nonce・リダイレクト処理）を正しく作っている組織は、VC対応までの技術的距離が近い。逆にOIDCの基礎が崩れている実装は、VC以前の問題を抱えています。OIDCの仕様の骨格はOpenID Connectの仕様入門で解説しています。

EUと日本、それぞれの現在地

標準の実装・普及フェーズでは、EUと日本で駆動力が異なります。

EU: eIDAS 2.0規則により、加盟国はEUデジタルアイデンティティウォレット（EUDIウォレット）を市民へ提供する義務を負います。主要サービス側にも受け入れ義務が広がる方向で整備が進んでおり、ウォレット実装と相互運用試験の世界的な牽引役になっています
日本: マイナンバーカードのスマホ搭載とデジタル認証サービスが、事実上の公的ID基盤として先行しています（マイナンバーカードのスマホ搭載で本人確認はどう変わるか）。各種免許・資格のデジタル化などVC型資格証明の検討・実証も進んでいますが、民間取引の本人確認としての法令上の位置づけはこれからです

プロトコルの標準化と、制度上の受け入れは別問題

ここが本記事で最も重要な注意点です。技術仕様が最終化されても、「そのVCを犯収法上の本人確認として使ってよいか」は自動的には決まりません。

誰をIssuerとして信頼するか
失効・再発行の責任を誰が負うか
なりすまし事故が起きたときの責任分配をどうするか

これらはトラストフレームワークと呼ばれる制度設計の問題であり、技術では解決できません。犯収法の2027年改正が施行規則の号記号で本人確認方式を定めているのと同じレイヤーの整備が、VCにも必要になります（現行の方式体系は2027年のeKYC方式を参照してください）。「標準があるから使える」と「法令上の本人確認として認められる」の間には、明確な距離があります。

事業者がいま打つべき手・待つべき手

VCへの向き合い方は、「いま効く話」と「まだ先の話」に分けるのが実務的です。

いま効く3つの設計

確認結果をverified_claims的な構造で保存する — 確認した属性だけでなく、「どの証拠（evidence）で・どの手法で・いつ確認したか」をセットで構造化して持ちます。将来VCを発行・受け入れる際のデータ変換が容易になるうえ、現行の犯収法対応の確認記録としてもそのまま強い設計です。証跡の持ち方はeKYCの証跡設計で詳述しています
確認手段をプロバイダ抽象の背後に置く — JPKI・顔照合方式に続く「VC受け入れ」という新しい確認手段を、後から差し込める構造にしておきます。確認方式をアプリケーション本体に直書きしない設計原則は壊れないeKYC APIの設計のとおりです
OIDC実装の品質を上げる — 署名検証・nonce・鍵ローテーションといった基本の品質は、OpenID4VCI/VPでもそのまま要求されます。同じ筋肉を使うため、現行実装の品質向上がそのまま将来への投資になります

まだ先の話

特定のウォレット製品や特定のVC形式への深いコミットは、現時点では時期尚早です。トラストフレームワークが固まる前に一点張りをすると、標準の改版や制度の確定にともなって書き直しになるリスクがあります。「接続できる設計にしておく」ことと「特定実装に賭ける」ことは別物です。

ベンダー・開発会社への確認チェックリスト

eKYC基盤の新規構築・刷新でRFPや仕様レビューを行う際、「VCの次の形」への備えができているかは次の観点で確認できます。

確認結果は、属性・証拠・確認手法・確認時点をセットにした構造（verified_claims相当）で保存される設計か
本人確認方式は抽象化されており、新しい確認手段（将来のVC受け入れを含む）を追加できるか
OIDCを利用する場合、ID Tokenの署名検証・nonce検証・鍵ローテーション対応が実装されているか
特定ウォレット製品・特定VC形式への依存を前提としない構成か
「VC対応済み」を謳う場合、それが法令上の本人確認として利用可能かどうかを区別して説明できるか

最後の項目はとくに重要です。技術デモとしてのVC対応と、犯収法上の本人確認としての利用可否は別問題であり、この区別が曖昧な提案は制度理解に不安があります。

まとめ

VCはIssuer・Holder・Verifierの三者モデルで、「確認済みの結果を本人が持ち歩き、必要な部分だけ提示する」仕組みです。選択的開示により、事業者が受領する個人情報を最小化できます
標準部品はW3C VCデータモデル+OpenID4VCI/VP+verified_claimsで、OAuth・OIDCの延長線上にあります。既存のOIDC実装力がそのまま活きます
EUはeIDAS 2.0による義務化で先行し、日本はマイナンバーカードのスマホ搭載を軸とする公的ID基盤が先行しています
プロトコルの標準化と、法令上の本人確認としての受け入れ（トラストフレームワーク）は別問題で、後者の整備はこれからです
いま打つべき手は、確認結果の構造化保存・確認手段のプロバイダ抽象・OIDC実装品質の3つです。VCが来ても来なくても損をしない設計にできます

よくある質問

Q. Verifiable Credentials（VC）とは何ですか？

発行者（Issuer）がデジタル署名を付けて発行する資格情報で、利用者本人（Holder）が自分のウォレットに保管し、サービス事業者（Verifier）へ必要な部分だけを提示できる仕組みです。検証者は発行者に問い合わせずに署名と失効を検証できるため、発行者に利用履歴を知られない構造になっています。データモデルはW3Cで標準化されています。

Q. デジタルIDウォレットとeKYCはどう関係しますか？

現在のeKYCは、サービスごとに毎回ゼロから本人確認をやり直す構造です。デジタルIDウォレットとVCは、一度確認した結果を本人が持ち歩いて別サービスで再利用する「次の形」にあたります。ただし現時点の日本では、VCを犯収法上の本人確認として使うための制度整備が済んでいないため、当面はeKYC基盤をVCに接続しやすい設計にしておくことが実務の正解です。

Q. 選択的開示（Selective Disclosure）とは何ですか？

保有する資格情報のうち、証明に必要な部分だけを相手に開示する仕組みです。たとえば「20歳以上である」ことだけを、氏名や生年月日そのものを渡さずに証明できます。免許証の全項目を提出している現在の年齢確認と比べ、事業者が受領・保管する個人情報を大幅に減らせます。

Q. OpenID4VCIとOpenID4VPの違いは何ですか？

OpenID4VCIは発行者からウォレットへVCを発行するプロトコル、OpenID4VPはウォレットから検証者へVCを提示するプロトコルです。どちらもOAuth・OpenID Connectの延長線上に設計されているため、OIDCのRP実装を正しく作っている組織はVC対応への技術的距離が近くなります。

Q. VCは日本の犯収法上の本人確認に使えますか？

現時点では、VCを犯収法上の本人確認方式として使うための法令上の位置づけは整備されていません。プロトコルが標準化されても、誰の発行するVCを信頼するか・事故時の責任をどう分配するかというトラストフレームワークは制度の問題として別に定める必要があります。犯収法の本人確認方式は施行規則の号記号で定められており、VCが使えるようになるにはこのレイヤーの改正・整備が必要です。

Q. eKYCシステムを今つくる場合、VCに向けて何を準備すべきですか？

3点あります。第一に、確認結果を「属性+証拠+確認手法+確認時点」のセット（verified_claims相当の構造）で保存すること。第二に、本人確認方式をプロバイダとして抽象化し、将来「VC受け入れ」を追加できる構造にすること。第三に、署名検証・nonce・鍵ローテーションといったOIDC実装の基本品質を確保することです。特定のウォレット製品への深いコミットは、制度が固まるまで待つのが安全です。

主な参考資料: W3C Verifiable Credentials Data Model 2.0、OpenID for Verifiable Credential Issuance 1.0、OpenID for Verifiable Presentations 1.0、OpenID Connect for Identity Assurance 1.0、欧州委員会 EU Digital Identity Wallet、NIST SP 800-63-4

TodoONada株式会社は、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。方式選定から開発・運用までのワンストップ支援に加え、本記事で触れた「VC時代を見据えた確認結果のデータ設計」——verified_claims相当の構造化保存やプロバイダ抽象——を織り込んだeKYC基盤の設計相談にも対応しています。デジタル庁「デジタル認証アプリ」の利用申請・審査対応の伴走支援も可能です。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜です。詳しくはマイナンバーシステム導入支援をご覧いただくか、お問い合わせからご相談ください。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。