運転免許証やパスポートなど、本人確認に欠かせない重要な個人情報が、大規模なサイバー攻撃の標的になっています。
2026年、日本ではタイムズカーへの不正アクセスによって約663万件の会員情報が漏えいし、暗号化された運転免許証などの画像約146万件にも外部送信の痕跡が見つかりました。米国でも、テキサス州公園野生生物局の委託先への不正アクセスにより、300万人以上の運転免許証情報やパスポート番号が取得された可能性があると公表されています。
こうした事件は、情報を安全に守るだけでなく、そもそも企業が個人情報をどこまで収集し、保管する必要があるのかという問題を浮き彫りにしています。
従来の個人情報管理のあり方を見直す選択肢として注目されているのが、DID（分散型識別子）とVC（検証可能なデジタル証明書）です。
1. 本人確認書類の流出と保管
国内外の流出事例
2026年秋、カーシェアリングのタイムズカーは、約663万件の会員情報に外部送信の痕跡があったと公表しました。攻撃者がアクセスした暗号化済みの本人確認書類の画像約236万件のうち、約146万件に外部送信の痕跡が見つかっています（第5報）。同じ10月には、焼肉きんぐ公式アプリで約1,079万件の会員情報（会員番号、氏名、メールアドレス、電話番号）の漏えいが公表されました（物語コーポレーション）。
海外でも、本人確認書類の流出は珍しくありません。米国テキサス州では2026年6月、公園野生生物局（TPWD）の狩猟・釣りライセンスを運営する委託先が不正アクセスを受け、約309万人分の運転免許証情報やパスポート番号が取得された可能性があると公表されました（BleepingComputer）。オーストラリアのLatitude Financialは2023年3月、運転免許証番号約790万件とパスポート番号約5万3,000件が盗まれたと公表しました。Discordは2025年10月、外部のカスタマーサポート事業者経由で、年齢確認の審査用に預かっていた身分証画像約7万人分が流出した可能性があると公表しています。委託先に渡した書類も、流出元になります。
東京商工リサーチによると、上場企業とその子会社が公表した100万件以上の漏えいは、2026年10月5日時点で10件に達し、前年1年間の6件を超えました。2012〜2025年に漏えい・紛失した可能性のある個人情報は、延べ2億1,313万人分だそうです。
書類画像の重複保管
本人確認書類は、なりすましを防ぐために提出します。その画像が流出すれば、今度はなりすましの材料になります。金融庁も2026年10月9日、本人確認書類の画像を含む漏えいを受けて、金融機関になりすまし対策の強化を求めました。
同じ利用者が銀行、証券会社、暗号資産取引所の3社に登録し、3社とも免許証の画像を保管していれば、守るべき画像は3か所にあります。各社の対策や保管期間で漏えいのリスクは変わりますが、複製の数だけ守る場所が増えます。
口座開設で各社が確かめたいのは、申告された氏名や住所が本人のものかどうかで、画像そのものが欲しいわけではありません。タイムズカーは10月16日、免許証画像を退会後7年間保有する運用をやめ、登録確認が済んだら即時削除する方針に切り替えました。保有中の画像も10月末までに削除するとしています。
取引所間でのKYC結果の再利用
確認後に画像を消せるなら、そもそも各社が画像を受け取らずに済む方法も考えられます。
信頼できる本人確認機関が確認を行い、確認した属性、確認方法、確認日時をVCとして発行します。利用者がそのVCを取引所Aに提示すると、Aは発行者の信頼性、署名、失効状態、提示者との結び付きを検証します。取引所Bも同じ方式を受け入れれば、利用者は書類を一から出し直さずに済みます。
取引所は、氏名や住所などの必要な属性は引き続き受け取ります。KYCには本人確認以外の顧客審査や、取引開始後のモニタリングもあり、各社の記録保存義務やリスク判断も残ります。変わるのは、本人確認を実施する会社と、その結果を利用する会社を分けられる点です。他社の確認結果をどこまで自社の確認の代わりに使えるかは、制度と業務の両方で決めることになります。
2. DID・VCの仕組み
VC：発行者・保有者・検証者
VC（Verifiable Credential）は、人や組織の属性や資格を、第三者が検証できる形式で表したデジタル証明書です。
大学が卒業証明書をVCで発行する場合、大学がIssuer（発行者）、卒業生がHolder（保有者）、採用企業がVerifier（検証者）になります。卒業生は証明書をウォレット（証明書と鍵を管理するアプリ。暗号資産用とは限らない）に保管し、採用企業に提示します。採用企業は電子署名を検証して改ざんがないことを確かめ、署名した鍵が本当にその大学のものかを確認します。
大学は提出先ごとに証明書を送る必要がなく、卒業生が自分で必要な相手に提示します。ただし、提示した人と証明書に書かれた人が同じかどうかは、本人確認に使う場合は別に確認します。
DID：識別子から公開鍵を引く
DID（Decentralized Identifier）は、個人や組織を識別し、対応する公開鍵などを参照するための識別子です。did:web:example.comのような形式で、DIDからDID Documentを取得して、署名の検証に使う公開鍵を確認します。何に依存して識別子を管理するかはDID Method（方式）ごとに異なり、did:webならドメインとHTTPSに依存します。
DID Documentから分かるのは署名の検証に使う公開鍵までで、相手が対応する秘密鍵を使えるかはチャレンジへの署名などで別に確かめます。本名や資格は分かりません。医師であることを示すには、資格を確認できる発行者のVCが要ります。逆に、VCの発行者の検証にX.509証明書を使う構成もあり、VCにDIDは必須ではありません。
本人確認書類を電子化するだけなら、従来の電子証明書や中央の認証基盤でもできます。VCの特徴は、発行者が署名した証明を保有者が持ち歩き、発行者を介さずに複数の検証者へ提示できることです。DIDは、そのとき公開鍵を参照する手段の一つです。
3. 実装で組み合わせる技術
DID・VCは一つの製品やプロトコルではなく、証明書のデータ形式、発行・提示の通信手順、署名方式、発行者の信頼性確認、失効管理を組み合わせて作ります。W3C VC Data ModelとSD-JWT VCのように、データ形式の選択肢も複数あります。
発行と提示：OpenID4VCI・OpenID4VP
銀行が本人確認を終えた顧客にVCを発行するときの代表的なプロトコルが、OpenID4VCI（OpenID for Verifiable Credential Issuance）です。OAuth 2.0を土台にしているので、既存の認証・認可システムとつなぎやすい。銀行がCredential Offerで発行を案内し、ウォレットは認可処理を経て証明書を受け取ります。このとき、VCをウォレットの鍵に結び付けることもできます。
その顧客が証券会社にVCを提示するときに使うのが、OpenID4VP（OpenID for Verifiable Presentations）です。証券会社はDCQL（Digital Credentials Query Language）で必要な証明書や属性を指定し、ウォレットは利用者の承認を得て提示します。リプレイ攻撃（過去の提示データを別の取引で使い回す攻撃）を防ぐには、ウォレットがVCに結び付いた鍵で、検証者の識別情報と要求ごとのnonce（使い捨ての値）を含めた証明を作り、検証者がそれを要求時の値と照合します。鍵を結び付けない提示では、この防御は成り立ちません。
一般的なフェデレーション型認証では、ログインのたびにIDプロバイダーと通信します。VCでは検証者が署名付きの証明を直接検証できるので、発行者は利用者がどこで証明を使ったかを把握しにくくなります。ただし、失効確認のたびに発行者へ照会する構成にすると、利用状況が発行者に集まります。
選択的開示と追跡
氏名、住所、生年月日が入った証明書をそのまま提示すれば、署名が正しくても全項目が相手に渡ります。必要な項目だけを渡す仕組みが選択的開示（Selective Disclosure）で、代表的な方式がSD-JWTです。
SD-JWTでは、属性ごとにsalt（ランダムな値）、属性名、値をまとめたDisclosureを作り、そのハッシュを発行者が署名するJWTに含めます。利用者は署名付きJWTと、開示したい属性のDisclosureだけを渡します。検証者は署名を検証し、Disclosureから再計算したハッシュを照合します。
生年月日を隠しただけでは「18歳以上」は証明できません。発行者が「18歳以上」という属性をあらかじめ証明書に含めておくか、値を見せずに条件を満たすことを示す暗号学的な証明を使います。
同じSD-JWTを複数のサービスに提示すると、署名やハッシュが共通なので、検証者同士が突き合わせれば同じ人の利用だと分かります。対策の一つは、同じ属性のVCを、saltや結び付ける鍵を変えて複数枚まとめて発行し、提示先ごとに使い分ける方法です。OpenID4VCIはこのまとめての発行に対応しており、欧州のEUDI Walletの技術仕様（ARF）も、この方法で追跡に対処しようとしています。BBS署名なら、1枚のVCから提示のたびに、元の署名との対応を照合できない証明を作れます。ただしW3CのBBS Cryptosuitesは、2026年11月時点で勧告候補の草案です。
どの方式でも、毎回同じ氏名やウォレットアドレスを開示すれば、そこから同一人物だと分かります。暗号方式の選択と同じくらい、どの項目を渡すか、識別子を使い回すか、受け取った相手が何を保存するかが効いてきます。
失効管理
資格を停止された人のVCも、署名は暗号学的に正しいままです。今も有効かを確かめる仕組みが失効管理です。
W3CのBitstring Status Listは、多数の証明書の状態を1本のビット列で配布します。検証者はリスト全体を取得して該当位置を調べるので、どの証明書が使われたかを発行者に知られにくい。SD-JWT VCの仕様案は、状態確認の方法としてIETFのToken Status List（2026年11月時点でInternet-Draft）を参照しています。
失効情報をどのくらいの頻度で確認するかは、取り消された証明を誤って受け入れたときの影響で決めます。金融商品の取引資格なら、短い有効期限や取引直前の状態確認を組み合わせます。
トラストフレームワーク
署名も失効状態も問題がなくても、その発行者に資格を証明する権限があるかは別に確かめる必要があります。医師資格を確認できない会社が「この人は医師です」と署名しても、受け入れる根拠にはなりません。
発行者の登録や認定、証明する属性の定義、事故時の責任分担を定めるのがトラストフレームワークで、Trust Registryはその判断に必要な発行者情報を参照する仕組みです。誰の証明を受け入れるかは、署名検証ではなく業務と制度の側で決まります。
4. ブロックチェーンの使いどころ
チェーンに載せるもの・載せないもの
ここまでの仕組みの大部分は、ブロックチェーンなしで動きます。VCは電子署名で検証できるので証明書をチェーンに保存する必要はなく、DIDもdid:webのように既存のWeb基盤で公開できます。
ブロックチェーンが役に立つのは、公開鍵の登録・更新情報や発行者の登録情報を、複数の組織が同じ台帳で共有したい場合です。参加者全員が同じ記録と更新履歴を参照できます。台帳が改ざんされにくくても、登録された組織が信頼できるかは別なので、誰を認定し誰が取り消すかのルールは台帳の外で決めます。
個人情報そのものをパブリックチェーンに載せると、後から消せず、公開情報から利用者を追跡される恐れがあります。ハッシュ化しても、生年月日のように候補が限られる値は総当たりで元の値を推測でき、同じハッシュを繰り返し使えば利用履歴を結び付ける材料になります。
4つの構成
技術選定の目安として、ここでは4つの構成に分けます。標準で決まった分類ではなく、実際には組み合わせることもあります。
① Web/PKI型
HTTPS、X.509証明書、did:webなど、既存のWebと公開鍵基盤を使います。発行者と検証者がはっきりしていて、既存の証明書管理の体制を使える場合に向きます。ブロックチェーンの運用は不要です。
② コンソーシアムDLT型
複数の金融機関が、参加者を限定したPermissioned DLTを共同運営し、DID RegistryやTrust Registryを共有します。本人確認の詳細は各社の業務システムに置き、共通の登録情報だけを台帳で管理します。参加者の追加、更新権限、障害対応の運営ルールが要ります。
③ パブリックチェーン型
発行者の登録情報や検証に必要な情報を、誰でも参照できるチェーンに置き、スマートコントラクトから資格や属性を確認します。ゼロ知識証明（ZK）を組み合わせる構成もあります。プライバシー、ガス代、証明の生成・検証コストを見て選びます。
④ ハイブリッド型
本人確認とVCの検証はオフチェーンで行い、その結果に基づく許可情報だけをオンチェーンに反映します。証券会社がVCを検証して取引を認めるウォレットアドレスを登録し、コントラクトはその登録を見てトークンの移転を許可します。本人確認書類をチェーンに載せずに取引を制限できる一方、VCの失効からオンチェーンの許可取消しまでに時間差が出ます（6章で扱います）。
5. 国内金融機関の実証
811のテストケースと犯収法上の整理
金融庁は2026年3月13日、三菱UFJ信託銀行が申し込んだFinTech実証実験ハブの結果を公表しました。実験期間は2024年12月から2025年3月です。銀行の顧客管理結果を記録したVCと、eKYC事業者がマイナンバーカードで確認した基本4情報を記録したVCを、利用者がウォレットで受け取り、別の金融機関に提示する構成を検証しています。
3種類の発行基盤、2種類の検証基盤、3種類のウォレットを組み合わせ、相互運用性、本人確認・セキュリティ、ユーザー体験について811のテストケースを定義して検証しています。複数ベンダーの実装を組み合わせても、標準に沿って発行から提示まで動くことが確認されています。
一方、当初の構成は、犯罪収益移転防止法（犯収法）が定める本人確認方法の要件を満たさないと判断されました。当初はマイナンバーカードのICチップを使う方法として検討していましたが、VCを提示するたびにICチップを読み取るわけではないため、提示の時点で本人が実在することを担保できない、という理由です。ウォレットが正しいVCを提示できても、法令が求める方法で本人を確認したことにはなりません。
最終的には、電子署名法の認定を受けたeKYC事業者が、公的個人認証で利用者を確認したうえで認定業務としてX.509証明書を発行し、それをVC形式で受け渡す構成について、犯収法上の本人確認方法として認められると整理されました。適切なリスク評価を行うことが前提です。この場合の検証は、VCのStatus ListやTrusted Listではなく、X.509証明書の通常の検証手続に従います。VCは運ぶ形式として使い、本人確認方法としての根拠は既存の電子署名法の枠組みに置いた形です。
受け入れ側の条件
A銀行が「確認済み」と証明しても、B銀行が求める確認水準と同じとは限りません。どの書類を使い、いつ確認し、どんな条件で失効させるかが分からなければ、B銀行は受け入れを判断できません。
実用化には、発行者の認定、確認方法の水準、ウォレットの安全性、失効条件、事故時の責任分担の取り決めが要ります。金融庁の公表資料でも、発行者の適格性の認定基準や信頼リストの運営ガバナンスは、この実証の対象外とされています。
6. オンチェーン金融での取引制御
暗号資産の送金は、秘密鍵で署名してネットワークのルールを満たせば実行できます。トークン化した証券や預金では、鍵を持っているだけでは足りない場合があります。一定の投資家しか保有できないトークン化証券なら、送金先アドレスの保有者に購入資格があるか、居住地、投資家区分、本人確認の状況、取引制限を確かめる必要があります。
VC検証からアドレス登録まで
銀行や証券会社が本人確認と投資家資格の確認を行い、結果をVCとして発行し、投資家はウォレットに保管します。投資家がトークン化証券の購入を申し込むと、証券会社や検証サービスがVCの提示を求め、署名、失効状態、発行者の信頼性を確認したうえで、その商品を買えるかを業務ルールに照らして判定します。
許可する場合は、VCの提示者が受取先のウォレットアドレスを管理していることも確かめてから、取引制御に必要な情報をチェーンに反映します。VCを提示する鍵と資産を動かす鍵が同じとは限らないためです。スマートコントラクトはその登録情報を見て移転の可否を判断し、本人確認書類やVCの中身はチェーンに書き込みません。
ERC-3643との接続
規制対応を想定したトークン規格の一つにERC-3643があります。Identity RegistryのisVerified()は、受取人に必要なClaim（属性についての証明）が信頼された発行者によって有効に付与されているかを確認し、ComplianceのcanTransfer()は、設定された移転ルールに合うかを確認します。
ERC-3643には、W3CのVCを検証する標準手順は定められていません。この記事の構成では、VCをオフチェーンで検証し、その結果をIdentityの登録やClaimに反映します。どのVCを受け入れ、どのClaimを要求し、資格が変わったらどの情報を更新するかは、実装する側が決めます。
個人情報をチェーンに載せなくても、氏名とウォレットアドレスの対応が外に漏れれば、取引履歴を追跡されます。対応表を持つデータベースやログも、アクセス範囲と保存期間を決めて管理します。
失効と取引許可の時間差
投資家の資格が失効しても、オンチェーンのClaimや許可情報が更新されなければ、資格確認を通過してしまう可能性があります。確認元で資格が取り消されたことを、チェーンは自分では知りません。また、ERC-3643の通常の移転でisVerified()が確認するのは受取人です。資格を失った保有者からの送信も止めるなら、アドレスの凍結や、送信者を確認するComplianceのルールが別に要ります。
そのため、失効の通知を受け取る処理、チェーンへの更新、失敗時の再試行、反映済みかの確認まで作り込む必要があります。更新トランザクションを送った時点ではなく、必要な確定性を得て反映された時点で取消し完了とみなします。業務側が取消しの反映期限と、期限までに更新できなかったときの取引停止条件を先に決め、実装側はそれに合わせて再試行や監視、許可情報の有効期限を設定します。
相互運用性
A銀行のネットワークからB銀行のネットワークへトークン化証券を移せても、B銀行が受取人の資格を確認できなければ、取引は受け入れられません。A銀行が確認した資格をB銀行が一定の条件で検証して受け入れられれば、移転先でも必要な取引制御をかけられます。オンチェーン金融の相互運用性には、資産を動かせることに加えて、取引に必要な属性や資格を相手先が検証できることも含まれます。
VC自体が資産を別のチェーンに運ぶわけではなく、共通の証明書を使っても、銀行ごとのリスク判断と法令上の責任は残ります。証明を発行・検証する基盤は共通にし、どの証明をどの取引で受け入れるかは各行が設定する、という分け方になります。