AMATELUS基盤のスマートシティにおける自治体窓口での本人認証と大容量の住民票・戸籍謄本VC発行方法

1. 序論

AMATELUSは、分散型識別子（DID）とゼロ知識証明（ZKP）を核に、市民中心のデジタル体験と、政府や自治体の効率的かつ透明なサービス提供の両立を目指す。しかし、その実装には市民のデジタルリテラシー、既存の行政運用、および現行技術の制約（例: QRコードのデータ容量、オンライン送信の困難さ）を乗り越える具体的な運用フローの確立が不可欠である。

本稿では、AMATELUSの最初の信頼構築フェーズ、すなわち市民が自治体窓口で自身のDIDの所有権を証明し、公的なVC（例: 住民票VC、戸籍VC）を取得するプロセスに焦点を当てる。特に、以下の課題を解決する実用的な運用モデルを提案する。

• AMATELUS特有のDID設計（DIDドキュメント全体のハッシュがDIDとなる）に基づく、秘密鍵の効率的かつ確実な所有権証明
• 大容量のVCが単一のQRコードに収まらない場合の安全なデータ転送
• 自治体窓口の既存インフラ（QRコードリーダー、小型ディスプレイ）を活用した、導入障壁の低い運用フロー

2. AMATELUS DIDと公開鍵認証の設計

AMATELUSのDID設計は、DIDドキュメントの不変性を特徴とする。DIDドキュメント自体の耐量子計算機（PQC）ハッシュ値がDIDのmethod-specific-idとなる（例: did:amatelus:<DIDドキュメントのPQCハッシュ値>）。このDIDドキュメントは、そのDIDを制御する署名用の公開鍵を一つだけ持ち、その他は最小限の不変情報のみを保持する。

この設計に基づき、市民が自身のDIDの所有権を自治体に証明する際には、QRコードを介して以下の情報を提示する。

• バージョン番号 (v): AMATELUS DIDドキュメントの静的なテンプレート構造を一意に指定する整数。このバージョン番号により、検証者は公開鍵のタイプ（例: Ed25519）を含むDIDドキュメントの残りの部分を正確に再構築できる。
• 公開鍵 (pubKey): DIDを制御する秘密鍵に対応する公開鍵データ（Base58またはBase64エンコード）。

2.1. QRコードデータ構造

市民が提示するQRコードのデータは、可読性を高めるために内部的には連想配列形式で管理し、QRコードにエンコードする際にはデータ量を最適化するために配列形式に変換する。

内部管理形式（JSON）:

{
  "v": 1,
  "pubKey": "<Base58またはBase64エンコードされた公開鍵>"
}

QRコードエンコード形式（配列）: [1, "<Base58またはBase64エンコードされた公開鍵>"]

この設計により、QRコードのデータ量は極めて小さく（約50文字程度）、一般的なQRコードリーダーで容易に読み取り可能となる。

2.2. 秘密鍵所有権確認フロー

この節では、市民が自治体窓口で自身のAMATELUS DIDの所有権を証明する具体的なフローを記述する。このフローは、既存の行政インフラ（QRコードリーダー、小型ディスプレイ）と、公的身分証明書（マイナンバーカード、運転免許証など）による目視確認を組み合わせることで、強固な信頼の起点を構築する。

前提:

• 市民はAMATELUSウォレットアプリをインストールしたスマートフォンを所持している。
• 自治体窓口には、QRコードリーダーと、Nonce表示用の小型ディスプレイが設置されている。

フロー詳細:

1. 市民による最初のQRコード提示 (ウォレットアプリ)

   • 市民はウォレットアプリを開き、「本人確認（DID所有権証明）」機能を選択する。
   • アプリは、市民のDIDに紐づく**[バージョン番号, 公開鍵]配列をエンコードしたQRコード**をスマホ画面に表示する。
   • 市民はこのQRコードを窓口担当者へ提示する。

2. 自治体側によるQRコードスキャンとNonce表示 (窓口端末)

   • 自治体窓口担当者は、設置されたQRコードリーダーで市民のスマホ画面に表示されたQRコードをスキャンする。
   • 窓口システムは、スキャンした[バージョン番号, 公開鍵]データを受領し、以下の処理を行う。
     • バージョン番号に基づき、AMATELUS DIDドキュメントの静的テンプレートを取得。
     • 取得した公開鍵をテンプレートに挿入し、AMATELUSのDIDドキュメントを再構築。
     • 再構築されたDIDドキュメントのPQCハッシュを計算し、市民が使用しているAMATELUS DID文字列（例: did:amatelus:<PQCハッシュ値>）を確定する。
     • このセッション専用の一意なチャレンジ文字列（Nonce） を生成する。
     • 生成したNonceを、窓口の小型ディスプレイにQRコードとして表示する。これにより、市民は手入力なしでNonceを取得できる。

3. 市民によるNonce読み取りと署名生成 (ウォレットアプリ)

   • 市民は、自身のウォレットアプリで、自治体の小型ディスプレイに表示されたNonceのQRコードを読み取る。
   • ウォレットアプリは、読み取ったNonceと、自身の秘密鍵を用いてNonceへのデジタル署名を生成する。この署名は、所有権証明の核心となる。
   • ウォレットアプリは、生成された署名データを、新しい2つ目のQRコードとしてスマホ画面に表示する。

4. 自治体側による署名QRコードスキャンと検証 (窓口端末)

   • 窓口担当者は、市民のスマホ画面に表示された2つ目のQRコードを再度スキャンする。
   • 窓口システムは、スキャンした署名データと、ステップ2で抽出した公開鍵（または再構築したDID）を用いて、署名の正当性を検証する。
     • 検証成功: 提示された公開鍵の秘密鍵所有者と、現在スマホを操作している市民が同一人物であることが暗号学的に証明される。

5. 公的身分証による目視確認と住民票VC発行

   • 窓口担当者は、市民のマイナンバーカードや運転免許証などの公的身分証を目視で確認する。
   • ステップ4で完了したDIDの暗号学的所有権確認と、この目視による本人確認を突き合わせ、「提示されたDIDの所有者」と「目の前の人物」が同一であることを確認する。
   • 確認が完了後、自治体は市民のウォレットに対し、デジタル署名された 「住民票VC」 を発行する。

補足: 住民票VCの最初の発行時には、ZKPは直接関与しない。ZKPは、発行された住民票VCを利用して、他のサービス（例: 銀行、年齢認証）に対してプライバシーを保護しつつ特定の属性（例: 氏名を開示せずに20歳以上であること）を証明する際に用いられる。

3. 大容量VCの安全な発行フロー

世帯住民票VCや戸籍VCなど、データ量が大きく単一のQRコードに収まらないVCの発行には、以下の分割・検証フローを適用する。これにより、自治体窓口でのオンライン送信の困難さを回避しつつ、データの完全性と信頼性を確保する。

3.1. VC分割の原則

• VC全体のハッシュによる完全性保証: VC全体を特定のハッシュ関数（例: SHA3-512）でハッシュ化し、このハッシュ値をVCの分割・転送における「真正性の証明」として用いる。
• JSONのセグメント化: 大容量VCのJSONデータを、読み取りやすいQRコード容量（例: 数百バイト程度）に余裕を持って収まるように複数に分割する。
• インデックス情報の付与: 各分割されたVCパーツには、そのVCがどのVCの何番目のパーツであるかを示すインデックス情報を付与する。
• 順不同読み取りの許容: インデックス情報があるため、市民は分割されたQRコードを順不同で読み取ることが可能。

3.2. 大容量VC発行フロー詳細

1. 自治体側によるVC全体ハッシュと分割数情報QRコードの表示 (窓口端末)

   • 住民票VCが生成されると、自治体窓口システムはVC全体のハッシュを計算し、VCの分割数を決定する。
   • 窓口の小型ディスプレイに、VC全体のハッシュ値と分割数情報をエンコードした最初のQRコードを表示する。

2. 市民による最初のQRコード読み取り (ウォレットアプリ)

   • 市民はウォレットアプリで、小型ディスプレイに表示された最初のQRコードを読み取る。
   • アプリはVC全体のハッシュ値と分割数を認識し、VCの受け取り準備を開始する。

3. 自治体側によるVCパーツQRコードの順次表示 (窓口端末)

   • 窓口システムは、VCの各分割パーツを、それぞれインデックス情報（例: [VC_Part_Index, VC_Part_Data]）と共にQRコードにエンコードし、小型ディスプレイに順次表示する。
   • 担当者の操作や、一定時間ごとの自動切り替えなどで次のQRコードが表示される。

4. 市民によるVCパーツQRコードの順不同読み取りと再構築 (ウォレットアプリ)

   • 市民はウォレットアプリで、表示されるVCパーツのQRコードを順不同で連続して読み取っていく。
   • アプリは読み取った各パーツをメモリ上に収集し、インデックス情報を用いてVCの再構築を進める。
   • アプリのUIは、読み取り済みのパーツ数や、残りのパーツ数などを表示し、市民を支援する。

5. 市民ウォレットによるVC完全性検証

   • 全てのVCパーツが読み取られ、VCが完全に再構築されると、ウォレットアプリは再構築されたVC全体のハッシュを計算する。
   • この計算結果が、ステップ2で最初に読み取ったVC全体のハッシュ値と一致するかを検証する。
   • 検証成功: VCが完全に、かつ改ざんされずに受け取られたことが証明される。ウォレットはVCを安全に保存する。

利点:

• オフライン転送: 大容量VCをオンラインで送信できない環境でも、物理的なQRコードを介して安全にデータ転送が可能。
• 堅牢性: 個々のQRコードが破損しても、残りのコードで再構築・検証が可能であり、全体ハッシュにより不正なパーツの混入を防ぐ。
• UXの許容性: 複数回のスキャンは必要だが、UI支援と順不同読み取りにより、市民の負担を最小限に抑える。一度VCを取得すれば、その後のスマートシティ体験は飛躍的に向上するため、この一度の手間は許容されやすい。

4. 既存技術との連携と将来展望

提案されたフローは、既存の自治体運用インフラ（QRコードリーダー、小型ディスプレイ）を最大限に活用し、導入障壁を低く抑えることを目指している。

• PQCハッシュの採用: DIDの生成段階からPQCハッシュを模倣して組み込むことで、将来的な量子コンピュータ脅威への耐性を担保する。
• ZKPの活用: 最初の住民票VC発行後、市民はウォレットに格納されたVCからZKPを生成し、個人情報を明かすことなく様々な行政・民間サービス（例: 年齢認証、資格証明、補助金申請）を利用できるようになる。このZKP生成時には、サービス提供者からのNonceを組み込むことでリプレイ攻撃を防ぐ。
• AIエージェントの役割: 将来的には、市民側のAIエージェントが、本稿で述べたQRコードの読み取り、Nonceへの署名、VCの再構築といった複雑な操作を自動化し、市民の負担をさらに軽減することが期待される。

5. 結論

本論文で提案するAMATELUSプロトコルにおける本人認証と大容量VC発行フローは、自治体窓口の現実的な運用状況と、AMATELUSのDID設計およびセキュリティ要件を両立させる実践的なアプローチである。

• [バージョン番号, 公開鍵] の2要素QRコードによる効率的なDID所有権証明。
• チャレンジ＆レスポンス（Nonce） による強力なリプレイ攻撃対策。
• VC全体のハッシュ値と分割情報を用いた、大容量VCの安全なオフライン転送。

これらのメカニズムは、PoC段階での検証を通じて、現代のスマートフォンブラウザ環境における計算時間や運用フローの実現可能性を実証し、AMATELUSが目指す市民主導のデジタルガバナンスへの確かな一歩を築くものである。