English version (英語版)

日付: 2025年12月31日

更新履歴

  • 2024-12-24: 初版発行 (v1.0)
  • 2025-12-27: インタラクティブ・フォーム対応のため「3層トラスト・アーキテクチャ」へ拡張 (v1.1)
  • 2025-12-29: Layer 2 Encryption (L2E) による機密性保護と配送プロトコル拡張を定義 (v1.2)
  • 2025-12-31: トラストモデルを「4層アーキテクチャ」へ昇華。Context層の分離と呼称の適正化 (v1.3)

1. 概要

本稿では、アーカイブ品質のWeb文書仕様である Web/A を提案する。長期の視覚的保存には PDF/A が広く利用されているが、PDF/A は構造や意味の抽出が困難な「データのサイロ」になりがちである。Web/A は、HTML5、CSS、JSON-LD といった標準的な Web 技術を活用し、人間と機械の両方が普遍的に読み取ることができ、単一ファイルとしてポータブルで、かつ暗号的に検証可能なフォーマットを実現する。

2. 背景と課題：PDF/A と XML の限界

2.1. PDF/A の課題：視覚的サイロ

PDF/A (ISO 19005) は文書の「見栄え」の保存には成功したが、自動データ処理の時代においては以下の課題がある：

  • 不透明性: 住所や金額などの特定データの抽出には AI やヒューリスティックな処理が必要であり、決定論的なデータ利用が困難。
  • アクセシビリティ: テキストのリフローやスクリーンリーダー対応が、実装によって不完全になりやすい。

2.2. 「機械可読」の罠：XTX や独自 XML の限界

e-Tax 等で使用される XTX 形式のように、高度に構造化された機械可読データであっても、人間が直接判読できない形式には特有の課題がある：

  • 専用ビューアへの依存: データを人間が確認するために専用のソフトウェアやシステムが必要であり、発行から数十年後にそのビューアが動作する保証がない。
  • 署名対象と視認内容の解離: 人間はビューアが書き出した「二次的な表示」を見て判断する一方、署名は元の「読めないデータ」に対してなされる。このため、ビューアのバグや意図的な改変により、署名を壊さずに情報の見え方だけを操作することが原理的に可能となってしまう。

2.3. XML+XSLT の失敗：接続性の罠 (Connectivity Trap)

初期の電子政府プロジェクトでは、データ（XML）と表示（XSLT）を分離するアプローチが試みられた。しかし、これは「ビットロット（情報の腐敗）」を招いた：

  • 依存関係の断絶: XML は外部の XSLT ファイルなしでは判読不能だが、その XSLT が紛失したり、URL が無効になったりすることが多い。
  • ブラウザの進化: モダンブラウザは XSLT のサポートを縮小（ローカル XSLT の制限等）しており、アーカイブされた文書が閲覧不能になるリスクがある。

2.4. 署名検証の壁：AATL の不透明性とビューア依存

PDF の真正性確認における大きな課題として、信頼の起点（Root of Trust）の管理とユーザー体験の断絶がある：

  • AATL (Adobe Approved Trust List) への依存: 多くの PDF 署名は Adobe 社が管理する独自の「信頼済みリスト (AATL)」に依存している。これは一私企業による中央集権的な信頼管理であり、オープンな Web 標準や各国の公的認証基盤との透明性・ガバナンスにおける乖離が課題となる。
  • 限定的なビューア・サポート: 電子署名（PAdES等）や長期検証（LTV）を正しく処理できるのは、Adobe Acrobat 等の特定のデスクトップアプリに限定される。モバイルブラウザや OS 標準の PDF ビューアでは「署名の状態が不明」と表示されることが一般的であり、エンドユーザーがその場で真正性を確認することが極めて困難である。

Web/A は、**「自己記述的」「自己完結的」「セマンティック」**なフォーマットを提供することで、これらの溝を埋めることを目的とする。

3. Web/A の中核となる原則

3.1. 人間・機械・AI に最適化された構造

すべての Web/A 文書は、単なる二層構造を超え、以下の三つの側面で最適化されなければならない：

  1. 人間可読レイヤー: 高品質な HTML/CSS による視覚的提示。
  2. 機械可読レイヤー: 基幹システムが処理するための厳格な JSON-LD。
  3. セマンティック・アクセシビリティ (AI/Assistive): 構造化の徹底による、支援技術と AI への最適化。

ここで重要なのは、「アクセシビリティ（支援技術への対応）」と「AI による解釈性」の収束である。セマンティックに正しくマークアップされた文書は、視覚障害者のスクリーンリーダーにとっても、情報の要約や推論を行う AI モデルにとっても、等しく「読みやすい」ものとなる。Web/A は PDF/A が抱えていたアクセシビリティ対応の複雑さを、Web 標準のセマンティック HTML によって解消する。

3.2. 極めて高いポータビリティ (Self-Contained)

フォント、画像、スタイルは Data URL 等によりインライン化、または同梱される。50年後のブラウザでも、外部サーバーにアクセスすることなく機能することが保証される。

3.3. 静的なフォーマッティング

Web/A は 静的 CSS を使用する。JavaScript なしでレンダリングが完結するため、ブラウザエンジンの挙動変化の影響を受けにくく、発行時の見栄えを維持できる。

3.4. 暗号による真正性保証

分散型 ID (DID) や検証可能証明書 (VC) と統合され、デジタル署名が付与される。署名は視覚的な HTML とセマンティックな JSON-LD の両方を対象とし、改ざんを防止する。

4. Web/A のスコープとユースケース

Web/A は、すべての Web コンテンツを置き換えるものではない。その主眼は「長期的な信頼と再利用が必要なデジタル・アセット」の標準化にある。

4.1. 主なターゲット（置換・補完対象）

  • 静的な長期保存用 PDF/A: 「表示の固定」には成功しているが機械可読性に欠ける PDF/A を、セマンティックなデータ抽出が可能な Web/A で補完・置換する。
  • 配布用 XML/XTX + 専用ビューア: 専用ソフトがなければ判読できない「不透明なデータファイル」を、汎用ブラウザで即座に閲覧・検証可能な「自己完結型文書」へ転換する。
  • プラットフォーム依存の通知・履歴照会: 特定のサービスにログインしなければ確認できない（サービス終了と共に消失する）通知や受領証を、ユーザーが主体的に管理・永続保有できる独立したアセットにする。

4.2. アウトオブフォーカス（対象外）

  • 高度な動的アプリケーション: リッチなユーザーインタラクションや、外部 API との頻繁な通信を前提とする「Web アプリ」は対象外である。Web/A は、発行された瞬間の「事実」を封じ込めるための静的な記録（レコード）である。
  • リアルタイムな秘密通信: チャットや認証セッションのような「動的な通信経路」の保護は、TLS やメッセージング・プロトコルの領分であり、Web/A の目的ではない。
  • 大容量メディアのアーカイブ: 高解像度動画や巨大なデータベースの物理的な格納。Web/A はあくまで「セマンティックな文書構造」に最適化されており、汎用的な高密度コンテナではない。

4.3. 拡張ユースケース：Web/A Form（入力と記録の統合）

Web/A は「読むため」の文書だけでなく、「入力するため」のアプリケーションとしても機能する。これが Web/A Form である。 後述する「4層トラスト・アーキテクチャ」により、発行者が提供する「正しい設問とロジック（Layer 1）」に対し、利用者が「署名付きの回答（Layer 2）」を付加することで、双方の真正性が担保された一連の文書レコードが完成する。

5. Web/A 準拠レベル

PDF/A-1a/1b のように、用途に応じた厳格さのレベルを定義する：

  • Web/A-1s (Semantic):
    • 有効な HTML5 + CSS。
    • 有効な JSON-LD の埋め込み。
    • 基本的なデジタル署名。
  • Web/A-1u (Universal):
    • 1s の全要件に加え、外部リクエストを禁止。
    • 全アセットのインライン化。
    • 使用文字のみを抽出したサブセットフォントの埋め込み。
  • Web/A-1p (Provenance):
    • 1u の全要件に加え、C2PA形式のプロバンス・マニフェストを保持。
    • 生成ツールによる「人間・機械レイヤーの同一性 (HMP)」の署名付き宣言を含む。
    • 対象: 高い信頼性が必要な公文書や証跡記録。

6. 技術構築モデル

6.1. 4層トラスト・アーキテクチャ (The 4-Layer Trust Architecture)

静的なアーカイブ文書からインタラクティブなフォーム、広域な配送プロトコルまでを統一的に扱うため、Web/A は階層化された 4層トラスト・アーキテクチャ を定義する。

  1. Layer 1: テンプレート (The Template)

    • 役割: 文書の器、設問、および意味論の定義。
    • 内容: HTMLテンプレート、JSON-LDスキーマ、バリデーションロジック。
    • 署名者: 発行者 (Issuer)。公権力や組織による「定義された事実の器」を保証する。

  2. Layer 2: データ (The Data)

    • 役割: 具体的な事実の記録。
    • 内容: 利用者による回答、入力、合意した事実。L2E (Layer 2 Encryption) により暗号化され得る。
    • 署名者: 利用者 (User/Subject)。Layer 1 のハッシュを含めることで、どの設問に対する回答かを紐付ける。

  3. Layer 3: コンテキスト (The Context) ※新設

    • 役割: 流通・管理属性の定義。
    • 内容: 配送タグ (Transport Tag)、有効期限、リプレイガード用 Nonce、ポリシー参照。
    • 特性: 暗号化された Layer 2 を復号することなく、中継サーバー（Web/A Post）が適切にルーティングや一時検証を行うためのメタデータを分離する。

  4. Layer 4: プレゼンテーション (The Presentation)

    • 役割: 視覚的表現とユーザー体験。
    • 内容: CSS、フォント、最小限のレンダリング・ロジック（JavaScript）。
    • 特性: 署名されたデータ・コンテキスト層とは疎結合であり、原本性を損なわずに将来のデバイス環境に合わせてUIをアップデートできる。

6.2. 人間と機械の同一性 (Human-Machine Parity : HMP)

生成ツール（Sorane等）は、JSON-LD と HTML が乖離しないことを保証する責任を持つ：

  • 静的同期: HTML は JSON-LD と同じデータソースから同時に生成（ベイク）される。
  • 生成ツール宣言: C2PA マニフェストを埋め込み、「このツールが同一性を持って生成した」ことを署名付きで記録する。

6.3. Web/A の文書構造と信頼の連鎖

Web/A の堅牢性は、これら四つのレイヤーの厳格な分離と紐付けによって担保される。

Web/A Document (.html) Layer 4: Presentation (View / UI) CSS、フォント、最小限のJS Layer 3: Context (Metadata / Routing) 配送タグ、有効期限、Nonce、ポリシー参照 Layer 2: Data (Evidence / Fact) 暗号化ペイロード、利用者署名 Layer 1: Template (Definition / Schema) 人間用（可読） HTML / テンプレート 等価 マシン用（定義） JSON-LD / ロジック 発行者署名: Ed25519 + PQC

6.3.1. セマンティック・マッピング（検証可能性の向上）

第三者による監査やスクリプトでの突合を容易にするため、表示レイヤーの HTML 要素に対し、JSON-LD のプロパティとの対応を示す属性（例：data-weba-field）を付与することを推奨する。これにより、署名されたペイロード内で「どの表示項目が、どの機械可読データに基づいているか」を透明化し、視覚的な偽装を防止する。

6.3. トラストアンカー（DID）

検証者は、文書内の JSON-LD に含まれる DID (Decentralized Identifier) を解決することで、発行者の正当な公開鍵を取得する。これは DNS や WebTrust 配下の TLS 証明書といった既存のトラスト基盤に立脚した「Web 上の信頼の連鎖」を活用するものであり、特定の証明書発行局（CA）の個別ポリシーに硬直的に依存しない、柔軟かつ透明性の高い運用を実現する。

6.4. 独立した刻印：タイムスタンプ (TSA) による存在証明

発行体の署名だけでは、「いつ」その文書が存在したかを客観的に証明（存在証明）することは困難である。

  • RFC 3161 への対応: Web/A は、公的に信頼されたタイムスタンプ局（TSA）から取得したタイムスタンプ・トークンをプロバンス・マニフェスト内に包含することを推奨する。
  • 検証の自己完結性: 外部の TSA を組み合わせることで、発行体の鍵が将来失効したりアルゴリズムが脆弱化したりした場合でも、発行時点において正当な署名がなされていたことを客観的に証明（長期署名 LTV の実現）可能にする。

6.5. 秘匿性：Layer 2 Encryption (L2E)

Layer 2 が利用者の真正性を担保するのに対し、L2E は提出データの高度な秘匿性を保証する。

  • 受取人限定エンベロープ: 利用者の回答データは、受取人（自治体や企業）の公開鍵を用いて、耐量子ハイブリッド暗号（X25519 + ML-KEM-768）により暗号化される。
  • 復号なき検証: エンベロープ自体には利用者の署名（真正性）とテンプレートハッシュ（文脈結合）が平文で付与されている。これにより、中継ノードやアーキビストは内容を復号することなく、レコードの「存在と完全性」を検証できる。
  • 組織的復号: 特定の担当者のみが復号できるよう、組織鍵（YubiKeyやHSM）を用いた厳格なアクセス制御運用に対応する。

[!TIP] 詳細資料: L2Eの具体的な仕組みについては Web/A L2 Encryption を、そのセキュリティ評価については Security Audit v2 (English) および 既存製品との比較分析 を参照してください。

7. 実装の柔軟性と鍵管理：軽量トラストモデル

アーカイブ品質の署名において、鍵管理の複雑さは最大の導入障壁となっている。Web/A は、高い安全性を担保する HSM（ハードウェア・セキュリティ・モジュール）等による厳格な管理を否定するものではなく、それらを補完し、より広範な普及を促すための「軽量トラストモデル」を提案する。

本モデルの真価は、専用の鍵管理インフラを構築せずとも、既存の Web アプリケーション基盤上で安全に署名文書を発行できる点にある。これにより、VC の普及に不可欠な「発行体の多様性」と「スモールスタート」を両立させる。

特に 耐量子暗号 (PQC) への移行において、このモデルは極めて有効である。既存の PKI や HSM 基盤が PQC に完全対応するのを待つのではなく、Passkey などの既存の信頼基盤をルートとしつつ、ビルドプロセスにおいて PQC 署名を動的に生成・付与することで、**PQC の「安全な先行施行」**を可能にする。

7.1. 権限委譲：Passkey からビルド鍵へ

高価な HSM を全ビルドで回す代わりに、委譲型アイデンティティを活用する：

  1. Root of Trust: 開発者端末の Passkey (WebAuthn) を信頼の基点とする。
  2. 委譲証明書 (Delegate Certificate): ビルド時のみ有効な短期間の鍵（エフェメラル鍵）を Root 鍵で認可する。
  3. CI/CD での署名: ビルド鍵が文書に署名し、その正当性は Passkey への遡及によって証明される。

7.2. エフェメラルな発行

鍵の漏洩リスクを最小化するため、ビルドごとに使い捨ての鍵ペアを生成し、サイト上で公開される key-history.json（公開透明性ログ） に記録する。

7.3. 透明性によるアイデンティティ (DID-lite)

高コストな PKI 証明書に代えて、ウェブサイト自体のドメイン信頼をベースとした公開鍵の開示を行う。

7.4. 高い暗号アジリティ：アルゴリズムの進化への柔軟な適応

Web/A は、特定の暗号アルゴリズムに固定されない「暗号アジリティ (Cryptographic Agility)」を設計の根幹に置いている。これは、従来の PDF やレガシーな XML 署名と比較して、将来の脅威（量子コンピュータの台頭等）に対する極めて高い適応性を提供する。

  1. Root of Trust の動的な更新と継続性: 現在普及している Passkey (FIDO2) デバイスの多くは ECDSA (P-256) 等の古典暗号に基づいている。Web/A の「委譲型アイデンティティ」モデルでは、これら既存デバイスを当面の信頼の起点（Root）としつつ、ビルドプロセスにおいて最新の PQC 署名を付与し、それらを DID ドキュメント上で安全に紐付けることができる。 将来、PQC 対応の次世代 Passkey デバイスが登場した際には、発行体（人間）は自身のアイデンティティを維持したまま、新しい PQC 鍵を Root 鍵リストに追加するだけでよい。これにより、過去に発行した文書との継続性を保ちながら、システム全体のセキュリティレベルをシームレスに引き上げることが可能となる。

  2. ハイブリッド署名による安全な移行: Web/A は、Ed25519（古典）と ML-DSA-44（耐量子）の双方を用いたハイブリッド署名を推奨している。これにより、既存の検証環境（古典暗号のみを解釈可能）での互換性を維持しつつ、将来に備えた耐量子性を「安全に先行施行」できる。単一のアルゴリズムに依存する旧来の証明書モデルに比べ、アルゴリズムの脆弱化が判明した際の「切り替え速度」と「安全網」において優位性を持つ。

  3. 硬直的な証明書構造からの解放: X.509 証明書を PDF に埋め込む従来の方式では、証明書の ASN.1 構造や発行局（CA）のポリシーにアルゴリズムが強く依存しており、迅速な移行が困難であった。Web/A は拡張性の高い JSON-LD と DID を基盤とするため、新しい署名スキーム（ハッシュベース署名等）や証明技術を、既存のデータ構造を破壊することなくアディティブに導入・拡張できる。

8. 高度なタイポグラフィと帳票表現

Web/A は、PDF/A が得意としてきた「帳票の忠実な再現」と、Web が得意とする「データの流動性」を高度にバランスさせる必要がある。

8.1. 文字の網羅性：行政事務標準文字と外字への対応

日本の行政事務で不可欠な「行政事務標準文字」や「人名外字」への対応は、Web/A において以下の二段構えで実現される：

  • WebFont サブセット化: IVS (Ideographic Variation Sequence) を含む膨大な文字セットから、その文書で実際に使用されている字形のみを抽出して埋め込む。
  • SVG 埋め込み: フォント化が困難な特殊な図形文字や、超一過性の外字については、パスデータとして HTML 内に直接インライン化する。 これにより、クライアント側の環境に依存することなく、100% の文字再現性を確保する。

8.2. 帳票レイアウトの再現と課題

日本の公文書は伝統的に「A4 縦、罫線あり」の固定様式を前提としている。Web/A において CSS を用いた帳票レイアウトの再現は可能だが、以下の課題が残る：

  • ピクセル・パーフェクトの追求: ブラウザごとのレンダリングエンジンの微差により、ミリ単位の配置を固定することの難しさ。
  • リフロー性との衝突: 文字サイズ変更などのアクセシビリティ対応と、固定枠レイアウトをいかに両立させるか。

8.3. スマホ時代の「バイモーダル・プレゼンテーション」

スマートフォンの普及により、文書には**二つの提示様態（バイモーダル）**が求められる：

  1. アーカイブ・ビュー (Fixed): 従来の帳票形式。印刷時や、公的な真正性確認の際に利用する「公式な顔」。
  2. ウォレット・ビュー (Adaptive): スマホ画面に最適化されたカード形式。日々の利用において内容を即座に確認するための「実務的な顔」。 Web/A のプレゼンテーション・レイヤーは、単一のペイロードからこれら二つのビューを CSS で切り替えて提供し、管理コストを抑えつつモバイル体験を最大化する。

9. 既存技術との比較

機能項目 PDF/A XML + XSLT Web/A
人間可読性 ◎ (固定表示) △ (ビットロットリスク) ◎ (モダンHTML/CSS)
機械可読性 △ (視覚サイロ) ◎ (構造化データ) ◎ (JSON-LD 統合)
自己完結性 ◯ (フォント埋込等) × (外部定義依存) ◎ (完全インライン)
アクセシビリティ △ (限定的) ◯ (処理次第) ◎ (ネイティブ)
長期保守性 再イメージ化 再コーディング 再ラッピング (LTV)

10. 空音 (Sorane) における実装

Sorane プロジェクトは、Web/A-1p レベルを標準で実装している：

  1. プロバンス・マニフェスト: JSON-LD 内に自動注入。
  2. フォント内署名: サブセットフォントへの SRNC テーブル注入による完全性保護。
  3. ハイブリッド署名: Ed25519 と ML-DSA-44（耐量子暗号）による二重署名。

11. 段階的な導入戦略：利用シーンに応じた階層化

すべての文書に最初からフルスペックの VC 要件（Holder Binding 等）を課すことは、システム構築の難易度を引き上げ、普及を妨げる要因となる。Web/A は、技術の成熟度とユースケースの切実さに応じた段階的な導入を推奨する。

1層：公表用文書・広報資料（現時点の空音のスコープ）

不特定多数に公開される官報、統計データ、ホワイトペーパー等が対象。

  • 技術要件: 真正性（署名）と長期閲覧性の確保。
  • 特性: リプレイアタック（再利用攻撃）のリスクが低く、情報の公開性そのものに価値がある。

2層：個人宛のプライバシー情報を含む文書

特定の個人や組織に対して発出される通知書、受領書、非公開の報告書等が対象。

  • 技術要件: 1層の要件に加え、適切なアクセス制御と秘匿性の確保。
  • 特性: プライバシー保護が重要となるが、提出先での厳格な本人確認までは必ずしも求められない。

3層：本人確認・権限証明書類

住民票の写し、委任状、社員証、資格証明書など、二次流通時において本人性を証明する必要がある文書が対象。

  • 技術要件: Holder Binding（所持者結合）。証明書とそれを提示する個人のアイデンティティ（スマホ内の秘密鍵等）が暗号的に結合されていること。
  • 総務省研究会報告の要件への対応: 総務省の「デジタル技術を活用した効率的・効果的な住民基本台帳事務等のあり方に関するワーキンググループ 中間とりまとめ」（2025年6月）では、本人確認書類の VC 化において以下の主要要件を求めている。Web/A はこれらを Web 標準の延長線上で解決する。
    1. 原本性の確保（改ざん検知）: デジタル署名による完全性保証。Web/A は HTML と JSON-LD の両方に署名することで、表示内容とデータの両面で原本性を担保する。
    • なりすまし防止（Holder Binding）: 所持者と VC を動的に紐付ける技術。Web/A は Verifiable Presentation (VP) の生成機能をプレゼンテーション層に内蔵しており、提示の瞬間にユーザーの Passkey (WebAuthn) 等を用いて「一時的な署名」を作成・付与する。これにより、専用アプリなしで高度な本人確認を実現する。
    1. コピー・再利用の防止: 単なるスクリーンショットでは偽造を困難にする。Web/A 文書は「動的な検証 UI」を内蔵しており、検証者がその場でブラウザを通じて真正性を確認できる。
    2. 選択的開示（Selective Disclosure）: 中間報告で言及されているプライバシー配慮。Web/A は SD-JWT/SD-COSE 技術をサポートし、住民票の全項目のうち「住所・氏名のみ」といった一部開示を、署名の有効性を維持したまま行うことが可能である。
  • 特性: 行政・民間を跨ぐ二次利用を想定し、専用の検証インフラを必要としない「ブラウザ・ベースの信頼チェーン」を構築する。

12. 技術的課題と標準化への展望

Web/A の真の普及には、単一のフォーマット規定を超え、エコシステム全体での技術的課題の解決と標準化が不可欠である。

12.1. クロスデバイス・対面授受のプロトコル

ブラウザ上で閲覧されている Web/A 文書を、対面で相手のスマートフォンに「手渡す」ためのプロトコルにはまだ改善の余地がある。

  • 課題: QRコードの読み取り、NFC/BLE を介した近距離通信がブラウザからシームレスに行えるための標準 API の確立。
  • 展望: ISO/IEC 18013-5 (mDL) や OID4VP などのモバイルウォレット標準との、ブラウザネイティブな統合。

12.2. Holder Binding の実装技術と現実解

3層（本人確認書類）において「なりすまし防止」を実現するには、文書と提示者のアイデンティティを暗号的に結合する必要がある。

  • ブラウザ完結の難しさと制約: Web ブラウザはセキュリティ上のサンドボックスにより、OS レベルの秘密鍵（Secure Enclave等）へのアクセスが制限されている。WebAuthn (Passkey) を利用すれば「端末の所持」は証明できるが、その鍵が「特定個人のものであること」を証明するには、発行時の JPKI（公的個人認証）等による初期登録が必要となる。
  • プラグマティックな解決策（所持の連鎖）:
    1. 公的基盤との紐付け: 発行時にマイナンバーカードの電子証明書を用いて、ユーザーの所持する Passkey と文書を紐付ける。
    2. VP による提示: 提示時にブラウザ内で Passkey を呼び出し、Verifiable Presentation (VP) を生成する。 これにより、原本性が保証された Web/A 文書と、提示時の「生きた署名」が組み合わさり、本人確認書類としての要件を満たす。
  • 展望: スマートフォン搭載の電子証明書とブラウザの API 連携が標準化されることで、ブリッジアプリを介さずに、ブラウザ単体で「マイナンバーカードと同等の信頼性を持つ Holder Binding」が可能となることが期待される。

12.3. フォーマットのネイティブサポート

ブラウザが Web/A を特別な文書として認識するための標準化が必要である。

  • 展望: ブラウザのアドレスバー付近で、その文書の署名状態や HMP（人間・機械の一貫性）を直接表示する標準 UI の策定。

12.4. 信頼の継承 (Trust Transition) の規格化

50年以上の長期保存において、署名を最新の暗号アルゴリズムへ洗替（Refresh）するプロセスの標準化。

  • 展望: 複数のアーカイブ機関（NDL、公文書館、民間クラウド等）が共通して解釈可能な、署名継承履歴の証跡（バーチャルな信頼の連鎖）に関するプロトコルの策定。

12.5. 法的位置付け：証拠力の向上と技術的検証可能性

Web/A は、必ずしも電子署名法が定める「意思表示の代替としての電子署名」の枠組みに固執するものではない。

  • 真正な成立の証明: 公文書においては民事訴訟法上の推定規定が働くが、私文書において Web/A は、その「真正な成立（改ざんがないこと、発行元が確かであること）」を客観的・技術的に検証可能にすることで、裁判外・裁判内を問わず文書の証拠力を高めることに寄与する。
  • PKI エコシステムとの適度な距離: 厳格な本人確認（意思の発露）を必要とする文書以外であれば、必ずしも高コストな PKI インフラに依存せずとも、軽量トラストモデルによる検証可能性だけで十分な社会的・実務的価値を提供できる。

12.6. エコシステム戦略：AI エージェント・ファースト

短期的にはフルスペックのモバイル・ウォレットの普及を待つのではなく、開発者や AI エージェントが直接利用できるツールの提供を優先する。

  • Headless Wallet (CLI / MCP): Gemini-CLI や Claude Code といった AI エージェントが、メタデータを読み取り、自律的に申請・発行・検証を行えるコマンドライン・ツールや MCP (Model Context Protocol) サーバーの開発。
  • プログラム可能なアイデンティティ: AI が Web/A 文書を「処理」する際、その真正性を API 経由で即座に検証し、信頼スコアを算出する。これにより、人間が UI を操作するよりも先に、AI 同士の自動化された信頼チェーンが構築される。

12.7. 移植容易な技術範囲の合意（保存用プロファイル）

Web 技術は進化が速く、かつて標準だった技術（例：XSLT）が廃止されるリスクがある。

  • 課題: 「50年後のブラウザでも確実に動作する」と確信できる HTML/CSS の機能範囲（サブセット）を特定し、コミュニティでのコンセンサスを得ること。
  • 展望: HTML5 Core や基本的な CSS プロパティに限定した「Web/A 保存用基本プロファイル」の規定。これに反する高度なスクリプトや実験的 API の使用をバリデータで検知し、長期保存適性をスコアリングする仕組みの構築。

13. 国際標準化の文脈とコミュニティへの貢献

Web/A は、全く新しい技術をゼロから定義するのではなく、既存の国際標準を「長期保存と検証可能性」という観点から統合・最適化したプロファイルである。以下のコミュニティにおける議論との高い親和性を持つ。

13.1. W3C Verifiable Credentials (VC)

Web/A は、W3C VC 2.0 仕様を「文書」という特定の形式にパッケージングするための Document-centric Profile と位置づけられる。メタデータ（JSON-LD）と表示（HTML）を不可分に結合し、ブラウザさえあれば誰でも検証可能にする実装モデルは、VC の実務的な普及に寄与する。

13.2. IETF SPICE / COSE

バイナリ形式の証明書や選択的開示（SD-COSE）を HTML 文書に応用する試みは、IETF の SPICE WG 等における議論の実証的な一例となる。特に PQC（耐量子暗号）署名を既存インフラ上で安全に運用する「軽量トラストモデル」は、次世代のセキュアなインフラ構築への示唆を含む。

13.3. C2PA (Provenance)

画像や動画を対象とした C2PA (Provenance) 仕様を、HTML ベースのテキスト文書へと拡張し、フォントのサブセット化まで含めた「生成プロセス全体の真正性」を保証するモデルは、C2PA をテキスト領域へ深化させるプロファイル提案となる。

本稿で整理した価値体系や技術的課題は、単一のフォーマットの提案に留まるものではない。次世代の電子行政、デジタル遺産管理、そして多機関が関与する長期的な知識管理において、真に持続可能で検証可能なインフラを構築するための「議論の土台」として位置づけたい。