ZenChAIne
記事一覧に戻る
DID/VCは日本と世界でどこまで進んだか。制度、ウォレット、普及の課題【中編】

DID/VCは日本と世界でどこまで進んだか。制度、ウォレット、普及の課題【中編】

ZenChAIne·
DIDVCEthereum

はじめに

「デジタルIDが普及している」というニュースだけでは、自社で何を使えるのかは分からない。仕様が完成したのか、制度で導入時期が決まったのか、実証をしているのか、利用者がすでに使えるのか。これらは、それぞれ違う段階の話だ。

前編では、DID/VCが必要とされた背景と、利用者自身が識別情報や証明の管理に関わるSSIの思想を扱った。DIDは人や組織などを指す分散型識別子、VCは資格や所属などを検証可能な形で表すデータである。

中編では、日本と海外でデジタル証明がどこまで使われているのかをたどる。AppleやGoogleが採用するmdocも、利用者が証明を持ち歩く取り組みとして取り上げる。各国の事例は2026年9月17日まで、mdocと両社の開発資料は同月18日に確認した。EBSIとの関係、OpenCertsの提供主体、mdocとVCの相互運用に関する資料は同月22日に追加確認した。

この記事のポイント

  • 日本では属性証明の運用の検討と、本人確認や企業間取引の実証が進む。EUの制度整備や米国のモバイル免許証とは、用途も導入段階も異なる。
  • AppleやGoogleが採用するmdocは、ISO/IECの国際標準に基づくモバイル文書である。本人が証明を持ち、必要な情報を提示するという目的はDID/VCと重なる。
  • 証明を発行する仕組みに加え、受け入れる企業や機関、端末紛失時の対応、発行者の責任を決める必要がある。
  • 仕様の比較と実装の詳細は後編の技術仕様編（準備中）で扱う。

日本では、どのような取り組みが進んでいるのか？

日本では、データの信頼性を確かめる仕組みの検討から、身元や資格を証明する際の運用、具体的な利用場面の実証へと取り組みが広がっている。行政、チケット、企業間取引では、確認したい対象も、失敗したときの影響も異なる。

Trusted Webで扱ってきた問題

国内の流れを理解する上で、Trusted Webという取り組みがある。特定のサービスへの依存を抑えながら、個人や法人がデータを管理し、やり取りする相手やデータを検証できるようにする構想だ。デジタル庁の説明は、既存のインターネットやWebに、こうした信頼の仕組みを加える取り組みと位置付けている。

この問題意識は、前編で紹介したSSI（自己主権型アイデンティティ）と共通している。 Googleなどのアカウントで複数のサービスにログインするモデルは便利だが、利用者の識別や認証を、そのアカウントを管理する事業者に依存する。 SSIが目指すのは、利用者自身がアイデンティティ情報を管理し、誰に何を提示するかを選べることだ。 特定のプラットフォームへの依存を抑え、データを扱う本人のコントロールを増やすという点で、Trusted Webも同じ方向を向いている。

実際に、内閣官房が公開する2023年の調査報告書も、プラットフォーム事業者によるアイデンティティ情報の管理をめぐる課題を挙げ、SSIとTrusted Webに共通する問題意識を説明している。 Trusted Webでは、個人のIDに加え、法人を含むデータのやり取りや検証、その際のルールも扱っている。

内閣官房が公開する資料では、2023年11月にホワイトペーパー3.0、2024年6月にはガバナンスに関する考え方などが公表されている。技術的に署名を確かめるだけでなく、参加者のルールや責任をどう決めるかが議論されてきた。

Trusted Webは一つの暗号資産やブロックチェーンの名称ではない。DID/VCを使う実装を検討する際にも、どのデータを誰が発行し、受け取った側が何を根拠に利用するか、という業務の設計が必要になる。

2025年から2026年にかけての属性証明の検討

デジタル庁は2025年3月に、VCを用いたデジタル証明書のガバナンスに関する有識者会議を開催した。その後の属性証明の課題整理に関する有識者会議では、身元や資格などをデジタルに証明する仕組みについて、技術面と運用面のリスクを検討している。報告書の公表日は2026年4月9日である。

ここで出てくるDIWは、Digital Identity Wallet、デジタルアイデンティティウォレットの略だ。証明を受け取り、保存し、必要な相手へ提示するためのソフトウェアを指す。ウォレットという用語を聞くと、Ethereumの暗号資産を保管するウォレットと混同されがちだが、必ず同じ製品や仕組みになるわけではない。

2026年の報告書（掲載ページ）は、公的個人認証などによる身元確認に加え、資格や属性の証明も扱う。この政策資料でいうVCは、あくまでデジタル証明書を概念的に説明したものであり、各種標準化団体が定めるVC形式とは、同じ範囲とは限らない。

公的個人認証は、マイナンバーカードなどを用いた本人確認や電子署名を支える既存の仕組みだ。それを使う実証があっても、カード上の情報が一律にDID/VCへ置き換わったという意味にはならない。本人を確認する工程と、その確認結果や属性を別の場面へ持ち運ぶ工程を分けて見ると理解しやすい。

チケットの実証では、何を確かめたのか？

デジタル庁の2026年3月27日の発表では、マイナンバーカードを使うチケット関連の実証を紹介している。その一つとして、同年3月のイベントで、本人確認の結果をVCとして扱い、チケット販売事業者をまたいで利用するモデルを検証した。

ここで注目したいのは、資格証の電子化に限らず、「一度確認した結果を、別のサービスがどう受け入れるか」を試していることだ。公表資料の対象は特定のイベントでの実証であり、すべてのチケット事業者での利用や、本人確認費用の削減を示したものではない。

たとえば、受け入れる企業が変われば、許容する本人確認の方法や更新間隔も変わり得る。確認済みというデータを運べることと、相手がその確認を十分だと判断することの間には、合意が要る。

企業間取引にも用途がある

VCが扱う対象は個人だけではない。NTTデータが2026年5月に公表した実証では、行政手続き向けの事業者認証で使うGビズIDと接続し、法人の信用情報や、製造業の取引に関する情報を扱っている。

この事例からは、企業の存在や属性を確かめる作業にも、デジタル証明を使う余地があると考えられる。たとえば取引先ごとに同じ書類を提出する業務であれば、発行者と受け入れ条件を共有できるかが検討対象になる。公表資料が示すのは実証的な接続実験であり、全国の企業間取引に導入済みという話ではない。

海外では、何が実用化され、何が準備中なのか？

海外でも、すべての国が同じDID/VC基盤へ移行しているわけではない。制度で整備を進める地域もあれば、特定の証明書から用途を広げる取り組みもある。

EU：制度に基づいてウォレットを整備する

EUは、European Digital Identity Wallet、欧州デジタルアイデンティティウォレットの整備を進めている。公的な本人確認やデジタル証明を、国境を越えたサービスでも利用できるようにする枠組みだ。

欧州委員会の説明では、関連規則に基づき、加盟国が2026年末までにウォレットを提供することになっている。これは制度上の提供期限の説明であり、2026年9月時点ですべての国とサービスで利用できるという確認ではない。

大規模な実証の公式説明には、教育、銀行、公共サービスなどの用途が挙がる。ウォレットアプリを作るだけでなく、発行者や受け入れ側の接続、認証やプライバシーの要件をそろえる作業が必要になる。

EUDI Walletは、利用者が証明を受け取り、保管し、相手に提示するための仕組みだ。 EU共通の制度や仕様に沿って各国が提供するもので、EU全体で一つのアプリを使うという意味ではない。 公式の参照実装では、mdocやSD-JWT VCという証明書形式を扱っている。 ここでいうウォレットは、Ethereumなどのブロックチェーンの利用を前提とするものではない。

一方、欧州にはEBSI（European Blockchain Services Infrastructure、欧州ブロックチェーンサービス基盤）という取り組みもある。 EBSIは、ブロックチェーンを使い、証明書の発行者の識別情報や発行権限などを登録して、相手が検証できるようにする共通基盤だ。 公式のAPI資料には、DIDや信頼できる発行者の登録簿を扱う機能が示されている。 EUDI Walletが利用者の手元で証明を扱うのに対し、EBSIは発行者などの信頼性を確かめるために使える。

両者は組み合わせることもできる。 欧州委員会の2026年の標準化計画では、EBSIをEUDIの非適格属性証明（EU法上の「適格」の認定を伴わない属性証明）を支える登録簿や、証明を受け取る事業者の登録簿に利用できると説明している。 例えば、利用者がウォレットから資格証明を提示し、受け取った企業が発行者の権限をEBSIの登録簿で確認する、という役割分担が考えられる。 これは連携の使い方を示す例であり、すべてのEUDI WalletがEBSIに接続しているという意味ではない。 EBSIはEUDI Walletを支える基盤の選択肢になり得るが、必須の基盤ではない。

日本企業が接続を考える場合も、利用先で求められる証明形式に加え、発行者をどの登録簿で確認するか、どの運用ルールに従うかを確かめる必要がある。

米国の一例：カリフォルニア州のモバイル運転免許証

カリフォルニア州の車両管理局は、スマートフォンで扱う運転免許証の試行を案内している。公式ページでは、一部の空港や店舗などで使える場面を示す一方、引き続き物理的な免許証を携帯するよう説明している。

これは利用者が試せる取り組みだが、米国全体での統一導入ではない。また、スマートフォンで証明書を提示できるというだけで、W3CのDIDやVCがそのまま採用されているとは判断できない。モバイル文書にはISO/IECの規格もあり、「デジタル証明」という大きな用途の中に複数の技術系統がある。

受け入れる店舗や機関が増えなければ、利用者は従来の証明書も持ち続ける。普及を考える際には、発行件数だけでなく、実際に提示できる場面を確かめる必要があることが分かる。

シンガポール：証明書サービスの形式も更新される

シンガポールのOpenCertsは、政府主導で開発された、学歴などの証明書をデジタルに発行・検証するための基盤だ。 政府の技術機関であるGovTech（Government Technology Agency）が開発し、2018年の記事では、Ethereum上の記録を使って証明書の改ざんを確かめる方法を紹介している。 証明書の内容を丸ごと公開するという説明ではない。

開発当初の主体と、現在のサービス提供主体は分けて見る必要がある。 OpenCertsの利用規約では、情報通信メディア開発庁（IMDA）がサービスを提供すると明記されている。 証明書そのものを発行するのは、基盤を使う教育機関や資格認定機関などだ。 例えば、技能開発を推進する政府機関のSkillsFuture Singaporeは、職業技能資格であるWSQの証明書にOpenCertsを利用している。 政府が共通の基盤を提供し、それぞれの機関が自らの責任で証明書を発行する関係である。

この基盤も、同じ形式のまま止まっているわけではない。OpenCertsの公式告知によると、2025年10月1日付で従来のOpenAttestationは非推奨となり、OpenCertsはW3C VC形式を使うTrustVCへ移行した。従来形式で発行済みの証明書は引き続き検証でき、新規発行では新形式への移行を勧めている。

この例が示すのは、長期間使う証明には、発行時点の仕様だけでなく移行計画も必要だということだ。卒業証明書は、利用したライブラリより長生きするかもしれない。新方式に対応することと、過去に発行した証明を検証できることを、両方維持する必要がある。

進み具合は、用途と段階を組にして読む

取り組み確認できた段階そこからは断定できないこと
日本の属性証明の検討リスクや運用に関する報告書を公表全国の行政手続きが同じVC方式に統一されたこと
日本のチケット・企業間取引特定の用途で実証を実施すべての事業者で利用できること
EUのウォレット制度に基づき2026年末の提供へ整備すべての国とサービスで提供が完了したこと
カリフォルニア州のモバイル免許証利用場面を限定した試行物理免許証が全面的に不要になったこと
OpenCerts証明書基盤を新形式へ移行過去の証明書がすべて新形式へ変換されたこと

「世界で普及」という一つの評価では、この違いが消えてしまう。自社の企画に近い事例を探すなら、利用者、発行者、検証者が誰で、どの範囲まで実際に使えるのかを見るべきだ。

AppleやGoogleが採用するmdocとは何か？

mdocはmobile document、モバイル文書の略で、スマートフォンなどで保持し、相手に必要な情報を提示するためのデジタル証明の形式である。運転免許証を扱うISO/IEC 18013-5などの国際標準に基づく。モバイル運転免許証はmDL（mobile driving licence）と呼び、mdocを使う代表的な用途に当たる。

AppleとGoogleは、証明を使う入口を広げている

Appleの開発者向け説明では、Apple Walletの身分証がmdoc形式と関連するISO規格に基づくことを示している。Webサイトから証明を求め、利用者が提示先と要求された項目を確認して許可する流れも紹介している。

Google Walletの開発資料も、ISOのmdocに基づくデジタルIDと、オンラインで情報を提示するための対応を案内している。両社が作った独自の証明規格というより、国際標準をスマートフォンのウォレットやブラウザから使えるようにする取り組みである。

身分証の写真を撮って送る方法では、利用者は必要以上の情報を渡しがちで、受け取る事業者にも画像から内容や真正性を判断する作業が生じる。発行者の署名を検証できるデータを、必要な項目に絞って提示する方法は、この作業を変えようとしている。使える証明書、地域、対応サービスは製品や制度によって異なるため、利用したい場面での対応を確認する必要がある。

SSIやDID/VCと、どこが似ているのか？

本人が証明を保持し、サービスを越えて提示し、相手に渡す情報を選ぶ。この利用者の体験には、前編で紹介したSSIと共通する部分がある。mdocも、証明書を発行元のWebサイトでしか使えない状態から、外へ持ち出して検証してもらうための手段になる。

ただし、提示する情報を選べることと、発行者やウォレットの提供元から独立できることは別だ。運転免許を認めるのは発行する行政機関であり、どのアプリで保持できるか、どの端末へ移せるかは実装や運用条件にも左右される。mdocを採用しただけで、SSIの要求をすべて満たすとは言えない。

技術の上では、mdocとW3C VCのデータ形式は異なるが、複数の形式を共通の仕組みで扱うための仕様や実装もある。 例えば、OpenID4VPは、ウォレットから相手へ証明を提示するためのプロトコルで、W3C VC、ISOのmdoc、IETFのSD-JWT VCを扱える。 ここでいうSD-JWT VCはW3C VCと同じ形式ではなく、IETFで仕様が策定されているデジタル証明書の形式だ。 ウォレットなどを開発するためのライブラリMultipazも、mdocとSD-JWT VCの両方に対応している。

AppleやGoogleは、こうした証明をスマートフォンから使うための仕組みを整えている。 Appleの開発資料では、ウォレットなどのアプリがmdocをWebサイトへ提示するためのAPIを案内している。 GoogleのChrome向け説明でも、WebサイトとウォレットをつなぐDigital Credentials APIを使い、mdocやSD-JWT VCを提示する例が示されている。 両社の対応範囲は同一ではないが、証明書をスマートフォンのアプリやブラウザから利用するための接続が進んでいる。

この流れを見ると、私は、スマートフォンで広く使われるサービスを作るなら、mdocとVCの相互乗り入れを前提に考える必要が出てくるのではないかと思っている。 利用者にとっては、自分のスマートフォンに入っている証明を、必要な場面で使えることが大事だ。 受け入れる事業者にも、複数の形式に対応する必要が増していくだろう。

ここでいう相互乗り入れは、mdocをVCへ自動変換することではなく、共通の提示手順や、一つのウォレット・検証システムで複数の形式を扱うことを指す。 実際につなぐには、双方が対応する形式や署名方式、発行者を信頼する条件をそろえる必要がある。 「形式が違う」という説明に加えて、その違いを残したまま一緒に使う仕組みも整備されていると見ると、現在の動きを理解しやすい。

普及には、何がそろう必要があるのか？

証明を発行できても、使える場所が少なければ、利用者は従来の書類や手続きを併用することになる。発行者、利用者、受け入れる側がそれぞれ参加する理由と、困ったときに対応する運用が必要だ。

受け入れる側は、何を信用するのか？

研修会社が修了証を発行し、受講者が転職先へ提示できたとする。採用企業がその研修を評価するか、発行元の審査を十分だと認めるかは、データを受け取れたことだけでは決まらない。参加する発行者や認定基準、誤発行を訂正する責任まで合意する必要がある。

国内のチケット実証も、EUのウォレット整備も、単に証明書ファイルを作る話ではない。複数の組織がどの確認結果を受け入れるかを決める作業を含む。利用できる場面を増やすには、発行側と同じくらい検証する側の参加が必要になる。

紛失や機種変更でも、使い続けられるか？

利用者にとっては、証明がどの規格で作られたかより、スマートフォンを失ったときに取り戻せるか、転職や機種変更の後も使えるかが切実である。再発行時の本人確認、古い端末での利用停止、問い合わせ先などを用意しなければ、紙の証明書とは違う不便が増える。

発行サービスが終了した後にも証明を使う必要があるなら、何を保存し、誰が検証に必要な情報を維持するかも決めたい。卒業証明のように長く使うものと、短期間だけ有効な入場資格では、必要な運用が違う。

仕様の選択肢が多いことを、どう見るか？

現在は、証明の形式、発行や提示の手順、利用先ごとの条件を組み合わせて実装する。その選択肢と接続確認の負担は、普及を考える際の論点になる。OpenID Foundationの相互運用プロファイルも、仕様の機能を選び、発行者・ウォレット・検証者が接続する条件をそろえるための文書だ。

私は、この「何をどこまで合わせれば使えるのか」が見えにくいことも、導入をためらわせる一因ではないかと考えている。これは接続に必要な作業から考えた私の見方であり、普及への影響を計測した結果ではない。受け入れ先の少なさや導入費用、運用責任と併せて検討したい問題である。

よくある疑問

世界でDID/VCが使われ始めたなら、今すぐ全部置き換えるべき？

既存の電子署名、認証、API連携で目的を満たせる業務もある。複数の発行者と検証者をまたいで証明を再利用したいのか、利用者自身が証明を持つ必要があるのかを先に確かめたい。接続先がないまま発行機能だけ作っても、証明を使う場面は増えない。

ブロックチェーンを使えば、発行元が消えても大丈夫？

チェーンに記録が残ることと、検証に必要なデータがすべて残ることは別だ。証明本体、データ項目の定義、鍵の情報、受け入れルールなどが外部にある設計もある。どの情報を誰が保存するかを確認する必要がある。

日本のマイナンバーカードとVCは競合する？

本人を確認する仕組みを、証明を発行する際の根拠として使う設計もある。実際に、国内の実証では両方を組み合わせている。置き換えを前提にせず、本人確認と、その結果や属性を受け渡す処理を分けて考えるとよい。

まとめ

日本では属性証明の運用と実証、EUでは制度に基づくウォレット整備、米国ではモバイル免許証の利用、シンガポールでは証明書基盤の形式更新が進んでいる。AppleやGoogleのmdocへの対応も、利用者が証明を保持し、必要な場面で提示するための取り組みとして位置付けられる。

事業として考えるなら、誰が発行し、誰が受け入れ、利用者がどの手続きを省けるのかを先に確かめたい。その条件に合わせて仕様を選ぶために、後編（準備中）ではDIDメソッド、W3C VC、SD-JWT VC、mdoc、OpenIDの発行・提示手順を具体的に比較する。

参考ソース