1. 序論

銀行口座開設プロセスは、本人確認（KYC: Know Your Customer）規制の厳格さから、依然として煩雑であり、ユーザーの利便性とプライバシー保護のトレードオフが課題となっている。従来のシステムでは、銀行は顧客の多量の個人情報を一元的に管理せざるを得ず、これはデータ侵害のリスクや、ユーザーのデータ主権の喪失につながる可能性がある。

本稿では、信頼のプロトコル「AMATELUS」の主要な構成要素であるDecentralized Identifiers (DIDs)、Verifiable Credentials (VCs)、そして**Zero-Knowledge Proofs (ZKPs)**を金融分野に応用する。これにより、銀行が顧客の個人情報を適切に保持しつつ、法規制要件を満たし、同時にユーザーのプライバシーを最大化する未来の口座開設フローを設計する。

2. AMATELUSアーキテクチャの主要概念と本稿への適用

2.1. 分散型識別子 (DID) と検証可能なクレデンシャル (VC)

AMATELUSは、ユーザーが自身のデジタルアイデンティティを完全に管理する**Self-Sovereign Identity (SSI)**の原則に基づいている。核となるのは、ImmutableなDIDであり、ユーザーは自身のDIDsを生成・管理し、特定のサービスに紐付けられた複数のDIDsを持つことで、クロスサービスでの追跡を防ぎプライバシーを保護する。

個人に関する変更可能な属性情報（例：氏名、住所、年齢、運転免許など）は、信頼できる発行者によって署名されたVCとして表現される。AMATELUSでは、VC発行チェーンが信頼の連鎖を構築し、政府機関から発行されたVCが、より下位のサービス固有のVCの信頼性を保証する。また、キーのローテーションに伴うDIDの変更時には、VCの再発行モデルが採用される。この際、旧DIDと新DIDの連続性を証明するVC（Continuity Proof VC）が発行される。

2.2. ゼロ知識証明 (ZKP)

ZKPは、特定の情報が真実であることを、その情報自体を開示することなく証明する暗号技術である。本稿では、ZKPをユーザーの特定の同意（例：個人情報開示への同意、規約同意）を証明するために活用する。AMATELUSは、Precomputed proofsやPost-Quantum Cryptography (PQC)対応の回路をサポートすることで、実用的な効率性と将来的なセキュリティを確保する。

3. 金融庁をトラストアンカーとする銀行DIDの信頼性

AMATELUSのVC発行チェーンの概念に則り、銀行のDIDのトラストアンカーとして、その監督官庁である金融庁が最も適切であると考えられる。

3.1. トラストアンカーの確立

銀行は、金融庁から銀行業務を行う認可を受けている。この認可プロセスをデジタルアイデンティティの世界にマッピングすることで、金融庁は、正規の銀行のDIDに対してVCを発行する。この 「金融庁発行の銀行認可VC」 は、当該銀行のDIDが、公的に認可・監督された正当な金融機関のものであることを証明する最上位の信頼の証となる。

これにより、ユーザーは、口座開設を希望する銀行のDIDが、金融庁によって公的に保証されていることを確認でき、安心して取引を開始できる。これは、既存の金融システムにおける信頼モデル（政府による認可・監督）を、SSIモデルへとシームレスに移行させるものである。

4. 未来のオンライン銀行口座開設フロー

以下に、AMATELUSのアーキテクチャと金融庁をトラストアンカーとする設計に基づいた、理想的なオンライン銀行口座開設フローを提案する。本稿は、法規制や政治的ハードルはセキュリティとコストの問題が解消され国民の生活心理に合致していれば時間の問題で解決するとみなし、議論を進める。

4.1. 前提条件

本フローを開始する市民は、自身のウォレット内に以下のVCを保有しているものとする。

• 住民票VC: 自治体から発行された、氏名、住所、生年月日などの基本的な個人情報を含むVC。
• 規約同意に関する準備: 口座開設時の規約同意に関するZKP生成の準備が整っていること。

また、ユーザーのウォレットには、金融庁の公開DIDがトラストアンカーとして登録されているものとする。

4.2. 口座開設フローの詳細

1. 銀行選択とZKP回路コードの取得

   • ユーザーは、口座開設を希望する銀行のウェブサイトを訪問する。
   • ユーザーのAIエージェントは、銀行が指定する種類のZKP回路コードを、金融庁が運営するDID公開サイトから取得する。これにより、回路コード自体の信頼性と安全性が保証される。

2. ZKPの生成と個人情報の提供への同意

   • AIエージェントは、バックグラウンドでZKP回路のビルドを開始する。
   • 同時に、以下のZKPを生成する。
     • 住民票VC開示同意ZKP: ユーザーが住民票VCから生成するZKPである。このZKPは、銀行が口座開設に必要な氏名、住所、生年月日などの法定要件を満たす情報を、住民票VCから取得し、保管することに同意する旨を証明する。
     • 規約同意ZKP: 口座開設規約に同意する意思があることを示すZKPである。
   • AIエージェントは、ユーザーのデバイス上でこれらのZKPを生成する。このプロセスは、ユーザーが意識することなくバックグラウンドで数時間かけて完了する。

3. ZKPおよび監査用DIDの送信

   • ZKPの生成が完了すると、AIエージェントは生成された複数のZKPと、将来的な監査に利用される監査用DIDを、**HTTPS (TLS 1.3)**を介して銀行に送信する。TLS 1.3は、通信の機密性、完全性、認証を保証し、リプレイ攻撃に対する耐性を提供する。

4. 銀行側での検証と口座開設

   • 銀行システムは、受信したZKP（住民票VC開示同意ZKP、規約同意ZKP）を検証する。
   • 住民票VC開示同意ZKPの検証が成功すると、銀行はユーザーから提供された住民票VCから、口座開設に必要な個人情報（氏名、住所、生年月日など）を直接取得し、保管する。これにより、銀行は厳格なKYC/AML要件を満たすことができる。
   • 銀行は取得した個人情報を用いて、自社のシステムで既存口座の有無を確認する。
   • 反社会的勢力ではないことの確認については、銀行はユーザーの住民票VCのID（またはそのZKPによって得られる匿名識別子）を用いて、金融庁と自治体が連携して管理する反社データベースに定期的に照会を行う。金融庁は、銀行からのZKPによる問い合わせに対し、個人情報を開示することなく「非該当である」というZKPを返信し、銀行はこれを検証する。
   • 全ての検証が成功し、必要な個人情報が適切に取得・確認されれば、銀行は印鑑登録や通帳発行の手続きなしに、内部的に口座を開設する。

5. 口座情報VCの返送とAIエージェントによる管理

   • 口座開設が完了すると、銀行はユーザーの新しいDIDに対して、開設された口座の情報を記載した口座情報VCをHTTPSでユーザーのAIエージェントに返送する。
   • AIエージェントは口座情報VCを受領し、ウォレット内に安全に保管する。ユーザーは口座開設完了通知を受け取る。

4.3. DIDローテーションへの対応

AMATELUSにおけるDIDローテーションは、セキュリティとプライバシーの強化に不可欠である。

• ユーザーが自身のDIDをローテーションした場合、自治体は、ユーザーの旧DIDと新DIDが同一人物のものであることを証明する連続性VCを発行する。
• 同時に、自治体は新しいDIDに対して、最新の住民票VCを再発行する。
• ユーザーのAIエージェントは、これらの新しいVC（連続性VCと新しい住民票VC）をバックグラウンドで銀行に更新申請する。銀行は連続性VCを検証し、口座情報と新しいDIDの紐付けを安全に更新する。これにより、DIDが変更されても、ユーザーは継続して既存の銀行口座を利用できる。

5. 結論

本稿で提案するAMATELUSを用いた未来のオンライン銀行口座開設フローは、金融庁を銀行DIDのトラストアンカーとすることで、法規制要件（特にKYC/AML）の遵守と、SSIおよびZKPが提供する高い利便性・プライバシー保護を両立させる。ZKPを用いた同意の証明、AIエージェントによる自動化されたバックグラウンド処理、そしてDIDローテーションへのシームレスな対応は、市民が自身のデジタルアイデンティティを主権的に管理しつつ、安全かつ効率的に金融サービスを享受できる未来を実現する。

このアプローチは、セキュリティ、コスト、そして国民の生活心理に合致するならば、現在の法規制や社会的なハードルも時間の経過とともに解決され、分散型で市民中心のデジタルガバナンスへの移行を加速させるものであろう。