1. はじめに

総務省「デジタル技術を活用した効率的・効果的な住民基本台帳事務等のあり方に関するワーキンググループ」における「中間とりまとめ」（2025年6月）では、住民票の写し等の電子交付について、利便性の向上と事務の効率化、そして原本性の確実な担保が強く求められている。

本資料では、特定の独自フォーマットに依存せず、HTML5 や JSON-LD、W3C Verifiable Credentials 等の既存の標準的 Web 技術を組み合わせることで、中間とりまとめで示された要件をいかに技術的に解決し、社会実装可能なものとするかについて、具体的な実現方式を提案する。

2. 住民票電子交付に求められる要件の整理

住民票の写し等の電子交付を実現するにあたっては、総務省の検討会で示された電子交付特有の要件に加え、住民票そのものが本来備えるべき一般的要件（住民記録システム標準仕様書等に基づく要件）の双方を充足する必要がある。

2.1 中間とりまとめにおける主要要件

「デジタル技術を活用した住民基本台帳事務等のあり方に関するワーキンググループ」の中間とりまとめ（2025年6月）では、電子交付の信頼性と利便性を確保するための技術的・実務的要件として、主に以下の事項が挙げられている。

  1. 実質的な真正性の担保（改ざん・偽造の防止）: 交付された電子的な証明書が、自治体によって発行されたときの内容と相違ないことを、第三者（民間窓口等）が暗号技術を用いて客観的かつ確実に確認可能であること。
  2. 券面表示事項とデータの整合性: 住民が画面上で目視する内容（券面表示）と、システムが機械的に処理する構造化データが完全に一致しており、表示とデータの「食い違い」による誤認や不正を招かないこと。
  3. スクリーンショット等の利用による不正防止: 単純なコピーや画面キャプチャによる提示ではないことを担保し、提示者が正当な所持者であることを確認できる（なりすましを防止する）仕組みを備えること。
  4. 検証プロセスの簡便性と民間利活用の促進: 金融機関等の民間窓口において、高度な専門知識や特殊な設備を介さずとも、オンライン・オフラインを問わず迅速かつ容易に真正性が確認できること。

2.2 住民票として一般的に満たすべき要件

媒体が紙か電子かを問わず、公証書類としての法的効力と実務上の正確性を担保するために、住民記録システム標準仕様書等の基準に準拠した以下の要件を充足しなければならない。

  1. 文字情報の正確な再現（標準文字・外字対応）: 氏名や住所における「行政事務標準文字」の完全な再現に加え、自治体固有の外字についても、閲覧者の環境（OSやデバイス）に依存せず正しく表示され、かつ機械的に処理可能であること。
  2. 原本様式の忠実な再現とポータビリティ: スマートフォンでの視認性（レスポンシブ表示）を確保しつつ、必要に応じて従来の「紙の住民票」の様式を忠実に再現し、A4用紙等への印刷時にも公証書類として適切な品質を維持すること。
  3. 基幹データとの同一性の確保: 住民基本台帳システム（基幹システム）に記録されている事項が、漏れなく正確に電子交付データへと反映されていること。

これらの要件を充足する枠組みとして、W3C Verifiable Credentials (VC) は国内外で高く評価されており、必要な機能要件を網羅している。しかし、VC を利活用するための専用のデジタルウォレット・ソフトウェアについては、現時点では異なるスキーム間での相互運用性が十分に確立されておらず、また、あらゆる住民が共通して利用可能なデファクトスタンダードも存在しない。

そのため、ベンダー中立性を維持しつつ、PC やスマートフォン等の主要なプラットフォームで広く住民が利用できる環境を速やかに実現するためには、特定のアプリインストールを強いることなく、OS 標準のブラウザで完結する仕組みが現実的である。なお、この方式は W3C VC や JSON-LD といった標準仕様に準拠しているため、将来的にウォレット・ソフトウェアの相互運用性が確保され、普及が進んだ段階においても、そのままウォレットへ格納・管理できる拡張性と互換性を有している。

3. 標準的 Web 技術による技術的解決策

上記の要件は、既存の Web 標準仕様を適切に組み合わせることで、特定の専用ソフトウェア（デジタルウォレット等）を必要とせずに解決可能である。先行するウォレット方式の機能性を維持しつつ、ブラウザという最も普及した汎用インフラを基盤とすることで、社会実装の難易度を大幅に下げることができる。

3.1. 真正性の担保と券面・データの整合性

表示レイヤーとしての HTML と、データレイヤーとしての JSON-LD を単一のファイル（自己完結型 Web 文書）に包含し、一括してデジタル署名を付与する。

  • 整合性の署名証明: 生成プロセスにおいて、HTML コンテンツのハッシュ値と構造化データを同一の署名対象（マニフェスト）に含める。これにより、目視確認する「券面」と、システムが読み取る「データ」が不可分であることを技術的に保証し、「表示とデータの不一致」を構造的に排除することができる。
  • 暗号アジリティへの配慮と信頼性の確保: NCO や CRYPTOREC 等が検討している暗号移行ロードマップおよび「暗号アジリティ」の重要性を踏まえ、将来のアルゴリズム移行を円滑に行える設計とする。具体的には、既存の楕円曲線暗号（ECDSA、EdDSA等）による署名に加え、耐量子計算機暗号（PQC）による署名を重畳する「ハイブリッド署名」等の手法を検討する。これにより、GPKI/LGPKI 等の既存インフラの PQC 対応・移行を待たずとも、技術的には先行して耐量子性を確保することが可能となる。

3.2. 公的個人認証と Passkey の組み合わせによる不正防止

中間とりまとめで示された「スクリーンショット等による不正防止」の課題に対し、公的個人認証（JPKI）による「本人確認」と、WebAuthn（Passkey）等による「提示の証明」を適切に組み合わせて解決する。

  • 本人確認と所持者結合 (Identity Binding): 交付プロセスの入口において、マイナンバーカードを用いた公的個人認証（JPKI）やカード代替電磁的記録を用いることで、厳格な本人確認を行う。この際、交付される証明書データ（ペイロード）と、例えば住民の保有する端末の Passkey（公開鍵）等を紐付ける。
  • 提示の証明とデバイス結合 (Device Binding): 提示の際、文書内に組み込まれたロジックが Passkey 等の生体認証を要求する。これにより、その瞬間に「正当な権限を持つデバイス/アカウントの管理下で操作されていること」を、時限的な署名（Verifiable Presentation）として動的に生成する。
  • 静的な複製の無効化: ブラウザ自体にはダウンロードされたファイルの複製や、スクリーンショット機能そのものを技術的に抑止する権限はないが、公的書類の「提示」が単なる目視ではなく、前述の Passkey 等による動的な署名の検証を伴うことで解決する。第三者が他人の画面キャプチャを不正に提示しても、検証時に必要な動的署名の再生成ができず、真正性の確認に失敗する。これにより、専用アプリ不要かつブラウザのみで、実効性の高い「静的なコピーによる不正利用の防止」が実現可能となる。

3.3. 自律的な保守モデルと暗号アジリティ

住民票の写し等は一般に短期間の利用が想定されるが、交付システムやデータ形式には、将来にわたる継続性が求められる。

  • 表示レイヤーの動的な最新化: コンテンツ本体（署名済みペイロード）と、その表示を制御するラッパー層（CSS・フォント等）を分離する構造を採用する。ブラウザの進化に合わせてラッパー層のみを更新・再配布可能にすることで、原本の署名を毀損することなく、その時々の閲覧環境で正しくレンダリングを維持できる。

  • 発行体のアイデンティティ管理と信頼の継続: 発行者のアイデンティティ管理において、既存の公적認証基盤に加え、DNS や WebTrust 認定といった多様な信頼基盤と紐付いた識別子体系を活用する。NCO/CRYPTOREC のロードマップに準じた円滑なアルゴリズム移行を可能にするため、発行体の継続性を保つつ、原本の真正性を損なうことなく最新の暗号方式へと「洗い替え」が可能な「暗号アジリティ」を設計上の要件とする。

3.4. 行政事務標準文字および自治体独自外字への対応

Web 標準のフォント技術（WOFF2）と IVS（Ideographic Variation Sequence）を組み合わせ、ブラウザ上で正確な字形表示を実現する。

  • 標準文字の完全サポート: 「行政事務標準文字」に対応したフォントファイルを Web フォントとして文書に内包またはオンデマンドで配信する。これにより、受信者の OS やデバイスの種類に関わらず、自治体側が意図した正確な字形を再現する。
  • 独自外字のベクター埋め込み: フォントに存在しない自治体独自の特殊な外字についても、SVG（Scalable Vector Graphics）等のベクター形式で HTML 内に直接埋め込む手法を採る。これにより、拡大・縮小しても品質が劣化せず、かつ画像キャプチャではない「文書の一部」として署名の対象に含めることができる。

3.5. レスポンシブ CSS による「表示の多層化」

単一の HTML ファイル内で、CSS 3 のメディアクエリを活用し、提示デバイスに応じた最適な表示に切り替える。

  • スマホ最適化ビュー: 窓口での提示時には、Passkey 連携ボタンや重要な記載事項を強調した、スマートフォンでの閲覧に最適なカード型レイアウトを表示する。
  • 原本・印刷用レイアウト: 提出先が従来の紙様式を求める場合や A4 印刷が必要な場合には、CSS 制御により「紙の住民票」と同一の伝統的な様式へと動的にレンダリングを変更する。
  • AI エージェントと自動化への対応: PC 等の利用環境においては、ブラウザ画面の情報を人間が確認するのと同時に、背後の JSON-LD データを AI エージェントがセマンティックに解読・処理することが可能である。これにより、民間窓口等における情報の転記ミスを防止し、事務手続きの高度な自動化を実現する。

4. 住民票電子交付の運用モデル案

4.1. 発行フロー（自治体）

  1. 申請・本人確認: 住民がフロントサービスから交付を申請。マイナンバーカードによる公的個人認証（JPKI）やカード代替電磁的記録等を用いて本人確認を行うとともに、後の提示で用いる Passkey（公開鍵）を登録・紐付け（Identity Binding）する。
  2. データ生成: 基幹システムから受領した住民票データを抽出。
  3. パッケージング: 登録された Passkey と構造化データを結合し、標準規格（HTML5 + JSON-LD + W3C VC）に基づいた自己完結型ファイルをパッケージング。
  4. 発行体署名: 公的な認証基盤、あるいはそれと整合する職印相当の電子署名を付与し、住民へ交付。

4.2. 提示・検証フロー（民間窓口・金融機関等）

  1. 提示: 住民がブラウザで文書を開き、窓口でスマホ画面を提示。
  2. 検証の実行: 文書上の「真正性を確認」ボタンを押し、自身の Passkey で認証。
  3. 真正性の証明: 画面上に発行自治体名や整合性の確認結果が動的に表示される。
  4. データ取得: 窓口側は JSON-LD データを直接抽出し、基幹システムへの自動取り込みに活用。

5. 提言：今後の検討に向けた方向性

本ワーキンググループにおいては、単なる「紙のコピーとしてのPDF」に留まらない、「機械が処理でき、人間が視覚的に確信できる」 デジタル公文書の標準仕様を確立すべきである。既存の Web 標準技術の組み合わせは、以下の 3 点において、電子政府の基盤として極めて有効な候補となると確信している。

  • オープンスタンダードへの立脚: 特定ベンダーの独自技術や専用アプリに依存せず、ブラウザという汎用インフラ上で、公的個人認証（JPKI）とデバイス認証（Passkey）を高度に連携させた安全な提示・検証環境を実現できる。
  • 持続的な情報のアクセシビリティ: コンテンツと表示制御を分離する多層的な構成により、閲覧環境の進化に左右されず、情報の再現性を維持できる。
  • 次世代の技術トレンドとの高い親和性: 既存の公的な信頼基盤を尊重しつつ、NCO/CRYPTOREC 等のロードマップを見据えた「暗号アジリティ」を確保し、さらには AI エージェントによる自動処理や、将来的なデジタルウォレットへの移行を見据えた拡張性を備えている。

6. 社会実装に向けた環境整備と政府の役割

デジタル公文書の普及には、技術仕様の策定のみならず、市場の創出と信頼の担保における政府の戦略的関与が不可欠である。

6.1. 所持者（Holder）環境のレディネスとウォレットの多様性

本方式の最大の特徴は、住民の利用環境（Holder環境）が既に普及している標準ブラウザによって「整っている」という点にある。一方で、より高度なワンストップサービスを実現する上では、クラウド型やAIエージェントを含むデジタルウォレットの活用も視野に入る。

  • 国による直接提供の限界: 国が単独で全ての住民にウォレットを提供し、その利用履歴を集中管理することは、プライバシー保護および中央集権的な監視の懸念から、サービス構造上の慎重な検討が必要である。
  • 民間参入の促進と「靴ひも問題」の解決: 民間のみでは「発行体（Issuer）がいないからウォレットが普及しない」「利用者がいないから検証側（Verifier）が対応しない」というデッドロック（靴ひも問題）が生じやすい。国はこの解きほぐしとして、**参照実装（Reference Implementation）の公開や、標準仕様への準拠を確認できる適合性試験（Conformance Test）**環境を提供することで、民間の多様なエージェント・ウォレット提供を促すべきである。

6.2. 発行者（Issuer）および検証者（Verifier）への支援

自治体および民間サービスにおける導入障壁を下げるため、国は以下の役割を担うべきである。

  • 共通発行基盤の整備: 小規模自治体でも容易に導入できるよう、既存の認証基盤と連携した標準的な発行 API や、セキュリティ要件を満たした発行体用コンポーネントを整備する。
  • 検証ライブラリの提供: 民間窓口（Verifier）が真正性を容易に確認できるよう、標準仕様に基づいた検証用 SDK や、ブラウザ上で動作する検証モジュールの参照実装を提供し、低コストかつ堅牢な検証環境の構築を支援する。

これにより、国が全てを抱え込むのではなく、共通の「信頼のアンカー」と「検証ルール」のみを整備し、その上で民間が創意工夫を凝らす「デジタル公共財」としての社会実装を推進すべきである。

本提案の方式が、効率的かつ効果的な住民基本台帳実務の実現、引いてはデジタル社会の信頼基盤の構築に寄与することを期待する。

以上