⚠️ SIMULATION NOTICE / 模擬演習 本文書は、品質確保およびシナリオテストのために生成された架空のアジェンダです。 実在する組織や政府機関による実際の意思決定を反映したものではありません。

ガバナンスTF会議アジェンダ：行政証明書提示ツール仕様案

開催日: 2025年12月31日 起案者: Tech Lead (SRN Core Team) 配布資料: デジタル技術を活用した住民基本台帳事務等のあり方に関するワーキンググループ 中間とりまとめ等 審議事項:

1. 総務省中間とりまとめにおける技術的論点への対応方針
2. 「Web/A + VP 行政証明書提示ツール仕様書 (Draft v2)」の承認
3. PoC（概念実証）開発フェーズへの移行判断

1. アジェンダ

2. Tech Lead 説明スクリプト（台本）

【1. 導入：中間とりまとめが突きつける4つの壁】

(Tech Lead) 「お疲れ様です。本日は、現在検討を進めている**『行政証明書の電子交付』**における技術仕様案について諮ります。 まず、お手元の参考資料（URL）をご覧ください。これは総務省の『デジタル技術を活用した住民基本台帳事務等のあり方に関するWG』での検討資料です。

この中で、住民票の電子交付を実現するためにクリアすべき『4つの壁』とも言える重要論点が提示されています。

1. 『真正性の確保』: 当然ながら、データが改ざんされていないこと。
2. 『見読性とデータの一体性』: ここが非常に重要です。資料でも指摘されていますが、『画面で見える内容（券面）』と『システムが処理するデータ』が乖離することで発生する誤認や不正を防がなければなりません。
3. 『なりすまし・不正利用の防止』: 単なるファイルのコピーやスクリーンショットの提示をどう防ぐか。単に電子署名があるだけでは、コピーされたファイルを他人が提示できてしまいます。
4. 『特定のシステム・ベンダーへの依存回避』: 国民全員に特定の有料アプリや、特定のベンダーのウォレットを強制することは現実的ではありません。汎用的な環境で検証できる必要があります。

既存のPDF形式や、単なるXMLデータでは、これらを同時に満たすことは困難です。 我々 SRNチームとしての回答は、『Web/A (Web Archive)』 技術の全面採用です。」

【2. 解決策：Web/A Folioによる包括的アプローチ】

(Tech Lead) 「今回提案する**『Web/A + VP 仕様 (Draft v2)』**は、これら4つの論点すべてに対し、技術的な解決策を提示しています。順に説明します。

論点1＆2への回答：『HMP（Human-Machine Pairing）』 中間とりまとめでは『紙の証明書と同様の情報の視認性』と『機械可読性』の両立が求められています。 Web/Aは、単一のHTMLファイルの中に、人間用の『正確なレイアウト』と、機械用の『構造化データ（JSON-LD）』を封入し、全体に署名します。 『見ているもの』と『データ』が不可分であるため、構造的に不整合が起きません。また、自治体独自の外字もSVGで埋め込むため、文字化けのリスクも排除します。

論点3への回答：『FIDO鍵による所持者結合（Identity Binding）』 スクショ問題をどう防ぐか。資料でも『提示者が正当な権利者であることの確認』が求められています。 本仕様では、証明書（Web/Aファイル）の中に、**ユーザーの端末（FIDO鍵）**を紐付けます（Binding）。 窓口で提示する際、ブラウザ上で生体認証（指紋・顔）を行わないと、そもそも復号・表示ができない、あるいは検証OKのマークが出ない仕組みとします。これにより、単にファイルをコピーしただけの第三者は、生体認証を突破できないため提示できません。

論点4への回答：『ブラウザ完結型の検証（Verifier）』 『特定のアプリが必要なのでは？』という懸念に対し、本提案では**『標準ブラウザ＋WASM』**で回答します。 検証ロジックをWASMとしてHTMLに内蔵することで、ChromeやSafariといった標準的なブラウザさえあれば、オフライン環境であっても高度な暗号検証が可能です。これは『特定ベンダーへの依存回避』という行政の要請に合致します。」

【3. 深掘り：プライバシーとID連携（JPKI vs FIDO とデータ最小化）】

(Tech Lead) 「続いて、配布資料でも触れられている**『プライバシー保護とデータ最小化（Data Minimization）』**の観点について補足します。これが今回の仕様の肝です。

報告書等では、過剰な個人情報の流通を防ぐため、『選択的開示（Selective Disclosure）』、つまり『相手にとって必要な情報だけを提示できること』の重要性が示唆されています。 従来の『全部入りの紙の住民票』をコピーして渡す運用では、不要な本籍地情報まで渡ってしまう等のリスクがありました。

本仕様では、この課題に対し、複雑な暗号技術（ZKP等）を使わずに、**『定型プロファイル事前発行 ＋ 手元でのVP生成』**という運用モデルで解決します。

1. 定型パターンの事前発行: 自治体は『世帯全員・本籍あり』『本人のみ・本籍なし』といった定型パターン（VC）を発行します。これらは特定の提出先には紐付いていません。
2. 手元でのVP生成と宛先指定: ユーザーは提出時に、手元のFolioで最適なパターンを選び、**『A銀行宛』**という情報を付加してVPを生成し、FIDOで署名します。
3. 法的整合性とプライバシーの両立: これにより、『勝手に中身をいじった違法な住民票』になることを防ぎつつ、自治体（国）には『いつ、どこに出したか』を知られずに済みます。

この設計なら、もし将来的に『性別表記を外したい』といった社会的要請が変わった際も、発行ロジック側の変更だけで柔軟に対応可能です。」

【4. 論点：デジタルウォレットの「相互運用性の欠如」をどう超えるか】

(Tech Lead) 「次に、デジタル証明書（Verifiable Credentials）に関する世界的な批判、すなわち**『相互運用性と見読性の欠如』**という問題に対して、Web/Aがどう回答するかを説明します。なぜ既存のウォレットではなく、我々のアプローチが必要なのか。

従来型のデジタルウォレット（EUDI Wallet等）では、データ（JSON）だけが流通します。 これをどう表示し、どう検証するかは、受け取る側の『ウォレットアプリ』任せでした。 その結果、『A社のウォレットでは正しく表示されるが、B社のウォレットでは詳細が表示されない』『レイアウトが崩れて公的証明書として認められない』といった相互運用性の断絶が起きています。

これに対し、我々のWeb/Aアプローチは発想を逆転させています。

**『データだけでなく、ビューア（表示ロジック）も一緒に包んで渡す』**のです。

Web/AファイルはHTMLですので、中にデータ（JSON-LD）と、それを正しく表示・検証するためのロジック（WASM/JavaScript）が全て内包されています。 これにより、相手がどのブラウザ（Chrome, Edge, Safari）を使っていても、発行者（自治体）が意図した通りの『正しい住民票のレイアウト』が、1ピクセルの狂いもなく100%再現されます。 『ウォレットアプリごとの表示の違い』という問題自体が発生しません。

これこそが、Web技術（HTML）をベースにする最大の利点であり、『相互運用性』に関する究極の解です。」

【5. 論点：PoCの実施形態（CLI vs 一般ユーザー）】

(Tech Lead) 「また、PoCの手法についても補足します。『CUI（コマンドライン）ツールでは一般の住民が使えないではないか』というご指摘を想定しています。 これについては、段階的な実証アプローチをとります。

1. Phase 1: プロトコル検証（CLI） まずはCLIで、複雑な暗号処理（Targeted IssuanceやFIDO署名）が仕様通りに動作し、法的・セキュリティ要件を満たせるかを技術的に検証します。 ここでいきなりGUIアプリを作ってしまうと、議論が『ボタンの配置』や『使い勝手』といった表層的なUXに終始してしまい、肝心の『信頼の仕組み』の検証が疎かになるリスクがあります。

2. Phase 2: ブラウザ実装への展開（WASM） 我々のコアロジックは WebAssembly (WASM) で実装されています。 Phase 1のCLIで検証されたロジックは、コードを書き換えることなく、そのままブラウザ上で動作するWebアプリとして提供可能です。 一般モニターを実験では、このWebアプリ版を提供します。

3. Phase 3: SDK化と民間開放 最終的には、この検証済みのWASMモジュールをSDKとして公開します。 これにより、銀行の公式アプリや、自治体ポータルアプリなどが、この機能を自社アプリ内に簡単に組み込めるようになり、住民は意識することなくFolioのセキュリティを享受できる未来を描いています。

つまり、今回のCLI実装は、『開発者のお遊び』ではなく、『将来のあらゆるGUIの共通基盤』を作るための必須工程であるとご理解ください。」

【6. 結びと決議依頼】

(Tech Lead) 「以上のように、本仕様案は、総務省の中間とりまとめで示された『真正性』『可読性』『不正防止』『汎用性』のすべての論点を網羅しています。

行政機関、そして民間事業者（検証者）の双方にとって、最も導入ハードルが低く、かつ安全な方式であると確信しています。 つきましては、本仕様書案の承認と、PoC開発フェーズへの移行についてご承認をお願いいたします。」