【AILEX】IETFにAI判断証跡の国際標準仕様「VAP/LAP」を提出しました

AILEXは、AI判断の証跡（プロベナンス）を暗号学的に検証可能にする技術仕様「VAP/LAP」を、インターネットの国際標準化団体 IETF（Internet Engineering Task Force） にInternet-Draftとして提出し、正式に公開されました。

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

本記事では、なぜこの技術仕様が必要なのか、何を定義しているのか、そしてこれがリーガルテック業界にどのような意味を持つのかを詳しく解説します。

IETFとは何か

IETFは、TCP/IP、HTTP、TLS（HTTPS）、DNS、電子メールなど、私たちが日常的に使うインターネットの基盤技術を策定してきた国際標準化団体です。「RFC（Request for Comments）」と呼ばれる技術仕様書を発行し、インターネットのプロトコルを定義しています。

IETFの標準化プロセスは、まず「Internet-Draft（I-D）」と呼ばれる草案を提出するところから始まります。今回AILEXが提出したのはこのInternet-Draftです。ここからレビュー、議論、改訂を経て、最終的にRFCとして標準化されることを目指します。

IETFが重視する原則の一つに「Running Code（動くコード）」があります。仕様だけでなく、実際に動く実装が存在することが重要視される文化です。AILEXのSaaS（https://users.ailex.co.jp）が、このVAP/LAP仕様のリファレンス実装として稼働していることは、IETF標準化プロセスにおいて大きな意味を持ちます。

なぜ「検証可能なAI」が必要なのか

信頼ベースのAIガバナンスの限界

現在のAIガバナンスには、構造的な問題があります。AIプロバイダーが「当社のAIは安全対策が適切に機能しています」と主張しても、独立した第三者がその主張を暗号学的に検証する手段がないのです。

たとえば、あるAIシステムが不適切な回答を生成した場合を考えてみてください。「安全装置は正常に機能していました」とプロバイダーが説明したとして、それを誰が検証できるでしょうか。ログが改ざんされていないことを、誰が保証できるでしょうか。都合の悪いログだけが削除されていないことを、どうやって証明するのでしょうか。

これが「信頼ベースのAIガバナンス」の限界です。

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

EU AI Act（欧州AI規則）は、高リスクAIシステムに対して以下を義務付けています。

Article 12：自動ログ記録 — AIシステムの稼働中の自動ログ記録
Article 14：人間による監視 — 人間による監視の記録と文書化
Article 11：技術文書 — AIシステムに関する技術文書の整備

2026年8月2日から高リスクAI義務の適用が開始されますが、問題があります。これらの要件を「どのプロトコルで」「どのデータフォーマットで」実装すべきかを定めた国際標準が存在しないのです。

法律AI特有の問題

法律AIには、一般的なAIにはない固有の課題があります。

非弁行為リスク： AIが法律事務を独立して行っていないことを、どう証明するか。弁護士法第72条は法律事務を弁護士に限定していますが、AIが生成した文書を弁護士が精査したという証跡がなければ、非弁行為の疑いが生じ得ます。

ハルシネーション： AIが架空の判例を引用した場合、それをどう事後的に検出・追跡するか。米国では2023年以降、弁護士がAI生成の虚偽判例を裁判所に提出する事案が社会問題化しています。

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

選択的ログ： AIが生成した「都合の悪い」出力だけをログから削除することを、どう技術的に防ぐか。

VAP/LAPは、これらすべての問題に対する技術的解決策を提供するために設計されました。

VAP Framework：「Verify, Don’t Trust」を実装する

設計原則

VAP（Verifiable AI Provenance Framework）の設計原則は一つです。

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

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

6層アーキテクチャ

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

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

第2層：プロベナンス層（Provenance Layer） — 「誰が」「何を入力し」「どのような文脈で」「何を実行し」「どのような結果が得られたか」を構造化して記録します。

第3層：アカウンタビリティ層（Accountability Layer） — 運用者の識別情報、承認チェーン、委任記録を管理します。「AIが言った」で終わる無責任な構造を排除し、責任の所在を明確にします。

第4層：トレーサビリティ層（Traceability Layer） — トレースIDと因果リンクにより、イベント間の因果関係を追跡可能にします。

第5層：共通基盤（Common Infrastructure） — 適合性レベル（Bronze/Silver/Gold）、外部アンカリング、完全性不変条件、エビデンスパック、プライバシー保護検証などの横断的機能を提供します。

第6層：ドメインプロファイル層（Domain Profile Layer） — 金融（VCP）、コンテンツ（CAP）、法律（LAP）などの分野固有のイベント型、データモデル拡張、規制マッピングを定義します。

暗号基盤

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

ハッシュ： SHA-256（代替としてSHA-384、SHA-512。ポスト量子はSHA3-256）
電子署名： Ed25519 / RFC 8032（代替としてECDSA P-256。ポスト量子はML-DSA-65）
暗号化： AES-256-GCM（代替としてChaCha20-Poly1305。ポスト量子はKyber-1024）

すべての暗号フィールドにアルゴリズム識別子を必須化しているため、将来のアルゴリズム移行（特にポスト量子暗号への移行）が容易です。

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

JSON正規化にはRFC 8785（JSON Canonicalization Scheme）を採用し、異なるプログラミング言語やライブラリ間でも同一のハッシュ値が計算されることを保証しています。イベントIDにはUUIDv7（RFC 9562）を採用し、時系列順のソートを保証します。

完全性不変条件（Completeness Invariant）

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

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

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

この不変条件により、3つの性質が強制されます。

完全性： すべてのATTEMPTに結果が存在する。結果のないATTEMPTは検出される
一意性： 各ATTEMPTに厳密に1つの結果が対応する。重複は検出される
参照整合性： すべての結果イベントは、発生元のATTEMPTへの因果リンクを含む

これにより、「都合の悪いログだけ消す」選択的ログが技術的に不可能になります。ATTEMPTを記録した以上、その結果を消去すれば数式が成立しなくなり、ログの欠落が数学的に検出されるのです。

適合性レベル：Bronze / Silver / Gold

VAP/LAPでは、実装の段階に応じて3つの適合性レベルを定義しています。

Bronze（中小企業・初期導入向け）： 全AI判断イベントのログ記録、SHA-256ハッシュチェーン、Ed25519電子署名、6ヶ月保持。最低限の暗号学的整合性を保証します。

Silver（エンタープライズ・規制産業向け）： Bronzeのすべてに加え、日次の外部アンカリング（RFC 3161タイムスタンプ局）、完全性不変条件の検証、エビデンスパック生成、プライバシー保護ハッシュ化、Merkleツリー構築、第三者検証エンドポイント、2年保持。

Gold（高度規制産業向け）： Silverのすべてに加え、毎時の外部アンカリング、HSM（FIPS 140-2/3）による署名鍵管理、透明性ログサービス（SCITT等）との統合、リアルタイム監査API、地理冗長性（最低2リージョン）、年次第三者監査、5年保持。

各レベルは下位のすべての要件を継承します。Gold ⊃ Silver ⊃ Bronze です。

外部アンカリングとMerkleツリー

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

RFC 3161タイムスタンプ局（TSA）を規範的ベースラインとし、イベントをバイナリMerkleハッシュツリーにバッチ処理します。Merkleルートハッシュを外部のタイムスタンプサービスに登録することで、バックデート（日付の遡り改ざん）、フォワードデート（日付の先付け改ざん）、ログのフォーク（分岐改ざん）をすべて防止します。

Merkle包含証明（Inclusion Proof）により、バッチ内の他のイベントを開示することなく、特定のイベントが確かにそのバッチに含まれていたことを証明できます。これはプライバシーの観点から極めて重要です。

エビデンスパック

エビデンスパックは、上記のアンカリング済み証跡を、規制当局や第三者監査人への提出に適した自己完結型パッケージとして標準化したものです。マニフェスト（メタデータ）、イベントファイル群（1ファイル最大10,000件）、アンカー記録、Merkleツリー構造、公開鍵情報、パック全体の署名で構成されます。

LAP：司法AI固有の5つの課題を解決する

Legal AI Profile（LAP）とは

LAP（Legal AI Profile）は、VAPの司法AI向けドメインプロファイルです。法律AIには一般的なAIとは異なる固有の課題があり、LAPはそれらを技術的に解決します。

課題	LAPによる解決
非弁行為リスク	HUMAN_OVERRIDEイベントによる弁護士精査証跡
ハルシネーション	LEGAL_FACTCHECKイベントによる検証証跡
選択的ログ	3パイプライン完全性不変条件
守秘義務との緊張	プライバシー保護フィールド（ハッシュ化）
責任の曖昧性	アカウンタビリティ層による責任記録

3つのパイプライン

LAPは法律AIの3つの主要機能を、それぞれ独立したパイプラインとして定義します。

パイプライン1：法律相談（Legal Query）

LEGAL_QUERY_ATTEMPT（質問送信）
    ├── LEGAL_QUERY_RESPONSE（AI回答生成）
    ├── LEGAL_QUERY_DENY（回答拒否）
    └── LEGAL_QUERY_ERROR（システムエラー）

パイプライン2：文書生成（Document Generation）

LEGAL_DOC_ATTEMPT（文書生成依頼）
    ├── LEGAL_DOC_RESPONSE（文書生成成功）
    ├── LEGAL_DOC_DENY（生成拒否）
    └── LEGAL_DOC_ERROR（システムエラー）

パイプライン3：ファクトチェック（Fact Check）

LEGAL_FACTCHECK_ATTEMPT（ファクトチェック依頼）
    ├── LEGAL_FACTCHECK_RESPONSE（チェック完了）
    ├── LEGAL_FACTCHECK_DENY（チェック拒否・任意実装）
    └── LEGAL_FACTCHECK_ERROR（システムエラー）

各パイプラインに完全性不変条件が独立して適用されるため、たとえば法律相談の完全性と文書生成の完全性はそれぞれ個別に検証できます。

HUMAN_OVERRIDE：弁護士精査の暗号学的証明

HUMAN_OVERRIDEイベントは、弁護士がAI出力を精査した事実を暗号学的に記録する、LAP固有の重要なイベント型です。

精査の種類は3つです。

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

各HUMAN_OVERRIDEイベントには、弁護士登録番号のハッシュ値（BarNumberHash）と、対象となるAI出力イベントへの因果リンク（target_event_id）が含まれます。これにより、「どの弁護士が」「どのAI出力に対して」「いつ」「どのような判断を下したか」が暗号学的に記録されます。

Override Coverage メトリクスは、AI出力に対する弁護士精査率を計測します。

Override Coverage = Count(HUMAN_OVERRIDE) / (Count(RESPONSE) + Count(DENY))

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

法務省ガイドライン（2023年8月）は、AI法務支援サービスを弁護士に提供する場合、「弁護士が自ら精査し、必要に応じて自ら修正を行う方法で利用するとき」に弁護士法72条に違反しないとしています。Override Coverageは、この「弁護士が自ら精査」という要件の充足度を定量的に計測するメトリクスです。

プライバシー保護フィールド：守秘義務と検証可能性の両立

法律AIが扱うデータは、弁護士・依頼者間の秘匿特権によって保護されます。依頼者の相談内容やAIの回答内容をそのままログに記録することは、守秘義務に反する可能性があります。

LAPは、この問題をハッシュ化によって解決します。生のテキストではなく、そのSHA-256ハッシュ値を記録するのです。

元データ	ハッシュフィールド	保護対象
ユーザーの質問文	PromptHash	法律相談内容
AI回答文	ResponseHash	AI生成回答
生成文書	OutputHash	法律文書
事件番号	CaseNumberHash	事件識別子
弁護士登録番号	BarNumberHash	弁護士識別子
当事者氏名	PartyHash	個人情報
修正内容	ModificationHash	弁護士の修正
ファクトチェック対象	TargetContentHash	検証対象テキスト

ハッシュ計算にはテナントごとの個別ソルトを使用し、テナント間の相関攻撃（異なるテナントの同一内容を照合する攻撃）を防止します。

第三者検証者は、ハッシュチェーンの整合性、完全性不変条件の成立、Override Coverageの計測を行うことができますが、法律相談の具体的な内容や当事者の個人情報にはアクセスできません。守秘義務を完全に保護しながら、システムの健全性を暗号学的に検証できるのです。

拡張されたデータ保持期間

法律分野では、出訴期限が長期にわたるケースがあります。LAPはこれを踏まえ、VAPの標準保持期間を拡張しています。

適合性レベル	VAP標準	LAP拡張
Bronze	6ヶ月	6ヶ月（同一）
Silver	2年	3年
Gold	5年	10年

AILEXの実装：仕様から実装へ

AILEXのSaaS（https://users.ailex.co.jp）は、このVAP/LAP仕様のリファレンス実装です。AILEXが創業以来実践してきた設計思想——PIIマスキング、AIファクトチェック、監査ログ——は、まさにVAP/LAPが標準化しようとしている「検証可能なAI」そのものです。

PIIMasker（個人情報自動マスキング）： 外部AIのAPIに送信する前に、依頼者の個人情報を自動的にマスキングします。これにより、弁護士・依頼者間の守秘義務を技術的に保護しながら、外部AIの能力を活用できます。LAPのプライバシー保護フィールドの実装基盤です。

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

監査ログ（AuditLogger）： すべての重要な操作を記録する監査ログ機能を実装しています。LAPのイベント記録基盤です。

IETF提出の戦略的意義

今回の提出には、3つの戦略的目的があります。

1. オープンな国際標準の確立

VAP/LAPは特定のベンダーに依存しないオープン仕様です。AILEX以外の法律AI/リーガルテックサービスも、この仕様に準拠することで、同じ基準で検証可能性を実現できます。標準化により、「検証可能なAI」が特定企業の独自機能ではなく、業界全体の共通基盤になることを目指しています。

2. IETF SCITT WGとの連携

IETFでは、サプライチェーンの整合性と透明性に関するワーキンググループ「SCITT（Supply Chain Integrity, Transparency, and Trust）」が活動しています。AILEXはすでにSCITT関連の関連ドラフト（draft-ailex-scitt-vcp、draft-ailex-scitt-refusal-events）を提出しており、今回のVAP/LAPはこれらを統合する上位フレームワークとして位置づけられます。

3. Running Code の原則

IETFは「Running Code」の原則を重視します。仕様書だけの提案ではなく、実際に動く実装が存在することが標準化の強力な推進力になります。AILEX SaaSがVAP/LAPのリファレンス実装として稼働していることは、この原則を直接的に満たすものです。

「便利なAI」から「検証可能なAI」へ

リーガルテック市場では、「AIで書面を自動生成する」「AIで契約書をレビューする」といった「便利なAI」の競争が激化しています。しかし、AIの便利さには構造的な落とし穴があります。AIが生成した文書が誤った判例を引用していた場合、それを誰が、いつ、どのように検証したのか。AIに送信された依頼者の秘密情報が、どこに、どのような形で処理されたのか。便利さを追求するだけでは、これらの問いに答えることができません。

AILEXは創業以来、「検証可能性」をプロダクトの中核に据えてきました。外部AIへの送信前に依頼者情報を自動マスキングするPIIMasker、AI回答を別のAIで独立検証するファクトチェック機能、そしてすべてのAI操作を記録する監査ログ。これらは「AIが便利に動く」ためではなく、「AIがどう動いたかを証明できる」ために設計されたものです。

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

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

今後のロードマップ

時期	マイルストーン
2026年2月	Internet-Draft -00 提出・公開 ✅
2026年Q2	IETF会合での発表・フィードバック収集
2026年8月	EU AI Act高リスク義務適用に合わせたリビジョン（-01）提出
2026年Q4以降	ワーキンググループ採択の提案・独立実装の獲得