AI法務SaaS「AILEX」、IETF Internet-Draftの改訂版（-02）を提出 ～ 法務関係者とセキュリティ技術者のレビューを反映し、 AI判断の検証可能性を大幅に強化 ～
AILEX合同会社（本社：東京都渋谷区、顧問弁護士事務所：弁護士法人えそら）は、同社がIETF（Internet Engineering Task Force）に提出しているInternet-Draft「Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP)」の改訂版（-02）を、IETF Datatrackerに提出いたしましたのでお知らせいたします。
IETF Internet-Draft公開URL：
https://datatracker.ietf.org/doc/draft-ailex-vap-legal-ai-provenance/
■ 改訂の背景
本Internet-Draftは、AIが生成した法律文書や法務判断の真正性を暗号技術で検証可能にするための技術仕様です。2026年2月に初版（-00）を提出後、-01を経て、法務関係者およびIETF・セキュリティ分野の技術者から寄せられた指摘をもとに、仕様の曖昧さや実装上の解釈割れを招く箇所を体系的に改善しました。
改訂前の仕様（-01）は33ページでしたが、改訂後（-02）は54ページとなり、実装者が迷わず検証コードを書ける水準まで仕様の具体性を引き上げています。
■ -02で改善した主な技術的課題（6項目）
(1) イベントハッシュの循環参照を解消
-01では、イベントのハッシュ値を計算する際に「何を除外するか」が曖昧であり、実装者によって異なるハッシュ値が生成される恐れがありました。-02では、除外すべきフィールド（security.event_hashとsecurity.signature）を明示的に定義し、Hash Inputの計算手順を一意に確定させました。これにより、どの実装でも同一のハッシュ値が得られることが保証されます。
(2) 暗号アルゴリズム識別子の正規化
-01ではアルゴリズムの表記に「SHA-256」「sha256」「SHA256」のような揺れがあり、バイト列の比較で不一致を起こす可能性がありました。-02ではCanonical Algorithm Identifiers（正規化アルゴリズム識別子テーブル）を導入し、全識別子を小文字ハイフン区切りのASCII文字列に統一しました。フィールド値とワイヤプレフィクスが同一文字列となるため、実装上の混乱が生じません。
(3) Merkleツリー構成をRFC 9162準拠に統一
-01ではMerkleツリーの構成にRFC 6962（旧版）とRFC 9162（Certificate Transparency v2）の混在が見られました。-02ではRFC 9162に統一し、domain separation（葉ノードに0x00、内部ノードに0x01のプレフィクス付与）を明記しました。これにより、第二プリイメージ攻撃への耐性と、証明の生成・検証の一致が保証されます。
(4) アンカー証明を型付きに再設計
-01ではアンカー証明（anchor_proof）が単一の文字列型であり、検証に必要な情報が構造化されていませんでした。-02では、アンカー種別（RFC 3161タイムスタンプ、透明性ログ、ブロックチェーン）ごとに固有のフィールド構造を定義し、第三者による機械的な検証を現実的にしました。
(5) 第三者検証APIの最低要件を定義
-01ではSilverレベルで第三者検証エンドポイントが必須（REQUIRED）とされていましたが、具体的なプロトコル定義がありませんでした。-02では5つのHTTPエンドポイント（アンカー取得、チェーン整合性検証、完全性不変条件検証、Merkle包含証明、リアルタイムストリーム）を定義し、認証方式とエラーレスポンスの仕様も含めました。
(6) IANAレジストリの正式定義
-02では、IANA（Internet Assigned Numbers Authority）への登録テンプレートとして、メディアタイプ2種（application/vap-evidence-pack+zip、application/vap-manifest+json）、ドメインプロファイル識別子レジストリ、およびイベントタイプレジストリを定義しました。これはIETFの標準化プロセスにおいて、仕様の再利用性と他プロトコルとの相互運用性を確保するための重要な要件です。
