AILEX、AI判断証跡の国際標準仕様「VAP/LAP」をIETFに提出。司法AIの「ブラックボックス問題」を解決する技術仕様を、インターネット標準化プロセスへ。

はじめに

2026年2月14日、AILEXはInternet-Draft「draft-ailex-vap-legal-ai-provenance-00」をIETF（Internet Engineering Task Force）に提出し、正式に公開されました。

IETF Datatracker： draft-ailex-vap-legal-ai-provenance-00

このドラフトは、全22セクション・26ページにわたる技術仕様書です。Part I（§1〜§12）でVAP Frameworkを、Part II（§13〜§19）でLAP（Legal AI Profile）を定義し、付録にドメインプロファイル比較表と変更履歴を含みます。

本記事では、このInternet-Draftの全セクションを網羅的に解説します。技術仕様書を「読み解く」ための解説記事として、省略なくお伝えします。

1. IETFとInternet-Draftとは

IETFの役割

IETFは1986年に設立された、インターネットの技術標準を策定する国際的なオープンコミュニティです。政府機関や企業の団体ではなく、個人の技術者が自発的に参加する「ラフコンセンサスとランニングコード（rough consensus and running code）」を原則とする組織です。

IETFが策定した代表的な標準には以下があります。

RFC番号	プロトコル	概要
RFC 791	IPv4	インターネットの基盤アドレス体系
RFC 2616 → RFC 9110	HTTP	Webの通信プロトコル
RFC 8446	TLS 1.3	HTTPSの暗号化基盤
RFC 5321	SMTP	電子メールの送信プロトコル
RFC 1034/1035	DNS	ドメイン名解決システム
RFC 8032	Ed25519	電子署名アルゴリズム（VAP/LAPが採用）
RFC 3161	TSP	タイムスタンプ・プロトコル（VAP/LAPの外部アンカリングで採用）

私たちが日常的にインターネットを使えるのは、IETFが定めたこれらの標準があるからです。

Internet-Draftの位置づけ

IETFの標準化プロセスは以下の流れで進みます。

Internet-Draft (I-D) 提出
    ↓ コミュニティレビュー・議論
    ↓ 改訂（-01, -02, ...）
Working Group 採択（WG Draft化）
    ↓ WG内での合意形成
    ↓ IETF Last Call
    ↓ IESG承認
RFC 発行（標準化完了）

今回AILEXが提出したのは、このプロセスの最初のステップ「Internet-Draft」です。ドラフト番号の末尾「-00」は初回提出を意味します。ここからレビュー、議論、改訂を経て、最終的にRFCとして標準化されることを目指します。

Internet-Draftは提出から185日（約6ヶ月）で自動的に失効するため、継続的な改訂（-01, -02, …）が必要です。これはIETFが「活発に議論されている仕様だけが生き残る」ことを意図した設計です。

「Running Code」の原則

IETFの文化において特に重要なのが「Running Code（動くコード）」の原則です。仕様書だけの提案よりも、実際に動く実装が存在する仕様のほうが標準化される可能性が高いとされています。

AILEX SaaS（https://users.ailex.co.jp）は、このVAP/LAP仕様のリファレンス実装として現に稼働しています。PIIマスキング、AIファクトチェック、監査ログといったAILEXの既存機能は、VAP/LAPが定義する概念の実装に直接対応しています。この「Running Code」の存在は、IETF標準化プロセスにおいて大きなアドバンテージです。

なぜ「Individual Submission」なのか

IETFへのInternet-Draft提出には、大きく2つのルートがあります。

提出ルート	説明	今回の提出
Individual Submission	個人・組織が独自に提出	✅ こちら
Working Group Draft	WGの合意を経て提出	将来目標

今回は「Individual Submission」として、AILEX単独で提出しました。カテゴリは「Experimental（実験的）」です。Standards Track（標準トラック）での提出はIETFのルール上Individual Submissionでは認められないため、まずExperimentalとして提出し、コミュニティの関心と支持を獲得した上で、Working Group（例えばSCITT WG）への採択を目指す戦略です。

2. なぜ今この仕様が必要なのか

構造的課題：「信頼ベースのAIガバナンス」の限界

VAP/LAPのIntroductionは、以下の構造的課題を列挙しています。

課題	説明	VAP/LAPによる解決
再現不可能性	AIの判断プロセスが再現できない	Provenance Layerによる判断由来の記録
記録欠如	意思決定の過程が記録されていない	Integrity Layerによる自動ロギング
改ざん可能性	監査記録が事後的に書き換え可能	Hash Chain + External Anchoringによる暗号的保証
責任曖昧性	事故時の責任主体が特定不能	Accountability Layerによる責任境界の可視化
検証不可能性	第三者が独立して検証できない	Third-Party Verification Protocolによる独立検証
選択的ログ	都合の悪い記録が省略される	Completeness Invariantによる完全性保証

現在のAIガバナンスは「信頼ベース」で運営されています。AIプロバイダーが「当社のAIは安全です」と主張しても、独立した第三者がその主張を暗号学的に検証する手段がないのです。

たとえば、あるAIシステムが不適切な回答を生成した場合を考えてください。

「安全装置は正常に機能していました」とプロバイダーが説明したとして、それを誰が検証できるでしょうか
ログが改ざんされていないことを、誰が保証できるでしょうか
都合の悪いログだけが削除されていないことを、どうやって証明するでしょうか

これが「信頼ベースのAIガバナンス」の限界です。VAP/LAPは、この限界を「暗号学的に検証可能な証跡」で克服します。

EU AI Actの要求と「規格の空白」

EU AI Act（Regulation (EU) 2024/1689）は、高リスクAIシステムに対して以下の義務を課しています。

Article	要件	適用開始
Article 12	AIシステムの稼働中の自動ログ記録	2026年8月2日
Article 14	人間による監視の記録と文書化	2026年8月2日
Article 11	AIシステムに関する技術文書の整備	2026年8月2日
Annex III	「司法の運営」はハイリスクカテゴリ	2026年8月2日

問題は、これらの要件を「どのプロトコルで」「どのデータフォーマットで」「どの暗号アルゴリズムで」実装すべきかを定めた国際標準が存在しないことです。VAP/LAPは、まさにこの「規格の空白」を埋めるために設計されました。

法律AI特有の5つの課題

法律AIには、一般的なAIにはない固有の課題があります。VAP/LAPのIntroductionとLAP Overviewは、以下の5つを明示的に定義しています。

課題1：非弁行為リスク（Unauthorized Practice of Law Risk）

弁護士法第72条は法律事務を弁護士に限定しています。AIが法律事務を独立して行っていないことを証明するには、「弁護士がAI出力を精査した」という証跡が必要です。しかし、現行のリーガルテックサービスの大半は、この精査証跡を暗号学的に記録していません。

課題2：ハルシネーション（Hallucination）

AIが架空の判例や存在しない条文を引用した場合、それをどう事後的に検出・追跡するか。米国では2023年以降、弁護士がAI生成の虚偽判例を裁判所に提出する事案が相次ぎ、社会問題化しています。Mata v. Avianca事件（2023年）では、ChatGPTが生成した6件の架空判例を弁護士が引用し、懲戒処分を受けました。

課題3：選択的ログ（Selective Logging）

AIが生成した「都合の悪い」出力だけをログから削除することを、どう技術的に防ぐか。AIシステムの運営者が、ハルシネーションを含む回答のログだけを消去すれば、事後的な検証が不可能になります。

課題4：守秘義務との緊張（Attorney-Client Privilege）

弁護士の守秘義務（弁護士法第23条）を守りながら、外部AIのAPIを利用する際の証跡をどう残すか。依頼者の相談内容そのものをログに記録すれば守秘義務に反しますが、何も記録しなければ検証ができません。

課題5：責任の曖昧性（Accountability Ambiguity）

「AIが言った」で終わる無責任な構造をどう排除するか。AIが生成した法律文書に誤りがあった場合、その責任はAIプロバイダーにあるのか、利用した弁護士にあるのか、SaaS提供者にあるのか。責任の所在を明確にするには、「いつ」「誰が」「何を根拠に」判断したかの記録が不可欠です。

3. 仕様の全体構成

Internet-Draft「draft-ailex-vap-legal-ai-provenance-00」は、以下の構成で全22セクション・26ページです。

Part I: VAP Framework（§1〜§12）

セクション	タイトル	内容
§1	Introduction	設計原則、スコープ、「Verify, Don’t Trust」
§2	Conventions and Definitions	BCP 14準拠のキーワード定義、用語集
§3	VAP Framework Architecture	6層アーキテクチャ、ドメインプロファイル体系
§4	Cryptographic Foundation	暗号アルゴリズム要件、ハッシュチェーン仕様、電子署名
§5	Common Event Structure	共通イベントJSONスキーマ、数値エンコーディング規則
§6	Conformance Levels	Bronze / Silver / Gold の3段階適合性レベル
§7	External Anchoring	RFC 3161 TSA、透明性ログ、Merkleツリー構築
§8	Completeness Invariant	完全性不変条件の数学的定義
§9	Evidence Pack Specification	エビデンスパックの構造とマニフェスト
§10	Privacy-Preserving Verification	ハッシュ化によるプライバシー保護検証
§11	Retention Framework	データ保持期間要件
§12	Third-Party Verification Protocol	3段階アクセスレベルの第三者検証

Part II: Legal AI Profile（§13〜§19）

セクション	タイトル	内容
§13	LAP Overview	司法AI固有の5課題、プロファイル登録情報
§14	LAP Event Type Taxonomy	3パイプライン＋HUMAN_OVERRIDEのイベント型定義
§15	LAP Completeness Invariant	3パイプライン独立の完全性不変条件
§16	Override Coverage Metric	弁護士精査率の計算式と評価基準
§17	LAP Privacy-Preserving Fields	8種類のプライバシー保護ハッシュフィールド
§18	LAP Conformance Level Mapping	LAP固有の適合性マトリクス
§19	LAP Regulatory Alignment	弁護士法・EU AI Act・法務省ガイドラインとの対応（参考情報）

その他

セクション	タイトル	内容
§20	Security Considerations	7つのセキュリティ検討事項
§21	IANA Considerations	IANA登録事項（現時点ではなし）
Appendix A	Profile Comparison	VCP / CAP / LAP の比較表
Appendix B	Change Log	ドラフト改訂履歴

4. §1 Introduction：設計原則「Verify, Don’t Trust」

設計原則

VAP Frameworkの設計原則は一つの文に凝縮されています。

「Verify, Don’t Trust」（信頼するな、検証せよ）

AIプロバイダーの自己申告に依存するのではなく、暗号学的に独立検証可能な証跡を構造的に提供する。これがVAPの核心です。

この原則はインターネットセキュリティの「ゼロトラスト（Zero Trust）」概念と同根です。ネットワークセキュリティの分野では「社内ネットワークだから安全」という信頼を排除し、すべての通信を検証する設計が主流になりました。VAP/LAPは同じ思想をAIガバナンスに適用します。「自社のAIだから安全」という信頼を排除し、すべてのAI判断を暗号学的に検証可能にするのです。

スコープの意図的な限定

VAP/LAPのスコープは意図的に限定されています。対象は「システム障害が人間の生命、社会インフラ、民主的制度に重大かつ不可逆的な損害を引き起こしうるAIシステム」です。

これは一般的なログフレームワーク（例：Syslog、OpenTelemetry）との差別化を意図しています。VAPは「あらゆるAIシステムのログ」を対象としているのではなく、「高リスクAIシステムの暗号学的に検証可能な判断証跡」に焦点を絞っています。

LAPは具体的に「弁護士に対してAIを活用した法律相談、文書生成、ファクトチェックサービスを提供する法律AIシステム」をスコープとします。

2部構成の設計

Internet-Draftは2つの補完的な仕様を定義しています。

Part I: VAP Framework — 高リスクAI全般に適用可能な分野横断フレームワーク
Part II: Legal AI Profile (LAP) — 法律AIシステム向けのドメイン固有プロファイル

この2層構造により、VAP Frameworkは法律以外のドメイン（金融、医療、自動車など）にも拡張可能です。各ドメインはVAPの共通基盤を継承しながら、ドメイン固有のイベント型、メトリクス、規制マッピングを定義できます。

5. §2 Conventions and Definitions：用語体系

BCP 14準拠のキーワード

VAP/LAPはIETFの標準的なキーワード定義（RFC 2119 / RFC 8174）に従い、以下のキーワードを大文字で使用しています。

キーワード	意味
MUST	絶対的な要件。準拠するためには必ず満たさなければならない
MUST NOT	絶対的な禁止。準拠するためには絶対に行ってはならない
REQUIRED	MUSTと同義
SHALL / SHALL NOT	MUST / MUST NOTと同義
SHOULD	推奨。特定の状況では無視してもよいが、その影響を十分理解すること
SHOULD NOT	非推奨。特定の状況では許容されるが、その影響を十分理解すること
RECOMMENDED	SHOULDと同義
MAY	任意。実装してもしなくてもよい
OPTIONAL	MAYと同義

IETFの仕様書では、これらのキーワードが大文字で書かれている場合にのみ、上記の意味を持ちます。通常の文中での小文字使用は一般的な英語の意味です。

主要用語

VAP/LAPが定義する主要な用語は以下の通りです。

用語	定義
VAP	Verifiable AI Provenance Framework — 本ドキュメントで定義される分野横断上位フレームワーク
Profile	VAPのドメイン固有インスタンス化（例：VCP=金融、CAP=コンテンツ、LAP=法律）
LAP	Legal AI Profile — 本ドキュメントで定義される司法AIドメインプロファイル
Provenance	データの起源・派生・履歴の暗号学的に検証可能な記録
Completeness Invariant	すべてのATTEMPTイベントに厳密に1つの対応する結果イベントが存在することの数学的保証
Evidence Pack	規制当局への提出と第三者監査に適した、自己完結型の署名済みプロベナンスイベントパッケージ
External Anchor	MerkleルートハッシュをRFC 3161等の外部信頼タイムスタンプサービスに登録すること
Human Override	人間の専門家がAI生成出力をレビュー・承認・修正・棄却した事実を記録するイベント
Override Coverage	AI出力のうち人間の専門家がレビューした割合をパーセンテージで表現したもの
Causal Link	結果イベントからその発生元のATTEMPTイベントへの参照。パイプライン内の参照整合性を確立する

6. §3 VAP Framework Architecture：6層アーキテクチャ

VAP Frameworkは6つの層で構成されています。

Layer 1：整合性層（Integrity Layer）

すべての適合性レベルでREQUIRED。

ハッシュチェーン、電子署名、タイムスタンプにより、すべてのイベントが改ざんされていないことを暗号学的に保証します。1つでもイベントが改ざん・削除されれば、チェーン全体の検証が失敗する設計です。

この層は「イベントが記録された時点から一切変更されていない」ことの暗号学的証明を提供します。

Layer 2：プロベナンス層（Provenance Layer）

すべての適合性レベルでREQUIRED。

各イベントについて、以下の5つの要素を構造化して記録します。

要素	説明	例（法律相談の場合）
Actor	誰が操作したか	弁護士（Bar Number Hash）
Input	何を入力したか	質問文（PromptHash）
Context	どのような文脈で	事件番号、使用AIモデル
Action	何を実行したか	法律相談AIに質問を送信
Outcome	どのような結果が得られたか	AI回答を受信（ResponseHash）

Layer 3：アカウンタビリティ層（Accountability Layer）

operator_idはREQUIRED、approval chainはRECOMMENDED。

運用者の識別情報、承認チェーン、委任記録を管理します。「AIが言った」で終わる無責任な構造を排除し、責任の所在を明確にします。

フィールド	要件	説明
operator_id	REQUIRED	システム運用者の識別子
last_approval_by	RECOMMENDED	最後に承認した人物
approval_timestamp	RECOMMENDED	承認日時

Layer 4：トレーサビリティ層（Traceability Layer）

trace_idはREQUIRED、cross-profile referencesはOPTIONAL。

トレースIDと因果リンク（Causal Link）により、イベント間の因果関係を追跡可能にします。たとえば「この文書生成リクエスト（ATTEMPT）は、このAI回答（RESPONSE）に対応する」という因果関係を暗号学的に記録します。

Layer 5：共通基盤（Common Infrastructure）

適合性レベルに応じて利用可能な横断的機能群です。

機能	Bronze	Silver	Gold
適合性レベル	✅	✅	✅
外部アンカリング	—	✅ 日次	✅ 毎時
完全性不変条件	—	✅	✅
エビデンスパック	—	✅	✅
プライバシー保護検証	—	✅	✅
データ保持フレームワーク	✅	✅	✅

Layer 6：ドメインプロファイル層（Domain Profile Layer）

ドメインごとに固有のイベント型、データモデル拡張、規制マッピングを定義します。

VAP/LAPでは以下のドメインプロファイルが登録されています（開発中含む）。

Profile ID	ドメイン	状態
VCP	金融（Finance）	v1.1 運用中
CAP	コンテンツ（Content/Creative AI）	v1.0 運用中
LAP	法律（Legal AI）	v0.2 本ドラフトで定義
DVP	自動車（Automotive）	開発中
MAP	医療（Medical）	開発中
PAP	行政（Public Administration）	開発中

各プロファイルはVAPの共通基盤を継承しつつ、以下の5項目を定義する義務を負います。

Event Types（イベント型） — ドメイン固有のイベント型分類
Data Model Extensions（データモデル拡張） — VAP共通イベント構造への追加フィールド
Conformance Mapping（適合性マッピング） — VAP Bronze/Silver/Goldレベルへのマッピング
Regulatory Alignment（規制適合性） — 適用される規制との対応関係（参考情報）
Completeness Invariant Application（完全性不変条件の適用） — ドメイン固有のイベントフローへの適用方法

7. §4 Cryptographic Foundation：暗号基盤

アルゴリズム要件

VAPの暗号基盤は、すべてRFCに準拠した標準アルゴリズムで構成されています。

カテゴリ	Primary（必須）	Alternative（代替）	Post-Quantum（将来）
ハッシュ	SHA-256	SHA-384, SHA-512	SHA3-256
電子署名	Ed25519 (RFC 8032)	ECDSA P-256	ML-DSA-65
暗号化	AES-256-GCM	ChaCha20-Poly1305	Kyber-1024

重要な設計判断：暗号アジリティ（Crypto Agility）

すべての暗号フィールドにアルゴリズム識別子を必須化（MUST） しています。これにより、将来のアルゴリズム移行（特にポスト量子暗号への移行）が容易になります。ハッシュ値は「sha256:...」、署名は「ed25519:...」のように、常にアルゴリズム名をプレフィックスとして含みます。

量子コンピュータが実用化された場合、現在の暗号アルゴリズムの一部は安全でなくなる可能性があります。VAP/LAPのアルゴリズム識別子設計は、この移行を「仕様の改訂なし」で実現できるようにしています。

ハッシュチェーン仕様

イベント間はハッシュチェーンで連結されます。

EventHash[n] = SHA-256(
  Canonicalize(Event[n] without Signature field)
)

where Event[n].PrevHash = EventHash[n-1]
      Event[0].PrevHash = null  (genesis event)

Canonicalization MUST follow RFC 8785 (JSON Canonicalization Scheme).

ハッシュチェーンの動作を直感的に説明すると、以下のようになります。

[Event 0] ──hash──→ H0
                      ↓ PrevHash
[Event 1] ──hash──→ H1 (H0を含む)
                      ↓ PrevHash
[Event 2] ──hash──→ H2 (H1を含む)
                      ↓ PrevHash
[Event 3] ──hash──→ H3 (H2を含む)
    ...

各イベントのハッシュには前のイベントのハッシュが含まれるため、チェーンの途中で1つでもイベントを改ざん・削除すれば、それ以降のすべてのハッシュが不整合となり、改ざんが即座に検出されます。

チェーン整合性の検証は、以下の3ステップで行います。

各イベントのハッシュが再計算ハッシュと一致すること
各イベントのPrevHashが前のイベントのEventHashと一致すること
最初のイベント（genesis event）のPrevHashがnullであること

JSON正規化：RFC 8785

ハッシュ計算において「同じデータから同じハッシュ値を得る」ためには、JSONの正規化（Canonicalization）が不可欠です。VAP/LAPはRFC 8785（JSON Canonicalization Scheme、JCS）を採用しています。

なぜ正規化が必要なのか。以下の2つのJSONは論理的に同一ですが、バイト列が異なります。

// 表現A
{"name": "AILEX", "version": "1.2"}

// 表現B（キー順が異なる）
{"version": "1.2", "name": "AILEX"}

// 表現C（空白が異なる）
{ "name" : "AILEX" , "version" : "1.2" }

RFC 8785は、キーの辞書順ソート、不要な空白の除去などの規則を定め、論理的に同一のJSONから常に同一のバイト列（＝同一のハッシュ値）が得られることを保証します。

電子署名

すべてのイベントはEd25519（RFC 8032）で署名されなければなりません（MUST）。

Signature = Ed25519.Sign(PrivateKey, EventHash_bytes)
Encoded as: "ed25519:" + Base64(Signature)

署名はイベントハッシュのバイト列に対して計算されます。これにより、イベントの内容が署名後に変更されていないことを検証できます。

数値エンコーディング規則

VAP/LAPは数値の扱いについて重要な設計判断を行っています。

金額、暗号値、高精度計測値はJSON文字列としてエンコードすべき（SHOULD）。 その理由は3つです。

IEEE 754の精度限界： JSONの数値型はIEEE 754倍精度浮動小数点のみであり、0.1 + 0.2 ≠ 0.3 となる。法律・金融の文脈では正確な10進表現が必須
パーサー間の不整合： プログラミング言語によって大きな整数（2^53超）や高精度小数の扱いが異なり、サイレントなデータ破損を引き起こす
正規化の安定性： RFC 8785は数値のシリアライズ規則を定めているが、文字列エンコーディングはパーサー依存の数値再フォーマットを完全に回避し、実装間で一貫したハッシュ計算を保証する

カウンター（event_count、token_count等）のような正確な精度が不要なフィールドはJSON数値を使用してもよい（MAY）。

8. §5 Common Event Structure：共通イベント構造

VAP/LAPの全イベントは、以下の共通JSON構造に従います。

{
  "vap_version": "1.2",
  "profile": {
    "id": "LAP",
    "version": "0.2.0"
  },
  "header": {
    "event_id": "UUIDv7 (RFC 9562)",
    "chain_id": "UUIDv7",
    "prev_hash": "sha256:... | null (genesis)",
    "timestamp": "ISO 8601 with timezone",
    "event_type": "LEGAL_QUERY_ATTEMPT"
  },
  "provenance": {
    "actor": {
      "actor_id": "string",
      "actor_hash": "sha256:...",
      "role": "attorney"
    },
    "input": { },
    "context": { },
    "action": { },
    "outcome": { }
  },
  "accountability": {
    "operator_id": "string",
    "last_approval_by": "string",
    "approval_timestamp": "ISO 8601"
  },
  "domain_payload": { },
  "security": {
    "event_hash": "sha256:...",
    "hash_algo": "SHA256",
    "signature": "ed25519:...",
    "sign_algo": "ED25519",
    "signer_id": "string"
  }
}

各セクションの詳細を解説します。

セクション	フィールド	説明
vap_version	—	VAPフレームワークバージョン（現在 “1.2”）
profile	id, version	ドメインプロファイルの識別子とバージョン
header	event_id	UUIDv7による一意識別子。RFC 9562準拠で時系列ソート保証
	chain_id	このイベントが属するハッシュチェーンの識別子
	prev_hash	前のイベントのハッシュ値。genesisイベントはnull
	timestamp	ISO 8601形式・タイムゾーン付きタイムスタンプ
	event_type	プロファイル固有のイベント型文字列
provenance	actor	操作者の識別情報（IDまたはプライバシー保護ハッシュ）
	input	入力データ（ハッシュ化される場合あり）
	context	操作の文脈（事件番号、使用モデル等）
	action	実行されたアクション
	outcome	結果データ
accountability	operator_id	システム運用者の識別子（REQUIRED）
	last_approval_by	最後の承認者（RECOMMENDED）
domain_payload	—	ドメイン固有の追加データ（LAP固有フィールド等）
security	event_hash	このイベント自体のSHA-256ハッシュ
	hash_algo	使用ハッシュアルゴリズム（暗号アジリティのため必須）
	signature	Ed25519電子署名
	sign_algo	使用署名アルゴリズム（暗号アジリティのため必須）
	signer_id	署名者の識別子

UUIDv7（RFC 9562）の採用理由： UUIDv7は48ビットのUnixタイムスタンプを先頭に含むため、UUID自体でイベントの時系列順ソートが保証されます。UUIDv4（完全ランダム）では時系列順が保証されず、大量イベントの効率的なソートと検索にオーバーヘッドが発生します。

9. §6 Conformance Levels：Bronze / Silver / Gold

VAP/LAPでは、実装の段階に応じて3つの適合性レベルを定義しています。各レベルは下位のすべての要件を継承します（Gold ⊃ Silver ⊃ Bronze）。

Bronze Level（中小企業・初期導入向け）

要件	必要性
全AI判断ポイントのイベントログ記録	REQUIRED
SHA-256ハッシュチェーンによる全イベント連結	REQUIRED
Ed25519電子署名（全イベント）	REQUIRED
ISO 8601タイムスタンプ（タイムゾーン付き）	REQUIRED
UUIDv7イベント識別子	REQUIRED
最低6ヶ月のデータ保持	REQUIRED
JSON Schema バリデーション	REQUIRED

Bronzeは「最低限の暗号学的整合性」を提供します。ハッシュチェーンと電子署名により、ログの改ざんは検出可能です。ただし、外部アンカリングがないため、「ログ全体が丸ごと差し替えられた」場合の検出はできません。

Silver Level（エンタープライズ・規制産業向け）

Bronzeの全要件に加え、以下が追加されます。

追加要件	必要性
日次の外部アンカリング（RFC 3161 TSAまたは同等の透明性ログ）	REQUIRED
完全性不変条件の検証	REQUIRED
エビデンスパック生成機能	REQUIRED
機密データのプライバシー保護ハッシュ化	REQUIRED
最低2年のデータ保持	REQUIRED
Merkleツリー構築	REQUIRED
第三者検証エンドポイント	REQUIRED

Silverは「規制産業で求められる水準」を提供します。外部アンカリングにより、ログ全体の差し替えも検出可能になります。完全性不変条件により、選択的ログが技術的に不可能になります。

Gold Level（高度規制産業向け）

Silverの全要件に加え、以下が追加されます。

追加要件	必要性
毎時の外部アンカリング	REQUIRED
HSMによる署名鍵管理（FIPS 140-2/3）	REQUIRED
透明性ログサービス（SCITT等）との統合	REQUIRED
リアルタイム監査API（サブ秒レイテンシ）	REQUIRED
最低5年のデータ保持	REQUIRED
24時間インシデント対応とエビデンス保全	REQUIRED
地理冗長性（最低2リージョン）	REQUIRED
年次第三者監査	REQUIRED
Crypto-shredding対応	REQUIRED

Goldは「最高水準の検証可能性」を提供します。HSMにより署名鍵が物理的に保護され、毎時アンカリングにより最大1時間の時間粒度で第三者検証が可能です。

10. §7 External Anchoring：外部アンカリング

外部アンカリングとは

外部アンカリングは、イベントが「特定の時点で確かに存在していた」ことを、システム運用者とは独立した第三者が検証できる仕組みです。

ハッシュチェーン単体では、「チェーン全体を丸ごと再生成して差し替える」という攻撃を防ぐことができません。外部アンカリングは、ハッシュチェーンの特定時点のスナップショット（Merkleルートハッシュ）を外部の信頼できるサービスに登録することで、この攻撃を防止します。

アンカリングサービスの種類

VAP/LAPは抽象的なアンカリングインターフェースを定義し、複数のサービスタイプで実現可能です。

サービスタイプ	信頼モデル	規範性	説明
RFC 3161 TSA	CA信頼階層	規範的ベースライン	X.509 PKIに基づく伝統的な企業向けタイムスタンプ
透明性ログ（SCITT等）	公開追記専用ログ	規範的（Gold）	IETF SCITT WGが策定するAppend-only透明性ログ
ブロックチェーン	PoW/PoSコンセンサス	非規範的	Bitcoin/Ethereumアンカリング。分散型信頼が必要な環境向け

Gold Level実装はRFC 3161 TSAに加えて（または代えて）、少なくとも1つの透明性ログサービスを使用しなければなりません（MUST）。クリティカルなデプロイメントでは複数の独立したアンカリングサービスを使用すべきです（SHOULD）。

Anchor Record Format

各アンカリング操作は、以下の構造で記録されます。

{
  "anchor_id": "UUIDv7",
  "anchor_type": "RFC3161 | TRANSPARENCY_LOG | BLOCKCHAIN",
  "merkle_root": "sha256:...",
  "event_count": 1000,
  "first_event_id": "UUIDv7",
  "last_event_id": "UUIDv7",
  "first_event_timestamp": "ISO 8601",
  "last_event_timestamp": "ISO 8601",
  "anchor_timestamp": "ISO 8601",
  "anchor_proof": "Base64-encoded proof",
  "service_endpoint": "https://tsa.example.com"
}

Merkleツリー構築

イベントはバイナリMerkleハッシュツリーにバッチ処理されます。

Leaf[i]      = SHA-256(EventHash[i])
Interior[j]  = SHA-256(Left_child || Right_child)
MerkleRoot   = Interior[root]

葉（Leaf）の数が2の冪でない場合、最後の葉を複製してツリーを完成させます（MUST）。

RFC 6962（Certificate Transparency）のツリー構築に従うか、同等のバイナリMerkleツリー構築を使用してもよい（MAY）とされています。

Merkle包含証明（Inclusion Proof） により、バッチ内の他のイベントを開示することなく、特定のイベントが確かにそのバッチに含まれていたことを証明できます。

      MerkleRoot
       /      \
     H01      H23
    /   \    /   \
   H0   H1  H2   H3
   |    |    |    |
  Ev0  Ev1  Ev2  Ev3

たとえばEv1の包含証明には、H0とH23のみが必要です。Ev0, Ev2, Ev3の内容は一切開示されません。これはプライバシーの観点から極めて重要です。

外部アンカリングが防止する3つの攻撃

攻撃	説明	防止メカニズム
バックデート	過去の日付でイベントを捏造	外部TSAのタイムスタンプと不整合
フォワードデート	未来の日付でイベントを捏造	外部TSAのタイムスタンプと不整合
ログフォーク	チェーンを分岐させて2つの歴史を作る	Merkleルートが1つしか存在しないことで検出

11. §8 Completeness Invariant：完全性不変条件

数学的定義

完全性不変条件はVAP/LAPの中核をなす設計原則です。

For each pipeline P:
  Count(P_ATTEMPT) = Count(P_SUCCESS)
                   + Count(P_DENY)
                   + Count(P_ERROR)

この数式が意味するのは、「AIに対するすべての試行（ATTEMPT）には、必ず1つの結果（成功・拒否・エラーのいずれか）が存在しなければならない」 ということです。

3つの強制される性質

性質	説明	違反が示すもの
完全性（Completeness）	すべてのATTEMPTに結果が存在する	イベントの欠落
一意性（Uniqueness）	各ATTEMPTに厳密に1つの結果が対応する	イベントの重複
参照整合性（Referential Integrity）	すべての結果イベントは発生元ATTEMPTへの因果リンクを含む	孤立イベント（Orphan）

選択的ログがなぜ「技術的に不可能」になるか

具体例で考えます。

弁護士AがAIに法律相談を送信 → LEGAL_QUERY_ATTEMPT が記録される（ATTEMPT = 1）
AIがハルシネーション（虚偽判例引用）を含む回答を生成 → LEGAL_QUERY_RESPONSE が記録される（RESPONSE = 1）
運用者が「この回答はまずい」と判断し、RESPONSEログを削除しようとする

削除した場合：ATTEMPT = 1、RESPONSE = 0、DENY = 0、ERROR = 0 → 不変条件が不成立（1 ≠ 0）

不変条件の検証は定期的に行われ、Silver以上では外部アンカリングにより「過去のある時点では不変条件が成立していた」ことが暗号学的に証明されています。したがって、不変条件の不成立は「その時点以降にログが改ざんされた」ことを意味します。

猶予期間（Grace Period）

実運用では、ATTEMPTの記録からRESPONSE/DENY/ERRORの記録までにタイムラグが発生し得ます（例：AIのAPI応答待ち）。そのため、検証は設定可能な猶予期間（grace period）を考慮すべき（SHOULD）とされています。猶予期間内のATTEMPTは「in-flight（処理中）」として扱われ、不変条件の計算から除外されます。

12. §9 Evidence Pack Specification：エビデンスパック

エビデンスパックとは

エビデンスパックは、アンカリング済み証跡を規制当局や第三者監査人への提出に適した自己完結型パッケージとして標準化したものです。

パック構造

エビデンスパックは以下のファイル群で構成されます（MUST）。

ファイル/ディレクトリ	説明
`manifest.json`	パックのメタデータと整合性情報
`events/`	イベントバッチ（1ファイル最大10,000件）
`anchors/`	外部アンカー記録
`merkle/`	Merkleツリー構造と選択的開示証明
`keys/`	署名検証用の公開鍵
`signatures/`	パックレベルの署名

マニフェスト（manifest.json）の構造

マニフェストには以下のフィールドが必須です。

フィールド	必要性	説明
pack_id	REQUIRED	UUIDv7によるパック一意識別子
vap_version	REQUIRED	VAPフレームワークバージョン（”1.2″）
profile	REQUIRED	プロファイルIDとバージョン（例：LAP v0.2）
conformance_level	REQUIRED	“Bronze” / “Silver” / “Gold”
generated_at	REQUIRED	パック生成日時（ISO 8601）
time_range	REQUIRED	パックがカバーする期間（start / end）
statistics	REQUIRED	total_events と events_by_type の内訳
completeness_verification	REQUIRED (Silver+)	invariant_type、invariant_valid（真偽値）、パイプライン別結果
integrity	REQUIRED	checksums（ファイルごとのSHA-256）、merkle_root、pack_hash
external_anchors	REQUIRED (Silver+)	この期間に対応するアンカー記録の配列

マニフェストにはプロファイル固有の追加フィールドを含めてもよい（MAY）とされており、LAPではOverride Coverageやファクトチェック率などのLAP固有メトリクスが追加されます。

13. §10 Privacy-Preserving Verification：プライバシー保護検証

VAP/LAPは、機密データを開示することなくシステムの整合性を検証する仕組みを提供します。これは以下の3つのメカニズムで実現されます。

メカニズム1：ハッシュベース証明（Hash-Based Attestation）

機密フィールドは暗号学的ハッシュとして保存されます。これにより、内容を開示することなく「そのデータが存在した」ことを証明できます。

例：弁護士の法律相談内容は PromptHash = sha256:a1b2c3... として記録される。第三者検証者はPromptHashの存在を確認できるが、質問の具体的内容は一切知ることができない。

メカニズム2：Merkle証明による選択的開示

Merkle包含証明により、エビデンスパック内の他のイベントを開示することなく、特定のイベントの存在を証明できます。これにより、規制当局が「特定の事件に関連するイベントのみ」を検証することが可能です。

メカニズム3：テナント別ソルト

ハッシュ計算にはテナントごとの個別ソルトを使用します。

def compute_prompt_hash(prompt_text: str, salt: str) -> str:
    salted = f"{salt}:{prompt_text}".encode('utf-8')
    return f"sha256:{hashlib.sha256(salted).hexdigest()}"

テナント間の相関攻撃（異なるテナントで同一の質問がされたことを、ハッシュ値の一致から推定する攻撃）を防止します。ソルトをテナント間で共有してはなりません（MUST NOT）。

注意：メタデータからの統計的情報漏洩

コンテンツがハッシュ化されていても、タイムスタンプ、イベント型、イベント数などのメタデータから統計的情報が漏洩する可能性があります。例えば「火曜日の午前中にLEGAL_QUERY_ATTEMPTが急増している」という情報から、「火曜日に大きな相談案件がある」ことが推測されるかもしれません。この点はSecurity Considerationsでも言及されています。

14. §11 Retention Framework：データ保持フレームワーク

保持期間要件

レベル	イベント	アンカー記録	エビデンスパック	鍵
Bronze	6ヶ月	N/A	オンデマンド	最終使用から1年
Silver	2年	5年	2年	最終使用から3年
Gold	5年	10年	5年	最終使用から7年

保持期間の延長

以下の場合、保持期間を延長しなければなりません（MUST）。

規制当局からの調査通知
訴訟ホールド（法的保全命令）
セキュリティまたは安全性のインシデント
第三者監査のリクエスト

Crypto-Shredding：GDPR「忘れられる権利」への対応

Silver以上の実装は、Crypto-Shreddingを実装すべき（SHOULD）です。Gold Level では REQUIRED です。

Crypto-Shreddingとは、個人データをユーザーごとの暗号鍵で暗号化しておき、削除リクエスト時にその鍵を破棄することで、データを暗号学的に復元不能にする手法です。ハッシュチェーンの整合性は保持しながら（ハッシュ値自体は変わらない）、実質的なデータ削除を実現します。

15. §12 Third-Party Verification Protocol：第三者検証プロトコル

3段階のアクセスレベル

レベル	アクセス範囲	検証スコープ	利用場面
Public	Merkleルートのみ	アンカーの存在確認	一般公開検証
Auditor	エビデンスパック	チェーン＋完全性の完全検証	年次監査
Regulator	リアルタイムAPI（Gold）	ライブモニタリング	規制当局調査

検証の5ステップ

Step 1: Anchor Verification（アンカー検証）
  └─ Merkleルートが外部TSA/透明性ログに存在することを確認

Step 2: Chain Verification（チェーン検証）
  └─ genesisから最新イベントまでのハッシュチェーン整合性を検証

Step 3: Signature Verification（署名検証）
  └─ すべてのイベントを公開鍵で認証

Step 4: Completeness Verification（完全性検証）
  └─ 対象期間の完全性不変条件を検証

Step 5: Selective Query（選択的クエリ・任意）
  └─ Merkle証明による特定イベントの検証

このプロトコルにより、第三者検証者はシステム運用者から独立して、以下を暗号学的に確認できます。

ログが改ざんされていないこと（Step 1-3）
ログが欠落していないこと（Step 4）
特定のイベントが確かに存在すること（Step 5）

16. §13 LAP Overview：Legal AI Profile概要

ここからPart II、LAP（Legal AI Profile）の解説に入ります。

LAPとは

LAPは、VAPの司法AIドメインプロファイルです。法律AIに固有の5つの課題を解決するために設計されています。

課題	説明	LAPによる解決
非弁行為リスク	AIが独立して法律事務を行っていないことの証明	HUMAN_OVERRIDEイベントによる弁護士精査の記録
ハルシネーション	AI生成文書の根拠不明性	LEGAL_FACTCHECKイベントによる出典チェーン検証
選択的ログ	都合の悪い生成の省略	3パイプライン完全性不変条件
守秘義務の緊張	外部API送信と弁護士法23条の緊張	プライバシー保護ハッシュフィールド
責任の曖昧性	「AIが言った」で終わる無責任構造	アカウンタビリティ層による「いつ・誰が・何を根拠に」の記録

プロファイル登録情報

フィールド	値
Profile ID	LAP
Full Name	Legal AI Profile
Domain	Legal AI / LegalTech
Regulatory Scope	Attorney regulation, AI governance（参考情報）
Time Precision	Second（秒精度）
Profile Version	0.2.0

VCP（金融）がナノ秒精度を要求するのに対し、LAPは秒精度で十分です。法律AIでは高頻度取引のようなマイクロ秒単位の操作は発生しません。

17. §14 LAP Event Type Taxonomy：LAPイベント型分類

LAPは3つの機能パイプラインと1つの横断的制御イベント型を定義します。

Pipeline 1：Legal Query（法律相談）

AI活用の法律相談機能に対応するパイプラインです。

イベント型	説明	AILEXでの対応
LEGAL_QUERY_ATTEMPT	AIへの質問送信	`POST /api/chat` 送信時
LEGAL_QUERY_RESPONSE	AI回答の正常生成	Claude API 応答成功時
LEGAL_QUERY_DENY	回答拒否（コンテンツフィルタ、権限不足）	Claude API コンテンツフィルタ発動時
LEGAL_QUERY_ERROR	システムエラー（API障害、タイムアウト）	Claude API エラー時

Pipeline 2：Document Generation（文書生成）

AI支援による法律文書ドラフト機能に対応するパイプラインです。

イベント型	説明	AILEXでの対応
LEGAL_DOC_ATTEMPT	文書生成リクエスト	`POST /generate` 送信時
LEGAL_DOC_RESPONSE	文書の正常生成	OpenAI API 応答成功時
LEGAL_DOC_DENY	生成拒否（同意不足、権限不足）	consent_scope チェック失敗時
LEGAL_DOC_ERROR	システムエラー（API障害、パースエラー）	OpenAI API エラー時

Pipeline 3：Fact Check（ファクトチェック）

AI活用の法律ファクト検証機能に対応するパイプラインです。

イベント型	説明	AILEXでの対応
LEGAL_FACTCHECK_ATTEMPT	ファクトチェックリクエスト	`POST /api/factcheck` 送信時
LEGAL_FACTCHECK_RESPONSE	ファクトチェック完了	Perplexity API 応答成功時
LEGAL_FACTCHECK_DENY	ファクトチェック拒否（OPTIONAL）	レート制限・権限不足時
LEGAL_FACTCHECK_ERROR	システムエラー	Perplexity API エラー時

LEGAL_FACTCHECK_DENYの特殊な扱い： Pipeline 3のDENYは任意実装（OPTIONAL）です。DENYを実装しない場合、拒否条件はLEGAL_FACTCHECK_ERRORとして記録し、エラー詳細にdeny_equivalent=trueフラグを設定しなければなりません（MUST）。これにより完全性不変条件が維持されます。

Cross-Cutting：HUMAN_OVERRIDE（弁護士精査）

HUMAN_OVERRIDEは3つのパイプラインを横断する制御イベントです。

精査種別	説明
APPROVE	弁護士がAI出力を修正なしで承認
MODIFY	弁護士がAI出力を修正して利用（修正内容のハッシュを記録）
REJECT	弁護士がAI出力を棄却

各HUMAN_OVERRIDEイベントには以下が含まれます。

target_event_id — 精査対象のAI出力イベントへの因果リンク
BarNumberHash — 弁護士登録番号のハッシュ値
override_type — APPROVE / MODIFY / REJECT
ModificationHash（MODIFYの場合）— 修正内容のハッシュ値

重要： HUMAN_OVERRIDEは完全性不変条件の外側に位置します。つまり、ATTEMPTに対する結果（RESPONSE/DENY/ERROR）とは別に、独立して記録されます。HUMAN_OVERRIDEの欠落は完全性不変条件違反を引き起こしませんが、Override Coverageメトリクスに反映されます。

18. §15 LAP Completeness Invariant：LAP完全性不変条件

LAPはVAPの完全性不変条件を3つのパイプラインに独立して適用します。

For each pipeline P in {QUERY, DOC, FACTCHECK}:

  Count(LEGAL_{P}_ATTEMPT)
  = Count(LEGAL_{P}_RESPONSE)
  + Count(LEGAL_{P}_DENY)    [if supported]
  + Count(LEGAL_{P}_ERROR)

展開形：

Pipeline 1: LEGAL_QUERY_ATTEMPT
  = LEGAL_QUERY_RESPONSE + LEGAL_QUERY_DENY + LEGAL_QUERY_ERROR

Pipeline 2: LEGAL_DOC_ATTEMPT
  = LEGAL_DOC_RESPONSE + LEGAL_DOC_DENY + LEGAL_DOC_ERROR

Pipeline 3: LEGAL_FACTCHECK_ATTEMPT
  = LEGAL_FACTCHECK_RESPONSE + LEGAL_FACTCHECK_DENY [optional] + LEGAL_FACTCHECK_ERROR

独立パイプラインの意味

3つのパイプラインが独立しているということは、以下を意味します。

Pipeline 1の完全性とPipeline 2の完全性はそれぞれ個別に検証できる
Pipeline 1に不整合があっても、Pipeline 2とPipeline 3の検証結果には影響しない
第三者検証者は「法律相談パイプラインの完全性」「文書生成パイプラインの完全性」「ファクトチェックパイプラインの完全性」を個別にレポートできる

参照整合性

すべての結果イベント（RESPONSE / DENY / ERROR）は、発生元のATTEMPTイベントの識別子への因果リンクフィールドを含まなければなりません（MUST）。これにより、参照整合性がイベントの順序に依存せず独立して検証可能になります。

19. §16 Override Coverage Metric：弁護士精査率メトリクス

計算式

Override Coverage =
  Count(HUMAN_OVERRIDE) /
  (Count(LEGAL_*_RESPONSE) + Count(LEGAL_*_DENY))

分母は「AI出力」の総数です。ここでERRORイベントは除外されます。ERRORはAI出力を生成しないため、弁護士が精査すべき対象ではないからです。ERRORの完全性はパイプラインごとの不変条件で別途評価されます。

評価基準

Coverage	評価	運用上の意味
100%	Ideal（理想）	すべてのAI出力を弁護士が精査
70-99%	Good（良好）	大多数を精査。低リスク出力は除外可能
30-69%	Warning（警告）	精査不足。運用改善を推奨
<30%	Critical（危機的）	弁護士精査義務を満たしていない可能性

法務省ガイドラインとの関係

法務省「AI等を用いた契約書等関連業務支援サービスの提供と弁護士法第72条との関係について」（2023年8月）は、以下の条件を示しています。

「サービスを弁護士又は弁護士法人に提供し、弁護士が自ら精査し、必要に応じて自ら修正を行う方法で利用するとき」は弁護士法72条に違反しない

Override Coverageは、この「弁護士が自ら精査」という要件の充足度を定量的に計測するメトリクスです。Override Coverage 100%は「すべてのAI出力を弁護士が精査している」ことの暗号学的な証拠となります。

20. §17 LAP Privacy-Preserving Fields：LAPプライバシー保護フィールド

法律AIが扱うデータは、弁護士・依頼者間の秘匿特権（Attorney-Client Privilege）によって保護されます。LAPはVAPのプライバシー保護検証を拡張し、以下の8種類のフィールドをハッシュ化します。

元データ	ハッシュフィールド	保護対象
ユーザーの質問文	PromptHash	法律相談内容（守秘義務対象）
AI回答文	ResponseHash	AI生成の法的アドバイス
生成文書	OutputHash	生成された法律文書
事件番号	CaseNumberHash	事件識別子（高い特定性）
弁護士登録番号	BarNumberHash	弁護士の専門家登録番号
当事者氏名	PartyHash	当事者の個人情報
修正内容	ModificationHash	弁護士による修正の詳細
ファクトチェック対象	TargetContentHash	検証対象のテキスト

第三者検証者が「できること」と「できないこと」

暗号学的に検証できること：

完全性（Completeness） — PromptHashの存在でATTEMPTの実在を確認（内容は見えない）
チェーン整合性 — ハッシュチェーンの連続性を検証
Override Coverage — HUMAN_OVERRIDEの数量を検証
出典の存在 — ファクトチェック結果の出典URLの存在を確認（法律内容の開示なし）

検証できないこと（意図的な設計）：

プロンプトの具体的内容
AI回答の具体的内容
事件の詳細情報
当事者の個人情報

これにより、弁護士法第23条の守秘義務を保持しながら、システムの健全性を第三者が検証可能となります。

21. §18 LAP Conformance Level Mapping：LAP適合性レベル

LAPはVAPの適合性レベルに、法律AI固有の要件を追加しています。

LAP適合性マトリクス

要件	Bronze	Silver	Gold
ハッシュチェーン	✅	✅	✅
電子署名	✅	✅	✅
外部アンカリング	—	✅ 日次	✅ 毎時
完全性不変条件	—	✅ 3パイプライン	✅ 3パイプライン
Override Coverage計測	—	✅	✅（アラート付き）
エビデンスパック	—	✅	✅
プライバシーハッシュ化	—	✅	✅
HSM	—	—	✅
データ保持期間	6ヶ月	3年	10年
リアルタイム監査API	—	—	✅

LAPの拡張保持期間

LAPはVAPの標準保持期間を拡張しています。

レベル	VAP標準	LAP拡張	拡張理由
Bronze	6ヶ月	6ヶ月（同一）	—
Silver	2年	3年	訴訟の出訴期限（消滅時効）
Gold	5年	10年	長期にわたる出訴期限への対応

民事訴訟の消滅時効は一般的に5年〜10年（権利の種類による）です。Goldレベルの10年保持は、最も長い出訴期限にも対応可能な設計です。

LAP固有の拡張機能（レベル別）

レベル	LAP固有拡張	説明
Bronze	基本イベントログ	全AI判断イベントの記録
Bronze	弁護士ロール検証	利用者が弁護士であることの検証ログ
Silver	3パイプライン完全性不変条件	3つのパイプライン独立の完全性保証
Silver	Override Coverage計測	弁護士精査率の計測
Silver	出典チェーン検証	ファクトチェック出典の暗号学的チェーン
Gold	リアルタイム精査率アラート	Override Coverage低下時の即時アラート
Gold	規制当局向け自動レポート生成	弁護士会・法務省向けの定期レポート
Gold	事件横断証跡分析	複数事件にまたがる証跡のクロス分析

22. §19 LAP Regulatory Alignment：LAP規制適合性

このセクションは完全に参考情報（Informative）であり、規範的（Normative）ではありません。 法的適合性の判断は管轄区域ごとに異なり、独立した法的分析が必要です。

弁護士専門家規制との対応

多くの法域では、法律事務を弁護士に限定しています。AIが弁護士を支援する場合、弁護士がAI出力を自ら精査し責任を負うことが求められます。

日本の法務省ガイドライン（2023年8月）の例：

ガイドラインの要件	LAP監査証跡の対応	支援メカニズム
利用者が弁護士であること	Actor.role + BarNumberHash	弁護士であることの検証記録
弁護士が自ら精査	HUMAN_OVERRIDE (APPROVE/MODIFY)	精査の暗号学的記録
必要に応じて自ら修正	ModificationHash	修正の暗号学的記録

高リスクAIシステムガバナンスとの対応

法律AIシステムは、EU AI Act Annex III「司法の運営（Administration of justice）」カテゴリに該当する可能性があります。LAP Silver以上は、以下の記録保持要件を支援するための監査証跡機能を提供します。

EU AI Act要件	LAP機能	適合性レベル
自動イベントログ（Article 12 ログ要件の支援）	イベント駆動アーキテクチャ	Bronze
ハッシュチェーンの連続性（生涯記録の支援）	ハッシュチェーン	Bronze
HUMAN_OVERRIDEイベント（人間による監視記録の支援）	弁護士精査イベント	Silver
イベント間の因果リンク（トレーサビリティの支援）	Causal Link	Silver

23. §20-§21 Security / IANA Considerations

Security Considerations（§20）

VAP/LAPは7つのセキュリティ検討事項を列挙しています。

脅威	説明	軽減策
鍵の漏洩	署名鍵が漏洩するとイベント偽造が可能	Bronze: 年次ローテーション。Silver: 半年次。Gold: HSM + 四半期ローテーション
ハッシュ衝突耐性	SHA-256は128ビットの衝突耐性を提供	現時点では十分。暗号アジリティによりポスト量子移行に備える
プライバシー漏洩	テナント別ソルトにより相関攻撃を防止	ソルトをテナント間で共有してはならない（MUST NOT）。メタデータからの統計的漏洩に注意
可用性攻撃	ログインフラへのDoS攻撃でイベント記録が阻害	Gold: 地理冗長性（MUST）
外部アンカー信頼	アンカリングサービスへの信頼依存	クリティカルなデプロイメントでは複数の独立サービスを使用（SHOULD）
完全性不変条件の回避	偽のERRORイベントを挿入して不変条件を満たしつつ実際の結果を隠蔽	Silver以上の外部アンカリングにより事後挿入が検出可能
時刻源の整合性	タイムスタンプのロールバックやクロックスキューによる誤検証	単調時刻源の使用を推奨（SHOULD）。外部アンカリングが独立した時間参照を提供

完全性不変条件の回避（Completeness Invariant Circumvention） は特に重要な攻撃シナリオです。イベントストアへの書き込みアクセスを持つ攻撃者が、偽のERRORイベントを挿入して不変条件（ATTEMPT = RESPONSE + DENY + ERROR）を算術的に満たしつつ、実際のRESPONSEを隠蔽する攻撃です。Silver以上の外部アンカリングは、「ある時点以降にイベントが追加された」ことを検出可能にすることで、この攻撃を軽減します。

IANA Considerations（§21）

現時点ではIANA（Internet Assigned Numbers Authority）への登録事項はありません。

将来のバージョンでは以下の登録が検討されています。

メディアタイプ登録： VAPエビデンスパックマニフェスト用のメディアタイプ application/vnd.vap.evidence-pack+json
IANAレジストリ： VAPドメインプロファイル識別子のレジストリ

現時点では、プロファイル識別子はVeritasChain Standards Organization（VSO）が管理しています。

24. 付録：ドメインプロファイル比較

Internet-Draftの付録（Appendix A）には、VAPの3つの運用中ドメインプロファイルの比較表が掲載されています。

比較項目	VCP（金融）	CAP（コンテンツ）	LAP（法律）
時間精度	ナノ秒	秒	秒
主要不変条件	SIG→ORD	GEN_ATTEMPT→GEN/DENY/ERROR	3パイプライン不変条件
固有機能	シグナル整合性	Safe Refusal (SRP)	Human Override Coverage
規制フォーカス	金融規制	コンテンツ規制	弁護士規制 + AIガバナンス
プライバシーモデル	取引データ	クリエイティブコンテンツ	弁護士・依頼者間秘匿特権
Gold保持期間	5年	5年	10年

LAPが他のプロファイルと決定的に異なるのは、Human Override Coverageという固有メトリクスの存在です。金融（VCP）では取引シグナルの整合性が、コンテンツ（CAP）では安全な拒否（Safe Refusal）が重要ですが、法律（LAP）では「弁護士がAI出力を精査した」という事実の暗号学的証明が最重要課題です。

また、LAPの保持期間（Gold: 10年）は他のプロファイル（5年）の2倍です。これは法律分野特有の長期出訴期限に対応するための設計です。

25. AILEXの実装：仕様から動くプロダクトへ

AILEX SaaS（https://users.ailex.co.jp）は、このVAP/LAP仕様のリファレンス実装です。AILEXが創業以来実践してきた設計思想は、VAP/LAPが標準化しようとしている「検証可能なAI」そのものです。

PIIMasker → LAPプライバシー保護フィールドの実装基盤

AILEXのPIIMaskerは、外部AI（Claude API、OpenAI API、Perplexity API）に送信する前に、依頼者の個人情報（氏名、住所、電話番号、メールアドレス等）を自動的にマスキングします。

これはLAPのプライバシー保護フィールド（PromptHash、PartyHash等）の「実装哲学」と同根です。LAPが「ログ内のデータをハッシュ化する」ことで守秘義務を保護するのに対し、PIIMaskerは「API送信前のデータをマスキングする」ことで守秘義務を保護します。両者は補完的な関係にあります。

AILEXの設計思想「依頼者への同意説明が必要となると弁護士事務所は使わない」は、まさにLAPのプライバシー保護設計と一致しています。

AIファクトチェック → LAP Pipeline 3（LEGAL_FACTCHECK）

AILEXのAIファクトチェック機能は、AI回答の正確性をPerplexity APIで独立検証し、出典URL付きで結果を表示します。調査した50社超のリーガルテックSaaSで、この機能を標準搭載しているのはAILEXだけでした（確信度99%）。

LAPのPipeline 3（LEGAL_FACTCHECK）は、このファクトチェック機能の証跡を暗号学的に記録するための仕様です。AILEXの実装がLAP仕様の設計を直接的にインスパイアしています。

監査ログ（AuditLogger） → LAPイベント記録基盤

AILEXのAuditLoggerは、すべての重要な操作（ログイン、文書生成、API呼び出し等）を記録しています。LAPのイベント記録基盤は、この監査ログを暗号学的に強化（ハッシュチェーン化、電子署名、外部アンカリング）したものです。

3つのAI API → LAPの3パイプライン

AILEXが使用する3つの外部AI APIは、LAPの3パイプラインに直接対応しています。

AILEX API	LAPパイプライン	用途
Anthropic Claude API	Pipeline 1: Legal Query	AI法律相談チャット
OpenAI GPT-4o API	Pipeline 2: Document Generation	AI文書生成（出典付き）
Perplexity API	Pipeline 3: Fact Check	AIファクトチェック

26. IETF標準化プロセスと今後のロードマップ

今回の提出の位置づけ

項目	値
ドラフト名	draft-ailex-vap-legal-ai-provenance-00
提出日	2026年2月14日
カテゴリ	Experimental
提出タイプ	Individual Submission
IESG状態	I-D Exists
ページ数	26ページ
セクション数	22セクション + 付録

ロードマップ

時期	マイルストーン	詳細
2026年2月	Internet-Draft -00 提出・公開	✅ 完了
2026年Q2	IETF会合での発表	コミュニティからのフィードバック収集
2026年8月	リビジョン（-01）提出	EU AI Act高リスク義務適用に合わせた改訂
2026年Q4	WG採択の提案	SCITT WG等への採択を提案
2027年以降	独立実装の獲得	AILEX以外の実装による相互運用性検証
将来	RFC発行	IETFの正式な標準として発行

IETF SCITT WGとの連携

IETFのSCITT（Supply Chain Integrity, Transparency, and Trust）ワーキンググループは、サプライチェーンの透明性と整合性に関する標準を策定しています。AILEXはすでにSCITT関連の関連ドラフトを提出済みです。

ドラフト	内容
draft-ailex-scitt-vcp	VCP（金融プロファイル）のSCITT統合
draft-ailex-scitt-refusal-events	安全な拒否イベントのSCITT統合
draft-ailex-vap-legal-ai-provenance	VAP/LAPフレームワーク全体（今回の提出）

VAP/LAPはこれらを統合する上位フレームワークとして位置づけられます。将来的にSCITT WGに採択された場合、ドラフト名は draft-ietf-scitt-vap-... に変更されます。

27. 「便利なAI」から「検証可能なAI」へ：AILEXのビジョン

リーガルテック市場では、「AIで書面を自動生成する」「AIで契約書をレビューする」といった「便利なAI」の競争が激化しています。しかし、AIの便利さには構造的な落とし穴があります。

AIが生成した文書が誤った判例を引用していた場合、それを誰が、いつ、どのように検証したのか。AIに送信された依頼者の秘密情報が、どこに、どのような形で処理されたのか。便利さを追求するだけでは、これらの問いに答えることができません。

AILEXは創業以来、「検証可能性」 をプロダクトの中核に据えてきました。

PIIMasker — 「AIが便利に動く」ためではなく、「依頼者情報がどう保護されたかを証明できる」ために設計
AIファクトチェック — 「AIが正しい」と信じるためではなく、「AIの回答を独立検証した証跡を残す」ために設計
監査ログ — 「操作履歴を残す」ためではなく、「すべてのAI判断を第三者が検証できる」ために設計

今回IETFに提出したVAP/LAPは、このビジョンをプロトコルレベルで標準化する試みです。AIの判断証跡をハッシュチェーンで連鎖させ、完全性不変条件で選択的ログを排除し、外部アンカリングで第三者検証を可能にする。AILEXが自社プロダクトで実践してきた「検証可能なAI」の設計思想を、特定のベンダーに依存しないオープンな国際標準として提案するものです。

AILEXは、AIの「便利さ」ではなくAIの「証明可能性」を提供します。 すべての生成は記録され、すべての判断は検証できる。

弁護士は依頼者の権利と自由を守る職業です。その弁護士が使うAIは、「便利だが中身がわからない」ものであってはなりません。「検証可能なAIリーガルOS」——AILEXはこのビジョンのもと、プロダクト開発と国際標準化の両面から、AIガバナンスの課題に取り組んでまいります。

仕様の全文

今回提出したInternet-Draftの全文は、IETF Datratrackerで公開されています。

IETF Datatracker： https://datatracker.ietf.org/doc/draft-ailex-vap-legal-ai-provenance/
テキスト版（26ページ）： draft-ailex-vap-legal-ai-provenance-00.txt
HTML版： draft-ailex-vap-legal-ai-provenance-00.html

ご質問・フィードバックは info@ailex.co.jp までお寄せください。

免責事項： AILEXのリーガルAI SaaSは弁護士の業務を支援するツールであり、弁護士法第72条に定める「法律事務」を行うものではありません。すべてのAI出力は弁護士自身が精査・修正した上で利用されることを前提としています。本記事のRegulatory Alignment（規制適合性）セクションは参考情報であり、法的助言ではありません。

AI AILEX AI判断証跡 IETF Internet-Draft LAP VAP VAP/LAP 司法AI 国際標準国際標準仕様

【施行まで残り3か月】mints実務を完全サポート — AILEX新機能「送達期限管理・手数料計算・当事者CSV・提出ステータス」を徹底解説

【世界初】なぜAILEXはIETFに技術仕様を提出したのか — リーガルテックAI分野で初のInternet-Draft、その背景と意義

はじめに

目次

1. IETFとInternet-Draftとは

IETFの役割

Internet-Draftの位置づけ

「Running Code」の原則

なぜ「Individual Submission」なのか

2. なぜ今この仕様が必要なのか

構造的課題：「信頼ベースのAIガバナンス」の限界

EU AI Actの要求と「規格の空白」

法律AI特有の5つの課題

3. 仕様の全体構成

Part I: VAP Framework（§1〜§12）

Part II: Legal AI Profile（§13〜§19）

その他

4. §1 Introduction：設計原則「Verify, Don’t Trust」

設計原則

スコープの意図的な限定

2部構成の設計

5. §2 Conventions and Definitions：用語体系

BCP 14準拠のキーワード

主要用語

6. §3 VAP Framework Architecture：6層アーキテクチャ

Layer 1：整合性層（Integrity Layer）

Layer 2：プロベナンス層（Provenance Layer）

Layer 3：アカウンタビリティ層（Accountability Layer）

Layer 4：トレーサビリティ層（Traceability Layer）

Layer 5：共通基盤（Common Infrastructure）

Layer 6：ドメインプロファイル層（Domain Profile Layer）

7. §4 Cryptographic Foundation：暗号基盤

アルゴリズム要件

ハッシュチェーン仕様

JSON正規化：RFC 8785

電子署名

数値エンコーディング規則

8. §5 Common Event Structure：共通イベント構造

9. §6 Conformance Levels：Bronze / Silver / Gold

Bronze Level（中小企業・初期導入向け）

Silver Level（エンタープライズ・規制産業向け）

Gold Level（高度規制産業向け）

10. §7 External Anchoring：外部アンカリング

外部アンカリングとは

アンカリングサービスの種類

Anchor Record Format

Merkleツリー構築

外部アンカリングが防止する3つの攻撃

11. §8 Completeness Invariant：完全性不変条件

数学的定義

3つの強制される性質

選択的ログがなぜ「技術的に不可能」になるか

猶予期間（Grace Period）

12. §9 Evidence Pack Specification：エビデンスパック

エビデンスパックとは

パック構造

マニフェスト（manifest.json）の構造

13. §10 Privacy-Preserving Verification：プライバシー保護検証

メカニズム1：ハッシュベース証明（Hash-Based Attestation）

メカニズム2：Merkle証明による選択的開示

メカニズム3：テナント別ソルト

注意：メタデータからの統計的情報漏洩

14. §11 Retention Framework：データ保持フレームワーク

保持期間要件

保持期間の延長

Crypto-Shredding：GDPR「忘れられる権利」への対応

15. §12 Third-Party Verification Protocol：第三者検証プロトコル

3段階のアクセスレベル

検証の5ステップ

16. §13 LAP Overview：Legal AI Profile概要

LAPとは

プロファイル登録情報

17. §14 LAP Event Type Taxonomy：LAPイベント型分類

Pipeline 1：Legal Query（法律相談）

Pipeline 2：Document Generation（文書生成）

Pipeline 3：Fact Check（ファクトチェック）

Cross-Cutting：HUMAN_OVERRIDE（弁護士精査）

18. §15 LAP Completeness Invariant：LAP完全性不変条件

独立パイプラインの意味

参照整合性

19. §16 Override Coverage Metric：弁護士精査率メトリクス