draft-ailex-vap-legal-ai-provenance-01 改訂報告書

-00 → -01 変更点・改善点の詳細

1. 改訂の経緯

1.1 -00の公開と反響

2026年2月13日（現地時間2月14日付）、AILEX Inc.は世界初の司法AI特化型Internet-Draftとして draft-ailex-vap-legal-ai-provenance-00（全26ページ）をIETF Datatrackerに公開した。本ドラフトは、AIが生成した法的判断の全プロセスに対し暗号学的に検証可能な証跡を提供するフレームワーク「VAP（Verifiable AI Provenance）」と、その司法AI領域のドメインプロファイル「LAP（Legal AI Profile）」を規定するものである。

公開後、以下の関係者から技術的・法的観点のフィードバックが寄せられた：

IETF技術コミュニティ — 暗号基盤設計、SCITTとの整合性、Privacy-Preserving Verificationの実装可能性に関する議論
技術者・セキュリティ専門家 — ログ保持設計の裁判所開示命令への耐性、Override Coverageの実効性、鍵管理モデルに関する技術的指摘
司法関係者（弁護士・法務実務家） — 弁護士の専門的裁量とシステム強制のバランス、日本の民事訴訟手続きにおける電子証拠の取扱い、弁護士法72条セーフハーバー要件の検証可能性に関する法的フィードバック

1.2 特定された2つの構造的課題

これらの議論を通じ、-00の設計に2つの重大な構造的課題が特定された。いずれもLAPの「Verify, Don’t Trust」原則の実効性に直結する問題であり、単なるバグフィックスではなく仕様のアーキテクチャレベルの改訂が必要と判断された。

課題A: ハッシュのみ保持と裁判所開示命令の矛盾

-00の設計: LAP Privacy-Preserving Verification（Section 17）において、プロンプト・AI回答・生成文書等のセンシティブデータをSHA-256ハッシュ化して保持し、原文は削除可能としていた。これは弁護士法23条（守秘義務）とプライバシー保護の観点からは正しい設計であった。

問題の本質: ハッシュは「整合性証明（このデータが改ざんされていないこと）」には有効だが、「内容の不存在証明（この内容のログは存在しないこと）」には不十分である。裁判所が「ログの全部開示」を命じた場合、ハッシュ値だけでは裁判所が証拠として採用しないケースが発生しうる。具体的には以下のシナリオが想定された：

民事訴訟における証拠保全命令（民事保全法24条）— AI生成文書の作成過程について相手方から証拠保全申立てがあった場合、ハッシュ値のみでは「内容を隠蔽している」との心証を裁判官に与えるリスク
弁護士懲戒手続き（弁護士法64条の7、時効なし）— AI出力を無精査で提出した疑いが生じた場合、「ハッシュチェーンは無傷です」という回答だけでは弁護士会の調査委員会を満足させられない
法務省調査（期間の定めなし）— 非弁行為（弁護士法72条違反）の疑義が生じた場合、AI相談内容の原文開示を求められる可能性

技術者からは「crypto-shredding（暗号鍵削除によるデータ無効化）は設計として正しいが、削除タイミングのポリシーが未定義」との指摘があり、司法関係者からは「日本の裁判実務では、電子データの存在を主張しながら内容を開示できないことは、文書提出命令違反（民事訴訟法224条）による不利な推定を招く」との法的見解が示された。

課題B: Override Coverageの強制力ゼロ

-00の設計: Section 16でOverride Coverageメトリクスを定義し、「弁護士がどの程度AI出力を精査しているか」を定量化していた。70%以上を「Good」、30%未満を「Critical」と評価するテーブルを提供していたが、これはあくまで「計測」であり、弁護士がAI出力をそのまま提出することをシステムが阻止する仕組みは存在しなかった。

問題の本質: Override Coverageが0%でもシステムは正常に動作する。これは「弁護士のモラル頼み」であり、LAP証跡は事後的に「精査していなかったことがバレやすくなる」効果はあるものの、「精査せずに使うことの事前防止」にはならない。

技術者からは「Completeness Invariantは試行と結果の対応を数学的に保証しているのに、HUMAN_OVERRIDEだけが完全にオプショナルなのはアーキテクチャの穴」との指摘があり、司法関係者からは「法務省ガイドラインの『弁護士が自ら精査し、必要に応じて自ら修正を行う』要件は、精査の証跡が存在しないこと自体がセーフハーバー逸脱を意味する。計測だけでなく、精査を促すシステム設計が必要」との見解が示された。

1.3 改訂方針

上記の課題を踏まえ、-01改訂では以下の方針を採用した：

プライバシー保護と司法開示義務の両立 — 単純な二者択一（「全部残す」vs「全部消す」）ではなく、時間経過に応じた段階的な保持モデルを導入する
専門家の裁量尊重と説明責任の強化 — 弁護士の専門的判断を否定する「全ブロック」ではなく、リスクに比例した段階的な摩擦と検知可能性を提供する
構造的限界の明示的承認 — 技術的に「完全な防止」が不可能であることを仕様上認めた上で、非遵守のコストと検知可能性を最大化する設計思想を明文化する
IETFドラフトとしての抽象度維持 — 特定の実装や法域に過度に依存する記述を避け、各実装者が法域固有の要件に適合できる柔軟性を保持する

2. ドキュメント全体の変更サマリー

2.1 数値比較

指標	-00	-01	差分
ページ数	26	33	+7
セクション数（トップレベル）	21 + Appendix 2	21 + Appendix 2	構造維持
サブセクション数	約30	約40	+10
テーブル数	7	10	+3
定義済み用語数	9	12	+3
イベントタイプ数	12	19	+7
Security Considerations項目数	7	11	+4
LAP Conformance Matrix行数	10	14	+4
LAP Profile Version	0.2.0	0.3.0	バージョンアップ

2.2 セクション対応表

-00 セクション	-01 セクション	変更種別
1. Introduction	1. Introduction	変更なし
1.1 Scope	1.1 Scope	変更なし
1.2 Design Philosophy	1.2 Design Philosophy	変更なし
2. Conventions and Definitions	2. Conventions and Definitions	拡張
2.1 Terminology	2.1 Terminology	3用語追加
3. VAP Framework Architecture	3. VAP Framework Architecture	変更なし
4. Cryptographic Foundation	4. Cryptographic Foundation	変更なし
5. Common Event Structure	5. Common Event Structure	変更なし
6. Conformance Levels	6. Conformance Levels	変更なし
7. External Anchoring	7. External Anchoring	変更なし
8. Completeness Invariant	8. Completeness Invariant	変更なし
9. Evidence Pack Specification	9. Evidence Pack Specification	拡張
9.2 Pack Manifest	9.2 Pack Manifest	2フィールド追加
10. Privacy-Preserving Verification	10. Privacy-Preserving Verification	変更なし
11. Retention Framework	11. Retention Framework	大幅拡張
（なし）	11.1 Content Retention Tiers	新設
（なし）	11.2 Legal Hold Protocol	新設
（なし）	11.3 Judicial Disclosure Response	新設
12. Third-Party Verification Protocol	12. Third-Party Verification Protocol	変更なし
13. LAP Overview	13. LAP Overview	微修正
13.1 Profile Registration	13.1 Profile Registration	バージョン更新
14. LAP Event Type Taxonomy	14. LAP Event Type Taxonomy	拡張
14.1-14.4	14.1-14.4	変更なし
（なし）	14.5 Retention and Enforcement Events	新設
15. LAP Completeness Invariant	15. LAP Completeness Invariant	変更なし
16. Override Coverage Metric	16. Override Coverage and Enforcement	大幅改訂
（なし）	16.1 Override Coverage Metric	再構成
（なし）	16.2 Enforcement Levels	新設
（なし）	16.3 Enforcement Level Mapping	新設
（なし）	16.4 Override Latency Threshold	新設
（なし）	16.5 Structural Limitation Acknowledgment	新設
17. LAP Privacy-Preserving Fields	17. LAP Privacy-Preserving Fields	微修正
18. LAP Conformance Level Mapping	18. LAP Conformance Level Mapping	拡張
19. LAP Regulatory Alignment	19. LAP Regulatory Alignment	拡張
20. Security Considerations	20. Security Considerations	大幅拡張
21. IANA Considerations	21. IANA Considerations	変更なし
22. References	22. References	変更なし
Appendix A. Profile Comparison	Appendix A. Profile Comparison	微修正
Appendix B. Change Log	Appendix B. Change Log	更新
Acknowledgments	Acknowledgments	更新

3. 変更点の詳細

3.1 【新設】Section 11.1: Content Retention Tiers（段階的内容保持モデル）

3.1.1 背景と動機

-00では、Privacy-Preserving Verification（Section 10/17）において「センシティブデータはハッシュ化して保持、原文は削除可能」という単一のモデルのみを提供していた。これは守秘義務保護には有効だが、裁判所開示命令に対しては「ハッシュしかないので内容を開示できない」という状況を生む。

技術者からの指摘：

「crypto-shredding自体は正しい設計パターンだが、いつ・どのような条件で削除に移行するかのポリシーが未定義。データのライフサイクル管理として不完全。」

司法関係者からの指摘：

「日本の民事裁判では、電子データの存在を認めながら内容開示を拒否した場合、民事訴訟法224条に基づき裁判所が不利な推定を行う可能性がある。ハッシュの存在は『データが存在した証拠』として機能するため、かえって逆効果になりうる。」

3.1.2 導入された設計

3段階の内容保持モデルを定義した：

Tier 1 — Full Content Retention（全文暗号化保持）

すべてのイベント内容（プロンプト、AI回答、生成文書）を暗号化した状態でプロベナンスハッシュとともに保持する。裁判所開示命令に対して即座に対応可能な状態である。保持期間はテナントごとに設定可能とした。

Tier 2 — Recoverable Hash Retention（復元可能ハッシュ保持）

原文は削除するが、内容復元鍵を指定されたカストディアン（管理弁護士、第三者エスクローサービス等）にエスクロー（預託）する。通常運用では内容にアクセスしないが、Legal Holdや裁判所命令が発動された場合にのみ、エスクローから復元鍵を取得して暗号化バックアップから内容を再構成できる。

Tier 3 — Hash-Only Retention（ハッシュのみ保持）

プロベナンスハッシュのみが残る。内容は暗号学的に復元不能（crypto-shredding完了）。-00の設計はこの段階のみを想定していた。

3.1.3 設計判断の根拠

Tier 2（Recoverable Hash）を中間層として導入した理由：

裁判所開示命令への耐性 — Tier 3（ハッシュのみ）の弱点を直接補完。裁判所命令時に「内容がない」と回答するリスクを劇的に軽減する
プライバシーとの両立 — 通常運用では内容にアクセスしない。復元は法的に正当な場合のみ
エスクロー方式の採用 — 復元鍵を第三者に預けることで、プラットフォーム運営者の単独判断での復元を防止。守秘義務の保護と開示義務の履行を構造的に分離する
Crypto-shreddingとの整合性 — Tier 3移行時に復元鍵も破壊することで、最終的なプライバシー保護は維持される
IETFドラフトとしての抽象度 — エスクローの具体的実装（Multi-party threshold、HSM escrow、Split key等）には踏み込まず、「designated custodian」という抽象的な表現を採用。法域によってエスクローの法的要件が異なる（日本の弁護士法23条の2 vs EU GDPRのDPO制度）ことを考慮した

3.1.4 Tier遷移の制約

Tier 1 → Tier 2 への遷移は、対象イベントに対してLegal Holdがアクティブでない場合のみ許可
Tier 2 → Tier 3 への遷移は、対象イベントに対してLegal Holdがアクティブでない場合のみ許可
すべてのTier遷移はRETENTION_TIER_CHANGEイベントとしてプロベナンスチェーンに記録される（改ざん不能）

3.2 【新設】Section 11.2: Legal Hold Protocol（リーガルホールドプロトコル）

3.2.1 背景と動機

-00では、Retention Framework（Section 11）において保持期間の延長トリガーとして「regulatory investigation notification, legal hold orders, security or safety incidents, and third-party audit requests」を列挙していたが、Legal Holdの発動・解除・影響範囲を定義するプロトコルは存在しなかった。

IETF技術者からの指摘：

「保持期間延長のトリガーは書いてあるが、発動後に何が起きるかが未定義。Legal Holdの発動がプロベナンスチェーンに記録されないなら、Hold自体の存在が改ざんされうる。」

3.2.2 導入された設計

Legal Holdを正式なプロトコルとして定義した。5つのトリガータイプを規定：

Court Order（裁判所命令）— 裁判所による証拠保全命令
Regulatory Investigation（規制当局調査）— 政府機関による規制調査
Litigation Hold（訴訟ホールド）— 合理的に予見される訴訟
Professional Body Inquiry（専門職団体照会）— 弁護士会等からの照会
Disciplinary Proceedings（懲戒手続き）— 専門職の懲戒手続き

Legal Hold発動時の必須動作：

対象イベントの保持Tierを凍結（Tier遷移をブロック）
LEGAL_HOLD_ACTIVATEDイベントをプロベナンスチェーンに記録（hold_id, hold_trigger, scope, activated_by, activation_timestamp）
Legal Holdの解除にはLEGAL_HOLD_RELEASEDイベントの記録が必要
Hold期間中に生成されるEvidence PackにLegal Hold情報を含める

3.2.3 コンフォーマンスレベルとの関係

Bronze: Legal Hold対応は手動で必須（MUST）
Silver: Legal Hold対応は手動で必須（MUST）
Gold: 自動Legal Hold検知（裁判所通知やAPI連携による自動発動）を推奨（RECOMMENDED）

3.3 【新設】Section 11.3: Judicial Disclosure Response（司法開示対応手順）

3.3.1 背景と動機

段階的内容保持モデル（Section 11.1）とLegal Holdプロトコル（Section 11.2）を導入したことで、「裁判所が内容開示を命じたとき、各Tierでどのように対応するか」を明示的に定義する必要が生じた。

3.3.2 導入された設計

裁判所または規制当局が特定イベントの内容開示を命じた場合の対応手順を、Tierごとに定義：

Tier 1のイベント: 内容は暗号化形式で利用可能。適切なアクセス制御と弁護士による確認を経て開示可能。

Tier 2のイベント: エスクローから内容復元鍵を取得。暗号化バックアップから内容を再構成。CONTENT_RECOVERY_EXECUTEDイベントを記録。復元プロセス自体がプロベナンスチェーンに記録されるため、「いつ・誰が・何の目的で復元したか」が検証可能。

Tier 3のイベント: 内容は暗号学的に復元不能。この場合、実装は以下を提供しなければならない（MUST）：

ハッシュチェーン整合性証明（プロベナンスが途切れていないことの証明）
Tier遷移ログ（いつ・なぜ内容が削除されたかの記録）
削除時点でLegal Holdがアクティブでなかったことの証明
統計メタデータ（トークン数、タイムスタンプ、イベントタイプ等）

3.3.3 設計思想

この3段階対応手順の設計思想は、「裁判所に対して、内容削除が計画的・監査可能なプロセスに基づいて実行されたことを証明する」ことにある。これにより、Tier 3（ハッシュのみ）の状態であっても、evidence spoliation（証拠隠滅）の疑いを軽減できる。

なお、「ハッシュのみ証拠が特定の司法手続きにおいて十分か否か」は法域固有の法的判断であり、本仕様のスコープ外であることを明記した。技術仕様は各保持段階で利用可能な最大限の技術的証拠を提供するにとどまる。

3.4 【大幅改訂】Section 16: Override Coverage → Override Coverage and Enforcement

3.4.1 改訂の全体像

-00のSection 16は「Override Coverage Metric」のみを規定する短いセクション（約1ページ）であった。-01では、これを「Override Coverage and Enforcement」として5つのサブセクションに拡張し、計測に加えて段階的な強制メカニズムを導入した（約3ページ）。

要素	-00	-01
Override Coverage計算式	✅	✅（16.1で維持）
Coverage評価テーブル	✅	✅（16.1で維持）
Enforcement Levels	❌	✅（16.2で新設：4段階）
Enforcement Level Mapping	❌	✅（16.3で新設）
Override Latency Threshold	❌	✅（16.4で新設）
構造的限界の明示的承認	❌	✅（16.5で新設）

3.4.2 【新設】Section 16.2: Enforcement Levels（段階的強制メカニズム）

-00の「計測のみ」モデルに対し、4段階の強制レベルを導入した：

Level 0 — Metric Only（計測のみ） -00と同等。Override Coverageを計算・報告するが、強制アクションは取らない。弁護士の倫理的義務に依存する。

Level 1 — Warn（警告） ユーザーがHUMAN_OVERRIDEイベントが存在しないAI出力をエクスポート・コピー・送信しようとした場合、システムは目立つ警告を表示しなければならない（MUST）。警告は以下を満たす必要がある：

エクスポート/コピーアクションの実行時点で、コンテキスト内に表示される
続行する前に明示的な確認（acknowledgment）を要求する
REVIEW_WARNING_ACKNOWLEDGEDイベントをプロベナンスチェーンに記録する

Level 2 — Gate（ゲート） 指定された高リスク文書タイプについて、HUMAN_OVERRIDEイベントが存在しない限りエクスポートや送信をブロックする（MUST）。ブロック時にはREVIEW_GATE_BLOCKEDイベントを記録する。ただし、「attorney」ロールを持つユーザーによる明示的なオーバーライド（理由記載必須のREVIEW_GATE_OVERRIDEイベント付き）でのバイパスを許可する。

デフォルトのゲート対象文書タイプ（テナントごとに設定変更可能）：

裁判所提出書類（準備書面、申立書、上申書等）
和解・調停文書
クライアント向け法律意見書
契約書・合意書

Level 3 — Strict（厳格） すべてのAI生成出力に対してHUMAN_OVERRIDEを必須とする。バイパスメカニズムなし。最大限のコンプライアンスを求める環境向けだが、ワークフロー効率への影響を考慮し、本仕様では義務付けない（OPTIONAL）。

3.4.3 Enforcement Level Mapping

コンフォーマンスレベルとの対応関係を定義：

Enforcement Level	Bronze	Silver	Gold
Level 0（Metric Only）	デフォルト	最低ライン	N/A
Level 1（Warn）	OPTIONAL	REQUIRED	REQUIRED
Level 2（Gate）	N/A	RECOMMENDED	RECOMMENDED
Level 3（Strict）	N/A	OPTIONAL	OPTIONAL

Silver以上でLevel 1が必須となることで、-00の「完全にオプショナル」な状態から「少なくとも警告は出る」状態に引き上げた。これにより、「精査なしの出力利用」が意図的な行為であることの証跡が確実に残る。

3.4.4 【新設】Section 16.4: Override Latency Threshold（精査時間閾値）

司法関係者からの以下のフィードバックを反映した：

「Override Coverageが100%でも、弁護士が0.5秒で全部APPROVEしていたら意味がない。形式的な精査と実質的な精査を区別する仕組みが必要。」

Override Latency（精査遅延）メトリクスを定義：

Override Latency = HUMAN_OVERRIDE.timestamp - target_output_event.timestamp

Silver以上の実装は、設定可能な閾値（デフォルト推奨値：10秒）未満のHUMAN_OVERRIDEイベントを「rapid approval（迅速承認）」としてフラグ付けすべきとした（SHOULD）。

このフラグ（RAPID_APPROVAL_FLAG）は：

Evidence PacksおよびAudit Reportに表示される
精査深度の不足を示唆する可能性がある
Gold レベルでは、迅速承認の割合が設定可能な閾値（推奨：20%）を超えた場合にアラートを発動可能

重要な設計判断として、このフラグはオーバーライドをブロックしない。あくまでメタデータとして記録し、事後の監査で検出可能にする。これは弁護士の専門的裁量を尊重しつつ、形式的承認のパターンを検知するバランスである。

3.4.5 【新設】Section 16.5: Structural Limitation Acknowledgment（構造的限界の明示的承認）

-01で最も重要な哲学的追加。技術者と司法関係者の双方からの議論を踏まえ、以下を仕様上で明示的に承認した：

「いかなる技術的メカニズムも、人間の専門家による精査の品質や深度を完全に保証することはできない。」

弁護士は、AI出力を本当に精査した後にAPPROVEすることも、ざっと見ただけでAPPROVEすることも可能であり、システムはこれを区別できない（区別しようとすれば、専門家の判断に対する受け入れがたい監視を導入することになる）。

この限界を認めた上で、Enforcement Frameworkの目標を以下のように明文化した：

摩擦の創出 — 完全に未精査のAI出力利用に対する抵抗を作る
監査可能な証拠 — 精査（またはその欠如）の監査可能な証拠を提供する
リスク比例的な制御 — 高リスク文書タイプに対してより強い制御を適用する
専門家の自律性の保持 — 説明責任メタデータを記録しながら、専門家の自律性を維持する

この組み合わせにより、説明責任モデルは「信頼のみ（trust alone）」から「検証インフラを伴う信頼（trust with verification infrastructure）」に移行する。絶対的な防止は不可能だが、非遵守のコストと検知可能性を大幅に向上させることができる。

この明示的承認を仕様に含めた理由:

技術者の指摘：

「仕様が『Override Enforcement Level 2でゲートする』と書いてあると、実装者は『これで完全に防げる』と誤解する。スクリーンキャプチャや手動転記でいくらでもバイパスできることを明記すべき。」

司法関係者の指摘：

「弁護士の独立性（弁護士法1条2項）は、AIツールが弁護士の判断を制限することへの法的リスクがある。『あくまで摩擦と検知であり、判断の制限ではない』ことを仕様レベルで宣言することは、法的安全性の観点からも重要。」

なぜLevel 3（全ブロック）をデフォルトにしないのか:

弁護士の専門的裁量の尊重 — 弁護士は自らの判断で低リスク出力の精査を省略する権利を有する。全ブロックはこの裁量を否定する
ワークフロー効率 — 内部メモや草案段階の文書まで全て精査必須にすると、AI導入のメリットが大幅に減少する
IETFドラフトとしての汎用性 — 各法域・事務所の運用ポリシーに委ねるべき部分まで仕様で強制するのは過剰
技術的限界 — スクリーンキャプチャ等のバイパス手段がある以上、「完全防止」は技術的に不可能。摩擦を増やし検知可能性を高める方が現実的

3.5 【新設】Section 14.5: Retention and Enforcement Events（保持管理・強制イベントタイプ）

3.5.1 背景

段階的内容保持モデル（Section 11.1-11.3）とOverride Enforcement Framework（Section 16.2-16.5）の導入に伴い、これらの操作を記録する専用イベントタイプが必要になった。

3.5.2 新規イベントタイプ一覧

イベントタイプ	カテゴリ	説明	主要フィールド
RETENTION_TIER_CHANGE	保持管理	内容保持Tierの遷移を記録	previous_tier, new_tier, affected_event_range, reason, authorized_by
LEGAL_HOLD_ACTIVATED	保持管理	Legal Holdの発動を記録	hold_id, hold_trigger, scope, activated_by
LEGAL_HOLD_RELEASED	保持管理	Legal Holdの解除を記録	hold_id, released_by, release_reason
CONTENT_RECOVERY_EXECUTED	保持管理	Tier 2エスクローからの内容復元を記録	hold_id, recovered_event_range, recovered_by, court_order_reference_hash
REVIEW_WARNING_ACKNOWLEDGED	強制管理	未精査警告の確認を記録	target_event_id, warning_type, acknowledged_by
REVIEW_GATE_BLOCKED	強制管理	HUMAN_OVERRIDE欠如によるエクスポートブロックを記録	target_event_id, document_type, blocked_action
REVIEW_GATE_OVERRIDE	強制管理	精査ゲートの明示的バイパスを記録	target_event_id, override_reason, overridden_by

3.5.3 Completeness Invariantとの関係

これら7つの新規イベントタイプは、3パイプラインCompleteness Invariantの対象外である。HUMAN_OVERRIDEと同様、制御/管理イベントとして分類される。ただし、ハッシュチェーンへの包含と電子署名は必須（MUST）である。これにより、イベント自体の改ざん不能性は保証される。

3.5.4 -00からの総イベントタイプ数の変化

カテゴリ	-00	-01	変更
ATTEMPT（試行）	3	3	変更なし
OUTCOME-SUCCESS	3	3	変更なし
OUTCOME-DENY	2（+1 OPTIONAL）	2（+1 OPTIONAL）	変更なし
OUTCOME-ERROR	3	3	変更なし
CONTROL	1（HUMAN_OVERRIDE）	1（HUMAN_OVERRIDE）	変更なし
RETENTION管理	0	4	+4
ENFORCEMENT管理	0	3	+3
合計	12	19	+7

3.6 【拡張】Section 9.2: Evidence Pack Manifest追加フィールド

3.6.1 変更内容

Pack Manifestに以下の2つのフィールドを追加（いずれもSilver以上のLAP実装でREQUIRED）：

retention_status:

{
  "events_at_tier1": 5000,
  "events_at_tier2": 8000,
  "events_at_tier3": 2000,
  "active_legal_holds": [
    {
      "hold_id": "UUIDv7",
      "hold_trigger": "court_order",
      "scope": "case_id:15"
    }
  ]
}

enforcement_metrics:

{
  "enforcement_level": 1,
  "warnings_issued": 42,
  "gates_blocked": 8,
  "gates_overridden": 2,
  "rapid_approvals": {
    "count": 15,
    "percentage": 3.2
  }
}

3.6.2 設計理由

Evidence Packは第三者監査用のパッケージであり、「このテナントがどの程度真剣にデータ保持と精査義務に取り組んでいるか」を定量的に示す指標が含まれるべきである。retention_statusにより保持ポリシーの実態が、enforcement_metricsにより精査強制の運用実態が可視化される。

3.7 【拡張】Section 18: LAP Conformance Level Mapping

3.7.1 変更内容

LAP Conformance Matrixに以下4行を追加：

要件	Bronze	Silver	Gold
Override Enforcement Level	Level 0	Level 1（REQUIRED）	Level 1（REQUIRED）
Content Retention Tiers	Tier 3 only	Tier 2 + Tier 3	All 3 Tiers
Legal Hold Protocol	Yes (manual)	Yes (manual)	Yes (automated detection)
Content Recovery Escrow	No	RECOMMENDED	REQUIRED

3.7.2 影響

この追加により、LAP Silver認証を取得するためには、Override Enforcement Level 1（警告）とTier 2（Recoverable Hash Retention）が最低限必要となる。-00ではSilver認証に精査強制も段階的保持も不要であったため、認証要件が実質的に引き上げられた。

3.8 【拡張】Section 20: Security Considerations

3.8.1 追加された4項目

Content Retention and Discovery Risk（内容保持と開示リスク）: Privacy-Preservingなハッシュのみ保持と司法開示義務の緊張関係を明記。Tiered Retentionモデルが発見可能性の高い期間に復元可能な内容を維持すること、Legal Holdプロトコルが訴訟予見時に早期の内容破壊を防止することを記述。

Override Enforcement Circumvention（精査強制の回避）: Enforcement Level 1および2は、スクリーンキャプチャや手動転記等のシステム外手段でバイパス可能であることを明記。技術的強制はシステム経由のエクスポートという一般的なケースに対処するが、すべての回避手段を防止することはできない。プロベナンスチェーンにHUMAN_OVERRIDEイベントが存在しないことが事後的な説明責任を提供する。

Rapid Approval Gaming（迅速承認のゲーミング）: Override Latency閾値を認識したユーザーが、RAPID_APPROVAL_FLAGを回避するために承認クリックを意図的に遅延させる可能性がある。これは既知の限界である。ユーザーおよび文書タイプ横断の承認遅延分布の統計分析により、このようなゲーミングパターンを監査レビューで検出できる。

Legal Hold Integrity（リーガルホールドの完全性）: Legal Holdの発動・解除イベントは不正な変更から保護されなければならない。Gold レベルの実装ではLegal Hold解除にマルチパーティ認可を要求すべき（SHOULD）。

3.9 【拡張】Section 2.1: Terminology

3.9.1 追加された3用語

用語	定義
Content Retention Tier	保持ライフサイクルの各時点におけるイベント内容の可用性を定義する3つのレベル（Full Content、Recoverable Hash、Hash-Only）のいずれか
Legal Hold	訴訟、調査、または規制照会の期間中、スコープ内のイベントの現在の保持Tierを凍結し、内容削除やTier遷移を防止する指令
Override Enforcement Level	HUMAN_OVERRIDEイベントが欠如するAI出力に対してシステムがどのように応答するかを規定する、4段階の制御レベル（Metric Only、Warn、Gate、Strict）のいずれか

3.10 その他の変更

3.10.1 Section 13: LAP Overview

LAP Overviewの課題リストにおいて：

「Attorney-Client Privilege」の説明に「tiered content retention with legal hold support」を追記
「Accountability Ambiguity」の説明に「graduated override enforcement」を追記

3.10.2 Section 13.1: Profile Registration

LAP Profile Versionを 0.2.0 → 0.3.0 に更新。

3.10.3 Section 17: LAP Privacy-Preserving Fields

末尾に以下の段落を追加：

「これらのハッシュに対応する原文の可用性は、現在のContent Retention Tier（Section 11.1）に依存する。Tier 1では原文が暗号化形式で利用可能、Tier 2ではエスクロー鍵による復元が可能、Tier 3ではハッシュのみが残る。」

これにより、Privacy-Preserving FieldsとTiered Retentionの関係が明確化された。

3.10.4 Section 19: LAP Regulatory Alignment

Section 19.1（Attorney Professional Regulation）のLAP audit trail項目リストに以下を追記：

「Enforcement Level 1/2: provides system-level friction against use of unreviewed outputs」
「Override Latency monitoring: flags potentially insufficient review」

Section 19.2（High-Risk AI System Governance）の項目リストに以下を追記：

「Tiered content retention with legal hold (supports discovery obligations under Article 12 and national procedural law)」

3.10.5 Appendix A: Profile Comparison

LAP列の以下を修正：

「Unique Feature」: Human Override Coverage → Human Override Coverage + Enforcement
「Privacy Model」: Professional privilege → Professional privilege + Tiered Retention

3.10.6 Appendix B: Change Log

-01の全変更点を記載するChange Logエントリを追加。

3.10.7 Acknowledgments

LAP v0.3の設計への貢献として「operational feedback from pilot law firms regarding judicial discovery and attorney oversight workflows」を追記。

3.10.8 Abstract

LAP固有の要件リストに以下を追加：

「tiered content retention with legal hold protocols for judicial discovery compliance」
「graduated override enforcement mechanisms」

4. 未変更セクションの確認

以下のセクションは-00から変更なし。これは、VAP Part I（フレームワーク共通部分）の安定性を維持し、-01の変更をLAP固有の拡張に集中させる意図的な判断である：

セクション	内容	変更なし理由
1. Introduction	導入、スコープ、設計哲学	基本思想に変更なし
3. VAP Framework Architecture	レイヤーモデル、ドメインプロファイル	VAP共通部分の安定性維持
4. Cryptographic Foundation	アルゴリズム要件、ハッシュチェーン、署名	暗号基盤に変更なし
5. Common Event Structure	共通イベント構造、数値エンコーディング	VAP共通部分の安定性維持
6. Conformance Levels	Bronze/Silver/Gold基本定義	VAP共通部分の安定性維持
7. External Anchoring	アンカリングサービス、Merkleツリー	将来のSCITT統合強化は-02以降
8. Completeness Invariant	完全性不変条件の一般形	数学的定義に変更なし
10. Privacy-Preserving Verification	プライバシー保護検証の基本原則	原則は維持、Tiered Retentionが補完
12. Third-Party Verification Protocol	第三者検証プロトコル	手順に変更なし
15. LAP Completeness Invariant	LAP 3パイプライン不変条件	不変条件自体に変更なし
21. IANA Considerations	IANA登録事項	変更なし
22. References	参照文献	新規参照の追加なし

5. 今後の展望（-02以降の検討事項）

-01改訂のレビューを通じ、以下の3点が「現段階では対応不要だが将来的に検討すべき事項」として特定された。いずれも-01に含めるには時期尚早であり、IETFドラフトの段階的成熟プロセスに沿って-02以降で検討する。

5.1 SCITTアーキテクチャとの関係強化

Section 7.1で「Transparency Log (e.g., IETF SCITT)」と言及しているが、SCITTのReceipt構造（COSE Sign1ベース）とVAP Anchor Recordの具体的な対応関係は未定義。SCITT自体がまだWorking Group draftであるため、現段階で深く結合するとSCITTの仕様変更に引きずられるリスクがある。SCITTが安定した段階でのAlignment Appendix追加を検討する。

5.2 Escrowモデルの具体化

Section 11.1 Tier 2の「designated custodian」は意図的に抽象的な表現としている。Multi-party threshold（Shamir’s Secret Sharing等）、HSM escrow、Split key等の具体的実装パターンについて、将来的にInformative Appendixとして「Escrow Implementation Patterns」を追加する可能性がある。ただし、法域によってエスクローの法的要件が異なるため、IETFドラフト本文では抽象度を維持する。

5.3 VAP meta-architectureとしての独立化

現行の1ドキュメント構成（VAP Part I + LAP Part II）を将来的に2つの独立ドラフトに分離する可能性がある。VAPを独立した上位フレームワーク（draft-ailex-vap-framework）、LAPを別ドラフト（draft-ailex-lap-legal-ai）とすることで、VAPは「複数プロファイルを束ねるmeta-architecture」として独立した存在感を持つ。分離のタイミングはIETFでのBOF/WG議論の進展に合わせて判断する。

6. ファイル一覧

ファイル名	形式	用途
`draft-ailex-vap-legal-ai-provenance-01.xml`	XML（xml2rfc v3）	ソースファイル。今後の修正はこれを編集
`draft-ailex-vap-legal-ai-provenance-01.txt`	プレーンテキスト	IETF Datatracker提出用
`draft-ailex-vap-legal-ai-provenance-01.html`	HTML	レビュー・閲覧用

提出先: https://datatracker.ietf.org/submit/
提出前チェック: https://author-tools.ietf.org/ （idnits検証）

AILEX Inc.
〒150-0043 東京都渋谷区道玄坂1-10-8 渋谷道玄坂東急ビル
Email: info@ailex.co.jp
URI: https://ailex.co.jp

End of Change Report: draft-ailex-vap-legal-ai-provenance-00 → 01

AI AILEX AILEX Inc.Completeness Invariant crypto-shredding IETF Internet-Draft LAP Legal AI Profile Override Coverage VAP Verifiable AI Provenance 司法AI 暗号学的証跡証拠保全命令護士法電子証拠

「使いにくい」を、翌日には直す — AILEX に管理者直通ホットラインを設置しました

「事務員を雇うか、AILEXを入れるか」── 3人の弁護士が選んだ答え

-00 → -01 変更点・改善点の詳細

1. 改訂の経緯

1.1 -00の公開と反響

1.2 特定された2つの構造的課題

課題A: ハッシュのみ保持と裁判所開示命令の矛盾

課題B: Override Coverageの強制力ゼロ

1.3 改訂方針

2. ドキュメント全体の変更サマリー

2.1 数値比較

2.2 セクション対応表

3. 変更点の詳細

3.1 【新設】Section 11.1: Content Retention Tiers（段階的内容保持モデル）

3.1.1 背景と動機

3.1.2 導入された設計

3.1.3 設計判断の根拠

3.1.4 Tier遷移の制約

3.2 【新設】Section 11.2: Legal Hold Protocol（リーガルホールドプロトコル）

3.2.1 背景と動機

3.2.2 導入された設計

3.2.3 コンフォーマンスレベルとの関係

3.3 【新設】Section 11.3: Judicial Disclosure Response（司法開示対応手順）

3.3.1 背景と動機

3.3.2 導入された設計

3.3.3 設計思想

3.4 【大幅改訂】Section 16: Override Coverage → Override Coverage and Enforcement

3.4.1 改訂の全体像

3.4.2 【新設】Section 16.2: Enforcement Levels（段階的強制メカニズム）

3.4.3 Enforcement Level Mapping

3.4.4 【新設】Section 16.4: Override Latency Threshold（精査時間閾値）

3.4.5 【新設】Section 16.5: Structural Limitation Acknowledgment（構造的限界の明示的承認）

3.5 【新設】Section 14.5: Retention and Enforcement Events（保持管理・強制イベントタイプ）

3.5.1 背景

3.5.2 新規イベントタイプ一覧

3.5.3 Completeness Invariantとの関係

3.5.4 -00からの総イベントタイプ数の変化

3.6 【拡張】Section 9.2: Evidence Pack Manifest追加フィールド

3.6.1 変更内容

3.6.2 設計理由

3.7 【拡張】Section 18: LAP Conformance Level Mapping

3.7.1 変更内容

3.7.2 影響

3.8 【拡張】Section 20: Security Considerations

3.8.1 追加された4項目

3.9 【拡張】Section 2.1: Terminology

3.9.1 追加された3用語

3.10 その他の変更

3.10.1 Section 13: LAP Overview

3.10.2 Section 13.1: Profile Registration

3.10.3 Section 17: LAP Privacy-Preserving Fields

3.10.4 Section 19: LAP Regulatory Alignment

3.10.5 Appendix A: Profile Comparison

3.10.6 Appendix B: Change Log

3.10.7 Acknowledgments

3.10.8 Abstract

4. 未変更セクションの確認

5. 今後の展望（-02以降の検討事項）

5.1 SCITTアーキテクチャとの関係強化

5.2 Escrowモデルの具体化

5.3 VAP meta-architectureとしての独立化

6. ファイル一覧

コメント

関連記事

AIが弁護士業務に入り込む時代、「証明できないAI」は許されるのか ── draft-ailex-vap-legal-ai-provenance-00 徹底解説

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

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

AIが弁護士業務を支援するとき、「説明責任」をどう証明するか — EU AI Act・弁護士法とAILEXの規制マッピング完全解説